Santiago,
<Snip>
>> - So many modes available. But only 2 are added to vpfe capture. What are
>the requirements here? If you need VESA timings and video (Analog &
>Digital) timings, then it make sense to support all modes that are
>supported by the chip. In that case you need to add the timing for this in
>the vpfe capture driver as well. Also input selection from all these
>sources should be possible. But at least from DM365 and DM6467 perspectives,
>I would like to see support for 720p 50/60, 1080i 50/60 & 1080p 50/60 for
>HDTV and also 480p/576p for SDTV. Please clarify.
>>
>>
>For the specific case of modes, the main goal was to match as closely as
>possible the tvp7002 specification on modes it provides but I'd like to
>hear from the expectations of the community on which modes are
>prioritary. I will add specific support for those above mentioned.
[MK] Once this is submitted to community anyone can add modes as needed. So I
suggest you focus on the above modes only for the initial patch you are sending
to community.
>>>
>>> +// According to TI's tvp7002 datasheet
>>> +static struct tvp7002_platform_data tvp7002_pdata = {
>>> + .clk_polarity = 0,
>>> + .hs_polarity = 1,
>>> + .vs_polarity = 1
>>> +};
>>>
>>
>>
>> [MK] I don't see it being used in your driver TVP7002 driver. In probe()
>these values are to be read and used for setting polarities as needed. This
>will allow for customization in individual boards. So also add fid polarity
>and clock polarity which are also configurable in the chip.
>>
>It is required by vpfe_capture for setting up polarities. Will add fid
>and clocl polarity.
[MK] vpfe capture will not consume this, but the sub device does. It gets it
as platform data. So you need to set polarity in the sub device based on this.
Checkout tvp514x for usage.
>> [MK]You have used many modes in your driver. Why only these used here.
>What is V4L2_STD_725_50 & V4L2_STD_825_60? Whatever modes required as per
>the requirement should be added here so that vpfe capture will be able to
>support it while doing s_std().
>>
>I will add the other modes as suggested. In the case of the mode
>definitions, my impression was that there existed a convention since the
>other modes (V4L2_STD_525_60 and V4L2_STD_625_50) provide no immediate
>information upon their names on resolution, only frequency. Should they
>be redefined according to these criteria?
[MK] Please focus on the list of modes I have provided. We can always add other
modes as needed later. For TI/Ridgerun requirement, the above mode list will
suffice (unless Ridgerun has additional requirement that I am
not aware of). BTW, I have added a patch for the standards definition for
drivers internal development. Sneha will be sending you this patch. This
defines all modes for internal development and will be called
include/media/davinci/videohd.h. Include this file in the source code.
Note that this code can't be submitted to upstream.
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
