dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Lucas Stach <l.stach@pengutronix.de>, dri-devel@lists.freedesktop.org
Cc: Jonas Karlman <jonas@kwiboo.se>, Sam Ravnborg <sam@ravnborg.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Maxime Ripard <maxime@cerno.tech>,
	Neil Armstrong <narmstrong@baylibre.com>
Subject: Re: [PATCH V2 11/11] drm/bridge: tc358767: Add DSI-to-DPI mode support
Date: Sat, 19 Feb 2022 05:44:38 +0100	[thread overview]
Message-ID: <f84dea89-fb4e-9e25-a020-b5e4f3cb82eb@denx.de> (raw)
In-Reply-To: <7d92962a433843af249a5adcc145dc4aecc66015.camel@pengutronix.de>

On 2/18/22 19:38, Lucas Stach wrote:

[...]

>> @@ -502,8 +548,10 @@ static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk, u32 pixelclock)
>>   				/*
>>   				 * refclk * mul / (ext_pre_div * pre_div)
>>   				 * should be in the 150 to 650 MHz range
>> +				 * for (e)DP
>>   				 */
>> -				if ((clk > 650000000) || (clk < 150000000))
>> +				if ((tc->bridge.type != DRM_MODE_CONNECTOR_DPI) &&
>> +				    ((clk > 650000000) || (clk < 150000000)))
>>   					continue;
> 
> Is there any indication what the bounds are for DPI mode? Can we
> replace this with a better check, instead of just disabling it?

Apparently the DPI pixel PLL output is limited to 100 MHz, so yes, this 
can be improved.

[...]

>> +static int tc_dpi_stream_enable(struct tc_data *tc)
>> +{
>> +	int ret;
>> +	u32 value;
>> +
>> +	dev_dbg(tc->dev, "enable video stream\n");
>> +
>> +	/* Setup PLL */
>> +	ret = tc_set_syspllparam(tc);
>> +	if (ret)
>> +		return ret;
>> +
>> +	/* Pixel PLL must always be enabled for DPI mode */
>> +	ret = tc_pxl_pll_en(tc, clk_get_rate(tc->refclk),
>> +			    1000 * tc->mode.clock);
>> +	if (ret)
>> +		return ret;
>> +
>> +	regmap_write(tc->regmap, PPI_D0S_CLRSIPOCOUNT, 3);
>> +	regmap_write(tc->regmap, PPI_D1S_CLRSIPOCOUNT, 3);
>> +	regmap_write(tc->regmap, PPI_D2S_CLRSIPOCOUNT, 3);
>> +	regmap_write(tc->regmap, PPI_D3S_CLRSIPOCOUNT, 3);
> 
> Hm, those hardcoded always seem kind of fishy, as AFAIK those
> parameters are dependent on land frequency and some other things. But
> I'm also not sure if we have all the information available to
> dynamically calculate them.

We have multiple copies of the same ^ code in other TC358nnn drivers 
too, it seems like some de-duplication could be done too. I have this 
feeling the Toshiba bridges are all glued together from two (or more) 
halves and there is large potential for de-duplication in all those TC 
drivers. But does anyone really have all the chips to test, except for 
Toshiba ?

>> +	regmap_write(tc->regmap, PPI_D0S_ATMR, 0);
>> +	regmap_write(tc->regmap, PPI_D1S_ATMR, 0);
>> +	regmap_write(tc->regmap, PPI_TX_RX_TA, TTA_GET | TTA_SURE);
>> +	regmap_write(tc->regmap, PPI_LPTXTIMECNT, LPX_PERIOD);
>> +
>> +	value = ((LANEENABLE_L0EN << tc->dsi_lanes) - LANEENABLE_L0EN) |
>> +		LANEENABLE_CLEN;
>> +	regmap_write(tc->regmap, PPI_LANEENABLE, value);
>> +	regmap_write(tc->regmap, DSI_LANEENABLE, value);
>> +
>> +	ret = tc_set_common_video_mode(tc, &tc->mode);
>> +	if (ret)
>> +		return ret;
>> +
>> +	ret = tc_set_dpi_video_mode(tc, &tc->mode);
>> +	if (ret)
>> +		return ret;
>> +
>> +	/* Set input interface */
>> +	value = DP0_AUDSRC_NO_INPUT;
>> +	if (tc_test_pattern)
>> +		value |= DP0_VIDSRC_COLOR_BAR;
>> +	else
>> +		value |= DP0_VIDSRC_DSI_RX;
>> +	ret = regmap_write(tc->regmap, SYSCTRL, value);
>> +	if (ret)
>> +		return ret;
>> +
>> +	msleep(100);
> 
> What is that used for? PLL stabilization? Some other purpose?

Yes, except that should've been microseconds ... fixed

[...]

>> +static int tc_mipi_dsi_host_attach(struct tc_data *tc)
>> +{
>> +	struct device *dev = tc->dev;
>> +	struct device_node *host_node;
>> +	struct device_node *endpoint;
>> +	struct mipi_dsi_device *dsi;
>> +	struct mipi_dsi_host *host;
>> +	const struct mipi_dsi_device_info info = {
>> +		.type = "tc358767",
>> +		.channel = 0,
>> +		.node = NULL,
>> +	};
>> +	int ret;
>> +
>> +	endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, 0);
>> +	tc->dsi_lanes = of_property_count_u32_elems(endpoint, "data-lanes");
> 
> The data-lanes property isn't documented in the DT binding. Please add.

Fixed in a separate patch.

[...]

>> @@ -1828,15 +2145,23 @@ static int tc_probe(struct i2c_client *client, const struct i2c_device_id *id)
>>   		tc->have_irq = true;
>>   	}
>>   
>> -	ret = tc_aux_link_setup(tc);
>> -	if (ret)
>> -		return ret;
>> +	if (tc->bridge.type != DRM_MODE_CONNECTOR_DPI) { /* (e)DP output */
>> +		ret = tc_aux_link_setup(tc);
>> +		if (ret)
>> +			return ret;
>> +	}
>>   
>>   	tc->bridge.of_node = dev->of_node;
>>   	drm_bridge_add(&tc->bridge);
>>   
>>   	i2c_set_clientdata(client, tc);
>>   
>> +	if (tc->bridge.type == DRM_MODE_CONNECTOR_DPI) { /* DPI output */
>> +		ret = tc_mipi_dsi_host_attach(tc);
>> +		if (ret)
>> +			return ret;
>> +	}
> 
> If tc_mipi_dsi_host_attach fails the drm bridge registered a few lines
> above isn't cleaned up properly.

