2019-05-27 13:55:01 +07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2015-10-29 15:37:32 +07:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2015 Free Electrons
|
|
|
|
* Copyright (C) 2015 NextThing Co
|
|
|
|
*
|
|
|
|
* Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/clk.h>
|
|
|
|
|
|
|
|
#include <drm/drm_atomic_helper.h>
|
2019-08-26 22:26:29 +07:00
|
|
|
#include <drm/drm_bridge.h>
|
2017-03-30 01:55:46 +07:00
|
|
|
#include <drm/drm_of.h>
|
2015-10-29 15:37:32 +07:00
|
|
|
#include <drm/drm_panel.h>
|
2019-07-16 13:42:06 +07:00
|
|
|
#include <drm/drm_print.h>
|
2019-01-18 04:03:34 +07:00
|
|
|
#include <drm/drm_probe_helper.h>
|
2020-03-05 22:59:42 +07:00
|
|
|
#include <drm/drm_simple_kms_helper.h>
|
2015-10-29 15:37:32 +07:00
|
|
|
|
2017-02-23 15:05:39 +07:00
|
|
|
#include "sun4i_crtc.h"
|
2015-10-29 15:37:32 +07:00
|
|
|
#include "sun4i_tcon.h"
|
2016-09-08 17:59:22 +07:00
|
|
|
#include "sun4i_rgb.h"
|
2015-10-29 15:37:32 +07:00
|
|
|
|
|
|
|
struct sun4i_rgb {
|
|
|
|
struct drm_connector connector;
|
|
|
|
struct drm_encoder encoder;
|
|
|
|
|
2017-02-23 15:05:41 +07:00
|
|
|
struct sun4i_tcon *tcon;
|
2019-02-26 21:25:46 +07:00
|
|
|
struct drm_panel *panel;
|
2019-02-26 21:25:47 +07:00
|
|
|
struct drm_bridge *bridge;
|
2015-10-29 15:37:32 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
static inline struct sun4i_rgb *
|
|
|
|
drm_connector_to_sun4i_rgb(struct drm_connector *connector)
|
|
|
|
{
|
|
|
|
return container_of(connector, struct sun4i_rgb,
|
|
|
|
connector);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct sun4i_rgb *
|
|
|
|
drm_encoder_to_sun4i_rgb(struct drm_encoder *encoder)
|
|
|
|
{
|
|
|
|
return container_of(encoder, struct sun4i_rgb,
|
|
|
|
encoder);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int sun4i_rgb_get_modes(struct drm_connector *connector)
|
|
|
|
{
|
|
|
|
struct sun4i_rgb *rgb =
|
|
|
|
drm_connector_to_sun4i_rgb(connector);
|
|
|
|
|
2019-12-07 21:03:34 +07:00
|
|
|
return drm_panel_get_modes(rgb->panel, connector);
|
2015-10-29 15:37:32 +07:00
|
|
|
}
|
|
|
|
|
drm/sun4i: rgb: Change the pixel clock validation check
The current code, since commit bb43d40d7c83 ("drm/sun4i: rgb: Validate the
clock rate"), perform some validation on the pixel clock to filter out the
EDID modes provided by monitors (through bridges) that we wouldn't be able
to reach. For the usual modes, we're able to generate a perfect clock rate,
so a strict check was enough.
However, this had the side effect of preventing displays that would work
otherwise to operate properly, since we would pretty much never be able to
generate an exact rate for those displays, even though we would fall within
that panel tolerance.
This was also shown to happen for unusual modes exposed through EDIDs, for
example on eDP panels.
We can work around this by simplifying a bit the problem: no panels we've
encountered so far actually needed that check. All of them are tied to a
particular board when it is produced, and made to work with the Allwinner
BSP. That pretty much guarantees that we never have a pixel clock out of
reach.
On the other hand, the EDIDs modes that needed to be validated have always
been exposed through bridges.
Let's just use that metric to instead of validating all modes, only
validate modes when we have a bridge attached. It should be good enough for
now, while we still have room for improvements or refinements using the
display_timings structure for example for panels.
We also add a tolerance for EDID-based modes instead of doing a strict
check. This tolerance is of 0.5% which is the one advertised in the VESA
DVT and CVT specs. If that needed to be extended in the future, we can add
a custom module parameter to relax it a bit.
Fixes: bb43d40d7c83 ("drm/sun4i: rgb: Validate the clock rate")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> # tested on pinebook
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ec2dc2a7b3d4bd44f7a2a6e1c1813f92449a7310.1551191081.git-series.maxime.ripard@bootlin.com
2019-02-26 21:25:49 +07:00
|
|
|
/*
|
|
|
|
* VESA DMT defines a tolerance of 0.5% on the pixel clock, while the
|
|
|
|
* CVT spec reuses that tolerance in its examples, so it looks to be a
|
|
|
|
* good default tolerance for the EDID-based modes. Define it to 5 per
|
|
|
|
* mille to avoid floating point operations.
|
|
|
|
*/
|
|
|
|
#define SUN4I_RGB_DOTCLOCK_TOLERANCE_PER_MILLE 5
|
|
|
|
|
2018-03-13 18:36:57 +07:00
|
|
|
static enum drm_mode_status sun4i_rgb_mode_valid(struct drm_encoder *crtc,
|
|
|
|
const struct drm_display_mode *mode)
|
2015-10-29 15:37:32 +07:00
|
|
|
{
|
2018-03-13 18:36:57 +07:00
|
|
|
struct sun4i_rgb *rgb = drm_encoder_to_sun4i_rgb(crtc);
|
2017-02-23 15:05:41 +07:00
|
|
|
struct sun4i_tcon *tcon = rgb->tcon;
|
2015-10-29 15:37:32 +07:00
|
|
|
u32 hsync = mode->hsync_end - mode->hsync_start;
|
|
|
|
u32 vsync = mode->vsync_end - mode->vsync_start;
|
2019-02-26 21:25:48 +07:00
|
|
|
unsigned long long rate = mode->clock * 1000;
|
drm/sun4i: rgb: Change the pixel clock validation check
The current code, since commit bb43d40d7c83 ("drm/sun4i: rgb: Validate the
clock rate"), perform some validation on the pixel clock to filter out the
EDID modes provided by monitors (through bridges) that we wouldn't be able
to reach. For the usual modes, we're able to generate a perfect clock rate,
so a strict check was enough.
However, this had the side effect of preventing displays that would work
otherwise to operate properly, since we would pretty much never be able to
generate an exact rate for those displays, even though we would fall within
that panel tolerance.
This was also shown to happen for unusual modes exposed through EDIDs, for
example on eDP panels.
We can work around this by simplifying a bit the problem: no panels we've
encountered so far actually needed that check. All of them are tied to a
particular board when it is produced, and made to work with the Allwinner
BSP. That pretty much guarantees that we never have a pixel clock out of
reach.
On the other hand, the EDIDs modes that needed to be validated have always
been exposed through bridges.
Let's just use that metric to instead of validating all modes, only
validate modes when we have a bridge attached. It should be good enough for
now, while we still have room for improvements or refinements using the
display_timings structure for example for panels.
We also add a tolerance for EDID-based modes instead of doing a strict
check. This tolerance is of 0.5% which is the one advertised in the VESA
DVT and CVT specs. If that needed to be extended in the future, we can add
a custom module parameter to relax it a bit.
Fixes: bb43d40d7c83 ("drm/sun4i: rgb: Validate the clock rate")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> # tested on pinebook
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ec2dc2a7b3d4bd44f7a2a6e1c1813f92449a7310.1551191081.git-series.maxime.ripard@bootlin.com
2019-02-26 21:25:49 +07:00
|
|
|
unsigned long long lowest, highest;
|
2019-02-26 21:25:48 +07:00
|
|
|
unsigned long long rounded_rate;
|
2015-10-29 15:37:32 +07:00
|
|
|
|
|
|
|
DRM_DEBUG_DRIVER("Validating modes...\n");
|
|
|
|
|
|
|
|
if (hsync < 1)
|
|
|
|
return MODE_HSYNC_NARROW;
|
|
|
|
|
|
|
|
if (hsync > 0x3ff)
|
|
|
|
return MODE_HSYNC_WIDE;
|
|
|
|
|
|
|
|
if ((mode->hdisplay < 1) || (mode->htotal < 1))
|
|
|
|
return MODE_H_ILLEGAL;
|
|
|
|
|
|
|
|
if ((mode->hdisplay > 0x7ff) || (mode->htotal > 0xfff))
|
|
|
|
return MODE_BAD_HVALUE;
|
|
|
|
|
|
|
|
DRM_DEBUG_DRIVER("Horizontal parameters OK\n");
|
|
|
|
|
|
|
|
if (vsync < 1)
|
|
|
|
return MODE_VSYNC_NARROW;
|
|
|
|
|
|
|
|
if (vsync > 0x3ff)
|
|
|
|
return MODE_VSYNC_WIDE;
|
|
|
|
|
|
|
|
if ((mode->vdisplay < 1) || (mode->vtotal < 1))
|
|
|
|
return MODE_V_ILLEGAL;
|
|
|
|
|
|
|
|
if ((mode->vdisplay > 0x7ff) || (mode->vtotal > 0xfff))
|
|
|
|
return MODE_BAD_VVALUE;
|
|
|
|
|
|
|
|
DRM_DEBUG_DRIVER("Vertical parameters OK\n");
|
|
|
|
|
drm/sun4i: rgb: Change the pixel clock validation check
The current code, since commit bb43d40d7c83 ("drm/sun4i: rgb: Validate the
clock rate"), perform some validation on the pixel clock to filter out the
EDID modes provided by monitors (through bridges) that we wouldn't be able
to reach. For the usual modes, we're able to generate a perfect clock rate,
so a strict check was enough.
However, this had the side effect of preventing displays that would work
otherwise to operate properly, since we would pretty much never be able to
generate an exact rate for those displays, even though we would fall within
that panel tolerance.
This was also shown to happen for unusual modes exposed through EDIDs, for
example on eDP panels.
We can work around this by simplifying a bit the problem: no panels we've
encountered so far actually needed that check. All of them are tied to a
particular board when it is produced, and made to work with the Allwinner
BSP. That pretty much guarantees that we never have a pixel clock out of
reach.
On the other hand, the EDIDs modes that needed to be validated have always
been exposed through bridges.
Let's just use that metric to instead of validating all modes, only
validate modes when we have a bridge attached. It should be good enough for
now, while we still have room for improvements or refinements using the
display_timings structure for example for panels.
We also add a tolerance for EDID-based modes instead of doing a strict
check. This tolerance is of 0.5% which is the one advertised in the VESA
DVT and CVT specs. If that needed to be extended in the future, we can add
a custom module parameter to relax it a bit.
Fixes: bb43d40d7c83 ("drm/sun4i: rgb: Validate the clock rate")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> # tested on pinebook
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ec2dc2a7b3d4bd44f7a2a6e1c1813f92449a7310.1551191081.git-series.maxime.ripard@bootlin.com
2019-02-26 21:25:49 +07:00
|
|
|
/*
|
|
|
|
* TODO: We should use the struct display_timing if available
|
|
|
|
* and / or trying to stretch the timings within that
|
|
|
|
* tolerancy to take care of panels that we wouldn't be able
|
|
|
|
* to have a exact match for.
|
|
|
|
*/
|
|
|
|
if (rgb->panel) {
|
|
|
|
DRM_DEBUG_DRIVER("RGB panel used, skipping clock rate checks");
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* That shouldn't ever happen unless something is really wrong, but it
|
|
|
|
* doesn't harm to check.
|
|
|
|
*/
|
|
|
|
if (!rgb->bridge)
|
|
|
|
goto out;
|
|
|
|
|
2018-02-21 19:57:02 +07:00
|
|
|
tcon->dclk_min_div = 6;
|
|
|
|
tcon->dclk_max_div = 127;
|
2016-04-21 16:25:26 +07:00
|
|
|
rounded_rate = clk_round_rate(tcon->dclk, rate);
|
drm/sun4i: rgb: Change the pixel clock validation check
The current code, since commit bb43d40d7c83 ("drm/sun4i: rgb: Validate the
clock rate"), perform some validation on the pixel clock to filter out the
EDID modes provided by monitors (through bridges) that we wouldn't be able
to reach. For the usual modes, we're able to generate a perfect clock rate,
so a strict check was enough.
However, this had the side effect of preventing displays that would work
otherwise to operate properly, since we would pretty much never be able to
generate an exact rate for those displays, even though we would fall within
that panel tolerance.
This was also shown to happen for unusual modes exposed through EDIDs, for
example on eDP panels.
We can work around this by simplifying a bit the problem: no panels we've
encountered so far actually needed that check. All of them are tied to a
particular board when it is produced, and made to work with the Allwinner
BSP. That pretty much guarantees that we never have a pixel clock out of
reach.
On the other hand, the EDIDs modes that needed to be validated have always
been exposed through bridges.
Let's just use that metric to instead of validating all modes, only
validate modes when we have a bridge attached. It should be good enough for
now, while we still have room for improvements or refinements using the
display_timings structure for example for panels.
We also add a tolerance for EDID-based modes instead of doing a strict
check. This tolerance is of 0.5% which is the one advertised in the VESA
DVT and CVT specs. If that needed to be extended in the future, we can add
a custom module parameter to relax it a bit.
Fixes: bb43d40d7c83 ("drm/sun4i: rgb: Validate the clock rate")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> # tested on pinebook
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ec2dc2a7b3d4bd44f7a2a6e1c1813f92449a7310.1551191081.git-series.maxime.ripard@bootlin.com
2019-02-26 21:25:49 +07:00
|
|
|
|
|
|
|
lowest = rate * (1000 - SUN4I_RGB_DOTCLOCK_TOLERANCE_PER_MILLE);
|
|
|
|
do_div(lowest, 1000);
|
|
|
|
if (rounded_rate < lowest)
|
2016-04-21 16:25:26 +07:00
|
|
|
return MODE_CLOCK_LOW;
|
|
|
|
|
drm/sun4i: rgb: Change the pixel clock validation check
The current code, since commit bb43d40d7c83 ("drm/sun4i: rgb: Validate the
clock rate"), perform some validation on the pixel clock to filter out the
EDID modes provided by monitors (through bridges) that we wouldn't be able
to reach. For the usual modes, we're able to generate a perfect clock rate,
so a strict check was enough.
However, this had the side effect of preventing displays that would work
otherwise to operate properly, since we would pretty much never be able to
generate an exact rate for those displays, even though we would fall within
that panel tolerance.
This was also shown to happen for unusual modes exposed through EDIDs, for
example on eDP panels.
We can work around this by simplifying a bit the problem: no panels we've
encountered so far actually needed that check. All of them are tied to a
particular board when it is produced, and made to work with the Allwinner
BSP. That pretty much guarantees that we never have a pixel clock out of
reach.
On the other hand, the EDIDs modes that needed to be validated have always
been exposed through bridges.
Let's just use that metric to instead of validating all modes, only
validate modes when we have a bridge attached. It should be good enough for
now, while we still have room for improvements or refinements using the
display_timings structure for example for panels.
We also add a tolerance for EDID-based modes instead of doing a strict
check. This tolerance is of 0.5% which is the one advertised in the VESA
DVT and CVT specs. If that needed to be extended in the future, we can add
a custom module parameter to relax it a bit.
Fixes: bb43d40d7c83 ("drm/sun4i: rgb: Validate the clock rate")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> # tested on pinebook
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ec2dc2a7b3d4bd44f7a2a6e1c1813f92449a7310.1551191081.git-series.maxime.ripard@bootlin.com
2019-02-26 21:25:49 +07:00
|
|
|
highest = rate * (1000 + SUN4I_RGB_DOTCLOCK_TOLERANCE_PER_MILLE);
|
|
|
|
do_div(highest, 1000);
|
|
|
|
if (rounded_rate > highest)
|
2016-04-21 16:25:26 +07:00
|
|
|
return MODE_CLOCK_HIGH;
|
|
|
|
|
drm/sun4i: rgb: Change the pixel clock validation check
The current code, since commit bb43d40d7c83 ("drm/sun4i: rgb: Validate the
clock rate"), perform some validation on the pixel clock to filter out the
EDID modes provided by monitors (through bridges) that we wouldn't be able
to reach. For the usual modes, we're able to generate a perfect clock rate,
so a strict check was enough.
However, this had the side effect of preventing displays that would work
otherwise to operate properly, since we would pretty much never be able to
generate an exact rate for those displays, even though we would fall within
that panel tolerance.
This was also shown to happen for unusual modes exposed through EDIDs, for
example on eDP panels.
We can work around this by simplifying a bit the problem: no panels we've
encountered so far actually needed that check. All of them are tied to a
particular board when it is produced, and made to work with the Allwinner
BSP. That pretty much guarantees that we never have a pixel clock out of
reach.
On the other hand, the EDIDs modes that needed to be validated have always
been exposed through bridges.
Let's just use that metric to instead of validating all modes, only
validate modes when we have a bridge attached. It should be good enough for
now, while we still have room for improvements or refinements using the
display_timings structure for example for panels.
We also add a tolerance for EDID-based modes instead of doing a strict
check. This tolerance is of 0.5% which is the one advertised in the VESA
DVT and CVT specs. If that needed to be extended in the future, we can add
a custom module parameter to relax it a bit.
Fixes: bb43d40d7c83 ("drm/sun4i: rgb: Validate the clock rate")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> # tested on pinebook
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ec2dc2a7b3d4bd44f7a2a6e1c1813f92449a7310.1551191081.git-series.maxime.ripard@bootlin.com
2019-02-26 21:25:49 +07:00
|
|
|
out:
|
2016-04-21 16:25:26 +07:00
|
|
|
DRM_DEBUG_DRIVER("Clock rate OK\n");
|
|
|
|
|
2015-10-29 15:37:32 +07:00
|
|
|
return MODE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct drm_connector_helper_funcs sun4i_rgb_con_helper_funcs = {
|
|
|
|
.get_modes = sun4i_rgb_get_modes,
|
|
|
|
};
|
|
|
|
|
|
|
|
static void
|
|
|
|
sun4i_rgb_connector_destroy(struct drm_connector *connector)
|
|
|
|
{
|
|
|
|
struct sun4i_rgb *rgb = drm_connector_to_sun4i_rgb(connector);
|
|
|
|
|
2019-02-26 21:25:46 +07:00
|
|
|
drm_panel_detach(rgb->panel);
|
2015-10-29 15:37:32 +07:00
|
|
|
drm_connector_cleanup(connector);
|
|
|
|
}
|
|
|
|
|
2017-08-08 18:28:31 +07:00
|
|
|
static const struct drm_connector_funcs sun4i_rgb_con_funcs = {
|
2015-10-29 15:37:32 +07:00
|
|
|
.fill_modes = drm_helper_probe_single_connector_modes,
|
|
|
|
.destroy = sun4i_rgb_connector_destroy,
|
|
|
|
.reset = drm_atomic_helper_connector_reset,
|
|
|
|
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
|
|
|
|
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
|
|
|
|
};
|
|
|
|
|
|
|
|
static void sun4i_rgb_encoder_enable(struct drm_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct sun4i_rgb *rgb = drm_encoder_to_sun4i_rgb(encoder);
|
|
|
|
|
|
|
|
DRM_DEBUG_DRIVER("Enabling RGB output\n");
|
|
|
|
|
2019-02-26 21:25:46 +07:00
|
|
|
if (rgb->panel) {
|
|
|
|
drm_panel_prepare(rgb->panel);
|
|
|
|
drm_panel_enable(rgb->panel);
|
drm/sun4i: tcon: Don't rely on encoders to enable the TCON
So far, we've required all the TCON-connected encoders to call the TCON
enable and disable functions.
This was made this way because in the RGB/LVDS case, the TCON is the CRTC
and the encoder. However, in all the other cases (HDMI, TV, DSI, etc.), we
have another encoder down the road that needs to be programmed.
We also needed to know which channel the encoder is connected to, which is
encoder-specific.
The CRTC's enable and disable callbacks can work just fine for our use
case, and we can get the channel to use just by looking at the type of
encoder, since that is fixed. Implement those callbacks, which will
remove some of the encoder boilerplate.
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/90b4396e19b3eca61b2ebfdae0672074b88ad74d.1508231063.git-series.maxime.ripard@free-electrons.com
2017-10-17 16:06:12 +07:00
|
|
|
}
|
2015-10-29 15:37:32 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void sun4i_rgb_encoder_disable(struct drm_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct sun4i_rgb *rgb = drm_encoder_to_sun4i_rgb(encoder);
|
|
|
|
|
|
|
|
DRM_DEBUG_DRIVER("Disabling RGB output\n");
|
|
|
|
|
2019-02-26 21:25:46 +07:00
|
|
|
if (rgb->panel) {
|
|
|
|
drm_panel_disable(rgb->panel);
|
|
|
|
drm_panel_unprepare(rgb->panel);
|
drm/sun4i: tcon: Don't rely on encoders to enable the TCON
So far, we've required all the TCON-connected encoders to call the TCON
enable and disable functions.
This was made this way because in the RGB/LVDS case, the TCON is the CRTC
and the encoder. However, in all the other cases (HDMI, TV, DSI, etc.), we
have another encoder down the road that needs to be programmed.
We also needed to know which channel the encoder is connected to, which is
encoder-specific.
The CRTC's enable and disable callbacks can work just fine for our use
case, and we can get the channel to use just by looking at the type of
encoder, since that is fixed. Implement those callbacks, which will
remove some of the encoder boilerplate.
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/90b4396e19b3eca61b2ebfdae0672074b88ad74d.1508231063.git-series.maxime.ripard@free-electrons.com
2017-10-17 16:06:12 +07:00
|
|
|
}
|
2015-10-29 15:37:32 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct drm_encoder_helper_funcs sun4i_rgb_enc_helper_funcs = {
|
|
|
|
.disable = sun4i_rgb_encoder_disable,
|
|
|
|
.enable = sun4i_rgb_encoder_enable,
|
2018-03-13 18:36:57 +07:00
|
|
|
.mode_valid = sun4i_rgb_mode_valid,
|
2015-10-29 15:37:32 +07:00
|
|
|
};
|
|
|
|
|
2017-02-23 15:05:41 +07:00
|
|
|
int sun4i_rgb_init(struct drm_device *drm, struct sun4i_tcon *tcon)
|
2015-10-29 15:37:32 +07:00
|
|
|
{
|
2016-04-11 17:16:33 +07:00
|
|
|
struct drm_encoder *encoder;
|
2015-10-29 15:37:32 +07:00
|
|
|
struct sun4i_rgb *rgb;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
rgb = devm_kzalloc(drm->dev, sizeof(*rgb), GFP_KERNEL);
|
|
|
|
if (!rgb)
|
|
|
|
return -ENOMEM;
|
2017-02-23 15:05:41 +07:00
|
|
|
rgb->tcon = tcon;
|
2016-04-11 17:16:33 +07:00
|
|
|
encoder = &rgb->encoder;
|
2015-10-29 15:37:32 +07:00
|
|
|
|
2017-03-30 01:55:46 +07:00
|
|
|
ret = drm_of_find_panel_or_bridge(tcon->dev->of_node, 1, 0,
|
2019-02-26 21:25:47 +07:00
|
|
|
&rgb->panel, &rgb->bridge);
|
2017-03-30 01:55:46 +07:00
|
|
|
if (ret) {
|
2016-04-11 17:16:33 +07:00
|
|
|
dev_info(drm->dev, "No panel or bridge found... RGB output disabled\n");
|
2016-07-20 15:35:06 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-10-29 15:37:32 +07:00
|
|
|
drm_encoder_helper_add(&rgb->encoder,
|
|
|
|
&sun4i_rgb_enc_helper_funcs);
|
2020-03-05 22:59:42 +07:00
|
|
|
ret = drm_simple_encoder_init(drm, &rgb->encoder,
|
|
|
|
DRM_MODE_ENCODER_NONE);
|
2015-10-29 15:37:32 +07:00
|
|
|
if (ret) {
|
|
|
|
dev_err(drm->dev, "Couldn't initialise the rgb encoder\n");
|
|
|
|
goto err_out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The RGB encoder can only work with the TCON channel 0 */
|
2018-06-27 02:47:14 +07:00
|
|
|
rgb->encoder.possible_crtcs = drm_crtc_mask(&tcon->crtc->crtc);
|
2015-10-29 15:37:32 +07:00
|
|
|
|
2019-02-26 21:25:46 +07:00
|
|
|
if (rgb->panel) {
|
2016-04-11 17:16:33 +07:00
|
|
|
drm_connector_helper_add(&rgb->connector,
|
|
|
|
&sun4i_rgb_con_helper_funcs);
|
|
|
|
ret = drm_connector_init(drm, &rgb->connector,
|
|
|
|
&sun4i_rgb_con_funcs,
|
|
|
|
DRM_MODE_CONNECTOR_Unknown);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(drm->dev, "Couldn't initialise the rgb connector\n");
|
|
|
|
goto err_cleanup_connector;
|
|
|
|
}
|
|
|
|
|
2018-07-09 15:40:07 +07:00
|
|
|
drm_connector_attach_encoder(&rgb->connector,
|
2016-04-11 17:16:33 +07:00
|
|
|
&rgb->encoder);
|
|
|
|
|
2019-02-26 21:25:46 +07:00
|
|
|
ret = drm_panel_attach(rgb->panel, &rgb->connector);
|
2016-04-11 17:16:33 +07:00
|
|
|
if (ret) {
|
|
|
|
dev_err(drm->dev, "Couldn't attach our panel\n");
|
|
|
|
goto err_cleanup_connector;
|
|
|
|
}
|
2015-10-29 15:37:32 +07:00
|
|
|
}
|
|
|
|
|
2019-02-26 21:25:47 +07:00
|
|
|
if (rgb->bridge) {
|
drm/bridge: Extend bridge API to disable connector creation
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple components. For instance a
pipeline with a bridge connected to the DDC signals to read EDID data,
and another one connected to the HPD signal to detect connection and
disconnection, will not be possible to support through this model.
- It requires every bridge driver to implement similar connector
handling code, resulting in code duplication.
- It assumes that a bridge will either be wired to a connector or to
another bridge, but doesn't support bridges that can be used in both
positions very well (although there is some ad-hoc support for this in
the analogix_dp bridge driver).
In order to solve these issues, ownership of the connector should be
moved to the display controller driver (where it can be implemented
using helpers provided by the core).
Extend the bridge API to allow disabling connector creation in bridge
drivers as a first step towards the new model. The new flags argument to
the bridge .attach() operation allows instructing the bridge driver to
skip creating a connector. Unconditionally set the new flags argument to
0 for now to keep the existing behaviour, and modify all existing bridge
drivers to return an error when connector creation is not requested as
they don't support this feature yet.
The change is based on the following semantic patch, with manual review
and edits.
@ rule1 @
identifier funcs;
identifier fn;
@@
struct drm_bridge_funcs funcs = {
...,
.attach = fn
};
@ depends on rule1 @
identifier rule1.fn;
identifier bridge;
statement S, S1;
@@
int fn(
struct drm_bridge *bridge
+ , enum drm_bridge_attach_flags flags
)
{
... when != S
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
+ DRM_ERROR("Fix bridge driver to make connector optional!");
+ return -EINVAL;
+ }
+
S1
...
}
@ depends on rule1 @
identifier rule1.fn;
identifier bridge, flags;
expression E1, E2, E3;
@@
int fn(
struct drm_bridge *bridge,
enum drm_bridge_attach_flags flags
) {
<...
drm_bridge_attach(E1, E2, E3
+ , flags
)
...>
}
@@
expression E1, E2, E3;
@@
drm_bridge_attach(E1, E2, E3
+ , 0
)
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-10-laurent.pinchart@ideasonboard.com
2020-02-26 18:24:29 +07:00
|
|
|
ret = drm_bridge_attach(encoder, rgb->bridge, NULL, 0);
|
2016-04-11 17:16:33 +07:00
|
|
|
if (ret) {
|
|
|
|
dev_err(drm->dev, "Couldn't attach our bridge\n");
|
|
|
|
goto err_cleanup_connector;
|
|
|
|
}
|
|
|
|
}
|
2015-10-29 15:37:32 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_cleanup_connector:
|
|
|
|
drm_encoder_cleanup(&rgb->encoder);
|
|
|
|
err_out:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(sun4i_rgb_init);
|