summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/sun4i/sun4i_crtc.h
Commit message (Collapse)AuthorAgeFilesLines
* drm/sun4i: abstract a engine typeIcenowy Zheng2017-06-011-2/+2
| | | | | | | | | | | | | | | | | | | As we are going to add support for the Allwinner DE2 engine in sun4i-drm driver, we will finally have two types of display engines -- the DE1 backend and the DE2 mixer. They both do some display blending and feed graphics data to TCON, and is part of the "Display Engine" called by Allwinner, so I choose to call them both "engine" here. Abstract the engine type to a new struct with an ops struct, which contains functions that should be called outside the engine-specified code (in TCON, CRTC or TV Encoder code). In order to preserve bisectability, we also switch the backend and layer code in its own module. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* drm/sun4i: return only planes for layers createdIcenowy Zheng2017-05-151-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | As we are going to add support for the Allwinner DE2 Mixer in sun4i-drm driver, we will finally have two types of layers. Each layer is bound to a drm_plane that is CRTC-specific, so we create them when initializing CRTC (calling sun4i_layers_init, which will be generalized in next patch). The drm_plane's will be used when creating CRTC, but the CRTC initialization code do not care other properties of the layer, so we let the sun4i_layers_init function return drm_plane's only. As we have no need to trace the layers after the CRTC is properly created, we drop the layers pointer in sun4i_crtc struct. Doing this uncouples the CRTC code from the type of layer (the sun4i_layers_init function name is still hardcoded and will be changed in the next patch), so that we can finally gain support for the mixer in DE2, which has different layers. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* drm/sun4i: Pass pointers for associated backend and tcon into crtc initChen-Yu Tsai2017-03-091-1/+3
| | | | | | | | | | | | | sun4i_crtc controls the backend and tcon hardware blocks of the display pipeline. Pass pointers to the underlying devices into the crtc init function, instead of trying to fetch them from the drm_device structure. This avoids the headache of trying to figure out which devices the crtc is actually associated with. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* drm/sun4i: Add backend and tcon pointers to sun4i_crtcChen-Yu Tsai2017-03-071-1/+2
| | | | | | | | | | | | | | | sun4i_crtc controls the backend and tcon hardware blocks of the display pipeline. Instead of doing so through the master drm structure, leave pointers to the corresponding backend and tcon in itself. Also drop the drm_device pointer, since it is no longer needed. The next step forward would be to pass the pointers in through sun4i_crtc_init as parameters. This would make it easier to support multiple display pipelines layer on. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* drm/sun4i: Move layers from sun4i_drv to sun4i_crtcChen-Yu Tsai2017-03-071-0/+1
| | | | | | | | | | | | | | | | | | This patch moves the sun4i_layers_init call from sun4i_drv_bind to sun4i_crtc_init, and the layers pointer from struct sun4i_drv to struct sun4i_crtc. The layers are bound to a specific crtc, and they are not directly used once initiated. They are used through their included drm_plane structures. Moving the layers into the crtc facilitates binding them to the crtc explicitly, by setting the corresponding bit in their .possible_crtcs fields right after the crtc is initialized. This is done in a later patch. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* drm: Add Allwinner A10 Display Engine supportMaxime Ripard2016-04-281-0/+30
The Allwinner A10 and subsequent SoCs share the same display pipeline, with variations in the number of controllers (1 or 2), or the presence or not of some output (HDMI, TV, VGA) or not. Add a driver with a limited set of features for now, and we will hopefully support all of them eventually Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
OpenPOWER on IntegriCloud