[PATCH] hxd8-resume.patch

Harald Welte laforge at openmoko.org
Wed May 23 10:04:47 CEST 2007

On Wed, May 23, 2007 at 09:47:19AM +0200, Arnaud Patard wrote:
> >> hmmm... Sorry, but I don't understand. When loaded, the ts driver configures
> >> the gpio to "ts mode" and doesn't play anymore with them. Nothing to do
> >> with suspend/resume.
> >
> > well, not exactly.  Without looking at the documentation again, IIRC the GPG[13:15]
> > gpio's are used to determine the bootup memory configuration on the
> > s3c2440.  The resume-from-RAM code in a NAND-only configuration requires
> 2440 ? uh... I though we were talking about the 2410 :(

no, hxd8 and gta02 have 2440. later down the road we might also
use the s3c2443.

> > The current s3c2410_ts driver however seems to assume that it is always
> > only running on s3c2410, not s3c2440.  Thus, it reconfigures GPG12..15
> > unconditionally.
> the ts driver is called "s3c2410_ts" for some reason :) 

well, lots of drivers are called '2410_something' and in fact work on a
combination of 2400,2410,2412,2440,2442 (and maybe even 2443) ;)

> For the 2440 but the driver may need some tweaks. I'm not even sure
> that you need to play with GPG12..15 (I don't have a 2440 datasheet at
> hand so it's iirc).

the driver functionality seems to work fine, only that GPIO
configuration seems broken on 2440.

> > The correct solution to this problem thus is: Put the GPG12..15
> > initialization in a s3c2410 specific section (runtime, not compile
> > time).
> What about doint like in the udc driver: different platforms driver
> structure and check against pdev->name ? 

hm, ok, sounds like a good compromise.

> May be interesting also to look at the other SoC from Samsung if they
> need similar tweak so that you can design a generic solution not
> something limited to s3c2410/s3c2440.

Well, nobody actually needs any tweak.  I am sure your driver works fine
without a flaw on most 24xx as long as you don't touch the GPIO config. 

Usually, I would assume that the bootloader configures the GPIO
correctly, i.e. the kernel driver should not have to change that.  But I
understand that many devices might have buggy/incomplete/incooperative

- Harald Welte <laforge at openmoko.org>          	        http://openmoko.org/
Software for the world's first truly open Free Software mobile phone

More information about the openmoko-kernel mailing list