Hi, On Tue, Feb 25, 2020 at 07:42:37AM -0800, Tony Lindgren wrote: > * Sebastian Reichel <sre@xxxxxxxxxx> [200225 02:29]: > > On Mon, Feb 24, 2020 at 04:10:11PM -0800, Tony Lindgren wrote: > > > BTW, I think there's also some refcount issue in general where > > > the omapdrm related modules cannot be unloaded any longer? > > > > I wouldn't be too surprised. The dependencies are quite interesting > > at the moment with omapdss registering omapdrm and then omapdrm > > registers the drm_device, which references the encoders from > > omapdss. I think this is something to look at once Laurent's and > > my branch have been merged to avoid increasing the complexity. > > Technically it should be possible to link everything into one > > module. > > Well the DSS is really DOSSI for Display Output SubSystem > Interconnect :) The devices on the interconnect are mostly > independent and ideally the toplevel dss driver would just > provide Linux generic resources to dispc and various output > drivers. So probably not a good idea to try to build it all > into a single module. All the output drivers and dispc are already in a single module: omapdss.ko. There is omapdss-base.ko, omapdss.ko and omapdrm.ko module. omapdss-base.ko contains a few helpers, omapdss.ko contains dispc and all output encoders, omapdrm has the tiler code and wraps some of the custom DSS APIs to DRM APIs. I think the best way forward is to eliminate the custom API and use common DRM APIs directly. Then merge all 3 modules into one module. In theory one could add modules for each encoder, but practically this only increases complexity. DRM cannnot hotplug encoders, so removing any module results in complete loss of DRM. Also during probe we need to load all modules, since something might be connected. So having extra modules is not really useful? -- Sebastian
Attachment:
signature.asc
Description: PGP signature
