date:20121016

[git pull] drm fixes

2012-10-16 Thread Dave Airlie


Hi Linus,

fixes for i915, nouveau and radeon

i915: haswell stability, modeset rework fallout, ums fix
nouveau: misc fixes from code rework
radeon: pll rework fixes, more 2 level PTE cleanups.
core: warning fixes on 32-bit.

Dave.

The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:

  Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)

are available in the git repository at:

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

for you to fetch changes up to 8a00b6af4cc547725f231c8367ddc7cb56b2cf76:

  nouveau: fix warning on 32-bit build. (2012-10-16 16:40:53 +1000)


Alex Deucher (5):
  drm/radeon: fix compilation with backlight disabled
  drm/radeon: allocate PPLLs from low to high
  drm/radeon: update comments to clarify VM setup (v2)
  drm/radeon/cayman: set VM max pfn at MC init
  drm/radeon: check if pcie gen 2 is already enabled (v2)

Ben Skeggs (1):
  drm/nouveau/bios: fix typo in error message

Chris Wilson (2):
  drm/i915: Disallow preallocation of requests
  drm/i915: fixup i915_gem_object_get_page inline helper

Christian König (3):
  drm/radeon: allocate page tables on demand v4
  drm/radeon: don't add the IB pool to all VMs v2
  drm/radeon: separate pt alloc from lru add

Daniel Vetter (5):
  drm/i915: paper over a pipe-enable vs pageflip race
  drm/i915: disable wc gtt pte mappings on gen2
  drm/i915: rip out the pipe A quirk for i855gm
  drm/i915: fixup the plane-pipe fixup code
  drm/i915/dvo-ch7xxx: fix get_hw_state

Dave Airlie (5):
  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
  Merge branch 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  drm: fix warning on 32-bit.
  Merge branch 'drm-nouveau-fixes' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
  nouveau: fix warning on 32-bit build.

Egbert Eich (1):
  drm/radeon: Don't destroy I2C Bus Rec in radeon_ext_tmds_enc_destroy().

Jani Nikula (1):
  drm/i915: fix non-DP-D eDP backlight cleanup and module reload

Kenneth Graunke (1):
  drm/i915: Set guardband clipping workaround bit in the right register.

Luca Tettamanti (1):
  drm/radeon: use %zu for formatting size_t

Marcin Slusarz (1):
  drm/nv50/fb: fix double free of vram mm

Martin Peres (3):
  drm/nouveau/hwmon: fix the initialization condition
  drm/nouveau/pm: fix a typo related to the move to the therm subdev
  drm/nouveau/pm: do not stop reclocking if failing to set the fan speed

Max Filippov (1):
  drm/nouveau: only call ttm_agp_tt_create when __OS_HAS_AGP

Randy Dunlap (1):
  drm: radeon: fix printk format warning

Rodrigo Vivi (1):
  drm/i915: HSW CRW stability magic

Thomas Friebel (1):
  drm/radeon: fix spelling typos in debugging output

Willy Tarreau (1):
  drm/i915: remove useless BUG_ON which caused a regression in 3.5.

 drivers/char/agp/intel-gtt.c|2 +-
 drivers/gpu/drm/drm_info.c  |2 +-
 drivers/gpu/drm/i915/dvo_ch7xxx.c   |6 +-
 drivers/gpu/drm/i915/i915_drv.h |9 +-
 drivers/gpu/drm/i915/i915_gem.c |   19 +-
 drivers/gpu/drm/i915/i915_reg.h |2 +-
 drivers/gpu/drm/i915/intel_display.c|   47 ++-
 drivers/gpu/drm/i915/intel_dp.c |3 +-
 drivers/gpu/drm/i915/intel_overlay.c|   72 +
 drivers/gpu/drm/i915/intel_pm.c |4 +-
 drivers/gpu/drm/nouveau/core/subdev/bios/dcb.c  |2 +-
 drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c   |1 -
 drivers/gpu/drm/nouveau/core/subdev/therm/fan.c |2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c|2 +
 drivers/gpu/drm/nouveau/nouveau_pm.c|6 +-
 drivers/gpu/drm/radeon/atombios_crtc.c  |8 +-
 drivers/gpu/drm/radeon/evergreen.c  |7 +-
 drivers/gpu/drm/radeon/ni.c |   12 +-
 drivers/gpu/drm/radeon/r600.c   |6 +
 drivers/gpu/drm/radeon/radeon.h |   14 +-
 drivers/gpu/drm/radeon/radeon_acpi.c|6 +-
 drivers/gpu/drm/radeon/radeon_atpx_handler.c|2 +-
 drivers/gpu/drm/radeon/radeon_cs.c  |1 +
 drivers/gpu/drm/radeon/radeon_device.c  |4 +
 drivers/gpu/drm/radeon/radeon_gart.c|  374 ---
 drivers/gpu/drm/radeon/radeon_kms.c |   22 +-
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |   48 ++-
 drivers/gpu/drm/radeon/radeon_ring.c|2 +-
 drivers/gpu/drm/radeon/si.c |7 +-
 29 files changed, 443 insertions(+), 249 deletions(-)___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] radeon: fix tile_split of 128-bit surface formats with 8x MSAA

2012-10-16 Thread Paul Menzel

Dear Marek,


Am Dienstag, den 16.10.2012, 02:21 +0200 schrieb Marek Olšák:
 The calculation led to the number 8192, which is too high.

what is the reason it is limited to 4096? Hardware limitation?

What are the ramifications? GPU hangs, rendering errors?

 ---
  radeon/radeon_surface.c |2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
 index 66c2444..eb587d2 100644
 --- a/radeon/radeon_surface.c
 +++ b/radeon/radeon_surface.c
 @@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager 
 *surf_man,
  } else {
  /* tile split must be = 256 for colorbuffer surfaces */
  surf-tile_split = MAX2(surf-nsamples * surf-bpe * 64, 256);
 +if (surf-tile_split  4096)
 +surf-tile_split = 4096;
  }
  } else {
  /* set tile split to row size */


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm-intel:drm-intel-next-queued 42/44] drivers/gpu/drm/i915/intel_pm.c:2506:2: error: 'ret' undeclared

2012-10-16 Thread Daniel Vetter

On Tue, Oct 16, 2012 at 08:59:51AM +0800, Fengguang Wu wrote:
 Hi Ben,
 
 FYI, kernel build failed on
 
 tree:   git://people.freedesktop.org/~danvet/drm-intel.git 
 drm-intel-next-queued
 head:   861b675336a1f686f480d92990251e99a3ec0956
 commit: 686279dbcbc69f71ce86efdccaa8cad762cba2ea [42/44] drm/i915: Extract 
 PCU communication
 config: x86_64-allyesconfig # make ARCH=x86_64 allyesconfig
 
 All error/warnings:
 
 drivers/gpu/drm/i915/intel_pm.c: In function 'gen6_enable_rps':
 drivers/gpu/drm/i915/intel_pm.c:2506:2: error: 'ret' undeclared (first use in 
 this function)
 drivers/gpu/drm/i915/intel_pm.c:2506:2: note: each undeclared identifier is 
 reported only once for each function it appears in
 
 vim +2506 drivers/gpu/drm/i915/intel_pm.c
 
 89ba829e Jesse Barnes   2012-05-22  2500 
 GEN6_RP_MEDIA_HW_NORMAL_MODE |
 2b4e57bd Eugeni Dodonov 2012-04-18  2501 GEN6_RP_MEDIA_IS_GFX 
 |
 2b4e57bd Eugeni Dodonov 2012-04-18  2502 GEN6_RP_ENABLE |
 2b4e57bd Eugeni Dodonov 2012-04-18  2503 GEN6_RP_UP_BUSY_AVG |
 5a7dc92a Eugeni Dodonov 2012-07-02  2504 (IS_HASWELL(dev) ? 
 GEN7_RP_DOWN_IDLE_AVG : GEN6_RP_DOWN_IDLE_CONT));
 2b4e57bd Eugeni Dodonov 2012-04-18  2505  
 686279db Ben Widawsky   2012-09-26 @2506  ret = 
 sandybridge_pcode_write(dev_priv, GEN6_PCODE_WRITE_MIN_FREQ_TABLE, 0);
 686279db Ben Widawsky   2012-09-26  2507  if (!ret) {
 686279db Ben Widawsky   2012-09-26  2508  pcu_mbox = 0;
 686279db Ben Widawsky   2012-09-26  2509  ret = 
 sandybridge_pcode_read(dev_priv, GEN6_READ_OC_PARAMS, pcu_mbox);

Fixed up, thanks a lot for the report.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: fix PFP sync in vm_flush

2012-10-16 Thread Christian König

Otherwise the next IB might start reading commands
with the page table still invalid.

Signed-off-by: Christian König deathsim...@vodafone.de
---
 drivers/gpu/drm/radeon/ni.c  |4 
 drivers/gpu/drm/radeon/nid.h |1 +
 drivers/gpu/drm/radeon/si.c  |4 
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 8c74c72..19b7fe1 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1586,4 +1586,8 @@ void cayman_vm_flush(struct radeon_device *rdev, int 
ridx, struct radeon_vm *vm)
/* bits 0-7 are the VM contexts0-7 */
radeon_ring_write(ring, PACKET0(VM_INVALIDATE_REQUEST, 0));
radeon_ring_write(ring, 1  vm-id);
+
+   /* sync PFP to ME, otherwise we might get invalid PFP reads */
+   radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0));
+   radeon_ring_write(ring, 0x0);
 }
diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
index 2423d1b..cbef681 100644
--- a/drivers/gpu/drm/radeon/nid.h
+++ b/drivers/gpu/drm/radeon/nid.h
@@ -502,6 +502,7 @@
 #definePACKET3_MPEG_INDEX  0x3A
 #definePACKET3_WAIT_REG_MEM0x3C
 #definePACKET3_MEM_WRITE   0x3D
+#definePACKET3_PFP_SYNC_ME 0x42
 #definePACKET3_SURFACE_SYNC0x43
 #  define PACKET3_CB0_DEST_BASE_ENA(1  6)
 #  define PACKET3_CB1_DEST_BASE_ENA(1  7)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index df8dd77..da184de 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2868,6 +2868,10 @@ void si_vm_flush(struct radeon_device *rdev, int ridx, 
