From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C30332E0412 for ; Sat, 17 Jan 2026 21:38:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768685905; cv=none; b=ZD/G0D0F0gqeHxFmA8Dn6bMQ/eqPbJO6kpKhOWmufyhuh5YdNWP2gEEancN+A5eejdysII+i1pnWhjTLUjrSXviUAa+NFZcvHcCkQbpDTzX+W/4cbSVU6a/ERKbZmN0uZIMuRtSOWcHwufBgCckfIl6VR5iyLpzIgeH8lW/E57M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768685905; c=relaxed/simple; bh=r75LXAxamOFiLJ7w1C7qUg+8O4qE9Zd/yue01h8JojA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=PDv8LnAwbL2m1yDF2ia11qyWwDvPB4KjZ1Ug3TUU/nwbyW9hS8SPvvuMEuePcbkZbBIUYv4vZwK2sUxSEddproY9I8vYnMU+aj7O1hXMhMVIJIlV2gJkYFkwexEuaOSzRL+1feiNVRdiRAjkdmEHsYbe3PQyX2XzZLFSKmei8j8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=UCpcSigS; arc=none smtp.client-ip=209.85.221.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="UCpcSigS" Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-432d2670932so2533855f8f.2 for ; Sat, 17 Jan 2026 13:38:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1768685901; x=1769290701; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=zOSrfCVt3slZZjtnDEf8LgA1EjmVMXj7ymK/XhVHifo=; b=UCpcSigSuj8AFXc4bBjc46Tc2LcqCDN/SdfDTYw6RdYFmloOmWjvHyyb8n4YRgIwwq mZsEEPc++KJkH9k6U1Tn3pn1HRF1S0Rc6hgdm8knoPO2jiucnhSxR/H8Nl0yFaV3ay7X BMUR/R26w52I1QK4mBjfJqoKPC54RpoFJFnQy6kDe+gPVjsbv92nJwdDsHP7Nadf5C5r kPCYHIJFOygVD1ZbYUPwdwuBxd0k0jrTp7ukDZFrL/29BaHuSMl52ekgWftTFoX4bRcw y7zIhNfTSYnzI6HHkNOvNFbRP1gdFtedFqEJ42PB/febRz++83+77xi9vcl80me/bojp KRzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768685901; x=1769290701; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zOSrfCVt3slZZjtnDEf8LgA1EjmVMXj7ymK/XhVHifo=; b=DxAC51kaAygL3zauR/067m6e0kwU0me8k+HJxYNGGxatocNeJPLNzrC6DNNoQ4xTaK hPvkzVUX3X6YPr3KVZ7KAyhgDK2LX9nAwUgiDJzH2AQKeCnH1EkNQk5fq9SCvw03UPPh gZkGkaZqto2F3wbiD4bxYshvzUUaiJ03iu5LxHTP1mffIxvWos/YSZRLbiOGPqb6cY/A xpWQv85h8kXcvQX3ELKSYXKEnNrYWPw73Ix2MYOOYP1nbIf5Ak0zaIb8Ghzpzz6mJS3d 63SVHfe8qAK10v07AyZ1KqIRzvm5PpmxY9dF20iVW8NLu6nYBU7pTUFMPMcv8e2oaRmt vx/g== X-Forwarded-Encrypted: i=1; AJvYcCVbegSgD/dcYNKFRedeaijA74cGSQ5ICc4f8apWXAj5I0+6HCGLfRr11canM0Ap/PyD7xnz01DwdpWaulE=@vger.kernel.org X-Gm-Message-State: AOJu0YwYcnumIr9pkqRgxzdV+ePNe1BKM0O3a1JXvJzI3cE9un5ENCxj YWwjOafZhIgD0ZKHgru6EGmBoGj7AE9BlrUFhnYFtxOrJuMEi3xRxW8h0oREakxnSjQ= X-Gm-Gg: AY/fxX5M84IqIiTUOAqCTs4j3cYQemJ1jxMAk5bq6kYV/OiTv0fFKZYzKdeOa+CAzch DcL7sf0CBe6O6ET6QSWfVwhtdm7IQS04J2SAbhfOmW9LlutTyp6/+v/r/4rJ9w7hajQyx1vj9fQ vLQQddm6IYaEIEePugPUY9paIVMAcpCvylwU15cZA2CfvmelWTbHun42hNMce2EQUhphWT6vg78 BU0hNuPtpxcQFvD0CIEnuZcP5qfobmmuLYneUOZu0Kc0/yHOb7SkFVpqBnGB6U0hza0O/fyy4Q5 2j+eqsyOfR+QPFmbZvkpNwdS1ZlukNdpVjtDSVnhAzmDCyd7BvjFhS6RftvtE+abicURtIL1Wn0 pA4S3AzwVRDVo1335Zv9VEc9UgGQ65+ovfXVLeqzZ5jtJmK15Nk8AHXuDT3AezKvUVmhFWueyzr vvppvZC4lXUVGCJ1SunffgvVTSp34e37SrNCDIGY+rkPSUPorsUwsl X-Received: by 2002:a05:6000:240e:b0:433:1d30:461 with SMTP id ffacd0b85a97d-43569bc4837mr8556092f8f.32.1768685901066; Sat, 17 Jan 2026 13:38:21 -0800 (PST) Received: from [192.168.0.40] (188-141-3-146.dynamic.upc.ie. [188.141.3.146]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569998240sm12791161f8f.43.2026.01.17.13.38.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 17 Jan 2026 13:38:20 -0800 (PST) Message-ID: Date: Sat, 17 Jan 2026 21:38:17 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/8] media: qcom: camss: csiphy-3ph: Use odd bits for configuring C-PHY lanes To: david@ixit.cz, Robert Foss , Todor Tomov , Vladimir Zapolskiy , Mauro Carvalho Chehab , Luca Weiss , Petr Hodina , Casey Connolly , "Dr. Git" Cc: Konrad Dybcio , Joel Selvaraj , Kieran Bingham , Sakari Ailus , linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, phone-devel@vger.kernel.org References: <20260117-qcom-cphy-v3-0-8ce76a06f7db@ixit.cz> <20260117-qcom-cphy-v3-2-8ce76a06f7db@ixit.cz> From: Bryan O'Donoghue Content-Language: en-US In-Reply-To: <20260117-qcom-cphy-v3-2-8ce76a06f7db@ixit.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 17/01/2026 15:36, David Heidelberg via B4 Relay wrote: > From: David Heidelberg > > So far, only D-PHY mode was supported, which uses even bits when enabling > or masking lanes. For C-PHY configuration, the hardware instead requires > using the odd bits. > > Since there can be unrecognized configuration allow returning failure. > > Signed-off-by: David Heidelberg > --- > .../platform/qcom/camss/camss-csiphy-2ph-1-0.c | 8 ++-- > .../platform/qcom/camss/camss-csiphy-3ph-1-0.c | 49 +++++++++++++++++----- > drivers/media/platform/qcom/camss/camss-csiphy.c | 4 +- > drivers/media/platform/qcom/camss/camss-csiphy.h | 6 +-- > 4 files changed, 47 insertions(+), 20 deletions(-) > > diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c > index 9d67e7fa6366a..bb4b91f69616b 100644 > --- a/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c > +++ b/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c > @@ -94,9 +94,9 @@ static u8 csiphy_settle_cnt_calc(s64 link_freq, u32 timer_clk_rate) > return settle_cnt; > } > > -static void csiphy_lanes_enable(struct csiphy_device *csiphy, > - struct csiphy_config *cfg, > - s64 link_freq, u8 lane_mask) > +static int csiphy_lanes_enable(struct csiphy_device *csiphy, > + struct csiphy_config *cfg, > + s64 link_freq, u8 lane_mask) > { > struct csiphy_lanes_cfg *c = &cfg->csi2->lane_cfg; > u8 settle_cnt; > @@ -132,6 +132,8 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy, > writel_relaxed(0x3f, csiphy->base + > CAMSS_CSI_PHY_INTERRUPT_CLEARn(l)); > } > + > + return 0; > } > > static void csiphy_lanes_disable(struct csiphy_device *csiphy, > diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c > index 4154832745525..f3a8625511e1e 100644 > --- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c > +++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include > > #define CSIPHY_3PH_LNn_CFG1(n) (0x000 + 0x100 * (n)) > #define CSIPHY_3PH_LNn_CFG1_SWI_REC_DLY_PRG (BIT(7) | BIT(6)) > @@ -993,13 +994,22 @@ static void csiphy_gen2_config_lanes(struct csiphy_device *csiphy, > > static u8 csiphy_get_lane_mask(struct csiphy_lanes_cfg *lane_cfg) > { > - u8 lane_mask; > - int i; > + u8 lane_mask = 0; > > - lane_mask = CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE; > + switch (lane_cfg->phy_cfg) { > + case V4L2_MBUS_CSI2_CPHY: > + for (int i = 0; i < lane_cfg->num_data; i++) > + lane_mask |= (1 << lane_cfg->data[i].pos) + 1; 1 << anything == BIT(anything) I've always disliked the look of this code and now it occurs to me why. This code is analogous to: lane_mask |= BIT(lane_cfg->data[i].pos) + 1); but BIT() is less janky and more upstreamy. janky/upstreamy - this is the on-point technical argument y'all came here for :) > + break; > + case V4L2_MBUS_CSI2_DPHY: > + lane_mask = CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE; > > - for (i = 0; i < lane_cfg->num_data; i++) > - lane_mask |= 1 << lane_cfg->data[i].pos; > + for (int i = 0; i < lane_cfg->num_data; i++) > + lane_mask |= 1 << lane_cfg->data[i].pos; > + break; > + default: > + break; > + } > > return lane_mask; > } > @@ -1027,10 +1037,11 @@ static bool csiphy_is_gen2(u32 version) > return ret; > } > > -static void csiphy_lanes_enable(struct csiphy_device *csiphy, > - struct csiphy_config *cfg, > - s64 link_freq, u8 lane_mask) > +static int csiphy_lanes_enable(struct csiphy_device *csiphy, > + struct csiphy_config *cfg, > + s64 link_freq, u8 lane_mask) > { > + struct device *dev = csiphy->camss->dev; > struct csiphy_lanes_cfg *c = &cfg->csi2->lane_cfg; > struct csiphy_device_regs *regs = csiphy->regs; > u8 settle_cnt; > @@ -1039,9 +1050,23 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy, > > settle_cnt = csiphy_settle_cnt_calc(link_freq, csiphy->timer_clk_rate); > > - val = CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE; > - for (i = 0; i < c->num_data; i++) > - val |= BIT(c->data[i].pos * 2); > + val = 0; > + > + switch (c->phy_cfg) { > + case V4L2_MBUS_CSI2_CPHY: > + for (i = 0; i < c->num_data; i++) > + val |= BIT((c->data[i].pos * 2) + 1); > + break; > + case V4L2_MBUS_CSI2_DPHY: > + val = CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE; > + > + for (i = 0; i < c->num_data; i++) > + val |= BIT(c->data[i].pos * 2); > + break; > + default: > + dev_err(dev, "Unsupported bus type %d\n", c->phy_cfg); > + return -EINVAL; > + } > > writel_relaxed(val, csiphy->base + > CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 5)); > @@ -1068,6 +1093,8 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy, > writel_relaxed(0, csiphy->base + > CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, i)); > } > + > + return 0; > } > > static void csiphy_lanes_disable(struct csiphy_device *csiphy, > diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c b/drivers/media/platform/qcom/camss/camss-csiphy.c > index 62623393f4144..08dd238e52799 100644 > --- a/drivers/media/platform/qcom/camss/camss-csiphy.c > +++ b/drivers/media/platform/qcom/camss/camss-csiphy.c > @@ -295,9 +295,7 @@ static int csiphy_stream_on(struct csiphy_device *csiphy) > wmb(); > } > > - csiphy->res->hw_ops->lanes_enable(csiphy, cfg, link_freq, lane_mask); > - > - return 0; > + return csiphy->res->hw_ops->lanes_enable(csiphy, cfg, link_freq, lane_mask); ick. More high brow stuff from bod here but, more seriously this is three levels of indirection deep and the statement keeps getting longer. Could you get a pointer to hw_ops() to reduce this down a bit. > } > > /* > diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.h b/drivers/media/platform/qcom/camss/camss-csiphy.h > index d198171700e73..21cf2ce931c1d 100644 > --- a/drivers/media/platform/qcom/camss/camss-csiphy.h > +++ b/drivers/media/platform/qcom/camss/camss-csiphy.h > @@ -73,9 +73,9 @@ struct csiphy_hw_ops { > void (*hw_version_read)(struct csiphy_device *csiphy, > struct device *dev); > void (*reset)(struct csiphy_device *csiphy); > - void (*lanes_enable)(struct csiphy_device *csiphy, > - struct csiphy_config *cfg, > - s64 link_freq, u8 lane_mask); > + int (*lanes_enable)(struct csiphy_device *csiphy, > + struct csiphy_config *cfg, > + s64 link_freq, u8 lane_mask); > void (*lanes_disable)(struct csiphy_device *csiphy, > struct csiphy_config *cfg); > irqreturn_t (*isr)(int irq, void *dev); > With those tweaks. Reviewed-by: Bryan O'Donoghue --- bod