Hi. On Thu, Nov 8, 2012 at 1:57 AM, Sylwester Nawrocki <sylvester.nawrocki@xxxxxxxxx> wrote: > On 11/06/2012 10:34 PM, Andrey Gusakov wrote: >> >> Hi. >> >>> Does the sensor still hang after 0x2f is written to REG_GRCOM instead ? >> >> Work! >> I'm looking at drivers/media/usb/gspca/m5602/m5602_ov9650.h >> It use significantly different init sequence. Some of settings >> described in Application note for ov9650, some look like magic. > > > I guess there are many ways the sensor can be configured initially. > I'd like to keep this initialization sequence as thin as possible, > and to move relevant settings to corresponding v4l2 controls. > Then after v4l2_control_handler_setup() is called, following the initial > register list write, the sensor would be configured into some known > state. I realize it might be more difficult in practice than it sounds > now. :-) > > >>> Do you have CONFIG_PM_RUNTIME enabled ? Can you try and see it works >>> if you enable it, without additional changes to the clock handling ? >> >> Work. With CONFIG_PM_RUNTIME and without enabling CLK_GATE at probe. > > > Ok, thanks. I will add the missing CONFIG_PM_RUNTIME dependency in Kconfig. > The driver has to have PM_RUNTIME enabled since on s3c64xx SoCs there are > power domains and the camera power domain needs to be enabled for the CAMIF > operation. The pm_runtime_* calls in the driver are supposed to ensure that. > I wonder why it works for you without PM_RUNTIME, i.e. how comes the power > domain is enabled. It is supposed to be off by default. DS says that all power domaint are on after reset. My bootloader did not switch then off. So when linux start everything is on. CONFIG_PM_RUNTIME was disabled, so nothing switch them off in linux too. >>> I hope to eventually prepare the ov9650 sensor driver for mainline. Your >>> help in making it ready for VER=0x52 would be very much appreciated. :-) >> >> I'll try to helpful. >> >> >>>> Next step is to make ov2460 work. >>> >>> For now I can only recommend you to make the ov2460 driver more similar >>> to the ov9650 one. >> >> Thanks, I'll try. >> >> P.S. I add support of image effects just for fun. And found in DS that >> s3c2450 also support effects. It's FIMC in-between of 2440 and >> 6400/6410. Does anyone have s3c2450 hardware to test it? > Patches adding image effect are welcome. I'm bit to busy to play with these > things, other than I don't have hardware to test it. > I wasn't really aware of CAMIF in s3c2450. I think a separate variant data > structure would need to be defined for s3c2450. If anyone ever needs it > it could be added easily. For now I'll pretend this version doesn't exist. > :-) Attached. I often get "VIDIOC_QUERYCAP: failed: Inappropriate ioctl for device" or "system error: Inappropriate ioctl for device" Is it because of not implemented set/get framerate func? How this should work? I mean framerate heavy depend of sensor's settings. So set/get framerate call to fimc should get/set framerate from sensor. What is mechanism of such things? And same question about synchronizing format of sensor and FIMC pads. I make ov2640 work, but if did not call media-ctl for sensor, format of FIMC sink pad and format of sensor source pad different. I think I missed something, but reading other sources did not help. Thanks. Best regards.
Attachment:
0001-S3C-FIMC-add-effect-controls.patch
Description: Binary data
