| Message ID | 20230911131411.196033-18-bryan.odonoghue@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | media: qcom: camss: Add parameter passing to remove several outstanding bugs | expand |
On 11/09/2023 15:14, Bryan O'Donoghue wrote: > Digging into the documentation we find that the DT_ID bitfield is used to > map the six bit DT to a two bit ID code. This value is concatenated to the > VC bitfield to create a CID value. DT_ID is the two least significant bits > of CID and VC the most significant bits. > > Originally we set dt_id = vc * 4 in and then subsequently set dt_id = vc. > > commit 3c4ed72a16bc ("media: camss: sm8250: Virtual channels for CSID") > silently fixed the multiplication by four which would give a better > value for the generated CID without mentioning what was being done or why. > > Next up I haplessly changed the value back to "dt_id = vc * 4" since there > didn't appear to be any logic behind it. > > Hans asked what the change was for and I honestly couldn't remember the > provenance of it, so I dug in. > > Link: https://lore.kernel.org/linux-arm-msm/edd4bf9b-0e1b-883c-1a4d-50f4102c3924@xs4all.nl/ > > Add a comment so the next hapless programmer doesn't make this same > mistake. > > Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> > --- > drivers/media/platform/qcom/camss/camss-csid-gen2.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen2.c b/drivers/media/platform/qcom/camss/camss-csid-gen2.c > index 6ba2b10326444..cee50fc87e9de 100644 > --- a/drivers/media/platform/qcom/camss/camss-csid-gen2.c > +++ b/drivers/media/platform/qcom/camss/camss-csid-gen2.c > @@ -352,6 +352,11 @@ static void __csid_configure_stream(struct csid_device *csid, u8 enable, u8 vc) > phy_sel = csid->phy.csiphy_id; > > if (enable) { > + /* > + * A value caled 'CID' gets generated internal to CAMSS logic caled -> called > + * which is a concatenation of [vc:6 | dt_id:2] hence we reuse vc:6? Do you mean bit 6 or do you mean the least significant 6 bits? Regardless, since the vc variable <= 3 (since MSM_CSID_MAX_SRC_STREAMS is 4), either interpretation makes little sense. And what does "DT" stand for? > + * the least significant two bits of the VC to 'stuff' the CID value. > + */ > u8 dt_id = vc; If dt_id should be the least significant two bits of vc, shouldn't this say: "= vc & 3;"? Or, alternatively, have a comment that vc <= 3? > > if (tg->enabled) { Regards, Hans
On Mon, Sep 25, 2023 at 09:11:52AM +0200, Hans Verkuil wrote: > On 11/09/2023 15:14, Bryan O'Donoghue wrote: > > Digging into the documentation we find that the DT_ID bitfield is used to > > map the six bit DT to a two bit ID code. This value is concatenated to the > > VC bitfield to create a CID value. DT_ID is the two least significant bits > > of CID and VC the most significant bits. > > > > Originally we set dt_id = vc * 4 in and then subsequently set dt_id = vc. > > > > commit 3c4ed72a16bc ("media: camss: sm8250: Virtual channels for CSID") > > silently fixed the multiplication by four which would give a better > > value for the generated CID without mentioning what was being done or why. > > > > Next up I haplessly changed the value back to "dt_id = vc * 4" since there > > didn't appear to be any logic behind it. > > > > Hans asked what the change was for and I honestly couldn't remember the > > provenance of it, so I dug in. > > > > Link: https://lore.kernel.org/linux-arm-msm/edd4bf9b-0e1b-883c-1a4d-50f4102c3924@xs4all.nl/ > > > > Add a comment so the next hapless programmer doesn't make this same > > mistake. > > > > Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> > > --- > > drivers/media/platform/qcom/camss/camss-csid-gen2.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen2.c b/drivers/media/platform/qcom/camss/camss-csid-gen2.c > > index 6ba2b10326444..cee50fc87e9de 100644 > > --- a/drivers/media/platform/qcom/camss/camss-csid-gen2.c > > +++ b/drivers/media/platform/qcom/camss/camss-csid-gen2.c > > @@ -352,6 +352,11 @@ static void __csid_configure_stream(struct csid_device *csid, u8 enable, u8 vc) > > phy_sel = csid->phy.csiphy_id; > > > > if (enable) { > > + /* > > + * A value caled 'CID' gets generated internal to CAMSS logic > > caled -> called > > > + * which is a concatenation of [vc:6 | dt_id:2] hence we reuse > > vc:6? Do you mean bit 6 or do you mean the least significant 6 bits? > > Regardless, since the vc variable <= 3 (since MSM_CSID_MAX_SRC_STREAMS is 4), > either interpretation makes little sense. More recent versions of CSI-2 support up to 6 bits of VC (or possibly even more in versions I may not know about). It would probably make sense to write vc[5:0] | dt_id[1:0] or something similar. > And what does "DT" stand for? Data Type. > > + * the least significant two bits of the VC to 'stuff' the CID value. > > + */ > > u8 dt_id = vc; > > If dt_id should be the least significant two bits of vc, shouldn't > this say: "= vc & 3;"? Or, alternatively, have a comment that vc <= 3? > > > > > if (tg->enabled) {
On 25/09/2023 09:14, Laurent Pinchart wrote: > On Mon, Sep 25, 2023 at 09:11:52AM +0200, Hans Verkuil wrote: >> On 11/09/2023 15:14, Bryan O'Donoghue wrote: >>> Digging into the documentation we find that the DT_ID bitfield is used to >>> map the six bit DT to a two bit ID code. This value is concatenated to the >>> VC bitfield to create a CID value. DT_ID is the two least significant bits >>> of CID and VC the most significant bits. >>> >>> Originally we set dt_id = vc * 4 in and then subsequently set dt_id = vc. >>> >>> commit 3c4ed72a16bc ("media: camss: sm8250: Virtual channels for CSID") >>> silently fixed the multiplication by four which would give a better >>> value for the generated CID without mentioning what was being done or why. >>> >>> Next up I haplessly changed the value back to "dt_id = vc * 4" since there >>> didn't appear to be any logic behind it. >>> >>> Hans asked what the change was for and I honestly couldn't remember the >>> provenance of it, so I dug in. >>> >>> Link: https://lore.kernel.org/linux-arm-msm/edd4bf9b-0e1b-883c-1a4d-50f4102c3924@xs4all.nl/ >>> >>> Add a comment so the next hapless programmer doesn't make this same >>> mistake. >>> >>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> >>> --- >>> drivers/media/platform/qcom/camss/camss-csid-gen2.c | 5 +++++ >>> 1 file changed, 5 insertions(+) >>> >>> diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen2.c b/drivers/media/platform/qcom/camss/camss-csid-gen2.c >>> index 6ba2b10326444..cee50fc87e9de 100644 >>> --- a/drivers/media/platform/qcom/camss/camss-csid-gen2.c >>> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen2.c >>> @@ -352,6 +352,11 @@ static void __csid_configure_stream(struct csid_device *csid, u8 enable, u8 vc) >>> phy_sel = csid->phy.csiphy_id; >>> >>> if (enable) { >>> + /* >>> + * A value caled 'CID' gets generated internal to CAMSS logic >> >> caled -> called >> >>> + * which is a concatenation of [vc:6 | dt_id:2] hence we reuse >> >> vc:6? Do you mean bit 6 or do you mean the least significant 6 bits? >> >> Regardless, since the vc variable <= 3 (since MSM_CSID_MAX_SRC_STREAMS is 4), >> either interpretation makes little sense. > > More recent versions of CSI-2 support up to 6 bits of VC (or possibly > even more in versions I may not know about). It would probably make > sense to write vc[5:0] | dt_id[1:0] or something similar. > >> And what does "DT" stand for? > > Data Type. > >>> + * the least significant two bits of the VC to 'stuff' the CID value. >>> + */ >>> u8 dt_id = vc; >> >> If dt_id should be the least significant two bits of vc, shouldn't >> this say: "= vc & 3;"? Or, alternatively, have a comment that vc <= 3? >> >>> >>> if (tg->enabled) { > I'll rewrite this comment since its still confusing people. @Hans VC and DT are fields in the CSI protocol structure sections 2.2.2.2 and 2.2.2.3 https://www.nxp.com/docs/en/application-note/AN5305.pdf --- bod
diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen2.c b/drivers/media/platform/qcom/camss/camss-csid-gen2.c index 6ba2b10326444..cee50fc87e9de 100644 --- a/drivers/media/platform/qcom/camss/camss-csid-gen2.c +++ b/drivers/media/platform/qcom/camss/camss-csid-gen2.c @@ -352,6 +352,11 @@ static void __csid_configure_stream(struct csid_device *csid, u8 enable, u8 vc) phy_sel = csid->phy.csiphy_id; if (enable) { + /* + * A value caled 'CID' gets generated internal to CAMSS logic + * which is a concatenation of [vc:6 | dt_id:2] hence we reuse + * the least significant two bits of the VC to 'stuff' the CID value. + */ u8 dt_id = vc; if (tg->enabled) {
Digging into the documentation we find that the DT_ID bitfield is used to map the six bit DT to a two bit ID code. This value is concatenated to the VC bitfield to create a CID value. DT_ID is the two least significant bits of CID and VC the most significant bits. Originally we set dt_id = vc * 4 in and then subsequently set dt_id = vc. commit 3c4ed72a16bc ("media: camss: sm8250: Virtual channels for CSID") silently fixed the multiplication by four which would give a better value for the generated CID without mentioning what was being done or why. Next up I haplessly changed the value back to "dt_id = vc * 4" since there didn't appear to be any logic behind it. Hans asked what the change was for and I honestly couldn't remember the provenance of it, so I dug in. Link: https://lore.kernel.org/linux-arm-msm/edd4bf9b-0e1b-883c-1a4d-50f4102c3924@xs4all.nl/ Add a comment so the next hapless programmer doesn't make this same mistake. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> --- drivers/media/platform/qcom/camss/camss-csid-gen2.c | 5 +++++ 1 file changed, 5 insertions(+)