All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 0/7] drm/i915: Move some load time init steps earlier
Date: Fri, 11 Mar 2016 15:59:09 +0200	[thread overview]
Message-ID: <87twkdnmj6.fsf@intel.com> (raw)
In-Reply-To: <20160309160357.GK1405@nuc-i3427.alporthouse.com>

On Wed, 09 Mar 2016, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Wed, Mar 09, 2016 at 05:31:39PM +0200, Imre Deak wrote:
>> While working on the CDCLK init code I realized that the driver load time
>> dependencies between the different init steps are rather difficult to follow
>> and so it's not obvious where some new piece of initialization needs to be
>> added.
>> 
>> Also because some things are initialized too late, other steps depending on
>> these must be initialized in a non-logical place or even split into multiple
>> parts. One example is the CDCLK initialization which needs the display
>> callbacks to be set already, but those callbacks are setup only late, so the
>> CDCLK initialization must be done in two parts.
>> 
>> As a generic solution, I suggest that we define the following load
>> time init phases:
>> - state init not requiring device access
>>   (i.e SW only, like initializing locks, allocating system memory, setting
>>    up callbacks, device attributes)
>> - minimal HW setup to enable MMIO access to the device
>> - state init requiring device access w/o side effects
>>   (i.e. read-only HW access, no interface registrations)
>> - state init causing device-wide side effects
>>   (i.e any HW access, no interface registration)
>> - registering all interfaces
>
> On paper sounds goods. The only complaint I have is that we have only
> nomenclature for 2 phases: init and init_hw. To be compelling I want
> consistent names for each init function so that we know at a glance what
> phase we are in, and the expectations/limitations upon the function.
>
> init_early() / setup()
> init_mmio()
> init_late()
> init_hw()

Agreed.

>
>> This patchset adds the corresponding comment markers for the first
>> two phases above and one common phase for the rest of the current
>> init steps. Later we could also add the last three init phases above
>> and restructure the code accordingly.
>> 
>> For now I only moved earlier a few obvious init steps that fit these
>> new phases.
>> 
>> I smoke tested this on GEN4, SNB, BXT.
>> 
>> Imre Deak (7):
>>   drm/i915: Add comments marking the start of load time init phases
>>   drm/i915: Move laod time PCH detect, DPIO, power domain SW init
>>     earlier
>>   drm/i915: Move load time IRQ SW init earlier
>>   drm/i915: Move load time display/audio callback init earlier
>>   drm/i915: Move load time clock gating callback init earlier
>>   drm/i915: Move load time runtime device info init earlier
>>   drm/i915: Move load time runtime PM get later
>
> Lgtm.
> -Chris

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

      parent reply	other threads:[~2016-03-11 13:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-09 15:31 [PATCH 0/7] drm/i915: Move some load time init steps earlier Imre Deak
2016-03-09 15:31 ` [PATCH 1/7] drm/i915: Add comments marking the start of load time init phases Imre Deak
2016-03-09 15:31 ` [PATCH 2/7] drm/i915: Move laod time PCH detect, DPIO, power domain SW init earlier Imre Deak
2016-03-09 15:31 ` [PATCH 3/7] drm/i915: Move load time IRQ " Imre Deak
2016-03-09 15:31 ` [PATCH 4/7] drm/i915: Move load time display/audio callback " Imre Deak
2016-03-09 17:14   ` kbuild test robot
2016-03-10  8:58   ` Ander Conselvan De Oliveira
2016-03-10 11:24     ` Imre Deak
2016-03-11 14:00   ` Jani Nikula
2016-03-11 14:17     ` Imre Deak
2016-03-09 15:31 ` [PATCH 5/7] drm/i915: Move load time clock gating " Imre Deak
2016-03-09 15:57   ` Chris Wilson
2016-03-09 16:01     ` Imre Deak
2016-03-09 16:09       ` Chris Wilson
2016-03-09 15:31 ` [PATCH 6/7] drm/i915: Move load time runtime device info " Imre Deak
2016-03-09 15:31 ` [PATCH 7/7] drm/i915: Move load time runtime PM get later Imre Deak
2016-03-09 16:02 ` ✗ Fi.CI.BAT: warning for drm/i915: Move some load time init steps earlier Patchwork
2016-03-09 16:03 ` [PATCH 0/7] " Chris Wilson
2016-03-10 18:37   ` Imre Deak
2016-03-11 13:59   ` Jani Nikula [this message]

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=87twkdnmj6.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.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 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.