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

[Balaji Rao]

On Fri, 03 Oct 2008 15:50:45 +0100
Andy Green <andy at openmoko.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Balaji Rao wrote:
> > On Fri, 03 Oct 2008 15:05:28 +0100
> > Andy Green <andy at openmoko.com> wrote:
> > 
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Balaji Rao wrote:
> >>> On Fri, 03 Oct 2008 12:11:24 +0100
> >>> Andy Green <andy at openmoko.com> wrote:
> >>>
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> 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 =
> >>>>> PCF50606_SS_RESUMING_BUT_NOT_US_YET; -
> >>>>> -	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.

Yes, there is quite a lot of stuff left! I'll move on..

	-Balaji