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(+)
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,
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,
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) {
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(+)
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.
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?
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
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.
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
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.
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
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
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
dri-devel@lists.freedesktop.org
-
Andreas Färber -
Daniel Stone -
Inki Dae -
Sjoerd Simons