aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/video (follow)
AgeCommit message (Collapse)AuthorFilesLines
2015-07-10stifb: Implement hardware accelerated copyareaAlex Ivanov1-2/+38
This patch adds hardware assisted scrolling. The code is based upon the following investigation: https://parisc.wiki.kernel.org/index.php/NGLE#Blitter A simple 'time ls -la /usr/bin' test shows 1.6x speed increase over soft copy and 2.3x increase over FBINFO_READS_FAST (prefer soft copy over screen redraw) on Artist framebuffer. Signed-off-by: Alex Ivanov <lausgans@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2015-07-03Merge tag 'fbdev-fixes-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linuxLinus Torvalds1-0/+9
Pull fbdev fix from Tomi Valkeinen: "Fix display regression on TI AM4xxx boards" * tag 'fbdev-fixes-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: OMAPDSS: fix probing if rfbi device is enabled
2015-07-02OMAPDSS: fix probing if rfbi device is enabledTomi Valkeinen1-0/+9
After the commit 736e60ddc215b85e73bbf7da26e1cde84cc9500f ("OMAPDSS: componentize omapdss") the dss core device will wait until all the subdevices have been successfully probed. However, we don't have a working driver for RFBI, so if RFBI device exists, omapdss will never get probed. All the .dtsi files set RFBI as disabled, except am4372.dtsi. This causes omapdss probe to not finish on AM4 devices. This patch makes omapdss driver skip adding rfbi device as a subcomponent, solving the issue. This should be reverted when we have a working RFBI driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Felipe Balbi <balbi@ti.com>
2015-07-01Merge tag 'modules-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linuxLinus Torvalds2-3/+3
Pull module updates from Rusty Russell: "Main excitement here is Peter Zijlstra's lockless rbtree optimization to speed module address lookup. He found some abusers of the module lock doing that too. A little bit of parameter work here too; including Dan Streetman's breaking up the big param mutex so writing a parameter can load another module (yeah, really). Unfortunately that broke the usual suspects, !CONFIG_MODULES and !CONFIG_SYSFS, so those fixes were appended too" * tag 'modules-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: (26 commits) modules: only use mod->param_lock if CONFIG_MODULES param: fix module param locks when !CONFIG_SYSFS. rcu: merge fix for Convert ACCESS_ONCE() to READ_ONCE() and WRITE_ONCE() module: add per-module param_lock module: make perm const params: suppress unused variable error, warn once just in case code changes. modules: clarify CONFIG_MODULE_COMPRESS help, suggest 'N'. kernel/module.c: avoid ifdefs for sig_enforce declaration kernel/workqueue.c: remove ifdefs over wq_power_efficient kernel/params.c: export param_ops_bool_enable_only kernel/params.c: generalize bool_enable_only kernel/module.c: use generic module param operaters for sig_enforce kernel/params: constify struct kernel_param_ops uses sysfs: tightened sysfs permission checks module: Rework module_addr_{min,max} module: Use __module_address() for module_address_lookup() module: Make the mod_tree stuff conditional on PERF_EVENTS || TRACING module: Optimize __module_address() using a latched RB-tree rbtree: Implement generic latch_tree seqlock: Introduce raw_read_seqcount_latch() ...
2015-06-26Merge tag 'tty-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/ttyLinus Torvalds2-2/+4
Pull tty/serial driver updates from Greg KH: "Here's the tty and serial driver patches for 4.2-rc1. A number of individual driver updates, some code cleanups, and other minor things, full details in the shortlog. All have been in linux-next for a while with no reported issues" * tag 'tty-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (152 commits) Doc: serial-rs485.txt: update RS485 driver interface Doc: tty.txt: remove mention of the BKL MAINTAINERS: tty: add serial docs directory serial: sprd: check for NULL after calling devm_clk_get serial: 8250_pci: Correct uartclk for xr17v35x expansion chips serial: 8250_pci: Add support for 12 port Exar boards serial: 8250_uniphier: add bindings document for UniPhier UART serial: core: cleanup in uart_get_baud_rate() serial: stm32-usart: Add STM32 USART Driver tty/serial: kill off set_irq_flags usage tty: move linux/gsmmux.h to uapi doc: dt: add documentation for nxp,lpc1850-uart serial: 8250: add LPC18xx/43xx UART driver serial: 8250_uniphier: add UniPhier serial driver serial: 8250_dw: support ACPI platforms with integrated DMA engine serial: of_serial: check the return value of clk_prepare_enable() serial: of_serial: use devm_clk_get() instead of clk_get() serial: earlycon: Add support for big-endian MMIO accesses serial: sirf: use hrtimer for data rx serial: sirf: correct the fifo empty_bit ...
2015-06-24Merge tag 'backlight-for-linus-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlightLinus Torvalds5-20/+16
Pull backlight updates from Lee Jones: "Changes to existing drivers: - supply MODULE_DEVICE_TABLE() to ensure probing - constify struct; da9052_bl - enable compile test; lcd_l4f00242t03, lcd_lms283fg05, backlight_gpio - suspend/resume bugfix; lp855x_bl - devm_gpiod_get_optional() API fixup; pwm_bl - error handling fixup; backlight" * tag 'backlight-for-linus-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight: backlight: Change the return type of backlight_update_status() to int backlight: pwm_bl: Simplify usage of devm_gpiod_get_optional backlight: lp855x: Don't clear level on suspend/blank backlight: Allow compile test of GPIO consumers if !GPIOLIB video: backlight: da9052: Constify platform_device_id gpio-backlight: Discover driver during boot time
2015-06-23Merge tag 'fbdev-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linuxLinus Torvalds69-6507/+948
Pull fbdev updates from Tomi Valkeinen: - ssd1307fb: various fixes and improvements, SSD1305 support - use architecture agnostic functions instead of MTRR functions in various fbdev drivers - TI DRA7xx SoC display support (arch/arm/ side) - OMAPDSS componentization to fix probing order issues - OMAPDSS scaling fixes - msm_fb: remove obsoleted driver * tag 'fbdev-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: (77 commits) msm: msm_fb: Remove dead code OMAPDSS: HDMI: wait for framedone when stopping video OMAPDSS: HDMI4: fix error handling OMAPDSS: DISPC: scaler debug print OMAPDSS: DISPC: do only y decimation on OMAP3 OMAPDSS: DISPC: check if scaling setup failed OMAPDSS: DISPC: fix 64 bit issue in 5-tap OMAPDSS: DISPC: fix row_inc for OMAP3 OMAPDSS: DISPC: add check for scaling limits OMAPDSS: DISPC: fix check_horiz_timing_omap3 args OMAPDSS: DISPC: fix predecimation for YUV modes OMAPDSS: DISPC: work-around for errata i631 OMAPDSS: simplify submodule reg/unreg code OMAPDSS: componentize omapdss OMAPDSS: reorder uninit calls OMAPDSS: remove uses of __init/__exit OMAPDSS: fix dss_init_ports error handling OMAPDSS: refactor dss probe function OMAPDSS: move 'dss_initialized' to dss driver fbdev: propagate result of fb_videomode_from_videomode() ...
2015-06-23backlight: pwm_bl: Simplify usage of devm_gpiod_get_optionalAxel Lin1-4/+2
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions), the gpiod_get* functions take an additional parameter that allows to specify direction and initial value for output. Simplify the usage of devm_gpiod_get_optional accordingly. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2015-06-23backlight: lp855x: Don't clear level on suspend/blankSean Paul1-12/+6
Don't clear the backlight level when we're going into suspend or blanking. Instead, just temporarily set the level to 0 so we retain the value when we resume. Reported-by: Benson Leung <bleung@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Tested-by: Stephen Barber <smbarber@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Acked-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2015-06-23backlight: Allow compile test of GPIO consumers if !GPIOLIBGeert Uytterhoeven1-3/+5
The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer functionality only, can still be compiled if GPIOLIB is not enabled. Relax the dependency on GPIOLIB if COMPILE_TEST is enabled, where appropriate. Cc: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2015-06-23video: backlight: da9052: Constify platform_device_idKrzysztof Kozlowski1-1/+1
The platform_device_id is not modified by the driver and core uses it as const. Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2015-06-23gpio-backlight: Discover driver during boot timeArun Bharadwaj1-0/+2
The gpio-backlight driver seems to be missing the MODULE_DEVICE_TABLE line which is preventing it from being modprobed during boot time even if the gpio-backlight device exists. This seems to be a bug and this patch attempts to fix that. Signed-off-by: Arun Bharadwaj <arun@gumstix.com> Signed-off-by: Ash Charles <ashcharles@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2015-06-23module: add per-module param_lockDan Streetman1-2/+2
Add a "param_lock" mutex to each module, and update params.c to use the correct built-in or module mutex while locking kernel params. Remove the kparam_block_sysfs_r/w() macros, replace them with direct calls to kernel_param_[un]lock(module). The kernel param code currently uses a single mutex to protect modification of any and all kernel params. While this generally works, there is one specific problem with it; a module callback function cannot safely load another module, i.e. with request_module() or even with indirect calls such as crypto_has_alg(). If the module to be loaded has any of its params configured (e.g. with a /etc/modprobe.d/* config file), then the attempt will result in a deadlock between the first module param callback waiting for modprobe, and modprobe trying to lock the single kernel param mutex to set the new module's param. This fixes that by using per-module mutexes, so that each individual module is protected against concurrent changes in its own kernel params, but is not blocked by changes to other module params. All built-in modules continue to use the built-in mutex, since they will always be loaded at runtime and references (e.g. request_module(), crypto_has_alg()) to them will never cause load-time param changing. This also simplifies the interface used by modules to block sysfs access to their params; while there are currently functions to block and unblock sysfs param access which are split up by read and write and expect a single kernel param to be passed, their actual operation is identical and applies to all params, not just the one passed to them; they simply lock and unlock the global param mutex. They are replaced with direct calls to kernel_param_[un]lock(THIS_MODULE), which locks THIS_MODULE's param_lock, or if the module is built-in, it locks the built-in mutex. Suggested-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Dan Streetman <ddstreet@ieee.org> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-06-22Merge omapdss scaling fixesTomi Valkeinen3-16/+116
2015-06-22Merge branches 'x86/apic', 'x86/asm', 'x86/mm' and 'x86/platform' into x86/core, to merge last updatesIngo Molnar4-6/+9
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-06-18msm: msm_fb: Remove dead codeStephen Boyd15-5693/+0
This code is no longer used now that mach-msm has been removed. Delete it. Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: David Brown <davidb@codeaurora.org> Cc: Bryan Huntsman <bryanh@codeaurora.org> Cc: Daniel Walker <dwalker@fifo99.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-17OMAPDSS: HDMI: wait for framedone when stopping videoTomi Valkeinen1-0/+16
At the moment when HDMI video output is stopped, we just clear the enable bit and return. While it's unclear if this can cause any issues, I think it's still better to wait for FRAMEDONE interrupt after clearing the enable bit so that we're sure the HDMI IP has finished. As we don't have any ready-made irq handling for HDMI, and this only needs to be done when disabling the HDMI output, this patch implements a simple loop with sleep, polling the FRAMEDONE bit. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-17OMAPDSS: HDMI4: fix error handlingTomi Valkeinen1-1/+1
Error handling in hdmi_power_on_full() is not correct, and could leave resources unfreed. Fix this by arranging the error labels correctly. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-17OMAPDSS: DISPC: scaler debug printTomi Valkeinen1-2/+16
Improve the DISPC debug print for scaling. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-17OMAPDSS: DISPC: do only y decimation on OMAP3Tomi Valkeinen1-11/+2
The current driver does both x and y decimation on OMAP3 DSS. Testing shows that x decimation rarely works, leading to underflows. The exact reason for this is unclear, as the underflows seem to happen even with low pixel clock rates, and I would presume that if the DSS can manage a display with 140MHz pixel clock, it could manage x decimation with factor 2 with a low pixel clock (~30MHz). So it is possible that there is a problem somewhere else, in memory management, or DSS DMA, or similar. I have not found anything that would help this. So, to fix the downscaling scaling, this patch removes x decimation for OMAP3. This will limit some of the more demanding downscaling scenarios, but one could argue that using DSS to downscale such a large amount is insane in the first place, as the produced image is rather bad quality. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-17OMAPDSS: DISPC: check if scaling setup failedTomi Valkeinen1-0/+10
The DISPC's scaling code seems to presume that decimation always succeeds, and so we always do find a suitable downscaling setup. However, this is not the case, and the algorithm can fail. When that happens, the code just proceeds with wrong results, causing issues later. Add the necessary checks to bail out if the scaling algorithm failed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-17OMAPDSS: DISPC: fix 64 bit issue in 5-tapTomi Valkeinen1-3/+3
The DISPC driver uses 64 bit arithmetic to calculate the required clock rate for scaling. The code does not seem to work correctly, and instead calculates with 32 bit numbers, giving wrong result. Fix the code by typecasting values to u64 first, so that the calculations do happen in 64 bits. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-17OMAPDSS: DISPC: fix row_inc for OMAP3Tomi Valkeinen1-0/+9
pixel_inc and row_inc work differently on OMAP2/3 and OMAP4+ DSS. On OMAP2/3 DSS, the pixel_inc is _not_ added by the HW at the end of the line, after the last pixel, whereas on OMAP4+ it is. The driver currently works for OMAP4+, but does not handle OMAP2/3 correctly, which leads to tilted image when row_inc is used. This patch adds a flag to DISPC driver so that the pixel_inc is added when required. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-17OMAPDSS: DISPC: add check for scaling limitsTomi Valkeinen1-0/+15
On OMAP3/AM43xx some scaling factors cause underflows/synclosts. After studying this, I found that sometimes the driver uses three-tap scaling with downscaling factor smaller than x0.5. This causes issues, as x0.5 is the limit for three-tap scaling. The driver has FEAT_PARAM_DOWNSCALE parameter, but that seems to be for five-tap scaling, which allows scaling down to x0.25. This patch adds checks for both horizontal and vertical scaling. For horizontal the HW always uses 5 taps, so the limit is x0.25. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-17OMAPDSS: DISPC: fix check_horiz_timing_omap3 argsTomi Valkeinen1-2/+2
After calculating the required decimation for scaling, the dispc driver checks once more if the resulting configuration is valid by calling check_horiz_timing_omap3(). Earlier calls to this function have correctly used in_width and in_height as parameters, but the last call uses width and height. This causes the driver to possibly reject scaling that would work. This patch fixes the parameters. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-17OMAPDSS: DISPC: fix predecimation for YUV modesTomi Valkeinen1-0/+36
DISPC needs even input buffer width for YUV modes. The DISPC driver doesn't check this at the moment (although omapdrm does), but worse, when DISPC driver does x predecimation the result may be uneven. This causes sometimes sync losts, underflows, or just visual errors. This patch makes DISPC driver return an error if the user gives uneven input width for a YUV buffer. It also makes the input width even in case of predecimation. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-17OMAPDSS: DISPC: work-around for errata i631Tomi Valkeinen1-0/+9
Errata i631 description: "When in YUV4:2:0 format in 1D burst, the DISPC DMA skips lines when fetching Chroma sampling." Workaround: "If YUV4:2:0-1D burst is required: Set DISPC_VIDp_ATTRIBUTES[22]DOUBLESTRIDE to 0x0 and DISPC_VIDp_ATTRIBUTES[13:12]ROTATION to 0x1 or 0x3" The description is somewhat confusing, but testing has shown that DSS fetches extra rows from memory when using NV12 format in 1D mode. If the memory after the framebuffer is inaccessible, this leads to OCP errors. The driver always uses DOUBLESTRIDE=0 when using 1D mode, so we only need to handle the ROTATION part. The issue exist on all OMAP4 and OMAP5 based DSS IPs. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-17Merge omapdss componentization workTomi Valkeinen11-198/+396
2015-06-17OMAPDSS: simplify submodule reg/unreg codeTomi Valkeinen1-31/+15
Now that we are using components in omapdss, there's no need for separate handling of dss and dispc driver init. Thus we can move the dss and dispc init and unit func pointers to the lists we use for the other dss submodules. We can now also handle errors returned by the registration functions properly: if registering a driver fails, we can stop processing and return the error. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2015-06-17OMAPDSS: componentize omapdssTomi Valkeinen9-38/+234
omapdss kernel module contains drivers for multiple devices, one for each DSS submodule. The probing we have at the moment is a mess, and doesn't give us proper deferred probing nor ensure that all the devices are probed before omapfb/omapdrm start using omapdss. This patch solves the mess by using the component system for DSS submodules. The changes to all DSS submodules (dispc, dpi, dsi, hdmi4/5, rfbi, sdi, venc) are the same: probe & remove functions are changed to bind & unbind, and new probe & remove functions are added which call component_add/del. The dss_core driver (dss.c) acts as a component master. Adding and matching the components is simple: all dss device's child devices are added as components. However, we do have some dependencies between the drivers. The order in which they should be probed is reflected by the list in core.c (dss_output_drv_reg_funcs). The drivers are registered in that order, which causes the components to be added in that order, which makes the components to be bound in that order. This feels a bit fragile, and we probably should improve the code to manage binds in random order. However, for now, this works fine. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2015-06-17OMAPDSS: reorder uninit callsTomi Valkeinen1-12/+12
We have a list of function pointers to dss submodule uninit functions. It makes sense to do the uninit in the reverse order to init, but that is not currently the case. This patch reorders the uninit calls to be the reverse of init order. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2015-06-17OMAPDSS: remove uses of __init/__exitTomi Valkeinen10-69/+69
The following patches will add component handling to omapdss, improving the handling of deferred probing. However, at the moment we're using quite a lot of __inits and __exits in the driver, which prevent normal dynamic probing and removal. This patch removes most of the uses of __init and __exit, so that we can register drivers after module init, and so that we can unregister drivers even if the module is built-in. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2015-06-17OMAPDSS: fix dss_init_ports error handlingTomi Valkeinen1-3/+6
The return value of dss_init_ports() is not handled at all, causing crashes later if the call failed. This patch adds the error handling, and we also move the call to a slightly earlier place to make bailing out easier. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2015-06-17OMAPDSS: refactor dss probe functionTomi Valkeinen1-56/+69
Refactor dss probe function by extracting the setup for video plls into a separate function. The call to this function is also moved to a slightly earlier phase, so that in error case we can bail out more easily. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2015-06-17OMAPDSS: move 'dss_initialized' to dss driverTomi Valkeinen2-10/+12
We have a flag, 'dss_initialized', which tells omapfb and omapdrm if omapdss is available. At the moment it can be set even if the dss submodules are not all ready, in case something gets deferred. Move the flag to dss_core driver so that it'll signal the availability of the dss drivers move accurately. For now, it'll signal that dss_core is ready, which is not quite correct but still better than previously. The following patches will add component system to omapdss, and after those patches 'dss_initialized' will signal that all the submodules are ready. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2015-06-16fbdev: propagate result of fb_videomode_from_videomode()Vladimir Murzin1-1/+3
fb_videomode_from_videomode() may fail, but of_get_fb_videomode() silently covers this fact. Instead, trow the error code to the caller. Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-16video: fbdev: vesafb: use arch_phys_wc_add()Luis R. Rodriguez1-21/+8
This driver uses the same area for MTRR as for the ioremap_wc(), if anything it just uses a smaller size in case MTRR reservation fails. ioremap_wc() API is already used to take advantage of architecture write-combining when available. Convert the driver from using the x86 specific MTRR code to the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add() will avoid MTRR if write-combining is available. There are a few motivations for this: a) Take advantage of PAT when available b) Help bury MTRR code away, MTRR is architecture specific and on x86 its replaced by PAT c) Help with the goal of eventually using _PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit de33c442e titled "x86 PAT: fix performance drop for glx, use UC minus for ioremap(), ioremap_nocache() and pci_mmap_page_range()") The conversion done is expressed by the following Coccinelle SmPL patch, it additionally required manual intervention to address all the #ifdery and removal of redundant things which arch_phys_wc_add() already addresses such as verbose message about when MTRR fails and doing nothing when we didn't get an MTRR. @ mtrr_found @ expression index, base, size; @@ -index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1); +index = arch_phys_wc_add(base, size); @ mtrr_rm depends on mtrr_found @ expression mtrr_found.index, mtrr_found.base, mtrr_found.size; @@ -mtrr_del(index, base, size); +arch_phys_wc_del(index); @ mtrr_rm_zero_arg depends on mtrr_found @ expression mtrr_found.index; @@ -mtrr_del(index, 0, 0); +arch_phys_wc_del(index); @ mtrr_rm_fb_info depends on mtrr_found @ struct fb_info *info; expression mtrr_found.index; @@ -mtrr_del(index, info->fix.smem_start, info->fix.smem_len); +arch_phys_wc_del(index); @ ioremap_replace_nocache depends on mtrr_found @ struct fb_info *info; expression base, size; @@ -info->screen_base = ioremap_nocache(base, size); +info->screen_base = ioremap_wc(base, size); @ ioremap_replace_default depends on mtrr_found @ struct fb_info *info; expression base, size; @@ -info->screen_base = ioremap(base, size); +info->screen_base = ioremap_wc(base, size); Generated-by: Coccinelle SmPL Cc: Toshi Kani <toshi.kani@hp.com> Cc: Suresh Siddha <sbsiddha@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Juergen Gross <jgross@suse.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Antonino Daplas <adaplas@gmail.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Jingoo Han <jg1.han@samsung.com> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-fbdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-16video: fbdev: vesafb: add missing mtrr_del() for added MTRRLuis R. Rodriguez1-7/+26
The MTRR added was never being deleted, in order to store the MTRR cookie we need to make use of the private info->par so we create a struct for this. This driver was already using the extra space typically used for info->par for the info->pseudo_palette which typically used stuffed on driver's own private structs (the respective info->par), so we just move the pseudo_palette into the private struct as well. Cc: Toshi Kani <toshi.kani@hp.com> Cc: Suresh Siddha <sbsiddha@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Juergen Gross <jgross@suse.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Antonino Daplas <adaplas@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Jingoo Han <jg1.han@samsung.com> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-fbdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-16video: fbdev: vesafb: only support MTRR_TYPE_WRCOMBLuis R. Rodriguez1-46/+16
No other video driver uses MTRR types except for MTRR_TYPE_WRCOMB, the other MTRR types were implemented and supported here but with no real good reason. The ioremap() APIs are architecture agnostic and at least on x86 PAT is a new design that extends MTRRs and can replace it in a much cleaner way, where so long as the proper ioremap_wc() or variant API is used the right thing will be done behind the scenes. This is the only driver left using the other MTRR types -- and since there is no good reason for it now rip them out. Cc: Toshi Kani <toshi.kani@hp.com> Cc: Suresh Siddha <sbsiddha@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Juergen Gross <jgross@suse.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Antonino Daplas <adaplas@gmail.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Jingoo Han <jg1.han@samsung.com> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: linux-fbdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-12video: fbdev: mxsfb: Constify platform_device_idKrzysztof Kozlowski1-1/+1
The platform_device_id is not modified by the driver and core uses it as const. Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-12video: fbdev: imxfb: Constify platform_device_idKrzysztof Kozlowski1-1/+1
The platform_device_id is not modified by the driver and core uses it as const. Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-12fbdev: omap2: remove potential format string leakKees Cook1-1/+1
Since kobject_init_and_add takes a format string, make sure that the passed in name cannot be accidentally parsed. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-08Merge 4.1-rc7 into tty-nextGreg Kroah-Hartman1-0/+4
This fixes up a merge issue with the amba-pl011.c driver, and we want the fixes in this branch as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-07video/fbdev, asm/io.h: Remove ioremap_writethrough()Toshi Kani3-6/+5
Replace all calls to ioremap_writethrough() with ioremap_wt(). Remove ioremap_writethrough() too. Signed-off-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Elliott@hp.com Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Luis R. Rodriguez <mcgrof@suse.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: arnd@arndb.de Cc: hch@lst.de Cc: hmh@hmh.eng.br Cc: jgross@suse.com Cc: konrad.wilk@oracle.com Cc: linux-mm <linux-mm@kvack.org> Cc: linux-nvdimm@lists.01.org Cc: stefan.bader@canonical.com Cc: yigal@plexistor.com Link: http://lkml.kernel.org/r/1433436928-31903-10-git-send-email-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-06-05Merge branch 'ti-dra7-dss' into 4.2/fbdevTomi Valkeinen1-0/+4
Merge arch/ changes for TI's DRA7 SoC Display Subsystem.
2015-06-03ASoC: omap-hdmi-audio: Force channel allocation only for OMAP4Misael Lopez Cruz1-0/+7
There is a constraint in the OMAP4 HDMI IP that requires to use the 8-channel code when transmitting more than two channels. The constraint doesn't apply for OMAP5 so don't force the channel allocation in the sound driver as it can be done specifically for OMAP4 later in the hdmi4 core. Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com> Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Mark Brown <broonie@kernel.org>
2015-06-03OMAPDSS: HDMI5: Fix AUDICONF3 bitfield offsetsMisael Lopez Cruz1-1/+3
Downmix inhibit in HDMI_CORE_FC_AUDICONF3 register is in bit 4 while CEA861_AUDIO_INFOFRAME_DB5_DM_INH sets bit 7. Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com> Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-03OMAPDSS: HDMI5: Set valid sample orderMisael Lopez Cruz1-0/+1
As per TRM, HDMI_WP_AUDIO_CFG[2] LEFT_BEFORE = 0 is reserved, so it must always be set to 1 (the first sample is the left). Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com> Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-03OMAPDSS: HDMI4: Set correct CC for 8-channels layoutMisael Lopez Cruz1-1/+4
OMAP4 HDMI IP uses the 8-channel layout with 8-channel speaker allocation mask when transmitting more than two channels. But the channel count field (CC) of the Audio InfoFrame's DB1 is not updated for 8-channels. As per HDMI Compliance Test 7.31 "Audio InfoFrame", CC = 7 is required for 8-channels CA masks (0x13 and 0x1F). Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com> Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-06-03fbdev: omap2: improve usage of gpiod APIUwe Kleine-König4-30/+11
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions) which appeared in v3.17-rc1, the gpiod_get* functions take an additional parameter that allows to specify direction and initial value for output. Also make use of gpiod_get*_optional where applicable. Apart from simplification of the affected drivers this is another step towards making the flags argument to gpiod_get*() mandatory. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>