Re: [PATCH 04/17] media: camss: csid-170: fix non-10bit formats

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jonathan,

On 25.05.2021 21:38, Jonathan Marek wrote:
On 5/25/21 2:15 PM, Andrey Konovalov wrote:
Hi Jonathan,

Thank you for your patch!

On 11.05.2021 21:07, Jonathan Marek wrote:
Use the decode_format/data_type from the "format" struct instead of a
hardcoded 10-bit format.

Fixes: eebe6d00e9bf ("media: camss: Add support for CSID hardware version Titan 170")
Signed-off-by: Jonathan Marek <jonathan@xxxxxxxx>
---
  drivers/media/platform/qcom/camss/camss-csid-170.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csid-170.c b/drivers/media/platform/qcom/camss/camss-csid-170.c
index ac22ff29d2a9..a81cc94c075f 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-170.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-170.c
@@ -366,7 +366,7 @@ static void csid_configure_stream(struct csid_device *csid, u8 enable)
              val |= input_format->width & 0x1fff << TPG_DT_n_CFG_0_FRAME_WIDTH;
              writel_relaxed(val, csid->base + CSID_TPG_DT_n_CFG_0(0));
-            val = DATA_TYPE_RAW_10BIT << TPG_DT_n_CFG_1_DATA_TYPE;
+            val = format->data_type << TPG_DT_n_CFG_1_DATA_TYPE;
              writel_relaxed(val, csid->base + CSID_TPG_DT_n_CFG_1(0));
              val = tg->mode << TPG_DT_n_CFG_2_PAYLOAD_MODE;
@@ -382,8 +382,8 @@ static void csid_configure_stream(struct csid_device *csid, u8 enable)
          val = 1 << RDI_CFG0_BYTE_CNTR_EN;
          val |= 1 << RDI_CFG0_FORMAT_MEASURE_EN;
          val |= 1 << RDI_CFG0_TIMESTAMP_EN;
-        val |= DECODE_FORMAT_PAYLOAD_ONLY << RDI_CFG0_DECODE_FORMAT;
-        val |= DATA_TYPE_RAW_10BIT << RDI_CFG0_DATA_TYPE;
+        val |= format->decode_format << RDI_CFG0_DECODE_FORMAT;
+        val |= format->data_type << RDI_CFG0_DATA_TYPE;

I've given it a try on RB3 board (aka db845c plus the navigation mezzanine), which uses ov8856 camera
sensor (its output format is SGRBG10_1X10).

The above change doesn't work for me because format->decode_format has the value of 0x02 (which is
DECODE_FORMAT_UNCOMPRESSED_10_BIT). format->data_type has the expected value of 0x2b (DATA_TYPE_RAW_10BIT).


I will change it back to using DECODE_FORMAT_PAYLOAD_ONLY for the v2, since it does seem like this is the correct value for the RDI path.

Sounds good. Just in case, I've tried

--- a/drivers/media/platform/qcom/camss/camss-csid-170.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-170.c
@@ -390,7 +390,7 @@ static void csid_configure_stream(struct csid_device *csid, u8 enable)
                val = 1 << RDI_CFG0_BYTE_CNTR_EN;
                val |= 1 << RDI_CFG0_FORMAT_MEASURE_EN;
                val |= 1 << RDI_CFG0_TIMESTAMP_EN;
-               val |= format->decode_format << RDI_CFG0_DECODE_FORMAT;
+               val |= DECODE_FORMAT_PAYLOAD_ONLY << RDI_CFG0_DECODE_FORMAT;
                val |= format->data_type << RDI_CFG0_DATA_TYPE;
                val |= vc << RDI_CFG0_VIRTUAL_CHANNEL;
                val |= dt_id << RDI_CFG0_DT_ID;

on top of v1 patchset, and it worked OK on RB3 with the ov8856 camera.

I planned to check the other RB3's camera too - the "tracking" ov7251 one, but it turned out that I don't
have the information on which particular SOC's MIPI lanes are connected to this camera. I've tried a few
clock-lanes/data-lanes combinations, but none worked (ov7251 is controlled OK via the i2c bus, but no
data are captured).

(but IIRC, using DECODE_FORMAT_UNCOMPRESSED_10_BIT worked on RB3 with the ov8856 camera last year when I brought it up. maybe the VFE or another register is configured differently)

OK. I only used the current upstream camss driver, so have nothing to compare it against.

I also noticed that with ov8856 camera, only 3264x2448 and 1632x1224 modes work correctly on RB3
(used the current media_tree). But with the below change all the other modes (3280x2464 and 1640x1232)
start working OK too:

--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -1575,7 +1575,7 @@ int msm_vfe_register_entities(struct vfe_device *vfe,
                }

                video_out->ops = &vfe->video_ops;
-               video_out->bpl_alignment = 8;
+               video_out->bpl_alignment = 16;
                video_out->line_based = 0;
                if (i == VFE_LINE_PIX) {
                        video_out->bpl_alignment = 16;

And (with the increased size of the capture buffer) I did see that the data captured from camss were padded
to the next 16-byte boundary with the data from the previous 16-byte chunk. E.g. in the 3280x2464 case 12
padding bytes were added.
Personally I don't have access to the datasheet, but I've been told that as per the docs, 16-byte alignment
should not be needed in this case (RAW10P camera connected through rdi).
Does it ring any bell for you?

Thanks,
Andrey

Thanks,
Andrey

          val |= vc << RDI_CFG0_VIRTUAL_CHANNEL;
          val |= dt_id << RDI_CFG0_DT_ID;
          writel_relaxed(val, csid->base + CSID_RDI_CFG0(0));




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux