Deadlock in Xorg after commit "drm: tweak getconnector locking"

2015-02-15 Thread Marc Finet
Hello,

After trying linux-next (next-20150130) on my i915-powered laptop, I failed to
get Xorg running (just a white underscore).
I bisected it to commit ccfc08655 "drm: tweak getconnector locking".

Issuing a Sysrq+T showed that Xorg has the following call-trace:
> drm_modeset_lock+0x30/0xf0 [drm]
> intel_get_load_detect_pipe+0x8f/0x480 [i915]
> intel_crt_get_edid+0x63/0x90 [i915]
> intel_crt_detect_ddc+0x51/0xe0 [i915]
> intel_crt_detect_ddc+0x51/0xe0 [i915]
> intel_crt_detect+0x45e/0x8d0 [i915]
> drm_helper_probe_single_connector_modes_merge_bits+0x278/0x410 
> [drm_kms_helper]
> drm_helper_probe_single_connector_modes+0x17/0x20 [drm_kms_helper]
> drm_mode_getconnector+0x295/0x330 [drm]
> drm_mode_getcrtc+0xd0/0xd0 [drm]
> drm_ioctl+0x1ed/0x560 [drm]
> drm_mode_getcrtc+0xd0/0xd0 [drm]
> drm_getmap+0xc0/0xc0 [drm]

In the mentioned commit, drm_modeset_lock() has been moved (too?) up in
drm_mode_getconnector() hence connector->funcs->fill_modes() 
later calls drm_modeset_lock() too.

Should I provide more info ?

Marc.


Bug in uninorth-agp.c parsing of module parameter uninorth_agp.aperture

2015-02-15 Thread Jochen Rollwagen
Hi,

i found a bug in uninorth-agp.c, function uninorth_fetch_size.

the line

size  <http://lxr.free-electrons.com/ident?i=size>  =memparse  
<http://lxr.free-electrons.com/ident?i=memparse>(aperture  
<http://lxr.free-electrons.com/ident?i=aperture>, &aperture  
<http://lxr.free-electrons.com/ident?i=aperture>) >> 20;

always sets size to zero which makes the driver allocate the default size of 
256 MB which is obviously too large for older uninorth revisions.

I split the line into memparse and shifting and inserted diagnostic messages, 
output with uninorth_agp.aperture = 32 as boot parameter:

Feb 15 19:12:44 mac-mini kernel: [2.568636] agpgart-uninorth :00:0b.0: 
size in uninorth_fetch_size after memparse: 32
Feb 15 19:12:44 mac-mini kernel: [2.568642] agpgart-uninorth :00:0b.0: 
size after >> 20: 0

It would be nice if a patch could be produced so i can experiment with 
different aperture sizes without having to rebuild the kernel every time :-)

Cheers

Jochen
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150215/1072b103/attachment.html>


[PATCH] drm/udl: add enable/disable_vblank stubs

2015-02-15 Thread Aaron Plattner
vblank_disable_and_save calls the driver's disable_vblank hook unconditionally,
which crashes the udl driver since it doesn't implement it.  Fix this by adding
stub implementations of these functions identical to the qxl ones.

  usb 5-1: USB disconnect, device number 2
  BUG: unable to handle kernel NULL pointer dereference at   (null)
  IP: [<  (null)>]   (null)
  PGD 3bc23d067 PUD 3bc0fc067 PMD 0
  Oops: 0010 [#1] PREEMPT SMP
  Modules linked in: udlfb fb_sys_fops nvidia(PO) udl drm_kms_helper drm
 syscopyarea sysfillrect sysimgblt netconsole cfg80211
 joydev mousedev nls_iso8859_1 nls_cp437 vfat fat coretemp
 intel_rapl eeepc_wmi asus_wmi sparse_keymap led_class
 rfkill hwmon iosf_mbi x86_pkg_temp_thermal intel_powerclamp
 iTCO_wdt iTCO_vendor_support evdev kvm crct10dif_pclmul
 crc32_pclmul ghash_clmulni_intel aesni_intel mac_hid
 tpm_infineon aes_x86_64 lrw gf128mul e1000e glue_helper
 ablk_helper cryptd mxm_wmi tpm_tis processor psmouse ptp
 serio_raw tpm snd_hda_codec_hdmi i2c_i801 i2c_core lpc_ich
 pps_core pcspkr snd_hda_codec_realtek snd_hda_codec_generic
 mei_me mei snd_hda_intel snd_hda_controller snd_hda_codec
 snd_hwdep snd_pcm snd_timer snd ie31200_edac edac_core
 soundcore thermal shpchp battery video wmi button fan
 sch_fq_codel nfs lockd grace sunrpc fscache btrfs xor
 raid6_pq hid_generic usbhid hid sd_mod atkbd libps2 ahci
 libahci crc32c_intel xhci_pci libata ehci_pci xhci_hcd
 ehci_hcd scsi_mod usbcore usb_common i8042 serio [last
 unloaded: drm]
  CPU: 2 PID: 2044 Comm: Xorg.bin Tainted: P   O   3.19.0-1-agp #1
  Hardware name: System manufacturer System Product Name/P8Z77-V, BIOS 2104 
08/13/2013
  task: 8803f99d27c0 ti: 8803bc1c4000 task.ti: 8803bc1c4000
  RIP: 0010:[<>]  [<  (null)>]   (null)
  RSP: 0018:8803bc1c7d00  EFLAGS: 00010046
  RAX: a06d0140 RBX:  RCX: 
  RDX: cee6 RSI:  RDI: 8804037c3000
  RBP: 8803bc1c7d88 R08: 0047b69a R09: 
  R10: a06de187 R11: 3246 R12: 880403d74540
  R13: 0003 R14: 8804037c3000 R15: 8803bc32eac8
  FS:  7f7f4753a900() GS:88041ec8() knlGS:
  CS:  0010 DS:  ES:  CR0: 80050033
  CR2:  CR3: 0003bc24 CR4: 001407e0
  Stack:
   a06e06da 8803bc1c7d38  0082
   8804037c3188 8803bc1c7d40 0282 8803bc1c7d68
   0106 cee6 f69756fa 880403d74580
  Call Trace:
   [] ? vblank_disable_and_save+0x9a/0x200 [drm]
   [] drm_vblank_cleanup+0x65/0xb0 [drm]
   [] udl_driver_unload+0x18/0x50 [udl]
   [] drm_dev_unregister+0x2d/0xb0 [drm]
   [] drm_put_dev+0x27/0x70 [drm]
   [] drm_release+0x347/0x520 [drm]
   [] __fput+0x9f/0x200
   [] fput+0xe/0x10
   [] task_work_run+0xb7/0xf0
   [] do_notify_resume+0x95/0xa0
   [] int_signal+0x12/0x17
  Code:  Bad RIP value.
  RIP  [<  (null)>]   (null)
   RSP 
  CR2: 
  ---[ end trace e0b184ca053571af ]---

Reported-by: Thomas Meyer 
Link: http://lists.freedesktop.org/archives/dri-devel/2014-December/073652.html
Signed-off-by: Aaron Plattner 
---
Daniel, it looks like your change "[5/5] drm/irq: Don't call
 ->get_vblank_counter directly from irq_uninstall/cleanup" masks the immediate
problem, but it's not clear to me whether that's just because I didn't manage to
trigger any of the new vblank stuff, or whether your change really fixes it.  It
does seem like these vblank functions are intended to be called unconditionally.

 drivers/gpu/drm/udl/udl_drv.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index d5728ec85254..5bacb556b0f5 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -16,6 +16,20 @@ static int udl_driver_set_busid(struct drm_device *d, struct 
drm_master *m)
return 0;
 }

