* IMX274 driver @ 2020-05-29 2:07 Sowjanya Komatineni 2020-05-31 21:56 ` Luca Ceresoli 0 siblings, 1 reply; 9+ messages in thread From: Sowjanya Komatineni @ 2020-05-29 2:07 UTC (permalink / raw) To: luca, hverkuil-cisco, Frank Chen, Thierry Reding, linux-media Hi Luca, Quick question regarding IMX274 driver that was up streamed by you. Upstream IMX274 driver programs Y_OUT_SIZE correctly based on IMX274 datasheet and register mode table for Y_OUT_SIZE where it includes 6 ignored area of effective pixels + 8 effective margin for color processing pixels. So, Y_OUT_SIZE register value = height + 14 But somehow with this we are not seeing full frame on CSI. In our internal NVIDIA IMX274 driver, we are programming Y_OUT_SIZE to exact height Y_OUT_SIZE = height So for debug, followed the same and updated upstream IMX274 driver to program Y_OUT_SIZE = crop.height locally and I see all resolutions working fine with this. Checking with Sony on whats causing sensor not to send full frame when Y_OUT_SIZE is set to height + 14. But thought to check with you in parallel if there are any known issues related to this with IMX274 driver. Appreciate your response. Thanks & Regards, Sowjanya ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IMX274 driver 2020-05-29 2:07 IMX274 driver Sowjanya Komatineni @ 2020-05-31 21:56 ` Luca Ceresoli 2020-06-01 8:31 ` Hans Verkuil 0 siblings, 1 reply; 9+ messages in thread From: Luca Ceresoli @ 2020-05-31 21:56 UTC (permalink / raw) To: Sowjanya Komatineni, hverkuil-cisco, Frank Chen, Thierry Reding, linux-media Hi Sowjanya, On 29/05/20 04:07, Sowjanya Komatineni wrote: > Hi Luca, > > Quick question regarding IMX274 driver that was up streamed by you. Well, to be fair I only added cropping and made some improvements. > Upstream IMX274 driver programs Y_OUT_SIZE correctly based on IMX274 > datasheet and register mode table for Y_OUT_SIZE where it includes 6 > ignored area of effective pixels + 8 effective margin for color > processing pixels. > > So, Y_OUT_SIZE register value = height + 14 > > But somehow with this we are not seeing full frame on CSI. > > In our internal NVIDIA IMX274 driver, we are programming Y_OUT_SIZE to > exact height Y_OUT_SIZE = height > > So for debug, followed the same and updated upstream IMX274 driver to > program Y_OUT_SIZE = crop.height locally and I see all resolutions > working fine with this. > > Checking with Sony on whats causing sensor not to send full frame when > Y_OUT_SIZE is set to height + 14. > > But thought to check with you in parallel if there are any known issues That's strange. Unfortunately I'm not using imx274 anymore since a long time and don't remember the details, but definitely I did test it and if there had been 14 missing lines I'm pretty sure I would have noticed. I'll see if I can remember anything useful, and in case I'll update you. I would be glad if you can update me on any findings too, maybe they will help in understanding the problem better. Regards, -- Luca ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IMX274 driver 2020-05-31 21:56 ` Luca Ceresoli @ 2020-06-01 8:31 ` Hans Verkuil 2020-06-01 8:47 ` Hans Verkuil 0 siblings, 1 reply; 9+ messages in thread From: Hans Verkuil @ 2020-06-01 8:31 UTC (permalink / raw) To: Luca Ceresoli, Sowjanya Komatineni, Frank Chen, Thierry Reding, linux-media Hi Luca, On 31/05/2020 23:56, Luca Ceresoli wrote: > Hi Sowjanya, > > On 29/05/20 04:07, Sowjanya Komatineni wrote: >> Hi Luca, >> >> Quick question regarding IMX274 driver that was up streamed by you. > > Well, to be fair I only added cropping and made some improvements. > >> Upstream IMX274 driver programs Y_OUT_SIZE correctly based on IMX274 >> datasheet and register mode table for Y_OUT_SIZE where it includes 6 >> ignored area of effective pixels + 8 effective margin for color >> processing pixels. >> >> So, Y_OUT_SIZE register value = height + 14 >> >> But somehow with this we are not seeing full frame on CSI. >> >> In our internal NVIDIA IMX274 driver, we are programming Y_OUT_SIZE to >> exact height Y_OUT_SIZE = height >> >> So for debug, followed the same and updated upstream IMX274 driver to >> program Y_OUT_SIZE = crop.height locally and I see all resolutions >> working fine with this. >> >> Checking with Sony on whats causing sensor not to send full frame when >> Y_OUT_SIZE is set to height + 14. >> >> But thought to check with you in parallel if there are any known issues > > That's strange. Unfortunately I'm not using imx274 anymore since a long > time and don't remember the details, but definitely I did test it and if > there had been 14 missing lines I'm pretty sure I would have noticed. > > I'll see if I can remember anything useful, and in case I'll update you. > I would be glad if you can update me on any findings too, maybe they > will help in understanding the problem better. The '+ 14' makes no sense. I wonder if this was perhaps to compensate for some problem in the bridge driver that this sensor was connected to. Which bridge driver did you use for testing? Do you remember where you got the '+ 14' from? Regards, Hans ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IMX274 driver 2020-06-01 8:31 ` Hans Verkuil @ 2020-06-01 8:47 ` Hans Verkuil 2020-06-02 8:51 ` Luca Ceresoli 0 siblings, 1 reply; 9+ messages in thread From: Hans Verkuil @ 2020-06-01 8:47 UTC (permalink / raw) To: Luca Ceresoli, Sowjanya Komatineni, Frank Chen, Thierry Reding, linux-media On 01/06/2020 10:31, Hans Verkuil wrote: > Hi Luca, > > On 31/05/2020 23:56, Luca Ceresoli wrote: >> Hi Sowjanya, >> >> On 29/05/20 04:07, Sowjanya Komatineni wrote: >>> Hi Luca, >>> >>> Quick question regarding IMX274 driver that was up streamed by you. >> >> Well, to be fair I only added cropping and made some improvements. >> >>> Upstream IMX274 driver programs Y_OUT_SIZE correctly based on IMX274 >>> datasheet and register mode table for Y_OUT_SIZE where it includes 6 >>> ignored area of effective pixels + 8 effective margin for color >>> processing pixels. >>> >>> So, Y_OUT_SIZE register value = height + 14 >>> >>> But somehow with this we are not seeing full frame on CSI. >>> >>> In our internal NVIDIA IMX274 driver, we are programming Y_OUT_SIZE to >>> exact height Y_OUT_SIZE = height >>> >>> So for debug, followed the same and updated upstream IMX274 driver to >>> program Y_OUT_SIZE = crop.height locally and I see all resolutions >>> working fine with this. >>> >>> Checking with Sony on whats causing sensor not to send full frame when >>> Y_OUT_SIZE is set to height + 14. >>> >>> But thought to check with you in parallel if there are any known issues >> >> That's strange. Unfortunately I'm not using imx274 anymore since a long >> time and don't remember the details, but definitely I did test it and if >> there had been 14 missing lines I'm pretty sure I would have noticed. >> >> I'll see if I can remember anything useful, and in case I'll update you. >> I would be glad if you can update me on any findings too, maybe they >> will help in understanding the problem better. > > The '+ 14' makes no sense. I wonder if this was perhaps to compensate for > some problem in the bridge driver that this sensor was connected to. > Which bridge driver did you use for testing? Do you remember where you got > the '+ 14' from? Hmm, this comes from the first version of this driver where Y_OUT_SIZE was set to 0x87e (2160 + 14). This in turn comes from the datasheet ('Register Setting for Each Readout Drive Mode'). Looking at the "Detailed Specification of Each Mode" (page 63 in my copy of the datasheet) I see three additional parameters: "Front ignore area of effective pixel", "Front effective margin for color processing" and "Rear effective margin for color processing", these are 6, 4 and 4, which is a total of 14. So I guess that's where the 14 comes from. Knowing with which bridge driver this was tested will definitely be helpful. Regards, Hans ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IMX274 driver 2020-06-01 8:47 ` Hans Verkuil @ 2020-06-02 8:51 ` Luca Ceresoli 2020-06-02 14:17 ` Sowjanya Komatineni 0 siblings, 1 reply; 9+ messages in thread From: Luca Ceresoli @ 2020-06-02 8:51 UTC (permalink / raw) To: Hans Verkuil, Sowjanya Komatineni, Frank Chen, Thierry Reding, linux-media Cc: Leon Luo Hi, [adding Leon Luo in Cc:, the maintainer and original driver author] On 01/06/20 10:47, Hans Verkuil wrote: > On 01/06/2020 10:31, Hans Verkuil wrote: >> Hi Luca, >> >> On 31/05/2020 23:56, Luca Ceresoli wrote: >>> Hi Sowjanya, >>> >>> On 29/05/20 04:07, Sowjanya Komatineni wrote: >>>> Hi Luca, >>>> >>>> Quick question regarding IMX274 driver that was up streamed by you. >>> >>> Well, to be fair I only added cropping and made some improvements. >>> >>>> Upstream IMX274 driver programs Y_OUT_SIZE correctly based on IMX274 >>>> datasheet and register mode table for Y_OUT_SIZE where it includes 6 >>>> ignored area of effective pixels + 8 effective margin for color >>>> processing pixels. >>>> >>>> So, Y_OUT_SIZE register value = height + 14 >>>> >>>> But somehow with this we are not seeing full frame on CSI. >>>> >>>> In our internal NVIDIA IMX274 driver, we are programming Y_OUT_SIZE to >>>> exact height Y_OUT_SIZE = height >>>> >>>> So for debug, followed the same and updated upstream IMX274 driver to >>>> program Y_OUT_SIZE = crop.height locally and I see all resolutions >>>> working fine with this. >>>> >>>> Checking with Sony on whats causing sensor not to send full frame when >>>> Y_OUT_SIZE is set to height + 14. >>>> >>>> But thought to check with you in parallel if there are any known issues >>> >>> That's strange. Unfortunately I'm not using imx274 anymore since a long >>> time and don't remember the details, but definitely I did test it and if >>> there had been 14 missing lines I'm pretty sure I would have noticed. >>> >>> I'll see if I can remember anything useful, and in case I'll update you. >>> I would be glad if you can update me on any findings too, maybe they >>> will help in understanding the problem better. >> >> The '+ 14' makes no sense. I wonder if this was perhaps to compensate for >> some problem in the bridge driver that this sensor was connected to. >> Which bridge driver did you use for testing? Do you remember where you got >> the '+ 14' from? > > Hmm, this comes from the first version of this driver where Y_OUT_SIZE > was set to 0x87e (2160 + 14). This in turn comes from the datasheet ('Register > Setting for Each Readout Drive Mode'). > > Looking at the "Detailed Specification of Each Mode" (page 63 in my copy of > the datasheet) I see three additional parameters: "Front ignore area of > effective pixel", "Front effective margin for color processing" and "Rear > effective margin for color processing", these are 6, 4 and 4, which is a > total of 14. > > So I guess that's where the 14 comes from. Double-checked, and I agree. > Knowing with which bridge driver this was tested will definitely be helpful. The design was based on a Xilinx zcu106 and the sensor output went into the Xilinx MIPI CSI-2 RX subsystem IP (currently being mainlined), an ISP IP and a Xilinx video DMA IP block, I think it was the "Video Frame Buffer Writer" IP. I did several experiments with similar setups, even with basic a Xilinx debayer+CCM in place of the ISP, and don't remember any problems with wrong lines. Wild guess: Sowjanya, are you using VFLIP? I never used that, but it might influence the order of lines processing somehow. -- Luca ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IMX274 driver 2020-06-02 8:51 ` Luca Ceresoli @ 2020-06-02 14:17 ` Sowjanya Komatineni 2020-06-02 16:16 ` Sowjanya Komatineni 0 siblings, 1 reply; 9+ messages in thread From: Sowjanya Komatineni @ 2020-06-02 14:17 UTC (permalink / raw) To: Luca Ceresoli, Hans Verkuil, Frank Chen, Thierry Reding, linux-media Cc: Leon Luo On 6/2/20 1:51 AM, Luca Ceresoli wrote: > Hi, > > [adding Leon Luo in Cc:, the maintainer and original driver author] > > On 01/06/20 10:47, Hans Verkuil wrote: >> On 01/06/2020 10:31, Hans Verkuil wrote: >>> Hi Luca, >>> >>> On 31/05/2020 23:56, Luca Ceresoli wrote: >>>> Hi Sowjanya, >>>> >>>> On 29/05/20 04:07, Sowjanya Komatineni wrote: >>>>> Hi Luca, >>>>> >>>>> Quick question regarding IMX274 driver that was up streamed by you. >>>> Well, to be fair I only added cropping and made some improvements. >>>> >>>>> Upstream IMX274 driver programs Y_OUT_SIZE correctly based on IMX274 >>>>> datasheet and register mode table for Y_OUT_SIZE where it includes 6 >>>>> ignored area of effective pixels + 8 effective margin for color >>>>> processing pixels. >>>>> >>>>> So, Y_OUT_SIZE register value = height + 14 >>>>> >>>>> But somehow with this we are not seeing full frame on CSI. >>>>> >>>>> In our internal NVIDIA IMX274 driver, we are programming Y_OUT_SIZE to >>>>> exact height Y_OUT_SIZE = height >>>>> >>>>> So for debug, followed the same and updated upstream IMX274 driver to >>>>> program Y_OUT_SIZE = crop.height locally and I see all resolutions >>>>> working fine with this. >>>>> >>>>> Checking with Sony on whats causing sensor not to send full frame when >>>>> Y_OUT_SIZE is set to height + 14. >>>>> >>>>> But thought to check with you in parallel if there are any known issues >>>> That's strange. Unfortunately I'm not using imx274 anymore since a long >>>> time and don't remember the details, but definitely I did test it and if >>>> there had been 14 missing lines I'm pretty sure I would have noticed. >>>> >>>> I'll see if I can remember anything useful, and in case I'll update you. >>>> I would be glad if you can update me on any findings too, maybe they >>>> will help in understanding the problem better. >>> The '+ 14' makes no sense. I wonder if this was perhaps to compensate for >>> some problem in the bridge driver that this sensor was connected to. >>> Which bridge driver did you use for testing? Do you remember where you got >>> the '+ 14' from? >> Hmm, this comes from the first version of this driver where Y_OUT_SIZE >> was set to 0x87e (2160 + 14). This in turn comes from the datasheet ('Register >> Setting for Each Readout Drive Mode'). >> >> Looking at the "Detailed Specification of Each Mode" (page 63 in my copy of >> the datasheet) I see three additional parameters: "Front ignore area of >> effective pixel", "Front effective margin for color processing" and "Rear >> effective margin for color processing", these are 6, 4 and 4, which is a >> total of 14. >> >> So I guess that's where the 14 comes from. > Double-checked, and I agree. > >> Knowing with which bridge driver this was tested will definitely be helpful. > The design was based on a Xilinx zcu106 and the sensor output went into > the Xilinx MIPI CSI-2 RX subsystem IP (currently being mainlined), an > ISP IP and a Xilinx video DMA IP block, I think it was the "Video Frame > Buffer Writer" IP. I did several experiments with similar setups, even > with basic a Xilinx debayer+CCM in place of the ISP, and don't remember > any problems with wrong lines. > > Wild guess: Sowjanya, are you using VFLIP? I never used that, but it > might influence the order of lines processing somehow. No I am not using VFLIP. Did quick experiment of keeping buffer as valid even in case of frame buffer write timeout to see so far captured image and I see full 3840x2160 image capture with both cases where Y_OUT_SIZE = height and also with Y_OUT_SIZE = height + 14 Could be something during end of frame when using Y_OUT_SIZE = height + 14 Provided all register settings being used to Sony and explained this observation. Will update when I hear from them. Also will check how these 14 lines (ignore + color processing effective margin) translates to CSI frame sent out.. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IMX274 driver 2020-06-02 14:17 ` Sowjanya Komatineni @ 2020-06-02 16:16 ` Sowjanya Komatineni 2020-06-02 20:08 ` Luca Ceresoli 0 siblings, 1 reply; 9+ messages in thread From: Sowjanya Komatineni @ 2020-06-02 16:16 UTC (permalink / raw) To: Luca Ceresoli, Hans Verkuil, Frank Chen, Thierry Reding, linux-media Cc: Leon Luo On 6/2/20 7:17 AM, Sowjanya Komatineni wrote: > > On 6/2/20 1:51 AM, Luca Ceresoli wrote: >> Hi, >> >> [adding Leon Luo in Cc:, the maintainer and original driver author] >> >> On 01/06/20 10:47, Hans Verkuil wrote: >>> On 01/06/2020 10:31, Hans Verkuil wrote: >>>> Hi Luca, >>>> >>>> On 31/05/2020 23:56, Luca Ceresoli wrote: >>>>> Hi Sowjanya, >>>>> >>>>> On 29/05/20 04:07, Sowjanya Komatineni wrote: >>>>>> Hi Luca, >>>>>> >>>>>> Quick question regarding IMX274 driver that was up streamed by you. >>>>> Well, to be fair I only added cropping and made some improvements. >>>>> >>>>>> Upstream IMX274 driver programs Y_OUT_SIZE correctly based on IMX274 >>>>>> datasheet and register mode table for Y_OUT_SIZE where it includes 6 >>>>>> ignored area of effective pixels + 8 effective margin for color >>>>>> processing pixels. >>>>>> >>>>>> So, Y_OUT_SIZE register value = height + 14 >>>>>> >>>>>> But somehow with this we are not seeing full frame on CSI. >>>>>> >>>>>> In our internal NVIDIA IMX274 driver, we are programming >>>>>> Y_OUT_SIZE to >>>>>> exact height Y_OUT_SIZE = height >>>>>> >>>>>> So for debug, followed the same and updated upstream IMX274 >>>>>> driver to >>>>>> program Y_OUT_SIZE = crop.height locally and I see all resolutions >>>>>> working fine with this. >>>>>> >>>>>> Checking with Sony on whats causing sensor not to send full frame >>>>>> when >>>>>> Y_OUT_SIZE is set to height + 14. >>>>>> >>>>>> But thought to check with you in parallel if there are any known >>>>>> issues >>>>> That's strange. Unfortunately I'm not using imx274 anymore since a >>>>> long >>>>> time and don't remember the details, but definitely I did test it >>>>> and if >>>>> there had been 14 missing lines I'm pretty sure I would have noticed. >>>>> >>>>> I'll see if I can remember anything useful, and in case I'll >>>>> update you. >>>>> I would be glad if you can update me on any findings too, maybe they >>>>> will help in understanding the problem better. >>>> The '+ 14' makes no sense. I wonder if this was perhaps to >>>> compensate for >>>> some problem in the bridge driver that this sensor was connected to. >>>> Which bridge driver did you use for testing? Do you remember where >>>> you got >>>> the '+ 14' from? >>> Hmm, this comes from the first version of this driver where Y_OUT_SIZE >>> was set to 0x87e (2160 + 14). This in turn comes from the datasheet >>> ('Register >>> Setting for Each Readout Drive Mode'). >>> >>> Looking at the "Detailed Specification of Each Mode" (page 63 in my >>> copy of >>> the datasheet) I see three additional parameters: "Front ignore area of >>> effective pixel", "Front effective margin for color processing" and >>> "Rear >>> effective margin for color processing", these are 6, 4 and 4, which >>> is a >>> total of 14. >>> >>> So I guess that's where the 14 comes from. >> Double-checked, and I agree. >> >>> Knowing with which bridge driver this was tested will definitely be >>> helpful. >> The design was based on a Xilinx zcu106 and the sensor output went into >> the Xilinx MIPI CSI-2 RX subsystem IP (currently being mainlined), an >> ISP IP and a Xilinx video DMA IP block, I think it was the "Video Frame >> Buffer Writer" IP. I did several experiments with similar setups, even >> with basic a Xilinx debayer+CCM in place of the ISP, and don't remember >> any problems with wrong lines. >> >> Wild guess: Sowjanya, are you using VFLIP? I never used that, but it >> might influence the order of lines processing somehow. > > No I am not using VFLIP. > > Did quick experiment of keeping buffer as valid even in case of frame > buffer write timeout to see so far captured image and I see full > 3840x2160 image capture with both cases where Y_OUT_SIZE = height and > also with Y_OUT_SIZE = height + 14 > > Could be something during end of frame when using Y_OUT_SIZE = height > + 14 > > Provided all register settings being used to Sony and explained this > observation. Will update when I hear from them. > > Also will check how these 14 lines (ignore + color processing > effective margin) translates to CSI frame sent out.. > Hi Luca, Can you please provide exact set-fmt and crop settings you used for imx274 pipeline for 3840X2160 mode1 testing? Would like to try same just in case.. Thanks Sowjanya ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IMX274 driver 2020-06-02 16:16 ` Sowjanya Komatineni @ 2020-06-02 20:08 ` Luca Ceresoli 2020-06-23 17:25 ` Sowjanya Komatineni 0 siblings, 1 reply; 9+ messages in thread From: Luca Ceresoli @ 2020-06-02 20:08 UTC (permalink / raw) To: Sowjanya Komatineni, Hans Verkuil, Frank Chen, Thierry Reding, linux-media Cc: Leon Luo Hi, On 02/06/20 18:16, Sowjanya Komatineni wrote: > > On 6/2/20 7:17 AM, Sowjanya Komatineni wrote: >> >> On 6/2/20 1:51 AM, Luca Ceresoli wrote: >>> Hi, >>> >>> [adding Leon Luo in Cc:, the maintainer and original driver author] >>> >>> On 01/06/20 10:47, Hans Verkuil wrote: >>>> On 01/06/2020 10:31, Hans Verkuil wrote: >>>>> Hi Luca, >>>>> >>>>> On 31/05/2020 23:56, Luca Ceresoli wrote: >>>>>> Hi Sowjanya, >>>>>> >>>>>> On 29/05/20 04:07, Sowjanya Komatineni wrote: >>>>>>> Hi Luca, >>>>>>> >>>>>>> Quick question regarding IMX274 driver that was up streamed by you. >>>>>> Well, to be fair I only added cropping and made some improvements. >>>>>> >>>>>>> Upstream IMX274 driver programs Y_OUT_SIZE correctly based on IMX274 >>>>>>> datasheet and register mode table for Y_OUT_SIZE where it includes 6 >>>>>>> ignored area of effective pixels + 8 effective margin for color >>>>>>> processing pixels. >>>>>>> >>>>>>> So, Y_OUT_SIZE register value = height + 14 >>>>>>> >>>>>>> But somehow with this we are not seeing full frame on CSI. >>>>>>> >>>>>>> In our internal NVIDIA IMX274 driver, we are programming >>>>>>> Y_OUT_SIZE to >>>>>>> exact height Y_OUT_SIZE = height >>>>>>> >>>>>>> So for debug, followed the same and updated upstream IMX274 >>>>>>> driver to >>>>>>> program Y_OUT_SIZE = crop.height locally and I see all resolutions >>>>>>> working fine with this. >>>>>>> >>>>>>> Checking with Sony on whats causing sensor not to send full frame >>>>>>> when >>>>>>> Y_OUT_SIZE is set to height + 14. >>>>>>> >>>>>>> But thought to check with you in parallel if there are any known >>>>>>> issues >>>>>> That's strange. Unfortunately I'm not using imx274 anymore since a >>>>>> long >>>>>> time and don't remember the details, but definitely I did test it >>>>>> and if >>>>>> there had been 14 missing lines I'm pretty sure I would have noticed. >>>>>> >>>>>> I'll see if I can remember anything useful, and in case I'll >>>>>> update you. >>>>>> I would be glad if you can update me on any findings too, maybe they >>>>>> will help in understanding the problem better. >>>>> The '+ 14' makes no sense. I wonder if this was perhaps to >>>>> compensate for >>>>> some problem in the bridge driver that this sensor was connected to. >>>>> Which bridge driver did you use for testing? Do you remember where >>>>> you got >>>>> the '+ 14' from? >>>> Hmm, this comes from the first version of this driver where Y_OUT_SIZE >>>> was set to 0x87e (2160 + 14). This in turn comes from the datasheet >>>> ('Register >>>> Setting for Each Readout Drive Mode'). >>>> >>>> Looking at the "Detailed Specification of Each Mode" (page 63 in my >>>> copy of >>>> the datasheet) I see three additional parameters: "Front ignore area of >>>> effective pixel", "Front effective margin for color processing" and >>>> "Rear >>>> effective margin for color processing", these are 6, 4 and 4, which >>>> is a >>>> total of 14. >>>> >>>> So I guess that's where the 14 comes from. >>> Double-checked, and I agree. >>> >>>> Knowing with which bridge driver this was tested will definitely be >>>> helpful. >>> The design was based on a Xilinx zcu106 and the sensor output went into >>> the Xilinx MIPI CSI-2 RX subsystem IP (currently being mainlined), an >>> ISP IP and a Xilinx video DMA IP block, I think it was the "Video Frame >>> Buffer Writer" IP. I did several experiments with similar setups, even >>> with basic a Xilinx debayer+CCM in place of the ISP, and don't remember >>> any problems with wrong lines. >>> >>> Wild guess: Sowjanya, are you using VFLIP? I never used that, but it >>> might influence the order of lines processing somehow. >> >> No I am not using VFLIP. >> >> Did quick experiment of keeping buffer as valid even in case of frame >> buffer write timeout to see so far captured image and I see full >> 3840x2160 image capture with both cases where Y_OUT_SIZE = height and >> also with Y_OUT_SIZE = height + 14 >> >> Could be something during end of frame when using Y_OUT_SIZE = height >> + 14 >> >> Provided all register settings being used to Sony and explained this >> observation. Will update when I hear from them. >> >> Also will check how these 14 lines (ignore + color processing >> effective margin) translates to CSI frame sent out.. >> > Hi Luca, > > Can you please provide exact set-fmt and crop settings you used for > imx274 pipeline for 3840X2160 mode1 testing? I don't remember much anymore. But I forgot to mention I [almost] always worked with 1920x1080 capture, either with binning or with cropping. I don't think the will change much, as the '+14' is equal in readout modes 1 and 3 (1920p and 3840p modes at 10 bits). Can you try that nevertheless? -- Luca ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IMX274 driver 2020-06-02 20:08 ` Luca Ceresoli @ 2020-06-23 17:25 ` Sowjanya Komatineni 0 siblings, 0 replies; 9+ messages in thread From: Sowjanya Komatineni @ 2020-06-23 17:25 UTC (permalink / raw) To: Luca Ceresoli, Hans Verkuil, Frank Chen, Thierry Reding, linux-media Cc: Leon Luo On 6/2/20 1:08 PM, Luca Ceresoli wrote: > Hi, > > On 02/06/20 18:16, Sowjanya Komatineni wrote: >> On 6/2/20 7:17 AM, Sowjanya Komatineni wrote: >>> On 6/2/20 1:51 AM, Luca Ceresoli wrote: >>>> Hi, >>>> >>>> [adding Leon Luo in Cc:, the maintainer and original driver author] >>>> >>>> On 01/06/20 10:47, Hans Verkuil wrote: >>>>> On 01/06/2020 10:31, Hans Verkuil wrote: >>>>>> Hi Luca, >>>>>> >>>>>> On 31/05/2020 23:56, Luca Ceresoli wrote: >>>>>>> Hi Sowjanya, >>>>>>> >>>>>>> On 29/05/20 04:07, Sowjanya Komatineni wrote: >>>>>>>> Hi Luca, >>>>>>>> >>>>>>>> Quick question regarding IMX274 driver that was up streamed by you. >>>>>>> Well, to be fair I only added cropping and made some improvements. >>>>>>> >>>>>>>> Upstream IMX274 driver programs Y_OUT_SIZE correctly based on IMX274 >>>>>>>> datasheet and register mode table for Y_OUT_SIZE where it includes 6 >>>>>>>> ignored area of effective pixels + 8 effective margin for color >>>>>>>> processing pixels. >>>>>>>> >>>>>>>> So, Y_OUT_SIZE register value = height + 14 >>>>>>>> >>>>>>>> But somehow with this we are not seeing full frame on CSI. >>>>>>>> >>>>>>>> In our internal NVIDIA IMX274 driver, we are programming >>>>>>>> Y_OUT_SIZE to >>>>>>>> exact height Y_OUT_SIZE = height >>>>>>>> >>>>>>>> So for debug, followed the same and updated upstream IMX274 >>>>>>>> driver to >>>>>>>> program Y_OUT_SIZE = crop.height locally and I see all resolutions >>>>>>>> working fine with this. >>>>>>>> >>>>>>>> Checking with Sony on whats causing sensor not to send full frame >>>>>>>> when >>>>>>>> Y_OUT_SIZE is set to height + 14. >>>>>>>> >>>>>>>> But thought to check with you in parallel if there are any known >>>>>>>> issues >>>>>>> That's strange. Unfortunately I'm not using imx274 anymore since a >>>>>>> long >>>>>>> time and don't remember the details, but definitely I did test it >>>>>>> and if >>>>>>> there had been 14 missing lines I'm pretty sure I would have noticed. >>>>>>> >>>>>>> I'll see if I can remember anything useful, and in case I'll >>>>>>> update you. >>>>>>> I would be glad if you can update me on any findings too, maybe they >>>>>>> will help in understanding the problem better. >>>>>> The '+ 14' makes no sense. I wonder if this was perhaps to >>>>>> compensate for >>>>>> some problem in the bridge driver that this sensor was connected to. >>>>>> Which bridge driver did you use for testing? Do you remember where >>>>>> you got >>>>>> the '+ 14' from? >>>>> Hmm, this comes from the first version of this driver where Y_OUT_SIZE >>>>> was set to 0x87e (2160 + 14). This in turn comes from the datasheet >>>>> ('Register >>>>> Setting for Each Readout Drive Mode'). >>>>> >>>>> Looking at the "Detailed Specification of Each Mode" (page 63 in my >>>>> copy of >>>>> the datasheet) I see three additional parameters: "Front ignore area of >>>>> effective pixel", "Front effective margin for color processing" and >>>>> "Rear >>>>> effective margin for color processing", these are 6, 4 and 4, which >>>>> is a >>>>> total of 14. >>>>> >>>>> So I guess that's where the 14 comes from. >>>> Double-checked, and I agree. >>>> >>>>> Knowing with which bridge driver this was tested will definitely be >>>>> helpful. >>>> The design was based on a Xilinx zcu106 and the sensor output went into >>>> the Xilinx MIPI CSI-2 RX subsystem IP (currently being mainlined), an >>>> ISP IP and a Xilinx video DMA IP block, I think it was the "Video Frame >>>> Buffer Writer" IP. I did several experiments with similar setups, even >>>> with basic a Xilinx debayer+CCM in place of the ISP, and don't remember >>>> any problems with wrong lines. >>>> >>>> Wild guess: Sowjanya, are you using VFLIP? I never used that, but it >>>> might influence the order of lines processing somehow. >>> No I am not using VFLIP. >>> >>> Did quick experiment of keeping buffer as valid even in case of frame >>> buffer write timeout to see so far captured image and I see full >>> 3840x2160 image capture with both cases where Y_OUT_SIZE = height and >>> also with Y_OUT_SIZE = height + 14 >>> >>> Could be something during end of frame when using Y_OUT_SIZE = height >>> + 14 >>> >>> Provided all register settings being used to Sony and explained this >>> observation. Will update when I hear from them. >>> >>> Also will check how these 14 lines (ignore + color processing >>> effective margin) translates to CSI frame sent out.. >>> >> Hi Luca, >> >> Can you please provide exact set-fmt and crop settings you used for >> imx274 pipeline for 3840X2160 mode1 testing? > I don't remember much anymore. But I forgot to mention I [almost] always > worked with 1920x1080 capture, either with binning or with cropping. I > don't think the will change much, as the '+14' is equal in readout modes > 1 and 3 (1920p and 3840p modes at 10 bits). Can you try that nevertheless? Just to update, discussed on this issue with Sony. Sony confirmed Y_OUT_SIZE should be the height of effective image output from sensor which are actually the total lines sent over CSI to receiver. Receiver expected height should match this. So, Y_OUT_SIZE = crop height. Regarding WRITE_VSIZE Sony mentioned, it includes Vertical OB where OB is a shaded pixel for black level adjustment. When using this, it is highly recommended that ISP use the OB value to make black level adjustments. WRITE_VSIZE should be set to height + 8. Using height + 22 will not have any impact if we dont use ISP and this VOB is shaded pixel for black level adjustment where ISP need to use to make black level adjustment. I tried by changing driver to set WRITE_VSIZE = crop.height + 8 and Y_OUT_SIZE = crop.height for all supported resolutions and capture works fine without any issues. Thanks Sowjanya ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-06-23 17:24 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-29 2:07 IMX274 driver Sowjanya Komatineni 2020-05-31 21:56 ` Luca Ceresoli 2020-06-01 8:31 ` Hans Verkuil 2020-06-01 8:47 ` Hans Verkuil 2020-06-02 8:51 ` Luca Ceresoli 2020-06-02 14:17 ` Sowjanya Komatineni 2020-06-02 16:16 ` Sowjanya Komatineni 2020-06-02 20:08 ` Luca Ceresoli 2020-06-23 17:25 ` Sowjanya Komatineni
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).