struct radeon_vm *vm)
radeon_ring_write(ring, VM_INVALIDATE_REQUEST  2);
radeon_ring_write(ring, 0);
radeon_ring_write(ring, 1  vm-id);
+
+   /* sync PFP to ME, otherwise we might get invalid PFP reads */
+   radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0));
+   radeon_ring_write(ring, 0x0);
 }
 
 /*
-- 
1.7.9.5

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

Re: [PATCHv10 23/26] v4l: vb2-dma-contig: align buffer size to PAGE_SIZE

2012-10-16 Thread Laurent Pinchart

Hi Tomasz,

On Friday 12 October 2012 10:24:34 Tomasz Stanislawski wrote:
 On 10/11/2012 11:31 PM, Laurent Pinchart wrote:
  On Wednesday 10 October 2012 16:46:42 Tomasz Stanislawski wrote:
  Most operations on DMA and DMABUF framework need page
  aligned buffers.
  
  The comment is a bit misleading, the buffer is already page-aligned
  (unless I'm mistaken dma_alloc_coherent() returns a page-aligned buffer)
  but its size isn't a multiple of the page size.
 
 Ok. I will update the commit message that only buffer size is going to be
 page aligned.

  Do we really need a page size multiple ? Isn't it enough to make the size
  a multiple of the cache line size ?
 
 Frankly, I strongly oppose forcing a size of a DMA buffer to be rounded up.
 
 However, I discovered a problem while testing mmap() interface in dma-buf.
 The test in dma_buf_mmap() will fail if the size is not a multiple of 4k.
 
 Maybe the value from dma-buf.c:456 should be changed from:
 
 dmabuf-size  PAGE_SHIFT
 
 to
 
 PAGE_ALIGN(dmabuf-size)  PAGE_SHIFT
 
 However, I preferred to avoid any changes outside of the media tree hoping
 that the patchset gets merged. Rounding the buffer size to a page size was
 quick workaround for the issue with DMABUF mmap().

After some more thoughts I'm not sure whether this patch does the right thing. 
We have two sizes that we neeed to care about, the user usable buffer size and 
the allocated memory size.

When a user of a buffer requests buffer allocation with an explicit or 
implicit size we might need to allocate a larger buffer to fulfill usage 
requirements. We can thus end up with an allocated memory size larger than 
what the user requested. Such usage requirements include

- DMA and CPU access: when accessing the buffer both through DMA and directly 
by the CPU cache management comes into play, and the buffer address and size 
then need to be aligned to a cache line size boundary.

- Mapping to userspace: we can only map complete pages to userspace, the 
buffer address and size need to be aligned to a page size boundary to make 
sure that we won't leak unrelated data to userspace.

As the cache line size is smaller than a page fulfilling the second 
requirement always fulfills the first. There might be other requirements that 
escape my mind right now.

As we don't precisely know at allocation time how the buffer will be used (for 
instance whether it will eventually be mapped to userspace or not), we have 
two options:

- Align the buffer size to a page size boundary unconditionally.

- Let the user handle that requirement by specifying an allocation size 
aligned to a page size boundary.

Given the complexity associated with the second solution and the very small, 
if not inexistent, expected memory gain (when using the DMA allocation APIs we 
always get complete pages anyway, so there would be no gain in not aligning 
the allocation size to a page size boundary), I think the first solution 
should be preferred.

This leaves us with two questions related to buffer size: what size (between 
the requested size and the actually allocated size) do we report back to the 
user (in the v4l2_buffer length field for instance), and what size do we 
report to the dma-buf core (and thus to the other subsystems and other buffer 
users) ?

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 1/2] uapi: update includes for drm content when no kernel API exists

2012-10-16 Thread Laurent Pinchart

Hi Luis,

On Saturday 13 October 2012 10:00:42 Luis R. Rodriguez wrote:
 On Sat, Oct 13, 2012 at 3:33 AM, Laurent Pinchart wrote:
  On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote:
  From: Luis R. Rodriguez mcg...@do-not-panic.com
  
  The UAPI changes split kernel API and userspace API
  content onto two separate header files. The userspace
  API drm content was moved to include/uapi/drm/ with the
  same file name while kernel specific API content was
  kept under include/drm/ with the same file name. When
  one file was split into two files the kernel header
  includes the uapi header and a UAPI prefix was added to
  the uapi header for its header guard. When there was no
  kernel API content found the uapi header file was the
  only one that was kept and the original guard for the
  header file was kept. In this particular case the
  original users of this header file were not modified
  and the uapi header file is expected to be picked up
  by path.
  
  This may work well at compilation on the kernel but when
  backporting this creates a few complexities.
  
  Could you please provide more details about those complexities ?
 
 Sure, the backported DRM code is as-is code from linux-next. The
 header search path includes a copy of a few select header files from
 linux-next, the rest are part of the compat [0] project to help with
 backporting and the last set are from your own kernel. In this
 particular case the UAPI effort pushed into include/uapi/drm a few
 files which are now no longer present in the old include/drm/ location
 when there was no respective kernel-only APIs exposed. For DRM code
 that did not use the new uapi/drm/ path for old header includes this
 means that upon backporting the older kernel's header file would be
 used obviously leading to a series of compilation failures. By being
 explicit about the path, as was done with a few other header files, we
 can suck out DRM code intact from the kernel to be compilable for
 older kernels. As of the v3.7-rc1 the compat-drivers project [1] will
 be providing DRM modules. The new UAPI changes broke compilation on
 compat-drivers when compiling DRM code so to fix this we either patch
 code taken from the Linux kernel as I have done, force inclusion of a
 few specific headers files, or use include_next tricks. It turns out
 that forcing inclusion of -I$(M)/include/uapi as a path search prior
 to your own kernel's at compilation time did not help.

Shouldn't that be added as a search path *after* include/linux/ instead of 
before ?

 The include_next trick can work as well but that'd mean synching the UAPI
 files regularly into compat. I'd much prefer to have code intact when
 possible when backporting so the option I stuck with then was to patch
 the code directly and then as part of compat-drivers to always copy
 that day's linux-next UAPI headers into the current directory for
 compilation. I see no other driver code using the uapi path explicitly
 though, is that by design?

As far as I understand that's by design, yes. Kernel code isn't expected to 
reference uapi/ headers directly.

 Would it be wrong to be explicit about using a UAPI header alone if no
 kernel API files exist?

I personally don't really like including such features in a mainline just 
for backporting, especially when they go against the spirit of the 
architecture (the uapi/ split design principles in this case). The way we're 
dealing with this in the V4L backport tree 
(http://git.linuxtv.org/media_build.git) is to play with Makefiles, include 
compatibility headers and, if nothing else can work, maintain backport patches 
for mainline code.

 [0] https://backports.wiki.kernel.org/index.php/Documentation/compat
 [1] https://backports.wiki.kernel.org/

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] drm/radeon: fix PFP sync in vm_flush

2012-10-16 Thread Alex Deucher

On Tue, Oct 16, 2012 at 5:02 AM, Christian König
deathsim...@vodafone.de wrote:
 Otherwise the next IB might start reading commands
 with the page table still invalid.

 Signed-off-by: Christian König deathsim...@vodafone.de

Looks good to me.  I'll add it to my -fixes queue.

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  drivers/gpu/drm/radeon/ni.c  |4 
  drivers/gpu/drm/radeon/nid.h |1 +
  drivers/gpu/drm/radeon/si.c  |4 
  3 files changed, 9 insertions(+)

 diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
 index 8c74c72..19b7fe1 100644
 --- a/drivers/gpu/drm/radeon/ni.c
 +++ b/drivers/gpu/drm/radeon/ni.c
 @@ -1586,4 +1586,8 @@ void cayman_vm_flush(struct radeon_device *rdev, int 
 ridx, struct radeon_vm *vm)
 /* bits 0-7 are the VM contexts0-7 */
 radeon_ring_write(ring, PACKET0(VM_INVALIDATE_REQUEST, 0));
 radeon_ring_write(ring, 1  vm-id);
 +
 +   /* sync PFP to ME, otherwise we might get invalid PFP reads */
 +   radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0));
 +   radeon_ring_write(ring, 0x0);
  }
 diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
 index 2423d1b..cbef681 100644
 --- a/drivers/gpu/drm/radeon/nid.h
 +++ b/drivers/gpu/drm/radeon/nid.h
 @@ -502,6 +502,7 @@
  #definePACKET3_MPEG_INDEX  0x3A
  #definePACKET3_WAIT_REG_MEM0x3C
  #definePACKET3_MEM_WRITE   0x3D
 +#definePACKET3_PFP_SYNC_ME 0x42
  #definePACKET3_SURFACE_SYNC0x43
  #  define PACKET3_CB0_DEST_BASE_ENA(1  6)
  #  define PACKET3_CB1_DEST_BASE_ENA(1  7)
 diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
 index df8dd77..da184de 100644
 --- a/drivers/gpu/drm/radeon/si.c
 +++ b/drivers/gpu/drm/radeon/si.c
 @@ -2868,6 +2868,10 @@ void si_vm_flush(struct radeon_device *rdev, int ridx, 
 struct radeon_vm *vm)
 radeon_ring_write(ring, VM_INVALIDATE_REQUEST  2);
 radeon_ring_write(ring, 0);
 radeon_ring_write(ring, 1  vm-id);
 +
 +   /* sync PFP to ME, otherwise we might get invalid PFP reads */
 +   radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0));
 +   radeon_ring_write(ring, 0x0);
  }

  /*
 --
 1.7.9.5

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

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

2012-10-16 Thread bugzilla-daemon

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

--- Comment #16 from Helge Bahmann h...@chaoticmind.net ---
(In reply to comment #15)
 A patch referencing this bug report has been merged in Linux v3.7-rc1:
 
 commit bced76f27165ca7733437715185c3a1aa526f7a1
 Author: Alex Deucher alexander.deuc...@amd.com
 Date:   Fri Sep 14 09:45:50 2012 -0400
 
 drm/radeon: restore backlight level on resume

appears to be the same patch as mentioned in comment #10, and (at least for me)
still does not fix the issue

-- 
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] radeon: fix tile_split of 128-bit surface formats with 8x MSAA

2012-10-16 Thread Alex Deucher

On Tue, Oct 16, 2012 at 2:50 AM, Paul Menzel
paulepan...@users.sourceforge.net wrote:
 Dear Marek,


 Am Dienstag, den 16.10.2012, 02:21 +0200 schrieb Marek Olšák:
 The calculation led to the number 8192, which is too high.

 what is the reason it is limited to 4096? Hardware limitation?

hw limit.


 What are the ramifications? GPU hangs, rendering errors?


Rendering errors.

Alex


 ---
  radeon/radeon_surface.c |2 ++
  1 file changed, 2 insertions(+)

 diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
 index 66c2444..eb587d2 100644
 --- a/radeon/radeon_surface.c
 +++ b/radeon/radeon_surface.c
 @@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager 
 *surf_man,
  } else {
  /* tile split must be = 256 for colorbuffer surfaces */
  surf-tile_split = MAX2(surf-nsamples * surf-bpe * 64, 256);
 +if (surf-tile_split  4096)
 +surf-tile_split = 4096;
  }
  } else {
  /* set tile split to row size */


 Thanks,

 Paul

 ___
 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] radeon: fix tile_split of 128-bit surface formats with 8x MSAA

2012-10-16 Thread Alex Deucher

On Mon, Oct 15, 2012 at 8:21 PM, Marek Olšák mar...@gmail.com wrote:
 The calculation led to the number 8192, which is too high.

Looks good.

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  radeon/radeon_surface.c |2 ++
  1 file changed, 2 insertions(+)

 diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
 index 66c2444..eb587d2 100644
 --- a/radeon/radeon_surface.c
 +++ b/radeon/radeon_surface.c
 @@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager 
 *surf_man,
  } else {
  /* tile split must be = 256 for colorbuffer surfaces */
  surf-tile_split = MAX2(surf-nsamples * surf-bpe * 64, 256);
 +if (surf-tile_split  4096)
 +surf-tile_split = 4096;
  }
  } else {
  /* set tile split to row size */
 --
 1.7.9.5

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

Re: [PATCH 01/11] drm: add drm_send_vblank_event() helper

2012-10-16 Thread Laurent Pinchart

Hi Mario,

On Saturday 13 October 2012 02:28:03 Mario Kleiner wrote:
 On 11.10.12 16:19, Laurent Pinchart wrote:
  On Monday 08 October 2012 14:50:39 Rob Clark wrote:
  From: Rob Clark r...@ti.com
 
 ...
 
  Do you know why some drivers don't call drm_vblank_count_and_time() ? For
  instance nouveau sets the sequence to 0 and uses do_gettimeofday(), but it
  looks like it could just call drm_vblank_count_and_time().
 
 At least nouveau could use it. Lucas Stach and me wrote patches for
 nouveau-kms, and they went through many iterations and missed many
 kernel merge windows due to slow review until i think both of us got
 tired of resubmitting with tiny changes.

I totally understand the feeling, but please don't give up. You can CC me on 
the next iteration, I'll make sure to review the patches (even though I have 
no experience with the nouveau driver).

 The latest iteration is posted by Lucas on nouveau-devel from 26. April
 2012. Not sure if they'd still apply after the nouveau-kms rewrite. I'll
 probably give them another try once that has landed when i have some spare
 time.
 
 In principle it's very simple to use drm_vblank_count_and_time(). A
 driver needs to
 
 1. Call drm_handle_vblank() from its vblank irq handler.
 
 2. Make sure that in the vblank of pageflip completion
 drm_handle_vblank() is called before drm_vblank_count_and_time(), so the
 latter picks up updated counts and timestamps.
 
 3. Big bonus for high precision and robustness: Implement the
 driver-get_vblank_timestamp() hook to provide a precise vblank
 timestamp. One simple way to do that is like radeon-kms or intel-kms do
 it: Call back into drm_calc_vbltimestamp_from_scanoutpos() and provide
 the driver-get_scanout_position() function - a function that returns
 the current hardware scanline counter. This is precise down to ~ 10
 microseconds (at least confirmed by measurements on
 intel,radeon,nouveau) and robust against delayed vblank irq handling.
 
 -mario
-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] radeon: fix tile_split of 128-bit surface formats with 8x MSAA

2012-10-16 Thread Marek Olšák

In this specific case, the eg_surface_sanity function (or something
like that, I don't remember its name) returns an error. Then the
cascade of perfectly working fail codepaths propagate the error to the
OpenGL user as an unsupported framebuffer object setup.

Marek

On Tue, Oct 16, 2012 at 8:50 AM, Paul Menzel
paulepan...@users.sourceforge.net wrote:
 Dear Marek,


 Am Dienstag, den 16.10.2012, 02:21 +0200 schrieb Marek Olšák:
 The calculation led to the number 8192, which is too high.

 what is the reason it is limited to 4096? Hardware limitation?

 What are the ramifications? GPU hangs, rendering errors?

 ---
  radeon/radeon_surface.c |2 ++
  1 file changed, 2 insertions(+)

 diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
 index 66c2444..eb587d2 100644
 --- a/radeon/radeon_surface.c
 +++ b/radeon/radeon_surface.c
 @@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager 
 *surf_man,
  } else {
  /* tile split must be = 256 for colorbuffer surfaces */
  surf-tile_split = MAX2(surf-nsamples * surf-bpe * 64, 256);
 +if (surf-tile_split  4096)
 +surf-tile_split = 4096;
  }
  } else {
  /* set tile split to row size */


 Thanks,

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

Re: [PATCH 0/11] drm: add drm_send_vblank_event() helper (v4)

2012-10-16 Thread Laurent Pinchart

Hi Rob,

Thanks for the patch (0/11 looks a bit weird BTW).

On Friday 12 October 2012 18:57:12 Rob Clark wrote:
 From: Rob Clark r...@ti.com
 
 A helper that drivers can use to send vblank event after a pageflip.
 If the driver doesn't support proper vblank irq based time/seqn then
 just pass -1 for the pipe # to get do_gettimestamp() behavior (since
 there are a lot of drivers that don't use drm_vblank_count_and_time())
 
 Also an internal send_vblank_event() helper for the various other code
 paths within drm_irq that also need to send vblank events.
 
 v1: original
 v2: add back 'vblwait-reply.sequence = seq' which should not have
 been deleted
 v3: add WARN_ON() in case lock is not held and comments
 v4: use WARN_ON_SMP() instead to fix issue with !SMP  !DEBUG_SPINLOCK
 as pointed out by Marcin Slusarz
 
 Signed-off-by: Rob Clark r...@ti.com
 ---
  drivers/gpu/drm/drm_irq.c |   74 --
  include/drm/drmP.h|2 ++

Documentation/DocBook/drm.tmpl is missing ;-)

  2 files changed, 54 insertions(+), 22 deletions(-)

I still wish we could have found a way to call drm_vblank_count_and_time() and 
do_gettimeofday() outside of the spinlock-protected region, but I won't 
complain. Apart from the missing documentation update the patch looks OK to 
me.

-- 
Regards,

Laurent Pinchart

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

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-16 Thread bugzilla-daemon

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

--- Comment #23 from Christian König deathsim...@vodafone.de ---
Created attachment 68623
  -- https://bugs.freedesktop.org/attachment.cgi?id=68623action=edit
Test patch.

VM is definitely enabled, otherwise you won't got that error in the first
place.

Ok let's try to narrow down that bug a bit more, please apply the attached test
patch and see what happens.

If the GPU hang vanished we indeed have a syncing issue, but not the PFP sync.

-- 
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 3.7-rc1] nouveau cli-mutex possible recursive locking detected

2012-10-16 Thread Stanislaw Gruszka

I have this lockdep warning on wireless-testing tree based
on 3.7-rc1 (no other patches except wireless bits).

=
Restarting tasks ... done.
[ INFO: possible recursive locking detected ]
3.7.0-rc1-wl+ #2 Not tainted
-
Xorg/2269 is trying to acquire lock:
 (cli-mutex){+.+.+.}, at: [a012a27f] 
nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]

but task is already holding lock:
 (cli-mutex){+.+.+.}, at: [a012f3c4] nouveau_abi16_get+0x34/0x100 
[nouveau]

other info that might help us debug this:
 Possible unsafe locking scenario:

   CPU0
   
  lock(cli-mutex);
  lock(cli-mutex);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

1 lock held by Xorg/2269:
 #0:  (cli-mutex){+.+.+.}, at: [a012f3c4] 
nouveau_abi16_get+0x34/0x100 [nouveau]

stack backtrace:
Pid: 2269, comm: Xorg Not tainted 3.7.0-rc1-wl+ #2
Call Trace:
 [810bbc24] print_deadlock_bug+0xf4/0x100
 [810bdba9] validate_chain+0x549/0x7e0
 [810be1a7] __lock_acquire+0x367/0x580
 [a012a27f] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
 [810be464] lock_acquire+0xa4/0x120
 [a012a27f] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
 [8156c860] ? _raw_spin_unlock_irqrestore+0x40/0x80
 [81569217] __mutex_lock_common+0x47/0x3f0
 [a012a27f] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
 [a011dd61] ? nv84_graph_tlb_flush+0x291/0x2b0 [nouveau]
 [a00b4be6] ? _nouveau_gpuobj_wr32+0x26/0x30 [nouveau]
 [a012a27f] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
 [815696e7] mutex_lock_nested+0x37/0x50
 [a012a27f] nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
 [a012a783] nouveau_bo_move+0xe3/0x330 [nouveau]
 [a009619d] ttm_bo_handle_move_mem+0x2bd/0x670 [ttm]
 [a0098a1e] ttm_bo_move_buffer+0x12e/0x150 [ttm]
 [a0098ad9] ttm_bo_validate+0x99/0x130 [ttm]
 [a012add3] nouveau_bo_validate+0x23/0x30 [nouveau]
 [a012cd8e] validate_list+0xae/0x2c0 [nouveau]
 [a012dec2] nouveau_gem_pushbuf_validate+0xa2/0x1e0 [nouveau]
 [a012e22c] nouveau_gem_ioctl_pushbuf+0x22c/0x8a0 [nouveau]
 [a002c465] drm_ioctl+0x355/0x570 [drm]
 [8119349a] ? do_sync_read+0xaa/0xf0
 [a012e000] ? nouveau_gem_pushbuf_validate+0x1e0/0x1e0 [nouveau]
 [811a579c] do_vfs_ioctl+0x8c/0x350
 [81575745] ? sysret_check+0x22/0x5d
 [811a5b01] sys_ioctl+0xa1/0xb0
 [81291eee] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [81575719] system_call_fastpath+0x16/0x1b
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] uapi: update includes for drm content when no kernel API exists

