linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Andy Walls <awalls@md.metrocast.net>
Cc: bjlockie@lockie.ca, Sakari Ailus <sakari.ailus@iki.fi>,
	linux-media Mailing List <linux-media@vger.kernel.org>
Subject: Re: boot slow down
Date: Mon, 13 Aug 2012 09:25:14 -0300	[thread overview]
Message-ID: <5028F22A.4040504@redhat.com> (raw)
In-Reply-To: <1344730005.2468.36.camel@palomino.walls.org>

Hi Andy,

Em 11-08-2012 21:06, Andy Walls escreveu:
> On Wed, 2012-08-08 at 13:18 -0400, bjlockie@lockie.ca wrote:
>> How hard would it be to get an official kernel option not to load firmware
> 
> Submit a patch for the cx23885 driver to the list.  It could add a
> module option so the user can specify not to load cx23885-av firmware
> (and maybe CX23417 firmware too).  The new module option could be set on
> your kernel commandline: cx23885.no_firmware_load=1

No, adding a parameter there is not right: it is not an user option to not
do firmware load during module init; it is a requirement for a driver to
work with newer userspace tools.

There are two situations there:

1) for devices where the firmware is inside an I2C driver, the solution
is to simply not load the firmware during module probing.

The easiest do to that is to call request_firmware_nowait() during module
probing. This call will start a deferred work that will use a callback
to warn the driver when the firmware is loaded.

If you want an example, please see: 61a96113de51e1f8f43ac98cbeadb54e60045905.
While I intend to do the same on other drivers as I have some spare time,
please don't wait for me on that, as I'm not with much spare time those
days.

You'll likely need to add a status flag at all drivers callback, that would
return a temporary error indication like -EAGAIN (or -ERESTARTSYS) and maybe
change the drivers to handle such error code.

2) for drivers where the firmware is needed for the bridge driver to work,
I couldn't find a perfect solution. There are two alternatives there:

a) patch the drivers base in order to improve the deferred probe. Currently,
a deferred probe will only be called again if a new device driver is probing.
It would make sense to add some way to make it do the probe after a while.

b) lie to probe(), returning 0 before probing the driver, and run a deferred 
probe inside the driver, in order to load the firmware and run the real probing
code.

Regards,
Mauro



  parent reply	other threads:[~2012-08-13 12:25 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-04 15:52 boot slow down James
2012-08-04 17:05 ` Ezequiel Garcia
2012-08-04 17:42 ` Andy Walls
2012-08-04 22:21   ` James
2012-08-04 22:28   ` James
2012-08-05 21:20     ` Sakari Ailus
2012-08-06  4:30       ` James
2012-08-06  4:38       ` James
2012-08-07 11:27         ` Sakari Ailus
2012-08-07 13:04           ` bjlockie
2012-08-07 13:53             ` Andy Walls
2012-08-07 20:33               ` bjlockie
2012-08-07 21:42                 ` James
2012-08-07 21:49                   ` James
2012-08-08  8:24                   ` Sakari Ailus
2012-08-08 17:18                     ` bjlockie
2012-08-11 15:20                       ` Sakari Ailus
2012-08-12  0:06                       ` Andy Walls
2012-08-12 19:56                         ` Ezequiel Garcia
2012-08-13 12:25                         ` Mauro Carvalho Chehab [this message]
2012-08-07 21:40               ` James
2012-08-06  8:37     ` Andy Walls
2012-08-06  9:19       ` Antti Palosaari
2012-08-06 10:57         ` Andy Walls
2012-08-06 11:41           ` Antti Palosaari

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=5028F22A.4040504@redhat.com \
    --to=mchehab@redhat.com \
    --cc=awalls@md.metrocast.net \
    --cc=bjlockie@lockie.ca \
    --cc=linux-media@vger.kernel.org \
    --cc=sakari.ailus@iki.fi \
    /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).