From: Jani Nikula <jani.nikula@intel.com>
To: Shobhit Kumar <shobhit.kumar@intel.com>,
intel-gfx <intel-gfx@lists.freedesktop.org>
Cc: vijayakumar.balakrishnan@intel.com, yogesh.mohan.marimuthu@intel.com
Subject: Re: [PATCH 1/4] drm/i915: Add more dev ops for MIPI sub encoder
Date: Mon, 21 Oct 2013 16:27:29 +0300 [thread overview]
Message-ID: <874n8a4uv2.fsf@intel.com> (raw)
In-Reply-To: <1382358067-5578-2-git-send-email-shobhit.kumar@intel.com>
Hi Shobhit -
On Mon, 21 Oct 2013, Shobhit Kumar <shobhit.kumar@intel.com> wrote:
> Also add new fields in intel_dsi to have all dphy related parameters.
> These will be useful even when we go for pure generic MIPI design
I feel like we have a different idea of what the ideal generic design
is. For me, the goal is that we change the struct intel_dsi_device to
struct drm_bridge, and those drm_bridge drivers are all about the panel,
and have as few details about i915 or our hardware as possible. Having
the bridge drivers fill in register values to be written by the core DSI
code does not fit that. Yes, I had some of those in my bridge conversion
patches too, but I did not intend we'd keep adding more.
I'd rather we provide generic helpers the bridge driver can call.
> Yogesh Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com>
> Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 9 ++++++++-
> drivers/gpu/drm/i915/intel_dsi.h | 29 +++++++++++++++++++++++++++++
> 2 files changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
> index 9a2fdd2..34e19b7 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -147,6 +147,9 @@ static void intel_dsi_enable(struct intel_encoder *encoder)
>
> DRM_DEBUG_KMS("\n");
>
> + if (intel_dsi->dev.dev_ops->panel_reset)
> + intel_dsi->dev.dev_ops->panel_reset(&intel_dsi->dev);
Would this map to ->pre_enable in drm_bridge?
> +
> temp = I915_READ(MIPI_DEVICE_READY(pipe));
> if ((temp & DEVICE_READY) == 0) {
> temp &= ~ULPS_STATE_MASK;
> @@ -162,6 +165,9 @@ static void intel_dsi_enable(struct intel_encoder *encoder)
> I915_WRITE(MIPI_DEVICE_READY(pipe), temp);
> }
>
> + if (intel_dsi->dev.dev_ops->send_otp_cmds)
> + intel_dsi->dev.dev_ops->send_otp_cmds(&intel_dsi->dev);
What is otp? one time programming? Why not in ->enable?
> +
> if (is_cmd_mode(intel_dsi))
> I915_WRITE(MIPI_MAX_RETURN_PKT_SIZE(pipe), 8 * 4);
>
> @@ -176,7 +182,8 @@ static void intel_dsi_enable(struct intel_encoder *encoder)
> POSTING_READ(MIPI_PORT_CTRL(pipe));
> }
>
> - intel_dsi->dev.dev_ops->enable(&intel_dsi->dev);
> + if (intel_dsi->dev.dev_ops->enable)
> + intel_dsi->dev.dev_ops->enable(&intel_dsi->dev);
> }
>
> static void intel_dsi_disable(struct intel_encoder *encoder)
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
> index c7765f3..b71c9b3 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -39,6 +39,13 @@ struct intel_dsi_device {
> struct intel_dsi_dev_ops {
> bool (*init)(struct intel_dsi_device *dsi);
>
> + void (*panel_reset)(struct intel_dsi_device *dsi);
> +
> + void (*disable_panel_power)(struct intel_dsi_device *dsi);
What is the enabling counterpart to disable_panel_power? panel_reset?
> +
> + /* send one time programmable commands */
> + void (*send_otp_cmds)(struct intel_dsi_device *dsi);
> +
> /* This callback must be able to assume DSI commands can be sent */
> void (*enable)(struct intel_dsi_device *dsi);
>
> @@ -89,6 +96,28 @@ struct intel_dsi {
>
> /* eot for MIPI_EOT_DISABLE register */
> u32 eot_disable;
> +
> + u16 dsi_clock_freq;
> + u8 video_mode_type;
> + u32 data_width;
> + u8 dither;
> + u32 port_bits;
> + u8 escape_clk_div;
> + u32 lp_rx_timeout;
> + u8 turn_arnd_val;
> + u16 init_count;
> + u16 rst_timer_val;
> + u16 hs_to_lp_count;
> + u16 lp_byte_clk;
> + u32 bw_timer;
> + u16 clk_lp_to_hs_count;
> + u16 clk_hs_to_lp_count;
> + u32 video_frmt_cfg_bits;
> + u32 dphy_reg;
> +
> + u8 backlight_off_delay; /*in ms*/
> + bool send_shutdown;
> + u8 shutdown_pkt_delay; /*in ms*/
> };
>
> static inline struct intel_dsi *enc_to_intel_dsi(struct drm_encoder *encoder)
> --
> 1.7.9.5
>
--
Jani Nikula, Intel Open Source Technology Center
next prev parent reply other threads:[~2013-10-21 13:25 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-21 12:21 [PATCH 0/4] drm/i915: Baytrail MIPI DSI support Updated Shobhit Kumar
2013-10-21 12:21 ` [PATCH 1/4] drm/i915: Add more dev ops for MIPI sub encoder Shobhit Kumar
2013-10-21 13:27 ` Jani Nikula [this message]
2013-10-22 9:39 ` Shobhit Kumar
2013-10-22 11:53 ` Jani Nikula
2013-10-23 12:52 ` Shobhit Kumar
2013-10-23 14:22 ` Jani Nikula
2013-10-24 8:01 ` Shobhit Kumar
2013-10-24 8:24 ` Jani Nikula
2013-10-24 12:13 ` Shobhit Kumar
2013-10-21 12:21 ` [PATCH 2/4] drm/i915: Use FLISDSI interface for band gap reset Shobhit Kumar
2013-10-21 13:30 ` Jani Nikula
2013-10-21 12:21 ` [PATCH 3/4] drm/i915: Compute dsi_clk from pixel clock Shobhit Kumar
2013-10-21 13:28 ` Ville Syrjälä
2013-10-22 9:15 ` Shobhit Kumar
2013-10-21 13:44 ` Jani Nikula
2013-10-22 9:25 ` Shobhit Kumar
2013-10-21 12:21 ` [PATCH 4/4] drm/i915: Parameterize the MIPI enabling sequnece and adjust the sequence Shobhit Kumar
2013-10-21 13:23 ` Ville Syrjälä
2013-10-22 9:06 ` Shobhit Kumar
2013-10-22 10:49 ` Ville Syrjälä
2013-10-23 12:57 ` Shobhit Kumar
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=874n8a4uv2.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=shobhit.kumar@intel.com \
--cc=vijayakumar.balakrishnan@intel.com \
--cc=yogesh.mohan.marimuthu@intel.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