2012-10-16 Thread Luis R. Rodriguez

On Tue, Oct 16, 2012 at 5:34 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Luis,

 On Saturday 13 October 2012 10:00:42 Luis R. Rodriguez wrote:
 On Sat, Oct 13, 2012 at 3:33 AM, Laurent Pinchart wrote:
  On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote:
  From: Luis R. Rodriguez mcg...@do-not-panic.com
 
  The UAPI changes split kernel API and userspace API
  content onto two separate header files. The userspace
  API drm content was moved to include/uapi/drm/ with the
  same file name while kernel specific API content was
  kept under include/drm/ with the same file name. When
  one file was split into two files the kernel header
  includes the uapi header and a UAPI prefix was added to
  the uapi header for its header guard. When there was no
  kernel API content found the uapi header file was the
  only one that was kept and the original guard for the
  header file was kept. In this particular case the
  original users of this header file were not modified
  and the uapi header file is expected to be picked up
  by path.
 
  This may work well at compilation on the kernel but when
  backporting this creates a few complexities.
 
  Could you please provide more details about those complexities ?

 Sure, the backported DRM code is as-is code from linux-next. The
 header search path includes a copy of a few select header files from
 linux-next, the rest are part of the compat [0] project to help with
 backporting and the last set are from your own kernel. In this
 particular case the UAPI effort pushed into include/uapi/drm a few
 files which are now no longer present in the old include/drm/ location
 when there was no respective kernel-only APIs exposed. For DRM code
 that did not use the new uapi/drm/ path for old header includes this
 means that upon backporting the older kernel's header file would be
 used obviously leading to a series of compilation failures. By being
 explicit about the path, as was done with a few other header files, we
 can suck out DRM code intact from the kernel to be compilable for
 older kernels. As of the v3.7-rc1 the compat-drivers project [1] will
 be providing DRM modules. The new UAPI changes broke compilation on
 compat-drivers when compiling DRM code so to fix this we either patch
 code taken from the Linux kernel as I have done, force inclusion of a
 few specific headers files, or use include_next tricks. It turns out
 that forcing inclusion of -I$(M)/include/uapi as a path search prior
 to your own kernel's at compilation time did not help.

 Shouldn't that be added as a search path *after* include/linux/ instead of
 before ?

Ah, therein lies the issue. If backporting no, if backporting you
should seek first for your current directory's include/drm/ dir and
then uapi, and then only later the older kernel's paths:

NOSTDINC_FLAGS := \
-I$(M)/include/ \
-I$(M)/include/drm \
-I$(M)/include/uapi \
-include $(M)/include/linux/compat-2.6.h \
$(CFLAGS)

 The include_next trick can work as well but that'd mean synching the UAPI
 files regularly into compat. I'd much prefer to have code intact when
 possible when backporting so the option I stuck with then was to patch
 the code directly and then as part of compat-drivers to always copy
 that day's linux-next UAPI headers into the current directory for
 compilation. I see no other driver code using the uapi path explicitly
 though, is that by design?

 As far as I understand that's by design, yes. Kernel code isn't expected to
 reference uapi/ headers directly.

Did the design consider the case where no respective kernel API header
file would ever exist?

 Would it be wrong to be explicit about using a UAPI header alone if no
 kernel API files exist?

 I personally don't really like including such features in a mainline just
 for backporting,

Sort of ditto. I haven't yet made a strong case for one particular
situation where this would help (but I will in the long run, see
blog), but this example should not be considered one. The patch itself
should be considered in terms of its merit for clarifying usage and
assumptions of uapi. The fact that I came up with it due to issues
when backporting is only secondary.

 especially when they go against the spirit of the
 architecture (the uapi/ split design principles in this case).

The patches, pull request, and even lwn article did not cover the
intent on architecture so if it was the design objective I'd like to
know how that is determined. From the looks of it, this as all
scripted and I do wonder if the case where no kernel API header file
existed was taken into consideration.

 The way we're
 dealing with this in the V4L backport tree
 (http://git.linuxtv.org/media_build.git) is to play with Makefiles, include
 compatibility headers and, if nothing else can work, maintain backport patches
 for mainline code.

Thanks for the heads up, I can certainly keep these patches as
external but when if I see something

Re: [PATCH 0/11] drm: add drm_send_vblank_event() helper (v4)

2012-10-16 Thread Rob Clark

On Tue, Oct 16, 2012 at 9:14 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Rob,

 Thanks for the patch (0/11 looks a bit weird BTW).

opps, that was *supposed* to be 01/11 :-P


 On Friday 12 October 2012 18:57:12 Rob Clark wrote:
 From: Rob Clark r...@ti.com

 A helper that drivers can use to send vblank event after a pageflip.
 If the driver doesn't support proper vblank irq based time/seqn then
 just pass -1 for the pipe # to get do_gettimestamp() behavior (since
 there are a lot of drivers that don't use drm_vblank_count_and_time())

 Also an internal send_vblank_event() helper for the various other code
 paths within drm_irq that also need to send vblank events.

 v1: original
 v2: add back 'vblwait-reply.sequence = seq' which should not have
 been deleted
 v3: add WARN_ON() in case lock is not held and comments
 v4: use WARN_ON_SMP() instead to fix issue with !SMP  !DEBUG_SPINLOCK
 as pointed out by Marcin Slusarz

 Signed-off-by: Rob Clark r...@ti.com
 ---
  drivers/gpu/drm/drm_irq.c |   74 --
  include/drm/drmP.h|2 ++

 Documentation/DocBook/drm.tmpl is missing ;-)

yeah, I just noticed that the docbook already has a section on
pageflip.. I'll send a separate patch for this.

BR,
-R


  2 files changed, 54 insertions(+), 22 deletions(-)

 I still wish we could have found a way to call drm_vblank_count_and_time() and
 do_gettimeofday() outside of the spinlock-protected region, but I won't
 complain. Apart from the missing documentation update the patch looks OK to
 me.

 --
 Regards,

 Laurent Pinchart

 ___
 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

[PATCH] drm/radeon: add some new SI PCI ids

2012-10-16 Thread alexdeucher

From: Alex Deucher alexander.deuc...@amd.com

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: sta...@vger.kernel.org
---
 include/drm/drm_pciids.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index c78bb99..af1cbaf 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -205,6 +205,8 @@
{0x1002, 0x6788, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_TAHITI|RADEON_NEW_MEMMAP}, \
{0x1002, 0x678A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_TAHITI|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6790, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_TAHITI|RADEON_NEW_MEMMAP}, \
+   {0x1002, 0x6791, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_TAHITI|RADEON_NEW_MEMMAP}, \
+   {0x1002, 0x6792, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_TAHITI|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6798, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_TAHITI|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6799, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_TAHITI|RADEON_NEW_MEMMAP}, \
{0x1002, 0x679A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_TAHITI|RADEON_NEW_MEMMAP}, \
@@ -217,6 +219,7 @@
{0x1002, 0x6808, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6809, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6810, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \
+   {0x1002, 0x6811, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6816, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6817, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6818, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \
-- 
1.7.7.5

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

[Bug 56038] New: r100_ring_test] ERROR messages sometimes on boot with ati radeon 9000 AGP ( r200 driver, dri2 KMS enabled )

2012-10-16 Thread bugzilla-daemon

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

  Priority: medium
Bug ID: 56038
  Assignee: dri-devel@lists.freedesktop.org
   Summary: r100_ring_test] *ERROR* messages sometimes on boot
with ati radeon 9000 AGP ( r200 driver, dri2 KMS
enabled )
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: mister.free...@laposte.net
  Hardware: x86 (IA32)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 68625
  -- https://bugs.freedesktop.org/attachment.cgi?id=68625action=edit
dmesg output

randomly ( it's very rare, 90% of the time I don't have this error message ) I
can see these error messages on boot :

[1.516518] [drm] Loading R200 Microcode
[1.517953] [drm] radeon: ring at 0xE0001000
[1.665941] [drm:r100_ring_test] *ERROR* radeon: ring test failed
(scratch(0x15E4)=0xCAFEDEAD)
[1.665996] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
[1.666043] radeon :01:00.0: failed initializing CP (-22).
[1.666084] radeon :01:00.0: Disabling GPU acceleration
[1.812455] [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting
down CP.
[1.812600] [drm] radeon: cp finalized
[1.812629] [drm] radeon: cp finalized

but the boot process continues and I see no problem on KDE4.9.2 and 3d games,

this bug occurs since the update of ati-dri 9.0 and xorg packages 1.13 on my
archlinux 32 bits installation, before that I had never seen this kind of error
message

my system :

- archlinux 32 bits
- laptop pentium 4 2.4 ghz 1,2 Gb ram
- video card: ati radeon 9000 agp ( M9 rv250, r200 driver, dri2 enabled with
kms early start )
- SIS645DX chipset on motherboard

You can fin an attachment ( dmesg output ) with this message,

this bug may related to another ( startx problems ) :

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

-- 
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 56042] New: [865G] BadAlloc (insufficient resources for operation)

2012-10-16 Thread bugzilla-daemon

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

  Priority: medium
Bug ID: 56042
  Assignee: dri-devel@lists.freedesktop.org
   Summary: [865G] BadAlloc (insufficient resources for operation)
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: goetzchr...@yahoo.es
  Hardware: x86 (IA32)
Status: NEW
   Version: 9.0
 Component: Drivers/DRI/i830
   Product: Mesa

Created attachment 68637
  -- https://bugs.freedesktop.org/attachment.cgi?id=68637action=edit
dmesg

When I run glxinfo, or any 3D application, the app doesn't start, and I only
get this error. With Mesa 8.0.4 there was no problem.

$ glxinfo 
name of display: :0
X Error of failed request:  BadAlloc (insufficient resources for operation)
  Major opcode of failed request:  153 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Serial number of failed request:  22
  Current serial number in output stream:  25

---

Linux 3.6.2
X Server 1.13.0
libdrm 2.4.39
xf86-video-intel 2.20.10

00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics
Controller (rev 02) (prog-if 00 [VGA controller])
Subsystem: ASRock Incorporation Device 2572
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR- INTx+
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 0: Memory at f000 (32-bit, prefetchable) [size=128M]
Region 1: Memory at ff28 (32-bit, non-prefetchable) [size=512K]
Region 2: I/O ports at ec00 [size=8]
Expansion ROM at unassigned [disabled]
Capabilities: [d0] Power Management version 1
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915

I don't know what information should I provide.

-- 
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 56042] [865G] BadAlloc (insufficient resources for operation)

2012-10-16 Thread bugzilla-daemon

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

--- Comment #1 from Götz goetzchr...@yahoo.es ---
Created attachment 68638
  -- https://bugs.freedesktop.org/attachment.cgi?id=68638action=edit
Xorg.0.log

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

Re: [PATCH] dma-buf: Use EXPORT_SYMBOL

2012-10-16 Thread Robert Morell

On Wed, Oct 10, 2012 at 11:57:15PM -0700, Hans Verkuil wrote:
 On Wed October 10 2012 23:02:06 Rob Clark wrote:
  On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
   On Wed, 10 Oct 2012 08:56:32 -0700
   Robert Morell rmor...@nvidia.com wrote:
  
   EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
   issue, and not really an interface.  The dma-buf infrastructure is
   explicitly intended as an interface between modules/drivers, so it
   should use EXPORT_SYMBOL instead.
  
   NAK. This needs at the very least the approval of all rights holders for
   the files concerned and all code exposed by this change.
  
  Well, for my contributions to dmabuf, I don't object.. and I think
  because we are planning to use dma-buf in userspace for dri3 /
  dri-next, I think that basically makes it a userspace facing kernel
  infrastructure which would be required for open and proprietary
  drivers alike.  So I don't see much alternative to making this
  EXPORT_SYMBOL().  Of course, IANAL.
 
 The whole purpose of this API is to let DRM and V4L drivers share buffers for
 zero-copy pipelines. Unfortunately it is a fact that several popular DRM 
 drivers
 are closed source. So we have a choice between keeping the export symbols GPL
 and forcing those closed-source drivers to make their own incompatible API,
 thus defeating the whole point of DMABUF, or using EXPORT_SYMBOL and letting
 the closed source vendors worry about the legality. They are already using 
 such
 functions (at least nvidia is), so they clearly accept that risk.
 
 I prefer the evil where the DMABUF API uses EXPORT_SYMBOL to prevent the worse
 evil where an incompatible API is created to work around the EXPORT_SYMBOL_GPL
 limitation. Neither situation is paradise, but at least one is a slightly less
 depressing world than the other :-)
 
 In other words, I'm OK with EXPORT_SYMBOL for whatever it is worth as I did 
 not
 do any coding but only some initial design help and reviewing.

Thanks for the discussion.

My intention is not to steal any code from the kernel or change any licenses.
The goal here is to allow interoperation between drivers.  I understand that it
can be difficult to debug the kernel when the nvidia binary module is loaded;
I'm not trying to force anyone to do that.  You're free to continue to use your
debug environment without change after this patch is applied.

I believe that the developers and maintainers of dma-buf have provided
the needed signoff, both in person and in this thread.  If there are any
objections from that group, I'm happy to discuss any changes necessary to get
this merged.

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

[PATCH] drm/debugfs: remove redundant info from gem_names

2012-10-16 Thread Marcin Slusarz

It's a relic of drm: Convert proc files to seq_file and introduce debugfs,
which wrongly converted DRM_INFO + sprintf to 2 seq_printfs.

Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: Ben Gamari bgam...@gmail.com
Cc: Eric Anholt e...@anholt.net
---
 drivers/gpu/drm/drm_info.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
index 8928edb..d498ec7 100644
--- a/drivers/gpu/drm/drm_info.c
+++ b/drivers/gpu/drm/drm_info.c
@@ -204,8 +204,6 @@ static int drm_gem_one_name_info(int id, void *ptr, void 
*data)
struct drm_gem_object *obj = ptr;
struct seq_file *m = data;
 
