On Tue, Oct 11, 2011 at 12:29 PM, Enrico <ebutera@xxxxxxxxxxxxxxxx> wrote:
> On Mon, Oct 10, 2011 at 8:18 PM, Javier Martinez Canillas
> <martinez.javier@xxxxxxxxx> wrote:
>> On Mon, Oct 10, 2011 at 7:09 PM, Enrico <ebutera@xxxxxxxxxxxxxxxx> wrote:
>>> On Mon, Oct 10, 2011 at 6:53 PM, Javier Martinez Canillas
>>> <martinez.javier@xxxxxxxxx> wrote:
>>>> On Mon, Oct 10, 2011 at 6:34 PM, Enrico <ebutera@xxxxxxxxxxxxxxxx> wrote:
>>>>> Ok, i made it work. It was missing just the config_outlineoffset i
>>>>> wrote before and a missing FLDMODE in SYNC registers.
>>>>>
>>>>
>>>> Great, do you get the ghosting effect or do you have a clean video?
>>>
>>>
>>> Unfortunately i always get the ghosting effect. But this is something
>>> we will try to fix later.
>>>
>>>
>>
>> Agree, we should try to get some code upstream to add interlaced video
>> and bt.656 support and fix the artifact later.
>>
>>>>> Moreover it seems to me that the software-maintained field id
>>>>> (interlaced_cnt in Javier patches, fldstat in Deepthy patches) is
>>>>> useless, i've tried to only use the FLDSTAT bit from isp register
>>>>> (fid) in vd0_isr:
>>>>>
>>>>> if (fid == 0) {
>>>>> restart = ccdc_isr_buffer(ccdc);
>>>>> goto done;
>>>>> }
>>>>>
>>>>> and it works. I've not tested very long frame sequences, only up to 16
>>>>> frames. The only issue is that the first frame could be half-green
>>>>> because a field is missing.
>>>>>
>>>>
>>>> Yes, when I tried Deepthy patches I realized that the fldstat was not
>>>> in sync with the frames, but probably I made something wrong.
>>>
>>>
>>> I had noticed the same thing, but now i tested it and it is ok, maybe
>>> my fault too.
>>>
>>>
>>>> We had the same problem with the hal-green frame. Our solution was to
>>>> synchronize the CCDC with the first even field looking at fdstat on
>>>> the VD1 interrupt handler and forcing to start processing from an ODD
>>>> sub-frame.
>>>
>>> Thinking more about it, it's ugly to have that half-green video frame
>>> even if it's just one. It's better to keep your or Deepthy solution.
>>>
>>> Enrico
>>>
>>
>> Well, that is something that can be fixed later also. Can you send to
>> the list your patches? So, Laurent, Sakari and others than know more
>> about the ISP can review it. I hope they can find the cause for the
>> artifact.
>
> I'm attaching some fixes (taken from Deepthy patches) to be applied on
> top of your v2 patches, with those i can grab frames but i only get
> garbage.
>
Yes, I still couldn't find time to try that patch on real hardware, sorry.
> I think the problem is that it always hits this in ccdc_isr_buffer:
>
> if (ccdc_sbl_wait_idle(ccdc, 1000)) {
> dev_info(isp->dev, "CCDC won't become idle!\n");
> goto done;
> }
>
> so the video buffer never gets updated.
>
> At this point i think it is better to go on with my port of Deepthy
> patches and try to solve the ghosting issues, maybe with your fixes
> about buffer decoupling.
>
I second you on that. Deepthy patches make two changes to the ISP in
order to support BT.656:
1- Add support to configure the bridge with UYVY8_2X8 format.
2- Add support to interlaced video mode.
Looking at your fixes taken from Deepthy I see code that still make
(1). I understood from Laurent's comments that its oma3isp-yuv branch
already made (1), but he also said he didn't try on hardware though.
I think the best approach is to resend Deepthy patches again on top of
Laurent's yuv branch so it can be reviewed. Probably Laurent will want
then to split the patch in two, one to fix the UYVY8_2X8 support and
another one that adds support to interlaced video mode.
> Laurent, what do you suggest to do?
>
> Enrico
>
Best regards,
--
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
--
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
