Commit Graph

5809 Commits

Author SHA1 Message Date
Tomi Valkeinen deb16df884 OMAPDSS: DSI: Add ops
Add "ops" style method for using DSI functionality.

Ops style calls will allow us to have arbitrarily long display
pipelines, where each entity can call ops in the previous display
entity.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:01:01 +03:00
Tomi Valkeinen 0b450c3131 OMAPDSS: HDMI: Add ops
Add "ops" style method for using HDMI functionality.

Ops style calls will allow us to have arbitrarily long display
pipelines, where each entity can call ops in the previous display
entity.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:01:00 +03:00
Tomi Valkeinen fb8efa4966 OMAPDSS: AnalogTV: Add ops
Add "ops" style method for using analog TV functionality.

Ops style calls will allow us to have arbitrarily long display
pipelines, where each entity can call ops in the previous display
entity.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:01:00 +03:00
Tomi Valkeinen b1082dfd61 OMAPDSS: SDI: Add ops
Add "ops" style method for using SDI functionality.

Ops style calls will allow us to have arbitrarily long display
pipelines, where each entity can call ops in the previous display
entity.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:59 +03:00
Tomi Valkeinen 0b24edb1c7 OMAPDSS: DPI: Add ops
Add "ops" style method for using DPI functionality.

Ops style calls will allow us to have arbitrarily long display
pipelines, where each entity can call ops in the previous display
entity.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:59 +03:00
Tomi Valkeinen bc24b8b6d7 OMAPDSS: add OMAP_DISPLAY_TYPE_DVI
Add new display bus type for DVI. This is not used by omapdss driver
itself, but is used by external encoder chips that output DVI.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:58 +03:00
Tomi Valkeinen efedce1425 OMAPDSS: modify get/find functions to go through the device chain
In the future will have arbitrarily long video pipeline chains, instead
of the current two-entities-per-pipeline model.

This patch changes the affected get/find style functions so that they
properly go through the video pipeline chain, for example when getting
the overlay manager connected to a given display.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:57 +03:00
Tomi Valkeinen 5d47dbc852 OMAPDSS: public omapdss_register_output()
In order to allow multiple display block in a video pipeline, we need to
give the drivers way to register themselves. For now we have
the omapdss_register_display() which is used to register panels, and
dss_register_output() which is used to register DSS encoders.

This patch makes dss_register_output() public (with the name of
omapdss_register_output), which can be used to register also external
encoders. The distinction between register_output and register_display
is that a "display" is an entity at the end of the videopipeline, and
"output" is something inside the pipeline.

The registration and naming will be made saner in the future, but the
current names and functions are kept to minimize changes during the dss
device model transition.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:57 +03:00
Sergey Kibrik 595470a785 OMAPDSS: gracefully disable overlay at error
Disable overlay via ovl->disable() interface, which will
properly set flags in cache and GO bits for managers.
This allows overlay user to re-enable it on next frame,
thus recovering from FIFO underflows.

Signed-off-by: Sergey Kibrik <sergiikibrik@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:56 +03:00
Emil Goode b0e449ce65 OMAPDSS: Remove kfree for memory allocated with devm_kzalloc
It's not necessary to free memory allocated with devm_kzalloc
in a remove function and using kfree leads to a double free.

Signed-off-by: Emil Goode <emilgoode@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:56 +03:00
Tomi Valkeinen 5391e87d12 OMAPDSS: remove dispc's dependency to VENC/HDMI
DISPC needs to know the clock rate for DIGIT (i.e. TV) channel, and this
clock is provided by either VENC or HDMI modules. Currently DISPC will
call a function in VENC/HDMI, asking what the clock rate is. This means
we have a fixed dependency from DISPC to both VENC and HDMI.

