TWL4030 intermittent freakout on boot

TWL4030 intermittent freakout on boot

[Paul Walmsley]

Hello everyone,

occasionally the TWL4030 driver on the 3430SDP freaks out on boot.  (This 
is either an ES2.0 or ES2.1, not sure.)  Here's a partial console log with 
initcall debugging enabled.  This probably happens every thirty or forty 
boots, I would guess.  The board does boot to userspace when this happens.

Perhaps the TWL4030 experts out there might know what's going on?


- Paul

calling  i2c_init+0x0/0x60()
initcall i2c_init+0x0/0x60() returned 0 after 7 msecs
calling  omap_i2c_init_driver+0x0/0x1c()
<6>i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz
<6>i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz
<6>i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz
initcall omap_i2c_init_driver+0x0/0x1c() returned 0 after 22 msecs
calling  twl4030_init+0x0/0x20()
<6>TWL4030: TRY attach Slave TWL4030-ID0 on Adapter OMAP I2C adapter [1]
<6>TWL4030: TRY attach Slave TWL4030-ID1 on Adapter OMAP I2C adapter [1]
<6>TWL4030: TRY attach Slave TWL4030-ID2 on Adapter OMAP I2C adapter [1]
<6>TWL4030: TRY attach Slave TWL4030-ID3 on Adapter OMAP I2C adapter [1]
initcall twl4030_init+0x0/0x20() returned 0 after 29 msecs
calling  twl4030_pwrirq_init+0x0/0xf8()
initcall twl4030_pwrirq_init+0x0/0xf8() returned 0 after 0 msecs
calling  twl4030_usb_init+0x0/0x1e8()
<3>irq 56: nobody cared (try booting with the "irqpoll" option)
[<c002cd14>] (dump_stack+0x0/0x14) from [<c006f9fc>] 
(__report_bad_irq+0x38/0x88)
[<c006f9c4>] (__report_bad_irq+0x0/0x88) from [<c006fc5c>] 
(note_interrupt+0x210/0x270)
 r5:c0336820 r4:00000000
[<c006fa4c>] (note_interrupt+0x0/0x270) from [<c0070868>] 
(handle_level_irq+0x94/0xf0)
[<c00707d4>] (handle_level_irq+0x0/0xf0) from [<c0028048>] 
(__exception_text_start+0x48/0x64)
 r5:c0336820 r4:00000038
[<c0028000>] (__exception_text_start+0x0/0x64) from [<c00285b0>] 
(__irq_svc+0x30/0x80)
Exception stack(0xc7c1dd78 to 0xc7c1ddc0)
dd60:                                                       00000020 c0354f60
dd80: c0354f60 00000000 00000002 c0354f60 0000000a 00000001 c7c5d800 00000001
dda0: 00000001 c7c1dddc c7c1dde0 c7c1ddc0 c0050ec0 c0050b44 20000113 ffffffff
 r7:00000001 r6:0000000a r5:d8200000 r4:ffffffff
[<c0050b00>] (__do_softirq+0x0/0xb8) from [<c0050ec0>] (irq_exit+0x48/0x8c)
 r7:00000001 r6:00000000 r5:c03363f8 r4:00000025
[<c0050e78>] (irq_exit+0x0/0x8c) from [<c002804c>] (__exception_text_start+0x4c/0x64)
 r5:c03363f8 r4:00000025
[<c0028000>] (__exception_text_start+0x0/0x64) from [<c00285b0>] (__irq_svc+0x30/0x80)
Exception stack(0xc7c1de18 to 0xc7c1de60)
de00:                                                       c7c5d800 000001e2
de20: d8070000 0000601f c7c5d800 c7c5d800 c0344c3c 00000001 c7c5d800 00000001
de40: 00000001 c7c1de74 c7c1de78 c7c1de60 c0195be8 c019593c 60000013 ffffffff
 r7:00000001 r6:c0344c3c r5:d8200000 r4:ffffffff
[<c0195914>] (omap_i2c_idle+0x0/0x68) from [<c0195be8>] (omap_i2c_xfer+0x26c/0x284)
 r5:c7c5d800 r4:00000001
[<c019597c>] (omap_i2c_xfer+0x0/0x284) from [<c0193284>] (i2c_transfer+0x88/0x9c)
[<c01931fc>] (i2c_transfer+0x0/0x9c) from [<c0196780>] (twl4030_i2c_write+0xc0/0xe8)
 r7:00000001 r6:00000000 r5:c0344c48 r4:c0344ac8
