linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: wsa@the-dreams.de (Wolfram Sang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] i2c: sirf: move driver init from module_init to subsys_initcall
Date: Mon, 10 Jun 2013 15:45:36 +0200	[thread overview]
Message-ID: <20130610134535.GB2987@katana> (raw)
In-Reply-To: <CAGsJ_4w867BhFvVze5BNaYheW75pMcOGhscz3wSZiia-neP59w@mail.gmail.com>

On Mon, May 27, 2013 at 11:36:14PM +0800, Barry Song wrote:
> 2013/5/27 Mark Brown <broonie@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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130610/2e105739/attachment.sig>

  reply	other threads:[~2013-06-10 13:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-16  2:50 [PATCH] i2c: sirf: move driver init from module_init to subsys_initcall Barry Song
2013-05-16  9:38 ` Wolfram Sang
2013-05-16 10:25   ` Barry Song
2013-05-25 20:10     ` Mark Brown
2013-05-27  1:54       ` Barry Song
2013-05-27 12:16         ` Mark Brown
2013-05-27 15:36           ` Barry Song
2013-06-10 13:45             ` Wolfram Sang [this message]
2013-06-11  1:14               ` Barry Song
2013-06-11  8:48                 ` Mark Brown
2013-06-11 11:13                   ` Barry Song
2013-06-11 12:10                     ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130610134535.GB2987@katana \
    --to=wsa@the-dreams.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).