linux-toradex.git/drivers/video, branch v3.15.5

drivers/video/fbdev/fb-puv3.c: Add header files for function unifb_mmap

2014-07-09T18:21:32+00:00

commit fbc6c4a13bbfb420eedfdb26a0a859f9c07e8a7b upstream.

Function unifb_mmap calls functions which are defined in linux/mm.h
and asm/pgtable.h

The related error (for unicore32 with unicore32_defconfig):
	CC      drivers/video/fbdev/fb-puv3.o
	drivers/video/fbdev/fb-puv3.c: In function 'unifb_mmap':
	drivers/video/fbdev/fb-puv3.c:646: error: implicit declaration of
				      function 'vm_iomap_memory'
	drivers/video/fbdev/fb-puv3.c:646: error: implicit declaration of
				      function 'pgprot_noncached'

Signed-off-by: Zhichuang Sun 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: Jingoo Han 
Cc: Daniel Vetter 
Cc: Joe Perches 
Cc: Laurent Pinchart 
Cc: linux-fbdev@vger.kernel.org
Acked-by: Xuetao Guan 
Signed-off-by: Tomi Valkeinen 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

Revert "offb: Add palette hack for little endian"

2014-07-01T03:14:01+00:00

commit 68986c9f0f4552c34c248501eb0c690553866d6e upstream.

This reverts commit e1edf18b20076da83dd231dbd2146cbbc31c0b14.

This patch was a misguided attempt at fixing offb for LE ppc64
kernels on BE qemu but is just wrong ... it breaks real LE/LE
setups, LE with real HW, and existing mixed endian systems
that did the fight thing with the appropriate device-tree
property. Bad reviewing on my part, sorry.

The right fix is to either make qemu change its endian when
the guest changes endian (working on that) or to use the
existing foreign endian support.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

matroxfb: perform a dummy read of M_STATUS

2014-07-01T03:13:56+00:00

commit 972754cfaee94d6e25acf94a497bc0a864d91b7e upstream.

I had occasional screen corruption with the matrox framebuffer driver and
I found out that the reason for the corruption is that the hardware
blitter accesses the videoram while it is being written to.

The matrox driver has a macro WaitTillIdle() that should wait until the
blitter is idle, but it sometimes doesn't work. I added a dummy read
mga_inl(M_STATUS) to WaitTillIdle() to fix the problem. The dummy read
will flush the write buffer in the PCI chipset, and the next read of
M_STATUS will return the hardware status.

Since applying this patch, I had no screen corruption at all.

Signed-off-by: Mikulas Patocka 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Greg Kroah-Hartman

video: Kconfig: move drm and fb into separate menus

2014-04-17T05:10:20+00:00

At the moment the "Device Drivers / Graphics support" kernel config page
looks rather messy, with DRM and fbdev driver selections on the same
page, some on the top level Graphics support page, some under their
respective subsystems.

If I'm not mistaken, this is caused by the drivers depending on other
things than DRM or FB, which causes Kconfig to arrange the options in
not-so-neat manner.

Both DRM and FB have a main menuconfig option for the whole DRM or FB
subsystem. Optimally, this would be enough to arrange all DRM and FB
options under the respective subsystem, but for whatever reason this
doesn't work reliably.

This patch adds an explicit submenu for DRM and FB, making it much
clearer which options are related to FB, and which to DRM.

Signed-off-by: Tomi Valkeinen 
Acked-by: Laurent Pinchart 
Acked-by: Geert Uytterhoeven 
Acked-by: Rob Clark 
Reviewed-by: Jingoo Han 
Acked-by: Daniel Vetter

fbdev: move fbdev core files to separate directory

2014-04-17T05:10:19+00:00

Instead of having fbdev framework core files at the root fbdev
directory, mixed with random fbdev device drivers, move the fbdev core
files to a separate core directory. This makes it much clearer which of
the files are actually part of the fbdev framework, and which are part
of device drivers.

Signed-off-by: Tomi Valkeinen 
Acked-by: Laurent Pinchart 
Acked-by: Geert Uytterhoeven 
Acked-by: Rob Clark 
Acked-by: Jingoo Han 
Acked-by: Daniel Vetter

video: move fbdev to drivers/video/fbdev

2014-04-17T05:10:19+00:00

The drivers/video directory is a mess. It contains generic video related
files, directories for backlight, console, linux logo, lots of fbdev
device drivers, fbdev framework files.

Make some order into the chaos by creating drivers/video/fbdev
directory, and move all fbdev related files there.

No functionality is changed, although I guess it is possible that some
subtle Makefile build order related issue could be created by this
patch.

Signed-off-by: Tomi Valkeinen 
Acked-by: Laurent Pinchart 
Acked-by: Geert Uytterhoeven 
Acked-by: Rob Clark 
Acked-by: Jingoo Han 
Acked-by: Daniel Vetter

video: bf54x-lq043fb: fix build error

2014-04-15T09:44:16+00:00

Fix build error by including linux/gpio.h. Also drop asm/gpio.h which is
not needed.

Signed-off-by: Steven Miao 
Signed-off-by: Tomi Valkeinen

OMAPDSS: Change struct reg_field to dispc_reg_field

2014-04-14T13:42:49+00:00

Avoid colision with regmap's struct reg_field definition by renaming
omapdss's struct reg_field to dispc_reg_field, and moving it inside
dispc.c as that's the only place it is used.

Signed-off-by: Jyri Sarha 
Signed-off-by: Tomi Valkeinen

OMAPDSS: Take pixelclock unit change into account in hdmi_compute_acr()

2014-04-14T13:17:26+00:00

Pixelclock unit change from kHz to Hz should be taken into account
in CTS value calculations in hdmi_compute_acr().

Signed-off-by: Jyri Sarha 
Signed-off-by: Tomi Valkeinen

OMAPDSS: fix shared irq handlers

2014-04-14T11:52:08+00:00

DSS uses shared irq handlers for DISPC and DSI, because on OMAP3, the
DISPC and DSI share the same irq line.

However, the irq handlers presume that the hardware is enabled, which,
in theory, may not be the case with shared irq handlers. So if an
interrupt happens while the DISPC/DSI is off, the kernel will halt as
the irq handler tries to access the DISPC/DSI registers.

In practice that should never happen, as both DSI and DISPC are in the
same power domain. So if there's an IRQ for one of them, the other is
also enabled. However, if CONFIG_DEBUG_SHIRQ is enabled, the kernel will
generate a spurious IRQ, which then causes the problem.

This patch adds an is_enabled field for both DISPC and DSI, which is
used to track if the HW is enabled. For DISPC the code is slightly more
complex, as the users of DISPC can register the interrupt handler, and
we want to hide the is_enabled handling from the users of DISPC.

Signed-off-by: Tomi Valkeinen