[PATCH] m68k/video: Create

[Geert Uytterhoeven]

For now, it just contains the hack for cirrusfb on Amiga, which is moved
out of  with some slight modifications (use raw_*() instead of
z_*(), which are defined on all m68k platforms).

This makes it safe to include  in all contexts. Before it
could fail to compile with

include/video/vga.h: In function ?vga_mm_r?:
include/video/vga.h:242: error: implicit declaration of function ?z_readb?
include/video/vga.h: In function ?vga_mm_w?:
include/video/vga.h:247: error: implicit declaration of function ?z_writeb?
include/video/vga.h: In function ?vga_mm_w_fast?:
include/video/vga.h:253: error: implicit declaration of function ?z_writew?

or

include/video/vga.h:23:21: error: asm/vga.h: No such file or directory

depending on the value of CONFIG_AMIGA.

Signed-off-by: Geert Uytterhoeven 
Cc: linux-fbdev at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
---
Will queue for 3.5, cfr.
http://kisskb.ellerman.id.au/kisskb/buildresult/6127136/
---
 arch/m68k/include/asm/vga.h |   27 +++
 include/video/vga.h |   22 --
 2 files changed, 27 insertions(+), 22 deletions(-)
 create mode 100644 arch/m68k/include/asm/vga.h

diff --git a/arch/m68k/include/asm/vga.h b/arch/m68k/include/asm/vga.h
new file mode 100644
index 000..d3aa140
--- /dev/null
+++ b/arch/m68k/include/asm/vga.h
@@ -0,0 +1,27 @@
+#ifndef _ASM_M68K_VGA_H
+#define _ASM_M68K_VGA_H
+
+#include 
+
+/*
+ * FIXME
+ * Ugh, we don't have PCI space, so map readb() and friends to use raw I/O
+ * accessors, which are identical to the z_*() Zorro bus accessors.
+ * This should make cirrusfb work again on Amiga
+ */
+#undef inb_p
+#undef inw_p
+#undef outb_p
+#undef outw
+#undef readb
+#undef writeb
+#undef writew
+#define inb_p(port)0
+#define inw_p(port)0
+#define outb_p(port, val)  do { } while (0)
+#define outw(port, val)do { } while (0)
+#define readb  raw_inb
+#define writeb raw_outb
+#define writew raw_outw
+
+#endif /* _ASM_M68K_VGA_H */
diff --git a/include/video/vga.h b/include/video/vga.h
index 2b8691f..cac567f 100644
--- a/include/video/vga.h
+++ b/include/video/vga.h
@@ -19,29 +19,7 @@

 #include 
 #include 
-#ifndef CONFIG_AMIGA
 #include 
-#else
-/*
- * FIXME
- * Ugh, we don't have PCI space, so map readb() and friends to use Zorro space
- * for MMIO accesses. This should make cirrusfb work again on Amiga
- */
-#undef inb_p
-#undef inw_p
-#undef outb_p
-#undef outw
-#undef readb
-#undef writeb
-#undef writew
-#define inb_p(port)0
-#define inw_p(port)0
-#define outb_p(port, val)  do { } while (0)
-#define outw(port, val)do { } while (0)
-#define readb  z_readb
-#define writeb z_writeb
-#define writew z_writew
-#endif
 #include 


-- 
1.7.0.4

[PATCH] scatterlist: add sg_alloc_table_by_pages function

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Wednesday 18 April 2012 11:44:59 Tomasz Stanislawski wrote:
> This patch adds a new constructor for an sg table. The table is constructed
> from an array of struct pages. All contiguous chunks of the pages are merged
> into a single sg nodes. A user may provide an offset and a size of a buffer
> if the buffer is not page-aligned.
> 
> The function is dedicated for DMABUF exporters which often performs
> conversion from an page array to a scatterlist. Moreover the scatterlist
> should be squashed in order to save memory and to speed-up DMA mapping
> using dma_map_sg.
> 
> The code is based on the patch 'v4l: vb2-dma-contig: add support for
> scatterlist in userptr mode' and hints from Laurent Pinchart.

The patch looks good to me. Just a small comment, what do you think about 
naming the function sg_alloc_table_from_pages instead of 
sg_table_alloc_by_pages ?

> Signed-off-by: Tomasz Stanislawski 
> Signed-off-by: Kyungmin Park 
> ---
>  include/linux/scatterlist.h |4 +++
>  lib/scatterlist.c   |   63
> +++ 2 files changed, 67
> insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
> index ac9586d..8d9e6fe 100644
> --- a/include/linux/scatterlist.h
> +++ b/include/linux/scatterlist.h
> @@ -214,6 +214,10 @@ void sg_free_table(struct sg_table *);
>  int __sg_alloc_table(struct sg_table *, unsigned int, unsigned int, gfp_t,
>sg_alloc_fn *);
>  int sg_alloc_table(struct sg_table *, unsigned int, gfp_t);
> +int sg_alloc_table_by_pages(struct sg_table *sgt,
> + struct page **pages, unsigned int n_pages,
> + unsigned long offset, unsigned long size,
> + gfp_t gfp_mask);
>  size_t sg_copy_from_buffer(struct scatterlist *sgl, unsigned int nents,
>  void *buf, size_t buflen);
> diff --git a/lib/scatterlist.c b/lib/scatterlist.c
> index 6096e89..30b9def 100644
> --- a/lib/scatterlist.c
> +++ b/lib/scatterlist.c
> @@ -319,6 +319,69 @@ int sg_alloc_table(struct sg_table *table, unsigned int
> nents, gfp_t gfp_mask) EXPORT_SYMBOL(sg_alloc_table);
> 
>  /**
> + * sg_alloc_table_by_pages - Allocate and initialize an sg table from an
> array + *  of pages
> + * @sgt: The sg table header to use
> + * @pages:   Pointer to an array of page pointers
> + * @n_pages: Number of pages in the pages array
> + * @offset: Offset from start of the first page to the start of a
> buffer + * @size:   Number of valid bytes in the buffer (after offset)
> + * @gfp_mask:GFP allocation mask
> + *
> + *  Description:
> + *Allocate and initialize an sg table from a list of pages. Continuous
> + *ranges of the pages are squashed into a single scatterlist node. A
> user + *may provide an offset at a start and a size of valid data in a
> buffer + *specified by the page array. The returned sg table is
> released by + *sg_free_table.
> + *
> + * Returns:
> + *   0 on success

Maybe you should mention what it returns in case of an error as well.

> + **/
> +int sg_alloc_table_by_pages(struct sg_table *sgt,
> + struct page **pages, unsigned int n_pages,
> + unsigned long offset, unsigned long size,
> + gfp_t gfp_mask)
> +{
> + unsigned int chunks;
> + unsigned int i;
> + unsigned int cur_page;
> + int ret;
> + struct scatterlist *s;
> +
> + /* compute number of contiguous 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_mask);
> + if (unlikely(ret))
> + return ret;
> +
> + /* merging chunks and putting them into the scatterlist */
> + cur_page = 0;
> + for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
> + unsigned long chunk_size;
> + unsigned int j;
> +
> + /* looking for the end of the current chunk */
> + for (j = cur_page + 1; j < n_pages; ++j)
> + if (pages[j] != pages[j - 1] + 1)
> + break;
> +
> + chunk_size = ((j - cur_page) << PAGE_SHIFT) - offset;
> + sg_set_page(s, pages[cur_page], min(size, chunk_size), offset);
> + size -= chunk_size;
> + offset = 0;
> + cur_page = j;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(sg_alloc_table_by_pages);
> +
> +/**
>   * sg_miter_start - start mapping iteration over a sg list
>   * @miter: sg mapping iter to be started
>   * @sgl: sg list to iterate over
-- 
Regards,

Laurent Pinchart

Linux 3.4-rc4

[Linus Torvalds]

David & co, any ideas?

There are other reports of problems with 3.3.x kernels, there's a
report from Tim  which may be related (also
apparently working in 3.2, broken black screen in all 3.3.x).

Nick, I realize you had trouble with a bisection already, but it might
really be worth trying again. Do a

git bisect visualize

and try to pick a good commit (avoding the problems you hit) when you
hit a problem, and then do

   git reset --hard 

to force bisection to try another place. That way you can sometimes
avoid the problem spots, and continue the bisection.

Linus

On Sat, Apr 21, 2012 at 9:07 PM, Nick Bowler  
wrote:
> On 2012-04-21 15:43 -0700, Linus Torvalds wrote:
>> But none of it really looks all that scary. It looks like the 3.4
>> release is all on track, but please do holler if you see regressions.
>
> OK, I'll holler. ?Nouveau is still broken in mainline, as it has been
> since March or so, first reported here:
>
> ?Subject: Regression: black screen on VGA w/ nouveau in Linux 3.3.
> ?http://thread.gmane.org/gmane.linux.kernel/1269631
>
> So far, attempts to elicit a response of any kind from maintainers has
> been about as successful as talking to my doorknob.
>
> Thanks,
> --
> Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
>

VM lockdep warning

[Christian König]

On 21.04.2012 19:30, Jerome Glisse wrote:
> 2012/4/21 Christian K?nig:
>> On 21.04.2012 17:57, Dave Airlie wrote:
>>> 2012/4/21 Jerome Glisse:
 2012/4/21 Christian K?nig:
> On 21.04.2012 16:08, Jerome Glisse wrote:
>> 2012/4/21 Christian K?nig:
>>> Interesting, I'm pretty sure that I haven't touched the locking order
>>> of
>>> the
>>> cs_mutex vs. vm_mutex.
>>>
>>> Maybe it is just some kind of side effect, going to locking into it
>>> anyway.
>>>
>>> Christian.
>>>
>> It's the using, init path take lock in different order than cs path
> Well, could you explain to me why the vm code takes cs mutex in the
> first
> place?
>
> It clearly has it's own mutex and it doesn't looks like that it deals
> with
> any cs related data anyway.
>
> Christian.
 Lock simplification is on my todo. The issue is that vm manager is
 protected by
 cs_mutex The vm.mutex is specific to each vm it doesn't protect the
 global vm
 management. I didn't wanted to introduce a new global vm mutex as vm
 activity
 is mostly trigger on behalf of cs so i dediced to use the cs mutex.

 That's why non cs path of vm need to take the cs mutex.
>>> So if one app is adding a bo, and another doing CS, isn't deadlock a
>>> real possibility?
>> Yeah, I think so.
> No it's not. Look at the code.
>
>>> I expect the VM code need to take CS mutex earlier then.
> No it does not. The idea is that when adding a bo we only need to take the
> cs mutex if we need to resize the vm size (and even that can be worked 
> around).
>
> So we will need to take the cs ioctl in very few case (suspend, increasing vm
> size).
>
>> I would strongly suggest to give the vm code their own global mutex and
>> remove the per vm mutex, cause the later is pretty superfluous if the
>> cs_mutex is also taken most of the time.
>>
>> The attached patch is against drm-fixes and does exactly that.
>>
>> Christian.
> NAK with your change there will be lock contention if one app is in cs and
> another try to create bo. Currently there is allmost never contention. Once
> i ironed out the DP->VGA i will work on something to remove the cs mutex
> from vm path (ie remove it from bo creation/del path).

Ok, sounds like I don't understand the code deeply enough to fix this. 
So I'm just going to wait for your fix.

By the way: If you are talking about the NUTMEG DP->VGA problem, I have 
two systems with that sitting directly beside me. So if you got any 
patches just leave me a note and I can try them.

Christian.

[Regression][3.4-rc3][intel-dri] MMIO read or write has been dropped ffffffff

[Maciej Rutecki]

On sobota, 21 kwietnia 2012 o 15:13:52 Daniel Vetter wrote:
> On Sat, Apr 21, 2012 at 03:03:07PM +0200, Daniel Vetter wrote:
> > On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote:
> > > Bad kernel: 3.4-rc3
> > > Last known good: 3.3
> > > 
> > > Subsystem: dri-intel (guess)
> > > 
> > > Steps to reproduce:
> > > 1. Suspend to ram
> > > 2. Resume
> > > 
> > > After resume laptop works ok, but in dmesg I found:
> > > [  164.098113] [ cut here ]
> > > [  164.098124] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398
> > > gen6_gt_check_fifodbg.isra.6+0x31/0x43()
> > > [  164.098126] Hardware name: 1141ALG
> > > [  164.098128] MMIO read or write has been dropped 
> > > [  164.098129] Modules linked in: xt_tcpudp xt_limit xt_state
> > > iptable_filter nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables
> > > x_tables bnep rfcomm bluetooth uinput fuse loop sha256_generic
> > > aes_x86_64 aes_generic cbc dm_crypt dm_mod uvcvideo videobuf2_vmalloc
> > > videobuf2_memops videobuf2_core videodev usbhid hid media
> > > snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi mac80211
> > > thinkpad_acpi cfg80211 coretemp nvram snd_hda_intel snd_hda_codec
> > > snd_hwdep snd_pcm snd_page_alloc snd_seq ehci_hcd sdhci_pci
> > > crc32c_intel iTCO_wdt iTCO_vendor_support ghash_clmulni_intel
> > > snd_seq_device cryptd snd_timer microcode snd acpi_cpufreq mperf
> > > usbcore psmouse sdhci r8169 mmc_core mii ac rfkill i2c_i801 soundcore
> > > mei(C) serio_raw pcspkr thermal battery power_supply wmi usb_common
> > > evdev processor
> > > [  164.098188] Pid: 4684, comm: kworker/u:9 Tainted: G C  
> > > 3.4.0-rc3 #1
> > > [  164.098189] Call Trace:
> > > [  164.098197]  [] warn_slowpath_common+0x7e/0x96
> > > [  164.098200]  [] warn_slowpath_fmt+0x41/0x43
> > > [  164.098203]  []
> > > gen6_gt_check_fifodbg.isra.6+0x31/0x43 [  164.098207] 
> > > [] __gen6_gt_force_wake_put+0x19/0x1b [  164.098210]
> > >  [] i915_read32+0x66/0x9d
> > > [  164.098213]  [] i915_update_gfx_val+0x61/0xb9
> > > [  164.098218]  [] intel_idle_update+0x47/0x18d
> > > [  164.098222]  [] process_one_work+0x1b5/0x340
> > > [  164.098225]  [] ? process_one_work+0x118/0x340
> > > [  164.098228]  [] ? intel_disable_plane+0x60/0x60
> > > [  164.098231]  [] worker_thread+0xce/0x152
> > > [  164.098234]  [] ?
> > > manage_workers.isra.22+0x16a/0x16a [  164.098237] 
> > > [] kthread+0xa1/0xa9
> > > [  164.098242]  [] ? trace_hardirqs_on+0xd/0xf
> > > [  164.098246]  [] kernel_thread_helper+0x4/0x10
> > > [  164.098250]  [] ? retint_restore_args+0x13/0x13
> > > [  164.098253]  [] ? __init_kthread_worker+0x55/0x55
> > > [  164.098256]  [] ? gs_change+0x13/0x13
> > > [  164.098257] ---[ end trace 97bd0b679d161c3e ]---
> > > [  164.098827] [ cut here ]
> > > [  164.098830] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398
> > > gen6_gt_check_fifodbg.isra.6+0x31/0x43()
> > > [  164.098832] Hardware name: 1141ALG
> > > [  164.098833] MMIO read or write has been dropped 
> > > [  164.098834] Modules linked in: xt_tcpudp xt_limit xt_state
> > > iptable_filter nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables
> > > x_tables bnep rfcomm bluetooth uinput fuse loop sha256_generic
> > > aes_x86_64 aes_generic cbc dm_crypt dm_mod uvcvideo videobuf2_vmalloc
> > > videobuf2_memops videobuf2_core videodev usbhid hid media
> > > snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi mac80211
> > > thinkpad_acpi cfg80211 coretemp nvram snd_hda_intel snd_hda_codec
> > > snd_hwdep snd_pcm snd_page_alloc snd_seq ehci_hcd sdhci_pci
> > > crc32c_intel iTCO_wdt iTCO_vendor_support ghash_clmulni_intel
> > > snd_seq_device cryptd snd_timer microcode snd acpi_cpufreq mperf
> > > usbcore psmouse sdhci r8169 mmc_core mii ac rfkill i2c_i801 soundcore
> > > mei(C) serio_raw pcspkr thermal battery power_supply wmi usb_common
> > > evdev processor
> > > [  164.098877] Pid: 4684, comm: kworker/u:9 Tainted: GWC  
> > > 3.4.0-rc3 #1
> > > [  164.098878] Call Trace:
> > > [  164.098881]  [] warn_slowpath_common+0x7e/0x96
> > > [  164.098884]  [] warn_slowpath_fmt+0x41/0x43
> > > [  164.09]  []
> > > gen6_gt_check_fifodbg.isra.6+0x31/0x43 [  164.098891] 
> > > [] __gen6_gt_force_wake_put+0x19/0x1b [  164.098894]
> > >  [] i915_read32+0x66/0x9d
> > > [  164.098896]  [] intel_idle_update+0x9f/0x18d
> > > [  164.098899]  [] process_one_work+0x1b5/0x340
> > > [  164.098902]  [] ? process_one_work+0x118/0x340
> > > [  164.098904]  [] ? intel_disable_plane+0x60/0x60
> > > [  164.098907]  [] worker_thread+0xce/0x152
> > > [  164.098910]  [] ?
> > > manage_workers.isra.22+0x16a/0x16a [  164.098913] 
> > > [] kthread+0xa1/0xa9
> > > [  164.098916]  [] ? trace_hardirqs_on+0xd/0xf
> > > [  164.098918]  [] kernel_thread_helper+0x4/0x10
> > > [  164.098921]  [] ? retint_restore_args+0x13/0x13
> > > [  164.098925]  [] ? __init_kthread_worker+0x55/0x55
> > > [  164.098927]  [] ? gs_change+0x13/0x13
> > > [  

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

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Friday 20 April 2012 16:45:29 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 

Acked-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart

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

[Laurent Pinchart]

Hi R?mi,

On Friday 20 April 2012 15:03:17 R?mi Denis-Courmont wrote:
> On Fri, 20 Apr 2012 14:25:01 +0200, Tomasz Stanislawski wrote:
> >>> The USERPTR simplifies userspace code but introduce
> >>> a lot of complexity problems for the kernel drivers
> >>> and frameworks.
> >> 
> >> It is not only a simplification. In some cases, USERPTR is the only I/O
> >> method that supports zero copy in pretty much any circumstance.
> > 
> > Only for devices that have its own IOMMU that can access system memory.
> 
> Newer versions of the UVC driver have USERTPR, and simingly gspca seems
> too. That is practically all USB capture devices... That might be
> irrelevant for a smartphone manufacturer. That is very relevant for desktop
> applications.
> 
> > Moreover the userptr must come from malloc or be a mmaped file.
> > The other case are drivers that touch memory using CPU in the kernel
> > space like VIVI or USB drivers.
> 
> I'd argue that USB is the most common case of V4L2 on the desktop...
> 
> >> When the user cannot reliably predict the maximum number of required
> >> buffers, predicts a value larger than the device will negotiate, or
> >> needs buffers to outlive STREAMOFF (?), MMAP requires memory copying.
> >> USERPTR does not.
> > 
> > What does outlive STREAMOFF means in this context?
> 
> Depending how your multimedia pipeline is built, it is plausible that the
> V4L2 source is shutdown (STREAMOFF then close()) before buffers coming from
> it are released/destroyed downstream. I might be wrong, but I would expect
> that V4L2 MMAP buffers become invalid after STREAMOFF+close()?

If the buffer is mmap()ed to userspace, it will not be freed before being 
munmap()ed.

> > Anyway, IMO allocation of the buffers at VIDIOC_REQBUFS was not the best
> > idea because it introduces an allocation overhead for negotiations of
> > the number of the buffers. An allocation at mmap was to late. There is a
> > need for some intermediate state between REQBUFS and mmap. The ioctl
> > BUF_PREPARE may help here.
> > 
> > Can you give me an example of a sane application is forced to negotiate
> > a larger number of buffers than it is actually going to use?
> 
> Outside the embedded world, the application typically does not know what
> the latency of the multimedia pipeline is. If the latency is not known, the
> number of buffers needed for zero copy cannot be precomputed for REQBUFS,
> say:
> 
> count = 1 + latency / frame interval.
> 
> Even for a trivial analog TV viewer application, lip synchronization
> requires picture frames to be bufferred to be long enough to account for
> the latency of the audio input, dejitter, filtering and audio output. Those
> values are usually not well determined at the time of requesting buffers
> from the video capture device. Also the application may want to play nice
> with PulseAudio. Then it will get very long audio buffers with very few
> audio periods... more latency.
> 
> It gets harder or outright impossible for frameworks dealing with
> complicated or arbitrary pipelines such as LibVLC or gstreamer. There is
> far too much unpredictability and variability downstream of the V4L2 source
> to estimate latency, and infer the number of buffers needed.

If I'm not mistaken VIDIOC_CREATEBUF allows you to create additional buffers 
at runtime. You can thus cope with a latency increase (provided that the 
allocation overhead isn't prohibitive, in which case you're stuck whatever 
method you select). Deleting buffers at runtime is currently not possible 
though.

> >> Now, I do realize that some devices cannot support USERPTR efficiently,
> >> then they should not support USERPTR.
> > 
> > The problem is not there is *NO* device that can handle USERPTR reliably.
> > The can handle USERPTR generated by malloc or page cache (not sure).
> > Memory mmaped from other devices, frameworks etc may or may not work.
> > Even if the device has its IOMMU the DMA layer provides no generic way to
> > transform from one device to the mapping in some other device.
> 
> I'm not saying that USERPTR should replace DMABUF. I'm saying USERPTR has
> advantages over MMAP that DMABUF does not seem to cover as yet (if only
> libv4l2 would not inhibit USERPTR...).
> 
> I'm definitely not saying that applications should rely on USERPTR being
> supported. We agree that not all devices can support USERPTR.
> 
> > The userptr has its niches were it works pretty well like Web cams or
> > VIVI.
> >
> > I am saying that if ever DMABUF becomes a good alternative for USERPTR
> > than maybe we should consider encouraging dropping USERPTR in the new
> > drivers as 'obsolete' feature and providing some emulation layer in
> > libv4l2 for legacy applications.
> 
> Sure.
-- 
Regards,

Laurent Pinchart

VM lockdep warning

[Christian König]

On 21.04.2012 17:57, Dave Airlie wrote:
> 2012/4/21 Jerome Glisse:
>> 2012/4/21 Christian K?nig:
>>> On 21.04.2012 16:08, Jerome Glisse wrote:
 2012/4/21 Christian K?nig:
> Interesting, I'm pretty sure that I haven't touched the locking order of
> the
> cs_mutex vs. vm_mutex.
>
> Maybe it is just some kind of side effect, going to locking into it
> anyway.
>
> Christian.
>
 It's the using, init path take lock in different order than cs path
>>> Well, could you explain to me why the vm code takes cs mutex in the first
>>> place?
>>>
>>> It clearly has it's own mutex and it doesn't looks like that it deals with
>>> any cs related data anyway.
>>>
>>> Christian.
>> Lock simplification is on my todo. The issue is that vm manager is protected 
>> by
>> cs_mutex The vm.mutex is specific to each vm it doesn't protect the global vm
>> management. I didn't wanted to introduce a new global vm mutex as vm activity
>> is mostly trigger on behalf of cs so i dediced to use the cs mutex.
>>
>> That's why non cs path of vm need to take the cs mutex.
> So if one app is adding a bo, and another doing CS, isn't deadlock a
> real possibility?
Yeah, I think so.
> I expect the VM code need to take CS mutex earlier then.

I would strongly suggest to give the vm code their own global mutex and 
remove the per vm mutex, cause the later is pretty superfluous if the 
cs_mutex is also taken most of the time.

The attached patch is against drm-fixes and does exactly that.

Christian.

[PATCH] drm/radeon: use a global mutex instead of per vm one

[Christian König]

Resolving deadlock problems with the cs_mutex.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon.h|2 +-
 drivers/gpu/drm/radeon/radeon_device.c |1 +
 drivers/gpu/drm/radeon/radeon_gart.c   |   25 +
 3 files changed, 11 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 138b952..f35957d 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -680,7 +680,6 @@ struct radeon_vm {
u64 pt_gpu_addr;
u64 *pt;
struct radeon_sa_bo sa_bo;
-   struct mutexmutex;
/* last fence for cs using this vm */
struct radeon_fence *fence;
 };
