Add COMPILE_TEST support to pxa168fb driver for better compile
testing coverage.
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Add COMPILE_TEST support to imxfb driver for better compile
testing coverage.

Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: NXP Linux Team <linux-imx@nxp.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Add COMPILE_TEST support to atmel_lcdfb driver for better compile
testing coverage.

While at it fix improper use of UL (to silence build warnings on
x86_64).

Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
Acked-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

There is a DRM version of the mxsfb driver for quite some time
at drivers/gpu/drm/mxsfb/, so there is no need to keep maintaining
the fbdev version any longer.

Remove the fbdev mxsfb driver in favour of the DRM version.
Signed-off-by: NFabio Estevam <festevam@gmail.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: NXP Linux Team <linux-imx@nxp.com>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

These board families are now handled in the DRM subsystem
where we can have reusable panel drivers and some other
stuff. The PL111 there is now the driver used in the
defconfig for Versatile and Nomadik so no need to keep
this code around.

There are a few minor machines in arch/arm/ such as
mach-netx still using the old driver, so we need to keep
the core fbdev driver around for some time.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

We have two *_CLASS_DEVICE kernel config options (LCD_CLASS_DEVICE
and BACKLIGHT_LCD_DEVICE) that do the same job.
The patch removes useless BACKLIGHT_LCD_SUPPORT option
and converts LCD_CLASS_DEVICE into a menu.
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Acked-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: NDaniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Formatting of Kconfig files doesn't look so pretty, so let the
Great White Handkerchief come around and clean it up.
Signed-off-by: NEnrico Weigelt, metux IT consult <info@metux.net>
[b.zolnierkie: add missing patch description]
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Make the driver OF only as since AVR32 has been removed from the kernel,
there are only OF enabled platform using it.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: NNicolas Ferre <nicolas.ferre@microchip.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

The FB_PRE_INIT_FB option keeps the kernel from reinitializing the display
and prevents flickering during the transition from a bootloader splash
screen to the kernel logo screen.

Make this option available for the mxsfb driver.
Signed-off-by: NMelchior Franz <melchior.franz@ginzinger.com>
Signed-off-by: NMartin Kepplinger <martin.kepplinger@ginzinger.com>
Signed-off-by: NManfred Schlaegl <manfred.schlaegl@ginzinger.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

This patch addresses inconsistencies in Mac framebuffer drivers and their
use of Kconfig symbols relating to NVRAM, so PPC64 can use CONFIG_NVRAM.

The defined(CONFIG_NVRAM) condition is replaced with the weaker
IS_REACHABLE(CONFIG_NVRAM) condition, like atari_scsi.

Macintosh framebuffer drivers use default settings for color mode and
video mode that are found in NVRAM. On PCI Macs, MacOS stores display
settings in the Name Registry (NR) partition in NVRAM*. On NuBus Macs,
there is no NR partition and MacOS stores display mode settings in PRAM**.

Early-model Macs are the ones most likely to benefit from these settings,
since they are more likely to have a fixed-frequency monitor connected to
the built-in framebuffer device. Moreover, a single NV_CMODE value and
a single NV_VMODE value provide for only one display.

The NV_CMODE and NV_VMODE constants are apparently offsets into the NR
partition for Old World machines. This also suggests that these defaults
are not useful on later models. The NR partition seems to be optional on
New World machines. CONFIG_NVRAM cannot be enabled on PPC64 at present.

It is safe to say that NVRAM support in PowerMac fbdev drivers is only
applicable to CONFIG_PPC32 so make this condition explicit. This means
matroxfb driver won't crash on PPC64 when CONFIG_NVRAM becomes available
there.

For imsttfb, add the missing CONFIG_NVRAM test to prevent a build failure,
since PPC64 does not implement nvram_read_byte(). Also add a missing
machine_is(powermac) check. Change the inconsistent dependency on
CONFIG_PPC and the matching #ifdef tests to CONFIG_PPC_PMAC.

For valkyriefb, to improve clarity and consistency with the other PowerMac
fbdev drivers, test for CONFIG_PPC_PMAC instead of !CONFIG_MAC. Remove a
bogus comment regarding PRAM.

* See GetPreferredConfiguration and SavePreferredConfiguration in
"Designing PCI Cards and Drivers for Power Macintosh Computers".

** See SetDefaultMode and GetDefaultMode in "Designing Cards and Drivers
for the Macintosh Family".
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: NMark Brown <broonie@kernel.org>
Acked-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

BACKLIGHT_CLASS_DEVICE is already tristate, but a dependency
FB_BACKLIGHT prevents it from being built as a module.  There
doesn't seem to be any particularly good reason for this, so
switch FB_BACKLIGHT over to tristate.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Tested-by: NArnd Bergmann <arnd@arndb.de>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ulf Magnusson <ulfalizer@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Hans de Goede <j.w.r.degoede@gmail.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.

