From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 1/6] OMAPDSS: DISPC: cleanup cpu_is_xxxx checks
Date: Wed, 08 Aug 2012 12:36:00 +0000 [thread overview]
Message-ID: <1344429360.4932.58.camel@deskari> (raw)
In-Reply-To: <1344425874-28222-1-git-send-email-cmahapatra@ti.com>
[-- Attachment #1: Type: text/plain, Size: 7991 bytes --]
On Wed, 2012-08-08 at 17:07 +0530, Chandrabhanu Mahapatra wrote:
> All the cpu_is checks have been moved to dispc_init_features function providing
> a much more generic and cleaner interface. The OMAP version and revision
> specific functions are initialized by dispc_features structure local to dispc.c.
>
> Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
> ---
> drivers/video/omap2/dss/dispc.c | 476 ++++++++++++++++++++++++++-------------
> 1 file changed, 315 insertions(+), 161 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index 5b289c5..7e0b080 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -75,12 +75,60 @@ enum omap_burst_size {
> #define REG_FLD_MOD(idx, val, start, end) \
> dispc_write_reg(idx, FLD_MOD(dispc_read_reg(idx), val, start, end))
>
> +static int dispc_ovl_calc_scaling_24xx(enum omap_channel channel,
> + const struct omap_video_timings *mgr_timings, u16 width, u16 height,
> + u16 out_width, u16 out_height, enum omap_color_mode color_mode,
> + bool *five_taps, int *x_predecim, int *y_predecim, int *decim_x,
> + int *decim_y, u16 pos_x, unsigned long *core_clk);
> +static int dispc_ovl_calc_scaling_34xx(enum omap_channel channel,
> + const struct omap_video_timings *mgr_timings, u16 width, u16 height,
> + u16 out_width, u16 out_height, enum omap_color_mode color_mode,
> + bool *five_taps, int *x_predecim, int *y_predecim, int *decim_x,
> + int *decim_y, u16 pos_x, unsigned long *core_clk);
> +static int dispc_ovl_calc_scaling_44xx(enum omap_channel channel,
> + const struct omap_video_timings *mgr_timings, u16 width, u16 height,
> + u16 out_width, u16 out_height, enum omap_color_mode color_mode,
> + bool *five_taps, int *x_predecim, int *y_predecim, int *decim_x,
> + int *decim_y, u16 pos_x, unsigned long *core_clk);
> +
> +static unsigned long calc_core_clk_24xx(enum omap_channel channel, u16 width,
> + u16 height, u16 out_width, u16 out_height);
> +static unsigned long calc_core_clk_34xx(enum omap_channel channel, u16 width,
> + u16 height, u16 out_width, u16 out_height);
> +static unsigned long calc_core_clk_44xx(enum omap_channel channel, u16 width,
> + u16 height, u16 out_width, u16 out_height);
> +
> +static bool _dispc_lcd_timings_ok_24xx(int hsw, int hfp, int hbp,
> + int vsw, int vfp, int vbp);
> +static bool _dispc_lcd_timings_ok_44xx(int hsw, int hfp, int hbp,
> + int vsw, int vfp, int vbp);
> +
> +static void _dispc_mgr_set_lcd_timings_hv_24xx(enum omap_channel channel,
> + int hsw, int hfp, int hbp, int vsw, int vfp, int vbp);
> +static void _dispc_mgr_set_lcd_timings_hv_44xx(enum omap_channel channel,
> + int hsw, int hfp, int hbp, int vsw, int vfp, int vbp);
While it's nice to have the initialization of struct dispc_features in
the beginning of dispc.c, it requires the above prototypes. And in the
future we may require more. For that reason I think it's better to
initialize the dispc_features at the end of dispc.c, just above
dispc_init_features(). This would be kinda similar to how drivers often
initialize their ops.
> +static const struct dispc_features omap2_dispc_features = {
> + .calc_scaling = dispc_ovl_calc_scaling_24xx,
> + .calc_core_clk = calc_core_clk_24xx,
> + .lcd_timings_ok = _dispc_lcd_timings_ok_24xx,
> + .set_lcd_timings_hv = _dispc_mgr_set_lcd_timings_hv_24xx,
> +};
> +
> +static const struct dispc_features omap3_2_1_dispc_features = {
> + .calc_scaling = dispc_ovl_calc_scaling_34xx,
> + .calc_core_clk = calc_core_clk_34xx,
> + .lcd_timings_ok = _dispc_lcd_timings_ok_24xx,
> + .set_lcd_timings_hv = _dispc_mgr_set_lcd_timings_hv_24xx,
> +};
> +
> +static const struct dispc_features omap3_3_0_dispc_features = {
> + .calc_scaling = dispc_ovl_calc_scaling_34xx,
> + .calc_core_clk = calc_core_clk_34xx,
> + .lcd_timings_ok = _dispc_lcd_timings_ok_44xx,
> + .set_lcd_timings_hv = _dispc_mgr_set_lcd_timings_hv_44xx,
> +};
> +
> +static const struct dispc_features omap4_dispc_features = {
> + .calc_scaling = dispc_ovl_calc_scaling_44xx,
> + .calc_core_clk = calc_core_clk_44xx,
> + .lcd_timings_ok = _dispc_lcd_timings_ok_44xx,
> + .set_lcd_timings_hv = _dispc_mgr_set_lcd_timings_hv_44xx,
> +};
During runtime we only require one of these, others can be discarded.
This can be accomplished with the combination of "__initdata" for these,
and "__init" for dispc_init_features().
However, because even the one we need will be discarded, we need to copy
the values. This could be done either by having the dispc_features
struct inside dispc struct (instead of a pointer), or allocating memory
for it with devm_kzalloc(). The latter allows us to keep it const, but
I'm not sure which approach is better (if either).
> -static bool _dispc_lcd_timings_ok(int hsw, int hfp, int hbp,
> +static bool _dispc_lcd_timings_ok_24xx(int hsw, int hfp, int hbp,
> int vsw, int vfp, int vbp)
> {
> - if (cpu_is_omap24xx() || omap_rev() < OMAP3430_REV_ES3_0) {
> - if (hsw < 1 || hsw > 64 ||
> - hfp < 1 || hfp > 256 ||
> - hbp < 1 || hbp > 256 ||
> - vsw < 1 || vsw > 64 ||
> - vfp < 0 || vfp > 255 ||
> - vbp < 0 || vbp > 255)
> - return false;
> - } else {
> - if (hsw < 1 || hsw > 256 ||
> - hfp < 1 || hfp > 4096 ||
> - hbp < 1 || hbp > 4096 ||
> - vsw < 1 || vsw > 256 ||
> - vfp < 0 || vfp > 4095 ||
> - vbp < 0 || vbp > 4095)
> - return false;
> - }
> -
> + if (hsw < 1 || hsw > 64 ||
> + hfp < 1 || hfp > 256 ||
> + hbp < 1 || hbp > 256 ||
> + vsw < 1 || vsw > 64 ||
> + vfp < 0 || vfp > 255 ||
> + vbp < 0 || vbp > 255)
> + return false;
> + return true;
> +}
> +static bool _dispc_lcd_timings_ok_44xx(int hsw, int hfp, int hbp,
> + int vsw, int vfp, int vbp)
> +{
> + if (hsw < 1 || hsw > 256 ||
> + hfp < 1 || hfp > 4096 ||
> + hbp < 1 || hbp > 4096 ||
> + vsw < 1 || vsw > 256 ||
> + vfp < 0 || vfp > 4095 ||
> + vbp < 0 || vbp > 4095)
> + return false;
> return true;
> }
I think we should use separate functions only when the code is
different. Here the code is the same, we just use different max values.
So instead of these functions, I suggest to add those max values into
struct dispc_features.
> @@ -2633,7 +2757,8 @@ bool dispc_mgr_timings_ok(enum omap_channel channel,
> timings_ok = _dispc_mgr_size_ok(timings->x_res, timings->y_res);
>
> if (dss_mgr_is_lcd(channel))
> - timings_ok = timings_ok && _dispc_lcd_timings_ok(timings->hsw,
> + timings_ok = timings_ok &&
> + dispc.feat->lcd_timings_ok(timings->hsw,
> timings->hfp, timings->hbp,
> timings->vsw, timings->vfp,
> timings->vbp);
> @@ -2641,6 +2766,34 @@ bool dispc_mgr_timings_ok(enum omap_channel channel,
> return timings_ok;
> }
>
> +static void _dispc_mgr_set_lcd_timings_hv_24xx(enum omap_channel channel,
> + int hsw, int hfp, int hbp, int vsw, int vfp, int vbp)
> +{
> + u32 timing_h, timing_v;
> +
> + timing_h = FLD_VAL(hsw-1, 5, 0) | FLD_VAL(hfp-1, 15, 8) |
> + FLD_VAL(hbp-1, 27, 20);
> + timing_v = FLD_VAL(vsw-1, 5, 0) | FLD_VAL(vfp, 15, 8) |
> + FLD_VAL(vbp, 27, 20);
> +
> + dispc_write_reg(DISPC_TIMING_H(channel), timing_h);
> + dispc_write_reg(DISPC_TIMING_V(channel), timing_v);
> +}
> +
> +static void _dispc_mgr_set_lcd_timings_hv_44xx(enum omap_channel channel,
> + int hsw, int hfp, int hbp, int vsw, int vfp, int vbp)
> +{
> + u32 timing_h, timing_v;
> +
> + timing_h = FLD_VAL(hsw-1, 7, 0) | FLD_VAL(hfp-1, 19, 8) |
> + FLD_VAL(hbp-1, 31, 20);
> + timing_v = FLD_VAL(vsw-1, 7, 0) | FLD_VAL(vfp, 19, 8) |
> + FLD_VAL(vbp, 31, 20);
> +
> + dispc_write_reg(DISPC_TIMING_H(channel), timing_h);
> + dispc_write_reg(DISPC_TIMING_V(channel), timing_v);
> +}
Same thing here. The code is the same, only the bit fields are larger.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-08-08 12:36 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-07 8:39 [PATCH 0/6] OMAPDSS: Remove cpu_is checks Chandrabhanu Mahapatra
2012-08-07 8:39 ` [PATCH 1/6] OMAPDSS: DISPC: Remove cpu_is_xxxx checks Chandrabhanu Mahapatra
2012-08-07 8:48 ` Felipe Balbi
2012-08-07 9:05 ` Tomi Valkeinen
2012-08-07 9:14 ` Felipe Balbi
2012-08-07 9:27 ` Tomi Valkeinen
2012-08-07 9:32 ` Felipe Balbi
2012-08-07 9:57 ` Tomi Valkeinen
2012-08-07 10:27 ` Felipe Balbi
2012-08-07 10:57 ` Tomi Valkeinen
2012-08-07 11:14 ` Tony Lindgren
2012-08-07 10:52 ` Tomi Valkeinen
2012-08-07 12:34 ` Chandrabhanu Mahapatra
2012-08-07 13:00 ` Tomi Valkeinen
2012-08-08 11:49 ` [PATCH 1/6] OMAPDSS: DISPC: cleanup " Chandrabhanu Mahapatra
2012-08-08 12:36 ` Tomi Valkeinen [this message]
2012-08-08 13:13 ` Mahapatra, Chandrabhanu
2012-08-08 13:25 ` Tomi Valkeinen
2012-08-13 12:10 ` Chandrabhanu Mahapatra
2012-08-14 9:58 ` Tomi Valkeinen
2012-08-14 12:15 ` Mahapatra, Chandrabhanu
2012-08-14 12:16 ` Tomi Valkeinen
2012-08-16 11:30 ` [PATCH V4 " Chandrabhanu Mahapatra
2012-08-07 8:39 ` [PATCH 2/6] OMAPDSS: DSS: Remove redundant functions Chandrabhanu Mahapatra
2012-08-07 8:40 ` [PATCH 3/6] OMAPDSS: DSS: Remove cpu_is_xxxx checks Chandrabhanu Mahapatra
2012-08-07 8:49 ` Felipe Balbi
2012-08-07 13:14 ` Tomi Valkeinen
2012-08-08 11:50 ` [PATCH 3/6] OMAPDSS: DSS: Cleanup " Chandrabhanu Mahapatra
2012-08-08 13:16 ` Tomi Valkeinen
2012-08-09 11:51 ` Mahapatra, Chandrabhanu
2012-08-13 12:11 ` Chandrabhanu Mahapatra
2012-08-14 9:48 ` Tomi Valkeinen
2012-08-14 12:42 ` Mahapatra, Chandrabhanu
2012-08-14 14:34 ` Tomi Valkeinen
2012-08-16 11:30 ` [PATCH V4 " Chandrabhanu Mahapatra
2012-08-17 13:54 ` Tomi Valkeinen
2012-08-20 8:42 ` Tomi Valkeinen
2012-08-20 10:48 ` Mahapatra, Chandrabhanu
2012-08-20 10:46 ` Tomi Valkeinen
2012-08-07 8:40 ` [PATCH 4/6] OMAPDSS: VENC: Remove " Chandrabhanu Mahapatra
2012-08-07 8:51 ` Felipe Balbi
2012-08-07 12:48 ` Chandrabhanu Mahapatra
2012-08-07 8:40 ` [PATCH 5/6] ARM: OMAP: Disable venc for OMAP4 Chandrabhanu Mahapatra
2012-08-07 8:41 ` [PATCH 6/6] OMAPDSS: DPI: Remove cpu_is_xxxx checks Chandrabhanu Mahapatra
2012-08-20 13:33 ` [PATCH V5 0/6] OMAPDSS: Cleanup cpu_is checks Chandrabhanu Mahapatra
2012-08-20 13:34 ` [PATCH V5 1/6] OMAPDSS: DISPC: cleanup cpu_is_xxxx checks Chandrabhanu Mahapatra
2012-08-21 10:31 ` Tomi Valkeinen
2012-08-21 11:32 ` Mahapatra, Chandrabhanu
2012-08-20 13:35 ` [PATCH V5 2/6] OMAPDSS: DSS: Remove redundant functions Chandrabhanu Mahapatra
2012-08-20 13:35 ` [PATCH V5 3/6] OMAPDSS: DSS: Cleanup cpu_is_xxxx checks Chandrabhanu Mahapatra
2012-08-21 10:35 ` Tomi Valkeinen
2012-08-21 11:18 ` Mahapatra, Chandrabhanu
2012-08-21 11:20 ` Tomi Valkeinen
2012-08-20 13:36 ` [PATCH V5 4/6] OMAPDSS: VENC: Remove " Chandrabhanu Mahapatra
2012-08-20 13:36 ` [PATCH V5 5/6] ARM: OMAP: Disable venc for OMAP4 Chandrabhanu Mahapatra
2012-08-21 10:32 ` Tomi Valkeinen
2012-08-21 11:25 ` Mahapatra, Chandrabhanu
2012-08-20 13:36 ` [PATCH V5 6/6] OMAPDSS: DPI: Remove cpu_is_xxxx checks Chandrabhanu Mahapatra
2012-08-22 6:48 ` [PATCH V6 0/6] OMAPDSS: Cleanup cpu_is checks Chandrabhanu Mahapatra
2012-08-22 6:49 ` [PATCH V6 1/6] OMAPDSS: DISPC: Cleanup cpu_is_xxxx checks Chandrabhanu Mahapatra
2012-08-22 6:49 ` [PATCH V6 2/6] OMAPDSS: DSS: Remove redundant functions Chandrabhanu Mahapatra
2012-08-22 6:50 ` [PATCH V6 3/6] OMAPDSS: DSS: Cleanup cpu_is_xxxx checks Chandrabhanu Mahapatra
2012-08-22 6:50 ` [PATCH V6 4/6] ARM: OMAP: Disable venc for OMAP4 Chandrabhanu Mahapatra
2012-08-22 6:50 ` [PATCH V6 5/6] OMAPDSS: VENC: Remove cpu_is_xxxx checks Chandrabhanu Mahapatra
2012-08-22 6:51 ` [PATCH V6 6/6] OMAPDSS: DPI: " Chandrabhanu Mahapatra
2012-08-22 8:44 ` [PATCH V6 0/6] OMAPDSS: Cleanup cpu_is checks Tomi Valkeinen
2012-08-30 0:20 ` [PATCH V5 " Tony Lindgren
2012-08-30 7:34 ` Tomi Valkeinen
2012-08-30 17:19 ` Tony Lindgren
2012-08-31 11:23 ` Tomi Valkeinen
2012-09-06 20:08 ` Tony Lindgren
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=1344429360.4932.58.camel@deskari \
--to=tomi.valkeinen@ti.com \
--cc=cmahapatra@ti.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).