[linux-sunxi] Re: [PATCH v7 05/13] drm/sun4i: abstract a engine type
From: icenowy@aosc.io (Icenowy Zheng)
Date: 2017-05-15 09:35:15
Also in:
dri-devel, linux-clk, linux-devicetree, lkml
? 2017?5?15? GMT+08:00 ??5:20:01, Maxime Ripard [off-list ref] ??:
On Mon, May 15, 2017 at 12:30:37AM +0800, Icenowy Zheng wrote:quoted
As we are going to add support for the Allwinner DE2 engine insun4i-drmquoted
driver, we will finally have two types of display engines -- the DE1 backend and the DE2 mixer. They both do some display blending andfeedquoted
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, whichcontainsquoted
functions that should be called outside the engine-specified code (in TCON, CRTC or TV Encoder code). Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Reviewed-by: Chen-Yu Tsai <redacted> --- Changes in v7: - Mention "Display Engine" for the name "engine". - Fixed some small issues found by Chen-Yu and added his ACK. Changes in v6: - Rebased on wens's multi-pipeline patchset. - Split out Makefile changes.You also added a get_id callback here...quoted
+static const struct sunxi_engine_ops sun4i_backend_engine_ops = { + .commit = sun4i_backend_commit, + .layers_init = sun4i_layers_init, + .apply_color_correction = sun4i_backend_apply_color_correction, + .disable_color_correction = sun4i_backend_disable_color_correction, +}; +... that you don't populate ...quoted
@@ -477,7 +481,7 @@ static int sun4i_tcon_bind(struct device *dev,struct device *master,quoted
dev_set_drvdata(dev, tcon); tcon->drm = drm; tcon->dev = dev; - tcon->id = backend->id; + tcon->id = sunxi_engine_get_id(engine);... that you call to fill the TCON ID ...quoted
+/** + * sunxi_engine_get_id - Get the ID of the engine. + * @engine: pointer to the engine + * + * If the ID is not necessary, just do not implement it insunxi_engine_ops,quoted
+ * and a default -1 will be returned. + */ +static inline int +sunxi_engine_get_id(struct sunxi_engine *engine) +{ + if (engine->ops && engine->ops->get_id) + return engine->ops->get_id(engine); + + return -1;... and will return -1 if not populated, which essentially means that instead of having 0 or 1, we're now having -1 as our id. This is a regression, and I'm even wondering if we can't just store the ID in the sunxi_engine structure. Is anything preventing us to do that, instead of using a callback?
Some engines (de2 mixer) doesn't use the ID. But 0 is a valid ID here. If we just store it in sunxi_engine, it should be assigned -1 for de2 mixer. Is this applicable? If it's okay I will do so.
Maxime