2019-06-03 12:44:50 +07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
OMAPDSS: outputs: Create a new entity called outputs
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>
2012-09-07 19:08:00 +07:00
|
|
|
/*
|
2017-12-06 03:29:31 +07:00
|
|
|
* Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
|
OMAPDSS: outputs: Create a new entity called outputs
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>
2012-09-07 19:08:00 +07:00
|
|
|
* Author: Archit Taneja <archit@ti.com>
|
|
|
|
*/
|
|
|
|
|
2019-08-22 01:32:26 +07:00
|
|
|
#include <linux/bitops.h>
|
OMAPDSS: outputs: Create a new entity called outputs
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>
2012-09-07 19:08:00 +07:00
|
|
|
#include <linux/kernel.h>
|
2012-08-29 15:00:15 +07:00
|
|
|
#include <linux/module.h>
|
OMAPDSS: outputs: Create a new entity called outputs
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>
2012-09-07 19:08:00 +07:00
|
|
|
#include <linux/platform_device.h>
|
|
|
|
#include <linux/slab.h>
|
OMAPDSS: DT: Get source endpoint by matching reg-id
In omapdss_of_find_source_for_first_ep, we retrieve a source endpoint's DT node,
and then see what omapdss output has the matching device_node pointer in
omap_dss_find_output_by_node.
For all DPI and SDI outputs, the device_node pointer is set as the parent's DSS
device_node pointer. If the source is one of these outputs, the above method
won't work.
To get the correct output for ports within DSS(and in other cases in the future,
where multiple ports might be under one device), we require additional
information which is exclusive to the output port.
We create a new field in omap_dss_device called 'port_num', this provides port
number of the output port corresponding to this device. When searching for the
source endpoint in DT, we extract the 'reg' property from the port corresponding
to the endpoint source. From the list of registered outputs, we pick out that
output which has both dev->of_node and port_num matching with the device_node
pointer and 'reg' of the source endpoint node from DT.
For encoder blocks(the ones which have both an input and output port), we need
to set the port_num as the 'reg' property for the output port as defined in the
DT bindings. We set port_num to 1 in the tfp410 and tpd12s015 encoder drivers.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-04-22 19:13:48 +07:00
|
|
|
#include <linux/of.h>
|
2018-09-23 16:58:15 +07:00
|
|
|
#include <linux/of_graph.h>
|
OMAPDSS: outputs: Create a new entity called outputs
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>
2012-09-07 19:08:00 +07:00
|
|
|
|
2019-08-26 22:26:29 +07:00
|
|
|
#include <drm/drm_bridge.h>
|
2018-12-08 04:08:35 +07:00
|
|
|
#include <drm/drm_panel.h>
|
|
|
|
|
2018-03-02 08:05:10 +07:00
|
|
|
#include "dss.h"
|
2016-05-27 18:40:49 +07:00
|
|
|
#include "omapdss.h"
|
OMAPDSS: outputs: Create a new entity called outputs
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>
2012-09-07 19:08:00 +07:00
|
|
|
|
2018-09-12 23:41:31 +07:00
|
|
|
int omapdss_device_init_output(struct omap_dss_device *out)
|
2012-08-29 15:00:15 +07:00
|
|
|
{
|
2018-09-23 16:58:15 +07:00
|
|
|
struct device_node *remote_node;
|
|
|
|
|
2019-08-22 01:32:26 +07:00
|
|
|
remote_node = of_graph_get_remote_node(out->dev->of_node,
|
|
|
|
ffs(out->of_ports) - 1, 0);
|
2018-09-23 16:58:15 +07:00
|
|
|
if (!remote_node) {
|
|
|
|
dev_dbg(out->dev, "failed to find video sink\n");
|
|
|
|
return 0;
|
2018-09-12 23:41:31 +07:00
|
|
|
}
|
|
|
|
|
2018-09-23 16:58:15 +07:00
|
|
|
out->next = omapdss_find_device_by_node(remote_node);
|
|
|
|
out->bridge = of_drm_find_bridge(remote_node);
|
2018-12-08 04:08:35 +07:00
|
|
|
out->panel = of_drm_find_panel(remote_node);
|
|
|
|
if (IS_ERR(out->panel))
|
|
|
|
out->panel = NULL;
|
2018-09-23 16:58:15 +07:00
|
|
|
|
|
|
|
of_node_put(remote_node);
|
|
|
|
|
2018-12-10 19:00:38 +07:00
|
|
|
if (out->next && out->type != out->next->type) {
|
2015-11-06 20:26:39 +07:00
|
|
|
dev_err(out->dev, "output type and display type don't match\n");
|
2018-09-23 16:58:15 +07:00
|
|
|
omapdss_device_put(out->next);
|
|
|
|
out->next = NULL;
|
2018-03-06 06:25:13 +07:00
|
|
|
return -EINVAL;
|
2012-08-29 15:00:15 +07:00
|
|
|
}
|
|
|
|
|
2018-12-08 04:08:35 +07:00
|
|
|
return out->next || out->bridge || out->panel ? 0 : -EPROBE_DEFER;
|
2012-08-29 15:00:15 +07:00
|
|
|
}
|
2018-09-12 23:41:31 +07:00
|
|
|
EXPORT_SYMBOL(omapdss_device_init_output);
|
|
|
|
|
|
|
|
void omapdss_device_cleanup_output(struct omap_dss_device *out)
|
|
|
|
{
|
|
|
|
if (out->next)
|
|
|
|
omapdss_device_put(out->next);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(omapdss_device_cleanup_output);
|
2012-08-29 15:00:15 +07:00
|
|
|
|
2018-03-02 08:05:10 +07:00
|
|
|
int dss_install_mgr_ops(struct dss_device *dss,
|
|
|
|
const struct dss_mgr_ops *mgr_ops,
|
2018-02-13 19:00:39 +07:00
|
|
|
struct omap_drm_private *priv)
|
2012-10-10 14:56:05 +07:00
|
|
|
{
|
2018-03-02 08:05:10 +07:00
|
|
|
if (dss->mgr_ops)
|
2012-10-10 14:56:05 +07:00
|
|
|
return -EBUSY;
|
|
|
|
|
2018-03-02 08:05:10 +07:00
|
|
|
dss->mgr_ops = mgr_ops;
|
|
|
|
dss->mgr_ops_priv = priv;
|
2012-10-10 14:56:05 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2012-10-24 17:52:40 +07:00
|
|
|
EXPORT_SYMBOL(dss_install_mgr_ops);
|
2012-10-10 14:56:05 +07:00
|
|
|
|
2018-03-02 08:05:10 +07:00
|
|
|
void dss_uninstall_mgr_ops(struct dss_device *dss)
|
2012-10-10 14:56:05 +07:00
|
|
|
{
|
2018-03-02 08:05:10 +07:00
|
|
|
dss->mgr_ops = NULL;
|
|
|
|
dss->mgr_ops_priv = NULL;
|
2012-10-10 14:56:05 +07:00
|
|
|
}
|
2012-10-24 17:52:40 +07:00
|
|
|
EXPORT_SYMBOL(dss_uninstall_mgr_ops);
|
2012-10-10 14:56:05 +07:00
|
|
|
|
2018-02-13 19:00:38 +07:00
|
|
|
void dss_mgr_set_timings(struct omap_dss_device *dssdev,
|
|
|
|
const struct videomode *vm)
|
2012-10-10 14:56:05 +07:00
|
|
|
{
|
2018-03-02 08:05:10 +07:00
|
|
|
dssdev->dss->mgr_ops->set_timings(dssdev->dss->mgr_ops_priv,
|
|
|
|
dssdev->dispc_channel, vm);
|
2012-10-10 14:56:05 +07:00
|
|
|
}
|
2012-10-24 17:52:40 +07:00
|
|
|
EXPORT_SYMBOL(dss_mgr_set_timings);
|
2012-10-10 14:56:05 +07:00
|
|
|
|
2018-02-13 19:00:38 +07:00
|
|
|
void dss_mgr_set_lcd_config(struct omap_dss_device *dssdev,
|
2012-10-10 14:56:05 +07:00
|
|
|
const struct dss_lcd_mgr_config *config)
|
|
|
|
{
|
2018-03-02 08:05:10 +07:00
|
|
|
dssdev->dss->mgr_ops->set_lcd_config(dssdev->dss->mgr_ops_priv,
|
|
|
|
dssdev->dispc_channel, config);
|
2012-10-10 14:56:05 +07:00
|
|
|
}
|
2012-10-24 17:52:40 +07:00
|
|
|
EXPORT_SYMBOL(dss_mgr_set_lcd_config);
|
2012-10-10 14:56:05 +07:00
|
|
|
|
2018-02-13 19:00:38 +07:00
|
|
|
int dss_mgr_enable(struct omap_dss_device *dssdev)
|
2012-10-10 14:56:05 +07:00
|
|
|
{
|
2018-03-02 08:05:10 +07:00
|
|
|
return dssdev->dss->mgr_ops->enable(dssdev->dss->mgr_ops_priv,
|
|
|
|
dssdev->dispc_channel);
|
2012-10-10 14:56:05 +07:00
|
|
|
}
|
2012-10-24 17:52:40 +07:00
|
|
|
EXPORT_SYMBOL(dss_mgr_enable);
|
2012-10-10 14:56:05 +07:00
|
|
|
|
2018-02-13 19:00:38 +07:00
|
|
|
void dss_mgr_disable(struct omap_dss_device *dssdev)
|
2012-10-10 14:56:05 +07:00
|
|
|
{
|
2018-03-02 08:05:10 +07:00
|
|
|
dssdev->dss->mgr_ops->disable(dssdev->dss->mgr_ops_priv,
|
|
|
|
dssdev->dispc_channel);
|
2012-10-10 14:56:05 +07:00
|
|
|
}
|
2012-10-24 17:52:40 +07:00
|
|
|
EXPORT_SYMBOL(dss_mgr_disable);
|
2012-10-10 14:56:05 +07:00
|
|
|
|
2018-02-13 19:00:38 +07:00
|
|
|
void dss_mgr_start_update(struct omap_dss_device *dssdev)
|
2012-10-10 14:56:05 +07:00
|
|
|
{
|
2018-03-02 08:05:10 +07:00
|
|
|
dssdev->dss->mgr_ops->start_update(dssdev->dss->mgr_ops_priv,
|
|
|
|
dssdev->dispc_channel);
|
2012-10-10 14:56:05 +07:00
|
|
|
}
|
2012-10-24 17:52:40 +07:00
|
|
|
EXPORT_SYMBOL(dss_mgr_start_update);
|
2012-10-10 17:59:07 +07:00
|
|
|
|
2018-02-13 19:00:38 +07:00
|
|
|
int dss_mgr_register_framedone_handler(struct omap_dss_device *dssdev,
|
2012-10-10 17:59:07 +07:00
|
|
|
void (*handler)(void *), void *data)
|
|
|
|
{
|
2018-03-02 08:05:10 +07:00
|
|
|
struct dss_device *dss = dssdev->dss;
|
|
|
|
|
|
|
|
return dss->mgr_ops->register_framedone_handler(dss->mgr_ops_priv,
|
|
|
|
dssdev->dispc_channel,
|
|
|
|
handler, data);
|
2012-10-10 17:59:07 +07:00
|
|
|
}
|
2012-10-24 17:52:40 +07:00
|
|
|
EXPORT_SYMBOL(dss_mgr_register_framedone_handler);
|
2012-10-10 17:59:07 +07:00
|
|
|
|
2018-02-13 19:00:38 +07:00
|
|
|
void dss_mgr_unregister_framedone_handler(struct omap_dss_device *dssdev,
|
2012-10-10 17:59:07 +07:00
|
|
|
void (*handler)(void *), void *data)
|
|
|
|
{
|
2018-03-02 08:05:10 +07:00
|
|
|
struct dss_device *dss = dssdev->dss;
|
|
|
|
|
|
|
|
dss->mgr_ops->unregister_framedone_handler(dss->mgr_ops_priv,
|
|
|
|
dssdev->dispc_channel,
|
|
|
|
handler, data);
|
2012-10-10 17:59:07 +07:00
|
|
|
}
|
2012-10-24 17:52:40 +07:00
|
|
|
EXPORT_SYMBOL(dss_mgr_unregister_framedone_handler);
|