Commit Graph

6 Commits

Author SHA1 Message Date
Dmitry Torokhov
2988f8f946 video: fbdev: pmag-aa-fb: remove incorrect __exit markups
Even if bus is not hot-pluggable, devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2017-03-20 18:31:00 +01:00
Maciej W. Rozycki
5832706e8b video: fbdev: pmag-ba-fb: Optimize Bt455 colormap addressing
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>
2016-02-26 13:06:11 +02:00
Maciej W. Rozycki
01ac59c344 video: fbdev: pmag-ba-fb: Fix and rework Bt455 colormap handling
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>
2016-02-26 13:06:11 +02:00
Maciej W. Rozycki
df0821043f video: fbdev: pmag-aa-fb: Report video timings
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>
2016-02-26 13:06:11 +02:00
Maciej W. Rozycki
90c83176e5 video: fbdev: pmag-aa-fb: Adapt to current APIs
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>
2016-02-26 13:06:10 +02:00
Tomi Valkeinen
f7018c2135 video: move fbdev to drivers/video/fbdev
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 <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Rob Clark <robdclark@gmail.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-04-17 08:10:19 +03:00