Also since commit f467c564 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:

    ...
    One side effect of (and the main motivation for) this change is making
    the following two definitions behave exactly the same:
    
        config FOO
                bool
    
        config FOO
                bool
                default n
    
    With this change, neither of these will generate a
    '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
    That might make it clearer to people that a bare 'default n' is
    redundant.
    ...
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Since commit c86f5173 ("ARM: clps711x: Switch to MULTIPLATFORM")
ARCH_CLPS711X depends on ARCH_MULTIPLATFORM to be enabled so the old
CLPS711x LCD support driver (enabled by the FB_CLPS711X_OLD config
option) can't be selected any longer. Remove all FB_CLPS711XX_OLD
code as it has been dead for over 2 years now. Please note that the
new CLPS711x LCD support driver (enabled by the FB_CLPS711X config
option) is still available in the kernel tree.
Reviewed-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

The framebuffer options and devices menu is unintentionally split
or broken because some items in it do not depend on FB (including
several under omap and mmp).
Fix this by moving FB_CMDLINE, FB_NOTIFY, and FB_CLPS711X_OLD to
just before the FB Kconfig symbol definition and by moving the
omap, omap2, and mmp menus to last, following FB_SM712.

Also, the FB_VIA dependencies are duplicated by both being inside
an "if FB_VIA/endif" block and "depends on FB_VIA", so drop the
"depends on FB_VIA" lines since they are redundant.

Fixes: ea6763c1 ("video/fbdev: Always built-in video= cmdline parsing")
Fixes: 5ec96538 ("fbdev: Make fb-notify a no-op if CONFIG_FB=n")
Fixes: ef74d46a ("video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver")
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

broadsheetfb is a platform driver and it should not be used on x86.
It should be used only by single ARM PXA board so add the dependency
in Kconfig.
Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

This patch allows viafb driver to be build on !X86 archs
using COMPILE_TEST config option.

