summaryrefslogtreecommitdiff
path: root/arch/arm/mach-omap2/fb.c
AgeCommit message (Collapse)AuthorFilesLines
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 156Thomas Gleixner1-14/+1
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 59 temple place suite 330 boston ma 02111 1307 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1334 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-08-26ARM: OMAP2+: use IS_ENABLED() instead of checking for built-in or moduleJavier Martinez Canillas1-1/+1
The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either built-in or as a module, use that macro instead of open coding the same. Using the macro makes the code more readable by helping abstract away some of the Kconfig built-in and module enable details. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-05-20ARM: OMAP2+: Remove calls to deprecacted marco,PTR_RET in the files,fb.c and ↵Nicholas Krause1-1/+1
pmu.c This removes two calls to the deprecated marco,PTR_RET in the files,fb.c and pmu.c for the functions,omap_init_vrfb and omap_init_pmu respectfully. Furthermore these are now replaced by calling the correctly non deprecacted function, PTR_ERR_OR_ZERO in both functions. Signed-off-by: Nicholas Krause <xerofoify@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-10-09ARM: OMAP2+: display: Create omapvrfb and omapfb devices inside ↵Archit Taneja1-7/+7
omap_display_init Move omapfb and omapvrfb device creation inside the omap_display_init so that we can correctly create the device based on the presence of omapdss within the platform. For example, on a kernel image supporting multiple platforms, omap_init_vrfb and omap_init_fb will create omapvrfb and omapfb platform devices respectively on a AM33xx platform even though it doesn't have a VRFB or DSS block. Signed-off-by: Archit Taneja <archit@ti.com> Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-07-04ARM: OMAP2+: Cocci spatch "ptr_ret.spatch"Thomas Meyer1-4/+1
Cocci spatch "ptr_ret.spatch" Signed-off-by: Thomas Meyer <thomas@m3y3r.de> Acked-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-01-11ARM: OMAP2+: Use omap initcallsTony Lindgren1-2/+2
This way the initcalls don't run on other SoCs on multiplatform kernels. Otherwise we'll get something like this when booting on vexpress: omap_hwmod: _ensure_mpu_hwmod_is_setup: MPU initiator hwmod mpu not yet registered ... WARNING: at arch/arm/mach-omap2/pm.c:82 _init_omap_device+0x74/0x94() _init_omap_device: could not find omap_hwmod for mpu ... omap-dma-engine omap-dma-engine: OMAP DMA engine driver ... Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-12-17ARM: OMAP: Split fb.c to remove last remaining cpu_is_omap usageTony Lindgren1-0/+118
Looks like we missed plat-omap/fb.c for cpu_is_omap usage mach-omap2. This is the last user of cpu_is_omap, so let's quickly fix it up so we can finally remove plat/cpu.h for omap2lus. We want to limit cpu_is_omap macro usage to mach-omap2 only so we can make plat/cpu.h private. After this we can finally drop plat/cpu.h for omap2+. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>