RE: [RFC] passing bus/interface parameters from bridge driver to sub device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hans,

Thanks for looking into this...

>>
>> 1) I want to use v4l2_i2c_new_probed_subdev_addr() to load and probe the
>> the v4l2 sub-device from my vpfe capture driver. Currently the api's
>> available doesn't allow setting platform data in the client before the
>> sub-device's probe is called. I see that there is discussion about adding
>> i2c_board_info as an argument to the api. I would need this to allow
>> loading of sub-device from vpfe capture. I have seen patches sent by
>> Eduardo Valentin & Guennadi Liakhovetski addressing the issue. Do you
>> have any suggestions for use in my vpfe capture driver?
>
>As you have probably seen by now I've made changes to the v4l2 core that
>make it easy to use an i2c_board_info struct when creating a subdev. So as
>far as I can tell that solves this issue completely.
>
>The code is in my v4l-dvb-subdev tree.
>
[MK] Yes. I have been following this and will resolve this.
>> 2) I need a common structure (preferably in i2c-subdev.h for defining and
>> using bus (interface) parameters in the bridge (vpfe capture) and sub
>> device (tvp514x or mt9t031) drivers. This will allow bridge driver to
>> read these values from platform data and set the same in the vpfe capture
>> driver and sub device drivers. Since bus parameters such as interface
>> type (BT.656, BT.1120, Raw Bayer image data etc), polarity of various
>> signals etc are used across bridge and sub-devices, it make sense to add
>> it to i2c-subdev.h. Here is what I have come up with. If this support is
>> not already planned, I would like to sent a patch for the same.
>
>It makes sense to define a struct in v4l2-subdev.h and a core ops to set it
>(s_bus).
>
>However, I would pack it differently:
>
>struct v4l2_subdev_bus {
>	enum v4l2_subdev_bus_type type;
>	u8 width;
>	unsigned pol_vsync:1;
>	unsigned pol_hsync:1;
>	unsigned pol_field:1;
>	unsigned pol_pclock:1;
>};
>
[MK] Looks good to me. So is it up to the bridge and sub device to determine how they interpret the values of pol_xxx fields? Since same sub-device might work across multiple sub device, it is worth documenting them as given in my RFC. I would like to add one more field for data polarity :-
	unsigned pol_data:1; 

Will you take care of this yourself or expecting me to send a patch for the same?

Regards,
Murali
>It's more concise this way.
>
>Regards,
>
>	Hans
>
>> +/*
>> + * Some Sub-devices are connected to the bridge device through a bus
>> + * that carries the clock, vsync, hsync and data. Some interfaces
>> + * such as BT.656 carries the sync embedded in the data where as others
>> + * have seperate line carrying the sync signals. This structure is
>> + * used by bridge driver to set the desired bus parameters in the sub
>> + * device to work with it.
>> + */
>> +enum v4l2_subdev_bus_type {
>> +	/* BT.656 interface. Embedded syncs */
>> +	V4L2_SUBDEV_BUS_BT_656,
>> +	/* BT.1120 interface. Embedded syncs */
>> +	V4L2_SUBDEV_BUS_BT_1120,
>> +	/* 8 bit YCbCr muxed bus, separate sync and field id signals */
>> +	V4L2_SUBDEV_BUS_YCBCR_8,
>> +	/* 16 bit YCbCr bus, separate sync and field id signals */
>> +	V4L2_SUBDEV_BUS_YCBCR_16,
>> +	/* Raw Bayer data bus, 8 - 16 bit wide, sync signals  */
>> +	V4L2_SUBDEV_BUS_RAW_BAYER
>> +};
>> +
>> +/* Raw bayer data bus width */
>> +enum v4l2_subdev_raw_bayer_data_width {
>> +	V4L2_SUBDEV_RAW_BAYER_DATA_8BIT,
>> +	V4L2_SUBDEV_RAW_BAYER_DATA_9BIT,
>> +	V4L2_SUBDEV_RAW_BAYER_DATA_10BIT,
>> +	V4L2_SUBDEV_RAW_BAYER_DATA_11BIT,
>> +	V4L2_SUBDEV_RAW_BAYER_DATA_12BIT,
>> +	V4L2_SUBDEV_RAW_BAYER_DATA_13BIT,
>> +	V4L2_SUBDEV_RAW_BAYER_DATA_14BIT,
>> +	V4L2_SUBDEV_RAW_BAYER_DATA_15BIT,
>> +	V4L2_SUBDEV_RAW_BAYER_DATA_16BIT
>> +};
>> +
>> +struct v4l2_subdev_bus_params {
>> +	/* bus type */
>> +	enum v4l2_subdev_bus_type type;
>> +	/* data size for raw bayer data bus */
>> +	enum v4l2_subdev_raw_bayer_data_width width;
>> +	/* polarity of vsync. 0 - active low, 1 - active high */
>> +	u8 vsync_pol;
>> +	/* polarity of hsync. 0 - active low, 1 - active low */
>> +	u8 hsync_pol;
>> +	/* polarity of field id, 0 - low to high, 1 - high to low */
>> +	u8 fid_pol;
>> +	/* polarity of data. 0 - active low, 1 - active high */
>> +	u8 data_pol;
>> +	/* pclk polarity. 0 - sample at falling edge, 1 - sample at rising
>edge
>> */ +	u8 pclk_pol;
>> +};
>> +
>> Murali Karicheri
>> email: m-karicheri2@xxxxxx
>>
>> --
>> 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
>
>
>
>--
>Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
>--
>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

--
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

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux