summaryrefslogtreecommitdiff
path: root/drivers/media/platform/vsp1/vsp1_drm.h
AgeCommit message (Collapse)AuthorFilesLines
2021-03-22media: vsp1/vsp1_drm.h: add missing 'struct' kernel-doc keywordHans Verkuil1-2/+2
The kernel-doc documentation for two structs was missing the 'struct' keyword. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2019-03-18media: vsp1: drm: Extend frame completion API to the DU driverLaurent Pinchart1-1/+1
The VSP1 driver will need to pass extra flags to the DU through the frame completion API. Replace the completed bool flag by a bitmask to support this. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-05-17media: v4l: vsp1: Integrate DISCOM in display pipelineLaurent Pinchart1-0/+7
The DISCOM is used to compute CRCs on display frames. Integrate it in the display pipeline at the output of the blending unit to process output frames. Computing CRCs on input frames is possible by positioning the DISCOM at a different point in the pipeline. This use case isn't supported at the moment and could be implemented by extending the API between the VSP1 and DU drivers if needed. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-05-17media: v4l: vsp1: Extend the DU API to support CRC computationLaurent Pinchart1-1/+1
Add a parameter (in the form of a structure to ease future API extensions) to the VSP atomic flush handler to pass CRC source configuration, and pass the CRC value to the completion callback. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-05-17media: v4l: vsp1: Use SPDX license headersLaurent Pinchart1-5/+1
Adopt the SPDX license identifier headers to ease license compliance management. All files in the driver are licensed under the GPLv2+ except for the vsp1_regs.h file which is licensed under the GPLv2. This is likely an oversight, but fixing this requires contacting the copyright owners and is out of scope for this patch. While at it fix the file descriptions to match file names where copy and paste error occurred. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-05-04media: v4l: vsp1: Rename BRU to BRxLaurent Pinchart1-3/+3
Some VSP instances have two blending units named BRU (Blend/ROP Unit) and BRS (Blend/ROP Sub unit). The BRS is a smaller version of the BRU with only two inputs, but otherwise offers similar features and offers the same register interface. The BRU and BRS can be used exchangeably in VSP pipelines (provided no more than two inputs are needed). Due to historical reasons, the VSP1 driver implements support for both the BRU and BRS through objects named vsp1_bru. The code uses the name BRU to refer to either the BRU or the BRS, except in a few places where noted explicitly. This creates confusion. In an effort to avoid confusion, rename the vsp1_bru object and the corresponding API to vsp1_brx, and use BRx to refer to blend unit instances regardless of their type. The names BRU and BRS are retained where reference to a particular blend unit type is needed, as well as in hardware registers to stay close to the datasheet. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-05-04media: v4l: vsp1: Assign BRU and BRS to pipelines dynamicallyLaurent Pinchart1-0/+9
The VSPDL variant drives two DU channels through two LIF and two blenders, BRU and BRS. The DU channels thus share the five available VSPDL inputs and expose them as five KMS planes. The current implementation assigns the BRS to the second LIF and thus artificially limits the number of planes for the second display channel to two at most. Lift this artificial limitation by assigning the BRU and BRS to the display pipelines on demand based on the number of planes used by each pipeline. When a display pipeline needs more than two inputs and the BRU is already in use by the other pipeline, this requires reconfiguring the other pipeline to free the BRU before processing, which can result in frame drop on both pipelines. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-05-04media: v4l: vsp1: Setup BRU at atomic commit timeLaurent Pinchart1-0/+5
To implement fully dynamic plane assignment to pipelines, we need to reassign the BRU and BRS to the DRM pipelines in the atomic commit handler. In preparation for this setup factor out the BRU source pad code and call it both at LIF setup and atomic commit time. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-05-04media: v4l: vsp1: Remove unused field from vsp1_drm_pipeline structureLaurent Pinchart1-2/+0
The vsp1_drm_pipeline enabled field is set but never used. Remove it. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2017-08-03drm: rcar-du: Repair vblank for DRM page flips using the VSPKieran Bingham1-1/+1
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 <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-08-03v4l: vsp1: Add support for multiple DRM pipelinesLaurent Pinchart1-13/+22
The R-Car H3 ES2.0 VSP-DL instance has two LIF entities and can drive two display pipelines at the same time. Refactor the VSP DRM code to support that by introducing a vsp_drm_pipeline object that models one display pipeline. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-07-29v4l: vsp1: Don't create links for DRM pipelineLaurent Pinchart1-1/+0
When the VSP1 is used in a DRM pipeline the driver doesn't register the media device. Links between entities are not exposed to userspace, but are still used internally for the sole purpose of setting up internal source to sink pointers through the link setup handler. Instead of going through this complex procedure, remove link creation and set the sink pointers directly. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-07-29v4l: vsp1: Don't recycle active list at display startLaurent Pinchart1-2/+0
When the display start interrupt occurs, we know that the hardware has finished loading the active display list. The driver then proceeds to recycle the list, assuming it won't be needed anymore. This assumption holds true for headerless display lists, as the VSP doesn't reload the list for the next frame if it hasn't changed. However, this isn't true anymore for header display lists, as they are loaded at every frame start regardless of whether they have been updated. To prepare for header display lists usage in display pipelines, we need to postpone recycling the list until it gets replaced by a new one through a page flip. The driver already does so in the frame end interrupt handler, so all we need is to skip list recycling in the display start interrupt handler. While the active list can be recycled at display start for headerless display lists, there's no real harm in postponing that to the frame end interrupt handler in all cases. This simplifies interrupt handling as we don't need to process the display start interrupt anymore. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-05-22v4l: vsp1: Extend VSP1 module API to allow DRM callbacksKieran Bingham1-0/+11
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 <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-04-10[media] v4l: vsp1: Fix struct vsp1_drm documentationKieran Bingham1-1/+1
The struct vsp1_drm references a member 'planes' which doesn't exist. Correctly identify this documentation against the 'inputs' Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-04-14[media] v4l: vsp1: Add Z-order support for DRM pipelineLaurent Pinchart1-2/+10
Make the Z-order of planes configurable by assigning RPFs to BRU inputs dynamically based on the Z-order position. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-04-13[media] v4l: vsp1: Store the display list manager in the WPFLaurent Pinchart1-7/+1
Each WPF can process display lists independently, move the manager to the WPF to reflect that and prepare for display list support for non-DRM pipelines. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-04-13[media] v4l: vsp1: Split display list manager from display listLaurent Pinchart1-4/+8
This clarifies the API and prepares display list support for being used to implement the request API. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-04-13[media] v4l: vsp1: drm: Include correct header fileLaurent Pinchart1-11/+0
The VSP1 DRM API is declared in <media/vsp1.h>, not <linux/vsp1.h>. Fix it. This also reverts commit 18922936dc28 ("[media] vsp1_drm.h: add missing prototypes") that added the same declarations in a different header file. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-02-19[media] vsp1_drm.h: add missing prototypesMauro Carvalho Chehab1-0/+11
drivers/media/platform/vsp1/vsp1_drm.c:47:5: warning: no previous prototype for 'vsp1_du_init' [-Wmissing-prototypes] int vsp1_du_init(struct device *dev) ^ drivers/media/platform/vsp1/vsp1_drm.c:76:5: warning: no previous prototype for 'vsp1_du_setup_lif' [-Wmissing-prototypes] int vsp1_du_setup_lif(struct device *dev, unsigned int width, ^ drivers/media/platform/vsp1/vsp1_drm.c:221:6: warning: no previous prototype for 'vsp1_du_atomic_begin' [-Wmissing-prototypes] void vsp1_du_atomic_begin(struct device *dev) ^ drivers/media/platform/vsp1/vsp1_drm.c:273:5: warning: no previous prototype for 'vsp1_du_atomic_update' [-Wmissing-prototypes] int vsp1_du_atomic_update(struct device *dev, unsigned int rpf_index, ^ drivers/media/platform/vsp1/vsp1_drm.c:451:6: warning: no previous prototype for 'vsp1_du_atomic_flush' [-Wmissing-prototypes] void vsp1_du_atomic_flush(struct device *dev) ^ Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-02-19[media] v4l: vsp1: Add display list supportTakashi Saito1-0/+5
Display lists contain lists of registers and associated values to be applied atomically by the hardware. They lower the pressure on interrupt processing delays when reprogramming the device as settings can be prepared well in advance and queued to the hardware without waiting for the end of the current frame. Display list support is currently limited to the DRM pipeline. Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-02-19[media] v4l: vsp1: Implement atomic update for the DRM driverLaurent Pinchart1-0/+7
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 <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-02-19[media] v4l: vsp1: Add VSP+DU supportLaurent Pinchart1-0/+26
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 <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>