-   seq_printf(m, name %d size %zd\n, obj-name, obj-size);
-
seq_printf(m, %6d %8zd %7d %8d\n,
   obj-name, obj-size,
   atomic_read(obj-handle_count),
-- 
1.7.12

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

Re: linux-next: Tree for Oct 16 (readeon_legacy)

2012-10-16 Thread Alex Deucher

On Tue, Oct 16, 2012 at 4:05 PM, Randy Dunlap rdun...@xenotime.net wrote:
 On 10/15/2012 08:58 PM, Stephen Rothwell wrote:

 Hi all,

 The merge window has closed, feel free to add new stuff again.

 Changes since 201201015:


patch already sent to Dave:
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixesid=cd23492af3d4401c02c48a4bebe5995c9498eac5

Alex



 on x86_64:

 drivers/built-in.o: In function `radeon_asic_init':
 (.text+0xd3c71): undefined reference to `radeon_legacy_set_backlight_level'
 drivers/built-in.o:(.data+0x20490): undefined reference to 
 `radeon_legacy_set_backlight_level'
 drivers/built-in.o:(.data+0x20498): undefined reference to 
 `radeon_legacy_get_backlight_level'
 drivers/built-in.o:(.data+0x20710): undefined reference to 
 `radeon_legacy_set_backlight_level'
 drivers/built-in.o:(.data+0x20718): undefined reference to 
 `radeon_legacy_get_backlight_level'
 drivers/built-in.o:(.data+0x20990): undefined reference to 
 `radeon_legacy_set_backlight_level'
 drivers/built-in.o:(.data+0x20998): undefined reference to 
 `radeon_legacy_get_backlight_level'
 drivers/built-in.o:(.data+0x20c10): undefined reference to 
 `radeon_legacy_set_backlight_level'
 drivers/built-in.o:(.data+0x20c18): undefined reference to 
 `radeon_legacy_get_backlight_level'
 drivers/built-in.o:(.data+0x21110): undefined reference to 
 `radeon_legacy_set_backlight_level'
 drivers/built-in.o:(.data+0x21118): undefined reference to 
 `radeon_legacy_get_backlight_level'


 Full randconfig file is attached.
 CONFIG_BACKLIGHT_CLASS_DEVICE is not enabled.

 --
 ~Randy

 ___
 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

[PATCH 01/11] drm: add drm_send_vblank_event() helper (v5)

2012-10-16 Thread Rob Clark

From: Rob Clark r...@ti.com

A helper that drivers can use to send vblank event after a pageflip.
If the driver doesn't support proper vblank irq based time/seqn then
just pass -1 for the pipe # to get do_gettimestamp() behavior (since
there are a lot of drivers that don't use drm_vblank_count_and_time())

Also an internal send_vblank_event() helper for the various other code
paths within drm_irq that also need to send vblank events.

v1: original
v2: add back 'vblwait-reply.sequence = seq' which should not have
been deleted
v3: add WARN_ON() in case lock is not held and comments
v4: use WARN_ON_SMP() instead to fix issue with !SMP  !DEBUG_SPINLOCK
as pointed out by Marcin Slusarz
v5: update docbook

Signed-off-by: Rob Clark r...@ti.com
---
 Documentation/DocBook/drm.tmpl |   20 +++
 drivers/gpu/drm/drm_irq.c  |   74 
 include/drm/drmP.h |2 ++
 3 files changed, 59 insertions(+), 37 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index b030052..c9cbb3f 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -1141,23 +1141,13 @@ int max_width, max_height;/synopsis
 the methodnamepage_flip/methodname operation will be called 
with a
 non-NULL parameterevent/parameter argument pointing to a
 structnamedrm_pending_vblank_event/structname instance. Upon 
page
-flip completion the driver must fill the
-parameterevent/parameter::structfieldevent/structfield
-structfieldsequence/structfield, 
structfieldtv_sec/structfield
-and structfieldtv_usec/structfield fields with the associated
-vertical blanking count and timestamp, add the event to the
-parameterdrm_file/parameter list of events to be signaled, and 
wake
-up any waiting process. This can be performed with
+flip completion the driver must call 
methodnamedrm_send_vblank_event/methodname
+to fill in the event and send to wake up any waiting processes.
+This can be performed with
 programlisting![CDATA[
-struct timeval now;
-
-event-event.sequence = drm_vblank_count_and_time(..., now);
-event-event.tv_sec = now.tv_sec;
-event-event.tv_usec = now.tv_usec;
-
 spin_lock_irqsave(dev-event_lock, flags);
-list_add_tail(event-base.link, 
event-base.file_priv-event_list);
-wake_up_interruptible(event-base.file_priv-event_wait);
+...
+drm_send_vblank_event(dev, pipe, event);
 spin_unlock_irqrestore(dev-event_lock, flags);
 ]]/programlisting
   /para
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 076c4a8..9bdcfd5 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -802,6 +802,46 @@ u32 drm_vblank_count_and_time(struct drm_device *dev, int 
crtc,
 }
 EXPORT_SYMBOL(drm_vblank_count_and_time);
 
+static void send_vblank_event(struct drm_device *dev,
+   struct drm_pending_vblank_event *e,
+   unsigned long seq, struct timeval *now)
+{
+   WARN_ON_SMP(!spin_is_locked(dev-event_lock));
+   e-event.sequence = seq;
+   e-event.tv_sec = now-tv_sec;
+   e-event.tv_usec = now-tv_usec;
+
+   list_add_tail(e-base.link,
+ e-base.file_priv-event_list);
+   wake_up_interruptible(e-base.file_priv-event_wait);
+   trace_drm_vblank_event_delivered(e-base.pid, e-pipe,
+e-event.sequence);
+}
+
+/**
+ * drm_send_vblank_event - helper to send vblank event after pageflip
+ * @dev: DRM device
+ * @crtc: CRTC in question
+ * @e: the event to send
+ *
+ * Updates sequence # and timestamp on event, and sends it to userspace.
+ * Caller must hold event lock.
+ */
+void drm_send_vblank_event(struct drm_device *dev, int crtc,
+   struct drm_pending_vblank_event *e)
+{
+   struct timeval now;
+   unsigned int seq;
+   if (crtc = 0) {
+   seq = drm_vblank_count_and_time(dev, crtc, now);
+   } else {
+   seq = 0;
+   do_gettimeofday(now);
+   }
+   send_vblank_event(dev, e, seq, now);
+}
+EXPORT_SYMBOL(drm_send_vblank_event);
+
 /**
  * drm_update_vblank_count - update the master vblank counter
  * @dev: DRM device
@@ -936,6 +976,13 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
 }
 EXPORT_SYMBOL(drm_vblank_put);
 
+/**
+ * drm_vblank_off - disable vblank events on a CRTC
+ * @dev: DRM device
+ * @crtc: CRTC in question
+ *
+ * Caller must hold event lock.
+ */
 void drm_vblank_off(struct drm_device *dev, int crtc)
 {
struct drm_pending_vblank_event *e, *t;
@@ -955,15 +1002,9 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
DRM_DEBUG(Sending premature vblank event on disable: \

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-16 Thread bugzilla-daemon

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

--- Comment #24 from Serkan Hosca ser...@hosca.com ---
(In reply to comment #23)
 Created attachment 68623 [details] [review]
 Test patch.
 
 VM is definitely enabled, otherwise you won't got that error in the first
 place.
 
 Ok let's try to narrow down that bug a bit more, please apply the attached
 test patch and see what happens.
 
 If the GPU hang vanished we indeed have a syncing issue, but not the PFP
 sync.

The patch resets the gpu constantly, even without X, with both linus git and
agd5f drm-next-3.7 branch with mesa git.

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

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-16 Thread bugzilla-daemon

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

--- Comment #25 from Serkan Hosca ser...@hosca.com ---
Created attachment 68655
  -- https://bugs.freedesktop.org/attachment.cgi?id=68655action=edit
dmesg.3.7-rc1 with test patch

-- 
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 48941] New: Error creating '/sys/class/backlight/radeon_bl' in radeon_atom_backlight_init()

2012-10-16 Thread bugzilla-daemon

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

   Summary: Error creating '/sys/class/backlight/radeon_bl' in
radeon_atom_backlight_init()
   Product: Drivers
   Version: 2.5
Kernel Version: 3.7.0-rc1
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: e-m...@date.by
Regression: No


Created an attachment (id=83691)
 -- (https://bugzilla.kernel.org/attachment.cgi?id=83691)
dmesg

There is an error in my dmesg:

sysfs: cannot create duplicate filename '/class/backlight/radeon_bl'

and there is no '/sys/class/backlight/radeon_bl' after system boot.

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

[Bug 48941] Error creating '/sys/class/backlight/radeon_bl' in radeon_atom_backlight_init()

2012-10-16 Thread bugzilla-daemon

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





--- Comment #1 from Igor Murzov e-m...@date.by  2012-10-17 00:35:56 ---
Created an attachment (id=83701)
 -- (https://bugzilla.kernel.org/attachment.cgi?id=83701)
lspci -vvv

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

[PATCH v2 0/2] add exynos-drm platform device registration to driver

2012-10-16 Thread Rahul Sharma

This patch adds drm-exynos and drm-exynos-hdmi device registration to the
drm driver. It was happening in machine init code earlier which is not
acceptable for dt enabled platforms. 

Patch which cleans the respective code from arch/arm is "arm: exynos:
removing exynos-drm device registration from non-dt platforms" is posted
to linux-samsung-soc mailing list.

This patchset is based on branch exynos-drm-next at
git://git.infradead.org/users/kmpark/linux-samsung (linux v3.6-rc4)

v1:
- moved exynos_drm_hdmi_pdev to drm hdmi layer
- added exynos_platform_device_hdmi_register interface

v2:
- moved register/unregister hdmi device function declarations to
exynos_drm_drv.h

Rahul Sharma (2):
  drm: exynos: moved exynos drm device registration to drm driver
  drm: exynos: moved exynos drm hdmi device registration to drm driver

 drivers/gpu/drm/exynos/exynos_drm_drv.c  |   25 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |   11 +++
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c |   22 ++
 3 files changed, 57 insertions(+), 1 deletions(-)

[PATCH v2 1/2] drm: exynos: moved exynos drm device registration to drm driver

2012-10-16 Thread Rahul Sharma

This patch moved the exynos-drm platform device registration to the drm driver.
When DT is enabled, platform devices needs to be registered within the driver
code. This patch fits the requirement of both DT and Non DT based drm drivers.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index d070719..4200f15 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -50,6 +50,9 @@

 #define VBLANK_OFF_DELAY   5

+/* platform device pointer for eynos drm device. */
+static struct platform_device *exynos_drm_pdev;
+
 static int exynos_drm_load(struct drm_device *dev, unsigned long flags)
 {
struct exynos_drm_private *private;
@@ -280,6 +283,7 @@ static int exynos_drm_platform_probe(struct platform_device 
*pdev)
 {
DRM_DEBUG_DRIVER("%s\n", __FILE__);

+   pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
exynos_drm_driver.num_ioctls = DRM_ARRAY_SIZE(exynos_ioctls);

return drm_platform_init(_drm_driver, pdev);
@@ -341,11 +345,21 @@ static int __init exynos_drm_init(void)

ret = platform_driver_register(_drm_platform_driver);
if (ret < 0)
+   goto out_drm;
+
+   exynos_drm_pdev = platform_device_register_simple("exynos-drm", -1,
+   NULL, 0);
+   if (IS_ERR_OR_NULL(exynos_drm_pdev)) {
+   ret = PTR_ERR(exynos_drm_pdev);
goto out;
+   }

return 0;

 out:
+   platform_driver_unregister(_drm_platform_driver);
+
+out_drm:
 #ifdef CONFIG_DRM_EXYNOS_G2D
platform_driver_unregister(_driver);
 out_g2d:
@@ -376,6 +390,8 @@ static void __exit exynos_drm_exit(void)
 {
DRM_DEBUG_DRIVER("%s\n", __FILE__);

+   platform_device_unregister(exynos_drm_pdev);
+
platform_driver_unregister(_drm_platform_driver);

 #ifdef CONFIG_DRM_EXYNOS_G2D
-- 
1.7.0.4

[PATCH v2 2/2] drm: exynos: moved exynos drm hdmi device registration to drm driver

2012-10-16 Thread Rahul Sharma

This patch moved the exynos-drm-hdmi platform device registration to the drm
driver. When DT is enabled, platform devices needs to be registered within the
driver code. This patch fits the requirement of both DT and Non DT based drm
drivers.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |9 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |   11 +++
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c |   22 ++
 3 files changed, 41 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 4200f15..507f8ba 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -329,6 +329,10 @@ static int __init exynos_drm_init(void)
ret = platform_driver_register(_drm_common_hdmi_driver);
if (ret < 0)
goto out_common_hdmi;
+
+   ret = exynos_platform_device_hdmi_register();
+   if (ret < 0)
+   goto out_common_hdmi_dev;
 #endif

 #ifdef CONFIG_DRM_EXYNOS_VIDI
@@ -366,11 +370,13 @@ out_g2d:
 #endif

 #ifdef CONFIG_DRM_EXYNOS_VIDI
-out_vidi:
platform_driver_unregister(_driver);
+out_vidi:
 #endif

 #ifdef CONFIG_DRM_EXYNOS_HDMI
+   exynos_platform_device_hdmi_unregister();
+out_common_hdmi_dev:
platform_driver_unregister(_drm_common_hdmi_driver);
 out_common_hdmi:
platform_driver_unregister(_driver);
@@ -399,6 +405,7 @@ static void __exit exynos_drm_exit(void)
 #endif

 #ifdef CONFIG_DRM_EXYNOS_HDMI
+   exynos_platform_device_hdmi_unregister();
platform_driver_unregister(_drm_common_hdmi_driver);
platform_driver_unregister(_driver);
platform_driver_unregister(_driver);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index eec77aa..e4abb62 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -319,6 +319,17 @@ int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv 
*drm_subdrv);
 int exynos_drm_subdrv_open(struct drm_device *dev, struct drm_file *file);
 void exynos_drm_subdrv_close(struct drm_device *dev, struct drm_file *file);

+/*
+ * this function registers exynos drm hdmi platform device. It ensures only one
+ * instance of the device is created.
+ */
+extern int exynos_platform_device_hdmi_register(void);
+
+/*
+ * this function unregisters exynos drm hdmi platform device if it exists.
+ */
+void exynos_platform_device_hdmi_unregister(void);
+
 extern struct platform_driver fimd_driver;
 extern struct platform_driver hdmi_driver;
 extern struct platform_driver mixer_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 85304c4..a4c84c1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -29,6 +29,9 @@
 #define get_ctx_from_subdrv(subdrv)container_of(subdrv,\
struct drm_hdmi_context, subdrv);

+/* platform device pointer for common drm hdmi device. */
+static struct platform_device *exynos_drm_hdmi_pdev;
+
 /* Common hdmi subdrv needs to access the hdmi and mixer though context.
 * These should be initialied by the repective drivers */
 static struct exynos_drm_hdmi_context *hdmi_ctx;
@@ -46,6 +49,25 @@ struct drm_hdmi_context {
boolenabled[MIXER_WIN_NR];
 };

+int exynos_platform_device_hdmi_register(void)
+{
+   if (exynos_drm_hdmi_pdev)
+   return -EEXIST;
+
+   exynos_drm_hdmi_pdev = platform_device_register_simple(
+   "exynos-drm-hdmi", -1, NULL, 0);
+   if (IS_ERR_OR_NULL(exynos_drm_hdmi_pdev))
+   return PTR_ERR(exynos_drm_hdmi_pdev);
+
+   return 0;
+}
+
+void exynos_platform_device_hdmi_unregister(void)
+{
+   if (exynos_drm_hdmi_pdev)
+   platform_device_unregister(exynos_drm_hdmi_pdev);
+}
+
 void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx)
 {
if (ctx)
-- 
1.7.0.4

[PATCH] radeon: fix tile_split of 128-bit surface formats with 8x MSAA

2012-10-16 Thread Marek Olšák

The calculation led to the number 8192, which is too high.
---
 radeon/radeon_surface.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 66c2444..eb587d2 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager 
*surf_man,
 } else {
 /* tile split must be >= 256 for colorbuffer surfaces */
 surf->tile_split = MAX2(surf->nsamples * surf->bpe * 64, 256);
+if (surf->tile_split > 4096)
+surf->tile_split = 4096;
 }
 } else {
 /* set tile split to row size */
-- 
1.7.9.5

[PATCH v2 0/2] add exynos-drm platform device registration to driver

2012-10-16 Thread Inki Dae

Applied.

Thanks,
Inki Dae

2012/10/16 Rahul Sharma :
> This patch adds drm-exynos and drm-exynos-hdmi device registration to the
> drm driver. It was happening in machine init code earlier which is not
> acceptable for dt enabled platforms.
>
> Patch which cleans the respective code from arch/arm is "arm: exynos:
> removing exynos-drm device registration from non-dt platforms" is posted
> to linux-samsung-soc mailing list.
>
> This patchset is based on branch exynos-drm-next at
> git://git.infradead.org/users/kmpark/linux-samsung (linux v3.6-rc4)
>
> v1:
> - moved exynos_drm_hdmi_pdev to drm hdmi layer
> - added exynos_platform_device_hdmi_register interface
>
> v2:
> - moved register/unregister hdmi device function declarations to
> exynos_drm_drv.h
>
> Rahul Sharma (2):
>   drm: exynos: moved exynos drm device registration to drm driver
>   drm: exynos: moved exynos drm hdmi device registration to drm driver
>
>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   25 -
>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |   11 +++
>  drivers/gpu/drm/exynos/exynos_drm_hdmi.c |   22 ++
>  3 files changed, 57 insertions(+), 1 deletions(-)
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[drm-intel:drm-intel-next-queued 42/44] drivers/gpu/drm/i915/intel_pm.c:2506:2: error: 'ret' undeclared

2012-10-16 Thread Fengguang Wu

Hi Ben,

FYI, kernel build failed on

tree:   git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-next-queued
head:   861b675336a1f686f480d92990251e99a3ec0956
commit: 686279dbcbc69f71ce86efdccaa8cad762cba2ea [42/44] drm/i915: Extract PCU 
communication
config: x86_64-allyesconfig # make ARCH=x86_64 allyesconfig

All error/warnings:

drivers/gpu/drm/i915/intel_pm.c: In function 'gen6_enable_rps':
drivers/gpu/drm/i915/intel_pm.c:2506:2: error: 'ret' undeclared (first use in 
this function)
drivers/gpu/drm/i915/intel_pm.c:2506:2: note: each undeclared identifier is 
reported only once for each function it appears in

vim +2506 drivers/gpu/drm/i915/intel_pm.c

89ba829e Jesse Barnes   2012-05-22  2500   
GEN6_RP_MEDIA_HW_NORMAL_MODE |
2b4e57bd Eugeni Dodonov 2012-04-18  2501   GEN6_RP_MEDIA_IS_GFX 
|
2b4e57bd Eugeni Dodonov 2012-04-18  2502   GEN6_RP_ENABLE |
2b4e57bd Eugeni Dodonov 2012-04-18  2503   GEN6_RP_UP_BUSY_AVG |
5a7dc92a Eugeni Dodonov 2012-07-02  2504   (IS_HASWELL(dev) ? 
GEN7_RP_DOWN_IDLE_AVG : GEN6_RP_DOWN_IDLE_CONT));
2b4e57bd Eugeni Dodonov 2012-04-18  2505  
686279db Ben Widawsky   2012-09-26 @2506ret = 
sandybridge_pcode_write(dev_priv, GEN6_PCODE_WRITE_MIN_FREQ_TABLE, 0);
686279db Ben Widawsky   2012-09-26  2507if (!ret) {
686279db Ben Widawsky   2012-09-26  2508pcu_mbox = 0;
686279db Ben Widawsky   2012-09-26  2509ret = 
sandybridge_pcode_read(dev_priv, GEN6_READ_OC_PARAMS, _mbox);

---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu  Intel Corporation

[Bug 55829] [Regression]Smokin-guns crash when change resolution

2012-10-16 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #5 from meng  ---
Xonotic (xonotic-linux64-sdl) can also repoduce this problem with above
version. Pls see Xorg.0.log and bt of xonotic.

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

[Bug 55829] [Regression]Smokin-guns crash when change resolution

2012-10-16 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #6 from meng  ---
Created attachment 68594
  --> https://bugs.freedesktop.org/attachment.cgi?id=68594=edit
backtrace of xonotic

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

[Bug 55829] [Regression]Smokin-guns crash when change resolution

2012-10-16 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #7 from meng  ---
Created attachment 68595
  --> https://bugs.freedesktop.org/attachment.cgi?id=68595=edit
Xorg.0.log of xonotic

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

[PATCH] drm/omap: Fix include error during make

2012-10-16 Thread Andy Gross

Fixed include error for drm_mode.h

Signed-off-by: Andy Gross 
---
 drivers/staging/omapdrm/omap_crtc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_crtc.c 
b/drivers/staging/omapdrm/omap_crtc.c
index 732f2ad..5249223 100644
--- a/drivers/staging/omapdrm/omap_crtc.c
+++ b/drivers/staging/omapdrm/omap_crtc.c
@@ -19,7 +19,7 @@

 #include "omap_drv.h"

-#include "drm_mode.h"
+#include 
 #include "drm_crtc.h"
 #include "drm_crtc_helper.h"

-- 
1.7.5.4

[git pull] drm fixes

2012-10-16 Thread Dave Airlie


Hi Linus,

fixes for i915, nouveau and radeon

i915: haswell stability, modeset rework fallout, ums fix
nouveau: misc fixes from code rework
radeon: pll rework fixes, more 2 level PTE cleanups.
core: warning fixes on 32-bit.

Dave.

The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:

  Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)

are available in the git repository at:

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

for you to fetch changes up to 8a00b6af4cc547725f231c8367ddc7cb56b2cf76:

  nouveau: fix warning on 32-bit build. (2012-10-16 16:40:53 +1000)


Alex Deucher (5):
  drm/radeon: fix compilation with backlight disabled
  drm/radeon: allocate PPLLs from low to high
  drm/radeon: update comments to clarify VM setup (v2)
  drm/radeon/cayman: set VM max pfn at MC init
  drm/radeon: check if pcie gen 2 is already enabled (v2)

Ben Skeggs (1):
  drm/nouveau/bios: fix typo in error message

Chris Wilson (2):
  drm/i915: Disallow preallocation of requests
  drm/i915: fixup i915_gem_object_get_page inline helper

Christian K?nig (3):
  drm/radeon: allocate page tables on demand v4
  drm/radeon: don't add the IB pool to all VMs v2
  drm/radeon: separate pt alloc from lru add

Daniel Vetter (5):
  drm/i915: paper over a pipe-enable vs pageflip race
  drm/i915: disable wc gtt pte mappings on gen2
  drm/i915: rip out the pipe A quirk for i855gm
  drm/i915: fixup the plane->pipe fixup code
  drm/i915/dvo-ch7xxx: fix get_hw_state

Dave Airlie (5):
  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
  Merge branch 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  drm: fix warning on 32-bit.
  Merge branch 'drm-nouveau-fixes' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
  nouveau: fix warning on 32-bit build.

Egbert Eich (1):
  drm/radeon: Don't destroy I2C Bus Rec in radeon_ext_tmds_enc_destroy().

Jani Nikula (1):
  drm/i915: fix non-DP-D eDP backlight cleanup and module reload

Kenneth Graunke (1):
  drm/i915: Set guardband clipping workaround bit in the right register.

Luca Tettamanti (1):
  drm/radeon: use %zu for formatting size_t

Marcin Slusarz (1):
  drm/nv50/fb: fix double free of vram mm

Martin Peres (3):
  drm/nouveau/hwmon: fix the initialization condition
  drm/nouveau/pm: fix a typo related to the move to the therm subdev
  drm/nouveau/pm: do not stop reclocking if failing to set the fan speed

Max Filippov (1):
  drm/nouveau: only call ttm_agp_tt_create when __OS_HAS_AGP

Randy Dunlap (1):
  drm: radeon: fix printk format warning

Rodrigo Vivi (1):
  drm/i915: HSW CRW stability magic

Thomas Friebel (1):
  drm/radeon: fix spelling typos in debugging output

Willy Tarreau (1):
  drm/i915: remove useless BUG_ON which caused a regression in 3.5.

 drivers/char/agp/intel-gtt.c|2 +-
 drivers/gpu/drm/drm_info.c  |2 +-
 drivers/gpu/drm/i915/dvo_ch7xxx.c   |6 +-
 drivers/gpu/drm/i915/i915_drv.h |9 +-
 drivers/gpu/drm/i915/i915_gem.c |   19 +-
 drivers/gpu/drm/i915/i915_reg.h |2 +-
 drivers/gpu/drm/i915/intel_display.c|   47 ++-
 drivers/gpu/drm/i915/intel_dp.c |3 +-
 drivers/gpu/drm/i915/intel_overlay.c|   72 +
 drivers/gpu/drm/i915/intel_pm.c |4 +-
 drivers/gpu/drm/nouveau/core/subdev/bios/dcb.c  |2 +-
 drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c   |1 -
 drivers/gpu/drm/nouveau/core/subdev/therm/fan.c |2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c|2 +
 drivers/gpu/drm/nouveau/nouveau_pm.c|6 +-
 drivers/gpu/drm/radeon/atombios_crtc.c  |8 +-
 drivers/gpu/drm/radeon/evergreen.c  |7 +-
 drivers/gpu/drm/radeon/ni.c |   12 +-
 drivers/gpu/drm/radeon/r600.c   |6 +
 drivers/gpu/drm/radeon/radeon.h |   14 +-
 drivers/gpu/drm/radeon/radeon_acpi.c|6 +-
 drivers/gpu/drm/radeon/radeon_atpx_handler.c|2 +-
 drivers/gpu/drm/radeon/radeon_cs.c  |1 +
 drivers/gpu/drm/radeon/radeon_device.c  |4 +
 drivers/gpu/drm/radeon/radeon_gart.c|  374 ---
 drivers/gpu/drm/radeon/radeon_kms.c |   22 +-
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |   48 ++-
 drivers/gpu/drm/radeon/radeon_ring.c|2 +-
 drivers/gpu/drm/radeon/si.c |7 +-
 29 files changed, 443 insertions(+), 249 deletions(-)

[PATCH] radeon: fix tile_split of 128-bit surface formats with 8x MSAA

2012-10-16 Thread Paul Menzel

Dear Marek,


Am Dienstag, den 16.10.2012, 02:21 +0200 schrieb Marek Ol??k:
> The calculation led to the number 8192, which is too high.

what is the reason it is limited to 4096? Hardware limitation?

What are the ramifications? GPU hangs, rendering errors?

> ---
>  radeon/radeon_surface.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 66c2444..eb587d2 100644
> --- a/radeon/radeon_surface.c
> +++ b/radeon/radeon_surface.c
> @@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager 
> *surf_man,
>  } else {
>  /* tile split must be >= 256 for colorbuffer surfaces */
>  surf->tile_split = MAX2(surf->nsamples * surf->bpe * 64, 256);
> +if (surf->tile_split > 4096)
> +surf->tile_split = 4096;
>  }
>  } else {
>  /* set tile split to row size */


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121016/c6df66b0/attachment-0001.pgp>

[drm-intel:drm-intel-next-queued 42/44] drivers/gpu/drm/i915/intel_pm.c:2506:2: error: 'ret' undeclared

2012-10-16 Thread Daniel Vetter

On Tue, Oct 16, 2012 at 08:59:51AM +0800, Fengguang Wu wrote:
> Hi Ben,
> 
> FYI, kernel build failed on
> 
> tree:   git://people.freedesktop.org/~danvet/drm-intel.git 
> drm-intel-next-queued
> head:   861b675336a1f686f480d92990251e99a3ec0956
> commit: 686279dbcbc69f71ce86efdccaa8cad762cba2ea [42/44] drm/i915: Extract 
> PCU communication
> config: x86_64-allyesconfig # make ARCH=x86_64 allyesconfig
> 
> All error/warnings:
> 
> drivers/gpu/drm/i915/intel_pm.c: In function 'gen6_enable_rps':
> drivers/gpu/drm/i915/intel_pm.c:2506:2: error: 'ret' undeclared (first use in 
> this function)
> drivers/gpu/drm/i915/intel_pm.c:2506:2: note: each undeclared identifier is 
> reported only once for each function it appears in
> 
> vim +2506 drivers/gpu/drm/i915/intel_pm.c
> 
> 89ba829e Jesse Barnes   2012-05-22  2500 
> GEN6_RP_MEDIA_HW_NORMAL_MODE |
> 2b4e57bd Eugeni Dodonov 2012-04-18  2501 GEN6_RP_MEDIA_IS_GFX 
> |
> 2b4e57bd Eugeni Dodonov 2012-04-18  2502 GEN6_RP_ENABLE |
> 2b4e57bd Eugeni Dodonov 2012-04-18  2503 GEN6_RP_UP_BUSY_AVG |
> 5a7dc92a Eugeni Dodonov 2012-07-02  2504 (IS_HASWELL(dev) ? 
> GEN7_RP_DOWN_IDLE_AVG : GEN6_RP_DOWN_IDLE_CONT));
> 2b4e57bd Eugeni Dodonov 2012-04-18  2505  
> 686279db Ben Widawsky   2012-09-26 @2506  ret = 
> sandybridge_pcode_write(dev_priv, GEN6_PCODE_WRITE_MIN_FREQ_TABLE, 0);
> 686279db Ben Widawsky   2012-09-26  2507  if (!ret) {
> 686279db Ben Widawsky   2012-09-26  2508  pcu_mbox = 0;
> 686279db Ben Widawsky   2012-09-26  2509  ret = 
> sandybridge_pcode_read(dev_priv, GEN6_READ_OC_PARAMS, _mbox);

Fixed up, thanks a lot for the report.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/radeon: fix PFP sync in vm_flush

2012-10-16 Thread Christian König

Otherwise the next IB might start reading commands
with the page table still invalid.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/ni.c  |4 
 drivers/gpu/drm/radeon/nid.h |1 +
 drivers/gpu/drm/radeon/si.c  |4 
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 8c74c72..19b7fe1 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1586,4 +1586,8 @@ void cayman_vm_flush(struct radeon_device *rdev, int 
ridx, struct radeon_vm *vm)
/* bits 0-7 are the VM contexts0-7 */
radeon_ring_write(ring, PACKET0(VM_INVALIDATE_REQUEST, 0));
radeon_ring_write(ring, 1 << vm->id);
+
+   /* sync PFP to ME, otherwise we might get invalid PFP reads */
+   radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0));
+   radeon_ring_write(ring, 0x0);
 }
diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
index 2423d1b..cbef681 100644
--- a/drivers/gpu/drm/radeon/nid.h
+++ b/drivers/gpu/drm/radeon/nid.h
@@ -502,6 +502,7 @@
 #definePACKET3_MPEG_INDEX  0x3A
 #definePACKET3_WAIT_REG_MEM0x3C
 #definePACKET3_MEM_WRITE   0x3D
+#definePACKET3_PFP_SYNC_ME 0x42
 #definePACKET3_SURFACE_SYNC0x43
 #  define PACKET3_CB0_DEST_BASE_ENA(1 << 6)
 #  define PACKET3_CB1_DEST_BASE_ENA(1 << 7)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index df8dd77..da184de 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2868,6 +2868,10 @@ void si_vm_flush(struct radeon_device *rdev, int ridx, 
struct radeon_vm *vm)
radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
radeon_ring_write(ring, 0);
radeon_ring_write(ring, 1 << vm->id);
+
+   /* sync PFP to ME, otherwise we might get invalid PFP reads */
+   radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0));
+   radeon_ring_write(ring, 0x0);
 }

 /*
-- 
1.7.9.5

[PATCHv10 23/26] v4l: vb2-dma-contig: align buffer size to PAGE_SIZE

2012-10-16 Thread Laurent Pinchart

Hi Tomasz,

On Friday 12 October 2012 10:24:34 Tomasz Stanislawski wrote:
> On 10/11/2012 11:31 PM, Laurent Pinchart wrote:
> > On Wednesday 10 October 2012 16:46:42 Tomasz Stanislawski wrote:
> >> Most operations on DMA and DMABUF framework need page
> >> aligned buffers.
> > 
> > The comment is a bit misleading, the buffer is already page-aligned
> > (unless I'm mistaken dma_alloc_coherent() returns a page-aligned buffer)
> > but its size isn't a multiple of the page size.
> 
> Ok. I will update the commit message that only buffer size is going to be
> page aligned.
>
> > Do we really need a page size multiple ? Isn't it enough to make the size
> > a multiple of the cache line size ?
> 
> Frankly, I strongly oppose forcing a size of a DMA buffer to be rounded up.
> 
> However, I discovered a problem while testing mmap() interface in dma-buf.
> The test in dma_buf_mmap() will fail if the size is not a multiple of 4k.
> 
> Maybe the value from dma-buf.c:456 should be changed from:
> 
> dmabuf->size >> PAGE_SHIFT
> 
> to
> 
> PAGE_ALIGN(dmabuf->size) >> PAGE_SHIFT
> 
> However, I preferred to avoid any changes outside of the media tree hoping
> that the patchset gets merged. Rounding the buffer size to a page size was
> quick workaround for the issue with DMABUF mmap().

After some more thoughts I'm not sure whether this patch does the right thing. 
We have two sizes that we neeed to care about, the user usable buffer size and 
the allocated memory size.

When a user of a buffer requests buffer allocation with an explicit or 
implicit size we might need to allocate a larger buffer to fulfill usage 
requirements. We can thus end up with an allocated memory size larger than 
what the user requested. Such usage requirements include

- DMA and CPU access: when accessing the buffer both through DMA and directly 
by the CPU cache management comes into play, and the buffer address and size 
then need to be aligned to a cache line size boundary.

- Mapping to userspace: we can only map complete pages to userspace, the 
buffer address and size need to be aligned to a page size boundary to make 
sure that we won't leak unrelated data to userspace.

As the cache line size is smaller than a page fulfilling the second 
requirement always fulfills the first. There might be other requirements that 
escape my mind right now.

As we don't precisely know at allocation time how the buffer will be used (for 
instance whether it will eventually be mapped to userspace or not), we have 
two options:

- Align the buffer size to a page size boundary unconditionally.

- Let the user handle that requirement by specifying an allocation size 
aligned to a page size boundary.

Given the complexity associated with the second solution and the very small, 
if not inexistent, expected memory gain (when using the DMA allocation APIs we 
always get complete pages anyway, so there would be no gain in not aligning 
the allocation size to a page size boundary), I think the first solution 
should be preferred.

This leaves us with two questions related to buffer size: what size (between 
the requested size and the actually allocated size) do we report back to the 
user (in the v4l2_buffer length field for instance), and what size do we 
report to the dma-buf core (and thus to the other subsystems and other buffer 
users) ?

-- 
Regards,

Laurent Pinchart

[PATCH 1/2] uapi: update includes for drm content when no kernel API exists

2012-10-16 Thread Laurent Pinchart

Hi Luis,

On Saturday 13 October 2012 10:00:42 Luis R. Rodriguez wrote:
> On Sat, Oct 13, 2012 at 3:33 AM, Laurent Pinchart wrote:
> > On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote:
> >> From: "Luis R. Rodriguez" 
> >> 
> >> The UAPI changes split kernel API and userspace API
> >> content onto two separate header files. The userspace
> >> API drm content was moved to include/uapi/drm/ with the
> >> same file name while kernel specific API content was
> >> kept under include/drm/ with the same file name. When
> >> one file was split into two files the kernel header
> >> includes the uapi header and a UAPI prefix was added to
> >> the uapi header for its header guard. When there was no
> >> kernel API content found the uapi header file was the
> >> only one that was kept and the original guard for the
> >> header file was kept. In this particular case the
> >> original users of this header file were not modified
> >> and the uapi header file is expected to be picked up
> >> by path.
> >> 
> >> This may work well at compilation on the kernel but when
> >> backporting this creates a few complexities.
> > 
> > Could you please provide more details about those complexities ?
> 
> Sure, the backported DRM code is as-is code from linux-next. The
> header search path includes a copy of a few select header files from
> linux-next, the rest are part of the compat [0] project to help with
> backporting and the last set are from your own kernel. In this
> particular case the UAPI effort pushed into include/uapi/drm a few
> files which are now no longer present in the old include/drm/ location
> when there was no respective kernel-only APIs exposed. For DRM code
> that did not use the new uapi/drm/ path for old header includes this
> means that upon backporting the older kernel's header file would be
> used obviously leading to a series of compilation failures. By being
> explicit about the path, as was done with a few other header files, we
> can suck out DRM code intact from the kernel to be compilable for
> older kernels. As of the v3.7-rc1 the compat-drivers project [1] will
> be providing DRM modules. The new UAPI changes broke compilation on
> compat-drivers when compiling DRM code so to fix this we either patch
> code taken from the Linux kernel as I have done, force inclusion of a
> few specific headers files, or use include_next tricks. It turns out
> that forcing inclusion of -I$(M)/include/uapi as a path search prior
> to your own kernel's at compilation time did not help.

Shouldn't that be added as a search path *after* include/linux/ instead of 
before ?

> The include_next trick can work as well but that'd mean synching the UAPI
> files regularly into compat. I'd much prefer to have code intact when
> possible when backporting so the option I stuck with then was to patch
> the code directly and then as part of compat-drivers to always copy
> that day's linux-next UAPI headers into the current directory for
> compilation. I see no other driver code using the uapi path explicitly
> though, is that by design?

As far as I understand that's by design, yes. Kernel code isn't expected to 
reference uapi/ headers directly.

> Would it be wrong to be explicit about using a UAPI header alone if no
> kernel API files exist?

I personally don't really like including such "features" in a mainline just 
for backporting, especially when they go against the spirit of the 
architecture (the uapi/ split design principles in this case). The way we're 
dealing with this in the V4L backport tree 
(http://git.linuxtv.org/media_build.git) is to play with Makefiles, include 
compatibility headers and, if nothing else can work, maintain backport patches 
for mainline code.

> [0] https://backports.wiki.kernel.org/index.php/Documentation/compat
> [1] https://backports.wiki.kernel.org/

-- 
Regards,

Laurent Pinchart

[PATCH] drm/radeon: fix PFP sync in vm_flush

2012-10-16 Thread Alex Deucher

On Tue, Oct 16, 2012 at 5:02 AM, Christian K?nig
 wrote:
> Otherwise the next IB might start reading commands
> with the page table still invalid.
>
> Signed-off-by: Christian K?nig 

Looks good to me.  I'll add it to my -fixes queue.

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/ni.c  |4 
>  drivers/gpu/drm/radeon/nid.h |1 +
>  drivers/gpu/drm/radeon/si.c  |4 
>  3 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index 8c74c72..19b7fe1 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -1586,4 +1586,8 @@ void cayman_vm_flush(struct radeon_device *rdev, int 
> ridx, struct radeon_vm *vm)
> /* bits 0-7 are the VM contexts0-7 */
> radeon_ring_write(ring, PACKET0(VM_INVALIDATE_REQUEST, 0));
> radeon_ring_write(ring, 1 << vm->id);
> +
> +   /* sync PFP to ME, otherwise we might get invalid PFP reads */
> +   radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0));
> +   radeon_ring_write(ring, 0x0);
>  }
> diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
> index 2423d1b..cbef681 100644
> --- a/drivers/gpu/drm/radeon/nid.h
> +++ b/drivers/gpu/drm/radeon/nid.h
> @@ -502,6 +502,7 @@
>  #definePACKET3_MPEG_INDEX  0x3A
>  #definePACKET3_WAIT_REG_MEM0x3C
>  #definePACKET3_MEM_WRITE   0x3D
> +#definePACKET3_PFP_SYNC_ME 0x42
>  #definePACKET3_SURFACE_SYNC0x43
>  #  define PACKET3_CB0_DEST_BASE_ENA(1 << 6)
>  #  define PACKET3_CB1_DEST_BASE_ENA(1 << 7)
> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
> index df8dd77..da184de 100644
> --- a/drivers/gpu/drm/radeon/si.c
> +++ b/drivers/gpu/drm/radeon/si.c
> @@ -2868,6 +2868,10 @@ void si_vm_flush(struct radeon_device *rdev, int ridx, 
> struct radeon_vm *vm)
> radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
> radeon_ring_write(ring, 0);
> radeon_ring_write(ring, 1 << vm->id);
> +
> +   /* sync PFP to ME, otherwise we might get invalid PFP reads */
> +   radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0));
> +   radeon_ring_write(ring, 0x0);
>  }
>
>  /*
> --
> 1.7.9.5
>

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

2012-10-16 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #16 from Helge Bahmann  ---
(In reply to comment #15)
> A patch referencing this bug report has been merged in Linux v3.7-rc1:
> 
> commit bced76f27165ca7733437715185c3a1aa526f7a1
> Author: Alex Deucher 
> Date:   Fri Sep 14 09:45:50 2012 -0400
> 
> drm/radeon: restore backlight level on resume

appears to be the same patch as mentioned in comment #10, and (at least for me)
still does not fix the issue

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

[PATCH] radeon: fix tile_split of 128-bit surface formats with 8x MSAA

2012-10-16 Thread Alex Deucher

On Tue, Oct 16, 2012 at 2:50 AM, Paul Menzel
 wrote:
> Dear Marek,
>
>
> Am Dienstag, den 16.10.2012, 02:21 +0200 schrieb Marek Ol??k:
>> The calculation led to the number 8192, which is too high.
>
> what is the reason it is limited to 4096? Hardware limitation?

hw limit.

>
> What are the ramifications? GPU hangs, rendering errors?


Rendering errors.

Alex

>
>> ---
>>  radeon/radeon_surface.c |2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
>> index 66c2444..eb587d2 100644
>> --- a/radeon/radeon_surface.c
>> +++ b/radeon/radeon_surface.c
>> @@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager 
>> *surf_man,
>>  } else {
>>  /* tile split must be >= 256 for colorbuffer surfaces */
>>  surf->tile_split = MAX2(surf->nsamples * surf->bpe * 64, 256);
>> +if (surf->tile_split > 4096)
>> +surf->tile_split = 4096;
>>  }
>>  } else {
>>  /* set tile split to row size */
>
>
> Thanks,
>
> Paul
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH] radeon: fix tile_split of 128-bit surface formats with 8x MSAA

