On 07/06/12 00:20, Steven King wrote:
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).
Relooking at it you may be right. It still compiles for coldfire
the way I did it. Wasn't sure if it only made sense to have
ARCH_HAVE_CUSTOM_GPIO_H if you also had ARCH_REQUIRE_GPIOLIB on.
In any, I have changed the patch on for-next to leave the
ARCH_HAVE_CUSTOM_GPIO_H in place. It does no harm being there.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
_______________________________________________
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