To have a more generic approach, and in particular to allow adding OMAP5
HDMI driver, we need to remove this dependency. This patch makes
VENC/HDMI inform DISPC when the their clock changes, thus reversing the
dependency and removing the issue.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:55 +03:00
Tomi Valkeinen 29356be1e0 OMAPDSS: HDMI clean up hpd_gpio
hpd_gpio is no longer used by the OMAP4 HDMI IP driver, and we can thus
remove the unnecessary code.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:54 +03:00
Tomi Valkeinen ddb1d5ca99 OMAPDSS: HDMI: clean up PHY power handling
The TRM tells to set PHY to TXON only after getting LINK_CONNECT, and to
set PHY to OFF or LDOON after getting LINK_DISCONNECT, in order to avoid
damage to the PHY.

We don't currently do it quite like that. Instead of using the HDMI
interrupts, we use HPD signal. This works, but is not actually quite
correct, as HPD comes at a different time than LINK_CONNECT and
LINK_DISCONNECT interrupts. Also, the HPD GPIO is a property of the TPD
level shifter, not HDMI IP, so handling the GPIO in the HDMI driver is
wrong.

This patch implements the PHY power handling correctly, using the
interrupts.

There is a corner case that causes some additional difficulties: we may
get both LINK_CONNECT and LINK_DISCONNECT interrupts at the same time.
This is handled in the code by retrying: turning off the PHY, clearing
the interrupt status, and re-enabling the PHY. This causes a new
LINK_CONNECT interrupt to happen if a cable is connected.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:54 +03:00
Tomi Valkeinen e9f322b491 OMAPFB: use EPROBE_DEFER if default display is not present
Currently omapfb returns EPROBE_DEFER if no displays have been probed at
the time omapfb is probed. However, sometimes some of the displays have
been probed at that time, but not all. We can't return EPROBE_DEFER in
that case, because then one missing driver would cause omapfb to defer
always, preventing any display from working.

However, if the user has defined a default display, we can presume that
the driver for that display is eventually loaded. Thus, this patch
changes omapfb to return EPROBE_DEFER in case default display is not
found.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:54 +03:00
Tomi Valkeinen 820caabf68 OMAPDSS: output: increase refcount in find_output funcs
Now that omap_dss_output has been combined into omap_dss_device, we can
add ref counting for the relevant output functions also.

This patch adds omap_dss_get_device() calls to the various find_output()
style functions. This, of course, means that the users of those
find_output functions need to do a omap_dss_put_device() after use.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:53 +03:00
Tomi Valkeinen b7328e1459 OMAPDSS: add THIS_MODULE owner to DSS outputs
Setup the owner field for DSS output's omap_dss_device so that module
refcounting works.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:53 +03:00
Tomi Valkeinen d35317a42d OMAPDSS: add module_get/put to omap_dss_get/put_device()
omap_dss_get_device() should be called for omap_dss_device before it is
used to increase its refcount. Currently we only increase the refcount
for the underlying device.

This patch adds managing the ref count to the underlying module also,
which contains the ops for the omap_dss_device.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:52 +03:00
Tomi Valkeinen 1f68d9c4b6 OMAPDSS: combine omap_dss_output into omap_dss_device
We currently have omap_dss_device, which represents an external display
device, sometimes an external encoder, sometimes a panel. Then we have
omap_dss_output, which represents DSS's output encoder.

In the future with new display device model, we construct a video
pipeline from the display blocks. To accomplish this, all the blocks
need to be presented by the same entity.

Thus, this patch combines omap_dss_output into omap_dss_device. Some of
the fields in omap_dss_output are already found in omap_dss_device, but
some are not. This means we'll have DSS output specific fields in
omap_dss_device, which is not very nice. However, it is easier to just
keep those output specific fields there for now, and after transition to
new display device model is made, they can be cleaned up easier than
could be done now.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:51 +03:00
Tomi Valkeinen d392393393 OMAPDSS: remove omap_dss_start/stop_device()
The omap_dss_start_device() and omap_dss_stop_device(), called by the
DSS output drivers, are old relics. They originally did something
totally else, but nowadays they increase the module ref count for panels
that are enabled.

This model is quite broken: the panel modules may be used even before
they are enabled. For example, configuring the panel requires calls to
functions located in the panel modules.

