From: "Mark M. Hoffman" <mhoffman@lightlink.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: linux-kernel@vger.kernel.org,
Etienne Lorrain <etienne_lorrain@yahoo.fr>,
lm-sensors <lm-sensors@lm-sensors.org>
Subject: Re: [lm-sensors] sis96x compiled in by error: delay of one minute at boot
Date: Thu, 16 Mar 2006 22:56:16 -0500 [thread overview]
Message-ID: <20060317035616.GA3446@jupiter.solarsys.private> (raw)
In-Reply-To: <3ZH07HE0.1142498811.4526410.khali@localhost>
Hi Jean:
> On 2006-03-16, Mark M. Hoffman wrote:
> > Loading it with the default could be considered an accident by
> > definition. It takes ~6 seconds to load all of
> > kernel/drivers/hwmon/*.ko on a test box here with i2c-parport-light
> > present (but without any adapter hardware). With this patch, that
> > drops to ~1 second.
* Jean Delvare <khali@linux-fr.org> [2006-03-16 09:46:51 +0100]:
> Note that the same result could be achieved by using
> i2c_algo_bit.bit_test=1, which is why I was suggesting to make it the
> default. Doing so would also help the radeonfb driver users: this one
> creates up to 4 i2c busses and at least one does not work for me (I
> guess it depends on how the chip was wired on the graphics adapter),
> causing significant delays on when loading i2c chip drivers afterwards.
>
> I wonder if i2c_algo_bit.bit_test=1 can cause problems. Why wasn't it
> made the default in the first place?
It doesn't look very reliable to me. E.g. if there happens to be bus
traffic during the bus test, it fails. If it gets past that, it gets
worse...
5. A START condition immediately followed by a STOP condition
(void message) is an illegal format.
- I2C Bus Specification, Version 2.1 (page 14)
Unless I read it wrong, that's exactly what the bus test will do.
> > This patch forces the user to specify what type of adapter is present
> > when loading i2c-parport or i2c-parport-light. If none is specified,
> > the driver init simply fails - instead of assuming adapter type 0.
> >
> > This alleviates the sometimes lengthy boot time delays which can be
> > caused by accidentally building one of these into a kernel along with
> > several i2c slave drivers that have lengthy probe routines (e.g. hwmon
> > drivers).
>
> This makes sense, no adapter type is more likely to be found than the
> others. So I like the patch and am willing to accept it. However, given
> that it changes the default behavior, and makes the "type" module
> parameter mandatory, a short notice in the documentation and/or Kconfig
> would be welcome, don't you think?
OK - patch to follow.
Regards,
--
Mark M. Hoffman
mhoffman@lightlink.com
next prev parent reply other threads:[~2006-03-17 3:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-13 10:27 sis96x compiled in by error: delay of one minute at boot Etienne Lorrain
2006-03-13 11:46 ` Jean Delvare
2006-03-13 22:38 ` Etienne Lorrain
2006-03-14 9:43 ` Jean Delvare
2006-03-15 3:46 ` Mark M. Hoffman
2006-03-15 9:01 ` Jean Delvare
2006-03-16 3:59 ` Mark M. Hoffman
2006-03-16 8:46 ` Jean Delvare
2006-03-16 10:53 ` Etienne Lorrain
2006-03-17 4:20 ` [lm-sensors] " Mark M. Hoffman
2006-03-20 23:00 ` Etienne Lorrain
2006-03-29 3:45 ` I2C_PCA_ISA causes boot delays (was re: sis96x compiled in by error: delay of one minute at boot) Mark M. Hoffman
2006-03-29 9:26 ` Etienne Lorrain
2006-03-29 13:38 ` Mark M. Hoffman
2006-03-29 14:00 ` Ian Campbell
2006-03-17 3:56 ` Mark M. Hoffman [this message]
2006-03-17 3:58 ` [PATCH 2.6.16-rc6] i2c: require type parameter for i2c-parport and i2c-parport-light Mark M. Hoffman
2006-03-22 12:32 ` Jean Delvare
2006-03-15 23:03 ` [ot] VIA southbridge strangeness (was: sis96x compiled in by error: delay of one minute at boot) Jan Engelhardt
2006-03-16 8:22 ` Jean Delvare
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=20060317035616.GA3446@jupiter.solarsys.private \
--to=mhoffman@lightlink.com \
--cc=etienne_lorrain@yahoo.fr \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lm-sensors@lm-sensors.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