On Wednesday 06 June 2012 12:07:33 am Greg Ungerer wrote: > Hi Steven, > > On 06/06/12 00:23, Steven King wrote: > > On Monday 04 June 2012 11:27:04 pm Greg Ungerer wrote: > >> 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. > > Ok, done. I had a merge conflict on Kconfig.cpu, but I thinked I > fixed it up right.
Yeah, I ran into that conflict too when I rebased my trees; curious, I looked at the log and that ARCH_HAVE_CUSTOM_GPIO_H was added by Mark Brown, and from the commit message it sounds like removing it as you did may break whatever it was he was intending. (cc'ing Mark). _______________________________________________ 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
