/* * Copyright (C) 2009 Marvell International Ltd. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ #ifndef __ASM_MACH_PXA168FB_H #define __ASM_MACH_PXA168FB_H #include #include /* Dumb interface */ #define PIN_MODE_DUMB_24 0 #define PIN_MODE_DUMB_18_SPI 1 #define PIN_MODE_DUMB_18_GPIO 2 #define PIN_MODE_DUMB_16_SPI 3 #define PIN_MODE_DUMB_16_GPIO 4 #define PIN_MODE_DUMB_12_SPI_GPIO 5 #define PIN_MODE_SMART_18_SPI 6 #define PIN_MODE_SMART_16_SPI 7 #define PIN_MODE_SMART_8_SPI_GPIO 8 /* Dumb interface pin allocation */ #define DUMB_MODE_RGB565 0 #define DUMB_MODE_RGB565_UPPER 1 #define DUMB_MODE_RGB666 2 #define DUMB_MODE_RGB666_UPPER 3 #define DUMB_MODE_RGB444 4 #define DUMB_MODE_RGB444_UPPER 5 #define DUMB_MODE_RGB888 6 /* default fb buffer size WVGA-32bits */ #define DEFAULT_FB_SIZE (800 * 480 * 4) /* * Buffer pixel format * bit0 is for rb swap. * bit12 is for Y UorV swap */ #define PIX_FMT_RGB565 0 #define PIX_FMT_BGR565 1 #define PIX_FMT_RGB1555 2 #define PIX_FMT_BGR1555 3 #define PIX_FMT_RGB888PACK 4 #define PIX_FMT_BGR888PACK 5 #define PIX_FMT_RGB888UNPACK 6 #define PIX_FMT_BGR888UNPACK 7 #define PIX_FMT_RGBA888 8 #define PIX_FMT_BGRA888 9 #define PIX_FMT_YUV422PACK 10 #define PIX_FMT_YVU422PACK 11 #define PIX_FMT_YUV422PLANAR 12 #define PIX_FMT_YVU422PLANAR 13 #define PIX_FMT_YUV420PLANAR 14 #define PIX_FMT_YVU420PLANAR 15 #define PIX_FMT_PSEUDOCOLOR 20 #define PIX_FMT_UYVY422PACK (0x1000|PIX_FMT_YUV422PACK) /* * PXA LCD controller private state. */ struct pxa168fb_info { struct device *dev; struct clk *clk; struct fb_info *info; void __iomem *reg_base; dma_addr_t fb_start_dma; u32 pseudo_palette[16]; int pix_fmt; unsigned is_blanked:1; unsigned panel_rbswap:1; unsigned active:1; }; /* * PXA fb machine information */ struct pxa168fb_mach_info { char id[16]; int num_modes; struct fb_videomode *modes; /* * Pix_fmt */ unsigned pix_fmt; /* * I/O pin allocation. */ unsigned io_pin_allocation_mode:4; /* * Dumb panel -- assignment of R/G/B component info to the 24 * available external data lanes. */ unsigned dumb_mode:4; unsigned panel_rgb_reverse_lanes:1; /* * Dumb panel -- GPIO output data. */ unsigned gpio_output_mask:8; unsigned gpio_output_data:8; /* * Dumb panel -- configurable output signal polarity. */ unsigned invert_composite_blank:1; unsigned invert_pix_val_ena:1; unsigned invert_pixclock:1; unsigned panel_rbswap:1; unsigned active:1; unsigned enable_lcd:1; }; #endif /* __ASM_MACH_PXA168FB_H */ s='txt' type='search' size='10' name='q' value=''/>
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2017-01-29 13:50:06 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2017-01-29 13:50:06 -0800
commit39cb2c9a316e77f6dfba96c543e55b6672d5a37e (patch)
tree98fe974ee4e20121253de7f61fc8d01bdb3821c1 /include/acpi/acpi.h
parent2c5d9555d6d937966d79d4c6529a5f7b9206e405 (diff)
drm/i915: Check for NULL i915_vma in intel_unpin_fb_obj()
I've seen this trigger twice now, where the i915_gem_object_to_ggtt() call in intel_unpin_fb_obj() returns NULL, resulting in an oops immediately afterwards as the (inlined) call to i915_vma_unpin_fence() tries to dereference it. It seems to be some race condition where the object is going away at shutdown time, since both times happened when shutting down the X server. The call chains were different: - VT ioctl(KDSETMODE, KD_TEXT): intel_cleanup_plane_fb+0x5b/0xa0 [i915] drm_atomic_helper_cleanup_planes+0x6f/0x90 [drm_kms_helper] intel_atomic_commit_tail+0x749/0xfe0 [i915] intel_atomic_commit+0x3cb/0x4f0 [i915] drm_atomic_commit+0x4b/0x50 [drm] restore_fbdev_mode+0x14c/0x2a0 [drm_kms_helper] drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x80 [drm_kms_helper] drm_fb_helper_set_par+0x2d/0x60 [drm_kms_helper] intel_fbdev_set_par+0x18/0x70 [i915] fb_set_var+0x236/0x460 fbcon_blank+0x30f/0x350 do_unblank_screen+0xd2/0x1a0 vt_ioctl+0x507/0x12a0 tty_ioctl+0x355/0xc30 do_vfs_ioctl+0xa3/0x5e0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x13/0x94 - i915 unpin_work workqueue: intel_unpin_work_fn+0x58/0x140 [i915] process_one_work+0x1f1/0x480 worker_thread+0x48/0x4d0 kthread+0x101/0x140 and this patch purely papers over the issue by adding a NULL pointer check and a WARN_ON_ONCE() to avoid the oops that would then generally make the machine unresponsive. Other callers of i915_gem_object_to_ggtt() seem to also check for the returned pointer being NULL and warn about it, so this clearly has happened before in other places. [ Reported it originally to the i915 developers on Jan 8, applying the ugly workaround on my own now after triggering the problem for the second time with no feedback. This is likely to be the same bug reported as https://bugs.freedesktop.org/show_bug.cgi?id=98829 https://bugs.freedesktop.org/show_bug.cgi?id=99134 which has a patch for the underlying problem, but it hasn't gotten to me, so I'm applying the workaround. ] Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'include/acpi/acpi.h')