[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100903122619.GC4813@pengutronix.de>
Date: Fri, 3 Sep 2010 14:26:20 +0200
From: Wolfram Sang <w.sang@...gutronix.de>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Masayuki Ohtak <masa-korg@....okisemi.com>,
"Jean Delvare (PC drivers, core)" <khali@...ux-fr.org>,
"Ben Dooks (embedded platforms)" <ben-linux@...ff.org>,
Crane Cai <crane.cai@....com>,
Samuel Ortiz <sameo@...ux.intel.com>,
Linus Walleij <linus.walleij@...ricsson.com>,
Ralf Baechle <ralf@...ux-mips.org>,
srinidhi kasagar <srinidhi.kasagar@...ricsson.com>,
linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
joe@...ches.com, yong.y.wang@...el.com, qi.wang@...el.com,
andrew.chih.howe.khor@...el.com, arjan@...ux.intel.com,
Tomoya MORINAGA <morinaga526@....okisemi.com>,
Arnd Bergmann <arnd@...db.de>
Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_I2C driver to 2.6.35
On Fri, Sep 03, 2010 at 01:36:13PM +0100, Alan Cox wrote:
> > +config PCH_I2C_CH_COUNT
> > + int "PCH I2C the number of channel count"
> > + range 1 2
> > + depends on PCH_I2C
> > + help
> > + This driver is for PCH(Platform controller Hub) I2C of Topcliff which
> > + is an IOH(Input/Output Hub) for x86 embedded processor.
> > + The number of I2C buses/channels supported by the PCH I2C controller.
> > + PCH I2C of Topcliff supports only one channel.
>
> These sort of settings need to be runtime so one kernel can be built for
> many platform variants. In this case if I understand correctly the
> current device only has one channel so the define could just be moved
> into the driver for now and made a variable later as/when/if new hardware
> with more channels appears.
>
>
>
> > +static s32 pch_wait_for_xfer_complete(struct i2c_algo_pch_data *adap)
> > +{
> > + s32 ret;
> > + ret = wait_event_interruptible_timeout(pch_event,
> > + (adap->pch_event_flag != 0), msecs_to_jiffies(50));
> > + if (ret < 0) {
> > + pch_err(adap, "timeout: %x\n", adap->pch_event_flag);
> > + return ret;
> > + }
>
> You are reporting a timeout when _interruptible can also be woken by a
> signal to the process (eg the user hitting ^C)
Sidenote: a number of embedded drivers decided to switch to
wait_event_timeout() recently because reacting to a signal may have
subtle issues and must be carefully implemented and tested. Stalled
busses were often the consequence. I don't know if this applies here but
better keep it in mind.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists