On Mon, 14 Dec 2009 19:39 +0900 Marc Zyngier wrote: > On Mon, 14 Dec 2009 19:27:06 +0900 > Kukjin Kim <kgene.kim@xxxxxxxxxxx> wrote: > > > On Fri, Dec 11, 2009 at 20:16 +0900, Mark Brown wrote: > > > On Fri, Dec 11, 2009 at 12:00:11PM +0100, Marc Zyngier wrote: > > > > Kukjin Kim <kgene.kim@xxxxxxxxxxx> wrote: > > > > Hi Mark Brown and Marc Zyngier, > > > > > > > +/* define the number of gpios we need to the one after the GPR() range > > */ > > > > > +#define ARCH_NR_GPIOS > (S5P6440_GPR(S5P6440_GPIO_R_NR) > > > + 1) > > > > > > > Doing so prevents the use of GPIO expanders. Either provide a config > > > > option to provide additional GPIO space, or just get rid of the #define. > > To satisfy your request, I know what to do. However, I don't know well the > > reason. Please explain the reason why need the use of GPIO expanders. As you > > know, the number of hardware GPIO pin is fixed and limited. And the limit > > value is ARCH_NR_GPIOS. > > Exactly because the number of GPIOs is limited (and in the case of 6440, > it is actually *very* limited), you may want to connect a GPIO expander > over I2C or SPI. > > By setting ARCH_NR_GPIOS to the number of GPIOs the SoC provides, > you're actually preventing any use of such hardware by giving a hard > limit to the gpiolib. The ARCH_NR_GPIO limit is actually, and despite > its name, a platform dependent value. > > I'm actually using a platform that has this exact requirement (6440 + > pca9539). Hi Marc Zyngier, Thanks for your detailed explain. Let me check and change it. > > > It also prevents the use of external devices with interrupt controllers > > > (eg, most PMICs these days). See the S3C24xx and S3C64xx code for > > > examples of how to avoid this limit. > > As you mentioned, I can find the code in the S3C24XX, but I can't in the > > S3C64XX. The S3C64XX codes are as follows: > > > > /* from arch/arm/mach-s3c6400/include/mach/gpio.h */ > > 93 /* define the number of gpios we need to the one after the GPQ() range */ > > 94 #define ARCH_NR_GPIOS (S3C64XX_GPQ(S3C64XX_GPIO_Q_NR) + 1) > > Then it needs to be fixed as well. Ok. > > Anyway, if the definition like my patch becomes problem, please let me know > > the reason. Thanks. Best regards, Kgene. -- Kukjin Kim <kgene.kim@xxxxxxxxxxx>, Senior Engineer, System LSI Division, SAMSUNG ELECTRONICS CO., LTD. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |