• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 2881 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM5728: Writeback 1080p to 1080i conversion

kim yoochang
Intellectual 720 points

Part Number: AM5728

Tool/software: Linux

Hello,
I am using AM5728 PSDK 04.00.00.04.

We specify the dual camera, sample source (modetest.c) and currently WB 1920 x 1080p HDMI to the LCD.
ioctl (VIDIOC_STREAMON, VIDIOC_STREAMOFF, VIDIOC_DQBUF, VIDIOC_QBUF ...)
1080p has no problem.

but, if 1080p HDMI is changed to 1080i, WB, a lot of error messages occurred
Although it is displayed on the LCD on the WB screen, it is not a general screen.

An error message is attached.

==============================================

[49.252115] omap_crtc_error_irq: 50036 callbacks suppressed
[49.257715] [drm:omap_crtc_error_irq] *ERROR* tv: errors: 00008000
[49.263955] [drm:omap_crtc_error_irq] *ERROR* tv: errors: 1400a0a2
[49.270172] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.274575] [drm:omap_crtc_error_irq] *ERROR* tv: errors: 04008008
[49.280783] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.285449] [drm:omap_crtc_error_irq] *ERROR* tv: errors: 00008000
[49.291684] [drm:omap_crtc_error_irq] *ERROR* tv: errors: 04008000
[49.297894] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.302299] [drm:omap_crtc_error_irq] *ERROR* tv: errors: 1000a0aa
[49.308517] [drm:omap_crtc_error_irq] *ERROR* tv: errors: 04008000
[49.314723] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.319123] [drm:omap_crtc_error_irq] *ERROR* tv: errors: 1000a0a6
[49.325356] [drm:omap_crtc_error_irq] *ERROR* tv: errors: 04008000
[49.331562] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.335960] [drm:omap_crtc_error_irq] *ERROR* tv: errors: 1000a0aa
[49.342193] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.352734] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.369385] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.386066] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.402717] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.419399] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.436053] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.452735] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.469387] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.486067] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.502718] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.519398] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.536051] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.552733] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.569387] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.586068] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.602719] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.619402] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.786066] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.802718] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.819399] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.836052] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.852732] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.869386] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.886065] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.902718] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.919400] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.936051] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.952732] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.969386] omapwb-cap: WB: WBUNCOMPLETEERROR
[49.986068] omapwb-cap: WB: WBUNCOMPLETEERROR
....
...
..

==============================================

This problem also occurred in PSDK 03.01.00.06 version.
At this time, we solved the problem by modifying wbcap_handle_vsync (struct wbcap_dev * dev) of omap_wb_cap.
However, the same solution is not applied in PSDK 04.00.00.04 version currently in use.
Our customers want the 1080i.

