From: Tobias Jakobi <liquid.acid@gmx.net>
To: Gustavo Padovan <gustavo@padovan.org>,
Tobias Jakobi <tjakobi@math.uni-bielefeld.de>,
linux-samsung-soc@vger.kernel.org,
gustavo.padovan@collabora.co.uk, dri-devel@lists.freedesktop.org
Subject: Re: [RFC 1/5] drm/exynos: mixer: refactor layer setup
Date: Thu, 30 Apr 2015 22:48:57 +0200 [thread overview]
Message-ID: <55429539.1020006@gmx.net> (raw)
In-Reply-To: <20150430202935.GA15382@joana>
Hello Gustavo!
Gustavo Padovan wrote:
> Hi Tobias,
>
> 2015-04-30 Tobias Jakobi <tjakobi@math.uni-bielefeld.de>:
>
>> First step in allowing a more generic way to setup complex
>> blending for the different layers.
>>
>> Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
>> ---
>> drivers/gpu/drm/exynos/exynos_mixer.c | 74 +++++++++++++++++++++++++++++------
>> 1 file changed, 63 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 4155f43..a06b8e2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -63,6 +63,12 @@ struct mixer_resources {
>> struct clk *mout_mixer;
>> };
>>
>> +struct layer_config {
>> + unsigned int index;
>> + unsigned int priority;
>> + u32 cfg;
>> +};
>
> I don't see why you are creating this struct, index and priority are
> never used in this patch series.
Good catch about 'priority'. But 'index' is used, see the second patch.
>
>> +
>> enum mixer_version_id {
>> MXR_VER_0_0_0_16,
>> MXR_VER_16_0_33_0,
>> @@ -75,6 +81,8 @@ struct mixer_context {
>> struct drm_device *drm_dev;
>> struct exynos_drm_crtc *crtc;
>> struct exynos_drm_plane planes[MIXER_WIN_NR];
>> + const struct layer_config *layer_config;
>> + unsigned int num_layer;
>> int pipe;
>> bool interlace;
>> bool powered;
>> @@ -95,6 +103,40 @@ struct mixer_drv_data {
>> bool has_sclk;
>> };
>>
>> +/*
>> + * The default layer priorities. A higher priority means that
>> + * the layer is at the top of layer stack.
>> + * The current configuration assumes the following usage scenario:
>> + * layer1: OSD [top]
>> + * layer0: main framebuffer
>> + * video layer: video overlay [bottom]
>> + * Note that the video layer is only usable when the
>> + * video processor is available.
>> + */
>> +
>> +static const struct layer_config default_layer_config[] = {
>> + {
>> + .index = 0, .priority = 1, /* layer0 */
>> + .cfg = MXR_LAYER_CFG_GRP0_VAL(1)
>> + }, {
>> + .index = 1, .priority = 2, /* layer1 */
>> + .cfg = MXR_LAYER_CFG_GRP1_VAL(2)
>> + }
>> +};
>> +
>> +static const struct layer_config vp_layer_config[] = {
>> + {
>> + .index = 2, .priority = 1, /* video layer */
>> + .cfg = MXR_LAYER_CFG_VP_VAL(1)
>> + }, {
>> + .index = 0, .priority = 2, /* layer0 */
>> + .cfg = MXR_LAYER_CFG_GRP0_VAL(2)
>> + }, {
>> + .index = 1, .priority = 3, /* layer1 */
>> + .cfg = MXR_LAYER_CFG_GRP1_VAL(3)
>> + }
>> +};
>> +
>> static const u8 filter_y_horiz_tap8[] = {
>> 0, -1, -1, -1, -1, -1, -1, -1,
>> -1, -1, -1, -1, -1, 0, 0, 0,
>> @@ -253,6 +295,17 @@ static void vp_default_filter(struct mixer_resources *res)
>> filter_cr_horiz_tap4, sizeof(filter_cr_horiz_tap4));
>> }
>>
>> +static void mixer_layer_priority(struct mixer_context *ctx)
>> +{
>> + u32 val = 0;
>> + unsigned int i;
>> +
>> + for (i = 0; i < ctx->num_layer; ++i)
>> + val |= ctx->layer_config[i].cfg;
>> +
>> + mixer_reg_write(&ctx->mixer_res, MXR_LAYER_CFG, val);
>> +}
>> +
>> static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable)
>> {
>> struct mixer_resources *res = &ctx->mixer_res;
>> @@ -655,17 +708,7 @@ static void mixer_win_reset(struct mixer_context *ctx)
>> mixer_reg_writemask(res, MXR_STATUS, MXR_STATUS_16_BURST,
>> MXR_STATUS_BURST_MASK);
>>
>> - /* setting default layer priority: layer1 > layer0 > video
>> - * because typical usage scenario would be
>> - * layer1 - OSD
>> - * layer0 - framebuffer
>> - * video - video overlay
>> - */
>> - val = MXR_LAYER_CFG_GRP1_VAL(3);
>> - val |= MXR_LAYER_CFG_GRP0_VAL(2);
>> - if (ctx->vp_enabled)
>> - val |= MXR_LAYER_CFG_VP_VAL(1);
>> - mixer_reg_write(res, MXR_LAYER_CFG, val);
>
> I would move this exaclty piece of code into mixer_layer_priority().
Then we end up with the same static/hardcoded setup as before. That's
something I want to move away from. The entire information about layer
ordering should be stored in 'layer_config'.
>> + mixer_layer_priority(ctx);
>>
>> /* setting background color */
>> mixer_reg_write(res, MXR_BG_COLOR0, 0x008080);
>> @@ -1274,6 +1317,15 @@ static int mixer_probe(struct platform_device *pdev)
>> ctx->vp_enabled = drv->is_vp_enabled;
>> ctx->has_sclk = drv->has_sclk;
>> ctx->mxr_ver = drv->version;
>> +
>> + if (drv->is_vp_enabled) {
>> + ctx->layer_config = vp_layer_config;
>> + ctx->num_layer = ARRAY_SIZE(vp_layer_config);
>> + } else {
>> + ctx->layer_config = default_layer_config;
>> + ctx->num_layer = ARRAY_SIZE(default_layer_config);
>> + }
>
> Then this piece of code is useless.
No, since the second patch depends on it.
With best wishes,
Tobias
>
> Gustavo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2015-04-30 20:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-30 14:56 [RFC] drm/exynos: rework layer blending setup Tobias Jakobi
2015-04-30 14:56 ` [RFC 1/5] drm/exynos: mixer: refactor layer setup Tobias Jakobi
2015-04-30 20:29 ` Gustavo Padovan
2015-04-30 20:48 ` Tobias Jakobi [this message]
2015-04-30 21:23 ` Gustavo Padovan
2015-04-30 14:56 ` [RFC 2/5] drm/exynos: mixer: introduce mixer_layer_blending() Tobias Jakobi
2015-04-30 14:56 ` [RFC 3/5] drm/exynos: mixer: remove all static blending setup Tobias Jakobi
2015-04-30 14:56 ` [RFC 4/5] drm/exynos: mixer: do blending setup in mixer_cfg_layer() Tobias Jakobi
2015-04-30 14:56 ` [RFC 5/5] drm/exynos: mixer: also allow ARGB1555 and ARGB4444 Tobias Jakobi
2015-05-04 7:28 ` [RFC] drm/exynos: rework layer blending setup Inki Dae
2015-05-04 9:15 ` Tobias Jakobi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55429539.1020006@gmx.net \
--to=liquid.acid@gmx.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavo.padovan@collabora.co.uk \
--cc=gustavo@padovan.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=tjakobi@math.uni-bielefeld.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.