This patch adds a new function, dispc_ovl_check(), which can be used to
verify scaling configuration for an overlay. The function gets both the
overlay and overlay manager as parameters, so that the caller does not
need to configure the hardware before using this function.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The whole dispc irq handling system we currently have is only needed for
compat layer, and thus can be moved from dispc.c to the compat layer.
This is quite straigtforward, but we need to add new dispc functions to
request and free the actual hardware irq: dispc_request_irq() and
dispc_free_irq().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dispc_mgr_enable_sync and dispc_mgr_disable_sync are only used with the
compat mode. Non-compat will use the simpler enable and disable
functions.
This patch moves the synchronous enable/disable code to the compat
layer. A new file is created, dispc-compat.c, which contains low level
dispc compat code (versus apply.c, which contains slightly higher level
compat code).
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Some of the output drivers need to handle FRAMEDONE interrupt from
DISPC. This creates a direct dependency to dispc code, and we need to
avoid this to make the compat code to work.
Instead of the output drivers registering for dispc interrupts, we
create new mgr-ops that are used to register a framedone handler. The
code implementing the mgr-ops is responsible for calling the handler
when DISPC FRAMEDONE interrupt happens. The compat layer is improved
accordingly to do the call to the framedone handler.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The output drivers need some operations from the overlay managers, like
enable and set_timings. These will affect the dispc registers, and need
to be synchronized with the composition-side changes with overlays and
overlay managers.
We want to handle these calls in the apply.c in the compatibility mode,
but when in non-compat mode, the calls need to be handled by some other
component (e.g. omapdrm).
To make this possible, this patch creates a set of function pointers in
a dss_mgr_ops struct, that is used to redirect the calls into the
correct destination.
The non-compat users can install their mgr ops with
dss_install_mgr_ops() function.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Most of the functions that are assigned to the fields in ovl struct are
in apply.c. By moving the function pointer setup into apply.c we can
make these functions static.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Most of the functions that are assigned to the fields in ovl-mgr struct
are in apply.c. By moving the function pointer setup into apply.c we can
make these functions static.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add two new exported functions, omapdss_compat_init and
omapdss_compat_uninit, which are to be used by omapfb, omap_vout to
enable compatibility mode for omapdss. The functions are called by
omapdss internally for now, and moved to other drivers later.
The compatibility mode is implemented fully in the following patches.
For now, enabling compat mode only sets up the private data in apply.c.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We currently attach an output to a dssdev in the initialization code for
dssdevices in display.c. This works, but doesn't quite make sense: an
output entity represents (surprisingly) an output of DSS, which is
managed by an output driver. The output driver also handles adding new
dssdev's for that particular output.
It makes more sense to make the output-dssdev connection in the output
driver. This is also in line with common display framework.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
When enabling a hwmod, omap_hwmod refers to the register mentioned in the
hwmod struct's member 'prcm.omap4.context_offs' to see whether context was
lost or not. It increments the context lost count for the hwmod and then clears
the register.
All the DSS hwmods have the same register(RM_DSS_DSS_CONTEXT) as context_offs.
When DSS is enabled, the first hwmod to be enabled is the "dss_core" hwmod since
it's corresponding platform device is the parent platform device("omapdss_dss").
The dss_core hwmod updates it's context lost count correctly and clears the
register. When the hwmods corresponding to the children platform devices are
enabled, they see that the register is clear, and don't increment their context
lost count. Therefore, all the children platform devices never report a loss in
context.
The DISPC driver currently gets the context lost count for DSS power domain from
it's corresponding platform device instance("omapdss_dispc"). The DISPC platform
device is one of the child devices, and it's corresponding hwmod("dss_dispc")
doesn't report the context lost count correctly.
Modify dss_get_ctx_loss_count() such that it always takes the "omapdss_dss"
platform device as it's input, move the function to dss.c so that it has access
to that platform device.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add dss_get_core_pdev() which returns the platform device for dss core
device. The following patches use the core pdev to register sysfs files
in the compat code.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Move display sysfs related code from display.c to display-sysfs.c, for
clarity. The sysfs code will only be used for compat mode.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dsi_get_dsidev_from_id() gives a WARN if DSI support is not compiled in.
This warning is not right, as it's valid to call
dsi_get_dsidev_from_id() to see if there is DSI support or not.
Remove the WARN().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Remove dispc_mgr_is_channel_enabled() and dss_mgr_get_timings()
declarations, as the function doesn't exist.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dss.c currently exposes functions to configure the dispc source clock
and lcd source clock. There are configured separately from the output
drivers.
However, there is no safe way for the output drivers to handle dispc
clock, as it's shared between the outputs. Thus, if, say, the DSI driver
sets up DSI PLL and configures both the dispc and lcd clock sources to
that DSI PLL, the resulting dispc clock could be too low for, say, HDMI.
Thus the output drivers should really only be concerned about the lcd
clock, which is what the output drivers actually use. There's lot to do
to clean up the dss clock handling, but this patch takes one step
forward and removes the use of dss_select_dispc_clk_source() from the
output drivers.
After this patch, the output drivers only configure the lcd source
clock. On omap4+ the dispc src clock is never changed from the default
PRCM source. On omap3, where the dispc and lcd clocks are actually the
same, setting the lcd clock source sets the dispc clock source.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dss_calc_clock_rates() was removed earlier as it was not used, but it is
needed for DSI PLL calculations, so this patch adds it back.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
This patch makes use of the hdmi_power_[on|off]_core() functions added
in the previous patch. The functions are used when reading EDID or
detecting if a monitor is connected.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ricardo Neri <ricardo.neri@ti.com>
DISPC irqs need to be handled from the compat layer and also in the
future by the omapdrm. To make this possible, this patchs adds a set of
helper functions, so that the irqs can be managed without direct
register reads/writes.
The following functions are added, and all the current direct reg
reads/writes are changed to use these.
u32 dispc_read_irqstatus(void);
void dispc_clear_irqstatus(u32 mask);
u32 dispc_read_irqenable(void);
void dispc_write_irqenable(u32 mask);
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add new dispc function, dispc_ovl_enabled(). This returns if the overlay
enable bit is set in the registers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We need a low level manager-enable function for omapdrm. We have that
function as dispc internal func, _enable_mgr_out().
This patch exposes that function, and renames it to dispc_mgr_enable().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The current dispc_mgr_enable/disable function are blocking, and do a bit
too much for omapdrm. We'll expose new enable & disable functions that
will just set the bits in the registers in the following patches.
This patch renames the current functions to *_sync, to make it clear
that they are blocking, and also to free up the dispc_mgr_enable/disable
names for these new functions.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Export dss_get_def_display_name() with the name of
omapdss_get_def_display_name() so that omapfb can use it after the next
patch which moves default display handling to omapfb.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dss.h contains dispc_irq_handler declaration, even if the function is
dispc.c internal. Remove the declaration.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We currently have a single function to enable and disable the manager
output for LCD and DIGIT. The functions are a bit complex, as handling
both enable and disable require some extra steps to ensure that the
output is enabled or disabled properly without errors before exiting the
function.
The code can be made simpler to understand by splitting the functions
into separate enable and disable functions. We'll also clean up the
comments and some parameter names at the same time.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dss_mgr_set_device and dss_mgr_unset_device are declared in dss.h, but
the functions do not exist. Remove the declarations.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Dispc has a bunch of functions used to configure output related
parameters:
- dispc_mgr_set_io_pad_mode
- dispc_mgr_enable_stallmode
- dispc_mgr_enable_fifohandcheck
- dispc_mgr_set_clock_div
- dispc_mgr_set_tft_data_lines
- dispc_lcd_enable_signal_polarity
- dispc_mgr_set_lcd_type_tft
These are all called together, and the configuration values are taken
from struct dss_lcd_mgr_config.
Instead of exposing those individual dispc functions, create a new one,
dispc_mgr_set_lcd_config(), which is used to configure the above
parameters from values in struct dss_lcd_mgr_config.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
All the debug prints have been replaced with pr_debug(). Thus, the dependency on
dss_debug variable is replaced with dyndbg in dynamic debugging mode and DEBUG
flag otherwise. So, the dss_debug variable is removed along with checks for
DEBUG flag.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Reviewed-by: Sumit Semwal <sumit.semwal@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The printk in DSSDBG function definition is replaced with dynamic debug enabled
pr_debug(). The use of dynamic debugging provides more flexibility as each debug
statement can be enabled or disabled dynamically on basis of source filename,
line number, module name etc., by writing to a control file in debugfs
filesystem. For better understanding please refer to
Documentation/dynamic-debug-howto.txt.
The DSSDBGF() differs from DSSDBG() by providing function name. However,
function name, line number, module name and thread ID can be printed through
dynamic debug by setting appropriate flags 'f','l','m' and 't' in the debugfs
control file. So, DSSDBGF instances are replaced with DSSDBG.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Reviewed-by: Sumit Semwal <sumit.semwal@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The config option CONFIG_OMAP2_DSS_DEBUG_SUPPORT has been removed and replaced
with CONFIG_OMAP2_DSS_DEBUG and CONFIG_OMAP2_DSS_DEBUGFS. CONFIG_OMAP2_DSS_DEBUG
enables DEBUG flag and CONFIG_OMAP2_DSS_DEBUGFS enables creation of debugfs for
OMAPDSS. Both the config options are disabled by default and can be enabled
independently of one another as per convenience.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Reviewed-by: Sumit Semwal <sumit.semwal@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In OMAPDSS the DEBUG flag is set only after the OMAPDSS module is called, for
which the debugging capabilities are available only after its proper
initialization. As a result of which tracking of bugs prior to or during initial
process becomes difficult. So, the definition of DEBUG is being moved to the
corresponding Makefile.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Reviewed-by: Sumit Semwal <sumit.semwal@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add functions to enable writeback, and set/check state of GO bit. These bits are
identical in behaviour with the corresponding overlay manager bits. Configure
them in a similar way to mgr_enable() and mgr_go_* functions. Add a helper to
get the FRAMEDONE irq corresponding to writeback.
Signed-off-by: Archit Taneja <archit@ti.com>
Configure some of the writeback specific parameters in dispc_wb_setup(). The
writeback parameters configured are:
truncation: This needs to be set if the color depth input to writeback is more
than the color depth of the color mode we want to store in memory.
writeback mode: This configures whether we want to use writeback in mem to mem
or capture mode. This information will be directly passed by APPLY later.
Signed-off-by: Archit Taneja <archit@ti.com>
Create struct omap_dss_writeback_info, this is similar to omap_overlay_info,
the major difference is that there is no parameter which describes the input
size to writeback, this is because this is always fixed, and decided by the
connected overlay or overlay manager. One more difference is that screen_width
is renamed to buf_width, to give the value of stride the writeback buffer has.
Call dispc_ovl_setup_common() through dispc_wb_setup() to configure overlay-like
parameters. The parameters in dispc_ovl_setup_common() which do not hold for
writeback are filled passed as zeroes or false, the code takes care of not
configuring them as they won't possess the needed overlay caps.
Signed-off-by: Archit Taneja <archit@ti.com>
Writeback can take input from either one of the overlays, or one of the overlay
managers. Add an enum which represents the channel_in for writeback, and maps
to the register field programming.
Add a function to configure channel in for writeback. This will be used later in
APPLY.
Signed-off-by: Archit Taneja <archit@ti.com>
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>
The struct omap_overlay_info passed to dispc_ovl_setup() is used to configure
DISPC registers. It shouldn't modify the overlay_info structure. The pos_y field
was being changed in dispc_ovl_setup in the case of interlaced displays. Fix
this and const qualifier to the omap_overlay_info argument.
Signed-off-by: Archit Taneja <archit@ti.com>
Links between DSS entities are made in dss_init_connections() when a panel
device is registered, and are removed in dss_uninit_connections() when the
device is unregistered. Modify these functions to incorporate the addition of
outputs.
The fields in omap_dss_device struct gives information on which output and
manager to connect to. The desired manager and output pointers are retrieved and
prepared to form the desired links. The output is linked to the device, and then
the manager to the output.
A helper function omapdss_get_output_from_device() is created to retrieve the
output from the display by checking it's type, and the module id in case of DSI.
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 current OMAPDSS design contains 3 software entities: Overlays, Managers and
Devices. These map to pipelines, overlay managers and the panels respectively in
hardware. One or more overlays connect to a manager to represent a composition,
the manager connects to a device(generally a display) to display the content.
The part of DSS hardware which isn't represented by any of the above entities
are interfaces/outputs that connect to an overlay manager, i.e blocks like DSI,
HDMI, VENC and so on. Currently, an overlay manager directly connects to the
display, and the output to which it is actually connected is ignored. The panel
driver of the display is responsible of calling output specific functions to
configure the output.
Adding outputs as a new software entity gives us the following benefits:
- Have exact information on the possible connections between managers and
outputs: A manager can't connect to each and every output, there only limited
hardware links between a manager's video port and some of the outputs.
- Remove hacks related to connecting managers and devices: Currently, default
links between managers and devices are set in a not so clean way. Matching is
done via comparing the device type, and the display types supported by the
manager. This isn't sufficient to establish all the possible links between
managers, outputs and devices in hardware.
- Make panel drivers more generic: The DSS panel drivers currently call
interface/output specific functions to configure the hardware IP. When making
these calls, the driver isn't actually aware of the underlying output. The
output driver extracts information from the panel's omap_dss_device pointer
to figure out which interface it is connected to, and then configures the
corresponding output block. An example of this is when a DSI panel calls
dsi functions, the dsi driver figures out whether the panel is connected
to DSI1 or DSI2. This isn't correct, and having output as entities will
give the panel driver the exact information on which output to configure.
Having outputs also gives the opportunity to make panel drivers generic
across different platforms/SoCs, this is achieved as omap specific output
calls can be replaced by ops of a particular output type.
- Have more complex connections between managers, outputs and devices: OMAPDSS
currently doesn't support use cases like 2 outputs connect to a single
device. This can be achieved by extending properties of outputs to connect to
more managers or devices.
- Represent writeback as an output: The writeback pipeline fits well in OMAPDSS
as compared to overlays, managers or devices.
Add a new struct to represent outputs. An output struct holds pointers to the
manager and device structs to which it is connected. Add functions which can
register/unregister an output, or look for one. Create an enum which represent
each output instance.
Signed-off-by: Archit Taneja <archit@ti.com>
This series adds basic OMAP5 DSS functionality, mainly related to DSS core, DPI
and DSI.
* omap5-dss:
OMAPDSS: DSI: make OMAP2_DSS_DSI depend on ARCH_OMAP5
OMAPDSS: DSI: Add code to disable PHY DCC
OMAPDSS: DSI: Add new linebuffer size for OMAP5
OMAPDSS: DSI: Add FEAT_DSI_PLL_REFSEL
OMAPDSS: DSI: Add FEAT_DSI_PLL_SELFREQDCO
OMAPDSS: Add support for DPI source selection
OMAPDSS: move dss feats to the end of dss.c
OMAPDSS: Add basic omap5 features to dss and dispc
OMAPDSS: DSI: improve DSI clock calcs for DISPC
We can select the video source for DPI output as follows:
OMAP2/3: always LCD1
OMAP4: LCD2 or DIGIT
OMAP5: LCD1/LCD2/LCD3/DIGIT
This patch adds support to select the source, and makes dpi.c call the
function to set the source.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: David Anders <x0132446@ti.com>
We currently create omap_dss_devices statically in board files, and use
those devices directly in the omapdss driver. This model prevents us
from having the platform data (which the dssdevs in board files
practically are) as read-only, and it's also different than what we will
use with device tree.
This patch changes the model to be in line with DT model: we allocate
the dssdevs dynamically, and initialize them according to the data in
the board file's dssdev (basically we memcopy the dssdev fields).
The allocation and registration is done in the following steps in the
output drivers:
- Use dss_alloc_and_init_device to allocate and initialize the device.
The function uses kalloc and device_initialize to accomplish this.
- Call dss_copy_device_pdata to copy the data from the board file's
dssdev
- Use dss_add_device to register the device.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cleanup dss_recheck_connections, move and rename it to a static
dss_init_connections function inside display.c. Improve the function to
return errors, and implement a matching dss_uninit_connections that can
be used to free the mgr->dssdev link.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We have boards with multiple panel devices connected to the same
physical output, of which only one panel can be enabled at one time.
Examples of these are Overo, where you can use different daughter boards
that have different LCDs, and 3430SDP which has an LCD and a DVI output
and a physical switch to select the active display.
These are supported by omapdss so that we add all the possible display
devices at probe, but the displays are inactive until somebody enables
one. At this point the panel driver starts using the DSS, thus reserving
the physcal resource and excluding the other panels.
This is problematic:
- Panel drivers can't allocate their resources properly at probe(),
because the resources can be shared with other panels. Thus they can
be only reserved at enable time.
- Managing this in omapdss is confusing. It's not natural to have
child devices, which may not even exist (for example, a daughterboard
that is not connected).
Only some boards have multiple displays per output, and of those, only
very few have possibility of switching the display during runtime.
Because of the above points:
- We don't want to make omapdss and all the panel drivers more complex
just because some boards have complex setups.
- Only few boards support runtime switching, and afaik even then it's
not required. So we don't need to support runtime switching.
Thus we'll change to a model where we will have only one display device
per output and this cannot be (currently) changed at runtime. We'll
still have the possibility to select the display from multiple options
during boot with the default display option.
This patch accomplishes the above by changing how the output drivers
register the display device. Instead of registering all the devices
given from the board file, we'll only register one. If the default
display option is set, the output driver selects that display from its
displays. If the default display is not set, or the default display is
not one of the output's displays, the output driver selects the first
display.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
