[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <C5AB7166D8288A4698415C150FD56DBA22E42013@SHSMSX103.ccr.corp.intel.com>
Date: Wed, 12 Oct 2016 09:04:35 +0000
From: "Sun, Jing A" <jing.a.sun@...el.com>
To: Daniel Vetter <daniel@...ll.ch>
CC: Andrzej Hajda <a.hajda@...sung.com>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Takashi Iwai <tiwai@...e.de>,
Emil Velikov <emil.l.velikov@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"Vetter, Daniel" <daniel.vetter@...el.com>,
Thierry Reding <treding@...dia.com>
Subject: RE: [PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to
"tristate".
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.
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.
Regards,
Sun, Jing
-----Original Message-----
From: Daniel Vetter [mailto:daniel.vetter@...ll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, October 12, 2016 2:52 PM
To: Sun, Jing A
Cc: Andrzej Hajda; Jani Nikula; Takashi Iwai; Emil Velikov; linux-kernel@...r.kernel.org; dri-devel@...ts.freedesktop.org; Vetter, Daniel; Thierry Reding
Subject: Re: [PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".
On Wed, Oct 12, 2016 at 03:08:24AM +0000, Sun, Jing A wrote:
> Interestingly, I am able to reload i915 and drm. Our CI has tests for
> i915 unload/reload, but does not check drm. In any case the config
> problem should not impact the reloadability of i915.
> ======
> Sorry that I didn't make myself clear. In order to replace the default
> i915 module with an updated one, the related DRM modules also need to
> be updated to match the updated i915, hence the restriction.
Just to avoid tears in the future: If you plan to ship this in product, you won't ship.
And for debugging, just install a kernel with your changes for both drm and i915.
In short, your use-case isn't really valid (but we could still make the dsi code modular if people feel like).
-Daniel
>
> Regards,
> Sun, Jing
>
>
> -----Original Message-----
> From: Andrzej Hajda [mailto:a.hajda@...sung.com]
> Sent: Tuesday, October 11, 2016 5:53 PM
> To: Jani Nikula; Sun, Jing A; Takashi Iwai
> Cc: airlied@...ux.ie; Vetter, Daniel; linux-kernel@...r.kernel.org;
> dri-devel@...ts.freedesktop.org; Thierry Reding; Emil Velikov
> Subject: Re: [PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".
>
> On 11.10.2016 11:33, Jani Nikula wrote:
> > On Tue, 11 Oct 2016, "Sun, Jing A" <jing.a.sun@...el.com> wrote:
> >> It's needed that DRM Driver module could be removed and reloaded
> >> after kernel booting on the projects that I have been working on,
> >> and I hope such module type change could be accepted. Looks like
> >> Iwai has similar change request as well. Would you please review it
> >> and let us know if any concerns?
> > Looking at the Kconfig, selecting CONFIG_DRM_MIPI_DSI is against the
> > recommendations of Documentation/kbuild/kconfig-language.txt:
> >
> > select should be used with care. select will force
> > a symbol to a value without visiting the dependencies.
> > By abusing select you are able to select a symbol FOO even
> > if FOO depends on BAR that is not set.
> > In general use select only for non-visible symbols
> > (no prompts anywhere) and for symbols with no dependencies.
> > That will limit the usefulness but on the other hand avoid
> > the illegal configurations all over.
>
> All existing drivers which selects DRM_MIPI_DSI also depends on DRM.
> So the dependency is always true. I am not sure if it could not change
> in the future, but in such case mipi_dsi bus should be completely
> detached from DRM framework, I hope we have not such case yet :)
>
> >
> > Indeed, you may end up with CONFIG_DRM_MIPI_DSI=y and CONFIG_DRM=m,
> > which violates DRM_MIPI_DSI dependency on CONFIG_DRM. This is broken
> > and should be fixed. The suggested patch does *not* fix this issue.
>
> At the moment it should not be possible.
>
> Regards
> Andrzej
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Powered by blists - more mailing lists