Re: S3C24XX: Ensure GPIO pins are configure properly on init and resume.

[Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>]

On Thu, Jul 31, 2008 at 01:14:42AM -0700, David Brownell wrote:
> On Tuesday 29 July 2008, Ben Dooks wrote:
> 
> > @@ -412,6 +428,26 @@ static int s3c24xx_spi_suspend(struct pl
> >  {
> >  	struct s3c24xx_spi *hw = platform_get_drvdata(pdev);
> >  
> > +	/* Place the gpio associated with the controller into input over
> 
> Well, input-with-pullup.  As usual, we don't want inputs to float.  :)

Ok, the comment needs changing, we do ensure the weak-pin-pullups are
enabled.
 
> 
> > +	 * suspend as on resume the controller is reset and will end up
> > +	 * as a slave until we reconfigure it in the resume path.
> 
> Kind of unfriendly, and not something I've seen much on ARM, FWIW.

I'm not sure, this tends to be the case in the Samsung range that
blocks are powered down over suspend, and get reset whilst resuming. It
is just unfortunate in this case that the defaults are not what we need.
 
> I generally like to see pinmux stuff kept out of drivers, since it
> tends to change between revisions more than the controller design.
> I take it that's not yet an issue with this controller ...

Yes, unfortunately this case needs fixing, even if it is to add a
callback to set the pin state to/from the spi pins and add some
common code in arch/arm/plat-s3c24xx to deal with this. Not all
devices come up in the state that you can directly connect them to
their pin blocks.

I'll check through all the range that has this block in them, iirc
S3C2410, S3C2412, S3C2440 and S3C2442... newer designs have a different
controller in them, so do not need to be consideres for this.
 
> 
> > 					This 
> > +	 * means that we cannot allow the controller to drive MISO line
> > +	 * during this period in case it drives against something on the
> > +	 * board.
> > +	 */
> > +
> 
> What I don't get is that there are two outputs other than chipselect
> (SCK on GPE13 and GPG7, and MOSI on GPE12 and GPG6), and you seem to
> remux those on bus 0 but *NOT* bus 1:
> 
> > +	if (pdev->id == 0) {
> > +		s3c2410_gpio_pullup(S3C2410_GPE12, 1);
> > +		s3c2410_gpio_pullup(S3C2410_GPE13, 1);
> > +		s3c2410_gpio_cfgpin(S3C2410_GPE12, S3C2410_GPIO_INPUT);
> > +		s3c2410_gpio_cfgpin(S3C2410_GPE11, S3C2410_GPIO_INPUT);
> > +	} else {
> > +		s3c2410_gpio_pullup(S3C2410_GPG5, 1);
> > +		s3c2410_gpio_pullup(S3C2410_GPG6, 1);
> > +		s3c2410_gpio_cfgpin(S3C2410_GPG6, S3C2410_GPIO_INPUT);
> > +		s3c2410_gpio_cfgpin(S3C2410_GPG5, S3C2410_GPIO_INPUT); 
> 
> ... where you do GPG6/MOSI alright, but GPG5/MISO not GPG7/SCK.

SCK will become an input when the controller pops into slave mode, it is
just the data pins that swap their meanings when the controller changes.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/