On Mon, 2 Feb 2009, morimoto.kuninori@xxxxxxxxxxx wrote: > > > + value |= common_flags & SOCAM_FLDPOL_ACTIVE_LOW ? 1 << 16 : 0; > > > value |= common_flags & SOCAM_VSYNC_ACTIVE_LOW ? 1 << 1 : 0; > > > value |= common_flags & SOCAM_HSYNC_ACTIVE_LOW ? 1 << 0 : 0; > > > value |= buswidth == 16 ? 1 << 12 : 0; > > > > Why are you basing your decision to use active low or high level of the > > Field ID signal upon the platform data? Doesn't it depend on the > > configuration of the connected device, and, possibly, an inverter between > > them? So, looks like it should be handled in exactly the same way as all > > other signals - negotiate with the connected device (sensor / decoder / > > ...) and apply platform-defined inverters if any? > > Hmmm. > > The soc_camera framework supports automatic negotiation > for some type of option. > But it doesn't include board configuration. > > When board doesn't support Field ID signal, > we will have to modify driver though camera and host support it. Aha, I didn't realise that the Field ID signal was optional. If it is so, then yes, you need a platform flag for it, but not for polarity, but for availability. And if it is available, connected, and used, then you should negotiate its polarity with the camera driver. Makes sense? > This is the reason. > > I think bus width and field ID are depend on board configuration. > # May be camera strobe. but I'm not sure Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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
