Re: [uClinux-dev] [RFC/PATCH] m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
On Thu, Jun 07, 2012 at 12:01:20PM +1000, Greg Ungerer wrote: On 07/06/12 00:20, Steven King wrote: 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. The goal of the patch is to allow architectures using gpiolib to provide an asm/gpio.h, without defining the symbol your asm/gpio.h should be ignored by gpiolib. signature.asc Description: Digital signature ___ 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
Re: [uClinux-dev] [RFC/PATCH] m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 Kingsfk...@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. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: 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
Re: [uClinux-dev] [RFC/PATCH] m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 Kingsfk...@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
Re: [uClinux-dev] [RFC/PATCH] m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 Kingsfk...@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 EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: 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
Re: [uClinux-dev] [RFC/PATCH] m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 Kingsfk...@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? Regards Greg -- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: 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
Re: [uClinux-dev] [RFC/PATCH] m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 Kingsfk...@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