2012-10-16 Thread Alex Deucher

On Mon, Oct 15, 2012 at 8:21 PM, Marek Ol??k  wrote:
> The calculation led to the number 8192, which is too high.

Looks good.

Reviewed-by: Alex Deucher 

> ---
>  radeon/radeon_surface.c |2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 66c2444..eb587d2 100644
> --- a/radeon/radeon_surface.c
> +++ b/radeon/radeon_surface.c
> @@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager 
> *surf_man,
>  } else {
>  /* tile split must be >= 256 for colorbuffer surfaces */
>  surf->tile_split = MAX2(surf->nsamples * surf->bpe * 64, 256);
> +if (surf->tile_split > 4096)
> +surf->tile_split = 4096;
>  }
>  } else {
>  /* set tile split to row size */
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/11] drm: add drm_send_vblank_event() helper

2012-10-16 Thread Laurent Pinchart

Hi Mario,

On Saturday 13 October 2012 02:28:03 Mario Kleiner wrote:
> On 11.10.12 16:19, Laurent Pinchart wrote:
> > On Monday 08 October 2012 14:50:39 Rob Clark wrote:
> >> From: Rob Clark 
> 
> ...
> 
> > Do you know why some drivers don't call drm_vblank_count_and_time() ? For
> > instance nouveau sets the sequence to 0 and uses do_gettimeofday(), but it
> > looks like it could just call drm_vblank_count_and_time().
> 
> At least nouveau could use it. Lucas Stach and me wrote patches for
> nouveau-kms, and they went through many iterations and missed many
> kernel merge windows due to slow review until i think both of us got
> tired of resubmitting with tiny changes.

I totally understand the feeling, but please don't give up. You can CC me on 
the next iteration, I'll make sure to review the patches (even though I have 
no experience with the nouveau driver).

> The latest iteration is posted by Lucas on nouveau-devel from 26. April
> 2012. Not sure if they'd still apply after the nouveau-kms rewrite. I'll
> probably give them another try once that has landed when i have some spare
> time.
> 
> In principle it's very simple to use drm_vblank_count_and_time(). A
> driver needs to
> 
> 1. Call drm_handle_vblank() from its vblank irq handler.
> 
> 2. Make sure that in the vblank of pageflip completion
> drm_handle_vblank() is called before drm_vblank_count_and_time(), so the
> latter picks up updated counts and timestamps.
> 
> 3. Big bonus for high precision and robustness: Implement the
> driver->get_vblank_timestamp() hook to provide a precise vblank
> timestamp. One simple way to do that is like radeon-kms or intel-kms do
> it: Call back into drm_calc_vbltimestamp_from_scanoutpos() and provide
> the driver->get_scanout_position() function - a function that returns
> the current hardware scanline counter. This is precise down to ~ 10
> microseconds (at least confirmed by measurements on
> intel,radeon,nouveau) and robust against delayed vblank irq handling.
> 
> -mario
-- 
Regards,

Laurent Pinchart

[PATCH] radeon: fix tile_split of 128-bit surface formats with 8x MSAA

2012-10-16 Thread Marek Olšák

In this specific case, the eg_surface_sanity function (or something
like that, I don't remember its name) returns an error. Then the
cascade of perfectly working fail codepaths propagate the error to the
OpenGL user as an unsupported framebuffer object setup.

Marek

On Tue, Oct 16, 2012 at 8:50 AM, Paul Menzel
 wrote:
> Dear Marek,
>
>
> Am Dienstag, den 16.10.2012, 02:21 +0200 schrieb Marek Ol??k:
>> The calculation led to the number 8192, which is too high.
>
> what is the reason it is limited to 4096? Hardware limitation?
>
> What are the ramifications? GPU hangs, rendering errors?
>
>> ---
>>  radeon/radeon_surface.c |2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
>> index 66c2444..eb587d2 100644
>> --- a/radeon/radeon_surface.c
>> +++ b/radeon/radeon_surface.c
>> @@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager 
>> *surf_man,
>>  } else {
>>  /* tile split must be >= 256 for colorbuffer surfaces */
>>  surf->tile_split = MAX2(surf->nsamples * surf->bpe * 64, 256);
>> +if (surf->tile_split > 4096)
>> +surf->tile_split = 4096;
>>  }
>>  } else {
>>  /* set tile split to row size */
>
>
> Thanks,
>
> Paul

[PATCH 0/11] drm: add drm_send_vblank_event() helper (v4)

2012-10-16 Thread Laurent Pinchart

Hi Rob,

Thanks for the patch (0/11 looks a bit weird BTW).

On Friday 12 October 2012 18:57:12 Rob Clark wrote:
> From: Rob Clark 
> 
> A helper that drivers can use to send vblank event after a pageflip.
> If the driver doesn't support proper vblank irq based time/seqn then
> just pass -1 for the pipe # to get do_gettimestamp() behavior (since
> there are a lot of drivers that don't use drm_vblank_count_and_time())
> 
> Also an internal send_vblank_event() helper for the various other code
> paths within drm_irq that also need to send vblank events.
> 
> v1: original
> v2: add back 'vblwait->reply.sequence = seq' which should not have
> been deleted
> v3: add WARN_ON() in case lock is not held and comments
> v4: use WARN_ON_SMP() instead to fix issue with !SMP && !DEBUG_SPINLOCK
> as pointed out by Marcin Slusarz
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/drm_irq.c |   74 --
>  include/drm/drmP.h|2 ++

Documentation/DocBook/drm.tmpl is missing ;-)

