From: Imre Deak <imre.deak@intel.com>
To: "chris@chris-wilson.co.uk" <chris@chris-wilson.co.uk>
Cc: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Subject: Re: [PATCH] drm/i915/dmc: Accept symbolic link in firmware name
Date: Mon, 11 Jul 2016 15:45:21 +0300 [thread overview]
Message-ID: <1468241121.30897.15.camel@intel.com> (raw)
In-Reply-To: <20160711123906.GD6157@nuc-i3427.alporthouse.com>
On ma, 2016-07-11 at 13:39 +0100, chris@chris-wilson.co.uk wrote:
> On Mon, Jul 11, 2016 at 02:23:48PM +0300, Imre Deak wrote:
> > On to, 2016-07-07 at 17:57 +0300, Mika Kuoppala wrote:
> > > "Vivi, Rodrigo" <rodrigo.vivi@intel.com> writes:
> > >
> > > > Nak.
> > > >
> > > > I don't intend to update the symbolic links on linux-
> > > > firmware.git
> > > > repository anymore so if we receive a new minor version update
> > > > we
> > > > are
> > > > not going to load.
> > > >
> > > > I was the one advocating in the favor for the symbolic link
> > > > flexibility
> > > > but I lost the discussions for the stability and validation
> > > > etc.
> > > >
> > >
> > > And I was one advocating in favor of getting rid of symlink. But
> > > the
> > > filename versioning is superfluous as the contents has the
> > > version
> > > info
> > > which we can solely rely to not run something we dont want.
> > >
> > > So I am not sure what we lose in stability and validation front
> > > with the strict version check.
> >
> > Bisection is more cumbersome with a symlink.
>
> Did you miss a without there? Because when bisecting the kernel it's
> harder without the symlink as the build breaks otherwise and the
> runtime
> is not bisectable either.
No, I meant when bisecting we also want to load the proper fw version
for each bisect commit point. So using exact filenames we'll
automatically load the proper firmware file for a given commit, whereas
with symlinks we have to adjust the symlink at each bisect step.
You need to have all the required FW versions for the bisect range to
be present on the filesystem of course.
--Imre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-07-11 12:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-05 9:25 [PATCH] drm/i915/dmc: Accept symbolic link in firmware name Mika Kuoppala
2016-07-05 9:58 ` ✗ Ro.CI.BAT: failure for " Patchwork
2016-07-06 17:31 ` [PATCH] " Vivi, Rodrigo
2016-07-07 14:57 ` Mika Kuoppala
2016-07-07 23:47 ` Vivi, Rodrigo
2016-07-11 11:23 ` Imre Deak
2016-07-11 12:39 ` chris
2016-07-11 12:45 ` Imre Deak [this message]
2016-07-11 12:55 ` chris
2016-07-11 13:24 ` Imre Deak
2016-07-11 13:50 ` chris
2016-07-11 14:01 ` Imre Deak
2016-07-19 21:58 ` Herbert, Marc
2016-07-19 22:39 ` Vivi, Rodrigo
2016-07-21 13:32 ` Imre Deak
2016-08-01 13:24 ` Jani Nikula
2016-08-03 6:00 ` Vivi, Rodrigo
2016-08-03 7:25 ` Daniel Vetter
2016-08-03 9:45 ` Jani Nikula
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=1468241121.30897.15.camel@intel.com \
--to=imre.deak@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=rodrigo.vivi@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