config FB_OMAP tristate "OMAP frame buffer support" depends on FB depends on ARCH_OMAP1 select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT help Frame buffer driver for OMAP based boards. config FB_OMAP_LCDC_EXTERNAL bool "External LCD controller support" depends on FB_OMAP help Say Y here, if you want to have support for boards with an external LCD controller connected to the SoSSI/RFBI interface. config FB_OMAP_LCDC_HWA742 bool "Epson HWA742 LCD controller support" depends on FB_OMAP && FB_OMAP_LCDC_EXTERNAL help Say Y here if you want to have support for the external Epson HWA742 LCD controller. config FB_OMAP_MANUAL_UPDATE bool "Default to manual update mode" depends on FB_OMAP && FB_OMAP_LCDC_EXTERNAL help Say Y here, if your user-space applications are capable of notifying the frame buffer driver when a change has occurred in the frame buffer content and thus a reload of the image data to the external frame buffer is required. If unsure, say N. config FB_OMAP_LCD_MIPID bool "MIPI DBI-C/DCS compatible LCD support" depends on FB_OMAP && SPI_MASTER help Say Y here if you want to have support for LCDs compatible with the Mobile Industry Processor Interface DBI-C/DCS specification. (Supported LCDs: Philips LPH8923, Sharp LS041Y3) config FB_OMAP_LCD_H3 bool "TPS65010 LCD controller on OMAP-H3" depends on MACH_OMAP_H3 depends on TPS65010=y default y help Say Y here if you want to have support for the LCD on the H3 board. config FB_OMAP_DMA_TUNE bool "Set DMA SDRAM access priority high" depends on FB_OMAP help On systems in which video memory is in system memory (SDRAM) this will speed up graphics DMA operations. If you have such a system and want to use rotation answer yes. Answer no if you have a dedicated video memory, or don't use any of the accelerated features. mp;id=ca92e6c7e6329029d7188487a5c32e86ef471977'>treecommitdiff
path: root/net/ceph/osdmap.c
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2017-01-18 11:13:41 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2017-01-18 11:13:41 -0800
commitca92e6c7e6329029d7188487a5c32e86ef471977 (patch)
tree704fb5c2ca533cdb569826522eed0dbbcf31f316 /net/ceph/osdmap.c
parent0b75f821ec8be459dd4dec77be39595d989d77ac (diff)
parent4205e4786d0b9fc3b4fec7b1910cf645a0468307 (diff)
Merge branch 'smp-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull SMP hotplug update from Thomas Gleixner: "This contains a trivial typo fix and an extension to the core code for dynamically allocating states in the prepare stage. The extension is necessary right now because we need a proper way to unbreak LTTNG, which iscurrently non functional due to the removal of the notifiers. Surely it's out of tree, but it's widely used by distros. The simple solution would have been to reserve a state for LTTNG, but I'm not fond about unused crap in the kernel and the dynamic range, which we admittedly should have done right away, allows us to remove quite some of the hardcoded states, i.e. those which have no ordering requirements. So doing the right thing now is better than having an smaller intermediate solution which needs to be reworked anyway" * 'smp-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: cpu/hotplug: Provide dynamic range for prepare stage perf/x86/amd/ibs: Fix typo after cleanup state names in cpu/hotplug
Diffstat (limited to 'net/ceph/osdmap.c')
ls/power turbostat: tidy up output on Joule counter overflow
Diffstat (limited to 'include/net/irda/qos.h')