Re: [patch 2.6.27-rc7-omap1-git 1/2] twl4030-core: move to drivers/mfd
On Friday 03 October 2008, Nathan Monson wrote: > > http://marc.info/?l=linux-omap&m=122297833314280&w=2 > > > > commenting on the issue I noted when I posted this patch; > > showing how I work around that specific I2C error. It'd > > likely work for you too. > > Thanks for pointing this out. The retry patch earlier in the thread > fixes the problem. > > On 5 test boots I received the "i2c_omap i2c_omap.1: controller timed > out" message all 5 times, but it recovers and seems to work fine. That's good news. Now, I'll hope someone more in touch with the I2C hardware can take a look at drivers/i2c/busses/i2c-omap.c and suggest some way to stop getting this error ... nice that it's rather reproducible, if one were to debug it! As I noted in the message above, I see this error in other cases too. All of them "of course" should be made to handle such faults better. But virtually nothing in the I2C stack does sane fault handling, so we also need the i2c-omap code to stop misbehaving. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc7-omap1-git 1/2] twl4030-core: move to drivers/mfd
On Fri, Oct 3, 2008 at 3:16 PM, David Brownell <[EMAIL PROTECTED]> wrote: > On Friday 03 October 2008, Nathan Monson wrote: >> can't get IRQ 378, err -22 >> twl4030_usb: probe of twl4030_usb failed with error -22 >> Unable to allocate IRQ for power button > > Did you see "i2c_omap i2c_omap.1: controller timed out" > earlier in the boot sequence? It would have this symptom, > among others... Earlier in this thread you'll find: > > http://marc.info/?l=linux-omap&m=122297833314280&w=2 > > commenting on the issue I noted when I posted this patch; > showing how I work around that specific I2C error. It'd > likely work for you too. Thanks for pointing this out. The retry patch earlier in the thread fixes the problem. On 5 test boots I received the "i2c_omap i2c_omap.1: controller timed out" message all 5 times, but it recovers and seems to work fine. - Nathan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc7-omap1-git 1/2] twl4030-core: move to drivers/mfd
On Friday 03 October 2008, Nathan Monson wrote: > can't get IRQ 378, err -22 > twl4030_usb: probe of twl4030_usb failed with error -22 > Unable to allocate IRQ for power button > > This is a stock linux-omap with no patches. Did you see "i2c_omap i2c_omap.1: controller timed out" earlier in the boot sequence? It would have this symptom, among others... Earlier in this thread you'll find: http://marc.info/?l=linux-omap&m=122297833314280&w=2 commenting on the issue I noted when I posted this patch; showing how I work around that specific I2C error. It'd likely work for you too. I've seen this i2c adapter hit such failures in other places too, but that location is more reproducible. And it has relatively *visible* nasty side effects... - Dave p.s. Shades of OMAP1 I2C problems! I recall similar cases of the I2C adapter driver stumbling during boot and thus making registrations fail. The same workaround (retry) solved things then too... -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc7-omap1-git 1/2] twl4030-core: move to drivers/mfd
On Fri, Oct 3, 2008 at 6:37 AM, Tony Lindgren <[EMAIL PROTECTED]> wrote: > Pushed. After pulling this one (twl4030-core: move to drivers/mfd), TWL4030 doesn't initialize the same way on my BeagleBoard. Before (708244b3f3d5dad958059729c384a068ecd46161): twl4030_usb twl4030_usb: Initialized TWL4030 USB module input: triton2-pwrbutton as /class/input/input0 triton2 power button driver initialized After (56d33dd99b13c4f18df838e766c595299f7e1e0f): can't get IRQ 378, err -22 twl4030_usb: probe of twl4030_usb failed with error -22 Unable to allocate IRQ for power button This is a stock linux-omap with no patches. - Nathan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc7-omap1-git 1/2] twl4030-core: move to drivers/mfd
* Felipe Balbi <[EMAIL PROTECTED]> [081002 17:56]: > On Thu, Oct 02, 2008 at 07:52:35AM -0700, David Brownell wrote: > > On Thursday 02 October 2008, Felipe Balbi wrote: > > > On Wed, Oct 01, 2008 at 07:47:54PM -0700, David Brownell wrote: > > > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> > > > > > > I suppose this first one should be From: > > > > Yes. > > > > > > + return; > > > > > > also this one > > > > I've got a "lots of twl-core cleanups" patch; I'll include this > > change there. This was *just* a "move". > > Sounds good :-) Pushed. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc7-omap1-git 1/2] twl4030-core: move to drivers/mfd
On Wednesday 01 October 2008, David Brownell wrote:
> NOTE: minor weirdness. The twl403-pwrirq initializes earlier (?)
> than before ... but "i2c_omap i2c_omap.1: controller timed out"
I'm seeing a bunch of these ... not clear why. Usually while
booting ... but regardless, lack of fault recovery makes for
lots of trouble.
> is the response to its first I2C request. So it bails, causing
> twl4030_usb and then rtc_twl4030 request_irq() calls to fail, and
> those drivers probe() calls fail.
>
> But, for the first time in a long while, the USB host now enumerates
> my Ethernet adapter!! So it's a net win in terms of overall behavior,
> since I can now get the time from NTP (loss of RTC doesn't hurt).
>
> Make the pwrirq code retry that first write (setting the mask to
> the value the core already set it) ... and pwrirq comes up, RTC,
> the transceiver glue. And USB can't enumerate that adapter. :(
My retry hack is appended. If anyone has an idea what's up with
the I2C driver, it'd be good to fix ... although I'm happy to see
what fault handling bugs these errors turn up.
More info on the USB thing: the issue is that if the external
hub is connected when MUSB comes up, it misbehaves. If it's
plugged in later, it works. The misbehavior may involve not
seeing the external hub; or it may instead be errors in some
operations talking to a devices hooked up to it.
- Dave
Usually a single retry lets this chip behave.
---
drivers/i2c/chips/twl4030-pwrirq.c | 10 ++
1 file changed, 10 insertions(+)
--- a/drivers/i2c/chips/twl4030-pwrirq.c
+++ b/drivers/i2c/chips/twl4030-pwrirq.c
@@ -161,6 +161,8 @@ static int twl4030_pwrirq_thread(void *d
return 0;
}
+#include
+
static int __init twl4030_pwrirq_init(void)
{
int i, err;
@@ -168,8 +170,16 @@ static int __init twl4030_pwrirq_init(vo
twl4030_pwrirq_mask = 0xff;
twl4030_pwrirq_pending_unmask = 0;
+/* HEY: core already did this.
+ * But that's surely not why we
+ * sometimes see timeouts here ...
+ */
+for (i = 0; i < 5; i++) {
err = twl4030_i2c_write_u8(TWL4030_MODULE_INT, twl4030_pwrirq_mask,
TWL4030_INT_PWR_IMR1);
+if (!err) break;
+msleep(10);
+}
if (err)
return err;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc7-omap1-git 1/2] twl4030-core: move to drivers/mfd
On Thu, Oct 02, 2008 at 07:52:35AM -0700, David Brownell wrote: > On Thursday 02 October 2008, Felipe Balbi wrote: > > On Wed, Oct 01, 2008 at 07:47:54PM -0700, David Brownell wrote: > > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> > > > > I suppose this first one should be From: > > Yes. > > > > + return; > > > > also this one > > I've got a "lots of twl-core cleanups" patch; I'll include this > change there. This was *just* a "move". Sounds good :-) -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc7-omap1-git 1/2] twl4030-core: move to drivers/mfd
On Thursday 02 October 2008, Felipe Balbi wrote: > On Wed, Oct 01, 2008 at 07:47:54PM -0700, David Brownell wrote: > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> > > I suppose this first one should be From: Yes. > > + return; > > also this one I've got a "lots of twl-core cleanups" patch; I'll include this change there. This was *just* a "move". -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc7-omap1-git 1/2] twl4030-core: move to drivers/mfd
On Wed, Oct 01, 2008 at 07:47:54PM -0700, David Brownell wrote:
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
I suppose this first one should be From:
> -static void __init twl4030_mask_clear_intrs(const struct twl4030_mod_iregs
> *t,
> - const u8 t_sz)
> -{
> - int i, j;
> -
> - /*
> - * N.B. - further efficiency is possible here. Eight I2C
> - * operations on BCI and GPIO modules are avoidable if I2C
> - * burst read/write transactions were implemented. Would
> - * probably save about 1ms of boot time and a small amount of
> - * power.
> - */
> - for (i = 0; i < t_sz; i++) {
> - const struct twl4030_mod_iregs tmr = t[i];
> - int cor;
> -
> - /* Are ISRs cleared by reads or writes? */
> - cor = twl4030_read_cor_bit(tmr.mod_no, tmr.sih_ctrl);
> - WARN_ON(cor < 0);
> -
> - for (j = 0; j < tmr.reg_cnt; j++) {
> -
> - /* Mask interrupts at the TWL4030 */
> - WARN_ON(twl4030_i2c_write_u8(tmr.mod_no, 0xff,
> - tmr.imrs[j]) < 0);
> -
> - /* Clear TWL4030 ISRs */
> - WARN_ON(twl4030_i2c_clear_isr(tmr.mod_no,
> - tmr.isrs[j], cor) < 0);
> - }
> - }
> -
> - return;
this return can be removed.
> +static void __init twl4030_mask_clear_intrs(const struct twl4030_mod_iregs
> *t,
> + const u8 t_sz)
> +{
> + int i, j;
> +
> + /*
> + * N.B. - further efficiency is possible here. Eight I2C
> + * operations on BCI and GPIO modules are avoidable if I2C
> + * burst read/write transactions were implemented. Would
> + * probably save about 1ms of boot time and a small amount of
> + * power.
> + */
> + for (i = 0; i < t_sz; i++) {
> + const struct twl4030_mod_iregs tmr = t[i];
> + int cor;
> +
> + /* Are ISRs cleared by reads or writes? */
> + cor = twl4030_read_cor_bit(tmr.mod_no, tmr.sih_ctrl);
> + WARN_ON(cor < 0);
> +
> + for (j = 0; j < tmr.reg_cnt; j++) {
> +
> + /* Mask interrupts at the TWL4030 */
> + WARN_ON(twl4030_i2c_write_u8(tmr.mod_no, 0xff,
> + tmr.imrs[j]) < 0);
> +
> + /* Clear TWL4030 ISRs */
> + WARN_ON(twl4030_i2c_clear_isr(tmr.mod_no,
> + tmr.isrs[j], cor) < 0);
> + }
> + }
> +
> + return;
also this one
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
