[PATCH] i2c: sirf: move driver init from module_init to subsys_initcall
21cnbao at gmail.com
Mon Jun 10 21:14:41 EDT 2013
2013/6/10 Wolfram Sang <wsa at the-dreams.de>:
> On Mon, May 27, 2013 at 11:36:14PM +0800, Barry Song wrote:
>> 2013/5/27 Mark Brown <broonie at kernel.org>:
>> > On Mon, May 27, 2013 at 09:54:56AM +0800, Barry Song wrote:
>> >> Mark, the case is not that deferred probing is slow or not. deferred
>> >> probing is pretty good.
>> >> the case is that we want to i2c and media connected with i2c probed
>> >> earlier than other devices.
>> >> in auto infotainment devices, we actually do some hacking in kernel
>> >> that makes rear view work earlier than other device driver
>> >> initialization with a kernel thread which take care of backing-car
>> >> policy not only mechanism. that means, we make camera work to see
>> >> backview image even earlier than other drivers' initialization.
>> >> we don't want media deferred to wait for i2c. we want make some early
>> >> jobs ready earlier.
>> > So this change makes no practical difference in mainline and exists to
>> > support out of tree hacks for performance? It doesn't seem like that
>> > big a patch to carry along with the out of tree stuff...
>> yes. but i don't think we are easy to make those out-of-mainline hacks
>> be in mainline. but this patch is both ok to mainline and local tree.
>> making local tree and mainline same as many as possible decreases our
>> maintaince efforts totally.
> I understand that, yet I agree with Mark. The mainline idea is to use
> deferred probing to make sure all components come up correctly. In fact,
> I wish for patches removing subsys_initcall with deferred probing.
the mainline idea you mentioned is that you don't care about any early
device, which means some devices want to start earlier than others in
some real automative user scenerioes.
but i think another important idea is that mainline codes come from
branches of different vendors and serve final users of those drivers,
but not only make source codes no difference to all environments. the
auto users i2c-sirf serves, here, actually means some differences with
PC/tablet/mobilephone. we don't make codes good-looking by losing
functionality and not close to final users.
anyway, it is up to you to decide. i can definitely maintain the
More information about the linux-arm-kernel