All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Hans de Goede" <hdegoede@redhat.com>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 09/18] drm/i915/dsi: Make intel_dsi_enable/disable directly exec VBT sequences
Date: Fri, 02 Dec 2016 16:01:24 +0200	[thread overview]
Message-ID: <87d1hazayz.fsf@intel.com> (raw)
In-Reply-To: <5ec68620-1bdf-8a96-f6b6-9303a6d0fbc8@redhat.com>

On Fri, 02 Dec 2016, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 02-12-16 11:31, Jani Nikula wrote:
>> On Thu, 01 Dec 2016, Hans de Goede <hdegoede@redhat.com> wrote:
>>> The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are
>>> not fine grained enough to abstract all the different steps we need to
>>> take (and VBT sequences we need to exec) properly. So simply remove the
>>> panel _enable/disable and prepare/unprepare callbacks and instead
>>> export intel_dsi_exec_vbt_sequence() from intel_dsi_panel_vbt.c
>>> and call that from intel_dsi_enable/disable().
>>>
>>> No functional changes.
>>
>> No functional changes, but this is quite a big design change between
>> intel_dsi.c and intel_dsi_panel_vbt.c.
>
> True, I did this because adding a callback per init step to the
> drm_panel interface felt like it will result in a game of
> whack a mole (adding more and more callbacks). See the end of
> this mail for a proposal with leaves the drm_panel interface
> in place, while also avoiding this problem.
>
>> Originally the idea was to
>> separate the dsi core code and the panel specific code, letting one
>> write a panel driver that was not based on values in VBT. This patch
>> changes that.
>
> I see, I was not aware of this history.
>
>> Now I'm not sure if there'll ever be a panel driver not based on VBT,
>> and perhaps the current drm_panel based interface between two is not
>> enough in the end, nor prettiest. But after this patch, we might just as
>> well throw out the drm_panel interface, and refactor the division
>> between the two files completely. Indeed, if we accept the direction set
>> in this patch, that refactoring would be the logical next step.
>
> Is intel_dsi.c the only user of the drm_panel interface ? The name
> suggests it is not intel specific.

Just a quick note here, it's not i915 specific, it's used in other
drivers.

BR,
Jani.