[<c01966c0>] (twl4030_i2c_write+0x0/0xe8) from [<c01967d0>] (twl4030_i2c_write_u8+0x28/0x30)
[<c01967a8>] (twl4030_i2c_write_u8+0x0/0x30) from [<c0197e14>] (twl4030_i2c_write_u8_verify+0x20/0x9c)
[<c0197df4>] (twl4030_i2c_write_u8_verify+0x0/0x9c) from [<c01982b0>] (twl4030_i2c_access+0x120/0x150)
 r6:00000000 r5:c7c59a60 r4:00000000
[<c0198190>] (twl4030_i2c_access+0x0/0x150) from [<c001a93c>] (twl4030_usb_init+0x18c/0x1e8)
 r5:c7c59a60 r4:00000001
[<c001a7b0>] (twl4030_usb_init+0x0/0x1e8) from [<c0008928>] (kernel_init+0xa0/0x218)
 r6:00000000 r5:00000000 r4:c0024000
[<c0008888>] (kernel_init+0x0/0x218) from [<c004ec70>] (do_exit+0x0/0x5fc)
<3>handlers:
<3>[<c0195f58>] (omap_i2c_isr+0x0/0x308)
<0>Disabling IRQ #56
<3>i2c_omap i2c_omap.1: controller timed out
<3>i2c_omap i2c_omap.1: controller timed out
<3>twl4030_usb: i2c write failed, line 422

Re: TWL4030 intermittent freakout on boot

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Op 8 mei 2008, om 20:13 heeft Paul Walmsley het volgende geschreven:
>
> Hello everyone,
>
> occasionally the TWL4030 driver on the 3430SDP freaks out on boot.   
> (This
> is either an ES2.0 or ES2.1, not sure.)  Here's a partial console  
> log with
> initcall debugging enabled.  This probably happens every thirty or  
> forty
> boots, I would guess.  The board does boot to userspace when this  
> happens.
>
> Perhaps the TWL4030 experts out there might know what's going on?
>
> <3>i2c_omap i2c_omap.1: controller timed out
> <3>i2c_omap i2c_omap.1: controller timed out
> <3>twl4030_usb: i2c write failed, line 422

Looks suspiciously like the symptons in

http://code.google.com/p/beagleboard/issues/detail?id=14

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFII0R9MkyGM64RGpERAkZFAKC1LiEAK3DcBwzasa3yE2cLr/MLxgCgprDi
ABlwZjvXIM0UTP8dMCd1s44=
=BbS2
-----END PGP SIGNATURE-----

Re: TWL4030 intermittent freakout on boot

[Tony Lindgren]

* Koen Kooi <k.kooi@student.utwente.nl> [080508 11:22]:
> 
> Op 8 mei 2008, om 20:13 heeft Paul Walmsley het volgende geschreven:
> >
> > Hello everyone,
> >
> > occasionally the TWL4030 driver on the 3430SDP freaks out on boot.   
> > (This
> > is either an ES2.0 or ES2.1, not sure.)  Here's a partial console  
> > log with
> > initcall debugging enabled.  This probably happens every thirty or  
> > forty
> > boots, I would guess.  The board does boot to userspace when this  
> > happens.
> >
> > Perhaps the TWL4030 experts out there might know what's going on?
> >
> > <3>i2c_omap i2c_omap.1: controller timed out
> > <3>i2c_omap i2c_omap.1: controller timed out
> > <3>twl4030_usb: i2c write failed, line 422
> 
> Looks suspiciously like the symptons in
> 
> http://code.google.com/p/beagleboard/issues/detail?id=14

This also looks similar to the earlier twl4030 hangs where access
to some domains caused twl4030 to hang. If twl4030 hangs, there's
no way to reset it as all control is over I2C. When twl4030 hangs,
bootloader won't be able to detect the chip either unless devices
is power cycled (and USB cable detached).

The reason earlier was that twl4030 internal clock was not being
programmed properly, and was fixed by patch
0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d.

Maybe there's some twl4030 register access going on before the
internal clock is programmed properly?

Tony

Re: TWL4030 intermittent freakout on boot

[Paul Walmsley]

On Thu, 8 May 2008, Tony Lindgren wrote:

> This also looks similar to the earlier twl4030 hangs where access
> to some domains caused twl4030 to hang. If twl4030 hangs, there's
> no way to reset it as all control is over I2C. When twl4030 hangs,
> bootloader won't be able to detect the chip either unless devices
> is power cycled (and USB cable detached).
> 
> The reason earlier was that twl4030 internal clock was not being
> programmed properly, and was fixed by patch
> 0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d.
> 
> Maybe there's some twl4030 register access going on before the
> internal clock is programmed properly?

IRQ 56 is the TWL4030 I2C1 IRQ.  Seems strange that there would be no 
handler for it after i2c_omap has initialized...


- Paul

