From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2DF8E291C10 for ; Thu, 9 Jul 2026 13:29:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783603789; cv=none; b=Lmoo0+Fr/FMEmgFlHdby/me6ecyQVvd44TPcpuJfICGPzpYbwyRYVtVxv/iF1YsbbCeJl65DkoVM2nHLbAkgAcQMTHEbm6dDSU8IytWcuxC6OeWSyv8JWVU/Rpe1eJHwz52TLyuU4cPHRGcr+s83NC3dssU3GZPJ1J8Dh8Wn5DQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783603789; c=relaxed/simple; bh=87lVA9V8V2lXzJG4XdXjKeodniJQa1uBXNGQb9jGZJM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fuqJEk2WEh9+eqir43UEzZXXB+B+Pk79nevhHoVlQ/lyWnncHvew2KcnuVLu5pF76eAYZRLv+lw6+79FtNnwzUuaVZQKvtN/77Y8aDIb90jN9Hre2vuGMmbi7YF1/yjWePuHrnllCNqHH4VWHUj26KVhtgsmS0mlkLLwdhC+dAo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=G+U7IBey; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="G+U7IBey" Received: from killaraus.ideasonboard.com (2001-14ba-70f3-e800--a06.rev.dnainternet.fi [IPv6:2001:14ba:70f3:e800::a06]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id C80344DC; Thu, 9 Jul 2026 15:28:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1783603736; bh=87lVA9V8V2lXzJG4XdXjKeodniJQa1uBXNGQb9jGZJM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=G+U7IBeynh0jeseXC7sX0Cab66rDpSjpSrjkesARwkWMCrBPYOGD+oFO5I8cXKNpH KWSqUmd2i/lYa4QRQnOiTE/SnPCn/5LcrMgIbxY7K6IiptWQa2Ou9JOjg0CdgkbYH9 21B7ZZrgAFBUm1dhVLnI8VRuQct4TZsvOPpQnS0E= Date: Thu, 9 Jul 2026 16:29:44 +0300 From: Laurent Pinchart To: Wojciech Dubowik Cc: linux-kernel@vger.kernel.org, Andrzej Hajda , Neil Armstrong , Robert Foss , Jonas Karlman , Jernej Skrabec , Luca Ceresoli , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org Subject: Re: [PATCH v2] drm/bridge: ti-sn65dsi83: Add reversed lvds lanes support Message-ID: <20260709132944.GB1007225@killaraus.ideasonboard.com> References: <20260709125810.340612-1-wojciech.dubowik@mt.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260709125810.340612-1-wojciech.dubowik@mt.com> On Thu, Jul 09, 2026 at 02:58:09PM +0200, Wojciech Dubowik wrote: > From: Wojciech Dubowik > > The chip supports output lvds lanes in two orders, default <1 2 3 4> > and <4 3 2 1>. Add parsing of an optional output lvds data-lanes > property so we can inform chip that the lanes have been reversed. > > Signed-off-by: Wojciech Dubowik > --- > Changes in v2: > - Parse existing data-lanes property instead of ading new DT > bindings You still need to update the bindings to relax the ordering requirement of the data-lanes property. Does the device support less than 4 data lanes ? If not, the bindings will also need to be updated to reflect that. > --- > drivers/gpu/drm/bridge/ti-sn65dsi83.c | 50 +++++++++++++++++++++++++++ > 1 file changed, 50 insertions(+) > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c > index 42b451432bbb..4945d4c960c4 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c > @@ -148,6 +148,18 @@ enum sn65dsi83_lvds_term { > OHM_200 > }; > > +enum { > + NORMAL_LANE_MAPPING, > + REVERSE_LANE_MAPPING, > +}; > + > +#define DATA_LANES_COUNT 4 > + > +static const int supported_data_lane_mapping[][DATA_LANES_COUNT] = { > + [NORMAL_LANE_MAPPING] = { 1, 2, 3, 4 }, > + [REVERSE_LANE_MAPPING] = { 4, 3, 2, 1}, > +}; > + > enum sn65dsi83_model { > MODEL_SN65DSI83, > MODEL_SN65DSI84, > @@ -163,6 +175,7 @@ struct sn65dsi83 { > struct regulator *vcc; > bool lvds_dual_link; > bool lvds_dual_link_even_odd_swap; > + bool lvds_reverse_lanes_conf[2]; > int lvds_vod_swing_conf[2]; > int lvds_term_conf[2]; > int irq; > @@ -644,6 +657,10 @@ static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge, > regmap_write(ctx->regmap, REG_LVDS_LANE, > (ctx->lvds_dual_link_even_odd_swap ? > REG_LVDS_LANE_EVEN_ODD_SWAP : 0) | > + (ctx->lvds_reverse_lanes_conf[CHANNEL_A] ? > + REG_LVDS_LANE_CHA_REVERSE_LVDS : 0) | > + (ctx->lvds_reverse_lanes_conf[CHANNEL_B] ? > + REG_LVDS_LANE_CHB_REVERSE_LVDS : 0) | > (ctx->lvds_term_conf[CHANNEL_A] ? > REG_LVDS_LANE_CHA_LVDS_TERM : 0) | > (ctx->lvds_term_conf[CHANNEL_B] ? > @@ -832,10 +849,12 @@ static int sn65dsi83_parse_lvds_endpoint(struct sn65dsi83 *ctx, int channel) > u32 lvds_vod_swing_clk[2] = { 0, 1000000 }; > /* Set default near end terminataion to 200 Ohm */ > u32 lvds_term = 200; > + u32 data_lanes[DATA_LANES_COUNT]; > int lvds_vod_swing_conf; > int ret = 0; > int ret_data; > int ret_clock; > + int i, j; > > if (channel == CHANNEL_A) > endpoint_reg = 2; > @@ -854,6 +873,37 @@ static int sn65dsi83_parse_lvds_endpoint(struct sn65dsi83 *ctx, int channel) > goto exit; > } > > + ret_data = of_property_read_u32_array(endpoint, "data-lanes", data_lanes, > + ARRAY_SIZE(data_lanes)); > + if (ret_data != 0 && ret_data != -EINVAL) { > + ret = ret_data; > + goto exit; > + } > + > + if (!ret_data) { I wish we could drop this check, but as the data-lanes property is not documented as mandatory, I suppose not all device trees use it :-( Could you, while at it, make the property mandatory in the bindings, to ensure it gets specified in all future device trees (and fix in-tree offenders, if any) ? > + for (i = 0; i < ARRAY_SIZE(supported_data_lane_mapping); i++) { > + for (j = 0; j < DATA_LANES_COUNT; j++) { > + if (data_lanes[j] != supported_data_lane_mapping[i][j]) > + break; > + } > + > + if (j == DATA_LANES_COUNT) > + break; > + } > + > + switch (i) { > + case NORMAL_LANE_MAPPING: > + break; > + case REVERSE_LANE_MAPPING: > + ctx->lvds_reverse_lanes_conf[channel] = true; > + break; > + default: > + dev_err(dev, "invalid data lanes mapping\n"); > + ret = -EINVAL; > + goto exit; > + } > + } > + > ret_data = of_property_read_u32_array(endpoint, "ti,lvds-vod-swing-data-microvolt", > lvds_vod_swing_data, ARRAY_SIZE(lvds_vod_swing_data)); > if (ret_data != 0 && ret_data != -EINVAL) { -- Regards, Laurent Pinchart