Deadlock in Xorg after commit "drm: tweak getconnector locking"
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
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>, <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
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 =
[PATCH 4/5] of: Add vendor prefix for Ortus Technology Co., Ltd.
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
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
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 = >vblank[crtc];
> +
> + spin_lock_irqsave(>vbl_lock, irqflags);
> + /*
> + * Prevent subsequent drm_vblank_get() from enabling the vblank
> + * interrupt by bumping the refcount.
> + */
> + if (!vblank->inmodeset) {
> + atomic_inc(>refcount);
> + vblank->inmodeset = 1;
> + }
> + spin_unlock_irqrestore(>vbl_lock, irqflags);
> +
> + WARN_ON(!list_empty(>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(>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(>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
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
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=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
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=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
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=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
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 [
[PATCH] drm: panel: simple-panel add bus format information to edt_etm0700g0dh6 panel
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!
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!
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!
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
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 @@
><_clk 1>;
> };
>
> + dcfb: dcfb at 2ce {
> + compatible = "fsl,ls1021a-dcfb";
> + reg = <0x0 0x2ce 0x0 0x1>;
> + interrupts = ;
> + clocks = <_clk 0>;
> + clock-names = "dcfb";
> + scfg-controller = <>;
> + 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!
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
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
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
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
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
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
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
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=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
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=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
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=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
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=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
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=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
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=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
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=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
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=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.
