From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Sun\, Jing A" <jing.a.sun@intel.com>, Daniel Vetter <daniel@ffwll.ch>
Cc: Andrzej Hajda <a.hajda@samsung.com>, Takashi Iwai <tiwai@suse.de>,
Emil Velikov <emil.l.velikov@gmail.com>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dri-devel\@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>, "Vetter\,
Daniel" <daniel.vetter@intel.com>,
Thierry Reding <treding@nvidia.com>
Subject: RE: [PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".
Date: Wed, 12 Oct 2016 13:52:46 +0300 [thread overview]
Message-ID: <87h98hyh35.fsf@intel.com> (raw)
In-Reply-To: <C5AB7166D8288A4698415C150FD56DBA22E42013@SHSMSX103.ccr.corp.intel.com>
On Wed, 12 Oct 2016, "Sun, Jing A" <jing.a.sun@intel.com> wrote:
> I think "installing a kernel with my changes for both drm and i915"
> takes more time and effort to complete than "only updating DRM/i915
> modules without rebuilding the whole kernel". In some cases, that's
> beneficial.
It's possible to change and rebuild and update just the drm and i915,
but you need to be careful to build against the same tree as the ones
you are replacing. This is like using out-of-tree modules (which is
something I can't recommend no matter what, but that's another
discussion).
However, this is completely different from planning to update drm and
i915 modules on a running production system by unloading the old ones
and probing the new ones. Don't do that. It will be a disaster.
> Also reloadablility is always a good thing to have and I truly hope
> Hajda/Iwai's patches would be accepted and merged. No downside of it
> after all.
I think it's good to be able to unload and reload modules for debugging
and development, but not for normal use.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
next prev parent reply other threads:[~2016-10-12 10:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-10 7:31 [PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate" Sun, Jing A
2016-10-10 8:28 ` Jani Nikula
2016-10-10 9:57 ` Takashi Iwai
2016-10-11 8:40 ` Sun, Jing A
2016-10-11 9:17 ` Andrzej Hajda
2016-10-11 9:33 ` Jani Nikula
2016-10-11 9:53 ` Andrzej Hajda
2016-10-12 3:08 ` Sun, Jing A
2016-10-12 6:51 ` Daniel Vetter
2016-10-12 9:04 ` Sun, Jing A
2016-10-12 10:52 ` Jani Nikula [this message]
2016-10-12 11:28 ` Emil Velikov
2016-10-12 14:28 ` Jani Nikula
2016-10-20 13:20 ` Andrzej Hajda
2016-10-20 13:44 ` Jani Nikula
2016-10-21 12:19 ` Daniel Vetter
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=87h98hyh35.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=a.hajda@samsung.com \
--cc=daniel.vetter@intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
--cc=jing.a.sun@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tiwai@suse.de \
--cc=treding@nvidia.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