Age | Commit message (Collapse) | Author |
|
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: Arnd Bergmann <arnd@arndb.de>
Suggested-by: David Vrabel <david.vrabel@citrix.com>
Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The variables modeflag and resinfo were only assigned some value but
were never used.
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The Kconfig currently controlling compilation of this code is:
config FB_XVR2500
bool "Sun XVR-2500 3DLABS Wildcat support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.
We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.
We don't replace module.h with init.h since the file already has that.
We also delete the MODULE_LICENSE tag etc. since all that information
was (or is now) contained at the top of the file in the comments.
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The Kconfig currently controlling compilation of this code is:
config FB_XVR1000
bool "Sun XVR-1000 support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.
We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.
We don't replace module.h with init.h since the file already has that.
Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
We also delete the MODULE_LICENSE tag etc. since all that information
was (or is now) contained at the top of the file in the comments.
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The Kconfig currently controlling compilation of this code is:
config FB_XVR500
bool "Sun XVR-500 3DLABS Wildcat support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.
We don't replace module.h with init.h since the file already has that.
We also delete the MODULE_LICENSE tag etc. since all that information
was (or is now) contained at the top of the file in the comments.
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The s6e8ax0 driver has a dependency on BACKLIGHT_CLASS_DEVICE,
which can be configured as a loadable module, so we have to
make the driver a tristate symbol as well, to avoid this error:
drivers/built-in.o: In function `s6e8ax0_probe':
:(.text+0x23a48): undefined reference to `devm_backlight_device_register'
This also means we get another error from a missing export, which
this fixes as well:
ERROR: "exynos_mipi_dsi_register_lcd_driver" [drivers/video/fbdev/exynos/s6e8ax0.ko] undefined!
The drivers are all written to be loadable modules already,
except the Kconfig options for that are missing, which makes
the patch really easy.
Finally, the EXYNOS_VIDEO option is turned into tristate as well
for good measure, as all framebuffer drivers should be configurable
as modules, though this change is not strictly necessary.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Commit 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the
hsync/vsync pulse") fixes polarities of HSYNC/VSYNC pulse but
forgot to update known_lcd_panels[] which had sync values
according to old logic. This breaks LCD at least on DA850 EVM.
This patch fixes this issue and I have tested this for panel
"Sharp_LK043T1DG01" using DA850 EVM board.
Fixes: 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the hsync/vsync pulse")
Signed-off-by: Sushaanth Srirangapathi <sushaanth.s@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The fb_rotate method in struct fb_ops is never actually invoked, and
it's been that way in the entire history of git (in fact, the last
occurrence of the string '->fb_rotate' vanished over 10 years ago,
with b4d8aea6d6, and that merely tested whether the callback
existed). So remove some dead code and make struct fb_obs a little
smaller.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The Bt431 cursor generator supports simultaneous generation of a 64 x 64
and a cross hair cursor in which the cursor format control bit (bit D4)
of the command register "specifies whether the contents of the cursor
RAM are to be logically exclusive-ORed (logical zero) or ORed (logical
one) with the cross hair cursor". Rename the relevant macro accordingly.
References:
[1] "Bt431 Monolithic CMOS 64 x 64 Pixel Cursor Generator", Brooktree
Corporation, Document Number: L431001, Rev. J
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Use the address autoincrement feature when accessing successive palette
entries and also skip loading a palette address in overlay register
assesses which do not use that address. Provide a red/green/blue
register sequencer reset helper for use in overlay register assesses
where the state of the sequencer is not known.
References:
[1] "Bt454 Bt455 170 MHz Monolithic CMOS 16 Color Palette RAMDAC",
Brooktree Corporation, Document Number: L454001, Rev. I
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The Bt455 is a greyscale RAMDAC, using the green color palette entries
only while still providing registers for the red and blue components,
all the three of which have to be loaded on palette updates. Chip
documentation [1] mandates that the unused red and blue registers are
written with 0.
Therefore update code to follow this requirement and given that it makes
the red and blue components unusable remove them from internal API calls
altogether.
References:
[1] "Bt454 Bt455 170 MHz Monolithic CMOS 16 Color Palette RAMDAC",
Brooktree Corporation, Document Number: L454001, Rev. I
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The board uses hardwired timings compatible with 72Hz DEC VR319-DA and
VRM17-AA monitors, according to the board owner's manual[1]. These
timings are accordingly taken from the VR319 manual[2].
References:
[1] "The Monochrome Frame Buffer TURBOchannel Module", Digital Equipment
Corporation, Order Number: EK-MFBOM-TC-001, December 1991
[2] "Installing and Using the VR319 Monochrome Monitor", Digital
Equipment Corporation, Order Number: EK-VR319-IN-001, First Edition,
January 1990, Table 6-1 "Video Timing--1280 x 1024 Resolution"
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
With the current TURBOchannel API support is automagical.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Rework the driver to use the current frambuffer and TURBOchannel APIs,
including proper resource management and using the new framework for
hardware cursor support.
NB two Bt431 cursor generators are included onboard, both responding at
the same TURBOchannel bus addresses and with their host data buses wired
to byte lanes #0 and #1 respectively of the 32-bit bus. Therefore both
can be accessed simultaneously with 16-bit data transfers. Cursor
outputs of the chip wired to lane #0 drive the respective overlay select
inputs of the Bt455 RAMDAC, whereas cursor outputs of the chip wired to
lane #1 drive the respective P3 pixel select inputs of the RAMDAC.
So 5 (out of 17) Bt455 color registers are usable with this board:
palette entries #0 and #1 for frame buffer pixel data driven while
neither cursor generator is active, palette entries #8 and #9 for frame
buffer pixel data driven while cursor generator #1 is active only and
the overlay entry while cursor generator #0 is active.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
According to the board specification[1] the width of the vertical sync
front porch is 12 pixels or the same as the width of the horizontal sync
front porch. This in turn means the size of the lower margin is 0,
because the vertical sync starts as soon as the start of the horizontal
sync terminates the last line.
References:
[1] "PMAG-BA TURBOchannel Color Frame Buffer Functional Specification",
Revision 1.2, Workstation Systems Engineering, Digital Equipment
Corporation, August 27, 1990, Table 3-5: "Video Timing"
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Tomi 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: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
We were not checking the return value of platform_device_add_data()
which can fail.
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
IS_ERR_VALUE macro should be used only with unsigned long type.
For signed types comparison 'ret < 0' should be used.
The patch follows conclusion from discussion on LKML [1][2].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2120927
[2]: http://permalink.gmane.org/gmane.linux.kernel/2150581
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
As the function name already indicates that get_opt_bool() parses
for a bool. It is not a surprise that compiler is complaining
about it when -Werror=incompatible-pointer-types is used:
drivers/video/fbdev/intelfb/intelfbdrv.c: In function ‘intelfb_setup’:
drivers/video/fbdev/intelfb/intelfbdrv.c:353:39: error: passing argument 3 of ‘get_opt_bool’ from incompatible pointer type [-Werror=incompatible-pointer-types]
if (get_opt_bool(this_opt, "accel", &accel))
Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
par->metromem_cmd->args[] is an array of 31 elements of size u16. Here
we have initialized the first "i" elements and want to set the rest to
zero.
The issue here is that ARRAY_SIZE(par->metromem_cmd->args) is 31 and not
32 as in the original code. It means that we set ->csum to zero, but
that is harmless because we immediately set it to the correct value on
the next line.
Still, the buffer overflow upsets static checkers so let's correct the
math.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Currently when we boot the kernel on a mx25pdk the LCDC controller
does not show the Linux logo on boot.
This problem is well explained by Sascha Hauer:
"Unfortunately this LCD controller does not have an enable bit. The
controller starts directly when the clocks are enabled. If the clocks
are enabled when the controller is not yet programmed with proper
register values then it just goes into some undefined state. What I
suspect is that the clocks already were enabled before driver probe,
presumably by the bootloader, so the controller is already in undefined
state when entering Linux. Now by dis/enabling the ipg clock you
effectively reset the controller. Since you have programmed it with
valid register values in the mean time it starts working after this
reset."
So do as suggested and force a reset of the LCDC hardware by
enabling and disabling the IPG clock.
With this change the Linux logo can be seen on boot on a mx25pdk.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
resource_size_t cannot be printed using the %x format string
when we it is defined as u64:
drivers/video/fbdev/mmp/hw/mmp_ctrl.c: In function 'mmphw_probe':
drivers/video/fbdev/mmp/hw/mmp_ctrl.c:506:22: error: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Werror=format=]
dev_err(ctrl->dev, "%s: res %x - %x map failed\n", __func__,
^
drivers/video/fbdev/mmp/hw/mmp_ctrl.c:506:22: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'resource_size_t {aka long long unsigned int}' [-Werror=format=]
This changes the format string to %pR, which is interpreted
by the printk implementation to pretty-print a resource
structure.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The probe function correct passes a dma_addr_t pointer into
dma_alloc_coherent(), but has a cast to resource_size_t, which
might be different from dma_addr_t:
drivers/video/fbdev/da8xx-fb.c: In function 'fb_probe':
drivers/video/fbdev/da8xx-fb.c:1431:10: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]
This removes the cast, which avoids the warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The s6e8ax0 suspend/resume functions are hidden inside of an #ifdef
when CONFIG_PM is set to avoid unused function warnings, but they
call some other functions that nothing else calls, and we get warnings
about those:
drivers/video/fbdev/exynos/s6e8ax0.c:449:13: error: 's6e8ax0_sleep_in' defined but not used [-Werror=unused-function]
drivers/video/fbdev/exynos/s6e8ax0.c:485:13: error: 's6e8ax0_display_off' defined but not used [-Werror=unused-function]
This marks the PM functions as __maybe_unused so the compiler can
silently drop them when they are not referenced.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
According to the ocfb documentation:
Fix tgdel HW param should be left margin, not right.
Fix tvdel HW param should upper margin, not lower.
This seems to fix lock issues on certain monitors (tested on a
slightly customized IP, but the FPGA guy said that it should
be the same wrt this changes).
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Acked-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
parallel to mutex_{lock,unlock,trylock,is_locked,lock_nested},
inode_foo(inode) being mutex_foo(&inode->i_mutex).
Please, use those for access to ->i_mutex; over the coming cycle
->i_mutex will become rwsem, with ->lookup() done with it held
only shared.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux
Pull fbdev updates from Tomi Valkeinen:
"Summary:
- pxafb: device-tree support
- An unsafe kernel parameter 'lockless_register_fb' for debugging
problems happening while inside the console lock
- Small miscellaneous fixes & cleanups
- omapdss: add writeback support functions
- Separation of omapfb and omapdrm (see below)
About the separation of omapfb and omapdrm, see
http://permalink.gmane.org/gmane.comp.video.dri.devel/143151
for longer story. The short version:
omapfb and omapdrm have shared low level drivers (omapdss and panel
drivers), making further development of omapdrm difficult. After
these patches omapfb and omapdrm have their own versions of the
drivers, which are more or less direct copies for now but will diverge
soon.
This also means that omapfb (everything under drivers/video/fbdev/omap2/)
is now in maintenance mode, and all new development will be done for
omapdrm (drivers/gpu/drm/omapdrm/)"
* tag 'fbdev-4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: (49 commits)
video: fbdev: pxafb: fix out of memory error path
drm/omap: make omapdrm select OMAP2_DSS
drm/omap: move omapdss & displays under omapdrm
omapfb: move vrfb into omapfb
omapfb: take omapfb's private omapdss into use
omapfb/displays: change CONFIG_DISPLAY_* to CONFIG_FB_OMAP2_*
omapfb/dss: change CONFIG_OMAP* to CONFIG_FB_OMAP*
omapdss: remove CONFIG_OMAP2_DSS_VENC from omapdss.h
omapfb: copy omapdss & displays for omapfb
omapfb: allow compilation only if DRM_OMAP is disabled
fbdev: omap2: panel-dpi: simplify gpio setting
fbdev: omap2: panel-dpi: in .disable first disable backlight then display
OMAPDSS: DSS: fix a warning message
video: omapdss: delete unneeded of_node_put
OMAPDSS: DISPC: Remove boolean comparisons
OMAPDSS: DSI: cleanup DSI_IRQ_ERROR_MASK define
OMAPDSS: remove extra out == NULL checks
OMAPDSS: change internal dispc functions to static
OMAPDSS: make a two dss feat funcs internal to omapdss
OMAPDSS: remove extra EXPORT_SYMBOLs
...
|
|
As seen by Julia, the initial allocation memory is not checked anymore
after commit "video: fbdev: pxafb: initial devicetree conversion".
Introduce back the removed test.
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO updates from Linus Walleij:
"Here is the bulk of GPIO changes for v4.5.
Notably there are big refactorings mostly by myself, aimed at getting
the gpio_chip into a shape that makes me believe I can proceed to
preserve state for a proper userspace ABI (character device) that has
already been proposed once, but resulted in the feedback that I need
to go back and restructure stuff. So I've been restructuring stuff.
On the way I ran into brokenness (return code from the get_value()
callback) and had to fix it. Also, refactored generic GPIO to be
simpler.
Some of that is still waiting to trickle down from the subsystems all
over the kernel that provide random gpio_chips, I've touched every
single GPIO driver in the kernel now, oh man I didn't know I was
responsible for so much...
Apart from that we're churning along as usual.
I took some effort to test and retest so it should merge nicely and we
shook out a couple of bugs in -next.
Infrastructural changes:
- In struct gpio_chip, rename the .dev node to .parent to better
reflect the fact that this is not the GPIO struct device
abstraction. We will add that soon so this would be totallt
confusing.
- It was noted that the driver .get_value() callbacks was sometimes
reporting negative -ERR values to the gpiolib core, expecting them
to be propagated to consumer gpiod_get_value() and gpio_get_value()
calls. This was not happening, so as there was a mess of drivers
returning negative errors and some returning "anything else than
zero" to indicate that a line was active. As some would have bit
31 set to indicate "line active" it clashed with negative error
codes. This is fixed by the largeish series clamping values in all
drivers with !!value to [0,1] and then augmenting the code to
propagate error codes to consumers. (Includes some ACKed patches
in other subsystems.)
- Add a void *data pointer to struct gpio_chip. The container_of()
design pattern is indeed very nice, but we want to reform the
struct gpio_chip to be a non-volative, stateless business, and keep
states internal to the gpiolib to be able to hold on to the state
when adding a proper userspace ABI (character device) further down
the road. To achieve this, drivers need a handle at the internal
state that is not dependent on their struct gpio_chip() so we add
gpiochip_add_data() and gpiochip_get_data() following the pattern
of many other subsystems. All the "use gpiochip data pointer"
patches transforms drivers to this scheme.
- The Generic GPIO chip header has been merged into the general
<linux/gpio/driver.h> header, and the custom header for that
removed. Instead of having a separate mm_gpio_chip struct for
these generic drivers, merge that into struct gpio_chip,
simplifying the code and removing the need for separate and
confusing includes.
Misc improvements:
- Stabilize the way GPIOs are looked up from the ACPI legacy
specification.
- Incremental driver features for PXA, PCA953X, Lantiq (patches from
the OpenWRT community), RCAR, Zynq, PL061, 104-idi-48
New drivers:
- Add a GPIO chip to the ALSA SoC AC97 driver.
- Add a new Broadcom NSP SoC driver (this lands in the pinctrl dir,
but the branch is merged here too to account for infrastructural
changes).
- The sx150x driver now supports the sx1502"
* tag 'gpio-v4.5-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (220 commits)
gpio: generic: make bgpio_pdata always visible
gpiolib: fix chip order in gpio list
gpio: mpc8xxx: Do not use gpiochip_get_data() in mpc8xxx_gpio_save_regs()
gpio: mm-lantiq: Do not use gpiochip_get_data() in ltq_mm_save_regs()
gpio: brcmstb: Allow building driver for BMIPS_GENERIC
gpio: brcmstb: Set endian flags for big-endian MIPS
gpio: moxart: fix build regression
gpio: xilinx: Do not use gpiochip_get_data() in xgpio_save_regs()
leds: pca9532: use gpiochip data pointer
leds: tca6507: use gpiochip data pointer
hid: cp2112: use gpiochip data pointer
bcma: gpio: use gpiochip data pointer
avr32: gpio: use gpiochip data pointer
video: fbdev: via: use gpiochip data pointer
gpio: pch: Optimize pch_gpio_get()
Revert "pinctrl: lantiq: Implement gpio_chip.to_irq"
pinctrl: nsp-gpio: use gpiochip data pointer
pinctrl: vt8500-wmt: use gpiochip data pointer
pinctrl: exynos5440: use gpiochip data pointer
pinctrl: at91-pio4: use gpiochip data pointer
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight
Pull backlight updates from Lee Jones:
Fix-ups:
- Take heed of GPIO default-on requests; gpio_backlight
- Enable DT probing; tps65217_bl
Bug Fixes:
- Free resources in error path; pwm_bl
- Fix uninitialised variable warning; adp8860_bl, adp8870_bl
- Protect unconditional DT look-ups from non-DT platforms; pwm_bl
- Fix backlight flicker; pwm_bl
* tag 'backlight-for-linus-4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight:
backlight: pwm_bl: Free PWM requested by legacy API on error path
backlight: adp8860: Fix another uninitialized variable use
backlight: gpio-backlight: Use default-on on GPIO request
backlight: pwm_bl: Fix broken PWM backlight for non-dt platforms
backlight: tps65217_bl: Add MODULE_DEVICE_TABLE
backlight: pwm_bl: Avoid backlight flicker when probed from DT
backlight: adp88x0: Fix uninitialized variable use
|
|
If pwm is requested by legacy pwm_request() and if the following
backlight_device_register() call fails, add pwm_free() clean-up.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
A recent patch I did fixed two potential uses of uninitialized
variables in the adp8870 and adp8860 drivers. Unfortunately,
I missed another one:
drivers/video/backlight/adp8860_bl.c: In function 'adp8860_bl_ambient_light_level_show':
drivers/video/backlight/adp8860_bl.c:570:11: warning: 'reg_val' may be used uninitialized in this function
This does the same change as before in one additional function,
and also changes the check for the return value in a way that
avoids another false positive warning with a similar message.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 6be3a5a9cd91 ("backlight: adp88x0: Fix uninitialized variable use")
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
There are situations where the backlight should be on at boot time
(e.g. if the boot loader already turned the display on). The DT
bindings specify the "default-on" property for that purpose.
Currently, the initial state of the GPIO at request time is always
set to logical off (high or low depending on whether it is an
active high or low GPIO). Since the GPIO is requested as an output,
the GPIO will be driven low for a short period of time, which leads
to a flickering display in the above use-case.
Initialize the GPIO depending on the default-on property to be
logical on or off.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
Commit ee65ad0e2a9e ("backlight: pwm_bl: Avoid backlight flicker when
probed from DT") tries to dereference the device of_node pointer
unconditionally, causing a NULL pointer dereference on non-dt platforms.
Fix it by replacing the phandle variable with a node variable and
by checking that for NULL before dereferencing it.
Reported-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
The device table is required to load modules based on modaliases.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
If the driver is probed from the device tree, and there is a phandle
property set on it, and the enable GPIO is already configured as output,
and the backlight is currently disabled, keep it disabled.
If all these conditions are met, assume there will be some other driver
that can enable the backlight at the appropriate time.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
gcc correctly warns about both the adp8860 and adp8870 backlight
drivers using an uninitialized variable in their error handling
path:
drivers/video/backlight/adp8870_bl.c: In function 'adp8870_bl_ambient_light_zone_store':
drivers/video/backlight/adp8870_bl.c:811:11: warning: 'reg_val' may be used uninitialized in this function
This changes the code to only write back the data if it was
correctly read to start with.
As a side-note, the drivers are mostly identical, so I think they
should really be merged into one file to avoid having to fix every
bug twice.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
This makes the driver use the data pointer added to the gpio_chip
to store a pointer to the state container instead of relying on
container_of().
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
As we want gpio_chip .get() calls to be able to return negative
error codes and propagate to drivers, we need to go over all
drivers and make sure their return values are clamped to [0,1].
We do this by using the ret = !!(val) design pattern.
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Now that omapfb has its own copy of omapdss and display drivers, we can
move omapdss and display drivers which omapdrm uses to omapdrm's
directory.
We also need to change the main drm Makefile so that omapdrm directory
is always entered, because omapdss has a file that can't be built as a
module.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
|
|
VRFB is only used by omapfb, so we can move it under omapfb's directory.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
|
|
omapfb's private copy of omapdss is now ready to be used.
This patch makes omapfb use its private omapdss and display drivers, and
also makes omap_vout (which uses omapfb) to depend on omapfb.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
|
|
We need to change the config symbols of omapfb's private copy of the
panel and encoder drivers so that we won't have config symbol conflicts.
This patch changes the symbols from the panel and encoder drivers using
simple replacement of DISPLAY_* to FB_OMAP2*.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
|
|
We need to change the config symbols of omapfb's private copy of
omapdss so that we won't have config symbol conflicts.
This patch changes the symbols from omapdss using simple replacement of
CONFIG_OMAP* to CONFIG_FB_OMAP*.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
|
|
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
The original files are in:
drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/
Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:
A short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and related) SoCs. It offers only a
kernel internal API, and does not implement anything for fbdev or drm.
* omapdss panels and encoders, located in
drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
drivers, which use APIs offered by omapdss driver. These also don't implement
anything for fbdev or drm.
* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
uses omapdss and the panel/encoder drivers to operate the hardware.
* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
driver, which uses omapdss and the panel/encoder drivers to operate the
hardware.
* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.
The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used. At some point in the future I'd like to remove omapfb and
omap_vout altogether.
Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.
I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.
This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.
The omapfb+omap_vout versions won't be touched unless there are some big issues
there.
The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.
This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
|
|
At the moment omapfb and omapdrm can be compiled at the same time, if
both are modules. However, they can't be both loaded, as they use the
same hardware. This has been mostly for compile testing.
To make it clear that omapfb and omapdrm are mutually exclusive drivers,
this patch makes omapfb available only if omapdrm is disabled.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
|
|
gpiod_set_value_cansleep is a noop when the passed descriptor is NULL.
So there is no need to duplicate the check for NULL; just call the
function unconditionally instead.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
This makes .disable operate in reverse order compared to .enable.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The WARN() macro has to take a condition. The current code will just
print the stack trace and the function name instead of the intended
warning message.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|