Kim HeungJun wrote: > Hi Sakari, Hi, > 2011. 3. 30., ìí 8:37, Sakari Ailus ìì: > >> Kim, HeungJun wrote: >>> Hi Sakari, >> >> Hi HeungJun, >> >>> 2011-03-29 ìí 11:41, Sakari Ailus ì ê: >>>> Kim, HeungJun wrote: >>> [snip] >>>>> I think it's not different method to turn on/off, whatever the mode name is. >>>>> But, the mode name DEDICATED is look more reasonable, because the reason >>>>> which is devided FLASH and TORCH in the mode, is why only power up the led, >>>>> not sensor. >>>> >>>> Sensor? Is the flash part of the sensor module for you? >>> Yes. The flash is a part of the sensor module(our case like M-5MOLS). >>> Precisely, the sensor internal core's gpio pin is connected with >>> external Flash LED, and the control master is the sensor internal core. >>> For turnning on the Flash LED, we should use I2C register access. >>> So, I think it's exactly matches with hardware strobe as you metioned. >> >> Ok, I think I'm lost now. :-) >> >> What signals are sent from sensor to flash in both torch and flash cases? > I guess the signal probably is just continuous repetition High/Low like PWM signal, > which is generated by the core of sensor module. Although I don't check what signal > it is, it's very possible. Because it's the only way to be able to control intensity of Flash. > > So, I think the torch and flash case is the same way or signal in this case. So... to summarise, the sensor determines the flash power by providing the flash controller a pwm signal both in flash and torch modes, if I understand correctly? This sounds like a quite low level control. Is the flash controller still an I2C device? ... >>> So, I suggesst that, if we can not give to users(of course, this user >>> want to use only flash function, not the camera) proper method usage >>> (openning the videonode for using flash), let's express that the camera >>> flash is used in the DEDICATED MODE now, as the enumeration name DEDICATED. >> >> No. The video nodes should not be involved since they are related to the >> bridge (ISP) which is not needed to use the flash. Assuming that this is >> the situation. >> >> This is how the use case should go: >> >> 1. open subdev node, e.g. /dev/v4l-subdev0, which is the flash >> (flash controller powered on) >> 2. VIDIOC_S_CTRL: V4L2_CID_FLASH_LED_MODE, V4L2_FLASH_LED_MODE_TORCH >> (flash is on now) >> 2. VIDIOC_S_CTRL: V4L2_CID_FLASH_LED_MODE, V4L2_FLASH_LED_MODE_NONE >> (flash is off now) >> 3. close the file handle >> (flash controller powered off) > Probably you mean media controller framework is based on. I get it. :) > >> >>> But, I think it might be not a big issue. So, any others don't comment at this, >>> it's ok for me to pass this naming issue. >>> >>> I can see this API is very cool for camera man just like me. >> >> Thanks! >> >>> plus: actually I have the one of N-series, N810. So, the omap3isp is available to >>> activate this device, not even it's cpu is omap3? Just question. >> >> The N810 has OMAP 2420 which has a completely different camera bridge, >> and there's no flash. The drivers for the camera in N810 are omap24xxcam >> and tcm825x. The drivers are functional in mainline but the platform >> data is missing, as well as the CBUS driver. This work is queued but >> unknown when there's time for this. > Thanks for plus reply. I've tested tony's patch for booting the ubuntu long time ago, > but I'm sure this gadget is good device. I've never tried it out with Ubuntu. Probably that 128 MiB of RAM is slightly small for Ubuntu. ;-) -- Sakari Ailus sakari.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx -- 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
