18 Mar, 2019

2 commits


18 Sep, 2018

1 commit

  • YCbCr planar formats can have different pitch values for the luma and
    chroma planes. This isn't taken into account in the driver. Fix it.

    Based on a BSP patch from Koji Matsuoka .

    Fixes: 7863ac504bc5 ("drm: rcar-du: Add tri-planar memory formats support")
    [Updated documentation of the struct vsp1_du_atomic_config pitch field]

    Signed-off-by: Koji Matsuoka
    Signed-off-by: Laurent Pinchart
    Reviewed-by: Kieran Bingham
    Signed-off-by: Mauro Carvalho Chehab

    Koji Matsuoka
     

12 Sep, 2018

1 commit


04 Aug, 2018

1 commit

  • Calculate the top and bottom fields for the interlaced frames and
    utilise the extended display list command feature to implement the
    auto-field operations. This allows the DU to update the VSP2 registers
    dynamically based upon the currently processing field.

    Signed-off-by: Kieran Bingham
    Signed-off-by: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab

    Kieran Bingham
     

17 May, 2018

2 commits


03 Aug, 2017

1 commit

  • The driver recently switched from handling page flip completion in the
    DU vertical blanking handler to the VSP frame end handler to fix a race
    condition. This unfortunately resulted in incorrect timestamps in the
    vertical blanking events sent to userspace as vertical blanking is now
    handled after sending the event.

    To fix this we must reverse the order of the two operations. The easiest
    way is to handle vertical blanking in the VSP frame end handler before
    sending the event. The VSP frame end interrupt occurs approximately 50µs
    earlier than the DU frame end interrupt, but this should not cause any
    undue harm.

    As we need to handle vertical blanking even when page flip completion is
    delayed, the VSP driver now needs to call the frame end completion
    callback unconditionally, with a new argument to report whether page
    flip has completed.

    With this new scheme the DU vertical blanking interrupt isn't needed
    anymore, so we can stop enabling it.

    Fixes: d503a43ac06a ("drm: rcar-du: Register a completion callback with VSP1")
    Signed-off-by: Kieran Bingham
    Signed-off-by: Laurent Pinchart
    Acked-by: Mauro Carvalho Chehab

    Kieran Bingham
     

30 Jul, 2017

1 commit

  • In the H3 ES2.0 SoC the VSP2-DL instance has two connections to DU
    channels that need to be configured independently. Extend the VSP-DU API
    with a pipeline index to identify which pipeline the caller wants to
    operate on.

    Signed-off-by: Laurent Pinchart
    Reviewed-by: Kieran Bingham
    Acked-by: Mauro Carvalho Chehab

    Laurent Pinchart
     

09 Jun, 2017

1 commit

  • The display buffers must be mapped for DMA through the device that
    performs memory access. Expose an API to map and unmap memory through
    the VSP device to be used by the DU.

    As all the buffers allocated by the DU driver are coherent, we can skip
    cache handling when mapping and unmapping them. This will need to be
    revisited when support for non-coherent buffers will be added to the DU
    driver.

    Signed-off-by: Laurent Pinchart
    Reviewed-by: Kieran Bingham
    [Kieran: Remove unused header]
    Signed-off-by: Kieran Bingham
    Acked-by: Mauro Cavalho Chehab

    Laurent Pinchart
     

22 May, 2017

1 commit

  • To be able to perform page flips in DRM without flicker we need to be
    able to notify the rcar-du module when the VSP has completed its
    processing.

    We must not have bidirectional dependencies on the two components to
    maintain support for loadable modules, thus we extend the API to allow
    a callback to be registered within the VSP DRM interface.

    Signed-off-by: Kieran Bingham
    Reviewed-by: Laurent Pinchart
    Signed-off-by: Laurent Pinchart
    Acked-by: Mauro Carvalho Chehab

    Kieran Bingham
     

08 Mar, 2017

1 commit

  • The interface to configure the LIF in the VSP1 requires adapting the
    function prototype for any changes. This makes extending the interface
    difficult.

    Change the function prototype to pass a structure which can be easily
    extended.

    This changes the means of disabling the pipeline, by now passing a NULL
    configuration rather than passing either a 0 width or height.

    [Fixed kerneldoc, made vsp1_du_setup_lif() cfg argument const]

    Signed-off-by: Kieran Bingham
    Signed-off-by: Laurent Pinchart
    Acked-by: Dave Airlie
    Signed-off-by: Mauro Carvalho Chehab

    Kieran Bingham
     

09 Sep, 2016

1 commit


21 Jun, 2016

1 commit


17 Jun, 2016

1 commit

  • The vsp1_du_atomic_update_ext() function takes 7 RPF configuration
    parameters, and more will likely be added later. This makes the code
    difficult to read and error-prone as multiple parameters have the same
    type.

    Make the API safer and easier to extend in the future by grouping all
    parameters in a structure. Use macro magic to ease the transition to the
    new function by allowing the old and new functions to be called using
    the same name. The macros and static inline wrapper will be removed as
    soon as the caller is updated.

    Signed-off-by: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab

    Laurent Pinchart
     

14 Apr, 2016

3 commits


19 Feb, 2016

2 commits

  • Add two API functions named vsp1_du_atomic_begin() and
    vsp1_du_atomic_flush() to signal the start and end of an atomic update.
    The vsp1_du_setup_rpf() function is renamed to vsp1_du_atomic_update()
    for consistency.

    With this new API, the driver will reprogram all modified inputs
    atomically before restarting the video stream.

    Signed-off-by: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab

    Laurent Pinchart
     
  • Implement internal control of the VSP pipeline to be used by the DU
    DRM/KMS driver when using the VSP as an internal composer handled
    through DRM/KMS only.

    Signed-off-by: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab

    Laurent Pinchart