I2C problems (kernel init freeze)

Kernel development related

I2C problems (kernel init freeze)

Postby Dopi » Fri Oct 22, 2010 4:50 pm

Hi JetDroid developers,

here is a short summary of the currently planned I2C related features

Full I2C bus support
This is a fundamental requirement for more driver support in the kernel. Basic I2C communication is currently possible but some of the I2C ports seem to work not or only unreliable. One problem is currently that the kernel freezes during initialization if an access to some I2C devices is attempted. This issue urgently needs to be resolved.

Support for USB debugging (ADB)
This depends on I2C support as the USB bus from the phone USB connector is connected to the application processor via a USB switch. This switch is I2C controlled. Thus no USB connection is possible unless the switch is properly setup.

Cheers,
Dopi
Ad banners support the JetDroid forum. Please consider clicking them once in a while.
User avatar
Dopi
Dev Team
Dev Team
 
Posts: 926
Joined: Sun Aug 22, 2010 9:47 pm

Advertisement

Re: Roadmap (start helping here!)

Postby Thijs » Thu Oct 28, 2010 12:32 pm

Hi Dopi,

Just to make sure we all look at the same problem with respect to the I2C access (freeze) problem...

How do you reproduce the freeze exactly (compilation options, file modifications, manual actions, ...)?

Best regards
Thijs
Dev Team
Dev Team
 
Posts: 114
Joined: Fri Sep 10, 2010 6:28 pm

Re: Roadmap (start helping here!)

Postby Dopi » Thu Oct 28, 2010 1:43 pm

Thijs wrote:How do you reproduce the freeze exactly (compilation options, file modifications, manual actions, ...)?


The I2C problems become visible by some more or less obvious side-effects.

  1. CPU constantly running at 800MHz (this is less obvious but it can be lead to battery draining or increased heat)
    If the I2C communication to the PMU is not working the kernel cannot slow down the processor as the CPU core voltage needs to be reduced for this.
  2. Kernel freezes during initialization (this is quite obvious and can happen only if you compile your own kernel with changed I2C settings)
    This is actually the problem I was referring to in the roadmap / where to start post. Thus I will try to give some more background on this, now.

All below statements refer to the current experimental-2.6.29 kernel from our github repository (JetKernel-0.3pre1)

The function instinctq_machine_init in the kernel source file arch/arm/mach-s3c6410/mach-jet.c. Is the hardware specific initialization function called by the kernel. Before this fuction is called all interfaces (e.g. I2C including attached devices) should be initialized. However, the following call in line 1186
Code: Select all
// spica_ftm_enable_usb_sw(true);

or the following code called by check_pmic(); in line 1192
Code: Select all
static void check_pmic(void)
{
/* unsigned char reg_buff = 0;

if (Get_MAX8906_PM_REG(REG_CARD1TV, &reg_buff)) {
pr_info("%s: CARD1TV (%d)\n", __func__, reg_buff);
}
if (Get_MAX8906_PM_REG(REG_CARD1EN, &reg_buff)) {
pr_info("%s: CARD1EN 2.6V (%d)\n", __func__, reg_buff);
}
if (Get_MAX8906_PM_REG(REG_CARD1FSEQ, &reg_buff)) {
pr_info("%s: REG_CARD1FSEQ (%d)\n", __func__, reg_buff);
}
if (Get_MAX8906_PM_REG(REG_CARD2TV, &reg_buff)) {
pr_info("%s: CARD2TV (%d)\n", __func__, reg_buff);
}
if (Get_MAX8906_PM_REG(REG_CARD2EN, &reg_buff)) {
pr_info("%s: CARD2EN (%d)\n", __func__, reg_buff);
}
if (Get_MAX8906_PM_REG(REG_CARD2FSEQ, &reg_buff)) {
pr_info("%s: REG_CARD2FSEQ (%d)\n", __func__, reg_buff);
}

*/
}

is commented out as it would lead to the kernel freeze discribed above. This behaviour leeds me to the conclusion that the I2C interface or slave device driver does not work reliable.

Surprisingly the same kernel seems to work in a rare number of cases (I woudl say 1 in a 100 times) and the PMU setting (and cpu downcycling) was working in some previous kernel version.

It have been looking at this problem for quite some times and tried several I2C settings (see arch/arm/mach-s3c6410/mach-jet.c lines 135 - 194 (I2C GPIO) and arch/arm/plat-s3c/dev-i2c0.c or arch/arm/plat-s3c/dev-i2c1.c (hardware I2C) ). Thus I think I might be overseeing something obvious and could need a second opinion on this.

Cheers,
Dopi
Ad banners support the JetDroid forum. Please consider clicking them once in a while.
User avatar
Dopi
Dev Team
Dev Team
 
