From: Thierry Reding <thierry.reding@gmail.com>
To: Ajay Kumar <ajaykumar.rs@samsung.com>
Cc: devicetree@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
seanpaul@google.com, daniel.vetter@ffwll.ch, joshi@samsung.com,
dri-devel@lists.freedesktop.org, ajaynumb@gmail.com,
prashanth.g@samsung.com
Subject: Re: [PATCH V6 3/8] drm/panel: simple: Add support for auo_b133htn01 panel
Date: Wed, 30 Jul 2014 12:51:33 +0200 [thread overview]
Message-ID: <20140730105132.GF29590@ulmo> (raw)
In-Reply-To: <1406316130-4744-4-git-send-email-ajaykumar.rs@samsung.com>
[-- Attachment #1.1: Type: text/plain, Size: 5490 bytes --]
On Sat, Jul 26, 2014 at 12:52:05AM +0530, Ajay Kumar wrote:
> Add panel_desc structure for auo_b133htn01 eDP panel.
>
> Also, modify the panel_simple routines to support timing_parameter
> delays if mentioned in the panel_desc structure.
>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> ---
> .../devicetree/bindings/panel/auo,b133htn01.txt | 7 +++
> drivers/gpu/drm/panel/panel-simple.c | 47 ++++++++++++++++++++
> 2 files changed, 54 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/panel/auo,b133htn01.txt
I think this should be two patches, one which adds the delay parameters
and another which adds support for the new panel.
> diff --git a/Documentation/devicetree/bindings/panel/auo,b133htn01.txt b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt
> new file mode 100644
> index 0000000..302226b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt
> @@ -0,0 +1,7 @@
> +AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel
> +
> +Required properties:
> +- compatible: should be "auo,b133htn01"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index fb0cfe2..cbbb1b8 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -41,6 +41,13 @@ struct panel_desc {
> unsigned int width;
> unsigned int height;
> } size;
> +
> + struct {
> + unsigned int prepare_stage_delay;
> + unsigned int enable_stage_delay;
> + unsigned int disable_stage_delay;
> + unsigned int unprepare_stage_delay;
> + } timing_parameter;
These are overly long in my opinion, how about:
struct {
unsigned int prepare;
unsigned int enable;
unsigned int disable;
unsigned int unprepare;
} delay;
? Oh, and this should probably mention that it's in milliseconds. On
that note, do you think we'll ever need microsecond resolution? I don't
think I've ever seen a panel datasheet mentioning that kind of
granularity.
> struct panel_simple {
> @@ -105,6 +112,8 @@ static int panel_simple_unprepare(struct drm_panel *panel)
> gpiod_set_value_cansleep(p->enable_gpio, 0);
>
> regulator_disable(p->supply);
> + if (p->desc)
Should have a blank line between "regulator_disable(...)" and "if ...".
Also it's not useful to check for p->desc, really, since it's a bug if
that is NULL.
However I think it would be good to check for the delay being set, like
so:
if (p->desc->delay.unprepare)
msleep(p->desc->delay.unprepare);
I'm not sure about the placement of the delay here, see below for more.
> @@ -142,6 +154,9 @@ static int panel_simple_prepare(struct drm_panel *panel)
> return err;
> }
>
> + if (p->desc)
> + msleep(p->desc->timing_parameter.prepare_stage_delay);
> +
> if (p->enable_gpio)
> gpiod_set_value_cansleep(p->enable_gpio, 1);
Should the delay not be *after* all steps in prepare have been
performed? That way drivers can use it to specify the time that a panel
needs to "internally" become ready after they've been power up (for
example).
>
> @@ -157,6 +172,8 @@ static int panel_simple_enable(struct drm_panel *panel)
> if (p->backlight_enabled)
> return 0;
>
> + if (p->desc)
> + msleep(p->desc->timing_parameter.enable_stage_delay);
> if (p->backlight) {
> p->backlight->props.power = FB_BLANK_UNBLANK;
> backlight_update_status(p->backlight);
I think here the delay makes sense where it is because it allows the
panel driver to wait for a given amount of time (after video data has
been sent by the display controller) until the first "good" frame is
visible.
In general I think it would be good to have a description of these in
the struct panel_desc structure, something like this perhaps:
/**
* @prepare: the time (in milliseconds) that it takes for the panel
* to become ready and start receiving video data
* @enable: the time (in milliseconds) that it takes for the panel
* to display the first valid frame after starting to
* receive video data
* @disable: the time (in milliseconds) that it takes for the panel
* to turn the display off (no content is visible)
* @unprepare: ???
*/
struct {
unsigned int prepare;
unsigned int enable;
unsigned int disable;
unsigned int unprepare;
} delay;
For prepare and enable delays this would mean that they should take
effect at the very end of the .prepare() and .enable() functions,
respectively. For disable in means that it should be at the end (for
example to take into account the time it takes for backlight to
completely turn off). For unprepare I have no idea what we would need it
for. And the new panel that you're adding in this patch doesn't use it
either, so perhaps it can just be left out (for now)?
> +static const struct panel_desc auo_b133htn01 = {
> + .modes = &auo_b133htn01_mode,
> + .num_modes = 1,
> + .size = {
> + .width = 293,
> + .height = 165,
> + },
> + .timing_parameter = {
> + .prepare_stage_delay = 105,
> + .enable_stage_delay = 20,
> + .prepare_stage_delay = 50,
I take it that this last one was supposed to be .enable_stage_delay
since you've already set up .prepare_stage_delay.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-07-30 10:51 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-25 19:22 [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support Ajay Kumar
2014-07-25 19:22 ` [PATCH V6 1/8] drm/panel: Add prepare, unprepare and get_modes routines Ajay Kumar
2014-07-30 10:00 ` Thierry Reding
2014-07-30 10:29 ` Ajay kumar
2014-07-25 19:22 ` [PATCH V6 2/8] drm/panel: Add support for prepare and unprepare routines Ajay Kumar
2014-07-30 10:32 ` Thierry Reding
2014-07-30 11:09 ` Ajay kumar
2014-07-25 19:22 ` [PATCH V6 3/8] drm/panel: simple: Add support for auo_b133htn01 panel Ajay Kumar
2014-07-30 10:51 ` Thierry Reding [this message]
2014-07-30 11:32 ` Ajay kumar
2014-07-30 13:30 ` Thierry Reding
2014-07-30 13:42 ` Ajay kumar
2014-07-25 19:22 ` [PATCH V6 4/8] drm/exynos: Move DP setup into commit() Ajay Kumar
2014-07-30 10:52 ` Thierry Reding
2014-07-30 12:05 ` Ajay kumar
2014-07-25 19:22 ` [PATCH V6 5/8] drm/exynos: dp: Modify driver to support drm_panel Ajay Kumar
2014-07-30 10:58 ` Thierry Reding
2014-07-25 19:22 ` [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model Ajay Kumar
2014-07-30 11:19 ` Thierry Reding
2014-07-30 14:31 ` Ajay kumar
2014-07-30 15:08 ` Thierry Reding
2014-07-30 16:03 ` Ajay kumar
2014-07-31 10:58 ` Thierry Reding
2014-08-22 23:33 ` Javier Martinez Canillas
2014-08-25 6:11 ` Ajay kumar
2014-08-25 10:10 ` Javier Martinez Canillas
2014-09-15 17:37 ` Laurent Pinchart
2014-09-17 9:07 ` Ajay kumar
2014-09-17 9:22 ` Dave Airlie
2014-09-17 9:27 ` Laurent Pinchart
2014-09-17 13:15 ` Ajay kumar
2014-09-22 7:40 ` Thierry Reding
2014-09-23 0:29 ` Laurent Pinchart
2014-09-23 5:36 ` Thierry Reding
2014-07-25 19:22 ` [PATCH V2 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge Ajay Kumar
2014-07-30 12:05 ` Thierry Reding
2014-07-30 15:16 ` Ajay kumar
2014-07-30 15:40 ` Thierry Reding
2014-07-30 16:14 ` Ajay kumar
2014-07-31 11:21 ` Thierry Reding
2014-07-25 19:22 ` [PATCH V6 8/8] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge Ajay Kumar
2014-07-29 11:29 ` Andreas Färber
2014-07-30 6:27 ` Ajay kumar
2014-07-30 13:11 ` Thierry Reding
2014-07-27 18:22 ` [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support Andreas Färber
2014-07-28 6:13 ` Ajay kumar
2014-07-29 11:21 ` Andreas Färber
2014-07-29 11:36 ` Thierry Reding
2014-07-29 11:42 ` Andreas Färber
2014-07-29 11:47 ` Thierry Reding
2014-07-30 6:24 ` Ajay kumar
2014-07-30 9:40 ` Thierry Reding
2014-07-30 10:24 ` Ajay kumar
2014-07-30 13:16 ` Thierry Reding
2014-09-17 9:53 ` Laurent Pinchart
2014-09-17 10:13 ` Ajay kumar
2014-09-18 9:54 ` Laurent Pinchart
2014-07-29 11:43 ` Thierry Reding
2014-07-30 6:21 ` Ajay kumar
2014-07-30 19:32 ` Andreas Färber
2014-07-31 8:38 ` Ajay kumar
2014-07-31 8:57 ` Andreas Färber
2014-07-31 10:07 ` Ajay kumar
2014-07-31 10:23 ` Thierry Reding
2014-07-31 10:28 ` Andreas Färber
2014-07-31 14:22 ` Andreas Färber
2014-08-01 7:02 ` Ajay kumar
2014-08-01 12:13 ` Andreas Färber
2014-08-01 14:57 ` Andreas Färber
2014-07-30 9:56 ` Thierry Reding
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=20140730105132.GF29590@ulmo \
--to=thierry.reding@gmail.com \
--cc=ajaykumar.rs@samsung.com \
--cc=ajaynumb@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=joshi@samsung.com \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=prashanth.g@samsung.com \
--cc=seanpaul@google.com \
/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).