Re: TWL4030 intermittent freakout on boot

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [080508 11:33]:
> On Thu, 8 May 2008, Tony Lindgren wrote:
> 
> > This also looks similar to the earlier twl4030 hangs where access
> > to some domains caused twl4030 to hang. If twl4030 hangs, there's
> > no way to reset it as all control is over I2C. When twl4030 hangs,
> > bootloader won't be able to detect the chip either unless devices
> > is power cycled (and USB cable detached).
> > 
> > The reason earlier was that twl4030 internal clock was not being
> > programmed properly, and was fixed by patch
> > 0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d.
> > 
> > Maybe there's some twl4030 register access going on before the
> > internal clock is programmed properly?
> 
> IRQ 56 is the TWL4030 I2C1 IRQ.  Seems strange that there would be no 
> handler for it after i2c_omap has initialized...

Well if the I2C register access hangs, nothing will be able to reset
the twl4030 interrupt registers when an interrupt happens.

Tony

Re: [beagleboard] Re: TWL4030 intermittent freakout on boot

[Dirk Behme]

Tony Lindgren wrote:
> * Koen Kooi <k.kooi@student.utwente.nl> [080508 11:22]:
> 
>>Op 8 mei 2008, om 20:13 heeft Paul Walmsley het volgende geschreven:
>>
>>>Hello everyone,
>>>
>>>occasionally the TWL4030 driver on the 3430SDP freaks out on boot.   
>>>(This
>>>is either an ES2.0 or ES2.1, not sure.)  Here's a partial console  
>>>log with
>>>initcall debugging enabled.  This probably happens every thirty or  
>>>forty
>>>boots, I would guess.  The board does boot to userspace when this  
>>>happens.
>>>
>>>Perhaps the TWL4030 experts out there might know what's going on?
>>>
>>><3>i2c_omap i2c_omap.1: controller timed out
>>><3>i2c_omap i2c_omap.1: controller timed out
>>><3>twl4030_usb: i2c write failed, line 422
>>
>>Looks suspiciously like the symptons in
>>
>>http://code.google.com/p/beagleboard/issues/detail?id=14
> 
> 
> This also looks similar to the earlier twl4030 hangs where access
> to some domains caused twl4030 to hang. If twl4030 hangs, there's
> no way to reset it as all control is over I2C. When twl4030 hangs,
> bootloader won't be able to detect the chip either unless devices
> is power cycled (and USB cable detached).
> 
> The reason earlier was that twl4030 internal clock was not being
> programmed properly, and was fixed by patch
> 0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d.

Link for this is

http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d

I don't know OMAP3 good enough yet, but which clock should we use on 
OMAP3 here?

Does it make sense to use osc_ck for OMAP3 instead of osc_sys_ck, too?

E.g something like

...
if (cpu_is_omap2430() || cpu_is_omap34xx())
   osc = clk_get(NULL, "osc_ck");
else
   osc = clk_get(NULL, "osc_sys_ck");
...

Dirk

Re: [beagleboard] Re: TWL4030 intermittent freakout on boot

[Tony Lindgren]

* Dirk Behme <dirk.behme@googlemail.com> [080509 11:08]:
> Tony Lindgren wrote:
>> * Koen Kooi <k.kooi@student.utwente.nl> [080508 11:22]:
>>
>>> Op 8 mei 2008, om 20:13 heeft Paul Walmsley het volgende geschreven:
>>>
>>>> Hello everyone,
>>>>
>>>> occasionally the TWL4030 driver on the 3430SDP freaks out on boot.  
>>>>  (This
>>>> is either an ES2.0 or ES2.1, not sure.)  Here's a partial console   
>>>> log with
>>>> initcall debugging enabled.  This probably happens every thirty or  
>>>> forty
>>>> boots, I would guess.  The board does boot to userspace when this   
>>>> happens.
>>>>
>>>> Perhaps the TWL4030 experts out there might know what's going on?
>>>>
>>>> <3>i2c_omap i2c_omap.1: controller timed out
>>>> <3>i2c_omap i2c_omap.1: controller timed out
>>>> <3>twl4030_usb: i2c write failed, line 422
>>>
>>> Looks suspiciously like the symptons in
>>>
>>> http://code.google.com/p/beagleboard/issues/detail?id=14
>>
>>
>> This also looks similar to the earlier twl4030 hangs where access
>> to some domains caused twl4030 to hang. If twl4030 hangs, there's
>> no way to reset it as all control is over I2C. When twl4030 hangs,
>> bootloader won't be able to detect the chip either unless devices
>> is power cycled (and USB cable detached).
>>
>> The reason earlier was that twl4030 internal clock was not being
>> programmed properly, and was fixed by patch
>> 0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d.
>
> Link for this is
>
> http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d
>
> I don't know OMAP3 good enough yet, but which clock should we use on  
> OMAP3 here?