>
>> I have not made up my mind about this yet. An alternative would be to
>> amend the drm_panel interface to achieve the kind of granularity you're
>> after in the follow-up patches. Indeed, such patches have been sent in
>> the past.
>
> How about we add a "drm_panel_exec_sequence" callback to the
> drm_panel interface, which takes an enum argument which (de)init
> step to do ?
>
> Then we can easily add extra init steps later by extending the
> enum, and panel implementations which do not care about certain
> steps can simply treat these as nops. This avoids the need
> to add a ton of callbacks to the drm_panel struct.
>
> If there are no other users, we could then also remove the
> enable/disable and prepare/unprepare pairs from drm_panel
> now, I left those in place assuming that intel_dsi.c was
> not the only user of drm_panel.
>
> Regards,
>
> Hans
>
>
>
>
>>
>> BR,
>> Jani.
>>
>>>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>> ---
>>>  drivers/gpu/drm/i915/intel_dsi.c           | 14 +++++++---
>>>  drivers/gpu/drm/i915/intel_dsi.h           |  3 +++
>>>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 43 ++----------------------------
>>>  3 files changed, 15 insertions(+), 45 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
>>> index 85b748d..cf761e8 100644
>>> --- a/drivers/gpu/drm/i915/intel_dsi.c
>>> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>>> @@ -656,7 +656,10 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder,
>>>  	/* put device in ready state */
>>>  	intel_dsi_device_ready(encoder);
>>>
>>> -	drm_panel_prepare(intel_dsi->panel);
>>> +	intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
>>> +	intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
>>> +	intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
>>> +	intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP);
>>>
>>>  	/* Enable port in pre-enable phase itself because as per hw team
>>>  	 * recommendation, port should be enabled befor plane & pipe */
>>> @@ -669,7 +672,8 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder,
>>>  			dpi_send_cmd(intel_dsi, TURN_ON, false, port);
>>>  		msleep(100);
>>>
>>> -		drm_panel_enable(intel_dsi->panel);
>>> +		intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
>>> +		intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
>>>
>>>  		intel_dsi_port_enable(encoder);
>>>  	}
>>> @@ -732,7 +736,8 @@ static void intel_dsi_post_disable(struct intel_encoder *encoder,
>>>  	 * if disable packets are sent before sending shutdown packet then in
>>>  	 * some next enable sequence send turn on packet error is observed
>>>  	 */
>>> -	drm_panel_disable(intel_dsi->panel);
>>> +	intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
>>> +	intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
>>>
>>>  	intel_dsi_clear_device_ready(encoder);
>>>
>>> @@ -746,7 +751,8 @@ static void intel_dsi_post_disable(struct intel_encoder *encoder,
>>>  		I915_WRITE(DSPCLK_GATE_D, val);
>>>  	}
>>>
>>> -	drm_panel_unprepare(intel_dsi->panel);
>>> +	intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
>>> +	intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_OFF);
>>>
>>>  	msleep(intel_dsi->panel_off_delay);
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
>>> index d567823..5486491 100644
>>> --- a/drivers/gpu/drm/i915/intel_dsi.h
>>> +++ b/drivers/gpu/drm/i915/intel_dsi.h
>>> @@ -132,6 +132,9 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct drm_encoder *encoder)
>>>
>>>  void wait_for_dsi_fifo_empty(struct intel_dsi *intel_dsi, enum port port);
>>>
>>> +void intel_dsi_exec_vbt_sequence(struct intel_dsi *intel_dsi,
>>> +				 enum mipi_seq seq_id);
>>> +
>>>  bool intel_dsi_pll_is_enabled(struct drm_i915_private *dev_priv);
>>>  int intel_compute_dsi_pll(struct intel_encoder *encoder,
>>>  			  struct intel_crtc_state *config);
>>> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>>> index b5a02c6..f71f913 100644
>>> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>>> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>>> @@ -400,10 +400,9 @@ static const char *sequence_name(enum mipi_seq seq_id)
>>>  		return "(unknown)";
>>>  }
>>>
>>> -static void generic_exec_sequence(struct drm_panel *panel, enum mipi_seq seq_id)
>>> +void intel_dsi_exec_vbt_sequence(struct intel_dsi *intel_dsi,
>>> +				 enum mipi_seq seq_id)
>>>  {
>>> -	struct vbt_panel *vbt_panel = to_vbt_panel(panel);
>>> -	struct intel_dsi *intel_dsi = vbt_panel->intel_dsi;
>>>  	struct drm_i915_private *dev_priv = to_i915(intel_dsi->base.base.dev);
>>>  	const u8 *data;
>>>  	fn_mipi_elem_exec mipi_elem_exec;
>>> @@ -467,40 +466,6 @@ static void generic_exec_sequence(struct drm_panel *panel, enum mipi_seq seq_id)
>>>  	}
>>>  }
>>>
>>> -static int vbt_panel_prepare(struct drm_panel *panel)
>>> -{
>>> -	generic_exec_sequence(panel, MIPI_SEQ_ASSERT_RESET);
>>> -	generic_exec_sequence(panel, MIPI_SEQ_POWER_ON);
>>> -	generic_exec_sequence(panel, MIPI_SEQ_DEASSERT_RESET);
>>> -	generic_exec_sequence(panel, MIPI_SEQ_INIT_OTP);
>>> -
>>> -	return 0;
>>> -}
>>> -
>>> -static int vbt_panel_unprepare(struct drm_panel *panel)
>>> -{
>>> -	generic_exec_sequence(panel, MIPI_SEQ_ASSERT_RESET);
>>> -	generic_exec_sequence(panel, MIPI_SEQ_POWER_OFF);
>>> -
>>> -	return 0;
>>> -}
>>> -
>>> -static int vbt_panel_enable(struct drm_panel *panel)
>>> -{
>>> -	generic_exec_sequence(panel, MIPI_SEQ_DISPLAY_ON);
>>> -	generic_exec_sequence(panel, MIPI_SEQ_BACKLIGHT_ON);
>>> -
>>> -	return 0;
>>> -}
>>> -
>>> -static int vbt_panel_disable(struct drm_panel *panel)
>>> -{
>>> -	generic_exec_sequence(panel, MIPI_SEQ_BACKLIGHT_OFF);
>>> -	generic_exec_sequence(panel, MIPI_SEQ_DISPLAY_OFF);
>>> -
>>> -	return 0;
>>> -}
>>> -
>>>  static int vbt_panel_get_modes(struct drm_panel *panel)
>>>  {
>>>  	struct vbt_panel *vbt_panel = to_vbt_panel(panel);
>>> @@ -524,10 +489,6 @@ static int vbt_panel_get_modes(struct drm_panel *panel)
>>>  }
>>>
>>>  static const struct drm_panel_funcs vbt_panel_funcs = {
>>> -	.disable = vbt_panel_disable,
>>> -	.unprepare = vbt_panel_unprepare,
>>> -	.prepare = vbt_panel_prepare,
>>> -	.enable = vbt_panel_enable,
>>>  	.get_modes = vbt_panel_get_modes,
>>>  };
>>

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-12-02 14:01 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-01 20:29 [PATCH 00/18] drm/i915/dsi: Fix / cleanup dsi enable / disable sequences Hans de Goede
2016-12-01 20:29 ` [PATCH 01/18] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET Hans de Goede
2016-12-02 12:37   ` Ville Syrjälä
2016-12-02 13:34     ` Hans de Goede
2016-12-02 13:45       ` Ville Syrjälä
2016-12-01 20:29 ` [PATCH 02/18] drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting Hans de Goede
2016-12-07 17:48   ` Ville Syrjälä
2016-12-07 17:48     ` Ville Syrjälä
2016-12-01 20:29 ` [PATCH 03/18] drm/i915/dsi: Move calling of wait_for_dsi_fifo_empty to mipi_exec_send_packet Hans de Goede
2016-12-01 20:29 ` [PATCH 04/18] drm/i915/dsi: Merge intel_dsi_disable/enable into their respective callers Hans de Goede
2016-12-01 20:29 ` [PATCH 05/18] drm/i915/dsi: Add intel_dsi_unprepare() helper Hans de Goede
2016-12-01 20:29 ` [PATCH 06/18] drm/i915/dsi: Move disable pll call outside of clear_device_ready() Hans de Goede
2016-12-23 13:35   ` Jani Nikula
2016-12-01 20:29 ` [PATCH 07/18] drm/i915/dsi: Move intel_dsi_clear_device_ready() Hans de Goede
2016-12-01 20:29 ` [PATCH 08/18] drm/i915/dsi: Document the panel enable / disable sequences from the spec Hans de Goede
2016-12-02 10:31   ` Jani Nikula
2016-12-01 20:29 ` [PATCH 09/18] drm/i915/dsi: Make intel_dsi_enable/disable directly exec VBT sequences Hans de Goede
2016-12-02 10:31   ` Jani Nikula
2016-12-02 13:44     ` Hans de Goede
2016-12-02 14:01       ` Jani Nikula [this message]
2016-12-01 20:29 ` [PATCH 10/18] drm/i915/dsi: Drop bogus MIPI_SEQ_ASSERT_RESET before POWER_ON Hans de Goede
2016-12-01 20:29 ` [PATCH 11/18] drm/i915/dsi: Move MIPI_SEQ_POWER_ON/OFF calls together with pmic gpio calls Hans de Goede
2016-12-01 20:29 ` [PATCH 12/18] drm/i915/dsi: Group DPOunit clock gate workaround with PLL enable Hans de Goede
2016-12-01 20:29 ` [PATCH 13/18] drm/i915/dsi: Execute MIPI_SEQ_DEASSERT_RESET before calling device_ready() Hans de Goede
2016-12-01 20:29 ` [PATCH 14/18] drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlight Hans de Goede
2016-12-01 20:29 ` [PATCH 15/18] drm/i915/dsi: Document always using v3 SHUTDOWN / MIPI_SEQ_DISPLAY_OFF order Hans de Goede
2016-12-01 20:29 ` [PATCH 16/18] drm/i915/dsi: Execute MIPI_SEQ_TEAR_OFF from intel_dsi_post_disable Hans de Goede
2016-12-01 20:29 ` [PATCH 17/18] drm/i915/dsi: Call MIPI_SEQ_TEAR_ON and DISPLAY_ON for cmd-mode (untested) Hans de Goede
2016-12-01 20:29 ` [PATCH 18/18] drm/i915/dsi: Skip delays for v3 VBTs in vid-mode Hans de Goede

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=87d1hazayz.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hdegoede@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.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 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.