In the following patches we try to improve the ref count management for
the modules and display devices. The first step, however, is to remove
the omap_dss_start/stop_device() totally.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:51 +03:00
Tomi Valkeinen ecc8b37089 OMAPDSS: Add panel dev pointer to dssdev
We are about to remove the dss bus support, which also means that the
omap_dss_device won't be a real device anymore. This means that the
embedded "dev" struct needs to be removed from omap_dss_device.

After we've finished the removal of the dss bus, we see the following
changes:

- struct omap_dss_device won't be a real Linux device anymore, but more
  like a "display entity".
- struct omap_dss_driver won't be a Linux device driver, but "display
  entity ops".
- The panel devices/drivers won't be omapdss devices/drivers, but
  platform/i2c/spi/etc devices/drivers, whichever fits the control
  mechanism of the panel.
- The panel drivers will create omap_dss_device and omap_dss_driver,
  fill the required fields, and register the omap_dss_device to
  omapdss.
- omap_dss_device won't have an embedded dev struct anymore, but a
  dev pointer to the actual device that manages the omap_dss_device.

The model described above resembles the model that has been discussed
with CDF (common display framework).

For the duration of the conversion, we temporarily have two devs in the
dssdev, the old "old_dev", which is a full embedded device struct, and the
new "dev", which is a pointer to the device. "old_dev" will be removed
in the future.

For devices belonging to dss bus the dev is initialized to point to
old_dev. This way all the code can just use the dev, for both old and
new style panels.

Both the new and old style panel drivers work during the conversion, and
only after the dss bus support is removed will the old style panels stop
to compile.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:50 +03:00
Tomi Valkeinen 94140f0d22 OMAPDSS: implement display sysfs without dss bus
We aim to remove the custom omapdss bus totally, as it's quite a strange
construct and won't be compatible with common display framework. One
problem on the road is that we have sysfs files for each display, and
they depend on the omapdss bus.

This patch creates the display sysfs files independent of the omapdss
bus. This gives us backwards compatibility without using the omapdss bus
for the sysfs files.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:50 +03:00
Tomi Valkeinen a65c8bdab9 OMAPDSS: don't use dss bus in suspend/resume
We have support functions to suspend and resume all the displays that
are used with system suspend. These functions use the dss bus to iterate
the display devices.

As we aim to remove the custom dss bus totally, this patch removes the
explicit use of dss bus from these functions. Instead the
for_each_dss_dev() macro is used to go through the devices.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:49 +03:00
Tomi Valkeinen 67b23ca1b6 OMAPDSS: use the panel list in omap_dss_get_next_device
omap_dss_get_next_device() uses the dss bus to iterate over the
displays. This patch changes omap_dss_get_next_device() to use the new
panel list instead.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:49 +03:00
Tomi Valkeinen 2e7e3dc794 OMAPDSS: add panel list
We currently use the omapdss bus (which contains all the available
displays) to iterate the displays. As the omapdss bus is on its way out,
this needs to be changed.

Instead of using the dss bus to iterate displays, this patch adds our
own list of displays which we manage. The panels on the dss bus are
automatically added to this new list.

An "alias" field is also added to omap_dss_device. This field is
set to "display%d", the same way as omap_dss_device's dev name is set.
This alias is later used to keep backward compatibility, when the
embedded dev is no longer used.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:48 +03:00
Tomi Valkeinen 7ae9a71e09 OMAPDSS: remove dssdev uses in trivial cases
In the future the "dssdev" parameter passed to output drivers will
change its meaning. Instead of being a pointer to the panel device, it's
a pointer to the output instance.

To make the transition easier, some of the uses for this dssdev
parameter can be easily removed.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:48 +03:00
Tomi Valkeinen 6fcd485b04 OMAPDSS: add videomode conversion support
Add helper functions to convert between omapdss specific video timings
and the common videomode.