It should be osc_sys_ck for 34xx.

> Does it make sense to use osc_ck for OMAP3 instead of osc_sys_ck, too?
>
> E.g something like
>
> ...
> if (cpu_is_omap2430() || cpu_is_omap34xx())
>   osc = clk_get(NULL, "osc_ck");
> else
>   osc = clk_get(NULL, "osc_sys_ck");
> ...

There's no osc_ck in clock34xx.h.

But what I'm thinking is that maybe the MMC driver does twl4030 calls
before the twl4030 clock is programmed to the right value?

Tony

Re: [beagleboard] Re: TWL4030 intermittent freakout on boot

[Steve Sakoman]

FWIW, I've never had any issues with the twl4030 on my OMAP3 EVM.
Both it and the MMC come up fine every boot.

I'm sure that by saying that I have jinxed myself and will have no end
of issues from this point forward :-)

It's not obvious from looking at the board files why this might be.
Perhaps the order of inits?

Steve

On Fri, May 9, 2008 at 2:36 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Dirk Behme <dirk.behme@googlemail.com> [080509 11:08]:
>
>
> > Tony Lindgren wrote:
>  >> * Koen Kooi <k.kooi@student.utwente.nl> [080508 11:22]:
>  >>
>  >>> Op 8 mei 2008, om 20:13 heeft Paul Walmsley het volgende geschreven:
>  >>>
>  >>>> Hello everyone,
>  >>>>
>  >>>> occasionally the TWL4030 driver on the 3430SDP freaks out on boot.
>  >>>>  (This
>  >>>> is either an ES2.0 or ES2.1, not sure.)  Here's a partial console
>  >>>> log with
>  >>>> initcall debugging enabled.  This probably happens every thirty or
>  >>>> forty
>  >>>> boots, I would guess.  The board does boot to userspace when this
>  >>>> happens.
>  >>>>
>  >>>> Perhaps the TWL4030 experts out there might know what's going on?
>  >>>>
>  >>>> <3>i2c_omap i2c_omap.1: controller timed out
>  >>>> <3>i2c_omap i2c_omap.1: controller timed out
>  >>>> <3>twl4030_usb: i2c write failed, line 422
>  >>>
>  >>> Looks suspiciously like the symptons in
>  >>>
>  >>> http://code.google.com/p/beagleboard/issues/detail?id=14
>  >>
>  >>
>  >> This also looks similar to the earlier twl4030 hangs where access
>  >> to some domains caused twl4030 to hang. If twl4030 hangs, there's
>  >> no way to reset it as all control is over I2C. When twl4030 hangs,
>  >> bootloader won't be able to detect the chip either unless devices
>  >> is power cycled (and USB cable detached).
>  >>
>  >> The reason earlier was that twl4030 internal clock was not being
>  >> programmed properly, and was fixed by patch
>  >> 0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d.
>  >
>  > Link for this is
>  >
>  > http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d
>  >
>  > I don't know OMAP3 good enough yet, but which clock should we use on
>  > OMAP3 here?
>
>  It should be osc_sys_ck for 34xx.
>
>
>  > Does it make sense to use osc_ck for OMAP3 instead of osc_sys_ck, too?
>  >
>  > E.g something like
>  >
>  > ...
>  > if (cpu_is_omap2430() || cpu_is_omap34xx())
>  >   osc = clk_get(NULL, "osc_ck");
>  > else
>  >   osc = clk_get(NULL, "osc_sys_ck");
>  > ...
>
>  There's no osc_ck in clock34xx.h.
>
>  But what I'm thinking is that maybe the MMC driver does twl4030 calls
>  before the twl4030 clock is programmed to the right value?
>
>  Tony
>
>
> --
>  To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>  the body of a message to majordomo@vger.kernel.org
>  More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [beagleboard] Re: TWL4030 intermittent freakout on boot

[Dirk Behme]

Steve Sakoman wrote:
> FWIW, I've never had any issues with the twl4030 on my OMAP3 EVM.
> Both it and the MMC come up fine every boot.
> 
> I'm sure that by saying that I have jinxed myself and will have no end
> of issues from this point forward :-)
> 
> It's not obvious from looking at the board files why this might be.
> Perhaps the order of inits?

How do you boot OMAP3 EVM? Or better, does your bootloader touch TWL?

Below, Tony mentioned "But what I'm thinking is that maybe the MMC 
driver does twl4030 calls before the twl4030 clock is programmed to 
the right value?"

Looking into U-Boot for Beagle in u-boot/cpu/omap3/mmc.c there is

void twl4030_mmc_config(void)
{
	unsigned char data;

	data = 0x20;
	i2c_write(0x4B, 0x82, 1, &data, 1);
	data = 0x2;
	i2c_write(0x4B, 0x85, 1, &data, 1);
	return 1;
}