@@ -1527,6 +1526,7 @@ struct radeon_device {
struct radeon_pmpm;
uint32_tbios_scratch[RADEON_BIOS_NUM_SCRATCH];
struct radeon_mutex cs_mutex;
+   struct mutexvm_mutex;
struct radeon_wbwb;
struct radeon_dummy_pagedummy_page;
boolgpu_lockup;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index ea7df16..cecb785 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -725,6 +725,7 @@ int radeon_device_init(struct radeon_device *rdev,
 * can recall function without having locking issues */
radeon_mutex_init(>cs_mutex);
radeon_mutex_init(>ib_pool.mutex);
+   mutex_init(>vm_mutex);
for (i = 0; i < RADEON_NUM_RINGS; ++i)
mutex_init(>ring[i].mutex);
mutex_init(>dc_hw_i2c_mutex);
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index c58a036..1b4933b 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -356,13 +356,13 @@ int radeon_vm_manager_suspend(struct radeon_device *rdev)
 {
struct radeon_vm *vm, *tmp;

-   radeon_mutex_lock(>cs_mutex);
+   mutex_lock(>vm_mutex);
/* unbind all active vm */
list_for_each_entry_safe(vm, tmp, >vm_manager.lru_vm, list) {
radeon_vm_unbind_locked(rdev, vm);
}
rdev->vm_manager.funcs->fini(rdev);
-   radeon_mutex_unlock(>cs_mutex);
+   mutex_unlock(>vm_mutex);
return radeon_sa_bo_manager_suspend(rdev, >vm_manager.sa_manager);
 }

@@ -476,13 +476,11 @@ int radeon_vm_bo_add(struct radeon_device *rdev,
return -EINVAL;
}

-   mutex_lock(>mutex);
+   mutex_lock(>vm_mutex);
if (last_pfn > vm->last_pfn) {
/* grow va space 32M by 32M */
unsigned align = ((32 << 20) >> 12) - 1;
-   radeon_mutex_lock(>cs_mutex);
radeon_vm_unbind_locked(rdev, vm);
-   radeon_mutex_unlock(>cs_mutex);
vm->last_pfn = (last_pfn + align) & ~align;
}
head = >va;
@@ -498,7 +496,7 @@ int radeon_vm_bo_add(struct radeon_device *rdev,
bo, (unsigned)bo_va->soffset, tmp->bo,
(unsigned)tmp->soffset, (unsigned)tmp->eoffset);
kfree(bo_va);
-   mutex_unlock(>mutex);
+   mutex_unlock(>vm_mutex);
return -EINVAL;
}
last_offset = tmp->eoffset;
@@ -506,7 +504,7 @@ int radeon_vm_bo_add(struct radeon_device *rdev,
}
list_add(_va->vm_list, head);
list_add_tail(_va->bo_list, >va);
-   mutex_unlock(>mutex);
+   mutex_unlock(>vm_mutex);
return 0;
 }

@@ -597,13 +595,11 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
if (bo_va == NULL)
return 0;

-   mutex_lock(>mutex);
-   radeon_mutex_lock(>cs_mutex);
+   mutex_lock(>vm_mutex);
radeon_vm_bo_update_pte(rdev, vm, bo, NULL);
-   radeon_mutex_unlock(>cs_mutex);
list_del(_va->vm_list);
-   mutex_unlock(>mutex);
list_del(_va->bo_list);
+   mutex_unlock(>vm_mutex);

kfree(bo_va);
return 0;
@@ -643,11 +639,8 @@ void radeon_vm_fini(struct radeon_device *rdev, struct 
radeon_vm *vm)
struct radeon_bo_va *bo_va, *tmp;
int r;

-   mutex_lock(>mutex);
-
-   radeon_mutex_lock(>cs_mutex);
+   mutex_lock(>vm_mutex);
radeon_vm_unbind_locked(rdev, vm);
-   radeon_mutex_unlock(>cs_mutex);

/* remove all bo */
r = radeon_bo_reserve(rdev->ib_pool.sa_manager.bo, false);
@@ -670,5 +663,5 @@ void radeon_vm_fini(struct radeon_device *rdev, struct 
radeon_vm *vm)
kfree(bo_va);
}
}
-   mutex_unlock(>mutex);
+   mutex_unlock(>vm_mutex);
 }
-- 
1.7.5.4

[PATCH libdrm 4/4] modetest: print more about our properties

[Paulo Zanoni]

From: Paulo Zanoni 

In the future we'll have more than just connector properties, so create
a dump_prop function that can handle any property (instead of the
current dump_props function that only handles connector properties).

Also, make this function print a lot more information about the existing
properties.

Also change the printed indentation of the modes to make the output more
readable.

The previous function dump_props also segfaulted when we didn't have
enought permissions. The new function does not segfault in this case (by
checking for the return value of drmModeGetProperty).

Reviewed-by: Eugeni Dodonov 
Signed-off-by: Paulo Zanoni 
---
 tests/modetest/modetest.c |   95 -
 1 file changed, 86 insertions(+), 9 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 6deed69..5784622 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -145,7 +146,7 @@ void dump_encoders(void)

 void dump_mode(drmModeModeInfo *mode)
 {
-   printf("  %s %d %d %d %d %d %d %d %d %d\n",
+   printf("\t%s %d %d %d %d %d %d %d %d %d\n",
   mode->name,
   mode->vrefresh,
   mode->hdisplay,
@@ -159,16 +160,90 @@ void dump_mode(drmModeModeInfo *mode)
 }

 static void
-dump_props(drmModeConnector *connector)
+dump_blob(uint32_t blob_id)
+{
+   uint32_t i;
+   unsigned char *blob_data;
+   drmModePropertyBlobPtr blob;
+
+   blob = drmModeGetPropertyBlob(fd, blob_id);
+   if (!blob)
+   return;
+
+   blob_data = blob->data;
+
+   for (i = 0; i < blob->length; i++) {
+   if (i % 16 == 0)
+   printf("\n\t\t\t");
+   printf("%.2hhx", blob_data[i]);
+   }
+   printf("\n");
+
+   drmModeFreePropertyBlob(blob);
+}
+
+static void
+dump_prop(uint32_t prop_id, uint64_t value)
 {
-   drmModePropertyPtr props;
int i;
+   drmModePropertyPtr prop;
+
+   prop = drmModeGetProperty(fd, prop_id);
+
+   printf("\t%d", prop_id);
+   if (!prop) {
+   printf("\n");
+   return;
+   }
+
+   printf(" %s:\n", prop->name);
+
+   printf("\t\tflags:");
+   if (prop->flags & DRM_MODE_PROP_PENDING)
+   printf(" pending");
+   if (prop->flags & DRM_MODE_PROP_RANGE)
+   printf(" range");
+   if (prop->flags & DRM_MODE_PROP_IMMUTABLE)
+   printf(" immutable");
+   if (prop->flags & DRM_MODE_PROP_ENUM)
+   printf(" enum");
+   if (prop->flags & DRM_MODE_PROP_BLOB)
+   printf(" blob");
+   printf("\n");
+
+   if (prop->flags & DRM_MODE_PROP_RANGE) {
+   printf("\t\tvalues:");
+   for (i = 0; i < prop->count_values; i++)
+   printf(" %"PRIu64, prop->values[i]);
+   printf("\n");
+   }

-   for (i = 0; i < connector->count_props; i++) {
-   props = drmModeGetProperty(fd, connector->props[i]);
-   printf("\t%s, flags %d\n", props->name, props->flags);
-   drmModeFreeProperty(props);
+   if (prop->flags & DRM_MODE_PROP_ENUM) {
+   printf("\t\tenums:");
+   for (i = 0; i < prop->count_enums; i++)
+   printf(" %s=%llu", prop->enums[i].name,
+  prop->enums[i].value);
+   printf("\n");
+   } else {
+   assert(prop->count_enums == 0);
}
+
+   if (prop->flags & DRM_MODE_PROP_BLOB) {
+   printf("\t\tblobs:\n");
+   for (i = 0; i < prop->count_blobs; i++)
+   dump_blob(prop->blob_ids[i]);
+   printf("\n");
+   } else {
+   assert(prop->count_blobs == 0);
+   }
+
+   printf("\t\tvalue:");
+   if (prop->flags & DRM_MODE_PROP_BLOB)
+   dump_blob(value);
+   else
+   printf(" %"PRIu64"\n", value);
+
+   drmModeFreeProperty(prop);
 }

 void dump_connectors(void)
@@ -201,13 +276,15 @@ void dump_connectors(void)

if (connector->count_modes) {
printf("  modes:\n");
-   printf("  name refresh (Hz) hdisp hss hse htot vdisp "
+   printf("\tname refresh (Hz) hdisp hss hse htot vdisp "
   "vss vse vtot)\n");
for (j = 0; j < connector->count_modes; j++)
dump_mode(>modes[j]);

printf("  props:\n");
-   dump_props(connector);
+   for (j = 0; j < connector->count_props; j++)
+   dump_prop(connector->props[j],
+ connector->prop_values[j]);
}

[PATCH libdrm 3/4] modetest: call drmModeFreePlaneResources

[Paulo Zanoni]

From: Paulo Zanoni 

24 (16 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 
2 of 7
   at 0x402994D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x4A25950: drmMalloc (xf86drm.c:147)
   by 0x4A2E26D: drmModeGetPlaneResources (xf86drmMode.c:951)
   by 0x4025FF: dump_planes (modetest.c:276)
   by 0x4052AF: main (modetest.c:1120)

Signed-off-by: Paulo Zanoni 
---
 tests/modetest/modetest.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 64809da..6deed69 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -307,6 +307,7 @@ static void dump_planes(void)
}
printf("\n");

+   drmModeFreePlaneResources(plane_resources);
return;
 }

-- 
1.7.9.5

[PATCH libdrm 2/4] modetest: fix drmModeGetConnector memory leak

[Paulo Zanoni]

From: Paulo Zanoni 

Don't "continue" without freeing the connector.

192 bytes in 6 blocks are indirectly lost in loss record 6 of 12
   at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x4E30DD8: drmMalloc (xf86drm.c:147)
   by 0x4E35024: drmAllocCpy (xf86drmMode.c:73)
   by 0x4E35D69: drmModeGetConnector (xf86drmMode.c:507)
   by 0x402F22: dump_connectors (modetest.c:181)
   by 0x40261B: main (modetest.c:801)

Reviewed-by: Eugeni Dodonov 
Signed-off-by: Paulo Zanoni 
---
 tests/modetest/modetest.c |   21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 1b9ae18..64809da 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -199,17 +199,16 @@ void dump_connectors(void)
printf("%s%d", j > 0 ? ", " : "", 
connector->encoders[j]);
printf("\n");

-   if (!connector->count_modes)
-   continue;
-
-   printf("  modes:\n");
-   printf("  name refresh (Hz) hdisp hss hse htot vdisp "
-  "vss vse vtot)\n");
-   for (j = 0; j < connector->count_modes; j++)
-   dump_mode(>modes[j]);
-
-   printf("  props:\n");
-   dump_props(connector);
+   if (connector->count_modes) {
+   printf("  modes:\n");
+   printf("  name refresh (Hz) hdisp hss hse htot vdisp "
+  "vss vse vtot)\n");
+   for (j = 0; j < connector->count_modes; j++)
+   dump_mode(>modes[j]);
+
+   printf("  props:\n");
+   dump_props(connector);
+   }

drmModeFreeConnector(connector);
}
-- 
1.7.9.5

[PATCH libdrm 1/4] modetest: fix some compiler warnings

[Paulo Zanoni]

From: Paulo Zanoni 

Use unsigned int instead of int:
- modetest.c:90:1: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]
- modetest.c:98:1: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]
- modetest.c:118:1: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]
- modetest.c:286:16: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]
- modetest.c:303:17: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]
- modetest.c:694:16: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]
- modetest.c:1088:16: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]

The 'fd' variable is global, we don't need to pass it as an argument:
- modetest.c:998:40: warning: unused parameter ?fd? [-Wunused-parameter]

We don't use the 'modeset' variable:
- modetest.c:1025:8: warning: variable ?modeset? set but not used 
[-Wunused-but-set-variable]

V2: rebase, clear some more warnings

Signed-off-by: Paulo Zanoni 
---
 tests/modetest/modetest.c |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

Hi

I'm sending this patch series again. These 4 patches are independent
from the object properties patches, so once reviewed, it would be nice
if someone could push them.

Patch 1 had to be rebased and patch 3 is new.

Thanks,
Paulo


diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 223adc4..1b9ae18 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -71,7 +71,7 @@ struct type_name {

 #define type_name_fn(res) \
 char * res##_str(int type) {   \
-   int i;  \
+   unsigned int i; \
for (i = 0; i < ARRAY_SIZE(res##_names); i++) { \
if (res##_names[i].type == type)\
return res##_names[i].name; \
@@ -272,7 +272,7 @@ static void dump_planes(void)
 {
drmModePlaneRes *plane_resources;
drmModePlane *ovr;
-   int i, j;
+   unsigned int i, j;

plane_resources = drmModeGetPlaneResources(fd);
if (!plane_resources) {
@@ -681,7 +681,8 @@ set_plane(struct kms_driver *kms, struct connector *c, 
struct plane *p)
uint32_t plane_id = 0;
struct kms_bo *plane_bo;
uint32_t plane_flags = 0, format;
-   int i, ret, crtc_x, crtc_y, crtc_w, crtc_h;
+   int ret, crtc_x, crtc_y, crtc_w, crtc_h;
+   unsigned int i;

/* find an unused plane which can be connected to our crtc */
plane_resources = drmModeGetPlaneResources(fd);
@@ -995,7 +996,7 @@ void usage(char *name)

 #define dump_resource(res) if (res) dump_##res()

-static int page_flipping_supported(int fd)
+static int page_flipping_supported(void)
 {
/*FIXME: generic ioctl needed? */
return 1;
@@ -1022,8 +1023,8 @@ int main(int argc, char **argv)
int encoders = 0, connectors = 0, crtcs = 0, planes = 0, framebuffers = 
0;
int test_vsync = 0;
char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "omapdrm" };
-   char *modeset = NULL;
-   int i, count = 0, plane_count = 0;
+   unsigned int i;
+   int count = 0, plane_count = 0;
struct connector con_args[2];
struct plane plane_args[2] = {0};

@@ -1050,7 +1051,6 @@ int main(int argc, char **argv)
test_vsync = 1;
break;
case 's':
-   modeset = strdup(optarg);
con_args[count].crtc = -1;
if (sscanf(optarg, "%d:%64s",
   _args[count].id,
@@ -1096,7 +1096,7 @@ int main(int argc, char **argv)
}
}

-   if (test_vsync && !page_flipping_supported(fd)) {
+   if (test_vsync && !page_flipping_supported()) {
fprintf(stderr, "page flipping not supported by drm.\n");
return -1;
}
-- 
1.7.9.5

[PATCH libdrm 3/5] modetest: print more about our properties

[Paulo Zanoni]

2012/3/29 Eugeni Dodonov :
> On Thu, Mar 29, 2012 at 18:28, Paulo Zanoni  wrote:
>
> 
> I don't know if it should go into a separate patch though. But it is aligned
> to the other formatting patterns you do, and it certainly looks nicer this
> way, and it shouldn't break anything anyway. So I am fine either way :).
> 

I agree, but it's a single-line change that does not make much sense without
this patch, so I decided to not have a patch that just replaces "  " with "\t".

>> The previous function dump_props also segfaulted when we didn't have
>> enought permissions. The new function does not segfault in this case (by
>> checking for the return value of drmModeGetProperty).
>
> 
> I think this could be done in a separate patch..
> 

No. This is just a note like "the function I just killed had a bug,
the function
that replaces it does not have the same bug". It would make no sense
to send a
patch to fix the old function, then send this patch replacing the
whole
function. Why fix it if you're going to replace it?


-- 
Paulo Zanoni

[PATCH libdrm 1/5] modetest: fix some compiler warnings

[Paulo Zanoni]

2012/3/29 Eugeni Dodonov :
> I wonder if we could drop the dead^W#ifd 0'ed code here as well, perhaps
> with a separate patch? I don't think it will get used again in the future
> (but I might be wrong).
>

Removing #if 0'ed code won't fix compiler warnings, so if we do this,
it should
be done in a separate patch.

I'm resending this patch with more warning fixes and a rebase.


-- 
Paulo Zanoni

VM lockdep warning

[Dave Airlie]

2012/4/21 Jerome Glisse :
> 2012/4/21 Christian K?nig :
>> On 21.04.2012 16:08, Jerome Glisse wrote:
>>>
>>> 2012/4/21 Christian K?nig:

 Interesting, I'm pretty sure that I haven't touched the locking order of
 the
 cs_mutex vs. vm_mutex.

 Maybe it is just some kind of side effect, going to locking into it
 anyway.

 Christian.

>>> It's the using, init path take lock in different order than cs path
>>
>> Well, could you explain to me why the vm code takes cs mutex in the first
>> place?
>>
>> It clearly has it's own mutex and it doesn't looks like that it deals with
>> any cs related data anyway.
>>
>> Christian.
>
> Lock simplification is on my todo. The issue is that vm manager is protected 
> by
> cs_mutex The vm.mutex is specific to each vm it doesn't protect the global vm
> management. I didn't wanted to introduce a new global vm mutex as vm activity
> is mostly trigger on behalf of cs so i dediced to use the cs mutex.
>
> That's why non cs path of vm need to take the cs mutex.

So if one app is adding a bo, and another doing CS, isn't deadlock a
real possibility?

I expect the VM code need to take CS mutex earlier then.

Dave.

VM lockdep warning

[Christian König]

On 21.04.2012 16:08, Jerome Glisse wrote:
> 2012/4/21 Christian K?nig:
>> Interesting, I'm pretty sure that I haven't touched the locking order of the
>> cs_mutex vs. vm_mutex.
>>
>> Maybe it is just some kind of side effect, going to locking into it anyway.
>>
>> Christian.
>>
> It's the using, init path take lock in different order than cs path
Well, could you explain to me why the vm code takes cs mutex in the 
first place?

It clearly has it's own mutex and it doesn't looks like that it deals 
with any cs related data anyway.

Christian.

i915: kernel errors at resume

[Paul Bolle]

On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote:
> Please file a bug report with the error state attach (the
> entire thing), complete dmesg showing when the problem happens and a short
> description of the issue at bugs.freedesktop.org against DRI, component
> DRM/Intel.

See https://bugs.freedesktop.org/show_bug.cgi?id=49041 for that report.


Paul Bolle

[Regression][3.4-rc3][intel-dri] MMIO read or write has been dropped ffffffff

[Daniel Vetter]

On Sat, Apr 21, 2012 at 03:03:07PM +0200, Daniel Vetter wrote:
> On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote:
> > Bad kernel: 3.4-rc3
> > Last known good: 3.3
> > 
> > Subsystem: dri-intel (guess)
> > 
> > Steps to reproduce:
> > 1. Suspend to ram
> > 2. Resume
> > 
> > After resume laptop works ok, but in dmesg I found:
> > [  164.098113] [ cut here ]
> > [  164.098124] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398 
> > gen6_gt_check_fifodbg.isra.6+0x31/0x43()
> > [  164.098126] Hardware name: 1141ALG
> > [  164.098128] MMIO read or write has been dropped 
> > [  164.098129] Modules linked in: xt_tcpudp xt_limit xt_state 
> > iptable_filter 
> > nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables x_tables bnep 
> > rfcomm 
> > bluetooth uinput fuse loop sha256_generic aes_x86_64 aes_generic cbc 
> > dm_crypt 
> > dm_mod uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev 
> > usbhid hid media snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi 
> > mac80211 thinkpad_acpi cfg80211 coretemp nvram snd_hda_intel snd_hda_codec 
> > snd_hwdep snd_pcm snd_page_alloc snd_seq ehci_hcd sdhci_pci crc32c_intel 
> > iTCO_wdt iTCO_vendor_support ghash_clmulni_intel snd_seq_device cryptd 
> > snd_timer microcode snd acpi_cpufreq mperf usbcore psmouse sdhci r8169 
> > mmc_core mii ac rfkill i2c_i801 soundcore mei(C) serio_raw pcspkr thermal 
> > battery power_supply wmi usb_common evdev processor
> > [  164.098188] Pid: 4684, comm: kworker/u:9 Tainted: G C   
> > 3.4.0-rc3 
> > #1
> > [  164.098189] Call Trace:
> > [  164.098197]  [] warn_slowpath_common+0x7e/0x96
> > [  164.098200]  [] warn_slowpath_fmt+0x41/0x43
> > [  164.098203]  [] gen6_gt_check_fifodbg.isra.6+0x31/0x43
> > [  164.098207]  [] __gen6_gt_force_wake_put+0x19/0x1b
> > [  164.098210]  [] i915_read32+0x66/0x9d
> > [  164.098213]  [] i915_update_gfx_val+0x61/0xb9
> > [  164.098218]  [] intel_idle_update+0x47/0x18d
> > [  164.098222]  [] process_one_work+0x1b5/0x340
> > [  164.098225]  [] ? process_one_work+0x118/0x340
> > [  164.098228]  [] ? intel_disable_plane+0x60/0x60
> > [  164.098231]  [] worker_thread+0xce/0x152
> > [  164.098234]  [] ? manage_workers.isra.22+0x16a/0x16a
> > [  164.098237]  [] kthread+0xa1/0xa9
> > [  164.098242]  [] ? trace_hardirqs_on+0xd/0xf
> > [  164.098246]  [] kernel_thread_helper+0x4/0x10
> > [  164.098250]  [] ? retint_restore_args+0x13/0x13
> > [  164.098253]  [] ? __init_kthread_worker+0x55/0x55
> > [  164.098256]  [] ? gs_change+0x13/0x13
> > [  164.098257] ---[ end trace 97bd0b679d161c3e ]---
> > [  164.098827] [ cut here ]
> > [  164.098830] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398 
> > gen6_gt_check_fifodbg.isra.6+0x31/0x43()
> > [  164.098832] Hardware name: 1141ALG
> > [  164.098833] MMIO read or write has been dropped 
> > [  164.098834] Modules linked in: xt_tcpudp xt_limit xt_state 
> > iptable_filter 
> > nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables x_tables bnep 
> > rfcomm 
> > bluetooth uinput fuse loop sha256_generic aes_x86_64 aes_generic cbc 
> > dm_crypt 
> > dm_mod uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev 
> > usbhid hid media snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi 
> > mac80211 thinkpad_acpi cfg80211 coretemp nvram snd_hda_intel snd_hda_codec 
> > snd_hwdep snd_pcm snd_page_alloc snd_seq ehci_hcd sdhci_pci crc32c_intel 
> > iTCO_wdt iTCO_vendor_support ghash_clmulni_intel snd_seq_device cryptd 
> > snd_timer microcode snd acpi_cpufreq mperf usbcore psmouse sdhci r8169 
> > mmc_core mii ac rfkill i2c_i801 soundcore mei(C) serio_raw pcspkr thermal 
> > battery power_supply wmi usb_common evdev processor
> > [  164.098877] Pid: 4684, comm: kworker/u:9 Tainted: GWC   
> > 3.4.0-rc3 
> > #1
> > [  164.098878] Call Trace:
> > [  164.098881]  [] warn_slowpath_common+0x7e/0x96
> > [  164.098884]  [] warn_slowpath_fmt+0x41/0x43
> > [  164.09]  [] gen6_gt_check_fifodbg.isra.6+0x31/0x43
> > [  164.098891]  [] __gen6_gt_force_wake_put+0x19/0x1b
> > [  164.098894]  [] i915_read32+0x66/0x9d
> > [  164.098896]  [] intel_idle_update+0x9f/0x18d
> > [  164.098899]  [] process_one_work+0x1b5/0x340
> > [  164.098902]  [] ? process_one_work+0x118/0x340
> > [  164.098904]  [] ? intel_disable_plane+0x60/0x60
> > [  164.098907]  [] worker_thread+0xce/0x152
> > [  164.098910]  [] ? manage_workers.isra.22+0x16a/0x16a
> > [  164.098913]  [] kthread+0xa1/0xa9
> > [  164.098916]  [] ? trace_hardirqs_on+0xd/0xf
> > [  164.098918]  [] kernel_thread_helper+0x4/0x10
> > [  164.098921]  [] ? retint_restore_args+0x13/0x13
> > [  164.098925]  [] ? __init_kthread_worker+0x55/0x55
> > [  164.098927]  [] ? gs_change+0x13/0x13
> > [  164.098928] ---[ end trace 97bd0b679d161c3f ]---
> > 
> > I found similar report in:
> > https://bugzilla.redhat.com/show_bug.cgi?id=809773
> > 
> > Dmesg, config and lspci:
> > 

i915: kernel errors at resume

[Daniel Vetter]

On Sat, Apr 21, 2012 at 02:58:39PM +0200, Paul Bolle wrote:
> On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote:
> > On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote:
> > > What part of that almost 700K file could be of interest?
> > 
> > All of it. Please file a bug report with the error state attach (the
> > entire thing), complete dmesg showing when the problem happens and a short
> > description of the issue at bugs.freedesktop.org against DRI, component
> > DRM/Intel.
> 
> OK, I'll do that then. Would you know whether bugs.freedesktop.org
> requires me to compress files of that size?

Please don't if possible, it's a hassle to first unzip it. And usually it
works without issues.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Regression][3.4-rc3][intel-dri] MMIO read or write has been dropped ffffffff

[Daniel Vetter]

On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote:
> Bad kernel: 3.4-rc3
> Last known good: 3.3
> 
> Subsystem: dri-intel (guess)
> 
> Steps to reproduce:
> 1. Suspend to ram
> 2. Resume
> 
> After resume laptop works ok, but in dmesg I found:
> [  164.098113] [ cut here ]
> [  164.098124] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398 
> gen6_gt_check_fifodbg.isra.6+0x31/0x43()
> [  164.098126] Hardware name: 1141ALG
> [  164.098128] MMIO read or write has been dropped 
> [  164.098129] Modules linked in: xt_tcpudp xt_limit xt_state iptable_filter 
> nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables x_tables bnep rfcomm 
> bluetooth uinput fuse loop sha256_generic aes_x86_64 aes_generic cbc dm_crypt 
> dm_mod uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev 
> usbhid hid media snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi 
> mac80211 thinkpad_acpi cfg80211 coretemp nvram snd_hda_intel snd_hda_codec 
> snd_hwdep snd_pcm snd_page_alloc snd_seq ehci_hcd sdhci_pci crc32c_intel 
> iTCO_wdt iTCO_vendor_support ghash_clmulni_intel snd_seq_device cryptd 
> snd_timer microcode snd acpi_cpufreq mperf usbcore psmouse sdhci r8169 
> mmc_core mii ac rfkill i2c_i801 soundcore mei(C) serio_raw pcspkr thermal 
> battery power_supply wmi usb_common evdev processor
> [  164.098188] Pid: 4684, comm: kworker/u:9 Tainted: G C   3.4.0-rc3 
> #1
> [  164.098189] Call Trace:
> [  164.098197]  [] warn_slowpath_common+0x7e/0x96
> [  164.098200]  [] warn_slowpath_fmt+0x41/0x43
> [  164.098203]  [] gen6_gt_check_fifodbg.isra.6+0x31/0x43
> [  164.098207]  [] __gen6_gt_force_wake_put+0x19/0x1b
> [  164.098210]  [] i915_read32+0x66/0x9d
> [  164.098213]  [] i915_update_gfx_val+0x61/0xb9
> [  164.098218]  [] intel_idle_update+0x47/0x18d
> [  164.098222]  [] process_one_work+0x1b5/0x340
> [  164.098225]  [] ? process_one_work+0x118/0x340
> [  164.098228]  [] ? intel_disable_plane+0x60/0x60
> [  164.098231]  [] worker_thread+0xce/0x152
> [  164.098234]  [] ? manage_workers.isra.22+0x16a/0x16a
> [  164.098237]  [] kthread+0xa1/0xa9
> [  164.098242]  [] ? trace_hardirqs_on+0xd/0xf
> [  164.098246]  [] kernel_thread_helper+0x4/0x10
> [  164.098250]  [] ? retint_restore_args+0x13/0x13
> [  164.098253]  [] ? __init_kthread_worker+0x55/0x55
> [  164.098256]  [] ? gs_change+0x13/0x13
> [  164.098257] ---[ end trace 97bd0b679d161c3e ]---
> [  164.098827] [ cut here ]
> [  164.098830] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398 
> gen6_gt_check_fifodbg.isra.6+0x31/0x43()
> [  164.098832] Hardware name: 1141ALG
> [  164.098833] MMIO read or write has been dropped 
> [  164.098834] Modules linked in: xt_tcpudp xt_limit xt_state iptable_filter 
> nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables x_tables bnep rfcomm 
> bluetooth uinput fuse loop sha256_generic aes_x86_64 aes_generic cbc dm_crypt 
> dm_mod uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev 
> usbhid hid media snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi 
> mac80211 thinkpad_acpi cfg80211 coretemp nvram snd_hda_intel snd_hda_codec 
> snd_hwdep snd_pcm snd_page_alloc snd_seq ehci_hcd sdhci_pci crc32c_intel 
> iTCO_wdt iTCO_vendor_support ghash_clmulni_intel snd_seq_device cryptd 
> snd_timer microcode snd acpi_cpufreq mperf usbcore psmouse sdhci r8169 
> mmc_core mii ac rfkill i2c_i801 soundcore mei(C) serio_raw pcspkr thermal 
> battery power_supply wmi usb_common evdev processor
> [  164.098877] Pid: 4684, comm: kworker/u:9 Tainted: GWC   3.4.0-rc3 
> #1
> [  164.098878] Call Trace:
> [  164.098881]  [] warn_slowpath_common+0x7e/0x96
> [  164.098884]  [] warn_slowpath_fmt+0x41/0x43
> [  164.09]  [] gen6_gt_check_fifodbg.isra.6+0x31/0x43
> [  164.098891]  [] __gen6_gt_force_wake_put+0x19/0x1b
> [  164.098894]  [] i915_read32+0x66/0x9d
> [  164.098896]  [] intel_idle_update+0x9f/0x18d
> [  164.098899]  [] process_one_work+0x1b5/0x340
> [  164.098902]  [] ? process_one_work+0x118/0x340
> [  164.098904]  [] ? intel_disable_plane+0x60/0x60
> [  164.098907]  [] worker_thread+0xce/0x152
> [  164.098910]  [] ? manage_workers.isra.22+0x16a/0x16a
> [  164.098913]  [] kthread+0xa1/0xa9
> [  164.098916]  [] ? trace_hardirqs_on+0xd/0xf
> [  164.098918]  [] kernel_thread_helper+0x4/0x10
> [  164.098921]  [] ? retint_restore_args+0x13/0x13
> [  164.098925]  [] ? __init_kthread_worker+0x55/0x55
> [  164.098927]  [] ? gs_change+0x13/0x13
> [  164.098928] ---[ end trace 97bd0b679d161c3f ]---
> 
> I found similar report in:
> https://bugzilla.redhat.com/show_bug.cgi?id=809773
> 
> Dmesg, config and lspci:
> http://mrutecki.pl/download/kernel/3.4-rc3/dri_intel/

Can you please take these files and create a bug report at
bugs.freedesktop.org. Also, is there anything going wrong besides these
error message while you do a suspend cycle?

I'm asking because we newly added this error message to catch potential
issues, but without anything 

i915: kernel errors at resume

[Paul Bolle]

On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote:
> On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote:
> > What part of that almost 700K file could be of interest?
> 
> All of it. Please file a bug report with the error state attach (the
> entire thing), complete dmesg showing when the problem happens and a short
> description of the issue at bugs.freedesktop.org against DRI, component
> DRM/Intel.

OK, I'll do that then. Would you know whether bugs.freedesktop.org
requires me to compress files of that size?


Paul Bollw

i915: kernel errors at resume

[Daniel Vetter]

On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote:
> On Thu, 2012-04-19 at 11:04 +0200, Paul Bolle wrote:
> > <6>[14673.824599] [drm] capturing error event; look for more information in 
> > /debug/dri/0/i915_error_state
> 
> I triggered this issue once again in the session I run currently:
> $ cat /sys/kernel/debug/dri/0/i915_error_state | wc -c
> 689681
> 
> What part of that almost 700K file could be of interest?

All of it. Please file a bug report with the error state attach (the
entire thing), complete dmesg showing when the problem happens and a short
description of the issue at bugs.freedesktop.org against DRI, component
DRM/Intel.

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

VM lockdep warning

[Christian König]

Interesting, I'm pretty sure that I haven't touched the locking order of 
the cs_mutex vs. vm_mutex.

Maybe it is just some kind of side effect, going to locking into it anyway.

Christian.

On 21.04.2012 13:39, Dave Airlie wrote:
> running 3.4.0-rc3 + Christian's reset patch series.
>
> The locks are definitely taken in different orders between vm_bo_add
> and cs ioctl.
>
> Dave.
>
> ==
> [ INFO: possible circular locking dependency detected ]
> 3.4.0-rc3+ #33 Not tainted
> ---
> shader_runner/3090 is trying to acquire lock:
>   (>mutex){+.+...}, at: []
> radeon_cs_ioctl+0x438/0x5c1 [radeon]
>
> but task is already holding lock:
>   (>cs_mutex){+.+.+.}, at: []
> radeon_cs_ioctl+0x33/0x5c1 [radeon]
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> ->  #1 (>cs_mutex){+.+.+.}:
> [] lock_acquire+0xf0/0x116
> [] mutex_lock_nested+0x6a/0x2bb
> [] radeon_vm_bo_add+0x118/0x1f5 [radeon]
> [] radeon_vm_init+0x6b/0x70 [radeon]
> [] radeon_driver_open_kms+0x68/0x9a [radeon]
> [] drm_open+0x201/0x587 [drm]
> [] drm_stub_open+0xec/0x14a [drm]
> [] chrdev_open+0x11c/0x145
> [] __dentry_open+0x17e/0x29b
> [] nameidata_to_filp+0x5b/0x62
> [] do_last+0x75d/0x771
> [] path_openat+0xcb/0x380
> [] do_filp_open+0x33/0x81
> [] do_sys_open+0x100/0x192
> [] sys_open+0x1c/0x1e
> [] system_call_fastpath+0x16/0x1b
>
> ->  #0 (>mutex){+.+...}:
> [] __lock_acquire+0xfcd/0x1664
> [] lock_acquire+0xf0/0x116
> [] mutex_lock_nested+0x6a/0x2bb
> [] radeon_cs_ioctl+0x438/0x5c1 [radeon]
> [] drm_ioctl+0x2d8/0x3a4 [drm]
> [] do_vfs_ioctl+0x469/0x4aa
> [] sys_ioctl+0x51/0x75
> [] system_call_fastpath+0x16/0x1b
>
> other info that might help us debug this:
>
>   Possible unsafe locking scenario:
>
> CPU0CPU1
> 
>lock(>cs_mutex);
> lock(>mutex);
> lock(>cs_mutex);
>lock(>mutex);
>
>   *** DEADLOCK ***
>
> 1 lock held by shader_runner/3090:
>   #0:  (>cs_mutex){+.+.+.}, at: []
> radeon_cs_ioctl+0x33/0x5c1 [radeon]
>
> stack backtrace:
> Pid: 3090, comm: shader_runner Not tainted 3.4.0-rc3+ #33
> Call Trace:
>   [] print_circular_bug+0x28a/0x29b
>   [] __lock_acquire+0xfcd/0x1664
>   [] lock_acquire+0xf0/0x116
>   [] ? radeon_cs_ioctl+0x438/0x5c1 [radeon]
>   [] ? might_fault+0x57/0xa7
>   [] mutex_lock_nested+0x6a/0x2bb
>   [] ? radeon_cs_ioctl+0x438/0x5c1 [radeon]
>   [] ? evergreen_ib_parse+0x1b2/0x204 [radeon]
>   [] radeon_cs_ioctl+0x438/0x5c1 [radeon]
>   [] drm_ioctl+0x2d8/0x3a4 [drm]
>   [] ? radeon_cs_finish_pages+0xa3/0xa3 [radeon]
>   [] ? avc_has_perm_flags+0xd7/0x160
>   [] ? avc_has_perm_flags+0x26/0x160
>   [] ? up_read+0x1b/0x32
>   [] do_vfs_ioctl+0x469/0x4aa
>   [] sys_ioctl+0x51/0x75
>   [] ? __wake_up+0x1d/0x48
>   [] system_call_fastpath+0x16/0x1b
>

i915: kernel errors at resume

[Paul Bolle]

On Thu, 2012-04-19 at 11:04 +0200, Paul Bolle wrote:
> <6>[14673.824599] [drm] capturing error event; look for more information in 
> /debug/dri/0/i915_error_state

I triggered this issue once again in the session I run currently:
$ cat /sys/kernel/debug/dri/0/i915_error_state | wc -c
689681

What part of that almost 700K file could be of interest?


Paul Bolle

VM lockdep warning

[Jerome Glisse]

2012/4/21 Christian K?nig :
> On 21.04.2012 17:57, Dave Airlie wrote:
>>
>> 2012/4/21 Jerome Glisse:
>>>
>>> 2012/4/21 Christian K?nig:

 On 21.04.2012 16:08, Jerome Glisse wrote:
>
> 2012/4/21 Christian K?nig:
>>
>> Interesting, I'm pretty sure that I haven't touched the locking order
>> of
>> the
>> cs_mutex vs. vm_mutex.
>>
>> Maybe it is just some kind of side effect, going to locking into it
>> anyway.
>>
>> Christian.
>>
> It's the using, init path take lock in different order than cs path

 Well, could you explain to me why the vm code takes cs mutex in the
 first
 place?

 It clearly has it's own mutex and it doesn't looks like that it deals
 with
 any cs related data anyway.

 Christian.
>>>
>>> Lock simplification is on my todo. The issue is that vm manager is
>>> protected by
>>> cs_mutex The vm.mutex is specific to each vm it doesn't protect the
>>> global vm
>>> management. I didn't wanted to introduce a new global vm mutex as vm
>>> activity
>>> is mostly trigger on behalf of cs so i dediced to use the cs mutex.
>>>
>>> That's why non cs path of vm need to take the cs mutex.
>>
>> So if one app is adding a bo, and another doing CS, isn't deadlock a
>> real possibility?
>
> Yeah, I think so.

No it's not. Look at the code.

>> I expect the VM code need to take CS mutex earlier then.

No it does not. The idea is that when adding a bo we only need to take the
cs mutex if we need to resize the vm size (and even that can be worked around).

So we will need to take the cs ioctl in very few case (suspend, increasing vm
size).

>
> I would strongly suggest to give the vm code their own global mutex and
> remove the per vm mutex, cause the later is pretty superfluous if the
> cs_mutex is also taken most of the time.
>
> The attached patch is against drm-fixes and does exactly that.
>
> Christian.

NAK with your change there will be lock contention if one app is in cs and
another try to create bo. Currently there is allmost never contention. Once
i ironed out the DP->VGA i will work on something to remove the cs mutex
from vm path (ie remove it from bo creation/del path).

Cheers,
Jerome

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

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

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

--- Comment #70 from Daniel Vetter  2012-04-21 06:08:48 PDT 
---
Created attachment 60416
  --> https://bugs.freedesktop.org/attachment.cgi?id=60416
drm driver reload script

Looks like you've made a start alright. As I've said, I've you're getting stuck
somewhere, don't be afreaid to pop up on #intel-gfx on irc. To speed up the
development you can also only reload the drm/i915.ko kernel module. It's a bit
tricky, so I use the attached script (you still need to compile i915.ko and
copy it into the right place, of course).

You also need to enable CONFIG_VT_HW_CONSOLE_BINDING, otherwise the fbcon
unbinding won't work and you can't unload i915.ko. Also, a 2nd machine with ssh
access is very nice in case the module-reloading failed - otherwise you'll just
be starring at a blank screen.

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

[PATCH 1/2] drm: exynos: Use DRM_FORMAT_{NV12, YUV420} instead of DRM_FORMAT_{NV12M, YUV420M}

[InKi Dae]

thanks for your patch but your patch set needs some codes for
identifying whether pixel format is multiplanar or not as you
mentioned. so I will add the codes and apply your patch set to
exynos-drm-fixes branch for drm-fixes.


2012? 4? 21? ?? 12:26,  ?? ?:
> From: Ville Syrj?l? 
>
> The NV12M/YUV420M formats are identical to the already existing standard
> NV12/YUV420 formats. The M variants will be removed, so convert the
> driver to use the standard names.
>
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Signed-off-by: Ville Syrj?l? 
> ---
> Extra note: Based on a quick look, the driver appears to lack
> sufficient sanity checks wrt. the framebuffer layout. I guess it
> just assumes that handles[0] != handles[1] and offsets[] = { 0 }.
>
> ?drivers/gpu/drm/exynos/exynos_drm_fb.h | ? ?4 ++--
> ?drivers/gpu/drm/exynos/exynos_mixer.c ?| ? ?2 +-
> ?2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h 
> b/drivers/gpu/drm/exynos/exynos_drm_fb.h
> index 3ecb30d..5082375 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.h
> @@ -31,10 +31,10 @@
> ?static inline int exynos_drm_format_num_buffers(uint32_t format)
> ?{
> ? ? ? ?switch (format) {
> - ? ? ? case DRM_FORMAT_NV12M:
> + ? ? ? case DRM_FORMAT_NV12:
> ? ? ? ?case DRM_FORMAT_NV12MT:
> ? ? ? ? ? ? ? ?return 2;
> - ? ? ? case DRM_FORMAT_YUV420M:
> + ? ? ? case DRM_FORMAT_YUV420:
> ? ? ? ? ? ? ? ?return 3;
> ? ? ? ?default:
> ? ? ? ? ? ? ? ?return 1;
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 4d5f41e..f1e2369 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -370,7 +370,7 @@ static void vp_video_buffer(struct mixer_context *ctx, 
> int win)
> ? ? ? ?switch (win_data->pixel_format) {
> ? ? ? ?case DRM_FORMAT_NV12MT:
> ? ? ? ? ? ? ? ?tiled_mode = true;
> - ? ? ? case DRM_FORMAT_NV12M:
> + ? ? ? case DRM_FORMAT_NV12:
> ? ? ? ? ? ? ? ?crcb_mode = false;
> ? ? ? ? ? ? ? ?buf_num = 2;
> ? ? ? ? ? ? ? ?break;
> --
> 1.7.3.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] drm: Move drm_format_num_planes() to drm_crtc.c

[InKi Dae]

2012? 4? 20? ?? 11:22, Rob Clark ?? ?:
> On Fri, Apr 20, 2012 at 8:49 AM, Ville Syrj?l?
>  wrote:
>> On Fri, Apr 20, 2012 at 07:48:07AM -0500, Rob Clark wrote:
>>> On Fri, Apr 20, 2012 at 7:29 AM, Dave Airlie  wrote:
>>> > On Fri, Apr 20, 2012 at 1:23 PM, Ville Syrj?l?
>>> >  wrote:
>>> >> On Fri, Apr 20, 2012 at 12:43:03PM +0100, Dave Airlie wrote:
>>> >>> On Thu, Apr 5, 2012 at 7:35 PM, ? 
>>> >>> wrote:
>>> >>> > From: Ville Syrj?l? 
>>> >>> >
>>> >>> > There will be a need for this function in drm_crtc.c later. This
>>> >>> > avoids making drm_crtc.c depend on drm_crtc_helper.c.
>>> >>>
>>> >>> Hi Ville,
>>> >>>
>>> >>> I've applied these 4 patches, but I might have lost some others for
>>> >>> you, let me know if there is some other stuff I should be reviewing
>>> >>> for -next.
>>> >>
>>> >> IIRC only one patch fell through the cracks:
>>> >> Subject: [PATCH] drm: Unify and fix idr error handling
>>> >> Message-Id: <1331834311-30757-1-git-send-email-ville.syrjala at 
>>> >> linux.intel.com>
>>> >
>>> > Thanks I'll take a look at that,
>>> >
>>> >>
>>> >> BTW you never gave any statement wrt. removing NV12M and YUV420M from
>>> >> drm_fourcc.h. I can send a patch if you agree, and if not, well then
>>> >> someone has to actually change the code to treat them exactly the same
>>> >> as NV12 and YUV420.
>>> >
>>> > I'm probably not qualified, if you and jbarnes and say one other
>>> > non-Intel person agree, then send the patch with R-b and I'll apply
>>> > it.
>>>
>>> I agree that they seem like the same thing (as their non-M
>>> counterparts) to me.. ?maybe the one exception is if there was hw that
>>> somehow *only* supported discontiguous multi-planar.
>>
>> The way things are currently, anyone can feed the driver either
>> contiguous or discontiguous planes using either format.
>>
>> As a hint to userspace the M version might work, except it still
>> doesn't tell you anything on how you need to allocate or align the
>> planes. Since memory allocation is driver specific anyway, I see no
>> point in overloading the pixel formats with that information. Some
>> other mechanism to communicate such information would be needed if
>> there is a desire to make it generic.
>>
>>> I can't really
>>> tell if this is the case in current exynos, it seems to only advertise
>>> XRGB (but possibly I'm looking in the wrong place).
>>>
>>> For drivers that have weird requirements, I'd suggest they use the non
>>> 7-bit ascii space (ie. one or more of bytes in fourcc is non-ascii, so
>>> as to not conflict with potential future standard fourcc's) driver
>>> specific format values.
>>
>> We could define a DRM_FORMAT_DRIVER_SPECIFIC bit just like we have
>
> yeah, that is a good idea
>
>> DRM_FORMAT_BIG_ENDIAN. We still have three bits to choose from. OTOH
>> I'm not too worried about standard fourccs since we already differ
>> from the standard names anyway.
>
> well, was more just thinking from the point of view of clashes if we
> add more standard names later but some driver somewhere was already
> using that new fourcc name
>
> Possibly I'm over-thinking this.. but seemed like a reasonable thing
> to separate standard and non-standard formats before a bunch of driver
> specific formats start cropping up.
>
> BR,
> -R

we just wanted to use multi-planar format in same way as v4l2 side and
I am not still sure that it's good way to add some codes to identify
them. anyway for now, I'm ok.

Thanks,
Inki Dae.

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

VM lockdep warning

[Dave Airlie]

running 3.4.0-rc3 + Christian's reset patch series.

The locks are definitely taken in different orders between vm_bo_add
and cs ioctl.

Dave.

==
[ INFO: possible circular locking dependency detected ]
3.4.0-rc3+ #33 Not tainted
---
shader_runner/3090 is trying to acquire lock:
 (>mutex){+.+...}, at: []
radeon_cs_ioctl+0x438/0x5c1 [radeon]

but task is already holding lock:
 (>cs_mutex){+.+.+.}, at: []
radeon_cs_ioctl+0x33/0x5c1 [radeon]

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (>cs_mutex){+.+.+.}:
   [] lock_acquire+0xf0/0x116
   [] mutex_lock_nested+0x6a/0x2bb
   [] radeon_vm_bo_add+0x118/0x1f5 [radeon]
   [] radeon_vm_init+0x6b/0x70 [radeon]
   [] radeon_driver_open_kms+0x68/0x9a [radeon]
   [] drm_open+0x201/0x587 [drm]
   [] drm_stub_open+0xec/0x14a [drm]
   [] chrdev_open+0x11c/0x145
   [] __dentry_open+0x17e/0x29b
   [] nameidata_to_filp+0x5b/0x62
   [] do_last+0x75d/0x771
   [] path_openat+0xcb/0x380
   [] do_filp_open+0x33/0x81
   [] do_sys_open+0x100/0x192
   [] sys_open+0x1c/0x1e
   [] system_call_fastpath+0x16/0x1b

-> #0 (>mutex){+.+...}:
   [] __lock_acquire+0xfcd/0x1664
   [] lock_acquire+0xf0/0x116
   [] mutex_lock_nested+0x6a/0x2bb
   [] radeon_cs_ioctl+0x438/0x5c1 [radeon]
   [] drm_ioctl+0x2d8/0x3a4 [drm]
   [] do_vfs_ioctl+0x469/0x4aa
   [] sys_ioctl+0x51/0x75
   [] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(>cs_mutex);
   lock(>mutex);
   lock(>cs_mutex);
  lock(>mutex);

 *** DEADLOCK ***

1 lock held by shader_runner/3090:
 #0:  (>cs_mutex){+.+.+.}, at: []
radeon_cs_ioctl+0x33/0x5c1 [radeon]

stack backtrace:
Pid: 3090, comm: shader_runner Not tainted 3.4.0-rc3+ #33
Call Trace:
 [] print_circular_bug+0x28a/0x29b
 [] __lock_acquire+0xfcd/0x1664
 [] lock_acquire+0xf0/0x116
 [] ? radeon_cs_ioctl+0x438/0x5c1 [radeon]
 [] ? might_fault+0x57/0xa7
 [] mutex_lock_nested+0x6a/0x2bb
 [] ? radeon_cs_ioctl+0x438/0x5c1 [radeon]
 [] ? evergreen_ib_parse+0x1b2/0x204 [radeon]
 [] radeon_cs_ioctl+0x438/0x5c1 [radeon]
 [] drm_ioctl+0x2d8/0x3a4 [drm]
 [] ? radeon_cs_finish_pages+0xa3/0xa3 [radeon]
 [] ? avc_has_perm_flags+0xd7/0x160
 [] ? avc_has_perm_flags+0x26/0x160
 [] ? up_read+0x1b/0x32
 [] do_vfs_ioctl+0x469/0x4aa
 [] sys_ioctl+0x51/0x75
 [] ? __wake_up+0x1d/0x48
 [] system_call_fastpath+0x16/0x1b

Reworking of GPU reset logic

[Christian König]

On 20.04.2012 01:47, Jerome Glisse wrote:
> 2012/4/19 Christian K?nig:
>> This includes mostly fixes for multi ring lockups and GPU resets, but it 
>> should general improve the behavior of the kernel mode driver in case 
>> something goes badly wrong.
>>
>> On the other hand it completely rewrites the IB pool and semaphore handling, 
>> so I think there are still a couple of problems in it.
>>
>> The first four patches were already send to the list, but the current set 
>> depends on them so I resend them again.
>>
>> Cheers,
>> Christian.
> I did a quick review, it looks mostly good, but as it's sensitive code
> i would like to spend sometime on
> it. Probably next week. Note that i had some work on this area too, i
> mostly want to drop all the debugfs
> related to this and add some new more usefull (basicly something that
> allow you to read all the data
> needed to replay a locking up ib). I also was looking into Dave reset
> thread and your solution of moving
> reset in ioctl return path sounds good too but i need to convince my
> self that it encompass all possible
> case.
>
> Cheers,
> Jerome
>
After sleeping a night over it I already reworked the patch for 
improving the SA performance, so please wait at least for v2 before 
taking a look at it :)

Regarding the debugging of lockups I had the following on my "in mind 
todo" list:
1. Rework the chip specific lockup detection code a bit more and 
probably clean it up a bit.
2. Make the timeout a module parameter, cause compute task sometimes 
block a ring for more than 10 seconds.
3. Keep track of the actually RPTR offset a fence is emitted to
3. Keep track of all the BOs a IB is touching.
4. Now if a lockup happens start with the last successfully signaled 
fence and dump the ring content after that RPTR offset till the first 
not signaled fence.
5. Then if this fence references to an IB dump it's content and the BOs 
it is touching.
6. Dump everything on the ring after that fence until you reach the RPTR 
of the next fence or the WPTR of the ring.
7. If there is a next fence repeat the whole thing at number 5.

If I'm not completely wrong that should give you practically every 
information available, and we probably should put that behind another 
module option, cause we are going to spam syslog pretty much here. Feel 
free to add/modify the ideas on this list.

Christian.

[PATCHv5 00/13] Integration of videobuf2 with dmabuf

[Rob Landley]

On 04/20/2012 09:45 AM, Tomasz Stanislawski wrote:
> Hello everyone,
> This patchset adds support for DMABUF [2] importing to V4L2 stack.
> The support for DMABUF exporting was moved to separate patchset
> due to dependency on patches for DMA mapping redesign by
> Marek Szyprowski [4].

Would it be an an option to _not_ cc: all 14 patches to the linux-doc
list when 12 of them have nothing to do with documentation? (Or do the
tools not allow for that?)

Just wondering...

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.

VM lockdep warning

[Jerome Glisse]

2012/4/21 Christian K?nig :
> On 21.04.2012 16:08, Jerome Glisse wrote:
>>
>> 2012/4/21 Christian K?nig:
>>>
>>> Interesting, I'm pretty sure that I haven't touched the locking order of
>>> the
>>> cs_mutex vs. vm_mutex.
>>>
>>> Maybe it is just some kind of side effect, going to locking into it
>>> anyway.
>>>
>>> Christian.
>>>
>> It's the using, init path take lock in different order than cs path
>
> Well, could you explain to me why the vm code takes cs mutex in the first
> place?
>
> It clearly has it's own mutex and it doesn't looks like that it deals with
> any cs related data anyway.
>
> Christian.

Lock simplification is on my todo. The issue is that vm manager is protected by
cs_mutex The vm.mutex is specific to each vm it doesn't protect the global vm
management. I didn't wanted to introduce a new global vm mutex as vm activity
is mostly trigger on behalf of cs so i dediced to use the cs mutex.

That's why non cs path of vm need to take the cs mutex.

Cheers,
Jerome

[PATCH 3/7] DRM: add sdrm layer for general embedded system support

[Sascha Hauer]

On Fri, Apr 20, 2012 at 03:33:14PM +0200, Daniel Vetter wrote:
> On Fri, Apr 20, 2012 at 03:10:05PM +0200, Sascha Hauer wrote:
> > (BTW each driver in drm has this layer somewhere in it. If I had hidden
> > it in imx specific functions I probably wouldn't have raised any
> > questions, but I don't want to go that way)
> 
> That's _exactly_ what you should be doing. And once you have more than one
> driver that works in a similar way, you can extract the common code as
> helper functions to make life easier.

I already have three drivers working in a similar way from which I
posted two. I could easily throw in some more into the pot. Also the
code is based on the exynos driver, so I think it's suitable for this
aswell.

> 
> For your case it sounds like a new set of modeset helper functions
> tailored for the embedded use-case would be good (as Dave Airlie
> suggested).

One of my problems is that currently drm is based on the assumption that
there is a single device which offers all needed resources and
information to form a drm device. On embedded systems this is simply not
the case, we have our resources all around the SoC. I have physical
devices which are crtcs, encoders or connectors, but drm does not
provide a way to glue them together. You can find this aswell in the
exynos driver if you grep for exynos_drm_subdrv_register. If you follow
this function you'll see that a good bunch of the driver actually
handles the management of these subdevices. Do you have a suggestion
solving the involved code duplication with helper functions?

Also sooner or later it will happen that the same hdmi controller is
used on two otherwise different SoCs. Currently the driver can't be
shared between SoCs because each hdmi driver implements exynos or
nouveau specific callbacks. I guess the answer is to put the common hdmi
driver code into helper functions and to implement a middle layer in
each drm driver wishing to use it.

> Adding yet another middle-layer (like sdrm is) that forces
> drivers to go through it usually ends up in tears. And drm core
> unfortunately still has too much middle-layer heritage: For an awful lot
> of setup and teardown issues it's the core of the problme - because
> drivers can't control when drm sets up and tears down certain things, it's
> done at the wrong time (for certain drivers at least). Same problem when
> the abstraction doesn't quite fit.
> 
> Helper functions leave the driver in full control of what's going on, and
> working around hw-specific madness with ease.
> 
> https://lwn.net/Articles/336262/ is the canonical reference for why a lot
> of kernel people are allergic to anything that looks like a middle-layer.

I have read the article when it was featured on LWN. While I agree to
several things I have my problems with it. Take for example the MMC
core. A MMC driver mainly has to implement two callbacks, .request and
.set_ios. Noone has ever asked to get direct access from the driver to
the underlying block device and eventually pass control to MMC helper
functions. This makes the MMC core a middle layer sitting between the
blockdevice and the driver.  With drm instead it's normal that ioctls
fall straight through to the driver. This leads to such funny things
that the kernel itself cannot control the device to bring a console on
the screen without dedicated help from the driver.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Reworking of GPU reset logic

[Jerome Glisse]

2012/4/21 Christian K?nig :
> On 20.04.2012 01:47, Jerome Glisse wrote:
>>
>> 2012/4/19 Christian K?nig:
>>>
>>> This includes mostly fixes for multi ring lockups and GPU resets, but it
>>> should general improve the behavior of the kernel mode driver in case
>>> something goes badly wrong.
>>>
>>> On the other hand it completely rewrites the IB pool and semaphore
>>> handling, so I think there are still a couple of problems in it.
>>>
>>> The first four patches were already send to the list, but the current set
>>> depends on them so I resend them again.
>>>
>>> Cheers,
>>> Christian.
>>
>> I did a quick review, it looks mostly good, but as it's sensitive code
>> i would like to spend sometime on
>> it. Probably next week. Note that i had some work on this area too, i
>> mostly want to drop all the debugfs
>> related to this and add some new more usefull (basicly something that
>> allow you to read all the data
>> needed to replay a locking up ib). I also was looking into Dave reset
>> thread and your solution of moving
>> reset in ioctl return path sounds good too but i need to convince my
>> self that it encompass all possible
>> case.
>>
>> Cheers,
>> Jerome
>>
> After sleeping a night over it I already reworked the patch for improving
> the SA performance, so please wait at least for v2 before taking a look at
> it :)
>
> Regarding the debugging of lockups I had the following on my "in mind todo"
> list:
> 1. Rework the chip specific lockup detection code a bit more and probably
> clean it up a bit.
> 2. Make the timeout a module parameter, cause compute task sometimes block a
> ring for more than 10 seconds.
> 3. Keep track of the actually RPTR offset a fence is emitted to
> 3. Keep track of all the BOs a IB is touching.
> 4. Now if a lockup happens start with the last successfully signaled fence
> and dump the ring content after that RPTR offset till the first not signaled
> fence.
> 5. Then if this fence references to an IB dump it's content and the BOs it
> is touching.
> 6. Dump everything on the ring after that fence until you reach the RPTR of
> the next fence or the WPTR of the ring.
> 7. If there is a next fence repeat the whole thing at number 5.
>
> If I'm not completely wrong that should give you practically every
> information available, and we probably should put that behind another module
> option, cause we are going to spam syslog pretty much here. Feel free to
> add/modify the ideas on this list.
>
> Christian.

What i have is similar, i am assuming only ib trigger lockup, before each ib
emit to scratch reg ib offset in sa and ib size. For each ib keep bo list. On
lockup allocate big memory to copy the whole ib and all the bo referenced
by the ib (i am using my bof format as i already have userspace tools).

Remove all the debugfs file. Just add a new one that gave you the first faulty
ib. On read of this file kernel free the memory. Kernel should also free the
memory after a while or better would be to enable the lockup copy only if
some kernel radeon option is enabled.

Cheers,
Jerome

VM lockdep warning

[Jerome Glisse]

2012/4/21 Christian K?nig :
> Interesting, I'm pretty sure that I haven't touched the locking order of the
> cs_mutex vs. vm_mutex.
>
> Maybe it is just some kind of side effect, going to locking into it anyway.
>
> Christian.
>

It's the using, init path take lock in different order than cs path

Cheers,
Jerome

[Regression][3.4-rc3][intel-dri] MMIO read or write has been dropped ffffffff

[Maciej Rutecki]

Bad kernel: 3.4-rc3
Last known good: 3.3

Subsystem: dri-intel (guess)

Steps to reproduce:
1. Suspend to ram
2. Resume

After resume laptop works ok, but in dmesg I found:
[  164.098113] [ cut here ]
[  164.098124] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398 
gen6_gt_check_fifodbg.isra.6+0x31/0x43()
[  164.098126] Hardware name: 1141ALG
[  164.098128] MMIO read or write has been dropped 
[  164.098129] Modules linked in: xt_tcpudp xt_limit xt_state iptable_filter 
nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables x_tables bnep rfcomm 
bluetooth uinput fuse loop sha256_generic aes_x86_64 aes_generic cbc dm_crypt 
dm_mod uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev 
usbhid hid media snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi 
mac80211 thinkpad_acpi cfg80211 coretemp nvram snd_hda_intel snd_hda_codec 
snd_hwdep snd_pcm snd_page_alloc snd_seq ehci_hcd sdhci_pci crc32c_intel 
iTCO_wdt iTCO_vendor_support ghash_clmulni_intel snd_seq_device cryptd 
snd_timer microcode snd acpi_cpufreq mperf usbcore psmouse sdhci r8169 
mmc_core mii ac rfkill i2c_i801 soundcore mei(C) serio_raw pcspkr thermal 
battery power_supply wmi usb_common evdev processor
[  164.098188] Pid: 4684, comm: kworker/u:9 Tainted: G C   3.4.0-rc3 
#1
[  164.098189] Call Trace:
[  164.098197]  [] warn_slowpath_common+0x7e/0x96
[  164.098200]  [] warn_slowpath_fmt+0x41/0x43
[  164.098203]  [] gen6_gt_check_fifodbg.isra.6+0x31/0x43
[  164.098207]  [] __gen6_gt_force_wake_put+0x19/0x1b
[  164.098210]  [] i915_read32+0x66/0x9d
[  164.098213]  [] i915_update_gfx_val+0x61/0xb9
[  164.098218]  [] intel_idle_update+0x47/0x18d
[  164.098222]  [] process_one_work+0x1b5/0x340
[  164.098225]  [] ? process_one_work+0x118/0x340
[  164.098228]  [] ? intel_disable_plane+0x60/0x60
[  164.098231]  [] worker_thread+0xce/0x152
[  164.098234]  [] ? manage_workers.isra.22+0x16a/0x16a
[  164.098237]  [] kthread+0xa1/0xa9
[  164.098242]  [] ? trace_hardirqs_on+0xd/0xf
[  164.098246]  [] kernel_thread_helper+0x4/0x10
[  164.098250]  [] ? retint_restore_args+0x13/0x13
[  164.098253]  [] ? __init_kthread_worker+0x55/0x55
[  164.098256]  [] ? gs_change+0x13/0x13
[  164.098257] ---[ end trace 97bd0b679d161c3e ]---
[  164.098827] [ cut here ]
[  164.098830] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398 
gen6_gt_check_fifodbg.isra.6+0x31/0x43()
[  164.098832] Hardware name: 1141ALG
[  164.098833] MMIO read or write has been dropped 
[  164.098834] Modules linked in: xt_tcpudp xt_limit xt_state iptable_filter 
nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables x_tables bnep rfcomm 
bluetooth uinput fuse loop sha256_generic aes_x86_64 aes_generic cbc dm_crypt 
dm_mod uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev 
usbhid hid media snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi 
mac80211 thinkpad_acpi cfg80211 coretemp nvram snd_hda_intel snd_hda_codec 
snd_hwdep snd_pcm snd_page_alloc snd_seq ehci_hcd sdhci_pci crc32c_intel 
iTCO_wdt iTCO_vendor_support ghash_clmulni_intel snd_seq_device cryptd 
snd_timer microcode snd acpi_cpufreq mperf usbcore psmouse sdhci r8169 
mmc_core mii ac rfkill i2c_i801 soundcore mei(C) serio_raw pcspkr thermal 
battery power_supply wmi usb_common evdev processor
[  164.098877] Pid: 4684, comm: kworker/u:9 Tainted: GWC   3.4.0-rc3 
#1
[  164.098878] Call Trace:
[  164.098881]  [] warn_slowpath_common+0x7e/0x96
[  164.098884]  [] warn_slowpath_fmt+0x41/0x43
[  164.09]  [] gen6_gt_check_fifodbg.isra.6+0x31/0x43
[  164.098891]  [] __gen6_gt_force_wake_put+0x19/0x1b
[  164.098894]  [] i915_read32+0x66/0x9d
[  164.098896]  [] intel_idle_update+0x9f/0x18d
[  164.098899]  [] process_one_work+0x1b5/0x340
[  164.098902]  [] ? process_one_work+0x118/0x340
[  164.098904]  [] ? intel_disable_plane+0x60/0x60
[  164.098907]  [] worker_thread+0xce/0x152
[  164.098910]  [] ? manage_workers.isra.22+0x16a/0x16a
[  164.098913]  [] kthread+0xa1/0xa9
[  164.098916]  [] ? trace_hardirqs_on+0xd/0xf
[  164.098918]  [] kernel_thread_helper+0x4/0x10
[  164.098921]  [] ? retint_restore_args+0x13/0x13
[  164.098925]  [] ? __init_kthread_worker+0x55/0x55
[  164.098927]  [] ? gs_change+0x13/0x13
[  164.098928] ---[ end trace 97bd0b679d161c3f ]---

I found similar report in:
https://bugzilla.redhat.com/show_bug.cgi?id=809773

Dmesg, config and lspci:
http://mrutecki.pl/download/kernel/3.4-rc3/dri_intel/

Regards
-- 
Maciej Rutecki
http://www.mrutecki.pl

[Bug 43138] Radeon HD5450 fails to load cedar firmware ?

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

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





--- Comment #5 from bugtraq at hobbit.in-berlin.de  2012-04-21 06:51:09 ---
considering the age of that code I share your suspicions, but why then does a
stock debian kernel & initrd show same behavior as my self-compiled (newer)
one?

-- 
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 49030] New: Possible recursive locking detected in r600g

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

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

 Bug #: 49030
   Summary: Possible recursive locking detected in r600g
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: minor
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: alexandre.f.demers at gmail.com


Here is what I see under dmesg:

=
[ INFO: possible recursive locking detected ]
3.4.0-rc3+ #120 Tainted: G C  
-
gnome-shell/1120 is trying to acquire lock:
 (>mutex){+.+...}, at: [] radeon_vm_unbind+0x24/0x40
[radeon]

but task is already holding lock:
 (>mutex){+.+...}, at: [] radeon_cs_ioctl+0x434/0x598
[radeon]

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

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

 *** DEADLOCK ***

 May be due to missing lock nesting notation

2 locks held by gnome-shell/1120:
 #0:  (>mutex){+.+.+.}, at: []
radeon_cs_ioctl+0x36/0x598 [radeon]
 #1:  (>mutex){+.+...}, at: []
radeon_cs_ioctl+0x434/0x598 [radeon]

stack backtrace:
Pid: 1120, comm: gnome-shell Tainted: G C   3.4.0-rc3+ #120
Call Trace:
 [] __lock_acquire+0xbf6/0xd11
 [] ? __lock_acquire+0x4c0/0xd11
 [] lock_acquire+0x92/0x104
 [] ? radeon_vm_unbind+0x24/0x40 [radeon]
 [] ? __lock_acquire+0x4c0/0xd11
 [] __mutex_lock_common+0x48/0x34e
 [] ? radeon_vm_unbind+0x24/0x40 [radeon]
 [] ? radeon_vm_unbind+0x24/0x40 [radeon]
 [] ? trace_hardirqs_on_caller+0x123/0x17f
 [] mutex_lock_nested+0x2f/0x36
 [] ? radeon_cs_ioctl+0x434/0x598 [radeon]
 [] radeon_vm_unbind+0x24/0x40 [radeon]
 [] radeon_vm_bind+0xb9/0x1c4 [radeon]
 [] radeon_cs_ioctl+0x43f/0x598 [radeon]
 [] drm_ioctl+0x2d6/0x3c0 [drm]
 [] ? rcu_read_unlock+0x1c/0x1e
 [] ? radeon_cs_finish_pages+0x91/0x91 [radeon]
 [] ? avc_has_perm_flags+0x6b/0x7f
 [] vfs_ioctl+0x24/0x2f
 [] do_vfs_ioctl+0x412/0x455
 [] sys_ioctl+0x56/0x7a
 [] system_call_fastpath+0x1a/0x1f


It seems to be only a warning. However, if possible, it should be silenced if
there is no reason to have it. I know I reported something similar a couple of
months ago and it was fixed by moving some code around.

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

[gma500] Fix screen blackouts

[Guillaume Clément]

Hello,

Since linux-3.3 I have been experiencing screen "blackouts" with the 
gma500_gfx driver. My laptop display would turn off and on again frequently.

After activating the drm.debug=255 kernel option, the logs showed this during 
the blackout : 

[  166.940676] [drm:psb_intel_sdvo_read_response], SDVOB: R: (Target not 
specified)... failed


It appears that, for some reason, psb_intel_sdvo_read_reponse fails with 
status "Target not specified" during the polling for outputs. The driver then 
assumes the DPMS output is to be turned off and does so. Then the DPMS display 
is turned on again at the next poll.

The staging driver (which worked with my card) called psb_intel_sdvo_read_byte 
until the status is successful. Now the driver fails if one of the returned 
status is neither pending nor success.

It looks my card can return "target not specified" instead of pending. By 
considering "target not specified" like pending and waiting for another byte, 
everything works fine again.




To sum things up : 

Some Poulsbo cards seem to incorrectly report 
SDVO_CMD_STATUS_TARGET_NOT_SPECIFIED instead of SDVO_CMD_STATUS_PENDING which 
causes the display to be turned off.

Signed-by: Guillaume Clement 
Acked-by: Alan Cox 
---

diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo.c 
b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
index 36330ca..b3858bc 100644
--- a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
+++ b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
@@ -498,7 +498,9 @@ static bool psb_intel_sdvo_read_response(struct 
psb_intel_sdvo *psb_intel_sdvo,
  ))
goto log_fail;

-   while (status == SDVO_CMD_STATUS_PENDING && retry--) {
+   while ((status == SDVO_CMD_STATUS_PENDING
+   || status == SDVO_CMD_STATUS_TARGET_NOT_SPECIFIED)
+   && retry--) {
udelay(15);
if (!psb_intel_sdvo_read_byte(psb_intel_sdvo,
  SDVO_I2C_CMD_STATUS,

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

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

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

--- Comment #69 from Gilles Dartiguelongue  
2012-04-20 16:41:09 PDT ---
I pushed the current state of the code here:
https://github.com/EvaSDK/linux/commit/d590f8631a2421ba6bcef7041888b3aa382f87c7

I commented out dpms code for testing, but given the power of the machine it
was quite long to get that out already so I'll fix that later.

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

[Bug 43138] Radeon HD5450 fails to load cedar firmware ?

[bugzilla-daemon]

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





--- Comment #5 from bugt...@hobbit.in-berlin.de  2012-04-21 06:51:09 ---
considering the age of that code I share your suspicions, but why then does a
stock debian kernel  initrd show same behavior as my self-compiled (newer)
one?

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

Re: [PATCH 3/7] DRM: add sdrm layer for general embedded system support

[Sascha Hauer]

On Fri, Apr 20, 2012 at 03:33:14PM +0200, Daniel Vetter wrote:
 On Fri, Apr 20, 2012 at 03:10:05PM +0200, Sascha Hauer wrote:
  (BTW each driver in drm has this layer somewhere in it. If I had hidden
  it in imx specific functions I probably wouldn't have raised any
  questions, but I don't want to go that way)
 
 That's _exactly_ what you should be doing. And once you have more than one
 driver that works in a similar way, you can extract the common code as
 helper functions to make life easier.

I already have three drivers working in a similar way from which I
posted two. I could easily throw in some more into the pot. Also the
code is based on the exynos driver, so I think it's suitable for this
aswell.

 
 For your case it sounds like a new set of modeset helper functions
 tailored for the embedded use-case would be good (as Dave Airlie
 suggested).

One of my problems is that currently drm is based on the assumption that
there is a single device which offers all needed resources and
information to form a drm device. On embedded systems this is simply not
the case, we have our resources all around the SoC. I have physical
devices which are crtcs, encoders or connectors, but drm does not
provide a way to glue them together. You can find this aswell in the
exynos driver if you grep for exynos_drm_subdrv_register. If you follow
this function you'll see that a good bunch of the driver actually
handles the management of these subdevices. Do you have a suggestion
solving the involved code duplication with helper functions?

Also sooner or later it will happen that the same hdmi controller is
used on two otherwise different SoCs. Currently the driver can't be
shared between SoCs because each hdmi driver implements exynos or
nouveau specific callbacks. I guess the answer is to put the common hdmi
driver code into helper functions and to implement a middle layer in
each drm driver wishing to use it.

 Adding yet another middle-layer (like sdrm is) that forces
 drivers to go through it usually ends up in tears. And drm core
 unfortunately still has too much middle-layer heritage: For an awful lot
 of setup and teardown issues it's the core of the problme - because
 drivers can't control when drm sets up and tears down certain things, it's
 done at the wrong time (for certain drivers at least). Same problem when
 the abstraction doesn't quite fit.
 
 Helper functions leave the driver in full control of what's going on, and
 working around hw-specific madness with ease.
 
 https://lwn.net/Articles/336262/ is the canonical reference for why a lot
 of kernel people are allergic to anything that looks like a middle-layer.

I have read the article when it was featured on LWN. While I agree to
several things I have my problems with it. Take for example the MMC
core. A MMC driver mainly has to implement two callbacks, .request and
.set_ios. Noone has ever asked to get direct access from the driver to
the underlying block device and eventually pass control to MMC helper
functions. This makes the MMC core a middle layer sitting between the
blockdevice and the driver.  With drm instead it's normal that ioctls
fall straight through to the driver. This leads to such funny things
that the kernel itself cannot control the device to bring a console on
the screen without dedicated help from the driver.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Reworking of GPU reset logic

[Christian König]

On 20.04.2012 01:47, Jerome Glisse wrote:

2012/4/19 Christian Königdeathsim...@vodafone.de:

This includes mostly fixes for multi ring lockups and GPU resets, but it should 
general improve the behavior of the kernel mode driver in case something goes 
badly wrong.

On the other hand it completely rewrites the IB pool and semaphore handling, so 
I think there are still a couple of problems in it.

The first four patches were already send to the list, but the current set 
depends on them so I resend them again.

Cheers,
Christian.

I did a quick review, it looks mostly good, but as it's sensitive code
i would like to spend sometime on
it. Probably next week. Note that i had some work on this area too, i
mostly want to drop all the debugfs
related to this and add some new more usefull (basicly something that
allow you to read all the data
needed to replay a locking up ib). I also was looking into Dave reset
thread and your solution of moving
reset in ioctl return path sounds good too but i need to convince my
self that it encompass all possible
case.

Cheers,
Jerome

After sleeping a night over it I already reworked the patch for 
improving the SA performance, so please wait at least for v2 before 
taking a look at it :)


Regarding the debugging of lockups I had the following on my in mind 
todo list:
1. Rework the chip specific lockup detection code a bit more and 
probably clean it up a bit.
2. Make the timeout a module parameter, cause compute task sometimes 
block a ring for more than 10 seconds.

3. Keep track of the actually RPTR offset a fence is emitted to
3. Keep track of all the BOs a IB is touching.
4. Now if a lockup happens start with the last successfully signaled 
fence and dump the ring content after that RPTR offset till the first 
not signaled fence.
5. Then if this fence references to an IB dump it's content and the BOs 
it is touching.
6. Dump everything on the ring after that fence until you reach the RPTR 
of the next fence or the WPTR of the ring.

7. If there is a next fence repeat the whole thing at number 5.

If I'm not completely wrong that should give you practically every 
information available, and we probably should put that behind another 
module option, cause we are going to spam syslog pretty much here. Feel 
free to add/modify the ideas on this list.


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

Re: [RFC 0/4] Add NVIDIA Tegra DRM support

[Jon Mayo]

On 04/19/2012 11:05 PM, Lucas Stach wrote:

Am Freitag, den 20.04.2012, 07:02 +0200 schrieb Thierry Reding:

*cut*


Yes, I think we should go the route that Jerome Glisse pointed out: get
in a basic KMS driver first and hide any accel ioctl under a staging
config option.


Everyone seems happy with that, I have no objections.

*cut*


I'm really interested how this turns out in the end. I hope we can get a
somewhat stable cooperation between NVIDIA and the community, like AMD
has established at the moment.


Well, we always strive to be better than AMD ;-)
But seriously, I don't think GPU technology would be where it is today 
if NVIDIA and AMD didn't compete aggressively.


But our mobile division is more like TI, Qualcomm, Freescale and other 
SoC vendors. Upstreaming changes for arch/arm has so far been a 
different challenge than only updating drivers/gpu for x86. Mostly 
because there are so many aspects to SoCs compared to a driver for a 
graphics card or PC chipset. And it doesn't help that arch/arm is a real 
mess of wildly different SoCs, and it lacks the stability and maturity 
of the x86 code base. The state of ARM is every vendor's fault, every 
chip generation can be a complete resign of one or more subsystems. x86 
tends to be layers of extensions and enhancements from 1-3 vendors.


But even if Mobile doesn't consider AMD or Intel to be among the 
competition, we certainly watch and listen to good open source 
contributors and try to learn from their successes and mistakes. (and 
our own mistakes, we're not perfect!)


What I'm trying to say is that Tegra's business needs are different, so 
you should not be surprised to see different behavior from us. There are 
a lot of difficult issues with open sourcing the work done by my desktop 
colleagues. But those barriers don't apply to Tegra. Different product, 
different market, different rules.





(My vote is NVIDIA starts using this DRM in-house and builds new
extensions on top of it, sharing patches on LKML when the hardware is
released)


That sounds like a good plan. Ideally you should even share the patches as
soon as they're ready. That'll give viewers some head start and you can fix
the code even before the hardware is released.


One thing I would like to have is upstream first. We have seen much
Tegra development in both the nv-linux and chromium trees, but those
things are going upstream extremely slowly. I can understand that this
strategy was beneficial for a fast bring up of the new Tegra hardware,
but the DRM driver shouldn't be time critical and so everything should
be done to meet upstream quality from the start.

-- Lucas




We have a team of interested engineers assigned to just that problem.
Fractured trees are not efficient for us internally either. We want 
upstream to be our common repository for most changes. And internally we 
have been stricter about conforming to Linux kernel coding conventions 
in attempt to give ourselves less work when we get to upstreaming a 
change. I'll be happy when I can tell my customers they can just grab 
the latest Tegra updates from git.kernel.org


Hopefully our efforts will begin to convince you.

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

[gma500] Fix screen blackouts

[Guillaume Clément]

Hello,

Since linux-3.3 I have been experiencing screen blackouts with the 
gma500_gfx driver. My laptop display would turn off and on again frequently.

After activating the drm.debug=255 kernel option, the logs showed this during 
the blackout : 

[  166.940676] [drm:psb_intel_sdvo_read_response], SDVOB: R: (Target not 
specified)... failed


It appears that, for some reason, psb_intel_sdvo_read_reponse fails with 
status Target not specified during the polling for outputs. The driver then 
assumes the DPMS output is to be turned off and does so. Then the DPMS display 
is turned on again at the next poll.

The staging driver (which worked with my card) called psb_intel_sdvo_read_byte 
until the status is successful. Now the driver fails if one of the returned 
status is neither pending nor success.

It looks my card can return target not specified instead of pending. By 
considering target not specified like pending and waiting for another byte, 
everything works fine again.




To sum things up : 

Some Poulsbo cards seem to incorrectly report 
SDVO_CMD_STATUS_TARGET_NOT_SPECIFIED instead of SDVO_CMD_STATUS_PENDING which 
causes the display to be turned off.

Signed-by: Guillaume Clement gclem...@baobob.org
Acked-by: Alan Cox a...@linux.intel.com
---

diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo.c 
b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
index 36330ca..b3858bc 100644
--- a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
+++ b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
@@ -498,7 +498,9 @@ static bool psb_intel_sdvo_read_response(struct 
psb_intel_sdvo *psb_intel_sdvo,
  status))
goto log_fail;
 
-   while (status == SDVO_CMD_STATUS_PENDING  retry--) {
+   while ((status == SDVO_CMD_STATUS_PENDING
+   || status == SDVO_CMD_STATUS_TARGET_NOT_SPECIFIED)
+retry--) {
udelay(15);
if (!psb_intel_sdvo_read_byte(psb_intel_sdvo,
  SDVO_I2C_CMD_STATUS,



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

VM lockdep warning

[Dave Airlie]

running 3.4.0-rc3 + Christian's reset patch series.

The locks are definitely taken in different orders between vm_bo_add
and cs ioctl.

Dave.

==
[ INFO: possible circular locking dependency detected ]
3.4.0-rc3+ #33 Not tainted
---
shader_runner/3090 is trying to acquire lock:
 (vm-mutex){+.+...}, at: [a00c513f]
radeon_cs_ioctl+0x438/0x5c1 [radeon]

but task is already holding lock:
 (rdev-cs_mutex){+.+.+.}, at: [a00c4d3a]
radeon_cs_ioctl+0x33/0x5c1 [radeon]

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

- #1 (rdev-cs_mutex){+.+.+.}:
   [810757f5] lock_acquire+0xf0/0x116
   [81427881] mutex_lock_nested+0x6a/0x2bb
   [a00b5f4d] radeon_vm_bo_add+0x118/0x1f5 [radeon]
   [a00b6479] radeon_vm_init+0x6b/0x70 [radeon]
   [a00a3bfc] radeon_driver_open_kms+0x68/0x9a [radeon]
   [a0019698] drm_open+0x201/0x587 [drm]
   [a0019b0a] drm_stub_open+0xec/0x14a [drm]
   [8110f788] chrdev_open+0x11c/0x145
   [8110a23a] __dentry_open+0x17e/0x29b
   [8110b138] nameidata_to_filp+0x5b/0x62
   [811188d0] do_last+0x75d/0x771
   [81118ab3] path_openat+0xcb/0x380
   [81118e51] do_filp_open+0x33/0x81
   [8110b23f] do_sys_open+0x100/0x192
   [8110b2ed] sys_open+0x1c/0x1e
   [81430722] system_call_fastpath+0x16/0x1b

- #0 (vm-mutex){+.+...}:
   [81074c99] __lock_acquire+0xfcd/0x1664
   [810757f5] lock_acquire+0xf0/0x116
   [81427881] mutex_lock_nested+0x6a/0x2bb
   [a00c513f] radeon_cs_ioctl+0x438/0x5c1 [radeon]
   [a00187a9] drm_ioctl+0x2d8/0x3a4 [drm]
   [8111afd6] do_vfs_ioctl+0x469/0x4aa
   [8111b068] sys_ioctl+0x51/0x75
   [81430722] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(rdev-cs_mutex);
   lock(vm-mutex);
   lock(rdev-cs_mutex);
  lock(vm-mutex);

 *** DEADLOCK ***

1 lock held by shader_runner/3090:
 #0:  (rdev-cs_mutex){+.+.+.}, at: [a00c4d3a]
radeon_cs_ioctl+0x33/0x5c1 [radeon]

stack backtrace:
Pid: 3090, comm: shader_runner Not tainted 3.4.0-rc3+ #33
Call Trace:
 [81420ac7] print_circular_bug+0x28a/0x29b
 [81074c99] __lock_acquire+0xfcd/0x1664
 [810757f5] lock_acquire+0xf0/0x116
 [a00c513f] ? radeon_cs_ioctl+0x438/0x5c1 [radeon]
 [810db991] ? might_fault+0x57/0xa7
 [81427881] mutex_lock_nested+0x6a/0x2bb
 [a00c513f] ? radeon_cs_ioctl+0x438/0x5c1 [radeon]
 [a00f4196] ? evergreen_ib_parse+0x1b2/0x204 [radeon]
 [a00c513f] radeon_cs_ioctl+0x438/0x5c1 [radeon]
 [a00187a9] drm_ioctl+0x2d8/0x3a4 [drm]
 [a00c4d07] ? radeon_cs_finish_pages+0xa3/0xa3 [radeon]
 [811ee4c4] ? avc_has_perm_flags+0xd7/0x160
 [811ee413] ? avc_has_perm_flags+0x26/0x160
 [8104bf6a] ? up_read+0x1b/0x32
 [8111afd6] do_vfs_ioctl+0x469/0x4aa
 [8111b068] sys_ioctl+0x51/0x75
 [8104f955] ? __wake_up+0x1d/0x48
 [81430722] system_call_fastpath+0x16/0x1b
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915: kernel errors at resume

[Paul Bolle]

On Thu, 2012-04-19 at 11:04 +0200, Paul Bolle wrote:
 6[14673.824599] [drm] capturing error event; look for more information in 
 /debug/dri/0/i915_error_state

I triggered this issue once again in the session I run currently:
$ cat /sys/kernel/debug/dri/0/i915_error_state | wc -c
689681

What part of that almost 700K file could be of interest?


Paul Bolle

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

Re: VM lockdep warning

[Christian König]

Interesting, I'm pretty sure that I haven't touched the locking order of 
the cs_mutex vs. vm_mutex.


Maybe it is just some kind of side effect, going to locking into it anyway.

Christian.

On 21.04.2012 13:39, Dave Airlie wrote:

running 3.4.0-rc3 + Christian's reset patch series.

The locks are definitely taken in different orders between vm_bo_add
and cs ioctl.

Dave.

==
[ INFO: possible circular locking dependency detected ]
3.4.0-rc3+ #33 Not tainted
---
shader_runner/3090 is trying to acquire lock:
  (vm-mutex){+.+...}, at: [a00c513f]
radeon_cs_ioctl+0x438/0x5c1 [radeon]

but task is already holding lock:
  (rdev-cs_mutex){+.+.+.}, at: [a00c4d3a]
radeon_cs_ioctl+0x33/0x5c1 [radeon]

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-  #1 (rdev-cs_mutex){+.+.+.}:
[810757f5] lock_acquire+0xf0/0x116
[81427881] mutex_lock_nested+0x6a/0x2bb
[a00b5f4d] radeon_vm_bo_add+0x118/0x1f5 [radeon]
[a00b6479] radeon_vm_init+0x6b/0x70 [radeon]
[a00a3bfc] radeon_driver_open_kms+0x68/0x9a [radeon]
[a0019698] drm_open+0x201/0x587 [drm]
[a0019b0a] drm_stub_open+0xec/0x14a [drm]
[8110f788] chrdev_open+0x11c/0x145
[8110a23a] __dentry_open+0x17e/0x29b
[8110b138] nameidata_to_filp+0x5b/0x62
[811188d0] do_last+0x75d/0x771
[81118ab3] path_openat+0xcb/0x380
[81118e51] do_filp_open+0x33/0x81
[8110b23f] do_sys_open+0x100/0x192
[8110b2ed] sys_open+0x1c/0x1e
[81430722] system_call_fastpath+0x16/0x1b

-  #0 (vm-mutex){+.+...}:
[81074c99] __lock_acquire+0xfcd/0x1664
[810757f5] lock_acquire+0xf0/0x116
[81427881] mutex_lock_nested+0x6a/0x2bb
[a00c513f] radeon_cs_ioctl+0x438/0x5c1 [radeon]
[a00187a9] drm_ioctl+0x2d8/0x3a4 [drm]
[8111afd6] do_vfs_ioctl+0x469/0x4aa
[8111b068] sys_ioctl+0x51/0x75
[81430722] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

  Possible unsafe locking scenario:

CPU0CPU1

   lock(rdev-cs_mutex);
lock(vm-mutex);
lock(rdev-cs_mutex);
   lock(vm-mutex);

  *** DEADLOCK ***

1 lock held by shader_runner/3090:
  #0:  (rdev-cs_mutex){+.+.+.}, at: [a00c4d3a]
radeon_cs_ioctl+0x33/0x5c1 [radeon]

stack backtrace:
Pid: 3090, comm: shader_runner Not tainted 3.4.0-rc3+ #33
Call Trace:
  [81420ac7] print_circular_bug+0x28a/0x29b
  [81074c99] __lock_acquire+0xfcd/0x1664
  [810757f5] lock_acquire+0xf0/0x116
  [a00c513f] ? radeon_cs_ioctl+0x438/0x5c1 [radeon]
  [810db991] ? might_fault+0x57/0xa7
  [81427881] mutex_lock_nested+0x6a/0x2bb
  [a00c513f] ? radeon_cs_ioctl+0x438/0x5c1 [radeon]
  [a00f4196] ? evergreen_ib_parse+0x1b2/0x204 [radeon]
  [a00c513f] radeon_cs_ioctl+0x438/0x5c1 [radeon]
  [a00187a9] drm_ioctl+0x2d8/0x3a4 [drm]
  [a00c4d07] ? radeon_cs_finish_pages+0xa3/0xa3 [radeon]
  [811ee4c4] ? avc_has_perm_flags+0xd7/0x160
  [811ee413] ? avc_has_perm_flags+0x26/0x160
  [8104bf6a] ? up_read+0x1b/0x32
  [8111afd6] do_vfs_ioctl+0x469/0x4aa
  [8111b068] sys_ioctl+0x51/0x75
  [8104f955] ? __wake_up+0x1d/0x48
  [81430722] system_call_fastpath+0x16/0x1b



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

Re: i915: kernel errors at resume

[Daniel Vetter]

On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote:
 On Thu, 2012-04-19 at 11:04 +0200, Paul Bolle wrote:
  6[14673.824599] [drm] capturing error event; look for more information in 
  /debug/dri/0/i915_error_state
 
 I triggered this issue once again in the session I run currently:
 $ cat /sys/kernel/debug/dri/0/i915_error_state | wc -c
 689681
 
 What part of that almost 700K file could be of interest?

All of it. Please file a bug report with the error state attach (the
entire thing), complete dmesg showing when the problem happens and a short
description of the issue at bugs.freedesktop.org against DRI, component
DRM/Intel.

Thanks, daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915: kernel errors at resume

[Paul Bolle]

On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote:
 On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote:
  What part of that almost 700K file could be of interest?
 
 All of it. Please file a bug report with the error state attach (the
 entire thing), complete dmesg showing when the problem happens and a short
 description of the issue at bugs.freedesktop.org against DRI, component
 DRM/Intel.

OK, I'll do that then. Would you know whether bugs.freedesktop.org
requires me to compress files of that size?


Paul Bollw

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

Re: [Regression][3.4-rc3][intel-dri] MMIO read or write has been dropped ffffffff

[Daniel Vetter]

On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote:
 Bad kernel: 3.4-rc3
 Last known good: 3.3
 
 Subsystem: dri-intel (guess)
 
 Steps to reproduce:
 1. Suspend to ram
 2. Resume
 
 After resume laptop works ok, but in dmesg I found:
 [  164.098113] [ cut here ]
 [  164.098124] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398 
 gen6_gt_check_fifodbg.isra.6+0x31/0x43()
 [  164.098126] Hardware name: 1141ALG
 [  164.098128] MMIO read or write has been dropped 
 [  164.098129] Modules linked in: xt_tcpudp xt_limit xt_state iptable_filter 
 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables x_tables bnep rfcomm 
 bluetooth uinput fuse loop sha256_generic aes_x86_64 aes_generic cbc dm_crypt 
 dm_mod uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev 
 usbhid hid media snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi 
 mac80211 thinkpad_acpi cfg80211 coretemp nvram snd_hda_intel snd_hda_codec 
 snd_hwdep snd_pcm snd_page_alloc snd_seq ehci_hcd sdhci_pci crc32c_intel 
 iTCO_wdt iTCO_vendor_support ghash_clmulni_intel snd_seq_device cryptd 
 snd_timer microcode snd acpi_cpufreq mperf usbcore psmouse sdhci r8169 
 mmc_core mii ac rfkill i2c_i801 soundcore mei(C) serio_raw pcspkr thermal 
 battery power_supply wmi usb_common evdev processor
 [  164.098188] Pid: 4684, comm: kworker/u:9 Tainted: G C   3.4.0-rc3 
 #1
 [  164.098189] Call Trace:
 [  164.098197]  [8103aa3c] warn_slowpath_common+0x7e/0x96
 [  164.098200]  [8103aae8] warn_slowpath_fmt+0x41/0x43
 [  164.098203]  [812cbec7] gen6_gt_check_fifodbg.isra.6+0x31/0x43
 [  164.098207]  [812cc13b] __gen6_gt_force_wake_put+0x19/0x1b
 [  164.098210]  [812cc3cf] i915_read32+0x66/0x9d
 [  164.098213]  [812ce4fa] i915_update_gfx_val+0x61/0xb9
 [  164.098218]  [812e989f] intel_idle_update+0x47/0x18d
 [  164.098222]  [810520d7] process_one_work+0x1b5/0x340
 [  164.098225]  [8105203a] ? process_one_work+0x118/0x340
 [  164.098228]  [812e9858] ? intel_disable_plane+0x60/0x60
 [  164.098231]  [81052c63] worker_thread+0xce/0x152
 [  164.098234]  [81052b95] ? manage_workers.isra.22+0x16a/0x16a
 [  164.098237]  [810567c6] kthread+0xa1/0xa9
 [  164.098242]  [81080ea1] ? trace_hardirqs_on+0xd/0xf
 [  164.098246]  [8145d374] kernel_thread_helper+0x4/0x10
 [  164.098250]  [81456970] ? retint_restore_args+0x13/0x13
 [  164.098253]  [81056725] ? __init_kthread_worker+0x55/0x55
 [  164.098256]  [8145d370] ? gs_change+0x13/0x13
 [  164.098257] ---[ end trace 97bd0b679d161c3e ]---
 [  164.098827] [ cut here ]
 [  164.098830] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398 
 gen6_gt_check_fifodbg.isra.6+0x31/0x43()
 [  164.098832] Hardware name: 1141ALG
 [  164.098833] MMIO read or write has been dropped 
 [  164.098834] Modules linked in: xt_tcpudp xt_limit xt_state iptable_filter 
 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables x_tables bnep rfcomm 
 bluetooth uinput fuse loop sha256_generic aes_x86_64 aes_generic cbc dm_crypt 
 dm_mod uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev 
 usbhid hid media snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi 
 mac80211 thinkpad_acpi cfg80211 coretemp nvram snd_hda_intel snd_hda_codec 
 snd_hwdep snd_pcm snd_page_alloc snd_seq ehci_hcd sdhci_pci crc32c_intel 
 iTCO_wdt iTCO_vendor_support ghash_clmulni_intel snd_seq_device cryptd 
 snd_timer microcode snd acpi_cpufreq mperf usbcore psmouse sdhci r8169 
 mmc_core mii ac rfkill i2c_i801 soundcore mei(C) serio_raw pcspkr thermal 
 battery power_supply wmi usb_common evdev processor
 [  164.098877] Pid: 4684, comm: kworker/u:9 Tainted: GWC   3.4.0-rc3 
 #1
 [  164.098878] Call Trace:
 [  164.098881]  [8103aa3c] warn_slowpath_common+0x7e/0x96
 [  164.098884]  [8103aae8] warn_slowpath_fmt+0x41/0x43
 [  164.09]  [812cbec7] gen6_gt_check_fifodbg.isra.6+0x31/0x43
 [  164.098891]  [812cc13b] __gen6_gt_force_wake_put+0x19/0x1b
 [  164.098894]  [812cc3cf] i915_read32+0x66/0x9d
 [  164.098896]  [812e98f7] intel_idle_update+0x9f/0x18d
 [  164.098899]  [810520d7] process_one_work+0x1b5/0x340
 [  164.098902]  [8105203a] ? process_one_work+0x118/0x340
 [  164.098904]  [812e9858] ? intel_disable_plane+0x60/0x60
 [  164.098907]  [81052c63] worker_thread+0xce/0x152
 [  164.098910]  [81052b95] ? manage_workers.isra.22+0x16a/0x16a
 [  164.098913]  [810567c6] kthread+0xa1/0xa9
 [  164.098916]  [81080ea1] ? trace_hardirqs_on+0xd/0xf
 [  164.098918]  [8145d374] kernel_thread_helper+0x4/0x10
 [  164.098921]  [81456970] ? retint_restore_args+0x13/0x13
 [  164.098925]  [81056725] ? __init_kthread_worker+0x55/0x55
 [  164.098927]  [8145d370] ? gs_change+0x13/0x13
 [  164.098928] ---[ end trace 

Re: i915: kernel errors at resume

[Daniel Vetter]

On Sat, Apr 21, 2012 at 02:58:39PM +0200, Paul Bolle wrote:
 On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote:
  On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote:
   What part of that almost 700K file could be of interest?
  
  All of it. Please file a bug report with the error state attach (the
  entire thing), complete dmesg showing when the problem happens and a short
  description of the issue at bugs.freedesktop.org against DRI, component
  DRM/Intel.
 
 OK, I'll do that then. Would you know whether bugs.freedesktop.org
 requires me to compress files of that size?

Please don't if possible, it's a hassle to first unzip it. And usually it
works without issues.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
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 #70 from Daniel Vetter dan...@ffwll.ch 2012-04-21 06:08:48 PDT ---
Created attachment 60416
  -- https://bugs.freedesktop.org/attachment.cgi?id=60416
drm driver reload script

Looks like you've made a start alright. As I've said, I've you're getting stuck
somewhere, don't be afreaid to pop up on #intel-gfx on irc. To speed up the
development you can also only reload the drm/i915.ko kernel module. It's a bit
tricky, so I use the attached script (you still need to compile i915.ko and
copy it into the right place, of course).

You also need to enable CONFIG_VT_HW_CONSOLE_BINDING, otherwise the fbcon
unbinding won't work and you can't unload i915.ko. Also, a 2nd machine with ssh
access is very nice in case the module-reloading failed - otherwise you'll just
be starring at a blank screen.

-- 
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][3.4-rc3][intel-dri] MMIO read or write has been dropped ffffffff

[Daniel Vetter]

On Sat, Apr 21, 2012 at 03:03:07PM +0200, Daniel Vetter wrote:
 On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote:
  Bad kernel: 3.4-rc3
  Last known good: 3.3
  
  Subsystem: dri-intel (guess)
  
  Steps to reproduce:
  1. Suspend to ram
  2. Resume
  
  After resume laptop works ok, but in dmesg I found:
  [  164.098113] [ cut here ]
  [  164.098124] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398 
  gen6_gt_check_fifodbg.isra.6+0x31/0x43()
  [  164.098126] Hardware name: 1141ALG
  [  164.098128] MMIO read or write has been dropped 
  [  164.098129] Modules linked in: xt_tcpudp xt_limit xt_state 
  iptable_filter 
  nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables x_tables bnep 
  rfcomm 
  bluetooth uinput fuse loop sha256_generic aes_x86_64 aes_generic cbc 
  dm_crypt 
  dm_mod uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev 
  usbhid hid media snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi 
  mac80211 thinkpad_acpi cfg80211 coretemp nvram snd_hda_intel snd_hda_codec 
  snd_hwdep snd_pcm snd_page_alloc snd_seq ehci_hcd sdhci_pci crc32c_intel 
  iTCO_wdt iTCO_vendor_support ghash_clmulni_intel snd_seq_device cryptd 
  snd_timer microcode snd acpi_cpufreq mperf usbcore psmouse sdhci r8169 
  mmc_core mii ac rfkill i2c_i801 soundcore mei(C) serio_raw pcspkr thermal 
  battery power_supply wmi usb_common evdev processor
  [  164.098188] Pid: 4684, comm: kworker/u:9 Tainted: G C   
  3.4.0-rc3 
  #1
  [  164.098189] Call Trace:
  [  164.098197]  [8103aa3c] warn_slowpath_common+0x7e/0x96
  [  164.098200]  [8103aae8] warn_slowpath_fmt+0x41/0x43
  [  164.098203]  [812cbec7] gen6_gt_check_fifodbg.isra.6+0x31/0x43
  [  164.098207]  [812cc13b] __gen6_gt_force_wake_put+0x19/0x1b
  [  164.098210]  [812cc3cf] i915_read32+0x66/0x9d
  [  164.098213]  [812ce4fa] i915_update_gfx_val+0x61/0xb9
  [  164.098218]  [812e989f] intel_idle_update+0x47/0x18d
  [  164.098222]  [810520d7] process_one_work+0x1b5/0x340
  [  164.098225]  [8105203a] ? process_one_work+0x118/0x340
  [  164.098228]  [812e9858] ? intel_disable_plane+0x60/0x60
  [  164.098231]  [81052c63] worker_thread+0xce/0x152
  [  164.098234]  [81052b95] ? manage_workers.isra.22+0x16a/0x16a
  [  164.098237]  [810567c6] kthread+0xa1/0xa9
  [  164.098242]  [81080ea1] ? trace_hardirqs_on+0xd/0xf
  [  164.098246]  [8145d374] kernel_thread_helper+0x4/0x10
  [  164.098250]  [81456970] ? retint_restore_args+0x13/0x13
  [  164.098253]  [81056725] ? __init_kthread_worker+0x55/0x55
  [  164.098256]  [8145d370] ? gs_change+0x13/0x13
  [  164.098257] ---[ end trace 97bd0b679d161c3e ]---
  [  164.098827] [ cut here ]
  [  164.098830] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398 
  gen6_gt_check_fifodbg.isra.6+0x31/0x43()
  [  164.098832] Hardware name: 1141ALG
  [  164.098833] MMIO read or write has been dropped 
  [  164.098834] Modules linked in: xt_tcpudp xt_limit xt_state 
  iptable_filter 
  nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables x_tables bnep 
  rfcomm 
  bluetooth uinput fuse loop sha256_generic aes_x86_64 aes_generic cbc 
  dm_crypt 
  dm_mod uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev 
  usbhid hid media snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi 
  mac80211 thinkpad_acpi cfg80211 coretemp nvram snd_hda_intel snd_hda_codec 
  snd_hwdep snd_pcm snd_page_alloc snd_seq ehci_hcd sdhci_pci crc32c_intel 
  iTCO_wdt iTCO_vendor_support ghash_clmulni_intel snd_seq_device cryptd 
  snd_timer microcode snd acpi_cpufreq mperf usbcore psmouse sdhci r8169 
  mmc_core mii ac rfkill i2c_i801 soundcore mei(C) serio_raw pcspkr thermal 
  battery power_supply wmi usb_common evdev processor
  [  164.098877] Pid: 4684, comm: kworker/u:9 Tainted: GWC   
  3.4.0-rc3 
  #1
  [  164.098878] Call Trace:
  [  164.098881]  [8103aa3c] warn_slowpath_common+0x7e/0x96
  [  164.098884]  [8103aae8] warn_slowpath_fmt+0x41/0x43
  [  164.09]  [812cbec7] gen6_gt_check_fifodbg.isra.6+0x31/0x43
  [  164.098891]  [812cc13b] __gen6_gt_force_wake_put+0x19/0x1b
  [  164.098894]  [812cc3cf] i915_read32+0x66/0x9d
  [  164.098896]  [812e98f7] intel_idle_update+0x9f/0x18d
  [  164.098899]  [810520d7] process_one_work+0x1b5/0x340
  [  164.098902]  [8105203a] ? process_one_work+0x118/0x340
  [  164.098904]  [812e9858] ? intel_disable_plane+0x60/0x60
  [  164.098907]  [81052c63] worker_thread+0xce/0x152
  [  164.098910]  [81052b95] ? manage_workers.isra.22+0x16a/0x16a
  [  164.098913]  [810567c6] kthread+0xa1/0xa9
  [  164.098916]  [81080ea1] ? trace_hardirqs_on+0xd/0xf
  [  164.098918]  [8145d374] kernel_thread_helper+0x4/0x10
  [  164.098921]  [81456970] ? 

Re: i915: kernel errors at resume

[Paul Bolle]

On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote:
 Please file a bug report with the error state attach (the
 entire thing), complete dmesg showing when the problem happens and a short
 description of the issue at bugs.freedesktop.org against DRI, component
 DRM/Intel.

See https://bugs.freedesktop.org/show_bug.cgi?id=49041 for that report.


Paul Bolle



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

Re: VM lockdep warning

[Jerome Glisse]

2012/4/21 Christian König deathsim...@vodafone.de:
 Interesting, I'm pretty sure that I haven't touched the locking order of the
 cs_mutex vs. vm_mutex.

 Maybe it is just some kind of side effect, going to locking into it anyway.

 Christian.


It's the using, init path take lock in different order than cs path

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

Re: Reworking of GPU reset logic

[Jerome Glisse]

2012/4/21 Christian König deathsim...@vodafone.de:
 On 20.04.2012 01:47, Jerome Glisse wrote:

 2012/4/19 Christian Königdeathsim...@vodafone.de:

 This includes mostly fixes for multi ring lockups and GPU resets, but it
 should general improve the behavior of the kernel mode driver in case
 something goes badly wrong.

 On the other hand it completely rewrites the IB pool and semaphore
 handling, so I think there are still a couple of problems in it.

 The first four patches were already send to the list, but the current set
 depends on them so I resend them again.

 Cheers,
 Christian.

 I did a quick review, it looks mostly good, but as it's sensitive code
 i would like to spend sometime on
 it. Probably next week. Note that i had some work on this area too, i
 mostly want to drop all the debugfs
 related to this and add some new more usefull (basicly something that
 allow you to read all the data
 needed to replay a locking up ib). I also was looking into Dave reset
 thread and your solution of moving
 reset in ioctl return path sounds good too but i need to convince my
 self that it encompass all possible
 case.

 Cheers,
 Jerome

 After sleeping a night over it I already reworked the patch for improving
 the SA performance, so please wait at least for v2 before taking a look at
 it :)

 Regarding the debugging of lockups I had the following on my in mind todo
 list:
 1. Rework the chip specific lockup detection code a bit more and probably
 clean it up a bit.
 2. Make the timeout a module parameter, cause compute task sometimes block a
 ring for more than 10 seconds.
 3. Keep track of the actually RPTR offset a fence is emitted to
 3. Keep track of all the BOs a IB is touching.
 4. Now if a lockup happens start with the last successfully signaled fence
 and dump the ring content after that RPTR offset till the first not signaled
 fence.
 5. Then if this fence references to an IB dump it's content and the BOs it
 is touching.
 6. Dump everything on the ring after that fence until you reach the RPTR of
 the next fence or the WPTR of the ring.
 7. If there is a next fence repeat the whole thing at number 5.

 If I'm not completely wrong that should give you practically every
 information available, and we probably should put that behind another module
 option, cause we are going to spam syslog pretty much here. Feel free to
 add/modify the ideas on this list.

 Christian.

What i have is similar, i am assuming only ib trigger lockup, before each ib
emit to scratch reg ib offset in sa and ib size. For each ib keep bo list. On
lockup allocate big memory to copy the whole ib and all the bo referenced
by the ib (i am using my bof format as i already have userspace tools).

Remove all the debugfs file. Just add a new one that gave you the first faulty
ib. On read of this file kernel free the memory. Kernel should also free the
memory after a while or better would be to enable the lockup copy only if
some kernel radeon option is enabled.

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

Re: VM lockdep warning

[Christian König]

On 21.04.2012 16:08, Jerome Glisse wrote:

2012/4/21 Christian Königdeathsim...@vodafone.de:

Interesting, I'm pretty sure that I haven't touched the locking order of the
cs_mutex vs. vm_mutex.

Maybe it is just some kind of side effect, going to locking into it anyway.

Christian.


It's the using, init path take lock in different order than cs path
Well, could you explain to me why the vm code takes cs mutex in the 
first place?


It clearly has it's own mutex and it doesn't looks like that it deals 
with any cs related data anyway.


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

Re: VM lockdep warning

[Jerome Glisse]

2012/4/21 Christian König deathsim...@vodafone.de:
 On 21.04.2012 16:08, Jerome Glisse wrote:

 2012/4/21 Christian Königdeathsim...@vodafone.de:

 Interesting, I'm pretty sure that I haven't touched the locking order of
 the
 cs_mutex vs. vm_mutex.

 Maybe it is just some kind of side effect, going to locking into it
 anyway.

 Christian.

 It's the using, init path take lock in different order than cs path

 Well, could you explain to me why the vm code takes cs mutex in the first
 place?

 It clearly has it's own mutex and it doesn't looks like that it deals with
 any cs related data anyway.

 Christian.

Lock simplification is on my todo. The issue is that vm manager is protected by
cs_mutex The vm.mutex is specific to each vm it doesn't protect the global vm
management. I didn't wanted to introduce a new global vm mutex as vm activity
is mostly trigger on behalf of cs so i dediced to use the cs mutex.

That's why non cs path of vm need to take the cs mutex.

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

Re: VM lockdep warning

[Dave Airlie]

2012/4/21 Jerome Glisse j.gli...@gmail.com:
 2012/4/21 Christian König deathsim...@vodafone.de:
 On 21.04.2012 16:08, Jerome Glisse wrote:

 2012/4/21 Christian Königdeathsim...@vodafone.de:

 Interesting, I'm pretty sure that I haven't touched the locking order of
 the
 cs_mutex vs. vm_mutex.

 Maybe it is just some kind of side effect, going to locking into it
 anyway.

 Christian.

 It's the using, init path take lock in different order than cs path

 Well, could you explain to me why the vm code takes cs mutex in the first
 place?

 It clearly has it's own mutex and it doesn't looks like that it deals with
 any cs related data anyway.

 Christian.

 Lock simplification is on my todo. The issue is that vm manager is protected 
 by
 cs_mutex The vm.mutex is specific to each vm it doesn't protect the global vm
 management. I didn't wanted to introduce a new global vm mutex as vm activity
 is mostly trigger on behalf of cs so i dediced to use the cs mutex.

 That's why non cs path of vm need to take the cs mutex.

So if one app is adding a bo, and another doing CS, isn't deadlock a
real possibility?

I expect the VM code need to take CS mutex earlier then.

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

Re: VM lockdep warning

[Christian König]

On 21.04.2012 17:57, Dave Airlie wrote:

2012/4/21 Jerome Glissej.gli...@gmail.com:

2012/4/21 Christian Königdeathsim...@vodafone.de:

On 21.04.2012 16:08, Jerome Glisse wrote:

2012/4/21 Christian Königdeathsim...@vodafone.de:

Interesting, I'm pretty sure that I haven't touched the locking order of
the
cs_mutex vs. vm_mutex.

Maybe it is just some kind of side effect, going to locking into it
anyway.

Christian.


It's the using, init path take lock in different order than cs path

Well, could you explain to me why the vm code takes cs mutex in the first
place?

It clearly has it's own mutex and it doesn't looks like that it deals with
any cs related data anyway.

Christian.

Lock simplification is on my todo. The issue is that vm manager is protected by
cs_mutex The vm.mutex is specific to each vm it doesn't protect the global vm
management. I didn't wanted to introduce a new global vm mutex as vm activity
is mostly trigger on behalf of cs so i dediced to use the cs mutex.

That's why non cs path of vm need to take the cs mutex.

So if one app is adding a bo, and another doing CS, isn't deadlock a
real possibility?

Yeah, I think so.

I expect the VM code need to take CS mutex earlier then.


I would strongly suggest to give the vm code their own global mutex and 
remove the per vm mutex, cause the later is pretty superfluous if the 
cs_mutex is also taken most of the time.


The attached patch is against drm-fixes and does exactly that.

Christian.
From b6a79c2e54f8200e770c25e930b0784343105a2b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= deathsim...@vodafone.de
Date: Sat, 21 Apr 2012 18:29:34 +0200
Subject: [PATCH] drm/radeon: use a global mutex instead of per vm one
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Resolving deadlock problems with the cs_mutex.

Signed-off-by: Christian König deathsim...@vodafone.de
---
 drivers/gpu/drm/radeon/radeon.h|2 +-
 drivers/gpu/drm/radeon/radeon_device.c |1 +
 drivers/gpu/drm/radeon/radeon_gart.c   |   25 +
 3 files changed, 11 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 138b952..f35957d 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -680,7 +680,6 @@ struct radeon_vm {
 	u64pt_gpu_addr;
 	u64*pt;
 	struct radeon_sa_bo		sa_bo;
-	struct mutex			mutex;
 	/* last fence for cs using this vm */
 	struct radeon_fence		*fence;
 };
@@ -1527,6 +1526,7 @@ struct radeon_device {
 	struct radeon_pm		pm;
 	uint32_t			bios_scratch[RADEON_BIOS_NUM_SCRATCH];
 	struct radeon_mutex		cs_mutex;
+	struct mutex			vm_mutex;
 	struct radeon_wb		wb;
 	struct radeon_dummy_page	dummy_page;
 	boolgpu_lockup;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
index ea7df16..cecb785 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -725,6 +725,7 @@ int radeon_device_init(struct radeon_device *rdev,
 	 * can recall function without having locking issues */
 	radeon_mutex_init(rdev-cs_mutex);
 	radeon_mutex_init(rdev-ib_pool.mutex);
+	mutex_init(rdev-vm_mutex);
 	for (i = 0; i  RADEON_NUM_RINGS; ++i)
 		mutex_init(rdev-ring[i].mutex);
 	mutex_init(rdev-dc_hw_i2c_mutex);
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c b/drivers/gpu/drm/radeon/radeon_gart.c
index c58a036..1b4933b 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -356,13 +356,13 @@ int radeon_vm_manager_suspend(struct radeon_device *rdev)
 {
 	struct radeon_vm *vm, *tmp;
 
-	radeon_mutex_lock(rdev-cs_mutex);
+	mutex_lock(rdev-vm_mutex);
 	/* unbind all active vm */
 	list_for_each_entry_safe(vm, tmp, rdev-vm_manager.lru_vm, list) {
 		radeon_vm_unbind_locked(rdev, vm);
 	}
 	rdev-vm_manager.funcs-fini(rdev);
-	radeon_mutex_unlock(rdev-cs_mutex);
+	mutex_unlock(rdev-vm_mutex);
 	return radeon_sa_bo_manager_suspend(rdev, rdev-vm_manager.sa_manager);
 }
 
@@ -476,13 +476,11 @@ int radeon_vm_bo_add(struct radeon_device *rdev,
 		return -EINVAL;
 	}
 
-	mutex_lock(vm-mutex);
+	mutex_lock(rdev-vm_mutex);
 	if (last_pfn  vm-last_pfn) {
 		/* grow va space 32M by 32M */
 		unsigned align = ((32  20)  12) - 1;
-		radeon_mutex_lock(rdev-cs_mutex);
 		radeon_vm_unbind_locked(rdev, vm);
-		radeon_mutex_unlock(rdev-cs_mutex);
 		vm-last_pfn = (last_pfn + align)  ~align;
 	}
 	head = vm-va;
@@ -498,7 +496,7 @@ int radeon_vm_bo_add(struct radeon_device *rdev,
 bo, (unsigned)bo_va-soffset, tmp-bo,
 (unsigned)tmp-soffset, (unsigned)tmp-eoffset);
 			kfree(bo_va);
-			mutex_unlock(vm-mutex);
+			mutex_unlock(rdev-vm_mutex);
 			return -EINVAL;
 		}
 		last_offset = tmp-eoffset;
@@ -506,7 +504,7 @@ int radeon_vm_bo_add(struct radeon_device *rdev,
 	}
 	list_add(bo_va-vm_list, head);
 	list_add_tail(bo_va-bo_list, bo-va);
-	mutex_unlock(vm-mutex);
+	

Re: VM lockdep warning

[Jerome Glisse]

2012/4/21 Christian König deathsim...@vodafone.de:
 On 21.04.2012 17:57, Dave Airlie wrote:

 2012/4/21 Jerome Glissej.gli...@gmail.com:

 2012/4/21 Christian Königdeathsim...@vodafone.de:

 On 21.04.2012 16:08, Jerome Glisse wrote:

 2012/4/21 Christian Königdeathsim...@vodafone.de:

 Interesting, I'm pretty sure that I haven't touched the locking order
 of
 the
 cs_mutex vs. vm_mutex.

 Maybe it is just some kind of side effect, going to locking into it
 anyway.

 Christian.

 It's the using, init path take lock in different order than cs path

 Well, could you explain to me why the vm code takes cs mutex in the
 first
 place?

 It clearly has it's own mutex and it doesn't looks like that it deals
 with
 any cs related data anyway.

 Christian.

 Lock simplification is on my todo. The issue is that vm manager is
 protected by
 cs_mutex The vm.mutex is specific to each vm it doesn't protect the
 global vm
 management. I didn't wanted to introduce a new global vm mutex as vm
 activity
 is mostly trigger on behalf of cs so i dediced to use the cs mutex.

 That's why non cs path of vm need to take the cs mutex.

 So if one app is adding a bo, and another doing CS, isn't deadlock a
 real possibility?

 Yeah, I think so.

No it's not. Look at the code.

 I expect the VM code need to take CS mutex earlier then.

No it does not. The idea is that when adding a bo we only need to take the
cs mutex if we need to resize the vm size (and even that can be worked around).

So we will need to take the cs ioctl in very few case (suspend, increasing vm
size).


 I would strongly suggest to give the vm code their own global mutex and
 remove the per vm mutex, cause the later is pretty superfluous if the
 cs_mutex is also taken most of the time.

 The attached patch is against drm-fixes and does exactly that.

 Christian.

NAK with your change there will be lock contention if one app is in cs and
another try to create bo. Currently there is allmost never contention. Once
i ironed out the DP-VGA i will work on something to remove the cs mutex
from vm path (ie remove it from bo creation/del path).

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

Re: [Regression][3.4-rc3][intel-dri] MMIO read or write has been dropped ffffffff

[Maciej Rutecki]

On sobota, 21 kwietnia 2012 o 15:13:52 Daniel Vetter wrote:
 On Sat, Apr 21, 2012 at 03:03:07PM +0200, Daniel Vetter wrote:
  On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote:
   Bad kernel: 3.4-rc3
   Last known good: 3.3
   
   Subsystem: dri-intel (guess)
   
   Steps to reproduce:
   1. Suspend to ram
   2. Resume
   
   After resume laptop works ok, but in dmesg I found:
   [  164.098113] [ cut here ]
   [  164.098124] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398
   gen6_gt_check_fifodbg.isra.6+0x31/0x43()
   [  164.098126] Hardware name: 1141ALG
   [  164.098128] MMIO read or write has been dropped 
   [  164.098129] Modules linked in: xt_tcpudp xt_limit xt_state
   iptable_filter nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables
   x_tables bnep rfcomm bluetooth uinput fuse loop sha256_generic
   aes_x86_64 aes_generic cbc dm_crypt dm_mod uvcvideo videobuf2_vmalloc
   videobuf2_memops videobuf2_core videodev usbhid hid media
   snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi mac80211
   thinkpad_acpi cfg80211 coretemp nvram snd_hda_intel snd_hda_codec
   snd_hwdep snd_pcm snd_page_alloc snd_seq ehci_hcd sdhci_pci
   crc32c_intel iTCO_wdt iTCO_vendor_support ghash_clmulni_intel
   snd_seq_device cryptd snd_timer microcode snd acpi_cpufreq mperf
   usbcore psmouse sdhci r8169 mmc_core mii ac rfkill i2c_i801 soundcore
   mei(C) serio_raw pcspkr thermal battery power_supply wmi usb_common
   evdev processor
   [  164.098188] Pid: 4684, comm: kworker/u:9 Tainted: G C  
   3.4.0-rc3 #1
   [  164.098189] Call Trace:
   [  164.098197]  [8103aa3c] warn_slowpath_common+0x7e/0x96
   [  164.098200]  [8103aae8] warn_slowpath_fmt+0x41/0x43
   [  164.098203]  [812cbec7]
   gen6_gt_check_fifodbg.isra.6+0x31/0x43 [  164.098207] 
   [812cc13b] __gen6_gt_force_wake_put+0x19/0x1b [  164.098210]
[812cc3cf] i915_read32+0x66/0x9d
   [  164.098213]  [812ce4fa] i915_update_gfx_val+0x61/0xb9
   [  164.098218]  [812e989f] intel_idle_update+0x47/0x18d
   [  164.098222]  [810520d7] process_one_work+0x1b5/0x340
   [  164.098225]  [8105203a] ? process_one_work+0x118/0x340
   [  164.098228]  [812e9858] ? intel_disable_plane+0x60/0x60
   [  164.098231]  [81052c63] worker_thread+0xce/0x152
   [  164.098234]  [81052b95] ?
   manage_workers.isra.22+0x16a/0x16a [  164.098237] 
   [810567c6] kthread+0xa1/0xa9
   [  164.098242]  [81080ea1] ? trace_hardirqs_on+0xd/0xf
   [  164.098246]  [8145d374] kernel_thread_helper+0x4/0x10
   [  164.098250]  [81456970] ? retint_restore_args+0x13/0x13
   [  164.098253]  [81056725] ? __init_kthread_worker+0x55/0x55
   [  164.098256]  [8145d370] ? gs_change+0x13/0x13
   [  164.098257] ---[ end trace 97bd0b679d161c3e ]---
   [  164.098827] [ cut here ]
   [  164.098830] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398
   gen6_gt_check_fifodbg.isra.6+0x31/0x43()
   [  164.098832] Hardware name: 1141ALG
   [  164.098833] MMIO read or write has been dropped 
   [  164.098834] Modules linked in: xt_tcpudp xt_limit xt_state
   iptable_filter nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables
   x_tables bnep rfcomm bluetooth uinput fuse loop sha256_generic
   aes_x86_64 aes_generic cbc dm_crypt dm_mod uvcvideo videobuf2_vmalloc
   videobuf2_memops videobuf2_core videodev usbhid hid media
   snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi mac80211
   thinkpad_acpi cfg80211 coretemp nvram snd_hda_intel snd_hda_codec
   snd_hwdep snd_pcm snd_page_alloc snd_seq ehci_hcd sdhci_pci
   crc32c_intel iTCO_wdt iTCO_vendor_support ghash_clmulni_intel
   snd_seq_device cryptd snd_timer microcode snd acpi_cpufreq mperf
   usbcore psmouse sdhci r8169 mmc_core mii ac rfkill i2c_i801 soundcore
   mei(C) serio_raw pcspkr thermal battery power_supply wmi usb_common
   evdev processor
   [  164.098877] Pid: 4684, comm: kworker/u:9 Tainted: GWC  
   3.4.0-rc3 #1
   [  164.098878] Call Trace:
   [  164.098881]  [8103aa3c] warn_slowpath_common+0x7e/0x96
   [  164.098884]  [8103aae8] warn_slowpath_fmt+0x41/0x43
   [  164.09]  [812cbec7]
   gen6_gt_check_fifodbg.isra.6+0x31/0x43 [  164.098891] 
   [812cc13b] __gen6_gt_force_wake_put+0x19/0x1b [  164.098894]
[812cc3cf] i915_read32+0x66/0x9d
   [  164.098896]  [812e98f7] intel_idle_update+0x9f/0x18d
   [  164.098899]  [810520d7] process_one_work+0x1b5/0x340
   [  164.098902]  [8105203a] ? process_one_work+0x118/0x340
   [  164.098904]  [812e9858] ? intel_disable_plane+0x60/0x60
   [  164.098907]  [81052c63] worker_thread+0xce/0x152
   [  164.098910]  [81052b95] ?
   manage_workers.isra.22+0x16a/0x16a [  164.098913] 
   [810567c6] kthread+0xa1/0xa9
   [  164.098916]  [81080ea1] ? trace_hardirqs_on+0xd/0xf
   [  

Re: VM lockdep warning

[Christian König]

On 21.04.2012 19:30, Jerome Glisse wrote:

2012/4/21 Christian Königdeathsim...@vodafone.de:

On 21.04.2012 17:57, Dave Airlie wrote:

2012/4/21 Jerome Glissej.gli...@gmail.com:

2012/4/21 Christian Königdeathsim...@vodafone.de:

On 21.04.2012 16:08, Jerome Glisse wrote:

2012/4/21 Christian Königdeathsim...@vodafone.de:

Interesting, I'm pretty sure that I haven't touched the locking order
of
the
cs_mutex vs. vm_mutex.

Maybe it is just some kind of side effect, going to locking into it
anyway.

Christian.


It's the using, init path take lock in different order than cs path

Well, could you explain to me why the vm code takes cs mutex in the
first
place?

It clearly has it's own mutex and it doesn't looks like that it deals
with
any cs related data anyway.

Christian.

Lock simplification is on my todo. The issue is that vm manager is
protected by
cs_mutex The vm.mutex is specific to each vm it doesn't protect the
global vm
management. I didn't wanted to introduce a new global vm mutex as vm
activity
is mostly trigger on behalf of cs so i dediced to use the cs mutex.

That's why non cs path of vm need to take the cs mutex.

So if one app is adding a bo, and another doing CS, isn't deadlock a
real possibility?

Yeah, I think so.

No it's not. Look at the code.


I expect the VM code need to take CS mutex earlier then.

No it does not. The idea is that when adding a bo we only need to take the
cs mutex if we need to resize the vm size (and even that can be worked around).

So we will need to take the cs ioctl in very few case (suspend, increasing vm
size).


I would strongly suggest to give the vm code their own global mutex and
remove the per vm mutex, cause the later is pretty superfluous if the
cs_mutex is also taken most of the time.

The attached patch is against drm-fixes and does exactly that.

Christian.

NAK with your change there will be lock contention if one app is in cs and
another try to create bo. Currently there is allmost never contention. Once
i ironed out the DP-VGA i will work on something to remove the cs mutex
from vm path (ie remove it from bo creation/del path).


Ok, sounds like I don't understand the code deeply enough to fix this. 
So I'm just going to wait for your fix.


By the way: If you are talking about the NUTMEG DP-VGA problem, I have 
two systems with that sitting directly beside me. So if you got any 
patches just leave me a note and I can try them.


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

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

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Friday 20 April 2012 16:45:29 Tomasz Stanislawski wrote:
 From: Andrzej Pietrasiewicz andrze...@samsung.com
 
 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 andrze...@samsung.com
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
   [bugfixing]
 Signed-off-by: Kamil Debski k.deb...@samsung.com
   [bugfixing]
 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
   [add sglist subroutines/code refactoring]
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

-- 
Regards,

Laurent Pinchart

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

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

[Laurent Pinchart]

Hi Rémi,

On Friday 20 April 2012 15:03:17 Rémi Denis-Courmont wrote:
 On Fri, 20 Apr 2012 14:25:01 +0200, Tomasz Stanislawski wrote:
  The USERPTR simplifies userspace code but introduce
  a lot of complexity problems for the kernel drivers
  and frameworks.
  
  It is not only a simplification. In some cases, USERPTR is the only I/O
  method that supports zero copy in pretty much any circumstance.
  
  Only for devices that have its own IOMMU that can access system memory.
 
 Newer versions of the UVC driver have USERTPR, and simingly gspca seems
 too. That is practically all USB capture devices... That might be
 irrelevant for a smartphone manufacturer. That is very relevant for desktop
 applications.
 
  Moreover the userptr must come from malloc or be a mmaped file.
  The other case are drivers that touch memory using CPU in the kernel
  space like VIVI or USB drivers.
 
 I'd argue that USB is the most common case of V4L2 on the desktop...
 
  When the user cannot reliably predict the maximum number of required
  buffers, predicts a value larger than the device will negotiate, or
  needs buffers to outlive STREAMOFF (?), MMAP requires memory copying.
  USERPTR does not.
  
  What does outlive STREAMOFF means in this context?
 
 Depending how your multimedia pipeline is built, it is plausible that the
 V4L2 source is shutdown (STREAMOFF then close()) before buffers coming from
 it are released/destroyed downstream. I might be wrong, but I would expect
 that V4L2 MMAP buffers become invalid after STREAMOFF+close()?

If the buffer is mmap()ed to userspace, it will not be freed before being 
munmap()ed.

  Anyway, IMO allocation of the buffers at VIDIOC_REQBUFS was not the best
  idea because it introduces an allocation overhead for negotiations of
  the number of the buffers. An allocation at mmap was to late. There is a
  need for some intermediate state between REQBUFS and mmap. The ioctl
  BUF_PREPARE may help here.
  
  Can you give me an example of a sane application is forced to negotiate
  a larger number of buffers than it is actually going to use?
 
 Outside the embedded world, the application typically does not know what
 the latency of the multimedia pipeline is. If the latency is not known, the
 number of buffers needed for zero copy cannot be precomputed for REQBUFS,
 say:
 
 count = 1 + latency / frame interval.
 
 Even for a trivial analog TV viewer application, lip synchronization
 requires picture frames to be bufferred to be long enough to account for
 the latency of the audio input, dejitter, filtering and audio output. Those
 values are usually not well determined at the time of requesting buffers
 from the video capture device. Also the application may want to play nice
 with PulseAudio. Then it will get very long audio buffers with very few
 audio periods... more latency.
 
 It gets harder or outright impossible for frameworks dealing with
 complicated or arbitrary pipelines such as LibVLC or gstreamer. There is
 far too much unpredictability and variability downstream of the V4L2 source
 to estimate latency, and infer the number of buffers needed.

If I'm not mistaken VIDIOC_CREATEBUF allows you to create additional buffers 
at runtime. You can thus cope with a latency increase (provided that the 
allocation overhead isn't prohibitive, in which case you're stuck whatever 
method you select). Deleting buffers at runtime is currently not possible 
though.

  Now, I do realize that some devices cannot support USERPTR efficiently,
  then they should not support USERPTR.
  
  The problem is not there is *NO* device that can handle USERPTR reliably.
  The can handle USERPTR generated by malloc or page cache (not sure).
  Memory mmaped from other devices, frameworks etc may or may not work.
  Even if the device has its IOMMU the DMA layer provides no generic way to
  transform from one device to the mapping in some other device.
 
 I'm not saying that USERPTR should replace DMABUF. I'm saying USERPTR has
 advantages over MMAP that DMABUF does not seem to cover as yet (if only
 libv4l2 would not inhibit USERPTR...).
 
 I'm definitely not saying that applications should rely on USERPTR being
 supported. We agree that not all devices can support USERPTR.
 
  The userptr has its niches were it works pretty well like Web cams or
  VIVI.
 
  I am saying that if ever DMABUF becomes a good alternative for USERPTR
  than maybe we should consider encouraging dropping USERPTR in the new
  drivers as 'obsolete' feature and providing some emulation layer in
  libv4l2 for legacy applications.
 
 Sure.
-- 
Regards,

Laurent Pinchart

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

[PATCH] m68k/video: Create asm/vga.h

[Geert Uytterhoeven]

For now, it just contains the hack for cirrusfb on Amiga, which is moved
out of video/vga.h with some slight modifications (use raw_*() instead of
z_*(), which are defined on all m68k platforms).

This makes it safe to include video/vga.h in all contexts. Before it
could fail to compile with

include/video/vga.h: In function ‘vga_mm_r’:
include/video/vga.h:242: error: implicit declaration of function ‘z_readb’
include/video/vga.h: In function ‘vga_mm_w’:
include/video/vga.h:247: error: implicit declaration of function ‘z_writeb’
include/video/vga.h: In function ‘vga_mm_w_fast’:
include/video/vga.h:253: error: implicit declaration of function ‘z_writew’

or

include/video/vga.h:23:21: error: asm/vga.h: No such file or directory

depending on the value of CONFIG_AMIGA.

Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
Will queue for 3.5, cfr.
http://kisskb.ellerman.id.au/kisskb/buildresult/6127136/
---
 arch/m68k/include/asm/vga.h |   27 +++
 include/video/vga.h |   22 --
 2 files changed, 27 insertions(+), 22 deletions(-)
 create mode 100644 arch/m68k/include/asm/vga.h

diff --git a/arch/m68k/include/asm/vga.h b/arch/m68k/include/asm/vga.h
new file mode 100644
index 000..d3aa140
--- /dev/null
+++ b/arch/m68k/include/asm/vga.h
@@ -0,0 +1,27 @@
+#ifndef _ASM_M68K_VGA_H
+#define _ASM_M68K_VGA_H
+
+#include asm/raw_io.h
+
+/*
+ * FIXME
+ * Ugh, we don't have PCI space, so map readb() and friends to use raw I/O
+ * accessors, which are identical to the z_*() Zorro bus accessors.
+ * This should make cirrusfb work again on Amiga
+ */
+#undef inb_p
+#undef inw_p
+#undef outb_p
+#undef outw
+#undef readb
+#undef writeb
+#undef writew
+#define inb_p(port)0
+#define inw_p(port)0
+#define outb_p(port, val)  do { } while (0)
+#define outw(port, val)do { } while (0)
+#define readb  raw_inb
+#define writeb raw_outb
+#define writew raw_outw
+
+#endif /* _ASM_M68K_VGA_H */
diff --git a/include/video/vga.h b/include/video/vga.h
index 2b8691f..cac567f 100644
--- a/include/video/vga.h
+++ b/include/video/vga.h
@@ -19,29 +19,7 @@
 
 #include linux/types.h
 #include asm/io.h
-#ifndef CONFIG_AMIGA
 #include asm/vga.h
-#else
-/*
- * FIXME
- * Ugh, we don't have PCI space, so map readb() and friends to use Zorro space
- * for MMIO accesses. This should make cirrusfb work again on Amiga
- */
-#undef inb_p
-#undef inw_p
-#undef outb_p
-#undef outw
-#undef readb
-#undef writeb
-#undef writew
-#define inb_p(port)0
-#define inw_p(port)0
-#define outb_p(port, val)  do { } while (0)
-#define outw(port, val)do { } while (0)
-#define readb  z_readb
-#define writeb z_writeb
-#define writew z_writew
-#endif
 #include asm/byteorder.h
 
 
-- 
1.7.0.4

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

Re: [PATCH libdrm 1/5] modetest: fix some compiler warnings

[Paulo Zanoni]

2012/3/29 Eugeni Dodonov eug...@dodonov.net:
 I wonder if we could drop the dead^W#ifd 0'ed code here as well, perhaps
 with a separate patch? I don't think it will get used again in the future
 (but I might be wrong).


Removing #if 0'ed code won't fix compiler warnings, so if we do this,
it should
be done in a separate patch.

I'm resending this patch with more warning fixes and a rebase.


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

Re: [PATCH libdrm 3/5] modetest: print more about our properties

[Paulo Zanoni]

2012/3/29 Eugeni Dodonov eug...@dodonov.net:
 On Thu, Mar 29, 2012 at 18:28, Paulo Zanoni przan...@gmail.com wrote:

 really-small-bikeshedding
 I don't know if it should go into a separate patch though. But it is aligned
 to the other formatting patterns you do, and it certainly looks nicer this
 way, and it shouldn't break anything anyway. So I am fine either way :).
 /really-small-bikeshedding

I agree, but it's a single-line change that does not make much sense without
this patch, so I decided to not have a patch that just replaceswith \t.

 The previous function dump_props also segfaulted when we didn't have
 enought permissions. The new function does not segfault in this case (by
 checking for the return value of drmModeGetProperty).

 another-bikeshedding
 I think this could be done in a separate patch..
 /another-bikeshedding

No. This is just a note like the function I just killed had a bug,
the function
that replaces it does not have the same bug. It would make no sense
to send a
patch to fix the old function, then send this patch replacing the
whole
function. Why fix it if you're going to replace it?


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

[PATCH libdrm 1/4] modetest: fix some compiler warnings

[Paulo Zanoni]

From: Paulo Zanoni paulo.r.zan...@intel.com

Use unsigned int instead of int:
- modetest.c:90:1: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]
- modetest.c:98:1: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]
- modetest.c:118:1: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]
- modetest.c:286:16: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]
- modetest.c:303:17: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]
- modetest.c:694:16: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]
- modetest.c:1088:16: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]

The 'fd' variable is global, we don't need to pass it as an argument:
- modetest.c:998:40: warning: unused parameter ‘fd’ [-Wunused-parameter]

We don't use the 'modeset' variable:
- modetest.c:1025:8: warning: variable ‘modeset’ set but not used 
[-Wunused-but-set-variable]

V2: rebase, clear some more warnings

Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 tests/modetest/modetest.c |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

Hi

I'm sending this patch series again. These 4 patches are independent
from the object properties patches, so once reviewed, it would be nice
if someone could push them.

Patch 1 had to be rebased and patch 3 is new.

Thanks,
Paulo


diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 223adc4..1b9ae18 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -71,7 +71,7 @@ struct type_name {
 
 #define type_name_fn(res) \
 char * res##_str(int type) {   \
-   int i;  \
+   unsigned int i; \
for (i = 0; i  ARRAY_SIZE(res##_names); i++) { \
if (res##_names[i].type == type)\
return res##_names[i].name; \
@@ -272,7 +272,7 @@ static void dump_planes(void)
 {
drmModePlaneRes *plane_resources;
drmModePlane *ovr;
-   int i, j;
+   unsigned int i, j;
 
plane_resources = drmModeGetPlaneResources(fd);
if (!plane_resources) {
@@ -681,7 +681,8 @@ set_plane(struct kms_driver *kms, struct connector *c, 
struct plane *p)
uint32_t plane_id = 0;
struct kms_bo *plane_bo;
uint32_t plane_flags = 0, format;
-   int i, ret, crtc_x, crtc_y, crtc_w, crtc_h;
+   int ret, crtc_x, crtc_y, crtc_w, crtc_h;
+   unsigned int i;
 
/* find an unused plane which can be connected to our crtc */
plane_resources = drmModeGetPlaneResources(fd);
@@ -995,7 +996,7 @@ void usage(char *name)
 
 #define dump_resource(res) if (res) dump_##res()
 
-static int page_flipping_supported(int fd)
+static int page_flipping_supported(void)
 {
/*FIXME: generic ioctl needed? */
return 1;
@@ -1022,8 +1023,8 @@ int main(int argc, char **argv)
int encoders = 0, connectors = 0, crtcs = 0, planes = 0, framebuffers = 
0;
int test_vsync = 0;
char *modules[] = { i915, radeon, nouveau, vmwgfx, omapdrm };
-   char *modeset = NULL;
-   int i, count = 0, plane_count = 0;
+   unsigned int i;
+   int count = 0, plane_count = 0;
struct connector con_args[2];
struct plane plane_args[2] = {0};

@@ -1050,7 +1051,6 @@ int main(int argc, char **argv)
test_vsync = 1;
break;
case 's':
-   modeset = strdup(optarg);
con_args[count].crtc = -1;
if (sscanf(optarg, %d:%64s,
   con_args[count].id,
@@ -1096,7 +1096,7 @@ int main(int argc, char **argv)
}
}
 
-   if (test_vsync  !page_flipping_supported(fd)) {
+   if (test_vsync  !page_flipping_supported()) {
fprintf(stderr, page flipping not supported by drm.\n);
return -1;
}
-- 
1.7.9.5

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

[PATCH libdrm 2/4] modetest: fix drmModeGetConnector memory leak

[Paulo Zanoni]

From: Paulo Zanoni paulo.r.zan...@intel.com

Don't continue without freeing the connector.

192 bytes in 6 blocks are indirectly lost in loss record 6 of 12
   at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x4E30DD8: drmMalloc (xf86drm.c:147)
   by 0x4E35024: drmAllocCpy (xf86drmMode.c:73)
   by 0x4E35D69: drmModeGetConnector (xf86drmMode.c:507)
   by 0x402F22: dump_connectors (modetest.c:181)
   by 0x40261B: main (modetest.c:801)

Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 tests/modetest/modetest.c |   21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 1b9ae18..64809da 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -199,17 +199,16 @@ void dump_connectors(void)
printf(%s%d, j  0 ? ,  : , 
connector-encoders[j]);
printf(\n);
 
-   if (!connector-count_modes)
-   continue;
-
-   printf(  modes:\n);
-   printf(  name refresh (Hz) hdisp hss hse htot vdisp 
-  vss vse vtot)\n);
-   for (j = 0; j  connector-count_modes; j++)
-   dump_mode(connector-modes[j]);
-
-   printf(  props:\n);
-   dump_props(connector);
+   if (connector-count_modes) {
+   printf(  modes:\n);
+   printf(  name refresh (Hz) hdisp hss hse htot vdisp 
+  vss vse vtot)\n);
+   for (j = 0; j  connector-count_modes; j++)
+   dump_mode(connector-modes[j]);
+
+   printf(  props:\n);
+   dump_props(connector);
+   }
 
drmModeFreeConnector(connector);
}
-- 
1.7.9.5

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

[PATCH libdrm 3/4] modetest: call drmModeFreePlaneResources

[Paulo Zanoni]

From: Paulo Zanoni paulo.r.zan...@intel.com

24 (16 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 
2 of 7
   at 0x402994D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x4A25950: drmMalloc (xf86drm.c:147)
   by 0x4A2E26D: drmModeGetPlaneResources (xf86drmMode.c:951)
   by 0x4025FF: dump_planes (modetest.c:276)
   by 0x4052AF: main (modetest.c:1120)

Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 tests/modetest/modetest.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 64809da..6deed69 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -307,6 +307,7 @@ static void dump_planes(void)
}
printf(\n);
 
+   drmModeFreePlaneResources(plane_resources);
return;
 }
 
-- 
1.7.9.5

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

[PATCH libdrm 4/4] modetest: print more about our properties

[Paulo Zanoni]

From: Paulo Zanoni paulo.r.zan...@intel.com

In the future we'll have more than just connector properties, so create
a dump_prop function that can handle any property (instead of the
current dump_props function that only handles connector properties).

Also, make this function print a lot more information about the existing
properties.

Also change the printed indentation of the modes to make the output more
readable.

The previous function dump_props also segfaulted when we didn't have
enought permissions. The new function does not segfault in this case (by
checking for the return value of drmModeGetProperty).

Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 tests/modetest/modetest.c |   95 -
 1 file changed, 86 insertions(+), 9 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 6deed69..5784622 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -43,6 +43,7 @@
 #include stdio.h
 #include stdlib.h
 #include stdint.h
+#include inttypes.h
 #include unistd.h
 #include string.h
 #include errno.h
@@ -145,7 +146,7 @@ void dump_encoders(void)
 
 void dump_mode(drmModeModeInfo *mode)
 {
-   printf(  %s %d %d %d %d %d %d %d %d %d\n,
+   printf(\t%s %d %d %d %d %d %d %d %d %d\n,
   mode-name,
   mode-vrefresh,
   mode-hdisplay,
@@ -159,16 +160,90 @@ void dump_mode(drmModeModeInfo *mode)
 }
 
 static void
-dump_props(drmModeConnector *connector)
+dump_blob(uint32_t blob_id)
+{
+   uint32_t i;
+   unsigned char *blob_data;
+   drmModePropertyBlobPtr blob;
+
+   blob = drmModeGetPropertyBlob(fd, blob_id);
+   if (!blob)
+   return;
+
+   blob_data = blob-data;
+
+   for (i = 0; i  blob-length; i++) {
+   if (i % 16 == 0)
+   printf(\n\t\t\t);
+   printf(%.2hhx, blob_data[i]);
+   }
+   printf(\n);
+
+   drmModeFreePropertyBlob(blob);
+}
+
+static void
+dump_prop(uint32_t prop_id, uint64_t value)
 {
-   drmModePropertyPtr props;
int i;
+   drmModePropertyPtr prop;
+
+   prop = drmModeGetProperty(fd, prop_id);
+
+   printf(\t%d, prop_id);
+   if (!prop) {
+   printf(\n);
+   return;
+   }
+
+   printf( %s:\n, prop-name);
+
+   printf(\t\tflags:);
+   if (prop-flags  DRM_MODE_PROP_PENDING)
+   printf( pending);
+   if (prop-flags  DRM_MODE_PROP_RANGE)
+   printf( range);
+   if (prop-flags  DRM_MODE_PROP_IMMUTABLE)
+   printf( immutable);
+   if (prop-flags  DRM_MODE_PROP_ENUM)
+   printf( enum);
+   if (prop-flags  DRM_MODE_PROP_BLOB)
+   printf( blob);
+   printf(\n);
+
+   if (prop-flags  DRM_MODE_PROP_RANGE) {
+   printf(\t\tvalues:);
+   for (i = 0; i  prop-count_values; i++)
+   printf( %PRIu64, prop-values[i]);
+   printf(\n);
+   }
 
-   for (i = 0; i  connector-count_props; i++) {
-   props = drmModeGetProperty(fd, connector-props[i]);
-   printf(\t%s, flags %d\n, props-name, props-flags);
-   drmModeFreeProperty(props);
+   if (prop-flags  DRM_MODE_PROP_ENUM) {
+   printf(\t\tenums:);
+   for (i = 0; i  prop-count_enums; i++)
+   printf( %s=%llu, prop-enums[i].name,
+  prop-enums[i].value);
+   printf(\n);
+   } else {
+   assert(prop-count_enums == 0);
}
+
+   if (prop-flags  DRM_MODE_PROP_BLOB) {
+   printf(\t\tblobs:\n);
+   for (i = 0; i  prop-count_blobs; i++)
+   dump_blob(prop-blob_ids[i]);
+   printf(\n);
+   } else {
+   assert(prop-count_blobs == 0);
+   }
+
+   printf(\t\tvalue:);
+   if (prop-flags  DRM_MODE_PROP_BLOB)
+   dump_blob(value);
+   else
+   printf( %PRIu64\n, value);
+
+   drmModeFreeProperty(prop);
 }
 
 void dump_connectors(void)
@@ -201,13 +276,15 @@ void dump_connectors(void)
 
if (connector-count_modes) {
printf(  modes:\n);
-   printf(  name refresh (Hz) hdisp hss hse htot vdisp 
+   printf(\tname refresh (Hz) hdisp hss hse htot vdisp 
   vss vse vtot)\n);
for (j = 0; j  connector-count_modes; j++)
dump_mode(connector-modes[j]);
 
printf(  props:\n);
-   dump_props(connector);
+   for (j = 0; j  connector-count_props; j++)
+   dump_prop(connector-props[j],
+ connector-prop_values[j]);
}
 

Re: [PATCH] scatterlist: add sg_alloc_table_by_pages function

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Wednesday 18 April 2012 11:44:59 Tomasz Stanislawski wrote:
 This patch adds a new constructor for an sg table. The table is constructed
 from an array of struct pages. All contiguous chunks of the pages are merged
 into a single sg nodes. A user may provide an offset and a size of a buffer
 if the buffer is not page-aligned.
 
 The function is dedicated for DMABUF exporters which often performs
 conversion from an page array to a scatterlist. Moreover the scatterlist
 should be squashed in order to save memory and to speed-up DMA mapping
 using dma_map_sg.
 
 The code is based on the patch 'v4l: vb2-dma-contig: add support for
 scatterlist in userptr mode' and hints from Laurent Pinchart.

The patch looks good to me. Just a small comment, what do you think about 
naming the function sg_alloc_table_from_pages instead of 
sg_table_alloc_by_pages ?

 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  include/linux/scatterlist.h |4 +++
  lib/scatterlist.c   |   63
 +++ 2 files changed, 67
 insertions(+), 0 deletions(-)
 
 diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
 index ac9586d..8d9e6fe 100644
 --- a/include/linux/scatterlist.h
 +++ b/include/linux/scatterlist.h
 @@ -214,6 +214,10 @@ void sg_free_table(struct sg_table *);
  int __sg_alloc_table(struct sg_table *, unsigned int, unsigned int, gfp_t,
sg_alloc_fn *);
  int sg_alloc_table(struct sg_table *, unsigned int, gfp_t);
 +int sg_alloc_table_by_pages(struct sg_table *sgt,
 + struct page **pages, unsigned int n_pages,
 + unsigned long offset, unsigned long size,
 + gfp_t gfp_mask);
  size_t sg_copy_from_buffer(struct scatterlist *sgl, unsigned int nents,
  void *buf, size_t buflen);
 diff --git a/lib/scatterlist.c b/lib/scatterlist.c
 index 6096e89..30b9def 100644
 --- a/lib/scatterlist.c
 +++ b/lib/scatterlist.c
 @@ -319,6 +319,69 @@ int sg_alloc_table(struct sg_table *table, unsigned int
 nents, gfp_t gfp_mask) EXPORT_SYMBOL(sg_alloc_table);
 
  /**
 + * sg_alloc_table_by_pages - Allocate and initialize an sg table from an
 array + *  of pages
 + * @sgt: The sg table header to use
 + * @pages:   Pointer to an array of page pointers
 + * @n_pages: Number of pages in the pages array
 + * @offset: Offset from start of the first page to the start of a
 buffer + * @size:   Number of valid bytes in the buffer (after offset)
 + * @gfp_mask:GFP allocation mask
 + *
 + *  Description:
 + *Allocate and initialize an sg table from a list of pages. Continuous
 + *ranges of the pages are squashed into a single scatterlist node. A
 user + *may provide an offset at a start and a size of valid data in a
 buffer + *specified by the page array. The returned sg table is
 released by + *sg_free_table.
 + *
 + * Returns:
 + *   0 on success

Maybe you should mention what it returns in case of an error as well.

 + **/
 +int sg_alloc_table_by_pages(struct sg_table *sgt,
 + struct page **pages, unsigned int n_pages,
 + unsigned long offset, unsigned long size,
 + gfp_t gfp_mask)
 +{
 + unsigned int chunks;
 + unsigned int i;
 + unsigned int cur_page;
 + int ret;
 + struct scatterlist *s;
 +
 + /* compute number of contiguous 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_mask);
 + if (unlikely(ret))
 + return ret;
 +
 + /* merging chunks and putting them into the scatterlist */
 + cur_page = 0;
 + for_each_sg(sgt-sgl, s, sgt-orig_nents, i) {
 + unsigned long chunk_size;
 + unsigned int j;
 +
 + /* looking for the end of the current chunk */
 + for (j = cur_page + 1; j  n_pages; ++j)
 + if (pages[j] != pages[j - 1] + 1)
 + break;
 +
 + chunk_size = ((j - cur_page)  PAGE_SHIFT) - offset;
 + sg_set_page(s, pages[cur_page], min(size, chunk_size), offset);
 + size -= chunk_size;
 + offset = 0;
 + cur_page = j;
 + }
 +
 + return 0;
 +}
 +EXPORT_SYMBOL(sg_alloc_table_by_pages);
 +
 +/**
   * sg_miter_start - start mapping iteration over a sg list
   * @miter: sg mapping iter to be started
   * @sgl: sg list to iterate over
-- 
Regards,

Laurent Pinchart

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

Re: Linux 3.4-rc4

[Linus Torvalds]

David  co, any ideas?

There are other reports of problems with 3.3.x kernels, there's a
report from Tim timlie...@woh.rr.com which may be related (also
apparently working in 3.2, broken black screen in all 3.3.x).

Nick, I realize you had trouble with a bisection already, but it might
really be worth trying again. Do a

git bisect visualize

and try to pick a good commit (avoding the problems you hit) when you
hit a problem, and then do

   git reset --hard that-point

to force bisection to try another place. That way you can sometimes
avoid the problem spots, and continue the bisection.

Linus

On Sat, Apr 21, 2012 at 9:07 PM, Nick Bowler nbow...@elliptictech.com wrote:
 On 2012-04-21 15:43 -0700, Linus Torvalds wrote:
 But none of it really looks all that scary. It looks like the 3.4
 release is all on track, but please do holler if you see regressions.

 OK, I'll holler.  Nouveau is still broken in mainline, as it has been
 since March or so, first reported here:

  Subject: Regression: black screen on VGA w/ nouveau in Linux 3.3.
  http://thread.gmane.org/gmane.linux.kernel/1269631

 So far, attempts to elicit a response of any kind from maintainers has
 been about as successful as talking to my doorknob.

 Thanks,
 --
 Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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