On Monday 04 June 2012 11:27:04 pm Greg Ungerer wrote: > Hi Steven, > > On 22/05/12 06:10, Steven King wrote: > > If we're not connecting external GPIO extenders via i2c or spi or > > whatever, we probably don't need GPIOLIB. If we provide an alternate > > implementation of the GPIOLIB functions to use when only on-chip GPIO is > > needed, we can change ARCH_REQUIRE_GPIOLIB to ARCH_WANTS_OPTIONAL_GPIOLIB > > so that GPIOLIB becomes optional. > > > > The downside is that in the GPIOLIB=n case, we lose all error checking > > done by gpiolib, ie multiply allocating the gpio, free'ing gpio etc., so > > that the only checking that can be done is if we reference a gpio on an > > external part. Targets that need the extra error checking can still > > select GPIOLIB=y. > > > > For the case where GPIOLIB=y, we can simplify the table of gpio chips to > > use a single chip, eliminating the tables of chips in the 5xxx.c files. > > The original motivation for the definition of multiple chips was to match > > the way many of the Coldfire variants defined their gpio as a spare array > > in memory. However, all this really gains us is some error checking when > > we request a gpio, gpiolib can check that it doesn't fall in one of the > > holes. If thats important, I think we can still come up with a better > > way of accomplishing that. > > > > Also in this patch is some general cleanup and reorganizing of the gpio > > header files (I'm sure I must have had a reason why I sometimes used a > > prefix of mcf_gpio and other times mcfgpio but for the life of me I can't > > think of it now). > > > > Signed-off-by: Steven King<sfk...@fdwdc.com> > > This looks pretty good to me. I like the simplified setup and use. > If you are still happy with it I can apply to the for-next branch of > the m68knommu git tree?
Yes, please do. Thanks. _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev