On Tue, Jun 16, 2009 at 1:01 AM, Karicheri,
Muralidharan<m-karicheri2@xxxxxx> wrote:
>>> +
>>> +struct v4l2_subdev_bus {
>>> + enum v4l2_subdev_bus_type type;
>>> + u8 width;
>>> + /* 0 - active low, 1 - active high */
>>> + unsigned pol_vsync:1;
>>> + /* 0 - active low, 1 - active high */
>>> + unsigned pol_hsync:1;
>>> + /* 0 - low to high , 1 - high to low */
>>> + unsigned pol_field:1;
>>> + /* 0 - sample at falling edge , 1 - sample at rising edge */
>>> + unsigned pol_pclock:1;
>>> + /* 0 - active low , 1 - active high */
>>> + unsigned pol_data:1;
>>> +};
>>
>>As for the pins/signals, I wonder if per-signal polarity/edge is
>>enough. If this is going to be used by/replace the soc_camera
>>interface then we also need to know if the signal is present or not.
>>For instance, I have a SuperH board using my CEU driver together with
>>one OV7725 camera or one TW9910 video decoder. Some revisions of the
>>board do not route the field signal between the SuperH on-chip CEU and
>>the TW9910. Both the CEU and the TW9910 support this signal, it just
>>happen to be missing.
>
> [MK]In that case can't the driver just ignore the field polarity? I assume that drivers implement the parameter that has support in hardware. So it is not an issue.
No, because the same driver runs on hardware that also has the field
signal. So we need to be able to give information about which signals
that the board actually implement. We already do this with the
soc_camera framework and it is working just fine.
Thanks for your comment!
/ magnus
--
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
