[PATCH] drm/radeon: add new AMD ACPI header and update relevant code

[Luca Tettamanti]

On Mon, Jul 30, 2012 at 10:30 PM, Alex Deucher  wrote:
> On Mon, Jul 30, 2012 at 4:24 PM, Luca Tettamanti  
> wrote:
>> On Mon, Jul 30, 2012 at 10:20:15AM -0400, Alex Deucher wrote:
>>> Supported DWORD Bit vector providing supported functions
>>> information. Each bit marks
>>> Functions Bit  support for one specific function of the
>>> ATIF method. Bit n, if set,
>>> Vectorindicates that Function n+1 is supported.
>>
>> Sorry, I still don't understand it... what's "Function n+1" in this
>> context?
>> Does this mean that if bit n is set then the function defined as
>> 1 << (n+1) is supported?
>
> It means if bit n is set in teh supported function vector, function
> n+1 is supported.  E.g., if bit 1 is set, function 2
> (ATIF_FUNCTION_GET_SYSTEM_BIOS_REQUESTS) is supported.  If bit 3 is
> set function 4 (ATIF_FUNCTION_GET_LID_STATE) is supported, etc.

Great, just had an epiphany ;-) "n+1" refers to the value that's
passed down to ATIF, I was still thinking in terms of bitmasks...
Ok, so my code is correct, BIOS is botched... meh.

L

[PATCH] drm/radeon: add new AMD ACPI header and update relevant code

[Luca Tettamanti]

On Mon, Jul 30, 2012 at 10:20:15AM -0400, Alex Deucher wrote:
> On Sun, Jul 29, 2012 at 9:06 AM, Luca Tettamanti  
> wrote:
> > On Sat, Jul 28, 2012 at 05:29:25PM -0400, Alex Deucher wrote:
> >> On Sat, Jul 28, 2012 at 10:56 AM, Luca Tettamanti  
> >> wrote:
> >> > I just found the first problem (probably a BIOS bug):
> >> > ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
> >> > corresponding bit ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED is not set :(
> >> > I intended to use the method to set up the notification handler but now
> >> > my BIOS says that it's not there even if it is...
> >> > Can I assume some default values (e.g. notifications are enabled and will
> >> > use 0x81 unless ATIF_FUNCTION_GET_SYSTEM_PARAMETERS says something
> >> > different)?
> >>
> >> The spec says that the bits in the supported functions vector mean
> >> that if bit n is set, function n+1 exists,
> >
> > Hum, I don't follow. The vector in my case is 0x2 (1 << 1), that would
> > mean that ATIF_SELECT_ACTIVE_DISPLAYS_SUPPORTED (1 << 2) is supported?
> >
> > Maybe if the bit n is set then functions 0..n are available? That would
> > (almost) match what I see...
> 
> From the spec:
> 
> Supported DWORD Bit vector providing supported functions
> information. Each bit marks
> Functions Bit  support for one specific function of the
> ATIF method. Bit n, if set,
> Vectorindicates that Function n+1 is supported.

Sorry, I still don't understand it... what's "Function n+1" in this
context?
Does this mean that if bit n is set then the function defined as
1 << (n+1) is supported?

> I don't know how wonky bioses in the wild are however.  I can see what
> our internal teams do in these sort of cases.

That would be helpful :)
Note that on this machine (Toshiba L855-10W) brightness control under
windows does not work with the stock catalyst driver, it works only with
the (oldish) driver supplied by Toshiba.

Anyway, I'm attaching v2 of my patches, I've incorporated the
suggestions and some bits of code from joeyli, and now brightness
control is actually implemented.

Still missing is the issue of event 0x81 and the conflict with video.ko;
the handler should probably return NOTIFY_BAD to veto the keypress.

Luca
-- next part --
>From f0f8699eabee0d47b93fba14f8126b821cc106a5 Mon Sep 17 00:00:00 2001
From: Luca Tettamanti 
Date: Sun, 29 Jul 2012 17:04:43 +0200
Subject: [PATCH 1/4] drm/radeon: refactor radeon_atif_call

Don't hard-code function number, this will allow to reuse the function.
v2: add support for the 2nd parameter (from Lee, Chun-Yi
).

Signed-off-by: Luca Tettamanti 
---
 drivers/gpu/drm/radeon/radeon_acpi.c |   38 --
 1 file changed, 23 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c 
b/drivers/gpu/drm/radeon/radeon_acpi.c
index 5b32e49..158e514 100644
--- a/drivers/gpu/drm/radeon/radeon_acpi.c
+++ b/drivers/gpu/drm/radeon/radeon_acpi.c
@@ -14,23 +14,30 @@
 #include 

 /* Call the ATIF method
- *
- * Note: currently we discard the output
  */
-static int radeon_atif_call(acpi_handle handle)
+static union acpi_object *radeon_atif_call(acpi_handle handle, int function,
+   struct acpi_buffer *params)
 {
acpi_status status;
union acpi_object atif_arg_elements[2];
struct acpi_object_list atif_arg;
-   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL};
+   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };

atif_arg.count = 2;
atif_arg.pointer = _arg_elements[0];

atif_arg_elements[0].type = ACPI_TYPE_INTEGER;
-   atif_arg_elements[0].integer.value = ATIF_FUNCTION_VERIFY_INTERFACE;
-   atif_arg_elements[1].type = ACPI_TYPE_INTEGER;
-   atif_arg_elements[1].integer.value = 0;
+   atif_arg_elements[0].integer.value = function;
+
+   if (params) {
+   atif_arg_elements[1].type = ACPI_TYPE_BUFFER;
+   atif_arg_elements[1].buffer.length = params->length;
+   atif_arg_elements[1].buffer.pointer = params->pointer;
+   } else {
+   /* We need a second fake parameter */
+   atif_arg_elements[1].type = ACPI_TYPE_INTEGER;
+   atif_arg_elements[1].integer.value = 0;
+   }

status = acpi_evaluate_object(handle, "ATIF", _arg, );

@@ -39,18 +46,18 @@ static int radeon_atif_call(acpi_handle handle)
DRM_DEBUG_DRIVER("failed to evaluate ATIF got %s\n",
 acpi_format_exception(status));
kfree(buffer.pointer);
-   return 1;
+   return NULL;
}

