[PATCH 0/3] drm/exynos: Allow module to be autoloaded

[PATCH 0/3] drm/exynos: Allow module to be autoloaded

[Sjoerd Simons]

The exynos DRM module currently is not automatically loaded when build as a
module. This is due to the simple fact that it doesn't have any
MODULE_DEVICE_TABLE entries whatsoever... Most of these were removed previously
as it wasn't possible at the time to have multiple calls to MODULE_DEVICE_TABLE
in one module, however commit 21bdd17b21b45ea solved that.

The first two patches revert the previous removals of MODULE_DEVICE_TABLE
calls, while the last one adds calls for the remaining OF match tables without a
MODULE_DEVICE_TABLE call.

Sjoerd Simons (3):
  Revert "drm/exynos: fix module build error"
  Revert "drm/exynos: remove MODULE_DEVICE_TABLE definitions"
  drm/exynos: Add MODULE_DEVICE_TABLE entries for various components

 drivers/gpu/drm/exynos/exynos_dp_core.c     | 1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c     | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fimc.c    | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c    | 1 +
 drivers/gpu/drm/exynos/exynos_drm_g2d.c     | 1 +
 drivers/gpu/drm/exynos/exynos_drm_rotator.c | 1 +
 drivers/gpu/drm/exynos/exynos_hdmi.c        | 1 +
 drivers/gpu/drm/exynos/exynos_mixer.c       | 1 +
 8 files changed, 8 insertions(+)

-- 
2.0.1

[PATCH 1/3] Revert "drm/exynos: fix module build error"

[Sjoerd Simons]

This reverts commit de1d3677017a1d58419722b60564cb56bd9462c3, which was
original added to fix build errors when building exynosdrm as a single
module caused by multiple MODULE_DEVICE_TABLE in one module. Which, as
a side-effect broke autoloading of the module.

Since 21bdd17b21b45ea48e06e23918d681afbe0622e9 it is possible to have
multiple calls to MODULE_DEVICE_TABLE, so the patch can be
reverted to restore support for autoloading

Conflicts:
	drivers/gpu/drm/exynos/exynos_drm_fimd.c
	drivers/gpu/drm/exynos/exynos_drm_g2d.c

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 +
 drivers/gpu/drm/exynos/exynos_drm_g2d.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 33161ad..081eb15 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -136,6 +136,7 @@ static const struct of_device_id fimd_driver_dt_match[] = {
 	  .data = &exynos5_fimd_driver_data },
 	{},
 };
+MODULE_DEVICE_TABLE(of, fimd_driver_dt_match);
 
 static inline struct fimd_driver_data *drm_fimd_get_driver_data(
 	struct platform_device *pdev)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 8001587..bb728c8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1546,6 +1546,7 @@ static const struct of_device_id exynos_g2d_match[] = {
 	{ .compatible = "samsung,exynos5250-g2d" },
 	{},
 };