Since via-camera driver (VIDEO_VIA_CAMERA) depends on viafb
it also needs a little fixup.

Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Reviewed-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Since commit a521422e  ("ARM: shmobile: mackerel: Remove Legacy C
board code") MERAM functionality is unused. Remove it.
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Since commit a521422e  ("ARM: shmobile: mackerel: Remove Legacy C
board code") MERAM functionality is unused. Remove it.
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

auo_k1900fb and auo_k1901fb drivers have been introduced six
years ago by following commits:

commit 2c8304d3 ("video: auo_k190x: add code shared by controller drivers")
commit 96b1d500 ("video: auo_k190x: add driver for AUO-K1900 variant")
commit 53027cdf ("video: auo_k190x: add driver for AUO-K1901 variant")

They never had any in-kernel user so just remove them (since
they are platform drivers they need corresponding platform
devices to be registered by kernel and it has never happened).
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Since commit a521422e ("ARM: shmobile: mackerel: Remove Legacy C
board code"), the only remaining platforms using this driver are SuperH
SH-Mobile SoCs (sh7723).  As both SUPERH and ARCH_SHMOBILE are set for
these platforms, the SUPERH dependency can be dropped.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Exynos5, Exynos4 and S5PV210 platforms have been converted to
use Device Tree and Exynos DRM driver long time ago.  Remove
dead platform code for these platforms and update Kconfig
s3c-fb entry accordingly.
Acked-by: NJingoo Han <jingoohan1@gmail.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

The blackfin architecture is getting removed, this removes the
associated fbdev drivers as well.
Acked-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: NAaron Wu <aaron.wu@analog.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The FB_I810_I2C symbol previously had a blank help text, which was
removed in e9829ac4 ("video: fbdev: kconfig: Remove blank help
text").

Give it a proper help text, derived from commit 74f6ae84 ("[PATCH]
i810fb: Add > i2c/DDC support").
Signed-off-by: NUlf Magnusson <ulfalizer@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: "Luis R . Rodriguez" <mcgrof@kernel.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Paul Bolle <pebolle@tiscali.nl>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Hans de Goede <j.w.r.degoede@gmail.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Blank help texts are probably either a typo, a Kconfig misunderstanding,
or some kind of half-committing to adding a help text (in which case a
TODO comment would be clearer, if the help text really can't be added
right away).

Best to remove them, IMO.
Signed-off-by: NUlf Magnusson <ulfalizer@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Fix Kconfig symbol typo; it should be FB_INTEL.
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

On some hardware the LCD panel is not mounted upright in the casing,
but rotated by 90 degrees. In this case we want the console to
automatically be rotated to compensate.

The drm subsys has a quirk table for this, use the
drm_get_panel_orientation_quirk function to get the panel orientation
and set info->fbcon_rotate_hint based on this, so that the fbcon console
on top of efifb gets automatically rotated to compensate for the panel
orientation.
Acked-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171125193553.23986-7-hdegoede@redhat.com

igafb driver hasn't compiled since at least kernel v2.6.34 as
commit 6016a363 ("of: unify phandle name in struct device_node")
missed updating igafb.c to use dp->phandle instead of dp->node.

Cc: "David S. Miller" <davem@davemloft.net>
Cc: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Enable this driver for Xilinx ZynqMP.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

While working on another build error, I ran into several variations of
this dependency loop:

subsection "Kconfig recursive dependency limitations"
drivers/input/Kconfig:8:	symbol INPUT is selected by VT
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/tty/Kconfig:12:	symbol VT is selected by FB_STI
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:677:	symbol FB_STI depends on FB
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:5:	symbol FB is selected by DRM_KMS_FB_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:72:	symbol DRM_KMS_FB_HELPER is selected by DRM_KMS_CMA_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:137:	symbol DRM_KMS_CMA_HELPER is selected by DRM_HDLCD
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/arm/Kconfig:6:	symbol DRM_HDLCD depends on OF
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/of/Kconfig:4:	symbol OF is selected by X86_INTEL_CE
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/x86/Kconfig:523:	symbol X86_INTEL_CE depends on X86_IO_APIC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/x86/Kconfig:1011:	symbol X86_IO_APIC depends on X86_LOCAL_APIC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/x86/Kconfig:1005:	symbol X86_LOCAL_APIC depends on X86_UP_APIC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/x86/Kconfig:980:	symbol X86_UP_APIC depends on PCI_MSI
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/pci/Kconfig:11:	symbol PCI_MSI is selected by AMD_IOMMU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/iommu/Kconfig:106:	symbol AMD_IOMMU depends on IOMMU_SUPPORT
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/iommu/Kconfig:5:	symbol IOMMU_SUPPORT is selected by DRM_ETNAVIV
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/etnaviv/Kconfig:2:	symbol DRM_ETNAVIV depends on THERMAL
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/thermal/Kconfig:5:	symbol THERMAL is selected by ACPI_VIDEO
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/acpi/Kconfig:183:	symbol ACPI_VIDEO is selected by INPUT

This doesn't currently show up as I fixed the 'THERMAL' part of it,
but I noticed that the FB_STI dependency should not be there but
was introduced by slightly incorrect bug-fix patch that tried to
fix a link error.

Instead of selecting 'VT' to make us enter the drivers/video/console
directory at compile-time, it's sufficient to build the
drivers/video/console/sticore.c file by adding its directory
to when CONFIG_FB_STI is enabled. Alternatively, we could move the
sticore code to another directory that is always built when we
have at STI_CONSOLE or FB_STI enabled.

Fixes: 17085a93 ("parisc: stifb: should depend on STI_CONSOLE")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Helge Deller <deller@gmx.de>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Allow generic frame-buffer to provide a default
get_fb_unmapped_area function if specific devices need it.

Usually this function is defined in architecture directories but
define it here may limit code duplication especially for all ARM
platforms without MMU.

version 5:
- set get_unmapped_area field if FB_PROVIDE_GET_FB_UNMAPPED_AREA is
  defined

version 4:
- introdude a configuration flag to be independent of architecture
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1483521177-21794-2-git-send-email-benjamin.gaignard@linaro.org

The SEAD3 board no longer uses the cobalt_lcdfb driver, so remove the
SEAD3-specific code from it.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ondrej Zary <linux@rainbow-software.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: linux-mips@linux-mips.org
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/14060/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The old non-DRM Exynos MIPI driver does not support DeviceTree and
requires board files.  Our platforms do not provide such so the driver
is not usable since a long time ago.  All features provided by the
driver (and associated s6e8ax0 panel driver) are already supported by
newer DRM version so the old code can be removed.

Cc: Inki Dae <inki.dae@samsung.com>
Cc: Donghwa Lee <dh09.lee@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This adds a special panel init hook for the ARM reference designs
Integrator (IM-PD1), Versatile and RealView, so we can configure
a DPI panel from device tree and have it working without
boardfiles for these machines.

Basically this is the same code as from the board files, just
moved over to look up the syscon DT node and manipulate the
special CLCD register from their regmap.

Tested on RealView PB11MPcore.

Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

If the device is probed from device tree, we can support
backlight. This is used with some systems such as the
ST Microelectronics Nomadik.

We have to add HAS_IOMEM to the dependencies of CLCD since
the backlight class device will now be selected, and if it
gets selected on an arch that does not have IOMEM,
compilation will fail.

Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Remove the sh_mipi_dsi driver as it appears to be unused since
c0bb9b30 ("ARCH: ARM: shmobile: Remove ag5evm board support").
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Allows the efifb driver to be built for ARM and arm64. This simply involves
updating the Kconfig dependency expression, and supplying dummy versions of
efifb_setup_from_dmi().
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
Cc: Borislav Petkov <bp@alien8.de>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1461614832-17633-25-git-send-email-matt@codeblueprint.co.ukSigned-off-by: NIngo Molnar <mingo@kernel.org>

The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:

drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'

This removes the extra "select", as it just causes more trouble than
it helps. In theory, some defconfig file might break if it has
XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig
fragment we ship in the kernel (kernel/configs/xen.config) however
already enables both, and anyone using an old .config file would
keep having both enabled.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Suggested-by: NDavid Vrabel <david.vrabel@citrix.com>
Fixes: 36c1132e ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

With the current TURBOchannel API support is automagical.
Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.

This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>