Posts: 926
Joined: Sun Aug 22, 2010 9:47 pm

Re: I2C problems (kernel init freeze)

Postby Dopi » Thu Oct 28, 2010 1:47 pm

A list of devices connected to the various I2C busses of the S3C6410 processor is in the old wiki here.
Ad banners support the JetDroid forum. Please consider clicking them once in a while.
User avatar
Dopi
Dev Team
Dev Team
 
Posts: 926
Joined: Sun Aug 22, 2010 9:47 pm

Re: I2C problems (kernel init freeze)

Postby Thijs » Thu Oct 28, 2010 6:44 pm

Hi Dopi,

Ok, shooting from the hip...

Did you try to increase the 10ms delay in line 536 of spica_ftm_enable_usb_sw() already?

And do you know when or where the kernel freezes? Did you try to add some additional debug statements already?

best regards - Thijs
Thijs
Dev Team
Dev Team
 
Posts: 114
Joined: Fri Sep 10, 2010 6:28 pm

Re: I2C problems (kernel init freeze)

Postby Dopi » Thu Oct 28, 2010 9:03 pm

Hi Thijs,

I did not try changing this delay but in most cases I did not even test spica_ftm_enable_usb_sw but rather the check_pmic function. This fails as soon as I uncomment one statement that would try to read or write PMU registers.

The problem with what I call freeze is that the kernel does not display messages at all. I suspect the kernel stops working either before the display initialized or the kernel message output is lagging behind the init process with ceases execution before any message can be displayed.

In the current situation it is like an on-off switch. If I remove the comments for lines 1046 to 1050 which should simply read a register from the PMU no kernel message is displayed at all if I leave them commented out the kernel starts normally.

Another possible cause for this problem could be that it is (for some silly reason) not good to send I2C command at this time of the init processs. But this does not make any sense to me.

Cheers,
Dopi
Ad banners support the JetDroid forum. Please consider clicking them once in a while.
User avatar
Dopi
Dev Team
Dev Team
 
Posts: 926
Joined: Sun Aug 22, 2010 9:47 pm

Re: I2C problems (kernel init freeze)

Postby Daenja » Fri Oct 29, 2010 10:38 am

This is maybe a dumb question but.. Have you tried to compare your source to the source from omnia2 or spica?? Maybe you'll get hints from there.

For instance... About whether the I2C command is in the right place of the source...

Best regards.
Daenja
Dev Team
Dev Team
 
Posts: 95
Joined: Fri Oct 29, 2010 10:33 am
Location: Finland

Re: I2C problems (kernel init freeze)

Postby Dopi » Fri Oct 29, 2010 12:04 pm

Hi Daenja,

if you ask me there are no dumb questions. The init source is based on the Spica/InstinctQ source code. Thus everything should be in the right place. The problem is that these phones have much in common but are still too different to copy the source 1:1. One difference in the I2C implementation on the Jet is for example that different IO pins are used compared to the Spica or Omnia II.

Cheers,
Dopi
Ad banners support the JetDroid forum. Please consider clicking them once in a while.
User avatar
Dopi
Dev Team
Dev Team
 
Posts: 926
Joined: Sun Aug 22, 2010 9:47 pm

Re: I2C problems (kernel init freeze)

Postby Daenja » Fri Oct 29, 2010 12:12 pm

Hi Dopi

Thanks for a quick answer. I was wondering when I looked the code you posted. Are you sure you've written it correctly? For instance parts called "card1tv, card1en, card2tv, card2en" shouldn't they be called "Reg_card1tv, reg_card1en, reg_card2tv, reg_card2en" as in the registry here: http://code.google.com/p/jetdroid/wiki/MAX8906EWA

I'm no programmer but I try to see this thing in a simple way :lol:
Daenja
Dev Team
Dev Team
 
Posts: 95
Joined: Fri Oct 29, 2010 10:33 am
Location: Finland

Re: I2C problems (kernel init freeze)

Postby Dopi » Fri Oct 29, 2010 12:32 pm

Okay, now I understand your point. The register is named correctly (e.g. "REG_CARD1TV") in the function call. Only in the debug output the "REG_" prefix is sometimes omitted. But this has no impact on the functionality. Everything else should have caused compile problems anyway ...

However, thanks for looking closely. :)

Cheers,
Dopi
Ad banners support the JetDroid forum. Please consider clicking them once in a while.
User avatar
Dopi
Dev Team
Dev Team
 
Posts: 926
Joined: Sun Aug 22, 2010 9:47 pm

Next

Return to JetKernel

Who is online

Users browsing this forum: No registered users and 2 guests

  • Advertisement
cron