+static u32 udl_noop_get_vblank_counter(struct drm_device *dev, int crtc)
+{
+   return dev->vblank[crtc].count.counter;
+}
+
+static int udl_noop_enable_vblank(struct drm_device *dev, int crtc)
+{
+   return 0;
+}
+
+static void udl_noop_disable_vblank(struct drm_device *dev, int crtc)
+{
+}
+
 static const struct vm_operations_struct udl_gem_vm_ops = {
.fault = udl_gem_fault,
.open = drm_gem_vm_open,
@@ -42,6 +56,10 @@ static struct drm_driver driver = {
.unload = udl_driver_unload,
.set_busid = udl_driv

[PATCH 4/5] of: Add vendor prefix for Ortus Technology Co., Ltd.

2015-02-15 Thread Rob Herring
On Wed, Feb 11, 2015 at 11:50 AM, Philipp Zabel  
wrote:
> Add Ortus Technology Co., Ltd. to the list of device tree vendor prefixes.
>
> Signed-off-by: Philipp Zabel 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 1ca9ea1..a698268 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -121,6 +121,7 @@ nvidia  NVIDIA
>  nxpNXP Semiconductors
>  onnn   ON Semiconductor Corp.
>  opencores  OpenCores.org
> +ortustech  Ortus Technology Co., Ltd.
>  panasonic  Panasonic Corporation
>  parade Parade Technologies Inc.
>  pericomPericom Technology Inc.
> --
> 2.1.4
>


[Bug 89156] r300g: GL_COMPRESSED_RED_RGTC1 / ATI1N support broken

2015-02-15 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89156

Bug ID: 89156
   Summary: r300g: GL_COMPRESSED_RED_RGTC1 / ATI1N support broken
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r300
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: stefandoesinger at gmx.at
QA Contact: dri-devel at lists.freedesktop.org

r300g on r500 chips advertises GL_ARB_texture_compression_rgtc, but the
red-only format GL_COMPRESSED_RED_RGTC1 (aka ATI1N in ATI / d3d9 speak) is
broken. This breaks the d3d8 and d3d9 visual tests in Wine. It can also be seen
by running the rgtc-teximage-01 test in piglit.

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


[PATCH 1/5] drm/irq: Add drm_crtc_vblank_reset

2015-02-15 Thread Laurent Pinchart
Hi Daniel,

Thank you for the patch.

On Friday 13 February 2015 21:03:42 Daniel Vetter wrote:
> At driver load we need to tell the vblank code about the state of the
> pipes, so that the logic around reject vblank_get when the pipe is off
> works correctly.
> 
> Thus far i915 used drm_vblank_off, but one of the side-effects of it
> is that it also saves the vblank counter. And for that it calls down
> into the ->get_vblank_counter hook. Which isn't really a good idea
> when the pipe is off for a few reasons:
> - With runtime pm the register might not respond.
> - If the pipe is off some datastructures might not be around or
>   unitialized.
> 
> The later is what blew up on gen3: We look at intel_crtc->config to
> compute the vblank counter, and for a disabled pipe at boot-up that's
> just not there. Thus far this was papered over by a check for
> intel_crtc->active, but I want to get rid of that (since it's fairly
> race, vblank hooks are called from all kinds of places).
> 
> So prep for that by adding a _reset functions which only does what we
> really need to be done at driver load: Mark the vblank pipe as off,
> but don't do any vblank counter saving or event flushing - neither of
> that is required.
> 
> v2: Clarify the code flow slightly as suggested by Ville.
> 
> Cc: Ville Syrjälä 
> Cc: Laurent Pinchart 
> Cc: Imre Deak 
> Reviewed-by: Imre Deak 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_irq.c| 32 
>  drivers/gpu/drm/i915/intel_display.c |  6 +++---
>  include/drm/drmP.h   |  1 +
>  3 files changed, 36 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 75647e7f012b..1e5fb1b994d7 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1226,6 +1226,38 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc)
>  EXPORT_SYMBOL(drm_crtc_vblank_off);
> 
>  /**
> + * drm_crtc_vblank_reset - reset vblank state to off on a CRTC
> + * @crtc: CRTC in question
> + *
> + * Drivers can use this function to reset the vblank state to off at load
> time.
> + * Drivers should use this together with the drm_crtc_vblank_off() and
> + * drm_crtc_vblank_on() functions. The diffrence comparet to

s/diffrence comparet/difference compared/

With that fixed,

Acked-by: Laurent Pinchart 

> + * drm_crtc_vblank_off() is that this function doesn't save the vblank
> counter
> + * and hence doesn't need to call any driver hooks.
> + */
> +void drm_crtc_vblank_reset(struct drm_crtc *drm_crtc)
> +{
> + struct drm_device *dev = drm_crtc->dev;
> + unsigned long irqflags;
> + int crtc = drm_crtc_index(drm_crtc);
> + struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
> +
> + spin_lock_irqsave(&dev->vbl_lock, irqflags);
> + /*
> +  * Prevent subsequent drm_vblank_get() from enabling the vblank
> +  * interrupt by bumping the refcount.
> +  */
> + if (!vblank->inmodeset) {
> + atomic_inc(&vblank->refcount);
> + vblank->inmodeset = 1;
> + }
> + spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> +
> + WARN_ON(!list_empty(&dev->vblank_event_list));
> +}
> +EXPORT_SYMBOL(drm_crtc_vblank_reset);
> +
> +/**
>   * drm_vblank_on - enable vblank events on a CRTC
>   * @dev: DRM device
>   * @crtc: CRTC in question
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c index 423ef959264d..8dcf6b512236
> 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13294,11 +13294,11 @@ static void intel_sanitize_crtc(struct intel_crtc
> *crtc) I915_WRITE(reg, I915_READ(reg) & ~PIPECONF_FRAME_START_DELAY_MASK);
> 
>   /* restore vblank interrupts to correct state */
> + drm_crtc_vblank_reset(&crtc->base);
>   if (crtc->active) {
>   update_scanline_offset(crtc);
> - drm_vblank_on(dev, crtc->pipe);
> - } else
> - drm_vblank_off(dev, crtc->pipe);
> + drm_crtc_vblank_on(&crtc->base);
> + }
> 
>   /* We need to sanitize the plane -> pipe mapping first because this will
>* disable the crtc (and hence change the state) if it is wrong. Note
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index e928625a9da0..54c6ea1e5866 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -922,6 +922,7 @@ extern void drm_crtc_wait_one_vblank(struct drm_crtc
> *crtc); extern void drm_vblank_off(struct drm_device *dev, int crtc);
>  extern void drm_vblank_on(struct drm_device *dev, int crtc);
>  extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
> +extern void drm_crtc_vblank_reset(struct drm_crtc *crtc);
>  extern void drm_crtc_vblank_on(struct drm_crtc *crtc);
>  extern void drm_vblank_cleanup(struct drm_device *dev);

-- 
Regards,

Laurent Pinchart



[Bug 89155] Dual monitor setup does not initialize

2015-02-15 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89155

--- Comment #2 from Adam Reichold  ---
Maybe as a clarification: Both monitors always initialize properly when only
one is connected.

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


[Bug 89155] Dual monitor setup does not initialize

2015-02-15 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89155

--- Comment #1 from Adam Reichold  ---
Created attachment 113509
  --> https://bugs.freedesktop.org/attachment.cgi?id=113509&action=edit
journalctl -b | grep "\[drm"

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


[Bug 89155] Dual monitor setup does not initialize

2015-02-15 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89155

Bug ID: 89155
   Summary: Dual monitor setup does not initialize
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adam.reichold at t-online.de

Created attachment 113508
  --> https://bugs.freedesktop.org/attachment.cgi?id=113508&action=edit
journalctl -b | grep "\[drm"

I am running Arch Linux on an AMD A6-3500 with Radeon HD 6530D graphics on an
Gigabyte A55M-S2V mainboard. I just received updated X server to version 1.17.1
together with a rebuilt version 7.5.0 of the XFree86 ATI driver with the kernel
staying at 3.18.6.

I do have two Samsung monitors connected to the system, one via DVI and one via
VGA. This setup always initialized unreliably and I had to manually add modes
for the VGA-connected monitor using

xrandr --newmode "1680x1050_60.00"  146.25  1680 1784 1960 2240  1050 1053 1059
1089 -hsync +vsync
xrandr --addmode VGA-0 "1680x1050_60.00"
xrandr --output VGA-0 --mode "1680x1050_60.00"

for it to work at all. But after the update described above, the two monitors
never initialize properly anymore. Before the update, I sometimes had to
power-cycle (meaning switch off power not just a reboot) but it did eventually
work after two or three tries.

The reason I am reporting this as a Radeon DRM issue instead of an X server
problem is that my system log contains errors from the DRM driver about
"channel eq" and "clock recovery". I attached those logs grepped for "[drm".

Thank for your help and please tell me if I can provide any further information
to help diagnose this.

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


[Bug 89152] glBlitFramebuffer always "bad src/dst multisample pixel formats", when src fbo is multisample

2015-02-15 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89152

Bug ID: 89152
   Summary: glBlitFramebuffer always "bad src/dst multisample
pixel formats", when src fbo is multisample
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: osbios at web.de
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 113504
  --> https://bugs.freedesktop.org/attachment.cgi?id=113504&action=edit
simple sdl2 example

If I try to blit from a multisample fbo I always get:

GL_INVALID_OPERATION

or with KHR_debug callback:

GL_INVALID_OPERATION in glBlitFramebufferEXT(bad src/dst multisample pixel
formats)

This even happens when the target fbo has the same sample count.


glxinfo |grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.6.0-devel
(git-3f1e128 2015-02-13 trusty-oibaf-ppa)
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.6.0-devel (git-3f1e128 2015-02-13
trusty-oibaf-ppa)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.6.0-devel (git-3f1e128
2015-02-13 trusty-oibaf-ppa)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

uname -a
Linux c01 3.19.0 #1 SMP Sat Feb 14 23:33:44 CET 2015 x86_64 x86_64 x86_64
GNU/Linux

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


nouveau regression 3.19: unable to load BIOS from ACPI

2015-02-15 Thread Ortwin Glück
Hi Ben,

Since 3.19 the NV BIOS can no longer be loaded via ACPI. This breaks my HP 
laptop.
Looking at the recent changes (ad4a3626 split out shadow methods) in the bios 
shadow code, I think 
this happens:

- nvbios_shadow loops over all possible bios sources
- shadow_method
- shadow_score
- shadow_image tries to validate the image contents *before* loading it via 
ACPI calls
- nvbios_imagen calls nv_ro16 on the bios object which tries to read 16 bytes 
directly from memory.

Before the change, the code was:
-  mthd->shadow(bios);
-  which for ACPI calls nouveau_bios_shadow_acpi which doesn't try to validate 
the image
   mthd->score = nouveau_bios_score(bios, mthd->rw); which validates the image

So shadowing always happened *before* trying to look at the bios data.

The relevant log is below.

Ortwin

3.18:
Feb 15 11:28:50 localhost kernel: nouveau  [  DEVICE][:01:00.0] BOOT0  : 
0x0e63c0a1
Feb 15 11:28:50 localhost kernel: nouveau  [  DEVICE][:01:00.0] Chipset: 
GK106 (NVE6)
Feb 15 11:28:50 localhost kernel: nouveau  [  DEVICE][:01:00.0] Family : 
NVE0
Feb 15 11:28:50 localhost kernel: nouveau  [   VBIOS][:01:00.0] checking 
PRAMIN for image...
Feb 15 11:28:50 localhost kernel: nouveau  [   VBIOS][:01:00.0] ... 
signature not found
Feb 15 11:28:50 localhost kernel: nouveau  [   VBIOS][:01:00.0] checking 
PROM for image...
Feb 15 11:28:50 localhost kernel: fbcon: inteldrmfb (fb0) is primary device
Feb 15 11:28:50 localhost kernel: nouveau  [   VBIOS][:01:00.0] ... 
signature not found
Feb 15 11:28:50 localhost kernel: nouveau  [   VBIOS][:01:00.0] checking 
ACPI for image...
Feb 15 11:28:50 localhost kernel: Switched to clocksource tsc
Feb 15 11:28:50 localhost kernel: nouveau  [   VBIOS][:01:00.0] ... appears 
to be valid
Feb 15 11:28:50 localhost kernel: nouveau  [   VBIOS][:01:00.0] using image 
from ACPI
Feb 15 11:28:50 localhost kernel: nouveau  [   VBIOS][:01:00.0] BIT 
signature found


3.19:
Feb 15 11:30:40 localhost kernel: VGA switcheroo: detected Optimus DSM method 
\_SB_.PCI0.PEGP.DGFX 
handle
Feb 15 11:30:40 localhost kernel: nouveau :01:00.0: enabling device (0004 
-> 0007)
Feb 15 11:30:40 localhost kernel: nouveau  [  DEVICE][:01:00.0] BOOT0  : 
0x0e63c0a1
Feb 15 11:30:40 localhost kernel: nouveau  [  DEVICE][:01:00.0] Chipset: 
GK106 (NVE6)
Feb 15 11:30:40 localhost kernel: nouveau  [  DEVICE][:01:00.0] Family : 
NVE0
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] trying 
ACPI...
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] : 
type 00, 65536 bytes
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] : 
fetch failed
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] scored 0
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] trying 
ACPI...
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] : 
type 00, 65536 bytes
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] : 
fetch failed
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] scored 0
Feb 15 11:30:40 localhost kernel: nouveau E[   VBIOS][:01:00.0] ACPI invalid
Feb 15 11:30:40 localhost kernel: nouveau  [   VBIOS][:01:00.0] checking 
(null) for image...
Feb 15 11:30:40 localhost kernel: nouveau  [   VBIOS][:01:00.0] checking 
PRAMIN for image...
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] trying 
PRAMIN...
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] ... not 
enabled
Feb 15 11:30:40 localhost kernel: nouveau  [   VBIOS][:01:00.0] checking 
PROM for image...
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] trying 
PROM...
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] : 
ROM signature () 
unknown
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] image 0 
invalid
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] scored 0
Feb 15 11:30:40 localhost kernel: nouveau  [   VBIOS][:01:00.0] checking 
ACPI for image...
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] trying 
ACPI...
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] : 
type 00, 65536 bytes
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] : 
fetch failed
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] scored 0
Feb 15 11:30:40 localhost kernel: nouveau  [   VBIOS][:01:00.0] checking 
ACPI for image...
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] trying 
ACPI...
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] : 
type 00, 65536 bytes
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] : 
fetch failed
Feb 15 11:30:40 localhost kernel: nouveau D[   VBIOS][:01:00.0] scored 0
Feb 15 11:30:40 localhost kernel: nouveau  [   VBIOS][00

[PATCH] drm: panel: simple-panel add bus format information to edt_etm0700g0dh6 panel

2015-02-15 Thread Anthony Harivel
EDT's edt_etm0700g0dh6 supports RGB888 format.

Signed-off-by: Anthony Harivel 
---
 drivers/gpu/drm/panel/panel-simple.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 39806c3..cf902d6 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -568,6 +568,7 @@ static const struct panel_desc edt_etm0700g0dh6 = {
.width = 152,
.height = 91,
},
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };

 static const struct drm_display_mode foxlink_fl500wvr00_a0t_mode = {
-- 
1.9.1



[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!

2015-02-15 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=73378

--- Comment #34 from Chernovsky Oleg  ---
(In reply to Christian König from comment #32)

> Strange, the hardware docs say this is for routing the reset signal and
> shouldn't be touched by the driver, e.g. it should always be 1.

Is this some kind of open hardware docs? Or just internal? Maybe I missed
something

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


[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!

2015-02-15 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=73378

--- Comment #33 from Chernovsky Oleg  ---
Yep, I rechecked it and it seems set to 1 always...

Anyway I gathered around 18 Mb of mmiotrace logs to investigate. Now digging
through divider and clock registers.

P.S. I only fear that maybe I launched mmiotrace too late, I did rmmod and then
modprobe fglrx again. Could it setup any registers at the first run? Because at
second it touched UVD only when I launched mpv.

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


[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!

2015-02-15 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=73378

--- Comment #32 from Christian König  ---
(In reply to Chernovsky Oleg from comment #31)
> Tried to launch vdpau-accelerated mpv with fglrx driver and mmiotrace.
> Interesting, the CG_UPLL_FUNC_CNTL always has flags 0x100 | 0x600
> 
> R 4 456.556542 1 0xf634 0x707 0x0 0
> W 4 456.556547 1 0xf634 0x705 0x0 0
> R 4 456.556553 1 0xf634 0x705 0x0 0
> W 4 456.556576 1 0xf634 0x705 0x0 0
> R 4 456.556688 1 0xf634 0x705 0x0 0
> W 4 456.556693 1 0xf634 0x705 0x0 0
> R 4 456.556709 1 0xf634 0x705 0x0 0
> R 4 456.556725 1 0xf634 0x705 0x0 0
> W 4 456.556730 1 0xf634 0x705 0x0 0
> R 4 456.556771 1 0xf634 0x705 0x0 0
> W 4 456.556776 1 0xf634 0x704 0x0 0
> R 4 456.556837 1 0xf634 0x704 0x0 0
> W 4 456.556842 1 0xf634 0x700 0x0 0
> W 4 456.556847 1 0xf634 0x708 0x0 0
> 
> Any ideas what can 0x100 mask be for?

Strange, the hardware docs say this is for routing the reset signal and
shouldn't be touched by the driver, e.g. it should always be 1.

Is that bit 0 when you use the open source driver?

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


[PATCH 2/3] arm/dts/ls1021a: Add DCU dts node

2015-02-15 Thread jianwei.w...@freescale.com
My careless, I'll add "big―endia" to fsl,dcfb.txt next version.

发件人: Wood Scott-B07421
发送时间: 2015年2月14日 1:28:08
收件人: Wang Jianwei-B52261
抄送: dri-devel at lists.freedesktop.org; jbarnes at virtuousgeek.org; 
linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; Wang 
Huan-B18965; Xiubo Li
主题: Re: [PATCH 2/3] arm/dts/ls1021a: Add DCU dts node

On Fri, 2015-02-13 at 19:03 +0800, Jianwei Wang wrote:
> Add DCU node, DCU is a display controller of Freescale
> named 2D-ACE.
>
> Signed-off-by: Alison Wang 
> Signed-off-by: Xiubo Li 
> Signed-off-by: Jianwei Wang 
> ---
>  arch/arm/boot/dts/ls1021a.dtsi | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index c70bb27..28c37f1 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -383,6 +383,17 @@
><&platform_clk 1>;
>   };
>
> + dcfb: dcfb at 2ce {
> + compatible = "fsl,ls1021a-dcfb";
> + reg = <0x0 0x2ce 0x0 0x1>;
> + interrupts = ;
> + clocks = <&platform_clk 0>;
> + clock-names = "dcfb";
> + scfg-controller = <&scfg>;
> + big-endian;
> + status = "disabled";
> + };

I don't see "big-endian" in the dcfb binding.

-Scott



[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!

2015-02-15 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=73378

--- Comment #31 from Chernovsky Oleg  ---
Tried to launch vdpau-accelerated mpv with fglrx driver and mmiotrace.
Interesting, the CG_UPLL_FUNC_CNTL always has flags 0x100 | 0x600

R 4 456.556542 1 0xf634 0x707 0x0 0
W 4 456.556547 1 0xf634 0x705 0x0 0
R 4 456.556553 1 0xf634 0x705 0x0 0
W 4 456.556576 1 0xf634 0x705 0x0 0
R 4 456.556688 1 0xf634 0x705 0x0 0
W 4 456.556693 1 0xf634 0x705 0x0 0
R 4 456.556709 1 0xf634 0x705 0x0 0
R 4 456.556725 1 0xf634 0x705 0x0 0
W 4 456.556730 1 0xf634 0x705 0x0 0
R 4 456.556771 1 0xf634 0x705 0x0 0
W 4 456.556776 1 0xf634 0x704 0x0 0
R 4 456.556837 1 0xf634 0x704 0x0 0
W 4 456.556842 1 0xf634 0x700 0x0 0
W 4 456.556847 1 0xf634 0x708 0x0 0

Any ideas what can 0x100 mask be for?

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


[Bug 93281] Kernel modesetting causes the kernel to lock up during boot on a late 2011 MacBook Pro

2015-02-15 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=93281

--- Comment #8 from Alex Jordan  ---
I neglected to mention that I've also filed this bug downstream as Debian bug
#778441[1].

 [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778441

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 93281] Kernel modesetting causes the kernel to lock up during boot on a late 2011 MacBook Pro

2015-02-15 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=93281

Alex Jordan  changed:

   What|Removed |Added

 Attachment #166901|application/octet-stream|text/plain
  mime type||

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 93281] Kernel modesetting causes the kernel to lock up during boot on a late 2011 MacBook Pro

2015-02-15 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=93281

Alex Jordan  changed:

   What|Removed |Added

 Attachment #166891|application/octet-stream|text/plain
  mime type||

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 93281] Kernel modesetting causes the kernel to lock up during boot on a late 2011 MacBook Pro

2015-02-15 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=93281

Alex Jordan  changed:

   What|Removed |Added

 Attachment #166881|application/octet-stream|text/plain
  mime type||

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 93281] Kernel modesetting causes the kernel to lock up during boot on a late 2011 MacBook Pro

2015-02-15 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=93281

Alex Jordan  changed:

   What|Removed |Added

 Attachment #166871|application/octet-stream|text/plain
  mime type||

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 93281] Kernel modesetting causes the kernel to lock up during boot on a late 2011 MacBook Pro

2015-02-15 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=93281

Alex Jordan  changed:

   What|Removed |Added

 Attachment #166911|application/octet-stream|text/plain
  mime type||

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 93281] Kernel modesetting causes the kernel to lock up during boot on a late 2011 MacBook Pro

2015-02-15 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=93281

--- Comment #7 from Alex Jordan  ---
Created attachment 166921
  --> https://bugzilla.kernel.org/attachment.cgi?id=166921&action=edit
cat /var/log/Xorg.0.log

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 93281] Kernel modesetting causes the kernel to lock up during boot on a late 2011 MacBook Pro

2015-02-15 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=93281

--- Comment #6 from Alex Jordan  ---
Created attachment 166911
  --> https://bugzilla.kernel.org/attachment.cgi?id=166911&action=edit
cat /proc/modules

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 93281] Kernel modesetting causes the kernel to lock up during boot on a late 2011 MacBook Pro

2015-02-15 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=93281

--- Comment #5 from Alex Jordan  ---
Created attachment 166901
  --> https://bugzilla.kernel.org/attachment.cgi?id=166901&action=edit
cat /proc/ioports

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 93281] Kernel modesetting causes the kernel to lock up during boot on a late 2011 MacBook Pro

2015-02-15 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=93281

--- Comment #4 from Alex Jordan  ---
Created attachment 166891
  --> https://bugzilla.kernel.org/attachment.cgi?id=166891&action=edit
cat /proc/iomem

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 93281] Kernel modesetting causes the kernel to lock up during boot on a late 2011 MacBook Pro

2015-02-15 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=93281

--- Comment #3 from Alex Jordan  ---
Created attachment 166881
  --> https://bugzilla.kernel.org/attachment.cgi?id=166881&action=edit
cat /proc/cpuinfo

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 93281] Kernel modesetting causes the kernel to lock up during boot on a late 2011 MacBook Pro

2015-02-15 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=93281

--- Comment #2 from Alex Jordan  ---
Created attachment 166871
  --> https://bugzilla.kernel.org/attachment.cgi?id=166871&action=edit
sudo lspci -vvv

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 93281] Kernel modesetting causes the kernel to lock up during boot on a late 2011 MacBook Pro

2015-02-15 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=93281

--- Comment #1 from Alex Jordan  ---
Created attachment 166861
  --> https://bugzilla.kernel.org/attachment.cgi?id=166861&action=edit
Lower half of the screen during hang

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 93281] New: Kernel modesetting causes the kernel to lock up during boot on a late 2011 MacBook Pro

2015-02-15 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=93281

Bug ID: 93281
   Summary: Kernel modesetting causes the kernel to lock up during
boot on a late 2011 MacBook Pro
   Product: Drivers
   Version: 2.5
Kernel Version: 3.18
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: alex at strugee.net
Regression: No

Created attachment 166851
  --> https://bugzilla.kernel.org/attachment.cgi?id=166851&action=edit
Upper half of the screen during hang

I'm the owner of a 15-inch late 2011 MacBook Pro. If I boot the system in the
default setup, it completely hangs shortly after starting the X server (at
least, AFAICT). If I boot with "nomodeset" appended to the kernel parameters,
then the system boots fine. This has happened for a long time now, so it's not
a recent regression or anything. I'm on Debian Unstable, with an untainted
kernel installed from experimental.

I will attach all relevant logs. All logs are from a boot with "nomodeset"
appended. I'll also attach photos of the logs that appear on the screen at the
time of the hang. These photos are from a slightly different kernel, but the
symptoms are the same.

I'm comfortable applying patches and building the kernel from source.

$ uname -a
Linux caught-sigsegv 3.18.0-trunk-amd64 #1 SMP Debian 3.18.6-1~exp1
(2015-02-07) x86_64 GNU/Linux
$ cat /proc/sys/kernel/tainted
0

-- 
You are receiving this mail because:
You are watching the assignee of the bug.