2013/4/27 Sylwester Nawrocki <sylvester.nawrocki@xxxxxxxxx>
On 04/26/2013 09:42 PM, Tomasz Figa wrote:Yes, this is how it would have been in a perfect world. Probably something
On Friday 26 of April 2013 11:48:50 Sylwester Nawrocki wrote:
On 04/26/2013 10:20 AM, Inki Dae wrote:
Exactly right. it's my mistake. But now it seems thatSince all drivers seem to be linked into single a single module, you
__mode_of_device_table is multi defined at fimd and g2d side so there
still is module build error. :(
likely need to create a separate table of struct of_device_id just for
the purpose of MODULE_DEVICE_TABLE(of, ...). This table would contain
'compatible' strings for all devices. Or choose of_device_id for just
one device and define MODULE_DEVICE_TABLE() for it in some common place,
e.g. exynos_drm_drv.c. I believe all devices should be listed though.
IMHO, the most proper solution would be to split the module into parent
exynos_drm module and per-device submodules, which would depend on the
parent module.
This way you would be able to load dynamically any submodule you want,
without recompiling the modules.
worth to consider for the future, it likely implies a lot of work.
For now, exynos drm framework has a problem to module support with device tree. And for this, going back to previous style might be a right way but this also still has the probing issue. Frankly spreaking, I don't really want back to previous style because that way not only still has a probing issue but also makes exynos drm framework so complicated(there are many things to consider every time framework updating). So I'd like to resolve this issue as is first.
OTOH if there is one device for which the driver will always be present
in the main module it should be enough to make a single entry
MODULE_DEVICE_TABLE including its compatible string to ensure the driver
is properly loaded, shouldn't it ?
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