-   kfree(buffer.pointer);
-   return 0;
+   return buffer.pointer;
 }

 /* Call all ACPI methods here */
 int radeon_acpi_init(struct radeon_device *rdev)
 {
acpi_handle handle;
-   int ret;
+   union acpi_object *info;
+   int 

[PATCH] drm/radeon/kms: allow "invalid" DB formats as a means to disable DB

[Marek Olšák]

After some discussion in private, we've come to the conclusion that
this is a very important fix. So if it's possible:

Cc: stable at kernel.org

Applicable to 3.5 stable kernel only.

Marek

On Sun, Jul 29, 2012 at 4:24 PM, Marek Ol??k  wrote:
> Signed-off-by: Marek Ol??k 
> ---
>  drivers/gpu/drm/radeon/evergreen_cs.c |6 --
>  drivers/gpu/drm/radeon/evergreend.h   |2 ++
>  drivers/gpu/drm/radeon/r600_cs.c  |6 --
>  drivers/gpu/drm/radeon/radeon_drv.c   |3 ++-
>  4 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index c1655412..f2e5c54 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -961,13 +961,15 @@ static int evergreen_cs_track_check(struct 
> radeon_cs_parser *p)
>
> if (track->db_dirty) {
> /* Check stencil buffer */
> -   if (G_028800_STENCIL_ENABLE(track->db_depth_control)) {
> +   if (G_028044_FORMAT(track->db_s_info) != 
> V_028044_STENCIL_INVALID &&
> +   G_028800_STENCIL_ENABLE(track->db_depth_control)) {
> r = evergreen_cs_track_validate_stencil(p);
> if (r)
> return r;
> }
> /* Check depth buffer */
> -   if (G_028800_Z_ENABLE(track->db_depth_control)) {
> +   if (G_028040_FORMAT(track->db_z_info) != V_028040_Z_INVALID &&
> +   G_028800_Z_ENABLE(track->db_depth_control)) {
> r = evergreen_cs_track_validate_depth(p);
> if (r)
> return r;
> diff --git a/drivers/gpu/drm/radeon/evergreend.h 
> b/drivers/gpu/drm/radeon/evergreend.h
> index b50b15c..4a43b46 100644
> --- a/drivers/gpu/drm/radeon/evergreend.h
> +++ b/drivers/gpu/drm/radeon/evergreend.h
> @@ -1273,6 +1273,8 @@
>  #define   S_028044_FORMAT(x)   (((x) & 0x1) << 0)
>  #define   G_028044_FORMAT(x)   (((x) >> 0) & 0x1)
>  #define   C_028044_FORMAT  0xFFFE
> +#defineV_028044_STENCIL_INVALID0
> +#defineV_028044_STENCIL_8  1
>  #define   G_028044_TILE_SPLIT(x)   (((x) >> 8) & 0x7)
>  #define DB_Z_READ_BASE 0x28048
>  #define DB_STENCIL_READ_BASE   0x2804c
> diff --git a/drivers/gpu/drm/radeon/r600_cs.c 
> b/drivers/gpu/drm/radeon/r600_cs.c
> index ca87f7a..1119e31 100644
> --- a/drivers/gpu/drm/radeon/r600_cs.c
> +++ b/drivers/gpu/drm/radeon/r600_cs.c
> @@ -764,8 +764,10 @@ static int r600_cs_track_check(struct radeon_cs_parser 
> *p)
> }
>
> /* Check depth buffer */
> -   if (track->db_dirty && 
> (G_028800_STENCIL_ENABLE(track->db_depth_control) ||
> -   G_028800_Z_ENABLE(track->db_depth_control))) {
> +   if (track->db_dirty &&
> +   G_028010_FORMAT(track->db_depth_info) != V_028010_DEPTH_INVALID &&
> +   (G_028800_STENCIL_ENABLE(track->db_depth_control) ||
> +G_028800_Z_ENABLE(track->db_depth_control))) {
> r = r600_cs_track_validate_db(p);
> if (r)
> return r;
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 2c4d53f..ed13538 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -59,9 +59,10 @@
>   *   2.15.0 - add max_pipes query
>   *   2.16.0 - fix evergreen 2D tiled surface calculation
>   *   2.17.0 - add STRMOUT_BASE_UPDATE for r7xx
> + *   2.18.0 - r600-eg: allow "invalid" DB formats
>   */
>  #define KMS_DRIVER_MAJOR   2
> -#define KMS_DRIVER_MINOR   17
> +#define KMS_DRIVER_MINOR   18
>  #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);
> --
> 1.7.9.5
>

[Bug 49817] radeon: The kernel rejected CS when running shader example from SFML library

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

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

--- Comment #9 from Sven Arvidsson  2012-07-30 21:22:54 UTC ---
(In reply to comment #8)
> same problem here when trying to run dungeon siege 2 via wine, intro plays 
> fine
> and then hangs , found a radeon problem to be the cause.
> 

Keep in mind that you can get these errors does not necessarily indicate the
same problem, so it's probably not a good idea to make this bug a dumping
ground for rejected CS.

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

[Bug 49817] radeon: The kernel rejected CS when running shader example from SFML library

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

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

--- Comment #8 from stevenvandenbrandenstift at gmail.com 2012-07-30 20:30:03 
UTC ---
same problem here when trying to run dungeon siege 2 via wine, intro plays fine
and then hangs , found a radeon problem to be the cause.

dmegs output:

[ 7230.283645] radeon :00:01.0: evergreen_cs_track_validate_cb:477 cb[0] bo
too small (layer size -2147483648, offset 0, max layer 1, bo size 4096, slice
4194303)
[ 7230.283665] radeon :00:01.0: evergreen_cs_track_validate_cb:481
problematic surf: (32 8388608) (0 8 1 0 0 0 0)
[ 7230.283675] radeon :00:01.0: evergreen_packet3_check:2096 invalid cmd
stream 783
[ 7230.283684] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[ 7231.299423] radeon :00:01.0: evergreen_cs_track_validate_cb:477 cb[0] bo
too small (layer size -2147483648, offset 0, max layer 1, bo size 4096, slice
4194303)
[ 7231.299434] radeon :00:01.0: evergreen_cs_track_validate_cb:481
problematic surf: (32 8388608) (0 8 1 0 0 0 0)
[ 7231.299439] radeon :00:01.0: evergreen_packet3_check:2096 invalid cmd
stream 783
[ 7231.299444] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !

the wine errors (don't know if helpfull at all) show a directdraw problem

]$ wine ./.wine/drive_c/Program\ Files/2K\ Games/Dungeon\ Siege\ 2\ Broken\
World/DS2VideoConfig.exe 
fixme:ddraw:DirectDrawEnumerateExA flags 0x0007 not handled
radeon: The kernel rejected CS, see dmesg for more information.
fixme:win:EnumDisplayDevicesW ((null),0,0x33e048,0x), stub!
radeon: The kernel rejected CS, see dmesg for more information.
fixme:win:EnumDisplayDevicesW ((null),0,0x33e114,0x), stub!

uname -a:  
3.4.6-1-ARCH #1 SMP PREEMPT Fri Jul 20 08:21:26 CEST 2012 x86_64 GNU/Linux

glxinfo:

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD PALM
OpenGL version string: 2.1 Mesa 8.0.4
OpenGL shading language version string: 1.20

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

drm/nouveau: crash regression in 3.5

[Marcin Slusarz]

On Mon, Jul 30, 2012 at 01:16:37PM +0200, Ortwin Gl?ck wrote:
> On 29.07.2012 22:15, Marcin Slusarz wrote:
> > No, the real problem is: with "noaccel" we don't register "software engine",
> > but vblank ISR relies on its existance and happily derefences NULL pointer.
> >
> > Now, this patch should fix it for real...
> 
> Unfortunately I am still seeing the crash. Without "noaccel" it works though 
> (until X crashes the machine, but that is a different thing).

Are you sure you boot the correct kernel? I'm asking because your panic says its
version is "3.5.0 #3" - exactly the same as in previous crash log.

Marcin

Massive power regression going 3.4->3.5

[James Bottomley]

On Mon, 2012-07-30 at 09:33 -0700, Keith Packard wrote:
> James Bottomley  writes:
> 
> > OK, I've run the bisect as far as I can.  It looks to be in the drm
> > tree.  Unfortunately, this tree has several merge points, some of which
> > go further back than v3.4.  Unfortunately, once the bisect steps back
> > before 3.4, we lose the changes that gave us the power savings, making
> > further debugging impossible
> 
> What machine is this on? There are a few 'disable some power savings'
> patches in that list to work around issues on various machines; knowing
> what machine you're using can isolate which ones might have had some
> effect on power usage...

Lenovo X220i

The display device is

00:02.0 VGA compatible controller: Intel Corporation
82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03)
(prog-if 00 [VGA controller])
Subsystem: Giga-byte Technology Device 2562
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at e000 (32-bit, prefetchable) [size=128M]
Memory at e820 (32-bit, non-prefetchable) [size=512K]
Expansion ROM at  [disabled]
Capabilities: 
Kernel driver in use: i915


James

[PATCH 1/3] Move FIMD register headers to include/video/

[Jingoo Han]

On Monday, July 30, 2012 5:45 PM, Leela Krishna Amudala wrote:
> 
> Moved the contents of regs-fb-v4.h and regs-fb.h from arch side
> to include/video/samsung_fimd.h
> 
> Signed-off-by: Leela Krishna Amudala 
> ---
>  arch/arm/plat-samsung/include/plat/regs-fb-v4.h |  159 ---
>  arch/arm/plat-samsung/include/plat/regs-fb.h|  403 -
>  include/video/samsung_fimd.h|  533 
> +++
>  3 files changed, 533 insertions(+), 562 deletions(-)
>  delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h
>  delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h
>  create mode 100644 include/video/samsung_fimd.h
> 
> diff --git a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h 
> b/arch/arm/plat-samsung/include/plat/regs-
> fb-v4.h
> deleted file mode 100644
> index 4c3647f..000
> --- a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h
> +++ /dev/null
> @@ -1,159 +0,0 @@
> -/* arch/arm/plat-samsung/include/plat/regs-fb-v4.h
> - *
> - * Copyright 2008 Openmoko, Inc.
> - * Copyright 2008 Simtec Electronics
> - *  http://armlinux.simtec.co.uk/
> - *  Ben Dooks 
> - *
> - * S3C64XX - new-style framebuffer register definitions
> - *
> - * This is the register set for the new style framebuffer interface
> - * found from the S3C2443 onwards and specifically the S3C64XX series
> - * S3C6400 and S3C6410.
> - *
> - * The file contains the cpu specific items which change between whichever
> - * architecture is selected. See  for the core definitions
> - * that are the same.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> -*/
> -
> -/* include the core definitions here, in case we really do need to
> - * override them at a later date.
> -*/
> -
> -#include 
> -
> -#define S3C_FB_MAX_WIN (5)  /* number of hardware windows available. */
> -#define VIDCON1_FSTATUS_EVEN (1 << 15)
> -
> -/* Video timing controls */
> -#define VIDTCON0 (0x10)
> -#define VIDTCON1 (0x14)
> -#define VIDTCON2 (0x18)
> -
> -/* Window position controls */
> -
> -#define WINCON(_win) (0x20 + ((_win) * 4))
> -
> -/* OSD1 and OSD4 do not have register D */
> -
> -#define VIDOSD_BASE  (0x40)
> -
> -#define VIDINTCON0   (0x130)
> -
> -/* WINCONx */
> -
> -#define WINCONx_CSCWIDTH_MASK(0x3 << 26)
> -#define WINCONx_CSCWIDTH_SHIFT   (26)
> -#define WINCONx_CSCWIDTH_WIDE(0x0 << 26)
> -#define WINCONx_CSCWIDTH_NARROW  (0x3 << 26)
> -
> -#define WINCONx_ENLOCAL  (1 << 22)
> -#define WINCONx_BUFSTATUS(1 << 21)
> -#define WINCONx_BUFSEL   (1 << 20)
> -#define WINCONx_BUFAUTOEN(1 << 19)
> -#define WINCONx_YCbCr(1 << 13)
> -
> -#define WINCON1_LOCALSEL_CAMIF   (1 << 23)
> -
> -#define WINCON2_LOCALSEL_CAMIF   (1 << 23)
> -#define WINCON2_BLD_PIX  (1 << 6)
> -
> -#define WINCON2_ALPHA_SEL(1 << 1)
> -#define WINCON2_BPPMODE_MASK (0xf << 2)
> -#define WINCON2_BPPMODE_SHIFT(2)
> -#define WINCON2_BPPMODE_1BPP (0x0 << 2)
> -#define WINCON2_BPPMODE_2BPP (0x1 << 2)
> -#define WINCON2_BPPMODE_4BPP (0x2 << 2)
> -#define WINCON2_BPPMODE_8BPP_1232(0x4 << 2)
> -#define WINCON2_BPPMODE_16BPP_565(0x5 << 2)
> -#define WINCON2_BPPMODE_16BPP_A1555  (0x6 << 2)
> -#define WINCON2_BPPMODE_16BPP_I1555  (0x7 << 2)
> -#define WINCON2_BPPMODE_18BPP_666(0x8 << 2)
> -#define WINCON2_BPPMODE_18BPP_A1665  (0x9 << 2)
> -#define WINCON2_BPPMODE_19BPP_A1666  (0xa << 2)
> -#define WINCON2_BPPMODE_24BPP_888(0xb << 2)
> -#define WINCON2_BPPMODE_24BPP_A1887  (0xc << 2)
> -#define WINCON2_BPPMODE_25BPP_A1888  (0xd << 2)
> -#define WINCON2_BPPMODE_28BPP_A4888  (0xd << 2)
> -
> -#define WINCON3_BLD_PIX  (1 << 6)
> -
> -#define WINCON3_ALPHA_SEL(1 << 1)
> -#define WINCON3_BPPMODE_MASK (0xf << 2)
> -#define WINCON3_BPPMODE_SHIFT(2)
> -#define WINCON3_BPPMODE_1BPP (0x0 << 2)
> -#define WINCON3_BPPMODE_2BPP (0x1 << 2)
> -#define WINCON3_BPPMODE_4BPP (0x2 << 2)
> -#define WINCON3_BPPMODE_16BPP_565(0x5 << 2)
> -#define WINCON3_BPPMODE_16BPP_A1555  (0x6 << 2)
> -#define WINCON3_BPPMODE_16BPP_I1555  (0x7 << 2)
> -#define WINCON3_BPPMODE_18BPP_666(0x8 << 2)
> 

[PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Marek Olšák]

On Mon, Jul 30, 2012 at 4:56 PM, Jerome Glisse  wrote:
> On Sun, Jul 29, 2012 at 1:04 PM, Marek Ol??k  wrote:
>> If we don't need stencil, don't allocate it.
>> If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.
>>
>> v2: actually do it correctly
>
> Big NAK
>
> We need to allocate stencil and depth no matter what. Otherwise it
> will lockup. You can take a look by poisonning the surface and see
> that when stencil is disabled or depth is disabled the hw still write
> to it.

:)

If what you say is true, then we're in a big trouble. Regardless of
this patch, we're in it right now, because we cannot fully disable
depth or stencil if the user binds a NULL zbuffer. That's clearly the
kind of issue that cannot be fixed in the allocator code and should be
fixed in r600g where the hardware is programmed.

I *think* that the correct way to disable Z or stencil is to set the
Z_INVALID or STENCIL_INVALID format, respectively, and not by
disabling reads and writes. (cc'ing Alex to confirm that if he can). I
don't think the hardware designers have added those "invalid" formats
just for the lulz. Please see my latest kernel patch "drm/radeon/kms:
allow "invalid" DB formats as a means to disable DB" that tries to
address this issue.

For r600g, I was thinking of allocating a dummy buffer that will be
always bound in case the depth or stencil buffer or both are missing.
Either way, we should find how to get around this issue without
wasting memory, especially when there are other options to try.

BTW, before we used this allocator, we allocated the depth and stencil
buffers in separate resources. We might need to get back to it in the
future if Gallium grows separate depth and stencil buffer bindings.

Marek

[PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Roland Scheidegger]

Am 30.07.2012 16:56, schrieb Jerome Glisse:
> On Sun, Jul 29, 2012 at 1:04 PM, Marek Ol??k  wrote:
>> If we don't need stencil, don't allocate it.
>> If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.
>>
>> v2: actually do it correctly
> 
> Big NAK
> 
> We need to allocate stencil and depth no matter what. Otherwise it
> will lockup. You can take a look by poisonning the surface and see
> that when stencil is disabled or depth is disabled the hw still write
> to it.

That seems weird - bandwidth is a precious resource. Is that because of
some misconfiguration elsewhere? Or hiz buffers or the like?

Roland

> 
> Cheers,
> Jerome
> 
>> ---
>>  radeon/radeon_surface.c |   23 ---
>>  1 file changed, 8 insertions(+), 15 deletions(-)
>>
>> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
>> index 5800c33..874a092 100644
>> --- a/radeon/radeon_surface.c
>> +++ b/radeon/radeon_surface.c
>> @@ -604,7 +604,11 @@ static int eg_surface_init_1d(struct 
>> radeon_surface_manager *surf_man,
>>  }
>>  }
>>
>> -if (surf->flags & RADEON_SURF_SBUFFER) {
>> +/* The depth and stencil buffers are in separate resources on evergreen.
>> + * We allocate them in one buffer next to each other to simplify
>> + * communication between the DDX and the Mesa driver. */
>> +if ((surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) ==
>> +   (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
>>  surf->stencil_offset = ALIGN(surf->bo_size, surf->bo_alignment);
>>  surf->bo_size = surf->stencil_offset + surf->bo_size / 4;
>>  }
>> @@ -656,7 +660,8 @@ static int eg_surface_init_2d(struct 
>> radeon_surface_manager *surf_man,
>>  }
>>  }
>>
>> -if (surf->flags & RADEON_SURF_SBUFFER) {
>> +if ((surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) ==
>> +   (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
>>  surf->stencil_offset = ALIGN(surf->bo_size, surf->bo_alignment);
>>  surf->bo_size = surf->stencil_offset + surf->bo_size / 4;
>>  }
>> @@ -752,14 +757,7 @@ static int eg_surface_init(struct 
>> radeon_surface_manager *surf_man,
>>  /* tiling mode */
>>  mode = (surf->flags >> RADEON_SURF_MODE_SHIFT) & RADEON_SURF_MODE_MASK;
>>
>> -/* for some reason eg need to have room for stencil right after depth */
>> -if (surf->flags & RADEON_SURF_ZBUFFER) {
>> -surf->flags |= RADEON_SURF_SBUFFER;
>> -}
>> -if (surf->flags & RADEON_SURF_SBUFFER) {
>> -surf->flags |= RADEON_SURF_ZBUFFER;
>> -}
>> -if (surf->flags & RADEON_SURF_ZBUFFER) {
>> +if (surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
>>  /* zbuffer only support 1D or 2D tiled surface */
>>  switch (mode) {
>>  case RADEON_SURF_MODE_1D:
>> @@ -828,11 +826,6 @@ static int eg_surface_best(struct 
>> radeon_surface_manager *surf_man,
>>  /* tiling mode */
>>  mode = (surf->flags >> RADEON_SURF_MODE_SHIFT) & RADEON_SURF_MODE_MASK;
>>
>> -/* for some reason eg need to have room for stencil right after depth */
>> -if (surf->flags & RADEON_SURF_ZBUFFER) {
>> -surf->flags |= RADEON_SURF_SBUFFER;
>> -}
>> -
>>  /* set some default value to avoid sanity check choking on them */
>>  surf->tile_split = 1024;
>>  surf->bankw = 1;
>> --
>> 1.7.9.5
>>
>> ___
>> 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
> 

Fwd: Brightness on HP EliteBook 8460p

[joeyli]

? ??2012-07-30 ? 10:17 +0200?Artur Flinta ???
> On Sat, Jul 28, 2012 at 4:47 PM, Pali Roh?r  wrote:
> > Hello, I have some good news. Radeon patches from this post
> > http://lists.freedesktop.org/archives/dri-devel/2012-July/025535.html
> > export brightness file /sys/class/backlight/radeon_bl/brightness
> > And finally with these patches I'm able to change brightness on my 
> > EliteBook.
> 
> Wow, it's great news :) I was reading yesterday info about ACPI
> patches from AMD on Phronix and thinking will it help or no, and now I
> have an answer :)
> 
> Regards
> Artur

Yes, thanks for Alex's 3 patches, those patches also works to me on my
machine for backlight control.


Thanks
Joey LEe

[PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Christian König]

On 30.07.2012 16:56, Jerome Glisse wrote:
> On Sun, Jul 29, 2012 at 1:04 PM, Marek Ol??k  wrote:
>> If we don't need stencil, don't allocate it.
>> If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.
>>
>> v2: actually do it correctly
> Big NAK
>
> We need to allocate stencil and depth no matter what. Otherwise it
> will lockup. You can take a look by poisonning the surface and see
> that when stencil is disabled or depth is disabled the hw still write
> to it.

Really? That bug is new to me, at least on SI that works perfectly 
(currently working on it), so on which hardware do you see that behavior?

Anyway, when we have hardware bugs that enabling depth also enables 
stencil we should handle that in the hardware specific drivers, not in 
general purpose code.

Cheers,
Christian.

>
> Cheers,
> Jerome
>
>> ---
>>   radeon/radeon_surface.c |   23 ---
>>   1 file changed, 8 insertions(+), 15 deletions(-)
>>
>> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
>> index 5800c33..874a092 100644
>> --- a/radeon/radeon_surface.c
>> +++ b/radeon/radeon_surface.c
>> @@ -604,7 +604,11 @@ static int eg_surface_init_1d(struct 
>> radeon_surface_manager *surf_man,
>>   }
>>   }
>>
>> -if (surf->flags & RADEON_SURF_SBUFFER) {
>> +/* The depth and stencil buffers are in separate resources on evergreen.
>> + * We allocate them in one buffer next to each other to simplify
>> + * communication between the DDX and the Mesa driver. */
>> +if ((surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) ==
>> +   (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
>>   surf->stencil_offset = ALIGN(surf->bo_size, surf->bo_alignment);
>>   surf->bo_size = surf->stencil_offset + surf->bo_size / 4;
>>   }
>> @@ -656,7 +660,8 @@ static int eg_surface_init_2d(struct 
>> radeon_surface_manager *surf_man,
>>   }
>>   }
>>
>> -if (surf->flags & RADEON_SURF_SBUFFER) {
>> +if ((surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) ==
>> +   (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
>>   surf->stencil_offset = ALIGN(surf->bo_size, surf->bo_alignment);
>>   surf->bo_size = surf->stencil_offset + surf->bo_size / 4;
>>   }
>> @@ -752,14 +757,7 @@ static int eg_surface_init(struct 
>> radeon_surface_manager *surf_man,
>>   /* tiling mode */
>>   mode = (surf->flags >> RADEON_SURF_MODE_SHIFT) & RADEON_SURF_MODE_MASK;
>>
>> -/* for some reason eg need to have room for stencil right after depth */
>> -if (surf->flags & RADEON_SURF_ZBUFFER) {
>> -surf->flags |= RADEON_SURF_SBUFFER;
>> -}
>> -if (surf->flags & RADEON_SURF_SBUFFER) {
>> -surf->flags |= RADEON_SURF_ZBUFFER;
>> -}
>> -if (surf->flags & RADEON_SURF_ZBUFFER) {
>> +if (surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
>>   /* zbuffer only support 1D or 2D tiled surface */
>>   switch (mode) {
>>   case RADEON_SURF_MODE_1D:
>> @@ -828,11 +826,6 @@ static int eg_surface_best(struct 
>> radeon_surface_manager *surf_man,
>>   /* tiling mode */
>>   mode = (surf->flags >> RADEON_SURF_MODE_SHIFT) & RADEON_SURF_MODE_MASK;
>>
>> -/* for some reason eg need to have room for stencil right after depth */
>> -if (surf->flags & RADEON_SURF_ZBUFFER) {
>> -surf->flags |= RADEON_SURF_SBUFFER;
>> -}
>> -
>>   /* set some default value to avoid sanity check choking on them */
>>   surf->tile_split = 1024;
>>   surf->bankw = 1;
>> --
>> 1.7.9.5
>>
>> ___
>> 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

[PATCH 1/3] Move FIMD register headers to include/video/

[Leela Krishna Amudala]

Hello Jingoo Han,

On Mon, Jul 30, 2012 at 2:23 PM, Jingoo Han  wrote:
> On Monday, July 30, 2012 5:45 PM, Leela Krishna Amudala wrote:
>>
>> Moved the contents of regs-fb-v4.h and regs-fb.h from arch side
>> to include/video/samsung_fimd.h
>>
>> Signed-off-by: Leela Krishna Amudala 
>> ---
>>  arch/arm/plat-samsung/include/plat/regs-fb-v4.h |  159 ---
>>  arch/arm/plat-samsung/include/plat/regs-fb.h|  403 -
>>  include/video/samsung_fimd.h|  533 
>> +++
>>  3 files changed, 533 insertions(+), 562 deletions(-)
>>  delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h
>>  delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h
>>  create mode 100644 include/video/samsung_fimd.h
>>
>> diff --git a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h 
>> b/arch/arm/plat-samsung/include/plat/regs-
>> fb-v4.h
>> deleted file mode 100644
>> index 4c3647f..000
>> --- a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h
>> +++ /dev/null
>> @@ -1,159 +0,0 @@
>> -/* arch/arm/plat-samsung/include/plat/regs-fb-v4.h
>> - *
>> - * Copyright 2008 Openmoko, Inc.
>> - * Copyright 2008 Simtec Electronics
>> - *  http://armlinux.simtec.co.uk/
>> - *  Ben Dooks 
>> - *
>> - * S3C64XX - new-style framebuffer register definitions
>> - *
>> - * This is the register set for the new style framebuffer interface
>> - * found from the S3C2443 onwards and specifically the S3C64XX series
>> - * S3C6400 and S3C6410.
>> - *
>> - * The file contains the cpu specific items which change between whichever
>> - * architecture is selected. See  for the core definitions
>> - * that are the same.
>> - *
>> - * This program is free software; you can redistribute it and/or modify
>> - * it under the terms of the GNU General Public License version 2 as
>> - * published by the Free Software Foundation.
>> -*/
>> -
>> -/* include the core definitions here, in case we really do need to
>> - * override them at a later date.
>> -*/
>> -
>> -#include 
>> -
>> -#define S3C_FB_MAX_WIN (5)  /* number of hardware windows available. */
>> -#define VIDCON1_FSTATUS_EVEN (1 << 15)
>> -
>> -/* Video timing controls */
>> -#define VIDTCON0 (0x10)
>> -#define VIDTCON1 (0x14)
>> -#define VIDTCON2 (0x18)
>> -
>> -/* Window position controls */
>> -
>> -#define WINCON(_win) (0x20 + ((_win) * 4))
>> -
>> -/* OSD1 and OSD4 do not have register D */
>> -
>> -#define VIDOSD_BASE  (0x40)
>> -
>> -#define VIDINTCON0   (0x130)
>> -
>> -/* WINCONx */
>> -
>> -#define WINCONx_CSCWIDTH_MASK(0x3 << 26)
>> -#define WINCONx_CSCWIDTH_SHIFT   (26)
>> -#define WINCONx_CSCWIDTH_WIDE(0x0 << 26)
>> -#define WINCONx_CSCWIDTH_NARROW  (0x3 << 26)
>> -
>> -#define WINCONx_ENLOCAL  (1 << 22)
>> -#define WINCONx_BUFSTATUS(1 << 21)
>> -#define WINCONx_BUFSEL   (1 << 20)
>> -#define WINCONx_BUFAUTOEN(1 << 19)
>> -#define WINCONx_YCbCr(1 << 13)
>> -
>> -#define WINCON1_LOCALSEL_CAMIF   (1 << 23)
>> -
>> -#define WINCON2_LOCALSEL_CAMIF   (1 << 23)
>> -#define WINCON2_BLD_PIX  (1 << 6)
>> -
>> -#define WINCON2_ALPHA_SEL(1 << 1)
>> -#define WINCON2_BPPMODE_MASK (0xf << 2)
>> -#define WINCON2_BPPMODE_SHIFT(2)
>> -#define WINCON2_BPPMODE_1BPP (0x0 << 2)
>> -#define WINCON2_BPPMODE_2BPP (0x1 << 2)
>> -#define WINCON2_BPPMODE_4BPP (0x2 << 2)
>> -#define WINCON2_BPPMODE_8BPP_1232(0x4 << 2)
>> -#define WINCON2_BPPMODE_16BPP_565(0x5 << 2)
>> -#define WINCON2_BPPMODE_16BPP_A1555  (0x6 << 2)
>> -#define WINCON2_BPPMODE_16BPP_I1555  (0x7 << 2)
>> -#define WINCON2_BPPMODE_18BPP_666(0x8 << 2)
>> -#define WINCON2_BPPMODE_18BPP_A1665  (0x9 << 2)
>> -#define WINCON2_BPPMODE_19BPP_A1666  (0xa << 2)
>> -#define WINCON2_BPPMODE_24BPP_888(0xb << 2)
>> -#define WINCON2_BPPMODE_24BPP_A1887  (0xc << 2)
>> -#define WINCON2_BPPMODE_25BPP_A1888  (0xd << 2)
>> -#define WINCON2_BPPMODE_28BPP_A4888  (0xd << 2)
>> -
>> -#define WINCON3_BLD_PIX  (1 << 6)
>> -
>> -#define WINCON3_ALPHA_SEL(1 << 1)
>> -#define WINCON3_BPPMODE_MASK (0xf << 2)
>> -#define WINCON3_BPPMODE_SHIFT(2)
>> -#define WINCON3_BPPMODE_1BPP (0x0 << 2)
>> -#define WINCON3_BPPMODE_2BPP (0x1 << 2)
>> -#define WINCON3_BPPMODE_4BPP (0x2 << 2)
>> -#define WINCON3_BPPMODE_16BPP_565(0x5 << 2)
>> 

[PATCH] drm/radeon: add new AMD ACPI header and update relevant code

[Alex Deucher]

On Mon, Jul 30, 2012 at 4:24 PM, Luca Tettamanti  wrote:
> On Mon, Jul 30, 2012 at 10:20:15AM -0400, Alex Deucher wrote:
>> On Sun, Jul 29, 2012 at 9:06 AM, Luca Tettamanti  
>> wrote:
>> > On Sat, Jul 28, 2012 at 05:29:25PM -0400, Alex Deucher wrote:
>> >> On Sat, Jul 28, 2012 at 10:56 AM, Luca Tettamanti > >> gmail.com> wrote:
>> >> > I just found the first problem (probably a BIOS bug):
>> >> > ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
>> >> > corresponding bit ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED is not set :(
>> >> > I intended to use the method to set up the notification handler but now
>> >> > my BIOS says that it's not there even if it is...
>> >> > Can I assume some default values (e.g. notifications are enabled and 
>> >> > will
>> >> > use 0x81 unless ATIF_FUNCTION_GET_SYSTEM_PARAMETERS says something
>> >> > different)?
>> >>
>> >> The spec says that the bits in the supported functions vector mean
>> >> that if bit n is set, function n+1 exists,
>> >
>> > Hum, I don't follow. The vector in my case is 0x2 (1 << 1), that would
>> > mean that ATIF_SELECT_ACTIVE_DISPLAYS_SUPPORTED (1 << 2) is supported?
>> >
>> > Maybe if the bit n is set then functions 0..n are available? That would
>> > (almost) match what I see...
>>
>> From the spec:
>>
>> Supported DWORD Bit vector providing supported functions
>> information. Each bit marks
>> Functions Bit  support for one specific function of the
>> ATIF method. Bit n, if set,
>> Vectorindicates that Function n+1 is supported.
>
> Sorry, I still don't understand it... what's "Function n+1" in this
> context?
> Does this mean that if bit n is set then the function defined as
> 1 << (n+1) is supported?
>
>> I don't know how wonky bioses in the wild are however.  I can see what
>> our internal teams do in these sort of cases.
>
> That would be helpful :)
> Note that on this machine (Toshiba L855-10W) brightness control under
> windows does not work with the stock catalyst driver, it works only with
> the (oldish) driver supplied by Toshiba.
>
> Anyway, I'm attaching v2 of my patches, I've incorporated the
> suggestions and some bits of code from joeyli, and now brightness
> control is actually implemented.

Regarding patches 3 and 4, it might be easier to just store a pointer
to the relevant encoder when you verify ATIF rather than walking the
encoder list every time.

Alex

>
> Still missing is the issue of event 0x81 and the conflict with video.ko;
> the handler should probably return NOTIFY_BAD to veto the keypress.
>
> Luca

[PATCH 1/3] Move FIMD register headers to include/video/

[Leela Krishna Amudala]

Hello Sylwester,

On Mon, Jul 30, 2012 at 2:19 PM, Sylwester Nawrocki
 wrote:
>
> Hi,
>
> On 07/30/2012 10:45 AM, Leela Krishna Amudala wrote:
> > Moved the contents of regs-fb-v4.h and regs-fb.h from arch side
> > to include/video/samsung_fimd.h
> >
> > Signed-off-by: Leela Krishna Amudala 
> > ---
> >  arch/arm/plat-samsung/include/plat/regs-fb-v4.h |  159 ---
> >  arch/arm/plat-samsung/include/plat/regs-fb.h|  403 -
> >  include/video/samsung_fimd.h|  533 
> > +++
> >  3 files changed, 533 insertions(+), 562 deletions(-)
> >  delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h
> >  delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h
> >  create mode 100644 include/video/samsung_fimd.h
>
> Thanks for taking care if this. However you might need to split this
> patch in two, so there is no build and git bisection breakage. In the
> first patch a new header file would be added, then the patch updating
> users of the FIMD headers would be applied, and finally the regs-fb*.h
> files would be removed.
>
> Also it helps to use -M option to git format-patch when creating patches
> that mainly move files.
>

Will do it in the suggested way,
Thanks for reviewing the patch.

> --
>
> Regards,
> Sylwester
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] Move FIMD register headers to include/video/

[Tomasz Figa]

Hi,

On Monday 30 of July 2012 at 16:46:03, Leela Krishna Amudala wrote:
> Hello Jingoo Han,
> 
> On Mon, Jul 30, 2012 at 2:23 PM, Jingoo Han  wrote:
> > On Monday, July 30, 2012 5:45 PM, Leela Krishna Amudala wrote:
> >> Moved the contents of regs-fb-v4.h and regs-fb.h from arch side
> >> to include/video/samsung_fimd.h
> >> 
> >> Signed-off-by: Leela Krishna Amudala 
> >> ---
> >> 
> >>  arch/arm/plat-samsung/include/plat/regs-fb-v4.h |  159 ---
> >>  arch/arm/plat-samsung/include/plat/regs-fb.h|  403 -
> >>  include/video/samsung_fimd.h|  533
> >>  +++ 3 files changed, 533 insertions(+), 562
> >>  deletions(-)
> >>  delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h
> >>  delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h
> >>  create mode 100644 include/video/samsung_fimd.h
> >> 
> >> diff --git a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h
> >> b/arch/arm/plat-samsung/include/plat/regs- fb-v4.h
> >> deleted file mode 100644
> >> index 4c3647f..000
> >> --- a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h
> >> +++ /dev/null
> >> @@ -1,159 +0,0 @@
> >> -/* arch/arm/plat-samsung/include/plat/regs-fb-v4.h
> >> - *
> >> - * Copyright 2008 Openmoko, Inc.
> >> - * Copyright 2008 Simtec Electronics
> >> - *  http://armlinux.simtec.co.uk/
> >> - *  Ben Dooks 
> >> - *
> >> - * S3C64XX - new-style framebuffer register definitions
> >> - *
> >> - * This is the register set for the new style framebuffer interface
> >> - * found from the S3C2443 onwards and specifically the S3C64XX series
> >> - * S3C6400 and S3C6410.
> >> - *
> >> - * The file contains the cpu specific items which change between
> >> whichever
> >> - * architecture is selected. See  for the core
> >> definitions
> >> - * that are the same.
> >> - *
> >> - * This program is free software; you can redistribute it and/or modify
> >> - * it under the terms of the GNU General Public License version 2 as
> >> - * published by the Free Software Foundation.
> >> -*/
> >> -
> >> -/* include the core definitions here, in case we really do need to
> >> - * override them at a later date.
> >> -*/
> >> -
> >> -#include 
> >> -
> >> -#define S3C_FB_MAX_WIN (5)  /* number of hardware windows available. */
> >> -#define VIDCON1_FSTATUS_EVEN (1 << 15)
> >> -
> >> -/* Video timing controls */
> >> -#define VIDTCON0 (0x10)
> >> -#define VIDTCON1 (0x14)
> >> -#define VIDTCON2 (0x18)
> >> -
> >> -/* Window position controls */
> >> -
> >> -#define WINCON(_win) (0x20 + ((_win) * 4))
> >> -
> >> -/* OSD1 and OSD4 do not have register D */
> >> -
> >> -#define VIDOSD_BASE  (0x40)
> >> -
> >> -#define VIDINTCON0   (0x130)
> >> -
> >> -/* WINCONx */
> >> -
> >> -#define WINCONx_CSCWIDTH_MASK(0x3 << 26)
> >> -#define WINCONx_CSCWIDTH_SHIFT   (26)
> >> -#define WINCONx_CSCWIDTH_WIDE(0x0 << 26)
> >> -#define WINCONx_CSCWIDTH_NARROW  (0x3 << 26)
> >> -
> >> -#define WINCONx_ENLOCAL  (1 << 22)
> >> -#define WINCONx_BUFSTATUS(1 << 21)
> >> -#define WINCONx_BUFSEL   (1 << 20)
> >> -#define WINCONx_BUFAUTOEN(1 << 19)
> >> -#define WINCONx_YCbCr(1 << 13)
> >> -
> >> -#define WINCON1_LOCALSEL_CAMIF   (1 << 23)
> >> -
> >> -#define WINCON2_LOCALSEL_CAMIF   (1 << 23)
> >> -#define WINCON2_BLD_PIX  (1 << 6)
> >> -
> >> -#define WINCON2_ALPHA_SEL(1 << 1)
> >> -#define WINCON2_BPPMODE_MASK (0xf << 2)
> >> -#define WINCON2_BPPMODE_SHIFT(2)
> >> -#define WINCON2_BPPMODE_1BPP (0x0 << 2)
> >> -#define WINCON2_BPPMODE_2BPP (0x1 << 2)
> >> -#define WINCON2_BPPMODE_4BPP (0x2 << 2)
> >> -#define WINCON2_BPPMODE_8BPP_1232(0x4 << 2)
> >> -#define WINCON2_BPPMODE_16BPP_565(0x5 << 2)
> >> -#define WINCON2_BPPMODE_16BPP_A1555  (0x6 << 2)
> >> -#define WINCON2_BPPMODE_16BPP_I1555  (0x7 << 2)
> >> -#define WINCON2_BPPMODE_18BPP_666(0x8 << 2)
> >> -#define WINCON2_BPPMODE_18BPP_A1665  (0x9 << 2)
> >> -#define WINCON2_BPPMODE_19BPP_A1666  (0xa << 2)
> >> -#define WINCON2_BPPMODE_24BPP_888(0xb << 2)
> >> -#define WINCON2_BPPMODE_24BPP_A1887  (0xc << 2)
> >> -#define WINCON2_BPPMODE_25BPP_A1888  (0xd << 2)
> >> -#define WINCON2_BPPMODE_28BPP_A4888  (0xd << 2)
> >> -
> >> -#define WINCON3_BLD_PIX  (1 << 6)
> >> -
> >> -#define WINCON3_ALPHA_SEL(1 << 1)
> >> -#define WINCON3_BPPMODE_MASK (0xf << 

[PATCH] drm/radeon: add new AMD ACPI header and update relevant code

[joeyli]

? ??2012-07-29 ? 15:10 +0200?Luca Tettamanti ???
> On Sun, Jul 29, 2012 at 11:51:48AM +0800, joeyli wrote:
> > Hi Luca, 
> > 
> > ? ??2012-07-28 ? 16:56 +0200?Luca Tettamanti ???
> > > I just found the first problem (probably a BIOS bug):
> > > ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
> > > corresponding bit ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED is not set :(
> > > I intended to use the method to set up the notification handler but now
> > > my BIOS says that it's not there even if it is...
> > > Can I assume some default values (e.g. notifications are enabled and will
> > > use 0x81 unless ATIF_FUNCTION_GET_SYSTEM_PARAMETERS says something
> > > different)?
> > > 
> > 
> > Did you check your DSDT for there have some "Notify (VGA, 0x81)"
> > statement in AFN0..AFN15?
> > If YES, I think that means your machine in case the 0x81 is for ATI used
> > by default.
> 
> Yes, my point is that the nofication is there, but since
> GET_SYSTEM_PARAMETERS is not announced I have not way to check it.
> IOW, what is implemented in the DSDT does not match what is announced by
> VERIFY_INTERFACE.
> For reference this is the DSDT: http://pastebin.com/KKS7ZsTt
> 
> Luca
> 

Yes, saw the problem in your DSDT:

Method (AF00, 0, NotSerialized)
{
CreateWordField (ATIB, Zero, SSZE)
...
Store (0x80, NMSK)
Store (0x02, SFUN)  <=== 10b, bit 0 is 0
Return (ATIB)
}

But, AF01 still supported in ATIF on this machine, maybe we should still
try GET_SYSTEM_PARAMETERS even the function vector set to 0?
No idea...


On the other hand, 
My patch to avoid 0x81 event conflict with acpi/video driver like below.
This patch woks on my notebook. Your patches do much more things then
mine, so I think my patch just for reference.  

There have a problem is:
If we want use acpi_notifier_call_chain to check does event consume by
any notifier in acpi's blocking notifier chain, then we need return
NOTIFY_BAD in radeon_acpi but not NOTIFY_OK.

So, I suggest radeon_acpi should register to acpi notifier chain by
itself but not append on radeon_acpi_event in radeon_pm. 

And,
suggest also check the device class is ACPI_VIDEO_CLASS like following:

+static int radeon_acpi_video_event(struct notifier_block *nb,
...
+   if (strcmp(event->device_class, ACPI_VIDEO_CLASS) != 0)
+   return NOTIFY_DONE;
+

Thanks a lot!
Joey Lee


>From 9c0c42ab8f37dafd3b512ca395b64bf39819d26b Mon Sep 17 00:00:00 2001
From: Lee, Chun-Yi 
Date: Mon, 30 Jul 2012 16:17:05 +0800
Subject: [PATCH] drm/radeon avoid 0x81 acpi event conflict with acpi video
 driver

drm/radeon avoid 0x81 acpi event conflict with acpi video driver

Signed-off-by: Lee, Chun-Yi 
---
 drivers/acpi/video.c |6 +-
 drivers/gpu/drm/radeon/radeon_acpi.c |  150 ++
 2 files changed, 139 insertions(+), 17 deletions(-)

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 1e0a9e1..e32492d 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1457,7 +1457,8 @@ static void acpi_video_bus_notify(struct acpi_device 
*device, u32 event)
acpi_video_device_enumerate(video);
acpi_video_device_rebind(video);
acpi_bus_generate_proc_event(device, event, 0);
-   keycode = KEY_SWITCHVIDEOMODE;
+   if (!acpi_notifier_call_chain(device, event, 0))
+   keycode = KEY_SWITCHVIDEOMODE;
break;

case ACPI_VIDEO_NOTIFY_CYCLE:   /* Cycle Display output hotkey pressed. 
*/
@@ -1479,7 +1480,8 @@ static void acpi_video_bus_notify(struct acpi_device 
*device, u32 event)
break;
}

-   if (event != ACPI_VIDEO_NOTIFY_SWITCH)
+   if (event != ACPI_VIDEO_NOTIFY_SWITCH ||
+   event != ACPI_VIDEO_NOTIFY_PROBE)
acpi_notifier_call_chain(device, event, 0);

if (keycode) {
diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c 
b/drivers/gpu/drm/radeon/radeon_acpi.c
index 5b32e49..37ed5e1 100644
--- a/drivers/gpu/drm/radeon/radeon_acpi.c
+++ b/drivers/gpu/drm/radeon/radeon_acpi.c
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "drmP.h"
 #include "drm.h"
@@ -13,36 +14,150 @@

 #include 

+struct atif_verify_output {
+   u16 size;   /* structure size in bytes (includes size 
field) */
+   u16 version;/* version */
+   u32 notif_mask; /* supported notifications mask */
+   u32 func_bits;  /* supported functions bit vector */
+} __attribute__((packed));
+
+static struct atif_verify_output *verify_output;
+
+struct atif_get_sysparams_output {
+   u16 size;   /* structure size in bytes (includes size 
field) */
+   u32 valid_flags_mask;   /* valid flags mask */
+   u32 flags;  /* flags */
+   u8  notify_code;/* notify command code */
+} 

[PATCH] drm/radeon: add new AMD ACPI header and update relevant code

[Alex Deucher]

On Mon, Jul 30, 2012 at 4:24 PM, Luca Tettamanti  wrote:
> On Mon, Jul 30, 2012 at 10:20:15AM -0400, Alex Deucher wrote:
>> On Sun, Jul 29, 2012 at 9:06 AM, Luca Tettamanti  
>> wrote:
>> > On Sat, Jul 28, 2012 at 05:29:25PM -0400, Alex Deucher wrote:
>> >> On Sat, Jul 28, 2012 at 10:56 AM, Luca Tettamanti > >> gmail.com> wrote:
>> >> > I just found the first problem (probably a BIOS bug):
>> >> > ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
>> >> > corresponding bit ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED is not set :(
>> >> > I intended to use the method to set up the notification handler but now
>> >> > my BIOS says that it's not there even if it is...
>> >> > Can I assume some default values (e.g. notifications are enabled and 
>> >> > will
>> >> > use 0x81 unless ATIF_FUNCTION_GET_SYSTEM_PARAMETERS says something
>> >> > different)?
>> >>
>> >> The spec says that the bits in the supported functions vector mean
>> >> that if bit n is set, function n+1 exists,
>> >
>> > Hum, I don't follow. The vector in my case is 0x2 (1 << 1), that would
>> > mean that ATIF_SELECT_ACTIVE_DISPLAYS_SUPPORTED (1 << 2) is supported?
>> >
>> > Maybe if the bit n is set then functions 0..n are available? That would
>> > (almost) match what I see...
>>
>> From the spec:
>>
>> Supported DWORD Bit vector providing supported functions
>> information. Each bit marks
>> Functions Bit  support for one specific function of the
>> ATIF method. Bit n, if set,
>> Vectorindicates that Function n+1 is supported.
>
> Sorry, I still don't understand it... what's "Function n+1" in this
> context?
> Does this mean that if bit n is set then the function defined as
> 1 << (n+1) is supported?

It means if bit n is set in teh supported function vector, function
n+1 is supported.  E.g., if bit 1 is set, function 2
(ATIF_FUNCTION_GET_SYSTEM_BIOS_REQUESTS) is supported.  If bit 3 is
set function 4 (ATIF_FUNCTION_GET_LID_STATE) is supported, etc.

Alex


>
>> I don't know how wonky bioses in the wild are however.  I can see what
>> our internal teams do in these sort of cases.
>
> That would be helpful :)
> Note that on this machine (Toshiba L855-10W) brightness control under
> windows does not work with the stock catalyst driver, it works only with
> the (oldish) driver supplied by Toshiba.
>
> Anyway, I'm attaching v2 of my patches, I've incorporated the
> suggestions and some bits of code from joeyli, and now brightness
> control is actually implemented.
>
> Still missing is the issue of event 0x81 and the conflict with video.ko;
> the handler should probably return NOTIFY_BAD to veto the keypress.
>
> Luca

[PATCH] drm/radeon: add new AMD ACPI header and update relevant code

[Luca Tettamanti]

On Mon, Jul 30, 2012 at 04:32:47PM +0800, joeyli wrote:
> ? ??2012-07-29 ? 15:10 +0200?Luca Tettamanti ???
> > On Sun, Jul 29, 2012 at 11:51:48AM +0800, joeyli wrote:
> > > Hi Luca, 
> > > 
> > > ? ??2012-07-28 ? 16:56 +0200?Luca Tettamanti ???
> > > > I just found the first problem (probably a BIOS bug):
> > > > ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
> > > > corresponding bit ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED is not set :(
> > > > I intended to use the method to set up the notification handler but now
> > > > my BIOS says that it's not there even if it is...
> > > > Can I assume some default values (e.g. notifications are enabled and 
> > > > will
> > > > use 0x81 unless ATIF_FUNCTION_GET_SYSTEM_PARAMETERS says something
> > > > different)?
> > > > 
> > > 
> > > Did you check your DSDT for there have some "Notify (VGA, 0x81)"
> > > statement in AFN0..AFN15?
> > > If YES, I think that means your machine in case the 0x81 is for ATI used
> > > by default.
> > 
> > Yes, my point is that the nofication is there, but since
> > GET_SYSTEM_PARAMETERS is not announced I have not way to check it.
> > IOW, what is implemented in the DSDT does not match what is announced by
> > VERIFY_INTERFACE.
> > For reference this is the DSDT: http://pastebin.com/KKS7ZsTt
> > 
> > Luca
> > 
> 
> Yes, saw the problem in your DSDT:
> 
> Method (AF00, 0, NotSerialized)
> {
> CreateWordField (ATIB, Zero, SSZE)
>   ...
> Store (0x80, NMSK)
> Store (0x02, SFUN)<=== 10b, bit 0 is 0
> Return (ATIB)
> }
> 
> But, AF01 still supported in ATIF on this machine, maybe we should still
> try GET_SYSTEM_PARAMETERS even the function vector set to 0?
> No idea...

That's what I'm doing right now... if SBIOS_REQUESTS is supported I try
and call GET_SYSTEM_PARAMETERS even if it's not announced.

> On the other hand, 
> My patch to avoid 0x81 event conflict with acpi/video driver like below.
> This patch woks on my notebook. Your patches do much more things then
> mine, so I think my patch just for reference.  

I ignored the event handling for now... I'd like to hear something back
from ACPI camp before committing to this solution.

> There have a problem is:
> If we want use acpi_notifier_call_chain to check does event consume by
> any notifier in acpi's blocking notifier chain, then we need return
> NOTIFY_BAD in radeon_acpi but not NOTIFY_OK.
> 
> So, I suggest radeon_acpi should register to acpi notifier chain by
> itself but not append on radeon_acpi_event in radeon_pm. 

It shouldn't matter, once I change radeon_atif_handler to return
NOTIFY_BAD the call chain will be stopped anyway.

> And,
> suggest also check the device class is ACPI_VIDEO_CLASS like following:
> 
> +static int radeon_acpi_video_event(struct notifier_block *nb,
> ...
> + if (strcmp(event->device_class, ACPI_VIDEO_CLASS) != 0)
> + return NOTIFY_DONE;
> +

Will do. I'll use the package structs in the next iteration.

Luca

Massive power regression going 3.4->3.5

[James Bottomley]

On Mon, 2012-07-30 at 10:46 +0100, James Bottomley wrote:
> On Sun, 2012-07-29 at 21:25 +0200, Rafael J. Wysocki wrote:
> > On Sunday, July 29, 2012, Rafael J. Wysocki wrote:
> > > On Sunday, July 29, 2012, James Bottomley wrote:
> > > > On Sat, 2012-07-28 at 22:29 +0200, Rafael J. Wysocki wrote:
> > > > > On Saturday, July 28, 2012, Rafael J. Wysocki wrote:
> > > > > > On Saturday, July 28, 2012, James Bottomley wrote:
> > > > > > > One of the great things about the 3.4 kernel was the massive 
> > > > > > > increase in
> > > > > > > power savings on my x220i laptop.  With full PCI suspend, it 
> > > > > > > could get
> > > > > > > down to 6.5W in idle with a dim screen, provided I used powertop 
> > > > > > > 2.0 to
> > > > > > > activate all the tunings).  I just upgraded to 3.5 (the openSUSE
> > > > > > > tumbleweed kernel) and all the power savings are gone.  Now it's 
> > > > > > > back to
> > > > > > > its previous behaviour of idle somewhere between 16-18W.
> > > > > > 
> > > > > > Please check dbe9a2e (ACPI / PM: Make acpi_pm_device_sleep_state() 
> > > > > > follow the
> > > > > > specification) for starters.
> > > > > > 
> > > > > > If that is not the culprit, 38c92ff (ACPI / PM: Make 
> > > > > > __acpi_bus_get_power()
> > > > > > cover D3cold correctly) is worth ckecking too.
> > > > > > 
> > > > > > If none of the above, c2fb8a3 (USB: add NO_D3_DURING_SLEEP flag and 
> > > > > > revert
> > > > > > 151b61284776be2) is one more candidate.
> > > > > > 
> > > > > > I can't recall anything else that might be related to the symptom 
> > > > > > at the moment.
> > > > > 
> > > > > Actually, dbe9a2e and c2fb8a3 only affect system suspend, so for 
> > > > > runtime PM
> > > > > 38c92ff seems to be the only relevant one from the above.
> > > > 
> > > > I verified the problem shows up on vanilla 3.5 (just in case it was an
> > > > openSUSE problem).  I also tried reverting 38c92ff with no success.  The
> > > > symptoms appear to be that something is preventing the PCI/device
> > > > subsystem from going into auto suspend.
> > > 
> > > The number of core power management commits during the 3.5 cycle was 
> > > rather
> > > limited and none of them should affect PCI runtime PM.  I have no idea 
> > > what
> > > the root cause of that may be, quite frankly.
> > 
> > I've just realized that you said "auto suspend", which makes me think that 
> > the
> > problem may be related to USB.
> > 
> > PCI doesn't really use any kind of auto suspend for what I know, but USB 
> > does
> > and it may cause PCI USB controllers to be suspended as a result.
> 
> I'm trying to bisect this, but I've got stuck around here:
> 
> git bisect bad 2f78d8e249973f1eeb88315e6444e616c60177ae
> git bisect good 28f3d717618156c0dcd2f497d791b578a7931d87
> 
> That's around the drm tree ... unfortunately that broke a lot of the
> basics of my i915 based system (compositing and resolution) as I step
> into it.

OK, I've run the bisect as far as I can.  It looks to be in the drm
tree.  Unfortunately, this tree has several merge points, some of which
go further back than v3.4.  Unfortunately, once the bisect steps back
before 3.4, we lose the changes that gave us the power savings, making
further debugging impossible

Here's the log

git bisect start
# bad: [28a33cbc24e4256c143dce96c7d93bf423229f92] Linux 3.5
git bisect bad 28a33cbc24e4256c143dce96c7d93bf423229f92
# bad: [28a33cbc24e4256c143dce96c7d93bf423229f92] Linux 3.5
git bisect bad 28a33cbc24e4256c143dce96c7d93bf423229f92
# good: [76e10d158efb6d4516018846f60c2ab5501900bc] Linux 3.4
git bisect good 76e10d158efb6d4516018846f60c2ab5501900bc
# good: [59cd358a7a5b2f6b61faa01dae6cfda3830ac62a] Merge tag 
'perf-core-for-mingo' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
git bisect good 59cd358a7a5b2f6b61faa01dae6cfda3830ac62a
# bad: [7e5b2db77b05746613516599c916a8cc2e321077] Merge branch 'upstream' of 
git://git.linux-mips.org/pub/scm/ralf/upstream-linus
git bisect bad 7e5b2db77b05746613516599c916a8cc2e321077
# good: [f9369910a6225b8d4892c3f20ae740a711cd5ace] Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal
git bisect good f9369910a6225b8d4892c3f20ae740a711cd5ace
# bad: [2f78d8e249973f1eeb88315e6444e616c60177ae] Merge tag 'firewire-updates' 
of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
git bisect bad 2f78d8e249973f1eeb88315e6444e616c60177ae
# good: [28f3d717618156c0dcd2f497d791b578a7931d87] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
git bisect good 28f3d717618156c0dcd2f497d791b578a7931d87
# bad: [b3daeaef559d87b974c13a096582c5c70dc11061] drm/i915: move rps/emon 
function declarations
git bisect bad b3daeaef559d87b974c13a096582c5c70dc11061
# bad: [246bdbeb0f0fb14c4c085b6ed7edbab11afccd33] drm/i915: share forcewaking 
code between IVB and HSW
git bisect bad 246bdbeb0f0fb14c4c085b6ed7edbab11afccd33

If you do a gitk on the last bad and good 

gitk 

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

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

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

--- Comment #16 from Alexandre Demers  
2012-07-30 15:12:24 UTC ---
(In reply to comment #15)
> If it's same as https://bugs.freedesktop.org/show_bug.cgi?id=42373 then patch
> there should fix your issue.

I'll try it as soon as I'll have time. Thank you Jerome for your follow-up.

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

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

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

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

--- Comment #15 from Jerome Glisse  2012-07-30 
14:59:56 UTC ---
If it's same as https://bugs.freedesktop.org/show_bug.cgi?id=42373 then patch
there should fix your issue.

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

Optimize i2f()

[Steven Fuerst]

Looking through the kernel radeon drm source, it looks like the i2f()
functions in r600_blit.c and r600_blit_ksm() can be optimized a bit.

The following extends the range to all unsigned 32bit integers, and avoids
the slow loop by using the bsr instruction via __fls().  It provides an
exact 1-1 correspondence up to 2^24.  Above that, there is the inevitable
rounding.  This routine rounds towards zero (truncation).

/* 23 bits of float fractional data */
#define I2F_FRAC_BITS 23
#define I2F_MASK ((1 << I2F_FRAC_BITS) - 1)

/*
 * Converts an unsigned integer into 32-bit IEEE floating point
representation.
 * Will be exact from 0 to 2^24.  Above that, we round towards zero
 * as the fractional bits will not fit in a float.  (It would be better to
 * round towards even as the fpu does, but that is slower.)
 * This routine depends on the mod(32) behaviour of the rotate instructions
 * on x86.
 */
uint32_t i2f(uint32_t x)
{
uint32_t msb, exponent, fraction;

/* Zero is special */
if (!x) return 0;

/* Get location of the most significant bit */
msb = __fls(x);

/*
 * Use a rotate instead of a shift because that works both leftwards
 * and rightwards due to the mod(32) beahviour.  This means we don't
 * need to check to see if we are above 2^24 or not.
 */
fraction = ror32(x, msb - I2F_FRAC_BITS) & I2F_MASK;
exponent = (127 + msb) << I2F_FRAC_BITS;

return fraction + exponent;
}

Steven Fuerst
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120730/f194ee6b/attachment.html>

Massive power regression going 3.4->3.5

[Adam Jackson]

On 7/30/12 1:05 PM, James Bottomley wrote:

> Lenovo X220i
>
> The display device is
>
> 00:02.0 VGA compatible controller: Intel Corporation
> 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03)
> (prog-if 00 [VGA controller])
>  Subsystem: Giga-byte Technology Device 2562
>  Flags: bus master, fast devsel, latency 0, IRQ 16
>  Memory at e000 (32-bit, prefetchable) [size=128M]
>  Memory at e820 (32-bit, non-prefetchable) [size=512K]
>  Expansion ROM at  [disabled]
>  Capabilities: 
>  Kernel driver in use: i915

What in the world?  That's an _ancient_ chip, I wouldn't expect to see 
it in a laptop that new.  I would have assumed X220i to be a Sandybridge 
like X220.

For that matter when the 845 was current Lenovo wasn't the one making 
ThinkPads.

- ajax

[Bug 52957] [r200] piglit glean/vp1-LIT test 2 (degenerate case: 0 ^ 0 -> 1) test fails

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

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

Roland Scheidegger  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Roland Scheidegger  2012-07-30 
14:19:43 UTC ---
This is due to differences in LIT opcode between DX and OGL. AFAIK the chip can
only do the DX version (there's no documentation for this part of the chip, but
r300 could only do this too). Hence to make this opcode work correctly,
complicated workarounds might be needed - given the chip limits (program length
etc.) these might do more wrong than good. So unless you find some real app
where this is a problem noone will bother - not that many programs can use
vertex programs on r200 anyway since often new render paths also would require
fragment program.

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

[PATCH 3/3] driver: Include the modified FIMD header file

[Leela Krishna Amudala]

Adding Marek

On Mon, Jul 30, 2012 at 2:15 PM, Leela Krishna Amudala <
l.krishna at samsung.com> wrote:

> The fimd register headers have been moved to include/video/
> hence, modifying the driver files accordingly.
>
> Signed-off-by: Leela Krishna Amudala 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
>  drivers/video/s3c-fb.c   |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 29fdbfe..8da90f9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -20,7 +20,7 @@
>  #include 
>
>  #include 
> -#include 
> +#include 
>
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_fbdev.h"
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 69bf9d0..1226fdd 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -26,7 +26,7 @@
>  #include 
>
>  #include 
> -#include 
> +#include 
>  #include 
>
>  /* This driver will export a number of framebuffer interfaces depending
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120730/e19f6a8b/attachment-0001.html>

[PATCH 2/3] arm: samsung: Include the modified FIMD header file

[Leela Krishna Amudala]

ch-s3c64xx/mach-hmt.c
> b/arch/arm/mach-s3c64xx/mach-hmt.c
> index 6890881..ab78c5e 100644
> --- a/arch/arm/mach-s3c64xx/mach-hmt.c
> +++ b/arch/arm/mach-s3c64xx/mach-hmt.c
> @@ -41,7 +41,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include "common.h"
>
> diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c
> b/arch/arm/mach-s3c64xx/mach-mini6410.c
> index 5539a25..4b9a9ff 100644
> --- a/arch/arm/mach-s3c64xx/mach-mini6410.c
> +++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
> @@ -41,7 +41,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include 
>
> diff --git a/arch/arm/mach-s3c64xx/mach-ncp.c
> b/arch/arm/mach-s3c64xx/mach-ncp.c
> index cad2e05..d4c8af0 100644
> --- a/arch/arm/mach-s3c64xx/mach-ncp.c
> +++ b/arch/arm/mach-s3c64xx/mach-ncp.c
> @@ -43,7 +43,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include "common.h"
>
> diff --git a/arch/arm/mach-s3c64xx/mach-real6410.c
> b/arch/arm/mach-s3c64xx/mach-real6410.c
> index 326b216..05f05d2 100644
> --- a/arch/arm/mach-s3c64xx/mach-real6410.c
> +++ b/arch/arm/mach-s3c64xx/mach-real6410.c
> @@ -42,7 +42,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include 
>
> diff --git a/arch/arm/mach-s3c64xx/mach-smartq5.c
> b/arch/arm/mach-s3c64xx/mach-smartq5.c
> index d6266d8..aa225ff 100644
> --- a/arch/arm/mach-s3c64xx/mach-smartq5.c
> +++ b/arch/arm/mach-s3c64xx/mach-smartq5.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include "common.h"
>  #include "mach-smartq.h"
> diff --git a/arch/arm/mach-s3c64xx/mach-smartq7.c
> b/arch/arm/mach-s3c64xx/mach-smartq7.c
> index 0957d2a..6e9c070 100644
> --- a/arch/arm/mach-s3c64xx/mach-smartq7.c
> +++ b/arch/arm/mach-s3c64xx/mach-smartq7.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include "common.h"
>  #include "mach-smartq.h"
> diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c
> b/arch/arm/mach-s3c64xx/mach-smdk6410.c
> index 0fe4f15..1803192 100644
> --- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
> +++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
> @@ -72,7 +72,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include "common.h"
>
> diff --git a/arch/arm/mach-s5p64x0/mach-smdk6440.c
> b/arch/arm/mach-s5p64x0/mach-smdk6440.c
> index 92fefad..0db0bdd 100644
> --- a/arch/arm/mach-s5p64x0/mach-smdk6440.c
> +++ b/arch/arm/mach-s5p64x0/mach-smdk6440.c
> @@ -52,7 +52,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>
>  #include "common.h"
> diff --git a/arch/arm/mach-s5p64x0/mach-smdk6450.c
> b/arch/arm/mach-s5p64x0/mach-smdk6450.c
> index e2335ec..c641d33 100644
> --- a/arch/arm/mach-s5p64x0/mach-smdk6450.c
> +++ b/arch/arm/mach-s5p64x0/mach-smdk6450.c
> @@ -52,7 +52,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>
>  #include "common.h"
> diff --git a/arch/arm/mach-s5pc100/mach-smdkc100.c
> b/arch/arm/mach-s5pc100/mach-smdkc100.c
> index 0c3ae38..e4df3d0 100644
> --- a/arch/arm/mach-s5pc100/mach-smdkc100.c
> +++ b/arch/arm/mach-s5pc100/mach-smdkc100.c
> @@ -51,7 +51,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include "common.h"
>
> diff --git a/arch/arm/mach-s5pv210/mach-aquila.c
> b/arch/arm/mach-s5pv210/mach-aquila.c
> index 78028df..8cbe4ac 100644
> --- a/arch/arm/mach-s5pv210/mach-aquila.c
> +++ b/arch/arm/mach-s5pv210/mach-aquila.c
> @@ -39,7 +39,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include "common.h"
>
> diff --git a/arch/arm/mach-s5pv210/mach-goni.c
> b/arch/arm/mach-s5pv210/mach-goni.c
> index 822a559..e799a02 100644
> --- a/arch/arm/mach-s5pv210/mach-goni.c
> +++ b/arch/arm/mach-s5pv210/mach-goni.c
> @@ -49,7 +49,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>
>  #include 
> diff --git a/arch/arm/mach-s5pv210/mach-smdkv210.c
> b/arch/arm/mach-s5pv210/mach-smdkv210.c
> index 918b23d..3c569e5 100644
> --- a/arch/arm/mach-s5pv210/mach-smdkv210.c
> +++ b/arch/arm/mach-s5pv210/mach-smdkv210.c
> @@ -46,7 +46,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120730/8e98d39b/attachment.html>

[PATCH 1/3] Move FIMD register headers to include/video/

[Leela Krishna Amudala]

Adding Marek.

On Mon, Jul 30, 2012 at 2:15 PM, Leela Krishna Amudala <
l.krishna at samsung.com> wrote:

> Moved the contents of regs-fb-v4.h and regs-fb.h from arch side
> to include/video/samsung_fimd.h
>
> Signed-off-by: Leela Krishna Amudala 
> ---
>  arch/arm/plat-samsung/include/plat/regs-fb-v4.h |  159 ---
>  arch/arm/plat-samsung/include/plat/regs-fb.h|  403 -
>  include/video/samsung_fimd.h|  533
> +++
>  3 files changed, 533 insertions(+), 562 deletions(-)
>  delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h
>  delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h
>  create mode 100644 include/video/samsung_fimd.h
>
> diff --git a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h
> b/arch/arm/plat-samsung/include/plat/regs-fb-v4.h
> deleted file mode 100644
> index 4c3647f..000
> --- a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h
> +++ /dev/null
> @@ -1,159 +0,0 @@
> -/* arch/arm/plat-samsung/include/plat/regs-fb-v4.h
> - *
> - * Copyright 2008 Openmoko, Inc.
> - * Copyright 2008 Simtec Electronics
> - *  http://armlinux.simtec.co.uk/
> - *  Ben Dooks 
> - *
> - * S3C64XX - new-style framebuffer register definitions
> - *
> - * This is the register set for the new style framebuffer interface
> - * found from the S3C2443 onwards and specifically the S3C64XX series
> - * S3C6400 and S3C6410.
> - *
> - * The file contains the cpu specific items which change between whichever
> - * architecture is selected. See  for the core definitions
> - * that are the same.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> -*/
> -
> -/* include the core definitions here, in case we really do need to
> - * override them at a later date.
> -*/
> -
> -#include 
> -
> -#define S3C_FB_MAX_WIN (5)  /* number of hardware windows available. */
> -#define VIDCON1_FSTATUS_EVEN   (1 << 15)
> -
> -/* Video timing controls */
> -#define VIDTCON0   (0x10)
> -#define VIDTCON1   (0x14)
> -#define VIDTCON2   (0x18)
> -
> -/* Window position controls */
> -
> -#define WINCON(_win)   (0x20 + ((_win) * 4))
> -
> -/* OSD1 and OSD4 do not have register D */
> -
> -#define VIDOSD_BASE(0x40)
> -
> -#define VIDINTCON0 (0x130)
> -
> -/* WINCONx */
> -
> -#define WINCONx_CSCWIDTH_MASK  (0x3 << 26)
> -#define WINCONx_CSCWIDTH_SHIFT (26)
> -#define WINCONx_CSCWIDTH_WIDE  (0x0 << 26)
> -#define WINCONx_CSCWIDTH_NARROW(0x3 << 26)
> -
> -#define WINCONx_ENLOCAL(1 << 22)
> -#define WINCONx_BUFSTATUS  (1 << 21)
> -#define WINCONx_BUFSEL (1 << 20)
> -#define WINCONx_BUFAUTOEN  (1 << 19)
> -#define WINCONx_YCbCr  (1 << 13)
> -
> -#define WINCON1_LOCALSEL_CAMIF (1 << 23)
> -
> -#define WINCON2_LOCALSEL_CAMIF (1 << 23)
> -#define WINCON2_BLD_PIX(1 << 6)
> -
> -#define WINCON2_ALPHA_SEL  (1 << 1)
> -#define WINCON2_BPPMODE_MASK   (0xf << 2)
> -#define WINCON2_BPPMODE_SHIFT  (2)
> -#define WINCON2_BPPMODE_1BPP   (0x0 << 2)
> -#define WINCON2_BPPMODE_2BPP   (0x1 << 2)
> -#define WINCON2_BPPMODE_4BPP   (0x2 << 2)
> -#define WINCON2_BPPMODE_8BPP_1232  (0x4 << 2)
> -#define WINCON2_BPPMODE_16BPP_565  (0x5 << 2)
> -#define WINCON2_BPPMODE_16BPP_A1555(0x6 << 2)
> -#define WINCON2_BPPMODE_16BPP_I1555(0x7 << 2)
> -#define WINCON2_BPPMODE_18BPP_666  (0x8 << 2)
> -#define WINCON2_BPPMODE_18BPP_A1665(0x9 << 2)
> -#define WINCON2_BPPMODE_19BPP_A1666(0xa << 2)
> -#define WINCON2_BPPMODE_24BPP_888  (0xb << 2)
> -#define WINCON2_BPPMODE_24BPP_A1887(0xc << 2)
> -#define WINCON2_BPPMODE_25BPP_A1888(0xd << 2)
> -#define WINCON2_BPPMODE_28BPP_A4888(0xd << 2)
> -
> -#define WINCON3_BLD_PIX(1 << 6)
> -
> -#define WINCON3_ALPHA_SEL  (1 << 1)
> -#define WINCON3_BPPMODE_MASK   (0xf << 2)
> -#define WINCON3_BPPMODE_SHIFT  (2)
> -#define WINCON3_BPPMODE_1BPP   (0x0 << 2)
> -#define WINCON3_BPPMODE_2BPP   (0x1 << 2)
> -#define WINCON3_BPPMODE_4BPP   (0x2 << 2)
> -#define WINCON3_BPPMODE_16BPP_565  (0x5 << 2)
> -#define WINCON3_BPPMODE_16BPP_A1555(0x6 << 2)
> -#define WINCON3_BPPMODE_16BPP_I1555(0x7 << 2)
> -#define 

[PATCH 0/3] ARM: SAMSUNG: Move FIMD headers to include/video/

[Leela Krishna Amudala]

Adding Marek.

This patchset based on Marek's comments.

Chages based on Marek comments
On Mon, Jul 30, 2012 at 2:15 PM, Leela Krishna Amudala <
l.krishna at samsung.com> wrote:

> This patchset moves the contents of regs-fb-v4.h and regs-fb.h from arch
> side
> to include/video/samsung_fimd.h
>
> This patchset is created and rebased against master branch of torvalds
> tree.
> Tested on smdk5250 board, build tested for other boards.
>
> Leela Krishna Amudala (3):
>   Move FIMD register headers to include/video/
>   arm: samsung: Include the modified FIMD header file
>   driver: Include the modified FIMD header file
>
>  arch/arm/mach-exynos/mach-nuri.c|2 +-
>  arch/arm/mach-exynos/mach-origen.c  |2 +-
>  arch/arm/mach-exynos/mach-smdk4x12.c|2 +-
>  arch/arm/mach-exynos/mach-smdkv310.c|2 +-
>  arch/arm/mach-exynos/mach-universal_c210.c  |2 +-
>  arch/arm/mach-exynos/setup-fimd0.c  |2 +-
>  arch/arm/mach-s3c24xx/mach-smdk2416.c   |2 +-
>  arch/arm/mach-s3c64xx/mach-anw6410.c|2 +-
>  arch/arm/mach-s3c64xx/mach-crag6410.c   |2 +-
>  arch/arm/mach-s3c64xx/mach-hmt.c|2 +-
>  arch/arm/mach-s3c64xx/mach-mini6410.c   |2 +-
>  arch/arm/mach-s3c64xx/mach-ncp.c|2 +-
>  arch/arm/mach-s3c64xx/mach-real6410.c   |2 +-
>  arch/arm/mach-s3c64xx/mach-smartq5.c|2 +-
>  arch/arm/mach-s3c64xx/mach-smartq7.c|2 +-
>  arch/arm/mach-s3c64xx/mach-smdk6410.c   |2 +-
>  arch/arm/mach-s5p64x0/mach-smdk6440.c   |2 +-
>  arch/arm/mach-s5p64x0/mach-smdk6450.c   |2 +-
>  arch/arm/mach-s5pc100/mach-smdkc100.c   |2 +-
>  arch/arm/mach-s5pv210/mach-aquila.c |2 +-
>  arch/arm/mach-s5pv210/mach-goni.c   |2 +-
>  arch/arm/mach-s5pv210/mach-smdkv210.c   |2 +-
>  arch/arm/plat-samsung/include/plat/regs-fb-v4.h |  159 ---
>  arch/arm/plat-samsung/include/plat/regs-fb.h|  403 -
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c|2 +-
>  drivers/video/s3c-fb.c  |2 +-
>  include/video/samsung_fimd.h|  533
> +++
>  27 files changed, 557 insertions(+), 586 deletions(-)
>  delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h
>  delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h
>  create mode 100644 include/video/samsung_fimd.h
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120730/9ec5923f/attachment.html>

[PATCH 3/3] driver: Include the modified FIMD header file

[Leela Krishna Amudala]

The fimd register headers have been moved to include/video/
hence, modifying the driver files accordingly.

Signed-off-by: Leela Krishna Amudala 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
 drivers/video/s3c-fb.c   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 29fdbfe..8da90f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,7 +20,7 @@
 #include 

 #include 
-#include 
+#include 

 #include "exynos_drm_drv.h"
 #include "exynos_drm_fbdev.h"
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 69bf9d0..1226fdd 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -26,7 +26,7 @@
 #include 

 #include 
-#include 
+#include 
 #include 

 /* This driver will export a number of framebuffer interfaces depending
-- 
1.7.0.4

[PATCH 2/3] arm: samsung: Include the modified FIMD header file

[Leela Krishna Amudala]

The fimd register headers have been moved to include/video/
hence, modifying the machine files accordingly.

Signed-off-by: Leela Krishna Amudala 
---
 arch/arm/mach-exynos/mach-nuri.c   |2 +-
 arch/arm/mach-exynos/mach-origen.c |2 +-
 arch/arm/mach-exynos/mach-smdk4x12.c   |2 +-
 arch/arm/mach-exynos/mach-smdkv310.c   |2 +-
 arch/arm/mach-exynos/mach-universal_c210.c |2 +-
 arch/arm/mach-exynos/setup-fimd0.c |2 +-
 arch/arm/mach-s3c24xx/mach-smdk2416.c  |2 +-
 arch/arm/mach-s3c64xx/mach-anw6410.c   |2 +-
 arch/arm/mach-s3c64xx/mach-crag6410.c  |2 +-
 arch/arm/mach-s3c64xx/mach-hmt.c   |2 +-
 arch/arm/mach-s3c64xx/mach-mini6410.c  |2 +-
 arch/arm/mach-s3c64xx/mach-ncp.c   |2 +-
 arch/arm/mach-s3c64xx/mach-real6410.c  |2 +-
 arch/arm/mach-s3c64xx/mach-smartq5.c   |2 +-
 arch/arm/mach-s3c64xx/mach-smartq7.c   |2 +-
 arch/arm/mach-s3c64xx/mach-smdk6410.c  |2 +-
 arch/arm/mach-s5p64x0/mach-smdk6440.c  |2 +-
 arch/arm/mach-s5p64x0/mach-smdk6450.c  |2 +-
 arch/arm/mach-s5pc100/mach-smdkc100.c  |2 +-
 arch/arm/mach-s5pv210/mach-aquila.c|2 +-
 arch/arm/mach-s5pv210/mach-goni.c  |2 +-
 arch/arm/mach-s5pv210/mach-smdkv210.c  |2 +-
 22 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
index f98a83a..573a0c4 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -39,7 +39,7 @@
 #include 

 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-exynos/mach-origen.c 
b/arch/arm/mach-exynos/mach-origen.c
index 5a12dc2..c69707e 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -31,7 +31,7 @@
 #include 

 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-exynos/mach-smdk4x12.c 
b/arch/arm/mach-exynos/mach-smdk4x12.c
index b26beb1..8a8acff 100644
--- a/arch/arm/mach-exynos/mach-smdk4x12.c
+++ b/arch/arm/mach-exynos/mach-smdk4x12.c
@@ -35,7 +35,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 

diff --git a/arch/arm/mach-exynos/mach-smdkv310.c 
b/arch/arm/mach-exynos/mach-smdkv310.c
index 3cfa688..c2df6e8 100644
--- a/arch/arm/mach-exynos/mach-smdkv310.c
+++ b/arch/arm/mach-exynos/mach-smdkv310.c
@@ -28,7 +28,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c 
b/arch/arm/mach-exynos/mach-universal_c210.c
index 4d1f40d..e6fb471 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -39,7 +39,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-exynos/setup-fimd0.c 
b/arch/arm/mach-exynos/setup-fimd0.c
index 07a6dbe..53c4c51 100644
--- a/arch/arm/mach-exynos/setup-fimd0.c
+++ b/arch/arm/mach-exynos/setup-fimd0.c
@@ -14,7 +14,7 @@
 #include 

 #include 
-#include 
+#include 

 #include 

diff --git a/arch/arm/mach-s3c24xx/mach-smdk2416.c 
b/arch/arm/mach-s3c24xx/mach-smdk2416.c
index c3100a0..c8d5f51 100644
--- a/arch/arm/mach-s3c24xx/mach-smdk2416.c
+++ b/arch/arm/mach-s3c24xx/mach-smdk2416.c
@@ -52,7 +52,7 @@
 #include 
 #include 

-#include 
+#include 
 #include 

 #include 
diff --git a/arch/arm/mach-s3c64xx/mach-anw6410.c 
b/arch/arm/mach-s3c64xx/mach-anw6410.c
index ffa29dd..27e3087 100644
--- a/arch/arm/mach-s3c64xx/mach-anw6410.c
+++ b/arch/arm/mach-s3c64xx/mach-anw6410.c
@@ -44,7 +44,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 

 #include 
 #include 
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c 
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 09cd812..66e8c69 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -57,7 +57,7 @@
 #include 

 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-s3c64xx/mach-hmt.c b/arch/arm/mach-s3c64xx/mach-hmt.c
index 6890881..ab78c5e 100644
--- a/arch/arm/mach-s3c64xx/mach-hmt.c
+++ b/arch/arm/mach-s3c64xx/mach-hmt.c
@@ -41,7 +41,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 

 #include "common.h"

diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c 
b/arch/arm/mach-s3c64xx/mach-mini6410.c
index 5539a25..4b9a9ff 100644
--- a/arch/arm/mach-s3c64xx/mach-mini6410.c
+++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
@@ -41,7 +41,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 

 #include 

diff --git a/arch/arm/mach-s3c64xx/mach-ncp.c b/arch/arm/mach-s3c64xx/mach-ncp.c
index cad2e05..d4c8af0 100644
--- a/arch/arm/mach-s3c64xx/mach-ncp.c
+++ b/arch/arm/mach-s3c64xx/mach-ncp.c
@@ -43,7 +43,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 

 #include "common.h"

diff --git 

[PATCH 1/3] Move FIMD register headers to include/video/

[Leela Krishna Amudala]

Moved the contents of regs-fb-v4.h and regs-fb.h from arch side
to include/video/samsung_fimd.h

Signed-off-by: Leela Krishna Amudala 
---
 arch/arm/plat-samsung/include/plat/regs-fb-v4.h |  159 ---
 arch/arm/plat-samsung/include/plat/regs-fb.h|  403 -
 include/video/samsung_fimd.h|  533 +++
 3 files changed, 533 insertions(+), 562 deletions(-)
 delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h
 delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h
 create mode 100644 include/video/samsung_fimd.h

diff --git a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h 
b/arch/arm/plat-samsung/include/plat/regs-fb-v4.h
deleted file mode 100644
index 4c3647f..000
--- a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h
+++ /dev/null
@@ -1,159 +0,0 @@
-/* arch/arm/plat-samsung/include/plat/regs-fb-v4.h
- *
- * Copyright 2008 Openmoko, Inc.
- * Copyright 2008 Simtec Electronics
- *  http://armlinux.simtec.co.uk/
- *  Ben Dooks 
- *
- * S3C64XX - new-style framebuffer register definitions
- *
- * This is the register set for the new style framebuffer interface
- * found from the S3C2443 onwards and specifically the S3C64XX series
- * S3C6400 and S3C6410.
- *
- * The file contains the cpu specific items which change between whichever
- * architecture is selected. See  for the core definitions
- * that are the same.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-/* include the core definitions here, in case we really do need to
- * override them at a later date.
-*/
-
-#include 
-
-#define S3C_FB_MAX_WIN (5)  /* number of hardware windows available. */
-#define VIDCON1_FSTATUS_EVEN   (1 << 15)
-
-/* Video timing controls */
-#define VIDTCON0   (0x10)
-#define VIDTCON1   (0x14)
-#define VIDTCON2   (0x18)
-
-/* Window position controls */
-
-#define WINCON(_win)   (0x20 + ((_win) * 4))
-
-/* OSD1 and OSD4 do not have register D */
-
-#define VIDOSD_BASE(0x40)
-
-#define VIDINTCON0 (0x130)
-
-/* WINCONx */
-
-#define WINCONx_CSCWIDTH_MASK  (0x3 << 26)
-#define WINCONx_CSCWIDTH_SHIFT (26)
-#define WINCONx_CSCWIDTH_WIDE  (0x0 << 26)
-#define WINCONx_CSCWIDTH_NARROW(0x3 << 26)
-
-#define WINCONx_ENLOCAL(1 << 22)
-#define WINCONx_BUFSTATUS  (1 << 21)
-#define WINCONx_BUFSEL (1 << 20)
-#define WINCONx_BUFAUTOEN  (1 << 19)
-#define WINCONx_YCbCr  (1 << 13)
-
-#define WINCON1_LOCALSEL_CAMIF (1 << 23)
-
-#define WINCON2_LOCALSEL_CAMIF (1 << 23)
-#define WINCON2_BLD_PIX(1 << 6)
-
-#define WINCON2_ALPHA_SEL  (1 << 1)
-#define WINCON2_BPPMODE_MASK   (0xf << 2)
-#define WINCON2_BPPMODE_SHIFT  (2)
-#define WINCON2_BPPMODE_1BPP   (0x0 << 2)
-#define WINCON2_BPPMODE_2BPP   (0x1 << 2)
-#define WINCON2_BPPMODE_4BPP   (0x2 << 2)
-#define WINCON2_BPPMODE_8BPP_1232  (0x4 << 2)
-#define WINCON2_BPPMODE_16BPP_565  (0x5 << 2)
-#define WINCON2_BPPMODE_16BPP_A1555(0x6 << 2)
-#define WINCON2_BPPMODE_16BPP_I1555(0x7 << 2)
-#define WINCON2_BPPMODE_18BPP_666  (0x8 << 2)
-#define WINCON2_BPPMODE_18BPP_A1665(0x9 << 2)
-#define WINCON2_BPPMODE_19BPP_A1666(0xa << 2)
-#define WINCON2_BPPMODE_24BPP_888  (0xb << 2)
-#define WINCON2_BPPMODE_24BPP_A1887(0xc << 2)
-#define WINCON2_BPPMODE_25BPP_A1888(0xd << 2)
-#define WINCON2_BPPMODE_28BPP_A4888(0xd << 2)
-
-#define WINCON3_BLD_PIX(1 << 6)
-
-#define WINCON3_ALPHA_SEL  (1 << 1)
-#define WINCON3_BPPMODE_MASK   (0xf << 2)
-#define WINCON3_BPPMODE_SHIFT  (2)
-#define WINCON3_BPPMODE_1BPP   (0x0 << 2)
-#define WINCON3_BPPMODE_2BPP   (0x1 << 2)
-#define WINCON3_BPPMODE_4BPP   (0x2 << 2)
-#define WINCON3_BPPMODE_16BPP_565  (0x5 << 2)
-#define WINCON3_BPPMODE_16BPP_A1555(0x6 << 2)
-#define WINCON3_BPPMODE_16BPP_I1555(0x7 << 2)
-#define WINCON3_BPPMODE_18BPP_666  (0x8 << 2)
-#define WINCON3_BPPMODE_18BPP_A1665(0x9 << 2)
-#define WINCON3_BPPMODE_19BPP_A1666(0xa << 2)
-#define WINCON3_BPPMODE_24BPP_888  (0xb << 2)
-#define WINCON3_BPPMODE_24BPP_A1887(0xc << 2)
-#define WINCON3_BPPMODE_25BPP_A1888

[PATCH 0/3] ARM: SAMSUNG: Move FIMD headers to include/video/

[Leela Krishna Amudala]

This patchset moves the contents of regs-fb-v4.h and regs-fb.h from arch side
to include/video/samsung_fimd.h

This patchset is created and rebased against master branch of torvalds tree.
Tested on smdk5250 board, build tested for other boards.

Leela Krishna Amudala (3):
  Move FIMD register headers to include/video/
  arm: samsung: Include the modified FIMD header file
  driver: Include the modified FIMD header file

 arch/arm/mach-exynos/mach-nuri.c|2 +-
 arch/arm/mach-exynos/mach-origen.c  |2 +-
 arch/arm/mach-exynos/mach-smdk4x12.c|2 +-
 arch/arm/mach-exynos/mach-smdkv310.c|2 +-
 arch/arm/mach-exynos/mach-universal_c210.c  |2 +-
 arch/arm/mach-exynos/setup-fimd0.c  |2 +-
 arch/arm/mach-s3c24xx/mach-smdk2416.c   |2 +-
 arch/arm/mach-s3c64xx/mach-anw6410.c|2 +-
 arch/arm/mach-s3c64xx/mach-crag6410.c   |2 +-
 arch/arm/mach-s3c64xx/mach-hmt.c|2 +-
 arch/arm/mach-s3c64xx/mach-mini6410.c   |2 +-
 arch/arm/mach-s3c64xx/mach-ncp.c|2 +-
 arch/arm/mach-s3c64xx/mach-real6410.c   |2 +-
 arch/arm/mach-s3c64xx/mach-smartq5.c|2 +-
 arch/arm/mach-s3c64xx/mach-smartq7.c|2 +-
 arch/arm/mach-s3c64xx/mach-smdk6410.c   |2 +-
 arch/arm/mach-s5p64x0/mach-smdk6440.c   |2 +-
 arch/arm/mach-s5p64x0/mach-smdk6450.c   |2 +-
 arch/arm/mach-s5pc100/mach-smdkc100.c   |2 +-
 arch/arm/mach-s5pv210/mach-aquila.c |2 +-
 arch/arm/mach-s5pv210/mach-goni.c   |2 +-
 arch/arm/mach-s5pv210/mach-smdkv210.c   |2 +-
 arch/arm/plat-samsung/include/plat/regs-fb-v4.h |  159 ---
 arch/arm/plat-samsung/include/plat/regs-fb.h|  403 -
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|2 +-
 drivers/video/s3c-fb.c  |2 +-
 include/video/samsung_fimd.h|  533 +++
 27 files changed, 557 insertions(+), 586 deletions(-)
 delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h
 delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h
 create mode 100644 include/video/samsung_fimd.h

[PATCH 3/3] drm/udl: fix error handling in damage handler

[Dave Airlie]

From: Dave Airlie 

This checks the return from the hline renderer, and flags EAGAIN
if we jump out here.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/udl/udl_fb.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index b8c00ed..dfd27e9 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -145,7 +145,7 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
int y,
 {
struct drm_device *dev = fb->base.dev;
struct udl_device *udl = dev->dev_private;
-   int i, ret;
+   int i, ret = 0;
char *cmd;
cycles_t start_cycles, end_cycles;
int bytes_sent = 0;
@@ -189,11 +189,14 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
int y,
const int line_offset = fb->base.pitches[0] * i;
const int byte_offset = line_offset + (x * bpp);

-   if (udl_render_hline(dev, bpp, ,
+   ret = udl_render_hline(dev, bpp, ,
 (char *) fb->obj->vmapping,
 , byte_offset, width * bpp,
-_identical, _sent))
+_identical, _sent);
+   if (ret == 1) {
+   ret = -EAGAIN;
goto error;
+   }
}

if (cmd > (char *) urb->transfer_buffer) {
@@ -213,7 +216,7 @@ error:
>> 10)), /* Kcycles */
   >cpu_kcycles_used);

-   return 0;
+   return ret;
 }

 static int udl_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
-- 
1.7.10.2

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

[Dave Airlie]

From: Dave Airlie 

We need to call these before we transfer the damaged areas to the device
not before/after we setup the long lived vmaps.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/udl/udl_fb.c  |   22 --
 drivers/gpu/drm/udl/udl_gem.c |7 ---
 2 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index ce9a611..b8c00ed 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "drmP.h"
 #include "drm.h"
@@ -377,16 +378,33 @@ static int udl_user_framebuffer_dirty(struct 
drm_framebuffer *fb,
 {
struct udl_framebuffer *ufb = to_udl_fb(fb);
int i;
+   int ret = 0;

if (!ufb->active_16)
return 0;

+   if (ufb->obj->base.import_attach) {
+   ret = 
dma_buf_begin_cpu_access(ufb->obj->base.import_attach->dmabuf,
+  0, ufb->obj->base.size,
+  DMA_FROM_DEVICE);
+   if (ret)
+   return ret;
+   }
+
for (i = 0; i < num_clips; i++) {
-   udl_handle_damage(ufb, clips[i].x1, clips[i].y1,
+   ret = udl_handle_damage(ufb, clips[i].x1, clips[i].y1,
  clips[i].x2 - clips[i].x1,
  clips[i].y2 - clips[i].y1);
+   if (ret)
+   break;
}
-   return 0;
+
+   if (ufb->obj->base.import_attach) {
+   dma_buf_end_cpu_access(ufb->obj->base.import_attach->dmabuf,
+  0, ufb->obj->base.size,
+  DMA_FROM_DEVICE);
+   }
+   return ret;
 }

 static void udl_user_framebuffer_destroy(struct drm_framebuffer *fb)
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index 7bd65bd..2a49678 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -181,11 +181,6 @@ int udl_gem_vmap(struct udl_gem_object *obj)
int ret;

if (obj->base.import_attach) {
-   ret = dma_buf_begin_cpu_access(obj->base.import_attach->dmabuf,
-  0, obj->base.size, 
DMA_BIDIRECTIONAL);
-   if (ret)
-   return -EINVAL;
-
obj->vmapping = dma_buf_vmap(obj->base.import_attach->dmabuf);
if (!obj->vmapping)
return -ENOMEM;
@@ -206,8 +201,6 @@ void udl_gem_vunmap(struct udl_gem_object *obj)
 {
if (obj->base.import_attach) {
dma_buf_vunmap(obj->base.import_attach->dmabuf, obj->vmapping);
-   dma_buf_end_cpu_access(obj->base.import_attach->dmabuf, 0,
-  obj->base.size, DMA_BIDIRECTIONAL);
return;
}

-- 
1.7.10.2

[PATCH 1/3] drm/i915: implement dma buf begin_cpu_access

[Dave Airlie]

From: Dave Airlie 

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

question: what is direction here in terms of read/write to the device.

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

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |   17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index cf6bdec..ee51c63 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -147,6 +147,22 @@ static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, 
struct vm_area_struct *
return -EINVAL;
 }

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

 struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
-- 
1.7.10.2

[Bug 52950] [r200] piglit glean/blendFunc test fails

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

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

Roland Scheidegger  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Roland Scheidegger  2012-07-30 
13:56:04 UTC ---
IIRC radeon alpha blend units before r300 (maybe even later) had some precision
issues, they just don't quite fulfill the requirements. So getting these errors
is expected (it is just one bit of error after all), and it is unfixable.

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

[Bug 41265] KMS does not work on Radeon HD6700M

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

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

--- Comment #19 from Alex Deucher  2012-07-30 13:37:42 UTC 
---
Where the vbios (video bios) for the discrete card is stored (on a rom on the
board, in the sbios (system bios), etc.).  If it's part of the sbios, there's
probably an ACPI method (ROM or ATRM) to access it.

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

drm/nouveau: crash regression in 3.5

[Ortwin Glück]

On 29.07.2012 22:15, Marcin Slusarz wrote:
> No, the real problem is: with "noaccel" we don't register "software engine",
> but vblank ISR relies on its existance and happily derefences NULL pointer.
>
> Now, this patch should fix it for real...

Unfortunately I am still seeing the crash. Without "noaccel" it works though 
(until X crashes the machine, but that is a different thing).

Thanks,

Ortwin
-- next part --
Initializing cgroup subsys cpu
Linux version 3.5.0 (root at ortwin-hp) (gcc version 4.5.3 (Gentoo 4.5.3-r2 
p1.1, pie-0.4.7) ) #3 SMP PREEMPT Thu Jul 26 14:42:43 CEST 2012
Command line: root=/dev/sda5 rootfstype=ext4 pciehp_force=1 nouveau.modeset=1 
nouveau.noaccel=1 netconsole= at 10.11.1.234/eth0, at 
10.11.1.19/00:17:f2:c7:5f:06 drm.debug=15
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009fbff] usable
BIOS-e820: [mem 0x0009fc00-0x0009] reserved
BIOS-e820: [mem 0x000e-0x000f] reserved
BIOS-e820: [mem 0x0010-0xbefc1fff] usable
BIOS-e820: [mem 0xbefc2000-0xbf6c1fff] reserved
BIOS-e820: [mem 0xbf6c2000-0xbf7c1fff] ACPI NVS
BIOS-e820: [mem 0xbf7c2000-0xbf7fefff] ACPI data
BIOS-e820: [mem 0xbf7ff000-0xbf7f] usable
BIOS-e820: [mem 0xbf80-0xbfff] reserved
BIOS-e820: [mem 0xe000-0xefff] reserved
BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
BIOS-e820: [mem 0xfed1-0xfed13fff] reserved
BIOS-e820: [mem 0xfed19000-0xfed19fff] reserved
BIOS-e820: [mem 0xfed1b000-0xfed1] reserved
BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
BIOS-e820: [mem 0xffd0-0x] reserved
BIOS-e820: [mem 0x0001-0x0001fbff] usable
BIOS-e820: [mem 0x0001fc00-0x0001] reserved
BIOS-e820: [mem 0x0002-0x00023bff] usable
NX (Execute Disable) protection: active
DMI 2.6 present.
No AGP bridge found
e820: last_pfn = 0x23c000 max_arch_pfn = 0x4
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
e820: last_pfn = 0xbf800 max_arch_pfn = 0x4
init_memory_mapping: [mem 0x-0xbf7f]
init_memory_mapping: [mem 0x1-0x23bff]
ACPI: RSDP 000fddc0 00024 (v02 HPQOEM)
ACPI: XSDT bf7fe120 00094 (v01 HPQOEM SLIC-MPC 000F  0113)
ACPI: FACP bf7fc000 000F4 (v03 HPQOEM 1521 000F HP   0001)
ACPI: DSDT bf7da000 1C77F (v02 HPQOEM 1521 0001 INTL 20060912)
ACPI: FACS bf76 00040
ACPI: HPET bf7fb000 00038 (v01 HPQOEM 1521 0001 HP   0001)
ACPI: APIC bf7fa000 000BC (v01 HPQOEM 1521 0001 HP   0001)
ACPI: MCFG bf7f9000 0003C (v01 HPQOEM 1521 0001 HP   0001)
ACPI: TCPA bf7f7000 00032 (v02 HPQOEM 1521  HP   0001)
ACPI: SSDT bf7d7000 00135 (v01 HPQOEM SataAhci 1000 INTL 20060912)
ACPI: SSDT bf7d6000 00314 (v01 HPQOEM PtidDevc 1000 INTL 20060912)
ACPI: SLIC bf7d5000 00176 (v01 HPQOEM SLIC-MPC 0001 HP   0001)
ACPI: SSDT bf7d1000 02576 (v01 HPQOEM NVIDIAGF 0001 INTL 20060912)
ACPI: DMAR bf7d 00080 (v01 INTEL  CP_DALE  0001 INTL 0001)
ACPI: SSDT bf7cf000 00A10 (v01  PmRefCpuPm 3000 INTL 20060912)
ACPI: SSDT bf7ce000 00288 (v01  PmRef  Cpu0Tst 3000 INTL 20060912)
ACPI: SSDT bf7cd000 00225 (v01  PmRefApTst 3000 INTL 20060912)
ACPI: ASF! bf7f8000 000A0 (v32 HPQOEM 1521 0001 HP   0001)
Zone ranges:
  DMA  [mem 0x0001-0x00ff]
  DMA32[mem 0x0100-0x]
  Normal   [mem 0x1-0x23bff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x0001-0x0009efff]
  node   0: [mem 0x0010-0xbefc1fff]
  node   0: [mem 0xbf7ff000-0xbf7f]
  node   0: [mem 0x1-0x1fbff]
  node   0: [mem 0x2-0x23bff]
ACPI: PM-Timer IO Port: 0x408
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x05] enabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x00] disabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x00] disabled)
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x00] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
ACPI: 

[PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Jerome Glisse]

On Mon, Jul 30, 2012 at 1:03 PM, Alex Deucher  wrote:
> On Mon, Jul 30, 2012 at 12:52 PM, Jerome Glisse  wrote:
>> On Mon, Jul 30, 2012 at 12:16 PM, Alex Deucher  
>> wrote:
>>> On Mon, Jul 30, 2012 at 12:03 PM, Alex Deucher  
>>> wrote:
 On Mon, Jul 30, 2012 at 11:48 AM, Marek Ol??k  wrote:
> On Mon, Jul 30, 2012 at 4:56 PM, Jerome Glisse  
> wrote:
>> On Sun, Jul 29, 2012 at 1:04 PM, Marek Ol??k  wrote:
>>> If we don't need stencil, don't allocate it.
>>> If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate 
>>> depth.
>>>
>>> v2: actually do it correctly
>>
>> Big NAK
>>
>> We need to allocate stencil and depth no matter what. Otherwise it
>> will lockup. You can take a look by poisonning the surface and see
>> that when stencil is disabled or depth is disabled the hw still write
>> to it.
>
> :)
>
> If what you say is true, then we're in a big trouble. Regardless of
> this patch, we're in it right now, because we cannot fully disable
> depth or stencil if the user binds a NULL zbuffer. That's clearly the
> kind of issue that cannot be fixed in the allocator code and should be
> fixed in r600g where the hardware is programmed.
>
> I *think* that the correct way to disable Z or stencil is to set the
> Z_INVALID or STENCIL_INVALID format, respectively, and not by
> disabling reads and writes. (cc'ing Alex to confirm that if he can). I
> don't think the hardware designers have added those "invalid" formats
> just for the lulz. Please see my latest kernel patch "drm/radeon/kms:
> allow "invalid" DB formats as a means to disable DB" that tries to
> address this issue.

 That is correct.  I just verified with the hw team.  If you allocate
 both buffers there are some restrictions in that they share tiling
 parameters, but you can set either buffer to _INVALID and allocate one
 or the other independently.
>>>
>>> Some further clarifications from the hw team.  If you want to have
>>> truly independent z and stencil buffers that allows for mixing and
>>> matching, you need to make sure that any z and stencil buffer that can
>>> be bound together must share the same addressing parameters (except
>>> tile split), and you must disable the htile buffer on evergreen and
>>> before (DB_Z_INFO.TILE_SURFACE_ENABLE=0) or disable the htile buffer
>>> for stencil on cayman and newer
>>> (DB_STENCIL_INFO.TILE_STENCIL_DISABLE=1).  If you are only interested
>>> in unbinding z or stencil independently (but not mixing and matching)
>>> then you don't need to the above restrictions on the htile buffer.
>>> You can do so by setting the format to INVALID.
>>>
>>> Alex
>>
>> Well somehow i can't reproduce might have been fixed by something like
>> render backend fix. I should have write down how i saw this back in
>> the day.
>
> I think it was related to tiling.  I remember you mentioning something
> about that at the time.
>
> Alex

Yeah might be tiling related, surface allocator probably got the bo size right.

Cheers,
Jerime

[PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Alex Deucher]

On Mon, Jul 30, 2012 at 12:52 PM, Jerome Glisse  wrote:
> On Mon, Jul 30, 2012 at 12:16 PM, Alex Deucher  
> wrote:
>> On Mon, Jul 30, 2012 at 12:03 PM, Alex Deucher  
>> wrote:
>>> On Mon, Jul 30, 2012 at 11:48 AM, Marek Ol??k  wrote:
 On Mon, Jul 30, 2012 at 4:56 PM, Jerome Glisse  
 wrote:
> On Sun, Jul 29, 2012 at 1:04 PM, Marek Ol??k  wrote:
>> If we don't need stencil, don't allocate it.
>> If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.
>>
>> v2: actually do it correctly
>
> Big NAK
>
> We need to allocate stencil and depth no matter what. Otherwise it
> will lockup. You can take a look by poisonning the surface and see
> that when stencil is disabled or depth is disabled the hw still write
> to it.

 :)

 If what you say is true, then we're in a big trouble. Regardless of
 this patch, we're in it right now, because we cannot fully disable
 depth or stencil if the user binds a NULL zbuffer. That's clearly the
 kind of issue that cannot be fixed in the allocator code and should be
 fixed in r600g where the hardware is programmed.

 I *think* that the correct way to disable Z or stencil is to set the
 Z_INVALID or STENCIL_INVALID format, respectively, and not by
 disabling reads and writes. (cc'ing Alex to confirm that if he can). I
 don't think the hardware designers have added those "invalid" formats
 just for the lulz. Please see my latest kernel patch "drm/radeon/kms:
 allow "invalid" DB formats as a means to disable DB" that tries to
 address this issue.
>>>
>>> That is correct.  I just verified with the hw team.  If you allocate
>>> both buffers there are some restrictions in that they share tiling
>>> parameters, but you can set either buffer to _INVALID and allocate one
>>> or the other independently.
>>
>> Some further clarifications from the hw team.  If you want to have
>> truly independent z and stencil buffers that allows for mixing and
>> matching, you need to make sure that any z and stencil buffer that can
>> be bound together must share the same addressing parameters (except
>> tile split), and you must disable the htile buffer on evergreen and
>> before (DB_Z_INFO.TILE_SURFACE_ENABLE=0) or disable the htile buffer
>> for stencil on cayman and newer
>> (DB_STENCIL_INFO.TILE_STENCIL_DISABLE=1).  If you are only interested
>> in unbinding z or stencil independently (but not mixing and matching)
>> then you don't need to the above restrictions on the htile buffer.
>> You can do so by setting the format to INVALID.
>>
>> Alex
>
> Well somehow i can't reproduce might have been fixed by something like
> render backend fix. I should have write down how i saw this back in
> the day.

I think it was related to tiling.  I remember you mentioning something
about that at the time.

Alex

[PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Jerome Glisse]

On Mon, Jul 30, 2012 at 12:16 PM, Alex Deucher  wrote:
> On Mon, Jul 30, 2012 at 12:03 PM, Alex Deucher  
> wrote:
>> On Mon, Jul 30, 2012 at 11:48 AM, Marek Ol??k  wrote:
>>> On Mon, Jul 30, 2012 at 4:56 PM, Jerome Glisse  
>>> wrote:
 On Sun, Jul 29, 2012 at 1:04 PM, Marek Ol??k  wrote:
> If we don't need stencil, don't allocate it.
> If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.
>
> v2: actually do it correctly

 Big NAK

 We need to allocate stencil and depth no matter what. Otherwise it
 will lockup. You can take a look by poisonning the surface and see
 that when stencil is disabled or depth is disabled the hw still write
 to it.
>>>
>>> :)
>>>
>>> If what you say is true, then we're in a big trouble. Regardless of
>>> this patch, we're in it right now, because we cannot fully disable
>>> depth or stencil if the user binds a NULL zbuffer. That's clearly the
>>> kind of issue that cannot be fixed in the allocator code and should be
>>> fixed in r600g where the hardware is programmed.
>>>
>>> I *think* that the correct way to disable Z or stencil is to set the
>>> Z_INVALID or STENCIL_INVALID format, respectively, and not by
>>> disabling reads and writes. (cc'ing Alex to confirm that if he can). I
>>> don't think the hardware designers have added those "invalid" formats
>>> just for the lulz. Please see my latest kernel patch "drm/radeon/kms:
>>> allow "invalid" DB formats as a means to disable DB" that tries to
>>> address this issue.
>>
>> That is correct.  I just verified with the hw team.  If you allocate
>> both buffers there are some restrictions in that they share tiling
>> parameters, but you can set either buffer to _INVALID and allocate one
>> or the other independently.
>
> Some further clarifications from the hw team.  If you want to have
> truly independent z and stencil buffers that allows for mixing and
> matching, you need to make sure that any z and stencil buffer that can
> be bound together must share the same addressing parameters (except
> tile split), and you must disable the htile buffer on evergreen and
> before (DB_Z_INFO.TILE_SURFACE_ENABLE=0) or disable the htile buffer
> for stencil on cayman and newer
> (DB_STENCIL_INFO.TILE_STENCIL_DISABLE=1).  If you are only interested
> in unbinding z or stencil independently (but not mixing and matching)
> then you don't need to the above restrictions on the htile buffer.
> You can do so by setting the format to INVALID.
>
> Alex

Well somehow i can't reproduce might have been fixed by something like
render backend fix. I should have write down how i saw this back in
the day.

Cheers,
Jerome

[PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Alex Deucher]

On Mon, Jul 30, 2012 at 12:03 PM, Alex Deucher  wrote:
> On Mon, Jul 30, 2012 at 11:48 AM, Marek Ol??k  wrote:
>> On Mon, Jul 30, 2012 at 4:56 PM, Jerome Glisse  wrote:
>>> On Sun, Jul 29, 2012 at 1:04 PM, Marek Ol??k  wrote:
 If we don't need stencil, don't allocate it.
 If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.

 v2: actually do it correctly
>>>
>>> Big NAK
>>>
>>> We need to allocate stencil and depth no matter what. Otherwise it
>>> will lockup. You can take a look by poisonning the surface and see
>>> that when stencil is disabled or depth is disabled the hw still write
>>> to it.
>>
>> :)
>>
>> If what you say is true, then we're in a big trouble. Regardless of
>> this patch, we're in it right now, because we cannot fully disable
>> depth or stencil if the user binds a NULL zbuffer. That's clearly the
>> kind of issue that cannot be fixed in the allocator code and should be
>> fixed in r600g where the hardware is programmed.
>>
>> I *think* that the correct way to disable Z or stencil is to set the
>> Z_INVALID or STENCIL_INVALID format, respectively, and not by
>> disabling reads and writes. (cc'ing Alex to confirm that if he can). I
>> don't think the hardware designers have added those "invalid" formats
>> just for the lulz. Please see my latest kernel patch "drm/radeon/kms:
>> allow "invalid" DB formats as a means to disable DB" that tries to
>> address this issue.
>
> That is correct.  I just verified with the hw team.  If you allocate
> both buffers there are some restrictions in that they share tiling
> parameters, but you can set either buffer to _INVALID and allocate one
> or the other independently.

Some further clarifications from the hw team.  If you want to have
truly independent z and stencil buffers that allows for mixing and
matching, you need to make sure that any z and stencil buffer that can
be bound together must share the same addressing parameters (except
tile split), and you must disable the htile buffer on evergreen and
before (DB_Z_INFO.TILE_SURFACE_ENABLE=0) or disable the htile buffer
for stencil on cayman and newer
(DB_STENCIL_INFO.TILE_STENCIL_DISABLE=1).  If you are only interested
in unbinding z or stencil independently (but not mixing and matching)
then you don't need to the above restrictions on the htile buffer.
You can do so by setting the format to INVALID.

Alex

[PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Alex Deucher]

On Mon, Jul 30, 2012 at 11:48 AM, Marek Ol??k  wrote:
> On Mon, Jul 30, 2012 at 4:56 PM, Jerome Glisse  wrote:
>> On Sun, Jul 29, 2012 at 1:04 PM, Marek Ol??k  wrote:
>>> If we don't need stencil, don't allocate it.
>>> If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.
>>>
>>> v2: actually do it correctly
>>
>> Big NAK
>>
>> We need to allocate stencil and depth no matter what. Otherwise it
>> will lockup. You can take a look by poisonning the surface and see
>> that when stencil is disabled or depth is disabled the hw still write
>> to it.
>
> :)
>
> If what you say is true, then we're in a big trouble. Regardless of
> this patch, we're in it right now, because we cannot fully disable
> depth or stencil if the user binds a NULL zbuffer. That's clearly the
> kind of issue that cannot be fixed in the allocator code and should be
> fixed in r600g where the hardware is programmed.
>
> I *think* that the correct way to disable Z or stencil is to set the
> Z_INVALID or STENCIL_INVALID format, respectively, and not by
> disabling reads and writes. (cc'ing Alex to confirm that if he can). I
> don't think the hardware designers have added those "invalid" formats
> just for the lulz. Please see my latest kernel patch "drm/radeon/kms:
> allow "invalid" DB formats as a means to disable DB" that tries to
> address this issue.

That is correct.  I just verified with the hw team.  If you allocate
both buffers there are some restrictions in that they share tiling
parameters, but you can set either buffer to _INVALID and allocate one
or the other independently.

Alex

>
> For r600g, I was thinking of allocating a dummy buffer that will be
> always bound in case the depth or stencil buffer or both are missing.
> Either way, we should find how to get around this issue without
> wasting memory, especially when there are other options to try.
>
> BTW, before we used this allocator, we allocated the depth and stencil
> buffers in separate resources. We might need to get back to it in the
> future if Gallium grows separate depth and stencil buffer bindings.
>
> Marek
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Massive power regression going 3.4->3.5

[Keith Packard]

James Bottomley  writes:

> On Mon, 2012-07-30 at 09:33 -0700, Keith Packard wrote:
>> James Bottomley  writes:
>> 
>> > OK, I've run the bisect as far as I can.  It looks to be in the drm
>> > tree.  Unfortunately, this tree has several merge points, some of which
>> > go further back than v3.4.  Unfortunately, once the bisect steps back
>> > before 3.4, we lose the changes that gave us the power savings, making
>> > further debugging impossible
>> 
>> What machine is this on? There are a few 'disable some power savings'
>> patches in that list to work around issues on various machines; knowing
>> what machine you're using can isolate which ones might have had some
>> effect on power usage...
>
> Lenovo X220i

I don't see a whole lot of context from the elided email bits you'd sent
previously; can you summarize the issue in terms of how much power
savings you're losing, how you're measuring it and what's going on in
the system when the power savings is different?

Have you tried measuring power with X not running? How about with
compositing and other desktop effects disabled? 

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120730/9e73aa9c/attachment.pgp>

[PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Jerome Glisse]

On Mon, Jul 30, 2012 at 11:17 AM, Christian K?nig
 wrote:
> On 30.07.2012 16:56, Jerome Glisse wrote:
>>
>> On Sun, Jul 29, 2012 at 1:04 PM, Marek Ol??k  wrote:
>>>
>>> If we don't need stencil, don't allocate it.
>>> If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.
>>>
>>> v2: actually do it correctly
>>
>> Big NAK
>>
>> We need to allocate stencil and depth no matter what. Otherwise it
>> will lockup. You can take a look by poisonning the surface and see
>> that when stencil is disabled or depth is disabled the hw still write
>> to it.
>
>
> Really? That bug is new to me, at least on SI that works perfectly
> (currently working on it), so on which hardware do you see that behavior?

I must have put which GPU are affected in one commit either ddx, mesa
or libdrm. From memory all evergreen but not in all case and cayman in
all case.

Cheers,
Jerome

>
> Anyway, when we have hardware bugs that enabling depth also enables stencil
> we should handle that in the hardware specific drivers, not in general
> purpose code.
>
> Cheers,
> Christian.

At time it was the easiest solution to put it there.

Cheers,
Jerome

[PATCH 1/3] Move FIMD register headers to include/video/

[Sylwester Nawrocki]

Hi,

On 07/30/2012 10:53 AM, Jingoo Han wrote:
>> +/*FIMD V8 REG OFFSET */
>> +#define FIMD_V8_VIDTCON0(0x20010)
>> +#define FIMD_V8_VIDTCON1(0x20014)
>> +#define FIMD_V8_VIDTCON2(0x20018)
>> +#define FIMD_V8_VIDTCON3(0x2001C)
>> +#define FIMD_V8_VIDCON1 (0x20004)
> 
> 
> CC'ed Marek.
> 
> To Leela Krishna Amudala,
> 
> Don't add these definitions for FIMD_V8_xxx registers, which are 
> not related to current "regs-fb-v4.h and regs-fb.h".
> Just "move" and "merge" regs-fb-v4.h and regs-fb.h to one header 
> file, not "add" new definitions.
> If you want to add these definitions, please make new patch for this.

Good point.

> Also, "#define FIMD_V8_xxx" is ugly.
> I think that there is better way.
> Please, find other way.

Instead of just telling that something is wrong and you don't like it, 
perhaps it would be kind to give at least a slight suggestion of what 
would have been good enough to your taste...respecting someone else's
time and effort.

So what would you like to see there instead, EXYNOS5_FIMD_* ?

BTW, your e-mails are badly word wrapped, I had to manually correct it.

-- 

Regards,
Sylwester

[PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Jerome Glisse]

On Sun, Jul 29, 2012 at 1:04 PM, Marek Ol??k  wrote:
> If we don't need stencil, don't allocate it.
> If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.
>
> v2: actually do it correctly

Big NAK

We need to allocate stencil and depth no matter what. Otherwise it
will lockup. You can take a look by poisonning the surface and see
that when stencil is disabled or depth is disabled the hw still write
to it.

Cheers,
Jerome

> ---
>  radeon/radeon_surface.c |   23 ---
>  1 file changed, 8 insertions(+), 15 deletions(-)
>
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 5800c33..874a092 100644
> --- a/radeon/radeon_surface.c
> +++ b/radeon/radeon_surface.c
> @@ -604,7 +604,11 @@ static int eg_surface_init_1d(struct 
> radeon_surface_manager *surf_man,
>  }
>  }
>
> -if (surf->flags & RADEON_SURF_SBUFFER) {
> +/* The depth and stencil buffers are in separate resources on evergreen.
> + * We allocate them in one buffer next to each other to simplify
> + * communication between the DDX and the Mesa driver. */
> +if ((surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) ==
> +   (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
>  surf->stencil_offset = ALIGN(surf->bo_size, surf->bo_alignment);
>  surf->bo_size = surf->stencil_offset + surf->bo_size / 4;
>  }
> @@ -656,7 +660,8 @@ static int eg_surface_init_2d(struct 
> radeon_surface_manager *surf_man,
>  }
>  }
>
> -if (surf->flags & RADEON_SURF_SBUFFER) {
> +if ((surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) ==
> +   (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
>  surf->stencil_offset = ALIGN(surf->bo_size, surf->bo_alignment);
>  surf->bo_size = surf->stencil_offset + surf->bo_size / 4;
>  }
> @@ -752,14 +757,7 @@ static int eg_surface_init(struct radeon_surface_manager 
> *surf_man,
>  /* tiling mode */
>  mode = (surf->flags >> RADEON_SURF_MODE_SHIFT) & RADEON_SURF_MODE_MASK;
>
> -/* for some reason eg need to have room for stencil right after depth */
> -if (surf->flags & RADEON_SURF_ZBUFFER) {
> -surf->flags |= RADEON_SURF_SBUFFER;
> -}
> -if (surf->flags & RADEON_SURF_SBUFFER) {
> -surf->flags |= RADEON_SURF_ZBUFFER;
> -}
> -if (surf->flags & RADEON_SURF_ZBUFFER) {
> +if (surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
>  /* zbuffer only support 1D or 2D tiled surface */
>  switch (mode) {
>  case RADEON_SURF_MODE_1D:
> @@ -828,11 +826,6 @@ static int eg_surface_best(struct radeon_surface_manager 
> *surf_man,
>  /* tiling mode */
>  mode = (surf->flags >> RADEON_SURF_MODE_SHIFT) & RADEON_SURF_MODE_MASK;
>
> -/* for some reason eg need to have room for stencil right after depth */
> -if (surf->flags & RADEON_SURF_ZBUFFER) {
> -surf->flags |= RADEON_SURF_SBUFFER;
> -}
> -
>  /* set some default value to avoid sanity check choking on them */
>  surf->tile_split = 1024;
>  surf->bankw = 1;
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] Move FIMD register headers to include/video/

[Sylwester Nawrocki]

Hi,

On 07/30/2012 10:45 AM, Leela Krishna Amudala wrote:
> Moved the contents of regs-fb-v4.h and regs-fb.h from arch side
> to include/video/samsung_fimd.h
> 
> Signed-off-by: Leela Krishna Amudala 
> ---
>  arch/arm/plat-samsung/include/plat/regs-fb-v4.h |  159 ---
>  arch/arm/plat-samsung/include/plat/regs-fb.h|  403 -
>  include/video/samsung_fimd.h|  533 
> +++
>  3 files changed, 533 insertions(+), 562 deletions(-)
>  delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h
>  delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h
>  create mode 100644 include/video/samsung_fimd.h

Thanks for taking care if this. However you might need to split this 
patch in two, so there is no build and git bisection breakage. In the
first patch a new header file would be added, then the patch updating
users of the FIMD headers would be applied, and finally the regs-fb*.h 
files would be removed.

Also it helps to use -M option to git format-patch when creating patches
that mainly move files.

--

Regards,
Sylwester

drm/nouveau: crash regression in 3.5

[Maarten Lankhorst]

Hey,

Op 29-07-12 22:15, Marcin Slusarz schreef:
> On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Gl?ck wrote:
>> On 25.07.2012 20:42, Marcin Slusarz wrote:
>>> Good, below patch should fix this panic.
>>>
>>> Note that you can hit an oops in drm_handle_vblank because patch from
>>> http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html
>>> has not been applied (yet?).
>> After applying your patch, it still crashes, although with a slightly 
>> different stack trace. I then also applied the second patch, but that 
>> doesn't make any difference. New log attached.
>>
>> Looks like interrupt occurs before nouveau_software_context_new() is 
>> called? Shouldn't the initialization be done from 
>> nouveau_irq_preinstall() so it is available when the irq occurs? Again, 
>> I am not an expert here. Just guessing...
> No, the real problem is: with "noaccel" we don't register "software engine",
> but vblank ISR relies on its existance and happily derefences NULL pointer.
>
> Now, this patch should fix it for real...
>
> ---
> From: Marcin Slusarz 
> Subject: [PATCH] drm/nouveau: disable vblank interrupts before registering 
> PDISPLAY ISR
>
> Currently, we register vblank IRQ handler and later we disable vblank
> interrupts. So, for the short amount of time, we rely on vblank ISR
> to operate correctly, even if vblank interrupts are never going to be
> used later.
>
> In "noaccel" case, software engine - which is used by vblank ISR - is not
> registered, so if vblank interrupt triggers in a wrong moment, we can hit
> NULL pointer dereference in nouveau_software_vblank.
>
> To fix it, disable vblank interrupts before registering PDISPLAY ISR.
>
> Reported-by: Ortwin Gl?ck 
> Signed-off-by: Marcin Slusarz 
> Cc: stable at vger.kernel.org [3.5]
>
I can confirm this bug when I was working on adding d0 vblank, but it seems
to me like nv*_display_create would be a more logical place to put the disable
call. This will make it more clear that vblank is disabled before the irq is 
registered.

Also maybe add a WARN_ON(!nv_engine(dev, NVOBJ_ENGINE_SW)); in
nouveau_vblank_enable and/or return -EINVAL in that case?

If you add the modification to nouveau_vblank_enable:
Reviewed-by: Maarten Lankhorst 

~Maarten

[PATCH] drm/radeon: Mark all possible functions / structs as static

[Alex Deucher]

On Fri, Jul 27, 2012 at 5:34 PM, Lauri Kasanen  wrote:
> Let's allow GCC to optimize better.
>
> This exposed some five unused functions, but this patch doesn't remove them.
>
> Signed-off-by: Lauri Kasanen 

Reviewed-by: Alex Deucher 

3.4.0+ - Linus GIT -- drivers/built-in.o: In function `nouveau_acpi_edid': (.text+0x112337): undefined reference to `acpi_video_get_edid'

[Randy Dunlap]

On 05/31/2012 12:10 AM, Miles Lane wrote:

> I suspect this is due to a dependency not enforced in the Kconfig logic?
> 
>   LD  init/built-in.o
> drivers/built-in.o: In function `nouveau_acpi_edid':
> (.text+0x112337): undefined reference to `acpi_video_get_edid'




This build error still happens in Linux 3.5.
It is attempting to call a symbol in a loadable module from
a builtin driver.


CONFIG_ACPI_VIDEO=m
CONFIG_VIDEO_OUTPUT_CONTROL=m

If I use change CONFIG_VIDEO_OUTPUT_CONTROL to y,
CONFIG_ACPI_VIDEO also changes to y, so the relevant
functions are all builtin, and there is no build problem.


I guess that this line in drivers/gpu/drm/nouveau/Kconfig:

select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE && 
VIDEO_OUTPUT_CONTROL && INPUT

sets ACPI_VIDEO=m since VIDEO_OUTPUT_CONTROL=m, even though all of the
other symbols are =y.

xconfig tells me:

Selects: FW_LOADER [=y] && DRM_KMS_HELPER [=y] && DRM_TTM [=y] && 
FB_CFB_FILLRECT [=y] && FB_CFB_COPYAREA [=y] && FB_CFB_IMAGEBLIT [=y] && FB 
[=y] && FRAMEBUFFER_CONSOLE [=y] && FB_BACKLIGHT [=y] && ACPI_VIDEO [=m] && 
ACPI_WMI [=y] && MXM_WMI [=y] && POWER_SUPPLY [=y]




-- 
~Randy

[PATCH] drm/radeon: add new AMD ACPI header and update relevant code

[Alex Deucher]

On Sun, Jul 29, 2012 at 3:33 PM, Luca Tettamanti  wrote:
> Hi,
> I'm attaching a first draft of my work. The first 3 patches are
> infrastructure work, the fourth wires the notification handler and
> retrieves the requests from the system BIOS, but it does not actually
> change brightness yet.
>
> The problem here is how to get the correct encoder: should I just scan
> encoder_list checking for ATOM_DEVICE_LCD_SUPPORT and see if it has a
> backlight device attached?

Yeah, that should work.

> Hopefully there is only one encoder with it, right?

There's only one backlight controller and there should only be one
encoder with it enabled on it.

>
> I'm also toying with the idea of creating structures matching the output
> of the various ACPI methods, this would remove some ugly pointer
> arithmetics, but it _might_ make it easier to read past the buffer if
> one does not check the size before using the struct. What do you think?

That's fine with me.  We do something similar with atombios structs.
Also, feel free to add stuff to radeon_acpi.h if you think it's
useful.

Alex

[PATCH 1/2] radeon: simplify ZS buffer checking on r600

[Christian König]

I wanted to work on something similar this week, cause we need some 
updates for SI on this.

So thx, you saved me some work here. And both patches are:

Reviewed-by: Christian K?nig 

On 29.07.2012 16:02, Marek Ol??k wrote:
> Setting those flags has no effect anywhere else.
> ---
>   radeon/radeon_surface.c |9 +
>   1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index c80f7f4..5800c33 100644
> --- a/radeon/radeon_surface.c
> +++ b/radeon/radeon_surface.c
> @@ -385,14 +385,7 @@ static int r6_surface_init(struct radeon_surface_manager 
> *surf_man,
>   /* tiling mode */
>   mode = (surf->flags >> RADEON_SURF_MODE_SHIFT) & RADEON_SURF_MODE_MASK;
>   
> -/* always enable z & stencil together */
> -if (surf->flags & RADEON_SURF_ZBUFFER) {
> -surf->flags |= RADEON_SURF_SBUFFER;
> -}
> -if (surf->flags & RADEON_SURF_SBUFFER) {
> -surf->flags |= RADEON_SURF_ZBUFFER;
> -}
> -if (surf->flags & RADEON_SURF_ZBUFFER) {
> +if (surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
>   /* zbuffer only support 1D or 2D tiled surface */
>   switch (mode) {
>   case RADEON_SURF_MODE_1D:

[PATCH] drm/radeon: add new AMD ACPI header and update relevant code

[Alex Deucher]

On Sun, Jul 29, 2012 at 9:06 AM, Luca Tettamanti  wrote:
> On Sat, Jul 28, 2012 at 05:29:25PM -0400, Alex Deucher wrote:
>> On Sat, Jul 28, 2012 at 10:56 AM, Luca Tettamanti  
>> wrote:
>> > I just found the first problem (probably a BIOS bug):
>> > ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
>> > corresponding bit ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED is not set :(
>> > I intended to use the method to set up the notification handler but now
>> > my BIOS says that it's not there even if it is...
>> > Can I assume some default values (e.g. notifications are enabled and will
>> > use 0x81 unless ATIF_FUNCTION_GET_SYSTEM_PARAMETERS says something
>> > different)?
>>
>> The spec says that the bits in the supported functions vector mean
>> that if bit n is set, function n+1 exists,
>
> Hum, I don't follow. The vector in my case is 0x2 (1 << 1), that would
> mean that ATIF_SELECT_ACTIVE_DISPLAYS_SUPPORTED (1 << 2) is supported?
>
> Maybe if the bit n is set then functions 0..n are available? That would
> (almost) match what I see...

>From the spec:

Supported DWORD Bit vector providing supported functions
information. Each bit marks
Functions Bit  support for one specific function of the
ATIF method. Bit n, if set,
Vectorindicates that Function n+1 is supported.

I don't know how wonky bioses in the wild are however.  I can see what
our internal teams do in these sort of cases.

>
>> but it's possible that the
>> spec is wrong and it's actually a 1 to 1 mapping; if bit n is set,
>> function n is supported.  In which case the the supported functions
>> vector bits should be:
>> +/* supported functions vector */
>> +#   define ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED   (1 << 1)
>> +#   define ATIF_GET_SYSTEM_BIOS_REQUESTS_SUPPORTED(1 << 2)
>> +#   define ATIF_SELECT_ACTIVE_DISPLAYS_SUPPORTED  (1 << 3)
>> +#   define ATIF_GET_LID_STATE_SUPPORTED   (1 << 4)
>> +#   define ATIF_GET_TV_STANDARD_FROM_CMOS_SUPPORTED   (1 << 5)
>> +#   define ATIF_SET_TV_STANDARD_IN_CMOS_SUPPORTED (1 << 6)
>> +#   define ATIF_GET_PANEL_EXPANSION_MODE_FROM_CMOS_SUPPORTED  (1 << 7)
>> +#   define ATIF_SET_PANEL_EXPANSION_MODE_IN_CMOS_SUPPORTED(1 << 8)
>> +#   define ATIF_TEMPERATURE_CHANGE_NOTIFICATION_SUPPORTED (1 << 13)
>> +#   define ATIF_GET_GRAPHICS_DEVICE_TYPES_SUPPORTED   (1 << 15)
>>
>> See if that lines up better.
>
> Not really... the value returned by VERIFY_INTERFACE is 0x2, but in the
> DSDT I see:
>
> ATIF_FUNCTION_GET_SYSTEM_PARAMETERS
> ATIF_FUNCTION_GET_SYSTEM_BIOS_REQUESTS
> ATIF_FUNCTION_GET_TV_STANDARD_FROM_CMOS
> ATIF_FUNCTION_SET_TV_STANDARD_IN_CMOS
>
> The implementation of the first one makes sense, the second is used for
> brightness control. The other two _might_ be a leftover (the machine
> does not have an analog TV out).

Yeah, probably unless there is a TV-out on a docking station or
something like that.  The TV-out port should show up in the connector
table in the vbios even if it has a port on the docking station
however.

Alex

Fwd: Brightness on HP EliteBook 8460p

[Artur Flinta]

On Sat, Jul 28, 2012 at 4:47 PM, Pali Roh?r  wrote:
> Hello, I have some good news. Radeon patches from this post
> http://lists.freedesktop.org/archives/dri-devel/2012-July/025535.html
> export brightness file /sys/class/backlight/radeon_bl/brightness
> And finally with these patches I'm able to change brightness on my EliteBook.

Wow, it's great news :) I was reading yesterday info about ACPI
patches from AMD on Phronix and thinking will it help or no, and now I
have an answer :)

Regards
Artur



-- 
Ka?dy problem ma swoje rozwi?zanie, zatem
je?eli nie ma rozwi?zania to nie ma problemu.

[Bug 52956] New: [r200] piglit glean/pointAtten test fails

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

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

 Bug #: 52956
   Summary: [r200] piglit glean/pointAtten test fails
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r200
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: mister.freeman at laposte.net


System configuration :

- radeon 9000 AGP ( M9, rv250 )
- laptop pentium 4 2.4 Ghz 1.25 Gb ram
- archlinux 32 bits

Step to reproduce the bug

- mesa 8.0.4 release ( but the bug occurs also with the git version )
- a graphic card who uses the r200 driver 
- install piglit ( git version )
- run the glean test "pointAtten" in piglit :

./piglit-run.py  -t "glean/pointAtten" tests/quick.tests results/quick

the glean/pointAtten will fail with these error messages :

Test point size attenuation with the GL_ARB_point_parameters extension.

FAILURE:
Expected size: 3.53553  Actual size: 2
Size: 5
Min: 1  Max: 6
Attenuation: 1 0 1
Eye Z: -1
Aliased

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

[Bug 52954] New: [r200] piglit glean/exactRGBA test fails

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

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

 Bug #: 52954
   Summary: [r200] piglit glean/exactRGBA test fails
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r200
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: mister.freeman at laposte.net


System configuration :

- radeon 9000 AGP ( M9, rv250 )
- laptop pentium 4 2.4 Ghz 1.25 Gb ram
- archlinux 32 bits

Step to reproduce the bug

- mesa 8.0.4 release ( but the bug occurs also with the git version )
- a graphic card who uses the r200 driver 
- install piglit ( git version )
- run the glean test "exactRGBA" in piglit :

./piglit-run.py  -t "glean/exactRGBA" tests/quick.tests results/quick

the glean/exactRGBA will fail with these error messages :

Output:
--
This test performs a sanity check of glReadPixels, using as
few other portions of the GL as possible.  If this test fails,
it may be pointless to run other tests, since so many of them
depend on reading the contents of the framebuffer to determine
if they pass.

The test works by using glClear to fill the framebuffer with a
randomly-chosen value, reading the contents of the
framebuffer, and comparing the actual contents with the
expected contents.  RGB, RGBA, color index, stencil, and depth
buffers (whichever are applicable to the current rendering
context) are checked.  The test passes if the actual contents
are within 1 LSB of the expected contents.

readPixSanity:  PASS rgba8, db, z24, s8, win+pmap, id 33
RGBA largest readback error was 0 bits
Depth largest readback error was 0.33985 bits

--
The OpenGL specification requires that under certain conditions
(e.g. lighting disabled, no clipping, no dithering, etc.) colors
specified as unsigned integers are represented *exactly* in the
framebuffer (up to the number of bits common to both the
original color and the framebuffer color channel).  Several glean
tests depend on this behavior, so this test is a prerequisite for
them.

This test works by drawing many small quadrilaterals whose
colors are specified by glColorub, glColorus, and glColorui;
reading back the resulting image; and comparing the colors read
back to the colors written.  The high-order bits shared by the
source representation of the colors and the framebuffer
representation of the colors must agree exactly for the test to
pass.

exactRGBA:  FAIL rgba8, db, z24, s8, win+pmap, id 33
Unsigned short worst-case error was 0x100 at (0, 0)
expected (0xeb00, 0x5ea3, 0xb3a6, 0x36cd)
got (0xea00, 0x5e5e, 0xb3b3, 0x3737)
Unsigned int   worst-case error was 0x100 at (1, 0)
expected (0xff00, 0xf4c10287, 0xd06cde3a, 0xe62b5851)
got (0xfe00, 0xf4f4f4ff, 0xd0d0d0ff, 0xe5e5e5ff)

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

[Bug 52951] New: [r200] piglit glean/clipFlat test fails

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

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

 Bug #: 52951
   Summary: [r200] piglit glean/clipFlat test fails
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r200
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: mister.freeman at laposte.net


System configuration :

- radeon 9000 AGP ( M9, rv250 )
- laptop pentium 4 2.4 Ghz 1.25 Gb ram
- archlinux 32 bits

Step to reproduce the bug

- mesa 8.0.4 release ( but the bug occurs also with the git version )
- a graphic card who uses the r200 driver 
- install piglit ( git version )
- run the glean test "clipFlat" in piglit :

./piglit-run.py  -t "glean/clipFlat" tests/quick.tests results/quick

the glean/clipFlat will fail with this error message :

Test clipping with flat shading (provoking vertex).

clipFlat: Failure for glDrawElements(GL_QUAD_STRIP), glFrontFace(GL_CCW),
glPolygonMode(GL_FILL)
Translation: -1, -1
Expected color (0, 1, 0) but found (1, 1, 0)
clipFlat:  FAIL rgba8, db, z24, s8, win+pmap, id 33

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

[PATCH] drm/radeon/kms: allow "invalid" DB formats as a means to disable DB

[Alex Deucher]

On Sun, Jul 29, 2012 at 10:24 AM, Marek Ol??k  wrote:
> Signed-off-by: Marek Ol??k 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/evergreen_cs.c |6 --
>  drivers/gpu/drm/radeon/evergreend.h   |2 ++
>  drivers/gpu/drm/radeon/r600_cs.c  |6 --
>  drivers/gpu/drm/radeon/radeon_drv.c   |3 ++-
>  4 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index c1655412..f2e5c54 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -961,13 +961,15 @@ static int evergreen_cs_track_check(struct 
> radeon_cs_parser *p)
>
> if (track->db_dirty) {
> /* Check stencil buffer */
> -   if (G_028800_STENCIL_ENABLE(track->db_depth_control)) {
> +   if (G_028044_FORMAT(track->db_s_info) != 
> V_028044_STENCIL_INVALID &&
> +   G_028800_STENCIL_ENABLE(track->db_depth_control)) {
> r = evergreen_cs_track_validate_stencil(p);
> if (r)
> return r;
> }
> /* Check depth buffer */
> -   if (G_028800_Z_ENABLE(track->db_depth_control)) {
> +   if (G_028040_FORMAT(track->db_z_info) != V_028040_Z_INVALID &&
> +   G_028800_Z_ENABLE(track->db_depth_control)) {
> r = evergreen_cs_track_validate_depth(p);
> if (r)
> return r;
> diff --git a/drivers/gpu/drm/radeon/evergreend.h 
> b/drivers/gpu/drm/radeon/evergreend.h
> index b50b15c..4a43b46 100644
> --- a/drivers/gpu/drm/radeon/evergreend.h
> +++ b/drivers/gpu/drm/radeon/evergreend.h
> @@ -1273,6 +1273,8 @@
>  #define   S_028044_FORMAT(x)   (((x) & 0x1) << 0)
>  #define   G_028044_FORMAT(x)   (((x) >> 0) & 0x1)
>  #define   C_028044_FORMAT  0xFFFE
> +#defineV_028044_STENCIL_INVALID0
> +#defineV_028044_STENCIL_8  1
>  #define   G_028044_TILE_SPLIT(x)   (((x) >> 8) & 0x7)
>  #define DB_Z_READ_BASE 0x28048
>  #define DB_STENCIL_READ_BASE   0x2804c
> diff --git a/drivers/gpu/drm/radeon/r600_cs.c 
> b/drivers/gpu/drm/radeon/r600_cs.c
> index ca87f7a..1119e31 100644
> --- a/drivers/gpu/drm/radeon/r600_cs.c
> +++ b/drivers/gpu/drm/radeon/r600_cs.c
> @@ -764,8 +764,10 @@ static int r600_cs_track_check(struct radeon_cs_parser 
> *p)
> }
>
> /* Check depth buffer */
> -   if (track->db_dirty && 
> (G_028800_STENCIL_ENABLE(track->db_depth_control) ||
> -   G_028800_Z_ENABLE(track->db_depth_control))) {
> +   if (track->db_dirty &&
> +   G_028010_FORMAT(track->db_depth_info) != V_028010_DEPTH_INVALID &&
> +   (G_028800_STENCIL_ENABLE(track->db_depth_control) ||
> +G_028800_Z_ENABLE(track->db_depth_control))) {
> r = r600_cs_track_validate_db(p);
> if (r)
> return r;
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 2c4d53f..ed13538 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -59,9 +59,10 @@
>   *   2.15.0 - add max_pipes query
>   *   2.16.0 - fix evergreen 2D tiled surface calculation
>   *   2.17.0 - add STRMOUT_BASE_UPDATE for r7xx
> + *   2.18.0 - r600-eg: allow "invalid" DB formats
>   */
>  #define KMS_DRIVER_MAJOR   2
> -#define KMS_DRIVER_MINOR   17
> +#define KMS_DRIVER_MINOR   18
>  #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);
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 52950] New: [r200] piglit glean/blendFunc test fails

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

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

 Bug #: 52950
   Summary: [r200] piglit glean/blendFunc test fails
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r200
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: mister.freeman at laposte.net


System configuration :

- radeon 9000 AGP ( M9, rv250 )
- laptop pentium 4 2.4 Ghz 1.25 Gb ram
- archlinux 32 bits

Step to reproduce the bug

- mesa 8.0.4 release ( but the bug occurs also with the git version )
- a graphic card who uses the r200 driver 
- install piglit ( git version )
- run the glean test "blendFunc" in piglit :

./piglit-run.py  -t "glean/blendFunc" tests/quick.tests results/quick

the glean/blendFunc will fail with these error messages :

First failing pixel is at row 11 column 24
Actual values are (0, 0, 0, 0.54902)
Expected values are (0, 0, 0, 0.557007)
Errors are (0, 0, 0, 0.00798696)
Source values are (0.462745, 0.756863, 0.662745, 0.546639)
Destination values are (0.819608, 0.0980392, 0.615686, 0.0509804)
blendFunc:  FAIL rgba8, db, z24, s8, win+pmap, id 33
source factor RGB = GL_ZERO, source factor A = GL_ONE_MINUS_DST_COLOR
dest factor RGB = GL_ZERO, dest factor A = GL_CONSTANT_COLOR
equation RGB = GL_FUNC_ADD, equation A = GL_FUNC_ADD
const color = { 0.25, 0, 1, 0.75 }
Readback had 0 bits in error; blending had 1.03186 bits in error.

First failing pixel is at row 7 column 27
Actual values are (0.682353, 0.682353, 0.92549, 0.756863)
Expected values are (0.682353, 0.682353, 0.92549, 0.765417)
Errors are (0, 0, 0, 0.0085544)
Source values are (0.682353, 0.968627, 0.243137, 0.761929)
Destination values are (0.682353, 0.682353, 0.92549, 0.0156863)
blendFunc:  FAIL rgba8, db, z24, s8, win+pmap, id 33
source factor RGB = GL_ZERO, source factor A = GL_ONE_MINUS_DST_COLOR
dest factor RGB = GL_ONE, dest factor A = GL_ONE_MINUS_DST_ALPHA
equation RGB = GL_FUNC_ADD, equation A = GL_FUNC_ADD
const color = { 0.25, 0, 1, 0.75 }
Readback had 0 bits in error; blending had 1.13088 bits in error.

First failing pixel is at row 1 column 16
Actual values are (0.0705882, 0.298039, 0.243137, 0.74902)
Expected values are (0.0693272, 0.296286, 0.245752, 0.756865)
Errors are (0.00126106, 0.00175321, 0.00261439, 0.00784552)
Source values are (0.909804, 0.694118, 0.0784314, 0.804654)
Destination values are (0.768627, 0.968627, 0.27, 0.0784314)
blendFunc:  FAIL rgba8, db, z24, s8, win+pmap, id 33
source factor RGB = GL_ZERO, source factor A = GL_ONE_MINUS_DST_COLOR
dest factor RGB = GL_ONE_MINUS_SRC_COLOR, dest factor A =
GL_ONE_MINUS_SRC_ALPHA
equation RGB = GL_FUNC_ADD, equation A = GL_FUNC_ADD
const color = { 0.25, 0, 1, 0.75 }
Readback had 0 bits in error; blending had 1.00608 bits in error.

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

Massive power regression going 3.4->3.5

[Keith Packard]

James Bottomley  writes:

> OK, I've run the bisect as far as I can.  It looks to be in the drm
> tree.  Unfortunately, this tree has several merge points, some of which
> go further back than v3.4.  Unfortunately, once the bisect steps back
> before 3.4, we lose the changes that gave us the power savings, making
> further debugging impossible

What machine is this on? There are a few 'disable some power savings'
patches in that list to work around issues on various machines; knowing
what machine you're using can isolate which ones might have had some
effect on power usage...

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120730/ae63547e/attachment.pgp>

[Bug 41265] KMS does not work on Radeon HD6700M

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

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

--- Comment #18 from gyhor at gmx.de 2012-07-30 08:45:42 UTC ---
Hi Alex,

what specific information do we need from sony? if I got through the first help
desk, i should know what to ask :)

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

[git pull] drm exynos pull for -rc1

[Dave Airlie]

Hi Linus,

So I totally missed Inki's pull request for -next, its fully exynos self 
contained.

Regards,
Dave.

The following changes since commit 98c7b42375011ec37251e6fc85a0471cfe499eea:

  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2012-07-26 
10:40:31 +1000)

are available in the git repository at:


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

for you to fetch changes up to e2f895fac1e9fb5f59444e07391bfb3da719716f:

  Merge branch 'exynos-drm-next' of 
git://git.infradead.org/users/kmpark/linux-samsung into drm-next (2012-07-30 
15:16:52 +1000)



Cooper Yuan (1):
  drm/exynos: fix buffer pitch calculation

Dave Airlie (1):
  Merge branch 'exynos-drm-next' of 
git://git.infradead.org/users/kmpark/linux-samsung into drm-next

Inki Dae (14):
  Merge branch 'drm-next' of ../main_line/linux-drm into dave-drm-next
  Merge branch 'drm-next' of ../main_line/linux-drm into dave-drm-next
  drm/exynos: removed unnecessary declaration.
  drm/exynos: set edid fake data only for test.
  drm/exynos: check if raw edid data is fake or not for test
  drm/exynos: fixed edid data setting at vidi connection request
  drm/exynos: fixed build warning.
  drm/exynos: use alloc_page() to allocate pages.
  drm/exynos: set buffer type from exporter.
  drm/exynos: do not release memory region from exporter.
  drm/exynos: removed unnecessary variable
  drm/exynos: fixed a comment to gem size.
  drm/exynos: use __free_page() to deallocate memory
  drm/exynos: fixed exception to page allocation failure

Joonyoung Shim (11):
  drm/exynos: fix point to call overlay_ops->mode_set
  drm/exynos: fix to set pipe of crtc
  drm/exynos: define to_exynos_plane macro
  drm/exynos: use private plane for crtc
  drm/exynos: update overlay via plane from crtc
  drm/exynos: add property for plane zpos
  drm/exynos: fix dpms operation for mode set
  drm/exynos: remove unnecessary connector dpms control
  drm/exynos: add plane enable/disable
  drm/exynos: add crtc disable function
  drm/exynos: add property for crtc mode

Sachin Kamat (4):
  drm/exynos: Add missing static storage class specifier
  drm/exynos: Use devm_* functions in exynos_drm_fimd.c
  drm/exynos: Use devm_* functions in exynos_hdmi.c
  drm/exynos: Use devm_* functions in exynos_mixer.c

Subash Patel (2):
  drm/exynos: return NULL if exynos_pages_to_sg fails
  drm/exynos: check for null in return value of dma_buf_map_attachment()

 drivers/gpu/drm/exynos/exynos_drm_connector.c |3 +-
 drivers/gpu/drm/exynos/exynos_drm_core.c  |5 -
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |  294 +++--
 drivers/gpu/drm/exynos/exynos_drm_crtc.h  |   31 ---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c|   33 ++-
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |9 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |4 +
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |  123 +--
 drivers/gpu/drm/exynos/exynos_drm_encoder.h   |   12 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   40 +---
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |   49 ++---
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |3 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c |  246 ++---
 drivers/gpu/drm/exynos/exynos_drm_plane.h |   12 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |   53 -
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   36 +--
 drivers/gpu/drm/exynos/exynos_mixer.c |   48 ++--
 include/drm/exynos_drm.h  |9 -
 18 files changed, 493 insertions(+), 517 deletions(-)

Re: [PATCH 1/2] radeon: simplify ZS buffer checking on r600

[Christian König]

I wanted to work on something similar this week, cause we need some 
updates for SI on this.


So thx, you saved me some work here. And both patches are:

Reviewed-by: Christian König christian.koe...@amd.com

On 29.07.2012 16:02, Marek Olšák wrote:

Setting those flags has no effect anywhere else.
---
  radeon/radeon_surface.c |9 +
  1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index c80f7f4..5800c33 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -385,14 +385,7 @@ static int r6_surface_init(struct radeon_surface_manager 
*surf_man,
  /* tiling mode */
  mode = (surf-flags  RADEON_SURF_MODE_SHIFT)  RADEON_SURF_MODE_MASK;
  
-/* always enable z  stencil together */

-if (surf-flags  RADEON_SURF_ZBUFFER) {
-surf-flags |= RADEON_SURF_SBUFFER;
-}
-if (surf-flags  RADEON_SURF_SBUFFER) {
-surf-flags |= RADEON_SURF_ZBUFFER;
-}
-if (surf-flags  RADEON_SURF_ZBUFFER) {
+if (surf-flags  (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
  /* zbuffer only support 1D or 2D tiled surface */
  switch (mode) {
  case RADEON_SURF_MODE_1D:


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

[Bug 41265] KMS does not work on Radeon HD6700M

[bugzilla-daemon]

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

--- Comment #18 from gy...@gmx.de 2012-07-30 08:45:42 UTC ---
Hi Alex,

what specific information do we need from sony? if I got through the first help
desk, i should know what to ask :)

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

Re: drm/nouveau: crash regression in 3.5

[Maarten Lankhorst]

Hey,

Op 29-07-12 22:15, Marcin Slusarz schreef:
 On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Glück wrote:
 On 25.07.2012 20:42, Marcin Slusarz wrote:
 Good, below patch should fix this panic.

 Note that you can hit an oops in drm_handle_vblank because patch from
 http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html
 has not been applied (yet?).
 After applying your patch, it still crashes, although with a slightly 
 different stack trace. I then also applied the second patch, but that 
 doesn't make any difference. New log attached.

 Looks like interrupt occurs before nouveau_software_context_new() is 
 called? Shouldn't the initialization be done from 
 nouveau_irq_preinstall() so it is available when the irq occurs? Again, 
 I am not an expert here. Just guessing...
 No, the real problem is: with noaccel we don't register software engine,
 but vblank ISR relies on its existance and happily derefences NULL pointer.

 Now, this patch should fix it for real...

 ---
 From: Marcin Slusarz marcin.slus...@gmail.com
 Subject: [PATCH] drm/nouveau: disable vblank interrupts before registering 
 PDISPLAY ISR

 Currently, we register vblank IRQ handler and later we disable vblank
 interrupts. So, for the short amount of time, we rely on vblank ISR
 to operate correctly, even if vblank interrupts are never going to be
 used later.

 In noaccel case, software engine - which is used by vblank ISR - is not
 registered, so if vblank interrupt triggers in a wrong moment, we can hit
 NULL pointer dereference in nouveau_software_vblank.

 To fix it, disable vblank interrupts before registering PDISPLAY ISR.

 Reported-by: Ortwin Glück o...@odi.ch
 Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
 Cc: sta...@vger.kernel.org [3.5]

I can confirm this bug when I was working on adding d0 vblank, but it seems
to me like nv*_display_create would be a more logical place to put the disable
call. This will make it more clear that vblank is disabled before the irq is 
registered.

Also maybe add a WARN_ON(!nv_engine(dev, NVOBJ_ENGINE_SW)); in
nouveau_vblank_enable and/or return -EINVAL in that case?

If you add the modification to nouveau_vblank_enable:
Reviewed-by: Maarten Lankhorst maarten.lankho...@canonical.com

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

Re: [PATCH 2/3] arm: samsung: Include the modified FIMD header file

[Leela Krishna Amudala]

Adding Marek.

On Mon, Jul 30, 2012 at 2:15 PM, Leela Krishna Amudala 
l.kris...@samsung.com wrote:

 The fimd register headers have been moved to include/video/
 hence, modifying the machine files accordingly.

 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
 ---
  arch/arm/mach-exynos/mach-nuri.c   |2 +-
  arch/arm/mach-exynos/mach-origen.c |2 +-
  arch/arm/mach-exynos/mach-smdk4x12.c   |2 +-
  arch/arm/mach-exynos/mach-smdkv310.c   |2 +-
  arch/arm/mach-exynos/mach-universal_c210.c |2 +-
  arch/arm/mach-exynos/setup-fimd0.c |2 +-
  arch/arm/mach-s3c24xx/mach-smdk2416.c  |2 +-
  arch/arm/mach-s3c64xx/mach-anw6410.c   |2 +-
  arch/arm/mach-s3c64xx/mach-crag6410.c  |2 +-
  arch/arm/mach-s3c64xx/mach-hmt.c   |2 +-
  arch/arm/mach-s3c64xx/mach-mini6410.c  |2 +-
  arch/arm/mach-s3c64xx/mach-ncp.c   |2 +-
  arch/arm/mach-s3c64xx/mach-real6410.c  |2 +-
  arch/arm/mach-s3c64xx/mach-smartq5.c   |2 +-
  arch/arm/mach-s3c64xx/mach-smartq7.c   |2 +-
  arch/arm/mach-s3c64xx/mach-smdk6410.c  |2 +-
  arch/arm/mach-s5p64x0/mach-smdk6440.c  |2 +-
  arch/arm/mach-s5p64x0/mach-smdk6450.c  |2 +-
  arch/arm/mach-s5pc100/mach-smdkc100.c  |2 +-
  arch/arm/mach-s5pv210/mach-aquila.c|2 +-
  arch/arm/mach-s5pv210/mach-goni.c  |2 +-
  arch/arm/mach-s5pv210/mach-smdkv210.c  |2 +-
  22 files changed, 22 insertions(+), 22 deletions(-)

 diff --git a/arch/arm/mach-exynos/mach-nuri.c
 b/arch/arm/mach-exynos/mach-nuri.c
 index f98a83a..573a0c4 100644
 --- a/arch/arm/mach-exynos/mach-nuri.c
 +++ b/arch/arm/mach-exynos/mach-nuri.c
 @@ -39,7 +39,7 @@
  #include asm/mach-types.h

  #include plat/adc.h
 -#include plat/regs-fb-v4.h
 +#include video/samsung_fimd.h
  #include plat/regs-serial.h
  #include plat/cpu.h
  #include plat/devs.h
 diff --git a/arch/arm/mach-exynos/mach-origen.c
 b/arch/arm/mach-exynos/mach-origen.c
 index 5a12dc2..c69707e 100644
 --- a/arch/arm/mach-exynos/mach-origen.c
 +++ b/arch/arm/mach-exynos/mach-origen.c
 @@ -31,7 +31,7 @@
  #include video/platform_lcd.h

  #include plat/regs-serial.h
 -#include plat/regs-fb-v4.h
 +#include video/samsung_fimd.h
  #include plat/cpu.h
  #include plat/devs.h
  #include plat/sdhci.h
 diff --git a/arch/arm/mach-exynos/mach-smdk4x12.c
 b/arch/arm/mach-exynos/mach-smdk4x12.c
 index b26beb1..8a8acff 100644
 --- a/arch/arm/mach-exynos/mach-smdk4x12.c
 +++ b/arch/arm/mach-exynos/mach-smdk4x12.c
 @@ -35,7 +35,7 @@
  #include plat/iic.h
  #include plat/keypad.h
  #include plat/mfc.h
 -#include plat/regs-fb.h
 +#include video/samsung_fimd.h
  #include plat/regs-serial.h
  #include plat/sdhci.h

 diff --git a/arch/arm/mach-exynos/mach-smdkv310.c
 b/arch/arm/mach-exynos/mach-smdkv310.c
 index 3cfa688..c2df6e8 100644
 --- a/arch/arm/mach-exynos/mach-smdkv310.c
 +++ b/arch/arm/mach-exynos/mach-smdkv310.c
 @@ -28,7 +28,7 @@
  #include video/platform_lcd.h
  #include plat/regs-serial.h
  #include plat/regs-srom.h
 -#include plat/regs-fb-v4.h
 +#include video/samsung_fimd.h
  #include plat/cpu.h
  #include plat/devs.h
  #include plat/fb.h
 diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
 b/arch/arm/mach-exynos/mach-universal_c210.c
 index 4d1f40d..e6fb471 100644
 --- a/arch/arm/mach-exynos/mach-universal_c210.c
 +++ b/arch/arm/mach-exynos/mach-universal_c210.c
 @@ -39,7 +39,7 @@
  #include plat/fb.h
  #include plat/mfc.h
  #include plat/sdhci.h
 -#include plat/regs-fb-v4.h
 +#include video/samsung_fimd.h
  #include plat/fimc-core.h
  #include plat/s5p-time.h
  #include plat/camport.h
 diff --git a/arch/arm/mach-exynos/setup-fimd0.c
 b/arch/arm/mach-exynos/setup-fimd0.c
 index 07a6dbe..53c4c51 100644
 --- a/arch/arm/mach-exynos/setup-fimd0.c
 +++ b/arch/arm/mach-exynos/setup-fimd0.c
 @@ -14,7 +14,7 @@
  #include linux/gpio.h

  #include plat/gpio-cfg.h
 -#include plat/regs-fb-v4.h
 +#include video/samsung_fimd.h

  #include mach/map.h

 diff --git a/arch/arm/mach-s3c24xx/mach-smdk2416.c
 b/arch/arm/mach-s3c24xx/mach-smdk2416.c
 index c3100a0..c8d5f51 100644
 --- a/arch/arm/mach-s3c24xx/mach-smdk2416.c
 +++ b/arch/arm/mach-s3c24xx/mach-smdk2416.c
 @@ -52,7 +52,7 @@
  #include plat/udc.h
  #include linux/platform_data/s3c-hsudc.h

 -#include plat/regs-fb-v4.h
 +#include video/samsung_fimd.h
  #include plat/fb.h

  #include plat/common-smdk.h
 diff --git a/arch/arm/mach-s3c64xx/mach-anw6410.c
 b/arch/arm/mach-s3c64xx/mach-anw6410.c
 index ffa29dd..27e3087 100644
 --- a/arch/arm/mach-s3c64xx/mach-anw6410.c
 +++ b/arch/arm/mach-s3c64xx/mach-anw6410.c
 @@ -44,7 +44,7 @@
  #include plat/regs-serial.h
  #include plat/iic.h
  #include plat/fb.h
 -#include plat/regs-fb-v4.h
 +#include video/samsung_fimd.h

  #include plat/clock.h
  #include plat/devs.h
 diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
 b/arch/arm/mach-s3c64xx/mach-crag6410.c
 index 09cd812..66e8c69 100644
 --- 

Re: [PATCH 3/3] driver: Include the modified FIMD header file

[Leela Krishna Amudala]

Adding Marek

On Mon, Jul 30, 2012 at 2:15 PM, Leela Krishna Amudala 
l.kris...@samsung.com wrote:

 The fimd register headers have been moved to include/video/
 hence, modifying the driver files accordingly.

 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
  drivers/video/s3c-fb.c   |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 index 29fdbfe..8da90f9 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 @@ -20,7 +20,7 @@
  #include linux/pm_runtime.h

  #include drm/exynos_drm.h
 -#include plat/regs-fb-v4.h
 +#include video/samsung_fimd.h

  #include exynos_drm_drv.h
  #include exynos_drm_fbdev.h
 diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
 index 69bf9d0..1226fdd 100644
 --- a/drivers/video/s3c-fb.c
 +++ b/drivers/video/s3c-fb.c
 @@ -26,7 +26,7 @@
  #include linux/pm_runtime.h

  #include mach/map.h
 -#include plat/regs-fb-v4.h
 +#include video/samsung_fimd.h
  #include plat/fb.h

  /* This driver will export a number of framebuffer interfaces depending
 --
 1.7.0.4

 --
 To unsubscribe from this list: send the line unsubscribe linux-fbdev in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: [PATCH 1/3] Move FIMD register headers to include/video/

[Sylwester Nawrocki]

Hi,

On 07/30/2012 10:45 AM, Leela Krishna Amudala wrote:
 Moved the contents of regs-fb-v4.h and regs-fb.h from arch side
 to include/video/samsung_fimd.h
 
 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
 ---
  arch/arm/plat-samsung/include/plat/regs-fb-v4.h |  159 ---
  arch/arm/plat-samsung/include/plat/regs-fb.h|  403 -
  include/video/samsung_fimd.h|  533 
 +++
  3 files changed, 533 insertions(+), 562 deletions(-)
  delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h
  delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h
  create mode 100644 include/video/samsung_fimd.h

Thanks for taking care if this. However you might need to split this 
patch in two, so there is no build and git bisection breakage. In the
first patch a new header file would be added, then the patch updating
users of the FIMD headers would be applied, and finally the regs-fb*.h 
files would be removed.

Also it helps to use -M option to git format-patch when creating patches
that mainly move files.

--

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

Re: [PATCH 1/3] Move FIMD register headers to include/video/

[Sylwester Nawrocki]

Hi,

On 07/30/2012 10:53 AM, Jingoo Han wrote:
 +/*FIMD V8 REG OFFSET */
 +#define FIMD_V8_VIDTCON0(0x20010)
 +#define FIMD_V8_VIDTCON1(0x20014)
 +#define FIMD_V8_VIDTCON2(0x20018)
 +#define FIMD_V8_VIDTCON3(0x2001C)
 +#define FIMD_V8_VIDCON1 (0x20004)
 
 
 CC'ed Marek.
 
 To Leela Krishna Amudala,
 
 Don't add these definitions for FIMD_V8_xxx registers, which are 
 not related to current regs-fb-v4.h and regs-fb.h.
 Just move and merge regs-fb-v4.h and regs-fb.h to one header 
 file, not add new definitions.
 If you want to add these definitions, please make new patch for this.

Good point.

 Also, #define FIMD_V8_xxx is ugly.
 I think that there is better way.
 Please, find other way.

Instead of just telling that something is wrong and you don't like it, 
perhaps it would be kind to give at least a slight suggestion of what 
would have been good enough to your taste...respecting someone else's
time and effort.

So what would you like to see there instead, EXYNOS5_FIMD_* ?

BTW, your e-mails are badly word wrapped, I had to manually correct it.

-- 

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

[Bug 52950] New: [r200] piglit glean/blendFunc test fails

[bugzilla-daemon]

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

 Bug #: 52950
   Summary: [r200] piglit glean/blendFunc test fails
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r200
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: mister.free...@laposte.net


System configuration :

- radeon 9000 AGP ( M9, rv250 )
- laptop pentium 4 2.4 Ghz 1.25 Gb ram
- archlinux 32 bits

Step to reproduce the bug

- mesa 8.0.4 release ( but the bug occurs also with the git version )
- a graphic card who uses the r200 driver 
- install piglit ( git version )
- run the glean test blendFunc in piglit :

./piglit-run.py  -t glean/blendFunc tests/quick.tests results/quick

the glean/blendFunc will fail with these error messages :

First failing pixel is at row 11 column 24
Actual values are (0, 0, 0, 0.54902)
Expected values are (0, 0, 0, 0.557007)
Errors are (0, 0, 0, 0.00798696)
Source values are (0.462745, 0.756863, 0.662745, 0.546639)
Destination values are (0.819608, 0.0980392, 0.615686, 0.0509804)
blendFunc:  FAIL rgba8, db, z24, s8, win+pmap, id 33
source factor RGB = GL_ZERO, source factor A = GL_ONE_MINUS_DST_COLOR
dest factor RGB = GL_ZERO, dest factor A = GL_CONSTANT_COLOR
equation RGB = GL_FUNC_ADD, equation A = GL_FUNC_ADD
const color = { 0.25, 0, 1, 0.75 }
Readback had 0 bits in error; blending had 1.03186 bits in error.

First failing pixel is at row 7 column 27
Actual values are (0.682353, 0.682353, 0.92549, 0.756863)
Expected values are (0.682353, 0.682353, 0.92549, 0.765417)
Errors are (0, 0, 0, 0.0085544)
Source values are (0.682353, 0.968627, 0.243137, 0.761929)
Destination values are (0.682353, 0.682353, 0.92549, 0.0156863)
blendFunc:  FAIL rgba8, db, z24, s8, win+pmap, id 33
source factor RGB = GL_ZERO, source factor A = GL_ONE_MINUS_DST_COLOR
dest factor RGB = GL_ONE, dest factor A = GL_ONE_MINUS_DST_ALPHA
equation RGB = GL_FUNC_ADD, equation A = GL_FUNC_ADD
const color = { 0.25, 0, 1, 0.75 }
Readback had 0 bits in error; blending had 1.13088 bits in error.

First failing pixel is at row 1 column 16
Actual values are (0.0705882, 0.298039, 0.243137, 0.74902)
Expected values are (0.0693272, 0.296286, 0.245752, 0.756865)
Errors are (0.00126106, 0.00175321, 0.00261439, 0.00784552)
Source values are (0.909804, 0.694118, 0.0784314, 0.804654)
Destination values are (0.768627, 0.968627, 0.27, 0.0784314)
blendFunc:  FAIL rgba8, db, z24, s8, win+pmap, id 33
source factor RGB = GL_ZERO, source factor A = GL_ONE_MINUS_DST_COLOR
dest factor RGB = GL_ONE_MINUS_SRC_COLOR, dest factor A =
GL_ONE_MINUS_SRC_ALPHA
equation RGB = GL_FUNC_ADD, equation A = GL_FUNC_ADD
const color = { 0.25, 0, 1, 0.75 }
Readback had 0 bits in error; blending had 1.00608 bits in error.

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

[Bug 52951] New: [r200] piglit glean/clipFlat test fails

[bugzilla-daemon]

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

 Bug #: 52951
   Summary: [r200] piglit glean/clipFlat test fails
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r200
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: mister.free...@laposte.net


System configuration :

- radeon 9000 AGP ( M9, rv250 )
- laptop pentium 4 2.4 Ghz 1.25 Gb ram
- archlinux 32 bits

Step to reproduce the bug

- mesa 8.0.4 release ( but the bug occurs also with the git version )
- a graphic card who uses the r200 driver 
- install piglit ( git version )
- run the glean test clipFlat in piglit :

./piglit-run.py  -t glean/clipFlat tests/quick.tests results/quick

the glean/clipFlat will fail with this error message :

Test clipping with flat shading (provoking vertex).

clipFlat: Failure for glDrawElements(GL_QUAD_STRIP), glFrontFace(GL_CCW),
glPolygonMode(GL_FILL)
Translation: -1, -1
Expected color (0, 1, 0) but found (1, 1, 0)
clipFlat:  FAIL rgba8, db, z24, s8, win+pmap, id 33

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

[Bug 52954] New: [r200] piglit glean/exactRGBA test fails

[bugzilla-daemon]

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

 Bug #: 52954
   Summary: [r200] piglit glean/exactRGBA test fails
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r200
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: mister.free...@laposte.net


System configuration :

- radeon 9000 AGP ( M9, rv250 )
- laptop pentium 4 2.4 Ghz 1.25 Gb ram
- archlinux 32 bits

Step to reproduce the bug

- mesa 8.0.4 release ( but the bug occurs also with the git version )
- a graphic card who uses the r200 driver 
- install piglit ( git version )
- run the glean test exactRGBA in piglit :

./piglit-run.py  -t glean/exactRGBA tests/quick.tests results/quick

the glean/exactRGBA will fail with these error messages :

Output:
--
This test performs a sanity check of glReadPixels, using as
few other portions of the GL as possible.  If this test fails,
it may be pointless to run other tests, since so many of them
depend on reading the contents of the framebuffer to determine
if they pass.

The test works by using glClear to fill the framebuffer with a
randomly-chosen value, reading the contents of the
framebuffer, and comparing the actual contents with the
expected contents.  RGB, RGBA, color index, stencil, and depth
buffers (whichever are applicable to the current rendering
context) are checked.  The test passes if the actual contents
are within 1 LSB of the expected contents.

readPixSanity:  PASS rgba8, db, z24, s8, win+pmap, id 33
RGBA largest readback error was 0 bits
Depth largest readback error was 0.33985 bits

--
The OpenGL specification requires that under certain conditions
(e.g. lighting disabled, no clipping, no dithering, etc.) colors
specified as unsigned integers are represented *exactly* in the
framebuffer (up to the number of bits common to both the
original color and the framebuffer color channel).  Several glean
tests depend on this behavior, so this test is a prerequisite for
them.

This test works by drawing many small quadrilaterals whose
colors are specified by glColorub, glColorus, and glColorui;
reading back the resulting image; and comparing the colors read
back to the colors written.  The high-order bits shared by the
source representation of the colors and the framebuffer
representation of the colors must agree exactly for the test to
pass.

exactRGBA:  FAIL rgba8, db, z24, s8, win+pmap, id 33
Unsigned short worst-case error was 0x100 at (0, 0)
expected (0xeb00, 0x5ea3, 0xb3a6, 0x36cd)
got (0xea00, 0x5e5e, 0xb3b3, 0x3737)
Unsigned int   worst-case error was 0x100 at (1, 0)
expected (0xff00, 0xf4c10287, 0xd06cde3a, 0xe62b5851)
got (0xfe00, 0xf4f4f4ff, 0xd0d0d0ff, 0xe5e5e5ff)

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

[Bug 52955] New: [r200] piglit glean/fbo test fails

[bugzilla-daemon]

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

 Bug #: 52955
   Summary: [r200] piglit glean/fbo test fails
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r200
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: mister.free...@laposte.net


System configuration :

- radeon 9000 AGP ( M9, rv250 )
- laptop pentium 4 2.4 Ghz 1.25 Gb ram
- archlinux 32 bits

Step to reproduce the bug

- mesa 8.0.4 release ( but the bug occurs also with the git version )
- a graphic card who uses the r200 driver 
- install piglit ( git version )
- run the glean test fbo in piglit :

./piglit-run.py  -t glean/fbo tests/quick.tests results/quick

the glean/fbo will fail with these error messages :

fbo test: Test OpenGL Extension GL_EXT_framebuffer_object

GL_EXT_framebuffer_object is supported
GL_ARB_framebuffer_object is not supported
  depth = 0, stencil = 0
  (63, 0) = [0.00, 0.00, 0.00], is expected to be[1.00,
0.00, 0.00]
FAILURE: Render to single texture failed (at tfbo.cpp:850)
  mode = 0
 
(FBOTest::testRender2depthTexture:1090)GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT
  depth = 1, stencil = 0
  (0, 0) = [0.00, 1.00, 0.00], is expected to be[1.00,
1.00, 1.00]
FAILURE: Render to depth texture failed (at tfbo.cpp:1155)
FAILURE: If renderbuffer sizes don't all match, status should be
GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS_EXT (at tfbo.cpp:1344)
fbo:  FAIL rgba8, db, z24, s8, win+pmap, id 33
5 tests passed, 3 tests failed.

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

[Bug 52956] New: [r200] piglit glean/pointAtten test fails

[bugzilla-daemon]

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

 Bug #: 52956
   Summary: [r200] piglit glean/pointAtten test fails
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r200
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: mister.free...@laposte.net


System configuration :

- radeon 9000 AGP ( M9, rv250 )
- laptop pentium 4 2.4 Ghz 1.25 Gb ram
- archlinux 32 bits

Step to reproduce the bug

- mesa 8.0.4 release ( but the bug occurs also with the git version )
- a graphic card who uses the r200 driver 
- install piglit ( git version )
- run the glean test pointAtten in piglit :

./piglit-run.py  -t glean/pointAtten tests/quick.tests results/quick

the glean/pointAtten will fail with these error messages :

Test point size attenuation with the GL_ARB_point_parameters extension.

FAILURE:
Expected size: 3.53553  Actual size: 2
Size: 5
Min: 1  Max: 6
Attenuation: 1 0 1
Eye Z: -1
Aliased

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

[Bug 52957] New: [r200] piglit glean/vp1-LIT test 2 (degenerate case: 0 ^ 0 - 1) test fails

[bugzilla-daemon]

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

 Bug #: 52957
   Summary: [r200] piglit glean/vp1-LIT test 2 (degenerate case: 0
^ 0 - 1) test fails
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r200
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: mister.free...@laposte.net


System configuration :

- radeon 9000 AGP ( M9, rv250 )
- laptop pentium 4 2.4 Ghz 1.25 Gb ram
- archlinux 32 bits

Step to reproduce the bug

- mesa 8.0.4 release ( but the bug occurs also with the git version )
- a graphic card who uses the r200 driver 
- install piglit ( git version )
- run the glean test vp1-LIT test 2 (degenerate case: 0 ^ 0 - 1) in piglit :

./piglit-run.py  -t glean/vp1-LIT test 2 (degenerate case tests/quick.tests
results/quick

the glean/vp1-LIT test 2 (degenerate case: 0 ^ 0 - 1) will fail with this
error message :

Vertex Program test 1: test a specific set of vertex programs.

FAILURE:
  Program: LIT test 2 (degenerate case: 0 ^ 0 - 1)
  Expected color: 1, 0.65, 1, 1
  Observed color: 1, 0.65098, 0, 1
vertProg1:  FAIL rgba8, db, z24, s8, win+pmap, id 33
3 tests passed, 1 tests failed.

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

Re: [PATCH 1/3] Move FIMD register headers to include/video/

[Leela Krishna Amudala]

Hello Sylwester,

On Mon, Jul 30, 2012 at 2:19 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:

 Hi,

 On 07/30/2012 10:45 AM, Leela Krishna Amudala wrote:
  Moved the contents of regs-fb-v4.h and regs-fb.h from arch side
  to include/video/samsung_fimd.h
 
  Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
  ---
   arch/arm/plat-samsung/include/plat/regs-fb-v4.h |  159 ---
   arch/arm/plat-samsung/include/plat/regs-fb.h|  403 -
   include/video/samsung_fimd.h|  533 
  +++
   3 files changed, 533 insertions(+), 562 deletions(-)
   delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h
   delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h
   create mode 100644 include/video/samsung_fimd.h

 Thanks for taking care if this. However you might need to split this
 patch in two, so there is no build and git bisection breakage. In the
 first patch a new header file would be added, then the patch updating
 users of the FIMD headers would be applied, and finally the regs-fb*.h
 files would be removed.

 Also it helps to use -M option to git format-patch when creating patches
 that mainly move files.


Will do it in the suggested way,
Thanks for reviewing the patch.

 --

 Regards,
 Sylwester
 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41265] KMS does not work on Radeon HD6700M

[bugzilla-daemon]

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

--- Comment #19 from Alex Deucher ag...@yahoo.com 2012-07-30 13:37:42 UTC ---
Where the vbios (video bios) for the discrete card is stored (on a rom on the
board, in the sbios (system bios), etc.).  If it's part of the sbios, there's
probably an ACPI method (ROM or ATRM) to access it.

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

[Bug 52950] [r200] piglit glean/blendFunc test fails

[bugzilla-daemon]

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

Roland Scheidegger srol...@vmware.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Roland Scheidegger srol...@vmware.com 2012-07-30 13:56:04 
UTC ---
IIRC radeon alpha blend units before r300 (maybe even later) had some precision
issues, they just don't quite fulfill the requirements. So getting these errors
is expected (it is just one bit of error after all), and it is unfixable.

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

Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code

[Luca Tettamanti]

On Mon, Jul 30, 2012 at 04:32:47PM +0800, joeyli wrote:
 於 日，2012-07-29 於 15:10 +0200，Luca Tettamanti 提到：
  On Sun, Jul 29, 2012 at 11:51:48AM +0800, joeyli wrote:
   Hi Luca, 
   
   於 六，2012-07-28 於 16:56 +0200，Luca Tettamanti 提到：
I just found the first problem (probably a BIOS bug):
ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
corresponding bit ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED is not set :(
I intended to use the method to set up the notification handler but now
my BIOS says that it's not there even if it is...
Can I assume some default values (e.g. notifications are enabled and 
will
use 0x81 unless ATIF_FUNCTION_GET_SYSTEM_PARAMETERS says something
different)?

   
   Did you check your DSDT for there have some Notify (VGA, 0x81)
   statement in AFN0..AFN15?
   If YES, I think that means your machine in case the 0x81 is for ATI used
   by default.
  
  Yes, my point is that the nofication is there, but since
  GET_SYSTEM_PARAMETERS is not announced I have not way to check it.
  IOW, what is implemented in the DSDT does not match what is announced by
  VERIFY_INTERFACE.
  For reference this is the DSDT: http://pastebin.com/KKS7ZsTt
  
  Luca
  
 
 Yes, saw the problem in your DSDT:
 
 Method (AF00, 0, NotSerialized)
 {
 CreateWordField (ATIB, Zero, SSZE)
   ...
 Store (0x80, NMSK)
 Store (0x02, SFUN)=== 10b, bit 0 is 0
 Return (ATIB)
 }
 
 But, AF01 still supported in ATIF on this machine, maybe we should still
 try GET_SYSTEM_PARAMETERS even the function vector set to 0?
 No idea...

That's what I'm doing right now... if SBIOS_REQUESTS is supported I try
and call GET_SYSTEM_PARAMETERS even if it's not announced.

 On the other hand, 
 My patch to avoid 0x81 event conflict with acpi/video driver like below.
 This patch woks on my notebook. Your patches do much more things then
 mine, so I think my patch just for reference.  

I ignored the event handling for now... I'd like to hear something back
from ACPI camp before committing to this solution.

 There have a problem is:
 If we want use acpi_notifier_call_chain to check does event consume by
 any notifier in acpi's blocking notifier chain, then we need return
 NOTIFY_BAD in radeon_acpi but not NOTIFY_OK.
 
 So, I suggest radeon_acpi should register to acpi notifier chain by
 itself but not append on radeon_acpi_event in radeon_pm. 

It shouldn't matter, once I change radeon_atif_handler to return
NOTIFY_BAD the call chain will be stopped anyway.

 And,
 suggest also check the device class is ACPI_VIDEO_CLASS like following:
 
 +static int radeon_acpi_video_event(struct notifier_block *nb,
 ...
 + if (strcmp(event-device_class, ACPI_VIDEO_CLASS) != 0)
 + return NOTIFY_DONE;
 +

Will do. I'll use the package structs in the next iteration.

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

[Bug 52957] [r200] piglit glean/vp1-LIT test 2 (degenerate case: 0 ^ 0 - 1) test fails

[bugzilla-daemon]

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

Roland Scheidegger srol...@vmware.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Roland Scheidegger srol...@vmware.com 2012-07-30 14:19:43 
UTC ---
This is due to differences in LIT opcode between DX and OGL. AFAIK the chip can
only do the DX version (there's no documentation for this part of the chip, but
r300 could only do this too). Hence to make this opcode work correctly,
complicated workarounds might be needed - given the chip limits (program length
etc.) these might do more wrong than good. So unless you find some real app
where this is a problem noone will bother - not that many programs can use
vertex programs on r200 anyway since often new render paths also would require
fragment program.

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

Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code

[Alex Deucher]

On Sun, Jul 29, 2012 at 9:06 AM, Luca Tettamanti kronos...@gmail.com wrote:
 On Sat, Jul 28, 2012 at 05:29:25PM -0400, Alex Deucher wrote:
 On Sat, Jul 28, 2012 at 10:56 AM, Luca Tettamanti kronos...@gmail.com 
 wrote:
  I just found the first problem (probably a BIOS bug):
  ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
  corresponding bit ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED is not set :(
  I intended to use the method to set up the notification handler but now
  my BIOS says that it's not there even if it is...
  Can I assume some default values (e.g. notifications are enabled and will
  use 0x81 unless ATIF_FUNCTION_GET_SYSTEM_PARAMETERS says something
  different)?

 The spec says that the bits in the supported functions vector mean
 that if bit n is set, function n+1 exists,

 Hum, I don't follow. The vector in my case is 0x2 (1  1), that would
 mean that ATIF_SELECT_ACTIVE_DISPLAYS_SUPPORTED (1  2) is supported?

 Maybe if the bit n is set then functions 0..n are available? That would
 (almost) match what I see...

From the spec:

Supported DWORD Bit vector providing supported functions
information. Each bit marks
Functions Bit  support for one specific function of the
ATIF method. Bit n, if set,
Vectorindicates that Function n+1 is supported.

I don't know how wonky bioses in the wild are however.  I can see what
our internal teams do in these sort of cases.


 but it's possible that the
 spec is wrong and it's actually a 1 to 1 mapping; if bit n is set,
 function n is supported.  In which case the the supported functions
 vector bits should be:
 +/* supported functions vector */
 +#   define ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED   (1  1)
 +#   define ATIF_GET_SYSTEM_BIOS_REQUESTS_SUPPORTED(1  2)
 +#   define ATIF_SELECT_ACTIVE_DISPLAYS_SUPPORTED  (1  3)
 +#   define ATIF_GET_LID_STATE_SUPPORTED   (1  4)
 +#   define ATIF_GET_TV_STANDARD_FROM_CMOS_SUPPORTED   (1  5)
 +#   define ATIF_SET_TV_STANDARD_IN_CMOS_SUPPORTED (1  6)
 +#   define ATIF_GET_PANEL_EXPANSION_MODE_FROM_CMOS_SUPPORTED  (1  7)
 +#   define ATIF_SET_PANEL_EXPANSION_MODE_IN_CMOS_SUPPORTED(1  8)
 +#   define ATIF_TEMPERATURE_CHANGE_NOTIFICATION_SUPPORTED (1  13)
 +#   define ATIF_GET_GRAPHICS_DEVICE_TYPES_SUPPORTED   (1  15)

 See if that lines up better.

 Not really... the value returned by VERIFY_INTERFACE is 0x2, but in the
 DSDT I see:

 ATIF_FUNCTION_GET_SYSTEM_PARAMETERS
 ATIF_FUNCTION_GET_SYSTEM_BIOS_REQUESTS
 ATIF_FUNCTION_GET_TV_STANDARD_FROM_CMOS
 ATIF_FUNCTION_SET_TV_STANDARD_IN_CMOS

 The implementation of the first one makes sense, the second is used for
 brightness control. The other two _might_ be a leftover (the machine
 does not have an analog TV out).

Yeah, probably unless there is a TV-out on a docking station or
something like that.  The TV-out port should show up in the connector
table in the vbios even if it has a port on the docking station
however.

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

Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code

[Alex Deucher]

On Sun, Jul 29, 2012 at 3:33 PM, Luca Tettamanti kronos...@gmail.com wrote:
 Hi,
 I'm attaching a first draft of my work. The first 3 patches are
 infrastructure work, the fourth wires the notification handler and
 retrieves the requests from the system BIOS, but it does not actually
 change brightness yet.

 The problem here is how to get the correct encoder: should I just scan
 encoder_list checking for ATOM_DEVICE_LCD_SUPPORT and see if it has a
 backlight device attached?

Yeah, that should work.

 Hopefully there is only one encoder with it, right?

There's only one backlight controller and there should only be one
encoder with it enabled on it.


 I'm also toying with the idea of creating structures matching the output
 of the various ACPI methods, this would remove some ugly pointer
 arithmetics, but it _might_ make it easier to read past the buffer if
 one does not check the size before using the struct. What do you think?

That's fine with me.  We do something similar with atombios structs.
Also, feel free to add stuff to radeon_acpi.h if you think it's
useful.

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

Re: [PATCH] drm/radeon: Mark all possible functions / structs as static

[Alex Deucher]

On Fri, Jul 27, 2012 at 5:34 PM, Lauri Kasanen c...@gmx.com wrote:
 Let's allow GCC to optimize better.

 This exposed some five unused functions, but this patch doesn't remove them.

 Signed-off-by: Lauri Kasanen c...@gmx.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Jerome Glisse]

On Sun, Jul 29, 2012 at 1:04 PM, Marek Olšák mar...@gmail.com wrote:
 If we don't need stencil, don't allocate it.
 If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.

 v2: actually do it correctly

Big NAK

We need to allocate stencil and depth no matter what. Otherwise it
will lockup. You can take a look by poisonning the surface and see
that when stencil is disabled or depth is disabled the hw still write
to it.

Cheers,
Jerome

 ---
  radeon/radeon_surface.c |   23 ---
  1 file changed, 8 insertions(+), 15 deletions(-)

 diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
 index 5800c33..874a092 100644
 --- a/radeon/radeon_surface.c
 +++ b/radeon/radeon_surface.c
 @@ -604,7 +604,11 @@ static int eg_surface_init_1d(struct 
 radeon_surface_manager *surf_man,
  }
  }

 -if (surf-flags  RADEON_SURF_SBUFFER) {
 +/* The depth and stencil buffers are in separate resources on evergreen.
 + * We allocate them in one buffer next to each other to simplify
 + * communication between the DDX and the Mesa driver. */
 +if ((surf-flags  (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) ==
 +   (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
  surf-stencil_offset = ALIGN(surf-bo_size, surf-bo_alignment);
  surf-bo_size = surf-stencil_offset + surf-bo_size / 4;
  }
 @@ -656,7 +660,8 @@ static int eg_surface_init_2d(struct 
 radeon_surface_manager *surf_man,
  }
  }

 -if (surf-flags  RADEON_SURF_SBUFFER) {
 +if ((surf-flags  (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) ==
 +   (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
  surf-stencil_offset = ALIGN(surf-bo_size, surf-bo_alignment);
  surf-bo_size = surf-stencil_offset + surf-bo_size / 4;
  }
 @@ -752,14 +757,7 @@ static int eg_surface_init(struct radeon_surface_manager 
 *surf_man,
  /* tiling mode */
  mode = (surf-flags  RADEON_SURF_MODE_SHIFT)  RADEON_SURF_MODE_MASK;

 -/* for some reason eg need to have room for stencil right after depth */
 -if (surf-flags  RADEON_SURF_ZBUFFER) {
 -surf-flags |= RADEON_SURF_SBUFFER;
 -}
 -if (surf-flags  RADEON_SURF_SBUFFER) {
 -surf-flags |= RADEON_SURF_ZBUFFER;
 -}
 -if (surf-flags  RADEON_SURF_ZBUFFER) {
 +if (surf-flags  (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
  /* zbuffer only support 1D or 2D tiled surface */
  switch (mode) {
  case RADEON_SURF_MODE_1D:
 @@ -828,11 +826,6 @@ static int eg_surface_best(struct radeon_surface_manager 
 *surf_man,
  /* tiling mode */
  mode = (surf-flags  RADEON_SURF_MODE_SHIFT)  RADEON_SURF_MODE_MASK;

 -/* for some reason eg need to have room for stencil right after depth */
 -if (surf-flags  RADEON_SURF_ZBUFFER) {
 -surf-flags |= RADEON_SURF_SBUFFER;
 -}
 -
  /* set some default value to avoid sanity check choking on them */
  surf-tile_split = 1024;
  surf-bankw = 1;
 --
 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 43655] Latest radeon dri driver on HD6950 with GRUB set gfxpayload=$linux_gfx_mode put the display in a flickering state

[bugzilla-daemon]

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

--- Comment #15 from Jerome Glisse gli...@freedesktop.org 2012-07-30 14:59:56 
UTC ---
If it's same as https://bugs.freedesktop.org/show_bug.cgi?id=42373 then patch
there should fix your issue.

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

Re: Massive power regression going 3.4-3.5

[James Bottomley]

On Mon, 2012-07-30 at 10:46 +0100, James Bottomley wrote:
 On Sun, 2012-07-29 at 21:25 +0200, Rafael J. Wysocki wrote:
  On Sunday, July 29, 2012, Rafael J. Wysocki wrote:
   On Sunday, July 29, 2012, James Bottomley wrote:
On Sat, 2012-07-28 at 22:29 +0200, Rafael J. Wysocki wrote:
 On Saturday, July 28, 2012, Rafael J. Wysocki wrote:
  On Saturday, July 28, 2012, James Bottomley wrote:
   One of the great things about the 3.4 kernel was the massive 
   increase in
   power savings on my x220i laptop.  With full PCI suspend, it 
   could get
   down to 6.5W in idle with a dim screen, provided I used powertop 
   2.0 to
   activate all the tunings).  I just upgraded to 3.5 (the openSUSE
   tumbleweed kernel) and all the power savings are gone.  Now it's 
   back to
   its previous behaviour of idle somewhere between 16-18W.
  
  Please check dbe9a2e (ACPI / PM: Make acpi_pm_device_sleep_state() 
  follow the
  specification) for starters.
  
  If that is not the culprit, 38c92ff (ACPI / PM: Make 
  __acpi_bus_get_power()
  cover D3cold correctly) is worth ckecking too.
  
  If none of the above, c2fb8a3 (USB: add NO_D3_DURING_SLEEP flag and 
  revert
  151b61284776be2) is one more candidate.
  
  I can't recall anything else that might be related to the symptom 
  at the moment.
 
 Actually, dbe9a2e and c2fb8a3 only affect system suspend, so for 
 runtime PM
 38c92ff seems to be the only relevant one from the above.

I verified the problem shows up on vanilla 3.5 (just in case it was an
openSUSE problem).  I also tried reverting 38c92ff with no success.  The
symptoms appear to be that something is preventing the PCI/device
subsystem from going into auto suspend.
   
   The number of core power management commits during the 3.5 cycle was 
   rather
   limited and none of them should affect PCI runtime PM.  I have no idea 
   what
   the root cause of that may be, quite frankly.
  
  I've just realized that you said auto suspend, which makes me think that 
  the
  problem may be related to USB.
  
  PCI doesn't really use any kind of auto suspend for what I know, but USB 
  does
  and it may cause PCI USB controllers to be suspended as a result.
 
 I'm trying to bisect this, but I've got stuck around here:
 
 git bisect bad 2f78d8e249973f1eeb88315e6444e616c60177ae
 git bisect good 28f3d717618156c0dcd2f497d791b578a7931d87
 
 That's around the drm tree ... unfortunately that broke a lot of the
 basics of my i915 based system (compositing and resolution) as I step
 into it.

OK, I've run the bisect as far as I can.  It looks to be in the drm
tree.  Unfortunately, this tree has several merge points, some of which
go further back than v3.4.  Unfortunately, once the bisect steps back
before 3.4, we lose the changes that gave us the power savings, making
further debugging impossible

Here's the log

git bisect start
# bad: [28a33cbc24e4256c143dce96c7d93bf423229f92] Linux 3.5
git bisect bad 28a33cbc24e4256c143dce96c7d93bf423229f92
# bad: [28a33cbc24e4256c143dce96c7d93bf423229f92] Linux 3.5
git bisect bad 28a33cbc24e4256c143dce96c7d93bf423229f92
# good: [76e10d158efb6d4516018846f60c2ab5501900bc] Linux 3.4
git bisect good 76e10d158efb6d4516018846f60c2ab5501900bc
# good: [59cd358a7a5b2f6b61faa01dae6cfda3830ac62a] Merge tag 
'perf-core-for-mingo' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
git bisect good 59cd358a7a5b2f6b61faa01dae6cfda3830ac62a
# bad: [7e5b2db77b05746613516599c916a8cc2e321077] Merge branch 'upstream' of 
git://git.linux-mips.org/pub/scm/ralf/upstream-linus
git bisect bad 7e5b2db77b05746613516599c916a8cc2e321077
# good: [f9369910a6225b8d4892c3f20ae740a711cd5ace] Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal
git bisect good f9369910a6225b8d4892c3f20ae740a711cd5ace
# bad: [2f78d8e249973f1eeb88315e6444e616c60177ae] Merge tag 'firewire-updates' 
of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
git bisect bad 2f78d8e249973f1eeb88315e6444e616c60177ae
# good: [28f3d717618156c0dcd2f497d791b578a7931d87] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
git bisect good 28f3d717618156c0dcd2f497d791b578a7931d87
# bad: [b3daeaef559d87b974c13a096582c5c70dc11061] drm/i915: move rps/emon 
function declarations
git bisect bad b3daeaef559d87b974c13a096582c5c70dc11061
# bad: [246bdbeb0f0fb14c4c085b6ed7edbab11afccd33] drm/i915: share forcewaking 
code between IVB and HSW
git bisect bad 246bdbeb0f0fb14c4c085b6ed7edbab11afccd33

If you do a gitk on the last bad and good 

gitk 
28f3d717618156c0dcd2f497d791b578a7931d87..246bdbeb0f0fb14c4c085b6ed7edbab11afccd33

You see there are only drm commits in there.

James


___
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 gfxpayload=$linux_gfx_mode put the display in a flickering state

[bugzilla-daemon]

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

--- Comment #16 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-07-30 
15:12:24 UTC ---
(In reply to comment #15)
 If it's same as https://bugs.freedesktop.org/show_bug.cgi?id=42373 then patch
 there should fix your issue.

I'll try it as soon as I'll have time. Thank you Jerome for your follow-up.

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

Re: [PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Christian König]

On 30.07.2012 16:56, Jerome Glisse wrote:

On Sun, Jul 29, 2012 at 1:04 PM, Marek Olšák mar...@gmail.com wrote:

If we don't need stencil, don't allocate it.
If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.

v2: actually do it correctly

Big NAK

We need to allocate stencil and depth no matter what. Otherwise it
will lockup. You can take a look by poisonning the surface and see
that when stencil is disabled or depth is disabled the hw still write
to it.


Really? That bug is new to me, at least on SI that works perfectly 
(currently working on it), so on which hardware do you see that behavior?


Anyway, when we have hardware bugs that enabling depth also enables 
stencil we should handle that in the hardware specific drivers, not in 
general purpose code.


Cheers,
Christian.



Cheers,
Jerome


---
  radeon/radeon_surface.c |   23 ---
  1 file changed, 8 insertions(+), 15 deletions(-)

diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 5800c33..874a092 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -604,7 +604,11 @@ static int eg_surface_init_1d(struct 
radeon_surface_manager *surf_man,
  }
  }

-if (surf-flags  RADEON_SURF_SBUFFER) {
+/* The depth and stencil buffers are in separate resources on evergreen.
+ * We allocate them in one buffer next to each other to simplify
+ * communication between the DDX and the Mesa driver. */
+if ((surf-flags  (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) ==
+   (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
  surf-stencil_offset = ALIGN(surf-bo_size, surf-bo_alignment);
  surf-bo_size = surf-stencil_offset + surf-bo_size / 4;
  }
@@ -656,7 +660,8 @@ static int eg_surface_init_2d(struct radeon_surface_manager 
*surf_man,
  }
  }

-if (surf-flags  RADEON_SURF_SBUFFER) {
+if ((surf-flags  (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) ==
+   (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
  surf-stencil_offset = ALIGN(surf-bo_size, surf-bo_alignment);
  surf-bo_size = surf-stencil_offset + surf-bo_size / 4;
  }
@@ -752,14 +757,7 @@ static int eg_surface_init(struct radeon_surface_manager 
*surf_man,
  /* tiling mode */
  mode = (surf-flags  RADEON_SURF_MODE_SHIFT)  RADEON_SURF_MODE_MASK;

-/* for some reason eg need to have room for stencil right after depth */
-if (surf-flags  RADEON_SURF_ZBUFFER) {
-surf-flags |= RADEON_SURF_SBUFFER;
-}
-if (surf-flags  RADEON_SURF_SBUFFER) {
-surf-flags |= RADEON_SURF_ZBUFFER;
-}
-if (surf-flags  RADEON_SURF_ZBUFFER) {
+if (surf-flags  (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
  /* zbuffer only support 1D or 2D tiled surface */
  switch (mode) {
  case RADEON_SURF_MODE_1D:
@@ -828,11 +826,6 @@ static int eg_surface_best(struct radeon_surface_manager 
*surf_man,
  /* tiling mode */
  mode = (surf-flags  RADEON_SURF_MODE_SHIFT)  RADEON_SURF_MODE_MASK;

-/* for some reason eg need to have room for stencil right after depth */
-if (surf-flags  RADEON_SURF_ZBUFFER) {
-surf-flags |= RADEON_SURF_SBUFFER;
-}
-
  /* set some default value to avoid sanity check choking on them */
  surf-tile_split = 1024;
  surf-bankw = 1;
--
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


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

Re: [PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Marek Olšák]

On Mon, Jul 30, 2012 at 4:56 PM, Jerome Glisse j.gli...@gmail.com wrote:
 On Sun, Jul 29, 2012 at 1:04 PM, Marek Olšák mar...@gmail.com wrote:
 If we don't need stencil, don't allocate it.
 If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.

 v2: actually do it correctly

 Big NAK

 We need to allocate stencil and depth no matter what. Otherwise it
 will lockup. You can take a look by poisonning the surface and see
 that when stencil is disabled or depth is disabled the hw still write
 to it.

:)

If what you say is true, then we're in a big trouble. Regardless of
this patch, we're in it right now, because we cannot fully disable
depth or stencil if the user binds a NULL zbuffer. That's clearly the
kind of issue that cannot be fixed in the allocator code and should be
fixed in r600g where the hardware is programmed.

I *think* that the correct way to disable Z or stencil is to set the
Z_INVALID or STENCIL_INVALID format, respectively, and not by
disabling reads and writes. (cc'ing Alex to confirm that if he can). I
don't think the hardware designers have added those invalid formats
just for the lulz. Please see my latest kernel patch drm/radeon/kms:
allow invalid DB formats as a means to disable DB that tries to
address this issue.

For r600g, I was thinking of allocating a dummy buffer that will be
always bound in case the depth or stencil buffer or both are missing.
Either way, we should find how to get around this issue without
wasting memory, especially when there are other options to try.

BTW, before we used this allocator, we allocated the depth and stencil
buffers in separate resources. We might need to get back to it in the
future if Gallium grows separate depth and stencil buffer bindings.

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

Re: [PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Alex Deucher]

On Mon, Jul 30, 2012 at 11:48 AM, Marek Olšák mar...@gmail.com wrote:
 On Mon, Jul 30, 2012 at 4:56 PM, Jerome Glisse j.gli...@gmail.com wrote:
 On Sun, Jul 29, 2012 at 1:04 PM, Marek Olšák mar...@gmail.com wrote:
 If we don't need stencil, don't allocate it.
 If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.

 v2: actually do it correctly

 Big NAK

 We need to allocate stencil and depth no matter what. Otherwise it
 will lockup. You can take a look by poisonning the surface and see
 that when stencil is disabled or depth is disabled the hw still write
 to it.

 :)

 If what you say is true, then we're in a big trouble. Regardless of
 this patch, we're in it right now, because we cannot fully disable
 depth or stencil if the user binds a NULL zbuffer. That's clearly the
 kind of issue that cannot be fixed in the allocator code and should be
 fixed in r600g where the hardware is programmed.

 I *think* that the correct way to disable Z or stencil is to set the
 Z_INVALID or STENCIL_INVALID format, respectively, and not by
 disabling reads and writes. (cc'ing Alex to confirm that if he can). I
 don't think the hardware designers have added those invalid formats
 just for the lulz. Please see my latest kernel patch drm/radeon/kms:
 allow invalid DB formats as a means to disable DB that tries to
 address this issue.

That is correct.  I just verified with the hw team.  If you allocate
both buffers there are some restrictions in that they share tiling
parameters, but you can set either buffer to _INVALID and allocate one
or the other independently.

Alex


 For r600g, I was thinking of allocating a dummy buffer that will be
 always bound in case the depth or stencil buffer or both are missing.
 Either way, we should find how to get around this issue without
 wasting memory, especially when there are other options to try.

 BTW, before we used this allocator, we allocated the depth and stencil
 buffers in separate resources. We might need to get back to it in the
 future if Gallium grows separate depth and stencil buffer bindings.

 Marek
 ___
 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 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Alex Deucher]

On Mon, Jul 30, 2012 at 12:03 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Mon, Jul 30, 2012 at 11:48 AM, Marek Olšák mar...@gmail.com wrote:
 On Mon, Jul 30, 2012 at 4:56 PM, Jerome Glisse j.gli...@gmail.com wrote:
 On Sun, Jul 29, 2012 at 1:04 PM, Marek Olšák mar...@gmail.com wrote:
 If we don't need stencil, don't allocate it.
 If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.

 v2: actually do it correctly

 Big NAK

 We need to allocate stencil and depth no matter what. Otherwise it
 will lockup. You can take a look by poisonning the surface and see
 that when stencil is disabled or depth is disabled the hw still write
 to it.

 :)

 If what you say is true, then we're in a big trouble. Regardless of
 this patch, we're in it right now, because we cannot fully disable
 depth or stencil if the user binds a NULL zbuffer. That's clearly the
 kind of issue that cannot be fixed in the allocator code and should be
 fixed in r600g where the hardware is programmed.

 I *think* that the correct way to disable Z or stencil is to set the
 Z_INVALID or STENCIL_INVALID format, respectively, and not by
 disabling reads and writes. (cc'ing Alex to confirm that if he can). I
 don't think the hardware designers have added those invalid formats
 just for the lulz. Please see my latest kernel patch drm/radeon/kms:
 allow invalid DB formats as a means to disable DB that tries to
 address this issue.

 That is correct.  I just verified with the hw team.  If you allocate
 both buffers there are some restrictions in that they share tiling
 parameters, but you can set either buffer to _INVALID and allocate one
 or the other independently.

Some further clarifications from the hw team.  If you want to have
truly independent z and stencil buffers that allows for mixing and
matching, you need to make sure that any z and stencil buffer that can
be bound together must share the same addressing parameters (except
tile split), and you must disable the htile buffer on evergreen and
before (DB_Z_INFO.TILE_SURFACE_ENABLE=0) or disable the htile buffer
for stencil on cayman and newer
(DB_STENCIL_INFO.TILE_STENCIL_DISABLE=1).  If you are only interested
in unbinding z or stencil independently (but not mixing and matching)
then you don't need to the above restrictions on the htile buffer.
You can do so by setting the format to INVALID.

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

Re: Massive power regression going 3.4-3.5

[Keith Packard]

James Bottomley james.bottom...@hansenpartnership.com writes:

 OK, I've run the bisect as far as I can.  It looks to be in the drm
 tree.  Unfortunately, this tree has several merge points, some of which
 go further back than v3.4.  Unfortunately, once the bisect steps back
 before 3.4, we lose the changes that gave us the power savings, making
 further debugging impossible

What machine is this on? There are a few 'disable some power savings'
patches in that list to work around issues on various machines; knowing
what machine you're using can isolate which ones might have had some
effect on power usage...

-- 
keith.pack...@intel.com


pgpWOXaC1yMK4.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Jerome Glisse]

On Mon, Jul 30, 2012 at 12:16 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Mon, Jul 30, 2012 at 12:03 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Mon, Jul 30, 2012 at 11:48 AM, Marek Olšák mar...@gmail.com wrote:
 On Mon, Jul 30, 2012 at 4:56 PM, Jerome Glisse j.gli...@gmail.com wrote:
 On Sun, Jul 29, 2012 at 1:04 PM, Marek Olšák mar...@gmail.com wrote:
 If we don't need stencil, don't allocate it.
 If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.

 v2: actually do it correctly

 Big NAK

 We need to allocate stencil and depth no matter what. Otherwise it
 will lockup. You can take a look by poisonning the surface and see
 that when stencil is disabled or depth is disabled the hw still write
 to it.

 :)

 If what you say is true, then we're in a big trouble. Regardless of
 this patch, we're in it right now, because we cannot fully disable
 depth or stencil if the user binds a NULL zbuffer. That's clearly the
 kind of issue that cannot be fixed in the allocator code and should be
 fixed in r600g where the hardware is programmed.

 I *think* that the correct way to disable Z or stencil is to set the
 Z_INVALID or STENCIL_INVALID format, respectively, and not by
 disabling reads and writes. (cc'ing Alex to confirm that if he can). I
 don't think the hardware designers have added those invalid formats
 just for the lulz. Please see my latest kernel patch drm/radeon/kms:
 allow invalid DB formats as a means to disable DB that tries to
 address this issue.

 That is correct.  I just verified with the hw team.  If you allocate
 both buffers there are some restrictions in that they share tiling
 parameters, but you can set either buffer to _INVALID and allocate one
 or the other independently.

 Some further clarifications from the hw team.  If you want to have
 truly independent z and stencil buffers that allows for mixing and
 matching, you need to make sure that any z and stencil buffer that can
 be bound together must share the same addressing parameters (except
 tile split), and you must disable the htile buffer on evergreen and
 before (DB_Z_INFO.TILE_SURFACE_ENABLE=0) or disable the htile buffer
 for stencil on cayman and newer
 (DB_STENCIL_INFO.TILE_STENCIL_DISABLE=1).  If you are only interested
 in unbinding z or stencil independently (but not mixing and matching)
 then you don't need to the above restrictions on the htile buffer.
 You can do so by setting the format to INVALID.

 Alex

Well somehow i can't reproduce might have been fixed by something like
render backend fix. I should have write down how i saw this back in
the day.

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

Re: [PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Alex Deucher]

On Mon, Jul 30, 2012 at 12:52 PM, Jerome Glisse j.gli...@gmail.com wrote:
 On Mon, Jul 30, 2012 at 12:16 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Mon, Jul 30, 2012 at 12:03 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Mon, Jul 30, 2012 at 11:48 AM, Marek Olšák mar...@gmail.com wrote:
 On Mon, Jul 30, 2012 at 4:56 PM, Jerome Glisse j.gli...@gmail.com wrote:
 On Sun, Jul 29, 2012 at 1:04 PM, Marek Olšák mar...@gmail.com wrote:
 If we don't need stencil, don't allocate it.
 If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth.

 v2: actually do it correctly

 Big NAK

 We need to allocate stencil and depth no matter what. Otherwise it
 will lockup. You can take a look by poisonning the surface and see
 that when stencil is disabled or depth is disabled the hw still write
 to it.

 :)

 If what you say is true, then we're in a big trouble. Regardless of
 this patch, we're in it right now, because we cannot fully disable
 depth or stencil if the user binds a NULL zbuffer. That's clearly the
 kind of issue that cannot be fixed in the allocator code and should be
 fixed in r600g where the hardware is programmed.

 I *think* that the correct way to disable Z or stencil is to set the
 Z_INVALID or STENCIL_INVALID format, respectively, and not by
 disabling reads and writes. (cc'ing Alex to confirm that if he can). I
 don't think the hardware designers have added those invalid formats
 just for the lulz. Please see my latest kernel patch drm/radeon/kms:
 allow invalid DB formats as a means to disable DB that tries to
 address this issue.

 That is correct.  I just verified with the hw team.  If you allocate
 both buffers there are some restrictions in that they share tiling
 parameters, but you can set either buffer to _INVALID and allocate one
 or the other independently.

 Some further clarifications from the hw team.  If you want to have
 truly independent z and stencil buffers that allows for mixing and
 matching, you need to make sure that any z and stencil buffer that can
 be bound together must share the same addressing parameters (except
 tile split), and you must disable the htile buffer on evergreen and
 before (DB_Z_INFO.TILE_SURFACE_ENABLE=0) or disable the htile buffer
 for stencil on cayman and newer
 (DB_STENCIL_INFO.TILE_STENCIL_DISABLE=1).  If you are only interested
 in unbinding z or stencil independently (but not mixing and matching)
 then you don't need to the above restrictions on the htile buffer.
 You can do so by setting the format to INVALID.

 Alex

 Well somehow i can't reproduce might have been fixed by something like
 render backend fix. I should have write down how i saw this back in
 the day.

I think it was related to tiling.  I remember you mentioning something
about that at the time.

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

Re: Massive power regression going 3.4-3.5

[James Bottomley]

On Mon, 2012-07-30 at 09:33 -0700, Keith Packard wrote:
 James Bottomley james.bottom...@hansenpartnership.com writes:
 
  OK, I've run the bisect as far as I can.  It looks to be in the drm
  tree.  Unfortunately, this tree has several merge points, some of which
  go further back than v3.4.  Unfortunately, once the bisect steps back
  before 3.4, we lose the changes that gave us the power savings, making
  further debugging impossible
 
 What machine is this on? There are a few 'disable some power savings'
 patches in that list to work around issues on various machines; knowing
 what machine you're using can isolate which ones might have had some
 effect on power usage...

Lenovo X220i

The display device is

00:02.0 VGA compatible controller: Intel Corporation
82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03)
(prog-if 00 [VGA controller])
Subsystem: Giga-byte Technology Device 2562
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at e000 (32-bit, prefetchable) [size=128M]
Memory at e820 (32-bit, non-prefetchable) [size=512K]
Expansion ROM at unassigned [disabled]
Capabilities: access denied
Kernel driver in use: i915


James



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

Re: [PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

[Jerome Glisse]

On Mon, Jul 30, 2012 at 1:03 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Mon, Jul 30, 2012 at 12:52 PM, Jerome Glisse j.gli...@gmail.com wrote:
 On Mon, Jul 30, 2012 at 12:16 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Mon, Jul 30, 2012 at 12:03 PM, Alex Deucher alexdeuc...@gmail.com 
 wrote:
 On Mon, Jul 30, 2012 at 11:48 AM, Marek Olšák mar...@gmail.com wrote:
 On Mon, Jul 30, 2012 at 4:56 PM, Jerome Glisse j.gli...@gmail.com wrote:
 On Sun, Jul 29, 2012 at 1:04 PM, Marek Olšák mar...@gmail.com wrote:
 If we don't need stencil, don't allocate it.
 If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate 
 depth.

 v2: actually do it correctly

 Big NAK

 We need to allocate stencil and depth no matter what. Otherwise it
 will lockup. You can take a look by poisonning the surface and see
 that when stencil is disabled or depth is disabled the hw still write
 to it.

 :)

 If what you say is true, then we're in a big trouble. Regardless of
 this patch, we're in it right now, because we cannot fully disable
 depth or stencil if the user binds a NULL zbuffer. That's clearly the
 kind of issue that cannot be fixed in the allocator code and should be
 fixed in r600g where the hardware is programmed.

 I *think* that the correct way to disable Z or stencil is to set the
 Z_INVALID or STENCIL_INVALID format, respectively, and not by
 disabling reads and writes. (cc'ing Alex to confirm that if he can). I
 don't think the hardware designers have added those invalid formats
 just for the lulz. Please see my latest kernel patch drm/radeon/kms:
 allow invalid DB formats as a means to disable DB that tries to
 address this issue.

 That is correct.  I just verified with the hw team.  If you allocate
 both buffers there are some restrictions in that they share tiling
 parameters, but you can set either buffer to _INVALID and allocate one
 or the other independently.

 Some further clarifications from the hw team.  If you want to have
 truly independent z and stencil buffers that allows for mixing and
 matching, you need to make sure that any z and stencil buffer that can
 be bound together must share the same addressing parameters (except
 tile split), and you must disable the htile buffer on evergreen and
 before (DB_Z_INFO.TILE_SURFACE_ENABLE=0) or disable the htile buffer
 for stencil on cayman and newer
 (DB_STENCIL_INFO.TILE_STENCIL_DISABLE=1).  If you are only interested
 in unbinding z or stencil independently (but not mixing and matching)
 then you don't need to the above restrictions on the htile buffer.
 You can do so by setting the format to INVALID.

 Alex

 Well somehow i can't reproduce might have been fixed by something like
 render backend fix. I should have write down how i saw this back in
 the day.

 I think it was related to tiling.  I remember you mentioning something
 about that at the time.

 Alex

Yeah might be tiling related, surface allocator probably got the bo size right.

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

Re: Massive power regression going 3.4-3.5

[Keith Packard]

James Bottomley james.bottom...@hansenpartnership.com writes:

 On Mon, 2012-07-30 at 09:33 -0700, Keith Packard wrote:
 James Bottomley james.bottom...@hansenpartnership.com writes:
 
  OK, I've run the bisect as far as I can.  It looks to be in the drm
  tree.  Unfortunately, this tree has several merge points, some of which
  go further back than v3.4.  Unfortunately, once the bisect steps back
  before 3.4, we lose the changes that gave us the power savings, making
  further debugging impossible
 
 What machine is this on? There are a few 'disable some power savings'
 patches in that list to work around issues on various machines; knowing
 what machine you're using can isolate which ones might have had some
 effect on power usage...

 Lenovo X220i

I don't see a whole lot of context from the elided email bits you'd sent
previously; can you summarize the issue in terms of how much power
savings you're losing, how you're measuring it and what's going on in
the system when the power savings is different?

Have you tried measuring power with X not running? How about with
compositing and other desktop effects disabled? 

-- 
keith.pack...@intel.com


pgpKdtR1O3JKf.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Massive power regression going 3.4-3.5

[Adam Jackson]

On 7/30/12 1:05 PM, James Bottomley wrote:


Lenovo X220i

The display device is

00:02.0 VGA compatible controller: Intel Corporation
82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03)
(prog-if 00 [VGA controller])
 Subsystem: Giga-byte Technology Device 2562
 Flags: bus master, fast devsel, latency 0, IRQ 16
 Memory at e000 (32-bit, prefetchable) [size=128M]
 Memory at e820 (32-bit, non-prefetchable) [size=512K]
 Expansion ROM at unassigned [disabled]
 Capabilities: access denied
 Kernel driver in use: i915


What in the world?  That's an _ancient_ chip, I wouldn't expect to see 
it in a laptop that new.  I would have assumed X220i to be a Sandybridge 
like X220.


For that matter when the 845 was current Lenovo wasn't the one making 
ThinkPads.


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