[Bug 17902] [830M] need support for DVO-LVDS via na2501

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

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

--- Comment #67 from Gilles Dartiguelongue  
2012-04-17 15:45:56 PDT ---
Ok, forget that, I rebooted without kms disabled and now I get 28 i2c/smbus
devices (most likely duplicates). Now scanning:

i2c-9i2c   i915 gmbus dpb  I2C adapter
i2c-10i2c   i915 GPIOE  I2C adapter

gives:

# i2cdetect -y 9
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

and 

# i2cdump -y 9 0x38
No size specified (using byte-data access)
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f0123456789abcdef
00: 05 13 26 67 01 a5 19 a2 31 97 81 ff 00 04 00 00??1??..?..
10: 00 a0 02 02 02 02 02 02 07 00 00 11 54 03 02 40...?T??@
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 03 ff 00 28 88 88 00 00 00 00 00 00?..(??..
40: 80 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00?..?
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 11 00 00 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0?..?
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00..?.
80: ff 07 3d 05 00 00 00 00 00 00 00 00 10 02 10 00.?=????.
90: ff 07 a0 02 00 00 05 00 00 00 88 00 24 00 25 03.???..?...?.$.%?
a0: 28 01 28 05 84 00 00 00 00 04 70 4f 00 00 03 03(?(???pO..??
b0: 00 00 00 00 00 00 09 03 00 a0 00 20 33 33 33 33..??.?. 
c0: 05 90 00 0f 03 16 00 02 02 00 00 00 00 00 00 00??.???.??...
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 98 00 80 00 00 00 80 00 00 00 00 00 00 00..?.?...?...
f0: 71 77 b3 90 00 00 00 88 0a 0f 0a 0a 0a 0a 0a 0aqw??...?

So 1305 and 6726 actually look like the first registers indicated in the
datasheet.

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

Regression: black screen on VGA w/ nouveau in Linux 3.3

[Nick Bowler]

On 2012-04-03 21:27 -0400, Nick Bowler wrote:
> CCing Tom Bylander as he sent me a mail off-list saying he experiences
> a similar issue on an FX 5200.
> 
> Tom, maybe you'll have better luck bisecting this than I did?
> 
> On 2012-03-19 10:35 -0400, Nick Bowler wrote:
> > Just upgraded to Linux 3.3 on my desktop and noticed that the VGA output
> > on my card w/ nouveau is totally black (both at the console and in X).
> > Almost everything appears to work normally: DPMS works, modesetting
> > works, DDC works... all messages indicate that things are working --
> > just the image is completely black.
> 
> OK, so this is still reproducible on Linux 3.4-rc1+ (Linus' master).  I
> captured the dmesg output before (3.2.13, which is a working kernel),
> and after (3.3.1 and 3.4-rc1-00144-g01627d9 - both fail in an identical
> manner).  All three logs are attached in full (gzipped).

Ping?  I'm still seeing this on 3.4-rc3+.  Is there any other info that
I need to provide?

> One thing that immediately jumps out is the WARNING in the 3.4-rc1+ log
> that occurs early and did not appear in either of the other logs:
> 
> [ cut here ]
> WARNING: at /home/nick/misc/linux-2.6/arch/x86/pci/i386.c:60
> pcibios_fwaddrmap_lookup+0x1d/0x3d()
> Hardware name: K8N-E-Deluxe
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 3.4.0-rc1-00144-g01627d9 #47
> Call Trace:
>  [] warn_slowpath_common+0x80/0x98
>  [] warn_slowpath_null+0x15/0x17
>  [] pcibios_fwaddrmap_lookup+0x1d/0x3d
>  [] pcibios_allocate_resources+0xd4/0x217
>  [] ? pci_legacy_init+0x3e/0x3e
>  [] pcibios_resource_survey+0x17/0x2d
>  [] pcibios_init+0x28/0x3a
>  [] pci_subsys_init+0x47/0x4d
>  [] do_one_initcall+0x78/0x126
>  [] kernel_init+0xe9/0x17a
>  [] ? rdinit_setup+0x28/0x28
>  [] kernel_thread_helper+0x4/0x10
>  [] ? start_kernel+0x321/0x321
>  [] ? gs_change+0xb/0xb
> ---[ end trace 4eaa2a86a8e2da22 ]---
> 
> Other than that, I diffed the 3.2.13 log and 3.4-rc1+ log and grepped
> for nouveau-related differences.  I see no obvious errors, but I admit
> that I don't really know what to look for.
> 
> % diff -u nouveau-3.2.13.log nouveau-3.4-rc1+.log | grep -C3 '\[drm\]'
> 
> @@ -418,19 +429,21 @@
>  Real Time Clock Driver v1.12b
>  Linux agpgart interface v0.103
>  [drm] Initialized drm 1.1.0 20060810
> +VGA switcheroo: detected Optimus DSM method \ handle
>  ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 19
> -nouveau :01:00.0: PCI INT A -> Link[LNKE] -> GSI 19 (level, low) -> IRQ 
> 19
>  [drm] nouveau :01:00.0: Detected an NV30 generation card (0x436200a1)
> -[drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN
> +[drm] nouveau :01:00.0: Checking PRAMIN for VBIOS
>  [drm] nouveau :01:00.0: ... appears to be valid
> +[drm] nouveau :01:00.0: Using VBIOS from PRAMIN
>  [drm] nouveau :01:00.0: BMP BIOS found
>  [drm] nouveau :01:00.0: BMP version 5.40
>  [drm] nouveau :01:00.0: Bios version 04.36.20.21
> -[drm] nouveau :01:00.0: Found Display Configuration Block version 2.2
> -[drm] nouveau :01:00.0: Raw DCB entry 0: 01000300 9c40
> -[drm] nouveau :01:00.0: Raw DCB entry 1: 02010310 9c40
> -[drm] nouveau :01:00.0: Raw DCB entry 2: 04000302 
> -[drm] nouveau :01:00.0: Raw DCB entry 3: 02020321 0303
> +[drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do
> +[drm] nouveau :01:00.0: DCB version 2.2
> +[drm] nouveau :01:00.0: DCB outp 00: 01000300 9c40
> +[drm] nouveau :01:00.0: DCB outp 01: 02010310 9c40
> +[drm] nouveau :01:00.0: DCB outp 02: 04000302 
> +[drm] nouveau :01:00.0: DCB outp 03: 02020321 0303
>  [drm] nouveau :01:00.0: Loading NV17 power sequencing microcode
>  [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xF01D
>  [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xF4E1
> @@ -439,11 +452,10 @@
>  [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xF8B3
>  [drm] nouveau :01:00.0: Parsing VBIOS init table 5 at offset 0xF8D0
>  [drm] nouveau :01:00.0: Parsing VBIOS init table 6 at offset 0xF959
> -[drm] nouveau :01:00.0: 0 available performance level(s)
> -[drm] nouveau :01:00.0: c: core 425MHz memory 501MHz voltage 1350mV
> -[TTM] Zone  kernel: Available graphics memory: 512160 kiB.
> -[TTM] Initializing pool allocator.
> -[drm] nouveau :01:00.0: Detected 256MiB VRAM
> +[TTM] Zone  kernel: Available graphics memory: 512142 kiB
> +[TTM] Initializing pool allocator
> +[TTM] Initializing DMA pool allocator
> +[drm] nouveau :01:00.0: Detected 256MiB VRAM (DDR1)
>  agpgart-amd64 :00:00.0: AGP 3.0 bridge
>  agpgart: swapper tried to set rate=x12. Setting to AGP3 x8 mode.
>  agpgart-amd64 :00:00.0: putting AGP V3 device into 8x mode
> @@ -452,11 +464,14 @@
>  [drm] nouveau :01:00.0: Saving VGA fonts
>  [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>  [drm] No driver support for vblank 

[PATCH] radeon: fix r600/agp when vram is after AGP (v2)

[Dave Airlie]

From: Dave Airlie 

If AGP is placed in the middle, the size_af is off-by-one, it results
in VRAM being placed at 0x7fff instead of 0x800.

v2: fix the vram_start setup.

Reported-by: russiane39 on #radeon

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/r600.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 4added1..f85479e 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1135,7 +1135,7 @@ static void r600_vram_gtt_location(struct radeon_device 
*rdev, struct radeon_mc
}
if (rdev->flags & RADEON_IS_AGP) {
size_bf = mc->gtt_start;
-   size_af = 0x - mc->gtt_end + 1;
+   size_af = 0x - mc->gtt_end;
if (size_bf > size_af) {
if (mc->mc_vram_size > size_bf) {
dev_warn(rdev->dev, "limiting VRAM\n");
@@ -1149,7 +1149,7 @@ static void r600_vram_gtt_location(struct radeon_device 
*rdev, struct radeon_mc
mc->real_vram_size = size_af;
mc->mc_vram_size = size_af;
}
-   mc->vram_start = mc->gtt_end;
+   mc->vram_start = mc->gtt_end + 1;
}
mc->vram_end = mc->vram_start + mc->mc_vram_size - 1;
dev_info(rdev->dev, "VRAM: %lluM 0x%08llX - 0x%08llX (%lluM 
used)\n",
-- 
1.7.7.6

[PATCH] radeon: fix r600/agp when vram is after AGP

[Dave Airlie]

From: Dave Airlie 

If AGP is placed in the middle, the size_af is off-by-one, it results
in VRAM being placed at 0x7fff instead of 0x800.

Reported-by: russiane39 on #radeon

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/r600.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 4added1..121944c 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1135,7 +1135,7 @@ static void r600_vram_gtt_location(struct radeon_device 
*rdev, struct radeon_mc
}
if (rdev->flags & RADEON_IS_AGP) {
size_bf = mc->gtt_start;
-   size_af = 0x - mc->gtt_end + 1;
+   size_af = 0x - mc->gtt_end;
if (size_bf > size_af) {
if (mc->mc_vram_size > size_bf) {
dev_warn(rdev->dev, "limiting VRAM\n");
-- 
1.7.7.6

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

[Laurent Pinchart]

Hi Marek,

On Tuesday 17 April 2012 13:25:56 Marek Szyprowski wrote:
> On Tuesday, April 17, 2012 2:41 AM Laurent Pinchart wrote:
> 
> (snipped)
> 
> > > >> +static struct vm_area_struct *vb2_dc_get_user_vma(
> > > >> +  unsigned long start, unsigned long size)
> > > >> +{
> > > >> +  struct vm_area_struct *vma;
> > > >> +
> > > >> +  /* current->mm->mmap_sem is taken by videobuf2 core */
> > > >> +  vma = find_vma(current->mm, start);
> > > >> +  if (!vma) {
> > > >> +  printk(KERN_ERR "no vma for address %lu\n", start);
> > > >> +  return ERR_PTR(-EFAULT);
> > > >> +  }
> > > >> +
> > > >> +  if (vma->vm_end - vma->vm_start < size) {
> > > >> +  printk(KERN_ERR "vma at %lu is too small for %lu 
> > > >> bytes\n",
> > > >> +  start, size);
> > > >> +  return ERR_PTR(-EFAULT);
> > > >> +  }
> > > > 
> > > > Should we support multiple VMAs, or do you think that's not worth it ?
> > > 
> > > What do you mean by multiple VMAs?
> > 
> > I mean multiple VMAs for a single userspace buffer. It's probably
> > overkill, but I'm not familiar enough with the memory management code to
> > be sure. Do you have more insight ?
> 
> Multiple VMAs means that userspace did something really hacky in the
> specified address range, I'm really convinced that we should not bother
> supporting such cases.

I agree. I just wanted to make sure that I wasn't forgetting an important use 
case.

> With user pointer mode You usually want to get access to either anonymous
> pages (malloc and friends) or the memory somehow allocated by the other
> device (mmaped to userspace). In both cases it available as a single VMA.
> VMAs with anonymous memory are merged together if they get extended to meet
> side-by-side each other.
> 
> > > >> +  vma = vb2_get_vma(vma);
> > > >> +  if (!vma) {
> > > >> +  printk(KERN_ERR "failed to copy vma\n");
> > > >> +  return ERR_PTR(-ENOMEM);
> > > >> +  }
> > > > 
> > > > I still think there's no need to copy the VMA. get_user_pages() will
> > > > make sure the memory doesn't get paged out, and we don't need to
> > > > ensure that the userspace mapping stays in place as our cache
> > > > operations use a scatter list. Storing the result of vma_is_io() in
> > > > vb2_dc_buf should be enough.
> > > 
> > > As I understand calling get_user_pages ensures that pages are not going
> > > to be swapped or freed. I agree that it provides enough protection for
> > > the memory.
> > > 
> > > IO mappings are the problem. As you mentioned few mails ago get_page
> > > would likely crash for such pages. AFAIK increasing reference count for
> > > VMA could be a reliable mechanism for protecting the memory from being
> > > freed.
> > 
> > The main use case here (which is actually the only use case I have
> > encountered) is memory reserved at boot time to be used by specific
> > devices such as frame buffers. That memory will never be paged out, so I
> > don't think there's an issue here. Regarding freeing, it will likely not
> > be freed either, and if it does, I doubt that duplicating the VMA will
> > make any difference.
>
> We use user pointer method also to access buffers allocated dynamically by
> other v4l2 devices (we have quite a lot of the in our system). In this case
> duplicating VMA is necessary.
> 
> > > The problem is that VMA has no reference counters in it. Calling open
> > > ops will protect the memory. However it will not protect VMA structure
> > > from being freed!
> > > 
> > > Analyze following scenario:
> > > 
> > > - mmap -> returns userptr
> > > - qbuf (userptr)
> > > - unmap (userptr)
> > > - dqbuf
> > > 
> > > The VMA will be destroyed at unmap but memory will not be released.
> > > 
> > > The reason is that open ops was called at qbuf.
> > 
> > I think I see your point. You want to make sure that the exporter driver
> > (on which mmap() has been called) will not release the memory, and to do
> > so you call the exporter's open() vm operation when you acquire the
> > memory. To call the exporter's close() operation when you release the
> > memory you need a pointer to the VMA, but the original VMA might have
> > disappeared. To work around the problem you make a copy of the VMA and
> > use it when releasing the memory.
> > 
> > That's a pretty dirty hack. Most of the copy VMA fields will be invalid
> > when you use it. On a side note, would storing vm_ops and vm_private_data
> > be enough ? I'm also not sure if we need to call get_file() and
> > put_file().
> 
> This code is there from the beginning of the videobuf2. The main problem is
> the fact that you cannot get a reliable access to user pointer memory which
> is not described with anonymous pages. The hacks/workarounds we use at
> works really well with the memory mmaped by the other v4l2 devices (which
> use vm_open/ vm_close refcounting) and framebuffers which use no
> refcounting on vma, but we force 

[Intel-gfx] [PATCH 00/12] Add more DMT and common modes

[Takashi Iwai]

At Tue, 17 Apr 2012 17:33:17 +0200,
Takashi Iwai wrote:
> 
> At Fri, 13 Apr 2012 16:33:28 -0400,
> Adam Jackson wrote:
> > 
> > Incorporates some feedback from Rodrigo and Takashi.  Major themes of the
> > series:
> > 
> > - Fix the DMT list to include reduced-blanking modes
> > - Add modes from DMT for any range descriptor type
> > - Add an extra modes list for things not in DMT
> > - For ranges that specify a formula, generate timings from the extra modes
> > 
> > This still doesn't address the driver policy decision of "I know I have
> > a scaler, add modes as if there were a range descriptor even if there's
> > not one".  But it should at least make clear what such a helper function
> > should do.
> 
> I tried these patches now with a few monitors here and it looks
> working well (after fixing the alignment as I posted in another
> mail).  I got new 1600x900 output on two monitors.  Yay!

Oh, feel free to add my tested-by tag:

Tested-by: Takashi Iwai 


thanks,

Takashi

[Intel-gfx] [PATCH 00/12] Add more DMT and common modes

[Takashi Iwai]

At Fri, 13 Apr 2012 16:33:28 -0400,
Adam Jackson wrote:
> 
> Incorporates some feedback from Rodrigo and Takashi.  Major themes of the
> series:
> 
> - Fix the DMT list to include reduced-blanking modes
> - Add modes from DMT for any range descriptor type
> - Add an extra modes list for things not in DMT
> - For ranges that specify a formula, generate timings from the extra modes
> 
> This still doesn't address the driver policy decision of "I know I have
> a scaler, add modes as if there were a range descriptor even if there's
> not one".  But it should at least make clear what such a helper function
> should do.

I tried these patches now with a few monitors here and it looks
working well (after fixing the alignment as I posted in another
mail).  I got new 1600x900 output on two monitors.  Yay!

I guess this will solve major of problems we've face for HD+ panel.
The rest is the 1366x768 mode, but it's often covered by 1360x768.
So, once when LVDS gets additional de facto standard modes, it'll be
fixed as well.


thanks,

Takashi

[Intel-gfx] [PATCH 00/12] Add more DMT and common modes

[Takashi Iwai]

At Fri, 13 Apr 2012 16:56:26 -0400,
Adam Jackson wrote:
> 
> On 4/13/12 4:33 PM, Adam Jackson wrote:
> > Incorporates some feedback from Rodrigo and Takashi.  Major themes of the
> > series:
> >
> > - Fix the DMT list to include reduced-blanking modes
> > - Add modes from DMT for any range descriptor type
> > - Add an extra modes list for things not in DMT
> > - For ranges that specify a formula, generate timings from the extra modes
> >
> > This still doesn't address the driver policy decision of "I know I have
> > a scaler, add modes as if there were a range descriptor even if there's
> > not one".  But it should at least make clear what such a helper function
> > should do.
> 
> One minor buglet in this series that's not obvious from inspection (and 
> that I didn't realize until just now) is that putting 1366x768 in the 
> minimode list won't do what you want, since the mode you get back will 
> be 1368x768.  Probably we should move the manual-underscan hack into the 
> timing generators themselves.

Sounds like a good compromise.  We have already hacks in drm_edid.c
for HDMI TV, so one exception more isn't that bad ;)


Takashi

[Intel-gfx] [PATCH 09/12] drm/edid: Update range descriptor struct for EDID 1.4

[Takashi Iwai]

At Fri, 13 Apr 2012 16:33:37 -0400,
Adam Jackson wrote:
> 
> Signed-off-by: Adam Jackson 
> ---
>  include/drm/drm_edid.h |   26 --
>  1 files changed, 20 insertions(+), 6 deletions(-)
> 
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index bcb9a66..8cefbbe 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -90,12 +90,26 @@ struct detailed_data_monitor_range {
>   u8 min_hfreq_khz;
>   u8 max_hfreq_khz;
>   u8 pixel_clock_mhz; /* need to multiply by 10 */
> - __le16 sec_gtf_toggle; /* A000=use above, 20=use below */
> - u8 hfreq_start_khz; /* need to multiply by 2 */
> - u8 c; /* need to divide by 2 */
> - __le16 m;
> - u8 k;
> - u8 j; /* need to divide by 2 */
> + u8 flags;
> + union {
> + struct {
> + u8 reserved;
> + u8 hfreq_start_khz; /* need to multiply by 2 */
> + u8 c; /* need to divide by 2 */
> + __le16 m;
> + u8 k;
> + u8 j; /* need to divide by 2 */
> + } gtf2;
> + struct {
> + u8 version;
> + u8 data1; /* high 6 bits: extra clock resolution */
> + u8 data2; /* plus low 2 of above: max hactive */
> + u8 supported_aspects;
> + u8 flags; /* preferred aspect and blanking support */
> + u8 supported_scalings;
> + u8 preferred_refresh;
> + } cvt;

These new structs must be marked with __attribute__((packed)) although
the struct detailed_data_monitor_range itself is already marked.  At
least, with gcc 4.6 and x86-64 here, they get unaligned.


thanks,

Takashi

> + } formula;
>  } __attribute__((packed));
>  
>  struct detailed_data_wpindex {
> -- 
> 1.7.7.6
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

[PATCH] radeon: fix r600/agp when vram is after AGP (v3)

[Alex Deucher]

On Tue, Apr 17, 2012 at 4:51 PM,   wrote:
> From: Jerome Glisse 
>
> If AGP is placed in the middle, the size_af is off-by-one, it results
> in VRAM being placed at 0x7fff instead of 0x800.
>
> v2: fix the vram_start setup.
> v3: also fix r7xx & newer ASIC
>
> Reported-by: russiane39 on #radeon
>
> Signed-off-by: Dave Airlie 
> Signed-off-by: Jerome Glisse 

Reviewed-by: Alex Deucher 

Should also go to stable.

> ---
> ?drivers/gpu/drm/radeon/r600.c ?| ? ?4 ++--
> ?drivers/gpu/drm/radeon/rv770.c | ? ?4 ++--
> ?2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 391bd26..96e3fa3 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -1135,7 +1135,7 @@ static void r600_vram_gtt_location(struct radeon_device 
> *rdev, struct radeon_mc
> ? ? ? ?}
> ? ? ? ?if (rdev->flags & RADEON_IS_AGP) {
> ? ? ? ? ? ? ? ?size_bf = mc->gtt_start;
> - ? ? ? ? ? ? ? size_af = 0x - mc->gtt_end + 1;
> + ? ? ? ? ? ? ? size_af = 0x - mc->gtt_end;
> ? ? ? ? ? ? ? ?if (size_bf > size_af) {
> ? ? ? ? ? ? ? ? ? ? ? ?if (mc->mc_vram_size > size_bf) {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?dev_warn(rdev->dev, "limiting VRAM\n");
> @@ -1149,7 +1149,7 @@ static void r600_vram_gtt_location(struct radeon_device 
> *rdev, struct radeon_mc
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?mc->real_vram_size = size_af;
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?mc->mc_vram_size = size_af;
> ? ? ? ? ? ? ? ? ? ? ? ?}
> - ? ? ? ? ? ? ? ? ? ? ? mc->vram_start = mc->gtt_end;
> + ? ? ? ? ? ? ? ? ? ? ? mc->vram_start = mc->gtt_end + 1;
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?mc->vram_end = mc->vram_start + mc->mc_vram_size - 1;
> ? ? ? ? ? ? ? ?dev_info(rdev->dev, "VRAM: %lluM 0x%08llX - 0x%08llX (%lluM 
> used)\n",
> diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
> index c62ae4b..cdab1ae 100644
> --- a/drivers/gpu/drm/radeon/rv770.c
> +++ b/drivers/gpu/drm/radeon/rv770.c
> @@ -969,7 +969,7 @@ void r700_vram_gtt_location(struct radeon_device *rdev, 
> struct radeon_mc *mc)
> ? ? ? ?}
> ? ? ? ?if (rdev->flags & RADEON_IS_AGP) {
> ? ? ? ? ? ? ? ?size_bf = mc->gtt_start;
> - ? ? ? ? ? ? ? size_af = 0x - mc->gtt_end + 1;
> + ? ? ? ? ? ? ? size_af = 0x - mc->gtt_end;
> ? ? ? ? ? ? ? ?if (size_bf > size_af) {
> ? ? ? ? ? ? ? ? ? ? ? ?if (mc->mc_vram_size > size_bf) {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?dev_warn(rdev->dev, "limiting VRAM\n");
> @@ -983,7 +983,7 @@ void r700_vram_gtt_location(struct radeon_device *rdev, 
> struct radeon_mc *mc)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?mc->real_vram_size = size_af;
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?mc->mc_vram_size = size_af;
> ? ? ? ? ? ? ? ? ? ? ? ?}
> - ? ? ? ? ? ? ? ? ? ? ? mc->vram_start = mc->gtt_end;
> + ? ? ? ? ? ? ? ? ? ? ? mc->vram_start = mc->gtt_end + 1;
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?mc->vram_end = mc->vram_start + mc->mc_vram_size - 1;
> ? ? ? ? ? ? ? ?dev_info(rdev->dev, "VRAM: %lluM 0x%08llX - 0x%08llX (%lluM 
> used)\n",
> --
> 1.7.9.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: fix warning for uninitialized variable

[Laura Vasilescu]

Signed-off-by: Laura Vasilescu 
---
 drivers/gpu/drm/nouveau/nouveau_dp.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index d996134..2ff17ef 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -332,7 +332,7 @@ dp_link_train_cr(struct drm_device *dev, struct dp_state 
*dp)
 static int
 dp_link_train_eq(struct drm_device *dev, struct dp_state *dp)
 {
-   bool eq_done, cr_done = true;
+   bool eq_done = false, cr_done = true;
int tries = 0, i;

dp_set_training_pattern(dev, dp, DP_TRAINING_PATTERN_2);
-- 
1.7.1

[PATCH] radeon: fix r600/agp when vram is after AGP (v3)

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

From: Jerome Glisse 

If AGP is placed in the middle, the size_af is off-by-one, it results
in VRAM being placed at 0x7fff instead of 0x800.

v2: fix the vram_start setup.
v3: also fix r7xx & newer ASIC

Reported-by: russiane39 on #radeon

Signed-off-by: Dave Airlie 
Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/r600.c  |4 ++--
 drivers/gpu/drm/radeon/rv770.c |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 391bd26..96e3fa3 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1135,7 +1135,7 @@ static void r600_vram_gtt_location(struct radeon_device 
*rdev, struct radeon_mc
}
if (rdev->flags & RADEON_IS_AGP) {
size_bf = mc->gtt_start;
-   size_af = 0x - mc->gtt_end + 1;
+   size_af = 0x - mc->gtt_end;
if (size_bf > size_af) {
if (mc->mc_vram_size > size_bf) {
dev_warn(rdev->dev, "limiting VRAM\n");
@@ -1149,7 +1149,7 @@ static void r600_vram_gtt_location(struct radeon_device 
*rdev, struct radeon_mc
mc->real_vram_size = size_af;
mc->mc_vram_size = size_af;
}
-   mc->vram_start = mc->gtt_end;
+   mc->vram_start = mc->gtt_end + 1;
}
mc->vram_end = mc->vram_start + mc->mc_vram_size - 1;
dev_info(rdev->dev, "VRAM: %lluM 0x%08llX - 0x%08llX (%lluM 
used)\n",
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index c62ae4b..cdab1ae 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -969,7 +969,7 @@ void r700_vram_gtt_location(struct radeon_device *rdev, 
struct radeon_mc *mc)
}
if (rdev->flags & RADEON_IS_AGP) {
size_bf = mc->gtt_start;
-   size_af = 0x - mc->gtt_end + 1;
+   size_af = 0x - mc->gtt_end;
if (size_bf > size_af) {
if (mc->mc_vram_size > size_bf) {
dev_warn(rdev->dev, "limiting VRAM\n");
@@ -983,7 +983,7 @@ void r700_vram_gtt_location(struct radeon_device *rdev, 
struct radeon_mc *mc)
mc->real_vram_size = size_af;
mc->mc_vram_size = size_af;
}
-   mc->vram_start = mc->gtt_end;
+   mc->vram_start = mc->gtt_end + 1;
}
mc->vram_end = mc->vram_start + mc->mc_vram_size - 1;
dev_info(rdev->dev, "VRAM: %lluM 0x%08llX - 0x%08llX (%lluM 
used)\n",
-- 
1.7.9.3

[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg

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

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

--- Comment #13 from Jerome Glisse  2012-04-17 
09:37:38 PDT ---
Run through ssh "udevadm monitor" when pluging/unpluging screen you should see
event there. If you don't it's kernel issue, if you do it might be your ddx was
not build with the uevent code enabled (which would be a distribution issue).
You can try building your ddx yourself and make sure you have libudev-devel

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

[PATCH] radeon: fix r600/agp when vram is after AGP

[Jerome Glisse]

On Tue, Apr 17, 2012 at 4:19 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> If AGP is placed in the middle, the size_af is off-by-one, it results
> in VRAM being placed at 0x7fff instead of 0x800.
>
> Reported-by: russiane39 on #radeon
>
> Signed-off-by: Dave Airlie 

Reviewed-by: Jerome Glisse 

[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg

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

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

--- Comment #12 from Tvrtko Ursulin  2012-04-17 
09:09:15 PDT ---
Created attachment 60178
  --> https://bugs.freedesktop.org/attachment.cgi?id=60178
Log showing non-working and working events

Better in terms of what gets called but unfortunately still a black screen
without xset dance. Attached are two logs in one file. First sections is debug
from plugging in the monitor only. Second sections is after xset dpms force off
and on (but only the "on" bit). Looks like interesting things are happening in
both cases, but only second one results with video output.

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

[RFC 05/13] v4l: vb2-dma-contig: add support for DMABUF exporting

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Tuesday 10 April 2012 15:10:39 Tomasz Stanislawski wrote:
> This patch adds support for exporting a dma-contig buffer using
> DMABUF interface.
> 
> Signed-off-by: Tomasz Stanislawski 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/media/video/videobuf2-dma-contig.c |  128 +
>  1 files changed, 128 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index 0cdcd2b..e1ad47e 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
> @@ -31,6 +31,7 @@ struct vb2_dc_buf {
>   /* MMAP related */
>   struct vb2_vmarea_handler   handler;
>   atomic_trefcount;
> + struct dma_buf  *dma_buf;
>   struct sg_table *sgt_base;
> 
>   /* USERPTR related */
> @@ -190,6 +191,8 @@ static void vb2_dc_put(void *buf_priv)
>   if (!atomic_dec_and_test(>refcount))
>   return;
> 
> + if (buf->dma_buf)
> + dma_buf_put(buf->dma_buf);
>   vb2_dc_release_sgtable(buf->sgt_base);
>   dma_free_coherent(buf->dev, buf->size, buf->vaddr, buf->dma_addr);
>   kfree(buf);
> @@ -306,6 +309,130 @@ static int vb2_dc_mmap(void *buf_priv, struct
> vm_area_struct *vma) }
> 
>  /*/
> +/* DMABUF ops for exporters  */
> +/*/
> +
> +struct vb2_dc_attachment {
> + struct sg_table sgt;
> + enum dma_data_direction dir;
> +};
> +
> +static int vb2_dc_dmabuf_ops_attach(struct dma_buf *dbuf, struct device
> *dev,
> + struct dma_buf_attachment *dbuf_attach)
> +{
> + /* nothing to be done */
> + return 0;
> +}
> +
> +static void vb2_dc_dmabuf_ops_detach(struct dma_buf *dbuf,
> + struct dma_buf_attachment *db_attach)
> +{
> + struct vb2_dc_attachment *attach = db_attach->priv;
> + struct sg_table *sgt;
> +
> + if (!attach)
> + return;
> +
> + sgt = >sgt;
> +
> + dma_unmap_sg(db_attach->dev, sgt->sgl, sgt->nents, attach->dir);
> + sg_free_table(sgt);
> + kfree(attach);
> + db_attach->priv = NULL;
> +}
> +
> +static struct sg_table *vb2_dc_dmabuf_ops_map(
> + struct dma_buf_attachment *db_attach, enum dma_data_direction dir)
> +{
> + struct dma_buf *dbuf = db_attach->dmabuf;
> + struct vb2_dc_buf *buf = dbuf->priv;
> + struct vb2_dc_attachment *attach = db_attach->priv;
> + struct sg_table *sgt;
> + struct scatterlist *rd, *wr;
> + int i, ret;

You can make i an unsigned int :-)

> +
> + /* return previously mapped sg table */
> + if (attach)
> + return >sgt;

This effectively keeps the mapping around as long as the attachment exists. We 
don't try to swap out buffers in V4L2 as is done in DRM at the moment, so it 
might not be too much of an issue, but the behaviour of the implementation 
will change if we later decide to map/unmap the buffers in the map/unmap 
handlers. Do you think that could be a problem ?

> +
> + attach = kzalloc(sizeof *attach, GFP_KERNEL);
> + if (!attach)
> + return ERR_PTR(-ENOMEM);

Why don't you allocate the vb2_dc_attachment here instead of 
vb2_dc_dmabuf_ops_attach() ?

> + sgt = >sgt;
> + attach->dir = dir;
> +
> + /* copying the buf->base_sgt to attachment */

I would add an explanation regarding why you need to copy the SG list. 
Something like.

"Copy the buf->base_sgt scatter list to the attachment, as we can't map the 
same scatter list to multiple devices at the same time."

> + ret = sg_alloc_table(sgt, buf->sgt_base->orig_nents, GFP_KERNEL);
> + if (ret) {
> + kfree(attach);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + rd = buf->sgt_base->sgl;
> + wr = sgt->sgl;
> + for (i = 0; i < sgt->orig_nents; ++i) {
> + sg_set_page(wr, sg_page(rd), rd->length, rd->offset);
> + rd = sg_next(rd);
> + wr = sg_next(wr);
> + }
>
> + /* mapping new sglist to the client */
> + ret = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents, dir);
> + if (ret <= 0) {
> + printk(KERN_ERR "failed to map scatterlist\n");
> + sg_free_table(sgt);
> + kfree(attach);
> + return ERR_PTR(-EIO);
> + }
> +
> + db_attach->priv = attach;
> +
> + return sgt;
> +}
> +
> +static void vb2_dc_dmabuf_ops_unmap(struct dma_buf_attachment *db_attach,
> + struct sg_table *sgt, enum dma_data_direction dir)
> +{
> + /* nothing to be done here */
> +}
> +
> +static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
> +{
> + /* drop reference obtained in vb2_dc_get_dmabuf */
> + vb2_dc_put(dbuf->priv);

Shouldn't you set vb2_dc_buf::dma_buf to NULL here ? Otherwise the next 
vb2_dc_get_dmabuf() call will return a DMABUF object that 

[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg

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

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

--- Comment #11 from Alex Deucher  2012-04-17 08:45:04 PDT 
---
Created attachment 60177
  --> https://bugs.freedesktop.org/attachment.cgi?id=60177
possible fix

(In reply to comment #10)
> 
> So my question is why this saved_state business in radeon_connector_hotplug?

We don't want to change the DPMS state or the logic won't work for hotplug.  If
this is the first time the monitor is plugged in, there is no mode set so we
don't want to turn the display on as it won't work, we just want to send the
event to userspace.  If the user has configured the display already and then
replugs it or powers it off manually, then we want to power it back up in the
hotplug handler as that is what they expect.

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

[Bug 17902] [830M] need support for DVO-LVDS via na2501

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

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

--- Comment #66 from Gilles Dartiguelongue  
2012-04-17 15:37:21 UTC ---
Ok, I installed i2c-tools and here is what it sees:

# i2cdetect -l
i2c-0i2c   i915 gmbus disabled I2C adapter
i2c-1i2c   i915 gmbus ssc  I2C adapter
i2c-2i2c   i915 GPIOB  I2C adapter
i2c-3i2c   i915 gmbus vga  I2C adapter
i2c-4i2c   i915 GPIOA  I2C adapter
i2c-5i2c   i915 gmbus panelI2C adapter
i2c-6i2c   i915 GPIOC  I2C adapter
i2c-7i2c   i915 gmbus dpc  I2C adapter
i2c-8i2c   i915 GPIOD  I2C adapter
i2c-9i2c   i915 gmbus dpb  I2C adapter
i2c-10i2c   i915 GPIOE  I2C adapter
i2c-11i2c   i915 gmbus reserved I2C adapter
i2c-12i2c   i915 gmbus dpd  I2C adapter
i2c-13i2c   i915 GPIOF  I2C adapter
i2c-14smbus SMBus I801 adapter at 1880  SMBus adapter

Then I run i2cdetect -y on all i2c buses, but only 0 and 11 (and 14 but that's
unrelated to our work here I guess) show something.

Here is the output for those two:

# i2cdetect -y 0
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- -- 

# i2cdetect -y 11
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- 39 -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- 61 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- -- 

reserved and disabled does not sound right anyway. Am I doing it right ?

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

[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg

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

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

--- Comment #10 from Tvrtko Ursulin  2012-04-17 
08:23:56 PDT ---
(In reply to comment #9)
> (In reply to comment #8)
> > 
> > Brief look doesn't show me any locks there, I'll dig in.
> 
> The locking (or lack there of) would be on the kernel side.
> 
> > 
> > If relevant, we have the same symptoms with and without a "desktop
> > environment". Meaning same thing happens with pure X, and also with our
> > software running which does explicit output probing when nothing is 
> > connected.
> > 
> > Problem is (seems to me) xrandr reports monitor connected when in that 
> > state.
> > 
> > Also if relevant we do get two RandR events (RRScreenChangeNotify and
> > RRNotify_OutputChange) when re-plugging the monitor.
> > 
> > Unless there is no intersection between RandR and DPMS... ?
> 
> We don't change the dpms state in the hotplug handler we just use the dpms 
> code
> paths to properly tear down and bring up the display when an enabled monitor 
> is
> connected or disconnected.

Isn't that the problem? You are referring to radeon_connector_hotplug where it
puts old dpms state into the connector.

On disconnect DPMS gets set to off, and then connector->dpms restored to ON.

Subsequent hotplug then doesn't bring up the display
becausedrm_helper_connector_dpms bails out early due to current mode and target
mode being the same.

Manually calling xset dpms force off and then on works because "off" this time
really sets connector->dpms to OFF which allows following "on" command to do
all things it needs to turn it on.

So my question is why this saved_state business in radeon_connector_hotplug?

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

[RFC 04/13] v4l: vb2-dma-contig: add setup of sglist for MMAP buffers

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Tuesday 10 April 2012 15:10:38 Tomasz Stanislawski wrote:
> This patch adds the setup of sglist list for MMAP buffers.
> It is needed for buffer exporting via DMABUF mechanism.
> 
> This patch depends on dma_get_pages extension to DMA api.
> 
> Signed-off-by: Tomasz Stanislawski 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/media/video/videobuf2-dma-contig.c |   51 -
>  1 files changed, 49 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index f4df9e2..0cdcd2b 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c

[snip]

> @@ -197,6 +199,9 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long
> size) {
>   struct device *dev = alloc_ctx;
>   struct vb2_dc_buf *buf;
> + int ret = -ENOMEM;
> + int n_pages;
> + struct page **pages = NULL;
> 
>   buf = kzalloc(sizeof *buf, GFP_KERNEL);
>   if (!buf)
> @@ -205,10 +210,41 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned
> long size) buf->vaddr = dma_alloc_coherent(dev, size, >dma_addr,
> GFP_KERNEL); if (!buf->vaddr) {
>   dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size);
> - kfree(buf);
> - return ERR_PTR(-ENOMEM);
> + goto fail_buf;
> + }
> +
> + WARN_ON((unsigned long)buf->vaddr & ~PAGE_MASK);
> + WARN_ON(buf->dma_addr & ~PAGE_MASK);
> +
> + n_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
> +
> + pages = kmalloc(n_pages * sizeof pages[0], GFP_KERNEL);
> + if (!pages) {
> + dev_err(dev, "failed to alloc page table\n");
> + goto fail_dma;
> + }
> +
> + ret = dma_get_pages(dev, buf->vaddr, buf->dma_addr, pages, n_pages);
> + if (ret < 0) {
> + dev_err(dev, "failed to get buffer pages from DMA API\n");
> + goto fail_pages;
> + }
> + if (ret != n_pages) {
> + ret = -EFAULT;
> + dev_err(dev, "failed to get all pages from DMA API\n");
> + goto fail_pages;
>   }
> 
> + buf->sgt_base = vb2_dc_pages_to_sgt(pages, n_pages, 0, 0);
> + if (IS_ERR(buf->sgt_base)) {
> + ret = PTR_ERR(buf->sgt_base);
> + dev_err(dev, "failed to prepare sg table\n");
> + goto fail_pages;
> + }

I still (at least partially) share Daniel's opinion regarding dma_get_pages(), 
As I stated before, I think what we need here would be either

-  a DMA API call that maps the memory to the importer device instead of
dma_get_pages() + vb2_dc_pages_to_sgt(). The call would take a DMA memory
"cookie" (see the "Minutes from V4L2 update call" mail thread) and a pointer
to the importer device.

- a DMA API call to retrieve a scatter list suitable to be passed to
dma_map_sg(). This would be similar to dma_get_pages() +
vb2_dc_pages_to_sgt().

(And we still have to figure out whether the mapping call should be in the 
exporter or importer, which might have an influence here).

> +
> + /* pages are no longer needed */
> + kfree(pages);
> +
>   buf->dev = dev;
>   buf->size = size;
> 
> @@ -219,6 +255,17 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned
> long size) atomic_inc(>refcount);
> 
>   return buf;
> +
> +fail_pages:
> + kfree(pages);

As kfree(NULL) is legal, you can remove the fail_pages label and move the 
kfree() call just before dma_free_coherent().

> +
> +fail_dma:
> + dma_free_coherent(dev, size, buf->vaddr, buf->dma_addr);
> +
> +fail_buf:
> + kfree(buf);
> +
> + return ERR_PTR(ret);
>  }
> 
>  static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct *vma)

-- 
Regards,

Laurent Pinchart

[RFC 02/13] v4l: vb2: add buffer exporting via dmabuf

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Tuesday 10 April 2012 15:10:36 Tomasz Stanislawski wrote:
> This patch adds extension to videobuf2-core. It allow to export a mmap
> buffer as a file descriptor.
> 
> Signed-off-by: Tomasz Stanislawski 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/media/video/videobuf2-core.c |   66 +++
>  include/media/videobuf2-core.h   |2 +
>  2 files changed, 68 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-core.c
> b/drivers/media/video/videobuf2-core.c index b37feea..ff902aa 100644
> --- a/drivers/media/video/videobuf2-core.c
> +++ b/drivers/media/video/videobuf2-core.c
> @@ -1710,6 +1710,72 @@ static int __find_plane_by_offset(struct vb2_queue
> *q, unsigned long off, }
> 
>  /**
> + * vb2_expbuf() - Export a buffer as a file descriptor
> + * @q:   videobuf2 queue
> + * @b:   export buffer structure passed from userspace to 
> vidioc_expbuf
> + *   handler in driver

This should be @eb.

> + *
> + *The return values from this function are intended to be directly returned
> + * from vidioc_expbuf handler in driver.
> + */
> +int vb2_expbuf(struct vb2_queue *q, struct v4l2_exportbuffer *eb)
> +{
> + struct vb2_buffer *vb = NULL;
> + struct vb2_plane *vb_plane;
> + unsigned int buffer, plane;
> + int ret;
> + struct dma_buf *dbuf;
> +
> + if (q->memory != V4L2_MEMORY_MMAP) {
> + dprintk(1, "Queue is not currently set up for mmap\n");
> + return -EINVAL;
> + }
> +
> + if (!q->mem_ops->get_dmabuf) {
> + dprintk(1, "Queue does not support DMA buffer exporting\n");
> + return -EINVAL;
> + }
> +
> + if (eb->flags & ~O_CLOEXEC) {
> + dprintk(1, "Queue supports only O_CLOEXEC flag\n");
> + return -EINVAL;
> + }
> +
> + /*
> +  * Find the plane corresponding to the offset passed by userspace.
> +  */
> + ret = __find_plane_by_offset(q, eb->mem_offset, , );
> + if (ret) {
> + dprintk(1, "invalid offset %u\n", eb->mem_offset);
> + return ret;
> + }
> +
> + vb = q->bufs[buffer];
> + vb_plane = >planes[plane];
> +
> + dbuf = call_memop(q, get_dmabuf, vb_plane->mem_priv);
> + if (IS_ERR_OR_NULL(dbuf)) {
> + dprintk(1, "Failed to export buffer %d, plane %d\n",
> + buffer, plane);
> + return -EINVAL;
> + }
> +
> + ret = dma_buf_fd(dbuf, eb->flags);
> + if (ret < 0) {
> + dprintk(3, "buffer %d, plane %d failed to export (%d)\n",
> + buffer, plane, ret);
> + return ret;
> + }
> +
> + dprintk(3, "buffer %d, plane %d exported as %d descriptor\n",
> + buffer, plane, ret);
> + eb->fd = ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(vb2_expbuf);
> +
> +/**
>   * vb2_mmap() - map video buffers into application address space
>   * @q:   videobuf2 queue
>   * @vma: vma passed to the mmap file operation handler in the driver
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index 244165a..3bd4225 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -81,6 +81,7 @@ struct vb2_fileio_data;
>  struct vb2_mem_ops {
>   void*(*alloc)(void *alloc_ctx, unsigned long size);
>   void(*put)(void *buf_priv);
> + struct dma_buf *(*get_dmabuf)(void *buf_priv);
> 
>   void*(*get_userptr)(void *alloc_ctx, unsigned long vaddr,
>   unsigned long size, int write);
> @@ -354,6 +355,7 @@ int vb2_queue_init(struct vb2_queue *q);
>  void vb2_queue_release(struct vb2_queue *q);
> 
>  int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b);
> +int vb2_expbuf(struct vb2_queue *q, struct v4l2_exportbuffer *eb);
>  int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer *b, bool
> nonblocking);
> 
>  int vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type type);

-- 
Regards,

Laurent Pinchart

[RFC 03/13] v4l: vb2-dma-contig: let mmap method to use dma_mmap_coherent call

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Tuesday 10 April 2012 15:10:37 Tomasz Stanislawski wrote:
> From: Marek Szyprowski 
> 
> Let mmap method to use dma_mmap_coherent call.  This patch depends on DMA
> mapping redesign patches because the usage of dma_mmap_coherent breaks
> dma-contig allocator for architectures other than ARM and AVR.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/media/video/videobuf2-dma-contig.c |   28 +++--
>  1 files changed, 26 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index 6329483..f4df9e2 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
> @@ -224,14 +224,38 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned
> long size) static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct
> *vma) {
>   struct vb2_dc_buf *buf = buf_priv;
> + int ret;
> 
>   if (!buf) {
>   printk(KERN_ERR "No buffer to map\n");
>   return -EINVAL;
>   }
> 
> - return vb2_mmap_pfn_range(vma, buf->dma_addr, buf->size,
> -   _common_vm_ops, >handler);

This was the only vb2_mmap_pfn_range() if I'm not mistaken. Should the 
function be removed ?

> + /*
> +  * dma_mmap_* uses vm_pgoff as in-buffer offset, but we want to
> +  * map whole buffer
> +  */
> + vma->vm_pgoff = 0;

Is it safe to set vma->vm_pgoff to 0 here behind memory core's back ?

> + ret = dma_mmap_coherent(buf->dev, vma, buf->vaddr,
> + buf->dma_addr, buf->size);
> +
> + if (ret) {
> + printk(KERN_ERR "Remapping memory failed, error: %d\n", ret);
> + return ret;
> + }
> +
> + vma->vm_flags   |= VM_DONTEXPAND | VM_RESERVED;
> + vma->vm_private_data= >handler;
> + vma->vm_ops = _common_vm_ops;
> +
> + vma->vm_ops->open(vma);
> +
> + printk(KERN_DEBUG "%s: mapped dma addr 0x%08lx at 0x%08lx, size %ld\n",
> + __func__, (unsigned long)buf->dma_addr, vma->vm_start,
> + buf->size);
> +
> + return 0;
>  }
> 
>  /*/
-- 
Regards,

Laurent Pinchart

[RFC 01/13] v4l: add buffer exporting via dmabuf

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Tuesday 10 April 2012 15:10:35 Tomasz Stanislawski wrote:
> This patch adds extension to V4L2 api. It allow to export a mmap buffer as
> file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset
> used by mmap and return a file descriptor on success.
> 
> Signed-off-by: Tomasz Stanislawski 
> Signed-off-by: Kyungmin Park 

This mostly looks good to me, except for the lack of documentation of course 
:-)

> ---
>  drivers/media/video/v4l2-compat-ioctl32.c |1 +
>  drivers/media/video/v4l2-ioctl.c  |7 +++
>  include/linux/videodev2.h |   23 +++
>  include/media/v4l2-ioctl.h|2 ++
>  4 files changed, 33 insertions(+), 0 deletions(-)

[snip]

> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 38259bf..627e235 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -680,6 +680,28 @@ struct v4l2_buffer {
>  #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800
>  #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
> 
> +/**
> + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
> descriptor
> + *
> + * @fd:  file descriptor associated with DMABUF (set by driver)
> + * @mem_offset:  a "cookie" that is passed to mmap() as offset

I wouldn't mention mmap() here, as that's unrelated to the DMABUF exporter 
API. Maybe something like

"buffer memory offset as returned by VIDIOC_QUERYBUF in struct 
v4l2_buffer::m.offset (for single-plane formats) or v4l2_plane::m.offset (for 
multi-planar formats)"

> + * @flags:   flags for newly created file, currently only O_CLOEXEC is
> + *   supported, refer to manual of open syscall for more details
> + *
> + * Contains data used for exporting a video buffer as DMABUF file
> + *descriptor. Uses the same 'cookie' as mmap() syscall.

The buffer is identified by a 'cookie' returned by VIDIOC_QUERYBUF (identical 
to the cookie used to mmap() the buffer to userspace).

> All reserved fields
> +*must be set to zero. The field reserved0 is expected to become a structure
> + *'type' allowing an alternative layout of the structure content. Therefore
> + * this field should not be used for any other extensions.
> + */
> +struct v4l2_exportbuffer {
> + __u32   fd;
> + __u32   reserved0;
> + __u32   mem_offset;
> + __u32   flags;
> + __u32   reserved[12];
> +};

-- 
Regards,

Laurent Pinchart

Bug reports on the psb-gfx driver

[Håvar Nøvik]

>
> H?var N?vik skrev 2012-04-17 12:53:
>
>> Hi,
>>
>>  Greetings,


>  I'm experiencing a bug with the driver after a kernel upgrade (3.2 ->
>> 3.3). Every once in a while the screen is blacking out for a second or two.
>>
>> Anyways, I was wondering where I could look at bug reports or report a
>> new one if I can't find a similar?
>>
>>  Ive done a fresh build and Im seeing that same issue that you are
> describing. In a frequency of about 5-15mins it blackens and then returns
> within 1-2 seconds. Could you give us a dmesg output? I will do some
> bugtracking once I get back to my laptop.
> Alan, any thoughts?


That frequency seems about the same as the one I'm experiences. All though
some times it's more often, but I can't say I've done anything special at
the same time.

3.3.2-1-ARCH
Intel(R) Atom(TM) CPU Z520 @ 1.33GHz

Attachment: dmesg ouput


>
> PS: Thanks for the great work on a GMA 500 driver!
>
>>
>>  Alan is the one to thank. :)
>

Thanks to Alan, then :D


>  
>> Regards H?var N?vik
>>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120417/8058e840/attachment-0001.html>
-- next part --
A non-text attachment was scrubbed...
Name: dmesg.log
Type: application/octet-stream
Size: 46683 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120417/8058e840/attachment-0001.obj>

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

[Marek Szyprowski]

Hi Laurent,

On Tuesday, April 17, 2012 2:41 AM Laurent Pinchart wrote:

(snipped)

> > >> +static struct vm_area_struct *vb2_dc_get_user_vma(
> > >> +unsigned long start, unsigned long size)
> > >> +{
> > >> +struct vm_area_struct *vma;
> > >> +
> > >> +/* current->mm->mmap_sem is taken by videobuf2 core */
> > >> +vma = find_vma(current->mm, start);
> > >> +if (!vma) {
> > >> +printk(KERN_ERR "no vma for address %lu\n", start);
> > >> +return ERR_PTR(-EFAULT);
> > >> +}
> > >> +
> > >> +if (vma->vm_end - vma->vm_start < size) {
> > >> +printk(KERN_ERR "vma at %lu is too small for %lu 
> > >> bytes\n",
> > >> +start, size);
> > >> +return ERR_PTR(-EFAULT);
> > >> +}
> > >
> > > Should we support multiple VMAs, or do you think that's not worth it ?
> >
> > What do you mean by multiple VMAs?
> 
> I mean multiple VMAs for a single userspace buffer. It's probably overkill,
> but I'm not familiar enough with the memory management code to be sure. Do you
> have more insight ?

Multiple VMAs means that userspace did something really hacky in the specified 
address range, I'm really convinced that we should not bother supporting such 
cases.

With user pointer mode You usually want to get access to either anonymous pages
(malloc and friends) or the memory somehow allocated by the other device 
(mmaped to userspace). In both cases it available as a single VMA. VMAs with 
anonymous memory are merged together if they get extended to meet side-by-side 
each other.

> 
> > >> +vma = vb2_get_vma(vma);
> > >> +if (!vma) {
> > >> +printk(KERN_ERR "failed to copy vma\n");
> > >> +return ERR_PTR(-ENOMEM);
> > >> +}
> > >
> > > I still think there's no need to copy the VMA. get_user_pages() will make
> > > sure the memory doesn't get paged out, and we don't need to ensure that
> > > the userspace mapping stays in place as our cache operations use a
> > > scatter list. Storing the result of vma_is_io() in vb2_dc_buf should be
> > > enough.
> >
> > As I understand calling get_user_pages ensures that pages are not going to
> > be swapped or freed. I agree that it provides enough protection for the
> > memory.
> >
> > IO mappings are the problem. As you mentioned few mails ago get_page would
> > likely crash for such pages. AFAIK increasing reference count for VMA could
> > be a reliable mechanism for protecting the memory from being freed.
> 
> The main use case here (which is actually the only use case I have
> encountered) is memory reserved at boot time to be used by specific devices
> such as frame buffers. That memory will never be paged out, so I don't think
> there's an issue here. Regarding freeing, it will likely not be freed either,
> and if it does, I doubt that duplicating the VMA will make any difference.

We use user pointer method also to access buffers allocated dynamically by 
other v4l2 devices (we have quite a lot of the in our system). In this case
duplicating VMA is necessary.

> > The problem is that VMA has no reference counters in it. Calling open ops
> > will protect the memory. However it will not protect VMA structure from
> > being freed!
> >
> > Analyze following scenario:
> >
> > - mmap -> returns userptr
> > - qbuf (userptr)
> > - unmap (userptr)
> > - dqbuf
> >
> > The VMA will be destroyed at unmap but memory will not be released.
> >
> > The reason is that open ops was called at qbuf.
> 
> I think I see your point. You want to make sure that the exporter driver (on
> which mmap() has been called) will not release the memory, and to do so you
> call the exporter's open() vm operation when you acquire the memory. To call
> the exporter's close() operation when you release the memory you need a
> pointer to the VMA, but the original VMA might have disappeared. To work
> around the problem you make a copy of the VMA and use it when releasing the
> memory.
> 
> That's a pretty dirty hack. Most of the copy VMA fields will be invalid when
> you use it. On a side note, would storing vm_ops and vm_private_data be enough
> ? I'm also not sure if we need to call get_file() and put_file().

This code is there from the beginning of the videobuf2. The main problem is the
fact that you cannot get a reliable access to user pointer memory which is not 
described with anonymous pages. The hacks/workarounds we use at works really
well with the memory mmaped by the other v4l2 devices (which use vm_open/
vm_close refcounting) and framebuffers which use no refcounting on vma, but we
force them not to release memory by calling get_file() (so the framebuffer 
driver cannot be removed/unloaded once we use its memory, yes, pretty 
theoretical case).

Copying vma was the only solution for the races that usually happen on process 
cleanup or special 'nasty' test case which closed the device before closing the
other 

Bug reports on the psb-gfx driver

[Kristoffer Eriksson]

H?var N?vik skrev 2012-04-17 12:53:
> Hi,
>
Greetings,
> I'm experiencing a bug with the driver after a kernel upgrade (3.2 -> 
> 3.3). Every once in a while the screen is blacking out for a second or 
> two.
>
> Anyways, I was wondering where I could look at bug reports or report a 
> new one if I can't find a similar?
>
Ive done a fresh build and Im seeing that same issue that you are 
describing. In a frequency of about 5-15mins it blackens and then returns
within 1-2 seconds. Could you give us a dmesg output? I will do some 
bugtracking once I get back to my laptop.
Alan, any thoughts?

PS: Thanks for the great work on a GMA 500 driver!
>
Alan is the one to thank. :)
> 
> Regards H?var N?vik

[PATCH] drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series

[Dave Airlie]

From: Dave Airlie 

This is the initial driver for the Aspeed Technologies chips found in
servers. This driver supports the AST 2000, 2100, 2200, 2150 and 2300. It
doesn't support the AST11xx due to lack of hw to test it on, and them requiring
different codepaths.

This driver is intended to be used with xf86-video-modesetting in userspace.

This driver has a slightly different design than other KMS drivers, but
future server chips will probably share similiar setup. As these GPUs commonly
have low video RAM, it doesn't make sense to put the kms console in VRAM
always. This driver places the kms console into system RAM, and does dirty
updates to a copy in video RAM. When userspace sets a new scanout buffer,
it forcefully evicts the video RAM console, and X can create a framebuffer
that can use all of of video RAM.

This driver uses TTM but in a very simple fashion to control the eviction
to system RAM of the console, and multiple servers.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/Kconfig  |2 +
 drivers/gpu/drm/Makefile |1 +
 drivers/gpu/drm/ast/Kconfig  |   14 +
 drivers/gpu/drm/ast/Makefile |9 +
 drivers/gpu/drm/ast/ast_drv.c|  139 +
 drivers/gpu/drm/ast/ast_drv.h|  352 
 drivers/gpu/drm/ast/ast_fb.c |  331 +++
 drivers/gpu/drm/ast/ast_main.c   |  522 +
 drivers/gpu/drm/ast/ast_mode.c   | 1160 ++
 drivers/gpu/drm/ast/ast_tables.h |  265 +
 drivers/gpu/drm/ast/ast_ttm.c|  453 +++
 11 files changed, 3248 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/ast/Kconfig
 create mode 100644 drivers/gpu/drm/ast/Makefile
 create mode 100644 drivers/gpu/drm/ast/ast_drv.c
 create mode 100644 drivers/gpu/drm/ast/ast_drv.h
 create mode 100644 drivers/gpu/drm/ast/ast_fb.c
 create mode 100644 drivers/gpu/drm/ast/ast_main.c
 create mode 100644 drivers/gpu/drm/ast/ast_mode.c
 create mode 100644 drivers/gpu/drm/ast/ast_tables.h
 create mode 100644 drivers/gpu/drm/ast/ast_ttm.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 2418429..514049f 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -165,3 +165,5 @@ source "drivers/gpu/drm/vmwgfx/Kconfig"

 source "drivers/gpu/drm/gma500/Kconfig"

+source "drivers/gpu/drm/ast/Kconfig"
+
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 0cde1b8..bd76195 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -37,4 +37,5 @@ obj-$(CONFIG_DRM_VIA) +=via/
 obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
 obj-$(CONFIG_DRM_EXYNOS) +=exynos/
 obj-$(CONFIG_DRM_GMA500) += gma500/
+obj-$(CONFIG_DRM_AST) += ast/
 obj-y  += i2c/
diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig
new file mode 100644
index 000..dab137d
--- /dev/null
+++ b/drivers/gpu/drm/ast/Kconfig
@@ -0,0 +1,14 @@
+config DRM_AST
+   tristate "AST server chips"
+   depends on DRM && PCI && X86 && EXPERIMENTAL
+   select DRM_TTM
+   select FB_CFB_COPYAREA
+select FB_CFB_FILLRECT
+select FB_CFB_IMAGEBLIT
+   select SYS_CFB_COPYAREA
+select SYS_CFB_FILLRECT
+select SYS_CFB_IMAGEBLIT
+select DRM_KMS_HELPER
+   help
+Say yes for experimental AST driver
+
diff --git a/drivers/gpu/drm/ast/Makefile b/drivers/gpu/drm/ast/Makefile
new file mode 100644
index 000..e6477ea
--- /dev/null
+++ b/drivers/gpu/drm/ast/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the drm device driver.  This driver provides support for the
+# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
+
+ccflags-y := -Iinclude/drm
+
+ast-y := ast_drv.o ast_main.o ast_mode.o ast_fb.o ast_ttm.o
+
+obj-$(CONFIG_DRM_AST) := ast.o
\ No newline at end of file
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
new file mode 100644
index 000..00d9f67
--- /dev/null
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -0,0 +1,139 @@
+/*
+ * Copyright 2012 Red Hat Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE

[Bug 48772] Signal unstable over Display Port on 2560x1440 monitor

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

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

--- Comment #8 from Alex Deucher  2012-04-17 06:18:13 PDT 
---
(In reply to comment #7)
> Where does this finding leads us? According to the specifications
> (http://www.amd.com/us/products/notebook/graphics/amd-radeon-6000m/amd-radeon-6300m/pages/amd-radeon-6300m.aspx#2)
> this resolution over DP should work. Is it possible for the motherboard vendor
> to mess things up in some way?

That's the max theoretical mode supported by the chip.  Whether or not you can
drive a monitor that big probably depends on the type and speed of dram in your
system since the GPU (display controllers, 3D engine, etc.) and the CPU have to
share dram bandwidth.

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

[Intel-gfx] [PATCH 09/12] drm/edid: Update range descriptor struct for EDID 1.4

[Adam Jackson]

On Tue, 2012-04-17 at 17:25 +0200, Takashi Iwai wrote:
> At Fri, 13 Apr 2012 16:33:37 -0400, Adam Jackson wrote:
> > +   u8 flags;
> > +   union {
> > +   struct {
> > +   u8 reserved;
> > +   u8 hfreq_start_khz; /* need to multiply by 2 */
> > +   u8 c; /* need to divide by 2 */
> > +   __le16 m;
> > +   u8 k;
> > +   u8 j; /* need to divide by 2 */
> > +   } gtf2;
> > +   struct {
> > +   u8 version;
> > +   u8 data1; /* high 6 bits: extra clock resolution */
> > +   u8 data2; /* plus low 2 of above: max hactive */
> > +   u8 supported_aspects;
> > +   u8 flags; /* preferred aspect and blanking support */
> > +   u8 supported_scalings;
> > +   u8 preferred_refresh;
> > +   } cvt;
> 
> These new structs must be marked with __attribute__((packed)) although
> the struct detailed_data_monitor_range itself is already marked.  At
> least, with gcc 4.6 and x86-64 here, they get unaligned.

Eek.  Good catch, thanks.

- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120417/94680941/attachment.pgp>

[Intel-gfx] [PATCH 00/12] Add more DMT and common modes

[Rodrigo Vivi]

Thanks for the patches ajax

Feel free to use
Reviewed-by: Rodrigo Vivi 

On Tue, Apr 17, 2012 at 12:50 PM, Takashi Iwai  wrote:
> At Tue, 17 Apr 2012 17:33:17 +0200,
> Takashi Iwai wrote:
>>
>> At Fri, 13 Apr 2012 16:33:28 -0400,
>> Adam Jackson wrote:
>> >
>> > Incorporates some feedback from Rodrigo and Takashi. ?Major themes of the
>> > series:
>> >
>> > - Fix the DMT list to include reduced-blanking modes
>> > - Add modes from DMT for any range descriptor type
>> > - Add an extra modes list for things not in DMT
>> > - For ranges that specify a formula, generate timings from the extra modes
>> >
>> > This still doesn't address the driver policy decision of "I know I have
>> > a scaler, add modes as if there were a range descriptor even if there's
>> > not one". ?But it should at least make clear what such a helper function
>> > should do.
>>
>> I tried these patches now with a few monitors here and it looks
>> working well (after fixing the alignment as I posted in another
>> mail). ?I got new 1600x900 output on two monitors. ?Yay!
>
> Oh, feel free to add my tested-by tag:
>
> ? ? ? ?Tested-by: Takashi Iwai 
>
>
> thanks,
>
> Takashi
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
GPG: 0x905BE242 @ wwwkeys.pgp.net

[Bug 48747] regression [bisected]: display corruption in google earth/glxgears using git r600g on RS780M

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

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

--- Comment #8 from Jos van Wolput  2012-04-17 
04:42:21 PDT ---
(In reply to comment #7)

> Even with Option "ColorTiling2D"?

I am not quite sure if ColorTiling2D is really enabled since I am running
kernel 3.3, I understand you need kernel 3.4 to enable 2D tiling properly.

Anyway this is what Xorg.0.log mentions about tiling:
[  2648.738] (**) RADEON(0): Option "ColorTiling2D" "on"
[  2648.739] (II) RADEON(0): KMS Color Tiling: enabled

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

linux-next: Tree for Apr 17 (pci-sysfs.c and vga_switcheroo.c)

[Randy Dunlap]

On 04/16/2012 09:42 PM, Stephen Rothwell wrote:

> Hi all,
> 
> Changes since 20120416:


When CONFIG_VGA_ARB is not enabled:

drivers/built-in.o: In function `boot_vga_show':
pci-sysfs.c:(.text+0x1060f): undefined reference to `vga_default_device'


and

drivers/built-in.o: In function `boot_vga_show':
pci-sysfs.c:(.text+0x8cc2): undefined reference to `vga_default_device'
drivers/built-in.o: In function `vga_switcheroo_register_client':
(.text+0x76671): undefined reference to `vga_default_device'
drivers/built-in.o: In function `vga_switchto_stage1':
vga_switcheroo.c:(.text+0x767f4): undefined reference to 
`vga_set_default_device'


-- 
~Randy

[Intel-gfx] [PATCH] drm/i915: enable semaphores on gen6 if dmar is not active

[Daniel Vetter]

On Tue, Apr 03, 2012 at 12:32:05AM +0200, Daniel Vetter wrote:
> On Mon, Apr 02, 2012 at 02:44:14PM -0700, Andrew Lutomirski wrote:
> > On Mon, Apr 2, 2012 at 1:52 PM, Daniel Vetter  wrote:
> > > On Mon, Apr 02, 2012 at 01:45:39PM -0700, Andrew Lutomirski wrote:
> > >> On Mon, Apr 2, 2012 at 11:48 AM, Daniel Vetter  > >> ffwll.ch> wrote:
> > >> > Inspired by the recent ppgtt regression report, where switching of
> > >> > dmar only for the gpu seems to fix things completely, I've looked
> > >> > again at the semaphores+vt-d situation.
> > >> >
> > >> > Contrary to my earlier testing a few months back my system is now
> > >> > stable with dmar disabled for the igd, and not only when disabling
> > >> > dmar completely.
> > >> >
> > >> > So I'm rather hopeful that all our recent fixes for snb have changed
> > >> > things for code and it's time to try enabling semaphores again. We've
> > >> > also had issues with enabling semaphores which are not vt-d related,
> > >> > but I guess these are all fixed by the autoreport-disabling and lazy
> > >> > request fix. And there's only one way to find out whether there are
> > >> > still other issues ...
> > >> >
> > >> > Signed-Off-by: Daniel Vetter 
> > >> >
> > >> > ---
> > >> >
> > >> > If no further vt-d regressions show up in the 3.4 cycle I plan to
> > >> > merge this into -next for 3.5 (in a month or so). Comments about how
> > >> > unfeasibly you deem this highly welcome.
> > >> > -Daniel
> > >> > ---
> > >> > ?drivers/gpu/drm/i915/i915_gem_execbuffer.c | ? ?8 +---
> > >> > ?1 files changed, 5 insertions(+), 3 deletions(-)
> > >> >
> > >> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> > >> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > >> > index 8e0b686..ac52433 100644
> > >> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > >> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > >> > @@ -849,9 +849,11 @@ intel_enable_semaphores(struct drm_device *dev)
> > >> > ? ? ? ?if (i915_semaphores >= 0)
> > >> > ? ? ? ? ? ? ? ?return i915_semaphores;
> > >> >
> > >> > - ? ? ? /* Disable semaphores on SNB */
> > >> > - ? ? ? if (INTEL_INFO(dev)->gen == 6)
> > >> > - ? ? ? ? ? ? ? return 0;
> > >> > +#ifdef CONFIG_INTEL_IOMMU
> > >> > + ? ? ? /* Disable semaphores on SNB if VT-d is on. */
> > >> > + ? ? ? if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped)
> > >> > + ? ? ? ? ? ? ? return false;
> > >>
> > >> It might be nice to have a printk here giving instructions for how to 
> > >> work
> > >> around this. ?For example:
> > >>
> > >> i915: Disabling semaphores to work around a DMAR issue. ?As an
> > >> alternative, boot with intel_iommu=igfx_off [or on, igfx_off, or
> > >> whatever it's supposed to be].
> > >>
> > >> The documentation in kernel-parameters.txt is at best unclear to the
> > >> uninitiated.
> > >
> > > If this really does work, I'll look into this. Atm it's still unclear
> > > where to exactly put the plain, we need to annoy internal hardware people
> > > to analyze this. Once we have enough evidence that the combination of gpu
> > > with various features enable plus VT-d just doesn't seem to work reliably.
> > >
> > > So can you check whether things do indeed work with this patch, atop
> > > kernel 3.4-rc1? Iirc you've been the one with the most trouble when
> > > semaphores are enabled ...
> > 
> > I've had a hard time reproducing the problems lately.  The
> > unconditional instant hard hang went away a few months ago, I think.
> > I'll give it another shot when I get home to that machine.
> 
> Well, I've managed to kill my machine shortly after login with semaphores,
> rc6 and dmar enabled. It hasn't died in the same configuration after a few
> hours of light usage (in my case that seems to be the best killer) with
> dmar disabled for just the gpu.
> 
> So if you can give your machine some serious beating with the different
> options, that's really great.

Do you already have some preliminary results or has your machine not yet
died with this patch applied?

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

[Bug 48772] Signal unstable over Display Port on 2560x1440 monitor

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

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

--- Comment #7 from Tvrtko Ursulin  2012-04-17 
03:20:39 PDT ---
(In reply to comment #3)
> Does the proprietary driver work ok with that monitor?

It doesn't. In fact it is even worse than the open source driver which works OK
in 1920x1200, while fglrx has the same symptoms there (and at any higher
resolution) as open source at 2560x1440.

Where does this finding leads us? According to the specifications
(http://www.amd.com/us/products/notebook/graphics/amd-radeon-6000m/amd-radeon-6300m/pages/amd-radeon-6300m.aspx#2)
this resolution over DP should work. Is it possible for the motherboard vendor
to mess things up in some way?

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

[Bug 48747] regression [bisected]: display corruption in google earth/glxgears using git r600g on RS780M

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

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

--- Comment #7 from Michel D?nzer  2012-04-17 00:16:39 
PDT ---
(In reply to comment #6)
> I am sorry I can't patch my kernel since I use a precompiled one.

It's not hard to build your own Debian kernel with a patch. It'll be a skill
very useful to you for testing bug fixes.


(In reply to comment #5)
> Yes, it works without problems with xf86-video-ati driver from git.

Even with Option "ColorTiling2D"?

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

[Bug 48747] regression [bisected]: display corruption in google earth/glxgears using git r600g on RS780M

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

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

--- Comment #6 from Jos van Wolput  2012-04-16 
21:36:20 PDT ---
(In reply to comment #3)

> Does this kernel patch help?

I am sorry I can't patch my kernel since I use a precompiled one.

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

[PATCH v4 12/14] v4l: vb2-dma-contig: change map/unmap behaviour for importers

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Friday 13 April 2012 17:47:54 Tomasz Stanislawski wrote:
> The DMABUF documentation says that the map_dma_buf callback should return
> scatterlist that is mapped into a caller's address space. In practice,
> almost none of existing implementations of DMABUF exporter does it.  This
> patch breaks the DMABUF specification in order to allow exchange DMABUF
> buffers between other APIs like DRM.

Once again, this means that it's time to either fix the documentation or fix 
the non-compliant drivers.

Could you please read the mail I've sent on 27/03/2012 in the "Minutes from 
V4L2 update call" thread and reply there to avoid scattering the discussion ?

-- 
Regards,

Laurent Pinchart

[PATCH v4 03/14] v4l: vb2: add support for shared buffer (dma_buf)

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Friday 13 April 2012 17:47:45 Tomasz Stanislawski wrote:
> From: Sumit Semwal 
> 
> This patch adds support for DMABUF memory type in videobuf2. It calls
> relevant APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.
> 
> For this version, the support is for videobuf2 as a user of the shared
> buffer; so the allocation of the buffer is done outside of V4L2. [A sample
> allocator of dma-buf shared buffer is given at [1]]
> 
> [1]: Rob Clark's DRM:
>https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf
> 
> Signed-off-by: Tomasz Stanislawski 
>[original work in the PoC for buffer sharing]
> Signed-off-by: Sumit Semwal 
> Signed-off-by: Sumit Semwal 

Acked-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart

[PATCH v4 01/14] v4l: Add DMABUF as a memory type

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Friday 13 April 2012 17:47:43 Tomasz Stanislawski wrote:
> From: Sumit Semwal 
> 
> Adds DMABUF memory type to v4l framework. Also adds the related file
> descriptor in v4l2_plane and v4l2_buffer.
> 
> Signed-off-by: Tomasz Stanislawski 
>[original work in the PoC for buffer sharing]
> Signed-off-by: Sumit Semwal 
> Signed-off-by: Sumit Semwal 

Acked-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart

[PATCH v4 04/14] v4l: vb: remove warnings about MEMORY_DMABUF

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Friday 13 April 2012 17:47:46 Tomasz Stanislawski wrote:
> From: Sumit Semwal 
> 
> Adding DMABUF memory type causes videobuf to complain about not using it
> in some switch cases. This patch removes these warnings.
> 
> Signed-off-by: Sumit Semwal 

Acked-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart

[PATCH v4 06/14] v4l: vb2-dma-contig: Remove unneeded allocation context structure

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Friday 13 April 2012 17:47:48 Tomasz Stanislawski wrote:
> vb2-dma-contig returns a vb2_dc_conf structure instance as the vb2
> allocation context. That structure only stores a pointer to the physical
> device. Remove it and use the device pointer directly as the allocation
> context.
> 
> Signed-off-by: Tomasz Stanislawski 

Acked-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart

[PATCH v4 09/14] v4l: vb2: add prepare/finish callbacks to allocators

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Friday 13 April 2012 17:47:51 Tomasz Stanislawski wrote:
> From: Marek Szyprowski 
> 
> This patch adds support for prepare/finish callbacks in VB2 allocators.
> These callback are used for buffer flushing.
> 
> Signed-off-by: Marek Szyprowski 

Acked-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart

[PATCH v4 11/14] v4l: vb2-dma-contig: add support for dma_buf importing

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Friday 13 April 2012 17:47:53 Tomasz Stanislawski wrote:
> From: Sumit Semwal 
> 
> This patch makes changes for adding dma-contig as a dma_buf user. It
> provides function implementations for the {attach, detach, map,
> unmap}_dmabuf() mem_ops of DMABUF memory type.
> 
> Signed-off-by: Sumit Semwal 
> Signed-off-by: Sumit Semwal 
>   [author of the original patch]
> Signed-off-by: Tomasz Stanislawski 
>   [integration with refactored dma-contig allocator]

Pending the comment below,

Acked-by: Laurent Pinchart 

> +static void vb2_dc_detach_dmabuf(void *mem_priv)
> +{
> + struct vb2_dc_buf *buf = mem_priv;
> +
> + if (WARN_ON(buf->dma_addr))
> + vb2_dc_unmap_dmabuf(buf);

This should never happen, and would be a videobuf2 bug otherwise, right ?

> +
> + /* detach this attachment */
> + dma_buf_detach(buf->db_attach->dmabuf, buf->db_attach);
> + kfree(buf);
> +}

-- 
Regards,

Laurent Pinchart

[PATCH v4 08/14] v4l: vb2-dma-contig: add support for scatterlist in userptr mode

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Friday 13 April 2012 17:47:50 Tomasz Stanislawski wrote:
> From: Andrzej Pietrasiewicz 
> 
> This patch introduces usage of dma_map_sg to map memory behind
> a userspace pointer to a device as dma-contiguous mapping.
> 
> Signed-off-by: Andrzej Pietrasiewicz 
> Signed-off-by: Marek Szyprowski 
>   [bugfixing]
> Signed-off-by: Kamil Debski 
>   [bugfixing]
> Signed-off-by: Tomasz Stanislawski 
>   [add sglist subroutines/code refactoring]
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/media/video/videobuf2-dma-contig.c |  287 +++--
>  1 files changed, 270 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index 476e536..3a1e314 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c

[snip]

> +static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
> + unsigned int n_pages, unsigned long offset, unsigned long size)
> +{
> + struct sg_table *sgt;
> + unsigned int chunks;
> + unsigned int i;
> + unsigned int cur_page;
> + int ret;
> + struct scatterlist *s;
> + unsigned int offset_end = n_pages * PAGE_SIZE - size;

Shouldn't offset_end be equal to n_page * PAGE_SIZE - size - offset ?

> + sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
> + if (!sgt)
> + return ERR_PTR(-ENOMEM);
> +
> + /* compute number of chunks */
> + chunks = 1;
> + for (i = 1; i < n_pages; ++i)
> + if (pages[i] != pages[i - 1] + 1)
> + ++chunks;
> +
> + ret = sg_alloc_table(sgt, chunks, GFP_KERNEL);
> + if (ret) {
> + kfree(sgt);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + /* merging chunks and putting them into the scatterlist */
> + cur_page = 0;
> + for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
> + size_t size = PAGE_SIZE;

This will shadow the size parameter, it's a bit confusing. You could rename it 
chunk_size.

> + unsigned int j;
> +
> + for (j = cur_page + 1; j < n_pages; ++j) {
> + if (pages[j] != pages[j - 1] + 1)
> + break;
> + size += PAGE_SIZE;
> + }

> + /* cut offset if chunk starts at the first page */
> + if (cur_page == 0)
> + size -= offset;
> + /* cut offset_end if chunk ends at the last page */
> + if (j == n_pages)
> + size -= offset_end;
> +
> + sg_set_page(s, pages[cur_page], size, offset);
> + offset = 0;

What about just

chunk_size -= offset;
sg_set_page(s, pages[cur_page], min(size, chunk_size), offset);
size -= chunk_size;
offset = 0;

You could then remove the offset_end calculation above.

> + cur_page = j;
> + }
> +
> + return sgt;
> +}

-- 
Regards,

Laurent Pinchart

[Bug 48747] regression [bisected]: display corruption in google earth/glxgears using git r600g on RS780M

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

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

--- Comment #5 from Jos van Wolput  2012-04-16 
19:41:32 PDT ---
(In reply to comment #4)
> Does it works with ati driver from git ? gallium st/xorg is not really
> supported

Yes, it works without problems with xf86-video-ati driver from git.

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

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

[Laurent Pinchart]

Hi Tomasz,

On Wednesday 11 April 2012 12:06:59 Tomasz Stanislawski wrote:
> On 04/06/2012 05:02 PM, Laurent Pinchart wrote:
> > On Thursday 05 April 2012 16:00:05 Tomasz Stanislawski wrote:

[snip]

> > Also, Documentation/CodingStyle favors one variable declaration per line,
> > without commas for multiple declarations.
> 
> does it include loop counters like i and j?

According to CodingStyle, yes :-)

[snip]

> >> +static struct vm_area_struct *vb2_dc_get_user_vma(
> >> +  unsigned long start, unsigned long size)
> >> +{
> >> +  struct vm_area_struct *vma;
> >> +
> >> +  /* current->mm->mmap_sem is taken by videobuf2 core */
> >> +  vma = find_vma(current->mm, start);
> >> +  if (!vma) {
> >> +  printk(KERN_ERR "no vma for address %lu\n", start);
> >> +  return ERR_PTR(-EFAULT);
> >> +  }
> >> +
> >> +  if (vma->vm_end - vma->vm_start < size) {
> >> +  printk(KERN_ERR "vma at %lu is too small for %lu bytes\n",
> >> +  start, size);
> >> +  return ERR_PTR(-EFAULT);
> >> +  }
> > 
> > Should we support multiple VMAs, or do you think that's not worth it ?
> 
> What do you mean by multiple VMAs?

I mean multiple VMAs for a single userspace buffer. It's probably overkill, 
but I'm not familiar enough with the memory management code to be sure. Do you 
have more insight ?

> >> +  vma = vb2_get_vma(vma);
> >> +  if (!vma) {
> >> +  printk(KERN_ERR "failed to copy vma\n");
> >> +  return ERR_PTR(-ENOMEM);
> >> +  }
> > 
> > I still think there's no need to copy the VMA. get_user_pages() will make
> > sure the memory doesn't get paged out, and we don't need to ensure that
> > the userspace mapping stays in place as our cache operations use a
> > scatter list. Storing the result of vma_is_io() in vb2_dc_buf should be
> > enough.
> 
> As I understand calling get_user_pages ensures that pages are not going to
> be swapped or freed. I agree that it provides enough protection for the
> memory.
> 
> IO mappings are the problem. As you mentioned few mails ago get_page would
> likely crash for such pages. AFAIK increasing reference count for VMA could
> be a reliable mechanism for protecting the memory from being freed.

The main use case here (which is actually the only use case I have 
encountered) is memory reserved at boot time to be used by specific devices 
such as frame buffers. That memory will never be paged out, so I don't think 
there's an issue here. Regarding freeing, it will likely not be freed either, 
and if it does, I doubt that duplicating the VMA will make any difference. 

> The problem is that VMA has no reference counters in it. Calling open ops
> will protect the memory. However it will not protect VMA structure from
> being freed!
> 
> Analyze following scenario:
> 
> - mmap -> returns userptr
> - qbuf (userptr)
> - unmap (userptr)
> - dqbuf
> 
> The VMA will be destroyed at unmap but memory will not be released.
>
> The reason is that open ops was called at qbuf.

I think I see your point. You want to make sure that the exporter driver (on 
which mmap() has been called) will not release the memory, and to do so you 
call the exporter's open() vm operation when you acquire the memory. To call 
the exporter's close() operation when you release the memory you need a 
pointer to the VMA, but the original VMA might have disappeared. To work 
around the problem you make a copy of the VMA and use it when releasing the 
memory.

That's a pretty dirty hack. Most of the copy VMA fields will be invalid when 
you use it. On a side note, would storing vm_ops and vm_private_data be enough 
? I'm also not sure if we need to call get_file() and put_file().

> In order to free the memory the VB2 has to call close ops. This
> callback takes pointer to VMA as an argument. The original VMA
> cannot be used here because it is not longer valid.
> 
> Therefore VMA has to be copied at qbuf operation. The function vb2_get_vma
> is used for this purpose.
>
> The workaround could be dropping support for IO mappings in VB2.
> However it will handicap all s5p media drivers because mapping
> produced by dma_mmap_coherent (aka writecombine) are IO mapping.
> As result s5p-fimc could no longer create a pipeline with s5p-mfc.

There's no reason to drop that, even if it's currently hackish :-) (at least 
until we have a working replacement).

> Introducing DMABUF to V4L is a good alternative but only if exporting
> is supported.
> 
> For now I think it is better to keep support for IO mappings. At least
> until DMA mapping redesign and DMABUF exporting in V4L is merged.

I agree. DMABUF is the way to go, but we need to get it in first.

> >> +  return vma;
> >> +}

-- 
Regards,

Laurent Pinchart

[PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Friday 13 April 2012 17:47:44 Tomasz Stanislawski wrote:
> This patch adds description and usage examples for importing
> DMABUF file descriptor in V4L2.
> 
> Signed-off-by: Tomasz Stanislawski 
> Signed-off-by: Kyungmin Park 

[snip]

> diff --git a/Documentation/DocBook/media/v4l/io.xml
> b/Documentation/DocBook/media/v4l/io.xml index b815929..dc5979d 100644
> --- a/Documentation/DocBook/media/v4l/io.xml
> +++ b/Documentation/DocBook/media/v4l/io.xml
> @@ -472,6 +472,162 @@ rest should be evident.
>
>
> 
> +  
> +Streaming I/O (DMA buffer importing)

This section is very similar to the Streaming I/O (User Pointers) section. Do 
you think we should merge the two ? I could handle that if you want.

-- 
Regards,

Laurent Pinchart

[Bug 43114] Can't set high engine clock for RadeonHD 6620G

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

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





--- Comment #3 from RunetMember   2012-04-17 00:03:57 
---
Created an attachment (id=72936)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72936)
lspci

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

[Bug 43114] Can't set high engine clock for RadeonHD 6620G

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

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





--- Comment #2 from RunetMember   2012-04-17 00:03:38 
---
Created an attachment (id=72935)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72935)
cpuinfo

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

[Bug 43114] Can't set high engine clock for RadeonHD 6620G

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

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





--- Comment #1 from RunetMember   2012-04-17 00:03:21 
---
Created an attachment (id=72934)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72934)
dmesg

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

[Bug 43114] New: Can't set high engine clock for RadeonHD 6620G

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

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

   Summary: Can't set high engine clock for RadeonHD 6620G
   Product: Drivers
   Version: 2.5
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: runetmember at gmail.com
Regression: No


APU model: A8-3500M with Radeon HD 6620G.
Laptop model: Acer Aspire 7560G.
According to official specs of this APU
http://www.amd.com/us/products/notebook/apu/mainstream/Pages/mainstream.aspx#6
https://en.wikipedia.org/wiki/Comparison_of_AMD_graphics_processing_units#cite_ref-122
GPU core clock on high profile should be 444 MHz, but even when I set high
profile manually

~# cat /sys/class/drm/card0/device/power_method
profile
~# cat /sys/class/drm/card0/device/power_profile
high

GPU core clock is not 444 MHz anyway, even below 200 MHz:
~$ cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 20 kHz
current engine clock: 7990 kHz
default memory clock: 667000 kHz
Maybe output of radeon_pm_info is incorrect, because change between different
profiles and dynpm make no difference in radeon_pm_info information.

Reproduceable with Linux 3.2 and Linux 3.4rc3. dmesg of 3.4rc3 boot process
attached. Is there any additional information I need to provide?

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

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

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

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


Jonathan Nieder  changed:

   What|Removed |Added

 AssignedTo|drivers_video-dri at kernel-bu |jrnieder at gmail.com
   |gs.osdl.org |




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

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

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

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





--- Comment #17 from Alex Deucher   2012-04-16 
23:34:23 ---
This bug can be closed.

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

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

[Stephen Warren]

On 04/15/2012 02:39 AM, Thierry Reding wrote:
 * Stephen Warren wrote:
 On 04/13/2012 03:14 AM, Thierry Reding wrote:
 display-controllers = disp1 disp2;
 outputs = lvds hdmi tvo dsi;

 I don't think you need both the child nodes and those two properties.

 In other words, I think you either want:

  graphics@5400 {
  ... a bunch of child nodes
  };

 or you want:

  disp1 : dc@5420 {
  ...
  };
  disp2 : dc@5424 {
  ...
  };
  ... all the other graphics nodes

  graphics@5400 {
  display-controllers = disp1 disp2;
  outputs = lvds hdmi tvo dsi;
  };

 In the former case, presumably the drivers for the child nodes would
 make some API call into the parent node and just register themselves
 directly as a certain type of driver, so avoiding the
 display-controllers/outputs properties.
 
 I think I like the former better. The way I understand it the children of the
 graphics node will have to be registered explicitly by the DRM driver because
 of_platform_populate() doesn't work recursively. That would ensure that the
 DRM driver can setup the CRTC and output registries before the other devices
 call back into the DRM to register themselves.

Yes, with the first way, the DRM driver will have to call
of_platform_populate() recursively to make this work.

The thing here is that the device tree should model hardware, not be
designed purely to match the device registration needs of the DRM
driver. I'm not sure that it's correct to model all those devices as
children of the top-level graphics object; I /think/ all the devices are
flat on a single bus, and hence not children of each-other. That all
said, I guess having the nodes as children isn't too far off how the HW
is designed (even if the register accesses aren't on a child bus, the
modules at least logically are grouped together in an umbrella
situation), so I wouldn't push back on the first option above that you
prefer.

 /* initial configuration */
 configuration {
 lvds {
 display-controller = disp1;
 output = lvds;
 };

 hdmi {
 display-controller = disp2;
 output = hdmi;
 };
 };
 };

 I added an additional node for the initial configuration so that the driver
 knows which mapping to setup at boot.

 Isn't that kind of thing usually set up by the video= KMS-related kernel
 command-line option? See Documentation/fb/modedb.txt. Again here, I
 think the actual display controllers would be allocated to whichever
 outputs get used on a first-come first-serve based, so no need for the
 display-controller property above either way.
 
 Boards should still be able to boot and display a console on the standard
 output even if the user doesn't provide a video= option. Shouldn't there be a
 way for a board DTS to specify what the default (or even allowed) connections
 are?

Why wouldn't the default be to light up all outputs that have an
attached display, or an algorithm something like:

* If internal LCD is present, use that
* Else, if HDMI display plugged in, use that
...

 Evaluation hardware like the Harmony might have LVDS, HDMI and VGA connectors
 to provide for a wide range of use cases. The Plutux for instance has only an
 HDMI connector and the Medcom has only LVDS. For the Medcom it would be quite
 confusing for people to suddenly see an HDMI-1 connector pop up f.e. in
 xrandr. It would be equally useless for the Plutux to show up as supporting
 an LVDS or VGA connector.

So the device tree for those devices would disable (or not include) the
connectors that were not present on the board.

...
 I see. Maybe this could be used for board-specific configuration? For
 example, the Plutux could have something like this:
 
   connectors {
   hdmi {
   output = hdmi;
   ddc = i2c2;
   };
   };
 
 The Medcom could have:
 
   connectors {
   lvds {
   output = lvds;
   edid = edid;
   };
   };
 
 While Harmony could be more generic and provide more outputs:
 
   connectors {
   lvds {
   output = lvds;
   ddc = i2c1;
   };
 
   vga {
   /* which output is used for VGA? */
   output = ...;
   ddc = i2c2;
 
   hdmi {
   output = hdmi;
   ddc = i2c3;
   };
   };

That looks like a reasonable start.

 Has there been any discussion as to how EDID data would best be represented
 in DT? Should it just be a binary blob or rather some textual representation?

I think 

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

[Stephen Warren]

On 04/16/2012 12:48 PM, Thierry Reding wrote:
 * Stephen Warren wrote:
...
 Has there been any discussion as to how EDID data would best be represented
 in DT? Should it just be a binary blob or rather some textual 
 representation?

 I think a binary blob makes sense - that's the exact same format it'd
 have if read over the DDC I2C bus.
 
 DTC has /incbin/ for that. Is arch/arm/boot/dts still the correct place for
 EDID blobs? I could add tegra-medcom.edid if that's okay.

As far as I know, yes.

Perhaps we'll want to start putting stuff in SoC-specific
sub-directories given the number of files we'll end up with here
(irrespective of EDID etc.), but I haven't seen any move towards that yet.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

[Stephen Warren]

On 04/16/2012 01:03 PM, Thierry Reding wrote:
...
 I've been looking about for tools to generate EDID data but didn't find
 anything useful. Does anyone know of any tool that's more convenient than
 manually filling a struct edid and writing that to a file?

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

Re: [RFC 01/13] v4l: add buffer exporting via dmabuf

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Tuesday 10 April 2012 15:10:35 Tomasz Stanislawski wrote:
 This patch adds extension to V4L2 api. It allow to export a mmap buffer as
 file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset
 used by mmap and return a file descriptor on success.
 
 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

This mostly looks good to me, except for the lack of documentation of course 
:-)

 ---
  drivers/media/video/v4l2-compat-ioctl32.c |1 +
  drivers/media/video/v4l2-ioctl.c  |7 +++
  include/linux/videodev2.h |   23 +++
  include/media/v4l2-ioctl.h|2 ++
  4 files changed, 33 insertions(+), 0 deletions(-)

[snip]

 diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
 index 38259bf..627e235 100644
 --- a/include/linux/videodev2.h
 +++ b/include/linux/videodev2.h
 @@ -680,6 +680,28 @@ struct v4l2_buffer {
  #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800
  #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
 
 +/**
 + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
 descriptor
 + *
 + * @fd:  file descriptor associated with DMABUF (set by driver)
 + * @mem_offset:  a cookie that is passed to mmap() as offset

I wouldn't mention mmap() here, as that's unrelated to the DMABUF exporter 
API. Maybe something like

buffer memory offset as returned by VIDIOC_QUERYBUF in struct 
v4l2_buffer::m.offset (for single-plane formats) or v4l2_plane::m.offset (for 
multi-planar formats)

 + * @flags:   flags for newly created file, currently only O_CLOEXEC is
 + *   supported, refer to manual of open syscall for more details
 + *
 + * Contains data used for exporting a video buffer as DMABUF file
 + *descriptor. Uses the same 'cookie' as mmap() syscall.

The buffer is identified by a 'cookie' returned by VIDIOC_QUERYBUF (identical 
to the cookie used to mmap() the buffer to userspace).

 All reserved fields
 +*must be set to zero. The field reserved0 is expected to become a structure
 + *'type' allowing an alternative layout of the structure content. Therefore
 + * this field should not be used for any other extensions.
 + */
 +struct v4l2_exportbuffer {
 + __u32   fd;
 + __u32   reserved0;
 + __u32   mem_offset;
 + __u32   flags;
 + __u32   reserved[12];
 +};

-- 
Regards,

Laurent Pinchart

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

Re: [RFC 03/13] v4l: vb2-dma-contig: let mmap method to use dma_mmap_coherent call

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Tuesday 10 April 2012 15:10:37 Tomasz Stanislawski wrote:
 From: Marek Szyprowski m.szyprow...@samsung.com
 
 Let mmap method to use dma_mmap_coherent call.  This patch depends on DMA
 mapping redesign patches because the usage of dma_mmap_coherent breaks
 dma-contig allocator for architectures other than ARM and AVR.
 
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
 ---
  drivers/media/video/videobuf2-dma-contig.c |   28 +++--
  1 files changed, 26 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/media/video/videobuf2-dma-contig.c
 b/drivers/media/video/videobuf2-dma-contig.c index 6329483..f4df9e2 100644
 --- a/drivers/media/video/videobuf2-dma-contig.c
 +++ b/drivers/media/video/videobuf2-dma-contig.c
 @@ -224,14 +224,38 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned
 long size) static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct
 *vma) {
   struct vb2_dc_buf *buf = buf_priv;
 + int ret;
 
   if (!buf) {
   printk(KERN_ERR No buffer to map\n);
   return -EINVAL;
   }
 
 - return vb2_mmap_pfn_range(vma, buf-dma_addr, buf-size,
 -   vb2_common_vm_ops, buf-handler);

This was the only vb2_mmap_pfn_range() if I'm not mistaken. Should the 
function be removed ?

 + /*
 +  * dma_mmap_* uses vm_pgoff as in-buffer offset, but we want to
 +  * map whole buffer
 +  */
 + vma-vm_pgoff = 0;

Is it safe to set vma-vm_pgoff to 0 here behind memory core's back ?

 + ret = dma_mmap_coherent(buf-dev, vma, buf-vaddr,
 + buf-dma_addr, buf-size);
 +
 + if (ret) {
 + printk(KERN_ERR Remapping memory failed, error: %d\n, ret);
 + return ret;
 + }
 +
 + vma-vm_flags   |= VM_DONTEXPAND | VM_RESERVED;
 + vma-vm_private_data= buf-handler;
 + vma-vm_ops = vb2_common_vm_ops;
 +
 + vma-vm_ops-open(vma);
 +
 + printk(KERN_DEBUG %s: mapped dma addr 0x%08lx at 0x%08lx, size %ld\n,
 + __func__, (unsigned long)buf-dma_addr, vma-vm_start,
 + buf-size);
 +
 + return 0;
  }
 
  /*/
-- 
Regards,

Laurent Pinchart

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

Re: [RFC 05/13] v4l: vb2-dma-contig: add support for DMABUF exporting

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Tuesday 10 April 2012 15:10:39 Tomasz Stanislawski wrote:
 This patch adds support for exporting a dma-contig buffer using
 DMABUF interface.
 
 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/media/video/videobuf2-dma-contig.c |  128 +
  1 files changed, 128 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/media/video/videobuf2-dma-contig.c
 b/drivers/media/video/videobuf2-dma-contig.c index 0cdcd2b..e1ad47e 100644
 --- a/drivers/media/video/videobuf2-dma-contig.c
 +++ b/drivers/media/video/videobuf2-dma-contig.c
 @@ -31,6 +31,7 @@ struct vb2_dc_buf {
   /* MMAP related */
   struct vb2_vmarea_handler   handler;
   atomic_trefcount;
 + struct dma_buf  *dma_buf;
   struct sg_table *sgt_base;
 
   /* USERPTR related */
 @@ -190,6 +191,8 @@ static void vb2_dc_put(void *buf_priv)
   if (!atomic_dec_and_test(buf-refcount))
   return;
 
 + if (buf-dma_buf)
 + dma_buf_put(buf-dma_buf);
   vb2_dc_release_sgtable(buf-sgt_base);
   dma_free_coherent(buf-dev, buf-size, buf-vaddr, buf-dma_addr);
   kfree(buf);
 @@ -306,6 +309,130 @@ static int vb2_dc_mmap(void *buf_priv, struct
 vm_area_struct *vma) }
 
  /*/
 +/* DMABUF ops for exporters  */
 +/*/
 +
 +struct vb2_dc_attachment {
 + struct sg_table sgt;
 + enum dma_data_direction dir;
 +};
 +
 +static int vb2_dc_dmabuf_ops_attach(struct dma_buf *dbuf, struct device
 *dev,
 + struct dma_buf_attachment *dbuf_attach)
 +{
 + /* nothing to be done */
 + return 0;
 +}
 +
 +static void vb2_dc_dmabuf_ops_detach(struct dma_buf *dbuf,
 + struct dma_buf_attachment *db_attach)
 +{
 + struct vb2_dc_attachment *attach = db_attach-priv;
 + struct sg_table *sgt;
 +
 + if (!attach)
 + return;
 +
 + sgt = attach-sgt;
 +
 + dma_unmap_sg(db_attach-dev, sgt-sgl, sgt-nents, attach-dir);
 + sg_free_table(sgt);
 + kfree(attach);
 + db_attach-priv = NULL;
 +}
 +
 +static struct sg_table *vb2_dc_dmabuf_ops_map(
 + struct dma_buf_attachment *db_attach, enum dma_data_direction dir)
 +{
 + struct dma_buf *dbuf = db_attach-dmabuf;
 + struct vb2_dc_buf *buf = dbuf-priv;
 + struct vb2_dc_attachment *attach = db_attach-priv;
 + struct sg_table *sgt;
 + struct scatterlist *rd, *wr;
 + int i, ret;

You can make i an unsigned int :-)

 +
 + /* return previously mapped sg table */
 + if (attach)
 + return attach-sgt;

This effectively keeps the mapping around as long as the attachment exists. We 
don't try to swap out buffers in V4L2 as is done in DRM at the moment, so it 
might not be too much of an issue, but the behaviour of the implementation 
will change if we later decide to map/unmap the buffers in the map/unmap 
handlers. Do you think that could be a problem ?

 +
 + attach = kzalloc(sizeof *attach, GFP_KERNEL);
 + if (!attach)
 + return ERR_PTR(-ENOMEM);

Why don't you allocate the vb2_dc_attachment here instead of 
vb2_dc_dmabuf_ops_attach() ?

 + sgt = attach-sgt;
 + attach-dir = dir;
 +
 + /* copying the buf-base_sgt to attachment */

I would add an explanation regarding why you need to copy the SG list. 
Something like.

Copy the buf-base_sgt scatter list to the attachment, as we can't map the 
same scatter list to multiple devices at the same time.

 + ret = sg_alloc_table(sgt, buf-sgt_base-orig_nents, GFP_KERNEL);
 + if (ret) {
 + kfree(attach);
 + return ERR_PTR(-ENOMEM);
 + }
 +
 + rd = buf-sgt_base-sgl;
 + wr = sgt-sgl;
 + for (i = 0; i  sgt-orig_nents; ++i) {
 + sg_set_page(wr, sg_page(rd), rd-length, rd-offset);
 + rd = sg_next(rd);
 + wr = sg_next(wr);
 + }

 + /* mapping new sglist to the client */
 + ret = dma_map_sg(db_attach-dev, sgt-sgl, sgt-orig_nents, dir);
 + if (ret = 0) {
 + printk(KERN_ERR failed to map scatterlist\n);
 + sg_free_table(sgt);
 + kfree(attach);
 + return ERR_PTR(-EIO);
 + }
 +
 + db_attach-priv = attach;
 +
 + return sgt;
 +}
 +
 +static void vb2_dc_dmabuf_ops_unmap(struct dma_buf_attachment *db_attach,
 + struct sg_table *sgt, enum dma_data_direction dir)
 +{
 + /* nothing to be done here */
 +}
 +
 +static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
 +{
 + /* drop reference obtained in vb2_dc_get_dmabuf */
 + vb2_dc_put(dbuf-priv);

Shouldn't you set vb2_dc_buf::dma_buf to NULL here ? Otherwise the next 
vb2_dc_get_dmabuf() call will return a DMABUF object that has been freed.

 +}
 +
 +static struct dma_buf_ops vb2_dc_dmabuf_ops = {
 + .attach = 

[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg

[bugzilla-daemon]

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

--- Comment #10 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-04-17 
08:23:56 PDT ---
(In reply to comment #9)
 (In reply to comment #8)
  
  Brief look doesn't show me any locks there, I'll dig in.
 
 The locking (or lack there of) would be on the kernel side.
 
  
  If relevant, we have the same symptoms with and without a desktop
  environment. Meaning same thing happens with pure X, and also with our
  software running which does explicit output probing when nothing is 
  connected.
  
  Problem is (seems to me) xrandr reports monitor connected when in that 
  state.
  
  Also if relevant we do get two RandR events (RRScreenChangeNotify and
  RRNotify_OutputChange) when re-plugging the monitor.
  
  Unless there is no intersection between RandR and DPMS... ?
 
 We don't change the dpms state in the hotplug handler we just use the dpms 
 code
 paths to properly tear down and bring up the display when an enabled monitor 
 is
 connected or disconnected.

Isn't that the problem? You are referring to radeon_connector_hotplug where it
puts old dpms state into the connector.

On disconnect DPMS gets set to off, and then connector-dpms restored to ON.

Subsequent hotplug then doesn't bring up the display
becausedrm_helper_connector_dpms bails out early due to current mode and target
mode being the same.

Manually calling xset dpms force off and then on works because off this time
really sets connector-dpms to OFF which allows following on command to do
all things it needs to turn it on.

So my question is why this saved_state business in radeon_connector_hotplug?

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

Re: [Intel-gfx] [PATCH 09/12] drm/edid: Update range descriptor struct for EDID 1.4

[Takashi Iwai]

At Fri, 13 Apr 2012 16:33:37 -0400,
Adam Jackson wrote:
 
 Signed-off-by: Adam Jackson a...@redhat.com
 ---
  include/drm/drm_edid.h |   26 --
  1 files changed, 20 insertions(+), 6 deletions(-)
 
 diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
 index bcb9a66..8cefbbe 100644
 --- a/include/drm/drm_edid.h
 +++ b/include/drm/drm_edid.h
 @@ -90,12 +90,26 @@ struct detailed_data_monitor_range {
   u8 min_hfreq_khz;
   u8 max_hfreq_khz;
   u8 pixel_clock_mhz; /* need to multiply by 10 */
 - __le16 sec_gtf_toggle; /* A000=use above, 20=use below */
 - u8 hfreq_start_khz; /* need to multiply by 2 */
 - u8 c; /* need to divide by 2 */
 - __le16 m;
 - u8 k;
 - u8 j; /* need to divide by 2 */
 + u8 flags;
 + union {
 + struct {
 + u8 reserved;
 + u8 hfreq_start_khz; /* need to multiply by 2 */
 + u8 c; /* need to divide by 2 */
 + __le16 m;
 + u8 k;
 + u8 j; /* need to divide by 2 */
 + } gtf2;
 + struct {
 + u8 version;
 + u8 data1; /* high 6 bits: extra clock resolution */
 + u8 data2; /* plus low 2 of above: max hactive */
 + u8 supported_aspects;
 + u8 flags; /* preferred aspect and blanking support */
 + u8 supported_scalings;
 + u8 preferred_refresh;
 + } cvt;

These new structs must be marked with __attribute__((packed)) although
the struct detailed_data_monitor_range itself is already marked.  At
least, with gcc 4.6 and x86-64 here, they get unaligned.


thanks,

Takashi

 + } formula;
  } __attribute__((packed));
  
  struct detailed_data_wpindex {
 -- 
 1.7.7.6
 
 ___
 Intel-gfx mailing list
 intel-...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: Tree for Apr 17 (pci-sysfs.c and vga_switcheroo.c)

[Randy Dunlap]

On 04/16/2012 09:42 PM, Stephen Rothwell wrote:

 Hi all,
 
 Changes since 20120416:


When CONFIG_VGA_ARB is not enabled:

drivers/built-in.o: In function `boot_vga_show':
pci-sysfs.c:(.text+0x1060f): undefined reference to `vga_default_device'


and

drivers/built-in.o: In function `boot_vga_show':
pci-sysfs.c:(.text+0x8cc2): undefined reference to `vga_default_device'
drivers/built-in.o: In function `vga_switcheroo_register_client':
(.text+0x76671): undefined reference to `vga_default_device'
drivers/built-in.o: In function `vga_switchto_stage1':
vga_switcheroo.c:(.text+0x767f4): undefined reference to 
`vga_set_default_device'


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

[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg

[bugzilla-daemon]

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

--- Comment #11 from Alex Deucher ag...@yahoo.com 2012-04-17 08:45:04 PDT ---
Created attachment 60177
  -- https://bugs.freedesktop.org/attachment.cgi?id=60177
possible fix

(In reply to comment #10)
 
 So my question is why this saved_state business in radeon_connector_hotplug?

We don't want to change the DPMS state or the logic won't work for hotplug.  If
this is the first time the monitor is plugged in, there is no mode set so we
don't want to turn the display on as it won't work, we just want to send the
event to userspace.  If the user has configured the display already and then
replugs it or powers it off manually, then we want to power it back up in the
hotplug handler as that is what they expect.

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

Re: [Intel-gfx] [PATCH 00/12] Add more DMT and common modes

[Takashi Iwai]

At Tue, 17 Apr 2012 17:33:17 +0200,
Takashi Iwai wrote:
 
 At Fri, 13 Apr 2012 16:33:28 -0400,
 Adam Jackson wrote:
  
  Incorporates some feedback from Rodrigo and Takashi.  Major themes of the
  series:
  
  - Fix the DMT list to include reduced-blanking modes
  - Add modes from DMT for any range descriptor type
  - Add an extra modes list for things not in DMT
  - For ranges that specify a formula, generate timings from the extra modes
  
  This still doesn't address the driver policy decision of I know I have
  a scaler, add modes as if there were a range descriptor even if there's
  not one.  But it should at least make clear what such a helper function
  should do.
 
 I tried these patches now with a few monitors here and it looks
 working well (after fixing the alignment as I posted in another
 mail).  I got new 1600x900 output on two monitors.  Yay!

Oh, feel free to add my tested-by tag:

Tested-by: Takashi Iwai ti...@suse.de


thanks,

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

Re: [Intel-gfx] [PATCH 00/12] Add more DMT and common modes

[Rodrigo Vivi]

Thanks for the patches ajax

Feel free to use
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com

On Tue, Apr 17, 2012 at 12:50 PM, Takashi Iwai ti...@suse.de wrote:
 At Tue, 17 Apr 2012 17:33:17 +0200,
 Takashi Iwai wrote:

 At Fri, 13 Apr 2012 16:33:28 -0400,
 Adam Jackson wrote:
 
  Incorporates some feedback from Rodrigo and Takashi.  Major themes of the
  series:
 
  - Fix the DMT list to include reduced-blanking modes
  - Add modes from DMT for any range descriptor type
  - Add an extra modes list for things not in DMT
  - For ranges that specify a formula, generate timings from the extra modes
 
  This still doesn't address the driver policy decision of I know I have
  a scaler, add modes as if there were a range descriptor even if there's
  not one.  But it should at least make clear what such a helper function
  should do.

 I tried these patches now with a few monitors here and it looks
 working well (after fixing the alignment as I posted in another
 mail).  I got new 1600x900 output on two monitors.  Yay!

 Oh, feel free to add my tested-by tag:

        Tested-by: Takashi Iwai ti...@suse.de


 thanks,

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



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
GPG: 0x905BE242 @ wwwkeys.pgp.net
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg

[bugzilla-daemon]

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

--- Comment #12 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-04-17 
09:09:15 PDT ---
Created attachment 60178
  -- https://bugs.freedesktop.org/attachment.cgi?id=60178
Log showing non-working and working events

Better in terms of what gets called but unfortunately still a black screen
without xset dance. Attached are two logs in one file. First sections is debug
from plugging in the monitor only. Second sections is after xset dpms force off
and on (but only the on bit). Looks like interesting things are happening in
both cases, but only second one results with video output.

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

[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg

[bugzilla-daemon]

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

--- Comment #13 from Jerome Glisse gli...@freedesktop.org 2012-04-17 09:37:38 
PDT ---
Run through ssh udevadm monitor when pluging/unpluging screen you should see
event there. If you don't it's kernel issue, if you do it might be your ddx was
not build with the uevent code enabled (which would be a distribution issue).
You can try building your ddx yourself and make sure you have libudev-devel

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

Re: [PATCH 08/11] v4l: vb2-dma-contig: add support for scatterlist in userptr mode

[Laurent Pinchart]

Hi Marek,

On Tuesday 17 April 2012 13:25:56 Marek Szyprowski wrote:
 On Tuesday, April 17, 2012 2:41 AM Laurent Pinchart wrote:
 
 (snipped)
 
+static struct vm_area_struct *vb2_dc_get_user_vma(
+  unsigned long start, unsigned long size)
+{
+  struct vm_area_struct *vma;
+
+  /* current-mm-mmap_sem is taken by videobuf2 core */
+  vma = find_vma(current-mm, start);
+  if (!vma) {
+  printk(KERN_ERR no vma for address %lu\n, start);
+  return ERR_PTR(-EFAULT);
+  }
+
+  if (vma-vm_end - vma-vm_start  size) {
+  printk(KERN_ERR vma at %lu is too small for %lu 
bytes\n,
+  start, size);
+  return ERR_PTR(-EFAULT);
+  }

Should we support multiple VMAs, or do you think that's not worth it ?
   
   What do you mean by multiple VMAs?
  
  I mean multiple VMAs for a single userspace buffer. It's probably
  overkill, but I'm not familiar enough with the memory management code to
  be sure. Do you have more insight ?
 
 Multiple VMAs means that userspace did something really hacky in the
 specified address range, I'm really convinced that we should not bother
 supporting such cases.

I agree. I just wanted to make sure that I wasn't forgetting an important use 
case.

 With user pointer mode You usually want to get access to either anonymous
 pages (malloc and friends) or the memory somehow allocated by the other
 device (mmaped to userspace). In both cases it available as a single VMA.
 VMAs with anonymous memory are merged together if they get extended to meet
 side-by-side each other.
 
+  vma = vb2_get_vma(vma);
+  if (!vma) {
+  printk(KERN_ERR failed to copy vma\n);
+  return ERR_PTR(-ENOMEM);
+  }

I still think there's no need to copy the VMA. get_user_pages() will
make sure the memory doesn't get paged out, and we don't need to
ensure that the userspace mapping stays in place as our cache
operations use a scatter list. Storing the result of vma_is_io() in
vb2_dc_buf should be enough.
   
   As I understand calling get_user_pages ensures that pages are not going
   to be swapped or freed. I agree that it provides enough protection for
   the memory.
   
   IO mappings are the problem. As you mentioned few mails ago get_page
   would likely crash for such pages. AFAIK increasing reference count for
   VMA could be a reliable mechanism for protecting the memory from being
   freed.
  
  The main use case here (which is actually the only use case I have
  encountered) is memory reserved at boot time to be used by specific
  devices such as frame buffers. That memory will never be paged out, so I
  don't think there's an issue here. Regarding freeing, it will likely not
  be freed either, and if it does, I doubt that duplicating the VMA will
  make any difference.

 We use user pointer method also to access buffers allocated dynamically by
 other v4l2 devices (we have quite a lot of the in our system). In this case
 duplicating VMA is necessary.
 
   The problem is that VMA has no reference counters in it. Calling open
   ops will protect the memory. However it will not protect VMA structure
   from being freed!
   
   Analyze following scenario:
   
   - mmap - returns userptr
   - qbuf (userptr)
   - unmap (userptr)
   - dqbuf
   
   The VMA will be destroyed at unmap but memory will not be released.
   
   The reason is that open ops was called at qbuf.
  
  I think I see your point. You want to make sure that the exporter driver
  (on which mmap() has been called) will not release the memory, and to do
  so you call the exporter's open() vm operation when you acquire the
  memory. To call the exporter's close() operation when you release the
  memory you need a pointer to the VMA, but the original VMA might have
  disappeared. To work around the problem you make a copy of the VMA and
  use it when releasing the memory.
  
  That's a pretty dirty hack. Most of the copy VMA fields will be invalid
  when you use it. On a side note, would storing vm_ops and vm_private_data
  be enough ? I'm also not sure if we need to call get_file() and
  put_file().
 
 This code is there from the beginning of the videobuf2. The main problem is
 the fact that you cannot get a reliable access to user pointer memory which
 is not described with anonymous pages. The hacks/workarounds we use at
 works really well with the memory mmaped by the other v4l2 devices (which
 use vm_open/ vm_close refcounting) and framebuffers which use no
 refcounting on vma, but we force them not to release memory by calling
 get_file() (so the framebuffer driver cannot be removed/unloaded once we
 use its memory, yes, pretty theoretical case).
 
 Copying vma was the only solution for the races that usually happen on
 process cleanup or special 'nasty' test case which closed the device before
 

Re: [Intel-gfx] [PATCH 09/12] drm/edid: Update range descriptor struct for EDID 1.4

[Adam Jackson]

On Tue, 2012-04-17 at 17:25 +0200, Takashi Iwai wrote:
 At Fri, 13 Apr 2012 16:33:37 -0400, Adam Jackson wrote:
  +   u8 flags;
  +   union {
  +   struct {
  +   u8 reserved;
  +   u8 hfreq_start_khz; /* need to multiply by 2 */
  +   u8 c; /* need to divide by 2 */
  +   __le16 m;
  +   u8 k;
  +   u8 j; /* need to divide by 2 */
  +   } gtf2;
  +   struct {
  +   u8 version;
  +   u8 data1; /* high 6 bits: extra clock resolution */
  +   u8 data2; /* plus low 2 of above: max hactive */
  +   u8 supported_aspects;
  +   u8 flags; /* preferred aspect and blanking support */
  +   u8 supported_scalings;
  +   u8 preferred_refresh;
  +   } cvt;
 
 These new structs must be marked with __attribute__((packed)) although
 the struct detailed_data_monitor_range itself is already marked.  At
 least, with gcc 4.6 and x86-64 here, they get unaligned.

Eek.  Good catch, thanks.

- ajax


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

[PATCH] radeon: fix r600/agp when vram is after AGP

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

If AGP is placed in the middle, the size_af is off-by-one, it results
in VRAM being placed at 0x7fff instead of 0x800.

Reported-by: russiane39 on #radeon

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/radeon/r600.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 4added1..121944c 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1135,7 +1135,7 @@ static void r600_vram_gtt_location(struct radeon_device 
*rdev, struct radeon_mc
}
if (rdev-flags  RADEON_IS_AGP) {
size_bf = mc-gtt_start;
-   size_af = 0x - mc-gtt_end + 1;
+   size_af = 0x - mc-gtt_end;
if (size_bf  size_af) {
if (mc-mc_vram_size  size_bf) {
dev_warn(rdev-dev, limiting VRAM\n);
-- 
1.7.7.6

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

Re: [PATCH] radeon: fix r600/agp when vram is after AGP

[Jerome Glisse]

On Tue, Apr 17, 2012 at 4:19 PM, Dave Airlie airl...@gmail.com wrote:
 From: Dave Airlie airl...@redhat.com

 If AGP is placed in the middle, the size_af is off-by-one, it results
 in VRAM being placed at 0x7fff instead of 0x800.

 Reported-by: russiane39 on #radeon

 Signed-off-by: Dave Airlie airl...@redhat.com

Reviewed-by: Jerome Glisse jgli...@redhat.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] radeon: fix r600/agp when vram is after AGP (v2)

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

If AGP is placed in the middle, the size_af is off-by-one, it results
in VRAM being placed at 0x7fff instead of 0x800.

v2: fix the vram_start setup.

Reported-by: russiane39 on #radeon

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/radeon/r600.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 4added1..f85479e 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1135,7 +1135,7 @@ static void r600_vram_gtt_location(struct radeon_device 
*rdev, struct radeon_mc
}
if (rdev-flags  RADEON_IS_AGP) {
size_bf = mc-gtt_start;
-   size_af = 0x - mc-gtt_end + 1;
+   size_af = 0x - mc-gtt_end;
if (size_bf  size_af) {
if (mc-mc_vram_size  size_bf) {
dev_warn(rdev-dev, limiting VRAM\n);
@@ -1149,7 +1149,7 @@ static void r600_vram_gtt_location(struct radeon_device 
*rdev, struct radeon_mc
mc-real_vram_size = size_af;
mc-mc_vram_size = size_af;
}
-   mc-vram_start = mc-gtt_end;
+   mc-vram_start = mc-gtt_end + 1;
}
mc-vram_end = mc-vram_start + mc-mc_vram_size - 1;
dev_info(rdev-dev, VRAM: %lluM 0x%08llX - 0x%08llX (%lluM 
used)\n,
-- 
1.7.7.6

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

[PATCH] radeon: fix r600/agp when vram is after AGP (v3)

[j . glisse]

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

If AGP is placed in the middle, the size_af is off-by-one, it results
in VRAM being placed at 0x7fff instead of 0x800.

v2: fix the vram_start setup.
v3: also fix r7xx  newer ASIC

Reported-by: russiane39 on #radeon

Signed-off-by: Dave Airlie airl...@redhat.com
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/r600.c  |4 ++--
 drivers/gpu/drm/radeon/rv770.c |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 391bd26..96e3fa3 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1135,7 +1135,7 @@ static void r600_vram_gtt_location(struct radeon_device 
*rdev, struct radeon_mc
}
if (rdev-flags  RADEON_IS_AGP) {
size_bf = mc-gtt_start;
-   size_af = 0x - mc-gtt_end + 1;
+   size_af = 0x - mc-gtt_end;
if (size_bf  size_af) {
if (mc-mc_vram_size  size_bf) {
dev_warn(rdev-dev, limiting VRAM\n);
@@ -1149,7 +1149,7 @@ static void r600_vram_gtt_location(struct radeon_device 
*rdev, struct radeon_mc
mc-real_vram_size = size_af;
mc-mc_vram_size = size_af;
}
-   mc-vram_start = mc-gtt_end;
+   mc-vram_start = mc-gtt_end + 1;
}
mc-vram_end = mc-vram_start + mc-mc_vram_size - 1;
dev_info(rdev-dev, VRAM: %lluM 0x%08llX - 0x%08llX (%lluM 
used)\n,
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index c62ae4b..cdab1ae 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -969,7 +969,7 @@ void r700_vram_gtt_location(struct radeon_device *rdev, 
struct radeon_mc *mc)
}
if (rdev-flags  RADEON_IS_AGP) {
size_bf = mc-gtt_start;
-   size_af = 0x - mc-gtt_end + 1;
+   size_af = 0x - mc-gtt_end;
if (size_bf  size_af) {
if (mc-mc_vram_size  size_bf) {
dev_warn(rdev-dev, limiting VRAM\n);
@@ -983,7 +983,7 @@ void r700_vram_gtt_location(struct radeon_device *rdev, 
struct radeon_mc *mc)
mc-real_vram_size = size_af;
mc-mc_vram_size = size_af;
}
-   mc-vram_start = mc-gtt_end;
+   mc-vram_start = mc-gtt_end + 1;
}
mc-vram_end = mc-vram_start + mc-mc_vram_size - 1;
dev_info(rdev-dev, VRAM: %lluM 0x%08llX - 0x%08llX (%lluM 
used)\n,
-- 
1.7.9.3

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

Re: [PATCH] radeon: fix r600/agp when vram is after AGP (v3)

[Alex Deucher]

On Tue, Apr 17, 2012 at 4:51 PM,  j.gli...@gmail.com wrote:
 From: Jerome Glisse jgli...@redhat.com

 If AGP is placed in the middle, the size_af is off-by-one, it results
 in VRAM being placed at 0x7fff instead of 0x800.

 v2: fix the vram_start setup.
 v3: also fix r7xx  newer ASIC

 Reported-by: russiane39 on #radeon

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

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

Should also go to stable.

 ---
  drivers/gpu/drm/radeon/r600.c  |    4 ++--
  drivers/gpu/drm/radeon/rv770.c |    4 ++--
  2 files changed, 4 insertions(+), 4 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
 index 391bd26..96e3fa3 100644
 --- a/drivers/gpu/drm/radeon/r600.c
 +++ b/drivers/gpu/drm/radeon/r600.c
 @@ -1135,7 +1135,7 @@ static void r600_vram_gtt_location(struct radeon_device 
 *rdev, struct radeon_mc
        }
        if (rdev-flags  RADEON_IS_AGP) {
                size_bf = mc-gtt_start;
 -               size_af = 0x - mc-gtt_end + 1;
 +               size_af = 0x - mc-gtt_end;
                if (size_bf  size_af) {
                        if (mc-mc_vram_size  size_bf) {
                                dev_warn(rdev-dev, limiting VRAM\n);
 @@ -1149,7 +1149,7 @@ static void r600_vram_gtt_location(struct radeon_device 
 *rdev, struct radeon_mc
                                mc-real_vram_size = size_af;
                                mc-mc_vram_size = size_af;
                        }
 -                       mc-vram_start = mc-gtt_end;
 +                       mc-vram_start = mc-gtt_end + 1;
                }
                mc-vram_end = mc-vram_start + mc-mc_vram_size - 1;
                dev_info(rdev-dev, VRAM: %lluM 0x%08llX - 0x%08llX (%lluM 
 used)\n,
 diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
 index c62ae4b..cdab1ae 100644
 --- a/drivers/gpu/drm/radeon/rv770.c
 +++ b/drivers/gpu/drm/radeon/rv770.c
 @@ -969,7 +969,7 @@ void r700_vram_gtt_location(struct radeon_device *rdev, 
 struct radeon_mc *mc)
        }
        if (rdev-flags  RADEON_IS_AGP) {
                size_bf = mc-gtt_start;
 -               size_af = 0x - mc-gtt_end + 1;
 +               size_af = 0x - mc-gtt_end;
                if (size_bf  size_af) {
                        if (mc-mc_vram_size  size_bf) {
                                dev_warn(rdev-dev, limiting VRAM\n);
 @@ -983,7 +983,7 @@ void r700_vram_gtt_location(struct radeon_device *rdev, 
 struct radeon_mc *mc)
                                mc-real_vram_size = size_af;
                                mc-mc_vram_size = size_af;
                        }
 -                       mc-vram_start = mc-gtt_end;
 +                       mc-vram_start = mc-gtt_end + 1;
                }
                mc-vram_end = mc-vram_start + mc-mc_vram_size - 1;
                dev_info(rdev-dev, VRAM: %lluM 0x%08llX - 0x%08llX (%lluM 
 used)\n,
 --
 1.7.9.3

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

[Bug 17902] [830M] need support for DVO-LVDS via na2501

[bugzilla-daemon]

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

--- Comment #66 from Gilles Dartiguelongue gilles.dartiguelon...@esiee.org 
2012-04-17 15:37:21 UTC ---
Ok, I installed i2c-tools and here is what it sees:

# i2cdetect -l
i2c-0i2c   i915 gmbus disabled I2C adapter
i2c-1i2c   i915 gmbus ssc  I2C adapter
i2c-2i2c   i915 GPIOB  I2C adapter
i2c-3i2c   i915 gmbus vga  I2C adapter
i2c-4i2c   i915 GPIOA  I2C adapter
i2c-5i2c   i915 gmbus panelI2C adapter
i2c-6i2c   i915 GPIOC  I2C adapter
i2c-7i2c   i915 gmbus dpc  I2C adapter
i2c-8i2c   i915 GPIOD  I2C adapter
i2c-9i2c   i915 gmbus dpb  I2C adapter
i2c-10i2c   i915 GPIOE  I2C adapter
i2c-11i2c   i915 gmbus reserved I2C adapter
i2c-12i2c   i915 gmbus dpd  I2C adapter
i2c-13i2c   i915 GPIOF  I2C adapter
i2c-14smbus SMBus I801 adapter at 1880  SMBus adapter

Then I run i2cdetect -y on all i2c buses, but only 0 and 11 (and 14 but that's
unrelated to our work here I guess) show something.

Here is the output for those two:

# i2cdetect -y 0
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- -- 

# i2cdetect -y 11
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- 39 -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- 61 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- -- 

reserved and disabled does not sound right anyway. Am I doing it right ?

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

[Bug 17902] [830M] need support for DVO-LVDS via na2501

[bugzilla-daemon]

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

--- Comment #67 from Gilles Dartiguelongue gilles.dartiguelon...@esiee.org 
2012-04-17 15:45:56 PDT ---
Ok, forget that, I rebooted without kms disabled and now I get 28 i2c/smbus
devices (most likely duplicates). Now scanning:

i2c-9i2c   i915 gmbus dpb  I2C adapter
i2c-10i2c   i915 GPIOE  I2C adapter

gives:

# i2cdetect -y 9
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

and 

# i2cdump -y 9 0x38
No size specified (using byte-data access)
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f0123456789abcdef
00: 05 13 26 67 01 a5 19 a2 31 97 81 ff 00 04 00 00??g1??..?..
10: 00 a0 02 02 02 02 02 02 07 00 00 11 54 03 02 40...?T??@
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 03 ff 00 28 88 88 00 00 00 00 00 00?..(??..
40: 80 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00?..?
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 11 00 00 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0?..?
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00..?.
80: ff 07 3d 05 00 00 00 00 00 00 00 00 10 02 10 00.?=????.
90: ff 07 a0 02 00 00 05 00 00 00 88 00 24 00 25 03.???..?...?.$.%?
a0: 28 01 28 05 84 00 00 00 00 04 70 4f 00 00 03 03(?(???pO..??
b0: 00 00 00 00 00 00 09 03 00 a0 00 20 33 33 33 33..??.?. 
c0: 05 90 00 0f 03 16 00 02 02 00 00 00 00 00 00 00??.???.??...
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 98 00 80 00 00 00 80 00 00 00 00 00 00 00..?.?...?...
f0: 71 77 b3 90 00 00 00 88 0a 0f 0a 0a 0a 0a 0a 0aqw??...?

So 1305 and 6726 actually look like the first registers indicated in the
datasheet.

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

Re: Regression: black screen on VGA w/ nouveau in Linux 3.3

[Nick Bowler]

On 2012-04-03 21:27 -0400, Nick Bowler wrote:
 CCing Tom Bylander as he sent me a mail off-list saying he experiences
 a similar issue on an FX 5200.
 
 Tom, maybe you'll have better luck bisecting this than I did?
 
 On 2012-03-19 10:35 -0400, Nick Bowler wrote:
  Just upgraded to Linux 3.3 on my desktop and noticed that the VGA output
  on my card w/ nouveau is totally black (both at the console and in X).
  Almost everything appears to work normally: DPMS works, modesetting
  works, DDC works... all messages indicate that things are working --
  just the image is completely black.
 
 OK, so this is still reproducible on Linux 3.4-rc1+ (Linus' master).  I
 captured the dmesg output before (3.2.13, which is a working kernel),
 and after (3.3.1 and 3.4-rc1-00144-g01627d9 - both fail in an identical
 manner).  All three logs are attached in full (gzipped).

Ping?  I'm still seeing this on 3.4-rc3+.  Is there any other info that
I need to provide?

 One thing that immediately jumps out is the WARNING in the 3.4-rc1+ log
 that occurs early and did not appear in either of the other logs:
 
 [ cut here ]
 WARNING: at /home/nick/misc/linux-2.6/arch/x86/pci/i386.c:60
 pcibios_fwaddrmap_lookup+0x1d/0x3d()
 Hardware name: K8N-E-Deluxe
 Modules linked in:
 Pid: 1, comm: swapper Not tainted 3.4.0-rc1-00144-g01627d9 #47
 Call Trace:
  [81026baf] warn_slowpath_common+0x80/0x98
  [81026bdc] warn_slowpath_null+0x15/0x17
  [8129f79f] pcibios_fwaddrmap_lookup+0x1d/0x3d
  [81687306] pcibios_allocate_resources+0xd4/0x217
  [81688447] ? pci_legacy_init+0x3e/0x3e
  [81687460] pcibios_resource_survey+0x17/0x2d
  [81688dfd] pcibios_init+0x28/0x3a
  [8168848e] pci_subsys_init+0x47/0x4d
  [810002e2] do_one_initcall+0x78/0x126
  [81662bab] kernel_init+0xe9/0x17a
  [8166248a] ? rdinit_setup+0x28/0x28
  [8131ac44] kernel_thread_helper+0x4/0x10
  [81662ac2] ? start_kernel+0x321/0x321
  [8131ac40] ? gs_change+0xb/0xb
 ---[ end trace 4eaa2a86a8e2da22 ]---
 
 Other than that, I diffed the 3.2.13 log and 3.4-rc1+ log and grepped
 for nouveau-related differences.  I see no obvious errors, but I admit
 that I don't really know what to look for.
 
 % diff -u nouveau-3.2.13.log nouveau-3.4-rc1+.log | grep -C3 '\[drm\]'
 
 @@ -418,19 +429,21 @@
  Real Time Clock Driver v1.12b
  Linux agpgart interface v0.103
  [drm] Initialized drm 1.1.0 20060810
 +VGA switcheroo: detected Optimus DSM method \ handle
  ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 19
 -nouveau :01:00.0: PCI INT A - Link[LNKE] - GSI 19 (level, low) - IRQ 
 19
  [drm] nouveau :01:00.0: Detected an NV30 generation card (0x436200a1)
 -[drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN
 +[drm] nouveau :01:00.0: Checking PRAMIN for VBIOS
  [drm] nouveau :01:00.0: ... appears to be valid
 +[drm] nouveau :01:00.0: Using VBIOS from PRAMIN
  [drm] nouveau :01:00.0: BMP BIOS found
  [drm] nouveau :01:00.0: BMP version 5.40
  [drm] nouveau :01:00.0: Bios version 04.36.20.21
 -[drm] nouveau :01:00.0: Found Display Configuration Block version 2.2
 -[drm] nouveau :01:00.0: Raw DCB entry 0: 01000300 9c40
 -[drm] nouveau :01:00.0: Raw DCB entry 1: 02010310 9c40
 -[drm] nouveau :01:00.0: Raw DCB entry 2: 04000302 
 -[drm] nouveau :01:00.0: Raw DCB entry 3: 02020321 0303
 +[drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do
 +[drm] nouveau :01:00.0: DCB version 2.2
 +[drm] nouveau :01:00.0: DCB outp 00: 01000300 9c40
 +[drm] nouveau :01:00.0: DCB outp 01: 02010310 9c40
 +[drm] nouveau :01:00.0: DCB outp 02: 04000302 
 +[drm] nouveau :01:00.0: DCB outp 03: 02020321 0303
  [drm] nouveau :01:00.0: Loading NV17 power sequencing microcode
  [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xF01D
  [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xF4E1
 @@ -439,11 +452,10 @@
  [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xF8B3
  [drm] nouveau :01:00.0: Parsing VBIOS init table 5 at offset 0xF8D0
  [drm] nouveau :01:00.0: Parsing VBIOS init table 6 at offset 0xF959
 -[drm] nouveau :01:00.0: 0 available performance level(s)
 -[drm] nouveau :01:00.0: c: core 425MHz memory 501MHz voltage 1350mV
 -[TTM] Zone  kernel: Available graphics memory: 512160 kiB.
 -[TTM] Initializing pool allocator.
 -[drm] nouveau :01:00.0: Detected 256MiB VRAM
 +[TTM] Zone  kernel: Available graphics memory: 512142 kiB
 +[TTM] Initializing pool allocator
 +[TTM] Initializing DMA pool allocator
 +[drm] nouveau :01:00.0: Detected 256MiB VRAM (DDR1)
  agpgart-amd64 :00:00.0: AGP 3.0 bridge
  agpgart: swapper tried to set rate=x12. Setting to AGP3 x8 mode.
  agpgart-amd64 :00:00.0: putting AGP V3 device into 8x mode
 @@ -452,11 +464,14 @@
  [drm] nouveau :01:00.0: 

[RFC PATCH] drm: Add plane event

[Joonyoung Shim]

DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to
provide the event such as DRM_MODE_PAGE_FLIP_EVENT. The setplane ioctl
can change the framebuffer of plane but user can't know completion of
changing the framebuffer of plane via event. If DRM_MODE_PLANE_EVENT is
added, we can also do pageflip of a plane.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/drm_crtc.c |   45 ---
 include/drm/drm.h  |1 +
 include/drm/drm_crtc.h |3 +-
 include/drm/drm_mode.h |3 ++
 4 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d3aaeb6..4c4fa03 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1690,8 +1690,10 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
struct drm_plane *plane;
struct drm_crtc *crtc;
struct drm_framebuffer *fb;
+   struct drm_pending_vblank_event *e = NULL;
int ret = 0;
unsigned int fb_width, fb_height;
+   unsigned long flags;
int i;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
@@ -1785,16 +1787,51 @@ int drm_mode_setplane(struct drm_device *dev, void 
*data,
goto out;
}
 
+   if (plane_req-flags  DRM_MODE_PLANE_EVENT) {
+   ret = -ENOMEM;
+   spin_lock_irqsave(dev-event_lock, flags);
+   if (file_priv-event_space  sizeof e-event) {
+   spin_unlock_irqrestore(dev-event_lock, flags);
+   goto out;
+   }
+   file_priv-event_space -= sizeof e-event;
+   spin_unlock_irqrestore(dev-event_lock, flags);
+
+   e = kzalloc(sizeof *e, GFP_KERNEL);
+   if (e == NULL) {
+   spin_lock_irqsave(dev-event_lock, flags);
+   file_priv-event_space += sizeof e-event;
+   spin_unlock_irqrestore(dev-event_lock, flags);
+   goto out;
+   }
+
+   e-event.base.type = DRM_EVENT_SET_PLANE_COMPLETE;
+   e-event.base.length = sizeof e-event;
+   e-event.user_data = plane_req-user_data;
+   e-base.event = e-event.base;
+   e-base.file_priv = file_priv;
+   e-base.destroy = (void (*) (struct drm_pending_event *)) kfree;
+   }
+
ret = plane-funcs-update_plane(plane, crtc, fb,
 plane_req-crtc_x, plane_req-crtc_y,
 plane_req-crtc_w, plane_req-crtc_h,
 plane_req-src_x, plane_req-src_y,
-plane_req-src_w, plane_req-src_h);
-   if (!ret) {
-   plane-crtc = crtc;
-   plane-fb = fb;
+plane_req-src_w, plane_req-src_h,
+e);
+   if (ret) {
+   if (plane_req-flags  DRM_MODE_PLANE_EVENT) {
+   spin_lock_irqsave(dev-event_lock, flags);
+   file_priv-event_space += sizeof e-event;
+   spin_unlock_irqrestore(dev-event_lock, flags);
+   kfree(e);
+   }
+   goto out;
}
 
+   plane-crtc = crtc;
+   plane-fb = fb;
+
 out:
mutex_unlock(dev-mode_config.mutex);
 
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 64ff02d..8e2d385 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -761,6 +761,7 @@ struct drm_event {
 
 #define DRM_EVENT_VBLANK 0x01
 #define DRM_EVENT_FLIP_COMPLETE 0x02
+#define DRM_EVENT_SET_PLANE_COMPLETE 0x03
 
 struct drm_event_vblank {
struct drm_event base;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e250eda..19fb9ea 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -602,7 +602,8 @@ struct drm_plane_funcs {
int crtc_x, int crtc_y,
unsigned int crtc_w, unsigned int crtc_h,
uint32_t src_x, uint32_t src_y,
-   uint32_t src_w, uint32_t src_h);
+   uint32_t src_w, uint32_t src_h,
+   struct drm_pending_vblank_event *event);
int (*disable_plane)(struct drm_plane *plane);
void (*destroy)(struct drm_plane *plane);
 };
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 4a0aae3..5ebdbdd 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -124,6 +124,7 @@ struct drm_mode_crtc {
 
 #define DRM_MODE_PRESENT_TOP_FIELD (10)
 #define DRM_MODE_PRESENT_BOTTOM_FIELD  (11)
+#define DRM_MODE_PLANE_EVENT   (12)
 
 /* Planes blend with 

[PATCH] drm: fix page_flip error handling

[Joonyoung Shim]

Free event and restore event_space only when page_flip-flags has
DRM_MODE_PAGE_FLIP_EVENT if page_flip() is failed.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/drm_crtc.c |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d3aaeb6..c79870a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3335,10 +3335,12 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
 
ret = crtc-funcs-page_flip(crtc, fb, e);
if (ret) {
-   spin_lock_irqsave(dev-event_lock, flags);
-   file_priv-event_space += sizeof e-event;
-   spin_unlock_irqrestore(dev-event_lock, flags);
-   kfree(e);
+   if (page_flip-flags  DRM_MODE_PAGE_FLIP_EVENT) {
+   spin_lock_irqsave(dev-event_lock, flags);
+   file_priv-event_space += sizeof e-event;
+   spin_unlock_irqrestore(dev-event_lock, flags);
+   kfree(e);
+   }
}
 
 out:
-- 
1.7.5.4

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

Re: Bug reports on the psb-gfx driver

[Kristoffer Eriksson]

Håvar Nøvik skrev 2012-04-17 12:53:

Hi,


Greetings,
I'm experiencing a bug with the driver after a kernel upgrade (3.2 - 
3.3). Every once in a while the screen is blacking out for a second or 
two.


Anyways, I was wondering where I could look at bug reports or report a 
new one if I can't find a similar?


Ive done a fresh build and Im seeing that same issue that you are 
describing. In a frequency of about 5-15mins it blackens and then returns
within 1-2 seconds. Could you give us a dmesg output? I will do some 
bugtracking once I get back to my laptop.

Alan, any thoughts?

PS: Thanks for the great work on a GMA 500 driver!



Alan is the one to thank. :)


Regards Håvar Nøvik


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