i2c: sirf: move driver init from module_init to subsys_initcall

From: Xiaomeng Hou <[email protected]>

if we initilize i2c bus by module_init, there are some devices which want initialization earlier than i2c and could not do that in time, so move i2c driver initilization to subsys_initcall and make i2c ready before devices init.

Signed-off-by Xiaomeng Hou <[email protected]>

Signed-off-by Barry Song <[email protected]>

Quoted 7 lines

From: Xiaomeng Hou <[email protected]>

if we initilize i2c bus by module_init, there are some devices which want initialization earlier than i2c and could not do that in time, so move i2c driver initilization to subsys_initcall and make i2c ready before devices init.

Quoted 2 lines

Signed-off-by Xiaomeng Hou <[email protected]>

Signed-off-by Barry Song <[email protected]>

What about deferred probing?

2013/5/16 Wolfram Sang <[email protected]>:

Quoted 1 line

What about deferred probing?

deferred probing could work but could not work for automative. what we really want is that devices begin to work as early as possible. we want i2c clients like lcd, camera begin to show images as early as possible as an automative requirement.

Quoted 8 lines

2013/5/16 Wolfram Sang <[email protected]>:

Quoted 1 line

What about deferred probing?

deferred probing could work but could not work for automative. what we really want is that devices begin to work as early as possible. we want i2c clients like lcd, camera begin to show images as early as possible as an automative requirement.

Probe deferral should have at most a mimimal impact on the boot time - it's pretty much just changing the order providing the probe functions aren't excessively slow to defer. If the probe functions are taking a long time to defer that's probably what needs looking at.

If it really is probe deferral itself that's too slow then we ought to be looking at improving that rather than boding around it.

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.

Quoted 12 lines

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...

2013/5/27 Mark Brown <[email protected]>:

Quoted 14 lines · Barry Song

Quoted 12 lines

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.

Quoted 3 lines

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.

Quoted 19 lines

2013/5/27 Mark Brown <[email protected]>:

Quoted 17 lines · Barry Song

Quoted 12 lines

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...

Quoted 4 lines

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.

Quoted 10 lines

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.

It's not that people don't care about these users, it's that people don't care too much about out of tree users. Part of the goal here is to convince people working on such applications that they should make mainline better for everyone so that you don't need external code to make the kernel useful.

2013/6/11 Mark Brown <[email protected]>:

Quoted 5 lines

It's not that people don't care about these users, it's that people don't care too much about out of tree users. Part of the goal here is to convince people working on such applications that they should make mainline better for everyone so that you don't need external code to make the kernel useful.

Mark, then this is really confusing me.
for this reason, the target should be making this out-of-tree stuff be inside the tree. to make i2c-sirf "mainline better and not need external code", the target should be making this external code not external but become internal. otherwise, my mainline users will always need this external code.