So, on Beagle we are touching TWL *before* kernel (can program right 
clock value). Now, I wonder if u-boot code above is correct compared 
to kernel/drivers/i2c/chips/twl4030-core.c :

static int power_companion_init(void)
{
	struct clk *osc;
	u32 rate;
	u8 ctrl = HFCLK_FREQ_26_MHZ;
	int e = 0;

	if (cpu_is_omap2430())
		osc = clk_get(NULL, "osc_ck");
	else
		osc = clk_get(NULL, "osc_sys_ck");
	if (IS_ERR(osc)) {
		printk(KERN_WARNING "Skipping twl3040 internal clock init and "
				"using bootloader value (unknown osc rate)\n");
		return 0;
	}

	rate = clk_get_rate(osc);
	clk_put(osc);

	switch (rate) {
	case 19200000 : ctrl = HFCLK_FREQ_19p2_MHZ; break;
	case 26000000 : ctrl = HFCLK_FREQ_26_MHZ; break;
	case 38400000 : ctrl = HFCLK_FREQ_38p4_MHZ; break;
	}

	ctrl |= HIGH_PERF_SQ;
	e |= unprotect_pm_master();
	/* effect->MADC+USB ck en */
	e |= twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, ctrl, R_CFG_BOOT);
	e |= protect_pm_master();

	return e;
}

or if we have to add/remove/fix something in U-Boot?

Dirk

> On Fri, May 9, 2008 at 2:36 PM, Tony Lindgren <tony@atomide.com> wrote:
> 
>>* Dirk Behme <dirk.behme@googlemail.com> [080509 11:08]:
>>
>>
>>
>>>Tony Lindgren wrote:
>>
>> >> * Koen Kooi <k.kooi@student.utwente.nl> [080508 11:22]:
>> >>
>> >>> Op 8 mei 2008, om 20:13 heeft Paul Walmsley het volgende geschreven:
>> >>>
>> >>>> Hello everyone,
>> >>>>
>> >>>> occasionally the TWL4030 driver on the 3430SDP freaks out on boot.
>> >>>>  (This
>> >>>> is either an ES2.0 or ES2.1, not sure.)  Here's a partial console
>> >>>> log with
>> >>>> initcall debugging enabled.  This probably happens every thirty or
>> >>>> forty
>> >>>> boots, I would guess.  The board does boot to userspace when this
>> >>>> happens.
>> >>>>
>> >>>> Perhaps the TWL4030 experts out there might know what's going on?
>> >>>>
>> >>>> <3>i2c_omap i2c_omap.1: controller timed out
>> >>>> <3>i2c_omap i2c_omap.1: controller timed out
>> >>>> <3>twl4030_usb: i2c write failed, line 422
>> >>>
>> >>> Looks suspiciously like the symptons in
>> >>>
>> >>> http://code.google.com/p/beagleboard/issues/detail?id=14
>> >>
>> >>
>> >> This also looks similar to the earlier twl4030 hangs where access
>> >> to some domains caused twl4030 to hang. If twl4030 hangs, there's
>> >> no way to reset it as all control is over I2C. When twl4030 hangs,
>> >> bootloader won't be able to detect the chip either unless devices
>> >> is power cycled (and USB cable detached).
>> >>
>> >> The reason earlier was that twl4030 internal clock was not being
>> >> programmed properly, and was fixed by patch
>> >> 0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d.
>> >
>> > Link for this is
>> >
>> > http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d
>> >
>> > I don't know OMAP3 good enough yet, but which clock should we use on
>> > OMAP3 here?
>>
>> It should be osc_sys_ck for 34xx.
>>
>>
>> > Does it make sense to use osc_ck for OMAP3 instead of osc_sys_ck, too?
>> >
>> > E.g something like
>> >
>> > ...
>> > if (cpu_is_omap2430() || cpu_is_omap34xx())
>> >   osc = clk_get(NULL, "osc_ck");
>> > else
>> >   osc = clk_get(NULL, "osc_sys_ck");
>> > ...
>>
>> There's no osc_ck in clock34xx.h.
>>
>> But what I'm thinking is that maybe the MMC driver does twl4030 calls
>> before the twl4030 clock is programmed to the right value?
>>
>> Tony
>>
>>
>>--
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> 

Re: [beagleboard] Re: TWL4030 intermittent freakout on boot

[Steve Sakoman]

A grep of u-boot sources for the OMAP3 EVM does not yield any
occurrences of twl403 so you might be on to something with this
theory!

Also, I boot from on-board onenand so that is another major difference.

Steve

