dri-devel February 2013

dri-devel@lists.freedesktop.org

130 participants
696 discussions

[PATCH v6 0/1] Add display-timing node parsing to exynos drm fimd
by Vikas Sajjan 28 Feb '13

28 Feb '13

Add display-timing node parsing to drm fimd and depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html It also adds pinctrl support for drm fimd. changes since v5: - addressed comments from Inki Dae <inki.dae(a)samsung.com>, to remove the allocation of 'fbmode' and replaced '-1'in "of_get_fb_videomode(dev->of_node, fbmode, -1)" with OF_USE_NATIVE_MODE. changes since v4: - addressed comments from Paul Menzel <paulepanter(a)users.sourceforge.net>, to modify the commit message changes since v3: - addressed comments from Sean Paul <seanpaul(a)chromium.org>, to modify the return values and print messages. changes since v2: - moved 'devm_pinctrl_get_select_default' function call under 'if (pdev->dev.of_node)', this makes NON-DT code unchanged. (reported by: Rahul Sharma <r.sh.open(a)gmail.com>) changes since v1: - addressed comments from Sean Paul <seanpaul(a)chromium.org> Vikas Sajjan (1): video: drm: exynos: Add display-timing node parsing using video helper function drivers/gpu/drm/exynos/exynos_drm_fimd.c | 37 ++++++++++++++++++++++++++---- 1 file changed, 33 insertions(+), 4 deletions(-) -- 1.7.9.5

4 8

[PATCH v9 0/2] Add display-timing node parsing to exynos drm fimd
by Vikas Sajjan 28 Feb '13

28 Feb '13

Add display-timing node parsing to drm fimd and depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html It also adds pinctrl support for drm fimd. changes since v8: - replaced IS_ERR() with IS_ERR_OR_NULL(), because devm_pinctrl_get_select_default can return NULL, If CONFIG_PINCTRL is disabled. - modified the error log, such that it shall NOT cross 80 column. - added Acked-by. changes since v7: - addressed comments from Joonyoung Shim <jy0922.shim(a)samsung.com> to remove a unnecessary variable. changes since v6: addressed comments from Inki Dae <inki.dae(a)samsung.com> to separated out the pinctrl functionality and made a separate patch. changes since v5: - addressed comments from Inki Dae <inki.dae(a)samsung.com>, to remove the allocation of 'fbmode' and replaced '-1'in "of_get_fb_videomode(dev->of_node, fbmode, -1)" with OF_USE_NATIVE_MODE. changes since v4: - addressed comments from Paul Menzel <paulepanter(a)users.sourceforge.net>, to modify the commit message changes since v3: - addressed comments from Sean Paul <seanpaul(a)chromium.org>, to modify the return values and print messages. changes since v2: - moved 'devm_pinctrl_get_select_default' function call under 'if (pdev->dev.of_node)', this makes NON-DT code unchanged. (reported by: Rahul Sharma <r.sh.open(a)gmail.com>) changes since v1: - addressed comments from Sean Paul <seanpaul(a)chromium.org> Vikas Sajjan (2): video: drm: exynos: Add display-timing node parsing using video helper function video: drm: exynos: Add pinctrl support to fimd drivers/gpu/drm/exynos/exynos_drm_fimd.c | 33 ++++++++++++++++++++++++++---- 1 file changed, 29 insertions(+), 4 deletions(-) -- 1.7.9.5

5 6

radeon_gem_object_create:69 alloc size 139Mb bigger than 128Mb limit (RS780)
by Markus Trippelsdorf 28 Feb '13

28 Feb '13

Running the latest Linus git kernel I occasionally see the following warning: radeon_gem_object_create:69 alloc size 139Mb bigger than 128Mb limit >From dmesg: [drm] Initialized drm 1.1.0 20060810 [drm] radeon kernel modesetting enabled. [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D). [drm] register mmio base: 0xFBEE0000 [drm] register mmio size: 65536 ATOM BIOS: 113 radeon 0000:01:05.0: VRAM: 128M 0x00000000C0000000 - 0x00000000C7FFFFFF (128M used) radeon 0000:01:05.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 32bits DDR [TTM] Zone kernel: Available graphics memory: 4083398 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator [drm] radeon: 128M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RS780 Microcode [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000). radeon 0000:01:05.0: WB enabled radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x00000000a0000c00 and cpu addr 0xffff8802163d1c00 radeon 0000:01:05.0: fence driver on ring 3 use gpu addr 0x00000000a0000c0c and cpu addr 0xffff8802163d1c0c radeon 0000:01:05.0: setting latency timer to 64 [drm] ring test on 0 succeeded in 1 usecs [drm] ring test on 3 succeeded in 1 usecs [drm] ib test on ring 0 succeeded in 0 usecs [drm] ib test on ring 3 succeeded in 0 usecs [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA-1 [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 1: [drm] DVI-D-1 [drm] HPD3 [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [drm] Encoders: [drm] DFP3: INTERNAL_KLDSCP_LVTMA [drm] radeon: power management initialized [drm] fb mappable at 0xF0142000 [drm] vram apper at 0xF0000000 [drm] size 7299072 [drm] fb depth is 24 [drm] pitch is 6912 -- Markus

1 0

[RFD] Proposal for merging Android sync driver in staging
by John Stultz 28 Feb '13

28 Feb '13

I'd like to get a discussion going about submitting the Android sync driver to staging. I know there is currently some very similar work going on with the dmabuf-fences, and rather then both approaches being worked out individually on their own, I suspect there could be better collaboration around this effort. So my proposal is that we merge the Android sync driver into staging. In my mind, this has the following benefits: 1) It allows other drivers that depend on the sync interface to also be submitted to staging, rather then forcing those drivers to be hidden away in various out of tree git repos, location unknown. 2) It would provide a baseline view to the upstream community of the interface Android is using, providing a real-world, active use case of the functionality. Once the sync driver is in staging, if the dmabuf-fences work is fully sufficient to replace the Android sync driver, we should be able to whittle down the sync driver until its just a interface shim (and at which point efforts can be made to convert Android userland over to dmabuf-fences). However, if the dmabuf-fences work is not fully sufficient to replace the android sync driver, we should be able to at least to whittle down the driver to those specific differences, which would provide a concrete example of where the dmabuf-fences, or other work may need to be expanded, or if maybe the sync driver is the better approach. I've gone through the Android tree and reworked the sync driver to live in staging, while still preserving the full patch history/authorship. You can checkout the reworked patch queue here: http://git.linaro.org/gitweb?p=people/jstultz/android-dev.git;a=shortlog;h=… If folks would take a look and let me know what they think of the changes as well as what they think about pushing it to staging, or other ideas for how to improve collaboration so we can have common interfaces here, I'd appreciate it. Also note: I've done this so far without any feedback from the Android devs (despite my reaching out to Erik a few times recently), so if they object to pushing it to staging, in deference to it being their code I'll back off, even though I do think it would be good to have the code get more visibility upstream in staging. I don't mean to step on anyone's toes. :) thanks -john

3 3

[Bug 59982] New: Radeon: evergreen Atombios in loop during initialization on ppc64
by bugzilla-daemon＠freedesktop.org 28 Feb '13

28 Feb '13

https://bugs.freedesktop.org/show_bug.cgi?id=59982 Priority: medium Bug ID: 59982 Assignee: dri-devel(a)lists.freedesktop.org Summary: Radeon: evergreen Atombios in loop during initialization on ppc64 Severity: normal Classification: Unclassified OS: All Reporter: lucaskt(a)linux.vnet.ibm.com Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 73788 --> https://bugs.freedesktop.org/attachment.cgi?id=73788&action=edit Log for module insertion errors on mainline During the initialization of an evergreen adapter on ppc64 there are a lot of atombios problems reported, though none seems fatal. This is in sequence to bug #59672. Though this is now being run on the 3.8.0-rc5 kernel. The problem is basically a bunch of messages like: [ 854.915511] [drm:drm_vblank_get], enabling vblank on crtc 0, ret: 0 [ 854.915520] [drm:drm_calc_vbltimestamp_from_scanoutpos], crtc 0: Noop due to uninitialized mode. [ 854.915526] [drm:drm_update_vblank_count], enabling vblank interrupts on crtc 0, missed -1 [ 859.924406] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [ 859.924416] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing C898 (len 62, WS 0, PS 0) @ 0xC8B4 A full dump is included as an attachment. -- You are receiving this mail because: You are the assignee for the bug.

1 33

[PATCH] Fix build of swrast only without libdrm
by Daniel Martin 28 Feb '13

28 Feb '13

Signed-off-by: Daniel Martin <consume.noise(a)gmail.com> --- There's a small logic error preventing mesa to be build with swrast only and not having libdrm. configure.ac | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 5701f8a..aa1b38a 100644 --- a/configure.ac +++ b/configure.ac @@ -1089,7 +1089,7 @@ if test "x$enable_dri" = xyes; then fi # if we are building any dri driver other than swrast or using the dri state tracker ... - if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast || test "x$enable_dri" = xyes; then + if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast && test "x$enable_dri" = xyes; then # ... libdrm is required if test "x$have_libdrm" != xyes; then AC_MSG_ERROR([DRI drivers requires libdrm >= $LIBDRM_REQUIRED]) -- 1.7.2.5

2 1

[PATCH 0/9] System Framebuffer Bus (sysfb)
by David Herrmann 28 Feb '13

28 Feb '13

Hi This series tries to fix the mess with global system framebuffer access in device drivers. Currently, architecture initialization sets the "screen_info" object according to the system framebuffer that was detected during boot. The device driver that can map VMEM first gets access to it. There is no way to give a specific driver access to the device and no _proper_ way to revoke access again. In fact, some drivers don't even check whether they mapped the VMEM successfully, letting multiple drivers to access the system framebuffer at the same time. This series introduces a new bus in patch #1. Global system framebuffers are added as devices to this bus and drivers can register as bus drivers. Via sysfs we can now bind/unbind the drivers. This guarantees that only one driver has access to a single system-framebuffer at a time. But we can also easily control which driver gets loaded (and extend this logic at a central place if we want). If a real hardware drivers gets loaded via another bus that actually provides the system-framebuffer (like pci-bus), these drivers can use a special BUS function to claim the system framebuffer and unload all other drivers from this device. This can be used by _real_ DRM drivers that want to kill all other generic framebuffer drivers. This series adds a SYSFB_VBE (VESA/VBE) framebuffer type as example, but the bus can be used with any other system-framebuffer type. Any other architecture can add their own type like SYSFB_VBE. Patch #3 is currently a HACK to provide the VBE framebuffer on all architectures. However, the platform-device for system-framebuffers should instead be provided by architecture code. Why a new BUS type? We need a way to allow transition from a generic driver to a real hardware driver (like most DRM drivers or special fbdev drivers). We could implement this logic separately, but the BUS driver-core code is available, anyway. So lets use it and save a lot of .text space. Additionally, we get some extra features like driver binding/unbinding via sysfs for free (which is really handy for debugging). The new bus is actually implemented in <200 lines of code. I don't think we can get a smaller implementation when not using the bus-core code. Patch #4 fixes vesafb.c to be hotplug-capable. It doesn't depend on this new bus so it would be nice if it could get applied right away. It allows vesafb to be compiled as a module. Patch #5 makes vesafb.c register as new bus driver on the system-framebuffer bus. Patch #6-#9 introduce DVBE. It's a DRM driver based on VBE/VESA. It also uses the new system-framebuffer bus and provides merely the same functionality as vesafb.c but with a sane user-space API and without any fbdev dependency. What needs to be done? All drivers that use screen_info currently don't _have_ to be converted to the new bus as the request_memory() calls protect the drivers from interfering. So this new bus works even if no other driver gets converted. However, we really _should_ convert the drivers. I will do that if a maintainer agrees to take the bus code through their tree. But I hope to avoid converting all drivers if no maintainer thinks this bus is a good idea. The DVBE and vesafb drivers show how it is done. I also like to see the system-framebuffer platform-devices being registered during architecture initialization. I haven't worked much there so any comments are welcome. Otherwise, I will keep the HACK to add the devices during sysfb module-init. Regards David David Herrmann (9): video: introduce system framebuffer bus video: sysfb: new vbefb device type video: sysfb: always provide vbefb device video: vesafb: allow building as module video: vesafb: use sysfb bus drm: new sysfb DRM bus module drm: new VESA BIOS Extension DRM driver stub drm: dvbe: implement VBE/VESA blitting backend drm: dvbe: add optional fbdev frontend drivers/gpu/drm/Kconfig | 7 + drivers/gpu/drm/Makefile | 2 + drivers/gpu/drm/drm_sysfb.c | 145 +++++++++++++ drivers/gpu/drm/dvbe/Kconfig | 47 +++++ drivers/gpu/drm/dvbe/Makefile | 5 + drivers/gpu/drm/dvbe/dvbe.h | 121 +++++++++++ drivers/gpu/drm/dvbe/dvbe_drv.c | 104 +++++++++ drivers/gpu/drm/dvbe/dvbe_fbdev.c | 235 +++++++++++++++++++++ drivers/gpu/drm/dvbe/dvbe_main.c | 432 ++++++++++++++++++++++++++++++++++++++ drivers/gpu/drm/dvbe/dvbe_mem.c | 269 ++++++++++++++++++++++++ drivers/gpu/drm/dvbe/dvbe_vesa.c | 263 +++++++++++++++++++++++ drivers/video/Kconfig | 20 +- drivers/video/Makefile | 1 + drivers/video/sysfb.c | 315 +++++++++++++++++++++++++++ drivers/video/vesafb.c | 105 ++++----- include/drm/drmP.h | 4 + include/drm/drm_sysfb.h | 35 +++ include/linux/sysfb.h | 137 ++++++++++++ 18 files changed, 2197 insertions(+), 50 deletions(-) create mode 100644 drivers/gpu/drm/drm_sysfb.c create mode 100644 drivers/gpu/drm/dvbe/Kconfig create mode 100644 drivers/gpu/drm/dvbe/Makefile create mode 100644 drivers/gpu/drm/dvbe/dvbe.h create mode 100644 drivers/gpu/drm/dvbe/dvbe_drv.c create mode 100644 drivers/gpu/drm/dvbe/dvbe_fbdev.c create mode 100644 drivers/gpu/drm/dvbe/dvbe_main.c create mode 100644 drivers/gpu/drm/dvbe/dvbe_mem.c create mode 100644 drivers/gpu/drm/dvbe/dvbe_vesa.c create mode 100644 drivers/video/sysfb.c create mode 100644 include/drm/drm_sysfb.h create mode 100644 include/linux/sysfb.h -- 1.8.1.3

3 14

[PATCH v8 0/2] Add display-timing node parsing to exynos drm fimd
by Vikas Sajjan 28 Feb '13

28 Feb '13

Add display-timing node parsing to drm fimd and depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html It also adds pinctrl support for drm fimd. changes since v7: - addressed comments from Joonyoung Shim <jy0922.shim(a)samsung.com> to remove a unnecessary variable. changes since v6: addressed comments from Inki Dae <inki.dae(a)samsung.com> to separated out the pinctrl functionality and made a separate patch. changes since v5: - addressed comments from Inki Dae <inki.dae(a)samsung.com>, to remove the allocation of 'fbmode' and replaced '-1'in "of_get_fb_videomode(dev->of_node, fbmode, -1)" with OF_USE_NATIVE_MODE. changes since v4: - addressed comments from Paul Menzel <paulepanter(a)users.sourceforge.net>, to modify the commit message changes since v3: - addressed comments from Sean Paul <seanpaul(a)chromium.org>, to modify the return values and print messages. changes since v2: - moved 'devm_pinctrl_get_select_default' function call under 'if (pdev->dev.of_node)', this makes NON-DT code unchanged. (reported by: Rahul Sharma <r.sh.open(a)gmail.com>) changes since v1: - addressed comments from Sean Paul <seanpaul(a)chromium.org> Vikas Sajjan (2): video: drm: exynos: Add display-timing node parsing using video helper function video: drm: exynos: Add pinctrl support to fimd drivers/gpu/drm/exynos/exynos_drm_fimd.c | 34 ++++++++++++++++++++++++++---- 1 file changed, 30 insertions(+), 4 deletions(-) -- 1.7.9.5

4 8

[PATCH v4 0/9] drm/tegra: Miscellaneous enhancements
by Thierry Reding 28 Feb '13

28 Feb '13

This patch series introduces a number of useful features for the Tegra DRM driver. Patch 1 is a documentation update and adds a warning to the page-flip IOCTL to catch buggy drivers that return success but failed to update the crtc->fb field, which would cause the reference counting to become unbalanced. Patch 2 removes usage of the tegra_framebuffer structure which was used before the driver moved to the CMA FB helpers. It is wrong to use it but it happens to work because the drm_fb_cma and tegra_framebuffers were sufficiently similar. Patch 3 adds support for the additional two planes available on Tegra hardware, while patch 4 implement .mode_set_base() to allow for some nice speed up when changing the framebuffer without actually changing the resolution. Patch 5 adds VBLANK support and patch 6 builds on the previous two to provide the page-flipping IOCTL. Patch 7 splits the DC_CMD_STATE_CONTROL register writes into two consecutive writes as required by the TRM. Finally patch 8 fixes color expansions for pixel formats with less than 24 bits per pixel and patch 9 adds a new file, named "framebuffers" to debugfs which can be used to dump a list of framebuffers attached to the DRM device. This is most useful to inspect the reference count but could also be helpful in diagnosing out-of-memory conditions and such. This series is based on Dave's drm-next branch. Thierry Thierry Reding (9): drm: Add consistency check for page-flipping drm/tegra: Remove bogus tegra_framebuffer structure drm/tegra: Add plane support drm/tegra: Implement .mode_set_base() drm/tegra: Implement VBLANK support drm/tegra: Implement page-flipping support drm/tegra: Split DC_CMD_STATE_CONTROL register write drm/tegra: Fix color expansion drm/tegra: Add list of framebuffers to debugfs Documentation/DocBook/drm.tmpl | 6 + drivers/gpu/drm/drm_crtc.c | 7 + drivers/gpu/drm/tegra/dc.c | 585 +++++++++++++++++++++++++++++++++-------- drivers/gpu/drm/tegra/dc.h | 14 +- drivers/gpu/drm/tegra/drm.c | 103 ++++++++ drivers/gpu/drm/tegra/drm.h | 43 ++- 6 files changed, 635 insertions(+), 123 deletions(-) -- 1.8.1.2

3 12

resume fails to light display on Macbook Pro Retina on 3.8-rc1
by Greg KH 28 Feb '13

28 Feb '13

Hi Ben, My Macbook Pro Retina fails to resume properly on 3.8. I tracked this down to commit 6c5a04249d7afeea3e0ed971e7813f84e29a1706 (drm/nvd0/disp: move link training helpers into core as display methods) Anything I can try to help solve this? Note, I'm using the Intel driver as the main controller for this laptop, well, I think I am, my xorg log is attached. And sorry for not reporting this sooner, it took me a long time to bisect down, there were other resume and boot issues on the bisect trail leading to this, the full log is below. thanks, greg k-h git bisect start # good: [29594404d7fe73cd80eaa4ee8c43dcc53970c60e] Linux 3.7 git bisect good 29594404d7fe73cd80eaa4ee8c43dcc53970c60e # bad: [19f949f52599ba7c3f67a5897ac6be14bfcb1200] Linux 3.8 git bisect bad 19f949f52599ba7c3f67a5897ac6be14bfcb1200 # good: [dadfab4873256d2145640c0ce468fcbfb48977fe] Merge tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 git bisect good dadfab4873256d2145640c0ce468fcbfb48977fe # bad: [992956189de58cae9f2be40585bc25105cd7c5ad] efi: Fix the build with user namespaces enabled. git bisect bad 992956189de58cae9f2be40585bc25105cd7c5ad # skip: [2b8318881ddbcb67c5e8d2178b42284749442222] Merge tag 'fbdev-for-3.8' of git://gitorious.org/linux-omap-dss2/linux git bisect skip 2b8318881ddbcb67c5e8d2178b42284749442222 # good: [da22f22e91f0d14d996c7258101575a5a06ddf85] ssb: add ssb_chipco_gpio_pull{up,down} git bisect good da22f22e91f0d14d996c7258101575a5a06ddf85 # good: [bb523fc08d4a4a726c7555be7800735685888b3c] drm/i915: convert PIPE_CLK_SEL to transcoder git bisect good bb523fc08d4a4a726c7555be7800735685888b3c # good: [d3e4ea017a414a19ab11a10b52e80a0c8b3f1670] [media] em28xx-cards: fix a warning git bisect good d3e4ea017a414a19ab11a10b52e80a0c8b3f1670 # good: [3fcb6eb4063ab4eef05601c266afa2af667c8e1f] video: exynos_dp: remove redundant parameters git bisect good 3fcb6eb4063ab4eef05601c266afa2af667c8e1f # good: [c5b005ab7091c9ef4ca9b47569a8e27e54588933] drbd: use bitmap_parse instead of __bitmap_parse git bisect good c5b005ab7091c9ef4ca9b47569a8e27e54588933 # skip: [c13e69b2f0e1e2da41a175c7e9215659842cbef9] Merge tag 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev git bisect skip c13e69b2f0e1e2da41a175c7e9215659842cbef9 # good: [c8241969b44438c9335b59d375b627214bc36483] drm/i915: pass adjusted_mode to intel_choose_pipe_bpp_dither(), again git bisect good c8241969b44438c9335b59d375b627214bc36483 # skip: [c5258190c2ae664cdf367417a2a25e5fa4104322] Merge branch 'next' of git://git.monstr.eu/linux-2.6-microblaze git bisect skip c5258190c2ae664cdf367417a2a25e5fa4104322 # good: [24ebb37e6515d999bb27f5f8de6ff30faa7479f5] HID: i2c-hid: change I2C name git bisect good 24ebb37e6515d999bb27f5f8de6ff30faa7479f5 # good: [189e11731aa858597095fbe1e6d243bad26bd96b] x86: pvclock: add note about rdtsc barriers git bisect good 189e11731aa858597095fbe1e6d243bad26bd96b # skip: [75e300c8ba5864367634d946c729d8fd05c1cbc2] Merge tag 'for-v3.8' of git://git.infradead.org/users/cbou/linux-pstore git bisect skip 75e300c8ba5864367634d946c729d8fd05c1cbc2 # good: [08ff32352d6ff7083533dc1c25618d42f92ec28e] mlx4: 64-byte CQE/EQE support git bisect good 08ff32352d6ff7083533dc1c25618d42f92ec28e # skip: [e81d372ff9f694e13fa46e8b5aaed505c7fd2a1f] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds git bisect skip e81d372ff9f694e13fa46e8b5aaed505c7fd2a1f # good: [fc8d7547b1e19e1bb8f3206837ee0c7c6538e2e5] RDMA/nes: Fix for sending fpdus in order to hardware git bisect good fc8d7547b1e19e1bb8f3206837ee0c7c6538e2e5 # good: [4247bfe20ab1cb8cf1874b811c0dc60bcd0249e8] Merge remote-tracking branch 'regulator/topic/stub' into regulator-next git bisect good 4247bfe20ab1cb8cf1874b811c0dc60bcd0249e8 # good: [5028ea04c8a8a67fe73f18f5f34386730c9c1bf2] OMAPDSS: Remove acb and acbi fields from omap_dss_device git bisect good 5028ea04c8a8a67fe73f18f5f34386730c9c1bf2 # good: [986836503e49ccf7e84b813715d344964ec93566] Merge branch 'drbd-8.4_ed6' into for-3.8-drivers-drbd-8.4_ed6 git bisect good 986836503e49ccf7e84b813715d344964ec93566 # bad: [9add1ac3dd256ad12e266f8403daf928be19953f] Merge branch 'drm-next-3.8' of git://people.freedesktop.org/~agd5f/linux into drm-next git bisect bad 9add1ac3dd256ad12e266f8403daf928be19953f # good: [1f2285d462c02ef9b82ee9c553a31884c23994f0] drm/nouveau/clk: fix crystal frequency retrieval on nv25 git bisect good 1f2285d462c02ef9b82ee9c553a31884c23994f0 # bad: [bd3b49f25a3eae2d91432247b7565489120b6bcf] drm: tegra: Add maintainers entry git bisect bad bd3b49f25a3eae2d91432247b7565489120b6bcf # bad: [6c8e4633d351f6f794c8a5c03f19e8d5a25f9639] drm/nouveau/dp: move core link training calls to common code git bisect bad 6c8e4633d351f6f794c8a5c03f19e8d5a25f9639 # good: [b6caea505879c4a606cf364442fd1f06f6c40e30] drm/nouveau/bios: implement BIT 'U' table (and subtable) parsing in core git bisect good b6caea505879c4a606cf364442fd1f06f6c40e30 # skip: [ed58aee93c45d5095253d9bc370b418e3d767940] drm/nvd0/disp: handle DP transfer unit setup from second supervisor interrupt git bisect skip ed58aee93c45d5095253d9bc370b418e3d767940 # skip: [4a230fa61884ffe6b6a806563eee82f12a60fa1e] drm/nvd0/disp: calculate U script id in supervisor interrupt git bisect skip 4a230fa61884ffe6b6a806563eee82f12a60fa1e # bad: [0a9e2b959f2a1673ca9315df8e0b6dec1069060e] drm/nvd0/disp: move HDA codec setup to core git bisect bad 0a9e2b959f2a1673ca9315df8e0b6dec1069060e # good: [cbe7270d48670889a88705478a68d000b0bc3f6e] drm/nouveau/core: expose full method calling capabilities with nv_exec git bisect good cbe7270d48670889a88705478a68d000b0bc3f6e # bad: [6c5a04249d7afeea3e0ed971e7813f84e29a1706] drm/nvd0/disp: move link training helpers into core as display methods git bisect bad 6c5a04249d7afeea3e0ed971e7813f84e29a1706 # good: [fb445b3c23a4ae75190e814d952be6dce6181abe] drm/nouveau/core: allow representing method ranges in nouveau_omthds git bisect good fb445b3c23a4ae75190e814d952be6dce6181abe

4 13

← Newer
1
...
45
46
47
48
49
50
51
...
70
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2013