All of lore.kernel.org
 help / color / mirror / Atom feed
From: Inki Dae <inki.dae@samsung.com>
To: "Andreas Färber" <afaerber@suse.de>
Cc: Kukjin Kim <kgene.kim@samsung.com>,
	Seung-Woo Kim <sw0312.kim@samsung.com>,
	Sjoerd Simons <sjoerd.simons@collabora.co.uk>,
	dri-devel@lists.freedesktop.org,
	Kyungmin Park <kyungmin.park@samsung.com>,
	linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH 0/3] drm/exynos: Allow module to be autoloaded
Date: Tue, 29 Jul 2014 21:29:51 +0900	[thread overview]
Message-ID: <53D793BF.8070603@samsung.com> (raw)
In-Reply-To: <53D78CB7.6010806@suse.de>

On 2014년 07월 29일 20:59, Andreas Färber wrote:
> Am 29.07.2014 10:05, schrieb Sjoerd Simons:
>> On Tue, 2014-07-29 at 14:38 +0900, Inki Dae wrote:
>>> On 2014년 07월 28일 23:45, Sjoerd Simons wrote:
>>>> On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote:
>>>>> On 2014년 07월 28일 17:30, Sjoerd Simons wrote:
>>>>> I don't see why Exynos drm driver should be auto-loaded module. I think
>>>>> all devices covered by Exynos drm framework are not hot-plugged. Maybe
>>>>> there is my missing point. So can you explain why Exynos drm driver
>>>>> should be auto-loaded module?
>>>>
>>>> The background for this is that I'm building a distribution-style
>>>> multiplatform kernel, that is to say a kernel which can boot on a big
>>>> set of different ARM boards. As such, the intention is to keep the core
>>>> zImage as small as possible and essentially build things as far as
>>>> possible as loadable modules. So in a sense, all of the hardware is
>>>> "hotplugged", depending on which board the kernel is actually booted on!
>>>>
>>>> For that use-case, exynosdrm needs to be able to build as a module
>>>> (which it already can!) and it needs the required meta-data for
>>>> userspace to know when it should be loaded. The latter is what my patch
>>>> adds. 
>>>
>>> It seems that you want that module data of sub drivers are added by
>>> depmod to /lib/modules/KERNEL_VERSION/modules.xxxmap because some
>>> hot-plug system should use modules.xxxmap file to find the proper driver
>>> to load.
>>
>> Yes. I would like the module to export its module alias information for
>> the subdrivers such that depmod can add it to its databases and the
>> normal module autoloading mechanisms work as intended. Note that in my
>> case, "some hot-plug" system is really just udev, not something
>> special..
> 
> +1 here.
> 
> While I haven't tested this on my Exynos devices yet since I'm still
> working on -next kernels there, here's an example of such a 3.16 config:
> 
> http://kernel.opensuse.org/cgit/kernel-source/tree/config/armv7hl/default
> 
> Of the platforms enabled, all drivers are configured as modules where
> possible, to keep kernel size small, and dracut (or kiwi) is used to
> generate an initrd that makes available the modules.
> 
> So it would certainly be good to have the DRM auto-load somehow, without
> the user having to manually touch config files. In particular when I
> think of the Chromebooks, where Wifi needs configuration on first boot
> and no serial console is accessible.

Got it. will merge them. However, I'm not sure that Exynos drm should
have hot-plug feature such as PCI base devices: all devices covered by
Exynos drm framework cannot attached and detached to and from machine.

Thanks,
Inki Dae



> 
> Regards,
> Andreas
> 

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2014-07-29 12:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-18 20:36 [PATCH 0/3] drm/exynos: Allow module to be autoloaded Sjoerd Simons
2014-07-18 20:36 ` [PATCH 1/3] Revert "drm/exynos: fix module build error" Sjoerd Simons
2014-07-18 20:36 ` [PATCH 2/3] Revert "drm/exynos: remove MODULE_DEVICE_TABLE definitions" Sjoerd Simons
2014-07-18 20:36 ` [PATCH 3/3] drm/exynos: Add MODULE_DEVICE_TABLE entries for various components Sjoerd Simons
2014-07-21  3:02 ` [PATCH 0/3] drm/exynos: Allow module to be autoloaded Inki Dae
2014-07-21  6:50   ` Sjoerd Simons
2014-07-28  8:30     ` Sjoerd Simons
2014-07-28 14:17       ` Inki Dae
2014-07-28 14:45         ` Sjoerd Simons
2014-07-29  5:38           ` Inki Dae
2014-07-29  8:05             ` Sjoerd Simons
2014-07-29 11:59               ` Andreas Färber
2014-07-29 12:29                 ` Inki Dae [this message]
2014-07-29 13:43                   ` Daniel Stone

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=53D793BF.8070603@samsung.com \
    --to=inki.dae@samsung.com \
    --cc=afaerber@suse.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kgene.kim@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=sjoerd.simons@collabora.co.uk \
    --cc=sw0312.kim@samsung.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.