Eventually omapdss will be changed to use only the common video timings,
and these helper functions will make the transition easier.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:47 +03:00
Tomi Valkeinen 7e436bb2e3 OMAPDSS: VENC: clean up regulator init
Clean up the VENC driver's regulator init to remove the (unused)
omap_dss_device parameter, renaming the function to a more sensible
name, and making the code slightly clearer.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:47 +03:00
Tomi Valkeinen 46c4b64516 OMAPDSS: SDI: fix regulators for DT
SDI requires a regulator to operate. This regulator is, for some reason,
currently attached to the virtual omapdss device, instead of the SDI
device. This does not work for DT, as the regulator mappings need to be
described in the DT data, and the virtual omapdss device is not present
there.

Fix the issue by acquiring the regulator in the SDI device. To retain
compatibility with the current board files, the old method of getting
the regulator is kept. The old method can be removed when the board
files have been changed to pass the regulator to SDI.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:47 +03:00
Tomi Valkeinen d37801b3a2 OMAPDSS: SDI: clean up regulator init
Clean up the SDI driver's regulator init to remove the (unused)
omap_dss_device parameter, renaming the function to a more sensible
name, and making the code slightly clearer.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:46 +03:00
Tomi Valkeinen e25001d8be OMAPDSS: HDMI: add hdmi_init_regulator
Separate regulator init code into its own function for clarity.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:46 +03:00
Tomi Valkeinen 00df43b822 OMAPDSS: DPI: fix regulators for DT
On some platforms DPI requires a regulator to be enabled to power up the
output pins. This regulator is, for some reason, currently attached to
the virtual omapdss device, instead of the DPI device. This does not
work for DT, as the regulator mappings need to be described in the DT
data, and the virtual omapdss device is not present there.

Fix the issue by acquiring the regulator in the DPI device. To retain
compatibility with the current board files, the old method of getting
the regulator is kept. The old method can be removed when the board
files have been changed to pass the regulator to DPI.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:45 +03:00
Tomi Valkeinen 2795f646a7 OMAPDSS: DPI: cleanup pll & regulator init
Split regulator and DSI PLL init code to their own functions for
clarity.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:45 +03:00
Tomi Valkeinen b2541c40aa OMAPDSS: DSI: cleanup regulator init
Separate the regulator initialization code to its own function, removing
duplicate code.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:44 +03:00
Tomi Valkeinen 51930bba8e OMAPDSS: CORE: use devm_regulator_get
Use devm_regulator_get() instead of regulator_get() to simplify code.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:44 +03:00
Tomi Valkeinen a7e71e7f9f OMAPDSS: Implement display (dis)connect support
We currently have two steps in panel initialization and startup: probing
and enabling. After the panel has been probed, it's ready and can be
configured and later enabled.

This model is not enough with more complex display pipelines, where we
may have, for example, two panels, of which only one can be used at a
time, connected to the same video output.

To support that kind of scenarios, we need to add new step to the
initialization: connect.

This patch adds support for connecting and disconnecting panels. After
probe, but before connect, no panel ops should be called. When the
connect is called, a proper video pipeline is established, and the panel
is ready for use. If some part in the video pipeline is already
connected (by some other panel), the connect call fails.

One key difference with the old style setup is that connect() handles
also connecting to the overlay manager. This means that the omapfb (or
omapdrm) no longer needs to figure out which overlay manager to use, but
it can just call connect() on the panel, and the proper overlay manager
is connected by omapdss.

This also allows us to add back the support for dynamic switching
between two exclusive panels. However, the current panel device model is
not changed to support this, as the new device model is implemented in
the following patches and the old model will be removed. The new device
model supports dynamic switching.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:43 +03:00
Tomi Valkeinen 04b1fc0291 OMAPDRM: fix overlay manager handling
Currently omapdrm creates crtcs, which map directly to DSS overlay
managers, only on demand at init time. This would make it difficult to
manage connecting the display entities in the future, as the code cannot
just search for a suitable overlay manager.

We cannot fix this the sane way, which would be to create crtcs for each
overlay manager, because we need an overlay for each crtc. With limited
number of overlays, that's not possible.

So the solution for now is to detach the overlay manager from the crtc.
crtcs are still created on demand at init time, but all overlay managers
are always initialized by the omapdss.

