Date:   Thu, 16 May 2019 22:44:18 +0200
From:   "niklas.soderlund@...natech.se" <niklas.soderlund@...natech.se>
To:     "Rodin, Michael (Ferchau; ADITG/ESM1)" <mrodin@...adit-jv.com>
Cc:     "kieran.bingham@...asonboard.com" <kieran.bingham@...asonboard.com>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "michael@...in.online" <michael@...in.online>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>
Subject: Re: [PATCH] media: i2c: adv748x: initialize bit 7 of
 csi_tx_top_reg_1f

Hi Rodin,

On 2019-05-16 14:24:13 +0000, Rodin, Michael (Ferchau; ADITG/ESM1) wrote:
> Hi Kieran and Niklas,
> 
> thank you for your responses!
> 
> > Hi Kieran and Michael,
> >
> > On 2019-05-10 17:25:24 +0100, Kieran Bingham wrote:
> > <snip>
> >
> > >
> > > Niklas, how does RCar-CSI determine the top/bottom sequence?
> >
> > That patch just got merged in the media tree a few days ago,
> >
> >     9f7983bdc4925ae2 ("media: rcar-csi2: Propagate the FLD signal for NTSC
> > and PAL")
> >
> > >
> > > Do we have field inversion currently? (or one which is perhaps swapped
> > > somewhere along the pipeline in rcar-vin?)
> > >
> >
> > I'm not sure which tree this patch is developed on but Steve Longerbeam
> > posted a RFC which IMHO had the fields inverted, there was a discussion in
> his
> > thread [1] where I tried to get to the bottom of the issue. My conclusions
> > there might be wrong due to the issues addressed in this patch.
> >
> > Michael: Did you have Steve's patch in your tree when testing this?
> >
> > 1. https://patchwork.kernel.org/patch/10904263/
> >
> > --
> > Regards,
> > Niklas Söderlund
> 
> I had another version of Steve's patch when testing, but the FLD_NUM
> setting was still the opposite compared to 9f7983bdc4925ae2
> ("media: rcar-csi2: Propagate the FLD signal for NTSC and PAL").
> I could send all patches from the private pull request which Steve Longerbeam
> has created for ADIT if you want to better understand my test results,
> but probably they can not be applied to the current mainline development tree.
> The patch for adv748x I used for testing looks a bit different as well,
> so it can be applied to the tree used by ADIT. But the functionality
> is the same (I can provide the patch as well if it is required.).
> There are also concerns regarding VnMC.FOC bit (I tested V4L2_FIELD_INTERLACED mode 
> and in my tests I figured out, that this bit does not exactly do
> what the Renesas Hardware Manual describes and should be always set to 0
> regardless whether NTSC or PAL are used. But I had only Raspberry Pi as
> NTSC test source and no additional NTSC camera for verification,
> so the results may be not reliable.).

Interesting, I will add VnMC.FOC to my list of things to look into.

> 
> 
> Niklas, in [1] you mentioned that you could read the WC counter (which is in
> fact the frame number in case of frame start packets) in the interrupt
> INT_FSFE and it would start at 0. Could you please share the patch you used
> for reading?

I'm sorry I no longer have that code. It was a small hack thrown 
together quickly. Idea was to read the register from the interrupt 
handler and printk() it. Not the best of methods but at the time it 
confirmed my theory of how it should work. It might be that I have drawn 
some premature conclusions.

> As Steve Longerbeam mentioned in [2], this would be a CSI spec 
>violation, which he has cited in the commit message of his RFC 
>patch[3]. It's important to mention that the violation would be on the 
>side of the adv748x chip (adv7482 on my Salvator-X board), because it 
>creates the Frame Start packets. And according to the description of 
>the FRAMENUMBER_INTERLACED bit in [4] (page 193), adv7481 should always 
>send the
> "1,2,1,2..." CSI frame number sequence (I could  not find a generic document
> valid for all adv748x but I doubt that it would be  different there.).
> So starting with CSI frame number 0 would even violate specification in it's 
> own data sheet. Another possibility could also be a silicon bug in rcar CSI interface,
> which would decrement the WC value by one. 

A more likely cause is that my way of testing was flawed ;-)

I will add this to my growing pile of things to look into. I don't know 
when I will find the time. If you got time and figure out a method to 
verify the settings in rcar-csi2 together with a good video source 
please post patches ;-) It would be great if this could be figured out 
together with the VnMC.FOC issue mentioned above. If you should happen 
to work on it you might be interested in the patches recently merged in 
the media-tree which adds the interrupt handler to rcar-csi2 making 
inspection hacks easier to add on top.

One idea I have is to use a programmable video source and "display" 
frames for capture where one can distinguish top/bottom (different 
colors for each line for example) fields on the capture side and somehow 
automate regression testing. I have had this plan for some years now and 
I still use a old video game system as my test rig so don't hold your 
breath ;-)

> 
> 
> [1] https://patchwork.kernel.org/patch/10904263/#22594157
> [2] https://patchwork.kernel.org/patch/10904263/#22594563
> [3] https://patchwork.kernel.org/patch/10904263
> [4] https://www.analog.com/media/en/technical-documentation/user-guides/ADV7481_UG-747.pdf
> 
> Regards,
> Michael

-- 
Regards,
Niklas Söderlund

Powered by blists - more mailing lists