[PATCH] drm/debugfs: remove redundant info from gem_names
It's a relic of "drm: Convert proc files to seq_file and introduce debugfs", which wrongly converted DRM_INFO + sprintf to 2 seq_printfs. Signed-off-by: Marcin Slusarz Cc: Ben Gamari Cc: Eric Anholt --- drivers/gpu/drm/drm_info.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c index 8928edb..d498ec7 100644 --- a/drivers/gpu/drm/drm_info.c +++ b/drivers/gpu/drm/drm_info.c @@ -204,8 +204,6 @@ static int drm_gem_one_name_info(int id, void *ptr, void *data) struct drm_gem_object *obj = ptr; struct seq_file *m = data; - seq_printf(m, "name %d size %zd\n", obj->name, obj->size); - seq_printf(m, "%6d %8zd %7d %8d\n", obj->name, obj->size, atomic_read(&obj->handle_count), -- 1.7.12
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #25 from Serkan Hosca --- Created attachment 68655 --> https://bugs.freedesktop.org/attachment.cgi?id=68655&action=edit dmesg.3.7-rc1 with test patch -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121016/212992da/attachment-0001.html>
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #24 from Serkan Hosca --- (In reply to comment #23) > Created attachment 68623 [details] [review] > Test patch. > > VM is definitely enabled, otherwise you won't got that error in the first > place. > > Ok let's try to narrow down that bug a bit more, please apply the attached > test patch and see what happens. > > If the GPU hang vanished we indeed have a syncing issue, but not the PFP > sync. The patch resets the gpu constantly, even without X, with both linus git and agd5f drm-next-3.7 branch with mesa git. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121016/21ca0240/attachment.html>
linux-next: Tree for Oct 16 (readeon_legacy)
On Tue, Oct 16, 2012 at 4:05 PM, Randy Dunlap wrote: > On 10/15/2012 08:58 PM, Stephen Rothwell wrote: > >> Hi all, >> >> The merge window has closed, feel free to add new stuff again. >> >> Changes since 201201015: >> patch already sent to Dave: http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=cd23492af3d4401c02c48a4bebe5995c9498eac5 Alex > > > on x86_64: > > drivers/built-in.o: In function `radeon_asic_init': > (.text+0xd3c71): undefined reference to `radeon_legacy_set_backlight_level' > drivers/built-in.o:(.data+0x20490): undefined reference to > `radeon_legacy_set_backlight_level' > drivers/built-in.o:(.data+0x20498): undefined reference to > `radeon_legacy_get_backlight_level' > drivers/built-in.o:(.data+0x20710): undefined reference to > `radeon_legacy_set_backlight_level' > drivers/built-in.o:(.data+0x20718): undefined reference to > `radeon_legacy_get_backlight_level' > drivers/built-in.o:(.data+0x20990): undefined reference to > `radeon_legacy_set_backlight_level' > drivers/built-in.o:(.data+0x20998): undefined reference to > `radeon_legacy_get_backlight_level' > drivers/built-in.o:(.data+0x20c10): undefined reference to > `radeon_legacy_set_backlight_level' > drivers/built-in.o:(.data+0x20c18): undefined reference to > `radeon_legacy_get_backlight_level' > drivers/built-in.o:(.data+0x21110): undefined reference to > `radeon_legacy_set_backlight_level' > drivers/built-in.o:(.data+0x21118): undefined reference to > `radeon_legacy_get_backlight_level' > > > Full randconfig file is attached. > CONFIG_BACKLIGHT_CLASS_DEVICE is not enabled. > > -- > ~Randy > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[BUG] 3.7-rc1: nouveau: NULL pointer dereference at nouveau_channel_new
This is a regression towards 3.6. Occurs when starting X. I had already reported this before -rc1, but nobody listened. -- next part -- Oct 16 18:27:04 localhost kernel: Initializing cgroup subsys cpu Oct 16 18:27:04 localhost kernel: Linux version 3.7.0-rc1 (root at ortwin-hp) (gcc version 4.5.4 (Gentoo 4.5.4 p1.0, pie-0.4.7) ) #1 SMP PREEMPT Tue Oct 16 18:24:16 CEST 2012 Oct 16 18:27:04 localhost kernel: Command line: root=/dev/sda1 rootfstype=ext4 nouveau.noaccel=1 Oct 16 18:27:04 localhost kernel: e820: BIOS-provided physical RAM map: Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0x-0x0009fbff] usable Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0x0009fc00-0x0009] reserved Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0x000e-0x000f] reserved Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0x0010-0xbefc1fff] usable Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0xbefc2000-0xbf6c1fff] reserved Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0xbf6c2000-0xbf7c1fff] ACPI NVS Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0xbf7c2000-0xbf7fefff] ACPI data Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0xbf7ff000-0xbf7f] usable Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0xbf80-0xbfff] reserved Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0xe000-0xefff] reserved Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0xfec0-0xfec00fff] reserved Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0xfed1-0xfed13fff] reserved Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0xfed19000-0xfed19fff] reserved Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0xfed1b000-0xfed1] reserved Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0xfee0-0xfee00fff] reserved Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0xffd0-0x] reserved Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0x0001-0x0001fbff] usable Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0x0001fc00-0x0001] reserved Oct 16 18:27:04 localhost kernel: BIOS-e820: [mem 0x0002-0x00023bff] usable Oct 16 18:27:04 localhost kernel: NX (Execute Disable) protection: active Oct 16 18:27:04 localhost kernel: DMI 2.6 present. Oct 16 18:27:04 localhost kernel: DMI: Hewlett-Packard HP EliteBook 8540w/1521, BIOS 68CVD Ver. F.0E 11/25/2010 Oct 16 18:27:04 localhost kernel: e820: update [mem 0x-0x] usable ==> reserved Oct 16 18:27:04 localhost kernel: e820: remove [mem 0x000a-0x000f] usable Oct 16 18:27:04 localhost kernel: No AGP bridge found Oct 16 18:27:04 localhost kernel: e820: last_pfn = 0x23c000 max_arch_pfn = 0x4 Oct 16 18:27:04 localhost kernel: MTRR default type: uncachable Oct 16 18:27:04 localhost kernel: MTRR fixed ranges enabled: Oct 16 18:27:04 localhost kernel: 0-9 write-back Oct 16 18:27:04 localhost kernel: A-B uncachable Oct 16 18:27:04 localhost kernel: C-F write-protect Oct 16 18:27:04 localhost kernel: MTRR variable ranges enabled: Oct 16 18:27:04 localhost kernel: 0 base 0FFC0 mask FFFC0 write-protect Oct 16 18:27:04 localhost kernel: 1 base 0 mask F8000 write-back Oct 16 18:27:04 localhost kernel: 2 base 08000 mask FC000 write-back Oct 16 18:27:04 localhost kernel: 3 base 1 mask F write-back Oct 16 18:27:04 localhost kernel: 4 base 2 mask FC000 write-back Oct 16 18:27:04 localhost kernel: 5 base 23C00 mask FFC00 uncachable Oct 16 18:27:04 localhost kernel: 6 disabled Oct 16 18:27:04 localhost kernel: 7 disabled Oct 16 18:27:04 localhost kernel: x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 Oct 16 18:27:04 localhost kernel: e820: last_pfn = 0xbf800 max_arch_pfn = 0x4 Oct 16 18:27:04 localhost kernel: initial memory mapped: [mem 0x-0x1fff] Oct 16 18:27:04 localhost kernel: Base memory trampoline at [88099000] 99000 size 24576 Oct 16 18:27:04 localhost kernel: init_memory_mapping: [mem 0x-0xbf7f] Oct 16 18:27:04 localhost kernel: [mem 0x-0xbf7f] page 2M Oct 16 18:27:04 localhost kernel: kernel direct mapping tables up to 0xbf7f @ [mem 0x1fa0-0x1fff] Oct 16 18:27:04 localhost kernel: init_memory_mapping: [mem 0x1-0x23bff] Oct 16 18:27:04 localhost kernel: [mem 0x1-0x23bff] page 2M Oct 16 18:27:04 localhost kernel: kernel direct mapping tables up to 0x23bff @ [mem 0xbefb8000-0xbefc1fff] Oct 16 18:27:04 localhost kernel: ACPI: RSDP 000fddc0 00024 (v02 HPQOEM) Oct 16 18:27:04 localhost kernel: ACPI: XSDT bf7fe120 00094 (v01 HPQOEM SLIC-MPC
[Bug 56042] [865G] BadAlloc (insufficient resources for operation)
https://bugs.freedesktop.org/show_bug.cgi?id=56042 --- Comment #1 from G?tz --- Created attachment 68638 --> https://bugs.freedesktop.org/attachment.cgi?id=68638&action=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121016/2d389784/attachment.html>
[Bug 56042] New: [865G] BadAlloc (insufficient resources for operation)
https://bugs.freedesktop.org/show_bug.cgi?id=56042 Priority: medium Bug ID: 56042 Assignee: dri-devel at lists.freedesktop.org Summary: [865G] BadAlloc (insufficient resources for operation) Severity: normal Classification: Unclassified OS: Linux (All) Reporter: goetzchrist at yahoo.es Hardware: x86 (IA32) Status: NEW Version: 9.0 Component: Drivers/DRI/i830 Product: Mesa Created attachment 68637 --> https://bugs.freedesktop.org/attachment.cgi?id=68637&action=edit dmesg When I run glxinfo, or any 3D application, the app doesn't start, and I only get this error. With Mesa 8.0.4 there was no problem. $ glxinfo name of display: :0 X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 153 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Serial number of failed request: 22 Current serial number in output stream: 25 --- Linux 3.6.2 X Server 1.13.0 libdrm 2.4.39 xf86-video-intel 2.20.10 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) Subsystem: ASRock Incorporation Device 2572 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: [d0] Power Management version 1 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: i915 I don't know what information should I provide. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121016/47441ef5/attachment.html>
[PATCH 01/11] drm: add drm_send_vblank_event() helper (v5)
From: Rob Clark A helper that drivers can use to send vblank event after a pageflip. If the driver doesn't support proper vblank irq based time/seqn then just pass -1 for the pipe # to get do_gettimestamp() behavior (since there are a lot of drivers that don't use drm_vblank_count_and_time()) Also an internal send_vblank_event() helper for the various other code paths within drm_irq that also need to send vblank events. v1: original v2: add back 'vblwait->reply.sequence = seq' which should not have been deleted v3: add WARN_ON() in case lock is not held and comments v4: use WARN_ON_SMP() instead to fix issue with !SMP && !DEBUG_SPINLOCK as pointed out by Marcin Slusarz v5: update docbook Signed-off-by: Rob Clark --- Documentation/DocBook/drm.tmpl | 20 +++ drivers/gpu/drm/drm_irq.c | 74 include/drm/drmP.h |2 ++ 3 files changed, 59 insertions(+), 37 deletions(-) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index b030052..c9cbb3f 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -1141,23 +1141,13 @@ int max_width, max_height; the page_flip operation will be called with a non-NULL event argument pointing to a drm_pending_vblank_event instance. Upon page -flip completion the driver must fill the -event::event -sequence, tv_sec -and tv_usec fields with the associated -vertical blanking count and timestamp, add the event to the -drm_file list of events to be signaled, and wake -up any waiting process. This can be performed with +flip completion the driver must call drm_send_vblank_event +to fill in the event and send to wake up any waiting processes. +This can be performed with diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 076c4a8..9bdcfd5 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -802,6 +802,46 @@ u32 drm_vblank_count_and_time(struct drm_device *dev, int crtc, } EXPORT_SYMBOL(drm_vblank_count_and_time); +static void send_vblank_event(struct drm_device *dev, + struct drm_pending_vblank_event *e, + unsigned long seq, struct timeval *now) +{ + WARN_ON_SMP(!spin_is_locked(&dev->event_lock)); + e->event.sequence = seq; + e->event.tv_sec = now->tv_sec; + e->event.tv_usec = now->tv_usec; + + list_add_tail(&e->base.link, + &e->base.file_priv->event_list); + wake_up_interruptible(&e->base.file_priv->event_wait); + trace_drm_vblank_event_delivered(e->base.pid, e->pipe, +e->event.sequence); +} + +/** + * drm_send_vblank_event - helper to send vblank event after pageflip + * @dev: DRM device + * @crtc: CRTC in question + * @e: the event to send + * + * Updates sequence # and timestamp on event, and sends it to userspace. + * Caller must hold event lock. + */ +void drm_send_vblank_event(struct drm_device *dev, int crtc, + struct drm_pending_vblank_event *e) +{ + struct timeval now; + unsigned int seq; + if (crtc >= 0) { + seq = drm_vblank_count_and_time(dev, crtc, &now); + } else { + seq = 0; + do_gettimeofday(&now); + } + send_vblank_event(dev, e, seq, &now); +} +EXPORT_SYMBOL(drm_send_vblank_event); + /** * drm_update_vblank_count - update the master vblank counter * @dev: DRM device @@ -936,6 +976,13 @@ void drm_vblank_put(struct drm_device *dev, int crtc) } EXPORT_SYMBOL(drm_vblank_put); +/** + * drm_vblank_off - disable vblank events on a CRTC + * @dev: DRM device + * @crtc: CRTC in question + * + * Caller must hold event lock. + */ void drm_vblank_off(struct drm_device *dev, int crtc) { struct drm_pending_vblank_event *e, *t; @@ -955,15 +1002,9 @@ void drm_vblank_off(struct drm_device *dev, int crtc) DRM_DEBUG("Sending premature vblank event on disable: \ wanted %d, current %d\n", e->event.sequence, seq); - - e->event.sequence = seq; - e->event.tv_sec = now.tv_sec; - e->event.tv_usec = now.tv_usec; + list_del(&e->base.link); drm_vblank_put(dev, e->pipe); - list_move_tail(&e->base.link, &e->base.file_priv->event_list); - wake_up_interruptible(&e->base.file_priv->event_wait); - trace_drm_vblank_event_delivered(e->base.pid, e->pipe, -e->event.sequence); + send_vblank_event(dev, e, seq, &now); } spin_unlock_irqrestore(&dev->vbl_lock, irqflags); @@ -1107,15 +1148,9 @@ static int drm_queue_vblank_event(struct drm_device *dev, in
[Bug 48941] Error creating '/sys/class/backlight/radeon_bl' in radeon_atom_backlight_init()
https://bugzilla.kernel.org/show_bug.cgi?id=48941 --- Comment #1 from Igor Murzov 2012-10-17 00:35:56 --- Created an attachment (id=83701) --> (https://bugzilla.kernel.org/attachment.cgi?id=83701) lspci -vvv -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 48941] New: Error creating '/sys/class/backlight/radeon_bl' in radeon_atom_backlight_init()
https://bugzilla.kernel.org/show_bug.cgi?id=48941 Summary: Error creating '/sys/class/backlight/radeon_bl' in radeon_atom_backlight_init() Product: Drivers Version: 2.5 Kernel Version: 3.7.0-rc1 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: e-m...@date.by Regression: No Created an attachment (id=83691) --> (https://bugzilla.kernel.org/attachment.cgi?id=83691) dmesg There is an error in my dmesg: sysfs: cannot create duplicate filename '/class/backlight/radeon_bl' and there is no '/sys/class/backlight/radeon_bl' after system boot. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56038] New: "r100_ring_test] *ERROR*" messages sometimes on boot with ati radeon 9000 AGP ( r200 driver, dri2 KMS enabled )
https://bugs.freedesktop.org/show_bug.cgi?id=56038 Priority: medium Bug ID: 56038 Assignee: dri-devel at lists.freedesktop.org Summary: "r100_ring_test] *ERROR*" messages sometimes on boot with ati radeon 9000 AGP ( r200 driver, dri2 KMS enabled ) Severity: normal Classification: Unclassified OS: Linux (All) Reporter: mister.freeman at laposte.net Hardware: x86 (IA32) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 68625 --> https://bugs.freedesktop.org/attachment.cgi?id=68625&action=edit dmesg output randomly ( it's very rare, 90% of the time I don't have this error message ) I can see these error messages on boot : [1.516518] [drm] Loading R200 Microcode [1.517953] [drm] radeon: ring at 0xE0001000 [1.665941] [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) [1.665996] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). [1.666043] radeon :01:00.0: failed initializing CP (-22). [1.666084] radeon :01:00.0: Disabling GPU acceleration [1.812455] [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP. [1.812600] [drm] radeon: cp finalized [1.812629] [drm] radeon: cp finalized but the boot process continues and I see no problem on KDE4.9.2 and 3d games, this bug occurs since the update of ati-dri 9.0 and xorg packages 1.13 on my archlinux 32 bits installation, before that I had never seen this kind of error message my system : - archlinux 32 bits - laptop pentium 4 2.4 ghz 1,2 Gb ram - video card: ati radeon 9000 agp ( M9 rv250, r200 driver, dri2 enabled with kms early start ) - SIS645DX chipset on motherboard You can fin an attachment ( dmesg output ) with this message, this bug may related to another ( startx problems ) : https://bugs.freedesktop.org/show_bug.cgi?id=55982 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121016/4fcfff4e/attachment.html>
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #25 from Serkan Hosca --- Created attachment 68655 --> https://bugs.freedesktop.org/attachment.cgi?id=68655&action=edit dmesg.3.7-rc1 with test patch -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #24 from Serkan Hosca --- (In reply to comment #23) > Created attachment 68623 [details] [review] > Test patch. > > VM is definitely enabled, otherwise you won't got that error in the first > place. > > Ok let's try to narrow down that bug a bit more, please apply the attached > test patch and see what happens. > > If the GPU hang vanished we indeed have a syncing issue, but not the PFP > sync. The patch resets the gpu constantly, even without X, with both linus git and agd5f drm-next-3.7 branch with mesa git. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/11] drm: add drm_send_vblank_event() helper (v4)
Hi Rob, Thanks for the patch (0/11 looks a bit weird BTW). On Friday 12 October 2012 18:57:12 Rob Clark wrote: > From: Rob Clark > > A helper that drivers can use to send vblank event after a pageflip. > If the driver doesn't support proper vblank irq based time/seqn then > just pass -1 for the pipe # to get do_gettimestamp() behavior (since > there are a lot of drivers that don't use drm_vblank_count_and_time()) > > Also an internal send_vblank_event() helper for the various other code > paths within drm_irq that also need to send vblank events. > > v1: original > v2: add back 'vblwait->reply.sequence = seq' which should not have > been deleted > v3: add WARN_ON() in case lock is not held and comments > v4: use WARN_ON_SMP() instead to fix issue with !SMP && !DEBUG_SPINLOCK > as pointed out by Marcin Slusarz > > Signed-off-by: Rob Clark > --- > drivers/gpu/drm/drm_irq.c | 74 -- > include/drm/drmP.h|2 ++ Documentation/DocBook/drm.tmpl is missing ;-) > 2 files changed, 54 insertions(+), 22 deletions(-) I still wish we could have found a way to call drm_vblank_count_and_time() and do_gettimeofday() outside of the spinlock-protected region, but I won't complain. Apart from the missing documentation update the patch looks OK to me. -- Regards, Laurent Pinchart
[PATCH 01/11] drm: add drm_send_vblank_event() helper (v5)
From: Rob Clark A helper that drivers can use to send vblank event after a pageflip. If the driver doesn't support proper vblank irq based time/seqn then just pass -1 for the pipe # to get do_gettimestamp() behavior (since there are a lot of drivers that don't use drm_vblank_count_and_time()) Also an internal send_vblank_event() helper for the various other code paths within drm_irq that also need to send vblank events. v1: original v2: add back 'vblwait->reply.sequence = seq' which should not have been deleted v3: add WARN_ON() in case lock is not held and comments v4: use WARN_ON_SMP() instead to fix issue with !SMP && !DEBUG_SPINLOCK as pointed out by Marcin Slusarz v5: update docbook Signed-off-by: Rob Clark --- Documentation/DocBook/drm.tmpl | 20 +++ drivers/gpu/drm/drm_irq.c | 74 include/drm/drmP.h |2 ++ 3 files changed, 59 insertions(+), 37 deletions(-) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index b030052..c9cbb3f 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -1141,23 +1141,13 @@ int max_width, max_height; the page_flip operation will be called with a non-NULL event argument pointing to a drm_pending_vblank_event instance. Upon page -flip completion the driver must fill the -event::event -sequence, tv_sec -and tv_usec fields with the associated -vertical blanking count and timestamp, add the event to the -drm_file list of events to be signaled, and wake -up any waiting process. This can be performed with +flip completion the driver must call drm_send_vblank_event +to fill in the event and send to wake up any waiting processes. +This can be performed with diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 076c4a8..9bdcfd5 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -802,6 +802,46 @@ u32 drm_vblank_count_and_time(struct drm_device *dev, int crtc, } EXPORT_SYMBOL(drm_vblank_count_and_time); +static void send_vblank_event(struct drm_device *dev, + struct drm_pending_vblank_event *e, + unsigned long seq, struct timeval *now) +{ + WARN_ON_SMP(!spin_is_locked(&dev->event_lock)); + e->event.sequence = seq; + e->event.tv_sec = now->tv_sec; + e->event.tv_usec = now->tv_usec; + + list_add_tail(&e->base.link, + &e->base.file_priv->event_list); + wake_up_interruptible(&e->base.file_priv->event_wait); + trace_drm_vblank_event_delivered(e->base.pid, e->pipe, +e->event.sequence); +} + +/** + * drm_send_vblank_event - helper to send vblank event after pageflip + * @dev: DRM device + * @crtc: CRTC in question + * @e: the event to send + * + * Updates sequence # and timestamp on event, and sends it to userspace. + * Caller must hold event lock. + */ +void drm_send_vblank_event(struct drm_device *dev, int crtc, + struct drm_pending_vblank_event *e) +{ + struct timeval now; + unsigned int seq; + if (crtc >= 0) { + seq = drm_vblank_count_and_time(dev, crtc, &now); + } else { + seq = 0; + do_gettimeofday(&now); + } + send_vblank_event(dev, e, seq, &now); +} +EXPORT_SYMBOL(drm_send_vblank_event); + /** * drm_update_vblank_count - update the master vblank counter * @dev: DRM device @@ -936,6 +976,13 @@ void drm_vblank_put(struct drm_device *dev, int crtc) } EXPORT_SYMBOL(drm_vblank_put); +/** + * drm_vblank_off - disable vblank events on a CRTC + * @dev: DRM device + * @crtc: CRTC in question + * + * Caller must hold event lock. + */ void drm_vblank_off(struct drm_device *dev, int crtc) { struct drm_pending_vblank_event *e, *t; @@ -955,15 +1002,9 @@ void drm_vblank_off(struct drm_device *dev, int crtc) DRM_DEBUG("Sending premature vblank event on disable: \ wanted %d, current %d\n", e->event.sequence, seq); - - e->event.sequence = seq; - e->event.tv_sec = now.tv_sec; - e->event.tv_usec = now.tv_usec; + list_del(&e->base.link); drm_vblank_put(dev, e->pipe); - list_move_tail(&e->base.link, &e->base.file_priv->event_list); - wake_up_interruptible(&e->base.file_priv->event_wait); - trace_drm_vblank_event_delivered(e->base.pid, e->pipe, -e->event.sequence); + send_vblank_event(dev, e, seq, &now); } spin_unlock_irqrestore(&dev->vbl_lock, irqflags); @@ -1107,15 +1148,9 @@ static int drm_queue_vblank_event(struct drm_device *dev,
Re: linux-next: Tree for Oct 16 (readeon_legacy)
On Tue, Oct 16, 2012 at 4:05 PM, Randy Dunlap wrote: > On 10/15/2012 08:58 PM, Stephen Rothwell wrote: > >> Hi all, >> >> The merge window has closed, feel free to add new stuff again. >> >> Changes since 201201015: >> patch already sent to Dave: http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=cd23492af3d4401c02c48a4bebe5995c9498eac5 Alex > > > on x86_64: > > drivers/built-in.o: In function `radeon_asic_init': > (.text+0xd3c71): undefined reference to `radeon_legacy_set_backlight_level' > drivers/built-in.o:(.data+0x20490): undefined reference to > `radeon_legacy_set_backlight_level' > drivers/built-in.o:(.data+0x20498): undefined reference to > `radeon_legacy_get_backlight_level' > drivers/built-in.o:(.data+0x20710): undefined reference to > `radeon_legacy_set_backlight_level' > drivers/built-in.o:(.data+0x20718): undefined reference to > `radeon_legacy_get_backlight_level' > drivers/built-in.o:(.data+0x20990): undefined reference to > `radeon_legacy_set_backlight_level' > drivers/built-in.o:(.data+0x20998): undefined reference to > `radeon_legacy_get_backlight_level' > drivers/built-in.o:(.data+0x20c10): undefined reference to > `radeon_legacy_set_backlight_level' > drivers/built-in.o:(.data+0x20c18): undefined reference to > `radeon_legacy_get_backlight_level' > drivers/built-in.o:(.data+0x21110): undefined reference to > `radeon_legacy_set_backlight_level' > drivers/built-in.o:(.data+0x21118): undefined reference to > `radeon_legacy_get_backlight_level' > > > Full randconfig file is attached. > CONFIG_BACKLIGHT_CLASS_DEVICE is not enabled. > > -- > ~Randy > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] radeon: fix tile_split of 128-bit surface formats with 8x MSAA
In this specific case, the eg_surface_sanity function (or something like that, I don't remember its name) returns an error. Then the cascade of perfectly working fail codepaths propagate the error to the OpenGL user as an unsupported framebuffer object setup. Marek On Tue, Oct 16, 2012 at 8:50 AM, Paul Menzel wrote: > Dear Marek, > > > Am Dienstag, den 16.10.2012, 02:21 +0200 schrieb Marek Ol??k: >> The calculation led to the number 8192, which is too high. > > what is the reason it is limited to 4096? Hardware limitation? > > What are the ramifications? GPU hangs, rendering errors? > >> --- >> radeon/radeon_surface.c |2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c >> index 66c2444..eb587d2 100644 >> --- a/radeon/radeon_surface.c >> +++ b/radeon/radeon_surface.c >> @@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager >> *surf_man, >> } else { >> /* tile split must be >= 256 for colorbuffer surfaces */ >> surf->tile_split = MAX2(surf->nsamples * surf->bpe * 64, 256); >> +if (surf->tile_split > 4096) >> +surf->tile_split = 4096; >> } >> } else { >> /* set tile split to row size */ > > > Thanks, > > Paul
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #23 from Christian K?nig --- Created attachment 68623 --> https://bugs.freedesktop.org/attachment.cgi?id=68623&action=edit Test patch. VM is definitely enabled, otherwise you won't got that error in the first place. Ok let's try to narrow down that bug a bit more, please apply the attached test patch and see what happens. If the GPU hang vanished we indeed have a syncing issue, but not the PFP sync. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121016/7c032f32/attachment.html>
[PATCH 01/11] drm: add drm_send_vblank_event() helper
Hi Mario, On Saturday 13 October 2012 02:28:03 Mario Kleiner wrote: > On 11.10.12 16:19, Laurent Pinchart wrote: > > On Monday 08 October 2012 14:50:39 Rob Clark wrote: > >> From: Rob Clark > > ... > > > Do you know why some drivers don't call drm_vblank_count_and_time() ? For > > instance nouveau sets the sequence to 0 and uses do_gettimeofday(), but it > > looks like it could just call drm_vblank_count_and_time(). > > At least nouveau could use it. Lucas Stach and me wrote patches for > nouveau-kms, and they went through many iterations and missed many > kernel merge windows due to slow review until i think both of us got > tired of resubmitting with tiny changes. I totally understand the feeling, but please don't give up. You can CC me on the next iteration, I'll make sure to review the patches (even though I have no experience with the nouveau driver). > The latest iteration is posted by Lucas on nouveau-devel from 26. April > 2012. Not sure if they'd still apply after the nouveau-kms rewrite. I'll > probably give them another try once that has landed when i have some spare > time. > > In principle it's very simple to use drm_vblank_count_and_time(). A > driver needs to > > 1. Call drm_handle_vblank() from its vblank irq handler. > > 2. Make sure that in the vblank of pageflip completion > drm_handle_vblank() is called before drm_vblank_count_and_time(), so the > latter picks up updated counts and timestamps. > > 3. Big bonus for high precision and robustness: Implement the > driver->get_vblank_timestamp() hook to provide a precise vblank > timestamp. One simple way to do that is like radeon-kms or intel-kms do > it: Call back into drm_calc_vbltimestamp_from_scanoutpos() and provide > the driver->get_scanout_position() function - a function that returns > the current hardware scanline counter. This is precise down to ~ 10 > microseconds (at least confirmed by measurements on > intel,radeon,nouveau) and robust against delayed vblank irq handling. > > -mario -- Regards, Laurent Pinchart
[PATCH] drm/debugfs: remove redundant info from gem_names
It's a relic of "drm: Convert proc files to seq_file and introduce debugfs", which wrongly converted DRM_INFO + sprintf to 2 seq_printfs. Signed-off-by: Marcin Slusarz Cc: Ben Gamari Cc: Eric Anholt --- drivers/gpu/drm/drm_info.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c index 8928edb..d498ec7 100644 --- a/drivers/gpu/drm/drm_info.c +++ b/drivers/gpu/drm/drm_info.c @@ -204,8 +204,6 @@ static int drm_gem_one_name_info(int id, void *ptr, void *data) struct drm_gem_object *obj = ptr; struct seq_file *m = data; - seq_printf(m, "name %d size %zd\n", obj->name, obj->size); - seq_printf(m, "%6d %8zd %7d %8d\n", obj->name, obj->size, atomic_read(&obj->handle_count), -- 1.7.12 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[BUG 3.7-rc1] nouveau cli->mutex possible recursive locking detected
I have this lockdep warning on wireless-testing tree based on 3.7-rc1 (no other patches except wireless bits). = Restarting tasks ... done. [ INFO: possible recursive locking detected ] 3.7.0-rc1-wl+ #2 Not tainted - Xorg/2269 is trying to acquire lock: (&cli->mutex){+.+.+.}, at: [] nouveau_bo_move_m2mf+0x5f/0x170 [nouveau] but task is already holding lock: (&cli->mutex){+.+.+.}, at: [] nouveau_abi16_get+0x34/0x100 [nouveau] other info that might help us debug this: Possible unsafe locking scenario: CPU0 lock(&cli->mutex); lock(&cli->mutex); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by Xorg/2269: #0: (&cli->mutex){+.+.+.}, at: [] nouveau_abi16_get+0x34/0x100 [nouveau] stack backtrace: Pid: 2269, comm: Xorg Not tainted 3.7.0-rc1-wl+ #2 Call Trace: [] print_deadlock_bug+0xf4/0x100 [] validate_chain+0x549/0x7e0 [] __lock_acquire+0x367/0x580 [] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau] [] lock_acquire+0xa4/0x120 [] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau] [] ? _raw_spin_unlock_irqrestore+0x40/0x80 [] __mutex_lock_common+0x47/0x3f0 [] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau] [] ? nv84_graph_tlb_flush+0x291/0x2b0 [nouveau] [] ? _nouveau_gpuobj_wr32+0x26/0x30 [nouveau] [] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau] [] mutex_lock_nested+0x37/0x50 [] nouveau_bo_move_m2mf+0x5f/0x170 [nouveau] [] nouveau_bo_move+0xe3/0x330 [nouveau] [] ttm_bo_handle_move_mem+0x2bd/0x670 [ttm] [] ttm_bo_move_buffer+0x12e/0x150 [ttm] [] ttm_bo_validate+0x99/0x130 [ttm] [] nouveau_bo_validate+0x23/0x30 [nouveau] [] validate_list+0xae/0x2c0 [nouveau] [] nouveau_gem_pushbuf_validate+0xa2/0x1e0 [nouveau] [] nouveau_gem_ioctl_pushbuf+0x22c/0x8a0 [nouveau] [] drm_ioctl+0x355/0x570 [drm] [] ? do_sync_read+0xaa/0xf0 [] ? nouveau_gem_pushbuf_validate+0x1e0/0x1e0 [nouveau] [] do_vfs_ioctl+0x8c/0x350 [] ? sysret_check+0x22/0x5d [] sys_ioctl+0xa1/0xb0 [] ? trace_hardirqs_on_thunk+0x3a/0x3f [] system_call_fastpath+0x16/0x1b
[PATCH 1/2] uapi: update includes for drm content when no kernel API exists
Hi Luis, On Saturday 13 October 2012 10:00:42 Luis R. Rodriguez wrote: > On Sat, Oct 13, 2012 at 3:33 AM, Laurent Pinchart wrote: > > On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote: > >> From: "Luis R. Rodriguez" > >> > >> The UAPI changes split kernel API and userspace API > >> content onto two separate header files. The userspace > >> API drm content was moved to include/uapi/drm/ with the > >> same file name while kernel specific API content was > >> kept under include/drm/ with the same file name. When > >> one file was split into two files the kernel header > >> includes the uapi header and a UAPI prefix was added to > >> the uapi header for its header guard. When there was no > >> kernel API content found the uapi header file was the > >> only one that was kept and the original guard for the > >> header file was kept. In this particular case the > >> original users of this header file were not modified > >> and the uapi header file is expected to be picked up > >> by path. > >> > >> This may work well at compilation on the kernel but when > >> backporting this creates a few complexities. > > > > Could you please provide more details about those complexities ? > > Sure, the backported DRM code is as-is code from linux-next. The > header search path includes a copy of a few select header files from > linux-next, the rest are part of the compat [0] project to help with > backporting and the last set are from your own kernel. In this > particular case the UAPI effort pushed into include/uapi/drm a few > files which are now no longer present in the old include/drm/ location > when there was no respective kernel-only APIs exposed. For DRM code > that did not use the new uapi/drm/ path for old header includes this > means that upon backporting the older kernel's header file would be > used obviously leading to a series of compilation failures. By being > explicit about the path, as was done with a few other header files, we > can suck out DRM code intact from the kernel to be compilable for > older kernels. As of the v3.7-rc1 the compat-drivers project [1] will > be providing DRM modules. The new UAPI changes broke compilation on > compat-drivers when compiling DRM code so to fix this we either patch > code taken from the Linux kernel as I have done, force inclusion of a > few specific headers files, or use include_next tricks. It turns out > that forcing inclusion of -I$(M)/include/uapi as a path search prior > to your own kernel's at compilation time did not help. Shouldn't that be added as a search path *after* include/linux/ instead of before ? > The include_next trick can work as well but that'd mean synching the UAPI > files regularly into compat. I'd much prefer to have code intact when > possible when backporting so the option I stuck with then was to patch > the code directly and then as part of compat-drivers to always copy > that day's linux-next UAPI headers into the current directory for > compilation. I see no other driver code using the uapi path explicitly > though, is that by design? As far as I understand that's by design, yes. Kernel code isn't expected to reference uapi/ headers directly. > Would it be wrong to be explicit about using a UAPI header alone if no > kernel API files exist? I personally don't really like including such "features" in a mainline just for backporting, especially when they go against the spirit of the architecture (the uapi/ split design principles in this case). The way we're dealing with this in the V4L backport tree (http://git.linuxtv.org/media_build.git) is to play with Makefiles, include compatibility headers and, if nothing else can work, maintain backport patches for mainline code. > [0] https://backports.wiki.kernel.org/index.php/Documentation/compat > [1] https://backports.wiki.kernel.org/ -- Regards, Laurent Pinchart
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Oct 10, 2012 at 11:57:15PM -0700, Hans Verkuil wrote: > On Wed October 10 2012 23:02:06 Rob Clark wrote: > > On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox wrote: > > > On Wed, 10 Oct 2012 08:56:32 -0700 > > > Robert Morell wrote: > > > > > >> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation > > >> issue, and not really an interface". The dma-buf infrastructure is > > >> explicitly intended as an interface between modules/drivers, so it > > >> should use EXPORT_SYMBOL instead. > > > > > > NAK. This needs at the very least the approval of all rights holders for > > > the files concerned and all code exposed by this change. > > > > Well, for my contributions to dmabuf, I don't object.. and I think > > because we are planning to use dma-buf in userspace for dri3 / > > dri-next, I think that basically makes it a userspace facing kernel > > infrastructure which would be required for open and proprietary > > drivers alike. So I don't see much alternative to making this > > EXPORT_SYMBOL(). Of course, IANAL. > > The whole purpose of this API is to let DRM and V4L drivers share buffers for > zero-copy pipelines. Unfortunately it is a fact that several popular DRM > drivers > are closed source. So we have a choice between keeping the export symbols GPL > and forcing those closed-source drivers to make their own incompatible API, > thus defeating the whole point of DMABUF, or using EXPORT_SYMBOL and letting > the closed source vendors worry about the legality. They are already using > such > functions (at least nvidia is), so they clearly accept that risk. > > I prefer the evil where the DMABUF API uses EXPORT_SYMBOL to prevent the worse > evil where an incompatible API is created to work around the EXPORT_SYMBOL_GPL > limitation. Neither situation is paradise, but at least one is a slightly less > depressing world than the other :-) > > In other words, I'm OK with EXPORT_SYMBOL for whatever it is worth as I did > not > do any coding but only some initial design help and reviewing. Thanks for the discussion. My intention is not to steal any code from the kernel or change any licenses. The goal here is to allow interoperation between drivers. I understand that it can be difficult to debug the kernel when the nvidia binary module is loaded; I'm not trying to force anyone to do that. You're free to continue to use your debug environment without change after this patch is applied. I believe that the developers and maintainers of dma-buf have provided the needed signoff, both in person and in this thread. If there are any objections from that group, I'm happy to discuss any changes necessary to get this merged. - Robert ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Oct 10, 2012 at 11:57:15PM -0700, Hans Verkuil wrote: > On Wed October 10 2012 23:02:06 Rob Clark wrote: > > On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox > > wrote: > > > On Wed, 10 Oct 2012 08:56:32 -0700 > > > Robert Morell wrote: > > > > > >> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation > > >> issue, and not really an interface". The dma-buf infrastructure is > > >> explicitly intended as an interface between modules/drivers, so it > > >> should use EXPORT_SYMBOL instead. > > > > > > NAK. This needs at the very least the approval of all rights holders for > > > the files concerned and all code exposed by this change. > > > > Well, for my contributions to dmabuf, I don't object.. and I think > > because we are planning to use dma-buf in userspace for dri3 / > > dri-next, I think that basically makes it a userspace facing kernel > > infrastructure which would be required for open and proprietary > > drivers alike. So I don't see much alternative to making this > > EXPORT_SYMBOL(). Of course, IANAL. > > The whole purpose of this API is to let DRM and V4L drivers share buffers for > zero-copy pipelines. Unfortunately it is a fact that several popular DRM > drivers > are closed source. So we have a choice between keeping the export symbols GPL > and forcing those closed-source drivers to make their own incompatible API, > thus defeating the whole point of DMABUF, or using EXPORT_SYMBOL and letting > the closed source vendors worry about the legality. They are already using > such > functions (at least nvidia is), so they clearly accept that risk. > > I prefer the evil where the DMABUF API uses EXPORT_SYMBOL to prevent the worse > evil where an incompatible API is created to work around the EXPORT_SYMBOL_GPL > limitation. Neither situation is paradise, but at least one is a slightly less > depressing world than the other :-) > > In other words, I'm OK with EXPORT_SYMBOL for whatever it is worth as I did > not > do any coding but only some initial design help and reviewing. Thanks for the discussion. My intention is not to steal any code from the kernel or change any licenses. The goal here is to allow interoperation between drivers. I understand that it can be difficult to debug the kernel when the nvidia binary module is loaded; I'm not trying to force anyone to do that. You're free to continue to use your debug environment without change after this patch is applied. I believe that the developers and maintainers of dma-buf have provided the needed signoff, both in person and in this thread. If there are any objections from that group, I'm happy to discuss any changes necessary to get this merged. - Robert
[PATCHv10 23/26] v4l: vb2-dma-contig: align buffer size to PAGE_SIZE
Hi Tomasz, On Friday 12 October 2012 10:24:34 Tomasz Stanislawski wrote: > On 10/11/2012 11:31 PM, Laurent Pinchart wrote: > > On Wednesday 10 October 2012 16:46:42 Tomasz Stanislawski wrote: > >> Most operations on DMA and DMABUF framework need page > >> aligned buffers. > > > > The comment is a bit misleading, the buffer is already page-aligned > > (unless I'm mistaken dma_alloc_coherent() returns a page-aligned buffer) > > but its size isn't a multiple of the page size. > > Ok. I will update the commit message that only buffer size is going to be > page aligned. > > > Do we really need a page size multiple ? Isn't it enough to make the size > > a multiple of the cache line size ? > > Frankly, I strongly oppose forcing a size of a DMA buffer to be rounded up. > > However, I discovered a problem while testing mmap() interface in dma-buf. > The test in dma_buf_mmap() will fail if the size is not a multiple of 4k. > > Maybe the value from dma-buf.c:456 should be changed from: > > dmabuf->size >> PAGE_SHIFT > > to > > PAGE_ALIGN(dmabuf->size) >> PAGE_SHIFT > > However, I preferred to avoid any changes outside of the media tree hoping > that the patchset gets merged. Rounding the buffer size to a page size was > quick workaround for the issue with DMABUF mmap(). After some more thoughts I'm not sure whether this patch does the right thing. We have two sizes that we neeed to care about, the user usable buffer size and the allocated memory size. When a user of a buffer requests buffer allocation with an explicit or implicit size we might need to allocate a larger buffer to fulfill usage requirements. We can thus end up with an allocated memory size larger than what the user requested. Such usage requirements include - DMA and CPU access: when accessing the buffer both through DMA and directly by the CPU cache management comes into play, and the buffer address and size then need to be aligned to a cache line size boundary. - Mapping to userspace: we can only map complete pages to userspace, the buffer address and size need to be aligned to a page size boundary to make sure that we won't leak unrelated data to userspace. As the cache line size is smaller than a page fulfilling the second requirement always fulfills the first. There might be other requirements that escape my mind right now. As we don't precisely know at allocation time how the buffer will be used (for instance whether it will eventually be mapped to userspace or not), we have two options: - Align the buffer size to a page size boundary unconditionally. - Let the user handle that requirement by specifying an allocation size aligned to a page size boundary. Given the complexity associated with the second solution and the very small, if not inexistent, expected memory gain (when using the DMA allocation APIs we always get complete pages anyway, so there would be no gain in not aligning the allocation size to a page size boundary), I think the first solution should be preferred. This leaves us with two questions related to buffer size: what size (between the requested size and the actually allocated size) do we report back to the user (in the v4l2_buffer length field for instance), and what size do we report to the dma-buf core (and thus to the other subsystems and other buffer users) ? -- Regards, Laurent Pinchart
linux-next: Tree for Oct 16 (readeon_legacy)
On 10/15/2012 08:58 PM, Stephen Rothwell wrote: > Hi all, > > The merge window has closed, feel free to add new stuff again. > > Changes since 201201015: > on x86_64: drivers/built-in.o: In function `radeon_asic_init': (.text+0xd3c71): undefined reference to `radeon_legacy_set_backlight_level' drivers/built-in.o:(.data+0x20490): undefined reference to `radeon_legacy_set_backlight_level' drivers/built-in.o:(.data+0x20498): undefined reference to `radeon_legacy_get_backlight_level' drivers/built-in.o:(.data+0x20710): undefined reference to `radeon_legacy_set_backlight_level' drivers/built-in.o:(.data+0x20718): undefined reference to `radeon_legacy_get_backlight_level' drivers/built-in.o:(.data+0x20990): undefined reference to `radeon_legacy_set_backlight_level' drivers/built-in.o:(.data+0x20998): undefined reference to `radeon_legacy_get_backlight_level' drivers/built-in.o:(.data+0x20c10): undefined reference to `radeon_legacy_set_backlight_level' drivers/built-in.o:(.data+0x20c18): undefined reference to `radeon_legacy_get_backlight_level' drivers/built-in.o:(.data+0x21110): undefined reference to `radeon_legacy_set_backlight_level' drivers/built-in.o:(.data+0x21118): undefined reference to `radeon_legacy_get_backlight_level' Full randconfig file is attached. CONFIG_BACKLIGHT_CLASS_DEVICE is not enabled. -- ~Randy -- next part -- An embedded and charset-unspecified text was scrubbed... Name: config-r8139 URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121016/60d43107/attachment-0001.ksh>
[PATCH] drm/radeon: add some new SI PCI ids
From: Alex Deucher Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- include/drm/drm_pciids.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h index c78bb99..af1cbaf 100644 --- a/include/drm/drm_pciids.h +++ b/include/drm/drm_pciids.h @@ -205,6 +205,8 @@ {0x1002, 0x6788, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ {0x1002, 0x678A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6790, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ + {0x1002, 0x6791, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ + {0x1002, 0x6792, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6798, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6799, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ {0x1002, 0x679A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ @@ -217,6 +219,7 @@ {0x1002, 0x6808, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6809, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6810, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \ + {0x1002, 0x6811, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6816, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6817, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6818, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \ -- 1.7.7.5
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #16 from Helge Bahmann --- (In reply to comment #15) > A patch referencing this bug report has been merged in Linux v3.7-rc1: > > commit bced76f27165ca7733437715185c3a1aa526f7a1 > Author: Alex Deucher > Date: Fri Sep 14 09:45:50 2012 -0400 > > drm/radeon: restore backlight level on resume appears to be the same patch as mentioned in comment #10, and (at least for me) still does not fix the issue -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121016/135fffc3/attachment-0001.html>
[Bug 56042] [865G] BadAlloc (insufficient resources for operation)
https://bugs.freedesktop.org/show_bug.cgi?id=56042 --- Comment #1 from Götz --- Created attachment 68638 --> https://bugs.freedesktop.org/attachment.cgi?id=68638&action=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56042] New: [865G] BadAlloc (insufficient resources for operation)
https://bugs.freedesktop.org/show_bug.cgi?id=56042 Priority: medium Bug ID: 56042 Assignee: dri-devel@lists.freedesktop.org Summary: [865G] BadAlloc (insufficient resources for operation) Severity: normal Classification: Unclassified OS: Linux (All) Reporter: goetzchr...@yahoo.es Hardware: x86 (IA32) Status: NEW Version: 9.0 Component: Drivers/DRI/i830 Product: Mesa Created attachment 68637 --> https://bugs.freedesktop.org/attachment.cgi?id=68637&action=edit dmesg When I run glxinfo, or any 3D application, the app doesn't start, and I only get this error. With Mesa 8.0.4 there was no problem. $ glxinfo name of display: :0 X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 153 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Serial number of failed request: 22 Current serial number in output stream: 25 --- Linux 3.6.2 X Server 1.13.0 libdrm 2.4.39 xf86-video-intel 2.20.10 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) Subsystem: ASRock Incorporation Device 2572 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: [d0] Power Management version 1 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: i915 I don't know what information should I provide. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix PFP sync in vm_flush
Otherwise the next IB might start reading commands with the page table still invalid. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/ni.c |4 drivers/gpu/drm/radeon/nid.h |1 + drivers/gpu/drm/radeon/si.c |4 3 files changed, 9 insertions(+) diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c index 8c74c72..19b7fe1 100644 --- a/drivers/gpu/drm/radeon/ni.c +++ b/drivers/gpu/drm/radeon/ni.c @@ -1586,4 +1586,8 @@ void cayman_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm *vm) /* bits 0-7 are the VM contexts0-7 */ radeon_ring_write(ring, PACKET0(VM_INVALIDATE_REQUEST, 0)); radeon_ring_write(ring, 1 << vm->id); + + /* sync PFP to ME, otherwise we might get invalid PFP reads */ + radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0)); + radeon_ring_write(ring, 0x0); } diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h index 2423d1b..cbef681 100644 --- a/drivers/gpu/drm/radeon/nid.h +++ b/drivers/gpu/drm/radeon/nid.h @@ -502,6 +502,7 @@ #definePACKET3_MPEG_INDEX 0x3A #definePACKET3_WAIT_REG_MEM0x3C #definePACKET3_MEM_WRITE 0x3D +#definePACKET3_PFP_SYNC_ME 0x42 #definePACKET3_SURFACE_SYNC0x43 # define PACKET3_CB0_DEST_BASE_ENA(1 << 6) # define PACKET3_CB1_DEST_BASE_ENA(1 << 7) diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c index df8dd77..da184de 100644 --- a/drivers/gpu/drm/radeon/si.c +++ b/drivers/gpu/drm/radeon/si.c @@ -2868,6 +2868,10 @@ void si_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm *vm) radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2); radeon_ring_write(ring, 0); radeon_ring_write(ring, 1 << vm->id); + + /* sync PFP to ME, otherwise we might get invalid PFP reads */ + radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0)); + radeon_ring_write(ring, 0x0); } /* -- 1.7.9.5
[PATCH 0/11] drm: add drm_send_vblank_event() helper (v4)
On Tue, Oct 16, 2012 at 9:14 AM, Laurent Pinchart wrote: > Hi Rob, > > Thanks for the patch (0/11 looks a bit weird BTW). opps, that was *supposed* to be 01/11 :-P > > On Friday 12 October 2012 18:57:12 Rob Clark wrote: >> From: Rob Clark >> >> A helper that drivers can use to send vblank event after a pageflip. >> If the driver doesn't support proper vblank irq based time/seqn then >> just pass -1 for the pipe # to get do_gettimestamp() behavior (since >> there are a lot of drivers that don't use drm_vblank_count_and_time()) >> >> Also an internal send_vblank_event() helper for the various other code >> paths within drm_irq that also need to send vblank events. >> >> v1: original >> v2: add back 'vblwait->reply.sequence = seq' which should not have >> been deleted >> v3: add WARN_ON() in case lock is not held and comments >> v4: use WARN_ON_SMP() instead to fix issue with !SMP && !DEBUG_SPINLOCK >> as pointed out by Marcin Slusarz >> >> Signed-off-by: Rob Clark >> --- >> drivers/gpu/drm/drm_irq.c | 74 -- >> include/drm/drmP.h|2 ++ > > Documentation/DocBook/drm.tmpl is missing ;-) yeah, I just noticed that the docbook already has a section on pageflip.. I'll send a separate patch for this. BR, -R > >> 2 files changed, 54 insertions(+), 22 deletions(-) > > I still wish we could have found a way to call drm_vblank_count_and_time() and > do_gettimeofday() outside of the spinlock-protected region, but I won't > complain. Apart from the missing documentation update the patch looks OK to > me. > > -- > Regards, > > Laurent Pinchart > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56038] New: "r100_ring_test] *ERROR*" messages sometimes on boot with ati radeon 9000 AGP ( r200 driver, dri2 KMS enabled )
https://bugs.freedesktop.org/show_bug.cgi?id=56038 Priority: medium Bug ID: 56038 Assignee: dri-devel@lists.freedesktop.org Summary: "r100_ring_test] *ERROR*" messages sometimes on boot with ati radeon 9000 AGP ( r200 driver, dri2 KMS enabled ) Severity: normal Classification: Unclassified OS: Linux (All) Reporter: mister.free...@laposte.net Hardware: x86 (IA32) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 68625 --> https://bugs.freedesktop.org/attachment.cgi?id=68625&action=edit dmesg output randomly ( it's very rare, 90% of the time I don't have this error message ) I can see these error messages on boot : [1.516518] [drm] Loading R200 Microcode [1.517953] [drm] radeon: ring at 0xE0001000 [1.665941] [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) [1.665996] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). [1.666043] radeon :01:00.0: failed initializing CP (-22). [1.666084] radeon :01:00.0: Disabling GPU acceleration [1.812455] [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP. [1.812600] [drm] radeon: cp finalized [1.812629] [drm] radeon: cp finalized but the boot process continues and I see no problem on KDE4.9.2 and 3d games, this bug occurs since the update of ati-dri 9.0 and xorg packages 1.13 on my archlinux 32 bits installation, before that I had never seen this kind of error message my system : - archlinux 32 bits - laptop pentium 4 2.4 ghz 1,2 Gb ram - video card: ati radeon 9000 agp ( M9 rv250, r200 driver, dri2 enabled with kms early start ) - SIS645DX chipset on motherboard You can fin an attachment ( dmesg output ) with this message, this bug may related to another ( startx problems ) : https://bugs.freedesktop.org/show_bug.cgi?id=55982 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: add some new SI PCI ids
From: Alex Deucher Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org --- include/drm/drm_pciids.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h index c78bb99..af1cbaf 100644 --- a/include/drm/drm_pciids.h +++ b/include/drm/drm_pciids.h @@ -205,6 +205,8 @@ {0x1002, 0x6788, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ {0x1002, 0x678A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6790, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ + {0x1002, 0x6791, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ + {0x1002, 0x6792, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6798, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6799, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ {0x1002, 0x679A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI|RADEON_NEW_MEMMAP}, \ @@ -217,6 +219,7 @@ {0x1002, 0x6808, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6809, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6810, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \ + {0x1002, 0x6811, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6816, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6817, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6818, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PITCAIRN|RADEON_NEW_MEMMAP}, \ -- 1.7.7.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] add exynos-drm platform device registration to driver
Applied. Thanks, Inki Dae 2012/10/16 Rahul Sharma : > This patch adds drm-exynos and drm-exynos-hdmi device registration to the > drm driver. It was happening in machine init code earlier which is not > acceptable for dt enabled platforms. > > Patch which cleans the respective code from arch/arm is "arm: exynos: > removing exynos-drm device registration from non-dt platforms" is posted > to linux-samsung-soc mailing list. > > This patchset is based on branch exynos-drm-next at > git://git.infradead.org/users/kmpark/linux-samsung (linux v3.6-rc4) > > v1: > - moved exynos_drm_hdmi_pdev to drm hdmi layer > - added exynos_platform_device_hdmi_register interface > > v2: > - moved register/unregister hdmi device function declarations to > exynos_drm_drv.h > > Rahul Sharma (2): > drm: exynos: moved exynos drm device registration to drm driver > drm: exynos: moved exynos drm hdmi device registration to drm driver > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 25 - > drivers/gpu/drm/exynos/exynos_drm_drv.h | 11 +++ > drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 22 ++ > 3 files changed, 57 insertions(+), 1 deletions(-) > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:drm-intel-next-queued 42/44] drivers/gpu/drm/i915/intel_pm.c:2506:2: error: 'ret' undeclared
On Tue, Oct 16, 2012 at 08:59:51AM +0800, Fengguang Wu wrote: > Hi Ben, > > FYI, kernel build failed on > > tree: git://people.freedesktop.org/~danvet/drm-intel.git > drm-intel-next-queued > head: 861b675336a1f686f480d92990251e99a3ec0956 > commit: 686279dbcbc69f71ce86efdccaa8cad762cba2ea [42/44] drm/i915: Extract > PCU communication > config: x86_64-allyesconfig # make ARCH=x86_64 allyesconfig > > All error/warnings: > > drivers/gpu/drm/i915/intel_pm.c: In function 'gen6_enable_rps': > drivers/gpu/drm/i915/intel_pm.c:2506:2: error: 'ret' undeclared (first use in > this function) > drivers/gpu/drm/i915/intel_pm.c:2506:2: note: each undeclared identifier is > reported only once for each function it appears in > > vim +2506 drivers/gpu/drm/i915/intel_pm.c > > 89ba829e Jesse Barnes 2012-05-22 2500 > GEN6_RP_MEDIA_HW_NORMAL_MODE | > 2b4e57bd Eugeni Dodonov 2012-04-18 2501 GEN6_RP_MEDIA_IS_GFX > | > 2b4e57bd Eugeni Dodonov 2012-04-18 2502 GEN6_RP_ENABLE | > 2b4e57bd Eugeni Dodonov 2012-04-18 2503 GEN6_RP_UP_BUSY_AVG | > 5a7dc92a Eugeni Dodonov 2012-07-02 2504 (IS_HASWELL(dev) ? > GEN7_RP_DOWN_IDLE_AVG : GEN6_RP_DOWN_IDLE_CONT)); > 2b4e57bd Eugeni Dodonov 2012-04-18 2505 > 686279db Ben Widawsky 2012-09-26 @2506 ret = > sandybridge_pcode_write(dev_priv, GEN6_PCODE_WRITE_MIN_FREQ_TABLE, 0); > 686279db Ben Widawsky 2012-09-26 2507 if (!ret) { > 686279db Ben Widawsky 2012-09-26 2508 pcu_mbox = 0; > 686279db Ben Widawsky 2012-09-26 2509 ret = > sandybridge_pcode_read(dev_priv, GEN6_READ_OC_PARAMS, &pcu_mbox); Fixed up, thanks a lot for the report. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[drm-intel:drm-intel-next-queued 42/44] drivers/gpu/drm/i915/intel_pm.c:2506:2: error: 'ret' undeclared
Hi Ben, FYI, kernel build failed on tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-next-queued head: 861b675336a1f686f480d92990251e99a3ec0956 commit: 686279dbcbc69f71ce86efdccaa8cad762cba2ea [42/44] drm/i915: Extract PCU communication config: x86_64-allyesconfig # make ARCH=x86_64 allyesconfig All error/warnings: drivers/gpu/drm/i915/intel_pm.c: In function 'gen6_enable_rps': drivers/gpu/drm/i915/intel_pm.c:2506:2: error: 'ret' undeclared (first use in this function) drivers/gpu/drm/i915/intel_pm.c:2506:2: note: each undeclared identifier is reported only once for each function it appears in vim +2506 drivers/gpu/drm/i915/intel_pm.c 89ba829e Jesse Barnes 2012-05-22 2500 GEN6_RP_MEDIA_HW_NORMAL_MODE | 2b4e57bd Eugeni Dodonov 2012-04-18 2501 GEN6_RP_MEDIA_IS_GFX | 2b4e57bd Eugeni Dodonov 2012-04-18 2502 GEN6_RP_ENABLE | 2b4e57bd Eugeni Dodonov 2012-04-18 2503 GEN6_RP_UP_BUSY_AVG | 5a7dc92a Eugeni Dodonov 2012-07-02 2504 (IS_HASWELL(dev) ? GEN7_RP_DOWN_IDLE_AVG : GEN6_RP_DOWN_IDLE_CONT)); 2b4e57bd Eugeni Dodonov 2012-04-18 2505 686279db Ben Widawsky 2012-09-26 @2506ret = sandybridge_pcode_write(dev_priv, GEN6_PCODE_WRITE_MIN_FREQ_TABLE, 0); 686279db Ben Widawsky 2012-09-26 2507if (!ret) { 686279db Ben Widawsky 2012-09-26 2508pcu_mbox = 0; 686279db Ben Widawsky 2012-09-26 2509ret = sandybridge_pcode_read(dev_priv, GEN6_READ_OC_PARAMS, &pcu_mbox); --- 0-DAY kernel build testing backend Open Source Technology Center Fengguang Wu, Yuanhan Liu Intel Corporation
[PATCH] radeon: fix tile_split of 128-bit surface formats with 8x MSAA
Dear Marek, Am Dienstag, den 16.10.2012, 02:21 +0200 schrieb Marek Ol??k: > The calculation led to the number 8192, which is too high. what is the reason it is limited to 4096? Hardware limitation? What are the ramifications? GPU hangs, rendering errors? > --- > radeon/radeon_surface.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c > index 66c2444..eb587d2 100644 > --- a/radeon/radeon_surface.c > +++ b/radeon/radeon_surface.c > @@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager > *surf_man, > } else { > /* tile split must be >= 256 for colorbuffer surfaces */ > surf->tile_split = MAX2(surf->nsamples * surf->bpe * 64, 256); > +if (surf->tile_split > 4096) > +surf->tile_split = 4096; > } > } else { > /* set tile split to row size */ Thanks, Paul -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121016/c6df66b0/attachment-0001.pgp>
[PATCH] radeon: fix tile_split of 128-bit surface formats with 8x MSAA
On Mon, Oct 15, 2012 at 8:21 PM, Marek Ol??k wrote: > The calculation led to the number 8192, which is too high. Looks good. Reviewed-by: Alex Deucher > --- > radeon/radeon_surface.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c > index 66c2444..eb587d2 100644 > --- a/radeon/radeon_surface.c > +++ b/radeon/radeon_surface.c > @@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager > *surf_man, > } else { > /* tile split must be >= 256 for colorbuffer surfaces */ > surf->tile_split = MAX2(surf->nsamples * surf->bpe * 64, 256); > +if (surf->tile_split > 4096) > +surf->tile_split = 4096; > } > } else { > /* set tile split to row size */ > -- > 1.7.9.5 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] radeon: fix tile_split of 128-bit surface formats with 8x MSAA
On Tue, Oct 16, 2012 at 2:50 AM, Paul Menzel wrote: > Dear Marek, > > > Am Dienstag, den 16.10.2012, 02:21 +0200 schrieb Marek Ol??k: >> The calculation led to the number 8192, which is too high. > > what is the reason it is limited to 4096? Hardware limitation? hw limit. > > What are the ramifications? GPU hangs, rendering errors? Rendering errors. Alex > >> --- >> radeon/radeon_surface.c |2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c >> index 66c2444..eb587d2 100644 >> --- a/radeon/radeon_surface.c >> +++ b/radeon/radeon_surface.c >> @@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager >> *surf_man, >> } else { >> /* tile split must be >= 256 for colorbuffer surfaces */ >> surf->tile_split = MAX2(surf->nsamples * surf->bpe * 64, 256); >> +if (surf->tile_split > 4096) >> +surf->tile_split = 4096; >> } >> } else { >> /* set tile split to row size */ > > > Thanks, > > Paul > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH] drm/radeon: fix PFP sync in vm_flush
On Tue, Oct 16, 2012 at 5:02 AM, Christian K?nig wrote: > Otherwise the next IB might start reading commands > with the page table still invalid. > > Signed-off-by: Christian K?nig Looks good to me. I'll add it to my -fixes queue. Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/radeon/ni.c |4 > drivers/gpu/drm/radeon/nid.h |1 + > drivers/gpu/drm/radeon/si.c |4 > 3 files changed, 9 insertions(+) > > diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c > index 8c74c72..19b7fe1 100644 > --- a/drivers/gpu/drm/radeon/ni.c > +++ b/drivers/gpu/drm/radeon/ni.c > @@ -1586,4 +1586,8 @@ void cayman_vm_flush(struct radeon_device *rdev, int > ridx, struct radeon_vm *vm) > /* bits 0-7 are the VM contexts0-7 */ > radeon_ring_write(ring, PACKET0(VM_INVALIDATE_REQUEST, 0)); > radeon_ring_write(ring, 1 << vm->id); > + > + /* sync PFP to ME, otherwise we might get invalid PFP reads */ > + radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0)); > + radeon_ring_write(ring, 0x0); > } > diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h > index 2423d1b..cbef681 100644 > --- a/drivers/gpu/drm/radeon/nid.h > +++ b/drivers/gpu/drm/radeon/nid.h > @@ -502,6 +502,7 @@ > #definePACKET3_MPEG_INDEX 0x3A > #definePACKET3_WAIT_REG_MEM0x3C > #definePACKET3_MEM_WRITE 0x3D > +#definePACKET3_PFP_SYNC_ME 0x42 > #definePACKET3_SURFACE_SYNC0x43 > # define PACKET3_CB0_DEST_BASE_ENA(1 << 6) > # define PACKET3_CB1_DEST_BASE_ENA(1 << 7) > diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c > index df8dd77..da184de 100644 > --- a/drivers/gpu/drm/radeon/si.c > +++ b/drivers/gpu/drm/radeon/si.c > @@ -2868,6 +2868,10 @@ void si_vm_flush(struct radeon_device *rdev, int ridx, > struct radeon_vm *vm) > radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2); > radeon_ring_write(ring, 0); > radeon_ring_write(ring, 1 << vm->id); > + > + /* sync PFP to ME, otherwise we might get invalid PFP reads */ > + radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0)); > + radeon_ring_write(ring, 0x0); > } > > /* > -- > 1.7.9.5 >
Re: [PATCH 0/11] drm: add drm_send_vblank_event() helper (v4)
On Tue, Oct 16, 2012 at 9:14 AM, Laurent Pinchart wrote: > Hi Rob, > > Thanks for the patch (0/11 looks a bit weird BTW). opps, that was *supposed* to be 01/11 :-P > > On Friday 12 October 2012 18:57:12 Rob Clark wrote: >> From: Rob Clark >> >> A helper that drivers can use to send vblank event after a pageflip. >> If the driver doesn't support proper vblank irq based time/seqn then >> just pass -1 for the pipe # to get do_gettimestamp() behavior (since >> there are a lot of drivers that don't use drm_vblank_count_and_time()) >> >> Also an internal send_vblank_event() helper for the various other code >> paths within drm_irq that also need to send vblank events. >> >> v1: original >> v2: add back 'vblwait->reply.sequence = seq' which should not have >> been deleted >> v3: add WARN_ON() in case lock is not held and comments >> v4: use WARN_ON_SMP() instead to fix issue with !SMP && !DEBUG_SPINLOCK >> as pointed out by Marcin Slusarz >> >> Signed-off-by: Rob Clark >> --- >> drivers/gpu/drm/drm_irq.c | 74 -- >> include/drm/drmP.h|2 ++ > > Documentation/DocBook/drm.tmpl is missing ;-) yeah, I just noticed that the docbook already has a section on pageflip.. I'll send a separate patch for this. BR, -R > >> 2 files changed, 54 insertions(+), 22 deletions(-) > > I still wish we could have found a way to call drm_vblank_count_and_time() and > do_gettimeofday() outside of the spinlock-protected region, but I won't > complain. Apart from the missing documentation update the patch looks OK to > me. > > -- > Regards, > > Laurent Pinchart > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] uapi: update includes for drm content when no kernel API exists
On Tue, Oct 16, 2012 at 5:34 AM, Laurent Pinchart wrote: > Hi Luis, > > On Saturday 13 October 2012 10:00:42 Luis R. Rodriguez wrote: >> On Sat, Oct 13, 2012 at 3:33 AM, Laurent Pinchart wrote: >> > On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote: >> >> From: "Luis R. Rodriguez" >> >> >> >> The UAPI changes split kernel API and userspace API >> >> content onto two separate header files. The userspace >> >> API drm content was moved to include/uapi/drm/ with the >> >> same file name while kernel specific API content was >> >> kept under include/drm/ with the same file name. When >> >> one file was split into two files the kernel header >> >> includes the uapi header and a UAPI prefix was added to >> >> the uapi header for its header guard. When there was no >> >> kernel API content found the uapi header file was the >> >> only one that was kept and the original guard for the >> >> header file was kept. In this particular case the >> >> original users of this header file were not modified >> >> and the uapi header file is expected to be picked up >> >> by path. >> >> >> >> This may work well at compilation on the kernel but when >> >> backporting this creates a few complexities. >> > >> > Could you please provide more details about those complexities ? >> >> Sure, the backported DRM code is as-is code from linux-next. The >> header search path includes a copy of a few select header files from >> linux-next, the rest are part of the compat [0] project to help with >> backporting and the last set are from your own kernel. In this >> particular case the UAPI effort pushed into include/uapi/drm a few >> files which are now no longer present in the old include/drm/ location >> when there was no respective kernel-only APIs exposed. For DRM code >> that did not use the new uapi/drm/ path for old header includes this >> means that upon backporting the older kernel's header file would be >> used obviously leading to a series of compilation failures. By being >> explicit about the path, as was done with a few other header files, we >> can suck out DRM code intact from the kernel to be compilable for >> older kernels. As of the v3.7-rc1 the compat-drivers project [1] will >> be providing DRM modules. The new UAPI changes broke compilation on >> compat-drivers when compiling DRM code so to fix this we either patch >> code taken from the Linux kernel as I have done, force inclusion of a >> few specific headers files, or use include_next tricks. It turns out >> that forcing inclusion of -I$(M)/include/uapi as a path search prior >> to your own kernel's at compilation time did not help. > > Shouldn't that be added as a search path *after* include/linux/ instead of > before ? Ah, therein lies the issue. If backporting no, if backporting you should seek first for your current directory's include/drm/ dir and then uapi, and then only later the older kernel's paths: NOSTDINC_FLAGS := \ -I$(M)/include/ \ -I$(M)/include/drm \ -I$(M)/include/uapi \ -include $(M)/include/linux/compat-2.6.h \ $(CFLAGS) >> The include_next trick can work as well but that'd mean synching the UAPI >> files regularly into compat. I'd much prefer to have code intact when >> possible when backporting so the option I stuck with then was to patch >> the code directly and then as part of compat-drivers to always copy >> that day's linux-next UAPI headers into the current directory for >> compilation. I see no other driver code using the uapi path explicitly >> though, is that by design? > > As far as I understand that's by design, yes. Kernel code isn't expected to > reference uapi/ headers directly. Did the design consider the case where no respective kernel API header file would ever exist? >> Would it be wrong to be explicit about using a UAPI header alone if no >> kernel API files exist? > > I personally don't really like including such "features" in a mainline just > for backporting, Sort of ditto. I haven't yet made a strong case for one particular situation where this would help (but I will in the long run, see blog), but this example should not be considered one. The patch itself should be considered in terms of its merit for clarifying usage and assumptions of uapi. The fact that I came up with it due to issues when backporting is only secondary. > especially when they go against the spirit of the > architecture (the uapi/ split design principles in this case). The patches, pull request, and even lwn article did not cover the intent on architecture so if it was the design objective I'd like to know how that is determined. From the looks of it, this as all scripted and I do wonder if the case where no kernel API header file existed was taken into consideration. > The way we're > dealing with this in the V4L backport tree > (http://git.linuxtv.org/media_build.git) is to play with Makefiles, include > compatibility headers and, if nothing else can work, maintain backport patches > for mainl
[BUG 3.7-rc1] nouveau cli->mutex possible recursive locking detected
I have this lockdep warning on wireless-testing tree based on 3.7-rc1 (no other patches except wireless bits). = Restarting tasks ... done. [ INFO: possible recursive locking detected ] 3.7.0-rc1-wl+ #2 Not tainted - Xorg/2269 is trying to acquire lock: (&cli->mutex){+.+.+.}, at: [] nouveau_bo_move_m2mf+0x5f/0x170 [nouveau] but task is already holding lock: (&cli->mutex){+.+.+.}, at: [] nouveau_abi16_get+0x34/0x100 [nouveau] other info that might help us debug this: Possible unsafe locking scenario: CPU0 lock(&cli->mutex); lock(&cli->mutex); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by Xorg/2269: #0: (&cli->mutex){+.+.+.}, at: [] nouveau_abi16_get+0x34/0x100 [nouveau] stack backtrace: Pid: 2269, comm: Xorg Not tainted 3.7.0-rc1-wl+ #2 Call Trace: [] print_deadlock_bug+0xf4/0x100 [] validate_chain+0x549/0x7e0 [] __lock_acquire+0x367/0x580 [] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau] [] lock_acquire+0xa4/0x120 [] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau] [] ? _raw_spin_unlock_irqrestore+0x40/0x80 [] __mutex_lock_common+0x47/0x3f0 [] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau] [] ? nv84_graph_tlb_flush+0x291/0x2b0 [nouveau] [] ? _nouveau_gpuobj_wr32+0x26/0x30 [nouveau] [] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau] [] mutex_lock_nested+0x37/0x50 [] nouveau_bo_move_m2mf+0x5f/0x170 [nouveau] [] nouveau_bo_move+0xe3/0x330 [nouveau] [] ttm_bo_handle_move_mem+0x2bd/0x670 [ttm] [] ttm_bo_move_buffer+0x12e/0x150 [ttm] [] ttm_bo_validate+0x99/0x130 [ttm] [] nouveau_bo_validate+0x23/0x30 [nouveau] [] validate_list+0xae/0x2c0 [nouveau] [] nouveau_gem_pushbuf_validate+0xa2/0x1e0 [nouveau] [] nouveau_gem_ioctl_pushbuf+0x22c/0x8a0 [nouveau] [] drm_ioctl+0x355/0x570 [drm] [] ? do_sync_read+0xaa/0xf0 [] ? nouveau_gem_pushbuf_validate+0x1e0/0x1e0 [nouveau] [] do_vfs_ioctl+0x8c/0x350 [] ? sysret_check+0x22/0x5d [] sys_ioctl+0xa1/0xb0 [] ? trace_hardirqs_on_thunk+0x3a/0x3f [] system_call_fastpath+0x16/0x1b ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #23 from Christian König --- Created attachment 68623 --> https://bugs.freedesktop.org/attachment.cgi?id=68623&action=edit Test patch. VM is definitely enabled, otherwise you won't got that error in the first place. Ok let's try to narrow down that bug a bit more, please apply the attached test patch and see what happens. If the GPU hang vanished we indeed have a syncing issue, but not the PFP sync. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes
Hi Linus, fixes for i915, nouveau and radeon i915: haswell stability, modeset rework fallout, ums fix nouveau: misc fixes from code rework radeon: pll rework fixes, more 2 level PTE cleanups. core: warning fixes on 32-bit. Dave. The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linux 3.7-rc1 (2012-10-14 14:41:04 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux.git drm-fixes for you to fetch changes up to 8a00b6af4cc547725f231c8367ddc7cb56b2cf76: nouveau: fix warning on 32-bit build. (2012-10-16 16:40:53 +1000) Alex Deucher (5): drm/radeon: fix compilation with backlight disabled drm/radeon: allocate PPLLs from low to high drm/radeon: update comments to clarify VM setup (v2) drm/radeon/cayman: set VM max pfn at MC init drm/radeon: check if pcie gen 2 is already enabled (v2) Ben Skeggs (1): drm/nouveau/bios: fix typo in error message Chris Wilson (2): drm/i915: Disallow preallocation of requests drm/i915: fixup i915_gem_object_get_page inline helper Christian K?nig (3): drm/radeon: allocate page tables on demand v4 drm/radeon: don't add the IB pool to all VMs v2 drm/radeon: separate pt alloc from lru add Daniel Vetter (5): drm/i915: paper over a pipe-enable vs pageflip race drm/i915: disable wc gtt pte mappings on gen2 drm/i915: rip out the pipe A quirk for i855gm drm/i915: fixup the plane->pipe fixup code drm/i915/dvo-ch7xxx: fix get_hw_state Dave Airlie (5): Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Merge branch 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux into drm-fixes drm: fix warning on 32-bit. Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes nouveau: fix warning on 32-bit build. Egbert Eich (1): drm/radeon: Don't destroy I2C Bus Rec in radeon_ext_tmds_enc_destroy(). Jani Nikula (1): drm/i915: fix non-DP-D eDP backlight cleanup and module reload Kenneth Graunke (1): drm/i915: Set guardband clipping workaround bit in the right register. Luca Tettamanti (1): drm/radeon: use %zu for formatting size_t Marcin Slusarz (1): drm/nv50/fb: fix double free of vram mm Martin Peres (3): drm/nouveau/hwmon: fix the initialization condition drm/nouveau/pm: fix a typo related to the move to the therm subdev drm/nouveau/pm: do not stop reclocking if failing to set the fan speed Max Filippov (1): drm/nouveau: only call ttm_agp_tt_create when __OS_HAS_AGP Randy Dunlap (1): drm: radeon: fix printk format warning Rodrigo Vivi (1): drm/i915: HSW CRW stability magic Thomas Friebel (1): drm/radeon: fix spelling typos in debugging output Willy Tarreau (1): drm/i915: remove useless BUG_ON which caused a regression in 3.5. drivers/char/agp/intel-gtt.c|2 +- drivers/gpu/drm/drm_info.c |2 +- drivers/gpu/drm/i915/dvo_ch7xxx.c |6 +- drivers/gpu/drm/i915/i915_drv.h |9 +- drivers/gpu/drm/i915/i915_gem.c | 19 +- drivers/gpu/drm/i915/i915_reg.h |2 +- drivers/gpu/drm/i915/intel_display.c| 47 ++- drivers/gpu/drm/i915/intel_dp.c |3 +- drivers/gpu/drm/i915/intel_overlay.c| 72 + drivers/gpu/drm/i915/intel_pm.c |4 +- drivers/gpu/drm/nouveau/core/subdev/bios/dcb.c |2 +- drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c |1 - drivers/gpu/drm/nouveau/core/subdev/therm/fan.c |2 +- drivers/gpu/drm/nouveau/nouveau_bo.c|2 + drivers/gpu/drm/nouveau/nouveau_pm.c|6 +- drivers/gpu/drm/radeon/atombios_crtc.c |8 +- drivers/gpu/drm/radeon/evergreen.c |7 +- drivers/gpu/drm/radeon/ni.c | 12 +- drivers/gpu/drm/radeon/r600.c |6 + drivers/gpu/drm/radeon/radeon.h | 14 +- drivers/gpu/drm/radeon/radeon_acpi.c|6 +- drivers/gpu/drm/radeon/radeon_atpx_handler.c|2 +- drivers/gpu/drm/radeon/radeon_cs.c |1 + drivers/gpu/drm/radeon/radeon_device.c |4 + drivers/gpu/drm/radeon/radeon_gart.c| 374 --- drivers/gpu/drm/radeon/radeon_kms.c | 22 +- drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 48 ++- drivers/gpu/drm/radeon/radeon_ring.c|2 +- drivers/gpu/drm/radeon/si.c |7 +- 29 files changed, 443 insertions(+), 249 deletions(-)
[PATCH 1/2] uapi: update includes for drm content when no kernel API exists
On Tue, Oct 16, 2012 at 5:34 AM, Laurent Pinchart wrote: > Hi Luis, > > On Saturday 13 October 2012 10:00:42 Luis R. Rodriguez wrote: >> On Sat, Oct 13, 2012 at 3:33 AM, Laurent Pinchart wrote: >> > On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote: >> >> From: "Luis R. Rodriguez" >> >> >> >> The UAPI changes split kernel API and userspace API >> >> content onto two separate header files. The userspace >> >> API drm content was moved to include/uapi/drm/ with the >> >> same file name while kernel specific API content was >> >> kept under include/drm/ with the same file name. When >> >> one file was split into two files the kernel header >> >> includes the uapi header and a UAPI prefix was added to >> >> the uapi header for its header guard. When there was no >> >> kernel API content found the uapi header file was the >> >> only one that was kept and the original guard for the >> >> header file was kept. In this particular case the >> >> original users of this header file were not modified >> >> and the uapi header file is expected to be picked up >> >> by path. >> >> >> >> This may work well at compilation on the kernel but when >> >> backporting this creates a few complexities. >> > >> > Could you please provide more details about those complexities ? >> >> Sure, the backported DRM code is as-is code from linux-next. The >> header search path includes a copy of a few select header files from >> linux-next, the rest are part of the compat [0] project to help with >> backporting and the last set are from your own kernel. In this >> particular case the UAPI effort pushed into include/uapi/drm a few >> files which are now no longer present in the old include/drm/ location >> when there was no respective kernel-only APIs exposed. For DRM code >> that did not use the new uapi/drm/ path for old header includes this >> means that upon backporting the older kernel's header file would be >> used obviously leading to a series of compilation failures. By being >> explicit about the path, as was done with a few other header files, we >> can suck out DRM code intact from the kernel to be compilable for >> older kernels. As of the v3.7-rc1 the compat-drivers project [1] will >> be providing DRM modules. The new UAPI changes broke compilation on >> compat-drivers when compiling DRM code so to fix this we either patch >> code taken from the Linux kernel as I have done, force inclusion of a >> few specific headers files, or use include_next tricks. It turns out >> that forcing inclusion of -I$(M)/include/uapi as a path search prior >> to your own kernel's at compilation time did not help. > > Shouldn't that be added as a search path *after* include/linux/ instead of > before ? Ah, therein lies the issue. If backporting no, if backporting you should seek first for your current directory's include/drm/ dir and then uapi, and then only later the older kernel's paths: NOSTDINC_FLAGS := \ -I$(M)/include/ \ -I$(M)/include/drm \ -I$(M)/include/uapi \ -include $(M)/include/linux/compat-2.6.h \ $(CFLAGS) >> The include_next trick can work as well but that'd mean synching the UAPI >> files regularly into compat. I'd much prefer to have code intact when >> possible when backporting so the option I stuck with then was to patch >> the code directly and then as part of compat-drivers to always copy >> that day's linux-next UAPI headers into the current directory for >> compilation. I see no other driver code using the uapi path explicitly >> though, is that by design? > > As far as I understand that's by design, yes. Kernel code isn't expected to > reference uapi/ headers directly. Did the design consider the case where no respective kernel API header file would ever exist? >> Would it be wrong to be explicit about using a UAPI header alone if no >> kernel API files exist? > > I personally don't really like including such "features" in a mainline just > for backporting, Sort of ditto. I haven't yet made a strong case for one particular situation where this would help (but I will in the long run, see blog), but this example should not be considered one. The patch itself should be considered in terms of its merit for clarifying usage and assumptions of uapi. The fact that I came up with it due to issues when backporting is only secondary. > especially when they go against the spirit of the > architecture (the uapi/ split design principles in this case). The patches, pull request, and even lwn article did not cover the intent on architecture so if it was the design objective I'd like to know how that is determined. From the looks of it, this as all scripted and I do wonder if the case where no kernel API header file existed was taken into consideration. > The way we're > dealing with this in the V4L backport tree > (http://git.linuxtv.org/media_build.git) is to play with Makefiles, include > compatibility headers and, if nothing else can work, maintain backport patches > for mainl
Re: [PATCH 0/11] drm: add drm_send_vblank_event() helper (v4)
Hi Rob, Thanks for the patch (0/11 looks a bit weird BTW). On Friday 12 October 2012 18:57:12 Rob Clark wrote: > From: Rob Clark > > A helper that drivers can use to send vblank event after a pageflip. > If the driver doesn't support proper vblank irq based time/seqn then > just pass -1 for the pipe # to get do_gettimestamp() behavior (since > there are a lot of drivers that don't use drm_vblank_count_and_time()) > > Also an internal send_vblank_event() helper for the various other code > paths within drm_irq that also need to send vblank events. > > v1: original > v2: add back 'vblwait->reply.sequence = seq' which should not have > been deleted > v3: add WARN_ON() in case lock is not held and comments > v4: use WARN_ON_SMP() instead to fix issue with !SMP && !DEBUG_SPINLOCK > as pointed out by Marcin Slusarz > > Signed-off-by: Rob Clark > --- > drivers/gpu/drm/drm_irq.c | 74 -- > include/drm/drmP.h|2 ++ Documentation/DocBook/drm.tmpl is missing ;-) > 2 files changed, 54 insertions(+), 22 deletions(-) I still wish we could have found a way to call drm_vblank_count_and_time() and do_gettimeofday() outside of the spinlock-protected region, but I won't complain. Apart from the missing documentation update the patch looks OK to me. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] radeon: fix tile_split of 128-bit surface formats with 8x MSAA
In this specific case, the eg_surface_sanity function (or something like that, I don't remember its name) returns an error. Then the cascade of perfectly working fail codepaths propagate the error to the OpenGL user as an unsupported framebuffer object setup. Marek On Tue, Oct 16, 2012 at 8:50 AM, Paul Menzel wrote: > Dear Marek, > > > Am Dienstag, den 16.10.2012, 02:21 +0200 schrieb Marek Olšák: >> The calculation led to the number 8192, which is too high. > > what is the reason it is limited to 4096? Hardware limitation? > > What are the ramifications? GPU hangs, rendering errors? > >> --- >> radeon/radeon_surface.c |2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c >> index 66c2444..eb587d2 100644 >> --- a/radeon/radeon_surface.c >> +++ b/radeon/radeon_surface.c >> @@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager >> *surf_man, >> } else { >> /* tile split must be >= 256 for colorbuffer surfaces */ >> surf->tile_split = MAX2(surf->nsamples * surf->bpe * 64, 256); >> +if (surf->tile_split > 4096) >> +surf->tile_split = 4096; >> } >> } else { >> /* set tile split to row size */ > > > Thanks, > > Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm: add drm_send_vblank_event() helper
Hi Mario, On Saturday 13 October 2012 02:28:03 Mario Kleiner wrote: > On 11.10.12 16:19, Laurent Pinchart wrote: > > On Monday 08 October 2012 14:50:39 Rob Clark wrote: > >> From: Rob Clark > > ... > > > Do you know why some drivers don't call drm_vblank_count_and_time() ? For > > instance nouveau sets the sequence to 0 and uses do_gettimeofday(), but it > > looks like it could just call drm_vblank_count_and_time(). > > At least nouveau could use it. Lucas Stach and me wrote patches for > nouveau-kms, and they went through many iterations and missed many > kernel merge windows due to slow review until i think both of us got > tired of resubmitting with tiny changes. I totally understand the feeling, but please don't give up. You can CC me on the next iteration, I'll make sure to review the patches (even though I have no experience with the nouveau driver). > The latest iteration is posted by Lucas on nouveau-devel from 26. April > 2012. Not sure if they'd still apply after the nouveau-kms rewrite. I'll > probably give them another try once that has landed when i have some spare > time. > > In principle it's very simple to use drm_vblank_count_and_time(). A > driver needs to > > 1. Call drm_handle_vblank() from its vblank irq handler. > > 2. Make sure that in the vblank of pageflip completion > drm_handle_vblank() is called before drm_vblank_count_and_time(), so the > latter picks up updated counts and timestamps. > > 3. Big bonus for high precision and robustness: Implement the > driver->get_vblank_timestamp() hook to provide a precise vblank > timestamp. One simple way to do that is like radeon-kms or intel-kms do > it: Call back into drm_calc_vbltimestamp_from_scanoutpos() and provide > the driver->get_scanout_position() function - a function that returns > the current hardware scanline counter. This is precise down to ~ 10 > microseconds (at least confirmed by measurements on > intel,radeon,nouveau) and robust against delayed vblank irq handling. > > -mario -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] radeon: fix tile_split of 128-bit surface formats with 8x MSAA
On Mon, Oct 15, 2012 at 8:21 PM, Marek Olšák wrote: > The calculation led to the number 8192, which is too high. Looks good. Reviewed-by: Alex Deucher > --- > radeon/radeon_surface.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c > index 66c2444..eb587d2 100644 > --- a/radeon/radeon_surface.c > +++ b/radeon/radeon_surface.c > @@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager > *surf_man, > } else { > /* tile split must be >= 256 for colorbuffer surfaces */ > surf->tile_split = MAX2(surf->nsamples * surf->bpe * 64, 256); > +if (surf->tile_split > 4096) > +surf->tile_split = 4096; > } > } else { > /* set tile split to row size */ > -- > 1.7.9.5 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm: exynos: moved exynos drm hdmi device registration to drm driver
This patch moved the exynos-drm-hdmi platform device registration to the drm driver. When DT is enabled, platform devices needs to be registered within the driver code. This patch fits the requirement of both DT and Non DT based drm drivers. Signed-off-by: Rahul Sharma --- drivers/gpu/drm/exynos/exynos_drm_drv.c |9 - drivers/gpu/drm/exynos/exynos_drm_drv.h | 11 +++ drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 22 ++ 3 files changed, 41 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 4200f15..507f8ba 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -329,6 +329,10 @@ static int __init exynos_drm_init(void) ret = platform_driver_register(&exynos_drm_common_hdmi_driver); if (ret < 0) goto out_common_hdmi; + + ret = exynos_platform_device_hdmi_register(); + if (ret < 0) + goto out_common_hdmi_dev; #endif #ifdef CONFIG_DRM_EXYNOS_VIDI @@ -366,11 +370,13 @@ out_g2d: #endif #ifdef CONFIG_DRM_EXYNOS_VIDI -out_vidi: platform_driver_unregister(&vidi_driver); +out_vidi: #endif #ifdef CONFIG_DRM_EXYNOS_HDMI + exynos_platform_device_hdmi_unregister(); +out_common_hdmi_dev: platform_driver_unregister(&exynos_drm_common_hdmi_driver); out_common_hdmi: platform_driver_unregister(&mixer_driver); @@ -399,6 +405,7 @@ static void __exit exynos_drm_exit(void) #endif #ifdef CONFIG_DRM_EXYNOS_HDMI + exynos_platform_device_hdmi_unregister(); platform_driver_unregister(&exynos_drm_common_hdmi_driver); platform_driver_unregister(&mixer_driver); platform_driver_unregister(&hdmi_driver); diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h b/drivers/gpu/drm/exynos/exynos_drm_drv.h index eec77aa..e4abb62 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h @@ -319,6 +319,17 @@ int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv *drm_subdrv); int exynos_drm_subdrv_open(struct drm_device *dev, struct drm_file *file); void exynos_drm_subdrv_close(struct drm_device *dev, struct drm_file *file); +/* + * this function registers exynos drm hdmi platform device. It ensures only one + * instance of the device is created. + */ +extern int exynos_platform_device_hdmi_register(void); + +/* + * this function unregisters exynos drm hdmi platform device if it exists. + */ +void exynos_platform_device_hdmi_unregister(void); + extern struct platform_driver fimd_driver; extern struct platform_driver hdmi_driver; extern struct platform_driver mixer_driver; diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c index 85304c4..a4c84c1 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c @@ -29,6 +29,9 @@ #define get_ctx_from_subdrv(subdrv)container_of(subdrv,\ struct drm_hdmi_context, subdrv); +/* platform device pointer for common drm hdmi device. */ +static struct platform_device *exynos_drm_hdmi_pdev; + /* Common hdmi subdrv needs to access the hdmi and mixer though context. * These should be initialied by the repective drivers */ static struct exynos_drm_hdmi_context *hdmi_ctx; @@ -46,6 +49,25 @@ struct drm_hdmi_context { boolenabled[MIXER_WIN_NR]; }; +int exynos_platform_device_hdmi_register(void) +{ + if (exynos_drm_hdmi_pdev) + return -EEXIST; + + exynos_drm_hdmi_pdev = platform_device_register_simple( + "exynos-drm-hdmi", -1, NULL, 0); + if (IS_ERR_OR_NULL(exynos_drm_hdmi_pdev)) + return PTR_ERR(exynos_drm_hdmi_pdev); + + return 0; +} + +void exynos_platform_device_hdmi_unregister(void) +{ + if (exynos_drm_hdmi_pdev) + platform_device_unregister(exynos_drm_hdmi_pdev); +} + void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx) { if (ctx) -- 1.7.0.4
[PATCH v2 1/2] drm: exynos: moved exynos drm device registration to drm driver
This patch moved the exynos-drm platform device registration to the drm driver. When DT is enabled, platform devices needs to be registered within the driver code. This patch fits the requirement of both DT and Non DT based drm drivers. Signed-off-by: Rahul Sharma --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 16 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index d070719..4200f15 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -50,6 +50,9 @@ #define VBLANK_OFF_DELAY 5 +/* platform device pointer for eynos drm device. */ +static struct platform_device *exynos_drm_pdev; + static int exynos_drm_load(struct drm_device *dev, unsigned long flags) { struct exynos_drm_private *private; @@ -280,6 +283,7 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) { DRM_DEBUG_DRIVER("%s\n", __FILE__); + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); exynos_drm_driver.num_ioctls = DRM_ARRAY_SIZE(exynos_ioctls); return drm_platform_init(&exynos_drm_driver, pdev); @@ -341,11 +345,21 @@ static int __init exynos_drm_init(void) ret = platform_driver_register(&exynos_drm_platform_driver); if (ret < 0) + goto out_drm; + + exynos_drm_pdev = platform_device_register_simple("exynos-drm", -1, + NULL, 0); + if (IS_ERR_OR_NULL(exynos_drm_pdev)) { + ret = PTR_ERR(exynos_drm_pdev); goto out; + } return 0; out: + platform_driver_unregister(&exynos_drm_platform_driver); + +out_drm: #ifdef CONFIG_DRM_EXYNOS_G2D platform_driver_unregister(&g2d_driver); out_g2d: @@ -376,6 +390,8 @@ static void __exit exynos_drm_exit(void) { DRM_DEBUG_DRIVER("%s\n", __FILE__); + platform_device_unregister(exynos_drm_pdev); + platform_driver_unregister(&exynos_drm_platform_driver); #ifdef CONFIG_DRM_EXYNOS_G2D -- 1.7.0.4
[PATCH v2 0/2] add exynos-drm platform device registration to driver
This patch adds drm-exynos and drm-exynos-hdmi device registration to the drm driver. It was happening in machine init code earlier which is not acceptable for dt enabled platforms. Patch which cleans the respective code from arch/arm is "arm: exynos: removing exynos-drm device registration from non-dt platforms" is posted to linux-samsung-soc mailing list. This patchset is based on branch exynos-drm-next at git://git.infradead.org/users/kmpark/linux-samsung (linux v3.6-rc4) v1: - moved exynos_drm_hdmi_pdev to drm hdmi layer - added exynos_platform_device_hdmi_register interface v2: - moved register/unregister hdmi device function declarations to exynos_drm_drv.h Rahul Sharma (2): drm: exynos: moved exynos drm device registration to drm driver drm: exynos: moved exynos drm hdmi device registration to drm driver drivers/gpu/drm/exynos/exynos_drm_drv.c | 25 - drivers/gpu/drm/exynos/exynos_drm_drv.h | 11 +++ drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 22 ++ 3 files changed, 57 insertions(+), 1 deletions(-)
Re: [PATCH] radeon: fix tile_split of 128-bit surface formats with 8x MSAA
On Tue, Oct 16, 2012 at 2:50 AM, Paul Menzel wrote: > Dear Marek, > > > Am Dienstag, den 16.10.2012, 02:21 +0200 schrieb Marek Olšák: >> The calculation led to the number 8192, which is too high. > > what is the reason it is limited to 4096? Hardware limitation? hw limit. > > What are the ramifications? GPU hangs, rendering errors? Rendering errors. Alex > >> --- >> radeon/radeon_surface.c |2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c >> index 66c2444..eb587d2 100644 >> --- a/radeon/radeon_surface.c >> +++ b/radeon/radeon_surface.c >> @@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager >> *surf_man, >> } else { >> /* tile split must be >= 256 for colorbuffer surfaces */ >> surf->tile_split = MAX2(surf->nsamples * surf->bpe * 64, 256); >> +if (surf->tile_split > 4096) >> +surf->tile_split = 4096; >> } >> } else { >> /* set tile split to row size */ > > > Thanks, > > Paul > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #16 from Helge Bahmann --- (In reply to comment #15) > A patch referencing this bug report has been merged in Linux v3.7-rc1: > > commit bced76f27165ca7733437715185c3a1aa526f7a1 > Author: Alex Deucher > Date: Fri Sep 14 09:45:50 2012 -0400 > > drm/radeon: restore backlight level on resume appears to be the same patch as mentioned in comment #10, and (at least for me) still does not fix the issue -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix PFP sync in vm_flush
On Tue, Oct 16, 2012 at 5:02 AM, Christian König wrote: > Otherwise the next IB might start reading commands > with the page table still invalid. > > Signed-off-by: Christian König Looks good to me. I'll add it to my -fixes queue. Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/radeon/ni.c |4 > drivers/gpu/drm/radeon/nid.h |1 + > drivers/gpu/drm/radeon/si.c |4 > 3 files changed, 9 insertions(+) > > diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c > index 8c74c72..19b7fe1 100644 > --- a/drivers/gpu/drm/radeon/ni.c > +++ b/drivers/gpu/drm/radeon/ni.c > @@ -1586,4 +1586,8 @@ void cayman_vm_flush(struct radeon_device *rdev, int > ridx, struct radeon_vm *vm) > /* bits 0-7 are the VM contexts0-7 */ > radeon_ring_write(ring, PACKET0(VM_INVALIDATE_REQUEST, 0)); > radeon_ring_write(ring, 1 << vm->id); > + > + /* sync PFP to ME, otherwise we might get invalid PFP reads */ > + radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0)); > + radeon_ring_write(ring, 0x0); > } > diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h > index 2423d1b..cbef681 100644 > --- a/drivers/gpu/drm/radeon/nid.h > +++ b/drivers/gpu/drm/radeon/nid.h > @@ -502,6 +502,7 @@ > #definePACKET3_MPEG_INDEX 0x3A > #definePACKET3_WAIT_REG_MEM0x3C > #definePACKET3_MEM_WRITE 0x3D > +#definePACKET3_PFP_SYNC_ME 0x42 > #definePACKET3_SURFACE_SYNC0x43 > # define PACKET3_CB0_DEST_BASE_ENA(1 << 6) > # define PACKET3_CB1_DEST_BASE_ENA(1 << 7) > diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c > index df8dd77..da184de 100644 > --- a/drivers/gpu/drm/radeon/si.c > +++ b/drivers/gpu/drm/radeon/si.c > @@ -2868,6 +2868,10 @@ void si_vm_flush(struct radeon_device *rdev, int ridx, > struct radeon_vm *vm) > radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2); > radeon_ring_write(ring, 0); > radeon_ring_write(ring, 1 << vm->id); > + > + /* sync PFP to ME, otherwise we might get invalid PFP reads */ > + radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0)); > + radeon_ring_write(ring, 0x0); > } > > /* > -- > 1.7.9.5 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] uapi: update includes for drm content when no kernel API exists
Hi Luis, On Saturday 13 October 2012 10:00:42 Luis R. Rodriguez wrote: > On Sat, Oct 13, 2012 at 3:33 AM, Laurent Pinchart wrote: > > On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote: > >> From: "Luis R. Rodriguez" > >> > >> The UAPI changes split kernel API and userspace API > >> content onto two separate header files. The userspace > >> API drm content was moved to include/uapi/drm/ with the > >> same file name while kernel specific API content was > >> kept under include/drm/ with the same file name. When > >> one file was split into two files the kernel header > >> includes the uapi header and a UAPI prefix was added to > >> the uapi header for its header guard. When there was no > >> kernel API content found the uapi header file was the > >> only one that was kept and the original guard for the > >> header file was kept. In this particular case the > >> original users of this header file were not modified > >> and the uapi header file is expected to be picked up > >> by path. > >> > >> This may work well at compilation on the kernel but when > >> backporting this creates a few complexities. > > > > Could you please provide more details about those complexities ? > > Sure, the backported DRM code is as-is code from linux-next. The > header search path includes a copy of a few select header files from > linux-next, the rest are part of the compat [0] project to help with > backporting and the last set are from your own kernel. In this > particular case the UAPI effort pushed into include/uapi/drm a few > files which are now no longer present in the old include/drm/ location > when there was no respective kernel-only APIs exposed. For DRM code > that did not use the new uapi/drm/ path for old header includes this > means that upon backporting the older kernel's header file would be > used obviously leading to a series of compilation failures. By being > explicit about the path, as was done with a few other header files, we > can suck out DRM code intact from the kernel to be compilable for > older kernels. As of the v3.7-rc1 the compat-drivers project [1] will > be providing DRM modules. The new UAPI changes broke compilation on > compat-drivers when compiling DRM code so to fix this we either patch > code taken from the Linux kernel as I have done, force inclusion of a > few specific headers files, or use include_next tricks. It turns out > that forcing inclusion of -I$(M)/include/uapi as a path search prior > to your own kernel's at compilation time did not help. Shouldn't that be added as a search path *after* include/linux/ instead of before ? > The include_next trick can work as well but that'd mean synching the UAPI > files regularly into compat. I'd much prefer to have code intact when > possible when backporting so the option I stuck with then was to patch > the code directly and then as part of compat-drivers to always copy > that day's linux-next UAPI headers into the current directory for > compilation. I see no other driver code using the uapi path explicitly > though, is that by design? As far as I understand that's by design, yes. Kernel code isn't expected to reference uapi/ headers directly. > Would it be wrong to be explicit about using a UAPI header alone if no > kernel API files exist? I personally don't really like including such "features" in a mainline just for backporting, especially when they go against the spirit of the architecture (the uapi/ split design principles in this case). The way we're dealing with this in the V4L backport tree (http://git.linuxtv.org/media_build.git) is to play with Makefiles, include compatibility headers and, if nothing else can work, maintain backport patches for mainline code. > [0] https://backports.wiki.kernel.org/index.php/Documentation/compat > [1] https://backports.wiki.kernel.org/ -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv10 23/26] v4l: vb2-dma-contig: align buffer size to PAGE_SIZE
Hi Tomasz, On Friday 12 October 2012 10:24:34 Tomasz Stanislawski wrote: > On 10/11/2012 11:31 PM, Laurent Pinchart wrote: > > On Wednesday 10 October 2012 16:46:42 Tomasz Stanislawski wrote: > >> Most operations on DMA and DMABUF framework need page > >> aligned buffers. > > > > The comment is a bit misleading, the buffer is already page-aligned > > (unless I'm mistaken dma_alloc_coherent() returns a page-aligned buffer) > > but its size isn't a multiple of the page size. > > Ok. I will update the commit message that only buffer size is going to be > page aligned. > > > Do we really need a page size multiple ? Isn't it enough to make the size > > a multiple of the cache line size ? > > Frankly, I strongly oppose forcing a size of a DMA buffer to be rounded up. > > However, I discovered a problem while testing mmap() interface in dma-buf. > The test in dma_buf_mmap() will fail if the size is not a multiple of 4k. > > Maybe the value from dma-buf.c:456 should be changed from: > > dmabuf->size >> PAGE_SHIFT > > to > > PAGE_ALIGN(dmabuf->size) >> PAGE_SHIFT > > However, I preferred to avoid any changes outside of the media tree hoping > that the patchset gets merged. Rounding the buffer size to a page size was > quick workaround for the issue with DMABUF mmap(). After some more thoughts I'm not sure whether this patch does the right thing. We have two sizes that we neeed to care about, the user usable buffer size and the allocated memory size. When a user of a buffer requests buffer allocation with an explicit or implicit size we might need to allocate a larger buffer to fulfill usage requirements. We can thus end up with an allocated memory size larger than what the user requested. Such usage requirements include - DMA and CPU access: when accessing the buffer both through DMA and directly by the CPU cache management comes into play, and the buffer address and size then need to be aligned to a cache line size boundary. - Mapping to userspace: we can only map complete pages to userspace, the buffer address and size need to be aligned to a page size boundary to make sure that we won't leak unrelated data to userspace. As the cache line size is smaller than a page fulfilling the second requirement always fulfills the first. There might be other requirements that escape my mind right now. As we don't precisely know at allocation time how the buffer will be used (for instance whether it will eventually be mapped to userspace or not), we have two options: - Align the buffer size to a page size boundary unconditionally. - Let the user handle that requirement by specifying an allocation size aligned to a page size boundary. Given the complexity associated with the second solution and the very small, if not inexistent, expected memory gain (when using the DMA allocation APIs we always get complete pages anyway, so there would be no gain in not aligning the allocation size to a page size boundary), I think the first solution should be preferred. This leaves us with two questions related to buffer size: what size (between the requested size and the actually allocated size) do we report back to the user (in the v4l2_buffer length field for instance), and what size do we report to the dma-buf core (and thus to the other subsystems and other buffer users) ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55829] [Regression]Smokin-guns crash when change resolution
https://bugs.freedesktop.org/show_bug.cgi?id=55829 --- Comment #7 from meng --- Created attachment 68595 --> https://bugs.freedesktop.org/attachment.cgi?id=68595&action=edit Xorg.0.log of xonotic -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121016/82066e66/attachment.html>
[Bug 55829] [Regression]Smokin-guns crash when change resolution
https://bugs.freedesktop.org/show_bug.cgi?id=55829 --- Comment #6 from meng --- Created attachment 68594 --> https://bugs.freedesktop.org/attachment.cgi?id=68594&action=edit backtrace of xonotic -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121016/cfc4e2f4/attachment.html>
[Bug 55829] [Regression]Smokin-guns crash when change resolution
https://bugs.freedesktop.org/show_bug.cgi?id=55829 --- Comment #5 from meng --- Xonotic (xonotic-linux64-sdl) can also repoduce this problem with above version. Pls see Xorg.0.log and bt of xonotic. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121016/b3a06db6/attachment.html>
[PATCH] radeon: fix tile_split of 128-bit surface formats with 8x MSAA
The calculation led to the number 8192, which is too high. --- radeon/radeon_surface.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c index 66c2444..eb587d2 100644 --- a/radeon/radeon_surface.c +++ b/radeon/radeon_surface.c @@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager *surf_man, } else { /* tile split must be >= 256 for colorbuffer surfaces */ surf->tile_split = MAX2(surf->nsamples * surf->bpe * 64, 256); +if (surf->tile_split > 4096) +surf->tile_split = 4096; } } else { /* set tile split to row size */ -- 1.7.9.5
[PATCH] drm/radeon: fix PFP sync in vm_flush
Otherwise the next IB might start reading commands with the page table still invalid. Signed-off-by: Christian König --- drivers/gpu/drm/radeon/ni.c |4 drivers/gpu/drm/radeon/nid.h |1 + drivers/gpu/drm/radeon/si.c |4 3 files changed, 9 insertions(+) diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c index 8c74c72..19b7fe1 100644 --- a/drivers/gpu/drm/radeon/ni.c +++ b/drivers/gpu/drm/radeon/ni.c @@ -1586,4 +1586,8 @@ void cayman_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm *vm) /* bits 0-7 are the VM contexts0-7 */ radeon_ring_write(ring, PACKET0(VM_INVALIDATE_REQUEST, 0)); radeon_ring_write(ring, 1 << vm->id); + + /* sync PFP to ME, otherwise we might get invalid PFP reads */ + radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0)); + radeon_ring_write(ring, 0x0); } diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h index 2423d1b..cbef681 100644 --- a/drivers/gpu/drm/radeon/nid.h +++ b/drivers/gpu/drm/radeon/nid.h @@ -502,6 +502,7 @@ #definePACKET3_MPEG_INDEX 0x3A #definePACKET3_WAIT_REG_MEM0x3C #definePACKET3_MEM_WRITE 0x3D +#definePACKET3_PFP_SYNC_ME 0x42 #definePACKET3_SURFACE_SYNC0x43 # define PACKET3_CB0_DEST_BASE_ENA(1 << 6) # define PACKET3_CB1_DEST_BASE_ENA(1 << 7) diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c index df8dd77..da184de 100644 --- a/drivers/gpu/drm/radeon/si.c +++ b/drivers/gpu/drm/radeon/si.c @@ -2868,6 +2868,10 @@ void si_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm *vm) radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2); radeon_ring_write(ring, 0); radeon_ring_write(ring, 1 << vm->id); + + /* sync PFP to ME, otherwise we might get invalid PFP reads */ + radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0)); + radeon_ring_write(ring, 0x0); } /* -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm-intel:drm-intel-next-queued 42/44] drivers/gpu/drm/i915/intel_pm.c:2506:2: error: 'ret' undeclared
On Tue, Oct 16, 2012 at 08:59:51AM +0800, Fengguang Wu wrote: > Hi Ben, > > FYI, kernel build failed on > > tree: git://people.freedesktop.org/~danvet/drm-intel.git > drm-intel-next-queued > head: 861b675336a1f686f480d92990251e99a3ec0956 > commit: 686279dbcbc69f71ce86efdccaa8cad762cba2ea [42/44] drm/i915: Extract > PCU communication > config: x86_64-allyesconfig # make ARCH=x86_64 allyesconfig > > All error/warnings: > > drivers/gpu/drm/i915/intel_pm.c: In function 'gen6_enable_rps': > drivers/gpu/drm/i915/intel_pm.c:2506:2: error: 'ret' undeclared (first use in > this function) > drivers/gpu/drm/i915/intel_pm.c:2506:2: note: each undeclared identifier is > reported only once for each function it appears in > > vim +2506 drivers/gpu/drm/i915/intel_pm.c > > 89ba829e Jesse Barnes 2012-05-22 2500 > GEN6_RP_MEDIA_HW_NORMAL_MODE | > 2b4e57bd Eugeni Dodonov 2012-04-18 2501 GEN6_RP_MEDIA_IS_GFX > | > 2b4e57bd Eugeni Dodonov 2012-04-18 2502 GEN6_RP_ENABLE | > 2b4e57bd Eugeni Dodonov 2012-04-18 2503 GEN6_RP_UP_BUSY_AVG | > 5a7dc92a Eugeni Dodonov 2012-07-02 2504 (IS_HASWELL(dev) ? > GEN7_RP_DOWN_IDLE_AVG : GEN6_RP_DOWN_IDLE_CONT)); > 2b4e57bd Eugeni Dodonov 2012-04-18 2505 > 686279db Ben Widawsky 2012-09-26 @2506 ret = > sandybridge_pcode_write(dev_priv, GEN6_PCODE_WRITE_MIN_FREQ_TABLE, 0); > 686279db Ben Widawsky 2012-09-26 2507 if (!ret) { > 686279db Ben Widawsky 2012-09-26 2508 pcu_mbox = 0; > 686279db Ben Widawsky 2012-09-26 2509 ret = > sandybridge_pcode_read(dev_priv, GEN6_READ_OC_PARAMS, &pcu_mbox); Fixed up, thanks a lot for the report. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/omap: Fix include error during make
Fixed include error for drm_mode.h Signed-off-by: Andy Gross --- drivers/staging/omapdrm/omap_crtc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/staging/omapdrm/omap_crtc.c b/drivers/staging/omapdrm/omap_crtc.c index 732f2ad..5249223 100644 --- a/drivers/staging/omapdrm/omap_crtc.c +++ b/drivers/staging/omapdrm/omap_crtc.c @@ -19,7 +19,7 @@ #include "omap_drv.h" -#include "drm_mode.h" +#include #include "drm_crtc.h" #include "drm_crtc_helper.h" -- 1.7.5.4