This way we can create and connect whole display pipelines from the
overlay manager to the display, regardless of which crtcs omapdrm would
create.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:43 +03:00
Tomi Valkeinen 7f7cdbd688 OMAPDSS: split overlay manager creation
Split the function that creates overlay manager structs into two: one
that creates just the structs, and one that creates the sysfs files for
the manager.

This will help us use the overlay manager structs with omapdrm in the
following patches, while still leaving the sysfs files out.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:42 +03:00
Tomi Valkeinen be8e8e1c62 OMAPDSS: add helpers to get mgr or output from display
Add two helper functions that can be used to find either the DSS output
or the overlay manager that is connected to the given display.

This hides how the output and the manager are actually connected, making
it easier to change the connections in the future.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:42 +03:00
Tomi Valkeinen e724366498 OMAPDSS: clean up dss_[ovl|mgr]_get_device()
Minor cleanup for the dss_[ovl|mgr]_get_device() functions to make them
more readable.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:41 +03:00
Tomi Valkeinen 679852dbee OMAPDSS: fix dss_get_ctx_loss_count for DT
When using DT, dss device does not have platform data. However,
dss_get_ctx_loss_count() uses dss device's platform data to find the
get_ctx_loss_count function pointer.

To fix this, dss_get_ctx_loss_count() needs to be changed to get the
platform data from the omapdss device, which is a "virtual" device and
always has platform data.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:41 +03:00
Tomi Valkeinen 12ca755ba1 OMAPDSS: add omap_dss_find_output_by_node()
Add a support function to find a DSS output by given DT node. This is
used in later patches to link the panels to DSS outputs.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:40 +03:00
Tomi Valkeinen 805cc2d19c OMAPDSS: add omap_dss_find_output()
Add a support function to find a DSS output by given name. This is used
in later patches to link the panels to DSS outputs.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:40 +03:00
Tomi Valkeinen c6ca5b2201 OMAPDSS: only probe pdata if there's one
omapdss output drivers always read the platform data. This crashes when
there's no platform data when using DT.

Add a check to read the platform data only if it exists.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:39 +03:00
Tomi Valkeinen 0a20012605 OMAPDSS: add pdata->default_display_name
We can currently set the default display (i.e. the initial display) in
the omapdss platform data by using a pointer to the default
omap_dss_device. Internally omapdss uses the device's name to resolve
the default display.

As it's difficult to get the omap_dss_device pointer in the future,
after we've changed the omapdss device model, this patch adds a new way
to define the default display, by using the name of the display.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
2013-06-17 14:00:26 +03:00
Richard Genoud 56c21b53ab atmel_lcdfb: blank the backlight on remove
When removing atmel_lcdfb module, the backlight is unregistered but not
blanked. (only for CONFIG_BACKLIGHT_ATMEL_LCDC case).
This can result in the screen going full white depending on how the PWM
is wired.

Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
2013-06-01 03:18:55 +08:00
Richard Genoud 65ac057bce trivial: atmel_lcdfb: add missing error message
When a too small framebuffer is given, the atmel_lcdfb_check_var
silently fails.
Adding an error message will save some head scratching.

Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
2013-06-01 03:18:30 +08:00
Jean-Christophe PLAGNIOL-VILLARD 2436e8aa8a Merge branch 'fbdev-3.10-fixes' of git://gitorious.org/linux-omap-dss2/linux into linux-fbdev/for-3.10-fixes
Pull Tomi fixes for ps3fb and omap2

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
2013-05-29 17:00:34 +08:00
Geert Uytterhoeven e5ee7305ae fbdev: FB_GOLDFISH should depend on HAS_DMA
If NO_DMA=y:

  drivers/built-in.o: In function `goldfish_fb_remove':
  drivers/video/goldfishfb.c:301: undefined reference to `dma_free_coherent'
  drivers/built-in.o: In function `goldfish_fb_probe':
  drivers/video/goldfishfb.c:247: undefined reference to `dma_alloc_coherent'
  drivers/video/goldfishfb.c:280: undefined reference to `dma_free_coherent'

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-05-24 16:22:52 -07:00
Stephen Warren 26549c8d36 drivers/video: implement a simple framebuffer driver
A simple frame-buffer describes a raw memory region that may be rendered
to, with the assumption that the display hardware has already been set
up to scan out from that buffer.

This is useful in cases where a bootloader exists and has set up the
display hardware, but a Linux driver doesn't yet exist for the display
hardware.

Examples use-cases include:

* The built-in LCD panels on the Samsung ARM chromebook, and Tegra
  devices, and likely many other ARM or embedded systems.  These cannot
  yet be supported using a full graphics driver, since the panel control
  should be provided by the CDF (Common Display Framework), which has been
  stuck in design/review for quite some time.  One could support these
  panels using custom SoC-specific code, but there is a desire to use
  common infra-structure rather than having each SoC vendor invent their
  own code, hence the desire to wait for CDF.

* Hardware for which a full graphics driver is not yet available, and
  the path to obtain one upstream isn't yet clear.  For example, the
  Raspberry Pi.

* Any hardware in early stages of upstreaming, before a full graphics
  driver has been tackled.  This driver can provide a graphical boot
  console (even full X support) much earlier in the upstreaming process,
  thus making new SoC or board support more generally useful earlier.

[akpm@linux-foundation.org: make simplefb_formats[] static]
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Olof Johansson <olof@lixom.net>
Cc: Rob Clark <robclark@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-05-24 16:22:51 -07:00
Linus Torvalds 388c289697 Staging driver fixes for 3.10-rc2
Here are some staging tree driver fixes for 3.10-rc2
 
 The drivers/iio/ changes are here as they are still tied into
 drivers/staging/iio/.
 
 Nothing major, just a number of small bugfixes, and a larger documentation
 update for the ramster code.
 
 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (GNU/Linux)
 
 iEYEABECAAYFAlGeO5kACgkQMUfUDdst+ykILACdF6dUbLOa4Nvp9zqJcq87eBA2
 ubAAoMl6Cwwo1HGs8kzL/wNxSLQIxqTQ
 =XMx9
 -----END PGP SIGNATURE-----

Merge tag 'staging-3.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging

Pull staging driver fixes from Greg Kroah-Hartman:
 "Here are some staging tree driver fixes for 3.10-rc2

  The drivers/iio/ changes are here as they are still tied into
  drivers/staging/iio/.

  Nothing major, just a number of small bugfixes, and a larger
  documentation update for the ramster code."

* tag 'staging-3.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (28 commits)
  staging: dwc2: remove compile warning for USB_DWC2_TRACK_MISSED_SOFS
  iio: exynos_adc: fix wrong structure extration in suspend and resume
  iio:common:st: added disable function after read info raw data
  iio: dac: Fix build error when CONFIG_SPI_MASTER=y && CONFIG_I2C=m
  staging:iio:light:tsl2x7x: fix the error handling in tsl2x7x_probe()
  staging/iio/mxs-lradc: fix preenable for multiple buffers
  staging: imx-drm: imx-tve: Check the return value of 'regulator_enable()'
  staging: video: imx: Select VIDEOMODE_HELPERS for parallel display
  staging: ramster: add how-to document
  staging: dwc2: Fix dma-enabled platform devices using a default dma_mask
  staging: vt6656: [bug] Fix missing spin lock in iwctl_siwpower.
  staging: Swap zram and zsmalloc in Kconfig
  staging: android: logger: use kuid_t instead of uid_t
  staging: zcache: Fix incorrect module_param_array types
  staging/solo6x10: depend on CONFIG_FONTS
  staging/drm: imx: add missing dependencies
  staging: ste_rmi4: Suppress 'ignoring return value of ‘regulator_enable()' warning
  staging: sep: fix driver build and kconfig
  staging: nvec: cleanup childs on remove
  staging: nvec: implement unregistering of notifiers
  ...
2013-05-23 09:27:49 -07:00