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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
When booting with DT, there's a crash when omapfb is probed. This is
caused by the fact that omapdss+DT is not yet supported, and thus
omapdss is not probed at all. On the other hand, omapfb is always
probed. When omapfb tries to use omapdss, there's a NULL pointer
dereference crash. The same error should most likely happen with omapdrm
and omap_vout also.
To fix this, add an "initialized" state to omapdss. When omapdss has
been probed, it's marked as initialized. omapfb, omapdrm and omap_vout
check this state when they are probed to see that omapdss is actually
there.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Pull drm updates from Dave Airlie:
"This is the main drm pull request for 3.10.
Wierd bits:
- OMAP drm changes required OMAP dss changes, in drivers/video, so I
took them in here.
- one more fbcon fix for font handover
- VT switch avoidance in pm code
- scatterlist helpers for gpu drivers - have acks from akpm
Highlights:
- qxl kms driver - driver for the spice qxl virtual GPU
Nouveau:
- fermi/kepler VRAM compression
- GK110/nvf0 modesetting support.
Tegra:
- host1x core merged with 2D engine support
i915:
- vt switchless resume
- more valleyview support
- vblank fixes
- modesetting pipe config rework
radeon:
- UVD engine support
- SI chip tiling support
- GPU registers initialisation from golden values.
exynos:
- device tree changes
- fimc block support
Otherwise:
- bunches of fixes all over the place."
* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (513 commits)
qxl: update to new idr interfaces.
drm/nouveau: fix build with nv50->nvc0
drm/radeon: fix handling of v6 power tables
drm/radeon: clarify family checks in pm table parsing
drm/radeon: consolidate UVD clock programming
drm/radeon: fix UPLL_REF_DIV_MASK definition
radeon: add bo tracking debugfs
drm/radeon: add new richland pci ids
drm/radeon: add some new SI PCI ids
drm/radeon: fix scratch reg handling for UVD fence
drm/radeon: allocate SA bo in the requested domain
drm/radeon: fix possible segfault when parsing pm tables
drm/radeon: fix endian bugs in atom_allocate_fb_scratch()
OMAPDSS: TFP410: return EPROBE_DEFER if the i2c adapter not found
OMAPDSS: VENC: Add error handling for venc_probe_pdata
OMAPDSS: HDMI: Add error handling for hdmi_probe_pdata
OMAPDSS: RFBI: Add error handling for rfbi_probe_pdata
OMAPDSS: DSI: Add error handling for dsi_probe_pdata
OMAPDSS: SDI: Add error handling for sdi_probe_pdata
OMAPDSS: DPI: Add error handling for dpi_probe_pdata
...
If the I2C adapter needed by the TFP410 device is not available yet,
return EPROBE_DEFER so that the device will get probed again.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add proper error handling for venc_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the VENC driver to be
probed again later if a resource was missing.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add proper error handling for hdmi_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the HDMI driver to be
probed again later if a resource was missing.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add proper error handling for rfbi_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the RFBI driver to be
probed again later if a resource was missing.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add proper error handling for dsi_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the DSI driver to be
probed again later if a resource was missing.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add proper error handling for sdi_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the SDI driver to be
probed again later if a resource was missing.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add proper error handling for dpi_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the DPI driver to be
probed again later if a resource was missing.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Use platform_driver_register() instead of platform_driver_probe() so
that we can support EPROBE_DEFER.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Use platform_driver_register() instead of platform_driver_probe() so
that we can support EPROBE_DEFER.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Use platform_driver_register() instead of platform_driver_probe() so
that we can support EPROBE_DEFER.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Use platform_driver_register() instead of platform_driver_probe() so
that we can support EPROBE_DEFER.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Use platform_driver_register() instead of platform_driver_probe() so
that we can support EPROBE_DEFER.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Use platform_driver_register() instead of platform_driver_probe() so
that we can support EPROBE_DEFER.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
omapfb requires the panel drivers to have been probed when omapfb is
initialized. omapfb does not support insertion of new panels after its
probe. This causes a problem in case omapdss or the panel probes have
been deferred due to EPROBE_DEFER error, as omapfb won't find any
displays.
As a quick fix, this patch changes the omapfb probe so that if omapfb
does not find any displays, it'll return EPROBE_DEFER. This is not
perfect, as with a board with no displays, omapfb will get deferred
forever. Also, if the board has multiple displays, but only some of them
have been probed, omapfb will start and leave the unprobed displays out.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Instead of using platform_driver_probe(), use module_platform_driver()
so that we can support deferred probing.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
omapfb requires the panels to have been probed before omapfb's probe. We
currently manage that by having omapfb in late initcall level. However,
a much simpler way is to just change the makefile so that omapfb is
after the panel drivers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Commit 100c826235 (OMAPDSS: DPI: use new
clock calculation code) breaks dpi.c compilation if DSI is not enabled
in the kernel configuration.
Fix compilation by adding dummy inline functions for the ones that dpi.c
references. The functions will never be called, as dpi.c knows that
there is no DSI device available.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Use vm_iomap_memory() instead of [io_]remap_pfn_range().
vm_iomap_memory() gives us much simpler API to map memory to userspace,
and reduces possibilities for bugs.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
When not using DSI PLL to generate the pixel clock, but DSS FCK, the
possible pixel clock rates are rather limited. DSS FCK is currently used
on OMAP2 and OMAP3.
When using Beagleboard with a monitor that supports high resolutions,
the clock rates do not match (at least for me) for the monitor's pixel
clocks within the current threshold in the code, which is +/- 1MHz.
This patch widens the search up to +/- 15MHz. The search is done in
steps, i.e. it first tries to find a rather exact clock, than a bit less
exact, etc. so this should not change the cases where a clock was
already found.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