>  2 files changed, 54 insertions(+), 22 deletions(-)

I still wish we could have found a way to call drm_vblank_count_and_time() and 
do_gettimeofday() outside of the spinlock-protected region, but I won't 
complain. Apart from the missing documentation update the patch looks OK to 
me.

-- 
Regards,

Laurent Pinchart

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-16 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #23 from Christian K?nig  ---
Created attachment 68623
  --> https://bugs.freedesktop.org/attachment.cgi?id=68623=edit
Test patch.

VM is definitely enabled, otherwise you won't got that error in the first
place.

Ok let's try to narrow down that bug a bit more, please apply the attached test
patch and see what happens.

If the GPU hang vanished we indeed have a syncing issue, but not the PFP sync.

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

[BUG 3.7-rc1] nouveau cli->mutex possible recursive locking detected

2012-10-16 Thread Stanislaw Gruszka

I have this lockdep warning on wireless-testing tree based
on 3.7-rc1 (no other patches except wireless bits).

=
Restarting tasks ... done.
[ INFO: possible recursive locking detected ]
3.7.0-rc1-wl+ #2 Not tainted
-
Xorg/2269 is trying to acquire lock:
 (>mutex){+.+.+.}, at: [] 
nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]

but task is already holding lock:
 (>mutex){+.+.+.}, at: [] nouveau_abi16_get+0x34/0x100 
[nouveau]

other info that might help us debug this:
 Possible unsafe locking scenario:

   CPU0
   
  lock(>mutex);
  lock(>mutex);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

1 lock held by Xorg/2269:
 #0:  (>mutex){+.+.+.}, at: [] 
nouveau_abi16_get+0x34/0x100 [nouveau]

stack backtrace:
Pid: 2269, comm: Xorg Not tainted 3.7.0-rc1-wl+ #2
Call Trace:
 [] print_deadlock_bug+0xf4/0x100
 [] validate_chain+0x549/0x7e0
 [] __lock_acquire+0x367/0x580
 [] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
 [] lock_acquire+0xa4/0x120
 [] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
 [] ? _raw_spin_unlock_irqrestore+0x40/0x80
 [] __mutex_lock_common+0x47/0x3f0
 [] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
 [] ? nv84_graph_tlb_flush+0x291/0x2b0 [nouveau]
 [] ? _nouveau_gpuobj_wr32+0x26/0x30 [nouveau]
 [] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
 [] mutex_lock_nested+0x37/0x50
 [] nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
 [] nouveau_bo_move+0xe3/0x330 [nouveau]
 [] ttm_bo_handle_move_mem+0x2bd/0x670 [ttm]
 [] ttm_bo_move_buffer+0x12e/0x150 [ttm]
 [] ttm_bo_validate+0x99/0x130 [ttm]
 [] nouveau_bo_validate+0x23/0x30 [nouveau]
 [] validate_list+0xae/0x2c0 [nouveau]
 [] nouveau_gem_pushbuf_validate+0xa2/0x1e0 [nouveau]
 [] nouveau_gem_ioctl_pushbuf+0x22c/0x8a0 [nouveau]
 [] drm_ioctl+0x355/0x570 [drm]
 [] ? do_sync_read+0xaa/0xf0
 [] ? nouveau_gem_pushbuf_validate+0x1e0/0x1e0 [nouveau]
 [] do_vfs_ioctl+0x8c/0x350
 [] ? sysret_check+0x22/0x5d
 [] sys_ioctl+0xa1/0xb0
 [] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [] system_call_fastpath+0x16/0x1b

[PATCH 1/2] uapi: update includes for drm content when no kernel API exists

2012-10-16 Thread Luis R. Rodriguez

On Tue, Oct 16, 2012 at 5:34 AM, Laurent Pinchart
 wrote:
> Hi Luis,
>
> On Saturday 13 October 2012 10:00:42 Luis R. Rodriguez wrote:
>> On Sat, Oct 13, 2012 at 3:33 AM, Laurent Pinchart wrote:
>> > On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote:
>> >> From: "Luis R. Rodriguez" 
>> >>
>> >> The UAPI changes split kernel API and userspace API
>> >> content onto two separate header files. The userspace
>> >> API drm content was moved to include/uapi/drm/ with the
>> >> same file name while kernel specific API content was
>> >> kept under include/drm/ with the same file name. When
>> >> one file was split into two files the kernel header
>> >> includes the uapi header and a UAPI prefix was added to
>> >> the uapi header for its header guard. When there was no
>> >> kernel API content found the uapi header file was the
>> >> only one that was kept and the original guard for the
>> >> header file was kept. In this particular case the
>> >> original users of this header file were not modified
>> >> and the uapi header file is expected to be picked up
>> >> by path.
>> >>
>> >> This may work well at compilation on the kernel but when
>> >> backporting this creates a few complexities.
>> >
>> > Could you please provide more details about those complexities ?
>>
>> Sure, the backported DRM code is as-is code from linux-next. The
>> header search path includes a copy of a few select header files from
>> linux-next, the rest are part of the compat [0] project to help with
>> backporting and the last set are from your own kernel. In this
>> particular case the UAPI effort pushed into include/uapi/drm a few
>> files which are now no longer present in the old include/drm/ location
>> when there was no respective kernel-only APIs exposed. For DRM code
>> that did not use the new uapi/drm/ path for old header includes this
>> means that upon backporting the older kernel's header file would be
>> used obviously leading to a series of compilation failures. By being
>> explicit about the path, as was done with a few other header files, we
>> can suck out DRM code intact from the kernel to be compilable for
>> older kernels. As of the v3.7-rc1 the compat-drivers project [1] will
>> be providing DRM modules. The new UAPI changes broke compilation on
>> compat-drivers when compiling DRM code so to fix this we either patch
>> code taken from the Linux kernel as I have done, force inclusion of a
>> few specific headers files, or use include_next tricks. It turns out
>> that forcing inclusion of -I$(M)/include/uapi as a path search prior
>> to your own kernel's at compilation time did not help.
>
> Shouldn't that be added as a search path *after* include/linux/ instead of
> before ?

Ah, therein lies the issue. If backporting no, if backporting you
should seek first for your current directory's include/drm/ dir and
then uapi, and then only later the older kernel's paths:

NOSTDINC_FLAGS := \
-I$(M)/include/ \
-I$(M)/include/drm \
-I$(M)/include/uapi \
-include $(M)/include/linux/compat-2.6.h \
$(CFLAGS)

>> The include_next trick can work as well but that'd mean synching the UAPI
>> files regularly into compat. I'd much prefer to have code intact when
>> possible when backporting so the option I stuck with then was to patch
>> the code directly and then as part of compat-drivers to always copy
>> that day's linux-next UAPI headers into the current directory for
>> compilation. I see no other driver code using the uapi path explicitly
>> though, is that by design?
>
> As far as I understand that's by design, yes. Kernel code isn't expected to
> reference uapi/ headers directly.

Did the design consider the case where no respective kernel API header
file would ever exist?

>> Would it be wrong to be explicit about using a UAPI header alone if no
>> kernel API files exist?
>
> I personally don't really like including such "features" in a mainline just
> for backporting,

Sort of ditto. I haven't yet made a strong case for one particular
situation where this would help (but I will in the long run, see
blog), but this example should not be considered one. The patch itself
should be considered in terms of its merit for clarifying usage and
assumptions of uapi. The fact that I came up with it due to issues
when backporting is only secondary.

> especially when they go against the spirit of the
> architecture (the uapi/ split design principles in this case).

The patches, pull request, and even lwn article did not cover the
intent on architecture so if it was the design objective I'd like to
know how that is determined. From the looks of it, this as all
scripted and I do wonder if the case where no kernel API header file
existed was taken into consideration.

> The way we're
> dealing with this in the V4L backport tree
> (http://git.linuxtv.org/media_build.git) is to play with Makefiles, include
> compatibility headers and, if nothing else can work, maintain backport patches
> for

[PATCH 0/11] drm: add drm_send_vblank_event() helper (v4)

2012-10-16 Thread Rob Clark

On Tue, Oct 16, 2012 at 9:14 AM, Laurent Pinchart
 wrote:
> Hi Rob,
>
> Thanks for the patch (0/11 looks a bit weird BTW).

opps, that was *supposed* to be 01/11 :-P

>
> On Friday 12 October 2012 18:57:12 Rob Clark wrote:
>> From: Rob Clark 
>>
>> A helper that drivers can use to send vblank event after a pageflip.
>> If the driver doesn't support proper vblank irq based time/seqn then
>> just pass -1 for the pipe # to get do_gettimestamp() behavior (since
>> there are a lot of drivers that don't use drm_vblank_count_and_time())
>>
>> Also an internal send_vblank_event() helper for the various other code
>> paths within drm_irq that also need to send vblank events.
>>
>> v1: original
>> v2: add back 'vblwait->reply.sequence = seq' which should not have
>> been deleted
>> v3: add WARN_ON() in case lock is not held and comments
>> v4: use WARN_ON_SMP() instead to fix issue with !SMP && !DEBUG_SPINLOCK
>> as pointed out by Marcin Slusarz
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  drivers/gpu/drm/drm_irq.c |   74 --
>>  include/drm/drmP.h|2 ++
>
> Documentation/DocBook/drm.tmpl is missing ;-)

yeah, I just noticed that the docbook already has a section on
pageflip.. I'll send a separate patch for this.

BR,
-R

>
>>  2 files changed, 54 insertions(+), 22 deletions(-)
>
> I still wish we could have found a way to call drm_vblank_count_and_time() and
> do_gettimeofday() outside of the spinlock-protected region, but I won't
> complain. Apart from the missing documentation update the patch looks OK to
> me.
>
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: add some new SI PCI ids

2012-10-16 Thread alexdeuc...@gmail.com

