[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <176873791545.3486172.9291085318504972330@ping.linuxembedded.co.uk>
Date: Sun, 18 Jan 2026 12:05:15 +0000
From: Kieran Bingham <kieran.bingham@...asonboard.com>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>, Casey Connolly <casey.connolly@...aro.org>, Dr. Git <drgitx@...il.com>, Luca Weiss <luca.weiss@...rphone.com>, Mauro Carvalho Chehab <mchehab@...nel.org>, Petr Hodina <phodina@...tonmail.com>, Robert Foss <rfoss@...nel.org>, Todor Tomov <todor.too@...il.com>, Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>, david@...t.cz
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>, Joel Selvaraj <foss@...lselvaraj.com>, Kieran Bingham <kbingham@...nel.org>, Sakari Ailus <sakari.ailus@...ux.intel.com>, linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org, phone-devel@...r.kernel.org
Subject: Re: [PATCH v3 2/8] media: qcom: camss: csiphy-3ph: Use odd bits for configuring C-PHY lanes
Quoting Bryan O'Donoghue (2026-01-17 21:38:17)
> On 17/01/2026 15:36, David Heidelberg via B4 Relay wrote:
> > From: David Heidelberg <david@...t.cz>
> >
> > 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 <david@...t.cz>
> > ---
> > .../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 <linux/delay.h>
> > #include <linux/interrupt.h>
> > #include <linux/io.h>
> > +#include <linux/media-bus-format.h>
> >
> > #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);
I see that addition to a bit mask and get a little bit scared.
This gives:
pos mask
0 0b00000010 (note 0 bit is zero here but 1 on all others)
1 0b00000011
2 0b00000101
3 0b00001001
4 0b00010001
Is that expected?
Can data[i].pos ever be position 0 ??
I assume this starts at position 1 - and the +1 here is to always set
the zeroth bit ?
Perhapse this might be precise to convey that in such a case?
lane_mask |= BIT(pos) | 1;
I guess it depends on what this is really being used for which I don't
have in my context.
--
Kieran
>
> 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 <bryan.odonoghue@...aro.org>
>
> ---
> bod
Powered by blists - more mailing lists