[PATCH 1/2] I2C: Convert PCF50606 to I2C device

Andy Green andy at openmoko.com
Fri Oct 3 16:50:45 CEST 2008

Hash: SHA1

Balaji Rao wrote:
> On Fri, 03 Oct 2008 15:05:28 +0100
> Andy Green <andy at openmoko.com> wrote:
>> Hash: SHA1
>> Balaji Rao wrote:
>>> On Fri, 03 Oct 2008 12:11:24 +0100
>>> Andy Green <andy at openmoko.com> wrote:
>>>> Hash: SHA1
>>>> Jonas Bonn wrote:
>>>>> This chip is a regular I2C device and does not really need to be
>>>>> set up as a platform device.  This patch thus changes the driver
>>>>> definition and converts the I2C bits to the new-style I2C
>>>>> interface at the same time.
>>>>>  	/* now we try to detect the chip */
>>>>> -
>>>>> -	/* register with i2c core */
>>>>> -	err = i2c_attach_client(new_client);
>>>>> -	if (err) {
>>>>> -		dev_err(&new_client->dev,
>>>>> -			"error during i2c_attach_client()\n");
>>>>> -		goto exit_free;
>>>>> -	}
>>>>> +	// FIXME: Detect chip????
>>>>> +	/* */
>>>> In I2C protocol if the chip at the address is not present it won't
>>>> ACK at the first opportunity and transactions will fail.  So all
>>>> that's needed here is first regular register transaction should
>>>> bail from probe if it returned -E*.
>>>>> -/* We have this purely to capture an early indication that we are
>>>>> coming out
>>>>> - * of suspend, before our device resume got called; async
>>>>> interrupt service is
>>>>> - * interested in this.
>>>>> - */
>>>>> -
>>>>> -static int pcf50606_plat_resume(struct platform_device *pdev)
>>>>> -{
>>>>> -	/* i2c_get_clientdata(to_i2c_client(&pdev->dev)) returns
>>>>> NULL at this
>>>>> -	 * early resume time so we have to use pcf50606_global
>>>>> -	 */
>>>>> -	pcf50606_global->suspend_state =
>>>>> -	return 0;
>>>>> -}
>>>> Dunno about 50606 but I think the equivalent was important on 50633
>>>> resume sequencing.  Did you confirm it suspend / resumes OK still?
>>> Andy,
>>> Let me see if suspend/resume plays well with the changes I've
>>> introduced. I forgot to test that one.
>> Well I don't think stable-tracking itself has good suspend / resume,
>> but any testing of it and reports of symptoms is helpful.  Sorry guys
>> the mud from it is splashing everyone today.
> Oh, yes. suspend/resume is broken in stable-tracking.
> How does one debug this ? Even the debug board seems useless when the
> CPU is asleep..

Normally you would debug it by enabling some configuration options that
cause the PM stuff to issue debug messages down debug console
synchronously, so you can see the sequencing and at least how far it
gets before it blows up.  But somehow our suspend / resume problems
involve one and probably more async events like interrupts.  The
problems seem change according to exact timing of the races between
these events and what the foreground suspend and resume code is doing.
Putting synchronous debug code in changes the behaviour completely.

In addition there are hard lockups from Glamo nWAIT, either during
suspend / resume or later when something tries to touch video memory.

I have added some patches on andy-tracking that help by spewing stored
dmesg and backtrace in the event of a PANIC, and have a patch that
causes a PANIC if you hit AUX during suspend / resume time.  So that way
you can probe a soft hang or soft crash during this period.

But really I am stuck fighting hard Glamo nWAIT hangs on the andy-
branches otherwise I think we could move on considerably.

Assuming there's still more to do on pcf50633, my advice is don't worry
about suspend-resume yet and carry on.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list