| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The scalers of overlays and writeback do not have any constraints on downscale
ratio when operating in memory to memory mode.
This is because in memory to memory mode, we aren't connected to a display which
needs data output at the rate of pixel clock. The scalers can perform as much
downscaling as needed, the rate at which the scaler outputs is adjusted
accordingly.
Relax constraints related to downscaling based on whether the input overlays are
connected to writeback in memory to memory mode. We pass a mem_to_mem boolean
parameter to dispc_ovl_setup() from APPLY. This is currently set to false, this
will later be configured to the correct value based on whether the overlay is
connected to writeback or not. Do the same later for writeback when writeback is
configured.
In the scaling calculation code, we calculate the minimum amount of core clock we
need to achieve the required downscaling. If we are in memory to memory mode, we
set this to a very small value(1 in this case), this value would always be
lesser than the actual DISPC core clock value, and hence the scaling checks
would succeed.
We take care that pixel clock isn't calculated for writeback and the overlays
connected to it when in memory to memory mode. A pixel clock in such cases
doesn't make sense.
Signed-off-by: Archit Taneja <archit@ti.com>
|
| |
|
|
|
|
|
|
|
|
| |
Now that an omap_dss_output can be used to link between managers and devices, we
can remove the old way of setting manager and device links. This involves
removing the device and manager pointers from omap_overlay_manager and
omap_dss_device respectively, and removing the set_device/unset_device ops from
omap_overlay_manager.
Signed-off-by: Archit Taneja <archit@ti.com>
|
| |
|
|
|
|
|
|
|
|
| |
An overlay isn't allowed to be enabled/disabled if it isn't connected to an
omap_dss_device. This requirement isn't needed any more. An overlay can be
enabled/disabled as long as it has an output connected to it. The output may
not be connected to a device, but we can be assured that the connected
manager's output is in use by an output interface.
Signed-off-by: Archit Taneja <archit@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
With the introduction of output entities, managers will now connect to outputs.
Create helper ops for overlays and managers named get_device. This will abstract
away the information on how to get the device from an overlay or an overlay
manager. The get_device ops currently retrieve the output via a
ovl->manager->device reference. This will be later replaced by
ovl->manager->output->device references.
Signed-off-by: Archit Taneja <archit@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add set_output/unset_output ops for overlay managers, these form links between
managers and outputs. Create a function in dss features which tell all the
output instances that connect to a manager, use it when a manager tries to set
an output. Add a constraint of not unsetting an output when the manager is
enabled.
Keep the omap_dss_device pointer and set/unset_device ops in overlay_manager for
now to not break things. Keep the dss feature function get_supported_displays
as it's used in some places. These will be removed later.
Signed-off-by: Archit Taneja <archit@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The functions dss_mgr_wait_for_go() and dss_mgr_wait_for_go_ovl() check if there
is an enabled display connected to the manager before trying to see the state of
the GO bit.
The checks related to the display can be replaced by checking the state of the
manager, i.e, whether the manager is enabled or not. This makes more sense than
checking with the connected display as the GO bit behaviour is more connected
with the manager state rather than the display state. A GO bit can only be set
if the manager is enabled. If a manager isn't enabled, we can safely assume that
the GO bit is not set.
Signed-off-by: Archit Taneja <archit@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we removed fifomerge support, we also changed dss_ovl_disable so
that it doesn't wait for the hardware to be finished with the overlay.
This may cause a problem when changing the overlay's manager, as
changing the manager is an immediate change. Thus if the overlay is
still being used by the HW when the manager is changed, there may be
glitches on the screen.
This patch adds a wait into dss_ovl_unset_manager, which ensures the
overlays are disabled in the HW.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit fb0119742291b6f30cd97026ee137b2d3d1f4de8.
Adding fifo merge feature as an omapdss internal configuration was a
mistake. We cannot hide from the users of omapdss the complexities of
fifo merge.
The previous commit removed fifo merge itself, and this removes the
remaining fifo merge support functions.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 1d71f42b35ed66d90a9a39bc515bb16cfe2d4a46.
Adding fifo merge feature as an omapdss internal configuration was a
mistake. We cannot hide from the users of omapdss the complexities of
fifo merge.
This commit removes the fifo merge support, which luckily is easily done
as it was handled totally inside apply.c. Note that this is not a 1:1
revert, but some resolving was needed for the dss_ovl_setup_fifo.
The plan is to try fifo merge again later when it is more clear how the
hardware acts in various situations, and how the omapdrm wants to use
fifo merge.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
| |
dss_mgr_set_timings() can only be called when the output is not active.
This means that most of the code in the function is extra, as there's no
need to write the values to registers, etc, because that will be handled
when the output will be enabled.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
| |
dss_mgr_set_lcd_config() can only be called when the output is not
active. This means that most of the code in the function is extra, as
there's no need to write the values to registers, etc, because that will
be handled when the output will be enabled.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
| |
The function dss_mgr_set_timings is supposed to apply timings passed by an
interface driver. It is not supposed to change the timings. Add const qualifier
to the omap_video_timings pointer argument in dss_mgr_set_timings().
Signed-off-by: Archit Taneja <archit@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replication logic for an overlay depends on the color mode in which it is
configured and the video port width of the manager it is connected to.
video port width now held in dss_lcd_mgr_config in the manager's private
data in APPLY. Use this instead of referring to the omap_dss_device connected to
the manager.
Replication is enabled in the case of TV manager, the video_port_width is set to
a default value of 24 for TV manager.
Make the replication checking an overlay function since it's more of an overlay
characteristic than a display characteristic.
Signed-off-by: Archit Taneja <archit@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
APPLY needs to know at certain places whether an overlay manager is in manual
or auto update mode. The caps of the connected omap_dss_device were used to
check that.
A LCD manager is in manual update if stallmode is enabled for that manager. TV
managers for now always auto update.
Return the value of stallmode parameter in the private data 'lcd_confg' in
mgr_manual_update() and ovl_manual_update(), for TV managers stallmode field
will be false by default.
Signed-off-by: Archit Taneja <archit@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The LCD related manager configurations are a part of the manager's private data
in APPLY. Pass this to dss_lcd_mgr_config to dss_mgr_check and create a function
to check the validity of some of the configurations.
To check some of the configurations, we require information of interface to
which the manager output is connected. These can be added once interfaces are
represented as an entity.
Signed-off-by: Archit Taneja <archit@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
drivers
Replace the DISPC fuctions used to configure LCD channel related manager
parameters with dss_mgr_set_lcd_config() in APPLY. This function ensures that
the DISPC registers are written at the right time by using the shadow register
programming model.
The LCD manager configurations is stored as a private data of manager in APPLY.
It is treated as an extra info as it's the panel drivers which trigger this
apply via interface drivers, and not a DSS2 user like omapfb or omapdrm.
Storing LCD manager related properties in APPLY also prevents the need to refer
to the panel connected to the manager for information. This helps in making the
DSS driver less dependent on panel.
A helper function is added to check whether the manager is LCD or TV. The direct
DISPC register writes are removed from the interface drivers.
Signed-off-by: Archit Taneja <archit@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
dispc_ovl_setup()
Currently the interlace parameter passed to dispc_ovl_setup() is configured by
checking the display type, and set to true if the display type is VENC.
This isn't correct as other panels can take interlaced content too. The
omap_video_timings struct in manager's private data contains the info whether
the panel is in interlaced mode or not.
Signed-off-by: Archit Taneja <archit@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a problem related to DSS FIFO thresholds and power management
on OMAP3. It seems that when the full PM hits in, we get underflows. The
core reason is unknown, but after experiments it looks like only
particular FIFO thresholds work correctly.
This bug is related to an earlier patch, which added special FIFO
threshold configuration for OMAP3, because DSI command mode output
didn't work with the normal threshold configuration.
However, as the above work-around worked fine for other output types
also, we currently always configure thresholds in this special way on
OMAP3. In theory there should be negligible difference with this special
way and the standard way. The first paragraph explains what happens in
practice.
This patch changes the driver to use the special threshold configuration
only when the output is a manual update display on OMAP3. This does
include RFBI displays also, and although it hasn't been tested (no
boards using RFBI) I suspect the similar behaviour is present there
also, as the DISPC side should work similarly for DSI command mode and
RFBI.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Joe Woodward <jw@terrafix.co.uk>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The functions calc_fclk_five_taps() and check_horiz_timing_omap3() use the
function dispc_mgr_get_device() to get the omap_dss_device pointer to which
the manager is connected, the width of the panel is derived from that.
The manager's timing is stored in it's private data in APPLY. This contains
the latest timings applied to the manager. Pass these timings to
dispc_ovl_setup() and use them in the above functions. Remove the function
dispc_mgr_get_device() as it isn't used any more.
Signed-off-by: Archit Taneja <archit@ti.com>
|
| |
|
|
|
|
|
| |
The omap_dss_device pointer declared in dss_ovl_setup_fifo() isn't used. Remove
the pointer variable declaration and it's assignment.
Signed-off-by: Archit Taneja <archit@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In order to check the validity of overlay and manager info, there was a need to
use the omap_dss_device struct to get the panel resolution. The manager's
private data in APPLY now contains the manager timings. Hence, we don't need to
rely on the display resolution any more.
Pass the manager's timings in private data to dss_mgr_check(). Remove the need
to pass omap_dss_device structs in the functions which check for the validity
of overlay and manager parameters.
Signed-off-by: Archit Taneja <archit@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a manager is disabled, there is no guarantee at any point in time that all
it's parameters are configured. There is always a chance that some more
parameters are yet to be configured by a user of DSS, or by DSS itself.
However, when the manager is enabled, we can be certain that all the parameters
have been configured, as we can't enable a manager with an incomplete
configuration. Therefore, if a manager is disabled, don't check for the validity
of it's parameters or the parameters of the overlays connected to it. Only check
once it is enabled. Add a check in dss_check_settings_low() to achieve the same.
Signed-off-by: Archit Taneja <archit@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DISPC manager size and DISPC manager blanking parameters(for LCD managers)
follow the shadow register programming model. Currently, they are programmed
directly by the interface drivers.
To configure manager timings using APPLY, there is a need to introduce extra
info flags for managers, similar to what is done for overlays. This is needed
because timings aren't a part of overlay_manager_info struct configured by a
user of DSS, they are configured internally by the interface or panel drivers.
Add dirty and shadow_dirty extra_info flags for managers, update these flags
at the appropriate places. Rewrite the function extra_info_update_ongoing()
slightly as checking for manager's extra_info flags can simplify the code a bit.
Create function dss_mgr_set_timings() which applies the new manager timings to
extra_info.
Signed-off-by: Archit Taneja <archit@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently the shadow-dirty flags for manual update displays is cleared
in the apply_irq_handler when an update has finished. This is not
correct, as the shadow registers are taken into use (i.e. after that
they are not dirty) when the update is started.
Move the mgr_clear_shadow_dirty() call from apply_irq_handler to
dss_mgr_start_update() to fix this.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
wait_pending_extra_info_updates() currently does a hacky second check
for extra_info_update_ongoing() at the end of the function to show a
warning if extra_info update is still ongoing. The call to
extra_info_update_ongoing() should really be inside spinlock, but that's
a bit heavy just for verification.
Rather than that, check the return value of the
wait_for_completion_timeout() and print an error if it has timeouted or
returned an error.
Even better would be to return the error value and act on it in the
callers of wait_pending_extra_info_updates. However, it's not clear what
the callers should do in case of an error, as the error should only
happen if there's a bug in the driver or the HW. So we'll just print the
warning for now.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functions
If DSS suspends within the functions dss_mgr_wait_for_go(),
dss_mgr_wait_for_go_ovl() or dss_mgr_wait_for_vsync(). It may lose it's clock
and lead to a register access failure.
Request runtime_pm around these functions.
[archit@ti.com: Moved runtime_pm calls to wait_for_go/vsync functions rather
then calling them from omap_dispc_wait_for_irq_interruptible_timeout()]
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
| |
Move fifo threshold calculation into dispc.c, as the thresholds are
really dispc internal thing.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add fifo-merge support. This is done mainly in four functions:
mgr_enable/disable and ovl_enable/disable. These are the functions where
overlays are taken into and out of active use.
The process to enable and disable fifo-merge is not simple. We need to
do it in steps, waiting in between for certain settings to be taken into
use, and continuing after that. The reason for this is that fifo-merge
is a common thing for all managers/overlays, and its use must be
synchronized.
As an example, when we disable an overlay, we first set the overlay as
disabled, then wait until the overlay is actually disabled in the HW,
and only after that we may re-configure the fifos, possibly taking
fifo-merge into use.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add mechanism to set/unset the DISPC fifo-merge:
Add new fields to dss_data, fifo_merge and fifo_merge_dirty. These are
similar to the other info/dirty flags in ovl_priv_data and ovl_mgr_data,
but fifo merge is a common attribute to all managers and thus outside
the ovl_mgr_data.
The fifo-merge field is used in the dss_write_regs_common, which handles
writing the register.
dss_apply_fifo_merge() can be used to set/unset the fifo merge field in
the dss_data.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
extra_info_update_ongoing() goes through all overlays, but doesn't check
if the overlay is connected to a manager. This leads to a crash whenever
an overlay has been detached.
Add a check to skip the non-connected overlays.
Reported-by: Rob Clark <rob@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
| |
The functions dss_ovl_simple_check() and dss_mgr_simple_check() are not
really part of the apply mechanism, and can be moved to overlay.c and
manager.c.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
| |
The functions dss_ovl_check, dss_mgr_check_zorder, dss_mgr_check in
apply.c are not really part of the apply mechanism, and can be moved to
overlay.c and manager.c.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
| |
dss_mgr_check_zorder() has two unused variables. Remove them.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
| |
Current code will always write fifo threshold values to the register,
even if they are the same as previously. Separate the setting of fifo
fields into a separate function, and only set new values if they are
different than the old ones.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently fifo threshold configuration is done per overlay or per
manager. However, when a fifo size configuration is added, we need to
always configure the thresholds for all overlays.
This patch prepares for that by changing the fifo threshold
configuration to always handle all overlays.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
| |
dss_mgr_enable() has some extra assigns to mp->enabled, which can be
removed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we are enabling an overlay, there's a point in time when the
overlay is not actually enabled yet (nor do we want it to be enabled),
but we do want to check if the configuration for the overlay is valid,
and to calculate correct fifo thresholds for the soon-to-be-enabled
overlay.
Current code handled this in a hacky way, setting op->enabled to true
temporarily when calling functions that need to consider the state when
the overlay is enabled.
This patch makes this a bit cleaner, adding "enabling" field, which is
set when the overlay is not yet enabled but should be considered in the
checks and calculations.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
| |
Trivial cleanup for extra_info_update_ongoing(), making the function a
bit cleaner.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently dss_write_regs() implicitely sets the GO bits for all managers
with shadow dirty flags set. This is a bit misleading, as one does not
presume "write registers" function to also set the GO bit.
Thus this patch splits the setting of GO bits into a separate function,
dss_set_go_bits, which is used after writing the registers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the apply irq handler the code currently clears the shadow dirty
flags whenever the manager in question is not busy (i.e. GO bit is
down). However, this is not quite right, as the GO bit may have never
been set.
While not done in the current code, the above would cause bug in
scenario where the registers are written, and thus shadow_dirty flag is
set, but the GO bit will be set only later. In this case the
shadow_dirty flags would be cleared, even if the HW is not using the new
configurations.
This patch fixes the issue by clearing the shadow flags only when the GO
bit is clear, and the GO bit had been set.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
need_isr() should return true whenever there's work that needs to be
handled in the VSYNC/FRAMEDONE irq handler. However, need_isr() is
missing some cases where we need the irq handler.
This patch adds checks for shadow dirty flags, so that the irq handler
is started/kept running while shadow dirty flags are set.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
extra_info_update_ongoing() skipped checks for overlays that were marked
as disabled. This doesn't work, as the enable status of an overlay is in
the extra_info group, and thus extra_info_update_ongoing() reports false
when we are disabling an overlay. This causes
wait_pending_extra_info_updates() to not wait for the ongoing overlay
disable.
This patch changes extra_info_update_ongoing() to check the state of
overlays marked as disabled.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
| |
Now that dss_mgr_enable() can fail due to checks, make it return the
error value.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
| |
Add checks for overlay and manager settings. The checks are a bit
complex, as we need to observe the bigger picture instead of overlays
and managers independently. Things like the used display and the zorder
of other overlays affect the validity of the settings.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Add dss_mgr_simple_check() which is used to check the validity of
certain manager attributes. Only attributes that can be checked
independently, without knowing the display being used, is done here
(thus "simple").
We can use this function in dss_mgr_set_info().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Add dss_ovl_simple_check() which is used to check the validity of
certain overlay attributes. Only attributes that can be checked
independently, without knowing the display being used, is done here
(thus "simple").
We can use this function in dss_ovl_set_info().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
| |
apply.c no longer touches any registers if an output is not enabled.
This means that we don't need to do dispc_runtime_get() anymore, and the
calls can be removed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Add wait_pending_extra_info_updates() function which can be used to wait
until any extra_info changes have been taken into use by the hardware.
This can be only called when holding the apply mutex, so that other
threads cannot insert new extra_info changes.
This will be used to handle fifo-configurations.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
| |
Add checks to dss_mgr_enable, dss_mgr_disable, dss_ovl_enable,
dss_ovl_disable that check if the state is already the same as given in
the parameters, and exit if so.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add a helper function dss_apply_ovl_enable(), which is similar to the
main apply() function: dss_apply_ovl_enable() applies the given overlay
enable-status to ovl_priv_data, and sets the dirty flag.
The difference between the helper function and the previous direct use
of the fields is that the helper function will not do anything if the
enable state is already the same as given in the parameter.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
