2009-06-20 09:11:00 +08:00
|
|
|
/*
|
|
|
|
|
* Coldfire generic GPIO support.
|
|
|
|
|
*
|
|
|
|
|
* (C) Copyright 2009, Steven King <sfking@fdwdc.com>
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; version 2 of the License.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
#include <linux/module.h>
|
2009-06-20 09:11:00 +08:00
|
|
|
#include <linux/init.h>
|
2011-12-22 07:09:54 +08:00
|
|
|
#include <linux/device.h>
|
2009-06-20 09:11:00 +08:00
|
|
|
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
#include <linux/io.h>
|
|
|
|
|
#include <asm/coldfire.h>
|
|
|
|
|
#include <asm/mcfsim.h>
|
2009-06-20 09:11:00 +08:00
|
|
|
#include <asm/mcfgpio.h>
|
|
|
|
|
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
int __mcfgpio_get_value(unsigned gpio)
|
|
|
|
|
{
|
|
|
|
|
return mcfgpio_read(__mcfgpio_ppdr(gpio)) & mcfgpio_bit(gpio);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(__mcfgpio_get_value);
|
|
|
|
|
|
|
|
|
|
void __mcfgpio_set_value(unsigned gpio, int value)
|
|
|
|
|
{
|
|
|
|
|
if (gpio < MCFGPIO_SCR_START) {
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
MCFGPIO_PORTTYPE data;
|
|
|
|
|
|
|
|
|
|
local_irq_save(flags);
|
|
|
|
|
data = mcfgpio_read(__mcfgpio_podr(gpio));
|
|
|
|
|
if (value)
|
|
|
|
|
data |= mcfgpio_bit(gpio);
|
|
|
|
|
else
|
|
|
|
|
data &= ~mcfgpio_bit(gpio);
|
|
|
|
|
mcfgpio_write(data, __mcfgpio_podr(gpio));
|
|
|
|
|
local_irq_restore(flags);
|
|
|
|
|
} else {
|
|
|
|
|
if (value)
|
|
|
|
|
mcfgpio_write(mcfgpio_bit(gpio),
|
|
|
|
|
MCFGPIO_SETR_PORT(gpio));
|
|
|
|
|
else
|
|
|
|
|
mcfgpio_write(~mcfgpio_bit(gpio),
|
|
|
|
|
MCFGPIO_CLRR_PORT(gpio));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(__mcfgpio_set_value);
|
2009-06-20 09:11:00 +08:00
|
|
|
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
int __mcfgpio_direction_input(unsigned gpio)
|
2009-06-20 09:11:00 +08:00
|
|
|
{
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
MCFGPIO_PORTTYPE dir;
|
|
|
|
|
|
|
|
|
|
local_irq_save(flags);
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
dir = mcfgpio_read(__mcfgpio_pddr(gpio));
|
|
|
|
|
dir &= ~mcfgpio_bit(gpio);
|
|
|
|
|
mcfgpio_write(dir, __mcfgpio_pddr(gpio));
|
2009-06-20 09:11:00 +08:00
|
|
|
local_irq_restore(flags);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
EXPORT_SYMBOL(__mcfgpio_direction_input);
|
2009-06-20 09:11:00 +08:00
|
|
|
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
int __mcfgpio_direction_output(unsigned gpio, int value)
|
2009-06-20 09:11:00 +08:00
|
|
|
{
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
MCFGPIO_PORTTYPE data;
|
|
|
|
|
|
|
|
|
|
local_irq_save(flags);
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
data = mcfgpio_read(__mcfgpio_pddr(gpio));
|
2014-05-22 07:00:31 +08:00
|
|
|
data |= mcfgpio_bit(gpio);
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
mcfgpio_write(data, __mcfgpio_pddr(gpio));
|
|
|
|
|
|
|
|
|
|
/* now set the data to output */
|
|
|
|
|
if (gpio < MCFGPIO_SCR_START) {
|
|
|
|
|
data = mcfgpio_read(__mcfgpio_podr(gpio));
|
|
|
|
|
if (value)
|
|
|
|
|
data |= mcfgpio_bit(gpio);
|
|
|
|
|
else
|
|
|
|
|
data &= ~mcfgpio_bit(gpio);
|
|
|
|
|
mcfgpio_write(data, __mcfgpio_podr(gpio));
|
|
|
|
|
} else {
|
|
|
|
|
if (value)
|
|
|
|
|
mcfgpio_write(mcfgpio_bit(gpio),
|
|
|
|
|
MCFGPIO_SETR_PORT(gpio));
|
|
|
|
|
else
|
|
|
|
|
mcfgpio_write(~mcfgpio_bit(gpio),
|
|
|
|
|
MCFGPIO_CLRR_PORT(gpio));
|
|
|
|
|
}
|
2009-06-20 09:11:00 +08:00
|
|
|
local_irq_restore(flags);
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(__mcfgpio_direction_output);
|
2009-06-20 09:11:00 +08:00
|
|
|
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
int __mcfgpio_request(unsigned gpio)
|
|
|
|
|
{
|
2009-06-20 09:11:00 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
EXPORT_SYMBOL(__mcfgpio_request);
|
2009-06-20 09:11:00 +08:00
|
|
|
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
void __mcfgpio_free(unsigned gpio)
|
2009-06-20 09:11:00 +08:00
|
|
|
{
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
__mcfgpio_direction_input(gpio);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(__mcfgpio_free);
|
2009-06-20 09:11:00 +08:00
|
|
|
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
#ifdef CONFIG_GPIOLIB
|
2009-06-20 09:11:00 +08:00
|
|
|
|
2014-05-22 07:00:32 +08:00
|
|
|
static int mcfgpio_direction_input(struct gpio_chip *chip, unsigned offset)
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
{
|
|
|
|
|
return __mcfgpio_direction_input(offset);
|
2009-06-20 09:11:00 +08:00
|
|
|
}
|
|
|
|
|
|
2014-05-22 07:00:32 +08:00
|
|
|
static int mcfgpio_get_value(struct gpio_chip *chip, unsigned offset)
|
2009-06-20 09:11:00 +08:00
|
|
|
{
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
return __mcfgpio_get_value(offset);
|
2009-06-20 09:11:00 +08:00
|
|
|
}
|
|
|
|
|
|
2014-05-22 07:00:32 +08:00
|
|
|
static int mcfgpio_direction_output(struct gpio_chip *chip, unsigned offset,
|
|
|
|
|
int value)
|
2009-06-20 09:11:00 +08:00
|
|
|
{
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
return __mcfgpio_direction_output(offset, value);
|
2009-06-20 09:11:00 +08:00
|
|
|
}
|
|
|
|
|
|
2014-05-22 07:00:32 +08:00
|
|
|
static void mcfgpio_set_value(struct gpio_chip *chip, unsigned offset,
|
|
|
|
|
int value)
|
2009-06-20 09:11:00 +08:00
|
|
|
{
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
__mcfgpio_set_value(offset, value);
|
|
|
|
|
}
|
2009-06-20 09:11:00 +08:00
|
|
|
|
2014-05-22 07:00:32 +08:00
|
|
|
static int mcfgpio_request(struct gpio_chip *chip, unsigned offset)
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
{
|
|
|
|
|
return __mcfgpio_request(offset);
|
|
|
|
|
}
|
2009-06-20 09:11:00 +08:00
|
|
|
|
2014-05-22 07:00:32 +08:00
|
|
|
static void mcfgpio_free(struct gpio_chip *chip, unsigned offset)
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
{
|
|
|
|
|
__mcfgpio_free(offset);
|
2009-06-20 09:11:00 +08:00
|
|
|
}
|
|
|
|
|
|
2014-05-22 07:00:32 +08:00
|
|
|
static int mcfgpio_to_irq(struct gpio_chip *chip, unsigned offset)
|
2014-05-22 07:00:30 +08:00
|
|
|
{
|
|
|
|
|
#if defined(MCFGPIO_IRQ_MIN)
|
|
|
|
|
if ((offset >= MCFGPIO_IRQ_MIN) && (offset < MCFGPIO_IRQ_MAX))
|
|
|
|
|
#else
|
|
|
|
|
if (offset < MCFGPIO_IRQ_MAX)
|
|
|
|
|
#endif
|
|
|
|
|
return MCFGPIO_IRQ_VECBASE + offset;
|
|
|
|
|
else
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
2014-05-22 07:00:32 +08:00
|
|
|
static struct bus_type mcfgpio_subsys = {
|
2011-12-22 07:09:54 +08:00
|
|
|
.name = "gpio",
|
|
|
|
|
.dev_name = "gpio",
|
2009-06-20 09:11:00 +08:00
|
|
|
};
|
|
|
|
|
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
static struct gpio_chip mcfgpio_chip = {
|
|
|
|
|
.label = "mcfgpio",
|
|
|
|
|
.request = mcfgpio_request,
|
|
|
|
|
.free = mcfgpio_free,
|
|
|
|
|
.direction_input = mcfgpio_direction_input,
|
|
|
|
|
.direction_output = mcfgpio_direction_output,
|
|
|
|
|
.get = mcfgpio_get_value,
|
|
|
|
|
.set = mcfgpio_set_value,
|
2014-05-22 07:00:30 +08:00
|
|
|
.to_irq = mcfgpio_to_irq,
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
.base = 0,
|
|
|
|
|
.ngpio = MCFGPIO_PIN_MAX,
|
|
|
|
|
};
|
2012-04-17 11:25:38 +08:00
|
|
|
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
static int __init mcfgpio_sysinit(void)
|
|
|
|
|
{
|
|
|
|
|
gpiochip_add(&mcfgpio_chip);
|
|
|
|
|
return subsys_system_register(&mcfgpio_subsys, NULL);
|
2009-06-20 09:11:00 +08:00
|
|
|
}
|
|
|
|
|
|
m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.
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 <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-22 04:10:19 +08:00
|
|
|
core_initcall(mcfgpio_sysinit);
|
|
|
|
|
#endif
|