Add device tree bindings for OMAP Display Subsystem for the following
SoCs: OMAP2, OMAP3, OMAP4.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Add DT support for panel-sony-acx565akm
Signed-off-by: Sebastian Reichel <sre@debian.org>
[tomi.valkeinen@ti.com: some modifications]
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Add the code to make the DSI driver work with device tree on OMAP3 and
OMAP4.
A minor hack is needed at the moment in the DSI driver: the DSS driver
needs to know the ID number of a DSI device, as clocks are routed in
different ways to the DSI devices. At the moment we don't have any
proper way to manage this, so this patchs adds a simple lookup table
that is used to deduce the ID from the DSI device's base address.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Add DT support to VENC.
In contrast to non-DT version, the DT version gets the invert-polarity
and connector type via venc's endpoint, not from the connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Add DT support to HDMI driver. The only thing needed for DT support here
is the of_match_table.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Add DT support to DISPC. Only thing needed here is the of_match_table.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Add DT support for DSS. Contrary to the non-DT version, the DSS in DT
mode contains DPI and SDI outputs, which better reflects the hardware.
The non-DT code will be removed after all boards have been converted to
DT, so there's no need to change the non-DT code to act the same way.
The code for DPI and SDI needs to be refined later to make it possible
to add multiple DPI ports. For now, handling just a single DPI port is
enough for all the boards.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
The regulator names used for DSS components are somewhat ugly for DT
use. As we're just adding DT support, it's simple to change the
regulator names.
This patch makes the DSS driver get the regulators with somewhat cleaner
names when bootin with DT. For example, this allows us to define HDMI's
VDDA regulator in the DT data as:
vdda-supply = <...>;
instead of
vdda_hdmi_dac-supply = <...>;
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Add helpers to get ports and endpoints from DT data.
These helpers parse v4l2 style ports and endpoints, but compared to the
v4l2 helpers, these allow iterating ports and endpoints separately.
This is a temporary solution until we get generic code to parse the
ports and endpoints.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Improve the search for the default display in two ways:
* compare the given display name to the display's alias
* if no display name is given, look for "display0" DT alias
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Separate the code for finding the default display into a function for
clarity and to make it easier to extend it in the future.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
We currently create a "displayX" style alias name for all displays,
using a number that is incremented for each registered display. With the
new DSS device model there is no clear order in which the displays are
registered, and thus the numbering is somewhat random.
This patch improves the behavior for DT case so that if the displays
have been assigned DT aliases, those aliases will be used as DSS
aliases.
This means that "display0" is always the one specified in the DT alias,
and thus display0 can be used as default display in case the user didn't
specify a default display.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Add support to get the label (i.e. a "nickname") for a display from the
DT data. If there is no label defined, use the display's alias (e.g.
'display0') as a name.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
As there is no common panel framework in the kernel, we have OMAP
specific panel drivers. However, the DT data should be generic. This
brings the issue that some other platform could use the same panels, and
would need to create a driver with the same 'compatible' string as the
OMAP driver.
In the long run, we have to get a common panel framework. For the time
being, this patch solves the issue:
At early boot time, we go through the DT nodes looking for the panels
the kernel supports for OMAP. For each found node, the 'compatible'
string is prepended with "omapdss,", i.e. "sony,acx565akm" becomes
"omapdss,sony,acx565akm". The OMAP display drivers all have "omapdss,"
at the beginning of their compatible field.
This allows us to have generic DT data, but OMAP specific display
drivers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
The OMAP display architecture requires a bunch of platform devices which
are not created via .dts (for now). We also need to pass a few function
pointers and the DSS hardware version from the arch code to omapdss
driver.
This patch adds omapdss_init_of() function, called from board-generic at
init time, which handles those tasks.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
If x86-sysfb platform-devices are removed from a system, we should
properly unload vesafb. Otherwise, we end up releasing the parent while
our vesa framebuffer is still running. This currently works just fine, but
will cause problems on handover to real hw. So add the ->remove() callback
and unregister vesafb.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
If x86-sysfb platform-devices are removed from a system, we should
properly unload efifb. Otherwise, we end up releasing the parent while our
efi framebuffer is still running. This currently works just fine, but will
cause problems on handover to real hw. So add the ->remove() callback and
unregister efifb.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
This is necessary in order to make the core set file->private_data to
miscdev in use. We need that information later to dereference the
container of the device, so we can get access to our private struct from
other callbacks.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Instead of passing around struct platform_device, use struct device.
That saves one level of dereference. Also, call platform devices pdev,
and provide a shortcut for &pdev->dev.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Prefix some functions with more specific names. While at it, kill some
stray newlines and other coding style related minor things.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Because uvesafb_vbe_init will fail when get zero avaiable modes,
and we have checked the return value of uvesafb_vbe_init_mode,
so it is impossible to pass NULL as mode into uvesafb_init_info.
[ This patch fix warning report by fengguang.wu@intel.com
"drivers/video/fbdev/uvesafb.c:1509 uvesafb_init_info()
error: we previously assumed 'mode' could be null" ]
Signed-off-by: Wang YanQing <udknight@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Because uvesafb_par is allocated as part of fb_info in uvesafb_probe,
so we don't need to do NULL check for both fb_info and uvesafb_par in
uvesafb_remove.
[ This patch also fix a warning report by fengguang.wu@intel.com
"drivers/video/fbdev/uvesafb.c:1815 uvesafb_remove()
warn: variable dereferenced before check 'par'" ]
Signed-off-by: Wang YanQing <udknight@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
If NO_DMA=y:
drivers/built-in.o: In function `ocfb_remove':
ocfb.c:(.text+0x27fee): undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `ocfb_probe':
ocfb.c:(.text+0x28418): undefined reference to `dma_alloc_coherent'
ocfb.c:(.text+0x284d2): undefined reference to `dma_free_coherent'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
omapdss has its own video-timings struct, but we want to move the common
videomode.
The first step is to change the omapdss's pixelclock unit from kHz to
Hz. Also, omapdss uses "pixel_clock" field name, whereas the common
videomode uses "pixelclock" field name. This patch changes the field
name also, as that makes it easy to spot any non-converted pixel_clock
uses.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The omapdss driver no longer uses get_context_loss_count call, so we can
remove it.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Instead of relying on the OMAP specific
omap_pm_get_dev_context_loss_count() to detect register context loss, we
can achieve the same in a much simpler way by just observing the DISPC
registers.
We always set DISPC's load mode to LOAD_FRAME_ONLY, which is not the
reset value. Thus we can just observe the load mode to see if we have
lost register context.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Update driver to use SIMPLE_DEV_PM_OPS macro for power
management suspend and resume operations.
Signed-off-by: Manish Badarkhe <badarkhe.manish@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Instead of assigning the pm_ops fields individually we can simply
use SIMPLE_DEV_PM_OPS.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Currently, driver uses backlight class to control contrast value.
This is not correct. This patch resolves this issue by removing
backlight class from the driver and replace handling of LCDC PWM
Contrast Control Register by contrast control through LCD class.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We have no reason to call fb_get_options() when registering module,
so move this call in the probe() and convert the driver to use
module_platform_driver() macro.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Some fields in platform data structure is never used by boards.
This patch removes these fields and as a result optimizes private
driver structure a bit. Additionally patch removes backligh_power()
callback, so if it will be needed in the future, this feature should
be added as pwm{gpio,etc.}-regulator to the board code or in the DTS.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