On Sat, May 10, 2008 at 2:37 AM, Dirk Behme <dirk.behme@googlemail.com> wrote:
> Steve Sakoman wrote:
>
> > FWIW, I've never had any issues with the twl4030 on my OMAP3 EVM.
> > Both it and the MMC come up fine every boot.
> >
> > I'm sure that by saying that I have jinxed myself and will have no end
> > of issues from this point forward :-)
> >
> > It's not obvious from looking at the board files why this might be.
> > Perhaps the order of inits?
> >
>
>  How do you boot OMAP3 EVM? Or better, does your bootloader touch TWL?
>
>  Below, Tony mentioned "But what I'm thinking is that maybe the MMC driver
> does twl4030 calls before the twl4030 clock is programmed to the right
> value?"
>
>  Looking into U-Boot for Beagle in u-boot/cpu/omap3/mmc.c there is
>
>  void twl4030_mmc_config(void)
>  {
>         unsigned char data;
>
>         data = 0x20;
>         i2c_write(0x4B, 0x82, 1, &data, 1);
>         data = 0x2;
>         i2c_write(0x4B, 0x85, 1, &data, 1);
>         return 1;
>  }
>
>  So, on Beagle we are touching TWL *before* kernel (can program right clock
> value). Now, I wonder if u-boot code above is correct compared to
> kernel/drivers/i2c/chips/twl4030-core.c :
>
>  static int power_companion_init(void)
>  {
>         struct clk *osc;
>         u32 rate;
>         u8 ctrl = HFCLK_FREQ_26_MHZ;
>         int e = 0;
>
>         if (cpu_is_omap2430())
>
>                 osc = clk_get(NULL, "osc_ck");
>         else
>                 osc = clk_get(NULL, "osc_sys_ck");
>         if (IS_ERR(osc)) {
>                 printk(KERN_WARNING "Skipping twl3040 internal clock init
> and "
>                                 "using bootloader value (unknown osc
> rate)\n");
>                 return 0;
>         }
>
>         rate = clk_get_rate(osc);
>         clk_put(osc);
>
>         switch (rate) {
>         case 19200000 : ctrl = HFCLK_FREQ_19p2_MHZ; break;
>         case 26000000 : ctrl = HFCLK_FREQ_26_MHZ; break;
>         case 38400000 : ctrl = HFCLK_FREQ_38p4_MHZ; break;
>         }
>
>         ctrl |= HIGH_PERF_SQ;
>         e |= unprotect_pm_master();
>         /* effect->MADC+USB ck en */
>         e |= twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, ctrl,
> R_CFG_BOOT);
>         e |= protect_pm_master();
>
>         return e;
>  }
>
>  or if we have to add/remove/fix something in U-Boot?
>
>  Dirk
>
>
>
>
> > On Fri, May 9, 2008 at 2:36 PM, Tony Lindgren <tony@atomide.com> wrote:
> >
> >
> > > * Dirk Behme <dirk.behme@googlemail.com> [080509 11:08]:
> > >
> > >
> > >
> > >
> > > > Tony Lindgren wrote:
> > > >
> > >
> > > >> * Koen Kooi <k.kooi@student.utwente.nl> [080508 11:22]:
> > > >>
> > > >>> Op 8 mei 2008, om 20:13 heeft Paul Walmsley het volgende geschreven:
> > > >>>
> > > >>>> Hello everyone,
> > > >>>>
> > > >>>> occasionally the TWL4030 driver on the 3430SDP freaks out on boot.
> > > >>>>  (This
> > > >>>> is either an ES2.0 or ES2.1, not sure.)  Here's a partial console
> > > >>>> log with
> > > >>>> initcall debugging enabled.  This probably happens every thirty or
> > > >>>> forty
> > > >>>> boots, I would guess.  The board does boot to userspace when this
> > > >>>> happens.
> > > >>>>
> > > >>>> Perhaps the TWL4030 experts out there might know what's going on?
> > > >>>>
> > > >>>> <3>i2c_omap i2c_omap.1: controller timed out
> > > >>>> <3>i2c_omap i2c_omap.1: controller timed out
> > > >>>> <3>twl4030_usb: i2c write failed, line 422
> > > >>>
> > > >>> Looks suspiciously like the symptons in
> > > >>>
> > > >>> http://code.google.com/p/beagleboard/issues/detail?id=14
> > > >>
> > > >>
> > > >> This also looks similar to the earlier twl4030 hangs where access
> > > >> to some domains caused twl4030 to hang. If twl4030 hangs, there's
> > > >> no way to reset it as all control is over I2C. When twl4030 hangs,
> > > >> bootloader won't be able to detect the chip either unless devices
> > > >> is power cycled (and USB cable detached).
> > > >>
> > > >> The reason earlier was that twl4030 internal clock was not being
> > > >> programmed properly, and was fixed by patch
> > > >> 0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d.
> > > >
> > > > Link for this is
> > > >
> > > >
> http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d
> > > >
> > > > I don't know OMAP3 good enough yet, but which clock should we use on
> > > > OMAP3 here?
> > >
> > > It should be osc_sys_ck for 34xx.
> > >
> > >
> > > > Does it make sense to use osc_ck for OMAP3 instead of osc_sys_ck, too?
> > > >
> > > > E.g something like
> > > >
> > > > ...
> > > > if (cpu_is_omap2430() || cpu_is_omap34xx())
> > > >   osc = clk_get(NULL, "osc_ck");
> > > > else
> > > >   osc = clk_get(NULL, "osc_sys_ck");
> > > > ...
> > >
> > > There's no osc_ck in clock34xx.h.
> > >
> > > But what I'm thinking is that maybe the MMC driver does twl4030 calls
> > > before the twl4030 clock is programmed to the right value?
> > >
> > > Tony
> > >
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > >
> > >
> >
> >
> >
>
>

