+ MM Team. On 18/07/18 09:55, Laurent Pinchart wrote: > Hi Kieran, > > On Tuesday, 17 July 2018 23:32:56 EEST Kieran Bingham wrote: >> On 17/07/18 14:51, Laurent Pinchart wrote: >>> On Monday, 16 July 2018 20:20:30 EEST Kieran Bingham wrote: >>>> On 24/05/18 12:50, Laurent Pinchart wrote: >>>>> On Thursday, 3 May 2018 16:36:22 EEST Kieran Bingham wrote: >>>>>> Use the newly exposed VSP1 interface to enable interlaced frame support >>>>>> through the VSP1 lif pipelines. >>>>> >>>>> s/lif/LIF/ >>>> >>>> Fixed. >>>> >>>>>> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@xxxxxxxxxxxxxxxx> >>>>>> --- >>>>>> >>>>>> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 + >>>>>> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +++ >>>>>> 2 files changed, 4 insertions(+) >>>>>> >>>>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c >>>>>> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index >>>>>> d71d709fe3d9..206532959ec9 >>>>>> 100644 >>>>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c >>>>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c >>>>>> @@ -289,6 +289,7 @@ static void rcar_du_crtc_set_display_timing(struct >>>>>> rcar_du_crtc *rcrtc) >>>>>> >>>>>> /* Signal polarities */ >>>>>> value = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0) >>>>>> >>>>>> | ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? DSMR_HSL : 0) >>>>>> >>>>>> + | ((mode->flags & DRM_MODE_FLAG_INTERLACE) ? DSMR_ODEV : 0) >>>>> >>>>> How will this affect Gen2 ?. >>>> >>>> The bit is documented identically for Gen2. Potentially / Probably it >>>> 'might' reverse the fields... I'm not certain yet. I don't have access >>>> to a Gen2 platform to test. >>>> >>>> I'll see if this change can be dropped, but I think it is playing a role >>>> in ensuring that the field detection occurs in VSP1 through the >>>> VI6_STATUS_FLD_STD() field. (see vsp1_dlm_irq_frame_end()) >>>> >>>>> Could you document what this change does in the >>>>> commit message ? >>>> >>>> This sets the position in the buffer of the ODDF. With this set, the ODD >>>> field is located in the second half (BOTTOM) of the same frame of the >>>> interlace display. >>>> >>>> Otherwise, it's in the first half (TOP) >>>> >>>> I faced some issues as to the ordering when testing, so I suspect this >>>> might actually be related to that. (re VI6_STATUS_FLD_STD in >>>> vsp1_dlm_irq_frame_end()). >>>> >>>> As you mention - this may have a negative effect on the Gen2 >>>> implementation - so it needs considering with that. >>>> >>>> >>>> /me to investigate further. >>> >>> Thank you. I don't object to this change, but I'd like to know what its >>> implications are on Gen2. It might even fix a bug :-) Let me know if you'd >>> like me to run tests on a Lager board. >> >> I've done some testing with this (removing the DSMR change, and >> inverting the VI6_STATUS_FLD_STD handling) and had some odd results. >> Perhaps my testing needs refinement. >> >> So, yes please - I think I'd really like to know what the effects are on >> a Lager platform. >> >> Would you (or anyone with a Gen2 and interest in vsp1/du) be able to >> test my latest vsp1/du/interlaced branch/tag on your local Gen2 platform >> please? > > I can test it when I'll come back home on the 24th (or rather on the next day > as I'll land in the evening). Could you please ping me on the 25th ? > >> I'm testing interlaced with: >> >> kmstest # sanity test. >> kmstest -c 1 -r 1920x1080i --flip ## -c 1 may have to change to be the right CRTC number > > My monitors don't support interlaced modes, so this won't be easy :-/ More than that - I suspect "won't be possible"? Perhaps Niklas, Jacopo, or Uli could help ? Do any of you have a Gen2 platform - and a monitor/TV capable of showing interlaced display output? > Also, what's the expected outcome of the above command in the working and non- > working cases ? Expected outcome ... a clean output of the standard kmstest pattern for the sanity test. For: kmstest -c 1 -r 1920x1080i --flip Good: A clean view of the usual 'flip' bar moving from left to right across the screen. Must visually check the following for good result: - No 'tearing' on the vertical bar - A full height bar, showing the colours, red, green, and blue, followed by 3 shades of grey; each separated by a white block. - cleanly drawn frame numbers Bad symptoms - Half height frames (only RGB, or 3 Grey shades showing in the flip bar) - Tearing or image racing of any kind (check the frame numbers as they overdraw on the moving bar. Any blurring of the numbers as the bar travels past is a fail) > >> Any (easy) other methods for testing interlaced pipelines are welcome. >> >> Is it possible to set the mode for kmscube? (--help doesn't look promising) > > Not that I know of, but I think that shouldn't be too difficult to add. > >> I have various test streams of interlaced media content in my media >> library, but not an easy way of decoding and presenting these on the >> screen on the Gen3. >> >> I believe GStreamer now has a drm/kms sink ... Perhaps I should get that >> recompiled. (That would help me with other tasks too actually) >> >>>>>> | DSMR_DIPM_DISP | DSMR_CSPM; >>>>>> >>>>>> rcar_du_crtc_write(rcrtc, DSMR, value); >>>>>> >>>>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c >>>>>> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index >>>>>> af7822a66dee..c7b37232ee91 >>>>>> 100644 >>>>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c >>>>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c >>>>>> @@ -186,6 +186,9 @@ static void rcar_du_vsp_plane_setup(struct >>>>>> rcar_du_vsp_plane *plane) >>>>>> }; >>>>>> unsigned int i; >>>>>> >>>>>> + cfg.interlaced = !!(plane->plane.state->crtc->mode.flags >>>>>> + & DRM_MODE_FLAG_INTERLACE); >>>>>> + >>>>>> cfg.src.left = state->state.src.x1 >> 16; >>>>>> cfg.src.top = state->state.src.y1 >> 16; >>>>>> cfg.src.width = drm_rect_width(&state->state.src) >> 16; > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