From: Alex Deucher 

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 include/drm/drm_pciids.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index c78bb99..af1cbaf 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -205,6 +205,8 @@
{0x1002, 0x6788, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_TAHITI|RADEON_NEW_MEMMAP}, \
{0x1002, 0x678A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_TAHITI|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6790, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_TAHITI|RADEON_NEW_MEMMAP}, \
+   {0x1002, 0x6791, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_TAHITI|RADEON_NEW_MEMMAP}, \
+   {0x1002, 0x6792, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_TAHITI|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6798, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_TAHITI|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6799, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_TAHITI|RADEON_NEW_MEMMAP}, \
{0x1002, 0x679A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_TAHITI|RADEON_NEW_MEMMAP}, \
@@ -217,6 +219,7 @@
{0x1002, 0x6808, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6809, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6810, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \
+   {0x1002, 0x6811, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6816, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6817, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6818, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \
-- 
1.7.7.5

[Bug 56038] New: "r100_ring_test] ERROR" messages sometimes on boot with ati radeon 9000 AGP ( r200 driver, dri2 KMS enabled )

2012-10-16 Thread bugzilla-dae...@freedesktop.org

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

  Priority: medium
Bug ID: 56038
  Assignee: dri-devel at lists.freedesktop.org
   Summary: "r100_ring_test] *ERROR*" messages sometimes on boot
with ati radeon 9000 AGP ( r200 driver, dri2 KMS
enabled )
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: mister.freeman at laposte.net
  Hardware: x86 (IA32)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 68625
  --> https://bugs.freedesktop.org/attachment.cgi?id=68625=edit
dmesg output

randomly ( it's very rare, 90% of the time I don't have this error message ) I
can see these error messages on boot :

[1.516518] [drm] Loading R200 Microcode
[1.517953] [drm] radeon: ring at 0xE0001000
[1.665941] [drm:r100_ring_test] *ERROR* radeon: ring test failed
(scratch(0x15E4)=0xCAFEDEAD)
[1.665996] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
[1.666043] radeon :01:00.0: failed initializing CP (-22).
[1.666084] radeon :01:00.0: Disabling GPU acceleration
[1.812455] [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting
down CP.
[1.812600] [drm] radeon: cp finalized
[1.812629] [drm] radeon: cp finalized

but the boot process continues and I see no problem on KDE4.9.2 and 3d games,

this bug occurs since the update of ati-dri 9.0 and xorg packages 1.13 on my
archlinux 32 bits installation, before that I had never seen this kind of error
message

my system :

- archlinux 32 bits
- laptop pentium 4 2.4 ghz 1,2 Gb ram
- video card: ati radeon 9000 agp ( M9 rv250, r200 driver, dri2 enabled with
kms early start )
- SIS645DX chipset on motherboard

You can fin an attachment ( dmesg output ) with this message,

this bug may related to another ( startx problems ) :

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

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

[Bug 56042] New: [865G] BadAlloc (insufficient resources for operation)

2012-10-16 Thread bugzilla-dae...@freedesktop.org

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

  Priority: medium
Bug ID: 56042
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [865G] BadAlloc (insufficient resources for operation)
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: goetzchrist at yahoo.es
  Hardware: x86 (IA32)
Status: NEW
   Version: 9.0
 Component: Drivers/DRI/i830
   Product: Mesa

Created attachment 68637
  --> https://bugs.freedesktop.org/attachment.cgi?id=68637=edit
dmesg

When I run glxinfo, or any 3D application, the app doesn't start, and I only
get this error. With Mesa 8.0.4 there was no problem.

$ glxinfo 
name of display: :0
X Error of failed request:  BadAlloc (insufficient resources for operation)
  Major opcode of failed request:  153 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Serial number of failed request:  22
  Current serial number in output stream:  25

---

Linux 3.6.2
X Server 1.13.0
libdrm 2.4.39
xf86-video-intel 2.20.10

00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics
Controller (rev 02) (prog-if 00 [VGA controller])
Subsystem: ASRock Incorporation Device 2572
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-  [disabled]
Capabilities: [d0] Power Management version 1
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915

I don't know what information should I provide.

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

[Bug 56042] [865G] BadAlloc (insufficient resources for operation)

2012-10-16 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #1 from G?tz  ---
Created attachment 68638
  --> https://bugs.freedesktop.org/attachment.cgi?id=68638=edit
Xorg.0.log

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

linux-next: Tree for Oct 16 (readeon_legacy)

2012-10-16 Thread Randy Dunlap

On 10/15/2012 08:58 PM, Stephen Rothwell wrote:

> Hi all,
> 
> The merge window has closed, feel free to add new stuff again.
> 
> Changes since 201201015:
> 


on x86_64:

drivers/built-in.o: In function `radeon_asic_init':
(.text+0xd3c71): undefined reference to `radeon_legacy_set_backlight_level'
drivers/built-in.o:(.data+0x20490): undefined reference to 
`radeon_legacy_set_backlight_level'
drivers/built-in.o:(.data+0x20498): undefined reference to 
`radeon_legacy_get_backlight_level'
drivers/built-in.o:(.data+0x20710): undefined reference to 
`radeon_legacy_set_backlight_level'
drivers/built-in.o:(.data+0x20718): undefined reference to 
`radeon_legacy_get_backlight_level'
drivers/built-in.o:(.data+0x20990): undefined reference to 
`radeon_legacy_set_backlight_level'
drivers/built-in.o:(.data+0x20998): undefined reference to 
`radeon_legacy_get_backlight_level'
drivers/built-in.o:(.data+0x20c10): undefined reference to 
`radeon_legacy_set_backlight_level'
drivers/built-in.o:(.data+0x20c18): undefined reference to 
`radeon_legacy_get_backlight_level'
drivers/built-in.o:(.data+0x21110): undefined reference to 
`radeon_legacy_set_backlight_level'
drivers/built-in.o:(.data+0x21118): undefined reference to 
`radeon_legacy_get_backlight_level'


Full randconfig file is attached.
CONFIG_BACKLIGHT_CLASS_DEVICE is not enabled.

-- 
~Randy
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: config-r8139
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121016/60d43107/attachment-0001.ksh>

[PATCH] dma-buf: Use EXPORT_SYMBOL

2012-10-16 Thread Robert Morell

On Wed, Oct 10, 2012 at 11:57:15PM -0700, Hans Verkuil wrote:
> On Wed October 10 2012 23:02:06 Rob Clark wrote:
> > On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox  
> > wrote:
> > > On Wed, 10 Oct 2012 08:56:32 -0700
> > > Robert Morell  wrote:
> > >
> > >> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> > >> issue, and not really an interface".  The dma-buf infrastructure is
> > >> explicitly intended as an interface between modules/drivers, so it
> > >> should use EXPORT_SYMBOL instead.
> > >
> > > NAK. This needs at the very least the approval of all rights holders for
> > > the files concerned and all code exposed by this change.
> > 
> > Well, for my contributions to dmabuf, I don't object.. and I think
> > because we are planning to use dma-buf in userspace for dri3 /
> > dri-next, I think that basically makes it a userspace facing kernel
> > infrastructure which would be required for open and proprietary
> > drivers alike.  So I don't see much alternative to making this
> > EXPORT_SYMBOL().  Of course, IANAL.
> 
> The whole purpose of this API is to let DRM and V4L drivers share buffers for
> zero-copy pipelines. Unfortunately it is a fact that several popular DRM 
> drivers
> are closed source. So we have a choice between keeping the export symbols GPL
> and forcing those closed-source drivers to make their own incompatible API,
> thus defeating the whole point of DMABUF, or using EXPORT_SYMBOL and letting
> the closed source vendors worry about the legality. They are already using 
> such
> functions (at least nvidia is), so they clearly accept that risk.
> 
> I prefer the evil where the DMABUF API uses EXPORT_SYMBOL to prevent the worse
> evil where an incompatible API is created to work around the EXPORT_SYMBOL_GPL
> limitation. Neither situation is paradise, but at least one is a slightly less
> depressing world than the other :-)
> 
> In other words, I'm OK with EXPORT_SYMBOL for whatever it is worth as I did 
> not
> do any coding but only some initial design help and reviewing.

Thanks for the discussion.

My intention is not to steal any code from the kernel or change any licenses.
The goal here is to allow interoperation between drivers.  I understand that it
can be difficult to debug the kernel when the nvidia binary module is loaded;
I'm not trying to force anyone to do that.  You're free to continue to use your
debug environment without change after this patch is applied.

I believe that the developers and maintainers of dma-buf have provided
the needed signoff, both in person and in this thread.  If there are any
objections from that group, I'm happy to discuss any changes necessary to get
this merged.

- Robert

linux-next: Tree for Oct 16 (readeon_legacy)

2012-10-16 Thread Alex Deucher

On Tue, Oct 16, 2012 at 4:05 PM, Randy Dunlap  wrote:
> On 10/15/2012 08:58 PM, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> The merge window has closed, feel free to add new stuff again.
>>
>> Changes since 201201015:
>>

patch already sent to Dave:
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=cd23492af3d4401c02c48a4bebe5995c9498eac5

Alex

>
>
> on x86_64:
>
> drivers/built-in.o: In function `radeon_asic_init':
> (.text+0xd3c71): undefined reference to `radeon_legacy_set_backlight_level'
> drivers/built-in.o:(.data+0x20490): undefined reference to 
> `radeon_legacy_set_backlight_level'
> drivers/built-in.o:(.data+0x20498): undefined reference to 
> `radeon_legacy_get_backlight_level'
> drivers/built-in.o:(.data+0x20710): undefined reference to 
> `radeon_legacy_set_backlight_level'
> drivers/built-in.o:(.data+0x20718): undefined reference to 
> `radeon_legacy_get_backlight_level'
> drivers/built-in.o:(.data+0x20990): undefined reference to 
> `radeon_legacy_set_backlight_level'
> drivers/built-in.o:(.data+0x20998): undefined reference to 
> `radeon_legacy_get_backlight_level'
> drivers/built-in.o:(.data+0x20c10): undefined reference to 
> `radeon_legacy_set_backlight_level'
> drivers/built-in.o:(.data+0x20c18): undefined reference to 
> `radeon_legacy_get_backlight_level'
> drivers/built-in.o:(.data+0x21110): undefined reference to 
> `radeon_legacy_set_backlight_level'
> drivers/built-in.o:(.data+0x21118): undefined reference to 
> `radeon_legacy_get_backlight_level'
>
>
> Full randconfig file is attached.
> CONFIG_BACKLIGHT_CLASS_DEVICE is not enabled.
>
> --
> ~Randy
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH 01/11] drm: add drm_send_vblank_event() helper (v5)

2012-10-16 Thread Rob Clark

From: Rob Clark 

A helper that drivers can use to send vblank event after a pageflip.
If the driver doesn't support proper vblank irq based time/seqn then
just pass -1 for the pipe # to get do_gettimestamp() behavior (since
there are a lot of drivers that don't use drm_vblank_count_and_time())

Also an internal send_vblank_event() helper for the various other code
paths within drm_irq that also need to send vblank events.

v1: original
v2: add back 'vblwait->reply.sequence = seq' which should not have
been deleted
v3: add WARN_ON() in case lock is not held and comments
v4: use WARN_ON_SMP() instead to fix issue with !SMP && !DEBUG_SPINLOCK
as pointed out by Marcin Slusarz
v5: update docbook

Signed-off-by: Rob Clark 
---
 Documentation/DocBook/drm.tmpl |   20 +++
 drivers/gpu/drm/drm_irq.c  |   74 
 include/drm/drmP.h |2 ++
 3 files changed, 59 insertions(+), 37 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index b030052..c9cbb3f 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -1141,23 +1141,13 @@ int max_width, max_height;
 the page_flip operation will be called 
with a
 non-NULL event argument pointing to a
 drm_pending_vblank_event instance. Upon 
page
-flip completion the driver must fill the
-event::event
-sequence, 
tv_sec
-and tv_usec fields with the associated
-vertical blanking count and timestamp, add the event to the
-drm_file list of events to be signaled, and 
wake
-up any waiting process. This can be performed with
+flip completion the driver must call 
drm_send_vblank_event
+to fill in the event and send to wake up any waiting processes.
+This can be performed with
 
   
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 076c4a8..9bdcfd5 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -802,6 +802,46 @@ u32 drm_vblank_count_and_time(struct drm_device *dev, int 
crtc,
 }
 EXPORT_SYMBOL(drm_vblank_count_and_time);

+static void send_vblank_event(struct drm_device *dev,
+   struct drm_pending_vblank_event *e,
+   unsigned long seq, struct timeval *now)
+{
+   WARN_ON_SMP(!spin_is_locked(>event_lock));
+   e->event.sequence = seq;
+   e->event.tv_sec = now->tv_sec;
+   e->event.tv_usec = now->tv_usec;
+
+   list_add_tail(>base.link,
+ >base.file_priv->event_list);
+   wake_up_interruptible(>base.file_priv->event_wait);
+   trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
+e->event.sequence);
+}
+
+/**
+ * drm_send_vblank_event - helper to send vblank event after pageflip
+ * @dev: DRM device
+ * @crtc: CRTC in question
+ * @e: the event to send
+ *
+ * Updates sequence # and timestamp on event, and sends it to userspace.
+ * Caller must hold event lock.
+ */
+void drm_send_vblank_event(struct drm_device *dev, int crtc,
+   struct drm_pending_vblank_event *e)
+{
+   struct timeval now;
+   unsigned int seq;
+   if (crtc >= 0) {
+   seq = drm_vblank_count_and_time(dev, crtc, );
+   } else {
+   seq = 0;
+   do_gettimeofday();
+   }
+   send_vblank_event(dev, e, seq, );
+}
+EXPORT_SYMBOL(drm_send_vblank_event);
+
 /**
  * drm_update_vblank_count - update the master vblank counter
  * @dev: DRM device
@@ -936,6 +976,13 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
 }
 EXPORT_SYMBOL(drm_vblank_put);

+/**
+ * drm_vblank_off - disable vblank events on a CRTC
+ * @dev: DRM device
+ * @crtc: CRTC in question
+ *
+ * Caller must hold event lock.
+ */
 void drm_vblank_off(struct drm_device *dev, int crtc)
 {
struct drm_pending_vblank_event *e, *t;
@@ -955,15 +1002,9 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
DRM_DEBUG("Sending premature vblank event on disable: \
  wanted %d, current %d\n",
  e->event.sequence, seq);
-
-   e->event.sequence = seq;
-   e->event.tv_sec = now.tv_sec;
-   e->event.tv_usec = now.tv_usec;
+   list_del(>base.link);
drm_vblank_put(dev, e->pipe);
-   list_move_tail(>base.link, >base.file_priv->event_list);
-   wake_up_interruptible(>base.file_priv->event_wait);
-   trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
-e->event.sequence);
+   send_vblank_event(dev, e, seq, );
}

spin_unlock_irqrestore(>vbl_lock, irqflags);
@@ -1107,15 +1148,9 @@ static int drm_queue_vblank_event(struct drm_device 
*dev, int pipe,

[BUG] 3.7-rc1: nouveau: NULL pointer dereference at nouveau_channel_new

2012-10-16 Thread Ortwin Glück

This is a regression towards 3.6. Occurs when starting X.

I had already reported this before -rc1, but nobody listened.

-- next part --
Oct 16 18:27:04 localhost kernel: Initializing cgroup subsys cpu
Oct 16 18:27:04 localhost kernel: Linux version 3.7.0-rc1 (root at ortwin-hp) 
(gcc version 4.5.4 (Gentoo 4.5.4 p1.0, pie-0.4.7) ) #1 SMP PREEMPT Tue Oct 16 
18:24:16 CEST 2012
Oct 16 18:27:04 localhost kernel: Command line: root=/dev/sda1 rootfstype=ext4 
nouveau.noaccel=1
Oct 16 18:27:04 localhost kernel: e820: BIOS-provided physical RAM map:
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0x-0x0009fbff] usable
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0x0009fc00-0x0009] reserved
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0x000e-0x000f] reserved
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0x0010-0xbefc1fff] usable
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0xbefc2000-0xbf6c1fff] reserved
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0xbf6c2000-0xbf7c1fff] ACPI NVS
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0xbf7c2000-0xbf7fefff] ACPI data
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0xbf7ff000-0xbf7f] usable
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0xbf80-0xbfff] reserved
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0xe000-0xefff] reserved
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0xfec0-0xfec00fff] reserved
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0xfed1-0xfed13fff] reserved
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0xfed19000-0xfed19fff] reserved
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0xfed1b000-0xfed1] reserved
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0xfee0-0xfee00fff] reserved
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0xffd0-0x] reserved
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0x0001-0x0001fbff] usable
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0x0001fc00-0x0001] reserved
Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 
0x0002-0x00023bff] usable
Oct 16 18:27:04 localhost kernel: NX (Execute Disable) protection: active
Oct 16 18:27:04 localhost kernel: DMI 2.6 present.
Oct 16 18:27:04 localhost kernel: DMI: Hewlett-Packard HP EliteBook 8540w/1521, 
BIOS 68CVD Ver. F.0E 11/25/2010
Oct 16 18:27:04 localhost kernel: e820: update [mem 0x-0x] 
usable ==> reserved
Oct 16 18:27:04 localhost kernel: e820: remove [mem 0x000a-0x000f] 
usable
Oct 16 18:27:04 localhost kernel: No AGP bridge found
Oct 16 18:27:04 localhost kernel: e820: last_pfn = 0x23c000 max_arch_pfn = 
0x4
Oct 16 18:27:04 localhost kernel: MTRR default type: uncachable
Oct 16 18:27:04 localhost kernel: MTRR fixed ranges enabled:
Oct 16 18:27:04 localhost kernel: 0-9 write-back
Oct 16 18:27:04 localhost kernel: A-B uncachable
Oct 16 18:27:04 localhost kernel: C-F write-protect
Oct 16 18:27:04 localhost kernel: MTRR variable ranges enabled:
Oct 16 18:27:04 localhost kernel: 0 base 0FFC0 mask FFFC0 write-protect
Oct 16 18:27:04 localhost kernel: 1 base 0 mask F8000 write-back
Oct 16 18:27:04 localhost kernel: 2 base 08000 mask FC000 write-back
Oct 16 18:27:04 localhost kernel: 3 base 1 mask F write-back
Oct 16 18:27:04 localhost kernel: 4 base 2 mask FC000 write-back
Oct 16 18:27:04 localhost kernel: 5 base 23C00 mask FFC00 uncachable
Oct 16 18:27:04 localhost kernel: 6 disabled
Oct 16 18:27:04 localhost kernel: 7 disabled
Oct 16 18:27:04 localhost kernel: x86 PAT enabled: cpu 0, old 0x7040600070406, 
new 0x7010600070106
Oct 16 18:27:04 localhost kernel: e820: last_pfn = 0xbf800 max_arch_pfn = 
0x4
Oct 16 18:27:04 localhost kernel: initial memory mapped: [mem 
0x-0x1fff]
Oct 16 18:27:04 localhost kernel: Base memory trampoline at [88099000] 
99000 size 24576
Oct 16 18:27:04 localhost kernel: init_memory_mapping: [mem 
0x-0xbf7f]
Oct 16 18:27:04 localhost kernel: [mem 0x-0xbf7f] page 2M
Oct 16 18:27:04 localhost kernel: kernel direct mapping tables up to 0xbf7f 
@ [mem 0x1fa0-0x1fff]
Oct 16 18:27:04 localhost kernel: init_memory_mapping: [mem 
0x1-0x23bff]
Oct 16 18:27:04 localhost kernel: [mem 0x1-0x23bff] page 2M
Oct 16 18:27:04 localhost kernel: kernel direct mapping tables up to 
0x23bff @ [mem 0xbefb8000-0xbefc1fff]
Oct 16 18:27:04 localhost kernel: ACPI: RSDP 000fddc0 00024 (v02 HPQOEM)
Oct 16 18:27:04 localhost kernel: ACPI: XSDT bf7fe120 00094 (v01 HPQOEM 
SLIC-MPC

65 matches

Mail list logo