RE: [beagleboard] Re: TWL4030 intermittent freakout on boot

[Woodruff, Richard]

Hi,

> A grep of u-boot sources for the OMAP3 EVM does not yield any
> occurrences of twl403 so you might be on to something with this
> theory!

Your SYS_BOOT line values make a difference in TWL behavior.  The mask ROM knows specifics about this companion chip.

One aspect people seem to miss is the fact that the mask ROM will touch T2 based on the boot order.  The mask ROM also monkeys with some internal clocks and modules.

So, just because your x-loader or u-boot doesn't touch a register that doesn't mean the mask ROM hasn't.  So don't expect reset value.

Regards,
Richard W.

Re: [beagleboard] Re: TWL4030 intermittent freakout on boot

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Op 10 mei 2008, om 16:57 heeft Woodruff, Richard het volgende  
geschreven:
> Hi,
>
>> A grep of u-boot sources for the OMAP3 EVM does not yield any
>> occurrences of twl403 so you might be on to something with this
>> theory!
>
> Your SYS_BOOT line values make a difference in TWL behavior.  The  
> mask ROM knows specifics about this companion chip.
>
> One aspect people seem to miss is the fact that the mask ROM will  
> touch T2 based on the boot order.  The mask ROM also monkeys with  
> some internal clocks and modules.
>
> So, just because your x-loader or u-boot doesn't touch a register  
> that doesn't mean the mask ROM hasn't.  So don't expect reset value.

Would it be an option to dump TWL regs with something like devmem2  
after boot for the .22 WTBU kernels and linux-omap git ones? Or just  
printk() them during early boot? It would be nice the have the correct  
values, so the git twl driver can use those.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFIJbxOMkyGM64RGpERAkufAKCSRqUoZxcjzdQNTARs3/Uo2RjYaACfYcwo
3Niob3Jr57b3c1QmDU9CWDk=
=TzdK
-----END PGP SIGNATURE-----

Re: [beagleboard] Re: TWL4030 intermittent freakout on boot

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Op 9 mei 2008, om 23:36 heeft Tony Lindgren het volgende geschreven:
> * Dirk Behme <dirk.behme@googlemail.com> [080509 11:08]:
>> Tony Lindgren wrote:
>>>
>> http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d
>>
>> I don't know OMAP3 good enough yet, but which clock should we use on
>> OMAP3 here?
>
> It should be osc_sys_ck for 34xx.
>
>> Does it make sense to use osc_ck for OMAP3 instead of osc_sys_ck,  
>> too?
>>
>> E.g something like
>>
>> ...
>> if (cpu_is_omap2430() || cpu_is_omap34xx())
>>  osc = clk_get(NULL, "osc_ck");
>> else
>>  osc = clk_get(NULL, "osc_sys_ck");
>> ...
>
> There's no osc_ck in clock34xx.h.

Does this patch make sense for omap3?

- --- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -779,7 +779,11 @@ int __init omap2_pm_init(void)
         l = __raw_readl(OMAP24XX_PRCM_REVISION);
         printk(KERN_INFO "PRCM revision %d.%d\n", (l >> 4) & 0x0f, l  
& 0x0f);

- -       osc_ck = clk_get(NULL, "osc_ck");
+       if (cpu_is_omap2430() )
+               osc_ck = clk_get(NULL, "osc_ck");
+       else
+               osc_ck = clk_get(NULL, "osc_sys_ck");
+
         if (IS_ERR(osc_ck)) {
                 printk(KERN_ERR "could not get osc_ck\n");
                 return -ENODEV;


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFIJWwEMkyGM64RGpERAnnYAKC8UMuAY0FPTDt0xbMoaWKo7eBWCwCfaal8
p388pzBedv0UHmduWhWJKqc=
=A+rF
-----END PGP SIGNATURE-----

Re: [beagleboard] Re: TWL4030 intermittent freakout on boot

[Tony Lindgren]

* Koen Kooi <k.kooi@student.utwente.nl> [080510 02:43]:
> 
> Op 9 mei 2008, om 23:36 heeft Tony Lindgren het volgende geschreven:
> > * Dirk Behme <dirk.behme@googlemail.com> [080509 11:08]:
> >> Tony Lindgren wrote:
> >>>
> >> http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d
> >>
> >> I don't know OMAP3 good enough yet, but which clock should we use on
> >> OMAP3 here?
> >
> > It should be osc_sys_ck for 34xx.
> >
> >> Does it make sense to use osc_ck for OMAP3 instead of osc_sys_ck,  
> >> too?
> >>
> >> E.g something like
> >>
> >> ...
> >> if (cpu_is_omap2430() || cpu_is_omap34xx())
> >>  osc = clk_get(NULL, "osc_ck");
> >> else
> >>  osc = clk_get(NULL, "osc_sys_ck");
> >> ...
> >
> > There's no osc_ck in clock34xx.h.
> 
> Does this patch make sense for omap3?
> 
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -779,7 +779,11 @@ int __init omap2_pm_init(void)
>          l = __raw_readl(OMAP24XX_PRCM_REVISION);
>          printk(KERN_INFO "PRCM revision %d.%d\n", (l >> 4) & 0x0f, l  
> & 0x0f);
> 
> -       osc_ck = clk_get(NULL, "osc_ck");
> +       if (cpu_is_omap2430() )
> +               osc_ck = clk_get(NULL, "osc_ck");
> +       else
> +               osc_ck = clk_get(NULL, "osc_sys_ck");
> +
>          if (IS_ERR(osc_ck)) {
>                  printk(KERN_ERR "could not get osc_ck\n");
>                  return -ENODEV;
> 
> 

Well it make sense, but does not alone help much. I think there will
be some 34xx PM patches hitting the list soonish.

Tony

Re: [beagleboard] Re: TWL4030 intermittent freakout on boot

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Op 12 mei 2008, om 18:10 heeft Tony Lindgren het volgende geschreven:
> * Koen Kooi <k.kooi@student.utwente.nl> [080510 02:43]:
>>
>> Op 9 mei 2008, om 23:36 heeft Tony Lindgren het volgende geschreven:
>>> * Dirk Behme <dirk.behme@googlemail.com> [080509 11:08]:
>>>> Tony Lindgren wrote:
>>>>>
>>>> http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d
>>>>
>>>> I don't know OMAP3 good enough yet, but which clock should we use  
>>>> on
>>>> OMAP3 here?
>>>
>>> It should be osc_sys_ck for 34xx.
>>>
>>>> Does it make sense to use osc_ck for OMAP3 instead of osc_sys_ck,
>>>> too?
>>>>
>>>> E.g something like
>>>>
>>>> ...
>>>> if (cpu_is_omap2430() || cpu_is_omap34xx())
>>>> osc = clk_get(NULL, "osc_ck");
>>>> else
>>>> osc = clk_get(NULL, "osc_sys_ck");
>>>> ...
>>>
>>> There's no osc_ck in clock34xx.h.
>>
>> Does this patch make sense for omap3?
>>
>> --- a/arch/arm/mach-omap2/pm.c
>> +++ b/arch/arm/mach-omap2/pm.c
>> @@ -779,7 +779,11 @@ int __init omap2_pm_init(void)
>>         l = __raw_readl(OMAP24XX_PRCM_REVISION);
>>         printk(KERN_INFO "PRCM revision %d.%d\n", (l >> 4) & 0x0f, l
>> & 0x0f);
>>
>> -       osc_ck = clk_get(NULL, "osc_ck");
>> +       if (cpu_is_omap2430() )
>> +               osc_ck = clk_get(NULL, "osc_ck");
>> +       else
>> +               osc_ck = clk_get(NULL, "osc_sys_ck");
>> +
>>         if (IS_ERR(osc_ck)) {
>>                 printk(KERN_ERR "could not get osc_ck\n");
>>                 return -ENODEV;
>>
>>
>
> Well it make sense, but does not alone help much. I think there will
> be some 34xx PM patches hitting the list soonish.

It actually makes my beagleboard freeze right after printing "PRCM  
revision", so I suspect more is needed. I'm eagerly awaiting the PM  
patches :)

regards,

Koen
>
>
> Tony
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFIKG2RMkyGM64RGpERAphOAJ4rZhFUsv/lX7Nq5dkZoDmtzEveFgCfc2oU
OlrtbS1JBNIyIZDhTViahgw=
=9jvA
-----END PGP SIGNATURE-----