From: Ben Dooks <ben-linux@fluff.org>
To: christian pellegrin <chripell@fsfe.org>
Cc: Ben Dooks <ben-linux@fluff.org>,
linux-samsung-soc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, anarsoul@gmail.com
Subject: Re: [PATCH v2.6.34-rc2] s3c: Fix GPIOs bank H and J not being preserved during suspend on S3C24XX
Date: Thu, 6 May 2010 06:51:34 +0100 [thread overview]
Message-ID: <20100506055134.GM26401@trinity.fluff.org> (raw)
In-Reply-To: <i2lcabda6421005040034hf27d04f7m95ff2cda9333ff93@mail.gmail.com>
On Tue, May 04, 2010 at 09:34:01AM +0200, christian pellegrin wrote:
> On Tue, May 4, 2010 at 9:01 AM, Ben Dooks <ben-linux@fluff.org> wrote:
>
> >
> > could you send the gpio fix with the above change as a seperate patch
> > please?
> >
>
> Yes, no problem, I'll just wait for the "up-comming s3c2410_gpio
> fallout" patches so I can test everything with the new functions.
>
> BTW there is a nastiness in mixing old-style s3c24xx gpios and gpiolib
> ones for the J port found in the s3c2440. For the former you have to
> use S3C241?_GPJ* macros in regs-gpioj.h, for the later S3C2410_GPJ().
> The reason of this is the "hole" in GPIO registers address which
> breaks S3C2410_GPIO_BASE. So I'm looking forward for your
> reorganization of s3c24xx gpio to see if a patch is needed for this.
> Right now I'm using:
Yes, one of the reasons for these changes is to remove the gpio->regaddr
mappings we've been keeping around for a while. Given the new gpiolib code
it makes sense to base all the platform specific calls off the same numbering
scheme and even use the same data structures.
I'll post a series from the following, possibly later today.
http://git.fluff.org/gitweb?p=bjdooks/linux.git;a=shortlog;h=refs/heads/for-2635/s3c24xx-gpio
> diff --git a/arch/arm/mach-s3c2410/include/mach/regs-gpio.h
> b/arch/arm/mach-s3c2410/include/mach/regs-gpio.h
> index ebc85c6..a2eab90 100644
> --- a/arch/arm/mach-s3c2410/include/mach/regs-gpio.h
> +++ b/arch/arm/mach-s3c2410/include/mach/regs-gpio.h
> @@ -37,7 +37,16 @@
> S3C2400_BASEC2H(pin)+S3C24XX_VA_GPIO)
>
>
> -#define S3C2410_GPIO_BASE(pin) ((((pin) & ~31) >> 1) + S3C24XX_VA_GPIO)
> +#if !defined(__ASSEMBLER__) && defined(S3C24XX_VA_GPIO)
> +static inline void *S3C2410_GPIO_BASE(unsigned int pin)
> +{
> + unsigned int off = (pin & ~31) >> 1;
> +
> + if ((pin & ~31) == S3C2410_GPIO_J_START)
> + off += 0x50;
> + return S3C24XX_VA_GPIO + off;
> +}
> +#endif
> #define S3C2410_GPIO_OFFSET(pin) ((pin) & 31)
>
> so if I use, by mistake, S3C2410_GPJ() in s3c2410_gpio_cfgpin I don't
> shoot myself in the foot. If I understand you intentions S3C241?_GPJ*
> will go away after the mentioned patch series. Anyway I wait for your
> reorganization of s3c gpios to resubmit these patches if needed.
>
> Thanks,
>
> --
> Christian Pellegrin, see http://www.evolware.org/chri/
> "Real Programmers don't play tennis, or any other sport which requires
> you to change clothes. Mountain climbing is OK, and Real Programmers
> wear their climbing boots to work in case a mountain should suddenly
> spring up in the middle of the computer room."
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
WARNING: multiple messages have this Message-ID (diff)
From: ben-linux@fluff.org (Ben Dooks)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2.6.34-rc2] s3c: Fix GPIOs bank H and J not being preserved during suspend on S3C24XX
Date: Thu, 6 May 2010 06:51:34 +0100 [thread overview]
Message-ID: <20100506055134.GM26401@trinity.fluff.org> (raw)
In-Reply-To: <i2lcabda6421005040034hf27d04f7m95ff2cda9333ff93@mail.gmail.com>
On Tue, May 04, 2010 at 09:34:01AM +0200, christian pellegrin wrote:
> On Tue, May 4, 2010 at 9:01 AM, Ben Dooks <ben-linux@fluff.org> wrote:
>
> >
> > could you send the gpio fix with the above change as a seperate patch
> > please?
> >
>
> Yes, no problem, I'll just wait for the "up-comming s3c2410_gpio
> fallout" patches so I can test everything with the new functions.
>
> BTW there is a nastiness in mixing old-style s3c24xx gpios and gpiolib
> ones for the J port found in the s3c2440. For the former you have to
> use S3C241?_GPJ* macros in regs-gpioj.h, for the later S3C2410_GPJ().
> The reason of this is the "hole" in GPIO registers address which
> breaks S3C2410_GPIO_BASE. So I'm looking forward for your
> reorganization of s3c24xx gpio to see if a patch is needed for this.
> Right now I'm using:
Yes, one of the reasons for these changes is to remove the gpio->regaddr
mappings we've been keeping around for a while. Given the new gpiolib code
it makes sense to base all the platform specific calls off the same numbering
scheme and even use the same data structures.
I'll post a series from the following, possibly later today.
http://git.fluff.org/gitweb?p=bjdooks/linux.git;a=shortlog;h=refs/heads/for-2635/s3c24xx-gpio
> diff --git a/arch/arm/mach-s3c2410/include/mach/regs-gpio.h
> b/arch/arm/mach-s3c2410/include/mach/regs-gpio.h
> index ebc85c6..a2eab90 100644
> --- a/arch/arm/mach-s3c2410/include/mach/regs-gpio.h
> +++ b/arch/arm/mach-s3c2410/include/mach/regs-gpio.h
> @@ -37,7 +37,16 @@
> S3C2400_BASEC2H(pin)+S3C24XX_VA_GPIO)
>
>
> -#define S3C2410_GPIO_BASE(pin) ((((pin) & ~31) >> 1) + S3C24XX_VA_GPIO)
> +#if !defined(__ASSEMBLER__) && defined(S3C24XX_VA_GPIO)
> +static inline void *S3C2410_GPIO_BASE(unsigned int pin)
> +{
> + unsigned int off = (pin & ~31) >> 1;
> +
> + if ((pin & ~31) == S3C2410_GPIO_J_START)
> + off += 0x50;
> + return S3C24XX_VA_GPIO + off;
> +}
> +#endif
> #define S3C2410_GPIO_OFFSET(pin) ((pin) & 31)
>
> so if I use, by mistake, S3C2410_GPJ() in s3c2410_gpio_cfgpin I don't
> shoot myself in the foot. If I understand you intentions S3C241?_GPJ*
> will go away after the mentioned patch series. Anyway I wait for your
> reorganization of s3c gpios to resubmit these patches if needed.
>
> Thanks,
>
> --
> Christian Pellegrin, see http://www.evolware.org/chri/
> "Real Programmers don't play tennis, or any other sport which requires
> you to change clothes. Mountain climbing is OK, and Real Programmers
> wear their climbing boots to work in case a mountain should suddenly
> spring up in the middle of the computer room."
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
next prev parent reply other threads:[~2010-05-06 5:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-30 8:23 [PATCH v2.6.34-rc2] s3c: Fix GPIOs bank H and J not being preserved during suspend on S3C24XX Christian Pellegrin
2010-03-30 8:23 ` Christian Pellegrin
2010-04-23 6:33 ` Vasily Khoruzhick
2010-04-23 6:33 ` Vasily Khoruzhick
2010-05-04 7:01 ` Ben Dooks
2010-05-04 7:01 ` Ben Dooks
2010-05-04 7:34 ` christian pellegrin
2010-05-04 7:34 ` christian pellegrin
2010-05-06 5:51 ` Ben Dooks [this message]
2010-05-06 5:51 ` Ben Dooks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100506055134.GM26401@trinity.fluff.org \
--to=ben-linux@fluff.org \
--cc=anarsoul@gmail.com \
--cc=chripell@fsfe.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.