All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 09/10] drm/i915/uc: Separate firmware selection and preparation
Date: Thu, 2 Mar 2017 12:53:27 +0100	[thread overview]
Message-ID: <20170302115326.GB1444@ahiler-desk.igk.intel.com> (raw)
In-Reply-To: <20170224182957.GF103056@mwajdecz-MOBL1.ger.corp.intel.com>

On Fri, Feb 24, 2017 at 07:29:57PM +0100, Michal Wajdeczko wrote:
> On Fri, Feb 24, 2017 at 04:40:03PM +0100, Arkadiusz Hiler wrote:
> > intel_{h,g}uc_init_fw selects correct firmware and then triggers it's
> > preparation (fetch + initial parsing).
> > 
> > This change separates out select steps, so those can be called by
> > the sanitize_options().
> > 
> > Then, during the init_fw() we prepare the firmware if the firmware was
> > selected.
> > 
> > Cc: Michal Winiarski <michal.winiarski@intel.com>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
> > ---
> 
> It looks strange that in one series you're changing function names
> or their logic few times ... patch ordering really matters ;)

Is this really that bad? I do not see that much disadvantage to the
current state.

I am seeing the series as a whole. Titles of the commits are pretty
informative (and you have them both in you email client when you are
viewing the whole thread, and in the cover letter) - e.g. you can see that
one of the later commits reworks firmware path handling, and can assume
that the previous changes to that code were intermediary (changing
argument it takes and removing one or two checks as they are now on the
level above).

As of the name changes - those follow a pattern.

If I went with the original name until the final change it looks
inconsistent, and quite probably someone would've commented on that.

If I have had used the final names straight away that would be simply
misleading (in case of intel_guc_init -> init_fw -> select_fw).

> Please consider reorder/squash.

I've tried to rebase with squashing and resplitting two times, and what
I came with was pretty similar to the current series.

But I might have hard-wired my brain to follow those exact steps,
therefore the repetition...

If you have any suggestion how to do that properly, keeping changes
small, logical and ordered please share. I'd love to learn how to make
my series less painful for future reviewers.

-- 
Cheers,
Arek
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-03-02 11:53 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-24 15:39 [PATCH v5 00/10] GuC Scrub vol. 1 Arkadiusz Hiler
2017-02-24 15:39 ` [PATCH 01/10] drm/i915/uc: Rename intel_?uc_{setup, load}() to _init_hw() Arkadiusz Hiler
2017-02-24 15:39 ` [PATCH 02/10] drm/i915/uc: Drop superfluous externs in intel_uc.h Arkadiusz Hiler
2017-02-24 15:39 ` [PATCH 03/10] drm/i915/huc: Add huc_to_i915 Arkadiusz Hiler
2017-02-24 15:39 ` [PATCH 04/10] drm/i915/uc: Move intel_uc_fw_fetch() to intel_uc.c Arkadiusz Hiler
2017-02-24 16:28   ` Michal Wajdeczko
2017-02-27 12:36     ` [PATCH v2] " Arkadiusz Hiler
2017-02-24 15:39 ` [PATCH 05/10] drm/i915/uc: Introduce intel_uc_init_fw() Arkadiusz Hiler
2017-02-24 16:39   ` Michal Wajdeczko
2017-02-27 12:09   ` Joonas Lahtinen
2017-02-24 15:40 ` [PATCH 06/10] drm/i915/guc: Extract param logic form guc_init_fw() Arkadiusz Hiler
2017-02-24 16:55   ` Michal Wajdeczko
2017-02-27 12:50     ` [PATCH v5] " Arkadiusz Hiler
2017-03-01 12:18       ` Joonas Lahtinen
2017-02-24 15:40 ` [PATCH 07/10] drm/i915/guc: Simplify intel_guc_init_hw() Arkadiusz Hiler
2017-02-24 17:26   ` Michal Wajdeczko
2017-02-27 15:48     ` Arkadiusz Hiler
2017-02-24 15:40 ` [PATCH 08/10] drm/i915/uc: Simplify firmware path handling Arkadiusz Hiler
2017-02-24 17:46   ` Michal Wajdeczko
2017-02-24 15:40 ` [PATCH 09/10] drm/i915/uc: Separate firmware selection and preparation Arkadiusz Hiler
2017-02-24 18:29   ` Michal Wajdeczko
2017-03-02 11:53     ` Arkadiusz Hiler [this message]
2017-02-27 12:23   ` Joonas Lahtinen
2017-02-24 15:40 ` [PATCH 10/10] drm/i915/uc: Add params for specifying firmware Arkadiusz Hiler
2017-02-24 18:44   ` Michal Wajdeczko
2017-02-27 12:39   ` Joonas Lahtinen
2017-02-27 13:30     ` Jani Nikula
2017-02-24 16:02 ` ✗ Fi.CI.BAT: failure for GuC Scrub vol. 1 (rev5) Patchwork
2017-02-27 14:02 ` ✗ Fi.CI.BAT: failure for GuC Scrub vol. 1 (rev7) Patchwork
2017-03-02 16:03 [PATCH v6 00/10] GuC Scrub vol. 1 Arkadiusz Hiler
2017-03-02 16:03 ` [PATCH 09/10] drm/i915/uc: Separate firmware selection and preparation Arkadiusz Hiler
2017-03-07 15:24 [PATCH v7 00/10] GuC Scrub vol. 1 Arkadiusz Hiler
2017-03-07 15:24 ` [PATCH 09/10] drm/i915/uc: Separate firmware selection and preparation Arkadiusz Hiler

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=20170302115326.GB1444@ahiler-desk.igk.intel.com \
    --to=arkadiusz.hiler@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=michal.wajdeczko@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.