+MODULE_DEVICE_TABLE(of, exynos_g2d_match);
 
 struct platform_driver g2d_driver = {
 	.probe		= g2d_probe,
-- 
2.0.1

[PATCH 2/3] Revert "drm/exynos: remove MODULE_DEVICE_TABLE definitions"

[Sjoerd Simons]

This reverts commit d089621896c3530a9bd309f96e9c9124d07f6c3f was
original to prevent multiple MODULE_DEVICE_TABLE in one module.
Which, as a side-effect broke autoloading of the module.

Since 21bdd17b21b45ea48e06e23918d681afbe0622e9 it is possible to have
multiple calls to MODULE_DEVICE_TABLE, so the patch can be
reverted to restore support for autoloading

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
---
 drivers/gpu/drm/exynos/exynos_dp_core.c | 1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 845d766..31c3de9 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1376,6 +1376,7 @@ static const struct of_device_id exynos_dp_match[] = {
 	{ .compatible = "samsung,exynos5-dp" },
 	{},
 };
+MODULE_DEVICE_TABLE(of, exynos_dp_match);
 
 struct platform_driver dp_driver = {
 	.probe		= exynos_dp_probe,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 2df3592..46b7bf6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1529,6 +1529,7 @@ static struct of_device_id exynos_dsi_of_match[] = {
 	{ .compatible = "samsung,exynos4210-mipi-dsi" },
 	{ }
 };
+MODULE_DEVICE_TABLE(of, exynos_dsi_of_match);
 
 struct platform_driver dsi_driver = {
 	.probe = exynos_dsi_probe,
-- 
2.0.1

[PATCH 3/3] drm/exynos: Add MODULE_DEVICE_TABLE entries for various components

[Sjoerd Simons]

Add MODULE_DEVICE_TABLE calls for the various OF match tables that
currently don't have one. This allows the module to be
autoloaded based on devicetree information.

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c    | 1 +
 drivers/gpu/drm/exynos/exynos_drm_rotator.c | 1 +
 drivers/gpu/drm/exynos/exynos_hdmi.c        | 1 +
 drivers/gpu/drm/exynos/exynos_mixer.c       | 1 +
 4 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 831dde9..ec7cc9e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1887,6 +1887,7 @@ static const struct of_device_id fimc_of_match[] = {
 	{ .compatible = "samsung,exynos4212-fimc" },
 	{ },
 };
+MODULE_DEVICE_TABLE(of, fimc_of_match);
 
 struct platform_driver fimc_driver = {
 	.probe		= fimc_probe,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index f01fbb6..55af6b4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -691,6 +691,7 @@ static const struct of_device_id exynos_rotator_match[] = {
 	},
 	{},
 };
+MODULE_DEVICE_TABLE(of, exynos_rotator_match);
 
 static int rotator_probe(struct platform_device *pdev)
 {
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index fd8141f..d08e00d 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2295,6 +2295,7 @@ static struct of_device_id hdmi_match_types[] = {
 		/* end node */
 	}
 };
+MODULE_DEVICE_TABLE (of, hdmi_match_types);
 
 static int hdmi_bind(struct device *dev, struct device *master, void *data)
 {
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c
index 9d0c21a..6756d1c 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1240,6 +1240,7 @@ static struct of_device_id mixer_match_types[] = {
 		/* end node */
 	}
 };
+MODULE_DEVICE_TABLE(of, mixer_match_types);
 
 static int mixer_bind(struct device *dev, struct device *manager, void *data)
 {
-- 
2.0.1

Re: [PATCH 0/3] drm/exynos: Allow module to be autoloaded

[Inki Dae]

On 2014년 07월 19일 05:36, Sjoerd Simons wrote:
> The exynos DRM module currently is not automatically loaded when build as a
> module. This is due to the simple fact that it doesn't have any
> MODULE_DEVICE_TABLE entries whatsoever... Most of these were removed previously
> as it wasn't possible at the time to have multiple calls to MODULE_DEVICE_TABLE
> in one module, however commit 21bdd17b21b45ea solved that.
> 
> The first two patches revert the previous removals of MODULE_DEVICE_TABLE
> calls, while the last one adds calls for the remaining OF match tables without a
> MODULE_DEVICE_TABLE call.

Hi,

Exynos drm follows single-driver model. So each usb driver of Exynos drm
wouldn't need its own MODULE_DEVICE_TABLE.

Thanks,
Inki Dae

> 
> Sjoerd Simons (3):
>   Revert "drm/exynos: fix module build error"
>   Revert "drm/exynos: remove MODULE_DEVICE_TABLE definitions"
>   drm/exynos: Add MODULE_DEVICE_TABLE entries for various components
> 
>  drivers/gpu/drm/exynos/exynos_dp_core.c     | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c     | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c    | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c    | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c     | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c | 1 +
>  drivers/gpu/drm/exynos/exynos_hdmi.c        | 1 +
>  drivers/gpu/drm/exynos/exynos_mixer.c       | 1 +
>  8 files changed, 8 insertions(+)
> 

Re: [PATCH 0/3] drm/exynos: Allow module to be autoloaded

[Sjoerd Simons]

[-- Attachment #1: Type: text/plain, Size: 1876 bytes --]

Hey Inki,

On Mon, 2014-07-21 at 12:02 +0900, Inki Dae wrote:
> On 2014년 07월 19일 05:36, Sjoerd Simons wrote:
> > The exynos DRM module currently is not automatically loaded when build as a
> > module. This is due to the simple fact that it doesn't have any
> > MODULE_DEVICE_TABLE entries whatsoever... Most of these were removed previously
> > as it wasn't possible at the time to have multiple calls to MODULE_DEVICE_TABLE
> > in one module, however commit 21bdd17b21b45ea solved that.
> > 
> > The first two patches revert the previous removals of MODULE_DEVICE_TABLE
> > calls, while the last one adds calls for the remaining OF match tables without a
> > MODULE_DEVICE_TABLE call.

> Exynos drm follows single-driver model. So each usb driver of Exynos drm
> wouldn't need its own MODULE_DEVICE_TABLE.

Strictly speaking you're right, for module autoloading to work the
module just needs to have one that matches. So in principle all other
entries are redundant.

However for exynos drm there does not seem to be one main device which
is guaranteed to always be present which can be used to key the module
autoloading of. So you still need seperate MODULE_DEVICE_TABLE entries
for all the various subdrivers to ensure autoloading actually happens,
especially since the various subdrivers can be seperately enabled
at build time. 

The one exception from the above might be the HDMI sub-driver, which is
always build together with the mixer (And i asume the HDMI hw block
depends on the mixer block for its input). However it seems more elegant
and less error-prone to have simply entries for both, rather then
implicitly replying on the other (sub)driver to trigger module loading.
Especially given there is essentially no cost in having another module
alias.

-- 
Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Collabora Ltd.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6170 bytes --]

Re: [PATCH 0/3] drm/exynos: Allow module to be autoloaded

[Sjoerd Simons]

[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]

Hey Inki,

On Mon, 2014-07-21 at 08:50 +0200, Sjoerd Simons wrote:
> Hey Inki,
> 
> On Mon, 2014-07-21 at 12:02 +0900, Inki Dae wrote:
> > On 2014년 07월 19일 05:36, Sjoerd Simons wrote:
> > > The exynos DRM module currently is not automatically loaded when build as a
> > > module. This is due to the simple fact that it doesn't have any
> > > MODULE_DEVICE_TABLE entries whatsoever... Most of these were removed previously
> > > as it wasn't possible at the time to have multiple calls to MODULE_DEVICE_TABLE
> > > in one module, however commit 21bdd17b21b45ea solved that.
> > > 
> > > The first two patches revert the previous removals of MODULE_DEVICE_TABLE
> > > calls, while the last one adds calls for the remaining OF match tables without a
> > > MODULE_DEVICE_TABLE call.
> 
> > Exynos drm follows single-driver model. So each usb driver of Exynos drm
> > wouldn't need its own MODULE_DEVICE_TABLE.
> 
> Strictly speaking you're right, for module autoloading to work the
> module just needs to have one that matches. So in principle all other
> entries are redundant.
> 
> However for exynos drm there does not seem to be one main device which
> is guaranteed to always be present which can be used to key the module
> autoloading of. So you still need seperate MODULE_DEVICE_TABLE entries
> for all the various subdrivers to ensure autoloading actually happens,
> especially since the various subdrivers can be seperately enabled
> at build time. 

Been about a week since this last mail. If you have any suggestions on a
better approach or on how to move this forward, i'd be very grateful to
hear as i think i've addressed your original comment on the set in the
previous reply?

-- 
Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Collabora Ltd.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6170 bytes --]

Re: [PATCH 0/3] drm/exynos: Allow module to be autoloaded

[Inki Dae]

On 2014년 07월 28일 17:30, Sjoerd Simons wrote:
> Hey Inki,
> 
> On Mon, 2014-07-21 at 08:50 +0200, Sjoerd Simons wrote:
>> Hey Inki,
>>
>> On Mon, 2014-07-21 at 12:02 +0900, Inki Dae wrote:
>>> On 2014년 07월 19일 05:36, Sjoerd Simons wrote:
>>>> The exynos DRM module currently is not automatically loaded when build as a
>>>> module. This is due to the simple fact that it doesn't have any
>>>> MODULE_DEVICE_TABLE entries whatsoever... Most of these were removed previously
>>>> as it wasn't possible at the time to have multiple calls to MODULE_DEVICE_TABLE
>>>> in one module, however commit 21bdd17b21b45ea solved that.
>>>>
>>>> The first two patches revert the previous removals of MODULE_DEVICE_TABLE
>>>> calls, while the last one adds calls for the remaining OF match tables without a
>>>> MODULE_DEVICE_TABLE call.
>>
>>> Exynos drm follows single-driver model. So each usb driver of Exynos drm
>>> wouldn't need its own MODULE_DEVICE_TABLE.
>>
>> Strictly speaking you're right, for module autoloading to work the
>> module just needs to have one that matches. So in principle all other
>> entries are redundant.
>>
>> However for exynos drm there does not seem to be one main device which
>> is guaranteed to always be present which can be used to key the module
>> autoloading of. So you still need seperate MODULE_DEVICE_TABLE entries
>> for all the various subdrivers to ensure autoloading actually happens,
>> especially since the various subdrivers can be seperately enabled
>> at build time. 
> 
> Been about a week since this last mail. If you have any suggestions on a
> better approach or on how to move this forward, i'd be very grateful to
> hear as i think i've addressed your original comment on the set in the
> previous reply?

Sorry for late,

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?

Thanks,
Inki Dae

> 

Re: [PATCH 0/3] drm/exynos: Allow module to be autoloaded

[Sjoerd Simons]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

Hey Inki,

On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote:
> On 2014년 07월 28일 17:30, Sjoerd Simons wrote:
> Sorry for late,
> 
> 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. 

-- 
Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Collabora Ltd.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6170 bytes --]

Re: [PATCH 0/3] drm/exynos: Allow module to be autoloaded

[Inki Dae]

On 2014년 07월 28일 23:45, Sjoerd Simons wrote:
> Hey Inki,
> 
> On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote:
>> On 2014년 07월 28일 17:30, Sjoerd Simons wrote:
>> Sorry for late,
>>
>> 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.

Ok, then does exynos drm driver is loaded well with your patches? My
concern is that device_id of exynos drm core driver , exynos_drm_drv.c,
wouldn't be exported to userspace, which means that exynos drm subsystem
aren't bound by component framework because most sub drivers except vidi
are bound by component interfaces of exynos drm core: exynos drm drv is
not device tree base driver.

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

Re: [PATCH 0/3] drm/exynos: Allow module to be autoloaded

[Sjoerd Simons]

[-- Attachment #1: Type: text/plain, Size: 2512 bytes --]

On Tue, 2014-07-29 at 14:38 +0900, Inki Dae wrote:
> On 2014년 07월 28일 23:45, Sjoerd Simons wrote:
> > Hey Inki,
> > 
> > On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote:
> >> On 2014년 07월 28일 17:30, Sjoerd Simons wrote:
> >> Sorry for late,
> >>
> >> 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..


> Ok, then does exynos drm driver is loaded well with your patches? 

It is indeed.

> My concern is that device_id of exynos drm core driver ,
> exynos_drm_drv.c, wouldn't be exported to userspace, which means that
> exynos drm subsystem aren't bound by component framework because most
> sub drivers except vidi are bound by component interfaces of exynos drm
> core: exynos drm drv is not device tree base driver.

This patchset doesn't change how that works. Really all it does is to
tell userspace which devices exynosdrm supports. From the kernel side of
things, there is no difference between the module being loaded based on
that information vs. it being loaded by hand.

-- 
Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Collabora Ltd.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6170 bytes --]

Re: [PATCH 0/3] drm/exynos: Allow module to be autoloaded

[Andreas Färber]

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.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [PATCH 0/3] drm/exynos: Allow module to be autoloaded

[Inki Dae]

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

Re: [PATCH 0/3] drm/exynos: Allow module to be autoloaded

[Daniel Stone]

[-- Attachment #1.1: Type: text/plain, Size: 1902 bytes --]

Hi Inki,

On 29 July 2014 13:29, Inki Dae <inki.dae@samsung.com> wrote:

> On 2014년 07월 29일 20:59, Andreas Färber wrote:
> > Am 29.07.2014 10:05, schrieb Sjoerd Simons:
> >> 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 for merging these. Just wanted to reiterate that it is not about
hotplug at all: it is about delayed/conditional loading. There is no
expectation that these will be used in a hotplug manner, it is just about
being able to load them in the initrd without having to have explicit cases
for every single driver and device in userspace (which would make it much
harder to change the driver later).

Cheers,
Daniel

[-- Attachment #1.2: Type: text/html, Size: 2521 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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