2011/3/30 Bastian Hecht <hechtb@xxxxxxxxxxxxxx>: > 2011/3/30 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>: >> Hi Bastian, >> >> On Wednesday 30 March 2011 11:41:44 Bastian Hecht wrote: >>> 2011/3/29 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>: >>> > On Friday 25 March 2011 13:34:10 Bastian Hecht wrote: >>> >> 2011/3/24 Bastian Hecht <hechtb@xxxxxxxxxxxxxx>: >>> >> > 2011/3/24 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>: >>> >> >> On Thursday 24 March 2011 10:59:01 Bastian Hecht wrote: >>> >> >>> 2011/3/22 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>: >>> >> >>> > On Tuesday 22 March 2011 17:11:04 Bastian Hecht wrote: >>> >> >>> >> Hello omap isp devs, >>> >> >>> >> >>> >> >>> >> maybe you can help me, I am a bit desperate with my current cam >>> >> >>> >> problem: >>> >> >>> >> >>> >> >>> >> I use a ov5642 chip and get only 0x55 in my data output when I >>> >> >>> >> use a camclk > 1 MHz. With 1 MHz data rate from the camera chip >>> >> >>> >> to the omap all works (well the colorspace is strange - it's >>> >> >>> >> greenish, but that is not my main concern). >>> >> >>> >> I looked up the data on the oscilloscope and all flanks seem to >>> >> >>> >> be fine at the isp. Very clear cuts with 4 MHz and 10MHz. Also >>> >> >>> >> the data pins are flickering fine. Looks like a picture. >>> >> >>> >> >>> >> >>> >> I found that the isp stats module uses 0x55 as a magic number but >>> >> >>> >> I don't see why it should confuse my readout. >>> >> >>> >> >>> >> >>> >> I use 2592x1944 raw bayer output via the ccdc. Next to the >>> >> >>> >> logical right config I tried all possible configurations of >>> >> >>> >> vs/hs active high and low on camera and isp. The isp gets the vs >>> >> >>> >> flanks right as the images come out in time (sometimes it misses >>> >> >>> >> 1 frame). >>> >> >>> >> >>> >> >>> >> Anyone of you had this behaviour before? >>> >> >>> > >>> >> >>> > How do you capture images ? yavta will fill buffers with 0x55 >>> >> >>> > before queueing them, so this might indicate that no data is >>> >> >>> > written to the buffer at all. >>> >> >>> >>> >> >>> Yes I use yavta. So what does that all mean? >>> >> >> >>> >> >> It means that the ISP doesn't write data to the buffer. I have no >>> >> >> idea why. >>> >> >>> >> This simple and clear statement directly led me to the problem :) >>> >> >>> >> There was no cam_wen (write enable) pin on both my camera boards. The >>> >> ISP on the other hand is configured by default to expect it. So I only >>> >> captured images when my data lanes luckily pulled up the omap wen pin >>> >> by induction. >>> >> >>> >> In ccdc_config_sync_if() I added: >>> >> >>> >> /* HACK */ >>> >> printk(KERN_ALERT "Disable wen\n"); >>> >> syn_mode &= ~ISPCCDC_SYN_MODE_WEN; >>> >> >>> >> So is this something to add to the platform data? I can prepare my >>> >> very first kernel patch :) >>> > >>> > The WEN bit controls whether the CCDC module writes to memory or not. >>> > It's not supposed to interact with the external cam_wen signal. If you >>> > clear the WEN bit, the CCDC is supposed not to write data to memory at >>> > all. >>> > >>> > What you might need to check is the EXWEN bit in the same register. It >>> > controls whether the CCDC uses the cam_wen signal or not. The EXWEN bit >>> > should already be set to zero by the driver though. >>> > >>> > Does clearing the WEN bit fix your issue ? >>> >>> Hi Laurent, >>> >>> As I remember (I currently haven't the datasheet available) the wen signal >>> is an input from the camera >> >> That's correct. >> >>> and the SYN_MODE_WEN makes check this signal. >> >> According to the TRM, SYN_MODE_EXWEN control whether the cam_wen signal is >> used or not, and SYN_MODE_WEN controls whether the CCDC captures data to >> memory or not. >> >>> Disabling the SYN_MODE_WEN solved my problem and I can reliably read images >>> with 24 MHz datarate on the parallel bus. Artefacts are gone that I had >>> before with 1 MHz, too. >> >> If you capture data at the CCDC output, clearing SYN_MODE_WEN is supposed to >> disable capture completely. Could you double-check your modifications ? > Hi Laurent, > > I fetched the documentation and see what you mean.Doesn't make much > sense. I'll double-check soon. Hi, when I wanted to try out the WEN bit I updated to the newest kernel head. It indeed works now whether I disable or enable the SYN_MODE_WEN. So the error must have been eliminated by other patches in the meantime. best regards, Bastian > regards, > > Bastian > > > >> -- >> Regards, >> >> Laurent Pinchart >> > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
