Re: [PATCH 6/7] drm/bridge: Introduce early_enable and late disable
Hi Maxime,
On 28/05/24 17:13, Maxime Ripard wrote:
> On Fri, May 24, 2024 at 04:38:13PM GMT, Aradhya Bhatia wrote:
>> Hi Maxime,
>>
>> On 21/05/24 18:45, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Thu, May 16, 2024 at 03:10:15PM GMT, Aradhya Bhatia wrote:
>>>>>> /**
>>>>>> * @pre_enable:
>>>>>> *
>>>>>> @@ -285,6 +319,26 @@ struct drm_bridge_funcs {
>>>>>> */
>>>>>> void (*enable)(struct drm_bridge *bridge);
>>>>>>
>>>>>> +/**
>>>>>> + * @atomic_early_enable:
>>>>>> + *
>>>>>> + * This callback should enable the bridge. It is called right
>>>>>> before
>>>>>> + * the preceding element in the display pipe is enabled. If the
>>>>>> + * preceding element is a bridge this means it's called before
>>>>>> that
>>>>>> + * bridge's @atomic_early_enable. If the preceding element is a
>>>>>> + * _crtc it's called right before the crtc's
>>>>>> + * _crtc_helper_funcs.atomic_enable hook.
>>>>>> + *
>>>>>> + * The display pipe (i.e. clocks and timing signals) feeding
>>>>>> this bridge
>>>>>> + * will not yet be running when this callback is called. The
>>>>>> bridge can
>>>>>> + * enable the display link feeding the next bridge in the chain
>>>>>> (if
>>>>>> + * there is one) when this callback is called.
>>>>>> + *
>>>>>> + * The @early_enable callback is optional.
>>>>>> + */
>>>>>> +void (*atomic_early_enable)(struct drm_bridge *bridge,
>>>>>> +struct drm_bridge_state
>>>>>> *old_bridge_state);
>>>>>> +
>>>>>> /**
>>>>>> * @atomic_pre_enable:
>>>>>> *
>>>>>> @@ -361,6 +415,21 @@ struct drm_bridge_funcs {
>>>>>> void (*atomic_post_disable)(struct drm_bridge *bridge,
>>>>>> struct drm_bridge_state
>>>>>> *old_bridge_state);
>>>>>>
>>>>>> +/**
>>>>>> + * @atomic_late_disable:
>>>>>> + *
>>>>>> + * This callback should disable the bridge. It is called right
>>>>>> after the
>>>>>> + * preceding element in the display pipe is disabled. If the
>>>>>> preceding
>>>>>> + * element is a bridge this means it's called after that
>>>>>> bridge's
>>>>>> + * @atomic_late_disable. If the preceding element is a
>>>>>> _crtc it's
>>>>>> + * called right after the crtc's
>>>>>> _crtc_helper_funcs.atomic_disable
>>>>>> + * hook.
>>>>>> + *
>>>>>> + * The @atomic_late_disable callback is optional.
>>>>>> + */
>>>>>> +void (*atomic_late_disable)(struct drm_bridge *bridge,
>>>>>> +struct drm_bridge_state
>>>>>> *old_bridge_state);
>>>>>> +
>>>>>
>>>>> But more importantly, I don't quite get the use case you're trying to
>>>>> solve here.
>>>>>
>>>>> If I got the rest of your series, the Cadence DSI bridge needs to be
>>>>> powered up before its source is started. You can't use atomic_enable or
>>>>> atomic_pre_enable because it would start the source before the DSI
>>>>> bridge. Is that correct?
>>>>>
>>>>
>>>> That's right. I cannot use bridge_atomic_pre_enable /
>>>> bridge_atomic_enable here. But that's because my source is CRTC, which
>>>> gets enabled via crtc_atomic_enable.
>>>>
>>>>
>>>>> If it is, then how is it different from what
>>>>> drm_atomic_bridge_chain_pre_enable is doing? The assumption there is
>>>>> that it starts enabling bridges last to first, to it should be enabled
&
Re: [PATCH 1/7] drm/tidss: Add CRTC mode_fixup
Hi Maxime,
On 21/05/24 18:48, Maxime Ripard wrote:
> On Thu, May 16, 2024 at 04:33:40PM GMT, Aradhya Bhatia wrote:
>> Hi Maxime,
>>
>> Thank you for reviewing the patches.
>>
>> On 16/05/24 13:40, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Sat, May 11, 2024 at 09:00:45PM +0530, Aradhya Bhatia wrote:
>>>> Add support for mode_fixup for the tidss CRTC.
>>>>
>>>> Some bridges like the cdns-dsi consume the crtc_* timing parameters for
>>>> programming the blanking values. Allow for the normal timing parameters
>>>> to get copied to crtc_* timing params.
>>>>
>>>> Signed-off-by: Aradhya Bhatia
>>>> ---
>>>> drivers/gpu/drm/tidss/tidss_crtc.c | 11 +++
>>>> 1 file changed, 11 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c
>>>> b/drivers/gpu/drm/tidss/tidss_crtc.c
>>>> index 94f8e3178df5..797ef53d9ad2 100644
>>>> --- a/drivers/gpu/drm/tidss/tidss_crtc.c
>>>> +++ b/drivers/gpu/drm/tidss/tidss_crtc.c
>>>> @@ -309,12 +309,23 @@ enum drm_mode_status tidss_crtc_mode_valid(struct
>>>> drm_crtc *crtc,
>>>>return dispc_vp_mode_valid(tidss->dispc, tcrtc->hw_videoport, mode);
>>>> }
>>>>
>>>> +static
>>>> +bool tidss_crtc_mode_fixup(struct drm_crtc *crtc,
>>>> + const struct drm_display_mode *mode,
>>>> + struct drm_display_mode *adjusted_mode)
>>>> +{
>>>> + drm_mode_set_crtcinfo(adjusted_mode, 0);
>>>> +
>>>> + return true;
>>>> +}
>>>> +
>>>> static const struct drm_crtc_helper_funcs tidss_crtc_helper_funcs = {
>>>>.atomic_check = tidss_crtc_atomic_check,
>>>>.atomic_flush = tidss_crtc_atomic_flush,
>>>>.atomic_enable = tidss_crtc_atomic_enable,
>>>>.atomic_disable = tidss_crtc_atomic_disable,
>>>>
>>>> + .mode_fixup = tidss_crtc_mode_fixup,
>>>>.mode_valid = tidss_crtc_mode_valid,
>>>> };
>>>
>>> mode_fixup is deprecated for atomic drivers, so the solution must be
>>> different there.
>>>
>>> It's also not clear to me how it could change anything there:
>>> drm_mode_set_crtcinfo with no flags will make crtc_* field exactly
>>> identical to their !crtc counterparts.
>>>
>>
>> I checked the flag options. There isn't any flag required. The only
>> reason to add this call is because cdns-dsi strictly requires the crtc_*
>> fields to be populated during the bridge enable.
>>
>> Secondly, if mode_fixup is deprecated, I think the crtc_atomic_check
>> would be the next best place to add this call.
>
> That would be better, yes, but we shouldn't even have to do that in the
> first place. AFAIK all the path that create a drm_display_mode will call
> drm_mode_set_crtcinfo on it to fill those fields. So if they are missing
> somewhere, that's what the actual bug is, not something we should work
> around of at the driver level.
>
You are right. This patch isn't required at all. The fix around the
mode->crtc_clock usage in one place in the cdns-dsi driver makes this
patch unnecessary. The DRM core does duplicate the timing parameters at
a later stage for the cdns-dsi bridge_enable to consume.
Dropped this patch in v2. Thanks!
Regards
Aradhya
[PATCH v2 6/9] drm/bridge: cdns-dsi: Reset the DCS write FIFO
Allow the DCS Write FIFO in the cdns-dsi controller to reset before any DCS packet is transmitted to the DSI sink device. The DCS FIFO reset is optional. Not all panels require it. But at least one of the DSI based panel that uses Ilitek ILI9881C (DSI to DPI bridge) doesn't work with without this reset. Signed-off-by: Aradhya Bhatia --- drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c index 05d2f4cc50da..87fdd07ca0bc 100644 --- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c +++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c @@ -1037,6 +1037,9 @@ static ssize_t cdns_dsi_transfer(struct mipi_dsi_host *host, cdns_dsi_init_link(dsi); + /* Reset the DCS Write FIFO */ + writel(0x00, dsi->regs + DIRECT_CMD_FIFO_RST); + ret = mipi_dsi_create_packet(, msg); if (ret) goto out; -- 2.34.1
[PATCH v2 9/9] drm/bridge: cdns-dsi: Use pre_enable/post_disable to enable/disable
The cdns-dsi controller requires that it be turned on completely before
the input DPI's source has begun streaming[0]. Not having that, allows
for a small window before cdns-dsi enable and after cdns-dsi disable
where the previous entity (in this case tidss's videoport) to continue
streaming DPI video signals. This small window where cdns-dsi is
disabled but is still receiving signals causes the input FIFO of
cdns-dsi to get corrupted. This causes the colors to shift on the output
display. The colors can either shift by one color component (R->G, G->B,
B->R), or by two color components (R->B, G->R, B->G).
Since tidss's videoport starts streaming via crtc enable hooks, we need
cdns-dsi to be up and running before that. Now that the bridges are
pre_enabled before crtc is enabled, and post_disabled after crtc is
disabled, use the pre_enable and post_disable hooks to get cdns-dsi
ready and running before the tidss videoport to get pass the color shift
issues.
[0]: See section 12.6.5.7.3 "Start-up Procedure" in J721E SoC TRM
TRM Link: http://www.ti.com/lit/pdf/spruil1
Signed-off-by: Aradhya Bhatia
---
.../gpu/drm/bridge/cadence/cdns-dsi-core.c| 32 +++
1 file changed, 4 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
index 6a2223ecff7d..1eedc7053ef8 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
@@ -656,8 +656,8 @@ cdns_dsi_bridge_mode_valid(struct drm_bridge *bridge,
return MODE_OK;
}
-static void cdns_dsi_bridge_atomic_disable(struct drm_bridge *bridge,
- struct drm_bridge_state
*old_bridge_state)
+static void cdns_dsi_bridge_atomic_post_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
struct cdns_dsi *dsi = input_to_dsi(input);
@@ -677,15 +677,6 @@ static void cdns_dsi_bridge_atomic_disable(struct
drm_bridge *bridge,
pm_runtime_put(dsi->base.dev);
}
-static void cdns_dsi_bridge_atomic_post_disable(struct drm_bridge *bridge,
- struct drm_bridge_state
*old_bridge_state)
-{
- struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
- struct cdns_dsi *dsi = input_to_dsi(input);
-
- pm_runtime_put(dsi->base.dev);
-}
-
static void cdns_dsi_hs_init(struct cdns_dsi *dsi)
{
struct cdns_dsi_output *output = >output;
@@ -755,8 +746,8 @@ static void cdns_dsi_init_link(struct cdns_dsi *dsi)
dsi->link_initialized = true;
}
-static void cdns_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
- struct drm_bridge_state
*old_bridge_state)
+static void cdns_dsi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
struct cdns_dsi *dsi = input_to_dsi(input);
@@ -907,19 +898,6 @@ static void cdns_dsi_bridge_atomic_enable(struct
drm_bridge *bridge,
writel(tmp, dsi->regs + MCTL_MAIN_EN);
}
-static void cdns_dsi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
- struct drm_bridge_state
*old_bridge_state)
-{
- struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
- struct cdns_dsi *dsi = input_to_dsi(input);
-
- if (WARN_ON(pm_runtime_get_sync(dsi->base.dev) < 0))
- return;
-
- cdns_dsi_init_link(dsi);
- cdns_dsi_hs_init(dsi);
-}
-
static u32 *cdns_dsi_bridge_get_input_bus_fmts(struct drm_bridge *bridge,
struct drm_bridge_state
*bridge_state,
struct drm_crtc_state
*crtc_state,
@@ -968,9 +946,7 @@ static u32 *cdns_dsi_bridge_get_input_bus_fmts(struct
drm_bridge *bridge,
static const struct drm_bridge_funcs cdns_dsi_bridge_funcs = {
.attach = cdns_dsi_bridge_attach,
.mode_valid = cdns_dsi_bridge_mode_valid,
- .atomic_disable = cdns_dsi_bridge_atomic_disable,
.atomic_pre_enable = cdns_dsi_bridge_atomic_pre_enable,
- .atomic_enable = cdns_dsi_bridge_atomic_enable,
.atomic_post_disable = cdns_dsi_bridge_atomic_post_disable,
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
--
2.34.1
[PATCH v2 8/9] drm/atomic-helper: Re-order bridge chain pre-enable and post-disable
Move the bridge pre_enable call before crtc enable, and the bridge
post_disable call after the crtc disable.
The sequence of enable after this patch will look like:
bridge[n]_pre_enable
...
bridge[1]_pre_enable
crtc_enable
encoder_enable
bridge[1]_enable
...
bridge[n]__enable
and vice-versa for the bridge chain disable sequence.
The definition of bridge pre_enable hook says that,
"The display pipe (i.e. clocks and timing signals) feeding this bridge
will not yet be running when this callback is called".
Since CRTC is also a source feeding the bridge, it should not be enabled
before the bridges in the pipeline are pre_enabled. Fix that by
re-ordering the sequence of bridge pre_enable and bridge post_disable.
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/drm_atomic_helper.c | 70 +++--
1 file changed, 67 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index fb97b51b38f1..02e093950218 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1186,8 +1186,6 @@ disable_outputs(struct drm_device *dev, struct
drm_atomic_state *old_state)
else if (funcs->dpms)
funcs->dpms(encoder, DRM_MODE_DPMS_OFF);
}
-
- drm_atomic_bridge_chain_post_disable(bridge, old_state);
}
for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
new_crtc_state, i) {
@@ -1234,6 +1232,49 @@ disable_outputs(struct drm_device *dev, struct
drm_atomic_state *old_state)
if (ret == 0)
drm_crtc_vblank_put(crtc);
}
+
+ for_each_oldnew_connector_in_state(old_state, connector, old_conn_state,
+ new_conn_state, i) {
+ struct drm_encoder *encoder;
+ struct drm_bridge *bridge;
+
+ /*
+* Shut down everything that's in the changeset and currently
+* still on. So need to check the old, saved state.
+*/
+ if (!old_conn_state->crtc)
+ continue;
+
+ old_crtc_state = drm_atomic_get_old_crtc_state(old_state,
old_conn_state->crtc);
+
+ if (new_conn_state->crtc)
+ new_crtc_state =
drm_atomic_get_new_crtc_state(old_state,
+
new_conn_state->crtc);
+ else
+ new_crtc_state = NULL;
+
+ if (!crtc_needs_disable(old_crtc_state, new_crtc_state) ||
+ !drm_atomic_crtc_needs_modeset(old_conn_state->crtc->state))
+ continue;
+
+ encoder = old_conn_state->best_encoder;
+
+ /* We shouldn't get this far if we didn't previously have
+* an encoder.. but WARN_ON() rather than explode.
+*/
+ if (WARN_ON(!encoder))
+ continue;
+
+ drm_dbg_atomic(dev, "disabling [ENCODER:%d:%s]\n",
+ encoder->base.id, encoder->name);
+
+ /*
+* Each encoder has at most one connector (since we always steal
+* it away), so we won't call disable hooks twice.
+*/
+ bridge = drm_bridge_chain_get_first_bridge(encoder);
+ drm_atomic_bridge_chain_post_disable(bridge, old_state);
+ }
}
/**
@@ -1469,6 +1510,30 @@ void drm_atomic_helper_commit_modeset_enables(struct
drm_device *dev,
struct drm_connector_state *new_conn_state;
int i;
+ for_each_new_connector_in_state(old_state, connector, new_conn_state,
i) {
+ struct drm_encoder *encoder;
+ struct drm_bridge *bridge;
+
+ if (!new_conn_state->best_encoder)
+ continue;
+
+ if (!new_conn_state->crtc->state->active ||
+ !drm_atomic_crtc_needs_modeset(new_conn_state->crtc->state))
+ continue;
+
+ encoder = new_conn_state->best_encoder;
+
+ drm_dbg_atomic(dev, "enabling [ENCODER:%d:%s]\n",
+ encoder->base.id, encoder->name);
+
+ /*
+* Each encoder has at most one connector (since we always steal
+* it away), so we won't call enable hooks twice.
+*/
+ bridge = drm_bridge_chain_get_first_bridge(encoder);
+ drm_atomic_bridge_chain_pre_enable(bridge, old_state);
+ }
+
for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
new_crtc_state, i) {
const struct drm_crtc_helper_funcs *funcs
[PATCH v2 7/9] drm/bridge: cdns-dsi: Support atomic bridge APIs
Change the existing (and deprecated) bridge hooks, to the bridge
atomic APIs.
Add drm helpers for duplicate_state, destroy_state, and bridge_reset
bridge hooks.
Further add support for the input format negotiation hook.
Signed-off-by: Aradhya Bhatia
---
.../gpu/drm/bridge/cadence/cdns-dsi-core.c| 70 ---
1 file changed, 62 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
index 87fdd07ca0bc..6a2223ecff7d 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -655,7 +656,8 @@ cdns_dsi_bridge_mode_valid(struct drm_bridge *bridge,
return MODE_OK;
}
-static void cdns_dsi_bridge_disable(struct drm_bridge *bridge)
+static void cdns_dsi_bridge_atomic_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
struct cdns_dsi *dsi = input_to_dsi(input);
@@ -675,7 +677,8 @@ static void cdns_dsi_bridge_disable(struct drm_bridge
*bridge)
pm_runtime_put(dsi->base.dev);
}
-static void cdns_dsi_bridge_post_disable(struct drm_bridge *bridge)
+static void cdns_dsi_bridge_atomic_post_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
struct cdns_dsi *dsi = input_to_dsi(input);
@@ -752,7 +755,8 @@ static void cdns_dsi_init_link(struct cdns_dsi *dsi)
dsi->link_initialized = true;
}
-static void cdns_dsi_bridge_enable(struct drm_bridge *bridge)
+static void cdns_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
struct cdns_dsi *dsi = input_to_dsi(input);
@@ -903,7 +907,8 @@ static void cdns_dsi_bridge_enable(struct drm_bridge
*bridge)
writel(tmp, dsi->regs + MCTL_MAIN_EN);
}
-static void cdns_dsi_bridge_pre_enable(struct drm_bridge *bridge)
+static void cdns_dsi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
struct cdns_dsi *dsi = input_to_dsi(input);
@@ -915,13 +920,62 @@ static void cdns_dsi_bridge_pre_enable(struct drm_bridge
*bridge)
cdns_dsi_hs_init(dsi);
}
+static u32 *cdns_dsi_bridge_get_input_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state
*bridge_state,
+ struct drm_crtc_state
*crtc_state,
+ struct drm_connector_state
*conn_state,
+ u32 output_fmt,
+ unsigned int *num_input_fmts)
+{
+ struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
+ struct cdns_dsi *dsi = input_to_dsi(input);
+ struct cdns_dsi_output *output = >output;
+ u32 *input_fmts;
+
+ *num_input_fmts = 0;
+
+ input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+
+ switch (output->dev->format) {
+ case MIPI_DSI_FMT_RGB888:
+ input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+ break;
+
+ case MIPI_DSI_FMT_RGB666:
+ input_fmts[0] = MEDIA_BUS_FMT_RGB666_1X24_CPADHI;
+ break;
+
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ input_fmts[0] = MEDIA_BUS_FMT_RGB666_1X18;
+ break;
+
+ case MIPI_DSI_FMT_RGB565:
+ input_fmts[0] = MEDIA_BUS_FMT_RGB565_1X16;
+ break;
+
+ default:
+ /* Unsupported DSI Format */
+ return NULL;
+ }
+
+ *num_input_fmts = 1;
+
+ return input_fmts;
+}
+
static const struct drm_bridge_funcs cdns_dsi_bridge_funcs = {
.attach = cdns_dsi_bridge_attach,
.mode_valid = cdns_dsi_bridge_mode_valid,
- .disable = cdns_dsi_bridge_disable,
- .pre_enable = cdns_dsi_bridge_pre_enable,
- .enable = cdns_dsi_bridge_enable,
- .post_disable = cdns_dsi_bridge_post_disable,
+ .atomic_disable = cdns_dsi_bridge_atomic_disable,
+ .atomic_pre_enable = cdns_dsi_bridge_atomic_pre_enable,
+ .atomic_enable = cdns_dsi_bridge_atomic_enable,
+ .atomic_post_disable = cdns_dsi_bridge_atomic_post_disable,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .at
[PATCH v2 4/9] drm/bridge: cdns-dsi: Fix the clock variable for mode_valid()
Allow the D-Phy config checks to use mode->clock instead of
mode->crtc_clock during mode_valid checks, like everywhere else in the
driver.
Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework")
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
index 371a3453970c..557b037bbc67 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
@@ -574,7 +574,7 @@ static int cdns_dsi_check_conf(struct cdns_dsi *dsi,
if (ret)
return ret;
- phy_mipi_dphy_get_default_config(mode->crtc_clock * 1000,
+ phy_mipi_dphy_get_default_config((mode_valid_check ? mode->clock :
mode->crtc_clock) * 1000,
mipi_dsi_pixel_format_to_bpp(output->dev->format),
nlanes, phy_cfg);
--
2.34.1
[PATCH v2 5/9] drm/bridge: cdns-dsi: Wait for Clk and Data Lanes to be ready
Once the DSI Link and DSI Phy are initialized, the code needs to wait
for Clk and Data Lanes to be ready, before continuing configuration.
This is in accordance with the DSI Start-up procedure, found in the
Technical Reference Manual of Texas Instrument's J721E SoC[0] which
houses this DSI TX controller.
If the previous bridge (or crtc/encoder) are configured pre-maturely,
the input signal FIFO gets corrupt. This introduces a color-shift on the
display.
Allow the driver to wait for the clk and data lanes to get ready during
DSI enable.
[0]: See section 12.6.5.7.3 "Start-up Procedure" in J721E SoC TRM
TRM Link: http://www.ti.com/lit/pdf/spruil1
Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver")
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
index 557b037bbc67..05d2f4cc50da 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
@@ -761,7 +761,7 @@ static void cdns_dsi_bridge_enable(struct drm_bridge
*bridge)
struct phy_configure_opts_mipi_dphy *phy_cfg =
>phy_opts.mipi_dphy;
unsigned long tx_byte_period;
struct cdns_dsi_cfg dsi_cfg;
- u32 tmp, reg_wakeup, div;
+ u32 tmp, reg_wakeup, div, status;
int nlanes;
if (WARN_ON(pm_runtime_get_sync(dsi->base.dev) < 0))
@@ -778,6 +778,17 @@ static void cdns_dsi_bridge_enable(struct drm_bridge
*bridge)
cdns_dsi_init_link(dsi);
cdns_dsi_hs_init(dsi);
+ /*
+* Now that the DSI Link and DSI Phy are initialized,
+* wait for the CLK and Data Lanes to be ready.
+*/
+ tmp = CLK_LANE_RDY;
+ for (int i = 0; i < nlanes; i++)
+ tmp |= DATA_LANE_RDY(i);
+
+ WARN_ON_ONCE(readl_poll_timeout(dsi->regs + MCTL_MAIN_STS, status,
+ status & tmp, 100, 0));
+
writel(HBP_LEN(dsi_cfg.hbp) | HSA_LEN(dsi_cfg.hsa),
dsi->regs + VID_HSIZE1);
writel(HFP_LEN(dsi_cfg.hfp) | HACT_LEN(dsi_cfg.hact),
--
2.34.1
[PATCH v2 1/9] drm/bridge: cdns-dsi: Fix OF node pointer
Fix the OF node pointer passed to the of_drm_find_bridge() call to find
the next bridge in the display chain.
Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver")
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
index 7457d38622b0..b016f2ba06bb 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
@@ -952,7 +952,7 @@ static int cdns_dsi_attach(struct mipi_dsi_host *host,
bridge = drm_panel_bridge_add_typed(panel,
DRM_MODE_CONNECTOR_DSI);
} else {
- bridge = of_drm_find_bridge(dev->dev.of_node);
+ bridge = of_drm_find_bridge(np);
if (!bridge)
bridge = ERR_PTR(-EINVAL);
}
--
2.34.1
[PATCH v2 0/9] drm/bridge: cdns-dsi: Fix the color-shift issue
Hello all, This series provides some crucial fixes and improvements for the Cadence's DSI TX (cdns-dsi) controller found commonly in Texas Instruments' J7 family of SoCs as well as in AM62P. Along with that, this series aims to fix the color-shift issue that has been going on with the DSI controller. This controller requires to be enabled before the previous entity enables its stream[0]. It's a strict requirement which, if not followed, causes the colors to "shift" on the display. The fix happens in 2 steps. 1. The bridge pre_enable calls have been shifted before the crtc_enable and the bridge post_disable calls have been shifted after the crtc_disable. This has been done as per the definition of bridge pre_enable. "The display pipe (i.e. clocks and timing signals) feeding this bridge will not yet be running when this callback is called". Since CRTC is also a source feeding the bridge, it should not be enabled before the bridges in the pipeline are pre_enabled. The sequence of enable after this patch will look like: bridge[n]_pre_enable ... bridge[1]_pre_enable crtc_enable encoder_enable bridge[1]_enable ... bridge[n]_enable and vice-versa for the bridge chain disable sequence. 2. The cdns-dsi enable / disable sequences have now been moved to pre_enable and post_disable sequences. This is the only way to have cdns-dsi drivers be up and ready before the previous entity is enables its streaming. The DSI also spec requires the Clock and Data Lanes be ready before the DSI TX enables its stream[0]. A patch has been added to make the code wait for that to happen. Going ahead with further DSI (and DSS configuration), while the lanes are not ready, has been found to be another reason for shift in colors. All these patches have been tested on TI's vendor tree kernel with more devices, but for the mainline, these patches have been tested with J721E based BeagleboneAI64 along with a RaspberryPi 7" DSI panel. The extra patches can be found in the "next_dsi-v2-tests" branch of my github fork[1] for anyone who would like to test them. Thanks, Aradhya [0]: Section 12.6.5.7.3: "Start-up Procedure" [For DSI TX controller] in TDA4VM Technical Reference Manual https://www.ti.com/lit/zip/spruil1 [1]: https://github.com/aradhya07/linux-ab/tree/next_dsi-v2-tests Change Log: - Changes in v2: - Drop patch "drm/tidss: Add CRTC mode_fixup" - Split patch "drm/bridge: cdns-dsi: Fix minor bugs" into 4 separate ones - Drop support for early_enable/late_disable APIs and instead re-order the pre_enable / post_disable APIs to be called before / after crtc_enable / crtc_disable. - Drop support for early_enable/late_disable in cdns-dsi and use pre_enable/post_disable APIs instead to do bridge enable/disable. Previous versions: v1: https://lore.kernel.org/all/20240511153051.1355825-1-a-bhat...@ti.com/ Aradhya Bhatia (9): drm/bridge: cdns-dsi: Fix OF node pointer drm/bridge: cdns-dsi: Fix the phy_initialized variable drm/bridge: cdns-dsi: Fix the link and phy init order drm/bridge: cdns-dsi: Fix the clock variable for mode_valid() drm/bridge: cdns-dsi: Wait for Clk and Data Lanes to be ready drm/bridge: cdns-dsi: Reset the DCS write FIFO drm/bridge: cdns-dsi: Support atomic bridge APIs drm/atomic-helper: Re-order bridge chain pre-enable and post-disable drm/bridge: cdns-dsi: Use pre_enable/post_disable to enable/disable .../gpu/drm/bridge/cadence/cdns-dsi-core.c| 91 ++- drivers/gpu/drm/drm_atomic_helper.c | 70 +- 2 files changed, 135 insertions(+), 26 deletions(-) base-commit: 9d99040b1bc8dbf385a8aa535e9efcdf94466e19 -- 2.34.1
[PATCH v2 3/9] drm/bridge: cdns-dsi: Fix the link and phy init order
The order of init of DSI link and DSI phy is wrong. The DSI link needs
to be configured before the DSI phy is getting configured. Otherwise,
the D-Phy is unable to lock in on the incoming PLL Reference clock[0].
Fix the order of inits.
[0]: See section 12.6.5.7.3 "Start-up Procedure" in J721E SoC TRM
TRM Link: http://www.ti.com/lit/pdf/spruil1
Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework")
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
index 42565e253b2d..371a3453970c 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
@@ -775,8 +775,8 @@ static void cdns_dsi_bridge_enable(struct drm_bridge
*bridge)
WARN_ON_ONCE(cdns_dsi_check_conf(dsi, mode, _cfg, false));
- cdns_dsi_hs_init(dsi);
cdns_dsi_init_link(dsi);
+ cdns_dsi_hs_init(dsi);
writel(HBP_LEN(dsi_cfg.hbp) | HSA_LEN(dsi_cfg.hsa),
dsi->regs + VID_HSIZE1);
--
2.34.1
[PATCH v2 2/9] drm/bridge: cdns-dsi: Fix the phy_initialized variable
Update the Phy initialized state to "not initialized" when the driver
(and the hardware by extension) gets suspended. This will allow the Phy
to get initialized again after resume.
Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver")
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
index b016f2ba06bb..42565e253b2d 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
@@ -1153,6 +1153,7 @@ static int __maybe_unused cdns_dsi_suspend(struct device
*dev)
clk_disable_unprepare(dsi->dsi_p_clk);
reset_control_assert(dsi->dsi_p_rst);
dsi->link_initialized = false;
+ dsi->phy_initialized = false;
return 0;
}
--
2.34.1
Re: [PATCH 6/7] drm/bridge: Introduce early_enable and late disable
Hi Maxime,
On 21/05/24 18:45, Maxime Ripard wrote:
> Hi,
>
> On Thu, May 16, 2024 at 03:10:15PM GMT, Aradhya Bhatia wrote:
>>>>/**
>>>> * @pre_enable:
>>>> *
>>>> @@ -285,6 +319,26 @@ struct drm_bridge_funcs {
>>>> */
>>>>void (*enable)(struct drm_bridge *bridge);
>>>>
>>>> + /**
>>>> + * @atomic_early_enable:
>>>> + *
>>>> + * This callback should enable the bridge. It is called right before
>>>> + * the preceding element in the display pipe is enabled. If the
>>>> + * preceding element is a bridge this means it's called before that
>>>> + * bridge's @atomic_early_enable. If the preceding element is a
>>>> + * _crtc it's called right before the crtc's
>>>> + * _crtc_helper_funcs.atomic_enable hook.
>>>> + *
>>>> + * The display pipe (i.e. clocks and timing signals) feeding this bridge
>>>> + * will not yet be running when this callback is called. The bridge can
>>>> + * enable the display link feeding the next bridge in the chain (if
>>>> + * there is one) when this callback is called.
>>>> + *
>>>> + * The @early_enable callback is optional.
>>>> + */
>>>> + void (*atomic_early_enable)(struct drm_bridge *bridge,
>>>> + struct drm_bridge_state *old_bridge_state);
>>>> +
>>>>/**
>>>> * @atomic_pre_enable:
>>>> *
>>>> @@ -361,6 +415,21 @@ struct drm_bridge_funcs {
>>>>void (*atomic_post_disable)(struct drm_bridge *bridge,
>>>>struct drm_bridge_state *old_bridge_state);
>>>>
>>>> + /**
>>>> + * @atomic_late_disable:
>>>> + *
>>>> + * This callback should disable the bridge. It is called right after the
>>>> + * preceding element in the display pipe is disabled. If the preceding
>>>> + * element is a bridge this means it's called after that bridge's
>>>> + * @atomic_late_disable. If the preceding element is a _crtc it's
>>>> + * called right after the crtc's _crtc_helper_funcs.atomic_disable
>>>> + * hook.
>>>> + *
>>>> + * The @atomic_late_disable callback is optional.
>>>> + */
>>>> + void (*atomic_late_disable)(struct drm_bridge *bridge,
>>>> + struct drm_bridge_state *old_bridge_state);
>>>> +
>>>
>>> But more importantly, I don't quite get the use case you're trying to
>>> solve here.
>>>
>>> If I got the rest of your series, the Cadence DSI bridge needs to be
>>> powered up before its source is started. You can't use atomic_enable or
>>> atomic_pre_enable because it would start the source before the DSI
>>> bridge. Is that correct?
>>>
>>
>> That's right. I cannot use bridge_atomic_pre_enable /
>> bridge_atomic_enable here. But that's because my source is CRTC, which
>> gets enabled via crtc_atomic_enable.
>>
>>
>>> If it is, then how is it different from what
>>> drm_atomic_bridge_chain_pre_enable is doing? The assumption there is
>>> that it starts enabling bridges last to first, to it should be enabled
>>> before anything starts.
>>>
>>> The whole bridge enabling order code starts to be a bit of a mess, so it
>>> would be great if you could list all the order variations we have
>>> currently, and why none work for cdns-dsi.
>>>
>>
>> Of course! I can elaborate on the order.
>>
>> Without my patches (and given there isn't any bridge setting the
>> "pre_enable_prev_first" flag) the order of enable for any single display
>> chain, looks like this -
>>
>> crtc_enable
>>
>> bridge[n]_pre_enable
>> ---
>> bridge[1]_pre_enable
>>
>> encoder_enable
>>
>> bridge[1]_enable
>> ---
>> bridge[n]_enable
>>
>> The tidss enables at the crtc_enable level, and hence is the first
>> entity with stream on. cdns-dsi doesn't stand a chance with
>> bridge_atmoic_pre_enable / bridge_atmoic_enable hooks. And there is no
>> bridge call happening before crtc currently.
>
> Thanks for filling the blanks :)
>
> I assume that since cdns-dsi is a bridge, and it only has a simple
> encoder implementation, for it to receive some video signal we need to
>
Re: [PATCH v3 3/6] dt-bindings: display: simple: Add Microtips & Lincolntech Dual-LVDS Panels
Hi Liu, Thanks for reviewing the patch. On 16/05/24 07:49, Liu Ying wrote: > On 5/15/24 17:51, Aradhya Bhatia wrote: >> Add the Microtips Technology USA's MF-101HIEBCAF0 10.1"[0] panel, >> MF-103HIEB0GA0 10.25"[1] panel, and Lincoln Technology Solutions' >> LCD185-101CT 10.1"[2] panel. >> >> Thes are all dual-lvds panels. >> >> Panel Links: >> [0]: >> https://simplespec.microtipsusa.com/uploads/spec/datasheetFile/2588/13-101HIEBCAF0-S_V1.1_20221104.pdf >> [1]: >> https://simplespec.microtipsusa.com/uploads/spec/datasheetFile/2660/13-103HIEB0GA0-S_V1.0_20211206.pdf > > This one mentions some controls in '3. PIN DESCRIPTION' which > don't comply with this binding, like RL, TB, STBYB and RESET. > Note this binding only allows compatible, ports, backlight, > enable-gpios and power-supply properties, nothing more. > Maybe the internal module _can_ support these control options but the actual panel hardware does not expose any of these controls on its connector pin-out, and hence has no possibility for additional SW control. Even for the usage, the device-tree node for the panel only has "compatible" and "ports" properties defined. The panel is being used within the confines of a simple panel. Regards Aradhya > >> [2]: >> https://lincolntechsolutions.com/wp-content/uploads/2023/04/LCD185-101CTL1ARNTT_DS_R1.3.pdf >> >> Signed-off-by: Aradhya Bhatia >> --- >> .../display/panel/panel-simple-lvds-dual-ports.yaml | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git >> a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml >> >> b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml >> index 716ece5f3978..e78160d1aa24 100644 >> --- >> a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml >> +++ >> b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml >> @@ -41,6 +41,12 @@ properties: >>- auo,g190ean01 >> # Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS >> TFT LCD panel >>- koe,tx26d202vm0bwa >> +# Lincoln Technology Solutions, LCD185-101CT 10.1" TFT 1920x1200 >> + - lincolntech,lcd185-101ct >> +# Microtips Technology MF-101HIEBCAF0 10.1" WUXGA (1920x1200) TFT >> LCD panel >> + - microtips,mf-101hiebcaf0 >> +# Microtips Technology MF-103HIEB0GA0 10.25" 1920x720 TFT LCD panel >> + - microtips,mf-103hieb0ga0 >> # NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel >>- nlt,nl192108ac18-02d >> >
Re: [PATCH 1/7] drm/tidss: Add CRTC mode_fixup
Hi Maxime,
Thank you for reviewing the patches.
On 16/05/24 13:40, Maxime Ripard wrote:
> Hi,
>
> On Sat, May 11, 2024 at 09:00:45PM +0530, Aradhya Bhatia wrote:
>> Add support for mode_fixup for the tidss CRTC.
>>
>> Some bridges like the cdns-dsi consume the crtc_* timing parameters for
>> programming the blanking values. Allow for the normal timing parameters
>> to get copied to crtc_* timing params.
>>
>> Signed-off-by: Aradhya Bhatia
>> ---
>> drivers/gpu/drm/tidss/tidss_crtc.c | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c
>> b/drivers/gpu/drm/tidss/tidss_crtc.c
>> index 94f8e3178df5..797ef53d9ad2 100644
>> --- a/drivers/gpu/drm/tidss/tidss_crtc.c
>> +++ b/drivers/gpu/drm/tidss/tidss_crtc.c
>> @@ -309,12 +309,23 @@ enum drm_mode_status tidss_crtc_mode_valid(struct
>> drm_crtc *crtc,
>> return dispc_vp_mode_valid(tidss->dispc, tcrtc->hw_videoport, mode);
>> }
>>
>> +static
>> +bool tidss_crtc_mode_fixup(struct drm_crtc *crtc,
>> + const struct drm_display_mode *mode,
>> + struct drm_display_mode *adjusted_mode)
>> +{
>> +drm_mode_set_crtcinfo(adjusted_mode, 0);
>> +
>> +return true;
>> +}
>> +
>> static const struct drm_crtc_helper_funcs tidss_crtc_helper_funcs = {
>> .atomic_check = tidss_crtc_atomic_check,
>> .atomic_flush = tidss_crtc_atomic_flush,
>> .atomic_enable = tidss_crtc_atomic_enable,
>> .atomic_disable = tidss_crtc_atomic_disable,
>>
>> +.mode_fixup = tidss_crtc_mode_fixup,
>> .mode_valid = tidss_crtc_mode_valid,
>> };
>
> mode_fixup is deprecated for atomic drivers, so the solution must be
> different there.
>
> It's also not clear to me how it could change anything there:
> drm_mode_set_crtcinfo with no flags will make crtc_* field exactly
> identical to their !crtc counterparts.
>
I checked the flag options. There isn't any flag required. The only
reason to add this call is because cdns-dsi strictly requires the crtc_*
fields to be populated during the bridge enable.
Secondly, if mode_fixup is deprecated, I think the crtc_atomic_check
would be the next best place to add this call.
Regards
Aradhya
Re: [PATCH 2/7] drm/bridge: cdns-dsi: Fix minor bugs
On 16/05/24 13:41, Maxime Ripard wrote: > On Sat, May 11, 2024 at 09:00:46PM +0530, Aradhya Bhatia wrote: >> Update the Phy initialized state to "not initialized" when the driver >> (and the hardware by extension) gets suspended. This will allow the Phy >> to get initialized again after resume. >> >> Fix the OF node that gets passed to find the next available bridge in >> the display pipeline. >> >> Fix the order of DSI Link and DSI Phy inits. The link init needs to >> happen before the Phy is initialized, so the Phy can lock on the >> incoming PLL reference clock. If this doesn't happen, the Phy cannot >> lock (until DSI Link is init later on). This causes a warning dump >> during the kernel boot. >> >> Allow the D-Phy config checks to use mode->clock instead of >> mode->crtc_clock during mode_valid checks, like everywhere else in the >> driver. > > All these should be in separate patches. > Alright! I will split them into different patches in v2. Regards Aradhya
Re: [PATCH 6/7] drm/bridge: Introduce early_enable and late disable
Hi Maxime,
Thank you for reviewing the patches!
On 16/05/24 13:52, Maxime Ripard wrote:
> On Sat, May 11, 2024 at 09:00:50PM +0530, Aradhya Bhatia wrote:
>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>> index 4baca0d9107b..40f93230abb2 100644
>> --- a/include/drm/drm_bridge.h
>> +++ b/include/drm/drm_bridge.h
>> @@ -206,6 +206,20 @@ struct drm_bridge_funcs {
>> */
>> void (*post_disable)(struct drm_bridge *bridge);
>>
>> +/**
>> + * @late_disable:
>> + *
>> + * This callback should disable the bridge. It is called right after the
>> + * preceding element in the display pipe is disabled. If the preceding
>> + * element is a bridge this means it's called after that bridge's
>> + * @atomic_post_disable. If the preceding element is a _crtc it's
>> + * called right after the crtc's _crtc_helper_funcs.atomic_disable
>> + * hook.
>> + *
>> + * The @late_disable callback is optional.
>> + */
>> +void (*late_disable)(struct drm_bridge *bridge);
>> +
>> /**
>> * @mode_set:
>> *
>> @@ -235,6 +249,26 @@ struct drm_bridge_funcs {
>> void (*mode_set)(struct drm_bridge *bridge,
>> const struct drm_display_mode *mode,
>> const struct drm_display_mode *adjusted_mode);
>> +
>> +/**
>> + * @early_enable:
>> + *
>> + * This callback should enable the bridge. It is called right before
>> + * the preceding element in the display pipe is enabled. If the
>> + * preceding element is a bridge this means it's called before that
>> + * bridge's @early_enable. If the preceding element is a _crtc it's
>> + * called right before the crtc's _crtc_helper_funcs.atomic_enable
>> + * hook.
>> + *
>> + * The display pipe (i.e. clocks and timing signals) feeding this bridge
>> + * will not yet be running when this callback is called. The bridge can
>> + * enable the display link feeding the next bridge in the chain (if
>> + * there is one) when this callback is called.
>> + *
>> + * The @early_enable callback is optional.
>> + */
>> +void (*early_enable)(struct drm_bridge *bridge);
>> +
>
> You don't need the legacy option here, just go straight for the atomic one.
Got it! I can remove these in v2.
>
>> /**
>> * @pre_enable:
>> *
>> @@ -285,6 +319,26 @@ struct drm_bridge_funcs {
>> */
>> void (*enable)(struct drm_bridge *bridge);
>>
>> +/**
>> + * @atomic_early_enable:
>> + *
>> + * This callback should enable the bridge. It is called right before
>> + * the preceding element in the display pipe is enabled. If the
>> + * preceding element is a bridge this means it's called before that
>> + * bridge's @atomic_early_enable. If the preceding element is a
>> + * _crtc it's called right before the crtc's
>> + * _crtc_helper_funcs.atomic_enable hook.
>> + *
>> + * The display pipe (i.e. clocks and timing signals) feeding this bridge
>> + * will not yet be running when this callback is called. The bridge can
>> + * enable the display link feeding the next bridge in the chain (if
>> + * there is one) when this callback is called.
>> + *
>> + * The @early_enable callback is optional.
>> + */
>> +void (*atomic_early_enable)(struct drm_bridge *bridge,
>> +struct drm_bridge_state *old_bridge_state);
>> +
>> /**
>> * @atomic_pre_enable:
>> *
>> @@ -361,6 +415,21 @@ struct drm_bridge_funcs {
>> void (*atomic_post_disable)(struct drm_bridge *bridge,
>> struct drm_bridge_state *old_bridge_state);
>>
>> +/**
>> + * @atomic_late_disable:
>> + *
>> + * This callback should disable the bridge. It is called right after the
>> + * preceding element in the display pipe is disabled. If the preceding
>> + * element is a bridge this means it's called after that bridge's
>> + * @atomic_late_disable. If the preceding element is a _crtc it's
>> + * called right after the crtc's _crtc_helper_funcs.atomic_disable
>> + * hook.
>> + *
>> + * The @atomic_late_disable callback is optional.
>> + */
>> +void (*atomic_late_disable)(struct drm_bridge *bridge,
>> +struct drm_bridge_state *old_bridge_sta
[PATCH v3 6/6] drm/panel: simple: Add Microtips Technology MF-103HIEB0GA0 panel
Add support for Microtips Technology USA MF-103HIEB0GA0 10.25"[0],
1920x720, 8-bit TFT LCD with LVDS interface. Its a Dual-LVDS Panel and
does not support touch.
[0]: Panel Datasheet
https://simplespec.microtipsusa.com/uploads/spec/datasheetFile/2660/13-103HIEB0GA0-S_V1.0_20211206.pdf
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/panel/panel-simple.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 3a0d8f0ff267..1b0a6b4e034c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3084,6 +3084,35 @@ static const struct panel_desc
microtips_mf_101hiebcaf0_c = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct drm_display_mode microtips_mf_103hieb0ga0_mode = {
+ .clock = 93301,
+ .hdisplay = 1920,
+ .hsync_start = 1920 + 72,
+ .hsync_end = 1920 + 72 + 72,
+ .htotal = 1920 + 72 + 72 + 72,
+ .vdisplay = 720,
+ .vsync_start = 720 + 3,
+ .vsync_end = 720 + 3 + 3,
+ .vtotal = 720 + 3 + 3 + 2,
+};
+
+static const struct panel_desc microtips_mf_103hieb0ga0 = {
+ .modes = _mf_103hieb0ga0_mode,
+ .bpc = 8,
+ .num_modes = 1,
+ .size = {
+ .width = 244,
+ .height = 92,
+ },
+ .delay = {
+ .prepare = 50,
+ .disable = 50,
+ },
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct drm_display_mode mitsubishi_aa070mc01_mode = {
.clock = 30400,
.hdisplay = 800,
@@ -4726,6 +4755,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "microtips,mf-101hiebcaf0",
.data = _mf_101hiebcaf0_c,
+ }, {
+ .compatible = "microtips,mf-103hieb0ga0",
+ .data = _mf_103hieb0ga0,
}, {
.compatible = "mitsubishi,aa070mc01-ca1",
.data = _aa070mc01,
--
2.34.1
[PATCH v3 4/6] drm/panel: simple: Add Lincoln Tech Sol LCD185-101CT panel
Add support for Lincoln Technology Solutions LCD185-101CT, 10.1",
1920x1200, 8-bit TFT LCD with LVDS interface, LED backlight and PCAP
touch support (Goodix GT928).
[0]: Panel Datasheet
https://lincolntechsolutions.com/wp-content/uploads/2023/04/LCD185-101CTL1ARNTT_DS_R1.3.pdf
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/panel/panel-simple.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index dcb6d0b6ced0..10e974bffd28 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2870,6 +2870,35 @@ static const struct panel_desc lg_lb070wv8 = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct drm_display_mode lincolntech_lcd185_101ct_mode = {
+ .clock = 155127,
+ .hdisplay = 1920,
+ .hsync_start = 1920 + 128,
+ .hsync_end = 1920 + 128 + 20,
+ .htotal = 1920 + 128 + 20 + 12,
+ .vdisplay = 1200,
+ .vsync_start = 1200 + 19,
+ .vsync_end = 1200 + 19 + 4,
+ .vtotal = 1200 + 19 + 4 + 20,
+};
+
+static const struct panel_desc lincolntech_lcd185_101ct = {
+ .modes = _lcd185_101ct_mode,
+ .bpc = 8,
+ .num_modes = 1,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+ .delay = {
+ .prepare = 50,
+ .disable = 50,
+ },
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct display_timing logictechno_lt161010_2nh_timing = {
.pixelclock = { 2640, 3330, 4680 },
.hactive = { 800, 800, 800 },
@@ -4644,6 +4673,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "lg,lb070wv8",
.data = _lb070wv8,
+ }, {
+ .compatible = "lincolntech,lcd185-101ct",
+ .data = _lcd185_101ct,
}, {
.compatible = "logicpd,type28",
.data = _type_28,
--
2.34.1
[PATCH v3 2/6] dt-bindings: vendor-prefixes: Add lincolntech
Add document vendor prefix for Lincoln Technology Solutions (lincolntech). Signed-off-by: Aradhya Bhatia Acked-by: Krzysztof Kozlowski Reviewed-by: Laurent Pinchart --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index afebaf8e62bb..51ca841db26e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -820,6 +820,8 @@ patternProperties: description: Lichee Pi "^linaro,.*": description: Linaro Limited + "^lincolntech,.*": +description: Lincoln Technology Solutions "^lineartechnology,.*": description: Linear Technology "^linksprite,.*": -- 2.34.1
[PATCH v3 5/6] drm/panel: simple: Add Microtips Technology 13-101HIEBCAF0-C panel
Add support for Microtips Technology USA 13-101HIECAF0-C 10.1",
1920x1200, 8-bit TFT LCD with LVDS interface, LED backlight and touch
support (ILITEK 2511).
[0]: Panel Datasheet
https://simplespec.microtipsusa.com/uploads/spec/datasheetFile/2588/13-101HIEBCAF0-S_V1.1_20221104.pdf
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/panel/panel-simple.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 10e974bffd28..3a0d8f0ff267 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3055,6 +3055,35 @@ static const struct panel_desc logicpd_type_28 = {
.connector_type = DRM_MODE_CONNECTOR_DPI,
};
+static const struct drm_display_mode microtips_mf_101hiebcaf0_c_mode = {
+ .clock = 150275,
+ .hdisplay = 1920,
+ .hsync_start = 1920 + 32,
+ .hsync_end = 1920 + 32 + 52,
+ .htotal = 1920 + 32 + 52 + 24,
+ .vdisplay = 1200,
+ .vsync_start = 1200 + 24,
+ .vsync_end = 1200 + 24 + 8,
+ .vtotal = 1200 + 24 + 8 + 3,
+};
+
+static const struct panel_desc microtips_mf_101hiebcaf0_c = {
+ .modes = _mf_101hiebcaf0_c_mode,
+ .bpc = 8,
+ .num_modes = 1,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+ .delay = {
+ .prepare = 50,
+ .disable = 50,
+ },
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct drm_display_mode mitsubishi_aa070mc01_mode = {
.clock = 30400,
.hdisplay = 800,
@@ -4694,6 +4723,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "logictechno,lttd800480070-l6wh-rt",
.data = _lttd800480070_l6wh_rt,
+ }, {
+ .compatible = "microtips,mf-101hiebcaf0",
+ .data = _mf_101hiebcaf0_c,
}, {
.compatible = "mitsubishi,aa070mc01-ca1",
.data = _aa070mc01,
--
2.34.1
[PATCH v3 3/6] dt-bindings: display: simple: Add Microtips & Lincolntech Dual-LVDS Panels
Add the Microtips Technology USA's MF-101HIEBCAF0 10.1"[0] panel, MF-103HIEB0GA0 10.25"[1] panel, and Lincoln Technology Solutions' LCD185-101CT 10.1"[2] panel. Thes are all dual-lvds panels. Panel Links: [0]: https://simplespec.microtipsusa.com/uploads/spec/datasheetFile/2588/13-101HIEBCAF0-S_V1.1_20221104.pdf [1]: https://simplespec.microtipsusa.com/uploads/spec/datasheetFile/2660/13-103HIEB0GA0-S_V1.0_20211206.pdf [2]: https://lincolntechsolutions.com/wp-content/uploads/2023/04/LCD185-101CTL1ARNTT_DS_R1.3.pdf Signed-off-by: Aradhya Bhatia --- .../display/panel/panel-simple-lvds-dual-ports.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml index 716ece5f3978..e78160d1aa24 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml @@ -41,6 +41,12 @@ properties: - auo,g190ean01 # Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT LCD panel - koe,tx26d202vm0bwa +# Lincoln Technology Solutions, LCD185-101CT 10.1" TFT 1920x1200 + - lincolntech,lcd185-101ct +# Microtips Technology MF-101HIEBCAF0 10.1" WUXGA (1920x1200) TFT LCD panel + - microtips,mf-101hiebcaf0 +# Microtips Technology MF-103HIEB0GA0 10.25" 1920x720 TFT LCD panel + - microtips,mf-103hieb0ga0 # NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel - nlt,nl192108ac18-02d -- 2.34.1
[PATCH v3 1/6] dt-bindings: vendor-prefixes: Add microtips
Add document vendor prefix for Microtips Technology USA (microtips). Signed-off-by: Aradhya Bhatia Acked-by: Krzysztof Kozlowski Reviewed-by: Laurent Pinchart --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index fbf47f0bacf1..afebaf8e62bb 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -924,6 +924,8 @@ patternProperties: description: Microsoft Corporation "^microsys,.*": description: MicroSys Electronics GmbH + "^microtips,.*": +description: Microtips Technology USA "^mikroe,.*": description: MikroElektronika d.o.o. "^mikrotik,.*": -- 2.34.1
[PATCH v3 0/6] drm/panel: simple: Add Panels and Panel Vendors
Hi all, Picking up this long-standing series which added support for Microtips' and LincolnTech's dual-lvds panels. Microtips Technology Solutions USA, and Lincoln Technology Solutions are 2 display panel vendors, and the patches 1/6 and 2/6 add their vendor prefixes. Patch 3/6 adds panel specific compatibles to the binding for simple panels with 2 lvds ports. Lastly, patches 4/6 through 6/6 add the timing parameters and the compatibles in the panel-simple driver file. This series has changed from v2 in that it is not trying to add a new schema for panel-dual-lvds anymore. There is no requirement for that today. So patches 3/4 and 4/4 from v2 have completely been dropped. And in their place, have come new patches - 3/6 through 6/6. Patches 1/4 and 2/4 from v2 are now 1/6 and 2/6 respectively, and I have carried the tags provided by Laurent Pinchart and Krzysztof Kozlowski. Regards Aradhya Changes in V3: == - Drop the schema for "panel-dual-lvds". - Instead add the panels under schema for simple panels with dual ports. - Add support for these panels in panel-simple driver. Changes in V2: == - Rebased to latest linux-next. - Made dt-binding syntax corrections in Patch 3/4, based on comments by Krzysztof Kozlowski and Laurent Pinchart. V2: https://lore.kernel.org/all/20230124101238.4542-1-a-bhat...@ti.com/ V1: https://lore.kernel.org/all/20230103064615.5311-1-a-bhat...@ti.com/ Aradhya Bhatia (6): dt-bindings: vendor-prefixes: Add microtips dt-bindings: vendor-prefixes: Add lincolntech dt-bindings: display: simple: Add Microtips & Lincolntech Dual-LVDS Panels drm/panel: simple: Add Lincoln Tech Sol LCD185-101CT panel drm/panel: simple: Add Microtips Technology 13-101HIEBCAF0-C panel drm/panel: simple: Add Microtips Technology MF-103HIEB0GA0 panel .../panel/panel-simple-lvds-dual-ports.yaml | 6 ++ .../devicetree/bindings/vendor-prefixes.yaml | 4 + drivers/gpu/drm/panel/panel-simple.c | 96 +++ 3 files changed, 106 insertions(+) base-commit: 82d92a9a1b9ea0ea52aff27cddd05009b4edad49 -- 2.34.1
Re: [PATCH 1/4] dt-bindings: display: ti,am65x-dss: Minor Cleanup
On 14/05/24 00:49, Rob Herring wrote: > On Sun, May 12, 2024 at 01:00:52AM +0530, Aradhya Bhatia wrote: >> Reduce tab size from 8 spaces to 4 spaces to make the bindings >> consistent, and easy to expand. > > "Re-indent the example" would be more specific than "minor cleanups" in > the subject. That would be better. Will reword this in v2. Thank you! Regards Aradhya > > Otherwise, > > Acked-by: Rob Herring (Arm) > >> >> Signed-off-by: Aradhya Bhatia >> --- >> .../bindings/display/ti/ti,am65x-dss.yaml | 54 +-- >> 1 file changed, 27 insertions(+), 27 deletions(-) >
Re: [PATCH 3/4] dt-bindings: display: ti,am65x-dss: Add OLDI properties for AM625 DSS
On 14/05/24 01:05, Rob Herring wrote: > On Sun, May 12, 2024 at 01:00:54AM +0530, Aradhya Bhatia wrote: >> The DSS in AM625 SoC has 2 OLDI TXes. Refer the OLDI schema to add the >> properties. >> >> Signed-off-by: Aradhya Bhatia >> --- >> .../bindings/display/ti/ti,am65x-dss.yaml | 136 +- >> 1 file changed, 135 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml >> b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml >> index 399d68986326..4aa2de59b32b 100644 >> --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml >> +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml >> @@ -85,12 +85,30 @@ properties: >> >> properties: >>port@0: >> -$ref: /schemas/graph.yaml#/properties/port >> +$ref: /schemas/graph.yaml#/$defs/port-base > > You don't need this change. You aren't adding any extra properties. Alright. I will make the change. > >> description: >>For AM65x DSS, the OLDI output port node from video port 1. >>For AM625 DSS, the internal DPI output port node from video >>port 1. >>For AM62A7 DSS, the port is tied off inside the SoC. >> +properties: >> + endpoint@0: >> +$ref: /schemas/graph.yaml#/properties/endpoint >> +description: >> + For AM625 DSS, VP Connection to OLDI0. >> + For AM65X DSS, OLDI output from the SoC. >> + >> + endpoint@1: >> +$ref: /schemas/graph.yaml#/properties/endpoint >> +description: >> + For AM625 DSS, VP Connection to OLDI1. >> + >> +anyOf: >> + - required: >> + - endpoint >> + - required: >> + - endpoint@0 >> + - endpoint@1 >> >>port@1: >> $ref: /schemas/graph.yaml#/properties/port >> @@ -112,6 +130,22 @@ properties: >>Input memory (from main memory to dispc) bandwidth limit in >>bytes per second >> >> + oldi-txes: >> +type: object >> +properties: >> + "#address-cells": >> +const: 1 >> + >> + "#size-cells": >> +const: 0 >> + >> +patternProperties: >> + '^oldi_tx@[0-1]$': >> +type: object >> +$ref: ti,am625-oldi.yaml# >> +unevaluatedProperties: false >> +description: OLDI transmitters connected to the DSS VPs > > Connected to is not part of the DSS. I don't think these nodes belong > here as mentioned in the other patch. > Replied to this in patch 2/4 to keep the discussion in one thread. Regards Aradhya
Re: [PATCH 2/4] dt-bindings: display: ti: Add schema for AM625 OLDI Transmitter
Hi Rob, Thank you for reviewing the patches! On 14/05/24 01:00, Rob Herring wrote: > On Mon, May 13, 2024 at 02:07:44PM +0530, Aradhya Bhatia wrote: >> Hi Laurent, >> >> Thank you for reviewing the patches! >> >> On 13-May-24 01:04, Laurent Pinchart wrote: >>> Hi Aradhya, >>> >>> Thank you for the patch. >>> >>> On Sun, May 12, 2024 at 01:00:53AM +0530, Aradhya Bhatia wrote: >>>> Add devicetree binding schema for AM625 OLDI Transmitters. >>>> >>>> Signed-off-by: Aradhya Bhatia >>>> --- >>>> .../bindings/display/ti/ti,am625-oldi.yaml| 153 ++ >>>> MAINTAINERS | 1 + >>>> 2 files changed, 154 insertions(+) >>>> create mode 100644 >>>> Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml >>>> >>>> diff --git >>>> a/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml >>>> b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml >>>> new file mode 100644 >>>> index ..0a96e600bc0b >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml >>>> @@ -0,0 +1,153 @@ >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>> +%YAML 1.2 >>>> +--- >>>> +$id: http://devicetree.org/schemas/display/ti/ti,am625-oldi.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: Texas Instruments AM625 OLDI Transmitter >>>> + >>>> +maintainers: >>>> + - Tomi Valkeinen >>>> + - Aradhya Bhatia >>>> + >>>> +description: | >>>> + The AM625 TI Keystone OpenLDI transmitter (OLDI TX) supports serialized >>>> RGB >>>> + pixel data transmission between host and flat panel display over LVDS >>>> (Low >>>> + Voltage Differential Sampling) interface. The OLDI TX consists of >>>> 7-to-1 data >>>> + serializers, and 4-data and 1-clock LVDS outputs. It supports the LVDS >>>> output >>>> + formats "jeida-18", "jeida-24" and "vesa-18", and can accept 24-bit RGB >>>> or >>>> + padded and un-padded 18-bit RGB bus formats as input. >>>> + >>>> +properties: >>>> + reg: >>>> +maxItems: 1 >>>> + >>>> + clocks: >>>> +maxItems: 1 >>>> +description: serial clock input for the OLDI transmitters >>>> + >>>> + clock-names: >>>> +const: s_clk >>>> + >>>> + ti,companion-oldi: >>>> +$ref: /schemas/types.yaml#/definitions/phandle >>>> +description: >>>> + phandle to companion OLDI transmitter. This property is mandatory >>>> for the >>>> + primarty OLDI TX if the OLDI TXes are expected to work either in >>>> dual-lvds >>>> + mode or in clone mode. This property should point to the secondary >>>> OLDI >>>> + TX. >>>> + >>>> + ti,secondary-oldi: >>>> +type: boolean >>>> +description: Boolean property to mark an OLDI TX as secondary node. >>>> + >>>> + ti,oldi-io-ctrl: >>>> +$ref: /schemas/types.yaml#/definitions/phandle >>>> +description: >>>> + phandle to syscon device node mapping OLDI IO_CTRL registers found >>>> in the >>>> + control MMR region. This property is needed for OLDI interface to >>>> work. >>>> + >>>> + ports: >>>> +$ref: /schemas/graph.yaml#/properties/ports >>>> + >>>> +properties: >>>> + port@0: >>>> +$ref: /schemas/graph.yaml#/properties/port >>>> +description: Parallel RGB input port >>>> + >>>> + port@1: >>>> +$ref: /schemas/graph.yaml#/properties/port >>>> +description: LVDS output port >>>> + >>>> +required: >>>> + - port@0 >>>> + - port@1 >>>> + >>>> +allOf: >>>> + - if: >>>> + properties: >>>> +ti,secondary-oldi: true >>>> +then: >>>> + properties: >>>> +ti,companion-oldi: false >&g
Re: [PATCH 2/4] dt-bindings: display: ti: Add schema for AM625 OLDI Transmitter
Hi Laurent,
Thank you for reviewing the patches!
On 13-May-24 01:04, Laurent Pinchart wrote:
> Hi Aradhya,
>
> Thank you for the patch.
>
> On Sun, May 12, 2024 at 01:00:53AM +0530, Aradhya Bhatia wrote:
>> Add devicetree binding schema for AM625 OLDI Transmitters.
>>
>> Signed-off-by: Aradhya Bhatia
>> ---
>> .../bindings/display/ti/ti,am625-oldi.yaml| 153 ++
>> MAINTAINERS | 1 +
>> 2 files changed, 154 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
>> b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
>> new file mode 100644
>> index ..0a96e600bc0b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
>> @@ -0,0 +1,153 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/ti/ti,am625-oldi.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Texas Instruments AM625 OLDI Transmitter
>> +
>> +maintainers:
>> + - Tomi Valkeinen
>> + - Aradhya Bhatia
>> +
>> +description: |
>> + The AM625 TI Keystone OpenLDI transmitter (OLDI TX) supports serialized
>> RGB
>> + pixel data transmission between host and flat panel display over LVDS (Low
>> + Voltage Differential Sampling) interface. The OLDI TX consists of 7-to-1
>> data
>> + serializers, and 4-data and 1-clock LVDS outputs. It supports the LVDS
>> output
>> + formats "jeida-18", "jeida-24" and "vesa-18", and can accept 24-bit RGB or
>> + padded and un-padded 18-bit RGB bus formats as input.
>> +
>> +properties:
>> + reg:
>> +maxItems: 1
>> +
>> + clocks:
>> +maxItems: 1
>> +description: serial clock input for the OLDI transmitters
>> +
>> + clock-names:
>> +const: s_clk
>> +
>> + ti,companion-oldi:
>> +$ref: /schemas/types.yaml#/definitions/phandle
>> +description:
>> + phandle to companion OLDI transmitter. This property is mandatory for
>> the
>> + primarty OLDI TX if the OLDI TXes are expected to work either in
>> dual-lvds
>> + mode or in clone mode. This property should point to the secondary
>> OLDI
>> + TX.
>> +
>> + ti,secondary-oldi:
>> +type: boolean
>> +description: Boolean property to mark an OLDI TX as secondary node.
>> +
>> + ti,oldi-io-ctrl:
>> +$ref: /schemas/types.yaml#/definitions/phandle
>> +description:
>> + phandle to syscon device node mapping OLDI IO_CTRL registers found in
>> the
>> + control MMR region. This property is needed for OLDI interface to
>> work.
>> +
>> + ports:
>> +$ref: /schemas/graph.yaml#/properties/ports
>> +
>> +properties:
>> + port@0:
>> +$ref: /schemas/graph.yaml#/properties/port
>> +description: Parallel RGB input port
>> +
>> + port@1:
>> +$ref: /schemas/graph.yaml#/properties/port
>> +description: LVDS output port
>> +
>> +required:
>> + - port@0
>> + - port@1
>> +
>> +allOf:
>> + - if:
>> + properties:
>> +ti,secondary-oldi: true
>> +then:
>> + properties:
>> +ti,companion-oldi: false
>> +ti,oldi-io-ctrl: false
>> +clocks: false
>> +clock-names: false
>> +
>> +else:
>> + required:
>> +- ti,oldi-io-ctrl
>> +- clocks
>> +- clock-names
>> +
>> +required:
>> + - reg
>> + - ports
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> +#include
>> +
>> +oldi_txes {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +oldi: oldi@0 {
>> +reg = <0>;
>> +clocks = <_clks 186 0>;
>> +clock-names = "s_clk";
>> +ti,oldi-io-ctrl = <_oldi_io_ctrl>;
>
> What bus does this device live on ? Couldn't the I/O register space be
> referenced by the reg property ?.
>
These registers are a part of the system-controller register space
(ctrl_mmr0). The whole register set is owned by the main_conf[0]
devicetree node, with sub-nodes pointing to specific regions. That's why
I cannot reference these registers directly.
The IO control node for OLDI will look like this though[1].
[0]:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am62-main.dtsi#n45
[1]:
https://github.com/aradhya07/linux-ab/commit/7d7184fb36dc22c67cc2704fe708e885f300860c
>> +ports {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +port@0 {
>> +reg = <0>;
>> +oldi_in: endpoint {
>> +remote-endpoint = <_out>;
>> +};
>> +};
>> +};
>> +};
>> +};
>> +
>
[ ... ]
--
Regards
Aradhya
Re: [PATCH 4/4] drm/tidss: Add OLDI bridge support
Hi Francesco,
On 12/05/24 17:18, Francesco Dolcini wrote:
> Hello Aradhya, thanks for you patch, I should be able to test your patch on my
> hardware in the coming days.
That's appreciated. Thank you! =)
>
> On Sun, May 12, 2024 at 01:00:55AM +0530, Aradhya Bhatia wrote:
>> Up till now, the OLDI support in tidss was integrated within the tidss dispc.
>> This was fine till the OLDI was one-to-mapped with the DSS video-port (VP).
>> The AM62 and AM62P SoCs have 2 OLDI TXes that can support dual-lvds /
>> lvds-clone
>> modes.
>>
>> Add OLDI TXes as separate DRM bridge entities to better support the new LVDS
>> configurations.
>>
>> Signed-off-by: Aradhya Bhatia
>> ---
>> drivers/gpu/drm/tidss/Makefile | 3 +-
>> drivers/gpu/drm/tidss/tidss_dispc.c | 11 +-
>> drivers/gpu/drm/tidss/tidss_dispc.h | 4 +
>> drivers/gpu/drm/tidss/tidss_drv.c | 13 +-
>> drivers/gpu/drm/tidss/tidss_drv.h | 4 +
>> drivers/gpu/drm/tidss/tidss_oldi.c | 568
>> drivers/gpu/drm/tidss/tidss_oldi.h | 73
>> 7 files changed, 673 insertions(+), 3 deletions(-)
>> create mode 100644 drivers/gpu/drm/tidss/tidss_oldi.c
>> create mode 100644 drivers/gpu/drm/tidss/tidss_oldi.h
>>
>> diff --git a/drivers/gpu/drm/tidss/tidss_drv.c
>> b/drivers/gpu/drm/tidss/tidss_drv.c
>> index d15f836dca95..fd90e8498cc2 100644
>> --- a/drivers/gpu/drm/tidss/tidss_drv.c
>> +++ b/drivers/gpu/drm/tidss/tidss_drv.c
>> @@ -23,6 +23,7 @@
>> #include "tidss_drv.h"
>> #include "tidss_kms.h"
>> #include "tidss_irq.h"
>> +#include "tidss_oldi.h"
>>
>> /* Power management */
>>
>> @@ -140,10 +141,17 @@ static int tidss_probe(struct platform_device *pdev)
>>
>> spin_lock_init(>wait_lock);
>>
>> +ret = tidss_oldi_init(tidss);
>> +if (ret) {
>> +if (ret != -EPROBE_DEFER)
>> +dev_err(dev, "failed to init OLDI (%d)\n", ret);
>> +return ret;
>> +}
>
> return dev_err_probe()
>
>> diff --git a/drivers/gpu/drm/tidss/tidss_oldi.c
>> b/drivers/gpu/drm/tidss/tidss_oldi.c
>> new file mode 100644
>> index ..fd96ca815542
>> --- /dev/null
>> +++ b/drivers/gpu/drm/tidss/tidss_oldi.c
>> @@ -0,0 +1,568 @@
>
> ...
>
>> +ret = drm_of_find_panel_or_bridge(child, OLDI_OURPUT_PORT, -1,
>> + , );
>> +if (ret) {
>> +/*
>> + * Either there was no OLDI sink in the devicetree, or
>> + * the OLDI sink has not been added yet. In any case,
>> + * return.
>> + * We don't want to have an OLDI node connected to DSS
>> + * but not to any sink.
>> + */
>> +if (ret != -EPROBE_DEFER)
>> +dev_err(tidss->dev,
>> +"no panel/bridge for OLDI%d. Error
>> %d\n",
>> +oldi_instance, ret);
>
> just dev_err_probe
>
>> +goto err_put_node;
>> +}
>
> ...
>
>> +if (IS_ERR(oldi->io_ctrl)) {
>> +dev_err(oldi->dev,
>> +"%s: oldi%d syscon_regmap_lookup_by_phandle
>> failed %ld\n",
>> + __func__, oldi_instance, PTR_ERR(oldi->io_ctrl));
>> +ret = PTR_ERR(oldi->io_ctrl);
>
> dev_err_probe
>
>> +goto err_put_node;
>> +}
>> +
>> +oldi->s_clk = of_clk_get_by_name(child, "s_clk");
>> +if (IS_ERR(oldi->s_clk)) {
>> +dev_err(oldi->dev,
>> +"%s: oldi%d Failed to get s_clk: %ld\n",
>> +__func__, oldi_instance, PTR_ERR(oldi->s_clk));
>> +ret = PTR_ERR(oldi->s_clk);
>
> dev_err_probe
Got it. Will update in all the 4 places.
>
> In general, in this function, sometime you print an error and goto
> err_put_node, sometime you just goto err_put_node. Not sure what's the
> rationale on this.
There hasn't been any real logic behind the prints, except that I have
added them whenever there was something (specifc) to be explained. Other
times, for example, if the error is -ENOM
[PATCH 1/4] dt-bindings: display: ti,am65x-dss: Minor Cleanup
Reduce tab size from 8 spaces to 4 spaces to make the bindings
consistent, and easy to expand.
Signed-off-by: Aradhya Bhatia
---
.../bindings/display/ti/ti,am65x-dss.yaml | 54 +--
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
index 55e3e490d0e6..399d68986326 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
@@ -142,32 +142,32 @@ examples:
#include
dss: dss@4a0 {
-compatible = "ti,am65x-dss";
-reg = <0x04a0 0x1000>, /* common */
-<0x04a02000 0x1000>, /* vidl1 */
-<0x04a06000 0x1000>, /* vid */
-<0x04a07000 0x1000>, /* ovr1 */
-<0x04a08000 0x1000>, /* ovr2 */
-<0x04a0a000 0x1000>, /* vp1 */
-<0x04a0b000 0x1000>, /* vp2 */
-<0x04a01000 0x1000>; /* common1 */
-reg-names = "common", "vidl1", "vid",
-"ovr1", "ovr2", "vp1", "vp2", "common1";
-ti,am65x-oldi-io-ctrl = <_oldi_io_ctrl>;
-power-domains = <_pds 67 TI_SCI_PD_EXCLUSIVE>;
-clocks =<_clks 67 1>,
-<_clks 216 1>,
-<_clks 67 2>;
-clock-names = "fck", "vp1", "vp2";
-interrupts = ;
-ports {
-#address-cells = <1>;
-#size-cells = <0>;
-port@0 {
-reg = <0>;
-oldi_out0: endpoint {
-remote-endpoint = <_in0>;
-};
-};
+compatible = "ti,am65x-dss";
+reg = <0x04a0 0x1000>, /* common */
+ <0x04a02000 0x1000>, /* vidl1 */
+ <0x04a06000 0x1000>, /* vid */
+ <0x04a07000 0x1000>, /* ovr1 */
+ <0x04a08000 0x1000>, /* ovr2 */
+ <0x04a0a000 0x1000>, /* vp1 */
+ <0x04a0b000 0x1000>, /* vp2 */
+ <0x04a01000 0x1000>; /* common1 */
+reg-names = "common", "vidl1", "vid",
+"ovr1", "ovr2", "vp1", "vp2", "common1";
+ti,am65x-oldi-io-ctrl = <_oldi_io_ctrl>;
+power-domains = <_pds 67 TI_SCI_PD_EXCLUSIVE>;
+clocks =<_clks 67 1>,
+<_clks 216 1>,
+<_clks 67 2>;
+clock-names = "fck", "vp1", "vp2";
+interrupts = ;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+oldi_out0: endpoint {
+remote-endpoint = <_in0>;
+};
};
+};
};
--
2.34.1
[PATCH 4/4] drm/tidss: Add OLDI bridge support
Up till now, the OLDI support in tidss was integrated within the tidss dispc.
This was fine till the OLDI was one-to-mapped with the DSS video-port (VP).
The AM62 and AM62P SoCs have 2 OLDI TXes that can support dual-lvds / lvds-clone
modes.
Add OLDI TXes as separate DRM bridge entities to better support the new LVDS
configurations.
Signed-off-by: Aradhya Bhatia
---
Note:
The OLDI configuration should happen before the video-port configuration takes
place in tidss_crtc_atomic_enable hook. I have posted a patch allowing DRM
bridges to get enabled before the CRTC of that bridge is enabled[0]. This patch
uses the bridge hooks introduced in [0], and hence will not compile without [0].
[0]: Dependency Patch: Introduce early_enable / late_disable drm bridge APIs
https://lore.kernel.org/all/20240511153051.1355825-7-a-bhat...@ti.com/
---
drivers/gpu/drm/tidss/Makefile | 3 +-
drivers/gpu/drm/tidss/tidss_dispc.c | 11 +-
drivers/gpu/drm/tidss/tidss_dispc.h | 4 +
drivers/gpu/drm/tidss/tidss_drv.c | 13 +-
drivers/gpu/drm/tidss/tidss_drv.h | 4 +
drivers/gpu/drm/tidss/tidss_oldi.c | 568
drivers/gpu/drm/tidss/tidss_oldi.h | 73
7 files changed, 673 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/tidss/tidss_oldi.c
create mode 100644 drivers/gpu/drm/tidss/tidss_oldi.h
diff --git a/drivers/gpu/drm/tidss/Makefile b/drivers/gpu/drm/tidss/Makefile
index 312645271014..b6d6becf1683 100644
--- a/drivers/gpu/drm/tidss/Makefile
+++ b/drivers/gpu/drm/tidss/Makefile
@@ -7,6 +7,7 @@ tidss-y := tidss_crtc.o \
tidss_irq.o \
tidss_plane.o \
tidss_scale_coefs.o \
- tidss_dispc.o
+ tidss_dispc.o \
+ tidss_oldi.o
obj-$(CONFIG_DRM_TIDSS) += tidss.o
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index 1ad711f8d2a8..4961da3989c0 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -466,6 +466,16 @@ static u32 dispc_vp_read(struct dispc_device *dispc, u32
hw_videoport, u16 reg)
return ioread32(base + reg);
}
+u32 tidss_get_status(struct tidss_device *tidss)
+{
+ return dispc_read(tidss->dispc, DSS_SYSSTATUS);
+}
+
+void tidss_configure_oldi(struct tidss_device *tidss, u32 hw_videoport, u32
val)
+{
+ return dispc_vp_write(tidss->dispc, hw_videoport,
DISPC_VP_DSS_OLDI_CFG, val);
+}
+
/*
* TRM gives bitfields as start:end, where start is the higher bit
* number. For example 7:0
@@ -1310,7 +1320,6 @@ void dispc_vp_disable_clk(struct dispc_device *dispc, u32
hw_videoport)
* Calculate the percentage difference between the requested pixel clock rate
* and the effective rate resulting from calculating the clock divider value.
*/
-static
unsigned int dispc_pclk_diff(unsigned long rate, unsigned long real_rate)
{
int r = rate / 100, rr = real_rate / 100;
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.h
b/drivers/gpu/drm/tidss/tidss_dispc.h
index 086327d51a90..800a73457aff 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.h
+++ b/drivers/gpu/drm/tidss/tidss_dispc.h
@@ -94,6 +94,10 @@ extern const struct dispc_features dispc_am62a7_feats;
extern const struct dispc_features dispc_am65x_feats;
extern const struct dispc_features dispc_j721e_feats;
+u32 tidss_get_status(struct tidss_device *tidss);
+void tidss_configure_oldi(struct tidss_device *tidss, u32 hw_videoport, u32
val);
+unsigned int dispc_pclk_diff(unsigned long rate, unsigned long real_rate);
+
void dispc_set_irqenable(struct dispc_device *dispc, dispc_irq_t mask);
dispc_irq_t dispc_read_and_clear_irqstatus(struct dispc_device *dispc);
diff --git a/drivers/gpu/drm/tidss/tidss_drv.c
b/drivers/gpu/drm/tidss/tidss_drv.c
index d15f836dca95..fd90e8498cc2 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.c
+++ b/drivers/gpu/drm/tidss/tidss_drv.c
@@ -23,6 +23,7 @@
#include "tidss_drv.h"
#include "tidss_kms.h"
#include "tidss_irq.h"
+#include "tidss_oldi.h"
/* Power management */
@@ -140,10 +141,17 @@ static int tidss_probe(struct platform_device *pdev)
spin_lock_init(>wait_lock);
+ ret = tidss_oldi_init(tidss);
+ if (ret) {
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "failed to init OLDI (%d)\n", ret);
+ return ret;
+ }
+
ret = dispc_init(tidss);
if (ret) {
dev_err(dev, "failed to initialize dispc: %d\n", ret);
- return ret;
+ goto err_oldi_deinit;
}
pm_runtime_enable(dev);
@@ -202,6 +210,9 @@ static int tidss_probe(struct platform_device *pdev)
pm_runtime_dont_use_autosuspend(dev);
pm_runtime_disable(dev);
+err_oldi_deinit:
+ tidss_oldi_deinit(tidss);
+
return ret;
}
diff --git a/drivers/gpu/drm/tidss/tidss_drv.h
b/drivers/gpu/drm/tidss/tidss_drv.h
index d7f27b0b0315..4ccdc177
[PATCH 0/4] drm/tidss: Add OLDI bridge support
Hello all, This patch series add support for the dual OLDI TXes supported in Texas Instruments' AM62x and AM62Px family of SoCs. The OLDI TXes support single-lvds, lvds-clone, and dual-lvds modes. These have now been represented through DRM bridges within TI-DSS. The OLDI configuration should happen before the video-port configuration takes place in tidss_crtc_atomic_enable hook. I have posted a patch allowing DRM bridges to get enabled before the CRTC of that bridge is enabled[0]. The patch 4/4 of this series uses the bridge hooks introduced in [0], and hence will not compile without [0]. This patch series is a complete re-vamp from the previously posted series[1] and hence, the version index has been reset to v1. The OLDI support from that series was dropped and only the base support for AM625 DSS was kept (and eventually merged)[2]. These patches have been tested on AM625 based platforms, SK-AM625 EVM with a Microptis dual-lvds panel (SK-LCD1), and Beagleplay with a Lincolntech dual-lvds panel (LCD-185T). The patches with complete support including the expected devicetree configuration of the OLDI TXes can be found in the "next_oldi_finals-v1-tests" branch of my github fork[3]. Thanks, Aradhya [0]: Dependency Patch: Introduce early_enable / late_disable drm bridge APIs https://lore.kernel.org/all/20240511153051.1355825-7-a-bhat...@ti.com/ [1]: AM62 OLDI Series - v7 https://lore.kernel.org/all/20230125113529.13952-1-a-bhat...@ti.com/ [2]: AM62 DSS Series - v9 https://lore.kernel.org/all/20230616150900.6617-1-a-bhat...@ti.com/ [3]: GitHub Fork for OLDI tests https://github.com/aradhya07/linux-ab/tree/next_oldi_finals-v1-tests Aradhya Bhatia (4): dt-bindings: display: ti,am65x-dss: Minor Cleanup dt-bindings: display: ti: Add schema for AM625 OLDI Transmitter dt-bindings: display: ti,am65x-dss: Add OLDI properties for AM625 DSS drm/tidss: Add OLDI bridge support .../bindings/display/ti/ti,am625-oldi.yaml| 153 + .../bindings/display/ti/ti,am65x-dss.yaml | 178 +- MAINTAINERS | 1 + drivers/gpu/drm/tidss/Makefile| 3 +- drivers/gpu/drm/tidss/tidss_dispc.c | 11 +- drivers/gpu/drm/tidss/tidss_dispc.h | 4 + drivers/gpu/drm/tidss/tidss_drv.c | 13 +- drivers/gpu/drm/tidss/tidss_drv.h | 4 + drivers/gpu/drm/tidss/tidss_oldi.c| 568 ++ drivers/gpu/drm/tidss/tidss_oldi.h| 73 +++ 10 files changed, 983 insertions(+), 25 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml create mode 100644 drivers/gpu/drm/tidss/tidss_oldi.c create mode 100644 drivers/gpu/drm/tidss/tidss_oldi.h base-commit: 75fa778d74b786a1608d55d655d42b480a6fa8bd -- 2.34.1
[PATCH 3/4] dt-bindings: display: ti, am65x-dss: Add OLDI properties for AM625 DSS
The DSS in AM625 SoC has 2 OLDI TXes. Refer the OLDI schema to add the
properties.
Signed-off-by: Aradhya Bhatia
---
.../bindings/display/ti/ti,am65x-dss.yaml | 136 +-
1 file changed, 135 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
index 399d68986326..4aa2de59b32b 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
@@ -85,12 +85,30 @@ properties:
properties:
port@0:
-$ref: /schemas/graph.yaml#/properties/port
+$ref: /schemas/graph.yaml#/$defs/port-base
description:
For AM65x DSS, the OLDI output port node from video port 1.
For AM625 DSS, the internal DPI output port node from video
port 1.
For AM62A7 DSS, the port is tied off inside the SoC.
+properties:
+ endpoint@0:
+$ref: /schemas/graph.yaml#/properties/endpoint
+description:
+ For AM625 DSS, VP Connection to OLDI0.
+ For AM65X DSS, OLDI output from the SoC.
+
+ endpoint@1:
+$ref: /schemas/graph.yaml#/properties/endpoint
+description:
+ For AM625 DSS, VP Connection to OLDI1.
+
+anyOf:
+ - required:
+ - endpoint
+ - required:
+ - endpoint@0
+ - endpoint@1
port@1:
$ref: /schemas/graph.yaml#/properties/port
@@ -112,6 +130,22 @@ properties:
Input memory (from main memory to dispc) bandwidth limit in
bytes per second
+ oldi-txes:
+type: object
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+patternProperties:
+ '^oldi_tx@[0-1]$':
+type: object
+$ref: ti,am625-oldi.yaml#
+unevaluatedProperties: false
+description: OLDI transmitters connected to the DSS VPs
+
allOf:
- if:
properties:
@@ -123,6 +157,19 @@ allOf:
ports:
properties:
port@0: false
+oldi_txes: false
+
+ - if:
+ properties:
+compatible:
+ contains:
+const: ti,am65x-dss
+then:
+ properties:
+oldi_txes: false
+port@0:
+ properties:
+endpoint@1: false
required:
- compatible
@@ -171,3 +218,90 @@ examples:
};
};
};
+
+ - |
+#include
+#include
+#include
+
+bus {
+#address-cells = <2>;
+#size-cells = <2>;
+dss1: dss@3020 {
+compatible = "ti,am625-dss";
+reg = <0x00 0x3020 0x00 0x1000>, /* common */
+ <0x00 0x30202000 0x00 0x1000>, /* vidl1 */
+ <0x00 0x30206000 0x00 0x1000>, /* vid */
+ <0x00 0x30207000 0x00 0x1000>, /* ovr1 */
+ <0x00 0x30208000 0x00 0x1000>, /* ovr2 */
+ <0x00 0x3020a000 0x00 0x1000>, /* vp1 */
+ <0x00 0x3020b000 0x00 0x1000>, /* vp2 */
+ <0x00 0x30201000 0x00 0x1000>; /* common1 */
+reg-names = "common", "vidl1", "vid",
+"ovr1", "ovr2", "vp1", "vp2", "common1";
+power-domains = <_pds 186 TI_SCI_PD_EXCLUSIVE>;
+clocks =<_clks 186 6>,
+<_clock>,
+<_clks 186 2>;
+clock-names = "fck", "vp1", "vp2";
+interrupts = ;
+oldi-txes {
+#address-cells = <1>;
+#size-cells = <0>;
+oldi0: oldi@0 {
+reg = <0>;
+clocks = <_clks 186 0>;
+clock-names = "s_clk";
+ti,companion-oldi = <>;
+ti,oldi-io-ctrl = <_oldi_io_ctrl>;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+oldi0_in: endpoint {
+remote-endpoint = <_out0>;
+};
+};
+};
+};
+oldi1: oldi@1 {
+reg = <1>;
+ti,secondary-oldi;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+
[PATCH 2/4] dt-bindings: display: ti: Add schema for AM625 OLDI Transmitter
Add devicetree binding schema for AM625 OLDI Transmitters.
Signed-off-by: Aradhya Bhatia
---
.../bindings/display/ti/ti,am625-oldi.yaml| 153 ++
MAINTAINERS | 1 +
2 files changed, 154 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
diff --git a/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
new file mode 100644
index ..0a96e600bc0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
@@ -0,0 +1,153 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/ti/ti,am625-oldi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments AM625 OLDI Transmitter
+
+maintainers:
+ - Tomi Valkeinen
+ - Aradhya Bhatia
+
+description: |
+ The AM625 TI Keystone OpenLDI transmitter (OLDI TX) supports serialized RGB
+ pixel data transmission between host and flat panel display over LVDS (Low
+ Voltage Differential Sampling) interface. The OLDI TX consists of 7-to-1 data
+ serializers, and 4-data and 1-clock LVDS outputs. It supports the LVDS output
+ formats "jeida-18", "jeida-24" and "vesa-18", and can accept 24-bit RGB or
+ padded and un-padded 18-bit RGB bus formats as input.
+
+properties:
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+description: serial clock input for the OLDI transmitters
+
+ clock-names:
+const: s_clk
+
+ ti,companion-oldi:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ phandle to companion OLDI transmitter. This property is mandatory for the
+ primarty OLDI TX if the OLDI TXes are expected to work either in
dual-lvds
+ mode or in clone mode. This property should point to the secondary OLDI
+ TX.
+
+ ti,secondary-oldi:
+type: boolean
+description: Boolean property to mark an OLDI TX as secondary node.
+
+ ti,oldi-io-ctrl:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ phandle to syscon device node mapping OLDI IO_CTRL registers found in the
+ control MMR region. This property is needed for OLDI interface to work.
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Parallel RGB input port
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: LVDS output port
+
+required:
+ - port@0
+ - port@1
+
+allOf:
+ - if:
+ properties:
+ti,secondary-oldi: true
+then:
+ properties:
+ti,companion-oldi: false
+ti,oldi-io-ctrl: false
+clocks: false
+clock-names: false
+
+else:
+ required:
+- ti,oldi-io-ctrl
+- clocks
+- clock-names
+
+required:
+ - reg
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+oldi_txes {
+#address-cells = <1>;
+#size-cells = <0>;
+oldi: oldi@0 {
+reg = <0>;
+clocks = <_clks 186 0>;
+clock-names = "s_clk";
+ti,oldi-io-ctrl = <_oldi_io_ctrl>;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+oldi_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+};
+
+ - |
+#include
+
+oldi_txes {
+#address-cells = <1>;
+#size-cells = <0>;
+oldi0: oldi@0 {
+reg = <0>;
+clocks = <_clks 186 0>;
+clock-names = "s_clk";
+ti,companion-oldi = <>;
+ti,oldi-io-ctrl = <_oldi_io_ctrl>;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+oldi0_in: endpoint {
+remote-endpoint = <_out0>;
+};
+};
+};
+};
+oldi1: oldi@1 {
+reg = <1>;
+ti,secondary-oldi;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+oldi1_in: endpoint {
+remote-endpoint = <_out1>;
+};
+};
+};
+};
+};
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index c675fc296b19..4426c4d41a7f 100644
--- a/MAINTAINERS
+++ b/MAINTAINE
[PATCH 7/7] drm/bridge: cdns-dsi: Implement early_enable and late_disable
The cdsn-dsi controller requires that it be turned on completely before
the input DPI's source has begun streaming.
Since tidss's videoport starts streaming via crtc enable hooks, we need
cdns-dsi to be up and running before that. Hence, use the early_enable
and late_disable hooks to get pass the color issues.
Signed-off-by: Aradhya Bhatia
---
.../gpu/drm/bridge/cadence/cdns-dsi-core.c| 36 ---
1 file changed, 6 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
index c7519d18e94f..53fa20720089 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
@@ -656,8 +656,8 @@ cdns_dsi_bridge_mode_valid(struct drm_bridge *bridge,
return MODE_OK;
}
-static void cdns_dsi_bridge_atomic_disable(struct drm_bridge *bridge,
- struct drm_bridge_state
*old_bridge_state)
+static void cdns_dsi_bridge_atomic_late_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
struct cdns_dsi *dsi = input_to_dsi(input);
@@ -677,15 +677,6 @@ static void cdns_dsi_bridge_atomic_disable(struct
drm_bridge *bridge,
pm_runtime_put(dsi->base.dev);
}
-static void cdns_dsi_bridge_post_disable(struct drm_bridge *bridge,
-struct drm_bridge_state
*old_bridge_state)
-{
- struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
- struct cdns_dsi *dsi = input_to_dsi(input);
-
- pm_runtime_put(dsi->base.dev);
-}
-
static void cdns_dsi_hs_init(struct cdns_dsi *dsi)
{
struct cdns_dsi_output *output = >output;
@@ -755,8 +746,8 @@ static void cdns_dsi_init_link(struct cdns_dsi *dsi)
dsi->link_initialized = true;
}
-static void cdns_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
- struct drm_bridge_state
*old_bridge_state)
+static void cdns_dsi_bridge_atomic_early_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
struct cdns_dsi *dsi = input_to_dsi(input);
@@ -907,19 +898,6 @@ static void cdns_dsi_bridge_atomic_enable(struct
drm_bridge *bridge,
writel(tmp, dsi->regs + MCTL_MAIN_EN);
}
-static void cdns_dsi_bridge_pre_enable(struct drm_bridge *bridge,
- struct drm_bridge_state
*old_bridge_state)
-{
- struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
- struct cdns_dsi *dsi = input_to_dsi(input);
-
- if (WARN_ON(pm_runtime_get_sync(dsi->base.dev) < 0))
- return;
-
- cdns_dsi_init_link(dsi);
- cdns_dsi_hs_init(dsi);
-}
-
static u32 *cdns_dsi_bridge_get_input_bus_fmts(struct drm_bridge *bridge,
struct drm_bridge_state
*bridge_state,
struct drm_crtc_state
*crtc_state,
@@ -968,10 +946,8 @@ static u32 *cdns_dsi_bridge_get_input_bus_fmts(struct
drm_bridge *bridge,
static const struct drm_bridge_funcs cdns_dsi_bridge_funcs = {
.attach = cdns_dsi_bridge_attach,
.mode_valid = cdns_dsi_bridge_mode_valid,
- .atomic_disable = cdns_dsi_bridge_atomic_disable,
- .atomic_pre_enable = cdns_dsi_bridge_atomic_pre_enable,
- .atomic_enable = cdns_dsi_bridge_atomic_enable,
- .atomic_post_disable = cdns_dsi_bridge_atomic_post_disable,
+ .atomic_early_enable = cdns_dsi_bridge_atomic_early_enable,
+ .atomic_late_disable = cdns_dsi_bridge_atomic_late_disable,
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_reset = drm_atomic_helper_bridge_reset,
--
2.34.1
[PATCH 4/7] drm/bridge: cdns-dsi: Reset the DCS write FIFO
Allow the DCS Write FIFO in the cdns-dsi controller to reset before any DCS packet is transmitted to the DSI sink device. Signed-off-by: Aradhya Bhatia --- drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c index 05d2f4cc50da..87fdd07ca0bc 100644 --- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c +++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c @@ -1037,6 +1037,9 @@ static ssize_t cdns_dsi_transfer(struct mipi_dsi_host *host, cdns_dsi_init_link(dsi); + /* Reset the DCS Write FIFO */ + writel(0x00, dsi->regs + DIRECT_CMD_FIFO_RST); + ret = mipi_dsi_create_packet(, msg); if (ret) goto out; -- 2.34.1
[PATCH 5/7] drm/bridge: cdns-dsi: Support atomic bridge APIs
Change the existing (and deparacated) bridge hooks, to the bridge
atomic APIs.
Add drm helpers for duplicate_state, destroy_state, and bridge_reset
bridge hooks.
Further add support for the input format negotiation hook.
Signed-off-by: Aradhya Bhatia
---
.../gpu/drm/bridge/cadence/cdns-dsi-core.c| 70 ---
1 file changed, 62 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
index 87fdd07ca0bc..c7519d18e94f 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -655,7 +656,8 @@ cdns_dsi_bridge_mode_valid(struct drm_bridge *bridge,
return MODE_OK;
}
-static void cdns_dsi_bridge_disable(struct drm_bridge *bridge)
+static void cdns_dsi_bridge_atomic_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
struct cdns_dsi *dsi = input_to_dsi(input);
@@ -675,7 +677,8 @@ static void cdns_dsi_bridge_disable(struct drm_bridge
*bridge)
pm_runtime_put(dsi->base.dev);
}
-static void cdns_dsi_bridge_post_disable(struct drm_bridge *bridge)
+static void cdns_dsi_bridge_post_disable(struct drm_bridge *bridge,
+struct drm_bridge_state
*old_bridge_state)
{
struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
struct cdns_dsi *dsi = input_to_dsi(input);
@@ -752,7 +755,8 @@ static void cdns_dsi_init_link(struct cdns_dsi *dsi)
dsi->link_initialized = true;
}
-static void cdns_dsi_bridge_enable(struct drm_bridge *bridge)
+static void cdns_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
struct cdns_dsi *dsi = input_to_dsi(input);
@@ -903,7 +907,8 @@ static void cdns_dsi_bridge_enable(struct drm_bridge
*bridge)
writel(tmp, dsi->regs + MCTL_MAIN_EN);
}
-static void cdns_dsi_bridge_pre_enable(struct drm_bridge *bridge)
+static void cdns_dsi_bridge_pre_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
struct cdns_dsi *dsi = input_to_dsi(input);
@@ -915,13 +920,62 @@ static void cdns_dsi_bridge_pre_enable(struct drm_bridge
*bridge)
cdns_dsi_hs_init(dsi);
}
+static u32 *cdns_dsi_bridge_get_input_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state
*bridge_state,
+ struct drm_crtc_state
*crtc_state,
+ struct drm_connector_state
*conn_state,
+ u32 output_fmt,
+ unsigned int *num_input_fmts)
+{
+ struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
+ struct cdns_dsi *dsi = input_to_dsi(input);
+ struct cdns_dsi_output *output = >output;
+ u32 *input_fmts;
+
+ *num_input_fmts = 0;
+
+ input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+
+ switch (output->dev->format) {
+ case MIPI_DSI_FMT_RGB888:
+ input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+ break;
+
+ case MIPI_DSI_FMT_RGB666:
+ input_fmts[0] = MEDIA_BUS_FMT_RGB666_1X24_CPADHI;
+ break;
+
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ input_fmts[0] = MEDIA_BUS_FMT_RGB666_1X18;
+ break;
+
+ case MIPI_DSI_FMT_RGB565:
+ input_fmts[0] = MEDIA_BUS_FMT_RGB565_1X16;
+ break;
+
+ default:
+ /* Unsupported DSI Format */
+ return NULL;
+ }
+
+ *num_input_fmts = 1;
+
+ return input_fmts;
+}
+
static const struct drm_bridge_funcs cdns_dsi_bridge_funcs = {
.attach = cdns_dsi_bridge_attach,
.mode_valid = cdns_dsi_bridge_mode_valid,
- .disable = cdns_dsi_bridge_disable,
- .pre_enable = cdns_dsi_bridge_pre_enable,
- .enable = cdns_dsi_bridge_enable,
- .post_disable = cdns_dsi_bridge_post_disable,
+ .atomic_disable = cdns_dsi_bridge_atomic_disable,
+ .atomic_pre_enable = cdns_dsi_bridge_atomic_pre_enable,
+ .atomic_enable = cdns_dsi_bridge_atomic_enable,
+ .atomic_post_disable = cdns_dsi_bridge_atomic_post_disable,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_br
[PATCH 1/7] drm/tidss: Add CRTC mode_fixup
Add support for mode_fixup for the tidss CRTC.
Some bridges like the cdns-dsi consume the crtc_* timing parameters for
programming the blanking values. Allow for the normal timing parameters
to get copied to crtc_* timing params.
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/tidss/tidss_crtc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c
b/drivers/gpu/drm/tidss/tidss_crtc.c
index 94f8e3178df5..797ef53d9ad2 100644
--- a/drivers/gpu/drm/tidss/tidss_crtc.c
+++ b/drivers/gpu/drm/tidss/tidss_crtc.c
@@ -309,12 +309,23 @@ enum drm_mode_status tidss_crtc_mode_valid(struct
drm_crtc *crtc,
return dispc_vp_mode_valid(tidss->dispc, tcrtc->hw_videoport, mode);
}
+static
+bool tidss_crtc_mode_fixup(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ drm_mode_set_crtcinfo(adjusted_mode, 0);
+
+ return true;
+}
+
static const struct drm_crtc_helper_funcs tidss_crtc_helper_funcs = {
.atomic_check = tidss_crtc_atomic_check,
.atomic_flush = tidss_crtc_atomic_flush,
.atomic_enable = tidss_crtc_atomic_enable,
.atomic_disable = tidss_crtc_atomic_disable,
+ .mode_fixup = tidss_crtc_mode_fixup,
.mode_valid = tidss_crtc_mode_valid,
};
--
2.34.1
[PATCH 2/7] drm/bridge: cdns-dsi: Fix minor bugs
Update the Phy initialized state to "not initialized" when the driver
(and the hardware by extension) gets suspended. This will allow the Phy
to get initialized again after resume.
Fix the OF node that gets passed to find the next available bridge in
the display pipeline.
Fix the order of DSI Link and DSI Phy inits. The link init needs to
happen before the Phy is initialized, so the Phy can lock on the
incoming PLL reference clock. If this doesn't happen, the Phy cannot
lock (until DSI Link is init later on). This causes a warning dump
during the kernel boot.
Allow the D-Phy config checks to use mode->clock instead of
mode->crtc_clock during mode_valid checks, like everywhere else in the
driver.
Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver")
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
index 7457d38622b0..557b037bbc67 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
@@ -574,7 +574,7 @@ static int cdns_dsi_check_conf(struct cdns_dsi *dsi,
if (ret)
return ret;
- phy_mipi_dphy_get_default_config(mode->crtc_clock * 1000,
+ phy_mipi_dphy_get_default_config((mode_valid_check ? mode->clock :
mode->crtc_clock) * 1000,
mipi_dsi_pixel_format_to_bpp(output->dev->format),
nlanes, phy_cfg);
@@ -775,8 +775,8 @@ static void cdns_dsi_bridge_enable(struct drm_bridge
*bridge)
WARN_ON_ONCE(cdns_dsi_check_conf(dsi, mode, _cfg, false));
- cdns_dsi_hs_init(dsi);
cdns_dsi_init_link(dsi);
+ cdns_dsi_hs_init(dsi);
writel(HBP_LEN(dsi_cfg.hbp) | HSA_LEN(dsi_cfg.hsa),
dsi->regs + VID_HSIZE1);
@@ -952,7 +952,7 @@ static int cdns_dsi_attach(struct mipi_dsi_host *host,
bridge = drm_panel_bridge_add_typed(panel,
DRM_MODE_CONNECTOR_DSI);
} else {
- bridge = of_drm_find_bridge(dev->dev.of_node);
+ bridge = of_drm_find_bridge(np);
if (!bridge)
bridge = ERR_PTR(-EINVAL);
}
@@ -1153,6 +1153,7 @@ static int __maybe_unused cdns_dsi_suspend(struct device
*dev)
clk_disable_unprepare(dsi->dsi_p_clk);
reset_control_assert(dsi->dsi_p_rst);
dsi->link_initialized = false;
+ dsi->phy_initialized = false;
return 0;
}
--
2.34.1
[PATCH 6/7] drm/bridge: Introduce early_enable and late disable
With the existing pre_enable and enable function hooks, the order of
enable of display elements looks as follows,
crtc_enable -> bridge[n]_pre_enable -> ... -> bridge[1]_pre_enable ->
encoder_enable -> bridge[1]_enable -> ... -> bridge[n]_enable
and vice versa for the disable.
Some bridges need to be up and running before and after their source
gets enabled and has run. In some case, that source is a display unit,
controlled as part of _crtc.
For those bridges, add support for early_enable and late_disable
function hooks.
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/drm_atomic_helper.c | 67 +++
drivers/gpu/drm/drm_bridge.c| 84 +
include/drm/drm_bridge.h| 73 +
3 files changed, 224 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index fb97b51b38f1..396bb83e4296 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1234,6 +1234,49 @@ disable_outputs(struct drm_device *dev, struct
drm_atomic_state *old_state)
if (ret == 0)
drm_crtc_vblank_put(crtc);
}
+
+ for_each_oldnew_connector_in_state(old_state, connector, old_conn_state,
+ new_conn_state, i) {
+ struct drm_encoder *encoder;
+ struct drm_bridge *bridge;
+
+ /*
+* Shut down everything that's in the changeset and currently
+* still on. So need to check the old, saved state.
+*/
+ if (!old_conn_state->crtc)
+ continue;
+
+ old_crtc_state = drm_atomic_get_old_crtc_state(old_state,
old_conn_state->crtc);
+
+ if (new_conn_state->crtc)
+ new_crtc_state =
drm_atomic_get_new_crtc_state(old_state,
+
new_conn_state->crtc);
+ else
+ new_crtc_state = NULL;
+
+ if (!crtc_needs_disable(old_crtc_state, new_crtc_state) ||
+ !drm_atomic_crtc_needs_modeset(old_conn_state->crtc->state))
+ continue;
+
+ encoder = old_conn_state->best_encoder;
+
+ /* We shouldn't get this far if we didn't previously have
+* an encoder.. but WARN_ON() rather than explode.
+*/
+ if (WARN_ON(!encoder))
+ continue;
+
+ drm_dbg_atomic(dev, "disabling [ENCODER:%d:%s]\n",
+ encoder->base.id, encoder->name);
+
+ /*
+* Each encoder has at most one connector (since we always steal
+* it away), so we won't call disable hooks twice.
+*/
+ bridge = drm_bridge_chain_get_first_bridge(encoder);
+ drm_atomic_bridge_chain_late_disable(bridge, old_state);
+ }
}
/**
@@ -1469,6 +1512,30 @@ void drm_atomic_helper_commit_modeset_enables(struct
drm_device *dev,
struct drm_connector_state *new_conn_state;
int i;
+ for_each_new_connector_in_state(old_state, connector, new_conn_state,
i) {
+ struct drm_encoder *encoder;
+ struct drm_bridge *bridge;
+
+ if (!new_conn_state->best_encoder)
+ continue;
+
+ if (!new_conn_state->crtc->state->active ||
+ !drm_atomic_crtc_needs_modeset(new_conn_state->crtc->state))
+ continue;
+
+ encoder = new_conn_state->best_encoder;
+
+ drm_dbg_atomic(dev, "enabling [ENCODER:%d:%s]\n",
+ encoder->base.id, encoder->name);
+
+ /*
+* Each encoder has at most one connector (since we always steal
+* it away), so we won't call enable hooks twice.
+*/
+ bridge = drm_bridge_chain_get_first_bridge(encoder);
+ drm_atomic_bridge_chain_early_enable(bridge, old_state);
+ }
+
for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
new_crtc_state, i) {
const struct drm_crtc_helper_funcs *funcs;
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 28abe9aa99ca..b9070f6b3554 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -623,6 +623,50 @@ void drm_atomic_bridge_chain_disable(struct drm_bridge
*bridge,
}
EXPORT_SYMBOL(drm_atomic_bridge_chain_disable);
+/**
+ * drm_atomic_bridge_chain_late_disable - disables all bridges in the encoder
+ * chain after crtc is disabled.
+ * @bridge: bridge control structu
[PATCH 0/7] drm/bridge: cdns-dsi: Fix the color-shift issue
Hello all, This series provides some crucial fixes and improvements for the Cadence's DSI TX (cdns-dsi) controller found commonly in Texas Instruments' J7 family of SoCs as well as in AM62P. The cdns-dsi bridge consumes the crtc_* timing parameters for programming the timing parameters. A patch has been added in tidss to make sure the crtc_* timings get populated. It further adds support for "early_enable" and "late_disable" DRM bridge hooks. These hooks are same as the existing "(pre_)enable" and "(post_)disable" hooks, except that the early_enable hook gets called before the CRTC is even enabled in the display pipeline and the late_disable hook gets called after the CRTC is disabled. The cdns-dsi controller requires to be enabled before the previous entity enables its stream[0]. It's a strict requirement which, if not followed, causes the colors to "shift" on the display. Since the previous entity is TIDSS in this case, which gets enabled via the tidss_crtc hooks, early_enable/late_disable API in the cdns-dsi bridge is the way to solve the issue. The early_enable/late_disable APIs also help with the OLDI TXes available on the AM62/AM62P SoCs, which will be a part of separate series. This spec also requires the Clock and Data Lanes be ready before the DSI TX enables its stream[0]. A patch has been added to make the code wait for that to happen. Going ahead with further DSI (and DSS configuration), while the lanes are not ready, has been found as another reason for shift in colors. All these patches have been tested on TI's vendor tree kernel with more devices, but for the mainline, these patches have been tested with J721E based BeagleboneAI64 along with a RaspberryPi 7" DSI panel. The extra patches can be found in the "next_dsi_finals-v1-test_rpi" branch of my github fork[1] for anyone who would like to test them. Thanks, Aradhya [0]: Section 12.6.5.7.3: Start-up Procesure [For DSI TX controller] in TDA4VM Technical Reference Manual https://www.ti.com/lit/zip/spruil1 [1]: https://github.com/aradhya07/linux-ab/tree/next_dsi_finals-v1-test_rpi Aradhya Bhatia (7): drm/tidss: Add CRTC mode_fixup drm/bridge: cdns-dsi: Fix minor bugs drm/bridge: cdns-dsi: Wait for Clk and Data Lanes to be ready drm/bridge: cdns-dsi: Reset the DCS write FIFO drm/bridge: cdns-dsi: Support atomic bridge APIs drm/bridge: Introduce early_enable and late disable drm/bridge: cdns-dsi: Implement early_enable and late_disable .../gpu/drm/bridge/cadence/cdns-dsi-core.c| 91 ++- drivers/gpu/drm/drm_atomic_helper.c | 67 ++ drivers/gpu/drm/drm_bridge.c | 84 + drivers/gpu/drm/tidss/tidss_crtc.c| 11 +++ include/drm/drm_bridge.h | 73 +++ 5 files changed, 303 insertions(+), 23 deletions(-) base-commit: 75fa778d74b786a1608d55d655d42b480a6fa8bd -- 2.34.1
[PATCH 3/7] drm/bridge: cdns-dsi: Wait for Clk and Data Lanes to be ready
Once the DSI Link and DSI Phy are initialized, the code needs to wait
for Clk and Data Lanes to be ready, before continuing configuration.
This is in accordance with the DSI Start-up procedure, found in the
Technical Reference Manual of Texas Instrument's J721E SoC[0] which
houses this DSI TX controller.
If the previous bridge (or crtc/encoder) are configured pre-maturely,
the input signal FIFO gets corrupt. This introduces a color-shift on the
display.
Allow the driver to wait for the clk and data lanes to get ready during
DSI enable.
Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver")
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
index 557b037bbc67..05d2f4cc50da 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
@@ -761,7 +761,7 @@ static void cdns_dsi_bridge_enable(struct drm_bridge
*bridge)
struct phy_configure_opts_mipi_dphy *phy_cfg =
>phy_opts.mipi_dphy;
unsigned long tx_byte_period;
struct cdns_dsi_cfg dsi_cfg;
- u32 tmp, reg_wakeup, div;
+ u32 tmp, reg_wakeup, div, status;
int nlanes;
if (WARN_ON(pm_runtime_get_sync(dsi->base.dev) < 0))
@@ -778,6 +778,17 @@ static void cdns_dsi_bridge_enable(struct drm_bridge
*bridge)
cdns_dsi_init_link(dsi);
cdns_dsi_hs_init(dsi);
+ /*
+* Now that the DSI Link and DSI Phy are initialized,
+* wait for the CLK and Data Lanes to be ready.
+*/
+ tmp = CLK_LANE_RDY;
+ for (int i = 0; i < nlanes; i++)
+ tmp |= DATA_LANE_RDY(i);
+
+ WARN_ON_ONCE(readl_poll_timeout(dsi->regs + MCTL_MAIN_STS, status,
+ status & tmp, 100, 0));
+
writel(HBP_LEN(dsi_cfg.hbp) | HSA_LEN(dsi_cfg.hsa),
dsi->regs + VID_HSIZE1);
writel(HFP_LEN(dsi_cfg.hfp) | HACT_LEN(dsi_cfg.hact),
--
2.34.1
Re: [PATCH v5 0/4] Add common1 region for AM62, AM62A & AM65x
On 16-Feb-24 11:54, Devarsh Thakkar wrote: > This adds DSS common1 region for respective SoCs supporting it. > > Changelog: > V2 : Remove do-not-merge tag and add am62a dss common1 reion > V3 : Add Fixes tag to each commit > V4 : Add Reviewed-by tag and AM62A SoC TRM Link > V5 : Split dts patch to separate patches for each SoC > > Devarsh Thakkar (4): > dt-bindings: display: ti,am65x-dss: Add support for common1 region > arm64: dts: ti: Add common1 register space for AM65x SoC > arm64: dts: ti: Add common1 register space for AM62x SoC > arm64: dts: ti: Add common1 register space for AM62A SoC For the series, Reviewed-by: Aradhya Bhatia Regards Aradhya > > .../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 7 +-- > arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 5 +++-- > arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 5 +++-- > arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 5 +++-- > 4 files changed, 14 insertions(+), 8 deletions(-) >
Re: [PATCH v3 1/2] dt-bindings: display: ti,am65x-dss: Add support for common1 region
On 15/02/24 14:02, Devarsh Thakkar wrote:
> TI keystone display subsystem present in AM65 and other SoCs such as AM62
> support two separate register spaces namely "common" and "common1" which
> can be used by two separate hosts to program the display controller as
> described in respective Technical Reference Manuals [1].
>
> The common1 register space has similar set of configuration registers as
> supported in common register space except the global configuration
> registers which are exclusive to common region.
>
> This adds binding for "common1" register region too as supported by the
> hardware.
>
> [1]:
> AM62x TRM:
> https://www.ti.com/lit/pdf/spruiv7 (Section 14.8.9.1 DSS Registers)
>
> AM65x TRM:
> https://www.ti.com/lit/pdf/spruid7 (Section 12.6.5 DSS Registers)
Can you add the TRM link for AM62A too?
With that sorted,
Reviewed-by: Aradhya Bhatia
>
> Fixes: 2d8730f1021f ("dt-bindings: display: ti,am65x-dss: Add dt-schema yaml
> binding")
> Signed-off-by: Devarsh Thakkar
> Acked-by: Conor Dooley > ---
> V2: Add Acked-by tag
> V3: Add Fixes tag
> ---
> .../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> index b6767ef0d24d..55e3e490d0e6 100644
> --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> @@ -37,6 +37,7 @@ properties:
>- description: OVR2 overlay manager for vp2
>- description: VP1 video port 1
>- description: VP2 video port 2
> + - description: common1 DSS register area
>
>reg-names:
> items:
> @@ -47,6 +48,7 @@ properties:
>- const: ovr2
>- const: vp1
>- const: vp2
> + - const: common1
>
>clocks:
> items:
> @@ -147,9 +149,10 @@ examples:
> <0x04a07000 0x1000>, /* ovr1 */
> <0x04a08000 0x1000>, /* ovr2 */
> <0x04a0a000 0x1000>, /* vp1 */
> -<0x04a0b000 0x1000>; /* vp2 */
> +<0x04a0b000 0x1000>, /* vp2 */
> +<0x04a01000 0x1000>; /* common1 */
> reg-names = "common", "vidl1", "vid",
> -"ovr1", "ovr2", "vp1", "vp2";
> +"ovr1", "ovr2", "vp1", "vp2", "common1";
> ti,am65x-oldi-io-ctrl = <_oldi_io_ctrl>;
> power-domains = <_pds 67 TI_SCI_PD_EXCLUSIVE>;
> clocks =<_clks 67 1>,
Re: [PATCH 2/2] drm/tidss: Fix sync-lost issue with two displays
On 13/02/24 13:46, Tomi Valkeinen wrote:
> A sync lost issue can be observed with two displays, when moving a plane
> from one disabled display to an another disabled display, and then
> enabling the display to which the plane was moved to. The exact
> requirements for this to trigger are not clear.
>
> It looks like the issue is that the layers are left enabled in the first
> display's OVR registers. Even if the corresponding VP is disabled, it
> still causes an issue, as if the disabled VP and its OVR would still be
> in use, leading to the same VID being used by two OVRs. However, this is
> just speculation based on testing the DSS behavior.
>
> Experimentation shows that as a workaround, we can disable all the
> layers in the OVR when disabling a VP. There should be no downside to
> this, as the OVR is anyway effectively disabled if its VP is disabled,
> and it seems to solve the sync lost issue.
>
> However, there may be a bigger issue in play here, related to J721e
> erratum i2097 ("DSS: Disabling a Layer Connected to Overlay May Result
> in Synclost During the Next Frame"). Experimentation also shows that the
> OVR's CHANNELIN field has similar issue. So we may need to revisit this
> when we find out more about the core issue.
>
> Signed-off-by: Tomi Valkeinen
> Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display
> SubSystem")
Reviewed-by: Aradhya Bhatia
> ---
> drivers/gpu/drm/tidss/tidss_crtc.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c
> b/drivers/gpu/drm/tidss/tidss_crtc.c
> index 5f838980c7a1..94f8e3178df5 100644
> --- a/drivers/gpu/drm/tidss/tidss_crtc.c
> +++ b/drivers/gpu/drm/tidss/tidss_crtc.c
> @@ -265,6 +265,16 @@ static void tidss_crtc_atomic_disable(struct drm_crtc
> *crtc,
>
> reinit_completion(>framedone_completion);
>
> + /*
> + * If a layer is left enabled when the videoport is disabled, and the
> + * vid pipeline that was used for the layer is taken into use on
> + * another videoport, the DSS will report sync lost issues. Disable all
> + * the layers here as a work-around.
> + */
> + for (u32 layer = 0; layer < tidss->feat->num_planes; layer++)
> + dispc_ovr_enable_layer(tidss->dispc, tcrtc->hw_videoport, layer,
> +false);
> +
> dispc_vp_disable(tidss->dispc, tcrtc->hw_videoport);
>
> if (!wait_for_completion_timeout(>framedone_completion,
>
Re: [PATCH 1/2] drm/tidss: Fix initial plane zpos values
Tomi, thank you for the fixes.
On 13/02/24 13:46, Tomi Valkeinen wrote:
> When the driver sets up the zpos property it sets the default zpos value
> to the HW id of the plane. That is fine as such, but as on many DSS
> versions the driver arranges the DRM planes in a different order than
> the HW planes (to keep the non-scalable planes first), this leads to odd
> initial zpos values. An example is J721e, where the initial zpos values
> for DRM planes are 1, 3, 0, 2.
>
> In theory the userspace should configure the zpos values properly when
> using multiple planes, and in that sense the initial zpos values
> shouldn't matter, but there's really no reason not to fix this and help
> the userspace apps which don't handle zpos perfectly. In particular,
> Weston seems to have issues dealing with the planes with the current
> default zpos values.
>
> So let's change the zpos values for the DRM planes to 0, 1, 2, 3.
>
> Another option would be to configure the planes marked as primary planes
> to zpos 0. On a two display system this would give us plane zpos values
> of 0, 0, 1, 2. The end result and behavior would be very similar in this
> option, and I'm not aware that this would actually help us in any way.
> So, to keep the code simple, I opted for the 0, 1, 2, 3 values.
>
> Signed-off-by: Tomi Valkeinen
> Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display
> SubSystem")
Reviewed-by: Aradhya Bhatia
> ---
> drivers/gpu/drm/tidss/tidss_plane.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tidss/tidss_plane.c
> b/drivers/gpu/drm/tidss/tidss_plane.c
> index e1c0ef0c3894..68fed531f6a7 100644
> --- a/drivers/gpu/drm/tidss/tidss_plane.c
> +++ b/drivers/gpu/drm/tidss/tidss_plane.c
> @@ -213,7 +213,7 @@ struct tidss_plane *tidss_plane_create(struct
> tidss_device *tidss,
>
> drm_plane_helper_add(>plane, _plane_helper_funcs);
>
> - drm_plane_create_zpos_property(>plane, hw_plane_id, 0,
> + drm_plane_create_zpos_property(>plane, tidss->num_planes, 0,
> num_planes - 1);
>
> ret = drm_plane_create_color_properties(>plane,
>
Re: [PATCH v3 2/2] arm64: dts: ti: Add common1 register space for AM62x, AM62A & AM65x SoCs
Thanks for the fixes, Devarsh!
On 15/02/24 14:02, Devarsh Thakkar wrote:
> This adds common1 register space for AM62x, AM62A and AM65x SoC's which are
> using TI's Keystone display hardware and supporting it as described in
> Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
>
> Fixes: 3618811657b3 ("arm64: dts: ti: k3-am62a-main: Add node for Display
> SubSystem (DSS)")
> Fixes: 8ccc1073c7bb ("arm64: dts: ti: k3-am62-main: Add node for DSS")
> Fixes: fc539b90eda2 ("arm64: dts: ti: am654: Add DSS node")
> Signed-off-by: Devarsh Thakkar
Reviewed-by: Aradhya Bhatia
> ---
> V2: Add common1 region for AM62A SoC too
> V3: Add Fixes tag
> ---
> arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 5 +++--
> arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 5 +++--
> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 5 +++--
> 3 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> index fe0cc4a9a501..8cee4d94cdd3 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> @@ -779,9 +779,10 @@ dss: dss@3020 {
> <0x00 0x30207000 0x00 0x1000>, /* ovr1 */
> <0x00 0x30208000 0x00 0x1000>, /* ovr2 */
> <0x00 0x3020a000 0x00 0x1000>, /* vp1: Used for OLDI */
> - <0x00 0x3020b000 0x00 0x1000>; /* vp2: Used as DPI Out */
> + <0x00 0x3020b000 0x00 0x1000>, /* vp2: Used as DPI Out */
> + <0x00 0x30201000 0x00 0x1000>; /* common1 */
> reg-names = "common", "vidl1", "vid",
> - "ovr1", "ovr2", "vp1", "vp2";
> + "ovr1", "ovr2", "vp1", "vp2", "common1";
> power-domains = <_pds 186 TI_SCI_PD_EXCLUSIVE>;
> clocks = <_clks 186 6>,
><_vp1_clk>,
> diff --git a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
> b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
> index 972971159a62..f475daea548e 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
> @@ -994,9 +994,10 @@ dss: dss@3020 {
> <0x00 0x30207000 0x00 0x1000>, /* ovr1 */
> <0x00 0x30208000 0x00 0x1000>, /* ovr2 */
> <0x00 0x3020a000 0x00 0x1000>, /* vp1: Tied OFF in the
> SoC */
> - <0x00 0x3020b000 0x00 0x1000>; /* vp2: Used as DPI Out */
> + <0x00 0x3020b000 0x00 0x1000>, /* vp2: Used as DPI Out */
> + <0x00 0x30201000 0x00 0x1000>; /* common1 */
> reg-names = "common", "vidl1", "vid",
> - "ovr1", "ovr2", "vp1", "vp2";
> + "ovr1", "ovr2", "vp1", "vp2", "common1";
> power-domains = <_pds 186 TI_SCI_PD_EXCLUSIVE>;
> clocks = <_clks 186 6>,
><_clks 186 0>,
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> index 07010d31350e..ff857117d719 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> @@ -991,9 +991,10 @@ dss: dss@4a0 {
> <0x0 0x04a07000 0x0 0x1000>, /* ovr1 */
> <0x0 0x04a08000 0x0 0x1000>, /* ovr2 */
> <0x0 0x04a0a000 0x0 0x1000>, /* vp1 */
> - <0x0 0x04a0b000 0x0 0x1000>; /* vp2 */
> + <0x0 0x04a0b000 0x0 0x1000>, /* vp2 */
> + <0x0 0x04a01000 0x0 0x1000>; /* common1 */
> reg-names = "common", "vidl1", "vid",
> - "ovr1", "ovr2", "vp1", "vp2";
> + "ovr1", "ovr2", "vp1", "vp2", "common1";
>
> ti,am65x-oldi-io-ctrl = <_oldi_io_ctrl>;
>
Re: [PATCH 0/2] drm/bridge: sii902x: Crash fixes
On 03/01/24 19:01, Tomi Valkeinen wrote: > Two small fixes to sii902x for crashes. > > Signed-off-by: Tomi Valkeinen > --- > Tomi Valkeinen (2): > drm/bridge: sii902x: Fix probing race issue > drm/bridge: sii902x: Fix audio codec unregistration Stress-tested kernel boot on SK-AM62, SK-AM62-LP, SK-AM62A, and I couldn't reproduce the issue. The kernel booted fine every time. For the series, Reviewed-by: Aradhya Bhatia > > drivers/gpu/drm/bridge/sii902x.c | 42 > +++- > 1 file changed, 29 insertions(+), 13 deletions(-) > --- > base-commit: 0c75d52190b8bfa22cdb66e07148aea599c4535d > change-id: 20240103-si902x-fixes-468d7153b8ee > > Best regards,
Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case
On 06/12/23 17:41, Tomi Valkeinen wrote: > Hi, > > On 08/11/2023 14:45, Alexander Stein wrote: >> Hi Tomi, >> >> Am Mittwoch, 8. November 2023, 12:27:21 CET schrieb Tomi Valkeinen: >>> These two patches are needed to make tc358767 work in the >>> DRM_BRIDGE_ATTACH_NO_CONNECTOR case, at least when using a DP connector. >>> >>> I have tested this with TI AM654 EVM with a tc358767 add-on card >>> connected to a DP monitor. >> >> Just a question regarding the usage of this DSI-DP bridge. >> What is the state of the DSI lanes after the DSI host has been >> initialized, >> but before calling atomic_pre_enable? AFAIK this bridge requires LP-11 >> on DSI >> at any time for accessing the AUX channel. + Marek Marek, Alexander, A quick grep tells me that you have added devicetree for tc358767 in DSI to (e)DP mode on other platforms. Could you please test these patches and report if you find any issue? Regards Aradhya > > We haven't received any test reports for the DSI-DP case... I was > looking at the datasheet, and I wonder, why do you say the bridge > requires DSI to be up for the AUX transactions? > > Tomi > >> Best regards, >> Alexander >> >>> Signed-off-by: Tomi Valkeinen >>> --- >>> Changes in v2: >>> - Update the format negotiation patch as discussed in >>> https://lore.kernel.org/all/7ddf0edb-2925-4b7c-ad07-27c030dd0...@ti.com/ - >>> Link to v1: >>> https://lore.kernel.org/r/20231031-tc358767-v1-0-392081ad9f4b@ideasonboard. >>> com >>> >>> --- >>> Aradhya Bhatia (1): >>> drm/bridge: tc358767: Add format negotiation hooks for DPI/DSI to >>> (e)DP >>> >>> Tomi Valkeinen (1): >>> drm/bridge: tc358767: Fix link properties discovery >>> >>> drivers/gpu/drm/bridge/tc358767.c | 32 >>> >>> 1 file changed, 32 insertions(+) >>> --- >>> base-commit: 9d7c8c066916f231ca0ed4e4fce6c4b58ca3e451 >>> change-id: 20231031-tc358767-58e3ebdf95f0 >>> >>> Best regards, >> >> >
Re: [PATCH] drm/panel: re-alphabetize the menu list
On 07/12/23 22:28, Randy Dunlap wrote: > > > On 12/7/23 01:52, Aradhya Bhatia wrote: >> Hi Randy, >> >> Thanks for the patch! >> >> On 07/12/23 11:52, Randy Dunlap wrote: >>> A few of the DRM_PANEL entries have become out of alphabetical order, >>> so move them around a bit to restore alpha order. >>> >>> Signed-off-by: Randy Dunlap >>> Cc: Neil Armstrong >>> Cc: Jessica Zhang >>> Cc: Sam Ravnborg >>> Cc: Maarten Lankhorst >>> Cc: Maxime Ripard >>> Cc: Thomas Zimmermann >>> Cc: David Airlie >>> Cc: Daniel Vetter >>> Cc: dri-devel@lists.freedesktop.org >>> --- >>> drivers/gpu/drm/panel/Kconfig | 90 >>> 1 file changed, 45 insertions(+), 45 deletions(-) >>> >>> diff -- a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig >>> --- a/drivers/gpu/drm/panel/Kconfig >>> +++ b/drivers/gpu/drm/panel/Kconfig >>> @@ -95,34 +95,6 @@ config DRM_PANEL_LVDS >>> handling of power supplies or control signals. It implements automatic >>> backlight handling if the panel is attached to a backlight controller. >>> >>> -config DRM_PANEL_SIMPLE >>> - tristate "support for simple panels (other than eDP ones)" >>> - depends on OF >>> - depends on BACKLIGHT_CLASS_DEVICE >>> - depends on PM >>> - select VIDEOMODE_HELPERS >>> - help >>> - DRM panel driver for dumb non-eDP panels that need at most a regulator >>> - and a GPIO to be powered up. Optionally a backlight can be attached so >>> - that it can be automatically turned off when the panel goes into a >>> - low power state. >>> - >>> -config DRM_PANEL_EDP >>> - tristate "support for simple Embedded DisplayPort panels" >>> - depends on OF >>> - depends on BACKLIGHT_CLASS_DEVICE >>> - depends on PM >>> - select VIDEOMODE_HELPERS >>> - select DRM_DISPLAY_DP_HELPER >>> - select DRM_DISPLAY_HELPER >>> - select DRM_DP_AUX_BUS >>> - select DRM_KMS_HELPER >>> - help >>> - DRM panel driver for dumb eDP panels that need at most a regulator and >>> - a GPIO to be powered up. Optionally a backlight can be attached so >>> - that it can be automatically turned off when the panel goes into a >>> - low power state. >>> - >>> config DRM_PANEL_EBBG_FT8719 >>> tristate "EBBG FT8719 panel driver" >>> depends on OF >>> @@ -317,12 +289,6 @@ config DRM_PANEL_LEADTEK_LTK500HD1829 >>> 24 bit RGB per pixel. It provides a MIPI DSI interface to >>> the host and has a built-in LED backlight. >>> >>> -config DRM_PANEL_SAMSUNG_LD9040 >>> - tristate "Samsung LD9040 RGB/SPI panel" >>> - depends on OF && SPI >>> - depends on BACKLIGHT_CLASS_DEVICE >>> - select VIDEOMODE_HELPERS >>> - >>> config DRM_PANEL_LG_LB035Q02 >>> tristate "LG LB035Q024573 RGB panel" >>> depends on GPIOLIB && OF && SPI >>> @@ -350,6 +316,17 @@ config DRM_PANEL_MAGNACHIP_D53E6EA8966 >>> with the Magnachip D53E6EA8966 panel IC. This panel receives >>> video data via DSI but commands via 9-bit SPI using DBI. >>> >>> +config DRM_PANEL_MANTIX_MLAF057WE51 >>> + tristate "Mantix MLAF057WE51-X MIPI-DSI LCD panel" >>> + depends on OF >>> + depends on DRM_MIPI_DSI >>> + depends on BACKLIGHT_CLASS_DEVICE >>> + help >>> + Say Y here if you want to enable support for the Mantix >>> + MLAF057WE51-X MIPI DSI panel as e.g. used in the Librem 5. It >>> + has a resolution of 720x1440 pixels, a built in backlight and touch >>> + controller. >>> + >>> config DRM_PANEL_NEC_NL8048HL11 >>> tristate "NEC NL8048HL11 RGB panel" >>> depends on GPIOLIB && OF && SPI >>> @@ -438,17 +415,6 @@ config DRM_PANEL_NOVATEK_NT39016 >>> Say Y here if you want to enable support for the panels built >>> around the Novatek NT39016 display controller. >>> >>> -config DRM_PANEL_MANTIX_MLAF057WE51 >>> - tristate "Mantix MLAF057WE51-X MIPI-DSI LCD panel" >>> - depends on OF >>> - depends on DRM_MIPI_DSI >>> - depends on BACKLIGHT_
Re: [PATCH] drm/panel: re-alphabetize the menu list
Hi Randy, Thanks for the patch! On 07/12/23 11:52, Randy Dunlap wrote: > A few of the DRM_PANEL entries have become out of alphabetical order, > so move them around a bit to restore alpha order. > > Signed-off-by: Randy Dunlap > Cc: Neil Armstrong > Cc: Jessica Zhang > Cc: Sam Ravnborg > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Cc: dri-devel@lists.freedesktop.org > --- > drivers/gpu/drm/panel/Kconfig | 90 > 1 file changed, 45 insertions(+), 45 deletions(-) > > diff -- a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > --- a/drivers/gpu/drm/panel/Kconfig > +++ b/drivers/gpu/drm/panel/Kconfig > @@ -95,34 +95,6 @@ config DRM_PANEL_LVDS > handling of power supplies or control signals. It implements automatic > backlight handling if the panel is attached to a backlight controller. > > -config DRM_PANEL_SIMPLE > - tristate "support for simple panels (other than eDP ones)" > - depends on OF > - depends on BACKLIGHT_CLASS_DEVICE > - depends on PM > - select VIDEOMODE_HELPERS > - help > - DRM panel driver for dumb non-eDP panels that need at most a regulator > - and a GPIO to be powered up. Optionally a backlight can be attached so > - that it can be automatically turned off when the panel goes into a > - low power state. > - > -config DRM_PANEL_EDP > - tristate "support for simple Embedded DisplayPort panels" > - depends on OF > - depends on BACKLIGHT_CLASS_DEVICE > - depends on PM > - select VIDEOMODE_HELPERS > - select DRM_DISPLAY_DP_HELPER > - select DRM_DISPLAY_HELPER > - select DRM_DP_AUX_BUS > - select DRM_KMS_HELPER > - help > - DRM panel driver for dumb eDP panels that need at most a regulator and > - a GPIO to be powered up. Optionally a backlight can be attached so > - that it can be automatically turned off when the panel goes into a > - low power state. > - > config DRM_PANEL_EBBG_FT8719 > tristate "EBBG FT8719 panel driver" > depends on OF > @@ -317,12 +289,6 @@ config DRM_PANEL_LEADTEK_LTK500HD1829 > 24 bit RGB per pixel. It provides a MIPI DSI interface to > the host and has a built-in LED backlight. > > -config DRM_PANEL_SAMSUNG_LD9040 > - tristate "Samsung LD9040 RGB/SPI panel" > - depends on OF && SPI > - depends on BACKLIGHT_CLASS_DEVICE > - select VIDEOMODE_HELPERS > - > config DRM_PANEL_LG_LB035Q02 > tristate "LG LB035Q024573 RGB panel" > depends on GPIOLIB && OF && SPI > @@ -350,6 +316,17 @@ config DRM_PANEL_MAGNACHIP_D53E6EA8966 > with the Magnachip D53E6EA8966 panel IC. This panel receives > video data via DSI but commands via 9-bit SPI using DBI. > > +config DRM_PANEL_MANTIX_MLAF057WE51 > + tristate "Mantix MLAF057WE51-X MIPI-DSI LCD panel" > + depends on OF > + depends on DRM_MIPI_DSI > + depends on BACKLIGHT_CLASS_DEVICE > + help > + Say Y here if you want to enable support for the Mantix > + MLAF057WE51-X MIPI DSI panel as e.g. used in the Librem 5. It > + has a resolution of 720x1440 pixels, a built in backlight and touch > + controller. > + > config DRM_PANEL_NEC_NL8048HL11 > tristate "NEC NL8048HL11 RGB panel" > depends on GPIOLIB && OF && SPI > @@ -438,17 +415,6 @@ config DRM_PANEL_NOVATEK_NT39016 > Say Y here if you want to enable support for the panels built > around the Novatek NT39016 display controller. > > -config DRM_PANEL_MANTIX_MLAF057WE51 > - tristate "Mantix MLAF057WE51-X MIPI-DSI LCD panel" > - depends on OF > - depends on DRM_MIPI_DSI > - depends on BACKLIGHT_CLASS_DEVICE > - help > - Say Y here if you want to enable support for the Mantix > - MLAF057WE51-X MIPI DSI panel as e.g. used in the Librem 5. It > - has a resolution of 720x1440 pixels, a built in backlight and touch > - controller. > - > config DRM_PANEL_OLIMEX_LCD_OLINUXINO > tristate "Olimex LCD-OLinuXino panel" > depends on OF > @@ -566,6 +532,12 @@ config DRM_PANEL_SAMSUNG_DB7430 > DB7430 DPI display controller used in such devices as the > LMS397KF04 480x800 DPI panel. > > +config DRM_PANEL_SAMSUNG_LD9040 > + tristate "Samsung LD9040 RGB/SPI panel" > + depends on OF && SPI > + depends on BACKLIGHT_CLASS_DEVICE > + select VIDEOMODE_HELPERS > + > config DRM_PANEL_SAMSUNG_S6D16D0 > tristate "Samsung S6D16D0 DSI video mode panel" > depends on OF > @@ -774,6 +746,34 @@ config DRM_PANEL_STARTEK_KD070FHFID015 > with a resolution of 1024 x 600 pixels. It provides a MIPI DSI > interface to > the host, a built-in LED backlight and touch controller. > > +config DRM_PANEL_EDP > + tristate "support for simple Embedded DisplayPort panels" > + depends on OF > + depends on
Re: [PATCH v2 00/11] drm/tidss: Probe related fixes and cleanups
Hi Tomi, Thank you for the patches! On 09/11/23 13:07, Tomi Valkeinen wrote: > While working on the TI BSP kernel, adding bootload splash screen > support, I noticed some issues with the driver and opportunities for > cleanups and improvements. > > Tomi > > Signed-off-by: Tomi Valkeinen > --- > Changes in v2: > - Add missing pm_runtime_dont_use_autosuspend() in error path > - Add simple manual "reset" for K2G > - Leave tidss->dispc NULL if dispc_init fails > - Add Fixes tags > - Drop "drm/tidss: Add dispc_is_idle()" > - Add "drm/tidss: Use DRM_PLANE_COMMIT_ACTIVE_ONLY" > - Link to v1: > https://lore.kernel.org/r/20231101-tidss-probe-v1-0-45149e0f9...@ideasonboard.com > > --- > Tomi Valkeinen (11): > drm/tidss: Use pm_runtime_resume_and_get() > drm/tidss: Use PM autosuspend > drm/tidss: Drop useless variable init > drm/tidss: Move reset to the end of dispc_init() > drm/tidss: Return error value from from softreset > drm/tidss: Check for K2G in in dispc_softreset() > drm/tidss: Add simple K2G manual reset > drm/tidss: Fix dss reset > drm/tidss: IRQ code cleanup > drm/tidss: Fix atomic_flush check > drm/tidss: Use DRM_PLANE_COMMIT_ACTIVE_ONLY For the series, Reviewed-by: Aradhya Bhatia Regards Aradhya > > drivers/gpu/drm/tidss/tidss_crtc.c | 12 ++ > drivers/gpu/drm/tidss/tidss_dispc.c | 79 > + > drivers/gpu/drm/tidss/tidss_drv.c | 15 +-- > drivers/gpu/drm/tidss/tidss_irq.c | 54 - > drivers/gpu/drm/tidss/tidss_kms.c | 2 +- > 5 files changed, 97 insertions(+), 65 deletions(-) > --- > base-commit: 9d7c8c066916f231ca0ed4e4fce6c4b58ca3e451 > change-id: 20231030-tidss-probe-854b1098c3af > > Best regards,
[PATCH v3 2/2] drivers/tidss: Add support for AM62A7 DSS
Add support for the DSS controller on TI's AM62A7 SoC in the tidss
driver.
This controller has 2 video pipelines that can render 2 video planes on
over a screen, using the overlay managers. The output of the DSS comes
from video port 2 (VP2) in the form of RGB88 DPI signals, while the VP1
is tied off inside the SoC.
Also add and use a new type of VP, DISPC_VP_TIED_OFF, for the tied-off
VP1 of AM62A DSS.
Signed-off-by: Aradhya Bhatia
---
Notes:
Changes from V2:
* Add new DISPC_VP_TIED_OFF for tied-off video-ports.
Changes from V1:
* Correctly sort DISPC_AM62A7 macro after DISPC_AM625.
drivers/gpu/drm/tidss/tidss_dispc.c | 59 +
drivers/gpu/drm/tidss/tidss_dispc.h | 3 ++
drivers/gpu/drm/tidss/tidss_drv.c | 1 +
3 files changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index 9d9dee7abaef..7af416457c57 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -322,6 +322,60 @@ const struct dispc_features dispc_am625_feats = {
.vid_order = { 1, 0 },
};
+const struct dispc_features dispc_am62a7_feats = {
+ /*
+* if the code reaches dispc_mode_valid with VP1,
+* it should return MODE_BAD.
+*/
+ .max_pclk_khz = {
+ [DISPC_VP_TIED_OFF] = 0,
+ [DISPC_VP_DPI] = 165000,
+ },
+
+ .scaling = {
+ .in_width_max_5tap_rgb = 1280,
+ .in_width_max_3tap_rgb = 2560,
+ .in_width_max_5tap_yuv = 2560,
+ .in_width_max_3tap_yuv = 4096,
+ .upscale_limit = 16,
+ .downscale_limit_5tap = 4,
+ .downscale_limit_3tap = 2,
+ /*
+* The max supported pixel inc value is 255. The value
+* of pixel inc is calculated like this: 1+(xinc-1)*bpp.
+* The maximum bpp of all formats supported by the HW
+* is 8. So the maximum supported xinc value is 32,
+* because 1+(32-1)*8 < 255 < 1+(33-1)*4.
+*/
+ .xinc_max = 32,
+ },
+
+ .subrev = DISPC_AM62A7,
+
+ .common = "common",
+ .common_regs = tidss_am65x_common_regs,
+
+ .num_vps = 2,
+ .vp_name = { "vp1", "vp2" },
+ .ovr_name = { "ovr1", "ovr2" },
+ .vpclk_name = { "vp1", "vp2" },
+ /* VP1 of the DSS in AM62A7 SoC is tied off internally */
+ .vp_bus_type = { DISPC_VP_TIED_OFF, DISPC_VP_DPI },
+
+ .vp_feat = { .color = {
+ .has_ctm = true,
+ .gamma_size = 256,
+ .gamma_type = TIDSS_GAMMA_8BIT,
+ },
+ },
+
+ .num_planes = 2,
+ /* note: vid is plane_id 0 and vidl1 is plane_id 1 */
+ .vid_name = { "vid", "vidl1" },
+ .vid_lite = { false, true, },
+ .vid_order = { 1, 0 },
+};
+
static const u16 *dispc_common_regmap;
struct dss_vp_data {
@@ -824,6 +878,7 @@ dispc_irq_t dispc_read_and_clear_irqstatus(struct
dispc_device *dispc)
case DISPC_K2G:
return dispc_k2g_read_and_clear_irqstatus(dispc);
case DISPC_AM625:
+ case DISPC_AM62A7:
case DISPC_AM65X:
case DISPC_J721E:
return dispc_k3_read_and_clear_irqstatus(dispc);
@@ -840,6 +895,7 @@ void dispc_set_irqenable(struct dispc_device *dispc,
dispc_irq_t mask)
dispc_k2g_set_irqenable(dispc, mask);
break;
case DISPC_AM625:
+ case DISPC_AM62A7:
case DISPC_AM65X:
case DISPC_J721E:
dispc_k3_set_irqenable(dispc, mask);
@@ -1331,6 +1387,7 @@ void dispc_ovr_set_plane(struct dispc_device *dispc, u32
hw_plane,
x, y, layer);
break;
case DISPC_AM625:
+ case DISPC_AM62A7:
case DISPC_AM65X:
dispc_am65x_ovr_set_plane(dispc, hw_plane, hw_videoport,
x, y, layer);
@@ -2250,6 +2307,7 @@ static void dispc_plane_init(struct dispc_device *dispc)
dispc_k2g_plane_init(dispc);
break;
case DISPC_AM625:
+ case DISPC_AM62A7:
case DISPC_AM65X:
case DISPC_J721E:
dispc_k3_plane_init(dispc);
@@ -2357,6 +2415,7 @@ static void dispc_vp_write_gamma_table(struct
dispc_device *dispc,
dispc_k2g_vp_write_gamma_table(dispc, hw_videoport);
break;
case DISPC_AM625:
+ case DISPC_AM62A7:
case DISPC_AM65X:
dispc_am65x_vp_write_gamma_table(dispc, hw_videoport);
break;
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.h
b/drivers/gpu/drm/tidss/tidss_dispc.h
index 33ac5ad7a423..086327d51a90 100644
--- a/driver
[PATCH v3 1/2] dt-bindings: display: ti: Add support for am62a7 dss
The DSS controller on TI's AM62A7 SoC is an update from that on TI's AM625 SoC. Like the DSS in AM625, the DSS in this SoC has 2 video pipelines, but unlike the former, the latter only has one output port on VP2 to service DPI display sinks. Add the new controller's compatible. Signed-off-by: Aradhya Bhatia Reviewed-by: Krzysztof Kozlowski --- .../bindings/display/ti/ti,am65x-dss.yaml | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml index ae09cd3cbce1..b6767ef0d24d 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml @@ -23,6 +23,7 @@ properties: compatible: enum: - ti,am625-dss + - ti,am62a7,dss - ti,am65x-dss reg: @@ -87,6 +88,7 @@ properties: For AM65x DSS, the OLDI output port node from video port 1. For AM625 DSS, the internal DPI output port node from video port 1. + For AM62A7 DSS, the port is tied off inside the SoC. port@1: $ref: /schemas/graph.yaml#/properties/port @@ -108,6 +110,18 @@ properties: Input memory (from main memory to dispc) bandwidth limit in bytes per second +allOf: + - if: + properties: +compatible: + contains: +const: ti,am62a7-dss +then: + properties: +ports: + properties: +port@0: false + required: - compatible - reg -- 2.42.0
[PATCH v3 0/2] Add DSS support for TI AM62A7 SoC
This patch series adds a new compatible for the Display SubSystem (DSS) controller on TI's AM62A7 SoC. It further adds the required support, for the same, in the tidss driver. The DSS controller is similar to the recently added AM625 DSS, with the key difference being the absence of VP1 output on the SoC. The VP1 in AM62A7 DSS is tied off and cannot be used, unlike in AM625, where the VP1 was connected to 2 OLDI TXes. The video pipeline that corresponds to VP1 still exists and can be used to overlay planes on the VP2's primary plane. This can be done using the overlay managers inside the SoC. Moreover, DSS VP2 can output Full-HD RGB888 DPI video signals. I have tested these patches on AM62A7 SK-EVM, which converts DPI signals to HDMI on the platform using the Sil9022A HDMI transmitter. All the patches, required to enable display on AM62A7-SK, can be found on my github fork[0] in the branch "next_am62a-v3". Regards Aradhya [0]: https://github.com/aradhya07/linux-ab/tree/next_am62a-v3 Change Log: V2 -> V3: - Add Krzysztof Kozlowski's R-b in patch 1/2. - Add new DISPC_VP_TIED_OFF for tied-off video-ports in patch 2/2. V1 -> V2: - Correctly sort DISPC_AM62A7 macro after DISPC_AM625 in patch 2/2. Previous Versions: V1: https://lore.kernel.org/all/20230818131750.4779-1-a-bhat...@ti.com/ V2: https://lore.kernel.org/all/20230818142124.8561-1-a-bhat...@ti.com/ Aradhya Bhatia (2): dt-bindings: display: ti: Add support for am62a7 dss drivers/tidss: Add support for AM62A7 DSS .../bindings/display/ti/ti,am65x-dss.yaml | 14 + drivers/gpu/drm/tidss/tidss_dispc.c | 59 +++ drivers/gpu/drm/tidss/tidss_dispc.h | 3 + drivers/gpu/drm/tidss/tidss_drv.c | 1 + 4 files changed, 77 insertions(+) base-commit: 2220f68f4504aa1ccce0fac721ccdb301e9da32f -- 2.42.0
Re: [PATCH] drm/bridge: tc358767: Support input format negotiation hook
Hi Sam,
On 07-Nov-23 21:11, Sam Ravnborg wrote:
> Hi Aradhya,
>
> On Tue, Nov 07, 2023 at 01:17:03AM +0530, Aradhya Bhatia wrote:
>> Hi Sam,
>>
>> Thank you for the suggestion!
>>
>> On 06-Nov-23 18:08, Sam Ravnborg wrote:
>>> Hi Aradhya,
>>>
>>> On Tue, Oct 31, 2023 at 12:58:46AM +0530, Aradhya Bhatia wrote:
>>>> With new connector model, tc358767 will not create the connector, when
>>>> DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will
>>>> rely on format negotiation to setup the encoder format.
>>>>
>>>> Add the missing input-format negotiation hook in the
>>>> drm_bridge_funcs to complete DRM_BRIDGE_ATTACH_NO_CONNECTOR support.
>>>>
>>>> Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is
>>>> the case with older model.
>>>>
>>>> Reported-by: Jan Kiszka
>>>> Signed-off-by: Aradhya Bhatia
>>>> ---
>>>>
>>>> Notes:
>>>>
>>>> * Since I do not have hardware with me, this was just build tested. I
>>>> would
>>>> appreciate it if someone could test and review it, especically
>>>> somebody, who
>>>> uses the bridge for DPI/DSI to eDP format conversion.
>>>>
>>>> * The Toshiba TC358767 bridge is not enabled in arm64 defconfig by
>>>> default,
>>>> when it should be. Hence, I sent a quick patch[0] earlier.
>>>>
>>>> [0]: https://lore.kernel.org/all/20231030152834.18450-1-a-bhat...@ti.com/
>>>>
>>>> drivers/gpu/drm/bridge/tc358767.c | 25 +
>>>> 1 file changed, 25 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/tc358767.c
>>>> b/drivers/gpu/drm/bridge/tc358767.c
>>>> index ef2e373606ba..0affcefdeb1c 100644
>>>> --- a/drivers/gpu/drm/bridge/tc358767.c
>>>> +++ b/drivers/gpu/drm/bridge/tc358767.c
>>>> @@ -1751,6 +1751,30 @@ tc_dpi_atomic_get_input_bus_fmts(struct drm_bridge
>>>> *bridge,
>>>>return input_fmts;
>>>> }
>>>>
>>>> +static u32 *
>>>> +tc_edp_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
>>>> + struct drm_bridge_state *bridge_state,
>>>> + struct drm_crtc_state *crtc_state,
>>>> + struct drm_connector_state *conn_state,
>>>> + u32 output_fmt,
>>>> + unsigned int *num_input_fmts)
>>>> +{
>>>> + u32 *input_fmts;
>>>> +
>>>> + *num_input_fmts = 0;
>>>> +
>>>> + input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
>>>> + GFP_KERNEL);
>>>> + if (!input_fmts)
>>>> + return NULL;
>>>> +
>>>> + /* This is the DSI/DPI-end bus format */
>>>> + input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
>>>> + *num_input_fmts = 1;
>>>> +
>>>> + return input_fmts;
>>>> +}
>>>
>>> You could benefit from using the helper:
>>> drm_atomic_helper_bridge_propagate_bus_fmt()
>>
>> You are right!
>>
>> Upon taking a second look, I realize that the bridge chain works with
>> MEDIA_BUS_FMT_FIXED bus format, when tc358767 is being used in DPI/DSI
>> to eDP mode (because the panel-bridge does not have a get_output_bus_fmt
>> hook, and uses the same helper for its get_input_bus_fmt hook). My patch
>> creates a deviation from that, by forcing MEDIA_BUS_FMT_RGB888_1X24 even
>> when eDP is involved.
>>
>> Using the helper here, will certainly address this deviation.
>>
>> However, for the DPI/DSI to DP mode, MEDIA_BUS_FMT_RGB888_1X24 bus
>> format is required, and *just* using the helper as its get_input_bus_fmt
>> hook, might not be enough.
>>
>> Since tc358767 is the last bridge in DPI/DSI to DP mode, the
>> output_fmt parameter get defaulted to MEDIA_BUS_FMT_FIXED too, as there
>> is no get_output_bus_fmt hook present in the driver. If we simply us
>> the helper here, the input_fmt will also get set to MEDIA_BUS_FMT_FIXED.
>> This too is an unwanted deviation.
>>
>> It seems like the right way to address both the cases, would be by
>> adding the get_output_bus_fmt hook that sets output_fmt to
>> MEDIA_BUS_FMT_RGB888_1X24, as well as using the helper as the
>> get_input_bus_fmt hook.
>>
>> If this seems good to you too, I will send a new version of Tomi's
>> series[0] which incorporates this patch.
>
> I never managed to fully wrap my head around the bus fmt negotiation,
> and as I am trying to recover from a flu this is not the time to try.
> Your explanations sounds like you have grasped it so I suggest to move
> ahead.
>
Sure, I will send a new version.
Hope you recover soon! =)
Regards
Aradhya
Re: [PATCH] drm/bridge: tc358767: Support input format negotiation hook
Hi Sam,
Thank you for the suggestion!
On 06-Nov-23 18:08, Sam Ravnborg wrote:
> Hi Aradhya,
>
> On Tue, Oct 31, 2023 at 12:58:46AM +0530, Aradhya Bhatia wrote:
>> With new connector model, tc358767 will not create the connector, when
>> DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will
>> rely on format negotiation to setup the encoder format.
>>
>> Add the missing input-format negotiation hook in the
>> drm_bridge_funcs to complete DRM_BRIDGE_ATTACH_NO_CONNECTOR support.
>>
>> Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is
>> the case with older model.
>>
>> Reported-by: Jan Kiszka
>> Signed-off-by: Aradhya Bhatia
>> ---
>>
>> Notes:
>>
>> * Since I do not have hardware with me, this was just build tested. I would
>> appreciate it if someone could test and review it, especically somebody,
>> who
>> uses the bridge for DPI/DSI to eDP format conversion.
>>
>> * The Toshiba TC358767 bridge is not enabled in arm64 defconfig by default,
>> when it should be. Hence, I sent a quick patch[0] earlier.
>>
>> [0]: https://lore.kernel.org/all/20231030152834.18450-1-a-bhat...@ti.com/
>>
>> drivers/gpu/drm/bridge/tc358767.c | 25 +
>> 1 file changed, 25 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/tc358767.c
>> b/drivers/gpu/drm/bridge/tc358767.c
>> index ef2e373606ba..0affcefdeb1c 100644
>> --- a/drivers/gpu/drm/bridge/tc358767.c
>> +++ b/drivers/gpu/drm/bridge/tc358767.c
>> @@ -1751,6 +1751,30 @@ tc_dpi_atomic_get_input_bus_fmts(struct drm_bridge
>> *bridge,
>> return input_fmts;
>> }
>>
>> +static u32 *
>> +tc_edp_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
>> + struct drm_bridge_state *bridge_state,
>> + struct drm_crtc_state *crtc_state,
>> + struct drm_connector_state *conn_state,
>> + u32 output_fmt,
>> + unsigned int *num_input_fmts)
>> +{
>> +u32 *input_fmts;
>> +
>> +*num_input_fmts = 0;
>> +
>> +input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
>> + GFP_KERNEL);
>> +if (!input_fmts)
>> +return NULL;
>> +
>> +/* This is the DSI/DPI-end bus format */
>> +input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
>> +*num_input_fmts = 1;
>> +
>> +return input_fmts;
>> +}
>
> You could benefit from using the helper:
> drm_atomic_helper_bridge_propagate_bus_fmt()
You are right!
Upon taking a second look, I realize that the bridge chain works with
MEDIA_BUS_FMT_FIXED bus format, when tc358767 is being used in DPI/DSI
to eDP mode (because the panel-bridge does not have a get_output_bus_fmt
hook, and uses the same helper for its get_input_bus_fmt hook). My patch
creates a deviation from that, by forcing MEDIA_BUS_FMT_RGB888_1X24 even
when eDP is involved.
Using the helper here, will certainly address this deviation.
However, for the DPI/DSI to DP mode, MEDIA_BUS_FMT_RGB888_1X24 bus
format is required, and *just* using the helper as its get_input_bus_fmt
hook, might not be enough.
Since tc358767 is the last bridge in DPI/DSI to DP mode, the
output_fmt parameter get defaulted to MEDIA_BUS_FMT_FIXED too, as there
is no get_output_bus_fmt hook present in the driver. If we simply us
the helper here, the input_fmt will also get set to MEDIA_BUS_FMT_FIXED.
This too is an unwanted deviation.
It seems like the right way to address both the cases, would be by
adding the get_output_bus_fmt hook that sets output_fmt to
MEDIA_BUS_FMT_RGB888_1X24, as well as using the helper as the
get_input_bus_fmt hook.
If this seems good to you too, I will send a new version of Tomi's
series[0] which incorporates this patch.
Regards
Aradhya
[0]:
https://lore.kernel.org/all/20231031-tc358767-v1-0-392081ad9...@ideasonboard.com/
Re: [PATCH] drm/tilcdc: Fix irq free on unload
On 19-Sep-23 12:42, Tomi Valkeinen wrote:
> The driver only frees the reserved irq if priv->irq_enabled is set to
> true. However, the driver mistakenly sets priv->irq_enabled to false,
> instead of true, in tilcdc_irq_install(), and thus the driver never
> frees the irq, causing issues on loading the driver a second time.
>
> Fixes: b6366814fa77 ("drm/tilcdc: Convert to Linux IRQ interfaces")
> Cc: Thomas Zimmermann
> Signed-off-by: Tomi Valkeinen
> ---
Reviewed-by: Aradhya Bhatia
Regards
Aradhya
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index fe56beea3e93..83233bdc0526 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -138,7 +138,7 @@ static int tilcdc_irq_install(struct drm_device *dev,
> unsigned int irq)
> if (ret)
> return ret;
>
> - priv->irq_enabled = false;
> + priv->irq_enabled = true;
>
> return 0;
> }
>
> ---
> base-commit: 0663e1da5ba8e6459e3555ac12c62741668c0d30
> change-id: 20230919-lcdc-9e09e94f4e93
>
> Best regards,
Re: [PATCH 2/2] drm/bridge: tc358767: Fix link properties discovery
On 31-Oct-23 18:56, Tomi Valkeinen wrote:
> When a display controller driver uses DRM_BRIDGE_ATTACH_NO_CONNECTOR,
> tc358767 will behave properly and skip the creation of the connector.
>
> However, tc_get_display_props(), which is used to find out about the DP
> monitor and link, is only called from two places: .atomic_enable() and
> tc_connector_get_modes(). The latter is only used when tc358767 creates
> its own connector, i.e. when DRM_BRIDGE_ATTACH_NO_CONNECTOR is _not_
> set.
>
> Thus, the driver never finds out the link properties before get_edid()
> is called. With num_lanes of 0 and link_rate of 0 there are not many
> valid modes...
>
> Fix this by adding tc_connector_get_modes() call at the beginning of
> get_edid(), so that we have up to date information before looking at the
> modes.
>
> Reported-by: Jan Kiszka
> Closes:
> https://lore.kernel.org/all/24282420-b4dd-45b3-bb1c-fc37fe4a8...@siemens.com/
> Signed-off-by: Tomi Valkeinen
> ---
Thank you, Tomi, for quickly debugging this!
Reviewed-by: Aradhya Bhatia
Regards
Aradhya
> drivers/gpu/drm/bridge/tc358767.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index 0affcefdeb1c..137a9f5e3cad 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -1579,6 +1579,13 @@ static struct edid *tc_get_edid(struct drm_bridge
> *bridge,
> struct drm_connector *connector)
> {
> struct tc_data *tc = bridge_to_tc(bridge);
> + int ret;
> +
> + ret = tc_get_display_props(tc);
> + if (ret < 0) {
> + dev_err(tc->dev, "failed to read display props: %d\n", ret);
> + return 0;
> + }
>
> return drm_get_edid(connector, >aux.ddc);
> }
>
[PATCH] drm/bridge: tc358767: Support input format negotiation hook
With new connector model, tc358767 will not create the connector, when
DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will
rely on format negotiation to setup the encoder format.
Add the missing input-format negotiation hook in the
drm_bridge_funcs to complete DRM_BRIDGE_ATTACH_NO_CONNECTOR support.
Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is
the case with older model.
Reported-by: Jan Kiszka
Signed-off-by: Aradhya Bhatia
---
Notes:
* Since I do not have hardware with me, this was just build tested. I would
appreciate it if someone could test and review it, especically somebody, who
uses the bridge for DPI/DSI to eDP format conversion.
* The Toshiba TC358767 bridge is not enabled in arm64 defconfig by default,
when it should be. Hence, I sent a quick patch[0] earlier.
[0]: https://lore.kernel.org/all/20231030152834.18450-1-a-bhat...@ti.com/
drivers/gpu/drm/bridge/tc358767.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index ef2e373606ba..0affcefdeb1c 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1751,6 +1751,30 @@ tc_dpi_atomic_get_input_bus_fmts(struct drm_bridge
*bridge,
return input_fmts;
}
+static u32 *
+tc_edp_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+struct drm_bridge_state *bridge_state,
+struct drm_crtc_state *crtc_state,
+struct drm_connector_state *conn_state,
+u32 output_fmt,
+unsigned int *num_input_fmts)
+{
+ u32 *input_fmts;
+
+ *num_input_fmts = 0;
+
+ input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
+GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+
+ /* This is the DSI/DPI-end bus format */
+ input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+ *num_input_fmts = 1;
+
+ return input_fmts;
+}
+
static const struct drm_bridge_funcs tc_dpi_bridge_funcs = {
.attach = tc_dpi_bridge_attach,
.mode_valid = tc_dpi_mode_valid,
@@ -1777,6 +1801,7 @@ static const struct drm_bridge_funcs tc_edp_bridge_funcs
= {
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_get_input_bus_fmts = tc_edp_atomic_get_input_bus_fmts,
};
static bool tc_readable_reg(struct device *dev, unsigned int reg)
base-commit: c503e3eec382ac708ee7adf874add37b77c5d312
--
2.42.0
Re: [PATCH v7 7/8] drm/tidss: Update encoder/bridge chain connect model
On 30-Oct-23 14:55, Jan Kiszka wrote:
> On 06.06.23 10:21, Aradhya Bhatia wrote:
>> With the new encoder/bridge chain model, the display controller driver
>> is required to create a drm_connector entity instead of asking the
>> bridge to do so during drm_bridge_attach. Moreover, the controller
>> driver should create a drm_bridge entity to negotiate bus formats and a
>> 'simple' drm_encoder entity to expose it to userspace.
>>
>> Update the encoder/bridge initialization sequence in tidss as per the
>> new model.
>>
>> Signed-off-by: Aradhya Bhatia
>> ---
>>
>> Notes:
>>
>> changes from v5:
>> * Drop patches 5 and 6 from the original series.
>> * Instead add this patch that addresses Boris Brezillon's comments
>> of creating bridge, simple encoder and connector.
>>
>> drivers/gpu/drm/tidss/tidss_encoder.c | 140 --
>> drivers/gpu/drm/tidss/tidss_encoder.h | 5 +-
>> drivers/gpu/drm/tidss/tidss_kms.c | 12 +--
>> 3 files changed, 94 insertions(+), 63 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tidss/tidss_encoder.c
>> b/drivers/gpu/drm/tidss/tidss_encoder.c
>> index 0d4865e9c03d..17a86bed8054 100644
>> --- a/drivers/gpu/drm/tidss/tidss_encoder.c
>> +++ b/drivers/gpu/drm/tidss/tidss_encoder.c
>> @@ -6,91 +6,125 @@
>>
>> #include
>>
>> +#include
>> +#include
>> +#include
>> #include
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "tidss_crtc.h"
>> #include "tidss_drv.h"
>> #include "tidss_encoder.h"
>>
>> -static int tidss_encoder_atomic_check(struct drm_encoder *encoder,
>> - struct drm_crtc_state *crtc_state,
>> - struct drm_connector_state *conn_state)
>> +struct tidss_encoder {
>> +struct drm_bridge bridge;
>> +struct drm_encoder encoder;
>> +struct drm_connector *connector;
>> +struct drm_bridge *next_bridge;
>> +struct tidss_device *tidss;
>> +};
>> +
>> +static inline struct tidss_encoder
>> +*bridge_to_tidss_encoder(struct drm_bridge *b)
>> +{
>> +return container_of(b, struct tidss_encoder, bridge);
>> +}
>> +
>> +static int tidss_bridge_attach(struct drm_bridge *bridge,
>> + enum drm_bridge_attach_flags flags)
>> +{
>> +struct tidss_encoder *t_enc = bridge_to_tidss_encoder(bridge);
>> +
>> +return drm_bridge_attach(bridge->encoder, t_enc->next_bridge,
>> + bridge, flags);
>> +}
>> +
>> +static int tidss_bridge_atomic_check(struct drm_bridge *bridge,
>> + struct drm_bridge_state *bridge_state,
>> + struct drm_crtc_state *crtc_state,
>> + struct drm_connector_state *conn_state)
>> {
>> -struct drm_device *ddev = encoder->dev;
>> +struct tidss_encoder *t_enc = bridge_to_tidss_encoder(bridge);
>> +struct tidss_device *tidss = t_enc->tidss;
>> struct tidss_crtc_state *tcrtc_state = to_tidss_crtc_state(crtc_state);
>> struct drm_display_info *di = _state->connector->display_info;
>> -struct drm_bridge *bridge;
>> -bool bus_flags_set = false;
>> -
>> -dev_dbg(ddev->dev, "%s\n", __func__);
>> -
>> -/*
>> - * Take the bus_flags from the first bridge that defines
>> - * bridge timings, or from the connector's display_info if no
>> - * bridge defines the timings.
>> - */
>> -drm_for_each_bridge_in_chain(encoder, bridge) {
>> -if (!bridge->timings)
>> -continue;
>> -
>> -tcrtc_state->bus_flags = bridge->timings->input_bus_flags;
>> -bus_flags_set = true;
>> -break;
>> -}
>> +struct drm_bridge_state *next_bridge_state = NULL;
>> +
>> +if (t_enc->next_bridge)
>> +next_bridge_state =
>> drm_atomic_get_new_bridge_state(crtc_state->state,
>> +
>> t_enc->next_bridge);
>>
>> -if (!di->bus_formats || di->num_bus_formats == 0) {
>> -dev_err(ddev->dev, "%s: No bus_formats in connected display\n",
>> +if (next_bridge_state) {
>> +tcrtc_state-&
Re: [PATCH 2/2] Revert "drm/omapdrm: Annotate dma-fence critical section in commit path"
_set+0x48/0x5c
> drm_bridge_chain_mode_set from crtc_set_mode+0x188/0x1d0
> crtc_set_mode from omap_atomic_commit_tail+0x2c/0xbc
> omap_atomic_commit_tail from commit_tail+0x9c/0x188
> commit_tail from drm_atomic_helper_commit+0x158/0x18c
> drm_atomic_helper_commit from drm_atomic_commit+0xa4/0xe8
> drm_atomic_commit from drm_mode_atomic_ioctl+0x9a4/0xc38
> drm_mode_atomic_ioctl from drm_ioctl+0x210/0x4a8
> drm_ioctl from sys_ioctl+0x138/0xf00
> sys_ioctl from ret_fast_syscall+0x0/0x1c
> Exception stack(0xf1011fa8 to 0xf1011ff0)
> 1fa0: 00466d58 be9ab510 0003 c03864bc be9ab510 be9ab4e0
> 1fc0: 00466d58 be9ab510 c03864bc 0036 00466ef0 00466fc0 00467020 00466f20
> 1fe0: b6bc7ef4 be9ab4d0 b600 b6cb2cc0
>
> Fixes: 250aa22920cd ("drm/omapdrm: Annotate dma-fence critical section in
> commit path")
> Signed-off-by: Tomi Valkeinen
> ---
Reviewed-by: Aradhya Bhatia
Regards
Aradhya
> drivers/gpu/drm/omapdrm/omap_drv.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index afeeb7737552..e000577a95dd 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -69,7 +69,6 @@ static void omap_atomic_commit_tail(struct drm_atomic_state
> *old_state)
> {
> struct drm_device *dev = old_state->dev;
> struct omap_drm_private *priv = dev->dev_private;
> - bool fence_cookie = dma_fence_begin_signalling();
>
> dispc_runtime_get(priv->dispc);
>
> @@ -92,6 +91,8 @@ static void omap_atomic_commit_tail(struct drm_atomic_state
> *old_state)
> omap_atomic_wait_for_completion(dev, old_state);
>
> drm_atomic_helper_commit_planes(dev, old_state, 0);
> +
> + drm_atomic_helper_commit_hw_done(old_state);
> } else {
> /*
>* OMAP3 DSS seems to have issues with the work-around above,
> @@ -101,11 +102,9 @@ static void omap_atomic_commit_tail(struct
> drm_atomic_state *old_state)
> drm_atomic_helper_commit_planes(dev, old_state, 0);
>
> drm_atomic_helper_commit_modeset_enables(dev, old_state);
> - }
>
> - drm_atomic_helper_commit_hw_done(old_state);
> -
> - dma_fence_end_signalling(fence_cookie);
> + drm_atomic_helper_commit_hw_done(old_state);
> + }
>
> /*
>* Wait for completion of the page flips to ensure that old buffers
>
Re: [PATCH 1/2] Revert "drm/tidss: Annotate dma-fence critical section in commit path"
0x234/0x4b0 [drm]
> drm_compat_ioctl+0x110/0x12c [drm]
> __arm64_compat_sys_ioctl+0x128/0x150
> invoke_syscall+0x48/0x110
> el0_svc_common.constprop.0+0x40/0xe0
> do_el0_svc_compat+0x1c/0x38
> el0_svc_compat+0x48/0xb4
> el0t_32_sync_handler+0xb0/0x138
> el0t_32_sync+0x194/0x198
>
> Fixes: 4d56a4f08391 ("drm/tidss: Annotate dma-fence critical section in
> commit path")
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Aradhya Bhatia
Regards
Aradhya
> ---
> drivers/gpu/drm/tidss/tidss_kms.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/tidss/tidss_kms.c
> b/drivers/gpu/drm/tidss/tidss_kms.c
> index c979ad1af236..d096d8d2bc8f 100644
> --- a/drivers/gpu/drm/tidss/tidss_kms.c
> +++ b/drivers/gpu/drm/tidss/tidss_kms.c
> @@ -4,8 +4,6 @@
> * Author: Tomi Valkeinen
> */
>
> -#include
> -
> #include
> #include
> #include
> @@ -25,7 +23,6 @@ static void tidss_atomic_commit_tail(struct
> drm_atomic_state *old_state)
> {
> struct drm_device *ddev = old_state->dev;
> struct tidss_device *tidss = to_tidss(ddev);
> - bool fence_cookie = dma_fence_begin_signalling();
>
> dev_dbg(ddev->dev, "%s\n", __func__);
>
> @@ -36,7 +33,6 @@ static void tidss_atomic_commit_tail(struct
> drm_atomic_state *old_state)
> drm_atomic_helper_commit_modeset_enables(ddev, old_state);
>
> drm_atomic_helper_commit_hw_done(old_state);
> - dma_fence_end_signalling(fence_cookie);
> drm_atomic_helper_wait_for_flip_done(ddev, old_state);
>
> drm_atomic_helper_cleanup_planes(ddev, old_state);
>
Re: [PATCH v2] drm: bridge: it66121: Fix invalid connector dereference
On 01-Sep-23 15:01, Jai Luthra wrote:
> Fix the NULL pointer dereference when no monitor is connected, and the
> sound card is opened from userspace.
>
> Instead return an empty buffer (of zeroes) as the EDID information to
> the sound framework if there is no connector attached.
>
> Fixes: e0fd83dbe924 ("drm: bridge: it66121: Add audio support")
> Reported-by: Nishanth Menon
> Closes: https://lore.kernel.org/all/20230825105849.crhon42qndxqif4i@gondola/
> Reviewed-by: Helen Koike
> Signed-off-by: Jai Luthra
Reviewed-by: Aradhya Bhatia
Regards
Aradhya
> ---
> Changes in v2:
> - Return an empty buffer of 0s instead of returning an error
> - Lock the mutex before accessing ctx->connector
> - Link to v1:
> https://lore.kernel.org/r/20230825-it66121_edid-v1-1-3ab54923e...@ti.com
> ---
> drivers/gpu/drm/bridge/ite-it66121.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ite-it66121.c
> b/drivers/gpu/drm/bridge/ite-it66121.c
> index 466641c77fe9..fc7f5ec5fb38 100644
> --- a/drivers/gpu/drm/bridge/ite-it66121.c
> +++ b/drivers/gpu/drm/bridge/ite-it66121.c
> @@ -1447,10 +1447,14 @@ static int it66121_audio_get_eld(struct device *dev,
> void *data,
> struct it66121_ctx *ctx = dev_get_drvdata(dev);
>
> mutex_lock(>lock);
> -
> - memcpy(buf, ctx->connector->eld,
> -min(sizeof(ctx->connector->eld), len));
> -
> + if (!ctx->connector) {
> + /* Pass en empty ELD if connector not available */
> + dev_dbg(dev, "No connector present, passing empty EDID data");
> + memset(buf, 0, len);
> + } else {
> + memcpy(buf, ctx->connector->eld,
> +min(sizeof(ctx->connector->eld), len));
> + }
> mutex_unlock(>lock);
>
> return 0;
>
> ---
> base-commit: 99d99825fc075fd24b60cc9cf0fb1e20b9c16b0f
> change-id: 20230825-it66121_edid-6ee98517808b
>
> Best regards,
Re: [PATCH] drm: bridge: it66121: Fix invalid connector dereference
Hi Jai,
Thanks for debugging the issue.
On 25-Aug-23 16:32, Jai Luthra wrote:
> Fix the NULL pointer dereference when no monitor is connected, and the
> sound card is opened from userspace.
>
> Instead return an error as EDID information cannot be provided to
> the sound framework if there is no connector attached.
>
> Fixes: e0fd83dbe924 ("drm: bridge: it66121: Add audio support")
> Reported-by: Nishanth Menon
> Closes: https://lore.kernel.org/all/20230825105849.crhon42qndxqif4i@gondola/
> Signed-off-by: Jai Luthra
> ---
> drivers/gpu/drm/bridge/ite-it66121.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ite-it66121.c
> b/drivers/gpu/drm/bridge/ite-it66121.c
> index 466641c77fe9..d6fa00dea464 100644
> --- a/drivers/gpu/drm/bridge/ite-it66121.c
> +++ b/drivers/gpu/drm/bridge/ite-it66121.c
> @@ -1446,6 +1446,11 @@ static int it66121_audio_get_eld(struct device *dev,
> void *data,
> {
> struct it66121_ctx *ctx = dev_get_drvdata(dev);
>
> + if (!ctx->connector) {
> + dev_dbg(dev, "No connector present, cannot provide EDID data");
> + return -EINVAL;
> + }
> +
There are not many HDMI bridges that support codecs in the kernel, but
upon a quick look, bridge/analogix/anx7625.c and
bridge/synopsys/dw-hdmi* gracefully return a buffer of 0s when the
connector is unavailable.
I am not sure why that is done, but I also don't see the hdmi-codec
driver handle the 0s situation properly. It is business as usual for the
hdmi-codec.
Did you come across some observation when you were testing?
Regards
Aradhya
> mutex_lock(>lock);
>
> memcpy(buf, ctx->connector->eld,
>
> ---
> base-commit: 6269320850097903b30be8f07a5c61d9f7592393
> change-id: 20230825-it66121_edid-6ee98517808b
>
> Best regards,
[PATCH v2 2/2] drivers/tidss: Add support for AM62A7 DSS
Add support for the DSS controller on TI's AM62A7 SoC in the tidss
driver.
This contrller has 2 video pipelines that can render 2 video planes on
over a screen, using the overlay managers. The output of the DSS comes
from video port 2 (VP2) in the form of RGB88 DPI signals, while the VP1
is tied off inside the SoC.
Signed-off-by: Aradhya Bhatia
---
Notes:
Changes from V1:
* Correctly sort DISPC_AM62A7 macro after DISPC_AM625.
drivers/gpu/drm/tidss/tidss_dispc.c | 53 +
drivers/gpu/drm/tidss/tidss_dispc.h | 2 ++
drivers/gpu/drm/tidss/tidss_drv.c | 1 +
3 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index 9d9dee7abaef..5539ddb7f338 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -322,6 +322,54 @@ const struct dispc_features dispc_am625_feats = {
.vid_order = { 1, 0 },
};
+const struct dispc_features dispc_am62a7_feats = {
+ .max_pclk_khz = {
+ [DISPC_VP_DPI] = 165000,
+ },
+
+ .scaling = {
+ .in_width_max_5tap_rgb = 1280,
+ .in_width_max_3tap_rgb = 2560,
+ .in_width_max_5tap_yuv = 2560,
+ .in_width_max_3tap_yuv = 4096,
+ .upscale_limit = 16,
+ .downscale_limit_5tap = 4,
+ .downscale_limit_3tap = 2,
+ /*
+* The max supported pixel inc value is 255. The value
+* of pixel inc is calculated like this: 1+(xinc-1)*bpp.
+* The maximum bpp of all formats supported by the HW
+* is 8. So the maximum supported xinc value is 32,
+* because 1+(32-1)*8 < 255 < 1+(33-1)*4.
+*/
+ .xinc_max = 32,
+ },
+
+ .subrev = DISPC_AM62A7,
+
+ .common = "common",
+ .common_regs = tidss_am65x_common_regs,
+
+ .num_vps = 2,
+ .vp_name = { "vp1", "vp2" },
+ .ovr_name = { "ovr1", "ovr2" },
+ .vpclk_name = { "vp1", "vp2" },
+ .vp_bus_type = { DISPC_VP_INTERNAL, DISPC_VP_DPI },
+
+ .vp_feat = { .color = {
+ .has_ctm = true,
+ .gamma_size = 256,
+ .gamma_type = TIDSS_GAMMA_8BIT,
+ },
+ },
+
+ .num_planes = 2,
+ /* note: vid is plane_id 0 and vidl1 is plane_id 1 */
+ .vid_name = { "vid", "vidl1" },
+ .vid_lite = { false, true, },
+ .vid_order = { 1, 0 },
+};
+
static const u16 *dispc_common_regmap;
struct dss_vp_data {
@@ -824,6 +872,7 @@ dispc_irq_t dispc_read_and_clear_irqstatus(struct
dispc_device *dispc)
case DISPC_K2G:
return dispc_k2g_read_and_clear_irqstatus(dispc);
case DISPC_AM625:
+ case DISPC_AM62A7:
case DISPC_AM65X:
case DISPC_J721E:
return dispc_k3_read_and_clear_irqstatus(dispc);
@@ -840,6 +889,7 @@ void dispc_set_irqenable(struct dispc_device *dispc,
dispc_irq_t mask)
dispc_k2g_set_irqenable(dispc, mask);
break;
case DISPC_AM625:
+ case DISPC_AM62A7:
case DISPC_AM65X:
case DISPC_J721E:
dispc_k3_set_irqenable(dispc, mask);
@@ -1331,6 +1381,7 @@ void dispc_ovr_set_plane(struct dispc_device *dispc, u32
hw_plane,
x, y, layer);
break;
case DISPC_AM625:
+ case DISPC_AM62A7:
case DISPC_AM65X:
dispc_am65x_ovr_set_plane(dispc, hw_plane, hw_videoport,
x, y, layer);
@@ -2250,6 +2301,7 @@ static void dispc_plane_init(struct dispc_device *dispc)
dispc_k2g_plane_init(dispc);
break;
case DISPC_AM625:
+ case DISPC_AM62A7:
case DISPC_AM65X:
case DISPC_J721E:
dispc_k3_plane_init(dispc);
@@ -2357,6 +2409,7 @@ static void dispc_vp_write_gamma_table(struct
dispc_device *dispc,
dispc_k2g_vp_write_gamma_table(dispc, hw_videoport);
break;
case DISPC_AM625:
+ case DISPC_AM62A7:
case DISPC_AM65X:
dispc_am65x_vp_write_gamma_table(dispc, hw_videoport);
break;
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.h
b/drivers/gpu/drm/tidss/tidss_dispc.h
index 33ac5ad7a423..7f203f83559b 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.h
+++ b/drivers/gpu/drm/tidss/tidss_dispc.h
@@ -60,6 +60,7 @@ enum dispc_vp_bus_type {
enum dispc_dss_subrevision {
DISPC_K2G,
DISPC_AM625,
+ DISPC_AM62A7,
DISPC_AM65X,
DISPC_J721E,
};
@@ -88,6 +89,7 @@ struct dispc_features {
extern const struct dispc_features dispc_k2g_feats;
extern const struct dispc_features dispc_am625_feats;
+extern const
[PATCH v2 1/2] dt-bindings: display: ti: Add support for am62a7 dss
The DSS controller on TI's AM62A7 SoC is an update from that on TI's AM625 SoC. Like the DSS in AM625, the DSS in this SoC has 2 video pipelines, but unlike the former, the latter only has one output port on VP2 to service DPI display sinks. Add the new controller's compatible. Signed-off-by: Aradhya Bhatia --- Notes: Changes from V1: * No change from V1. .../bindings/display/ti/ti,am65x-dss.yaml | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml index ae09cd3cbce1..b6767ef0d24d 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml @@ -23,6 +23,7 @@ properties: compatible: enum: - ti,am625-dss + - ti,am62a7,dss - ti,am65x-dss reg: @@ -87,6 +88,7 @@ properties: For AM65x DSS, the OLDI output port node from video port 1. For AM625 DSS, the internal DPI output port node from video port 1. + For AM62A7 DSS, the port is tied off inside the SoC. port@1: $ref: /schemas/graph.yaml#/properties/port @@ -108,6 +110,18 @@ properties: Input memory (from main memory to dispc) bandwidth limit in bytes per second +allOf: + - if: + properties: +compatible: + contains: +const: ti,am62a7-dss +then: + properties: +ports: + properties: +port@0: false + required: - compatible - reg -- 2.40.1
[PATCH v2 0/2] Add DSS support for TI AM62A7 SoC
This patch series adds a new compatible for the Display SubSystem (DSS) controller on TI's AM62A7 SoC. It further adds the required support, for the same, in the tidss driver. The DSS controller is similar to the recently added AM625 DSS, with the key difference being the absence of VP1 output on the SoC. The VP1 in AM62A7 DSS is tied off and cannot be used, unlike in AM625, where the VP1 was connected to 2 OLDI TXes. The video pipeline that corresponds to VP1 still exists and can be used to overlay planes on the VP2's primary plane. This can be done using the overlay managers inside the SoC. Moreover, DSS VP2 can output Full-HD RGB888 DPI video signals. I have tested these patches on AM62A7 SK-EVM, which converts DPI signals to HDMI on the platform using the Sil9022A HDMI transmitter. All the patches, required to enable display on AM62A7-SK, can be found on my github fork[0] in the branch "next_am62a-v2". Regards Aradhya [0]: https://github.com/aradhya07/linux-ab/tree/next_am62a-v2 Change Log: V1 -> V2: - Correctly sort DISPC_AM62A7 macro after DISPC_AM625 in patch 2/2. Previous Versions: V1: https://lore.kernel.org/all/20230818131750.4779-1-a-bhat...@ti.com/ Aradhya Bhatia (2): dt-bindings: display: ti: Add support for am62a7 dss drivers/tidss: Add support for AM62A7 DSS .../bindings/display/ti/ti,am65x-dss.yaml | 14 + drivers/gpu/drm/tidss/tidss_dispc.c | 53 +++ drivers/gpu/drm/tidss/tidss_dispc.h | 2 + drivers/gpu/drm/tidss/tidss_drv.c | 1 + 4 files changed, 70 insertions(+) base-commit: 47762f08697484cf0c2f2904b8c52375ed26c8cb -- 2.40.1
[PATCH 1/2] dt-bindings: display: ti: Add support for am62a7 dss
The DSS controller on TI's AM62A7 SoC is an update from that on TI's AM625 SoC. Like the DSS in AM625, the DSS in this SoC has 2 video pipelines, but unlike the former, the latter only has one output port on VP2 to service DPI display sinks. Add the new controller's compatible. Signed-off-by: Aradhya Bhatia --- .../bindings/display/ti/ti,am65x-dss.yaml | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml index ae09cd3cbce1..b6767ef0d24d 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml @@ -23,6 +23,7 @@ properties: compatible: enum: - ti,am625-dss + - ti,am62a7,dss - ti,am65x-dss reg: @@ -87,6 +88,7 @@ properties: For AM65x DSS, the OLDI output port node from video port 1. For AM625 DSS, the internal DPI output port node from video port 1. + For AM62A7 DSS, the port is tied off inside the SoC. port@1: $ref: /schemas/graph.yaml#/properties/port @@ -108,6 +110,18 @@ properties: Input memory (from main memory to dispc) bandwidth limit in bytes per second +allOf: + - if: + properties: +compatible: + contains: +const: ti,am62a7-dss +then: + properties: +ports: + properties: +port@0: false + required: - compatible - reg -- 2.40.1
Re: [PATCH 2/2] drivers/tidss: Add support for AM62A7 DSS
On 18-Aug-23 18:47, Aradhya Bhatia wrote:
> Add support for the DSS controller on TI's AM62A7 SoC in the tidss
> driver.
>
> This contrller has 2 video pipelines that can render 2 video planes on
> over a screen, using the overlay managers. The output of the DSS comes
> from video port 2 (VP2) in the form of RGB88 DPI signals, while the VP1
> is tied off inside the SoC.
>
> Signed-off-by: Aradhya Bhatia
> ---
> drivers/gpu/drm/tidss/tidss_dispc.c | 53 +
> drivers/gpu/drm/tidss/tidss_dispc.h | 2 ++
> drivers/gpu/drm/tidss/tidss_drv.c | 1 +
> 3 files changed, 56 insertions(+)
>
> diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
> b/drivers/gpu/drm/tidss/tidss_dispc.c
> index 9d9dee7abaef..0e2d55d9a0d7 100644
> --- a/drivers/gpu/drm/tidss/tidss_dispc.c
> +++ b/drivers/gpu/drm/tidss/tidss_dispc.c
> @@ -322,6 +322,54 @@ const struct dispc_features dispc_am625_feats = {
> .vid_order = { 1, 0 },
> };
>
> +const struct dispc_features dispc_am62a7_feats = {
> + .max_pclk_khz = {
> + [DISPC_VP_DPI] = 165000,
> + },
> +
> + .scaling = {
> + .in_width_max_5tap_rgb = 1280,
> + .in_width_max_3tap_rgb = 2560,
> + .in_width_max_5tap_yuv = 2560,
> + .in_width_max_3tap_yuv = 4096,
> + .upscale_limit = 16,
> + .downscale_limit_5tap = 4,
> + .downscale_limit_3tap = 2,
> + /*
> + * The max supported pixel inc value is 255. The value
> + * of pixel inc is calculated like this: 1+(xinc-1)*bpp.
> + * The maximum bpp of all formats supported by the HW
> + * is 8. So the maximum supported xinc value is 32,
> + * because 1+(32-1)*8 < 255 < 1+(33-1)*4.
> + */
> + .xinc_max = 32,
> + },
> +
> + .subrev = DISPC_AM62A7,
> +
> + .common = "common",
> + .common_regs = tidss_am65x_common_regs,
> +
> + .num_vps = 2,
> + .vp_name = { "vp1", "vp2" },
> + .ovr_name = { "ovr1", "ovr2" },
> + .vpclk_name = { "vp1", "vp2" },
> + .vp_bus_type = { DISPC_VP_INTERNAL, DISPC_VP_DPI },
> +
> + .vp_feat = { .color = {
> + .has_ctm = true,
> + .gamma_size = 256,
> + .gamma_type = TIDSS_GAMMA_8BIT,
> + },
> + },
> +
> + .num_planes = 2,
> + /* note: vid is plane_id 0 and vidl1 is plane_id 1 */
> + .vid_name = { "vid", "vidl1" },
> + .vid_lite = { false, true, },
> + .vid_order = { 1, 0 },
> +};
> +
> static const u16 *dispc_common_regmap;
>
> struct dss_vp_data {
> @@ -823,6 +871,7 @@ dispc_irq_t dispc_read_and_clear_irqstatus(struct
> dispc_device *dispc)
> switch (dispc->feat->subrev) {
> case DISPC_K2G:
> return dispc_k2g_read_and_clear_irqstatus(dispc);
> + case DISPC_AM62A7:
> case DISPC_AM625:
> case DISPC_AM65X:
> case DISPC_J721E:
> @@ -839,6 +888,7 @@ void dispc_set_irqenable(struct dispc_device *dispc,
> dispc_irq_t mask)
> case DISPC_K2G:
> dispc_k2g_set_irqenable(dispc, mask);
> break;
> + case DISPC_AM62A7:
> case DISPC_AM625:
> case DISPC_AM65X:
> case DISPC_J721E:
> @@ -1330,6 +1380,7 @@ void dispc_ovr_set_plane(struct dispc_device *dispc,
> u32 hw_plane,
> dispc_k2g_ovr_set_plane(dispc, hw_plane, hw_videoport,
> x, y, layer);
> break;
> + case DISPC_AM62A7:
> case DISPC_AM625:
> case DISPC_AM65X:
> dispc_am65x_ovr_set_plane(dispc, hw_plane, hw_videoport,
> @@ -2249,6 +2300,7 @@ static void dispc_plane_init(struct dispc_device *dispc)
> case DISPC_K2G:
> dispc_k2g_plane_init(dispc);
> break;
> + case DISPC_AM62A7:
> case DISPC_AM625:
> case DISPC_AM65X:
> case DISPC_J721E:
> @@ -2356,6 +2408,7 @@ static void dispc_vp_write_gamma_table(struct
> dispc_device *dispc,
> case DISPC_K2G:
> dispc_k2g_vp_write_gamma_table(dispc, hw_videoport);
> break;
> + case DISPC_AM62A7:
> case DISPC_AM625:
> case DISPC_AM65X:
> dispc_am65x_vp_write_gamma_table(dispc, hw_videoport);
> diff --git a/drivers/gpu/drm/tidss/tidss_dispc.h
> b/drivers/gpu/drm/tidss/tidss_dispc.h
> index 33ac5ad7a423..2aa1c814ea2a 100644
> --- a/drivers/gpu/drm/tidss/tidss_dispc.h
> +++ b/drivers/gpu/d
[PATCH 0/2] Add DSS support for TI AM62A7 SoC
This patch series adds a new compatible for the Display SubSystem (DSS) controller on TI's AM62A7 SoC. It further adds the required support, for the same, in the tidss driver. The DSS controller is similar to the recently added AM625 DSS, with the key difference being the absence of VP1 output on the SoC. The VP1 in AM62A7 DSS is tied off and cannot be used, unlike in AM625, where the VP1 was connected to 2 OLDI TXes. The video pipeline that corresponds to VP1 still exists and can be used to overlay planes on the VP2's primary plane. This can be done using the overlay managers inside the SoC. Moreover, DSS VP2 can output Full-HD RGB888 DPI video signals. I have tested these patches on AM62A7 SK-EVM, which converts DPI signals to HDMI on the platform using the Sil9022A HDMI transmitter. All the patches, required to enable display on AM62A7-SK, can be found on my github fork[0] in the branch "next_am62a". Regards Aradhya [0]: https://github.com/aradhya07/linux-ab/tree/next_am62a Aradhya Bhatia (2): dt-bindings: display: ti: Add support for am62a7 dss drivers/tidss: Add support for AM62A7 DSS .../bindings/display/ti/ti,am65x-dss.yaml | 14 + drivers/gpu/drm/tidss/tidss_dispc.c | 53 +++ drivers/gpu/drm/tidss/tidss_dispc.h | 2 + drivers/gpu/drm/tidss/tidss_drv.c | 1 + 4 files changed, 70 insertions(+) base-commit: 47762f08697484cf0c2f2904b8c52375ed26c8cb -- 2.40.1
[PATCH 2/2] drivers/tidss: Add support for AM62A7 DSS
Add support for the DSS controller on TI's AM62A7 SoC in the tidss
driver.
This contrller has 2 video pipelines that can render 2 video planes on
over a screen, using the overlay managers. The output of the DSS comes
from video port 2 (VP2) in the form of RGB88 DPI signals, while the VP1
is tied off inside the SoC.
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/tidss/tidss_dispc.c | 53 +
drivers/gpu/drm/tidss/tidss_dispc.h | 2 ++
drivers/gpu/drm/tidss/tidss_drv.c | 1 +
3 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index 9d9dee7abaef..0e2d55d9a0d7 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -322,6 +322,54 @@ const struct dispc_features dispc_am625_feats = {
.vid_order = { 1, 0 },
};
+const struct dispc_features dispc_am62a7_feats = {
+ .max_pclk_khz = {
+ [DISPC_VP_DPI] = 165000,
+ },
+
+ .scaling = {
+ .in_width_max_5tap_rgb = 1280,
+ .in_width_max_3tap_rgb = 2560,
+ .in_width_max_5tap_yuv = 2560,
+ .in_width_max_3tap_yuv = 4096,
+ .upscale_limit = 16,
+ .downscale_limit_5tap = 4,
+ .downscale_limit_3tap = 2,
+ /*
+* The max supported pixel inc value is 255. The value
+* of pixel inc is calculated like this: 1+(xinc-1)*bpp.
+* The maximum bpp of all formats supported by the HW
+* is 8. So the maximum supported xinc value is 32,
+* because 1+(32-1)*8 < 255 < 1+(33-1)*4.
+*/
+ .xinc_max = 32,
+ },
+
+ .subrev = DISPC_AM62A7,
+
+ .common = "common",
+ .common_regs = tidss_am65x_common_regs,
+
+ .num_vps = 2,
+ .vp_name = { "vp1", "vp2" },
+ .ovr_name = { "ovr1", "ovr2" },
+ .vpclk_name = { "vp1", "vp2" },
+ .vp_bus_type = { DISPC_VP_INTERNAL, DISPC_VP_DPI },
+
+ .vp_feat = { .color = {
+ .has_ctm = true,
+ .gamma_size = 256,
+ .gamma_type = TIDSS_GAMMA_8BIT,
+ },
+ },
+
+ .num_planes = 2,
+ /* note: vid is plane_id 0 and vidl1 is plane_id 1 */
+ .vid_name = { "vid", "vidl1" },
+ .vid_lite = { false, true, },
+ .vid_order = { 1, 0 },
+};
+
static const u16 *dispc_common_regmap;
struct dss_vp_data {
@@ -823,6 +871,7 @@ dispc_irq_t dispc_read_and_clear_irqstatus(struct
dispc_device *dispc)
switch (dispc->feat->subrev) {
case DISPC_K2G:
return dispc_k2g_read_and_clear_irqstatus(dispc);
+ case DISPC_AM62A7:
case DISPC_AM625:
case DISPC_AM65X:
case DISPC_J721E:
@@ -839,6 +888,7 @@ void dispc_set_irqenable(struct dispc_device *dispc,
dispc_irq_t mask)
case DISPC_K2G:
dispc_k2g_set_irqenable(dispc, mask);
break;
+ case DISPC_AM62A7:
case DISPC_AM625:
case DISPC_AM65X:
case DISPC_J721E:
@@ -1330,6 +1380,7 @@ void dispc_ovr_set_plane(struct dispc_device *dispc, u32
hw_plane,
dispc_k2g_ovr_set_plane(dispc, hw_plane, hw_videoport,
x, y, layer);
break;
+ case DISPC_AM62A7:
case DISPC_AM625:
case DISPC_AM65X:
dispc_am65x_ovr_set_plane(dispc, hw_plane, hw_videoport,
@@ -2249,6 +2300,7 @@ static void dispc_plane_init(struct dispc_device *dispc)
case DISPC_K2G:
dispc_k2g_plane_init(dispc);
break;
+ case DISPC_AM62A7:
case DISPC_AM625:
case DISPC_AM65X:
case DISPC_J721E:
@@ -2356,6 +2408,7 @@ static void dispc_vp_write_gamma_table(struct
dispc_device *dispc,
case DISPC_K2G:
dispc_k2g_vp_write_gamma_table(dispc, hw_videoport);
break;
+ case DISPC_AM62A7:
case DISPC_AM625:
case DISPC_AM65X:
dispc_am65x_vp_write_gamma_table(dispc, hw_videoport);
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.h
b/drivers/gpu/drm/tidss/tidss_dispc.h
index 33ac5ad7a423..2aa1c814ea2a 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.h
+++ b/drivers/gpu/drm/tidss/tidss_dispc.h
@@ -59,6 +59,7 @@ enum dispc_vp_bus_type {
enum dispc_dss_subrevision {
DISPC_K2G,
+ DISPC_AM62A7,
DISPC_AM625,
DISPC_AM65X,
DISPC_J721E,
@@ -88,6 +89,7 @@ struct dispc_features {
extern const struct dispc_features dispc_k2g_feats;
extern const struct dispc_features dispc_am625_feats;
+extern const struct dispc_features dispc_am62a7_feats;
extern const struct dispc_features dispc_am65x_feats;
extern const struct dispc_features dispc_j7
Re: [PATCH v7 5/8] drm/bridge: sii902x: Support format negotiation hooks
Hi Sam,
On 10-Jul-23 20:38, Sam Ravnborg wrote:
> Hi Aradhya,
>
> On Tue, Jun 06, 2023 at 01:51:39PM +0530, Aradhya Bhatia wrote:
>> With new connector model, sii902x will not create the connector, when
>> DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and SoC driver will rely on format
>> negotiation to setup the encoder format.
>>
>> Support format negotiations hooks in the drm_bridge_funcs.
>> Use helper functions for state management.
>>
>> Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is
>> the case with older model.
>>
>> Signed-off-by: Aradhya Bhatia
>> Reviewed-by: Neil Armstrong
>
> As noted by Javier, this patch-set was forgotten, so sorry for not
> providing timely feedback.
Thank you for reviewing my patch nevertheless! =)
>
>
>> ---
>>
>> Notes:
>>
>> changes from v6:
>> * Add Neil Armstrong's R-b tag.
>>
>> drivers/gpu/drm/bridge/sii902x.c | 25 +
>> 1 file changed, 25 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/sii902x.c
>> b/drivers/gpu/drm/bridge/sii902x.c
>> index ef66461e7f7c..70aeb04b7f77 100644
>> --- a/drivers/gpu/drm/bridge/sii902x.c
>> +++ b/drivers/gpu/drm/bridge/sii902x.c
>> @@ -473,6 +473,27 @@ static struct edid *sii902x_bridge_get_edid(struct
>> drm_bridge *bridge,
>> return sii902x_get_edid(sii902x, connector);
>> }
>>
>> +static u32 *sii902x_bridge_atomic_get_input_bus_fmts(struct drm_bridge
>> *bridge,
>> + struct drm_bridge_state
>> *bridge_state,
>> + struct drm_crtc_state
>> *crtc_state,
>> + struct drm_connector_state
>> *conn_state,
>> + u32 output_fmt,
>> + unsigned int
>> *num_input_fmts)
>> +{
>> +u32 *input_fmts;
>> +
>> +*num_input_fmts = 0;
>> +
>> +input_fmts = kcalloc(1, sizeof(*input_fmts), GFP_KERNEL);
>> +if (!input_fmts)
>> +return NULL;
>> +
>> +input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
>> +*num_input_fmts = 1;
>> +
>> +return input_fmts;
>> +}
>
> An alternative implementation of the above is:
> {
> switch (output_fmt) {
> case MEDIA_BUS_FMT_RGB888_1X24:
> break;
>
> default:
> /* Fail for any other formats */
>*num_input_fmts = 0;
> return NULL;
> }
>
>return drm_atomic_helper_bridge_propagate_bus_fmt(bridge, bridge_state,
> crtc_state,
> conn_state,
> output_fmt,
> num_input_fmts);
> }
>
> If you agree and have the time to do it it would be nice to use this
> simpler variant.
> Mostly so we avoid more open coded variants like you already did, and
> which we have plenty of already.
I agree with the idea that these hooks should get streamlined.
However, this particular approach will break things when the output_fmt
is defaulted to MEDIA_BUS_FMT_FIXED. Even if we add this format as a
fall-through case along with MEDIA_BUS_FMT_RGB888_1X24, tidss driver
will too then receive MEDIA_BUS_FMT_FIXED as an expected output format
and will throw an error.
The possibility of an equivalent if-check was discussed in the previous
version[1].
>
> It would be even better to walk through other implementations of
> get_input_bus_fmts and update them accordingly.
>
> Again, sorry for being late here. Feel free to ignore if you already
> moved on with something else.
>
I am working on adding OLDI support for tidss, but if we can resolve the
above concern, and Javier agrees, I will be happy to add an incremental
fix for this! =)
Regards
Aradhya
[1]: https://patchwork.freedesktop.org/patch/536008/?series=82765=6
[PATCH v9 1/2] dt-bindings: display: ti, am65x-dss: Add am625 dss compatible
The DSS controller on TI's AM625 SoC is an update from that on TI's AM65X SoC. The former has an additional OLDI TX on its first video port that helps output cloned video or WUXGA (1920x1200@60fps) resolution video output over a dual-link mode to reduce the required OLDI clock output. The second video port is same from AM65x DSS and it outputs DPI video data. It can support 2K resolutions @ 60fps, independently. Add the new controller's compatible and update descriptions. Signed-off-by: Aradhya Bhatia Acked-by: Krzysztof Kozlowski Reviewed-by: Tomi Valkeinen --- Notes: Changes from v8: * Add Krzysztof Kozlowski's and Tomi Valkeinen's tags. Changes from v7: * Drop the 3rd port property and update descriptions. * Drop the Reviewed-by tags of Krzysztof Kozlowski and Rahul T R because of the changes. .../bindings/display/ti/ti,am65x-dss.yaml | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml index b6b402f16161..ae09cd3cbce1 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml @@ -12,14 +12,18 @@ maintainers: - Tomi Valkeinen description: | - The AM65x TI Keystone Display SubSystem with two output ports and - two video planes. The first video port supports OLDI and the second - supports DPI format. The fist plane is full video plane with all - features and the second is a "lite plane" without scaling support. + The AM625 and AM65x TI Keystone Display SubSystem with two output + ports and two video planes. In AM65x DSS, the first video port + supports 1 OLDI TX and in AM625 DSS, the first video port output is + internally routed to 2 OLDI TXes. The second video port supports DPI + format. The first plane is full video plane with all features and the + second is a "lite plane" without scaling support. properties: compatible: -const: ti,am65x-dss +enum: + - ti,am625-dss + - ti,am65x-dss reg: description: @@ -80,7 +84,9 @@ properties: port@0: $ref: /schemas/graph.yaml#/properties/port description: - The DSS OLDI output port node form video port 1 + For AM65x DSS, the OLDI output port node from video port 1. + For AM625 DSS, the internal DPI output port node from video + port 1. port@1: $ref: /schemas/graph.yaml#/properties/port -- 2.40.1
[PATCH v9 2/2] drm/tidss: Add support for AM625 DSS
Add support for the DSS controller on TI's AM625 SoC in the tidss
driver.
The AM625 DSS supports 2 video planes connecting to 2 video ports.
The first plane is a full plane supporting all the features, while the
2nd plane is a "lite" plane without scaling support.
The first video port in AM625 DSS internally provides DPI output to 2
OLDI transmitters. Each OLDI TX outputs 4 differential lanes of video
output and 1 of clock output.
This patch does not automatically enable the OLDI features of AM625 yet.
That support for OLDI will be added subsequently.
The second video port outputs DPI data directly out of the SoC. It has
24 data lines and can support a maximum of RGB888 output bus format.
Signed-off-by: Aradhya Bhatia
Reviewed-by: Tomi Valkeinen
---
Notes:
Changes from v8:
* Update commit message.
* Add Tomi Valkeinen's R-b tag.
Changes from v7:
* Drop all changes made after v3.
- Drop output bus type support. All outputs from DSS will be the
video port outptus.
* Make the first video port type as INTERNAL from OLDI.
drivers/gpu/drm/tidss/tidss_dispc.c | 57 -
drivers/gpu/drm/tidss/tidss_dispc.h | 2 +
drivers/gpu/drm/tidss/tidss_drv.c | 1 +
3 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index dca077411f77..484da1aa27bb 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -275,6 +275,55 @@ const struct dispc_features dispc_j721e_feats = {
.vid_order = { 1, 3, 0, 2 },
};
+const struct dispc_features dispc_am625_feats = {
+ .max_pclk_khz = {
+ [DISPC_VP_DPI] = 165000,
+ [DISPC_VP_INTERNAL] = 17,
+ },
+
+ .scaling = {
+ .in_width_max_5tap_rgb = 1280,
+ .in_width_max_3tap_rgb = 2560,
+ .in_width_max_5tap_yuv = 2560,
+ .in_width_max_3tap_yuv = 4096,
+ .upscale_limit = 16,
+ .downscale_limit_5tap = 4,
+ .downscale_limit_3tap = 2,
+ /*
+* The max supported pixel inc value is 255. The value
+* of pixel inc is calculated like this: 1+(xinc-1)*bpp.
+* The maximum bpp of all formats supported by the HW
+* is 8. So the maximum supported xinc value is 32,
+* because 1+(32-1)*8 < 255 < 1+(33-1)*4.
+*/
+ .xinc_max = 32,
+ },
+
+ .subrev = DISPC_AM625,
+
+ .common = "common",
+ .common_regs = tidss_am65x_common_regs,
+
+ .num_vps = 2,
+ .vp_name = { "vp1", "vp2" },
+ .ovr_name = { "ovr1", "ovr2" },
+ .vpclk_name = { "vp1", "vp2" },
+ .vp_bus_type = { DISPC_VP_INTERNAL, DISPC_VP_DPI },
+
+ .vp_feat = { .color = {
+ .has_ctm = true,
+ .gamma_size = 256,
+ .gamma_type = TIDSS_GAMMA_8BIT,
+ },
+ },
+
+ .num_planes = 2,
+ /* note: vid is plane_id 0 and vidl1 is plane_id 1 */
+ .vid_name = { "vid", "vidl1" },
+ .vid_lite = { false, true, },
+ .vid_order = { 1, 0 },
+};
+
static const u16 *dispc_common_regmap;
struct dss_vp_data {
@@ -776,6 +825,7 @@ dispc_irq_t dispc_read_and_clear_irqstatus(struct
dispc_device *dispc)
switch (dispc->feat->subrev) {
case DISPC_K2G:
return dispc_k2g_read_and_clear_irqstatus(dispc);
+ case DISPC_AM625:
case DISPC_AM65X:
case DISPC_J721E:
return dispc_k3_read_and_clear_irqstatus(dispc);
@@ -791,6 +841,7 @@ void dispc_set_irqenable(struct dispc_device *dispc,
dispc_irq_t mask)
case DISPC_K2G:
dispc_k2g_set_irqenable(dispc, mask);
break;
+ case DISPC_AM625:
case DISPC_AM65X:
case DISPC_J721E:
dispc_k3_set_irqenable(dispc, mask);
@@ -1281,6 +1332,7 @@ void dispc_ovr_set_plane(struct dispc_device *dispc, u32
hw_plane,
dispc_k2g_ovr_set_plane(dispc, hw_plane, hw_videoport,
x, y, layer);
break;
+ case DISPC_AM625:
case DISPC_AM65X:
dispc_am65x_ovr_set_plane(dispc, hw_plane, hw_videoport,
x, y, layer);
@@ -2199,6 +2251,7 @@ static void dispc_plane_init(struct dispc_device *dispc)
case DISPC_K2G:
dispc_k2g_plane_init(dispc);
break;
+ case DISPC_AM625:
case DISPC_AM65X:
case DISPC_J721E:
dispc_k3_plane_init(dispc);
@@ -2305,6 +2358,7 @@ static void dispc_vp_write_gamma_table(struct
dispc_device *dispc,
case DISPC_K2G:
dispc_k2g_vp_w
[PATCH v9 0/2] Add DSS support for AM625 SoC
This patch series adds a new compatible for the Display SubSystem (DSS) controller on TI's AM625 SoC. It further adds the required support for the same in the tidss driver. The AM625-DSS is a newer version of the DSS from the AM65X version with the major change being the addition of another OLDI TX. With the help of 2 OLDI TXes, the AM625 DSS can support dual-linked OLDI displays with a resolution of up-to 2K or WUXGA (1920x1200@60fps) at half the OLDI clock frequency or even cloned video outputs on each of the TXes. This patch series acts as a continuation of the patches posted in v3[1]. The OLDI support patches combined from v5 onwards are now separated again. The OLDI support will be added subsequently with a separte patch series. I have tested these patches on AM625 SK-EVM and AM625 based Beagle Play. To test this series on AM625 based platforms, basic display support patches (for driver + devicetree) can be found in the "next_am62-base_support-V2" branch on my github fork[2]. [1]: V3: https://patchwork.freedesktop.org/series/105373/ [2]: https://github.com/aradhya07/linux-ab/tree/next_am62-base_support-V2 Previous versions: - V8: https://patchwork.freedesktop.org/series/119088/ - V7: https://patchwork.freedesktop.org/series/113328/ - V6: https://patchwork.freedesktop.org/series/06/ - V5: https://patchwork.freedesktop.org/series/109194/ Changelog: V9: - Edit the commit message for Patch 2/2. - Add Krzysztof Kozlowski's and Tomi Valkeinen's tags. V8: - Rebase for current merge window. - Drop all the OLDI support patches. - Update the binding to remove the 2nd OLDI port instances. - Drop the Reviewed-by tags of Krzysztof Kozlowski and Rahul T R because of the changes. V7: - Rebase to current linux-next. - Address Tomi Valkeinen's comments. 1. Separate the DSS VP and output port coupling. v6 introduced 'output_port_bus_type' in addition to 'vp_bus_type' but having both of the variables was redundant. Hence, in v7 the 'output_port_bus_type' essentially replaces 'vp_bus_type'. 2. Break Patch v6 2/5 into 2 separate patches (v7 1/6 and v7 3/6). 3. Change in name and addition of OLDI mode macros. 4. Other minor changes. V6: - Rebase for current merge window. - Add 'allOf:' condition in the DT binding. - Address Tomi Valkeinen's comments. 1. Combine DT binding patches for new compatible and 3rd DSS port. 2. Further separate DSS VPs and output ports. 3. Separate OLDI mode discovery logic from the panel/bridge discovery (which allowed support for OLDI bridges as well.) 4. Organize OLDI IO control register macros platform wise. V5: - Rebase for current merge window. - Add max DT ports in DSS features. - Combine the OLDI support series. (Changes from OLDI support series v1) - Address Tomi Valkeinen's comments. 1. Update the OLDI link detection approach. 2. Add port #3 for 2nd OLDI TX. 3. Configure 2 panel-bridges for cloned panels. 4. Drop the OLDI clock set patch. 5. Drop rgb565-to-888 patch. V3: - Change yaml enum in alphabetical order. - Correct a typo. V2: - Remove redundant register array. Aradhya Bhatia (2): dt-bindings: display: ti,am65x-dss: Add am625 dss compatible drm/tidss: Add support for AM625 DSS .../bindings/display/ti/ti,am65x-dss.yaml | 18 -- drivers/gpu/drm/tidss/tidss_dispc.c | 57 ++- drivers/gpu/drm/tidss/tidss_dispc.h | 2 + drivers/gpu/drm/tidss/tidss_drv.c | 1 + 4 files changed, 71 insertions(+), 7 deletions(-) -- 2.40.1
Re: [PATCH v8 2/2] drm/tidss: Add support for AM625 DSS
Hi Tomi, Thank you for the reviews! On 16-Jun-23 18:15, Tomi Valkeinen wrote: > Hi, > > On 08/06/2023 19:37, Aradhya Bhatia wrote: >> Add support for the DSS controller on TI's AM625 SoC in the tidss >> driver. >> >> The AM625 DSS supports 2 video planes connecting to 2 video ports. >> The first plane is a full plane supporting all the features, while the >> 2nd plane is a "lite" plane without scaling support. > > The DRM planes are reversed compared to the HW planes, aren't they? Is > the above referring to HW planes? Yes, I am referring to the HW planes, and the DRM planes reversed as well. =) > >> The first video port in AM625 DSS internally provides DPI output to 2 >> OLDI transmitters. Each OLDI TX outputs 4 differential lanes of video >> output and 1 of clock output. > > I think it should be explained that OLDI is not supported in this > version, but will be added later. Okay, I will make the change. Regards Aradhya > > Other than that: > > Reviewed-by: Tomi Valkeinen > > Tomi >
[PATCH v8 2/2] drm/tidss: Add support for AM625 DSS
Add support for the DSS controller on TI's AM625 SoC in the tidss
driver.
The AM625 DSS supports 2 video planes connecting to 2 video ports.
The first plane is a full plane supporting all the features, while the
2nd plane is a "lite" plane without scaling support.
The first video port in AM625 DSS internally provides DPI output to 2
OLDI transmitters. Each OLDI TX outputs 4 differential lanes of video
output and 1 of clock output.
The second video port outputs DPI data directly out of the SoC. It has
24 data lines and can support a maximum of RGB888 output bus format.
Signed-off-by: Aradhya Bhatia
---
Notes:
Changes from v7:
* Drop all changes made after v3.
- Drop output bus type support. All outputs from DSS will be the
video port outptus.
* Make the first video port type as INTERNAL from OLDI.
drivers/gpu/drm/tidss/tidss_dispc.c | 57 -
drivers/gpu/drm/tidss/tidss_dispc.h | 2 +
drivers/gpu/drm/tidss/tidss_drv.c | 1 +
3 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index dca077411f77..484da1aa27bb 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -275,6 +275,55 @@ const struct dispc_features dispc_j721e_feats = {
.vid_order = { 1, 3, 0, 2 },
};
+const struct dispc_features dispc_am625_feats = {
+ .max_pclk_khz = {
+ [DISPC_VP_DPI] = 165000,
+ [DISPC_VP_INTERNAL] = 17,
+ },
+
+ .scaling = {
+ .in_width_max_5tap_rgb = 1280,
+ .in_width_max_3tap_rgb = 2560,
+ .in_width_max_5tap_yuv = 2560,
+ .in_width_max_3tap_yuv = 4096,
+ .upscale_limit = 16,
+ .downscale_limit_5tap = 4,
+ .downscale_limit_3tap = 2,
+ /*
+* The max supported pixel inc value is 255. The value
+* of pixel inc is calculated like this: 1+(xinc-1)*bpp.
+* The maximum bpp of all formats supported by the HW
+* is 8. So the maximum supported xinc value is 32,
+* because 1+(32-1)*8 < 255 < 1+(33-1)*4.
+*/
+ .xinc_max = 32,
+ },
+
+ .subrev = DISPC_AM625,
+
+ .common = "common",
+ .common_regs = tidss_am65x_common_regs,
+
+ .num_vps = 2,
+ .vp_name = { "vp1", "vp2" },
+ .ovr_name = { "ovr1", "ovr2" },
+ .vpclk_name = { "vp1", "vp2" },
+ .vp_bus_type = { DISPC_VP_INTERNAL, DISPC_VP_DPI },
+
+ .vp_feat = { .color = {
+ .has_ctm = true,
+ .gamma_size = 256,
+ .gamma_type = TIDSS_GAMMA_8BIT,
+ },
+ },
+
+ .num_planes = 2,
+ /* note: vid is plane_id 0 and vidl1 is plane_id 1 */
+ .vid_name = { "vid", "vidl1" },
+ .vid_lite = { false, true, },
+ .vid_order = { 1, 0 },
+};
+
static const u16 *dispc_common_regmap;
struct dss_vp_data {
@@ -776,6 +825,7 @@ dispc_irq_t dispc_read_and_clear_irqstatus(struct
dispc_device *dispc)
switch (dispc->feat->subrev) {
case DISPC_K2G:
return dispc_k2g_read_and_clear_irqstatus(dispc);
+ case DISPC_AM625:
case DISPC_AM65X:
case DISPC_J721E:
return dispc_k3_read_and_clear_irqstatus(dispc);
@@ -791,6 +841,7 @@ void dispc_set_irqenable(struct dispc_device *dispc,
dispc_irq_t mask)
case DISPC_K2G:
dispc_k2g_set_irqenable(dispc, mask);
break;
+ case DISPC_AM625:
case DISPC_AM65X:
case DISPC_J721E:
dispc_k3_set_irqenable(dispc, mask);
@@ -1281,6 +1332,7 @@ void dispc_ovr_set_plane(struct dispc_device *dispc, u32
hw_plane,
dispc_k2g_ovr_set_plane(dispc, hw_plane, hw_videoport,
x, y, layer);
break;
+ case DISPC_AM625:
case DISPC_AM65X:
dispc_am65x_ovr_set_plane(dispc, hw_plane, hw_videoport,
x, y, layer);
@@ -2199,6 +2251,7 @@ static void dispc_plane_init(struct dispc_device *dispc)
case DISPC_K2G:
dispc_k2g_plane_init(dispc);
break;
+ case DISPC_AM625:
case DISPC_AM65X:
case DISPC_J721E:
dispc_k3_plane_init(dispc);
@@ -2305,6 +2358,7 @@ static void dispc_vp_write_gamma_table(struct
dispc_device *dispc,
case DISPC_K2G:
dispc_k2g_vp_write_gamma_table(dispc, hw_videoport);
break;
+ case DISPC_AM625:
case DISPC_AM65X:
dispc_am65x_vp_write_gamma_table(dispc, hw_videoport);
break;
@@ -2579,7 +2633,8 @@ int dispc_runtime_resum
[PATCH v8 1/2] dt-bindings: display: ti, am65x-dss: Add am625 dss compatible
The DSS controller on TI's AM625 SoC is an update from that on TI's AM65X SoC. The former has an additional OLDI TX on its first video port that helps output cloned video or WUXGA (1920x1200@60fps) resolution video output over a dual-link mode to reduce the required OLDI clock output. The second video port is same from AM65x DSS and it outputs DPI video data. It can support 2K resolutions @ 60fps, independently. Add the new controller's compatible and update descriptions. Signed-off-by: Aradhya Bhatia --- Notes: Changes from v7: * Drop the 3rd port property and update descriptions. * Drop the Reviewed-by tags of Krzysztof Kozlowski and Rahul T R because of the changes. .../bindings/display/ti/ti,am65x-dss.yaml | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml index b6b402f16161..ae09cd3cbce1 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml @@ -12,14 +12,18 @@ maintainers: - Tomi Valkeinen description: | - The AM65x TI Keystone Display SubSystem with two output ports and - two video planes. The first video port supports OLDI and the second - supports DPI format. The fist plane is full video plane with all - features and the second is a "lite plane" without scaling support. + The AM625 and AM65x TI Keystone Display SubSystem with two output + ports and two video planes. In AM65x DSS, the first video port + supports 1 OLDI TX and in AM625 DSS, the first video port output is + internally routed to 2 OLDI TXes. The second video port supports DPI + format. The first plane is full video plane with all features and the + second is a "lite plane" without scaling support. properties: compatible: -const: ti,am65x-dss +enum: + - ti,am625-dss + - ti,am65x-dss reg: description: @@ -80,7 +84,9 @@ properties: port@0: $ref: /schemas/graph.yaml#/properties/port description: - The DSS OLDI output port node form video port 1 + For AM65x DSS, the OLDI output port node from video port 1. + For AM625 DSS, the internal DPI output port node from video + port 1. port@1: $ref: /schemas/graph.yaml#/properties/port -- 2.40.1
[PATCH v8 0/2] Add DSS support for AM625 SoC
This patch series adds a new compatible for the Display SubSystem (DSS) controller on TI's AM625 SoC. It further adds the required support for the same in the tidss driver. The AM625-DSS is a newer version of the DSS from the AM65X version with the major change being the addition of another OLDI TX. With the help of 2 OLDI TXes, the AM625 DSS can support dual-linked OLDI displays with a resolution of up-to 2K or WUXGA (1920x1200@60fps) at half the OLDI clock frequency or even cloned video outputs on each of the TXes. This patch series acts as a continuation of the patches posted in v3[1]. The OLDI support patches combined from v5 onwards are now separated again. The OLDI support will be added subsequently with a separte patch series. I have dropped Krzysztof Kozlowski's and Rahul T R's R-b tags from patch 1/2 considering the changes involved in the binding. I have tested these patches on AM625 SK-EVM and AM625 based Beagle Play. To test this series on AM625 based platforms, basic display support patches, (for driver + devicetree) can be found in the "next_am62-base_support" branch on my github fork[2]. [1]: V3: https://patchwork.freedesktop.org/series/105373/ [2]: https://github.com/aradhya07/linux-ab/tree/next_am62-base_support Previous versions: - V7: https://patchwork.freedesktop.org/series/113328/ - V6: https://patchwork.freedesktop.org/series/06/ - V5: https://patchwork.freedesktop.org/series/109194/ Changelog: V8: - Rebase for current merge window. - Drop all the OLDI support patches. - Update the binding to remove the 2nd OLDI port instances. - Drop the Reviewed-by tags of Krzysztof Kozlowski and Rahul T R because of the changes. V7: - Rebase to current linux-next. - Address Tomi Valkeinen's comments. 1. Separate the DSS VP and output port coupling. v6 introduced 'output_port_bus_type' in addition to 'vp_bus_type' but having both of the variables was redundant. Hence, in v7 the 'output_port_bus_type' essentially replaces 'vp_bus_type'. 2. Break Patch v6 2/5 into 2 separate patches (v7 1/6 and v7 3/6). 3. Change in name and addition of OLDI mode macros. 4. Other minor changes. V6: - Rebase for current merge window. - Add 'allOf:' condition in the DT binding. - Address Tomi Valkeinen's comments. 1. Combine DT binding patches for new compatible and 3rd DSS port. 2. Further separate DSS VPs and output ports. 3. Separate OLDI mode discovery logic from the panel/bridge discovery (which allowed support for OLDI bridges as well.) 4. Organize OLDI IO control register macros platform wise. V5: - Rebase for current merge window. - Add max DT ports in DSS features. - Combine the OLDI support series. (Changes from OLDI support series v1) - Address Tomi Valkeinen's comments. 1. Update the OLDI link detection approach. 2. Add port #3 for 2nd OLDI TX. 3. Configure 2 panel-bridges for cloned panels. 4. Drop the OLDI clock set patch. 5. Drop rgb565-to-888 patch. V3: - Change yaml enum in alphabetical order. - Correct a typo. V2: - Remove redundant register array. Aradhya Bhatia (2): dt-bindings: display: ti,am65x-dss: Add am625 dss compatible drm/tidss: Add support for AM625 DSS .../bindings/display/ti/ti,am65x-dss.yaml | 18 -- drivers/gpu/drm/tidss/tidss_dispc.c | 57 ++- drivers/gpu/drm/tidss/tidss_dispc.h | 2 + drivers/gpu/drm/tidss/tidss_drv.c | 1 + 4 files changed, 71 insertions(+), 7 deletions(-) -- 2.40.1
Re: [PATCH v7 0/8] drm/tidss: Use new connector model for tidss
Hi Neil, Thank you for reviewing the previous patches! On 06-Jun-23 14:37, Neil Armstrong wrote: > Hi, > > On 06/06/2023 10:21, Aradhya Bhatia wrote: >> Hi all, >> >> I have picked up this long standing series from Nikhil Devshatwar[1]. >> >> This series moves the tidss to using new connectoe model, where the SoC >> driver (tidss) creates the connector and all the bridges are attached >> with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR. It also now creates bridge >> to support format negotiation and and 'simple' encoder to expose it to >> the userspace. >> >> Since the bridges do not create the connector, the bus_format and >> bus_flag is set via atomic hooks. >> >> Support format negotiations in the tfp410, sii902x and mhdp-8546 bridge >> drivers as a first step before moving the connector model. >> >> These patches were tested on AM625-SK EVM, AM625 SoC based BeaglePlay, >> and J721E-SK. Display support for AM625 SoC has not been added upstream >> and is a WIP. To test this series on AM625 based platforms, basic >> display support patches, (for driver + devicetree), can be found in >> the "next_AttachNoConn-v2" branch on my github fork[2]. > > I can apply all bridge patches right now so only the tidss change remain, > is that ok for you ? > While the bridge patches and the tidss patch can be separately built without any issue, the tidss functionality will break if only the bridge patches get picked up, and not the tidss. Would it be possible for you to pick all the patches together once Tomi acks the tidss patch? Regards Aradhya > >> >> Thanks, >> Aradhya >> >> [1]: https://patchwork.freedesktop.org/series/82765/#rev5 >> [2]: https://github.com/aradhya07/linux-ab/tree/next_AttachNoConn-v2 >> >> Change Log: >> V6 -> V7 >> - Rebase and cosmetic changes. >> - Drop the output format check condition for mhdp8546 and hence, >> drop Tomi Valkeinen's R-b tag. >> - Added tags wherever suggested. >> >> V5 -> V6 >> - Rebase and cosmetic changes >> - Dropped the output format check condition for tfp410 and hence, >> dropped Tomi Valkeinen's and Laurent Pinchart's R-b tags. >> - Based on Boris Brezillon's comments: dropped patches 5 and 6 from >> the series and instead created a single patch that, >> 1. Creates tidss bridge for format negotiation. >> 2. Creates 'simple' encoder for userspace exposure. >> 3. Creates a tidss connector. >> 4. Attaches the next-bridge to encoder with the >> DRM_BRIDGE_ATTACH_NO_CONNECTOR flag. >> - Add format negotiation support for sii902x driver. >> >> Previous versions: >> V1 to V6: https://patchwork.freedesktop.org/series/82765/ >> >> Aradhya Bhatia (3): >> drm/bridge: sii902x: Support format negotiation hooks >> drm/bridge: sii902x: Set input_bus_flags in atomic_check >> drm/tidss: Update encoder/bridge chain connect model >> >> Nikhil Devshatwar (5): >> drm/bridge: tfp410: Support format negotiation hooks >> drm/bridge: tfp410: Set input_bus_flags in atomic_check >> drm/bridge: mhdp8546: Add minimal format negotiation >> drm/bridge: mhdp8546: Set input_bus_flags from atomic_check >> drm/bridge: cdns-mhdp8546: Fix the interrupt enable/disable >> >> .../drm/bridge/cadence/cdns-mhdp8546-core.c | 77 ++ >> .../drm/bridge/cadence/cdns-mhdp8546-core.h | 2 +- >> .../drm/bridge/cadence/cdns-mhdp8546-j721e.c | 9 +- >> .../drm/bridge/cadence/cdns-mhdp8546-j721e.h | 2 +- >> drivers/gpu/drm/bridge/sii902x.c | 40 + >> drivers/gpu/drm/bridge/ti-tfp410.c | 43 ++ >> drivers/gpu/drm/tidss/tidss_encoder.c | 140 +++--- >> drivers/gpu/drm/tidss/tidss_encoder.h | 5 +- >> drivers/gpu/drm/tidss/tidss_kms.c | 12 +- >> 9 files changed, 235 insertions(+), 95 deletions(-) >> >
[PATCH v7 7/8] drm/tidss: Update encoder/bridge chain connect model
With the new encoder/bridge chain model, the display controller driver
is required to create a drm_connector entity instead of asking the
bridge to do so during drm_bridge_attach. Moreover, the controller
driver should create a drm_bridge entity to negotiate bus formats and a
'simple' drm_encoder entity to expose it to userspace.
Update the encoder/bridge initialization sequence in tidss as per the
new model.
Signed-off-by: Aradhya Bhatia
---
Notes:
changes from v5:
* Drop patches 5 and 6 from the original series.
* Instead add this patch that addresses Boris Brezillon's comments
of creating bridge, simple encoder and connector.
drivers/gpu/drm/tidss/tidss_encoder.c | 140 --
drivers/gpu/drm/tidss/tidss_encoder.h | 5 +-
drivers/gpu/drm/tidss/tidss_kms.c | 12 +--
3 files changed, 94 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_encoder.c
b/drivers/gpu/drm/tidss/tidss_encoder.c
index 0d4865e9c03d..17a86bed8054 100644
--- a/drivers/gpu/drm/tidss/tidss_encoder.c
+++ b/drivers/gpu/drm/tidss/tidss_encoder.c
@@ -6,91 +6,125 @@
#include
+#include
+#include
+#include
#include
#include
#include
#include
+#include
#include "tidss_crtc.h"
#include "tidss_drv.h"
#include "tidss_encoder.h"
-static int tidss_encoder_atomic_check(struct drm_encoder *encoder,
- struct drm_crtc_state *crtc_state,
- struct drm_connector_state *conn_state)
+struct tidss_encoder {
+ struct drm_bridge bridge;
+ struct drm_encoder encoder;
+ struct drm_connector *connector;
+ struct drm_bridge *next_bridge;
+ struct tidss_device *tidss;
+};
+
+static inline struct tidss_encoder
+*bridge_to_tidss_encoder(struct drm_bridge *b)
+{
+ return container_of(b, struct tidss_encoder, bridge);
+}
+
+static int tidss_bridge_attach(struct drm_bridge *bridge,
+ enum drm_bridge_attach_flags flags)
+{
+ struct tidss_encoder *t_enc = bridge_to_tidss_encoder(bridge);
+
+ return drm_bridge_attach(bridge->encoder, t_enc->next_bridge,
+bridge, flags);
+}
+
+static int tidss_bridge_atomic_check(struct drm_bridge *bridge,
+struct drm_bridge_state *bridge_state,
+struct drm_crtc_state *crtc_state,
+struct drm_connector_state *conn_state)
{
- struct drm_device *ddev = encoder->dev;
+ struct tidss_encoder *t_enc = bridge_to_tidss_encoder(bridge);
+ struct tidss_device *tidss = t_enc->tidss;
struct tidss_crtc_state *tcrtc_state = to_tidss_crtc_state(crtc_state);
struct drm_display_info *di = _state->connector->display_info;
- struct drm_bridge *bridge;
- bool bus_flags_set = false;
-
- dev_dbg(ddev->dev, "%s\n", __func__);
-
- /*
-* Take the bus_flags from the first bridge that defines
-* bridge timings, or from the connector's display_info if no
-* bridge defines the timings.
-*/
- drm_for_each_bridge_in_chain(encoder, bridge) {
- if (!bridge->timings)
- continue;
-
- tcrtc_state->bus_flags = bridge->timings->input_bus_flags;
- bus_flags_set = true;
- break;
- }
+ struct drm_bridge_state *next_bridge_state = NULL;
+
+ if (t_enc->next_bridge)
+ next_bridge_state =
drm_atomic_get_new_bridge_state(crtc_state->state,
+
t_enc->next_bridge);
- if (!di->bus_formats || di->num_bus_formats == 0) {
- dev_err(ddev->dev, "%s: No bus_formats in connected display\n",
+ if (next_bridge_state) {
+ tcrtc_state->bus_flags = next_bridge_state->input_bus_cfg.flags;
+ tcrtc_state->bus_format =
next_bridge_state->input_bus_cfg.format;
+ } else if (di->num_bus_formats) {
+ tcrtc_state->bus_format = di->bus_formats[0];
+ tcrtc_state->bus_flags = di->bus_flags;
+ } else {
+ dev_err(tidss->dev, "%s: No bus_formats in connected display\n",
__func__);
return -EINVAL;
}
- // XXX any cleaner way to set bus format and flags?
- tcrtc_state->bus_format = di->bus_formats[0];
- if (!bus_flags_set)
- tcrtc_state->bus_flags = di->bus_flags;
-
return 0;
}
-static void tidss_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
- kfree(encoder);
-}
-
-static const struct drm_encoder_helper_funcs encoder_helper_funcs = {
- .atomic_check =
[PATCH v7 8/8] drm/bridge: cdns-mhdp8546: Fix the interrupt enable/disable
From: Nikhil Devshatwar
When removing the tidss driver, there is a warning reported by
kernel about an unhandled interrupt for mhdp driver.
[ 43.238895] irq 31: nobody cared (try booting with the "irqpoll" option)
... [snipped backtrace]
[ 43.330735] handlers:
[ 43.333020] [<5367c4f9>] irq_default_primary_handler threaded
[<7e02b601>]
cdns_mhdp_irq_handler [cdns_mhdp8546]
[ 43.344607] Disabling IRQ #31
This happens because as part of cdns_mhdp_bridge_hpd_disable, driver tries
to disable the interrupts. While disabling the SW_EVENT interrupts,
it accidentally enables the MBOX interrupts, which are not handled by
the driver.
Fix this with a read-modify-write to update only required bits.
Use the enable / disable function as required in other places.
Signed-off-by: Nikhil Devshatwar
Reviewed-by: Swapnil Jakhade
Reviewed-by: Tomi Valkeinen
Signed-off-by: Aradhya Bhatia
---
Notes:
changes from v2:
* Fix the interrupt enable logic at other places in code
* Reorder functions so that they can be used earlier in the program
changes from v5:
* Manual rebase to linux-next.
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 44 +--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index f12fb62821f7..ecb935e46b62 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -54,6 +54,26 @@
#include "cdns-mhdp8546-hdcp.h"
#include "cdns-mhdp8546-j721e.h"
+static void cdns_mhdp_bridge_hpd_enable(struct drm_bridge *bridge)
+{
+ struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
+
+ /* Enable SW event interrupts */
+ if (mhdp->bridge_attached)
+ writel(readl(mhdp->regs + CDNS_APB_INT_MASK) &
+ ~CDNS_APB_INT_MASK_SW_EVENT_INT,
+ mhdp->regs + CDNS_APB_INT_MASK);
+}
+
+static void cdns_mhdp_bridge_hpd_disable(struct drm_bridge *bridge)
+{
+ struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
+
+ writel(readl(mhdp->regs + CDNS_APB_INT_MASK) |
+ CDNS_APB_INT_MASK_SW_EVENT_INT,
+ mhdp->regs + CDNS_APB_INT_MASK);
+}
+
static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
{
int ret, empty;
@@ -749,9 +769,7 @@ static int cdns_mhdp_fw_activate(const struct firmware *fw,
* MHDP_HW_STOPPED happens only due to driver removal when
* bridge should already be detached.
*/
- if (mhdp->bridge_attached)
- writel(~(u32)CDNS_APB_INT_MASK_SW_EVENT_INT,
- mhdp->regs + CDNS_APB_INT_MASK);
+ cdns_mhdp_bridge_hpd_enable(>bridge);
spin_unlock(>start_lock);
@@ -1740,8 +1758,7 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
/* Enable SW event interrupts */
if (hw_ready)
- writel(~(u32)CDNS_APB_INT_MASK_SW_EVENT_INT,
- mhdp->regs + CDNS_APB_INT_MASK);
+ cdns_mhdp_bridge_hpd_enable(bridge);
return 0;
aux_unregister:
@@ -2212,23 +2229,6 @@ static struct edid *cdns_mhdp_bridge_get_edid(struct
drm_bridge *bridge,
return cdns_mhdp_get_edid(mhdp, connector);
}
-static void cdns_mhdp_bridge_hpd_enable(struct drm_bridge *bridge)
-{
- struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
-
- /* Enable SW event interrupts */
- if (mhdp->bridge_attached)
- writel(~(u32)CDNS_APB_INT_MASK_SW_EVENT_INT,
- mhdp->regs + CDNS_APB_INT_MASK);
-}
-
-static void cdns_mhdp_bridge_hpd_disable(struct drm_bridge *bridge)
-{
- struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
-
- writel(CDNS_APB_INT_MASK_SW_EVENT_INT, mhdp->regs + CDNS_APB_INT_MASK);
-}
-
static const struct drm_bridge_funcs cdns_mhdp_bridge_funcs = {
.atomic_enable = cdns_mhdp_atomic_enable,
.atomic_disable = cdns_mhdp_atomic_disable,
--
2.40.1
[PATCH v7 6/8] drm/bridge: sii902x: Set input_bus_flags in atomic_check
input_bus_flags are specified in drm_bridge_timings (legacy) as well
as drm_bridge_state->input_bus_cfg.flags
The flags from the timings will be deprecated. Bridges are supposed
to validate and set the bridge state flags from atomic_check.
Implement atomic_check hook for the same.
Signed-off-by: Aradhya Bhatia
Reviewed-by: Neil Armstrong
---
Notes:
changes from v6:
* Add Neil Armstrong's R-b tag.
drivers/gpu/drm/bridge/sii902x.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 70aeb04b7f77..8f1ec526863a 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -494,6 +494,20 @@ static u32
*sii902x_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
return input_fmts;
}
+static int sii902x_bridge_atomic_check(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+ /*
+* There might be flags negotiation supported in future but
+* set the bus flags in atomic_check statically for now.
+*/
+ bridge_state->input_bus_cfg.flags = bridge->timings->input_bus_flags;
+
+ return 0;
+}
+
static const struct drm_bridge_funcs sii902x_bridge_funcs = {
.attach = sii902x_bridge_attach,
.mode_set = sii902x_bridge_mode_set,
@@ -505,6 +519,7 @@ static const struct drm_bridge_funcs sii902x_bridge_funcs =
{
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_get_input_bus_fmts = sii902x_bridge_atomic_get_input_bus_fmts,
+ .atomic_check = sii902x_bridge_atomic_check,
};
static int sii902x_mute(struct sii902x *sii902x, bool mute)
--
2.40.1
[PATCH v7 3/8] drm/bridge: mhdp8546: Add minimal format negotiation
From: Nikhil Devshatwar
With new connector model, mhdp bridge will not create the connector and
SoC driver will rely on format negotiation to setup the encoder format.
Support minimal format negotiations hooks in the drm_bridge_funcs.
Complete format negotiation can be added based on EDID data.
This patch adds the minimal required support to avoid failure
after moving to new connector model.
Signed-off-by: Nikhil Devshatwar
[a-bhatia1: Drop the output_fmt check condition]
Signed-off-by: Aradhya Bhatia
---
Notes:
changes from v1:
* cosmetic fixes, commit message update.
changes from v5:
* drop the default_bus_format variable and directly assigned
MEDIA_BUS_FMT_RGB121212_1X36 to input_fmts.
changes from v6:
* Drop the output_fmt check condition and hence drop Tomi
Valkeinen's R-b tag.
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 22 +++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index f6822dfa3805..afd4e353f37a 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -2146,6 +2146,27 @@ cdns_mhdp_bridge_atomic_reset(struct drm_bridge *bridge)
return _mhdp_state->base;
}
+static u32 *cdns_mhdp_get_input_bus_fmts(struct drm_bridge *bridge,
+struct drm_bridge_state *bridge_state,
+struct drm_crtc_state *crtc_state,
+struct drm_connector_state *conn_state,
+u32 output_fmt,
+unsigned int *num_input_fmts)
+{
+ u32 *input_fmts;
+
+ *num_input_fmts = 0;
+
+ input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+
+ *num_input_fmts = 1;
+ input_fmts[0] = MEDIA_BUS_FMT_RGB121212_1X36;
+
+ return input_fmts;
+}
+
static int cdns_mhdp_atomic_check(struct drm_bridge *bridge,
struct drm_bridge_state *bridge_state,
struct drm_crtc_state *crtc_state,
@@ -2210,6 +2231,7 @@ static const struct drm_bridge_funcs
cdns_mhdp_bridge_funcs = {
.atomic_duplicate_state = cdns_mhdp_bridge_atomic_duplicate_state,
.atomic_destroy_state = cdns_mhdp_bridge_atomic_destroy_state,
.atomic_reset = cdns_mhdp_bridge_atomic_reset,
+ .atomic_get_input_bus_fmts = cdns_mhdp_get_input_bus_fmts,
.detect = cdns_mhdp_bridge_detect,
.get_edid = cdns_mhdp_bridge_get_edid,
.hpd_enable = cdns_mhdp_bridge_hpd_enable,
--
2.40.1
[PATCH v7 4/8] drm/bridge: mhdp8546: Set input_bus_flags from atomic_check
From: Nikhil Devshatwar
input_bus_flags are specified in drm_bridge_timings (legacy) as well
as drm_bridge_state->input_bus_cfg.flags
The flags from the timings will be deprecated. Bridges are supposed
to validate and set the bridge state flags from atomic_check.
Signed-off-by: Nikhil Devshatwar
[a-bhatia1: replace timings in cdns_mhdp_platform_info by input_bus_flags]
Signed-off-by: Aradhya Bhatia
Reviewed-by: Neil Armstrong
---
Notes:
changes from v5:
* remove the wrongly addded return statement in tfp410 driver.
* replace the timings field in cdns_mhdp_platform_info by
input_bus_flags field, in order to get rid of bridge->timings
altogether.
changes from v6:
* Add Neil Armstrong's R-b tag.
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h | 2 +-
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c | 9 -
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.h | 2 +-
4 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index afd4e353f37a..f12fb62821f7 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -2186,6 +2186,13 @@ static int cdns_mhdp_atomic_check(struct drm_bridge
*bridge,
return -EINVAL;
}
+ /*
+* There might be flags negotiation supported in future.
+* Set the bus flags in atomic_check statically for now.
+*/
+ if (mhdp->info)
+ bridge_state->input_bus_cfg.flags =
*mhdp->info->input_bus_flags;
+
mutex_unlock(>link_mutex);
return 0;
}
@@ -2551,8 +2558,6 @@ static int cdns_mhdp_probe(struct platform_device *pdev)
mhdp->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID |
DRM_BRIDGE_OP_HPD;
mhdp->bridge.type = DRM_MODE_CONNECTOR_DisplayPort;
- if (mhdp->info)
- mhdp->bridge.timings = mhdp->info->timings;
ret = phy_init(mhdp->phy);
if (ret) {
@@ -2639,7 +2644,7 @@ static const struct of_device_id mhdp_ids[] = {
#ifdef CONFIG_DRM_CDNS_MHDP8546_J721E
{ .compatible = "ti,j721e-mhdp8546",
.data = &(const struct cdns_mhdp_platform_info) {
- .timings = _ti_j721e_bridge_timings,
+ .input_bus_flags = _ti_j721e_bridge_input_bus_flags,
.ops = _ti_j721e_ops,
},
},
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
index be510d17..bad2fc0c7306 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
@@ -336,7 +336,7 @@ struct cdns_mhdp_bridge_state {
};
struct cdns_mhdp_platform_info {
- const struct drm_bridge_timings *timings;
+ const u32 *input_bus_flags;
const struct mhdp_platform_ops *ops;
};
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
index dfe1b59514f7..12d04be4e242 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
@@ -71,8 +71,7 @@ const struct mhdp_platform_ops mhdp_ti_j721e_ops = {
.disable = cdns_mhdp_j721e_disable,
};
-const struct drm_bridge_timings mhdp_ti_j721e_bridge_timings = {
- .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
- DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE |
- DRM_BUS_FLAG_DE_HIGH,
-};
+const u32
+mhdp_ti_j721e_bridge_input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
+ DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE |
+ DRM_BUS_FLAG_DE_HIGH;
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.h
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.h
index 97d20d115a24..5ddca07a4255 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.h
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.h
@@ -14,6 +14,6 @@
struct mhdp_platform_ops;
extern const struct mhdp_platform_ops mhdp_ti_j721e_ops;
-extern const struct drm_bridge_timings mhdp_ti_j721e_bridge_timings;
+extern const u32 mhdp_ti_j721e_bridge_input_bus_flags;
#endif /* !CDNS_MHDP8546_J721E_H */
--
2.40.1
[PATCH v7 0/8] drm/tidss: Use new connector model for tidss
Hi all, I have picked up this long standing series from Nikhil Devshatwar[1]. This series moves the tidss to using new connectoe model, where the SoC driver (tidss) creates the connector and all the bridges are attached with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR. It also now creates bridge to support format negotiation and and 'simple' encoder to expose it to the userspace. Since the bridges do not create the connector, the bus_format and bus_flag is set via atomic hooks. Support format negotiations in the tfp410, sii902x and mhdp-8546 bridge drivers as a first step before moving the connector model. These patches were tested on AM625-SK EVM, AM625 SoC based BeaglePlay, and J721E-SK. Display support for AM625 SoC has not been added upstream and is a WIP. To test this series on AM625 based platforms, basic display support patches, (for driver + devicetree), can be found in the "next_AttachNoConn-v2" branch on my github fork[2]. Thanks, Aradhya [1]: https://patchwork.freedesktop.org/series/82765/#rev5 [2]: https://github.com/aradhya07/linux-ab/tree/next_AttachNoConn-v2 Change Log: V6 -> V7 - Rebase and cosmetic changes. - Drop the output format check condition for mhdp8546 and hence, drop Tomi Valkeinen's R-b tag. - Added tags wherever suggested. V5 -> V6 - Rebase and cosmetic changes - Dropped the output format check condition for tfp410 and hence, dropped Tomi Valkeinen's and Laurent Pinchart's R-b tags. - Based on Boris Brezillon's comments: dropped patches 5 and 6 from the series and instead created a single patch that, 1. Creates tidss bridge for format negotiation. 2. Creates 'simple' encoder for userspace exposure. 3. Creates a tidss connector. 4. Attaches the next-bridge to encoder with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag. - Add format negotiation support for sii902x driver. Previous versions: V1 to V6: https://patchwork.freedesktop.org/series/82765/ Aradhya Bhatia (3): drm/bridge: sii902x: Support format negotiation hooks drm/bridge: sii902x: Set input_bus_flags in atomic_check drm/tidss: Update encoder/bridge chain connect model Nikhil Devshatwar (5): drm/bridge: tfp410: Support format negotiation hooks drm/bridge: tfp410: Set input_bus_flags in atomic_check drm/bridge: mhdp8546: Add minimal format negotiation drm/bridge: mhdp8546: Set input_bus_flags from atomic_check drm/bridge: cdns-mhdp8546: Fix the interrupt enable/disable .../drm/bridge/cadence/cdns-mhdp8546-core.c | 77 ++ .../drm/bridge/cadence/cdns-mhdp8546-core.h | 2 +- .../drm/bridge/cadence/cdns-mhdp8546-j721e.c | 9 +- .../drm/bridge/cadence/cdns-mhdp8546-j721e.h | 2 +- drivers/gpu/drm/bridge/sii902x.c | 40 + drivers/gpu/drm/bridge/ti-tfp410.c| 43 ++ drivers/gpu/drm/tidss/tidss_encoder.c | 140 +++--- drivers/gpu/drm/tidss/tidss_encoder.h | 5 +- drivers/gpu/drm/tidss/tidss_kms.c | 12 +- 9 files changed, 235 insertions(+), 95 deletions(-) -- 2.40.1
[PATCH v7 1/8] drm/bridge: tfp410: Support format negotiation hooks
From: Nikhil Devshatwar
With new connector model, tfp410 will not create the connector and
SoC driver will rely on format negotiation to setup the encoder format.
Support format negotiations hooks in the drm_bridge_funcs.
Use helper functions for state management.
Input format is the one selected by the bridge from DT properties.
Signed-off-by: Nikhil Devshatwar
[a-bhatia1: Removed output fmt condition check]
Signed-off-by: Aradhya Bhatia
---
Notes:
changes from v1:
* Use only MEDIA_BUS_FMT_FIXED for output
changes from V5:
* Drop the output format check condition because the output
format for HDMI bridges should be RGB888_1X24 and not FIXED.
Hence, also drop Tomi Valkeinen's and Laurent Pinchart's R-b
tags.
drivers/gpu/drm/bridge/ti-tfp410.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index ab63225cd635..7dacc7e03eee 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -206,12 +206,38 @@ static enum drm_mode_status tfp410_mode_valid(struct
drm_bridge *bridge,
return MODE_OK;
}
+static u32 *tfp410_get_input_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state,
+ u32 output_fmt,
+ unsigned int *num_input_fmts)
+{
+ struct tfp410 *dvi = drm_bridge_to_tfp410(bridge);
+ u32 *input_fmts;
+
+ *num_input_fmts = 0;
+
+ input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+
+ *num_input_fmts = 1;
+ input_fmts[0] = dvi->bus_format;
+
+ return input_fmts;
+}
+
static const struct drm_bridge_funcs tfp410_bridge_funcs = {
.attach = tfp410_attach,
.detach = tfp410_detach,
.enable = tfp410_enable,
.disable= tfp410_disable,
.mode_valid = tfp410_mode_valid,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_get_input_bus_fmts = tfp410_get_input_bus_fmts,
};
static const struct drm_bridge_timings tfp410_default_timings = {
--
2.40.1
[PATCH v7 5/8] drm/bridge: sii902x: Support format negotiation hooks
With new connector model, sii902x will not create the connector, when
DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and SoC driver will rely on format
negotiation to setup the encoder format.
Support format negotiations hooks in the drm_bridge_funcs.
Use helper functions for state management.
Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is
the case with older model.
Signed-off-by: Aradhya Bhatia
Reviewed-by: Neil Armstrong
---
Notes:
changes from v6:
* Add Neil Armstrong's R-b tag.
drivers/gpu/drm/bridge/sii902x.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index ef66461e7f7c..70aeb04b7f77 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -473,6 +473,27 @@ static struct edid *sii902x_bridge_get_edid(struct
drm_bridge *bridge,
return sii902x_get_edid(sii902x, connector);
}
+static u32 *sii902x_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+struct drm_bridge_state
*bridge_state,
+struct drm_crtc_state
*crtc_state,
+struct drm_connector_state
*conn_state,
+u32 output_fmt,
+unsigned int
*num_input_fmts)
+{
+ u32 *input_fmts;
+
+ *num_input_fmts = 0;
+
+ input_fmts = kcalloc(1, sizeof(*input_fmts), GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+
+ input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+ *num_input_fmts = 1;
+
+ return input_fmts;
+}
+
static const struct drm_bridge_funcs sii902x_bridge_funcs = {
.attach = sii902x_bridge_attach,
.mode_set = sii902x_bridge_mode_set,
@@ -480,6 +501,10 @@ static const struct drm_bridge_funcs sii902x_bridge_funcs
= {
.enable = sii902x_bridge_enable,
.detect = sii902x_bridge_detect,
.get_edid = sii902x_bridge_get_edid,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_get_input_bus_fmts = sii902x_bridge_atomic_get_input_bus_fmts,
};
static int sii902x_mute(struct sii902x *sii902x, bool mute)
--
2.40.1
[PATCH v7 2/8] drm/bridge: tfp410: Set input_bus_flags in atomic_check
From: Nikhil Devshatwar
input_bus_flags are specified in drm_bridge_timings (legacy) as well
as drm_bridge_state->input_bus_cfg.flags
The flags from the timings will be deprecated. Bridges are supposed
to validate and set the bridge state flags from atomic_check.
Implement atomic_check hook for the same.
Signed-off-by: Nikhil Devshatwar
Signed-off-by: Aradhya Bhatia
Reviewed-by: Neil Armstrong
---
Notes:
changes from v4:
* fix a warning Reported-by: kernel test robot
changes from v5:
* Move the return statement here from patch 4 (where it was added
by mistake).
changes from v6:
* Add new line before return statement.
* Add Neil Armstrong's R-b tag.
drivers/gpu/drm/bridge/ti-tfp410.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index 7dacc7e03eee..edf4d30f4f2a 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -228,6 +228,22 @@ static u32 *tfp410_get_input_bus_fmts(struct drm_bridge
*bridge,
return input_fmts;
}
+static int tfp410_atomic_check(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+ struct tfp410 *dvi = drm_bridge_to_tfp410(bridge);
+
+ /*
+* There might be flags negotiation supported in future.
+* Set the bus flags in atomic_check statically for now.
+*/
+ bridge_state->input_bus_cfg.flags = dvi->timings.input_bus_flags;
+
+ return 0;
+}
+
static const struct drm_bridge_funcs tfp410_bridge_funcs = {
.attach = tfp410_attach,
.detach = tfp410_detach,
@@ -238,6 +254,7 @@ static const struct drm_bridge_funcs tfp410_bridge_funcs = {
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_get_input_bus_fmts = tfp410_get_input_bus_fmts,
+ .atomic_check = tfp410_atomic_check,
};
static const struct drm_bridge_timings tfp410_default_timings = {
--
2.40.1
Re: [PATCH v6 3/8] drm/bridge: mhdp8546: Add minimal format negotiation
Hi Tomi,
Thank you for taking a look at this.
On 26/05/23 14:59, Tomi Valkeinen wrote:
> On 16/05/2023 17:25, Aradhya Bhatia wrote:
>> Hi Neil,
>>
>> Thank you for reviewing the patch.
>>
>> On 16-May-23 12:51, Neil Armstrong wrote:
>>> On 15/05/2023 17:59, Aradhya Bhatia wrote:
>>>> Hi Tomi,
>>>>
>>>> On 12-May-23 14:45, Tomi Valkeinen wrote:
>>>>> On 09/05/2023 12:30, Aradhya Bhatia wrote:
>>>>>> From: Nikhil Devshatwar
>>>>>>
>>>>>> With new connector model, mhdp bridge will not create the
>>>>>> connector and
>>>>>> SoC driver will rely on format negotiation to setup the encoder
>>>>>> format.
>>>>>>
>>>>>> Support minimal format negotiations hooks in the drm_bridge_funcs.
>>>>>> Complete format negotiation can be added based on EDID data.
>>>>>> This patch adds the minimal required support to avoid failure
>>>>>> after moving to new connector model.
>>>>>>
>>>>>> Signed-off-by: Nikhil Devshatwar
>>>>>> Reviewed-by: Tomi Valkeinen
>>>>>
>>>>> You need to add your SoB to this and the other patches.
>>>>
>>>> Okay!
>>>>
>>>>>
>>>>>> ---
>>>>>>
>>>>>> Notes:
>>>>>>
>>>>>> changes from v1:
>>>>>> * cosmetic fixes, commit message update.
>>>>>>
>>>>>> changes from v5:
>>>>>> * dropped the default_bus_format variable and directly
>>>>>> assigned
>>>>>> MEDIA_BUS_FMT_RGB121212_1X36 to input_fmts.
>>>>>>
>>>>>> .../drm/bridge/cadence/cdns-mhdp8546-core.c | 25
>>>>>> +++
>>>>>> 1 file changed, 25 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>>>>>> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>>>>>> index f6822dfa3805..623e4235c94f 100644
>>>>>> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>>>>>> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>>>>>> @@ -2146,6 +2146,30 @@ cdns_mhdp_bridge_atomic_reset(struct
>>>>>> drm_bridge
>>>>>> *bridge)
>>>>>> return _mhdp_state->base;
>>>>>> }
>>>>>> +static u32 *cdns_mhdp_get_input_bus_fmts(struct drm_bridge
>>>>>> *bridge,
>>>>>> + struct drm_bridge_state *bridge_state,
>>>>>> + struct drm_crtc_state *crtc_state,
>>>>>> + struct drm_connector_state *conn_state,
>>>>>> + u32 output_fmt,
>>>>>> + unsigned int *num_input_fmts)
>>>>>> +{
>>>>>> + u32 *input_fmts;
>>>>>> +
>>>>>> + *num_input_fmts = 0;
>>>>>> +
>>>>>> + if (output_fmt != MEDIA_BUS_FMT_FIXED)
>>>>>> + return NULL;
>>>>>
>>>>> The tfp410 and sii902x drivers don't have the above check. Why does
>>>>> mhdp
>>>>> need it? Or the other way, why don't tfp410 and sii902x need it?
>>>>
>>>> I had removed this condition in order to follow status quo, from the
>>>> ITE-66121 HDMI bridge driver.
>>>>
>>>> The idea would have been to drop this for MHDP as well, but I guess I
>>>> overlooked this one.
>>>>
>>>> However...
>>>>
>>>>> I guess at the moment we always do get MEDIA_BUS_FMT_FIXED as the out
>>>>> fmt (in all three bridge drivers), don't we?
>>>>
>>>> ... I tested again to ensure that the above is indeed the case. And
>>>> ended up catching some odd behavior.
>>>>
>>>> It turns out that for all the HDMI bridges (TFP410, SII902X,
>>>> ITE-66121),
>>>> the format negotiation doesn't stop at output_fmt =
>>>> MEDIA_BUS_FMT_FIXED.
>>>> The {bridge}_get_input_format API gets called again with the output_fmt
>>>> = MEDIA_BUS_FMT_RGB24_1X24.
>>>>
>>>> This doesn't happ
Re: [PATCH v6 4/8] drm/bridge: mhdp8546: Set input_bus_flags from atomic_check
Hi Neil,
On 22-May-23 13:35, neil.armstr...@linaro.org wrote:
> On 17/05/2023 07:48, Aradhya Bhatia wrote:
>> Hi Neil,
>>
>> On 16-May-23 12:54, Neil Armstrong wrote:
>>> On 09/05/2023 11:30, Aradhya Bhatia wrote:
>>>> From: Nikhil Devshatwar
>>>>
>>>> input_bus_flags are specified in drm_bridge_timings (legacy) as well
>>>> as drm_bridge_state->input_bus_cfg.flags
>>>>
>>>> The flags from the timings will be deprecated. Bridges are supposed
>>>> to validate and set the bridge state flags from atomic_check.
>>>>
>>>> Signed-off-by: Nikhil Devshatwar
>>>> [a-bhatia1: replace timings in cdns_mhdp_platform_info by
>>>> input_bus_flags]
>>>> Signed-off-by: Aradhya Bhatia
>>>> ---
>>>>
>>>> Notes:
>>>>
>>>> changes from v5:
>>>> * removed the wrongly addded return statement in tfp410 driver.
>>>> * replaced the timings field in cdns_mhdp_platform_info by
>>>> input_bus_flags field, in order to get rid of bridge->timings
>>>> altogether.
>>>>
>>>> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11
>>>> ---
>>>> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h | 2 +-
>>>> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c | 9 -
>>>> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.h | 2 +-
>>>> 4 files changed, 14 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>>>> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>>>> index 623e4235c94f..a677b1267525 100644
>>>> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>>>> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>>>> @@ -2189,6 +2189,13 @@ static int cdns_mhdp_atomic_check(struct
>>>> drm_bridge *bridge,
>>>> return -EINVAL;
>>>> }
>>>> + /*
>>>> + * There might be flags negotiation supported in future.
>>>> + * Set the bus flags in atomic_check statically for now.
>>>> + */
>>>> + if (mhdp->info)
>>>> + bridge_state->input_bus_cfg.flags =
>>>> *mhdp->info->input_bus_flags;
>>>> +
>>>> mutex_unlock(>link_mutex);
>>>> return 0;
>>>> }
>>>> @@ -2554,8 +2561,6 @@ static int cdns_mhdp_probe(struct
>>>> platform_device *pdev)
>>>> mhdp->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID |
>>>> DRM_BRIDGE_OP_HPD;
>>>> mhdp->bridge.type = DRM_MODE_CONNECTOR_DisplayPort;
>>>> - if (mhdp->info)
>>>> - mhdp->bridge.timings = mhdp->info->timings;
>>>
>>> Won't this cause a breakage because at this point in time
>>> bridge.timings->input_bus_flags
>>> seems to be still used by tidss right ?
>>>
>>
>> tidss was using the bridge.timings->input_bus_flags before the 7th
>> patch[1] in this series.
>>
>> After the patch, it only relies on bridge_state and display_info for bus
>> flags and formats.
>
> OK thanks, then:
>
> Reviewed-by: Neil Armstrong
>
> if you resend a new version, please add this info in the commit message.
Thank you! Will do so.
Regards
Aradhya
>
> Neil
>
>>
>>
>> Regards
>> Aradhya
>>
>> [1]: https://lore.kernel.org/all/20230509093036.3303-8-a-bhat...@ti.com/
>>
>>
>>>
>>>> ret = phy_init(mhdp->phy);
>>>> if (ret) {
>>>> @@ -2642,7 +2647,7 @@ static const struct of_device_id mhdp_ids[] = {
>>>> #ifdef CONFIG_DRM_CDNS_MHDP8546_J721E
>>>> { .compatible = "ti,j721e-mhdp8546",
>>>> .data = &(const struct cdns_mhdp_platform_info) {
>>>> - .timings = _ti_j721e_bridge_timings,
>>>> + .input_bus_flags = _ti_j721e_bridge_input_bus_flags,
>>>> .ops = _ti_j721e_ops,
>>>> },
>>>> },
>>>> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
>>>> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
>>>> index be510d17..bad2fc0c7306 100644
>>>> --- a/drivers/gpu/drm/
Re: [PATCH v6 4/8] drm/bridge: mhdp8546: Set input_bus_flags from atomic_check
Hi Neil,
On 16-May-23 12:54, Neil Armstrong wrote:
> On 09/05/2023 11:30, Aradhya Bhatia wrote:
>> From: Nikhil Devshatwar
>>
>> input_bus_flags are specified in drm_bridge_timings (legacy) as well
>> as drm_bridge_state->input_bus_cfg.flags
>>
>> The flags from the timings will be deprecated. Bridges are supposed
>> to validate and set the bridge state flags from atomic_check.
>>
>> Signed-off-by: Nikhil Devshatwar
>> [a-bhatia1: replace timings in cdns_mhdp_platform_info by
>> input_bus_flags]
>> Signed-off-by: Aradhya Bhatia
>> ---
>>
>> Notes:
>>
>> changes from v5:
>> * removed the wrongly addded return statement in tfp410 driver.
>> * replaced the timings field in cdns_mhdp_platform_info by
>> input_bus_flags field, in order to get rid of bridge->timings
>> altogether.
>>
>> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ---
>> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h | 2 +-
>> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c | 9 -
>> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.h | 2 +-
>> 4 files changed, 14 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>> index 623e4235c94f..a677b1267525 100644
>> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>> @@ -2189,6 +2189,13 @@ static int cdns_mhdp_atomic_check(struct
>> drm_bridge *bridge,
>> return -EINVAL;
>> }
>> + /*
>> + * There might be flags negotiation supported in future.
>> + * Set the bus flags in atomic_check statically for now.
>> + */
>> + if (mhdp->info)
>> + bridge_state->input_bus_cfg.flags =
>> *mhdp->info->input_bus_flags;
>> +
>> mutex_unlock(>link_mutex);
>> return 0;
>> }
>> @@ -2554,8 +2561,6 @@ static int cdns_mhdp_probe(struct
>> platform_device *pdev)
>> mhdp->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID |
>> DRM_BRIDGE_OP_HPD;
>> mhdp->bridge.type = DRM_MODE_CONNECTOR_DisplayPort;
>> - if (mhdp->info)
>> - mhdp->bridge.timings = mhdp->info->timings;
>
> Won't this cause a breakage because at this point in time
> bridge.timings->input_bus_flags
> seems to be still used by tidss right ?
>
tidss was using the bridge.timings->input_bus_flags before the 7th
patch[1] in this series.
After the patch, it only relies on bridge_state and display_info for bus
flags and formats.
Regards
Aradhya
[1]: https://lore.kernel.org/all/20230509093036.3303-8-a-bhat...@ti.com/
>
>> ret = phy_init(mhdp->phy);
>> if (ret) {
>> @@ -2642,7 +2647,7 @@ static const struct of_device_id mhdp_ids[] = {
>> #ifdef CONFIG_DRM_CDNS_MHDP8546_J721E
>> { .compatible = "ti,j721e-mhdp8546",
>> .data = &(const struct cdns_mhdp_platform_info) {
>> - .timings = _ti_j721e_bridge_timings,
>> + .input_bus_flags = _ti_j721e_bridge_input_bus_flags,
>> .ops = _ti_j721e_ops,
>> },
>> },
>> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
>> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
>> index be510d17..bad2fc0c7306 100644
>> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
>> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
>> @@ -336,7 +336,7 @@ struct cdns_mhdp_bridge_state {
>> };
>> struct cdns_mhdp_platform_info {
>> - const struct drm_bridge_timings *timings;
>> + const u32 *input_bus_flags;
>> const struct mhdp_platform_ops *ops;
>> };
>> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
>> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
>> index dfe1b59514f7..12d04be4e242 100644
>> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
>> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
>> @@ -71,8 +71,7 @@ const struct mhdp_platform_ops mhdp_ti_j721e_ops = {
>> .disable = cdns_mhdp_j721e_disable,
>> };
>> -const struct drm_bridge_timings mhdp_ti_j721e_bridge_timings = {
>> - .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
>> - DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE |
>> - DRM_BUS_FLAG_DE_HIGH,
>> -};
>> +const u32
>> +mh
Re: [PATCH v6 2/8] drm/bridge: tfp410: Set input_bus_flags in atomic_check
Hi Neil,
On 16-May-23 12:55, Neil Armstrong wrote:
> On 09/05/2023 11:30, Aradhya Bhatia wrote:
>> From: Nikhil Devshatwar
>>
>> input_bus_flags are specified in drm_bridge_timings (legacy) as well
>> as drm_bridge_state->input_bus_cfg.flags
>>
>> The flags from the timings will be deprecated. Bridges are supposed
>> to validate and set the bridge state flags from atomic_check.
>>
>> Implement atomic_check hook for the same.
>>
>> Signed-off-by: Nikhil Devshatwar
>> ---
>>
>> Notes:
>> changes from v4:
>> * fix a warning Reported-by: kernel test robot
>>
>> changes from v5:
>> * Moved the return statement here from patch 4 (where it was added
>> by mistake).
>>
>> drivers/gpu/drm/bridge/ti-tfp410.c | 16
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
>> b/drivers/gpu/drm/bridge/ti-tfp410.c
>> index 7dacc7e03eee..631ae8f11a77 100644
>> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
>> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
>> @@ -228,6 +228,21 @@ static u32 *tfp410_get_input_bus_fmts(struct
>> drm_bridge *bridge,
>> return input_fmts;
>> }
>> +static int tfp410_atomic_check(struct drm_bridge *bridge,
>> + struct drm_bridge_state *bridge_state,
>> + struct drm_crtc_state *crtc_state,
>> + struct drm_connector_state *conn_state)
>> +{
>> + struct tfp410 *dvi = drm_bridge_to_tfp410(bridge);
>> +
>> + /*
>> + * There might be flags negotiation supported in future.
>> + * Set the bus flags in atomic_check statically for now.
>> + */
>> + bridge_state->input_bus_cfg.flags = dvi->timings.input_bus_flags;
>
> A newline here before return would look better
Yup! Will add one.
>
>> + return 0;
>> +}
>> +
>> static const struct drm_bridge_funcs tfp410_bridge_funcs = {
>> .attach = tfp410_attach,
>> .detach = tfp410_detach,
>> @@ -238,6 +253,7 @@ static const struct drm_bridge_funcs
>> tfp410_bridge_funcs = {
>> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
>> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
>> .atomic_get_input_bus_fmts = tfp410_get_input_bus_fmts,
>> + .atomic_check = tfp410_atomic_check,
>> };
>> static const struct drm_bridge_timings tfp410_default_timings = {
>
> With that fixed:
>
> Reviewed-by: Neil Armstrong
Thank you!
Regards
Aradhya
Re: [PATCH v6 3/8] drm/bridge: mhdp8546: Add minimal format negotiation
Hi Neil,
Thank you for reviewing the patch.
On 16-May-23 12:51, Neil Armstrong wrote:
> On 15/05/2023 17:59, Aradhya Bhatia wrote:
>> Hi Tomi,
>>
>> On 12-May-23 14:45, Tomi Valkeinen wrote:
>>> On 09/05/2023 12:30, Aradhya Bhatia wrote:
>>>> From: Nikhil Devshatwar
>>>>
>>>> With new connector model, mhdp bridge will not create the connector and
>>>> SoC driver will rely on format negotiation to setup the encoder format.
>>>>
>>>> Support minimal format negotiations hooks in the drm_bridge_funcs.
>>>> Complete format negotiation can be added based on EDID data.
>>>> This patch adds the minimal required support to avoid failure
>>>> after moving to new connector model.
>>>>
>>>> Signed-off-by: Nikhil Devshatwar
>>>> Reviewed-by: Tomi Valkeinen
>>>
>>> You need to add your SoB to this and the other patches.
>>
>> Okay!
>>
>>>
>>>> ---
>>>>
>>>> Notes:
>>>>
>>>> changes from v1:
>>>> * cosmetic fixes, commit message update.
>>>>
>>>> changes from v5:
>>>> * dropped the default_bus_format variable and directly assigned
>>>> MEDIA_BUS_FMT_RGB121212_1X36 to input_fmts.
>>>>
>>>> .../drm/bridge/cadence/cdns-mhdp8546-core.c | 25
>>>> +++
>>>> 1 file changed, 25 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>>>> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>>>> index f6822dfa3805..623e4235c94f 100644
>>>> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>>>> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>>>> @@ -2146,6 +2146,30 @@ cdns_mhdp_bridge_atomic_reset(struct drm_bridge
>>>> *bridge)
>>>> return _mhdp_state->base;
>>>> }
>>>> +static u32 *cdns_mhdp_get_input_bus_fmts(struct drm_bridge *bridge,
>>>> + struct drm_bridge_state *bridge_state,
>>>> + struct drm_crtc_state *crtc_state,
>>>> + struct drm_connector_state *conn_state,
>>>> + u32 output_fmt,
>>>> + unsigned int *num_input_fmts)
>>>> +{
>>>> + u32 *input_fmts;
>>>> +
>>>> + *num_input_fmts = 0;
>>>> +
>>>> + if (output_fmt != MEDIA_BUS_FMT_FIXED)
>>>> + return NULL;
>>>
>>> The tfp410 and sii902x drivers don't have the above check. Why does mhdp
>>> need it? Or the other way, why don't tfp410 and sii902x need it?
>>
>> I had removed this condition in order to follow status quo, from the
>> ITE-66121 HDMI bridge driver.
>>
>> The idea would have been to drop this for MHDP as well, but I guess I
>> overlooked this one.
>>
>> However...
>>
>>> I guess at the moment we always do get MEDIA_BUS_FMT_FIXED as the out
>>> fmt (in all three bridge drivers), don't we?
>>
>> ... I tested again to ensure that the above is indeed the case. And
>> ended up catching some odd behavior.
>>
>> It turns out that for all the HDMI bridges (TFP410, SII902X, ITE-66121),
>> the format negotiation doesn't stop at output_fmt = MEDIA_BUS_FMT_FIXED.
>> The {bridge}_get_input_format API gets called again with the output_fmt
>> = MEDIA_BUS_FMT_RGB24_1X24.
>>
>> This doesn't happen with the MHDP driver. Format negotiation with MHDP
>> bridge stops after one round, at output_fmt = MEDIA_BUS_FMT_FIXED.
>
> This is because the bridge negociation logic will test with all possible
> output formats from the chain, and won't stop at first working test.
>
Okay..
> If your bridge only supports a single input format, it should return the
> same format whatever output_fmt is tried.
>
> So indeed remove this test on mhdp aswell, or filter out invalid output
> formats.
Agreed.
I have been looking into the code deeper and trying to understand the
logic flow around the format negotiation in the framework. Here are the
2 points that I want to mention. Please let me know if I have missed
something with my understanding.
Firstly, the mhdp-8546 output connects to the display-connector (with
the compatible, "dp-connector") in the devicetree.
When the negotiation begins at 'drm_atomic_bridge_chain_select_bus_fmts'
the display-connector bridge *should* act as the 'last_brid
Re: [PATCH v6 3/8] drm/bridge: mhdp8546: Add minimal format negotiation
Hi Tomi,
On 12-May-23 14:45, Tomi Valkeinen wrote:
> On 09/05/2023 12:30, Aradhya Bhatia wrote:
>> From: Nikhil Devshatwar
>>
>> With new connector model, mhdp bridge will not create the connector and
>> SoC driver will rely on format negotiation to setup the encoder format.
>>
>> Support minimal format negotiations hooks in the drm_bridge_funcs.
>> Complete format negotiation can be added based on EDID data.
>> This patch adds the minimal required support to avoid failure
>> after moving to new connector model.
>>
>> Signed-off-by: Nikhil Devshatwar
>> Reviewed-by: Tomi Valkeinen
>
> You need to add your SoB to this and the other patches.
Okay!
>
>> ---
>>
>> Notes:
>>
>> changes from v1:
>> * cosmetic fixes, commit message update.
>>
>> changes from v5:
>> * dropped the default_bus_format variable and directly assigned
>> MEDIA_BUS_FMT_RGB121212_1X36 to input_fmts.
>>
>> .../drm/bridge/cadence/cdns-mhdp8546-core.c | 25 +++
>> 1 file changed, 25 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>> index f6822dfa3805..623e4235c94f 100644
>> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>> @@ -2146,6 +2146,30 @@ cdns_mhdp_bridge_atomic_reset(struct drm_bridge
>> *bridge)
>> return _mhdp_state->base;
>> }
>> +static u32 *cdns_mhdp_get_input_bus_fmts(struct drm_bridge *bridge,
>> + struct drm_bridge_state *bridge_state,
>> + struct drm_crtc_state *crtc_state,
>> + struct drm_connector_state *conn_state,
>> + u32 output_fmt,
>> + unsigned int *num_input_fmts)
>> +{
>> + u32 *input_fmts;
>> +
>> + *num_input_fmts = 0;
>> +
>> + if (output_fmt != MEDIA_BUS_FMT_FIXED)
>> + return NULL;
>
> The tfp410 and sii902x drivers don't have the above check. Why does mhdp
> need it? Or the other way, why don't tfp410 and sii902x need it?
I had removed this condition in order to follow status quo, from the
ITE-66121 HDMI bridge driver.
The idea would have been to drop this for MHDP as well, but I guess I
overlooked this one.
However...
> I guess at the moment we always do get MEDIA_BUS_FMT_FIXED as the out
> fmt (in all three bridge drivers), don't we?
... I tested again to ensure that the above is indeed the case. And
ended up catching some odd behavior.
It turns out that for all the HDMI bridges (TFP410, SII902X, ITE-66121),
the format negotiation doesn't stop at output_fmt = MEDIA_BUS_FMT_FIXED.
The {bridge}_get_input_format API gets called again with the output_fmt
= MEDIA_BUS_FMT_RGB24_1X24.
This doesn't happen with the MHDP driver. Format negotiation with MHDP
bridge stops after one round, at output_fmt = MEDIA_BUS_FMT_FIXED.
Regards
Aradhya
[PATCH v6 6/8] drm/bridge: sii902x: Set input_bus_flags in atomic_check
input_bus_flags are specified in drm_bridge_timings (legacy) as well
as drm_bridge_state->input_bus_cfg.flags
The flags from the timings will be deprecated. Bridges are supposed
to validate and set the bridge state flags from atomic_check.
Implement atomic_check hook for the same.
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/bridge/sii902x.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 662b6cb4aa62..4d1f10532fa6 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -495,6 +495,20 @@ static u32
*sii902x_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
return input_fmts;
}
+static int sii902x_bridge_atomic_check(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+ /*
+* There might be flags negotiation supported in future but
+* set the bus flags in atomic_check statically for now.
+*/
+ bridge_state->input_bus_cfg.flags = bridge->timings->input_bus_flags;
+
+ return 0;
+}
+
static const struct drm_bridge_funcs sii902x_bridge_funcs = {
.attach = sii902x_bridge_attach,
.mode_set = sii902x_bridge_mode_set,
@@ -506,6 +520,7 @@ static const struct drm_bridge_funcs sii902x_bridge_funcs =
{
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_get_input_bus_fmts = sii902x_bridge_atomic_get_input_bus_fmts,
+ .atomic_check = sii902x_bridge_atomic_check,
};
static int sii902x_mute(struct sii902x *sii902x, bool mute)
--
2.40.1
[PATCH v6 1/8] drm/bridge: tfp410: Support format negotiation hooks
From: Nikhil Devshatwar
With new connector model, tfp410 will not create the connector and
SoC driver will rely on format negotiation to setup the encoder format.
Support format negotiations hooks in the drm_bridge_funcs.
Use helper functions for state management.
Input format is the one selected by the bridge from DT properties.
Signed-off-by: Nikhil Devshatwar
[a-bhatia1: Removed output fmt condition check]
Signed-off-by: Aradhya Bhatia
---
Notes:
changes from v1:
* Use only MEDIA_BUS_FMT_FIXED for output
changes from V5:
* Dropped the output format check condition because the output
format for HDMI bridges should be RGB888_1X24 and not FIXED.
Hence, also dropped Tomi Valkeinen's and Laurent Pinchart's
R-b tags.
drivers/gpu/drm/bridge/ti-tfp410.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index ab63225cd635..7dacc7e03eee 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -206,12 +206,38 @@ static enum drm_mode_status tfp410_mode_valid(struct
drm_bridge *bridge,
return MODE_OK;
}
+static u32 *tfp410_get_input_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state,
+ u32 output_fmt,
+ unsigned int *num_input_fmts)
+{
+ struct tfp410 *dvi = drm_bridge_to_tfp410(bridge);
+ u32 *input_fmts;
+
+ *num_input_fmts = 0;
+
+ input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+
+ *num_input_fmts = 1;
+ input_fmts[0] = dvi->bus_format;
+
+ return input_fmts;
+}
+
static const struct drm_bridge_funcs tfp410_bridge_funcs = {
.attach = tfp410_attach,
.detach = tfp410_detach,
.enable = tfp410_enable,
.disable= tfp410_disable,
.mode_valid = tfp410_mode_valid,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_get_input_bus_fmts = tfp410_get_input_bus_fmts,
};
static const struct drm_bridge_timings tfp410_default_timings = {
--
2.40.1
[PATCH v6 4/8] drm/bridge: mhdp8546: Set input_bus_flags from atomic_check
From: Nikhil Devshatwar
input_bus_flags are specified in drm_bridge_timings (legacy) as well
as drm_bridge_state->input_bus_cfg.flags
The flags from the timings will be deprecated. Bridges are supposed
to validate and set the bridge state flags from atomic_check.
Signed-off-by: Nikhil Devshatwar
[a-bhatia1: replace timings in cdns_mhdp_platform_info by input_bus_flags]
Signed-off-by: Aradhya Bhatia
---
Notes:
changes from v5:
* removed the wrongly addded return statement in tfp410 driver.
* replaced the timings field in cdns_mhdp_platform_info by
input_bus_flags field, in order to get rid of bridge->timings
altogether.
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h | 2 +-
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c | 9 -
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.h | 2 +-
4 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index 623e4235c94f..a677b1267525 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -2189,6 +2189,13 @@ static int cdns_mhdp_atomic_check(struct drm_bridge
*bridge,
return -EINVAL;
}
+ /*
+* There might be flags negotiation supported in future.
+* Set the bus flags in atomic_check statically for now.
+*/
+ if (mhdp->info)
+ bridge_state->input_bus_cfg.flags =
*mhdp->info->input_bus_flags;
+
mutex_unlock(>link_mutex);
return 0;
}
@@ -2554,8 +2561,6 @@ static int cdns_mhdp_probe(struct platform_device *pdev)
mhdp->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID |
DRM_BRIDGE_OP_HPD;
mhdp->bridge.type = DRM_MODE_CONNECTOR_DisplayPort;
- if (mhdp->info)
- mhdp->bridge.timings = mhdp->info->timings;
ret = phy_init(mhdp->phy);
if (ret) {
@@ -2642,7 +2647,7 @@ static const struct of_device_id mhdp_ids[] = {
#ifdef CONFIG_DRM_CDNS_MHDP8546_J721E
{ .compatible = "ti,j721e-mhdp8546",
.data = &(const struct cdns_mhdp_platform_info) {
- .timings = _ti_j721e_bridge_timings,
+ .input_bus_flags = _ti_j721e_bridge_input_bus_flags,
.ops = _ti_j721e_ops,
},
},
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
index be510d17..bad2fc0c7306 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
@@ -336,7 +336,7 @@ struct cdns_mhdp_bridge_state {
};
struct cdns_mhdp_platform_info {
- const struct drm_bridge_timings *timings;
+ const u32 *input_bus_flags;
const struct mhdp_platform_ops *ops;
};
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
index dfe1b59514f7..12d04be4e242 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
@@ -71,8 +71,7 @@ const struct mhdp_platform_ops mhdp_ti_j721e_ops = {
.disable = cdns_mhdp_j721e_disable,
};
-const struct drm_bridge_timings mhdp_ti_j721e_bridge_timings = {
- .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
- DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE |
- DRM_BUS_FLAG_DE_HIGH,
-};
+const u32
+mhdp_ti_j721e_bridge_input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
+ DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE |
+ DRM_BUS_FLAG_DE_HIGH;
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.h
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.h
index 97d20d115a24..5ddca07a4255 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.h
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.h
@@ -14,6 +14,6 @@
struct mhdp_platform_ops;
extern const struct mhdp_platform_ops mhdp_ti_j721e_ops;
-extern const struct drm_bridge_timings mhdp_ti_j721e_bridge_timings;
+extern const u32 mhdp_ti_j721e_bridge_input_bus_flags;
#endif /* !CDNS_MHDP8546_J721E_H */
--
2.40.1
[PATCH v6 8/8] drm/bridge: cdns-mhdp8546: Fix the interrupt enable/disable
From: Nikhil Devshatwar
When removing the tidss driver, there is a warning reported by
kernel about an unhandled interrupt for mhdp driver.
[ 43.238895] irq 31: nobody cared (try booting with the "irqpoll" option)
... [snipped backtrace]
[ 43.330735] handlers:
[ 43.333020] [<5367c4f9>] irq_default_primary_handler threaded
[<7e02b601>]
cdns_mhdp_irq_handler [cdns_mhdp8546]
[ 43.344607] Disabling IRQ #31
This happens because as part of cdns_mhdp_bridge_hpd_disable, driver tries
to disable the interrupts. While disabling the SW_EVENT interrupts,
it accidentally enables the MBOX interrupts, which are not handled by
the driver.
Fix this with a read-modify-write to update only required bits.
Use the enable / disable function as required in other places.
Signed-off-by: Nikhil Devshatwar
Reviewed-by: Swapnil Jakhade
Reviewed-by: Tomi Valkeinen
---
Notes:
changes from v2:
* Fix the interrupt enable logic at other places in code
* Reorder functions so that they can be used earlier in the program
changes from v5:
* Manual rebase to linux-next.
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 44 +--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index a677b1267525..66a771b140bc 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -54,6 +54,26 @@
#include "cdns-mhdp8546-hdcp.h"
#include "cdns-mhdp8546-j721e.h"
+static void cdns_mhdp_bridge_hpd_enable(struct drm_bridge *bridge)
+{
+ struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
+
+ /* Enable SW event interrupts */
+ if (mhdp->bridge_attached)
+ writel(readl(mhdp->regs + CDNS_APB_INT_MASK) &
+ ~CDNS_APB_INT_MASK_SW_EVENT_INT,
+ mhdp->regs + CDNS_APB_INT_MASK);
+}
+
+static void cdns_mhdp_bridge_hpd_disable(struct drm_bridge *bridge)
+{
+ struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
+
+ writel(readl(mhdp->regs + CDNS_APB_INT_MASK) |
+ CDNS_APB_INT_MASK_SW_EVENT_INT,
+ mhdp->regs + CDNS_APB_INT_MASK);
+}
+
static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
{
int ret, empty;
@@ -749,9 +769,7 @@ static int cdns_mhdp_fw_activate(const struct firmware *fw,
* MHDP_HW_STOPPED happens only due to driver removal when
* bridge should already be detached.
*/
- if (mhdp->bridge_attached)
- writel(~(u32)CDNS_APB_INT_MASK_SW_EVENT_INT,
- mhdp->regs + CDNS_APB_INT_MASK);
+ cdns_mhdp_bridge_hpd_enable(>bridge);
spin_unlock(>start_lock);
@@ -1740,8 +1758,7 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
/* Enable SW event interrupts */
if (hw_ready)
- writel(~(u32)CDNS_APB_INT_MASK_SW_EVENT_INT,
- mhdp->regs + CDNS_APB_INT_MASK);
+ cdns_mhdp_bridge_hpd_enable(bridge);
return 0;
aux_unregister:
@@ -2215,23 +2232,6 @@ static struct edid *cdns_mhdp_bridge_get_edid(struct
drm_bridge *bridge,
return cdns_mhdp_get_edid(mhdp, connector);
}
-static void cdns_mhdp_bridge_hpd_enable(struct drm_bridge *bridge)
-{
- struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
-
- /* Enable SW event interrupts */
- if (mhdp->bridge_attached)
- writel(~(u32)CDNS_APB_INT_MASK_SW_EVENT_INT,
- mhdp->regs + CDNS_APB_INT_MASK);
-}
-
-static void cdns_mhdp_bridge_hpd_disable(struct drm_bridge *bridge)
-{
- struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
-
- writel(CDNS_APB_INT_MASK_SW_EVENT_INT, mhdp->regs + CDNS_APB_INT_MASK);
-}
-
static const struct drm_bridge_funcs cdns_mhdp_bridge_funcs = {
.atomic_enable = cdns_mhdp_atomic_enable,
.atomic_disable = cdns_mhdp_atomic_disable,
--
2.40.1