please, I want you to help me.
Provide cases where more information is needed.
Thank you!

  • 0
    TI__Guru 55345 points
    Hello aupers,

    Video expert has been notified. The answer will be posted here.

    Best regards,
    Kemal
  • 0 in reply to Kemal R. Shakir
    TI__Mastermind 22946 points
    The WB capture is not tested with interlace input, so there may be issues with it. The fix that you had done on PLSDK 3.1 should be applicable to PLSDK 4.0 but might need to be ported as the dss/drm subsystem has changed quite a bit between these two versions.

    Please share with us the patch that you applied before.
  • 0 in reply to Manisha Agrawal
    Intellectual 720 points
    hello, manisha

    From 3.1 to 4.0, we updated the PLSDK,
    It turned out that many parts of dss / drm subsystem have changed.
    We hoped that the problem would be included in that part.

    In PLSDK 3.1 our solution was simple.

    gpu / drm / omapdrm / omap_wb_cap.c
    void Called by wbcap_handle_vsync ()
    We changed the values of @time and @tim in hrtimer_start_range_ns ().

    hrtimer_start_range_ns (& dev-> wbgo_timer, 3,1000000, HRTIMER_MODE_REL)
    => hrtimer_start_range_ns (& dev-> wbgo_timer, 3, 100000, HRTIMER_MODE_REL)
    or hrtimer_start_range_ns (& dev-> wbgo_timer, 0, 100000, HRTIMER_MODE_REL)

    Currently, the corresponding solution is not applied in PLSDK 4.0.
    I hope this helps.

    We need to interlace WB.
    Our customers are desperately wanting this.

    thank you.
  • 0 in reply to kim yoochang
    TI__Mastermind 22946 points

    Please try attached patch and let us know if you see any further issues. 

    LCPD-10921.zip

  • 0 in reply to Manisha Agrawal
    Intellectual 720 points

    Thanks for the patch, We applied it.
    The omap_drm error message is no longer displayed.
    This seems to be effective.

    But I found one problem.
    WB is not a full screen, but height is displayed in a size of 1/2.

    We debug this problem.
    I have modified some code.

    drivers/gpu/drm/omapdrm/dss/dispc.c
    (0002-drm-omap-fix-WB-height-with-interlace.patch)
    ...

    - if (ilace && height == out_height)
    -  fieldmode = true;

    ...

    I did not apply that part.
    Then WB was displayed in full screen.

    We can not know that this method is a general way.
    I would like assistance on this issue.

    Thank you.

  • 0 in reply to kim yoochang
    TI__Mastermind 22946 points

    The interlace field height is expected to be half of frame height, so expected WB capture for 1080i is 540. Do you see 270 as capture height with the patch that I shared?

  • 0 in reply to Manisha Agrawal
    Intellectual 720 points

    We have checked again.

    The height of wb was 540.

    This was the correct behavior.

    We had to scale up and Display this.

    Thank you for your support.

  • 0 in reply to Manisha Agrawal
    Intellectual 720 points

    hello, manisha

    There is a new problem about the patch(LCPD-10921.zip) you provided.

    The offset of the frame received from the WB is not the same.

    When outputting the same screen to WB, the screen is not interrupted.

    Data continuously received from WB was saved as an image.

     frame_1

    frame_2

    There seems to be a problem with the offset when combining odd data / even data with DSS.


    Is there something that will confirm this problem?

    Thank you.

  • 0 in reply to kim yoochang
    TI__Mastermind 22946 points
    Currently, the capture write back solution doesn't detect which field is which. I have taken note of above issue that you reported. We shall look into it when we add feature for field detection. Currently I do not have any timeline to commit for this.
  • 0 in reply to Manisha Agrawal
    TI__Mastermind 22946 points

    Hi Aupers,

    Please find attached  the patch which notifies user if the field is TOP or bottom. We do not see any issue with field offset. Please try this and let us know if it fixes your issue.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/7776.0001_2D00_drm_2D00_omap_2D00_omap_5F00_wb_5F00_cap_2D00_Add_2D00_support_2D00_for_2D00_interlace_2D00_field.patch

    Regards,

    Manisha

  • 0 in reply to Manisha Agrawal
    Intellectual 720 points

    hello, Manisha

    Thanks for the patch.

    We tested it with this.

    It got better than before, but sometimes the screen shook.

    I set 'V4L2_FIELD_ALTERNATE' in the field options in my application.

    We modified a few sources.(7776.0001-drm-omap-omap_wb_cap-Add-support-for-interlace-field.patch)

    =======================================================

    omap_wb_cap_patch.c

    void wbcap_irq(struct wbcap_dev *dev, u32 irqstatus)

    {

        if (is_input_irq_vsync_set(dev, irqstatus)) {

           if (dev->field != V4L2_FIELD_NONE) {

             if (irqstatus & DISPC_IRQ_EVSYNC_EVEN)

                dev->field = V4L2_FIELD_BOTTOM;

             else if (irqstatus & DISPC_IRQ_EVSYNC_ODD)

                dev->field = V4L2_FIELD_TOP;

        }

             wbcap_handle_vsync(dev);

       }

    }

    =>

    void wbcap_irq(struct wbcap_dev *dev, u32 irqstatus)

    {

       if (is_input_irq_vsync_set(dev, irqstatus)) {

          if (dev->field != V4L2_FIELD_NONE) {

             if (irqstatus & DISPC_IRQ_EVSYNC_EVEN)

                dev->field = V4L2_FIELD_BOTTOM;

             else if (irqstatus & DISPC_IRQ_EVSYNC_ODD) {

                dev->field = V4L2_FIELD_TOP;

                wbcap_handle_vsync(dev);

             }

          }

       }

    }

    =======================================================

    The problem of screen shaking in this way is resolved.

    Is it appropriate for this?

    Thank you.

  • 0 in reply to kim yoochang
    TI__Mastermind 22946 points
    It doesn't appear to us that changes you made should help. Please help us understand your issue better.

    What kind of screen shaking do you see? How do we reproduce it at our end? Are you talking about the HDMI display or are talking about the captured data. If later , can you share the data that shows the shaking?