2015-01-21 00:38:44 +08:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2014 Samsung Electronics Co., Ltd
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sub license,
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice (including the
|
|
|
|
* next paragraph) shall be included in all copies or substantial portions
|
|
|
|
* of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
|
|
|
|
* DEALINGS IN THE SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/err.h>
|
|
|
|
#include <linux/module.h>
|
2016-09-01 00:09:05 +08:00
|
|
|
#include <linux/mutex.h>
|
2015-01-21 00:38:44 +08:00
|
|
|
|
2016-09-01 00:09:05 +08:00
|
|
|
#include <drm/drm_bridge.h>
|
2016-11-28 23:59:08 +08:00
|
|
|
#include <drm/drm_encoder.h>
|
2015-01-21 00:38:44 +08:00
|
|
|
|
2016-11-29 00:32:05 +08:00
|
|
|
#include "drm_crtc_internal.h"
|
|
|
|
|
2015-05-21 13:33:17 +08:00
|
|
|
/**
|
|
|
|
* DOC: overview
|
|
|
|
*
|
2016-12-30 04:48:26 +08:00
|
|
|
* &struct drm_bridge represents a device that hangs on to an encoder. These are
|
2015-12-04 16:45:47 +08:00
|
|
|
* handy when a regular &drm_encoder entity isn't enough to represent the entire
|
2015-05-21 13:33:17 +08:00
|
|
|
* encoder chain.
|
|
|
|
*
|
2015-12-04 16:45:47 +08:00
|
|
|
* A bridge is always attached to a single &drm_encoder at a time, but can be
|
2016-06-01 04:55:13 +08:00
|
|
|
* either connected to it directly, or through an intermediate bridge::
|
2015-05-21 13:33:17 +08:00
|
|
|
*
|
2015-12-04 16:45:47 +08:00
|
|
|
* encoder ---> bridge B ---> bridge A
|
2015-05-21 13:33:17 +08:00
|
|
|
*
|
|
|
|
* Here, the output of the encoder feeds to bridge B, and that furthers feeds to
|
|
|
|
* bridge A.
|
|
|
|
*
|
|
|
|
* The driver using the bridge is responsible to make the associations between
|
|
|
|
* the encoder and bridges. Once these links are made, the bridges will
|
|
|
|
* participate along with encoder functions to perform mode_set/enable/disable
|
2015-12-04 16:45:47 +08:00
|
|
|
* through the ops provided in &drm_bridge_funcs.
|
2015-05-21 13:33:17 +08:00
|
|
|
*
|
|
|
|
* drm_bridge, like drm_panel, aren't drm_mode_object entities like planes,
|
2015-12-04 16:45:47 +08:00
|
|
|
* CRTCs, encoders or connectors and hence are not visible to userspace. They
|
|
|
|
* just provide additional hooks to get the desired output at the end of the
|
|
|
|
* encoder chain.
|
|
|
|
*
|
2017-01-02 16:17:26 +08:00
|
|
|
* Bridges can also be chained up using the &drm_bridge.next pointer.
|
2015-12-04 16:45:47 +08:00
|
|
|
*
|
|
|
|
* Both legacy CRTC helpers and the new atomic modeset helpers support bridges.
|
2015-05-21 13:33:17 +08:00
|
|
|
*/
|
|
|
|
|
2015-01-21 00:38:44 +08:00
|
|
|
static DEFINE_MUTEX(bridge_lock);
|
|
|
|
static LIST_HEAD(bridge_list);
|
|
|
|
|
2015-05-21 13:33:17 +08:00
|
|
|
/**
|
|
|
|
* drm_bridge_add - add the given bridge to the global bridge list
|
|
|
|
*
|
|
|
|
* @bridge: bridge control structure
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
* Unconditionally returns Zero.
|
|
|
|
*/
|
2015-01-21 00:38:44 +08:00
|
|
|
int drm_bridge_add(struct drm_bridge *bridge)
|
|
|
|
{
|
|
|
|
mutex_lock(&bridge_lock);
|
|
|
|
list_add_tail(&bridge->list, &bridge_list);
|
|
|
|
mutex_unlock(&bridge_lock);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_bridge_add);
|
|
|
|
|
2015-05-21 13:33:17 +08:00
|
|
|
/**
|
|
|
|
* drm_bridge_remove - remove the given bridge from the global bridge list
|
|
|
|
*
|
|
|
|
* @bridge: bridge control structure
|
|
|
|
*/
|
2015-01-21 00:38:44 +08:00
|
|
|
void drm_bridge_remove(struct drm_bridge *bridge)
|
|
|
|
{
|
|
|
|
mutex_lock(&bridge_lock);
|
|
|
|
list_del_init(&bridge->list);
|
|
|
|
mutex_unlock(&bridge_lock);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_bridge_remove);
|
|
|
|
|
2015-05-21 13:33:17 +08:00
|
|
|
/**
|
2016-11-28 23:59:08 +08:00
|
|
|
* drm_bridge_attach - attach the bridge to an encoder's chain
|
2015-05-21 13:33:17 +08:00
|
|
|
*
|
2016-11-28 23:59:08 +08:00
|
|
|
* @encoder: DRM encoder
|
|
|
|
* @bridge: bridge to attach
|
|
|
|
* @previous: previous bridge in the chain (optional)
|
2015-05-21 13:33:17 +08:00
|
|
|
*
|
2016-11-28 23:59:08 +08:00
|
|
|
* Called by a kms driver to link the bridge to an encoder's chain. The previous
|
|
|
|
* argument specifies the previous bridge in the chain. If NULL, the bridge is
|
|
|
|
* linked directly at the encoder's output. Otherwise it is linked at the
|
|
|
|
* previous bridge's output.
|
2015-05-21 13:33:17 +08:00
|
|
|
*
|
2016-11-28 23:59:08 +08:00
|
|
|
* If non-NULL the previous bridge must be already attached by a call to this
|
|
|
|
* function.
|
2015-05-21 13:33:17 +08:00
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
* Zero on success, error code on failure
|
|
|
|
*/
|
2016-11-28 23:59:08 +08:00
|
|
|
int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
|
|
|
|
struct drm_bridge *previous)
|
2015-01-21 00:38:44 +08:00
|
|
|
{
|
2016-11-28 23:59:08 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!encoder || !bridge)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (previous && (!previous->dev || previous->encoder != encoder))
|
2015-01-21 00:38:44 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (bridge->dev)
|
|
|
|
return -EBUSY;
|
|
|
|
|
2016-11-28 23:59:08 +08:00
|
|
|
bridge->dev = encoder->dev;
|
|
|
|
bridge->encoder = encoder;
|
|
|
|
|
|
|
|
if (bridge->funcs->attach) {
|
|
|
|
ret = bridge->funcs->attach(bridge);
|
|
|
|
if (ret < 0) {
|
|
|
|
bridge->dev = NULL;
|
|
|
|
bridge->encoder = NULL;
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (previous)
|
|
|
|
previous->next = bridge;
|
|
|
|
else
|
|
|
|
encoder->bridge = bridge;
|
2015-01-21 00:38:44 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_bridge_attach);
|
|
|
|
|
2016-08-25 17:04:32 +08:00
|
|
|
void drm_bridge_detach(struct drm_bridge *bridge)
|
|
|
|
{
|
|
|
|
if (WARN_ON(!bridge))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (WARN_ON(!bridge->dev))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (bridge->funcs->detach)
|
|
|
|
bridge->funcs->detach(bridge);
|
|
|
|
|
|
|
|
bridge->dev = NULL;
|
|
|
|
}
|
|
|
|
|
2015-05-21 13:33:17 +08:00
|
|
|
/**
|
|
|
|
* DOC: bridge callbacks
|
|
|
|
*
|
2015-12-04 16:45:47 +08:00
|
|
|
* The &drm_bridge_funcs ops are populated by the bridge driver. The DRM
|
|
|
|
* internals (atomic and CRTC helpers) use the helpers defined in drm_bridge.c
|
|
|
|
* These helpers call a specific &drm_bridge_funcs op for all the bridges
|
2015-05-21 13:33:17 +08:00
|
|
|
* during encoder configuration.
|
|
|
|
*
|
2015-12-04 16:45:47 +08:00
|
|
|
* For detailed specification of the bridge callbacks see &drm_bridge_funcs.
|
2015-05-21 13:33:17 +08:00
|
|
|
*/
|
|
|
|
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
/**
|
|
|
|
* drm_bridge_mode_fixup - fixup proposed mode for all bridges in the
|
|
|
|
* encoder chain
|
|
|
|
* @bridge: bridge control structure
|
|
|
|
* @mode: desired mode to be set for the bridge
|
|
|
|
* @adjusted_mode: updated mode that works for this bridge
|
|
|
|
*
|
2017-01-02 16:17:26 +08:00
|
|
|
* Calls &drm_bridge_funcs.mode_fixup for all the bridges in the
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* encoder chain, starting from the first bridge to the last.
|
|
|
|
*
|
|
|
|
* Note: the bridge passed should be the one closest to the encoder
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
* true on success, false on failure
|
|
|
|
*/
|
|
|
|
bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
|
|
|
|
const struct drm_display_mode *mode,
|
|
|
|
struct drm_display_mode *adjusted_mode)
|
|
|
|
{
|
|
|
|
bool ret = true;
|
|
|
|
|
|
|
|
if (!bridge)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
if (bridge->funcs->mode_fixup)
|
|
|
|
ret = bridge->funcs->mode_fixup(bridge, mode, adjusted_mode);
|
|
|
|
|
|
|
|
ret = ret && drm_bridge_mode_fixup(bridge->next, mode, adjusted_mode);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_bridge_mode_fixup);
|
|
|
|
|
|
|
|
/**
|
2017-01-02 16:17:26 +08:00
|
|
|
* drm_bridge_disable - disables all bridges in the encoder chain
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* @bridge: bridge control structure
|
|
|
|
*
|
2017-01-02 16:17:26 +08:00
|
|
|
* Calls &drm_bridge_funcs.disable op for all the bridges in the encoder
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* chain, starting from the last bridge to the first. These are called before
|
|
|
|
* calling the encoder's prepare op.
|
|
|
|
*
|
|
|
|
* Note: the bridge passed should be the one closest to the encoder
|
|
|
|
*/
|
|
|
|
void drm_bridge_disable(struct drm_bridge *bridge)
|
|
|
|
{
|
|
|
|
if (!bridge)
|
|
|
|
return;
|
|
|
|
|
|
|
|
drm_bridge_disable(bridge->next);
|
|
|
|
|
2016-02-26 17:51:06 +08:00
|
|
|
if (bridge->funcs->disable)
|
|
|
|
bridge->funcs->disable(bridge);
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_bridge_disable);
|
|
|
|
|
|
|
|
/**
|
2017-01-02 16:17:26 +08:00
|
|
|
* drm_bridge_post_disable - cleans up after disabling all bridges in the encoder chain
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* @bridge: bridge control structure
|
|
|
|
*
|
2017-01-02 16:17:26 +08:00
|
|
|
* Calls &drm_bridge_funcs.post_disable op for all the bridges in the
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* encoder chain, starting from the first bridge to the last. These are called
|
|
|
|
* after completing the encoder's prepare op.
|
|
|
|
*
|
|
|
|
* Note: the bridge passed should be the one closest to the encoder
|
|
|
|
*/
|
|
|
|
void drm_bridge_post_disable(struct drm_bridge *bridge)
|
|
|
|
{
|
|
|
|
if (!bridge)
|
|
|
|
return;
|
|
|
|
|
2016-02-26 17:51:06 +08:00
|
|
|
if (bridge->funcs->post_disable)
|
|
|
|
bridge->funcs->post_disable(bridge);
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
|
|
|
|
drm_bridge_post_disable(bridge->next);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_bridge_post_disable);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* drm_bridge_mode_set - set proposed mode for all bridges in the
|
|
|
|
* encoder chain
|
|
|
|
* @bridge: bridge control structure
|
|
|
|
* @mode: desired mode to be set for the bridge
|
|
|
|
* @adjusted_mode: updated mode that works for this bridge
|
|
|
|
*
|
2017-01-02 16:17:26 +08:00
|
|
|
* Calls &drm_bridge_funcs.mode_set op for all the bridges in the
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* encoder chain, starting from the first bridge to the last.
|
|
|
|
*
|
|
|
|
* Note: the bridge passed should be the one closest to the encoder
|
|
|
|
*/
|
|
|
|
void drm_bridge_mode_set(struct drm_bridge *bridge,
|
|
|
|
struct drm_display_mode *mode,
|
|
|
|
struct drm_display_mode *adjusted_mode)
|
|
|
|
{
|
|
|
|
if (!bridge)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (bridge->funcs->mode_set)
|
|
|
|
bridge->funcs->mode_set(bridge, mode, adjusted_mode);
|
|
|
|
|
|
|
|
drm_bridge_mode_set(bridge->next, mode, adjusted_mode);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_bridge_mode_set);
|
|
|
|
|
|
|
|
/**
|
2017-01-02 16:17:26 +08:00
|
|
|
* drm_bridge_pre_enable - prepares for enabling all
|
|
|
|
* bridges in the encoder chain
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* @bridge: bridge control structure
|
|
|
|
*
|
2017-01-02 16:17:26 +08:00
|
|
|
* Calls &drm_bridge_funcs.pre_enable op for all the bridges in the encoder
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* chain, starting from the last bridge to the first. These are called
|
|
|
|
* before calling the encoder's commit op.
|
|
|
|
*
|
|
|
|
* Note: the bridge passed should be the one closest to the encoder
|
|
|
|
*/
|
|
|
|
void drm_bridge_pre_enable(struct drm_bridge *bridge)
|
|
|
|
{
|
|
|
|
if (!bridge)
|
|
|
|
return;
|
|
|
|
|
|
|
|
drm_bridge_pre_enable(bridge->next);
|
|
|
|
|
2016-02-26 17:51:06 +08:00
|
|
|
if (bridge->funcs->pre_enable)
|
|
|
|
bridge->funcs->pre_enable(bridge);
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_bridge_pre_enable);
|
|
|
|
|
|
|
|
/**
|
2017-01-02 16:17:26 +08:00
|
|
|
* drm_bridge_enable - enables all bridges in the encoder chain
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* @bridge: bridge control structure
|
|
|
|
*
|
2017-01-02 16:17:26 +08:00
|
|
|
* Calls &drm_bridge_funcs.enable op for all the bridges in the encoder
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* chain, starting from the first bridge to the last. These are called
|
|
|
|
* after completing the encoder's commit op.
|
|
|
|
*
|
|
|
|
* Note that the bridge passed should be the one closest to the encoder
|
|
|
|
*/
|
|
|
|
void drm_bridge_enable(struct drm_bridge *bridge)
|
|
|
|
{
|
|
|
|
if (!bridge)
|
|
|
|
return;
|
|
|
|
|
2016-02-26 17:51:06 +08:00
|
|
|
if (bridge->funcs->enable)
|
|
|
|
bridge->funcs->enable(bridge);
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
|
|
|
|
drm_bridge_enable(bridge->next);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_bridge_enable);
|
|
|
|
|
2015-01-21 00:38:44 +08:00
|
|
|
#ifdef CONFIG_OF
|
2015-05-21 13:33:17 +08:00
|
|
|
/**
|
|
|
|
* of_drm_find_bridge - find the bridge corresponding to the device node in
|
|
|
|
* the global bridge list
|
|
|
|
*
|
|
|
|
* @np: device node
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
* drm_bridge control struct on success, NULL on failure
|
|
|
|
*/
|
2015-01-21 00:38:44 +08:00
|
|
|
struct drm_bridge *of_drm_find_bridge(struct device_node *np)
|
|
|
|
{
|
|
|
|
struct drm_bridge *bridge;
|
|
|
|
|
|
|
|
mutex_lock(&bridge_lock);
|
|
|
|
|
|
|
|
list_for_each_entry(bridge, &bridge_list, list) {
|
|
|
|
if (bridge->of_node == np) {
|
|
|
|
mutex_unlock(&bridge_lock);
|
|
|
|
return bridge;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&bridge_lock);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(of_drm_find_bridge);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
MODULE_AUTHOR("Ajay Kumar <ajaykumar.rs@samsung.com>");
|
|
|
|
MODULE_DESCRIPTION("DRM bridge infrastructure");
|
|
|
|
MODULE_LICENSE("GPL and additional rights");
|