Fixed

  reply	other threads:[~2022-02-19  4:44 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-18  1:00 [PATCH V2 00/11] drm/bridge: tc358767: Add DSI-to-DPI mode support Marek Vasut
2022-02-18  1:00 ` [PATCH V2 01/11] dt-bindings: display: bridge: tc358867: Document DPI output support Marek Vasut
2022-02-18  1:00 ` [PATCH V2 02/11] drm/bridge: tc358767: Change tc_ prefix to tc_edp_ for (e)DP specific functions Marek Vasut
2022-02-18 17:24   ` Lucas Stach
2022-02-18  1:00 ` [PATCH V2 03/11] drm/bridge: tc358767: Convert to atomic ops Marek Vasut
2022-02-18 17:27   ` Lucas Stach
2022-02-18  1:00 ` [PATCH V2 04/11] drm/bridge: tc358767: Implement atomic_check callback Marek Vasut
2022-02-18 17:34   ` Lucas Stach
2022-02-19  2:26     ` Marek Vasut
2022-02-21  9:01       ` Maxime Ripard
2022-02-24 19:03         ` Marek Vasut
2022-02-18  1:00 ` [PATCH V2 05/11] drm/bridge: tc358767: Move hardware init to enable callback Marek Vasut
2022-02-18 17:49   ` Lucas Stach
2022-02-19  2:39     ` Marek Vasut
2022-02-21  9:12       ` Lucas Stach
2022-02-24 19:13         ` Marek Vasut
2022-02-18  1:00 ` [PATCH V2 06/11] drm/bridge: tc358767: Move (e)DP bridge endpoint parsing into dedicated function Marek Vasut
2022-02-18 17:51   ` Lucas Stach
2022-02-18  1:00 ` [PATCH V2 07/11] drm/bridge: tc358767: Wrap (e)DP aux I2C registration into tc_aux_link_setup() Marek Vasut
2022-02-18 17:57   ` Lucas Stach
2022-02-18  1:00 ` [PATCH V2 08/11] drm/bridge: tc358767: Move bridge ops setup into tc_probe_edp_bridge_endpoint() Marek Vasut
2022-02-18 18:01   ` Lucas Stach
2022-02-18  1:00 ` [PATCH V2 09/11] drm/bridge: tc358767: Detect bridge mode from connected endpoints in DT Marek Vasut
2022-02-18 18:04   ` Lucas Stach
2022-02-18  1:00 ` [PATCH V2 10/11] drm/bridge: tc358767: Split tc_set_video_mode() into common and (e)DP part Marek Vasut
2022-02-18 18:13   ` Lucas Stach
2022-02-18  1:00 ` [PATCH V2 11/11] drm/bridge: tc358767: Add DSI-to-DPI mode support Marek Vasut
2022-02-18 18:38   ` Lucas Stach
2022-02-19  4:44     ` Marek Vasut [this message]
2022-02-22 17:49     ` Lucas Stach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f84dea89-fb4e-9e25-a020-b5e4f3cb82eb@denx.de \
    --to=marex@denx.de \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jonas@kwiboo.se \
    --cc=l.stach@pengutronix.de \
    --cc=maxime@cerno.tech \
    --cc=narmstrong@baylibre.com \
    --cc=sam@ravnborg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox