Re: [PATCH] pwm: Remove obsolete HAVE_PWM Kconfig symbol
On Thu, Jan 16, 2014 at 7:01 AM, Sascha Hauer wrote: > Before we had the PWM framework we used to have a barebone PWM api. The > HAVE_PWM Kconfig symbol used to be selected by the PWM drivers to specify > the PWM API is present in the kernel. Since the last legacy driver is gone > the HAVE_PWM symbol can go aswell. > > Signed-off-by: Sascha Hauer Looks good to me, happy to see it gone. > --- > > I suggest that Thierry as PWM Maintainer takes the patch through his tree. > Is that ok for you Thierry? > > arch/arm/Kconfig | 4 > arch/arm/mach-pxa/Kconfig | 15 --- > arch/mips/Kconfig | 1 - > drivers/input/misc/Kconfig | 4 ++-- > include/linux/pwm.h| 2 +- > 5 files changed, 3 insertions(+), 23 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index c1f1a7e..1b6f499 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -109,9 +109,6 @@ config ARM_DMA_IOMMU_ALIGNMENT > > endif > > -config HAVE_PWM > - bool > - > config MIGHT_HAVE_PCI > bool > > @@ -606,7 +603,6 @@ config ARCH_LPC32XX > select CPU_ARM926T > select GENERIC_CLOCKEVENTS > select HAVE_IDE > - select HAVE_PWM > select USB_ARCH_HAS_OHCI > select USE_OF > help > diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig > index 96100db..b96244c 100644 > --- a/arch/arm/mach-pxa/Kconfig > +++ b/arch/arm/mach-pxa/Kconfig > @@ -7,7 +7,6 @@ comment "Intel/Marvell Dev Platforms (sorted by hardware > release time)" > config MACH_PXA3XX_DT > bool "Support PXA3xx platforms from device tree" > select CPU_PXA300 > - select HAVE_PWM > select POWER_SUPPLY > select PXA3xx > select USE_OF > @@ -23,12 +22,10 @@ config ARCH_LUBBOCK > > config MACH_MAINSTONE > bool "Intel HCDDBBVA0 Development Platform (aka Mainstone)" > - select HAVE_PWM > select PXA27x > > config MACH_ZYLONITE > bool > - select HAVE_PWM > select PXA3xx > > config MACH_ZYLONITE300 > @@ -69,7 +66,6 @@ config ARCH_PXA_IDP > config ARCH_VIPER > bool "Arcom/Eurotech VIPER SBC" > select ARCOM_PCMCIA > - select HAVE_PWM > select I2C_GPIO > select ISA > select PXA25x > @@ -120,7 +116,6 @@ config MACH_CM_X300 > bool "CompuLab CM-X300 modules" > select CPU_PXA300 > select CPU_PXA310 > - select HAVE_PWM > select PXA3xx > > config MACH_CAPC7117 > @@ -211,7 +206,6 @@ config TRIZEPS_PCMCIA > > config MACH_LOGICPD_PXA270 > bool "LogicPD PXA270 Card Engine Development Platform" > - select HAVE_PWM > select PXA27x > > config MACH_PCM027 > @@ -222,7 +216,6 @@ config MACH_PCM027 > config MACH_PCM990_BASEBOARD > bool "PHYTEC PCM-990 development board" > depends on MACH_PCM027 > - select HAVE_PWM > > choice > prompt "display on pcm990" > @@ -246,7 +239,6 @@ config MACH_COLIBRI > config MACH_COLIBRI_PXA270_INCOME > bool "Income s.r.o. PXA270 SBC" > depends on MACH_COLIBRI > - select HAVE_PWM > select PXA27x > > config MACH_COLIBRI300 > @@ -275,7 +267,6 @@ comment "End-user Products (sorted by vendor name)" > > config MACH_H4700 > bool "HP iPAQ hx4700" > - select HAVE_PWM > select IWMMXT > select PXA27x > > @@ -289,14 +280,12 @@ config MACH_HIMALAYA > > config MACH_MAGICIAN > bool "Enable HTC Magician Support" > - select HAVE_PWM > select IWMMXT > select PXA27x > > config MACH_MIOA701 > bool "Mitac Mio A701 Support" > select GPIO_SYSFS > - select HAVE_PWM > select IWMMXT > select PXA27x > help > @@ -306,7 +295,6 @@ config MACH_MIOA701 > > config PXA_EZX > bool "Motorola EZX Platform" > - select HAVE_PWM > select IWMMXT > select PXA27x > > @@ -346,7 +334,6 @@ config MACH_MP900C > > config ARCH_PXA_PALM > bool "PXA based Palm PDAs" > - select HAVE_PWM > > config MACH_PALM27X > bool > @@ -444,7 +431,6 @@ config MACH_TREO680 > config MACH_RAUMFELD_RC > bool "Raumfeld Controller" > select CPU_PXA300 > - select HAVE_PWM > select POWER_SUPPLY > select PXA3xx > > @@ -608,7 +594,6 @@ config MACH_E800 > > config MACH_ZIPIT2 > bool "Zipit Z2 Handheld" > - select HAVE_PWM > select PXA27x > endmenu > > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index 650de39..ce62af8 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -233,7 +233,6 @@ config MACH_JZ4740 > select IRQ_CPU > select ARCH_REQUIRE_GPIOLIB > select SYS_HAS_EARLY_PRINTK > - select HAVE_PWM > select HAVE_CLK > select GENERIC_IRQ_CHIP > > diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig > index 5f4967d..bc6ec8e 100644 > ---
Re: [PATCH] pwm: Remove obsolete HAVE_PWM Kconfig symbol
On Thu, Jan 16, 2014 at 7:01 AM, Sascha Hauer s.ha...@pengutronix.de wrote: Before we had the PWM framework we used to have a barebone PWM api. The HAVE_PWM Kconfig symbol used to be selected by the PWM drivers to specify the PWM API is present in the kernel. Since the last legacy driver is gone the HAVE_PWM symbol can go aswell. Signed-off-by: Sascha Hauer s.ha...@pengutronix.de Looks good to me, happy to see it gone. --- I suggest that Thierry as PWM Maintainer takes the patch through his tree. Is that ok for you Thierry? arch/arm/Kconfig | 4 arch/arm/mach-pxa/Kconfig | 15 --- arch/mips/Kconfig | 1 - drivers/input/misc/Kconfig | 4 ++-- include/linux/pwm.h| 2 +- 5 files changed, 3 insertions(+), 23 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index c1f1a7e..1b6f499 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -109,9 +109,6 @@ config ARM_DMA_IOMMU_ALIGNMENT endif -config HAVE_PWM - bool - config MIGHT_HAVE_PCI bool @@ -606,7 +603,6 @@ config ARCH_LPC32XX select CPU_ARM926T select GENERIC_CLOCKEVENTS select HAVE_IDE - select HAVE_PWM select USB_ARCH_HAS_OHCI select USE_OF help diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig index 96100db..b96244c 100644 --- a/arch/arm/mach-pxa/Kconfig +++ b/arch/arm/mach-pxa/Kconfig @@ -7,7 +7,6 @@ comment Intel/Marvell Dev Platforms (sorted by hardware release time) config MACH_PXA3XX_DT bool Support PXA3xx platforms from device tree select CPU_PXA300 - select HAVE_PWM select POWER_SUPPLY select PXA3xx select USE_OF @@ -23,12 +22,10 @@ config ARCH_LUBBOCK config MACH_MAINSTONE bool Intel HCDDBBVA0 Development Platform (aka Mainstone) - select HAVE_PWM select PXA27x config MACH_ZYLONITE bool - select HAVE_PWM select PXA3xx config MACH_ZYLONITE300 @@ -69,7 +66,6 @@ config ARCH_PXA_IDP config ARCH_VIPER bool Arcom/Eurotech VIPER SBC select ARCOM_PCMCIA - select HAVE_PWM select I2C_GPIO select ISA select PXA25x @@ -120,7 +116,6 @@ config MACH_CM_X300 bool CompuLab CM-X300 modules select CPU_PXA300 select CPU_PXA310 - select HAVE_PWM select PXA3xx config MACH_CAPC7117 @@ -211,7 +206,6 @@ config TRIZEPS_PCMCIA config MACH_LOGICPD_PXA270 bool LogicPD PXA270 Card Engine Development Platform - select HAVE_PWM select PXA27x config MACH_PCM027 @@ -222,7 +216,6 @@ config MACH_PCM027 config MACH_PCM990_BASEBOARD bool PHYTEC PCM-990 development board depends on MACH_PCM027 - select HAVE_PWM choice prompt display on pcm990 @@ -246,7 +239,6 @@ config MACH_COLIBRI config MACH_COLIBRI_PXA270_INCOME bool Income s.r.o. PXA270 SBC depends on MACH_COLIBRI - select HAVE_PWM select PXA27x config MACH_COLIBRI300 @@ -275,7 +267,6 @@ comment End-user Products (sorted by vendor name) config MACH_H4700 bool HP iPAQ hx4700 - select HAVE_PWM select IWMMXT select PXA27x @@ -289,14 +280,12 @@ config MACH_HIMALAYA config MACH_MAGICIAN bool Enable HTC Magician Support - select HAVE_PWM select IWMMXT select PXA27x config MACH_MIOA701 bool Mitac Mio A701 Support select GPIO_SYSFS - select HAVE_PWM select IWMMXT select PXA27x help @@ -306,7 +295,6 @@ config MACH_MIOA701 config PXA_EZX bool Motorola EZX Platform - select HAVE_PWM select IWMMXT select PXA27x @@ -346,7 +334,6 @@ config MACH_MP900C config ARCH_PXA_PALM bool PXA based Palm PDAs - select HAVE_PWM config MACH_PALM27X bool @@ -444,7 +431,6 @@ config MACH_TREO680 config MACH_RAUMFELD_RC bool Raumfeld Controller select CPU_PXA300 - select HAVE_PWM select POWER_SUPPLY select PXA3xx @@ -608,7 +594,6 @@ config MACH_E800 config MACH_ZIPIT2 bool Zipit Z2 Handheld - select HAVE_PWM select PXA27x endmenu diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 650de39..ce62af8 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -233,7 +233,6 @@ config MACH_JZ4740 select IRQ_CPU select ARCH_REQUIRE_GPIOLIB select SYS_HAS_EARLY_PRINTK - select HAVE_PWM select HAVE_CLK select GENERIC_IRQ_CHIP diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 5f4967d..bc6ec8e 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -156,7 +156,7 @@ config INPUT_MAX8925_ONKEY config INPUT_MAX8997_HAPTIC tristate MAXIM MAX8997 haptic controller
[PATCH 2/2] MODSIG: use pre-generated X.509 key by MODPUBKEY
If MODPUBKEY is specified and other than default ./signing_key.x509, use that key instead of generating one on-the-fly. Signed-off-by: Eric Miao Cc: David Howells Cc: Dan Willemsen --- kernel/Makefile | 8 1 file changed, 8 insertions(+) diff --git a/kernel/Makefile b/kernel/Makefile index 1ce4755..66c7c32 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -165,6 +165,13 @@ ifndef CONFIG_MODULE_SIG_HASH $(error Could not determine digest type to use from kernel config) endif +ifneq ($(MODPUBKEY),./signing_key.x509) +signing_key.x509: $(MODPUBKEY) + @echo "###" + @echo "### Use pre-generated X.509 key pair for signing modules." + @echo "###" + cp -f $< $@ +else signing_key.priv signing_key.x509: x509.genkey @echo "###" @echo "### Now generating an X.509 key pair to be used for signing modules." @@ -202,3 +209,4 @@ x509.genkey: @echo >>x509.genkey "subjectKeyIdentifier=hash" @echo >>x509.genkey "authorityKeyIdentifier=keyid" endif +endif -- 1.8.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] module: export sig_enforce readonly even if MODULE_SIG_FORCE is on
Even if MODULE_SIG_FORCE is turned on, it is still useful if module
can export sig_enforce, so user space will know if module signature
is turned on and forced.
Signed-off-by: Eric Miao
Cc: David Howells
Cc: Dan Willemsen
---
kernel/module.c | 8
1 file changed, 8 insertions(+)
diff --git a/kernel/module.c b/kernel/module.c
index dc58274..d55646b 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -110,6 +110,14 @@ struct list_head *kdb_modules = /* kdb needs the
list of modules */
#ifdef CONFIG_MODULE_SIG
#ifdef CONFIG_MODULE_SIG_FORCE
static bool sig_enforce = true;
+
+static const struct kernel_param_ops param_ops_bool_read_only = {
+ .flags = KERNEL_PARAM_FL_NOARG,
+ .get = param_get_bool,
+};
+#define param_check_bool_read_only param_check_bool
+
+module_param(sig_enforce, bool_read_only, 0444);
#else
static bool sig_enforce = false;
--
1.8.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] module: export sig_enforce readonly even if MODULE_SIG_FORCE is on
Even if MODULE_SIG_FORCE is turned on, it is still useful if module
can export sig_enforce, so user space will know if module signature
is turned on and forced.
Signed-off-by: Eric Miao eric.m...@nvidia.com
Cc: David Howells dhowe...@redhat.com
Cc: Dan Willemsen dwillem...@nvidia.com
---
kernel/module.c | 8
1 file changed, 8 insertions(+)
diff --git a/kernel/module.c b/kernel/module.c
index dc58274..d55646b 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -110,6 +110,14 @@ struct list_head *kdb_modules = modules; /* kdb needs the
list of modules */
#ifdef CONFIG_MODULE_SIG
#ifdef CONFIG_MODULE_SIG_FORCE
static bool sig_enforce = true;
+
+static const struct kernel_param_ops param_ops_bool_read_only = {
+ .flags = KERNEL_PARAM_FL_NOARG,
+ .get = param_get_bool,
+};
+#define param_check_bool_read_only param_check_bool
+
+module_param(sig_enforce, bool_read_only, 0444);
#else
static bool sig_enforce = false;
--
1.8.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] MODSIG: use pre-generated X.509 key by MODPUBKEY
If MODPUBKEY is specified and other than default ./signing_key.x509, use that key instead of generating one on-the-fly. Signed-off-by: Eric Miao eric.m...@nvidia.com Cc: David Howells dhowe...@redhat.com Cc: Dan Willemsen dwillem...@nvidia.com --- kernel/Makefile | 8 1 file changed, 8 insertions(+) diff --git a/kernel/Makefile b/kernel/Makefile index 1ce4755..66c7c32 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -165,6 +165,13 @@ ifndef CONFIG_MODULE_SIG_HASH $(error Could not determine digest type to use from kernel config) endif +ifneq ($(MODPUBKEY),./signing_key.x509) +signing_key.x509: $(MODPUBKEY) + @echo ### + @echo ### Use pre-generated X.509 key pair for signing modules. + @echo ### + cp -f $ $@ +else signing_key.priv signing_key.x509: x509.genkey @echo ### @echo ### Now generating an X.509 key pair to be used for signing modules. @@ -202,3 +209,4 @@ x509.genkey: @echo x509.genkey subjectKeyIdentifier=hash @echo x509.genkey authorityKeyIdentifier=keyid endif +endif -- 1.8.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: pxa: remove IRQF_DISABLED
On Sat, Jul 6, 2013 at 1:42 PM, Michael Opdenacker
wrote:
> This flag is a NOOP since 2.6.35 and can be removed.
>
> Signed-off-by: Michael Opdenacker
Indeed. Acked-by: Eric Miao
> ---
> arch/arm/mach-pxa/am200epd.c | 3 +--
> arch/arm/mach-pxa/am300epd.c | 3 +--
> arch/arm/mach-pxa/em-x270.c | 3 +--
> arch/arm/mach-pxa/magician.c | 2 +-
> arch/arm/mach-pxa/mainstone.c| 2 +-
> arch/arm/mach-pxa/pcm990-baseboard.c | 2 +-
> arch/arm/mach-pxa/sharpsl_pm.c | 8
> arch/arm/mach-pxa/time.c | 2 +-
> arch/arm/mach-pxa/trizeps4.c | 3 +--
> arch/arm/plat-pxa/dma.c | 2 +-
> 10 files changed, 13 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/am200epd.c b/arch/arm/mach-pxa/am200epd.c
> index ffa6d81..12fb0f4 100644
> --- a/arch/arm/mach-pxa/am200epd.c
> +++ b/arch/arm/mach-pxa/am200epd.c
> @@ -293,8 +293,7 @@ static int am200_setup_irq(struct fb_info *info)
> int ret;
>
> ret = request_irq(PXA_GPIO_TO_IRQ(RDY_GPIO_PIN), am200_handle_irq,
> - IRQF_DISABLED|IRQF_TRIGGER_FALLING,
> - "AM200", info->par);
> + IRQF_TRIGGER_FALLING, "AM200", info->par);
> if (ret)
> dev_err(_device->dev, "request_irq failed: %d\n", ret);
>
> diff --git a/arch/arm/mach-pxa/am300epd.c b/arch/arm/mach-pxa/am300epd.c
> index 3dfec1e..c9f309a 100644
> --- a/arch/arm/mach-pxa/am300epd.c
> +++ b/arch/arm/mach-pxa/am300epd.c
> @@ -241,8 +241,7 @@ static int am300_setup_irq(struct fb_info *info)
> struct broadsheetfb_par *par = info->par;
>
> ret = request_irq(PXA_GPIO_TO_IRQ(RDY_GPIO_PIN), am300_handle_irq,
> - IRQF_DISABLED|IRQF_TRIGGER_RISING,
> - "AM300", par);
> + IRQF_TRIGGER_RISING, "AM300", par);
> if (ret)
> dev_err(_device->dev, "request_irq failed: %d\n", ret);
>
> diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
> index f6726bb..86936d9 100644
> --- a/arch/arm/mach-pxa/em-x270.c
> +++ b/arch/arm/mach-pxa/em-x270.c
> @@ -556,8 +556,7 @@ static int em_x270_mci_init(struct device *dev,
> }
>
> err = request_irq(gpio_to_irq(mmc_cd), em_x270_detect_int,
> - IRQF_DISABLED | IRQF_TRIGGER_RISING |
> - IRQF_TRIGGER_FALLING,
> + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
> "MMC card detect", data);
> if (err) {
> dev_err(dev, "can't request MMC card detect IRQ: %d\n", err);
> diff --git a/arch/arm/mach-pxa/magician.c b/arch/arm/mach-pxa/magician.c
> index f44532f..38f544d 100644
> --- a/arch/arm/mach-pxa/magician.c
> +++ b/arch/arm/mach-pxa/magician.c
> @@ -633,7 +633,7 @@ static struct platform_device bq24022 = {
> static int magician_mci_init(struct device *dev,
> irq_handler_t detect_irq, void *data)
> {
> - return request_irq(IRQ_MAGICIAN_SD, detect_irq, IRQF_DISABLED,
> + return request_irq(IRQ_MAGICIAN_SD, detect_irq, 0,
>"mmc card detect", data);
> }
>
> diff --git a/arch/arm/mach-pxa/mainstone.c b/arch/arm/mach-pxa/mainstone.c
> index d2c6523..1184efa 100644
> --- a/arch/arm/mach-pxa/mainstone.c
> +++ b/arch/arm/mach-pxa/mainstone.c
> @@ -400,7 +400,7 @@ static int mainstone_mci_init(struct device *dev,
> irq_handler_t mstone_detect_in
> */
> MST_MSCWR1 &= ~MST_MSCWR1_MS_SEL;
>
> - err = request_irq(MAINSTONE_MMC_IRQ, mstone_detect_int, IRQF_DISABLED,
> + err = request_irq(MAINSTONE_MMC_IRQ, mstone_detect_int, 0,
> "MMC card detect", data);
> if (err)
> printk(KERN_ERR "mainstone_mci_init: MMC/SD: can't request
> MMC card detect IRQ\n");
> diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
> b/arch/arm/mach-pxa/pcm990-baseboard.c
> index fb7f1d1..33f058f 100644
> --- a/arch/arm/mach-pxa/pcm990-baseboard.c
> +++ b/arch/arm/mach-pxa/pcm990-baseboard.c
> @@ -326,7 +326,7 @@ static int pcm990_mci_init(struct device *dev,
> irq_handler_t mci_detect_int,
> {
> int err;
>
> - err = request_irq(PCM027_MMCDET_IRQ, mci_detect_int, IRQF_DISABLED,
> + err = request_irq(PCM027_MMCDET_IRQ, mci_detect_int,
> "MMC card detect", data);
> if (err)
>
Re: [PATCH] ARM: pxa: remove IRQF_DISABLED
On Sat, Jul 6, 2013 at 1:42 PM, Michael Opdenacker
michael.opdenac...@free-electrons.com wrote:
This flag is a NOOP since 2.6.35 and can be removed.
Signed-off-by: Michael Opdenacker michael.opdenac...@free-electrons.com
Indeed. Acked-by: Eric Miao eric.y.m...@gmail.com
---
arch/arm/mach-pxa/am200epd.c | 3 +--
arch/arm/mach-pxa/am300epd.c | 3 +--
arch/arm/mach-pxa/em-x270.c | 3 +--
arch/arm/mach-pxa/magician.c | 2 +-
arch/arm/mach-pxa/mainstone.c| 2 +-
arch/arm/mach-pxa/pcm990-baseboard.c | 2 +-
arch/arm/mach-pxa/sharpsl_pm.c | 8
arch/arm/mach-pxa/time.c | 2 +-
arch/arm/mach-pxa/trizeps4.c | 3 +--
arch/arm/plat-pxa/dma.c | 2 +-
10 files changed, 13 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-pxa/am200epd.c b/arch/arm/mach-pxa/am200epd.c
index ffa6d81..12fb0f4 100644
--- a/arch/arm/mach-pxa/am200epd.c
+++ b/arch/arm/mach-pxa/am200epd.c
@@ -293,8 +293,7 @@ static int am200_setup_irq(struct fb_info *info)
int ret;
ret = request_irq(PXA_GPIO_TO_IRQ(RDY_GPIO_PIN), am200_handle_irq,
- IRQF_DISABLED|IRQF_TRIGGER_FALLING,
- AM200, info-par);
+ IRQF_TRIGGER_FALLING, AM200, info-par);
if (ret)
dev_err(am200_device-dev, request_irq failed: %d\n, ret);
diff --git a/arch/arm/mach-pxa/am300epd.c b/arch/arm/mach-pxa/am300epd.c
index 3dfec1e..c9f309a 100644
--- a/arch/arm/mach-pxa/am300epd.c
+++ b/arch/arm/mach-pxa/am300epd.c
@@ -241,8 +241,7 @@ static int am300_setup_irq(struct fb_info *info)
struct broadsheetfb_par *par = info-par;
ret = request_irq(PXA_GPIO_TO_IRQ(RDY_GPIO_PIN), am300_handle_irq,
- IRQF_DISABLED|IRQF_TRIGGER_RISING,
- AM300, par);
+ IRQF_TRIGGER_RISING, AM300, par);
if (ret)
dev_err(am300_device-dev, request_irq failed: %d\n, ret);
diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index f6726bb..86936d9 100644
--- a/arch/arm/mach-pxa/em-x270.c
+++ b/arch/arm/mach-pxa/em-x270.c
@@ -556,8 +556,7 @@ static int em_x270_mci_init(struct device *dev,
}
err = request_irq(gpio_to_irq(mmc_cd), em_x270_detect_int,
- IRQF_DISABLED | IRQF_TRIGGER_RISING |
- IRQF_TRIGGER_FALLING,
+ IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
MMC card detect, data);
if (err) {
dev_err(dev, can't request MMC card detect IRQ: %d\n, err);
diff --git a/arch/arm/mach-pxa/magician.c b/arch/arm/mach-pxa/magician.c
index f44532f..38f544d 100644
--- a/arch/arm/mach-pxa/magician.c
+++ b/arch/arm/mach-pxa/magician.c
@@ -633,7 +633,7 @@ static struct platform_device bq24022 = {
static int magician_mci_init(struct device *dev,
irq_handler_t detect_irq, void *data)
{
- return request_irq(IRQ_MAGICIAN_SD, detect_irq, IRQF_DISABLED,
+ return request_irq(IRQ_MAGICIAN_SD, detect_irq, 0,
mmc card detect, data);
}
diff --git a/arch/arm/mach-pxa/mainstone.c b/arch/arm/mach-pxa/mainstone.c
index d2c6523..1184efa 100644
--- a/arch/arm/mach-pxa/mainstone.c
+++ b/arch/arm/mach-pxa/mainstone.c
@@ -400,7 +400,7 @@ static int mainstone_mci_init(struct device *dev,
irq_handler_t mstone_detect_in
*/
MST_MSCWR1 = ~MST_MSCWR1_MS_SEL;
- err = request_irq(MAINSTONE_MMC_IRQ, mstone_detect_int, IRQF_DISABLED,
+ err = request_irq(MAINSTONE_MMC_IRQ, mstone_detect_int, 0,
MMC card detect, data);
if (err)
printk(KERN_ERR mainstone_mci_init: MMC/SD: can't request
MMC card detect IRQ\n);
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/arm/mach-pxa/pcm990-baseboard.c
index fb7f1d1..33f058f 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -326,7 +326,7 @@ static int pcm990_mci_init(struct device *dev,
irq_handler_t mci_detect_int,
{
int err;
- err = request_irq(PCM027_MMCDET_IRQ, mci_detect_int, IRQF_DISABLED,
+ err = request_irq(PCM027_MMCDET_IRQ, mci_detect_int,
MMC card detect, data);
if (err)
printk(KERN_ERR pcm990_mci_init: MMC/SD: can't request MMC
diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-pxa/sharpsl_pm.c
index 0a36d35..051a655 100644
--- a/arch/arm/mach-pxa/sharpsl_pm.c
+++ b/arch/arm/mach-pxa/sharpsl_pm.c
@@ -860,18 +860,18 @@ static int sharpsl_pm_probe(struct platform_device
*pdev)
/* Register interrupt handlers */
irq = gpio_to_irq(sharpsl_pm.machinfo-gpio_acin);
- if (request_irq(irq
Re: [PATCH V4 3/3] pwm: pxa: add device tree support
On Mon, May 13, 2013 at 1:04 PM, Chao Xie wrote:
>>> + const struct of_device_id *of_id =
>>> + of_match_device(pxa_pwm_of_match, >dev);
>>> + unsigned int npwm;
>>> +
>>> + if (!of_id)
>>> + return -ENODEV;
>>> +
>>> + npwm = (unsigned int)of_id->data;
>>> + pwm->chip.npwm = (npwm & HAS_SECONDARY_PWM) ? 2 : 1;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> static int pwm_probe(struct platform_device *pdev)
>>> {
>>> const struct platform_device_id *id = platform_get_device_id(pdev);
>>> @@ -144,7 +180,6 @@ static int pwm_probe(struct platform_device *pdev)
>>> pwm->chip.dev = >dev;
>>> pwm->chip.ops = _pwm_ops;
>>> pwm->chip.base = -1;
>>> - pwm->chip.npwm = (id->driver_data & HAS_SECONDARY_PWM) ? 2 : 1;
>>>
>>> r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> if (r == NULL) {
>>> @@ -156,6 +191,20 @@ static int pwm_probe(struct platform_device *pdev)
>>> if (IS_ERR(pwm->mmio_base))
>>> return PTR_ERR(pwm->mmio_base);
>>>
>>> + if (!id) {
>>> + if (IS_ENABLED(CONFIG_OF))
>>> + ret = pxa_pwm_parse_data_dt(pdev, pwm);
>>> + else
>>> + ret = -ENODEV;
>>> + } else {
>>> + pwm->chip.npwm = (id->driver_data & HAS_SECONDARY_PWM) ? 2
>>> : 1;
>>> + }
>>
>> ^^ braces not necessarily here, and I'm not really sure if we should check
>> CONFIG_OF firstly, and leave the platform_device_id thing as a legacy
>> fall back, what do you think?
>>
>> if (IS_ENABLED(CONFIG_OF)) {
>> ...
>> } else {
>> const struct platform_device_id *id = platform_get_device_id(...);
>> ...
>> }
>>
> it has some reasons.
> You ways works for
> 1. PWM defined in DT configuration file and CONFIG_OF is defined
> 2. CONFIG_OF is not defined.
> If COFNIG_OF is defined, but PWM is not defined in device tree
> configuration file. The device
> can still match the driver is the id_table is matched or name is matched.
> So I covered addtional situation
> 1. PWM is not defined in DT configuration file but CONFIG_OF is defined.
>
> So i keep the possiblility that event CONFIG_OF is defined, but PWM is
> not defined in DT file, and we still can use old way to probe the
> device.
>
Yeah I was thinking maybe we should not keep the legacy working if
CONFIG_OF is defined, but that should be OK:
Acked-by: Eric Miao
>>> +
>>> + if (ret) {
>>> + dev_err(>dev, "failed to parse data from device
>>> id\n");
>>> + return ret;
>>> + }
>>> +
>>> ret = pwmchip_add(>chip);
>>> if (ret < 0) {
>>> dev_err(>dev, "pwmchip_add() failed: %d\n", ret);
>>> @@ -181,6 +230,7 @@ static struct platform_driver pwm_driver = {
>>> .driver = {
>>> .name = "pxa25x-pwm",
>>> .owner = THIS_MODULE,
>>> + .of_match_table = pxa_pwm_of_match,
>>> },
>>> .probe = pwm_probe,
>>> .remove = pwm_remove,
>>> --
>>> 1.7.4.1
>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 3/3] pwm: pxa: add device tree support
On Mon, May 13, 2013 at 1:04 PM, Chao Xie xiechao.m...@gmail.com wrote:
+ const struct of_device_id *of_id =
+ of_match_device(pxa_pwm_of_match, pdev-dev);
+ unsigned int npwm;
+
+ if (!of_id)
+ return -ENODEV;
+
+ npwm = (unsigned int)of_id-data;
+ pwm-chip.npwm = (npwm HAS_SECONDARY_PWM) ? 2 : 1;
+
+ return 0;
+}
+
static int pwm_probe(struct platform_device *pdev)
{
const struct platform_device_id *id = platform_get_device_id(pdev);
@@ -144,7 +180,6 @@ static int pwm_probe(struct platform_device *pdev)
pwm-chip.dev = pdev-dev;
pwm-chip.ops = pxa_pwm_ops;
pwm-chip.base = -1;
- pwm-chip.npwm = (id-driver_data HAS_SECONDARY_PWM) ? 2 : 1;
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (r == NULL) {
@@ -156,6 +191,20 @@ static int pwm_probe(struct platform_device *pdev)
if (IS_ERR(pwm-mmio_base))
return PTR_ERR(pwm-mmio_base);
+ if (!id) {
+ if (IS_ENABLED(CONFIG_OF))
+ ret = pxa_pwm_parse_data_dt(pdev, pwm);
+ else
+ ret = -ENODEV;
+ } else {
+ pwm-chip.npwm = (id-driver_data HAS_SECONDARY_PWM) ? 2
: 1;
+ }
^^ braces not necessarily here, and I'm not really sure if we should check
CONFIG_OF firstly, and leave the platform_device_id thing as a legacy
fall back, what do you think?
if (IS_ENABLED(CONFIG_OF)) {
...
} else {
const struct platform_device_id *id = platform_get_device_id(...);
...
}
it has some reasons.
You ways works for
1. PWM defined in DT configuration file and CONFIG_OF is defined
2. CONFIG_OF is not defined.
If COFNIG_OF is defined, but PWM is not defined in device tree
configuration file. The device
can still match the driver is the id_table is matched or name is matched.
So I covered addtional situation
1. PWM is not defined in DT configuration file but CONFIG_OF is defined.
So i keep the possiblility that event CONFIG_OF is defined, but PWM is
not defined in DT file, and we still can use old way to probe the
device.
Yeah I was thinking maybe we should not keep the legacy working if
CONFIG_OF is defined, but that should be OK:
Acked-by: Eric Miao eric.y.m...@gmail.com
+
+ if (ret) {
+ dev_err(pdev-dev, failed to parse data from device
id\n);
+ return ret;
+ }
+
ret = pwmchip_add(pwm-chip);
if (ret 0) {
dev_err(pdev-dev, pwmchip_add() failed: %d\n, ret);
@@ -181,6 +230,7 @@ static struct platform_driver pwm_driver = {
.driver = {
.name = pxa25x-pwm,
.owner = THIS_MODULE,
+ .of_match_table = pxa_pwm_of_match,
},
.probe = pwm_probe,
.remove = pwm_remove,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 3/3] pwm: pxa: add device tree support
On Mon, May 6, 2013 at 9:30 AM, Chao Xie wrote:
> Add the deice tree support for pwm-pxa.
>
> Signed-off-by: Chao Xie
> ---
> drivers/pwm/pwm-pxa.c | 52
> -
> 1 files changed, 51 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
> index aa4bea7..c8d59a2 100644
> --- a/drivers/pwm/pwm-pxa.c
> +++ b/drivers/pwm/pwm-pxa.c
> @@ -9,6 +9,8 @@
> *
> * 2008-02-13 initial version
> * eric miao
> + * 2013-04-24 add device tree support
> + * Chao Xie
> */
>
> #include
> @@ -18,6 +20,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
>
> #include
> @@ -124,6 +128,38 @@ static struct pwm_ops pxa_pwm_ops = {
> .owner = THIS_MODULE,
> };
>
> +static const struct of_device_id pxa_pwm_of_match[] = {
> + {
> + .compatible = "marvell,pxa25x-pwm",
> + }, {
> + .compatible = "marvell,pxa27x-pwm",
> + .data = (void *)HAS_SECONDARY_PWM
> + }, {
> + .compatible = "marvell,pxa168-pwm",
> + }, {
> + .compatible = "marvell,pxa910-pwm",
> + },
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(of, pxa_pwm_of_match);
> +
> +static int pxa_pwm_parse_data_dt(struct platform_device *pdev,
> + struct pxa_pwm_chip *pwm)
> +{
> + const struct of_device_id *of_id =
> + of_match_device(pxa_pwm_of_match, >dev);
> + unsigned int npwm;
> +
> + if (!of_id)
> + return -ENODEV;
> +
> + npwm = (unsigned int)of_id->data;
> + pwm->chip.npwm = (npwm & HAS_SECONDARY_PWM) ? 2 : 1;
> +
> + return 0;
> +}
> +
> static int pwm_probe(struct platform_device *pdev)
> {
> const struct platform_device_id *id = platform_get_device_id(pdev);
> @@ -144,7 +180,6 @@ static int pwm_probe(struct platform_device *pdev)
> pwm->chip.dev = >dev;
> pwm->chip.ops = _pwm_ops;
> pwm->chip.base = -1;
> - pwm->chip.npwm = (id->driver_data & HAS_SECONDARY_PWM) ? 2 : 1;
>
> r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (r == NULL) {
> @@ -156,6 +191,20 @@ static int pwm_probe(struct platform_device *pdev)
> if (IS_ERR(pwm->mmio_base))
> return PTR_ERR(pwm->mmio_base);
>
> + if (!id) {
> + if (IS_ENABLED(CONFIG_OF))
> + ret = pxa_pwm_parse_data_dt(pdev, pwm);
> + else
> + ret = -ENODEV;
> + } else {
> + pwm->chip.npwm = (id->driver_data & HAS_SECONDARY_PWM) ? 2 :
> 1;
> + }
^^ braces not necessarily here, and I'm not really sure if we should check
CONFIG_OF firstly, and leave the platform_device_id thing as a legacy
fall back, what do you think?
if (IS_ENABLED(CONFIG_OF)) {
...
} else {
const struct platform_device_id *id = platform_get_device_id(...);
...
}
> +
> + if (ret) {
> + dev_err(>dev, "failed to parse data from device id\n");
> + return ret;
> + }
> +
> ret = pwmchip_add(>chip);
> if (ret < 0) {
> dev_err(>dev, "pwmchip_add() failed: %d\n", ret);
> @@ -181,6 +230,7 @@ static struct platform_driver pwm_driver = {
> .driver = {
> .name = "pxa25x-pwm",
> .owner = THIS_MODULE,
> + .of_match_table = pxa_pwm_of_match,
> },
> .probe = pwm_probe,
> .remove = pwm_remove,
> --
> 1.7.4.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 2/3] pwm: pxa: use module_platform_driver()
On Mon, May 6, 2013 at 9:30 AM, Chao Xie wrote:
> Old pwm-pxa.c will register driver by arch_initcall. Then other
> drivers based on the PWM driver can successully call old
> pwm_request because arch_initcall make sure the PWM driver will
> be registered earlier.
> Now, pwm_request is re-written and done by common layer code. It
> will return -EPROBE_DEFER if the PWM device is not probed.
> The driver based on PWM driver can make use of -EPROBE_DEFER
> to delay its probing.
> So arch_initcall can be replaced by module_platform_driver.
>
> Signed-off-by: Chao Xie
Looks good to me,
Acked-by: Eric Miao
> ---
> drivers/pwm/pwm-pxa.c | 12 +---
> 1 files changed, 1 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
> index dee6ab55..aa4bea7 100644
> --- a/drivers/pwm/pwm-pxa.c
> +++ b/drivers/pwm/pwm-pxa.c
> @@ -187,16 +187,6 @@ static struct platform_driver pwm_driver = {
> .id_table = pwm_id_table,
> };
>
> -static int __init pwm_init(void)
> -{
> - return platform_driver_register(_driver);
> -}
> -arch_initcall(pwm_init);
> -
> -static void __exit pwm_exit(void)
> -{
> - platform_driver_unregister(_driver);
> -}
> -module_exit(pwm_exit);
> +module_platform_driver(pwm_driver);
>
> MODULE_LICENSE("GPL v2");
> --
> 1.7.4.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 1/3] pwm: pxa: ARCH_MMP share same pwm driver with ARCH_PXA
On Mon, May 6, 2013 at 9:29 AM, Chao Xie wrote: > The PWM driver is not only used by ARCH_PXA but also ARCH_MMP. > > Signed-off-by: Chao Xie Looks good to me. Acked-by: Eric Miao > --- > drivers/pwm/Kconfig |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig > index 115b644..9ec4040 100644 > --- a/drivers/pwm/Kconfig > +++ b/drivers/pwm/Kconfig > @@ -108,7 +108,7 @@ config PWM_PUV3 > > config PWM_PXA > tristate "PXA PWM support" > - depends on ARCH_PXA > + depends on ARCH_PXA || ARCH_MMP > help > Generic PWM framework driver for PXA. > > -- > 1.7.4.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 1/3] pwm: pxa: ARCH_MMP share same pwm driver with ARCH_PXA
On Mon, May 6, 2013 at 9:29 AM, Chao Xie chao@marvell.com wrote: The PWM driver is not only used by ARCH_PXA but also ARCH_MMP. Signed-off-by: Chao Xie chao@marvell.com Looks good to me. Acked-by: Eric Miao eric.y.m...@gmail.com --- drivers/pwm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig index 115b644..9ec4040 100644 --- a/drivers/pwm/Kconfig +++ b/drivers/pwm/Kconfig @@ -108,7 +108,7 @@ config PWM_PUV3 config PWM_PXA tristate PXA PWM support - depends on ARCH_PXA + depends on ARCH_PXA || ARCH_MMP help Generic PWM framework driver for PXA. -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 2/3] pwm: pxa: use module_platform_driver()
On Mon, May 6, 2013 at 9:30 AM, Chao Xie chao@marvell.com wrote:
Old pwm-pxa.c will register driver by arch_initcall. Then other
drivers based on the PWM driver can successully call old
pwm_request because arch_initcall make sure the PWM driver will
be registered earlier.
Now, pwm_request is re-written and done by common layer code. It
will return -EPROBE_DEFER if the PWM device is not probed.
The driver based on PWM driver can make use of -EPROBE_DEFER
to delay its probing.
So arch_initcall can be replaced by module_platform_driver.
Signed-off-by: Chao Xie chao@marvell.com
Looks good to me,
Acked-by: Eric Miao eric.y.m...@gmail.com
---
drivers/pwm/pwm-pxa.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index dee6ab55..aa4bea7 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -187,16 +187,6 @@ static struct platform_driver pwm_driver = {
.id_table = pwm_id_table,
};
-static int __init pwm_init(void)
-{
- return platform_driver_register(pwm_driver);
-}
-arch_initcall(pwm_init);
-
-static void __exit pwm_exit(void)
-{
- platform_driver_unregister(pwm_driver);
-}
-module_exit(pwm_exit);
+module_platform_driver(pwm_driver);
MODULE_LICENSE(GPL v2);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 3/3] pwm: pxa: add device tree support
On Mon, May 6, 2013 at 9:30 AM, Chao Xie chao@marvell.com wrote:
Add the deice tree support for pwm-pxa.
Signed-off-by: Chao Xie chao@marvell.com
---
drivers/pwm/pwm-pxa.c | 52
-
1 files changed, 51 insertions(+), 1 deletions(-)
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index aa4bea7..c8d59a2 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -9,6 +9,8 @@
*
* 2008-02-13 initial version
* eric miao eric.m...@marvell.com
+ * 2013-04-24 add device tree support
+ * Chao Xie chao@marvell.com
*/
#include linux/module.h
@@ -18,6 +20,8 @@
#include linux/err.h
#include linux/clk.h
#include linux/io.h
+#include linux/of.h
+#include linux/of_device.h
#include linux/pwm.h
#include asm/div64.h
@@ -124,6 +128,38 @@ static struct pwm_ops pxa_pwm_ops = {
.owner = THIS_MODULE,
};
+static const struct of_device_id pxa_pwm_of_match[] = {
+ {
+ .compatible = marvell,pxa25x-pwm,
+ }, {
+ .compatible = marvell,pxa27x-pwm,
+ .data = (void *)HAS_SECONDARY_PWM
+ }, {
+ .compatible = marvell,pxa168-pwm,
+ }, {
+ .compatible = marvell,pxa910-pwm,
+ },
+ {}
+};
+
+MODULE_DEVICE_TABLE(of, pxa_pwm_of_match);
+
+static int pxa_pwm_parse_data_dt(struct platform_device *pdev,
+ struct pxa_pwm_chip *pwm)
+{
+ const struct of_device_id *of_id =
+ of_match_device(pxa_pwm_of_match, pdev-dev);
+ unsigned int npwm;
+
+ if (!of_id)
+ return -ENODEV;
+
+ npwm = (unsigned int)of_id-data;
+ pwm-chip.npwm = (npwm HAS_SECONDARY_PWM) ? 2 : 1;
+
+ return 0;
+}
+
static int pwm_probe(struct platform_device *pdev)
{
const struct platform_device_id *id = platform_get_device_id(pdev);
@@ -144,7 +180,6 @@ static int pwm_probe(struct platform_device *pdev)
pwm-chip.dev = pdev-dev;
pwm-chip.ops = pxa_pwm_ops;
pwm-chip.base = -1;
- pwm-chip.npwm = (id-driver_data HAS_SECONDARY_PWM) ? 2 : 1;
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (r == NULL) {
@@ -156,6 +191,20 @@ static int pwm_probe(struct platform_device *pdev)
if (IS_ERR(pwm-mmio_base))
return PTR_ERR(pwm-mmio_base);
+ if (!id) {
+ if (IS_ENABLED(CONFIG_OF))
+ ret = pxa_pwm_parse_data_dt(pdev, pwm);
+ else
+ ret = -ENODEV;
+ } else {
+ pwm-chip.npwm = (id-driver_data HAS_SECONDARY_PWM) ? 2 :
1;
+ }
^^ braces not necessarily here, and I'm not really sure if we should check
CONFIG_OF firstly, and leave the platform_device_id thing as a legacy
fall back, what do you think?
if (IS_ENABLED(CONFIG_OF)) {
...
} else {
const struct platform_device_id *id = platform_get_device_id(...);
...
}
+
+ if (ret) {
+ dev_err(pdev-dev, failed to parse data from device id\n);
+ return ret;
+ }
+
ret = pwmchip_add(pwm-chip);
if (ret 0) {
dev_err(pdev-dev, pwmchip_add() failed: %d\n, ret);
@@ -181,6 +230,7 @@ static struct platform_driver pwm_driver = {
.driver = {
.name = pxa25x-pwm,
.owner = THIS_MODULE,
+ .of_match_table = pxa_pwm_of_match,
},
.probe = pwm_probe,
.remove = pwm_remove,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] platform: fall-back to driver name check if there is no id found
On Fri, Apr 19, 2013 at 8:35 PM, Hein Tibosch wrote: > Hi Andy, Mika, > > On 8 Feb 2013, Andy Shevchenko wrote: > >> Some of the platform devices rely on the name of their driver to match with. >> In >> the current implementation, if platform id table is needed, they have to add >> the name to the platform id table which sounds alogical. The patch adjustes >> the >> logic of the id table matching to make sure we will fall-back to match by the >> driver name. This will make it similar to the DT or ACPI cases. >> >> Signed-off-by: Andy Shevchenko >> Reported-by: Mika Westerberg >> Cc: Eric Miao >> Cc: Greg Kroah-Hartman >> --- >> drivers/base/platform.c |4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/base/platform.c b/drivers/base/platform.c >> index c0b8df3..452ba4b 100644 >> --- a/drivers/base/platform.c >> +++ b/drivers/base/platform.c >> @@ -732,8 +732,8 @@ static int platform_match(struct device *dev, struct >> device_driver *drv) >> return 1; >> >> /* Then try to match against the id table */ >> - if (pdrv->id_table) >> - return platform_match_id(pdrv->id_table, pdev) != NULL; >> + if (pdrv->id_table && platform_match_id(pdrv->id_table, pdev)) >> + return 1; >> >> /* fall-back to driver name match */ >> return (strcmp(pdev->name, drv->name) == 0); > > When I upgraded an avr32 system from 3.8 to a recent next release, I found it > was > broken: DMA was not available because the dw_dma driver did not get probed > anymore. > > The dw_dma driver does have a id_table, but the boards in arch/avr32 are > still expecting > driver identification by name. I think this is a different philosophy here. I'm actually fine with either. The questions are really: 1. will it be a bit inconsistent if the driver is using id_table, while the device is still using a legacy way? 2. instead of introducing a different logic in the platform driver core code, is it possible this could be fixed at the board level? > > As long as we want to support this simple identification-by-name, I'd say > Andy's patch > should get quickly into stable release. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] platform: fall-back to driver name check if there is no id found
On Fri, Apr 19, 2013 at 8:35 PM, Hein Tibosch wrote: > Hi Andy, Mika, > > On 8 Feb 2013, Andy Shevchenko wrote: > >> Some of the platform devices rely on the name of their driver to match with. >> In >> the current implementation, if platform id table is needed, they have to add >> the name to the platform id table which sounds alogical. The patch adjustes >> the >> logic of the id table matching to make sure we will fall-back to match by the >> driver name. This will make it similar to the DT or ACPI cases. >> >> Signed-off-by: Andy Shevchenko >> Reported-by: Mika Westerberg >> Cc: Eric Miao >> Cc: Greg Kroah-Hartman >> --- >> drivers/base/platform.c |4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/base/platform.c b/drivers/base/platform.c >> index c0b8df3..452ba4b 100644 >> --- a/drivers/base/platform.c >> +++ b/drivers/base/platform.c >> @@ -732,8 +732,8 @@ static int platform_match(struct device *dev, struct >> device_driver *drv) >> return 1; >> >> /* Then try to match against the id table */ >> - if (pdrv->id_table) >> - return platform_match_id(pdrv->id_table, pdev) != NULL; >> + if (pdrv->id_table && platform_match_id(pdrv->id_table, pdev)) >> + return 1; >> >> /* fall-back to driver name match */ >> return (strcmp(pdev->name, drv->name) == 0); > > When I upgraded an avr32 system from 3.8 to a recent next release, I found it > was > broken: DMA was not available because the dw_dma driver did not get probed > anymore. > > The dw_dma driver does have a id_table, but the boards in arch/avr32 are > still expecting > driver identification by name. I think this is a different philosophy here. I'm actually fine with either. The questions are really: 1. will it be a bit inconsistent if the driver is using id_table, while the device is still using a legacy way? 2. instead of introducing a different logic in the platform driver core code, is it possible this could be fixed at the board level? > > As long as we want to support this simple identification-by-name, I'd say > Andy's patch > should get quickly into stable release. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] platform: fall-back to driver name check if there is no id found
On Fri, Apr 19, 2013 at 8:35 PM, Hein Tibosch hein_tibo...@yahoo.es wrote: Hi Andy, Mika, On 8 Feb 2013, Andy Shevchenko wrote: Some of the platform devices rely on the name of their driver to match with. In the current implementation, if platform id table is needed, they have to add the name to the platform id table which sounds alogical. The patch adjustes the logic of the id table matching to make sure we will fall-back to match by the driver name. This will make it similar to the DT or ACPI cases. Signed-off-by: Andy Shevchenko andriy.shevchenko@xxx Reported-by: Mika Westerberg mika.westerberg@xxx Cc: Eric Miao eric.miao@xxx Cc: Greg Kroah-Hartman gregkh@xxx --- drivers/base/platform.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index c0b8df3..452ba4b 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -732,8 +732,8 @@ static int platform_match(struct device *dev, struct device_driver *drv) return 1; /* Then try to match against the id table */ - if (pdrv-id_table) - return platform_match_id(pdrv-id_table, pdev) != NULL; + if (pdrv-id_table platform_match_id(pdrv-id_table, pdev)) + return 1; /* fall-back to driver name match */ return (strcmp(pdev-name, drv-name) == 0); When I upgraded an avr32 system from 3.8 to a recent next release, I found it was broken: DMA was not available because the dw_dma driver did not get probed anymore. The dw_dma driver does have a id_table, but the boards in arch/avr32 are still expecting driver identification by name. I think this is a different philosophy here. I'm actually fine with either. The questions are really: 1. will it be a bit inconsistent if the driver is using id_table, while the device is still using a legacy way? 2. instead of introducing a different logic in the platform driver core code, is it possible this could be fixed at the board level? As long as we want to support this simple identification-by-name, I'd say Andy's patch should get quickly into stable release. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] platform: fall-back to driver name check if there is no id found
On Fri, Apr 19, 2013 at 8:35 PM, Hein Tibosch hein_tibo...@yahoo.es wrote: Hi Andy, Mika, On 8 Feb 2013, Andy Shevchenko wrote: Some of the platform devices rely on the name of their driver to match with. In the current implementation, if platform id table is needed, they have to add the name to the platform id table which sounds alogical. The patch adjustes the logic of the id table matching to make sure we will fall-back to match by the driver name. This will make it similar to the DT or ACPI cases. Signed-off-by: Andy Shevchenko andriy.shevchenko@xxx Reported-by: Mika Westerberg mika.westerberg@xxx Cc: Eric Miao eric.miao@xxx Cc: Greg Kroah-Hartman gregkh@xxx --- drivers/base/platform.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index c0b8df3..452ba4b 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -732,8 +732,8 @@ static int platform_match(struct device *dev, struct device_driver *drv) return 1; /* Then try to match against the id table */ - if (pdrv-id_table) - return platform_match_id(pdrv-id_table, pdev) != NULL; + if (pdrv-id_table platform_match_id(pdrv-id_table, pdev)) + return 1; /* fall-back to driver name match */ return (strcmp(pdev-name, drv-name) == 0); When I upgraded an avr32 system from 3.8 to a recent next release, I found it was broken: DMA was not available because the dw_dma driver did not get probed anymore. The dw_dma driver does have a id_table, but the boards in arch/avr32 are still expecting driver identification by name. I think this is a different philosophy here. I'm actually fine with either. The questions are really: 1. will it be a bit inconsistent if the driver is using id_table, while the device is still using a legacy way? 2. instead of introducing a different logic in the platform driver core code, is it possible this could be fixed at the board level? As long as we want to support this simple identification-by-name, I'd say Andy's patch should get quickly into stable release. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: pxa: Remove PWM_ID_BASE macro
On Mon, Apr 1, 2013 at 3:41 PM, Axel Lin wrote:
> PWM_ID_BASE() is not used after convert to PWM framework, remove it.
> Also update driver_data field of struct platform_device_id accordingly.
>
> Signed-off-by: Axel Lin
> ---
> This is v2 of [PATCH] pwm: pxa: Use driver_data field to store pwm_nr.
> I change the subject line to meet the change in v2.
>
> drivers/pwm/pwm-pxa.c |7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
> index b789882..dee6ab55 100644
> --- a/drivers/pwm/pwm-pxa.c
> +++ b/drivers/pwm/pwm-pxa.c
> @@ -23,14 +23,13 @@
> #include
>
> #define HAS_SECONDARY_PWM 0x10
> -#define PWM_ID_BASE(d) ((d) & 0xf)
>
> static const struct platform_device_id pwm_id_table[] = {
> /* PWMhas_secondary_pwm? */
> { "pxa25x-pwm", 0 },
> - { "pxa27x-pwm", 0 | HAS_SECONDARY_PWM },
> - { "pxa168-pwm", 1 },
> - { "pxa910-pwm", 1 },
> + { "pxa27x-pwm", HAS_SECONDARY_PWM },
> + { "pxa168-pwm", 0 },
> + { "pxa910-pwm", 0 },
> { },
> };
> MODULE_DEVICE_TABLE(platform, pwm_id_table);
Looks good to me, Acked-by: Eric Miao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] pwm: pxa: Remove clk_enabled field from struct pxa_pwm_chip
On Mon, Apr 1, 2013 at 3:32 PM, Axel Lin wrote:
> 2013/4/1 Eric Miao :
>> On Sun, Mar 31, 2013 at 11:04 PM, Axel Lin wrote:
>>> clk_enable/clk_disable maintain an enable_count, clk_prepare and
>>> clk_unprepare
>>> also maintain a prepare_count. These APIs will do prepare/enable when the
>>> first
>>> user calling these APIs, and do disable/unprepare when the corresponding
>>> counter
>>> reach 0. Thus We don't need to maintain a clk_enabled counter here.
>>
>> The original intention is to keep a paired clk enable counter no matter
>> how the user calls pwm_enable()/pwm_disable() in pair or not, if that's
>> no longer the case.
>
> We don't need to worry that case:
> In pwm core, both pwm_enable() and pwm_disable() will always check
> PWMF_ENABLED flag.
That's good then, this part of the code was dated before the pwm core,
looks like this has been carefully handled. Have my ack on this one then:
Acked-by: Eric Miao
>
>
> /**
> * pwm_enable() - start a PWM output toggling
> * @pwm: PWM device
> */
> int pwm_enable(struct pwm_device *pwm)
> {
> if (pwm && !test_and_set_bit(PWMF_ENABLED, >flags))
> return pwm->chip->ops->enable(pwm->chip, pwm);
>
> return pwm ? 0 : -EINVAL;
> }
> EXPORT_SYMBOL_GPL(pwm_enable);
>
> /**
> * pwm_disable() - stop a PWM output toggling
> * @pwm: PWM device
> */
> void pwm_disable(struct pwm_device *pwm)
> {
> if (pwm && test_and_clear_bit(PWMF_ENABLED, >flags))
> pwm->chip->ops->disable(pwm->chip, pwm);
> }
> EXPORT_SYMBOL_GPL(pwm_disable);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] pwm: pxa: Remove clk_enabled field from struct pxa_pwm_chip
On Sun, Mar 31, 2013 at 11:04 PM, Axel Lin wrote:
> clk_enable/clk_disable maintain an enable_count, clk_prepare and clk_unprepare
> also maintain a prepare_count. These APIs will do prepare/enable when the
> first
> user calling these APIs, and do disable/unprepare when the corresponding
> counter
> reach 0. Thus We don't need to maintain a clk_enabled counter here.
The original intention is to keep a paired clk enable counter no matter
how the user calls pwm_enable()/pwm_disable() in pair or not, if that's
no longer the case.
>
> Signed-off-by: Axel Lin
> ---
> drivers/pwm/pwm-pxa.c | 16 ++--
> 1 file changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
> index 20370e6..b789882 100644
> --- a/drivers/pwm/pwm-pxa.c
> +++ b/drivers/pwm/pwm-pxa.c
> @@ -48,7 +48,6 @@ struct pxa_pwm_chip {
> struct device *dev;
>
> struct clk *clk;
> - int clk_enabled;
> void __iomem*mmio_base;
> };
>
> @@ -108,24 +107,15 @@ static int pxa_pwm_config(struct pwm_chip *chip, struct
> pwm_device *pwm,
> static int pxa_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
> {
> struct pxa_pwm_chip *pc = to_pxa_pwm_chip(chip);
> - int rc = 0;
>
> - if (!pc->clk_enabled) {
> - rc = clk_prepare_enable(pc->clk);
> - if (!rc)
> - pc->clk_enabled++;
> - }
> - return rc;
> + return clk_prepare_enable(pc->clk);
> }
>
> static void pxa_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
> {
> struct pxa_pwm_chip *pc = to_pxa_pwm_chip(chip);
>
> - if (pc->clk_enabled) {
> - clk_disable_unprepare(pc->clk);
> - pc->clk_enabled--;
> - }
> + clk_disable_unprepare(pc->clk);
> }
>
> static struct pwm_ops pxa_pwm_ops = {
> @@ -152,8 +142,6 @@ static int pwm_probe(struct platform_device *pdev)
> if (IS_ERR(pwm->clk))
> return PTR_ERR(pwm->clk);
>
> - pwm->clk_enabled = 0;
> -
> pwm->chip.dev = >dev;
> pwm->chip.ops = _pwm_ops;
> pwm->chip.base = -1;
> --
> 1.7.10.4
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: pxa: Use driver_data field to store pwm_nr
On Mon, Apr 1, 2013 at 12:12 AM, Axel Lin wrote:
> The driver_data field was used to store information about PWM_ID_BASE and
> HAS_SECONDARY_PWM. PWM_ID_BASE is not used now after convert to pwm framework.
> This patch stores the pwm_nr in driver_data field to simplify the code.
>
> Signed-off-by: Axel Lin
> ---
> drivers/pwm/pwm-pxa.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
> index b789882..019a8e0 100644
> --- a/drivers/pwm/pwm-pxa.c
> +++ b/drivers/pwm/pwm-pxa.c
> @@ -22,13 +22,10 @@
>
> #include
>
> -#define HAS_SECONDARY_PWM 0x10
> -#define PWM_ID_BASE(d) ((d) & 0xf)
> -
> static const struct platform_device_id pwm_id_table[] = {
> - /* PWMhas_secondary_pwm? */
> - { "pxa25x-pwm", 0 },
> - { "pxa27x-pwm", 0 | HAS_SECONDARY_PWM },
> + /* PWMpwm_nr */
> + { "pxa25x-pwm", 1 },
> + { "pxa27x-pwm", 2 },
> { "pxa168-pwm", 1 },
> { "pxa910-pwm", 1 },
> { },
> @@ -145,7 +142,7 @@ static int pwm_probe(struct platform_device *pdev)
> pwm->chip.dev = >dev;
> pwm->chip.ops = _pwm_ops;
> pwm->chip.base = -1;
> - pwm->chip.npwm = (id->driver_data & HAS_SECONDARY_PWM) ? 2 : 1;
> + pwm->chip.npwm = id->driver_data;
I'd rather keep the flag for a bit more readability?
>
> r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (r == NULL) {
> --
> 1.7.10.4
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: pxa: Use driver_data field to store pwm_nr
On Mon, Apr 1, 2013 at 12:12 AM, Axel Lin axel@ingics.com wrote:
The driver_data field was used to store information about PWM_ID_BASE and
HAS_SECONDARY_PWM. PWM_ID_BASE is not used now after convert to pwm framework.
This patch stores the pwm_nr in driver_data field to simplify the code.
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/pwm/pwm-pxa.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index b789882..019a8e0 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -22,13 +22,10 @@
#include asm/div64.h
-#define HAS_SECONDARY_PWM 0x10
-#define PWM_ID_BASE(d) ((d) 0xf)
-
static const struct platform_device_id pwm_id_table[] = {
- /* PWMhas_secondary_pwm? */
- { pxa25x-pwm, 0 },
- { pxa27x-pwm, 0 | HAS_SECONDARY_PWM },
+ /* PWMpwm_nr */
+ { pxa25x-pwm, 1 },
+ { pxa27x-pwm, 2 },
{ pxa168-pwm, 1 },
{ pxa910-pwm, 1 },
{ },
@@ -145,7 +142,7 @@ static int pwm_probe(struct platform_device *pdev)
pwm-chip.dev = pdev-dev;
pwm-chip.ops = pxa_pwm_ops;
pwm-chip.base = -1;
- pwm-chip.npwm = (id-driver_data HAS_SECONDARY_PWM) ? 2 : 1;
+ pwm-chip.npwm = id-driver_data;
I'd rather keep the flag for a bit more readability?
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (r == NULL) {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] pwm: pxa: Remove clk_enabled field from struct pxa_pwm_chip
On Sun, Mar 31, 2013 at 11:04 PM, Axel Lin axel@ingics.com wrote:
clk_enable/clk_disable maintain an enable_count, clk_prepare and clk_unprepare
also maintain a prepare_count. These APIs will do prepare/enable when the
first
user calling these APIs, and do disable/unprepare when the corresponding
counter
reach 0. Thus We don't need to maintain a clk_enabled counter here.
The original intention is to keep a paired clk enable counter no matter
how the user calls pwm_enable()/pwm_disable() in pair or not, if that's
no longer the case.
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/pwm/pwm-pxa.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index 20370e6..b789882 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -48,7 +48,6 @@ struct pxa_pwm_chip {
struct device *dev;
struct clk *clk;
- int clk_enabled;
void __iomem*mmio_base;
};
@@ -108,24 +107,15 @@ static int pxa_pwm_config(struct pwm_chip *chip, struct
pwm_device *pwm,
static int pxa_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
{
struct pxa_pwm_chip *pc = to_pxa_pwm_chip(chip);
- int rc = 0;
- if (!pc-clk_enabled) {
- rc = clk_prepare_enable(pc-clk);
- if (!rc)
- pc-clk_enabled++;
- }
- return rc;
+ return clk_prepare_enable(pc-clk);
}
static void pxa_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
{
struct pxa_pwm_chip *pc = to_pxa_pwm_chip(chip);
- if (pc-clk_enabled) {
- clk_disable_unprepare(pc-clk);
- pc-clk_enabled--;
- }
+ clk_disable_unprepare(pc-clk);
}
static struct pwm_ops pxa_pwm_ops = {
@@ -152,8 +142,6 @@ static int pwm_probe(struct platform_device *pdev)
if (IS_ERR(pwm-clk))
return PTR_ERR(pwm-clk);
- pwm-clk_enabled = 0;
-
pwm-chip.dev = pdev-dev;
pwm-chip.ops = pxa_pwm_ops;
pwm-chip.base = -1;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] pwm: pxa: Remove clk_enabled field from struct pxa_pwm_chip
On Mon, Apr 1, 2013 at 3:32 PM, Axel Lin axel@ingics.com wrote:
2013/4/1 Eric Miao eric.y.m...@gmail.com:
On Sun, Mar 31, 2013 at 11:04 PM, Axel Lin axel@ingics.com wrote:
clk_enable/clk_disable maintain an enable_count, clk_prepare and
clk_unprepare
also maintain a prepare_count. These APIs will do prepare/enable when the
first
user calling these APIs, and do disable/unprepare when the corresponding
counter
reach 0. Thus We don't need to maintain a clk_enabled counter here.
The original intention is to keep a paired clk enable counter no matter
how the user calls pwm_enable()/pwm_disable() in pair or not, if that's
no longer the case.
We don't need to worry that case:
In pwm core, both pwm_enable() and pwm_disable() will always check
PWMF_ENABLED flag.
That's good then, this part of the code was dated before the pwm core,
looks like this has been carefully handled. Have my ack on this one then:
Acked-by: Eric Miao eric.y.m...@gmail.com
/**
* pwm_enable() - start a PWM output toggling
* @pwm: PWM device
*/
int pwm_enable(struct pwm_device *pwm)
{
if (pwm !test_and_set_bit(PWMF_ENABLED, pwm-flags))
return pwm-chip-ops-enable(pwm-chip, pwm);
return pwm ? 0 : -EINVAL;
}
EXPORT_SYMBOL_GPL(pwm_enable);
/**
* pwm_disable() - stop a PWM output toggling
* @pwm: PWM device
*/
void pwm_disable(struct pwm_device *pwm)
{
if (pwm test_and_clear_bit(PWMF_ENABLED, pwm-flags))
pwm-chip-ops-disable(pwm-chip, pwm);
}
EXPORT_SYMBOL_GPL(pwm_disable);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: pxa: Remove PWM_ID_BASE macro
On Mon, Apr 1, 2013 at 3:41 PM, Axel Lin axel@ingics.com wrote:
PWM_ID_BASE() is not used after convert to PWM framework, remove it.
Also update driver_data field of struct platform_device_id accordingly.
Signed-off-by: Axel Lin axel@ingics.com
---
This is v2 of [PATCH] pwm: pxa: Use driver_data field to store pwm_nr.
I change the subject line to meet the change in v2.
drivers/pwm/pwm-pxa.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index b789882..dee6ab55 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -23,14 +23,13 @@
#include asm/div64.h
#define HAS_SECONDARY_PWM 0x10
-#define PWM_ID_BASE(d) ((d) 0xf)
static const struct platform_device_id pwm_id_table[] = {
/* PWMhas_secondary_pwm? */
{ pxa25x-pwm, 0 },
- { pxa27x-pwm, 0 | HAS_SECONDARY_PWM },
- { pxa168-pwm, 1 },
- { pxa910-pwm, 1 },
+ { pxa27x-pwm, HAS_SECONDARY_PWM },
+ { pxa168-pwm, 0 },
+ { pxa910-pwm, 0 },
{ },
};
MODULE_DEVICE_TABLE(platform, pwm_id_table);
Looks good to me, Acked-by: Eric Miao eric.y.m...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/9] cpufreq: pxa3xx: move cpufreq driver to drivers/cpufreq
On Sun, Mar 31, 2013 at 2:45 PM, Viresh Kumar wrote: > On 31 March 2013 10:54, Eric Miao wrote: >> On Sun, Mar 31, 2013 at 11:52 AM, Viresh Kumar >> wrote: >>> Eric/Haojian, >>> >>> On 25 March 2013 15:41, Viresh Kumar wrote: >>>> This patch moves cpufreq driver of ARM based pxa3xx platform to >>>> drivers/cpufreq. >>>> >>>> Cc: Eric Miao >> >> Acked-by: Eric Miao >> >>>> Cc: Haojian Zhuang >>>> Signed-off-by: Viresh Kumar >>>> --- >>>> arch/arm/mach-pxa/Makefile | 1 - >>>> arch/arm/mach-pxa/include/mach/generic.h | 1 + >>>> drivers/cpufreq/Makefile | 1 + >>>> .../mach-pxa/cpufreq-pxa3xx.c => drivers/cpufreq/pxa3xx-cpufreq.c| 5 >>>> + >>>> 4 files changed, 3 insertions(+), 5 deletions(-) >>>> create mode 100644 arch/arm/mach-pxa/include/mach/generic.h >>>> rename arch/arm/mach-pxa/cpufreq-pxa3xx.c => >>>> drivers/cpufreq/pxa3xx-cpufreq.c (98%) >>> >>> Can i have your Ack or views about 6/9 and 7/9 Patch? > > Is this for both the patches?? Yes. Take the Ack for both, those two should really belong to drivers/cpufreq. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/9] cpufreq: pxa3xx: move cpufreq driver to drivers/cpufreq
On Sun, Mar 31, 2013 at 2:45 PM, Viresh Kumar viresh.ku...@linaro.org wrote: On 31 March 2013 10:54, Eric Miao eric.y.m...@gmail.com wrote: On Sun, Mar 31, 2013 at 11:52 AM, Viresh Kumar viresh.ku...@linaro.org wrote: Eric/Haojian, On 25 March 2013 15:41, Viresh Kumar viresh.ku...@linaro.org wrote: This patch moves cpufreq driver of ARM based pxa3xx platform to drivers/cpufreq. Cc: Eric Miao eric.y.m...@gmail.com Acked-by: Eric Miao eric.y.m...@gmail.com Cc: Haojian Zhuang haojian.zhu...@gmail.com Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- arch/arm/mach-pxa/Makefile | 1 - arch/arm/mach-pxa/include/mach/generic.h | 1 + drivers/cpufreq/Makefile | 1 + .../mach-pxa/cpufreq-pxa3xx.c = drivers/cpufreq/pxa3xx-cpufreq.c| 5 + 4 files changed, 3 insertions(+), 5 deletions(-) create mode 100644 arch/arm/mach-pxa/include/mach/generic.h rename arch/arm/mach-pxa/cpufreq-pxa3xx.c = drivers/cpufreq/pxa3xx-cpufreq.c (98%) Can i have your Ack or views about 6/9 and 7/9 Patch? Is this for both the patches?? Yes. Take the Ack for both, those two should really belong to drivers/cpufreq. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/9] cpufreq: pxa3xx: move cpufreq driver to drivers/cpufreq
On Sun, Mar 31, 2013 at 11:52 AM, Viresh Kumar wrote: > Eric/Haojian, > > On 25 March 2013 15:41, Viresh Kumar wrote: >> This patch moves cpufreq driver of ARM based pxa3xx platform to >> drivers/cpufreq. >> >> Cc: Eric Miao Acked-by: Eric Miao >> Cc: Haojian Zhuang >> Signed-off-by: Viresh Kumar >> --- >> arch/arm/mach-pxa/Makefile | 1 - >> arch/arm/mach-pxa/include/mach/generic.h | 1 + >> drivers/cpufreq/Makefile | 1 + >> .../mach-pxa/cpufreq-pxa3xx.c => drivers/cpufreq/pxa3xx-cpufreq.c| 5 >> + >> 4 files changed, 3 insertions(+), 5 deletions(-) >> create mode 100644 arch/arm/mach-pxa/include/mach/generic.h >> rename arch/arm/mach-pxa/cpufreq-pxa3xx.c => >> drivers/cpufreq/pxa3xx-cpufreq.c (98%) > > Can i have your Ack or views about 6/9 and 7/9 Patch? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/9] cpufreq: pxa3xx: move cpufreq driver to drivers/cpufreq
On Sun, Mar 31, 2013 at 11:52 AM, Viresh Kumar viresh.ku...@linaro.org wrote: Eric/Haojian, On 25 March 2013 15:41, Viresh Kumar viresh.ku...@linaro.org wrote: This patch moves cpufreq driver of ARM based pxa3xx platform to drivers/cpufreq. Cc: Eric Miao eric.y.m...@gmail.com Acked-by: Eric Miao eric.y.m...@gmail.com Cc: Haojian Zhuang haojian.zhu...@gmail.com Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- arch/arm/mach-pxa/Makefile | 1 - arch/arm/mach-pxa/include/mach/generic.h | 1 + drivers/cpufreq/Makefile | 1 + .../mach-pxa/cpufreq-pxa3xx.c = drivers/cpufreq/pxa3xx-cpufreq.c| 5 + 4 files changed, 3 insertions(+), 5 deletions(-) create mode 100644 arch/arm/mach-pxa/include/mach/generic.h rename arch/arm/mach-pxa/cpufreq-pxa3xx.c = drivers/cpufreq/pxa3xx-cpufreq.c (98%) Can i have your Ack or views about 6/9 and 7/9 Patch? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] spi/pxa2xx: allow building on a 64-bit kernel
On Mon, Jan 7, 2013 at 6:44 PM, Mika Westerberg
wrote:
> In addition fix following warnings seen when compiling 64-bit:
>
> drivers/spi/spi-pxa2xx.c: In function ‘map_dma_buffers’:
> drivers/spi/spi-pxa2xx.c:384:7: warning: cast from pointer to integer of
> different size [-Wpointer-to-int-cast]
> drivers/spi/spi-pxa2xx.c:384:40: warning: cast from pointer to integer of
> different size [-Wpointer-to-int-cast]
> drivers/spi/spi-pxa2xx.c: In function ‘pxa2xx_spi_probe’:
> drivers/spi/spi-pxa2xx.c:1572:34: warning: cast from pointer to integer of
> different size [-Wpointer-to-int-cast]
> drivers/spi/spi-pxa2xx.c:1572:34: warning: cast from pointer to integer of
> different size [-Wpointer-to-int-cast]
> drivers/spi/spi-pxa2xx.c:1572:34: warning: cast from pointer to integer of
> different size [-Wpointer-to-int-cast]
> drivers/spi/spi-pxa2xx.c:1572:27: warning: cast to pointer from integer of
> different size [-Wint-to-pointer-cast]
>
> Signed-off-by: Mika Westerberg
> ---
> drivers/spi/Kconfig |4 ++--
> drivers/spi/spi-pxa2xx.c |5 ++---
> 2 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 2e188e1..a90393d 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -299,7 +299,7 @@ config SPI_PPC4xx
>
> config SPI_PXA2XX
> tristate "PXA2xx SSP SPI master"
> - depends on (ARCH_PXA || (X86_32 && PCI)) && EXPERIMENTAL
> + depends on ARCH_PXA || PCI
> select PXA_SSP if ARCH_PXA
> help
> This enables using a PXA2xx or Sodaville SSP port as a SPI master
> @@ -307,7 +307,7 @@ config SPI_PXA2XX
> additional documentation can be found a Documentation/spi/pxa2xx.
>
> config SPI_PXA2XX_PCI
> - def_bool SPI_PXA2XX && X86_32 && PCI
> + def_tristate SPI_PXA2XX && PCI
>
Generally looks good to me, I think we could split the changes to
* Kconfig (adding 64-bit support or removing restrictions of X86_32
for the driver)
* and to spi-pxa2xx.c (mostly to handle the alignment warnings)
> config SPI_RSPI
> tristate "Renesas RSPI controller"
> diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
> index 5c8c4f5..7fac65d 100644
> --- a/drivers/spi/spi-pxa2xx.c
> +++ b/drivers/spi/spi-pxa2xx.c
> @@ -47,7 +47,7 @@ MODULE_ALIAS("platform:pxa2xx-spi");
>
> #define DMA_INT_MASK (DCSR_ENDINTR | DCSR_STARTINTR | DCSR_BUSERR)
> #define RESET_DMA_CHANNEL (DCSR_NODESC | DMA_INT_MASK)
> -#define IS_DMA_ALIGNED(x) u32)(x)) & 0x07) == 0)
> +#define IS_DMA_ALIGNED(x) IS_ALIGNED((unsigned long)x, DMA_ALIGNMENT)
OK.
> #define MAX_DMA_LEN8191
> #define DMA_ALIGNMENT 8
>
> @@ -1569,8 +1569,7 @@ static int pxa2xx_spi_probe(struct platform_device
> *pdev)
> master->transfer = transfer;
>
> drv_data->ssp_type = ssp->type;
> - drv_data->null_dma_buf = (u32 *)ALIGN((u32)(drv_data +
> - sizeof(struct driver_data)),
> 8);
> + drv_data->null_dma_buf = (u32 *)PTR_ALIGN(drv_data + 1, 8);
Hmm... the original code seems to have big problem and interestingly no
one has reported the issue, possibly due to null_dma_buf being seldomly
used.
However, it's still a bit obscure to have 'drv_data + 1', 'drv_data[1]' might
be a bit better for readability.
And it'll be better to have DMA_ALIGNTMENT here instead of a hard-coded
constant '8'.
u
>
> drv_data->ioaddr = ssp->mmio_base;
> drv_data->ssdr_physical = ssp->phys_base + SSDR;
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] spi/pxa2xx: allow building on a 64-bit kernel
On Mon, Jan 7, 2013 at 6:44 PM, Mika Westerberg mika.westerb...@linux.intel.com wrote: In addition fix following warnings seen when compiling 64-bit: drivers/spi/spi-pxa2xx.c: In function ‘map_dma_buffers’: drivers/spi/spi-pxa2xx.c:384:7: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] drivers/spi/spi-pxa2xx.c:384:40: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] drivers/spi/spi-pxa2xx.c: In function ‘pxa2xx_spi_probe’: drivers/spi/spi-pxa2xx.c:1572:34: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] drivers/spi/spi-pxa2xx.c:1572:34: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] drivers/spi/spi-pxa2xx.c:1572:34: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] drivers/spi/spi-pxa2xx.c:1572:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com --- drivers/spi/Kconfig |4 ++-- drivers/spi/spi-pxa2xx.c |5 ++--- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 2e188e1..a90393d 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -299,7 +299,7 @@ config SPI_PPC4xx config SPI_PXA2XX tristate PXA2xx SSP SPI master - depends on (ARCH_PXA || (X86_32 PCI)) EXPERIMENTAL + depends on ARCH_PXA || PCI select PXA_SSP if ARCH_PXA help This enables using a PXA2xx or Sodaville SSP port as a SPI master @@ -307,7 +307,7 @@ config SPI_PXA2XX additional documentation can be found a Documentation/spi/pxa2xx. config SPI_PXA2XX_PCI - def_bool SPI_PXA2XX X86_32 PCI + def_tristate SPI_PXA2XX PCI Generally looks good to me, I think we could split the changes to * Kconfig (adding 64-bit support or removing restrictions of X86_32 for the driver) * and to spi-pxa2xx.c (mostly to handle the alignment warnings) config SPI_RSPI tristate Renesas RSPI controller diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c index 5c8c4f5..7fac65d 100644 --- a/drivers/spi/spi-pxa2xx.c +++ b/drivers/spi/spi-pxa2xx.c @@ -47,7 +47,7 @@ MODULE_ALIAS(platform:pxa2xx-spi); #define DMA_INT_MASK (DCSR_ENDINTR | DCSR_STARTINTR | DCSR_BUSERR) #define RESET_DMA_CHANNEL (DCSR_NODESC | DMA_INT_MASK) -#define IS_DMA_ALIGNED(x) u32)(x)) 0x07) == 0) +#define IS_DMA_ALIGNED(x) IS_ALIGNED((unsigned long)x, DMA_ALIGNMENT) OK. #define MAX_DMA_LEN8191 #define DMA_ALIGNMENT 8 @@ -1569,8 +1569,7 @@ static int pxa2xx_spi_probe(struct platform_device *pdev) master-transfer = transfer; drv_data-ssp_type = ssp-type; - drv_data-null_dma_buf = (u32 *)ALIGN((u32)(drv_data + - sizeof(struct driver_data)), 8); + drv_data-null_dma_buf = (u32 *)PTR_ALIGN(drv_data + 1, 8); Hmm... the original code seems to have big problem and interestingly no one has reported the issue, possibly due to null_dma_buf being seldomly used. However, it's still a bit obscure to have 'drv_data + 1', 'drv_data[1]' might be a bit better for readability. And it'll be better to have DMA_ALIGNTMENT here instead of a hard-coded constant '8'. u drv_data-ioaddr = ssp-mmio_base; drv_data-ssdr_physical = ssp-phys_base + SSDR; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/11] ARM: pxa: convert timer suspend/resume to clock_event_device
On Fri, Nov 9, 2012 at 5:01 AM, Stephen Warren wrote:
> From: Stephen Warren
>
> Move PXA's timer suspend/resume functions from struct sys_timer
> pxa_timer into struct clock_event_device ckevt_pxa_osmr0. This
> will allow the sys_timer suspend/resume fields to be removed, and
> eventually lead to a complete removal of struct sys_timer.
>
> Cc: Eric Miao
> Cc: Russell King
> Cc: Haojian Zhuang
> Signed-off-by: Stephen Warren
Acked-by: Eric Miao
> ---
> arch/arm/mach-pxa/time.c | 76
> +++---
> 1 files changed, 38 insertions(+), 38 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/time.c b/arch/arm/mach-pxa/time.c
> index 4bc47d6..ce58bc9 100644
> --- a/arch/arm/mach-pxa/time.c
> +++ b/arch/arm/mach-pxa/time.c
> @@ -89,12 +89,50 @@ pxa_osmr0_set_mode(enum clock_event_mode mode, struct
> clock_event_device *dev)
> }
> }
>
> +#ifdef CONFIG_PM
> +static unsigned long osmr[4], oier, oscr;
> +
> +static void pxa_timer_suspend(struct clock_event_device *cedev)
> +{
> + osmr[0] = readl_relaxed(OSMR0);
> + osmr[1] = readl_relaxed(OSMR1);
> + osmr[2] = readl_relaxed(OSMR2);
> + osmr[3] = readl_relaxed(OSMR3);
> + oier = readl_relaxed(OIER);
> + oscr = readl_relaxed(OSCR);
> +}
> +
> +static void pxa_timer_resume(struct clock_event_device *cedev)
> +{
> + /*
> +* Ensure that we have at least MIN_OSCR_DELTA between match
> +* register 0 and the OSCR, to guarantee that we will receive
> +* the one-shot timer interrupt. We adjust OSMR0 in preference
> +* to OSCR to guarantee that OSCR is monotonically incrementing.
> +*/
> + if (osmr[0] - oscr < MIN_OSCR_DELTA)
> + osmr[0] += MIN_OSCR_DELTA;
> +
> + writel_relaxed(osmr[0], OSMR0);
> + writel_relaxed(osmr[1], OSMR1);
> + writel_relaxed(osmr[2], OSMR2);
> + writel_relaxed(osmr[3], OSMR3);
> + writel_relaxed(oier, OIER);
> + writel_relaxed(oscr, OSCR);
> +}
> +#else
> +#define pxa_timer_suspend NULL
> +#define pxa_timer_resume NULL
> +#endif
> +
> static struct clock_event_device ckevt_pxa_osmr0 = {
> .name = "osmr0",
> .features = CLOCK_EVT_FEAT_ONESHOT,
> .rating = 200,
> .set_next_event = pxa_osmr0_set_next_event,
> .set_mode = pxa_osmr0_set_mode,
> + .suspend= pxa_timer_suspend,
> + .resume = pxa_timer_resume,
> };
>
> static struct irqaction pxa_ost0_irq = {
> @@ -127,44 +165,6 @@ static void __init pxa_timer_init(void)
> clockevents_register_device(_pxa_osmr0);
> }
>
> -#ifdef CONFIG_PM
> -static unsigned long osmr[4], oier, oscr;
> -
> -static void pxa_timer_suspend(void)
> -{
> - osmr[0] = readl_relaxed(OSMR0);
> - osmr[1] = readl_relaxed(OSMR1);
> - osmr[2] = readl_relaxed(OSMR2);
> - osmr[3] = readl_relaxed(OSMR3);
> - oier = readl_relaxed(OIER);
> - oscr = readl_relaxed(OSCR);
> -}
> -
> -static void pxa_timer_resume(void)
> -{
> - /*
> -* Ensure that we have at least MIN_OSCR_DELTA between match
> -* register 0 and the OSCR, to guarantee that we will receive
> -* the one-shot timer interrupt. We adjust OSMR0 in preference
> -* to OSCR to guarantee that OSCR is monotonically incrementing.
> -*/
> - if (osmr[0] - oscr < MIN_OSCR_DELTA)
> - osmr[0] += MIN_OSCR_DELTA;
> -
> - writel_relaxed(osmr[0], OSMR0);
> - writel_relaxed(osmr[1], OSMR1);
> - writel_relaxed(osmr[2], OSMR2);
> - writel_relaxed(osmr[3], OSMR3);
> - writel_relaxed(oier, OIER);
> - writel_relaxed(oscr, OSCR);
> -}
> -#else
> -#define pxa_timer_suspend NULL
> -#define pxa_timer_resume NULL
> -#endif
> -
> struct sys_timer pxa_timer = {
> .init = pxa_timer_init,
> - .suspend= pxa_timer_suspend,
> - .resume = pxa_timer_resume,
> };
> --
> 1.7.0.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/11] ARM: pxa: convert timer suspend/resume to clock_event_device
On Fri, Nov 9, 2012 at 5:01 AM, Stephen Warren swar...@wwwdotorg.org wrote:
From: Stephen Warren swar...@nvidia.com
Move PXA's timer suspend/resume functions from struct sys_timer
pxa_timer into struct clock_event_device ckevt_pxa_osmr0. This
will allow the sys_timer suspend/resume fields to be removed, and
eventually lead to a complete removal of struct sys_timer.
Cc: Eric Miao eric.y.m...@gmail.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Signed-off-by: Stephen Warren swar...@nvidia.com
Acked-by: Eric Miao eric.y.m...@gmail.com
---
arch/arm/mach-pxa/time.c | 76
+++---
1 files changed, 38 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-pxa/time.c b/arch/arm/mach-pxa/time.c
index 4bc47d6..ce58bc9 100644
--- a/arch/arm/mach-pxa/time.c
+++ b/arch/arm/mach-pxa/time.c
@@ -89,12 +89,50 @@ pxa_osmr0_set_mode(enum clock_event_mode mode, struct
clock_event_device *dev)
}
}
+#ifdef CONFIG_PM
+static unsigned long osmr[4], oier, oscr;
+
+static void pxa_timer_suspend(struct clock_event_device *cedev)
+{
+ osmr[0] = readl_relaxed(OSMR0);
+ osmr[1] = readl_relaxed(OSMR1);
+ osmr[2] = readl_relaxed(OSMR2);
+ osmr[3] = readl_relaxed(OSMR3);
+ oier = readl_relaxed(OIER);
+ oscr = readl_relaxed(OSCR);
+}
+
+static void pxa_timer_resume(struct clock_event_device *cedev)
+{
+ /*
+* Ensure that we have at least MIN_OSCR_DELTA between match
+* register 0 and the OSCR, to guarantee that we will receive
+* the one-shot timer interrupt. We adjust OSMR0 in preference
+* to OSCR to guarantee that OSCR is monotonically incrementing.
+*/
+ if (osmr[0] - oscr MIN_OSCR_DELTA)
+ osmr[0] += MIN_OSCR_DELTA;
+
+ writel_relaxed(osmr[0], OSMR0);
+ writel_relaxed(osmr[1], OSMR1);
+ writel_relaxed(osmr[2], OSMR2);
+ writel_relaxed(osmr[3], OSMR3);
+ writel_relaxed(oier, OIER);
+ writel_relaxed(oscr, OSCR);
+}
+#else
+#define pxa_timer_suspend NULL
+#define pxa_timer_resume NULL
+#endif
+
static struct clock_event_device ckevt_pxa_osmr0 = {
.name = osmr0,
.features = CLOCK_EVT_FEAT_ONESHOT,
.rating = 200,
.set_next_event = pxa_osmr0_set_next_event,
.set_mode = pxa_osmr0_set_mode,
+ .suspend= pxa_timer_suspend,
+ .resume = pxa_timer_resume,
};
static struct irqaction pxa_ost0_irq = {
@@ -127,44 +165,6 @@ static void __init pxa_timer_init(void)
clockevents_register_device(ckevt_pxa_osmr0);
}
-#ifdef CONFIG_PM
-static unsigned long osmr[4], oier, oscr;
-
-static void pxa_timer_suspend(void)
-{
- osmr[0] = readl_relaxed(OSMR0);
- osmr[1] = readl_relaxed(OSMR1);
- osmr[2] = readl_relaxed(OSMR2);
- osmr[3] = readl_relaxed(OSMR3);
- oier = readl_relaxed(OIER);
- oscr = readl_relaxed(OSCR);
-}
-
-static void pxa_timer_resume(void)
-{
- /*
-* Ensure that we have at least MIN_OSCR_DELTA between match
-* register 0 and the OSCR, to guarantee that we will receive
-* the one-shot timer interrupt. We adjust OSMR0 in preference
-* to OSCR to guarantee that OSCR is monotonically incrementing.
-*/
- if (osmr[0] - oscr MIN_OSCR_DELTA)
- osmr[0] += MIN_OSCR_DELTA;
-
- writel_relaxed(osmr[0], OSMR0);
- writel_relaxed(osmr[1], OSMR1);
- writel_relaxed(osmr[2], OSMR2);
- writel_relaxed(osmr[3], OSMR3);
- writel_relaxed(oier, OIER);
- writel_relaxed(oscr, OSCR);
-}
-#else
-#define pxa_timer_suspend NULL
-#define pxa_timer_resume NULL
-#endif
-
struct sys_timer pxa_timer = {
.init = pxa_timer_init,
- .suspend= pxa_timer_suspend,
- .resume = pxa_timer_resume,
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: Get rid of HAVE_PWM
On Fri, Oct 5, 2012 at 3:13 AM, Thierry Reding wrote: > On Thu, Oct 04, 2012 at 08:48:54PM +0200, Lars-Peter Clausen wrote: >> On 10/04/2012 08:29 PM, Thierry Reding wrote: >> > On Thu, Oct 04, 2012 at 05:00:23PM +0200, Lars-Peter Clausen wrote: >> >> On 10/04/2012 08:06 AM, Thierry Reding wrote: >> >>> [...] >> >>> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig >> >>> index 331d574..b38f23d 100644 >> >>> --- a/arch/mips/Kconfig >> >>> +++ b/arch/mips/Kconfig >> >>> @@ -219,7 +219,8 @@ config MACH_JZ4740 >> >>> select GENERIC_GPIO >> >>> select ARCH_REQUIRE_GPIOLIB >> >>> select SYS_HAS_EARLY_PRINTK >> >>> - select HAVE_PWM >> >>> + select PWM >> >>> + select PWM_JZ4740 >> >>> select HAVE_CLK >> >>> select GENERIC_IRQ_CHIP >> >> >> >> I'm not sure if this is such a good idea, not all jz4740 based board >> >> necessarily require PWM. >> > >> > This really only restores previous behaviour. But I agree that this is >> > potentially not what we want. Maybe we should just not select this for >> > any boards but rather leave it up to some default configuration. If so >> > the patch can be made simpler by just removing the HAVE_PWM entries. >> >> At least for JZ4740 I think that is the better solution. > > Okay, I'll give other people the chance to comment on this. Especially > for PXA there are many boards that use the PWM for backlight and it > would be interesting to hear from them how they want this to be handled. I'd say the original intention to introduce HAVE_PWM (although PXA makes a lot use of this, but I remember Russell was the first to propose this), is for board config to indicate its potential usage of the PWM or rather if PWM is available for use on the board, and then leave the developer another config option to build or not-to-build. Personally I think removing HAVE_PWM will simplify the code a bit and that's a good thing, on the other hand, how to keep a certain level of flexibility mentioned above remains a small question. I guess with device tree, this can be mitigated a bit. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/17] ARM: pxa: remove sharpsl_fatal_check function
On Wed, Oct 3, 2012 at 12:36 AM, Arnd Bergmann wrote:
> The sharpsl_fatal_check has not been used since Pavel Machek removed
> the caller in 99f329a2b "pxa/sharpsl_pm: zaurus c3000 aka spitz: fix
> resume". Nobody has complained since 2009, so it's safe to assume we
> can just remove the function.
>
> Without this patch, building corgi_defconfig results in:
>
> /home/arnd/linux-arm/arch/arm/mach-pxa/sharpsl_pm.c:693:12: warning:
> 'sharpsl_fatal_check' defined but not used [-Wunused-function]
>
> Signed-off-by: Arnd Bergmann
> Cc: Pavel Machek
> Cc: Stanislav Brabec
> Cc: Eric Miao
> Cc: Haojian Zhuang
Acked-by: Eric Miao
Let's get it cleaned up firstly. One can always reference the history for a
sample implementation later if this is needed in the future.
> ---
> arch/arm/mach-pxa/sharpsl_pm.c | 48
>
> 1 file changed, 48 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-pxa/sharpsl_pm.c
> index bdf4cb8..6c9658f 100644
> --- a/arch/arm/mach-pxa/sharpsl_pm.c
> +++ b/arch/arm/mach-pxa/sharpsl_pm.c
> @@ -55,7 +55,6 @@
> #ifdef CONFIG_PM
> static int sharpsl_off_charge_battery(void);
> static int sharpsl_check_battery_voltage(void);
> -static int sharpsl_fatal_check(void);
> #endif
> static int sharpsl_check_battery_temp(void);
> static int sharpsl_ac_check(void);
> @@ -686,53 +685,6 @@ static int corgi_pxa_pm_enter(suspend_state_t state)
> return 0;
> }
>
> -/*
> - * Check for fatal battery errors
> - * Fatal returns -1
> - */
> -static int sharpsl_fatal_check(void)
> -{
> - int buff[5], temp, i, acin;
> -
> - dev_dbg(sharpsl_pm.dev, "sharpsl_fatal_check entered\n");
> -
> - /* Check AC-Adapter */
> - acin = sharpsl_pm.machinfo->read_devdata(SHARPSL_STATUS_ACIN);
> -
> - if (acin && (sharpsl_pm.charge_mode == CHRG_ON)) {
> - sharpsl_pm.machinfo->charge(0);
> - udelay(100);
> - sharpsl_pm.machinfo->discharge(1); /* enable discharge */
> - mdelay(SHARPSL_WAIT_DISCHARGE_ON);
> - }
> -
> - if (sharpsl_pm.machinfo->discharge1)
> - sharpsl_pm.machinfo->discharge1(1);
> -
> - /* Check battery : check inserting battery ? */
> - for (i = 0; i < 5; i++) {
> - buff[i] =
> sharpsl_pm.machinfo->read_devdata(SHARPSL_BATT_VOLT);
> - mdelay(SHARPSL_CHECK_BATTERY_WAIT_TIME_VOLT);
> - }
> -
> - if (sharpsl_pm.machinfo->discharge1)
> - sharpsl_pm.machinfo->discharge1(0);
> -
> - if (acin && (sharpsl_pm.charge_mode == CHRG_ON)) {
> - udelay(100);
> - sharpsl_pm.machinfo->charge(1);
> - sharpsl_pm.machinfo->discharge(0);
> - }
> -
> - temp = get_select_val(buff);
> - dev_dbg(sharpsl_pm.dev, "sharpsl_fatal_check: acin: %d, discharge
> voltage: %d, no discharge: %ld\n", acin, temp,
> sharpsl_pm.machinfo->read_devdata(SHARPSL_BATT_VOLT));
> -
> - if ((acin && (temp < sharpsl_pm.machinfo->fatal_acin_volt)) ||
> - (!acin && (temp <
> sharpsl_pm.machinfo->fatal_noacin_volt)))
> - return -1;
> - return 0;
> -}
> -
> static int sharpsl_off_charge_error(void)
> {
> dev_err(sharpsl_pm.dev, "Offline Charger: Error occurred.\n");
> --
> 1.7.10
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/17] ARM: pxa: remove sharpsl_fatal_check function
On Wed, Oct 3, 2012 at 12:36 AM, Arnd Bergmann a...@arndb.de wrote:
The sharpsl_fatal_check has not been used since Pavel Machek removed
the caller in 99f329a2b pxa/sharpsl_pm: zaurus c3000 aka spitz: fix
resume. Nobody has complained since 2009, so it's safe to assume we
can just remove the function.
Without this patch, building corgi_defconfig results in:
/home/arnd/linux-arm/arch/arm/mach-pxa/sharpsl_pm.c:693:12: warning:
'sharpsl_fatal_check' defined but not used [-Wunused-function]
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Pavel Machek pa...@ucw.cz
Cc: Stanislav Brabec u...@penguin.cz
Cc: Eric Miao eric.y.m...@gmail.com
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Acked-by: Eric Miao eric.y.m...@gmail.com
Let's get it cleaned up firstly. One can always reference the history for a
sample implementation later if this is needed in the future.
---
arch/arm/mach-pxa/sharpsl_pm.c | 48
1 file changed, 48 deletions(-)
diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-pxa/sharpsl_pm.c
index bdf4cb8..6c9658f 100644
--- a/arch/arm/mach-pxa/sharpsl_pm.c
+++ b/arch/arm/mach-pxa/sharpsl_pm.c
@@ -55,7 +55,6 @@
#ifdef CONFIG_PM
static int sharpsl_off_charge_battery(void);
static int sharpsl_check_battery_voltage(void);
-static int sharpsl_fatal_check(void);
#endif
static int sharpsl_check_battery_temp(void);
static int sharpsl_ac_check(void);
@@ -686,53 +685,6 @@ static int corgi_pxa_pm_enter(suspend_state_t state)
return 0;
}
-/*
- * Check for fatal battery errors
- * Fatal returns -1
- */
-static int sharpsl_fatal_check(void)
-{
- int buff[5], temp, i, acin;
-
- dev_dbg(sharpsl_pm.dev, sharpsl_fatal_check entered\n);
-
- /* Check AC-Adapter */
- acin = sharpsl_pm.machinfo-read_devdata(SHARPSL_STATUS_ACIN);
-
- if (acin (sharpsl_pm.charge_mode == CHRG_ON)) {
- sharpsl_pm.machinfo-charge(0);
- udelay(100);
- sharpsl_pm.machinfo-discharge(1); /* enable discharge */
- mdelay(SHARPSL_WAIT_DISCHARGE_ON);
- }
-
- if (sharpsl_pm.machinfo-discharge1)
- sharpsl_pm.machinfo-discharge1(1);
-
- /* Check battery : check inserting battery ? */
- for (i = 0; i 5; i++) {
- buff[i] =
sharpsl_pm.machinfo-read_devdata(SHARPSL_BATT_VOLT);
- mdelay(SHARPSL_CHECK_BATTERY_WAIT_TIME_VOLT);
- }
-
- if (sharpsl_pm.machinfo-discharge1)
- sharpsl_pm.machinfo-discharge1(0);
-
- if (acin (sharpsl_pm.charge_mode == CHRG_ON)) {
- udelay(100);
- sharpsl_pm.machinfo-charge(1);
- sharpsl_pm.machinfo-discharge(0);
- }
-
- temp = get_select_val(buff);
- dev_dbg(sharpsl_pm.dev, sharpsl_fatal_check: acin: %d, discharge
voltage: %d, no discharge: %ld\n, acin, temp,
sharpsl_pm.machinfo-read_devdata(SHARPSL_BATT_VOLT));
-
- if ((acin (temp sharpsl_pm.machinfo-fatal_acin_volt)) ||
- (!acin (temp
sharpsl_pm.machinfo-fatal_noacin_volt)))
- return -1;
- return 0;
-}
-
static int sharpsl_off_charge_error(void)
{
dev_err(sharpsl_pm.dev, Offline Charger: Error occurred.\n);
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: Get rid of HAVE_PWM
On Fri, Oct 5, 2012 at 3:13 AM, Thierry Reding thierry.red...@avionic-design.de wrote: On Thu, Oct 04, 2012 at 08:48:54PM +0200, Lars-Peter Clausen wrote: On 10/04/2012 08:29 PM, Thierry Reding wrote: On Thu, Oct 04, 2012 at 05:00:23PM +0200, Lars-Peter Clausen wrote: On 10/04/2012 08:06 AM, Thierry Reding wrote: [...] diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 331d574..b38f23d 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -219,7 +219,8 @@ config MACH_JZ4740 select GENERIC_GPIO select ARCH_REQUIRE_GPIOLIB select SYS_HAS_EARLY_PRINTK - select HAVE_PWM + select PWM + select PWM_JZ4740 select HAVE_CLK select GENERIC_IRQ_CHIP I'm not sure if this is such a good idea, not all jz4740 based board necessarily require PWM. This really only restores previous behaviour. But I agree that this is potentially not what we want. Maybe we should just not select this for any boards but rather leave it up to some default configuration. If so the patch can be made simpler by just removing the HAVE_PWM entries. At least for JZ4740 I think that is the better solution. Okay, I'll give other people the chance to comment on this. Especially for PXA there are many boards that use the PWM for backlight and it would be interesting to hear from them how they want this to be handled. I'd say the original intention to introduce HAVE_PWM (although PXA makes a lot use of this, but I remember Russell was the first to propose this), is for board config to indicate its potential usage of the PWM or rather if PWM is available for use on the board, and then leave the developer another config option to build or not-to-build. Personally I think removing HAVE_PWM will simplify the code a bit and that's a good thing, on the other hand, how to keep a certain level of flexibility mentioned above remains a small question. I guess with device tree, this can be mitigated a bit. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: pxa: fix return value check in pxa2xx_drv_pcmcia_probe()
On Fri, Sep 21, 2012 at 3:19 PM, Wei Yongjun wrote: > From: Wei Yongjun > > In case of error, the function clk_get() returns ERR_PTR() > and never returns NULL pointer. The NULL test in the error > handling should be replaced with IS_ERR(). > > dpatch engine is used to auto generated this patch. > (https://github.com/weiyj/dpatch) > > Signed-off-by: Wei Yongjun Ack > --- > drivers/pcmcia/pxa2xx_base.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/pcmcia/pxa2xx_base.c b/drivers/pcmcia/pxa2xx_base.c > index 490bb82..cfec9dd 100644 > --- a/drivers/pcmcia/pxa2xx_base.c > +++ b/drivers/pcmcia/pxa2xx_base.c > @@ -297,7 +297,7 @@ static int pxa2xx_drv_pcmcia_probe(struct platform_device > *dev) > } > > clk = clk_get(>dev, NULL); > - if (!clk) > + if (IS_ERR(clk)) > return -ENODEV; > > pxa2xx_drv_pcmcia_ops(ops); > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: pxa: fix return value check in pxa2xx_drv_pcmcia_probe()
On Fri, Sep 21, 2012 at 3:19 PM, Wei Yongjun weiyj...@gmail.com wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn In case of error, the function clk_get() returns ERR_PTR() and never returns NULL pointer. The NULL test in the error handling should be replaced with IS_ERR(). dpatch engine is used to auto generated this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Ack --- drivers/pcmcia/pxa2xx_base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pcmcia/pxa2xx_base.c b/drivers/pcmcia/pxa2xx_base.c index 490bb82..cfec9dd 100644 --- a/drivers/pcmcia/pxa2xx_base.c +++ b/drivers/pcmcia/pxa2xx_base.c @@ -297,7 +297,7 @@ static int pxa2xx_drv_pcmcia_probe(struct platform_device *dev) } clk = clk_get(dev-dev, NULL); - if (!clk) + if (IS_ERR(clk)) return -ENODEV; pxa2xx_drv_pcmcia_ops(ops); -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: pxa: using for_each_set_bit to simplify the code
On Tue, Sep 18, 2012 at 1:56 PM, Haojian Zhuang wrote: > On Tue, Sep 18, 2012 at 1:43 PM, Eric Miao wrote: >> On Mon, Sep 17, 2012 at 6:56 PM, Linus Walleij >> wrote: >>> On Fri, Sep 14, 2012 at 4:36 AM, Wei Yongjun wrote: >>> >>>> From: Wei Yongjun >>>> >>>> Using for_each_set_bit() to simplify the code. >>>> >>>> spatch with a semantic match is used to found this. >>>> (http://coccinelle.lip6.fr/) >>>> >>>> Signed-off-by: Wei Yongjun >>> >>> PXA maintainers: does this look OK? >> >> I seem to have Acked this already in another mail, if that got lost, here >> it is: >> >> Acked-by: Eric Miao >> > The another mail thread is for irq, not gpio. I'll apply it today. :) Thanks Haojian! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: pxa: using for_each_set_bit to simplify the code
On Tue, Sep 18, 2012 at 1:56 PM, Haojian Zhuang haojian.zhu...@gmail.com wrote: On Tue, Sep 18, 2012 at 1:43 PM, Eric Miao eric.y.m...@gmail.com wrote: On Mon, Sep 17, 2012 at 6:56 PM, Linus Walleij linus.wall...@linaro.org wrote: On Fri, Sep 14, 2012 at 4:36 AM, Wei Yongjun weiyj...@gmail.com wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn Using for_each_set_bit() to simplify the code. spatch with a semantic match is used to found this. (http://coccinelle.lip6.fr/) Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn PXA maintainers: does this look OK? I seem to have Acked this already in another mail, if that got lost, here it is: Acked-by: Eric Miao eric.y.m...@gmail.com The another mail thread is for irq, not gpio. I'll apply it today. :) Thanks Haojian! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: pxa: using for_each_set_bit to simplify the code
On Mon, Sep 17, 2012 at 6:56 PM, Linus Walleij wrote: > On Fri, Sep 14, 2012 at 4:36 AM, Wei Yongjun wrote: > >> From: Wei Yongjun >> >> Using for_each_set_bit() to simplify the code. >> >> spatch with a semantic match is used to found this. >> (http://coccinelle.lip6.fr/) >> >> Signed-off-by: Wei Yongjun > > PXA maintainers: does this look OK? I seem to have Acked this already in another mail, if that got lost, here it is: Acked-by: Eric Miao > > Yours, > Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: pxa: using for_each_set_bit to simplify the code
On Mon, Sep 17, 2012 at 6:56 PM, Linus Walleij linus.wall...@linaro.org wrote: On Fri, Sep 14, 2012 at 4:36 AM, Wei Yongjun weiyj...@gmail.com wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn Using for_each_set_bit() to simplify the code. spatch with a semantic match is used to found this. (http://coccinelle.lip6.fr/) Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn PXA maintainers: does this look OK? I seem to have Acked this already in another mail, if that got lost, here it is: Acked-by: Eric Miao eric.y.m...@gmail.com Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: mmp: using for_each_set_bit to simplify the code
On Fri, Sep 14, 2012 at 10:30 AM, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Using for_each_set_bit() to simplify the code.
>
> spatch with a semantic match is used to found this.
> (http://coccinelle.lip6.fr/)
>
> Signed-off-by: Wei Yongjun
Great API, this is good. Acked-by: Eric Miao
> ---
> arch/arm/mach-mmp/irq.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-mmp/irq.c b/arch/arm/mach-mmp/irq.c
> index e60c7d9..3c71246 100644
> --- a/arch/arm/mach-mmp/irq.c
> +++ b/arch/arm/mach-mmp/irq.c
> @@ -153,10 +153,8 @@ static void icu_mux_irq_demux(unsigned int irq, struct
> irq_desc *desc)
> status = readl_relaxed(data->reg_status) & ~mask;
> if (status == 0)
> break;
> - n = find_first_bit(, BITS_PER_LONG);
> - while (n < BITS_PER_LONG) {
> + for_each_set_bit(n, , BITS_PER_LONG) {
> generic_handle_irq(icu_data[i].virq_base + n);
> - n = find_next_bit(, BITS_PER_LONG, n + 1);
> }
> }
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: mmp: using for_each_set_bit to simplify the code
On Fri, Sep 14, 2012 at 10:30 AM, Wei Yongjun weiyj...@gmail.com wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Using for_each_set_bit() to simplify the code.
spatch with a semantic match is used to found this.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
Great API, this is good. Acked-by: Eric Miao eric.y.m...@gmail.com
---
arch/arm/mach-mmp/irq.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-mmp/irq.c b/arch/arm/mach-mmp/irq.c
index e60c7d9..3c71246 100644
--- a/arch/arm/mach-mmp/irq.c
+++ b/arch/arm/mach-mmp/irq.c
@@ -153,10 +153,8 @@ static void icu_mux_irq_demux(unsigned int irq, struct
irq_desc *desc)
status = readl_relaxed(data-reg_status) ~mask;
if (status == 0)
break;
- n = find_first_bit(status, BITS_PER_LONG);
- while (n BITS_PER_LONG) {
+ for_each_set_bit(n, status, BITS_PER_LONG) {
generic_handle_irq(icu_data[i].virq_base + n);
- n = find_next_bit(status, BITS_PER_LONG, n + 1);
}
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Emulating level IRQs
On Mon, Aug 6, 2012 at 1:56 AM, Daniel Mack wrote: > On 05.08.2012 18:56, Haojian Zhuang wrote: >> On Mon, Aug 6, 2012 at 12:22 AM, Daniel Mack wrote: >>> On 24.07.2012 20:01, Daniel Mack wrote: On 23.07.2012 18:51, Dmitry Torokhov wrote: > On Thu, Jul 19, 2012 at 05:36:12PM +0200, Daniel Mack wrote: >> Ok, finally I found some time. In general, the patch works fine. The >> only detail I had to amend was the irqflags, which were changed from >> IRQF_TRIGGER_RISING/IRQF_TRIGGER_FALLING to >> IRQF_TRIGGER_HIGH/IRQF_TRIGGER_LOW, which doesn't work as the PXA can't >> deal with level-based IRQs. Changing this back to RISING/FALLING makes >> the driver work again. > > Hmm, but that would mean we need to restore reading the data in open() > to make sure we re-arm IRQ in case somebody touched the screen before it > was opened by userspace... I had another look at this and don't really know what to do here. We definitely need level interrupts for this device as the interrupt line's level is the only that tells us when we can stop reading from the device. So it's not just the start condition that bites us here. I copied some people that might help find a solution. To summarize the problem: The EETI touchscreen is a device that asserts a GPIO line when it has events to deliver and waits for I2C commands to empty its buffers. When there are no more buffered events, it will de-assert the line. This device is connected to a PXA GPIO that is only able to deliver edge IRQs, and the old implemenation was to wait for an interrupt and then read data as long as the IRQ's corresponding GPIO was asserted. However, expecting that an IRQ is mappable to a GPIO is not something we should do, so the only clean solution is to teach the PXA GPIO controller level IRQs. So it boils down to the question: Is there any easy and generic way to emulate level irq on chips that don't support that natively? >>> >>> Otherwise, we would need some sort of generic irq_to_gpio() again, and >>> the interrupt line the driver listens to must have support for that sort >>> of mapping. >>> >>> Any opinion on this, anyone? >>> >> Since you're using gpio as input, you need to call gpio_request() and set it >> as input direction. And you could also transfer the gpio number into touch >> driver via platform data. Is it OK for you? > > No, that's not the point. What we get via the i2c runtime data is an > interrupt number. The driver is driven by that interrupt and doesn't > poll on a GPIO line, which is how it should be. > > However, in order to know when to stop reading from the device, we need > to monitor the GPIO line after the interrupt has arrived, and read as > long as the line is asserted. Then we stop reading and wait for the next > interrupt to arrive. > > Hence, what we need here is either a GPIO/IRQ controller that is able to > handle level-IRQs (which the PXA can't do), or we need to have a generic > way to map IRQ lines back to GPIOs. > > Of course, I could pass the GPIO in the platform data and the IRQ in the > I2C data and leave it to the user of the driver to keep both values in > sync, but I wanted to avoid that. I see no better way except to encode the GPIO line into the platform data. In order to solve the sync issue, I personally think mapping the GPIO to IRQ would be better here, and ignore the irq value from the I2C data. A forward mapping of gpio_to_irq() will be less problematic here, and for those platforms where gpio_to_irq() returns invalid, those platforms are probably not desirable for this chip. So my understanding, if it's correct, that we can treat the EETI chip as having two separate inputs: one IRQ line (for the event notification) and one GPIO line (for a condition where data are emptied), we could naturally have two numbers in the driver, but unfortunately they end up being in sync as they are physically one pin. And Daniel, I haven't looked into the driver myself, I guess you might need to change the pin role to GPIO with GPIO API explicitly at run-time, e.g. gpio_direction_input() followed by gpio_get_value(), but I believe you should have already done that good enough as always :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Emulating level IRQs
On Mon, Aug 6, 2012 at 1:56 AM, Daniel Mack zon...@gmail.com wrote: On 05.08.2012 18:56, Haojian Zhuang wrote: On Mon, Aug 6, 2012 at 12:22 AM, Daniel Mack zon...@gmail.com wrote: On 24.07.2012 20:01, Daniel Mack wrote: On 23.07.2012 18:51, Dmitry Torokhov wrote: On Thu, Jul 19, 2012 at 05:36:12PM +0200, Daniel Mack wrote: Ok, finally I found some time. In general, the patch works fine. The only detail I had to amend was the irqflags, which were changed from IRQF_TRIGGER_RISING/IRQF_TRIGGER_FALLING to IRQF_TRIGGER_HIGH/IRQF_TRIGGER_LOW, which doesn't work as the PXA can't deal with level-based IRQs. Changing this back to RISING/FALLING makes the driver work again. Hmm, but that would mean we need to restore reading the data in open() to make sure we re-arm IRQ in case somebody touched the screen before it was opened by userspace... I had another look at this and don't really know what to do here. We definitely need level interrupts for this device as the interrupt line's level is the only that tells us when we can stop reading from the device. So it's not just the start condition that bites us here. I copied some people that might help find a solution. To summarize the problem: The EETI touchscreen is a device that asserts a GPIO line when it has events to deliver and waits for I2C commands to empty its buffers. When there are no more buffered events, it will de-assert the line. This device is connected to a PXA GPIO that is only able to deliver edge IRQs, and the old implemenation was to wait for an interrupt and then read data as long as the IRQ's corresponding GPIO was asserted. However, expecting that an IRQ is mappable to a GPIO is not something we should do, so the only clean solution is to teach the PXA GPIO controller level IRQs. So it boils down to the question: Is there any easy and generic way to emulate level irq on chips that don't support that natively? Otherwise, we would need some sort of generic irq_to_gpio() again, and the interrupt line the driver listens to must have support for that sort of mapping. Any opinion on this, anyone? Since you're using gpio as input, you need to call gpio_request() and set it as input direction. And you could also transfer the gpio number into touch driver via platform data. Is it OK for you? No, that's not the point. What we get via the i2c runtime data is an interrupt number. The driver is driven by that interrupt and doesn't poll on a GPIO line, which is how it should be. However, in order to know when to stop reading from the device, we need to monitor the GPIO line after the interrupt has arrived, and read as long as the line is asserted. Then we stop reading and wait for the next interrupt to arrive. Hence, what we need here is either a GPIO/IRQ controller that is able to handle level-IRQs (which the PXA can't do), or we need to have a generic way to map IRQ lines back to GPIOs. Of course, I could pass the GPIO in the platform data and the IRQ in the I2C data and leave it to the user of the driver to keep both values in sync, but I wanted to avoid that. I see no better way except to encode the GPIO line into the platform data. In order to solve the sync issue, I personally think mapping the GPIO to IRQ would be better here, and ignore the irq value from the I2C data. A forward mapping of gpio_to_irq() will be less problematic here, and for those platforms where gpio_to_irq() returns invalid, those platforms are probably not desirable for this chip. So my understanding, if it's correct, that we can treat the EETI chip as having two separate inputs: one IRQ line (for the event notification) and one GPIO line (for a condition where data are emptied), we could naturally have two numbers in the driver, but unfortunately they end up being in sync as they are physically one pin. And Daniel, I haven't looked into the driver myself, I guess you might need to change the pin role to GPIO with GPIO API explicitly at run-time, e.g. gpio_direction_input() followed by gpio_get_value(), but I believe you should have already done that good enough as always :-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATED v2][PATCH 0/6] regulator: voltage and current regulator framework
On Fri, Feb 22, 2008 at 12:26 AM, Liam Girdwood <[EMAIL PROTECTED]> wrote: > On Thu, 2008-02-21 at 08:41 +, Russell King - ARM Linux wrote: > > On Wed, Feb 20, 2008 at 05:08:46PM +, Liam Girdwood wrote: > > > This patch series provides a generic framework to allow device drivers > > > to control voltage and current regulators on SoC based devices (e.g. > > > phones, gps, media players). > > > > Note that I'm explicitly avoiding commenting on this as far as PXA3xx > > devices go, until we're further down the road with PM support on that > > SoC. It's not clear at present whether a generic PMIC framework will > > be suitable for this SoC since it's my understanding from Marvell that > > we need to talk to the PMIC from IRQs-off contexts. > > > > So don't take my silence as some sort of acceptance of this code; it > > isn't. > > I wasn't ;) > > It then might be worth adding this functionality at a later stage when > more can be said about PXA3xx PMIC support. We could always have a > version of the _set() functions that are designed to handle this case. > > In the mean time this works well on 3 other SoC CPUs. > > Liam > Liam, I have a rough peek into the git tree on opensource.wolfsonmicro.com, find another PMIC framework, and here instead is a regulator framework, looks like a simplified or dedicated one. What is their relationship? For those PMIC that covers additional features, like - usb vbus detection (or pull-up/pull-down) - audio codec - touch screen - battery monitor/ fuel gauge - battery charger - possible many others How do you plan to handle them? > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Cheers - eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATED v2][PATCH 0/6] regulator: voltage and current regulator framework
On Fri, Feb 22, 2008 at 12:26 AM, Liam Girdwood [EMAIL PROTECTED] wrote: On Thu, 2008-02-21 at 08:41 +, Russell King - ARM Linux wrote: On Wed, Feb 20, 2008 at 05:08:46PM +, Liam Girdwood wrote: This patch series provides a generic framework to allow device drivers to control voltage and current regulators on SoC based devices (e.g. phones, gps, media players). Note that I'm explicitly avoiding commenting on this as far as PXA3xx devices go, until we're further down the road with PM support on that SoC. It's not clear at present whether a generic PMIC framework will be suitable for this SoC since it's my understanding from Marvell that we need to talk to the PMIC from IRQs-off contexts. So don't take my silence as some sort of acceptance of this code; it isn't. I wasn't ;) It then might be worth adding this functionality at a later stage when more can be said about PXA3xx PMIC support. We could always have a version of the _set() functions that are designed to handle this case. In the mean time this works well on 3 other SoC CPUs. Liam Liam, I have a rough peek into the git tree on opensource.wolfsonmicro.com, find another PMIC framework, and here instead is a regulator framework, looks like a simplified or dedicated one. What is their relationship? For those PMIC that covers additional features, like - usb vbus detection (or pull-up/pull-down) - audio codec - touch screen - battery monitor/ fuel gauge - battery charger - possible many others How do you plan to handle them? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Cheers - eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [spi-devel-general] SPI related Kconfig warning
On Jan 31, 2008 3:21 PM, David Brownell <[EMAIL PROTECTED]> wrote: > On Wednesday 30 January 2008, Kumar Gala wrote: > > Was wondering if anyone was looking at the cause of this warning in > > top of linus's tree (8af03e782cae1e0a0f530ddd22301cdd12cf9dc0) > > > > drivers/spi/Kconfig:156:warning: 'select' used by config symbol > > 'SPI_PXA2XX' refers to undefined symbol 'PXA_SSP' > > > > I was doing a build of a ppc kernel. > > Happens on x86, AVR32, and non-PXA ARM too. Came from some PXA cleanup > patches. Eric, didn't you have a patch for this? > Nope. If moving the symbol PXA_SSP to the "depends on" list, this option will remain invisible if a careless user does not select PXA_SSP. Yet I'm not sure this is the way to go or mandatory by the kconfig rules. > (Of course I *still* don't understand why kconfig bothers to look > at reverse dependencies whose "forward" ones can never be satisfied. > If it stopped looking at those, lots of similar problems would vanish.) > > - Dave > -- Cheers - eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [spi-devel-general] SPI related Kconfig warning
On Jan 31, 2008 3:21 PM, David Brownell [EMAIL PROTECTED] wrote: On Wednesday 30 January 2008, Kumar Gala wrote: Was wondering if anyone was looking at the cause of this warning in top of linus's tree (8af03e782cae1e0a0f530ddd22301cdd12cf9dc0) drivers/spi/Kconfig:156:warning: 'select' used by config symbol 'SPI_PXA2XX' refers to undefined symbol 'PXA_SSP' I was doing a build of a ppc kernel. Happens on x86, AVR32, and non-PXA ARM too. Came from some PXA cleanup patches. Eric, didn't you have a patch for this? Nope. If moving the symbol PXA_SSP to the depends on list, this option will remain invisible if a careless user does not select PXA_SSP. Yet I'm not sure this is the way to go or mandatory by the kconfig rules. (Of course I *still* don't understand why kconfig bothers to look at reverse dependencies whose forward ones can never be satisfied. If it stopped looking at those, lots of similar problems would vanish.) - Dave -- Cheers - eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc5-mm 2/3] gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander
> > From: eric miao <[EMAIL PROTECTED]>
> >
> > This patch adds the generic IRQ support for the PCA9539 on-chip GPIOs.
>
> This one bothers me a bit on some technical grounds. One problem is
> that these chips are not designed for reliable IRQ management, so no
> matter what a driver does it can't deliver that. The other is with
> respect to what this code does.
>
>
> As background, here's what the TI docs say about IRQ support on this
> chip. In this area the pca953x parts closely resemble pcf857x ones,
> which I've looked at. I can say that I haven't (yet?) happened
> across boards that use the IRQ mechanism on those '857x parts ...
>
> | Interrupt (INT) Output
> |
> | An interrupt is generated by any rising or falling edge of the port
> | inputs in the input mode.
>
> That's an issue. Your code is trying to emulate all three edge trigger
> modes instead of just "both edges". I've come to believe such emulation
> is not a good thing, since it necessarily loses in some cases.
>
>
> | After time, T(iv), the signal INT is valid.
> | Resetting the interrupt circuit is achieved when data on the port is
> | changed to the original setting,
>
> Another issue. The IRQ will effectively clear by itself, leaving
> no record of exactly what triggered the IRQ.
>
> So IRQs on this chip are problematic at the hardware level, except
> as a lossy "something changed" notification to help avoid polling
> the chip for the current status of input pins.
>
>
> |data is read from the port that
> | generated the interrupt, or in a Stop event.
>
> Another issue. IRQ pulses can be arbitrarily short -- maybe too short
> to register at the host, given glitch removal circuitry! -- when a
> host is performing I/O to the chip while the signal is being raised.
>
>
> | Resetting occurs in the
> | read mode at the acknowledge (ACK) bit or not acknowledge (NACK) bit
> | after the falling edge of the SCL signal. In a Stop event, INT is cleared
> | after the rising edge of SDA. Interrupts that occur during the ACK or
> | NACK clock pulse can be lost (or be very short) due to the resetting
> | of the interrupt during this pulse. Each change of the I/Os after
> | resetting is detected and is transmitted as INT.
> |
> | Reading from or writing to another device does not affect the interrupt
> | circuit, and a pin configured as an output cannot cause an interrupt.
> | Changing an I/O from an output to an input may cause a false interrupt
> | to occur if the state of the pin does not match the contents of the
> | Input Port register. Because each 8-bit port is read independently, the
> | interrupt caused by port 0 is not cleared by a read of port 1, or vice
> versa.
> |
> | INT has an open-drain structure and requires a pullup resistor to VCC.
>
> Now, there *are* I2C GPIO expanders that have non-lossy IRQ support,
> but these '857x and '953x parts don't seem to be in that category.
>
Indeed, the chip does not provide reliable enough IRQ support, so it is
designed to cope with slow signals on our system, where the code below
works OK most of the time, but this is risky.
>
> > ---
> > drivers/gpio/Kconfig | 11 +++-
> > drivers/gpio/pca9539.c | 185
> >
> > 2 files changed, 195 insertions(+), 1 deletions(-)
> >
> > ...
> >
> > --- a/drivers/gpio/pca9539.c
> > +++ b/drivers/gpio/pca9539.c
>
> As to what this code does:
>
>
> > @@ -155,6 +174,158 @@ static int pca9539_init_gpio(struct pca9539_chip
> > *chip)
> > return gpiochip_add(gc);
> > }
> >
> > +#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
> > +/* FIXME: change to schedule_delayed_work() here if reading out of
> > + * registers does not reflect the actual pin levels
> > + */
>
> Docs say reading the input registers does reflect current signal
> levels -- no IRQ latches involved. So that FIXME should go.
>
Docs don't always tell the truth, especially when the chip is connected to
different possible signals, this issue is really observed several times,
though not very frequently. I can remove this til really necessary.
>
> > +
> > +static void pca9539_irq_work(struct work_struct *work)
> > +{
> > + struct pca9539_chip *chip;
> > + uint16_t input, mask, rising, falling;
> > + int ret, i;
> > +
> > + chip = container_of(work, struct pca9539_chip, irq_work);
> > +
> > + ret = pca9539_read_reg(chip, PCA9539_INPUT, );
> > + if (ret < 0)
> > + re
Re: [PATCH 2.6.24-rc5-mm 2/3] gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander
From: eric miao [EMAIL PROTECTED]
This patch adds the generic IRQ support for the PCA9539 on-chip GPIOs.
This one bothers me a bit on some technical grounds. One problem is
that these chips are not designed for reliable IRQ management, so no
matter what a driver does it can't deliver that. The other is with
respect to what this code does.
As background, here's what the TI docs say about IRQ support on this
chip. In this area the pca953x parts closely resemble pcf857x ones,
which I've looked at. I can say that I haven't (yet?) happened
across boards that use the IRQ mechanism on those '857x parts ...
| Interrupt (INT) Output
|
| An interrupt is generated by any rising or falling edge of the port
| inputs in the input mode.
That's an issue. Your code is trying to emulate all three edge trigger
modes instead of just both edges. I've come to believe such emulation
is not a good thing, since it necessarily loses in some cases.
| After time, T(iv), the signal INT is valid.
| Resetting the interrupt circuit is achieved when data on the port is
| changed to the original setting,
Another issue. The IRQ will effectively clear by itself, leaving
no record of exactly what triggered the IRQ.
So IRQs on this chip are problematic at the hardware level, except
as a lossy something changed notification to help avoid polling
the chip for the current status of input pins.
|data is read from the port that
| generated the interrupt, or in a Stop event.
Another issue. IRQ pulses can be arbitrarily short -- maybe too short
to register at the host, given glitch removal circuitry! -- when a
host is performing I/O to the chip while the signal is being raised.
| Resetting occurs in the
| read mode at the acknowledge (ACK) bit or not acknowledge (NACK) bit
| after the falling edge of the SCL signal. In a Stop event, INT is cleared
| after the rising edge of SDA. Interrupts that occur during the ACK or
| NACK clock pulse can be lost (or be very short) due to the resetting
| of the interrupt during this pulse. Each change of the I/Os after
| resetting is detected and is transmitted as INT.
|
| Reading from or writing to another device does not affect the interrupt
| circuit, and a pin configured as an output cannot cause an interrupt.
| Changing an I/O from an output to an input may cause a false interrupt
| to occur if the state of the pin does not match the contents of the
| Input Port register. Because each 8-bit port is read independently, the
| interrupt caused by port 0 is not cleared by a read of port 1, or vice
versa.
|
| INT has an open-drain structure and requires a pullup resistor to VCC.
Now, there *are* I2C GPIO expanders that have non-lossy IRQ support,
but these '857x and '953x parts don't seem to be in that category.
Indeed, the chip does not provide reliable enough IRQ support, so it is
designed to cope with slow signals on our system, where the code below
works OK most of the time, but this is risky.
---
drivers/gpio/Kconfig | 11 +++-
drivers/gpio/pca9539.c | 185
2 files changed, 195 insertions(+), 1 deletions(-)
...
--- a/drivers/gpio/pca9539.c
+++ b/drivers/gpio/pca9539.c
As to what this code does:
@@ -155,6 +174,158 @@ static int pca9539_init_gpio(struct pca9539_chip
*chip)
return gpiochip_add(gc);
}
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+/* FIXME: change to schedule_delayed_work() here if reading out of
+ * registers does not reflect the actual pin levels
+ */
Docs say reading the input registers does reflect current signal
levels -- no IRQ latches involved. So that FIXME should go.
Docs don't always tell the truth, especially when the chip is connected to
different possible signals, this issue is really observed several times,
though not very frequently. I can remove this til really necessary.
+
+static void pca9539_irq_work(struct work_struct *work)
+{
+ struct pca9539_chip *chip;
+ uint16_t input, mask, rising, falling;
+ int ret, i;
+
+ chip = container_of(work, struct pca9539_chip, irq_work);
+
+ ret = pca9539_read_reg(chip, PCA9539_INPUT, input);
+ if (ret 0)
+ return;
+
+ mask = (input ^ chip-last_input) chip-irq_mask;
+ rising = (input mask) chip-irq_rising_edge;
+ falling = (~input mask) chip-irq_falling_edge;
As noted above, this stuff is all lossy. You won't be able to
issue some IRQs that should be issued.
Yes, and the work_queue schedule latency will make this worse, a level
change may have already gone and INT is cleared, while the code here
won't detect this.
+
+ irq_enter();
I thought irq_enter/irq_exit were intended to bracket hardirq
contexts? This isn't a hardirq context... it's a task.
However, I currently
Re: [PATCH 2.6.24-rc5-mm 3/3] gpiolib: obsolete drivers/i2c/chips/pca9539.c
On Dec 19, 2007 5:01 PM, Jean Delvare <[EMAIL PROTECTED]> wrote: > Hi Eric, > > > On Wed, 19 Dec 2007 16:45:00 +0800, eric miao wrote: > > Updated as follows, the driver name is left unchanged, while > > Kconfig and Documentation are modified so that > > 1. mark it as deprecated > > 2. exclusive selection of SENSOR_PCA9539 and GPIO_PCA9539 > > > > From c58dc1119355dc94d80763aef9d9bc999abda6df Mon Sep 17 00:00:00 2001 > > From: eric miao <[EMAIL PROTECTED]> > > Date: Wed, 19 Dec 2007 16:40:04 +0800 > > Subject: [PATCH] gpiolib: mark drivers/i2c/chips/pca9539.c as deprecated > > > > use drivers/gpio/pca9539.c instead. > > > > Signed-off-by: eric miao <[EMAIL PROTECTED]> > > Acked-by: Ben Gardner <[EMAIL PROTECTED]> > > --- > > Documentation/i2c/chips/pca9539 |3 +++ > > drivers/i2c/chips/Kconfig |7 +-- > > 2 files changed, 8 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/i2c/chips/pca9539 > > b/Documentation/i2c/chips/pca9539 > > index c4fce6a..1d81c53 100644 > > --- a/Documentation/i2c/chips/pca9539 > > +++ b/Documentation/i2c/chips/pca9539 > > @@ -1,6 +1,9 @@ > > Kernel driver pca9539 > > = > > > > +NOTE: this driver is deprecated and will be dropped soon, use > > +drivers/gpio/pca9539.c instead. > > + > > Supported chips: > >* Philips PCA9539 > > Prefix: 'pca9539' > > diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig > > index 2e1c24f..54fd302 100644 > > --- a/drivers/i2c/chips/Kconfig > > +++ b/drivers/i2c/chips/Kconfig > > @@ -66,8 +66,8 @@ config SENSORS_PCF8574 > > hardware. If unsure, say N. > > > > config SENSORS_PCA9539 > > - tristate "Philips PCA9539 16-bit I/O port" > > - depends on EXPERIMENTAL > > + tristate "Philips PCA9539 16-bit I/O port (DEPRECATED)" > > + depends on EXPERIMENTAL && !GPIO_PCA9539 > > If I remember correctly how the Kconfig language works, this will allow > for both drivers to be built as modules at the same time. Given that > they have the same name, which one will be loaded by "modprobe > pca9539"? I think that you should instead express the dependency as > "GPIO_PCA9539=n". > Indeed, fixed. > > help > > If you say yes here you get support for the Philips PCA9539 > > 16-bit I/O port. > > @@ -75,6 +75,9 @@ config SENSORS_PCA9539 > > This driver can also be built as a module. If so, the module > > will be called pca9539. > > > > + This driver is deprecated and will be dropped soon. Use > > + drivers/gpio/pca9539.c instead. > > + > > config SENSORS_PCF8591 > > tristate "Philips PCF8591" > > depends on EXPERIMENTAL > > Other than that I'm fine with this approach, note however that it will > have to go through David rather than me, as I can't merge this before > the new pca9539 driver. > > Thanks, > -- > Jean Delvare > OK, I'll then add your Acked-by :-). Updated as follows: >8 - >From 2bd2deff2f417543f0f17ec1aa32d421cc15cf23 Mon Sep 17 00:00:00 2001 From: eric miao <[EMAIL PROTECTED]> Date: Wed, 19 Dec 2007 16:40:04 +0800 Subject: [PATCH] gpiolib: mark drivers/i2c/chips/pca9539.c as deprecated use drivers/gpio/pca9539.c instead. Signed-off-by: eric miao <[EMAIL PROTECTED]> Acked-by: Ben Gardner <[EMAIL PROTECTED]> Acked-by: Jean Delvare <[EMAIL PROTECTED]> --- Documentation/i2c/chips/pca9539 |3 +++ drivers/i2c/chips/Kconfig |7 +-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/Documentation/i2c/chips/pca9539 b/Documentation/i2c/chips/pca9539 index c4fce6a..1d81c53 100644 --- a/Documentation/i2c/chips/pca9539 +++ b/Documentation/i2c/chips/pca9539 @@ -1,6 +1,9 @@ Kernel driver pca9539 = +NOTE: this driver is deprecated and will be dropped soon, use +drivers/gpio/pca9539.c instead. + Supported chips: * Philips PCA9539 Prefix: 'pca9539' diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig index 2e1c24f..7a216f8 100644 --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -66,8 +66,8 @@ config SENSORS_PCF8574 hardware. If unsure, say N. config SENSORS_PCA9539 - tristate "Philips PCA9539 16-bit I/O port" - depends on EXPERIMENTAL + tristate "Philips PCA9539 16-bit I/O port (DEPRECATED)" + depends on EXPERIMENTAL && GPIO_PCA9539 = "n" help If you say yes here you get support for the Phili
Re: [PATCH 2.6.24-rc5-mm 3/3] gpiolib: obsolete drivers/i2c/chips/pca9539.c
Updated as follows, the driver name is left unchanged, while Kconfig and Documentation are modified so that 1. mark it as deprecated 2. exclusive selection of SENSOR_PCA9539 and GPIO_PCA9539 >From c58dc1119355dc94d80763aef9d9bc999abda6df Mon Sep 17 00:00:00 2001 From: eric miao <[EMAIL PROTECTED]> Date: Wed, 19 Dec 2007 16:40:04 +0800 Subject: [PATCH] gpiolib: mark drivers/i2c/chips/pca9539.c as deprecated use drivers/gpio/pca9539.c instead. Signed-off-by: eric miao <[EMAIL PROTECTED]> Acked-by: Ben Gardner <[EMAIL PROTECTED]> --- Documentation/i2c/chips/pca9539 |3 +++ drivers/i2c/chips/Kconfig |7 +-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/Documentation/i2c/chips/pca9539 b/Documentation/i2c/chips/pca9539 index c4fce6a..1d81c53 100644 --- a/Documentation/i2c/chips/pca9539 +++ b/Documentation/i2c/chips/pca9539 @@ -1,6 +1,9 @@ Kernel driver pca9539 = +NOTE: this driver is deprecated and will be dropped soon, use +drivers/gpio/pca9539.c instead. + Supported chips: * Philips PCA9539 Prefix: 'pca9539' diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig index 2e1c24f..54fd302 100644 --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -66,8 +66,8 @@ config SENSORS_PCF8574 hardware. If unsure, say N. config SENSORS_PCA9539 - tristate "Philips PCA9539 16-bit I/O port" - depends on EXPERIMENTAL + tristate "Philips PCA9539 16-bit I/O port (DEPRECATED)" + depends on EXPERIMENTAL && !GPIO_PCA9539 help If you say yes here you get support for the Philips PCA9539 16-bit I/O port. @@ -75,6 +75,9 @@ config SENSORS_PCA9539 This driver can also be built as a module. If so, the module will be called pca9539. + This driver is deprecated and will be dropped soon. Use + drivers/gpio/pca9539.c instead. + config SENSORS_PCF8591 tristate "Philips PCF8591" depends on EXPERIMENTAL -- 1.5.2.5.GIT Cheers - eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc5-mm 3/3] gpiolib: obsolete drivers/i2c/chips/pca9539.c
Updated as follows, the driver name is left unchanged, while Kconfig and Documentation are modified so that 1. mark it as deprecated 2. exclusive selection of SENSOR_PCA9539 and GPIO_PCA9539 From c58dc1119355dc94d80763aef9d9bc999abda6df Mon Sep 17 00:00:00 2001 From: eric miao [EMAIL PROTECTED] Date: Wed, 19 Dec 2007 16:40:04 +0800 Subject: [PATCH] gpiolib: mark drivers/i2c/chips/pca9539.c as deprecated use drivers/gpio/pca9539.c instead. Signed-off-by: eric miao [EMAIL PROTECTED] Acked-by: Ben Gardner [EMAIL PROTECTED] --- Documentation/i2c/chips/pca9539 |3 +++ drivers/i2c/chips/Kconfig |7 +-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/Documentation/i2c/chips/pca9539 b/Documentation/i2c/chips/pca9539 index c4fce6a..1d81c53 100644 --- a/Documentation/i2c/chips/pca9539 +++ b/Documentation/i2c/chips/pca9539 @@ -1,6 +1,9 @@ Kernel driver pca9539 = +NOTE: this driver is deprecated and will be dropped soon, use +drivers/gpio/pca9539.c instead. + Supported chips: * Philips PCA9539 Prefix: 'pca9539' diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig index 2e1c24f..54fd302 100644 --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -66,8 +66,8 @@ config SENSORS_PCF8574 hardware. If unsure, say N. config SENSORS_PCA9539 - tristate Philips PCA9539 16-bit I/O port - depends on EXPERIMENTAL + tristate Philips PCA9539 16-bit I/O port (DEPRECATED) + depends on EXPERIMENTAL !GPIO_PCA9539 help If you say yes here you get support for the Philips PCA9539 16-bit I/O port. @@ -75,6 +75,9 @@ config SENSORS_PCA9539 This driver can also be built as a module. If so, the module will be called pca9539. + This driver is deprecated and will be dropped soon. Use + drivers/gpio/pca9539.c instead. + config SENSORS_PCF8591 tristate Philips PCF8591 depends on EXPERIMENTAL -- 1.5.2.5.GIT Cheers - eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc5-mm 3/3] gpiolib: obsolete drivers/i2c/chips/pca9539.c
On Dec 19, 2007 5:01 PM, Jean Delvare [EMAIL PROTECTED] wrote: Hi Eric, On Wed, 19 Dec 2007 16:45:00 +0800, eric miao wrote: Updated as follows, the driver name is left unchanged, while Kconfig and Documentation are modified so that 1. mark it as deprecated 2. exclusive selection of SENSOR_PCA9539 and GPIO_PCA9539 From c58dc1119355dc94d80763aef9d9bc999abda6df Mon Sep 17 00:00:00 2001 From: eric miao [EMAIL PROTECTED] Date: Wed, 19 Dec 2007 16:40:04 +0800 Subject: [PATCH] gpiolib: mark drivers/i2c/chips/pca9539.c as deprecated use drivers/gpio/pca9539.c instead. Signed-off-by: eric miao [EMAIL PROTECTED] Acked-by: Ben Gardner [EMAIL PROTECTED] --- Documentation/i2c/chips/pca9539 |3 +++ drivers/i2c/chips/Kconfig |7 +-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/Documentation/i2c/chips/pca9539 b/Documentation/i2c/chips/pca9539 index c4fce6a..1d81c53 100644 --- a/Documentation/i2c/chips/pca9539 +++ b/Documentation/i2c/chips/pca9539 @@ -1,6 +1,9 @@ Kernel driver pca9539 = +NOTE: this driver is deprecated and will be dropped soon, use +drivers/gpio/pca9539.c instead. + Supported chips: * Philips PCA9539 Prefix: 'pca9539' diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig index 2e1c24f..54fd302 100644 --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -66,8 +66,8 @@ config SENSORS_PCF8574 hardware. If unsure, say N. config SENSORS_PCA9539 - tristate Philips PCA9539 16-bit I/O port - depends on EXPERIMENTAL + tristate Philips PCA9539 16-bit I/O port (DEPRECATED) + depends on EXPERIMENTAL !GPIO_PCA9539 If I remember correctly how the Kconfig language works, this will allow for both drivers to be built as modules at the same time. Given that they have the same name, which one will be loaded by modprobe pca9539? I think that you should instead express the dependency as GPIO_PCA9539=n. Indeed, fixed. help If you say yes here you get support for the Philips PCA9539 16-bit I/O port. @@ -75,6 +75,9 @@ config SENSORS_PCA9539 This driver can also be built as a module. If so, the module will be called pca9539. + This driver is deprecated and will be dropped soon. Use + drivers/gpio/pca9539.c instead. + config SENSORS_PCF8591 tristate Philips PCF8591 depends on EXPERIMENTAL Other than that I'm fine with this approach, note however that it will have to go through David rather than me, as I can't merge this before the new pca9539 driver. Thanks, -- Jean Delvare OK, I'll then add your Acked-by :-). Updated as follows: 8 - From 2bd2deff2f417543f0f17ec1aa32d421cc15cf23 Mon Sep 17 00:00:00 2001 From: eric miao [EMAIL PROTECTED] Date: Wed, 19 Dec 2007 16:40:04 +0800 Subject: [PATCH] gpiolib: mark drivers/i2c/chips/pca9539.c as deprecated use drivers/gpio/pca9539.c instead. Signed-off-by: eric miao [EMAIL PROTECTED] Acked-by: Ben Gardner [EMAIL PROTECTED] Acked-by: Jean Delvare [EMAIL PROTECTED] --- Documentation/i2c/chips/pca9539 |3 +++ drivers/i2c/chips/Kconfig |7 +-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/Documentation/i2c/chips/pca9539 b/Documentation/i2c/chips/pca9539 index c4fce6a..1d81c53 100644 --- a/Documentation/i2c/chips/pca9539 +++ b/Documentation/i2c/chips/pca9539 @@ -1,6 +1,9 @@ Kernel driver pca9539 = +NOTE: this driver is deprecated and will be dropped soon, use +drivers/gpio/pca9539.c instead. + Supported chips: * Philips PCA9539 Prefix: 'pca9539' diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig index 2e1c24f..7a216f8 100644 --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -66,8 +66,8 @@ config SENSORS_PCF8574 hardware. If unsure, say N. config SENSORS_PCA9539 - tristate Philips PCA9539 16-bit I/O port - depends on EXPERIMENTAL + tristate Philips PCA9539 16-bit I/O port (DEPRECATED) + depends on EXPERIMENTAL GPIO_PCA9539 = n help If you say yes here you get support for the Philips PCA9539 16-bit I/O port. @@ -75,6 +75,9 @@ config SENSORS_PCA9539 This driver can also be built as a module. If so, the module will be called pca9539. + This driver is deprecated and will be dropped soon. Use + drivers/gpio/pca9539.c instead. + config SENSORS_PCF8591 tristate Philips PCF8591 depends on EXPERIMENTAL -- 1.5.2.5.GIT -- Cheers - eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc5-mm 3/3] gpiolib: obsolete drivers/i2c/chips/pca9539.c
Well, I guess it would be a smooth path if we rename the drivers/i2c/chips/pca9539.c since that's old style I2C driver, which means the driver name is not so useful external so the impact is actually minimum. On Dec 18, 2007 4:29 AM, Jean Delvare <[EMAIL PROTECTED]> wrote: > Hi David, > > > On Mon, 17 Dec 2007 10:09:53 -0800, David Brownell wrote: > > > Date: Mon, 17 Dec 2007 14:33:27 +0800 > > > From: "eric miao" <[EMAIL PROTECTED]> > > > > > > for the following reasons: > > > > > > 1. there is currently no known users of this driver > > > > > > 2. the functionality of this driver is well supported with the recent > > >proposed drivers/gpio/pca9539.c, using GPIO_LIB > > > > > > Signed-off-by: eric miao <[EMAIL PROTECTED]> > > > Acked-by: Ben Gardner <[EMAIL PROTECTED]> > > > --- > > > Documentation/i2c/chips/pca9539 | 47 > > > drivers/i2c/chips/Kconfig | 10 -- > > > drivers/i2c/chips/Makefile |1 - > > > drivers/i2c/chips/pca9539.c | 196 -- > > > > Jean, do you sign off on this? In any case I think this should > > be going through your I2C patches. > > > > I'd be a trifle uneasy just deleting this, because it's possible > > there are *unknown* users ... and also because nobody's yet done > > a userspace interface to the gpiolib infrastructure. (It seems > > to be the usual case of nobody wanting such a thing quite enough > > to write the code.) > > > > I'd be more comfortable marking it as obsolete and flagging it > > for removal a release or two after Eric's new version merges ... > > though maybe that's just paranoia. > > I'm fine with this and I agree that it would be safer, however please > note that both drivers are mutually exclusive because they have the > same name, meaning that deprecating the old driver is not enough, you > also need Kconfig magic to make sure that both drivers aren't built at > the same time. Or alternatively the old driver could be renamed... I > don't really care myself, I'll take whatever patch you or Eric submit. > > -- > Jean Delvare > -- Cheers - eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc5-mm 3/3] gpiolib: obsolete drivers/i2c/chips/pca9539.c
Well, I guess it would be a smooth path if we rename the drivers/i2c/chips/pca9539.c since that's old style I2C driver, which means the driver name is not so useful external so the impact is actually minimum. On Dec 18, 2007 4:29 AM, Jean Delvare [EMAIL PROTECTED] wrote: Hi David, On Mon, 17 Dec 2007 10:09:53 -0800, David Brownell wrote: Date: Mon, 17 Dec 2007 14:33:27 +0800 From: eric miao [EMAIL PROTECTED] for the following reasons: 1. there is currently no known users of this driver 2. the functionality of this driver is well supported with the recent proposed drivers/gpio/pca9539.c, using GPIO_LIB Signed-off-by: eric miao [EMAIL PROTECTED] Acked-by: Ben Gardner [EMAIL PROTECTED] --- Documentation/i2c/chips/pca9539 | 47 drivers/i2c/chips/Kconfig | 10 -- drivers/i2c/chips/Makefile |1 - drivers/i2c/chips/pca9539.c | 196 -- Jean, do you sign off on this? In any case I think this should be going through your I2C patches. I'd be a trifle uneasy just deleting this, because it's possible there are *unknown* users ... and also because nobody's yet done a userspace interface to the gpiolib infrastructure. (It seems to be the usual case of nobody wanting such a thing quite enough to write the code.) I'd be more comfortable marking it as obsolete and flagging it for removal a release or two after Eric's new version merges ... though maybe that's just paranoia. I'm fine with this and I agree that it would be safer, however please note that both drivers are mutually exclusive because they have the same name, meaning that deprecating the old driver is not enough, you also need Kconfig magic to make sure that both drivers aren't built at the same time. Or alternatively the old driver could be renamed... I don't really care myself, I'll take whatever patch you or Eric submit. -- Jean Delvare -- Cheers - eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc5-mm 3/3] gpiolib: obsolete drivers/i2c/chips/pca9539.c
[ Updated according to Jean's suggestion, thanks ]
>From 5b4d907da17d57ec168643ebd847278e8d7267f9 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Sat, 15 Dec 2007 12:07:26 +0800
Subject: [PATCH] gpiolib: obsolete drivers/i2c/chips/pca9539.c and related files
for the following reasons:
1. there is currently no known users of this driver
2. the functionality of this driver is well supported with the recent
proposed drivers/gpio/pca9539.c, using GPIO_LIB
Signed-off-by: eric miao <[EMAIL PROTECTED]>
Acked-by: Ben Gardner <[EMAIL PROTECTED]>
---
Documentation/i2c/chips/pca9539 | 47 -
drivers/i2c/chips/Kconfig | 10 --
drivers/i2c/chips/Makefile |1 -
drivers/i2c/chips/pca9539.c | 196 ---
4 files changed, 0 insertions(+), 254 deletions(-)
delete mode 100644 Documentation/i2c/chips/pca9539
delete mode 100644 drivers/i2c/chips/pca9539.c
diff --git a/Documentation/i2c/chips/pca9539 b/Documentation/i2c/chips/pca9539
deleted file mode 100644
index c4fce6a..000
--- a/Documentation/i2c/chips/pca9539
+++ /dev/null
@@ -1,47 +0,0 @@
-Kernel driver pca9539
-=
-
-Supported chips:
- * Philips PCA9539
-Prefix: 'pca9539'
-Addresses scanned: 0x74 - 0x77
-Datasheet:
-http://www.semiconductors.philips.com/acrobat/datasheets/PCA9539_2.pdf
-
-Author: Ben Gardner <[EMAIL PROTECTED]>
-
-
-Description
-
-The Philips PCA9539 is a 16 bit low power I/O device.
-All 16 lines can be individually configured as an input or output.
-The input sense can also be inverted.
-The 16 lines are split between two bytes.
-
-
-Sysfs entries
--
-
-Each is a byte that maps to the 8 I/O bits.
-A '0' suffix is for bits 0-7, while '1' is for bits 8-15.
-
-input[01] - read the current value
-output[01]- sets the output value
-direction[01] - direction of each bit: 1=input, 0=output
-invert[01]- toggle the input bit sense
-
-input reads the actual state of the line and is always available.
-The direction defaults to input for all channels.
-
-
-General Remarks
-
-Note that each output, direction, and invert entry controls 8 lines.
-You should use the read, modify, write sequence.
-For example. to set output bit 0 of 1.
- val=$(cat output0)
- val=$(( $val | 1 ))
- echo $val > output0
-
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 2e1c24f..a676f57 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -65,16 +65,6 @@ config SENSORS_PCF8574
These devices are hard to detect and rarely found on mainstream
hardware. If unsure, say N.
-config SENSORS_PCA9539
- tristate "Philips PCA9539 16-bit I/O port"
- depends on EXPERIMENTAL
- help
- If you say yes here you get support for the Philips PCA9539
- 16-bit I/O port.
-
- This driver can also be built as a module. If so, the module
- will be called pca9539.
-
config SENSORS_PCF8591
tristate "Philips PCF8591"
depends on EXPERIMENTAL
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index ca924e1..bc9e9ca 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -8,7 +8,6 @@ obj-$(CONFIG_DS1682)+= ds1682.o
obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o
obj-$(CONFIG_SENSORS_MAX6875) += max6875.o
obj-$(CONFIG_SENSORS_M41T00) += m41t00.o
-obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o
obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
diff --git a/drivers/i2c/chips/pca9539.c b/drivers/i2c/chips/pca9539.c
deleted file mode 100644
index f43c4e7..000
--- a/drivers/i2c/chips/pca9539.c
+++ /dev/null
@@ -1,196 +0,0 @@
-/*
-pca9539.c - 16-bit I/O port with interrupt and reset
-
-Copyright (C) 2005 Ben Gardner <[EMAIL PROTECTED]>
-
-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.
-*/
-
-#include
-#include
-#include
-#include
-#include
-
-/* Addresses to scan */
-static unsigned short normal_i2c[] = {0x74, 0x75, 0x76, 0x77, I2C_CLIENT_END};
-
-/* Insmod parameters */
-I2C_CLIENT_INSMOD_1(pca9539);
-
-enum pca9539_cmd
-{
- PCA9539_INPUT_0 = 0,
- PCA9539_INPUT_1 = 1,
- PCA9539_OUTPUT_0= 2,
- PCA9539_OUTPUT_1= 3,
- PCA9539_INVERT_0= 4,
- PCA9539_INVERT_1= 5,
- PCA9539_DIRECTION_0 = 6,
- PCA9539_DIRECTION_1 = 7,
-};
-
-static int pca9539_attach_adapter(struct i2c_adapter *adapter);
-static int pca9539_detect(struct i2c_adapter *adapter, int address, int kind);
-static int pca9539_detach_client(struct i2c_client *client);
-
-/* Th
Re: [PATCH 2.6.24-rc5-mm 2/3] gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander
[updated according to David's suggestion to handle the error
of I2C transfer]
>From c9b78718488dadc702f40789bd532d1f1765d76e Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:24:36 +0800
Subject: [PATCH] gpiolib: add Generic IRQ support for 16-bit PCA9539
GPIO expander
This patch adds the generic IRQ support for the PCA9539 on-chip GPIOs.
Note: due to the inaccessibility of the generic IRQ code within modules,
this support is only available if the driver is built-in.
Signed-off-by: eric miao <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig | 11 +++-
drivers/gpio/pca9539.c | 185
2 files changed, 195 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 4b54f60..a4f89a6 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -17,7 +17,16 @@ config GPIO_PCA9539
parts are made by NXP and TI.
This driver can also be built as a module. If so, the module
- will be called pca9539.
+ will be called pca9539. Note: the Generic IRQ support for the
+ chip will only be available if the driver is built-in
+
+config GPIO_PCA9539_GENERIC_IRQ
+ bool "Generic IRQ support for PCA9539"
+ depends on GPIO_PCA9539=y && GENERIC_HARDIRQS
+ help
+ Say yes here to support the Generic IRQ for the PCA9539 on-chip
+ GPIO lines. Only pin-changed IRQs (IRQ_TYPE_EDGE_BOTH) are
+ supported in hardware.
config GPIO_PCF857X
tristate "PCF857x, PCA857x, and PCA967x I2C GPIO expanders"
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
index fc8bee4..10f9549 100644
--- a/drivers/gpio/pca9539.c
+++ b/drivers/gpio/pca9539.c
@@ -14,6 +14,9 @@
#include
#include
+#include
+#include
+#include
#include
#include
@@ -33,6 +36,22 @@ struct pca9539_chip {
struct i2c_client *client;
struct gpio_chip gpio_chip;
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+ /*
+* Note: Generic IRQ is not accessible within module code, the IRQ
+* support will thus _only_ be available if the driver is built-in
+*/
+ int irq;/* IRQ for the chip itself */
+ int irq_start; /* starting IRQ for the on-chip GPIO lines */
+
+ uint16_t irq_mask;
+ uint16_t irq_falling_edge;
+ uint16_t irq_rising_edge;
+ uint16_t last_input;
+
+ struct irq_chip irq_chip;
+ struct work_struct irq_work;
+#endif
};
static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
@@ -155,6 +174,158 @@ static int pca9539_init_gpio(struct pca9539_chip *chip)
return gpiochip_add(gc);
}
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+/* FIXME: change to schedule_delayed_work() here if reading out of
+ * registers does not reflect the actual pin levels
+ */
+
+static void pca9539_irq_work(struct work_struct *work)
+{
+ struct pca9539_chip *chip;
+ uint16_t input, mask, rising, falling;
+ int ret, i;
+
+ chip = container_of(work, struct pca9539_chip, irq_work);
+
+ ret = pca9539_read_reg(chip, PCA9539_INPUT, );
+ if (ret < 0)
+ return;
+
+ mask = (input ^ chip->last_input) & chip->irq_mask;
+ rising = (input & mask) & chip->irq_rising_edge;
+ falling = (~input & mask) & chip->irq_falling_edge;
+
+ irq_enter();
+
+ for (i = 0; i < NR_PCA9539_GPIOS; i++) {
+ if ((rising | falling) & (1u << i)) {
+ int irq = chip->irq_start + i;
+ struct irq_desc *desc;
+
+ desc = irq_desc + irq;
+ desc_handle_irq(irq, desc);
+ }
+ }
+
+ irq_exit();
+
+ chip->last_input = input;
+}
+
+static void fastcall
+pca9539_irq_demux(unsigned int irq, struct irq_desc *desc)
+{
+ struct pca9539_chip *chip = desc->handler_data;
+
+ desc->chip->mask(chip->irq);
+ desc->chip->ack(chip->irq);
+ schedule_work(>irq_work);
+ desc->chip->unmask(chip->irq);
+}
+
+static void pca9539_irq_mask(unsigned int irq)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc->chip_data;
+
+ chip->irq_mask &= ~(1u << (irq - chip->irq_start));
+}
+
+static void pca9539_irq_unmask(unsigned int irq)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc->chip_data;
+
+ chip->irq_mask |= 1u << (irq - chip->irq_start);
+}
+
+static void pca9539_irq_ack(unsigned int irq)
+{
+ /* unfortunately, we have to provide an empty irq_chip.ack even
+* if we do nothing here, Generic IRQ will complain otherwise
+*/
+}
+
+static int pca9539_irq_set_type(unsigned int irq, unsigned in
Re: [PATCH 2.6.24-rc5-mm 1/3] gpiolib: basic support for 16-bit PCA9539 GPIO expander
[ forget about the previous patch, sorry for my carelessness not to
free the chip structure, below is the correct one ]
>From c4be69e8dad28dc75e80b393f9c60f740cca7047 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:19:12 +0800
Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander
1. use 16-bit register access to simplify the logic, cache OUTPUT
and DIRECTION registers for fast access
2. platform code is required to setup
a) the numbering of GPIO for PCA9539 (base and number)
c) pass "pca9539_platform_data" within "i2c_board_info"
Derived from drivers/i2c/chips/pca9539.c (which has no current known
users).
Signed-off-by: eric miao <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig| 10 ++
drivers/gpio/Makefile |1 +
drivers/gpio/pca9539.c | 260 +++
include/linux/i2c/pca9539.h | 18 +++
4 files changed, 289 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/pca9539.c
create mode 100644 include/linux/i2c/pca9539.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index dd9e697..4b54f60 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -9,6 +9,16 @@ menu "GPIO Expanders"
comment "I2C GPIO expanders:"
+config GPIO_PCA9539
+ tristate "PCA9539 16-bit I/O port"
+ depends on I2C
+ help
+ Say yes here to support the PCA9539 16-bit I/O port. These
+ parts are made by NXP and TI.
+
+ This driver can also be built as a module. If so, the module
+ will be called pca9539.
+
config GPIO_PCF857X
tristate "PCF857x, PCA857x, and PCA967x I2C GPIO expanders"
depends on I2C
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 575bb57..d14fc1e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -1,4 +1,5 @@
# gpio support: dedicated expander chips, etc
obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
+obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
new file mode 100644
index 000..fc8bee4
--- /dev/null
+++ b/drivers/gpio/pca9539.c
@@ -0,0 +1,260 @@
+/*
+ * pca9539.c - 16-bit I/O port with interrupt and reset
+ *
+ * Copyright (C) 2005 Ben Gardner <[EMAIL PROTECTED]>
+ * Copyright (C) 2007 Marvell International Ltd.
+ *
+ * Derived from drivers/i2c/chips/pca9539.c (which has no current known
+ * users).
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+#define NR_PCA9539_GPIOS 16
+
+#define PCA9539_INPUT 0
+#define PCA9539_OUTPUT 2
+#define PCA9539_INVERT 4
+#define PCA9539_DIRECTION 6
+
+struct pca9539_chip {
+ unsigned gpio_start;
+ uint16_t reg_output;
+ uint16_t reg_direction;
+
+ struct i2c_client *client;
+ struct gpio_chip gpio_chip;
+};
+
+static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
+{
+ return i2c_smbus_write_word_data(chip->client, reg, val);
+}
+
+static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t *val)
+{
+ int ret;
+
+ ret = i2c_smbus_read_word_data(chip->client, reg);
+ if (ret < 0) {
+ dev_err(>client->dev, "failed reading register\n");
+ return ret;
+ }
+
+ *val = (uint16_t)ret;
+ return 0;
+}
+
+static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ reg_val = chip->reg_direction | (1u << off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return -EIO;
+
+ chip->reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_direction_output(struct gpio_chip *gc,
+ unsigned off, int val)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ /* set output level */
+ if (val)
+ reg_val = chip->reg_output | (1u << off);
+ else
+ reg_val = chip->reg_output & ~(1u << off);
+
+ ret = pca9539_write_reg(chip, PCA9539_OUTPUT, reg_val);
+ if (ret)
+ return -EIO;
+
+ chip->reg_output = reg_val;
+
+ /* then direction */
+ reg_val = chip->reg_direction & ~(1u << off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ i
Re: [PATCH 2.6.24-rc5-mm 1/3] gpiolib: basic support for 16-bit PCA9539 GPIO expander
[ Yup, it's an issue, patch updated as below:]
>From 8de0246423cbbd0c6bb03a20baf61d360930c350 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:19:12 +0800
Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander
1. use 16-bit register access to simplify the logic, cache OUTPUT
and DIRECTION registers for fast access
2. platform code is required to setup
a) the numbering of GPIO for PCA9539 (base and number)
c) pass "pca9539_platform_data" within "i2c_board_info"
Derived from drivers/i2c/chips/pca9539.c (which has no current known
users).
Signed-off-by: eric miao <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig| 10 ++
drivers/gpio/Makefile |1 +
drivers/gpio/pca9539.c | 254 +++
include/linux/i2c/pca9539.h | 18 +++
4 files changed, 283 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/pca9539.c
create mode 100644 include/linux/i2c/pca9539.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index dd9e697..4b54f60 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -9,6 +9,16 @@ menu "GPIO Expanders"
comment "I2C GPIO expanders:"
+config GPIO_PCA9539
+ tristate "PCA9539 16-bit I/O port"
+ depends on I2C
+ help
+ Say yes here to support the PCA9539 16-bit I/O port. These
+ parts are made by NXP and TI.
+
+ This driver can also be built as a module. If so, the module
+ will be called pca9539.
+
config GPIO_PCF857X
tristate "PCF857x, PCA857x, and PCA967x I2C GPIO expanders"
depends on I2C
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 575bb57..d14fc1e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -1,4 +1,5 @@
# gpio support: dedicated expander chips, etc
obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
+obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
new file mode 100644
index 000..050a378
--- /dev/null
+++ b/drivers/gpio/pca9539.c
@@ -0,0 +1,254 @@
+/*
+ * pca9539.c - 16-bit I/O port with interrupt and reset
+ *
+ * Copyright (C) 2005 Ben Gardner <[EMAIL PROTECTED]>
+ * Copyright (C) 2007 Marvell International Ltd.
+ *
+ * Derived from drivers/i2c/chips/pca9539.c (which has no current known
+ * users).
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+#define NR_PCA9539_GPIOS 16
+
+#define PCA9539_INPUT 0
+#define PCA9539_OUTPUT 2
+#define PCA9539_INVERT 4
+#define PCA9539_DIRECTION 6
+
+struct pca9539_chip {
+ unsigned gpio_start;
+ uint16_t reg_output;
+ uint16_t reg_direction;
+
+ struct i2c_client *client;
+ struct gpio_chip gpio_chip;
+};
+
+static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
+{
+ return i2c_smbus_write_word_data(chip->client, reg, val);
+}
+
+static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t *val)
+{
+ int ret;
+
+ ret = i2c_smbus_read_word_data(chip->client, reg);
+ if (ret < 0) {
+ dev_err(>client->dev, "failed reading register\n");
+ return ret;
+ }
+
+ *val = (uint16_t)ret;
+ return 0;
+}
+
+static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ reg_val = chip->reg_direction | (1u << off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return -EIO;
+
+ chip->reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_direction_output(struct gpio_chip *gc,
+ unsigned off, int val)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ /* set output level */
+ if (val)
+ reg_val = chip->reg_output | (1u << off);
+ else
+ reg_val = chip->reg_output & ~(1u << off);
+
+ ret = pca9539_write_reg(chip, PCA9539_OUTPUT, reg_val);
+ if (ret)
+ return -EIO;
+
+ chip->reg_output = reg_val;
+
+ /* then direction */
+ reg_val = chip->reg_direction & ~(1u << off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return -EIO;
+
+ chip->reg_direction
Re: [PATCH 2.6.24-rc5-mm 1/3] gpiolib: basic support for 16-bit PCA9539 GPIO expander
[ Yup, it's an issue, patch updated as below:]
From 8de0246423cbbd0c6bb03a20baf61d360930c350 Mon Sep 17 00:00:00 2001
From: eric miao [EMAIL PROTECTED]
Date: Mon, 10 Dec 2007 17:19:12 +0800
Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander
1. use 16-bit register access to simplify the logic, cache OUTPUT
and DIRECTION registers for fast access
2. platform code is required to setup
a) the numbering of GPIO for PCA9539 (base and number)
c) pass pca9539_platform_data within i2c_board_info
Derived from drivers/i2c/chips/pca9539.c (which has no current known
users).
Signed-off-by: eric miao [EMAIL PROTECTED]
---
drivers/gpio/Kconfig| 10 ++
drivers/gpio/Makefile |1 +
drivers/gpio/pca9539.c | 254 +++
include/linux/i2c/pca9539.h | 18 +++
4 files changed, 283 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/pca9539.c
create mode 100644 include/linux/i2c/pca9539.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index dd9e697..4b54f60 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -9,6 +9,16 @@ menu GPIO Expanders
comment I2C GPIO expanders:
+config GPIO_PCA9539
+ tristate PCA9539 16-bit I/O port
+ depends on I2C
+ help
+ Say yes here to support the PCA9539 16-bit I/O port. These
+ parts are made by NXP and TI.
+
+ This driver can also be built as a module. If so, the module
+ will be called pca9539.
+
config GPIO_PCF857X
tristate PCF857x, PCA857x, and PCA967x I2C GPIO expanders
depends on I2C
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 575bb57..d14fc1e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -1,4 +1,5 @@
# gpio support: dedicated expander chips, etc
obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
+obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
new file mode 100644
index 000..050a378
--- /dev/null
+++ b/drivers/gpio/pca9539.c
@@ -0,0 +1,254 @@
+/*
+ * pca9539.c - 16-bit I/O port with interrupt and reset
+ *
+ * Copyright (C) 2005 Ben Gardner [EMAIL PROTECTED]
+ * Copyright (C) 2007 Marvell International Ltd.
+ *
+ * Derived from drivers/i2c/chips/pca9539.c (which has no current known
+ * users).
+ *
+ * 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.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/i2c.h
+#include linux/i2c/pca9539.h
+
+#include asm/gpio.h
+
+#define NR_PCA9539_GPIOS 16
+
+#define PCA9539_INPUT 0
+#define PCA9539_OUTPUT 2
+#define PCA9539_INVERT 4
+#define PCA9539_DIRECTION 6
+
+struct pca9539_chip {
+ unsigned gpio_start;
+ uint16_t reg_output;
+ uint16_t reg_direction;
+
+ struct i2c_client *client;
+ struct gpio_chip gpio_chip;
+};
+
+static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
+{
+ return i2c_smbus_write_word_data(chip-client, reg, val);
+}
+
+static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t *val)
+{
+ int ret;
+
+ ret = i2c_smbus_read_word_data(chip-client, reg);
+ if (ret 0) {
+ dev_err(chip-client-dev, failed reading register\n);
+ return ret;
+ }
+
+ *val = (uint16_t)ret;
+ return 0;
+}
+
+static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ reg_val = chip-reg_direction | (1u off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return -EIO;
+
+ chip-reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_direction_output(struct gpio_chip *gc,
+ unsigned off, int val)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ /* set output level */
+ if (val)
+ reg_val = chip-reg_output | (1u off);
+ else
+ reg_val = chip-reg_output ~(1u off);
+
+ ret = pca9539_write_reg(chip, PCA9539_OUTPUT, reg_val);
+ if (ret)
+ return -EIO;
+
+ chip-reg_output = reg_val;
+
+ /* then direction */
+ reg_val = chip-reg_direction ~(1u off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return -EIO;
+
+ chip-reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_get_value(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip
Re: [PATCH 2.6.24-rc5-mm 1/3] gpiolib: basic support for 16-bit PCA9539 GPIO expander
[ forget about the previous patch, sorry for my carelessness not to
free the chip structure, below is the correct one ]
From c4be69e8dad28dc75e80b393f9c60f740cca7047 Mon Sep 17 00:00:00 2001
From: eric miao [EMAIL PROTECTED]
Date: Mon, 10 Dec 2007 17:19:12 +0800
Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander
1. use 16-bit register access to simplify the logic, cache OUTPUT
and DIRECTION registers for fast access
2. platform code is required to setup
a) the numbering of GPIO for PCA9539 (base and number)
c) pass pca9539_platform_data within i2c_board_info
Derived from drivers/i2c/chips/pca9539.c (which has no current known
users).
Signed-off-by: eric miao [EMAIL PROTECTED]
---
drivers/gpio/Kconfig| 10 ++
drivers/gpio/Makefile |1 +
drivers/gpio/pca9539.c | 260 +++
include/linux/i2c/pca9539.h | 18 +++
4 files changed, 289 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/pca9539.c
create mode 100644 include/linux/i2c/pca9539.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index dd9e697..4b54f60 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -9,6 +9,16 @@ menu GPIO Expanders
comment I2C GPIO expanders:
+config GPIO_PCA9539
+ tristate PCA9539 16-bit I/O port
+ depends on I2C
+ help
+ Say yes here to support the PCA9539 16-bit I/O port. These
+ parts are made by NXP and TI.
+
+ This driver can also be built as a module. If so, the module
+ will be called pca9539.
+
config GPIO_PCF857X
tristate PCF857x, PCA857x, and PCA967x I2C GPIO expanders
depends on I2C
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 575bb57..d14fc1e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -1,4 +1,5 @@
# gpio support: dedicated expander chips, etc
obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
+obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
new file mode 100644
index 000..fc8bee4
--- /dev/null
+++ b/drivers/gpio/pca9539.c
@@ -0,0 +1,260 @@
+/*
+ * pca9539.c - 16-bit I/O port with interrupt and reset
+ *
+ * Copyright (C) 2005 Ben Gardner [EMAIL PROTECTED]
+ * Copyright (C) 2007 Marvell International Ltd.
+ *
+ * Derived from drivers/i2c/chips/pca9539.c (which has no current known
+ * users).
+ *
+ * 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.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/i2c.h
+#include linux/i2c/pca9539.h
+
+#include asm/gpio.h
+
+#define NR_PCA9539_GPIOS 16
+
+#define PCA9539_INPUT 0
+#define PCA9539_OUTPUT 2
+#define PCA9539_INVERT 4
+#define PCA9539_DIRECTION 6
+
+struct pca9539_chip {
+ unsigned gpio_start;
+ uint16_t reg_output;
+ uint16_t reg_direction;
+
+ struct i2c_client *client;
+ struct gpio_chip gpio_chip;
+};
+
+static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
+{
+ return i2c_smbus_write_word_data(chip-client, reg, val);
+}
+
+static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t *val)
+{
+ int ret;
+
+ ret = i2c_smbus_read_word_data(chip-client, reg);
+ if (ret 0) {
+ dev_err(chip-client-dev, failed reading register\n);
+ return ret;
+ }
+
+ *val = (uint16_t)ret;
+ return 0;
+}
+
+static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ reg_val = chip-reg_direction | (1u off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return -EIO;
+
+ chip-reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_direction_output(struct gpio_chip *gc,
+ unsigned off, int val)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ /* set output level */
+ if (val)
+ reg_val = chip-reg_output | (1u off);
+ else
+ reg_val = chip-reg_output ~(1u off);
+
+ ret = pca9539_write_reg(chip, PCA9539_OUTPUT, reg_val);
+ if (ret)
+ return -EIO;
+
+ chip-reg_output = reg_val;
+
+ /* then direction */
+ reg_val = chip-reg_direction ~(1u off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return -EIO;
+
+ chip-reg_direction = reg_val;
+ return 0;
+}
+
+static int
Re: [PATCH 2.6.24-rc5-mm 2/3] gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander
[updated according to David's suggestion to handle the error
of I2C transfer]
From c9b78718488dadc702f40789bd532d1f1765d76e Mon Sep 17 00:00:00 2001
From: eric miao [EMAIL PROTECTED]
Date: Mon, 10 Dec 2007 17:24:36 +0800
Subject: [PATCH] gpiolib: add Generic IRQ support for 16-bit PCA9539
GPIO expander
This patch adds the generic IRQ support for the PCA9539 on-chip GPIOs.
Note: due to the inaccessibility of the generic IRQ code within modules,
this support is only available if the driver is built-in.
Signed-off-by: eric miao [EMAIL PROTECTED]
---
drivers/gpio/Kconfig | 11 +++-
drivers/gpio/pca9539.c | 185
2 files changed, 195 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 4b54f60..a4f89a6 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -17,7 +17,16 @@ config GPIO_PCA9539
parts are made by NXP and TI.
This driver can also be built as a module. If so, the module
- will be called pca9539.
+ will be called pca9539. Note: the Generic IRQ support for the
+ chip will only be available if the driver is built-in
+
+config GPIO_PCA9539_GENERIC_IRQ
+ bool Generic IRQ support for PCA9539
+ depends on GPIO_PCA9539=y GENERIC_HARDIRQS
+ help
+ Say yes here to support the Generic IRQ for the PCA9539 on-chip
+ GPIO lines. Only pin-changed IRQs (IRQ_TYPE_EDGE_BOTH) are
+ supported in hardware.
config GPIO_PCF857X
tristate PCF857x, PCA857x, and PCA967x I2C GPIO expanders
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
index fc8bee4..10f9549 100644
--- a/drivers/gpio/pca9539.c
+++ b/drivers/gpio/pca9539.c
@@ -14,6 +14,9 @@
#include linux/module.h
#include linux/init.h
+#include linux/irq.h
+#include linux/interrupt.h
+#include linux/workqueue.h
#include linux/i2c.h
#include linux/i2c/pca9539.h
@@ -33,6 +36,22 @@ struct pca9539_chip {
struct i2c_client *client;
struct gpio_chip gpio_chip;
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+ /*
+* Note: Generic IRQ is not accessible within module code, the IRQ
+* support will thus _only_ be available if the driver is built-in
+*/
+ int irq;/* IRQ for the chip itself */
+ int irq_start; /* starting IRQ for the on-chip GPIO lines */
+
+ uint16_t irq_mask;
+ uint16_t irq_falling_edge;
+ uint16_t irq_rising_edge;
+ uint16_t last_input;
+
+ struct irq_chip irq_chip;
+ struct work_struct irq_work;
+#endif
};
static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
@@ -155,6 +174,158 @@ static int pca9539_init_gpio(struct pca9539_chip *chip)
return gpiochip_add(gc);
}
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+/* FIXME: change to schedule_delayed_work() here if reading out of
+ * registers does not reflect the actual pin levels
+ */
+
+static void pca9539_irq_work(struct work_struct *work)
+{
+ struct pca9539_chip *chip;
+ uint16_t input, mask, rising, falling;
+ int ret, i;
+
+ chip = container_of(work, struct pca9539_chip, irq_work);
+
+ ret = pca9539_read_reg(chip, PCA9539_INPUT, input);
+ if (ret 0)
+ return;
+
+ mask = (input ^ chip-last_input) chip-irq_mask;
+ rising = (input mask) chip-irq_rising_edge;
+ falling = (~input mask) chip-irq_falling_edge;
+
+ irq_enter();
+
+ for (i = 0; i NR_PCA9539_GPIOS; i++) {
+ if ((rising | falling) (1u i)) {
+ int irq = chip-irq_start + i;
+ struct irq_desc *desc;
+
+ desc = irq_desc + irq;
+ desc_handle_irq(irq, desc);
+ }
+ }
+
+ irq_exit();
+
+ chip-last_input = input;
+}
+
+static void fastcall
+pca9539_irq_demux(unsigned int irq, struct irq_desc *desc)
+{
+ struct pca9539_chip *chip = desc-handler_data;
+
+ desc-chip-mask(chip-irq);
+ desc-chip-ack(chip-irq);
+ schedule_work(chip-irq_work);
+ desc-chip-unmask(chip-irq);
+}
+
+static void pca9539_irq_mask(unsigned int irq)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc-chip_data;
+
+ chip-irq_mask = ~(1u (irq - chip-irq_start));
+}
+
+static void pca9539_irq_unmask(unsigned int irq)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc-chip_data;
+
+ chip-irq_mask |= 1u (irq - chip-irq_start);
+}
+
+static void pca9539_irq_ack(unsigned int irq)
+{
+ /* unfortunately, we have to provide an empty irq_chip.ack even
+* if we do nothing here, Generic IRQ will complain otherwise
+*/
+}
+
+static int pca9539_irq_set_type(unsigned int irq, unsigned int type)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc-chip_data
Re: [PATCH 2.6.24-rc5-mm 3/3] gpiolib: obsolete drivers/i2c/chips/pca9539.c
[ Updated according to Jean's suggestion, thanks ]
From 5b4d907da17d57ec168643ebd847278e8d7267f9 Mon Sep 17 00:00:00 2001
From: eric miao [EMAIL PROTECTED]
Date: Sat, 15 Dec 2007 12:07:26 +0800
Subject: [PATCH] gpiolib: obsolete drivers/i2c/chips/pca9539.c and related files
for the following reasons:
1. there is currently no known users of this driver
2. the functionality of this driver is well supported with the recent
proposed drivers/gpio/pca9539.c, using GPIO_LIB
Signed-off-by: eric miao [EMAIL PROTECTED]
Acked-by: Ben Gardner [EMAIL PROTECTED]
---
Documentation/i2c/chips/pca9539 | 47 -
drivers/i2c/chips/Kconfig | 10 --
drivers/i2c/chips/Makefile |1 -
drivers/i2c/chips/pca9539.c | 196 ---
4 files changed, 0 insertions(+), 254 deletions(-)
delete mode 100644 Documentation/i2c/chips/pca9539
delete mode 100644 drivers/i2c/chips/pca9539.c
diff --git a/Documentation/i2c/chips/pca9539 b/Documentation/i2c/chips/pca9539
deleted file mode 100644
index c4fce6a..000
--- a/Documentation/i2c/chips/pca9539
+++ /dev/null
@@ -1,47 +0,0 @@
-Kernel driver pca9539
-=
-
-Supported chips:
- * Philips PCA9539
-Prefix: 'pca9539'
-Addresses scanned: 0x74 - 0x77
-Datasheet:
-http://www.semiconductors.philips.com/acrobat/datasheets/PCA9539_2.pdf
-
-Author: Ben Gardner [EMAIL PROTECTED]
-
-
-Description
-
-The Philips PCA9539 is a 16 bit low power I/O device.
-All 16 lines can be individually configured as an input or output.
-The input sense can also be inverted.
-The 16 lines are split between two bytes.
-
-
-Sysfs entries
--
-
-Each is a byte that maps to the 8 I/O bits.
-A '0' suffix is for bits 0-7, while '1' is for bits 8-15.
-
-input[01] - read the current value
-output[01]- sets the output value
-direction[01] - direction of each bit: 1=input, 0=output
-invert[01]- toggle the input bit sense
-
-input reads the actual state of the line and is always available.
-The direction defaults to input for all channels.
-
-
-General Remarks
-
-Note that each output, direction, and invert entry controls 8 lines.
-You should use the read, modify, write sequence.
-For example. to set output bit 0 of 1.
- val=$(cat output0)
- val=$(( $val | 1 ))
- echo $val output0
-
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 2e1c24f..a676f57 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -65,16 +65,6 @@ config SENSORS_PCF8574
These devices are hard to detect and rarely found on mainstream
hardware. If unsure, say N.
-config SENSORS_PCA9539
- tristate Philips PCA9539 16-bit I/O port
- depends on EXPERIMENTAL
- help
- If you say yes here you get support for the Philips PCA9539
- 16-bit I/O port.
-
- This driver can also be built as a module. If so, the module
- will be called pca9539.
-
config SENSORS_PCF8591
tristate Philips PCF8591
depends on EXPERIMENTAL
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index ca924e1..bc9e9ca 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -8,7 +8,6 @@ obj-$(CONFIG_DS1682)+= ds1682.o
obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o
obj-$(CONFIG_SENSORS_MAX6875) += max6875.o
obj-$(CONFIG_SENSORS_M41T00) += m41t00.o
-obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o
obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
diff --git a/drivers/i2c/chips/pca9539.c b/drivers/i2c/chips/pca9539.c
deleted file mode 100644
index f43c4e7..000
--- a/drivers/i2c/chips/pca9539.c
+++ /dev/null
@@ -1,196 +0,0 @@
-/*
-pca9539.c - 16-bit I/O port with interrupt and reset
-
-Copyright (C) 2005 Ben Gardner [EMAIL PROTECTED]
-
-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.
-*/
-
-#include linux/module.h
-#include linux/init.h
-#include linux/slab.h
-#include linux/i2c.h
-#include linux/hwmon-sysfs.h
-
-/* Addresses to scan */
-static unsigned short normal_i2c[] = {0x74, 0x75, 0x76, 0x77, I2C_CLIENT_END};
-
-/* Insmod parameters */
-I2C_CLIENT_INSMOD_1(pca9539);
-
-enum pca9539_cmd
-{
- PCA9539_INPUT_0 = 0,
- PCA9539_INPUT_1 = 1,
- PCA9539_OUTPUT_0= 2,
- PCA9539_OUTPUT_1= 3,
- PCA9539_INVERT_0= 4,
- PCA9539_INVERT_1= 5,
- PCA9539_DIRECTION_0 = 6,
- PCA9539_DIRECTION_1 = 7,
-};
-
-static int pca9539_attach_adapter(struct i2c_adapter *adapter);
-static int pca9539_detect(struct i2c_adapter *adapter, int address, int kind);
-static int pca9539_detach_client(struct i2c_client *client
Re: [PATCH 0/2] gpiolib: add support for PCA9539
Jean, I'd like to postpone the corresponding change to the point that polling i2c patch is merged. On Dec 15, 2007 12:16 AM, Jean Delvare <[EMAIL PROTECTED]> wrote: > Hi Eric, > > > On Mon, 10 Dec 2007 17:37:05 +0800, eric miao wrote: > > Support for PCA9539 as a GPIO chip is separated into two patches: > > > > 0001 - gpiolib: basic support for 16-bit PCA9539 GPIO expander > > 0002 - gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander > > > > the 2nd one uses workqueue for IRQ handling due to the interrupt mode > > nature of the i2c-core, thus making it a separate patch. > > Note that the situation could change according to the discussion in > this thread: > http://lists.lm-sensors.org/pipermail/i2c/2007-December/002378.html > > -- > Jean Delvare > -- Cheers - eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.24-rc5-mm 3/3] gpiolib: obsolete drivers/i2c/chips/pca9539.c
>From 0bca662f68e7ffe84f333d7d26df25d846713db2 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Sat, 15 Dec 2007 12:07:26 +0800
Subject: [PATCH] gpiolib: obsolete drivers/i2c/chips/pca9539.c
for the following reasons:
1. there is currently no known users of this driver
2. the functionality of this driver is well supported with the recent
proposed drivers/gpio/pca9539.c, using GPIO_LIB
Signed-off-by: eric miao <[EMAIL PROTECTED]>
Acked-by: Ben Gardner <[EMAIL PROTECTED]>
---
drivers/i2c/chips/Kconfig | 10 --
drivers/i2c/chips/Makefile |1 -
drivers/i2c/chips/pca9539.c | 196 ---
3 files changed, 0 insertions(+), 207 deletions(-)
delete mode 100644 drivers/i2c/chips/pca9539.c
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 2e1c24f..a676f57 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -65,16 +65,6 @@ config SENSORS_PCF8574
These devices are hard to detect and rarely found on mainstream
hardware. If unsure, say N.
-config SENSORS_PCA9539
- tristate "Philips PCA9539 16-bit I/O port"
- depends on EXPERIMENTAL
- help
- If you say yes here you get support for the Philips PCA9539
- 16-bit I/O port.
-
- This driver can also be built as a module. If so, the module
- will be called pca9539.
-
config SENSORS_PCF8591
tristate "Philips PCF8591"
depends on EXPERIMENTAL
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index ca924e1..bc9e9ca 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -8,7 +8,6 @@ obj-$(CONFIG_DS1682)+= ds1682.o
obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o
obj-$(CONFIG_SENSORS_MAX6875) += max6875.o
obj-$(CONFIG_SENSORS_M41T00) += m41t00.o
-obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o
obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
diff --git a/drivers/i2c/chips/pca9539.c b/drivers/i2c/chips/pca9539.c
deleted file mode 100644
index f43c4e7..000
--- a/drivers/i2c/chips/pca9539.c
+++ /dev/null
@@ -1,196 +0,0 @@
-/*
-pca9539.c - 16-bit I/O port with interrupt and reset
-
-Copyright (C) 2005 Ben Gardner <[EMAIL PROTECTED]>
-
-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.
-*/
-
-#include
-#include
-#include
-#include
-#include
-
-/* Addresses to scan */
-static unsigned short normal_i2c[] = {0x74, 0x75, 0x76, 0x77, I2C_CLIENT_END};
-
-/* Insmod parameters */
-I2C_CLIENT_INSMOD_1(pca9539);
-
-enum pca9539_cmd
-{
- PCA9539_INPUT_0 = 0,
- PCA9539_INPUT_1 = 1,
- PCA9539_OUTPUT_0= 2,
- PCA9539_OUTPUT_1= 3,
- PCA9539_INVERT_0= 4,
- PCA9539_INVERT_1= 5,
- PCA9539_DIRECTION_0 = 6,
- PCA9539_DIRECTION_1 = 7,
-};
-
-static int pca9539_attach_adapter(struct i2c_adapter *adapter);
-static int pca9539_detect(struct i2c_adapter *adapter, int address, int kind);
-static int pca9539_detach_client(struct i2c_client *client);
-
-/* This is the driver that will be inserted */
-static struct i2c_driver pca9539_driver = {
- .driver = {
- .name = "pca9539",
- },
- .attach_adapter = pca9539_attach_adapter,
- .detach_client = pca9539_detach_client,
-};
-
-struct pca9539_data {
- struct i2c_client client;
-};
-
-/* following are the sysfs callback functions */
-static ssize_t pca9539_show(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- struct sensor_device_attribute *psa = to_sensor_dev_attr(attr);
- struct i2c_client *client = to_i2c_client(dev);
- return sprintf(buf, "%d\n", i2c_smbus_read_byte_data(client,
-psa->index));
-}
-
-static ssize_t pca9539_store(struct device *dev, struct device_attribute *attr,
-const char *buf, size_t count)
-{
- struct sensor_device_attribute *psa = to_sensor_dev_attr(attr);
- struct i2c_client *client = to_i2c_client(dev);
- unsigned long val = simple_strtoul(buf, NULL, 0);
- if (val > 0xff)
- return -EINVAL;
- i2c_smbus_write_byte_data(client, psa->index, val);
- return count;
-}
-
-/* Define the device attributes */
-
-#define PCA9539_ENTRY_RO(name, cmd_idx) \
- static SENSOR_DEVICE_ATTR(name, S_IRUGO, pca9539_show, NULL, cmd_idx)
-
-#define PCA9539_ENTRY_RW(name, cmd_idx) \
- static SENSOR_DEVICE_ATTR(name, S_IRUGO | S_IWUSR, pca9539_show, \
- pca9539_store, cmd_idx)
-
-PCA9539_
[PATCH 2.6.24-rc5-mm 2/3] gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander
>From b45be77acbf592b9c2085ed03ab5f16d780fa8c7 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:24:36 +0800
Subject: [PATCH] gpiolib: add Generic IRQ support for 16-bit PCA9539
GPIO expander
This patch adds the generic IRQ support for the PCA9539 on-chip GPIOs.
Note: due to the inaccessibility of the generic IRQ code within modules,
this support is only available if the driver is built-in.
Signed-off-by: eric miao <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig | 11 +++-
drivers/gpio/pca9539.c | 183
2 files changed, 193 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 4b54f60..a4f89a6 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -17,7 +17,16 @@ config GPIO_PCA9539
parts are made by NXP and TI.
This driver can also be built as a module. If so, the module
- will be called pca9539.
+ will be called pca9539. Note: the Generic IRQ support for the
+ chip will only be available if the driver is built-in
+
+config GPIO_PCA9539_GENERIC_IRQ
+ bool "Generic IRQ support for PCA9539"
+ depends on GPIO_PCA9539=y && GENERIC_HARDIRQS
+ help
+ Say yes here to support the Generic IRQ for the PCA9539 on-chip
+ GPIO lines. Only pin-changed IRQs (IRQ_TYPE_EDGE_BOTH) are
+ supported in hardware.
config GPIO_PCF857X
tristate "PCF857x, PCA857x, and PCA967x I2C GPIO expanders"
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
index 955d891..ad3267b 100644
--- a/drivers/gpio/pca9539.c
+++ b/drivers/gpio/pca9539.c
@@ -14,6 +14,9 @@
#include
#include
+#include
+#include
+#include
#include
#include
@@ -33,6 +36,22 @@ struct pca9539_chip {
struct i2c_client *client;
struct gpio_chip gpio_chip;
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+ /*
+* Note: Generic IRQ is not accessible within module code, the IRQ
+* support will thus _only_ be available if the driver is built-in
+*/
+ int irq;/* IRQ for the chip itself */
+ int irq_start; /* starting IRQ for the on-chip GPIO lines */
+
+ uint16_t irq_mask;
+ uint16_t irq_falling_edge;
+ uint16_t irq_rising_edge;
+ uint16_t last_input;
+
+ struct irq_chip irq_chip;
+ struct work_struct irq_work;
+#endif
};
static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
@@ -155,6 +174,156 @@ static int pca9539_init_gpio(struct pca9539_chip *chip)
return gpiochip_add(gc);
}
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+/* FIXME: change to schedule_delayed_work() here if reading out of
+ * registers does not reflect the actual pin levels
+ */
+
+static void pca9539_irq_work(struct work_struct *work)
+{
+ struct pca9539_chip *chip;
+ uint16_t input, mask, rising, falling;
+ int ret, i;
+
+ chip = container_of(work, struct pca9539_chip, irq_work);
+
+ ret = pca9539_read_reg(chip, PCA9539_INPUT, );
+ if (ret < 0)
+ return;
+
+ mask = (input ^ chip->last_input) & chip->irq_mask;
+ rising = (input & mask) & chip->irq_rising_edge;
+ falling = (~input & mask) & chip->irq_falling_edge;
+
+ irq_enter();
+
+ for (i = 0; i < NR_PCA9539_GPIOS; i++) {
+ if ((rising | falling) & (1u << i)) {
+ int irq = chip->irq_start + i;
+ struct irq_desc *desc;
+
+ desc = irq_desc + irq;
+ desc_handle_irq(irq, desc);
+ }
+ }
+
+ irq_exit();
+
+ chip->last_input = input;
+}
+
+static void fastcall
+pca9539_irq_demux(unsigned int irq, struct irq_desc *desc)
+{
+ struct pca9539_chip *chip = desc->handler_data;
+
+ desc->chip->mask(chip->irq);
+ desc->chip->ack(chip->irq);
+ schedule_work(>irq_work);
+ desc->chip->unmask(chip->irq);
+}
+
+static void pca9539_irq_mask(unsigned int irq)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc->chip_data;
+
+ chip->irq_mask &= ~(1u << (irq - chip->irq_start));
+}
+
+static void pca9539_irq_unmask(unsigned int irq)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc->chip_data;
+
+ chip->irq_mask |= 1u << (irq - chip->irq_start);
+}
+
+static void pca9539_irq_ack(unsigned int irq)
+{
+ /* unfortunately, we have to provide an empty irq_chip.ack even
+* if we do nothing here, Generic IRQ will complain otherwise
+*/
+}
+
+static int pca9539_irq_set_type(unsigned int irq, unsigned int type)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *
[PATCH 2.6.24-rc5-mm 1/3] gpiolib: basic support for 16-bit PCA9539 GPIO expander
>From 5ebe07236b99587296cbf603a965d284ceaf Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:19:12 +0800
Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander
1. use 16-bit register access to simplify the logic, cache OUTPUT
and DIRECTION registers for fast access
2. platform code is required to setup
a) the numbering of GPIO for PCA9539 (base and number)
c) pass "pca9539_platform_data" within "i2c_board_info"
Derived from drivers/i2c/chips/pca9539.c (which has no current known
users).
Signed-off-by: eric miao <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig| 10 ++
drivers/gpio/Makefile |1 +
drivers/gpio/pca9539.c | 247 +++
include/linux/i2c/pca9539.h | 18 +++
4 files changed, 276 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/pca9539.c
create mode 100644 include/linux/i2c/pca9539.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index dd9e697..4b54f60 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -9,6 +9,16 @@ menu "GPIO Expanders"
comment "I2C GPIO expanders:"
+config GPIO_PCA9539
+ tristate "PCA9539 16-bit I/O port"
+ depends on I2C
+ help
+ Say yes here to support the PCA9539 16-bit I/O port. These
+ parts are made by NXP and TI.
+
+ This driver can also be built as a module. If so, the module
+ will be called pca9539.
+
config GPIO_PCF857X
tristate "PCF857x, PCA857x, and PCA967x I2C GPIO expanders"
depends on I2C
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 575bb57..d14fc1e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -1,4 +1,5 @@
# gpio support: dedicated expander chips, etc
obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
+obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
new file mode 100644
index 000..955d891
--- /dev/null
+++ b/drivers/gpio/pca9539.c
@@ -0,0 +1,247 @@
+/*
+ * pca9539.c - 16-bit I/O port with interrupt and reset
+ *
+ * Copyright (C) 2005 Ben Gardner <[EMAIL PROTECTED]>
+ * Copyright (C) 2007 Marvell International Ltd.
+ *
+ * Derived from drivers/i2c/chips/pca9539.c (which has no current known
+ * users).
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+#define NR_PCA9539_GPIOS 16
+
+#define PCA9539_INPUT 0
+#define PCA9539_OUTPUT 2
+#define PCA9539_INVERT 4
+#define PCA9539_DIRECTION 6
+
+struct pca9539_chip {
+ unsigned gpio_start;
+ uint16_t reg_output;
+ uint16_t reg_direction;
+
+ struct i2c_client *client;
+ struct gpio_chip gpio_chip;
+};
+
+static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
+{
+ return i2c_smbus_write_word_data(chip->client, reg, val);
+}
+
+static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t *val)
+{
+ int ret;
+
+ ret = i2c_smbus_read_word_data(chip->client, reg);
+ if (ret < 0) {
+ dev_err(>client->dev, "failed reading register\n");
+ return ret;
+ }
+
+ *val = (uint16_t)ret;
+ return 0;
+}
+
+static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ reg_val = chip->reg_direction | (1u << off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return ret;
+
+ chip->reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_direction_output(struct gpio_chip *gc,
+ unsigned off, int val)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ /* set output level */
+ if (val)
+ reg_val = chip->reg_output | (1u << off);
+ else
+ reg_val = chip->reg_output & ~(1u << off);
+
+ ret = pca9539_write_reg(chip, PCA9539_OUTPUT, reg_val);
+ if (ret)
+ return ret;
+
+ chip->reg_output = reg_val;
+
+ /* then direction */
+ reg_val = chip->reg_direction & ~(1u << off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return ret;
+
+ chip->reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gp
[PATCH 2.6.24-rc5-mm 0/3] gpiolib: add support for NXP/TI PCA9539
[updated] support for PCA9539 as a GPIO chip is separated into three patches: 0001 - gpiolib: basic support for 16-bit PCA9539 GPIO expander 0002 - gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander 0003 - gpiolib: obsolete drivers/i2c/chips/pca9539.c The 2nd one uses workqueue for IRQ handling due to the interrupt mode nature of the i2c-core, thus making it a separate patch. -- Cheers - eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc4-mm 1/2] gpiolib: basic support for 16-bit PCA9539 GPIO expander[
I'd like to create another thread in LKML for the updated version, sorry.
On Dec 15, 2007 11:56 AM, eric miao <[EMAIL PROTECTED]> wrote:
> OK,
>
> Here's the updated version, which
> 1. modify the author info but still preserve Ben's credit in the source head
> 2. Alphabetic order in Kconfig/Makefile
> 3. typo fix and corrected Philips to NXP/TI
> 4. use dev_err instead of printk
> 5. move module_{init,exit} next to the routines
> 6. preserve initial output/direction register settings
>
> Also I'd like to fire another patch to obsolete drivers/i2c/chips/pca9539.c
> as everyone agreed.
>
> From 5ebe07236b99587296cbf603a965d284ceaf Mon Sep 17 00:00:00 2001
> From: eric miao <[EMAIL PROTECTED]>
> Date: Mon, 10 Dec 2007 17:19:12 +0800
> Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander
>
> 1. use 16-bit register access to simplify the logic, cache OUTPUT
>and DIRECTION registers for fast access
>
> 2. platform code is required to setup
>a) the numbering of GPIO for PCA9539 (base and number)
>c) pass "pca9539_platform_data" within "i2c_board_info"
>
> Derived from drivers/i2c/chips/pca9539.c (which has no current known
> users).
>
> Signed-off-by: eric miao <[EMAIL PROTECTED]>
> ---
> drivers/gpio/Kconfig| 10 ++
> drivers/gpio/Makefile |1 +
> drivers/gpio/pca9539.c | 247
> +++
> include/linux/i2c/pca9539.h | 18 +++
> 4 files changed, 276 insertions(+), 0 deletions(-)
> create mode 100644 drivers/gpio/pca9539.c
> create mode 100644 include/linux/i2c/pca9539.h
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index dd9e697..4b54f60 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -9,6 +9,16 @@ menu "GPIO Expanders"
>
> comment "I2C GPIO expanders:"
>
> +config GPIO_PCA9539
> + tristate "PCA9539 16-bit I/O port"
> + depends on I2C
> + help
> + Say yes here to support the PCA9539 16-bit I/O port. These
> + parts are made by NXP and TI.
> +
> + This driver can also be built as a module. If so, the module
> + will be called pca9539.
> +
> config GPIO_PCF857X
> tristate "PCF857x, PCA857x, and PCA967x I2C GPIO expanders"
> depends on I2C
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 575bb57..d14fc1e 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -1,4 +1,5 @@
> # gpio support: dedicated expander chips, etc
>
> obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
> +obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
> obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
> diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
> new file mode 100644
> index 000..955d891
> --- /dev/null
> +++ b/drivers/gpio/pca9539.c
> @@ -0,0 +1,247 @@
> +/*
> + * pca9539.c - 16-bit I/O port with interrupt and reset
> + *
> + * Copyright (C) 2005 Ben Gardner <[EMAIL PROTECTED]>
> + * Copyright (C) 2007 Marvell International Ltd.
> + *
> + * Derived from drivers/i2c/chips/pca9539.c (which has no current known
> + * users).
> + *
> + * 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define NR_PCA9539_GPIOS 16
> +
> +#define PCA9539_INPUT 0
> +#define PCA9539_OUTPUT 2
> +#define PCA9539_INVERT 4
> +#define PCA9539_DIRECTION 6
> +
> +struct pca9539_chip {
> + unsigned gpio_start;
> + uint16_t reg_output;
> + uint16_t reg_direction;
> +
> + struct i2c_client *client;
> + struct gpio_chip gpio_chip;
> +};
> +
> +static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t
> val)
> +{
> + return i2c_smbus_write_word_data(chip->client, reg, val);
> +}
> +
> +static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t
> *val)
> +{
> + int ret;
> +
> + ret = i2c_smbus_read_word_data(chip->client, reg);
> + if (ret < 0) {
> + dev_err(>client->dev, "failed reading register\n");
>
> + return ret;
> + }
> +
> + *val = (uint16_t)ret;
> + return 0;
> +}
> +
> +static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
> +{
> + struct pca9539_chip
Re: [PATCH 2.6.24-rc4-mm 1/2] gpiolib: basic support for 16-bit PCA9539 GPIO expander[
OK,
Here's the updated version, which
1. modify the author info but still preserve Ben's credit in the source head
2. Alphabetic order in Kconfig/Makefile
3. typo fix and corrected Philips to NXP/TI
4. use dev_err instead of printk
5. move module_{init,exit} next to the routines
6. preserve initial output/direction register settings
Also I'd like to fire another patch to obsolete drivers/i2c/chips/pca9539.c
as everyone agreed.
>From 5ebe07236b99587296cbf603a965d284ceaf Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:19:12 +0800
Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander
1. use 16-bit register access to simplify the logic, cache OUTPUT
and DIRECTION registers for fast access
2. platform code is required to setup
a) the numbering of GPIO for PCA9539 (base and number)
c) pass "pca9539_platform_data" within "i2c_board_info"
Derived from drivers/i2c/chips/pca9539.c (which has no current known
users).
Signed-off-by: eric miao <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig| 10 ++
drivers/gpio/Makefile |1 +
drivers/gpio/pca9539.c | 247 +++
include/linux/i2c/pca9539.h | 18 +++
4 files changed, 276 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/pca9539.c
create mode 100644 include/linux/i2c/pca9539.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index dd9e697..4b54f60 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -9,6 +9,16 @@ menu "GPIO Expanders"
comment "I2C GPIO expanders:"
+config GPIO_PCA9539
+ tristate "PCA9539 16-bit I/O port"
+ depends on I2C
+ help
+ Say yes here to support the PCA9539 16-bit I/O port. These
+ parts are made by NXP and TI.
+
+ This driver can also be built as a module. If so, the module
+ will be called pca9539.
+
config GPIO_PCF857X
tristate "PCF857x, PCA857x, and PCA967x I2C GPIO expanders"
depends on I2C
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 575bb57..d14fc1e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -1,4 +1,5 @@
# gpio support: dedicated expander chips, etc
obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
+obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
new file mode 100644
index 000..955d891
--- /dev/null
+++ b/drivers/gpio/pca9539.c
@@ -0,0 +1,247 @@
+/*
+ * pca9539.c - 16-bit I/O port with interrupt and reset
+ *
+ * Copyright (C) 2005 Ben Gardner <[EMAIL PROTECTED]>
+ * Copyright (C) 2007 Marvell International Ltd.
+ *
+ * Derived from drivers/i2c/chips/pca9539.c (which has no current known
+ * users).
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+#define NR_PCA9539_GPIOS 16
+
+#define PCA9539_INPUT 0
+#define PCA9539_OUTPUT 2
+#define PCA9539_INVERT 4
+#define PCA9539_DIRECTION 6
+
+struct pca9539_chip {
+ unsigned gpio_start;
+ uint16_t reg_output;
+ uint16_t reg_direction;
+
+ struct i2c_client *client;
+ struct gpio_chip gpio_chip;
+};
+
+static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
+{
+ return i2c_smbus_write_word_data(chip->client, reg, val);
+}
+
+static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t *val)
+{
+ int ret;
+
+ ret = i2c_smbus_read_word_data(chip->client, reg);
+ if (ret < 0) {
+ dev_err(>client->dev, "failed reading register\n");
+ return ret;
+ }
+
+ *val = (uint16_t)ret;
+ return 0;
+}
+
+static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ reg_val = chip->reg_direction | (1u << off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return ret;
+
+ chip->reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_direction_output(struct gpio_chip *gc,
+ unsigned off, int val)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ /* set output level */
+ if (val)
+ reg_val = chip->reg_output | (1u << off);
+ else
+ reg_val = chip->reg_output & ~(1u << off);
+
+
Re: [PATCH 2.6.24-rc4-mm 1/2] gpiolib: basic support for 16-bit PCA9539 GPIO expander[
OK,
Here's the updated version, which
1. modify the author info but still preserve Ben's credit in the source head
2. Alphabetic order in Kconfig/Makefile
3. typo fix and corrected Philips to NXP/TI
4. use dev_err instead of printk
5. move module_{init,exit} next to the routines
6. preserve initial output/direction register settings
Also I'd like to fire another patch to obsolete drivers/i2c/chips/pca9539.c
as everyone agreed.
From 5ebe07236b99587296cbf603a965d284ceaf Mon Sep 17 00:00:00 2001
From: eric miao [EMAIL PROTECTED]
Date: Mon, 10 Dec 2007 17:19:12 +0800
Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander
1. use 16-bit register access to simplify the logic, cache OUTPUT
and DIRECTION registers for fast access
2. platform code is required to setup
a) the numbering of GPIO for PCA9539 (base and number)
c) pass pca9539_platform_data within i2c_board_info
Derived from drivers/i2c/chips/pca9539.c (which has no current known
users).
Signed-off-by: eric miao [EMAIL PROTECTED]
---
drivers/gpio/Kconfig| 10 ++
drivers/gpio/Makefile |1 +
drivers/gpio/pca9539.c | 247 +++
include/linux/i2c/pca9539.h | 18 +++
4 files changed, 276 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/pca9539.c
create mode 100644 include/linux/i2c/pca9539.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index dd9e697..4b54f60 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -9,6 +9,16 @@ menu GPIO Expanders
comment I2C GPIO expanders:
+config GPIO_PCA9539
+ tristate PCA9539 16-bit I/O port
+ depends on I2C
+ help
+ Say yes here to support the PCA9539 16-bit I/O port. These
+ parts are made by NXP and TI.
+
+ This driver can also be built as a module. If so, the module
+ will be called pca9539.
+
config GPIO_PCF857X
tristate PCF857x, PCA857x, and PCA967x I2C GPIO expanders
depends on I2C
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 575bb57..d14fc1e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -1,4 +1,5 @@
# gpio support: dedicated expander chips, etc
obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
+obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
new file mode 100644
index 000..955d891
--- /dev/null
+++ b/drivers/gpio/pca9539.c
@@ -0,0 +1,247 @@
+/*
+ * pca9539.c - 16-bit I/O port with interrupt and reset
+ *
+ * Copyright (C) 2005 Ben Gardner [EMAIL PROTECTED]
+ * Copyright (C) 2007 Marvell International Ltd.
+ *
+ * Derived from drivers/i2c/chips/pca9539.c (which has no current known
+ * users).
+ *
+ * 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.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/i2c.h
+#include linux/i2c/pca9539.h
+
+#include asm/gpio.h
+
+#define NR_PCA9539_GPIOS 16
+
+#define PCA9539_INPUT 0
+#define PCA9539_OUTPUT 2
+#define PCA9539_INVERT 4
+#define PCA9539_DIRECTION 6
+
+struct pca9539_chip {
+ unsigned gpio_start;
+ uint16_t reg_output;
+ uint16_t reg_direction;
+
+ struct i2c_client *client;
+ struct gpio_chip gpio_chip;
+};
+
+static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
+{
+ return i2c_smbus_write_word_data(chip-client, reg, val);
+}
+
+static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t *val)
+{
+ int ret;
+
+ ret = i2c_smbus_read_word_data(chip-client, reg);
+ if (ret 0) {
+ dev_err(chip-client-dev, failed reading register\n);
+ return ret;
+ }
+
+ *val = (uint16_t)ret;
+ return 0;
+}
+
+static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ reg_val = chip-reg_direction | (1u off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return ret;
+
+ chip-reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_direction_output(struct gpio_chip *gc,
+ unsigned off, int val)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ /* set output level */
+ if (val)
+ reg_val = chip-reg_output | (1u off);
+ else
+ reg_val = chip-reg_output ~(1u off);
+
+ ret = pca9539_write_reg(chip, PCA9539_OUTPUT, reg_val);
+ if (ret)
+ return ret;
+
+ chip
Re: [PATCH 2.6.24-rc4-mm 1/2] gpiolib: basic support for 16-bit PCA9539 GPIO expander[
I'd like to create another thread in LKML for the updated version, sorry.
On Dec 15, 2007 11:56 AM, eric miao [EMAIL PROTECTED] wrote:
OK,
Here's the updated version, which
1. modify the author info but still preserve Ben's credit in the source head
2. Alphabetic order in Kconfig/Makefile
3. typo fix and corrected Philips to NXP/TI
4. use dev_err instead of printk
5. move module_{init,exit} next to the routines
6. preserve initial output/direction register settings
Also I'd like to fire another patch to obsolete drivers/i2c/chips/pca9539.c
as everyone agreed.
From 5ebe07236b99587296cbf603a965d284ceaf Mon Sep 17 00:00:00 2001
From: eric miao [EMAIL PROTECTED]
Date: Mon, 10 Dec 2007 17:19:12 +0800
Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander
1. use 16-bit register access to simplify the logic, cache OUTPUT
and DIRECTION registers for fast access
2. platform code is required to setup
a) the numbering of GPIO for PCA9539 (base and number)
c) pass pca9539_platform_data within i2c_board_info
Derived from drivers/i2c/chips/pca9539.c (which has no current known
users).
Signed-off-by: eric miao [EMAIL PROTECTED]
---
drivers/gpio/Kconfig| 10 ++
drivers/gpio/Makefile |1 +
drivers/gpio/pca9539.c | 247
+++
include/linux/i2c/pca9539.h | 18 +++
4 files changed, 276 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/pca9539.c
create mode 100644 include/linux/i2c/pca9539.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index dd9e697..4b54f60 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -9,6 +9,16 @@ menu GPIO Expanders
comment I2C GPIO expanders:
+config GPIO_PCA9539
+ tristate PCA9539 16-bit I/O port
+ depends on I2C
+ help
+ Say yes here to support the PCA9539 16-bit I/O port. These
+ parts are made by NXP and TI.
+
+ This driver can also be built as a module. If so, the module
+ will be called pca9539.
+
config GPIO_PCF857X
tristate PCF857x, PCA857x, and PCA967x I2C GPIO expanders
depends on I2C
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 575bb57..d14fc1e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -1,4 +1,5 @@
# gpio support: dedicated expander chips, etc
obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
+obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
new file mode 100644
index 000..955d891
--- /dev/null
+++ b/drivers/gpio/pca9539.c
@@ -0,0 +1,247 @@
+/*
+ * pca9539.c - 16-bit I/O port with interrupt and reset
+ *
+ * Copyright (C) 2005 Ben Gardner [EMAIL PROTECTED]
+ * Copyright (C) 2007 Marvell International Ltd.
+ *
+ * Derived from drivers/i2c/chips/pca9539.c (which has no current known
+ * users).
+ *
+ * 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.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/i2c.h
+#include linux/i2c/pca9539.h
+
+#include asm/gpio.h
+
+#define NR_PCA9539_GPIOS 16
+
+#define PCA9539_INPUT 0
+#define PCA9539_OUTPUT 2
+#define PCA9539_INVERT 4
+#define PCA9539_DIRECTION 6
+
+struct pca9539_chip {
+ unsigned gpio_start;
+ uint16_t reg_output;
+ uint16_t reg_direction;
+
+ struct i2c_client *client;
+ struct gpio_chip gpio_chip;
+};
+
+static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t
val)
+{
+ return i2c_smbus_write_word_data(chip-client, reg, val);
+}
+
+static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t
*val)
+{
+ int ret;
+
+ ret = i2c_smbus_read_word_data(chip-client, reg);
+ if (ret 0) {
+ dev_err(chip-client-dev, failed reading register\n);
+ return ret;
+ }
+
+ *val = (uint16_t)ret;
+ return 0;
+}
+
+static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ reg_val = chip-reg_direction | (1u off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return ret;
+
+ chip-reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_direction_output(struct gpio_chip *gc,
+ unsigned off, int val)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip
[PATCH 2.6.24-rc5-mm 0/3] gpiolib: add support for NXP/TI PCA9539
[updated] support for PCA9539 as a GPIO chip is separated into three patches: 0001 - gpiolib: basic support for 16-bit PCA9539 GPIO expander 0002 - gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander 0003 - gpiolib: obsolete drivers/i2c/chips/pca9539.c The 2nd one uses workqueue for IRQ handling due to the interrupt mode nature of the i2c-core, thus making it a separate patch. -- Cheers - eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.24-rc5-mm 1/3] gpiolib: basic support for 16-bit PCA9539 GPIO expander
From 5ebe07236b99587296cbf603a965d284ceaf Mon Sep 17 00:00:00 2001
From: eric miao [EMAIL PROTECTED]
Date: Mon, 10 Dec 2007 17:19:12 +0800
Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander
1. use 16-bit register access to simplify the logic, cache OUTPUT
and DIRECTION registers for fast access
2. platform code is required to setup
a) the numbering of GPIO for PCA9539 (base and number)
c) pass pca9539_platform_data within i2c_board_info
Derived from drivers/i2c/chips/pca9539.c (which has no current known
users).
Signed-off-by: eric miao [EMAIL PROTECTED]
---
drivers/gpio/Kconfig| 10 ++
drivers/gpio/Makefile |1 +
drivers/gpio/pca9539.c | 247 +++
include/linux/i2c/pca9539.h | 18 +++
4 files changed, 276 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/pca9539.c
create mode 100644 include/linux/i2c/pca9539.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index dd9e697..4b54f60 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -9,6 +9,16 @@ menu GPIO Expanders
comment I2C GPIO expanders:
+config GPIO_PCA9539
+ tristate PCA9539 16-bit I/O port
+ depends on I2C
+ help
+ Say yes here to support the PCA9539 16-bit I/O port. These
+ parts are made by NXP and TI.
+
+ This driver can also be built as a module. If so, the module
+ will be called pca9539.
+
config GPIO_PCF857X
tristate PCF857x, PCA857x, and PCA967x I2C GPIO expanders
depends on I2C
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 575bb57..d14fc1e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -1,4 +1,5 @@
# gpio support: dedicated expander chips, etc
obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
+obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
new file mode 100644
index 000..955d891
--- /dev/null
+++ b/drivers/gpio/pca9539.c
@@ -0,0 +1,247 @@
+/*
+ * pca9539.c - 16-bit I/O port with interrupt and reset
+ *
+ * Copyright (C) 2005 Ben Gardner [EMAIL PROTECTED]
+ * Copyright (C) 2007 Marvell International Ltd.
+ *
+ * Derived from drivers/i2c/chips/pca9539.c (which has no current known
+ * users).
+ *
+ * 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.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/i2c.h
+#include linux/i2c/pca9539.h
+
+#include asm/gpio.h
+
+#define NR_PCA9539_GPIOS 16
+
+#define PCA9539_INPUT 0
+#define PCA9539_OUTPUT 2
+#define PCA9539_INVERT 4
+#define PCA9539_DIRECTION 6
+
+struct pca9539_chip {
+ unsigned gpio_start;
+ uint16_t reg_output;
+ uint16_t reg_direction;
+
+ struct i2c_client *client;
+ struct gpio_chip gpio_chip;
+};
+
+static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
+{
+ return i2c_smbus_write_word_data(chip-client, reg, val);
+}
+
+static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t *val)
+{
+ int ret;
+
+ ret = i2c_smbus_read_word_data(chip-client, reg);
+ if (ret 0) {
+ dev_err(chip-client-dev, failed reading register\n);
+ return ret;
+ }
+
+ *val = (uint16_t)ret;
+ return 0;
+}
+
+static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ reg_val = chip-reg_direction | (1u off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return ret;
+
+ chip-reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_direction_output(struct gpio_chip *gc,
+ unsigned off, int val)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ /* set output level */
+ if (val)
+ reg_val = chip-reg_output | (1u off);
+ else
+ reg_val = chip-reg_output ~(1u off);
+
+ ret = pca9539_write_reg(chip, PCA9539_OUTPUT, reg_val);
+ if (ret)
+ return ret;
+
+ chip-reg_output = reg_val;
+
+ /* then direction */
+ reg_val = chip-reg_direction ~(1u off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return ret;
+
+ chip-reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_get_value(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret
[PATCH 2.6.24-rc5-mm 2/3] gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander
From b45be77acbf592b9c2085ed03ab5f16d780fa8c7 Mon Sep 17 00:00:00 2001
From: eric miao [EMAIL PROTECTED]
Date: Mon, 10 Dec 2007 17:24:36 +0800
Subject: [PATCH] gpiolib: add Generic IRQ support for 16-bit PCA9539
GPIO expander
This patch adds the generic IRQ support for the PCA9539 on-chip GPIOs.
Note: due to the inaccessibility of the generic IRQ code within modules,
this support is only available if the driver is built-in.
Signed-off-by: eric miao [EMAIL PROTECTED]
---
drivers/gpio/Kconfig | 11 +++-
drivers/gpio/pca9539.c | 183
2 files changed, 193 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 4b54f60..a4f89a6 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -17,7 +17,16 @@ config GPIO_PCA9539
parts are made by NXP and TI.
This driver can also be built as a module. If so, the module
- will be called pca9539.
+ will be called pca9539. Note: the Generic IRQ support for the
+ chip will only be available if the driver is built-in
+
+config GPIO_PCA9539_GENERIC_IRQ
+ bool Generic IRQ support for PCA9539
+ depends on GPIO_PCA9539=y GENERIC_HARDIRQS
+ help
+ Say yes here to support the Generic IRQ for the PCA9539 on-chip
+ GPIO lines. Only pin-changed IRQs (IRQ_TYPE_EDGE_BOTH) are
+ supported in hardware.
config GPIO_PCF857X
tristate PCF857x, PCA857x, and PCA967x I2C GPIO expanders
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
index 955d891..ad3267b 100644
--- a/drivers/gpio/pca9539.c
+++ b/drivers/gpio/pca9539.c
@@ -14,6 +14,9 @@
#include linux/module.h
#include linux/init.h
+#include linux/irq.h
+#include linux/interrupt.h
+#include linux/workqueue.h
#include linux/i2c.h
#include linux/i2c/pca9539.h
@@ -33,6 +36,22 @@ struct pca9539_chip {
struct i2c_client *client;
struct gpio_chip gpio_chip;
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+ /*
+* Note: Generic IRQ is not accessible within module code, the IRQ
+* support will thus _only_ be available if the driver is built-in
+*/
+ int irq;/* IRQ for the chip itself */
+ int irq_start; /* starting IRQ for the on-chip GPIO lines */
+
+ uint16_t irq_mask;
+ uint16_t irq_falling_edge;
+ uint16_t irq_rising_edge;
+ uint16_t last_input;
+
+ struct irq_chip irq_chip;
+ struct work_struct irq_work;
+#endif
};
static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
@@ -155,6 +174,156 @@ static int pca9539_init_gpio(struct pca9539_chip *chip)
return gpiochip_add(gc);
}
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+/* FIXME: change to schedule_delayed_work() here if reading out of
+ * registers does not reflect the actual pin levels
+ */
+
+static void pca9539_irq_work(struct work_struct *work)
+{
+ struct pca9539_chip *chip;
+ uint16_t input, mask, rising, falling;
+ int ret, i;
+
+ chip = container_of(work, struct pca9539_chip, irq_work);
+
+ ret = pca9539_read_reg(chip, PCA9539_INPUT, input);
+ if (ret 0)
+ return;
+
+ mask = (input ^ chip-last_input) chip-irq_mask;
+ rising = (input mask) chip-irq_rising_edge;
+ falling = (~input mask) chip-irq_falling_edge;
+
+ irq_enter();
+
+ for (i = 0; i NR_PCA9539_GPIOS; i++) {
+ if ((rising | falling) (1u i)) {
+ int irq = chip-irq_start + i;
+ struct irq_desc *desc;
+
+ desc = irq_desc + irq;
+ desc_handle_irq(irq, desc);
+ }
+ }
+
+ irq_exit();
+
+ chip-last_input = input;
+}
+
+static void fastcall
+pca9539_irq_demux(unsigned int irq, struct irq_desc *desc)
+{
+ struct pca9539_chip *chip = desc-handler_data;
+
+ desc-chip-mask(chip-irq);
+ desc-chip-ack(chip-irq);
+ schedule_work(chip-irq_work);
+ desc-chip-unmask(chip-irq);
+}
+
+static void pca9539_irq_mask(unsigned int irq)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc-chip_data;
+
+ chip-irq_mask = ~(1u (irq - chip-irq_start));
+}
+
+static void pca9539_irq_unmask(unsigned int irq)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc-chip_data;
+
+ chip-irq_mask |= 1u (irq - chip-irq_start);
+}
+
+static void pca9539_irq_ack(unsigned int irq)
+{
+ /* unfortunately, we have to provide an empty irq_chip.ack even
+* if we do nothing here, Generic IRQ will complain otherwise
+*/
+}
+
+static int pca9539_irq_set_type(unsigned int irq, unsigned int type)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc-chip_data;
+ uint16_t mask = 1u (irq - chip-irq_start);
+
+ if (type == IRQT_PROBE
[PATCH 2.6.24-rc5-mm 3/3] gpiolib: obsolete drivers/i2c/chips/pca9539.c
From 0bca662f68e7ffe84f333d7d26df25d846713db2 Mon Sep 17 00:00:00 2001
From: eric miao [EMAIL PROTECTED]
Date: Sat, 15 Dec 2007 12:07:26 +0800
Subject: [PATCH] gpiolib: obsolete drivers/i2c/chips/pca9539.c
for the following reasons:
1. there is currently no known users of this driver
2. the functionality of this driver is well supported with the recent
proposed drivers/gpio/pca9539.c, using GPIO_LIB
Signed-off-by: eric miao [EMAIL PROTECTED]
Acked-by: Ben Gardner [EMAIL PROTECTED]
---
drivers/i2c/chips/Kconfig | 10 --
drivers/i2c/chips/Makefile |1 -
drivers/i2c/chips/pca9539.c | 196 ---
3 files changed, 0 insertions(+), 207 deletions(-)
delete mode 100644 drivers/i2c/chips/pca9539.c
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 2e1c24f..a676f57 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -65,16 +65,6 @@ config SENSORS_PCF8574
These devices are hard to detect and rarely found on mainstream
hardware. If unsure, say N.
-config SENSORS_PCA9539
- tristate Philips PCA9539 16-bit I/O port
- depends on EXPERIMENTAL
- help
- If you say yes here you get support for the Philips PCA9539
- 16-bit I/O port.
-
- This driver can also be built as a module. If so, the module
- will be called pca9539.
-
config SENSORS_PCF8591
tristate Philips PCF8591
depends on EXPERIMENTAL
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index ca924e1..bc9e9ca 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -8,7 +8,6 @@ obj-$(CONFIG_DS1682)+= ds1682.o
obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o
obj-$(CONFIG_SENSORS_MAX6875) += max6875.o
obj-$(CONFIG_SENSORS_M41T00) += m41t00.o
-obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o
obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
diff --git a/drivers/i2c/chips/pca9539.c b/drivers/i2c/chips/pca9539.c
deleted file mode 100644
index f43c4e7..000
--- a/drivers/i2c/chips/pca9539.c
+++ /dev/null
@@ -1,196 +0,0 @@
-/*
-pca9539.c - 16-bit I/O port with interrupt and reset
-
-Copyright (C) 2005 Ben Gardner [EMAIL PROTECTED]
-
-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.
-*/
-
-#include linux/module.h
-#include linux/init.h
-#include linux/slab.h
-#include linux/i2c.h
-#include linux/hwmon-sysfs.h
-
-/* Addresses to scan */
-static unsigned short normal_i2c[] = {0x74, 0x75, 0x76, 0x77, I2C_CLIENT_END};
-
-/* Insmod parameters */
-I2C_CLIENT_INSMOD_1(pca9539);
-
-enum pca9539_cmd
-{
- PCA9539_INPUT_0 = 0,
- PCA9539_INPUT_1 = 1,
- PCA9539_OUTPUT_0= 2,
- PCA9539_OUTPUT_1= 3,
- PCA9539_INVERT_0= 4,
- PCA9539_INVERT_1= 5,
- PCA9539_DIRECTION_0 = 6,
- PCA9539_DIRECTION_1 = 7,
-};
-
-static int pca9539_attach_adapter(struct i2c_adapter *adapter);
-static int pca9539_detect(struct i2c_adapter *adapter, int address, int kind);
-static int pca9539_detach_client(struct i2c_client *client);
-
-/* This is the driver that will be inserted */
-static struct i2c_driver pca9539_driver = {
- .driver = {
- .name = pca9539,
- },
- .attach_adapter = pca9539_attach_adapter,
- .detach_client = pca9539_detach_client,
-};
-
-struct pca9539_data {
- struct i2c_client client;
-};
-
-/* following are the sysfs callback functions */
-static ssize_t pca9539_show(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- struct sensor_device_attribute *psa = to_sensor_dev_attr(attr);
- struct i2c_client *client = to_i2c_client(dev);
- return sprintf(buf, %d\n, i2c_smbus_read_byte_data(client,
-psa-index));
-}
-
-static ssize_t pca9539_store(struct device *dev, struct device_attribute *attr,
-const char *buf, size_t count)
-{
- struct sensor_device_attribute *psa = to_sensor_dev_attr(attr);
- struct i2c_client *client = to_i2c_client(dev);
- unsigned long val = simple_strtoul(buf, NULL, 0);
- if (val 0xff)
- return -EINVAL;
- i2c_smbus_write_byte_data(client, psa-index, val);
- return count;
-}
-
-/* Define the device attributes */
-
-#define PCA9539_ENTRY_RO(name, cmd_idx) \
- static SENSOR_DEVICE_ATTR(name, S_IRUGO, pca9539_show, NULL, cmd_idx)
-
-#define PCA9539_ENTRY_RW(name, cmd_idx) \
- static SENSOR_DEVICE_ATTR(name, S_IRUGO | S_IWUSR, pca9539_show, \
- pca9539_store, cmd_idx)
-
-PCA9539_ENTRY_RO(input0, PCA9539_INPUT_0
Re: [PATCH 0/2] gpiolib: add support for PCA9539
Jean, I'd like to postpone the corresponding change to the point that polling i2c patch is merged. On Dec 15, 2007 12:16 AM, Jean Delvare [EMAIL PROTECTED] wrote: Hi Eric, On Mon, 10 Dec 2007 17:37:05 +0800, eric miao wrote: Support for PCA9539 as a GPIO chip is separated into two patches: 0001 - gpiolib: basic support for 16-bit PCA9539 GPIO expander 0002 - gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander the 2nd one uses workqueue for IRQ handling due to the interrupt mode nature of the i2c-core, thus making it a separate patch. Note that the situation could change according to the discussion in this thread: http://lists.lm-sensors.org/pipermail/i2c/2007-December/002378.html -- Jean Delvare -- Cheers - eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc4-mm 2/2] gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander
On Dec 10, 2007 6:14 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Monday 10 December 2007, eric miao wrote:
> > +config GPIO_PCA9539_GENERIC_IRQ
> > +bool " Generic IRQ support for PCA9539"
> > +depends on GPIO_PCA9539=y
>
> Also depends on GENERIC_HARDIRQS, right? (You should let
> the Kconfig UI handle indentation, too...)
>
> Seems like doing this for an I2C chip ought to shake loose
> some interesting review comments. :)
>
>
> > +help
> > + Say yes here to support the Generic IRQ for the PCA9539 on-chip
> > + GPIO lines.
>
> This somewhat resembles the pcf857x chips in that it only support
> pin-changed IRQs (IRQ_TYPE_EDGE_BOTH) in hardware. Some other I/O
> expanders are a bit more flexible.
>
> - Dave
>
Updated as follows:
>From 486724d8b2b7a668600e38807680cc3a089ad533 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:24:36 +0800
Subject: [PATCH] gpiolib: add Generic IRQ support for 16-bit PCA9539
GPIO expander
This patch adds the generic IRQ support for the PCA9539 on-chip GPIOs.
Note: due to the inaccessibility of the generic IRQ code within modules,
this support is only available if the driver is built-in.
Signed-off-by: eric miao <[EMAIL PROTECTED]>
Acked-by: Ben Gardner <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig | 11 +++-
drivers/gpio/pca9539.c | 184
2 files changed, 194 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 6528fce..f897df8 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -40,7 +40,16 @@ config GPIO_PCA9539
16-bit I/O port.
This driver can also be built as a module. If so, the module
- will be called pca9539.
+ will be called pca9539. Note: the Generic IRQ support for the
+ chip will only be available if the driver is built-in
+
+config GPIO_PCA9539_GENERIC_IRQ
+ bool "Generic IRQ support for PCA9539"
+ depends on GPIO_PCA9539=y && GENERIC_HARDIRQS
+ help
+ Say yes here to support the Generic IRQ for the PCA9539 on-chip
+ GPIO lines. Only pin-changed IRQs (IRQ_TYPE_EDGE_BOTH) are
+ supported in hardware.
comment "SPI GPIO expanders:"
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
index 0a3ae6a..e736dd9 100644
--- a/drivers/gpio/pca9539.c
+++ b/drivers/gpio/pca9539.c
@@ -11,6 +11,9 @@
#include
#include
+#include
+#include
+#include
#include
#include
@@ -27,9 +30,25 @@ struct pca9539_chip {
unsigned gpio_start;
uint16_t reg_output;
uint16_t reg_direction;
+ uint16_t last_input;
struct i2c_client *client;
struct gpio_chip gpio_chip;
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+ /*
+* Note: Generic IRQ is not accessible within module code, the IRQ
+* support will thus _only_ be available if the driver is built-in
+*/
+ int irq;/* IRQ for the chip itself */
+ int irq_start; /* starting IRQ for the on-chip GPIO lines */
+
+ uint16_t irq_mask;
+ uint16_t irq_falling_edge;
+ uint16_t irq_rising_edge;
+
+ struct irq_chip irq_chip;
+ struct work_struct irq_work;
+#endif
};
static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
@@ -152,6 +171,150 @@ static int pca9539_init_gpio(struct pca9539_chip *chip)
return gpiochip_add(gc);
}
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+/* FIXME: change to schedule_delayed_work() here if reading out of
+ * registers does not reflect the actual pin levels
+ */
+
+static void pca9539_irq_work(struct work_struct *work)
+{
+ struct pca9539_chip *chip;
+ uint16_t input, mask, rising, falling;
+ int ret, i;
+
+ chip = container_of(work, struct pca9539_chip, irq_work);
+
+ ret = pca9539_read_reg(chip, PCA9539_INPUT, );
+ if (ret < 0)
+ return;
+
+ mask = (input ^ chip->last_input) & chip->irq_mask;
+ rising = (input & mask) & chip->irq_rising_edge;
+ falling = (~input & mask) & chip->irq_falling_edge;
+
+ irq_enter();
+
+ for (i = 0; i < NR_PCA9539_GPIOS; i++) {
+ if ((rising | falling) & (1u << i)) {
+ int irq = chip->irq_start + i;
+ struct irq_desc *desc;
+
+ desc = irq_desc + irq;
+ desc_handle_irq(irq, desc);
+ }
+ }
+
+ irq_exit();
+
+ chip->last_input = input;
+}
+
+static void fastcall
+pca9539_irq_demux(unsigned int irq, struct irq_desc *desc)
+{
+ struct pca9539_chip *chip = desc->handler_data;
+
+ desc->chip->mask(chip->irq);
+ desc->chip->ack(chip->irq);
+
[PATCH 2.6.24-rc4-mm 2/2] gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander
This patch adds the generic IRQ support for the PCA9539 on-chip GPIOs,
platform specific code is required to keep a correct gpio_to_irq() and
irq_to_gpio() mapping.
Note: due to the inaccessibility of the generic IRQ code within modules,
this support is only available if the driver is built-in.
Signed-off-by: eric miao <[EMAIL PROTECTED]>
Acked-by: Ben Gardner <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig | 10 +++-
drivers/gpio/pca9539.c | 184
2 files changed, 193 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 6528fce..ee5b684 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -40,7 +40,15 @@ config GPIO_PCA9539
16-bit I/O port.
This driver can also be built as a module. If so, the module
- will be called pca9539.
+ will be called pca9539. Note: the Generic IRQ support for the
+ chip will only be available if the driver is built-in
+
+config GPIO_PCA9539_GENERIC_IRQ
+ bool "Generic IRQ support for PCA9539"
+ depends on GPIO_PCA9539=y
+ help
+ Say yes here to support the Generic IRQ for the PCA9539 on-chip
+ GPIO lines.
comment "SPI GPIO expanders:"
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
index 0a3ae6a..e736dd9 100644
--- a/drivers/gpio/pca9539.c
+++ b/drivers/gpio/pca9539.c
@@ -11,6 +11,9 @@
#include
#include
+#include
+#include
+#include
#include
#include
@@ -27,9 +30,25 @@ struct pca9539_chip {
unsigned gpio_start;
uint16_t reg_output;
uint16_t reg_direction;
+ uint16_t last_input;
struct i2c_client *client;
struct gpio_chip gpio_chip;
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+ /*
+* Note: Generic IRQ is not accessible within module code, the IRQ
+* support will thus _only_ be available if the driver is built-in
+*/
+ int irq;/* IRQ for the chip itself */
+ int irq_start; /* starting IRQ for the on-chip GPIO lines */
+
+ uint16_t irq_mask;
+ uint16_t irq_falling_edge;
+ uint16_t irq_rising_edge;
+
+ struct irq_chip irq_chip;
+ struct work_struct irq_work;
+#endif
};
static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
@@ -152,6 +171,150 @@ static int pca9539_init_gpio(struct pca9539_chip *chip)
return gpiochip_add(gc);
}
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+/* FIXME: change to schedule_delayed_work() here if reading out of
+ * registers does not reflect the actual pin levels
+ */
+
+static void pca9539_irq_work(struct work_struct *work)
+{
+ struct pca9539_chip *chip;
+ uint16_t input, mask, rising, falling;
+ int ret, i;
+
+ chip = container_of(work, struct pca9539_chip, irq_work);
+
+ ret = pca9539_read_reg(chip, PCA9539_INPUT, );
+ if (ret < 0)
+ return;
+
+ mask = (input ^ chip->last_input) & chip->irq_mask;
+ rising = (input & mask) & chip->irq_rising_edge;
+ falling = (~input & mask) & chip->irq_falling_edge;
+
+ irq_enter();
+
+ for (i = 0; i < NR_PCA9539_GPIOS; i++) {
+ if ((rising | falling) & (1u << i)) {
+ int irq = chip->irq_start + i;
+ struct irq_desc *desc;
+
+ desc = irq_desc + irq;
+ desc_handle_irq(irq, desc);
+ }
+ }
+
+ irq_exit();
+
+ chip->last_input = input;
+}
+
+static void fastcall
+pca9539_irq_demux(unsigned int irq, struct irq_desc *desc)
+{
+ struct pca9539_chip *chip = desc->handler_data;
+
+ desc->chip->mask(chip->irq);
+ desc->chip->ack(chip->irq);
+ schedule_work(>irq_work);
+ desc->chip->unmask(chip->irq);
+}
+
+static void pca9539_irq_mask(unsigned int irq)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc->chip_data;
+
+ chip->irq_mask &= ~(1u << (irq - chip->irq_start));
+}
+
+static void pca9539_irq_unmask(unsigned int irq)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc->chip_data;
+
+ chip->irq_mask |= 1u << (irq - chip->irq_start);
+}
+
+static void pca9539_irq_ack(unsigned int irq)
+{
+ /* unfortunately, we have to provide an empty irq_chip.ack even
+* if we do nothing here, Generic IRQ will complain otherwise
+*/
+}
+
+static int pca9539_irq_set_type(unsigned int irq, unsigned int type)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc->chip_data;
+ uint16_t mask = 1u << (irq - chip->irq_start);
+
+ if (type == IRQT_PROBE) {
+ if ((mask & chip->irq_rising
[PATCH 2.6.24-rc4-mm 1/2] gpiolib: basic support for 16-bit PCA9539 GPIO expander
1. use 16-bit register access to simplify the logic, cache OUTPUT
and DIRECTION registers for fast access
2. platform code is required to setup
a) the numbering of GPIO for PCA9539 (base and number)
c) pass "pca9539_platform_data" within "i2c_board_info"
Signed-off-by: eric miao <[EMAIL PROTECTED]>
Acked-by: Ben Gardner <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig| 10 ++
drivers/gpio/Makefile |1 +
drivers/gpio/pca9539.c | 248 +++
include/linux/i2c/pca9539.h | 18 +++
4 files changed, 277 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/pca9539.c
create mode 100644 include/linux/i2c/pca9539.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index dd9e697..6528fce 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -32,6 +32,16 @@ config GPIO_PCF857X
This driver provides an in-kernel interface to those GPIOs using
platform-neutral GPIO calls.
+config GPIO_PCA9539
+ tristate "Philips PCA9539 16-bit I/O port"
+ depends on I2C
+ help
+ If you say yes here you get support for the Philips PCA9539
+ 16-bit I/O port.
+
+ This driver can also be built as a module. If so, the module
+ will be called pca9539.
+
comment "SPI GPIO expanders:"
config GPIO_MCP23S08
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 575bb57..5f32943 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -2,3 +2,4 @@
obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
+obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
new file mode 100644
index 000..0a3ae6a
--- /dev/null
+++ b/drivers/gpio/pca9539.c
@@ -0,0 +1,248 @@
+/*
+pca9539.c - 16-bit I/O port with interrupt and reset
+
+Copyright (C) 2005 Ben Gardner <[EMAIL PROTECTED]>
+Copyright (C) 2007 Marvell Internation Ltd.
+
+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.
+*/
+
+#include
+#include
+#include
+#include
+
+#include
+
+#define NR_PCA9539_GPIOS 16
+
+#define PCA9539_INPUT 0
+#define PCA9539_OUTPUT 2
+#define PCA9539_INVERT 4
+#define PCA9539_DIRECTION 6
+
+struct pca9539_chip {
+ unsigned gpio_start;
+ uint16_t reg_output;
+ uint16_t reg_direction;
+
+ struct i2c_client *client;
+ struct gpio_chip gpio_chip;
+};
+
+static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
+{
+ return i2c_smbus_write_word_data(chip->client, reg, val);
+}
+
+static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t *val)
+{
+ int ret;
+
+ ret = i2c_smbus_read_word_data(chip->client, reg);
+ if (ret < 0) {
+ printk(KERN_ERR "%s: failed to read\n", __FUNCTION__);
+ return ret;
+ }
+
+ *val = (uint16_t)ret;
+ return 0;
+}
+
+static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ reg_val = chip->reg_direction | (1u << off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return ret;
+
+ chip->reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_direction_output(struct gpio_chip *gc,
+ unsigned off, int val)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ /* set output level */
+ if (val)
+ reg_val = chip->reg_output | (1u << off);
+ else
+ reg_val = chip->reg_output & ~(1u << off);
+
+ ret = pca9539_write_reg(chip, PCA9539_OUTPUT, reg_val);
+ if (ret)
+ return ret;
+
+ chip->reg_output = reg_val;
+
+ /* then direction */
+ reg_val = chip->reg_direction & ~(1u << off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return ret;
+
+ chip->reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_get_value(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ ret = pca9539_read_reg(chip, PCA9539_INPUT, _val);
+ if (ret < 0)
+ return ret;
+
+ return (reg_val & (1u << off)) ? 1 : 0;
+}
+
+static void pca9539_gpio_set_val
[PATCH 0/2] gpiolib: add support for PCA9539
Support for PCA9539 as a GPIO chip is separated into two patches: 0001 - gpiolib: basic support for 16-bit PCA9539 GPIO expander 0002 - gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander the 2nd one uses workqueue for IRQ handling due to the interrupt mode nature of the i2c-core, thus making it a separate patch. -- Cheers - eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] gpiolib: add support for PCA9539
Support for PCA9539 as a GPIO chip is separated into two patches: 0001 - gpiolib: basic support for 16-bit PCA9539 GPIO expander 0002 - gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander the 2nd one uses workqueue for IRQ handling due to the interrupt mode nature of the i2c-core, thus making it a separate patch. -- Cheers - eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.24-rc4-mm 1/2] gpiolib: basic support for 16-bit PCA9539 GPIO expander
1. use 16-bit register access to simplify the logic, cache OUTPUT
and DIRECTION registers for fast access
2. platform code is required to setup
a) the numbering of GPIO for PCA9539 (base and number)
c) pass pca9539_platform_data within i2c_board_info
Signed-off-by: eric miao [EMAIL PROTECTED]
Acked-by: Ben Gardner [EMAIL PROTECTED]
---
drivers/gpio/Kconfig| 10 ++
drivers/gpio/Makefile |1 +
drivers/gpio/pca9539.c | 248 +++
include/linux/i2c/pca9539.h | 18 +++
4 files changed, 277 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/pca9539.c
create mode 100644 include/linux/i2c/pca9539.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index dd9e697..6528fce 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -32,6 +32,16 @@ config GPIO_PCF857X
This driver provides an in-kernel interface to those GPIOs using
platform-neutral GPIO calls.
+config GPIO_PCA9539
+ tristate Philips PCA9539 16-bit I/O port
+ depends on I2C
+ help
+ If you say yes here you get support for the Philips PCA9539
+ 16-bit I/O port.
+
+ This driver can also be built as a module. If so, the module
+ will be called pca9539.
+
comment SPI GPIO expanders:
config GPIO_MCP23S08
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 575bb57..5f32943 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -2,3 +2,4 @@
obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
+obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
new file mode 100644
index 000..0a3ae6a
--- /dev/null
+++ b/drivers/gpio/pca9539.c
@@ -0,0 +1,248 @@
+/*
+pca9539.c - 16-bit I/O port with interrupt and reset
+
+Copyright (C) 2005 Ben Gardner [EMAIL PROTECTED]
+Copyright (C) 2007 Marvell Internation Ltd.
+
+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.
+*/
+
+#include linux/module.h
+#include linux/init.h
+#include linux/i2c.h
+#include linux/i2c/pca9539.h
+
+#include asm/gpio.h
+
+#define NR_PCA9539_GPIOS 16
+
+#define PCA9539_INPUT 0
+#define PCA9539_OUTPUT 2
+#define PCA9539_INVERT 4
+#define PCA9539_DIRECTION 6
+
+struct pca9539_chip {
+ unsigned gpio_start;
+ uint16_t reg_output;
+ uint16_t reg_direction;
+
+ struct i2c_client *client;
+ struct gpio_chip gpio_chip;
+};
+
+static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
+{
+ return i2c_smbus_write_word_data(chip-client, reg, val);
+}
+
+static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t *val)
+{
+ int ret;
+
+ ret = i2c_smbus_read_word_data(chip-client, reg);
+ if (ret 0) {
+ printk(KERN_ERR %s: failed to read\n, __FUNCTION__);
+ return ret;
+ }
+
+ *val = (uint16_t)ret;
+ return 0;
+}
+
+static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ reg_val = chip-reg_direction | (1u off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return ret;
+
+ chip-reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_direction_output(struct gpio_chip *gc,
+ unsigned off, int val)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ /* set output level */
+ if (val)
+ reg_val = chip-reg_output | (1u off);
+ else
+ reg_val = chip-reg_output ~(1u off);
+
+ ret = pca9539_write_reg(chip, PCA9539_OUTPUT, reg_val);
+ if (ret)
+ return ret;
+
+ chip-reg_output = reg_val;
+
+ /* then direction */
+ reg_val = chip-reg_direction ~(1u off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return ret;
+
+ chip-reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_get_value(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ ret = pca9539_read_reg(chip, PCA9539_INPUT, reg_val);
+ if (ret 0)
+ return ret;
+
+ return (reg_val (1u off)) ? 1 : 0;
+}
+
+static void pca9539_gpio_set_value(struct gpio_chip *gc, unsigned off, int val)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val
[PATCH 2.6.24-rc4-mm 2/2] gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander
This patch adds the generic IRQ support for the PCA9539 on-chip GPIOs,
platform specific code is required to keep a correct gpio_to_irq() and
irq_to_gpio() mapping.
Note: due to the inaccessibility of the generic IRQ code within modules,
this support is only available if the driver is built-in.
Signed-off-by: eric miao [EMAIL PROTECTED]
Acked-by: Ben Gardner [EMAIL PROTECTED]
---
drivers/gpio/Kconfig | 10 +++-
drivers/gpio/pca9539.c | 184
2 files changed, 193 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 6528fce..ee5b684 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -40,7 +40,15 @@ config GPIO_PCA9539
16-bit I/O port.
This driver can also be built as a module. If so, the module
- will be called pca9539.
+ will be called pca9539. Note: the Generic IRQ support for the
+ chip will only be available if the driver is built-in
+
+config GPIO_PCA9539_GENERIC_IRQ
+ bool Generic IRQ support for PCA9539
+ depends on GPIO_PCA9539=y
+ help
+ Say yes here to support the Generic IRQ for the PCA9539 on-chip
+ GPIO lines.
comment SPI GPIO expanders:
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
index 0a3ae6a..e736dd9 100644
--- a/drivers/gpio/pca9539.c
+++ b/drivers/gpio/pca9539.c
@@ -11,6 +11,9 @@
#include linux/module.h
#include linux/init.h
+#include linux/irq.h
+#include linux/interrupt.h
+#include linux/workqueue.h
#include linux/i2c.h
#include linux/i2c/pca9539.h
@@ -27,9 +30,25 @@ struct pca9539_chip {
unsigned gpio_start;
uint16_t reg_output;
uint16_t reg_direction;
+ uint16_t last_input;
struct i2c_client *client;
struct gpio_chip gpio_chip;
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+ /*
+* Note: Generic IRQ is not accessible within module code, the IRQ
+* support will thus _only_ be available if the driver is built-in
+*/
+ int irq;/* IRQ for the chip itself */
+ int irq_start; /* starting IRQ for the on-chip GPIO lines */
+
+ uint16_t irq_mask;
+ uint16_t irq_falling_edge;
+ uint16_t irq_rising_edge;
+
+ struct irq_chip irq_chip;
+ struct work_struct irq_work;
+#endif
};
static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
@@ -152,6 +171,150 @@ static int pca9539_init_gpio(struct pca9539_chip *chip)
return gpiochip_add(gc);
}
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+/* FIXME: change to schedule_delayed_work() here if reading out of
+ * registers does not reflect the actual pin levels
+ */
+
+static void pca9539_irq_work(struct work_struct *work)
+{
+ struct pca9539_chip *chip;
+ uint16_t input, mask, rising, falling;
+ int ret, i;
+
+ chip = container_of(work, struct pca9539_chip, irq_work);
+
+ ret = pca9539_read_reg(chip, PCA9539_INPUT, input);
+ if (ret 0)
+ return;
+
+ mask = (input ^ chip-last_input) chip-irq_mask;
+ rising = (input mask) chip-irq_rising_edge;
+ falling = (~input mask) chip-irq_falling_edge;
+
+ irq_enter();
+
+ for (i = 0; i NR_PCA9539_GPIOS; i++) {
+ if ((rising | falling) (1u i)) {
+ int irq = chip-irq_start + i;
+ struct irq_desc *desc;
+
+ desc = irq_desc + irq;
+ desc_handle_irq(irq, desc);
+ }
+ }
+
+ irq_exit();
+
+ chip-last_input = input;
+}
+
+static void fastcall
+pca9539_irq_demux(unsigned int irq, struct irq_desc *desc)
+{
+ struct pca9539_chip *chip = desc-handler_data;
+
+ desc-chip-mask(chip-irq);
+ desc-chip-ack(chip-irq);
+ schedule_work(chip-irq_work);
+ desc-chip-unmask(chip-irq);
+}
+
+static void pca9539_irq_mask(unsigned int irq)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc-chip_data;
+
+ chip-irq_mask = ~(1u (irq - chip-irq_start));
+}
+
+static void pca9539_irq_unmask(unsigned int irq)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc-chip_data;
+
+ chip-irq_mask |= 1u (irq - chip-irq_start);
+}
+
+static void pca9539_irq_ack(unsigned int irq)
+{
+ /* unfortunately, we have to provide an empty irq_chip.ack even
+* if we do nothing here, Generic IRQ will complain otherwise
+*/
+}
+
+static int pca9539_irq_set_type(unsigned int irq, unsigned int type)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct pca9539_chip *chip = desc-chip_data;
+ uint16_t mask = 1u (irq - chip-irq_start);
+
+ if (type == IRQT_PROBE) {
+ if ((mask chip-irq_rising_edge) ||
+ (mask chip-irq_falling_edge) ||
+ (mask ~chip-reg_direction
Re: [PATCH 2.6.24-rc4-mm 2/2] gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander
On Dec 10, 2007 6:14 PM, David Brownell [EMAIL PROTECTED] wrote:
On Monday 10 December 2007, eric miao wrote:
+config GPIO_PCA9539_GENERIC_IRQ
+bool Generic IRQ support for PCA9539
+depends on GPIO_PCA9539=y
Also depends on GENERIC_HARDIRQS, right? (You should let
the Kconfig UI handle indentation, too...)
Seems like doing this for an I2C chip ought to shake loose
some interesting review comments. :)
+help
+ Say yes here to support the Generic IRQ for the PCA9539 on-chip
+ GPIO lines.
This somewhat resembles the pcf857x chips in that it only support
pin-changed IRQs (IRQ_TYPE_EDGE_BOTH) in hardware. Some other I/O
expanders are a bit more flexible.
- Dave
Updated as follows:
From 486724d8b2b7a668600e38807680cc3a089ad533 Mon Sep 17 00:00:00 2001
From: eric miao [EMAIL PROTECTED]
Date: Mon, 10 Dec 2007 17:24:36 +0800
Subject: [PATCH] gpiolib: add Generic IRQ support for 16-bit PCA9539
GPIO expander
This patch adds the generic IRQ support for the PCA9539 on-chip GPIOs.
Note: due to the inaccessibility of the generic IRQ code within modules,
this support is only available if the driver is built-in.
Signed-off-by: eric miao [EMAIL PROTECTED]
Acked-by: Ben Gardner [EMAIL PROTECTED]
---
drivers/gpio/Kconfig | 11 +++-
drivers/gpio/pca9539.c | 184
2 files changed, 194 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 6528fce..f897df8 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -40,7 +40,16 @@ config GPIO_PCA9539
16-bit I/O port.
This driver can also be built as a module. If so, the module
- will be called pca9539.
+ will be called pca9539. Note: the Generic IRQ support for the
+ chip will only be available if the driver is built-in
+
+config GPIO_PCA9539_GENERIC_IRQ
+ bool Generic IRQ support for PCA9539
+ depends on GPIO_PCA9539=y GENERIC_HARDIRQS
+ help
+ Say yes here to support the Generic IRQ for the PCA9539 on-chip
+ GPIO lines. Only pin-changed IRQs (IRQ_TYPE_EDGE_BOTH) are
+ supported in hardware.
comment SPI GPIO expanders:
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
index 0a3ae6a..e736dd9 100644
--- a/drivers/gpio/pca9539.c
+++ b/drivers/gpio/pca9539.c
@@ -11,6 +11,9 @@
#include linux/module.h
#include linux/init.h
+#include linux/irq.h
+#include linux/interrupt.h
+#include linux/workqueue.h
#include linux/i2c.h
#include linux/i2c/pca9539.h
@@ -27,9 +30,25 @@ struct pca9539_chip {
unsigned gpio_start;
uint16_t reg_output;
uint16_t reg_direction;
+ uint16_t last_input;
struct i2c_client *client;
struct gpio_chip gpio_chip;
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+ /*
+* Note: Generic IRQ is not accessible within module code, the IRQ
+* support will thus _only_ be available if the driver is built-in
+*/
+ int irq;/* IRQ for the chip itself */
+ int irq_start; /* starting IRQ for the on-chip GPIO lines */
+
+ uint16_t irq_mask;
+ uint16_t irq_falling_edge;
+ uint16_t irq_rising_edge;
+
+ struct irq_chip irq_chip;
+ struct work_struct irq_work;
+#endif
};
static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
@@ -152,6 +171,150 @@ static int pca9539_init_gpio(struct pca9539_chip *chip)
return gpiochip_add(gc);
}
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+/* FIXME: change to schedule_delayed_work() here if reading out of
+ * registers does not reflect the actual pin levels
+ */
+
+static void pca9539_irq_work(struct work_struct *work)
+{
+ struct pca9539_chip *chip;
+ uint16_t input, mask, rising, falling;
+ int ret, i;
+
+ chip = container_of(work, struct pca9539_chip, irq_work);
+
+ ret = pca9539_read_reg(chip, PCA9539_INPUT, input);
+ if (ret 0)
+ return;
+
+ mask = (input ^ chip-last_input) chip-irq_mask;
+ rising = (input mask) chip-irq_rising_edge;
+ falling = (~input mask) chip-irq_falling_edge;
+
+ irq_enter();
+
+ for (i = 0; i NR_PCA9539_GPIOS; i++) {
+ if ((rising | falling) (1u i)) {
+ int irq = chip-irq_start + i;
+ struct irq_desc *desc;
+
+ desc = irq_desc + irq;
+ desc_handle_irq(irq, desc);
+ }
+ }
+
+ irq_exit();
+
+ chip-last_input = input;
+}
+
+static void fastcall
+pca9539_irq_demux(unsigned int irq, struct irq_desc *desc)
+{
+ struct pca9539_chip *chip = desc-handler_data;
+
+ desc-chip-mask(chip-irq);
+ desc-chip-ack(chip-irq);
+ schedule_work(chip-irq_work);
+ desc-chip-unmask(chip-irq);
+}
+
+static void pca9539_irq_mask(unsigned int irq)
+{
+ struct irq_desc *desc = irq_desc + irq;
+ struct
Re: [patch/rfc 2.6.24-rc3-mm] gpiolib grows a gpio_desc
On Nov 28, 2007 11:15 AM, David Brownell <[EMAIL PROTECTED]> wrote:
> Update gpiolib to use a table of per-GPIO "struct gpio_desc" instead of
> a table of "struct gpio_chip".
>
> - Change "is_out" and "requested" from arrays in "struct gpio_chip" to
>bit fields in "struct gpio_desc", eliminating ARCH_GPIOS_PER_CHIP.
>
> - Stop overloading "requested" flag with "label" tracked for debugfs.
>
> - Change gpiochip_is_requested() into a regular function, since it
>now accesses data that's not exported from the gpiolib code. Also
>change its signature, for the same reason.
>
> - Reduce default ARCH_NR_GPIOS to 256 to shrink gpio_desc table cost.
>On 32-bit platforms without debugfs, that table size is 2KB.
>
> This makes it easier to work with chips with different numbers of GPIOs,
> and to avoid holes in GPIOs number sequences. Those holes can cost a
> lot of unusable irq_desc space for GPIOs that act as IRQs.
>
> Based on a patch from Eric Miao.
>
> # NOT signed-off yet ... purely for comment. It's been sanity tested.
> ---
> The question I'm most interested in is whether it's worth paying the
> extra data memory. I'm currently leaning towards "yes", mostly since
> it'll let me be lazy about some development boards with four different
> kinds of GPIO controller, each with different numbers of GPIOs.
>
> Note that the ARM AT91 updates are against a patch which has been
> circulated for comment but not yet submitted. The at32ap and mcp23s08
> parts are currently in the MM tree. The PXA platform support didn't
> need changes; DaVinci won't either. The OMAP support (not recently
> updated) will need slightly more updates than those shown here.
>
> arch/arm/mach-at91/gpio.c|7 -
> arch/avr32/mach-at32ap/pio.c |7 -
> drivers/spi/mcp23s08.c |8 -
> include/asm-avr32/arch-at32ap/gpio.h |2
> include/asm-generic/gpio.h | 45 +---
> lib/gpiolib.c| 194
> ++-
> 6 files changed, 129 insertions(+), 134 deletions(-)
>
> --- at91.orig/arch/arm/mach-at91/gpio.c 2007-11-27 14:31:05.0 -0800
> +++ at91/arch/arm/mach-at91/gpio.c 2007-11-27 14:32:01.0 -0800
> @@ -484,7 +484,10 @@ at91_bank_show(struct seq_file *s, struc
> mdsr = __raw_readl(pio + PIO_MDSR);
>
> for (i = 0, mask = 1; i < chip->ngpio; i++, mask <<= 1) {
> - if (!gpiochip_is_requested(chip, i)) {
> + const char *label;
> +
> + label = gpiochip_is_requested(chip, i);
> + if (!label) {
> /* peripheral-A or peripheral B?
> * else unused/unrequested GPIO; ignore.
> */
> @@ -501,7 +504,7 @@ at91_bank_show(struct seq_file *s, struc
> */
> seq_printf(s, " gpio-%-3d P%c%-2d (%-12s) %s %s %s",
> chip->base + i, 'A' + bank_num, i,
> - chip->requested[i],
> + label,
> (osr & mask) ? "out" : "in ",
> (mask & pdsr) ? "hi" : "lo",
> (mask & pusr) ? " " : "up");
> --- at91.orig/arch/avr32/mach-at32ap/pio.c 2007-11-27 14:30:03.0
> -0800
> +++ at91/arch/avr32/mach-at32ap/pio.c 2007-11-27 14:30:04.0 -0800
> @@ -315,12 +315,15 @@ static void pio_bank_show(struct seq_fil
> bank = 'A' + pio->pdev->id;
>
> for (i = 0, mask = 1; i < 32; i++, mask <<= 1) {
> - if (!gpiochip_is_requested(chip, i))
> + const char *label;
> +
> + label = gpiochip_is_requested(chip, i);
> + if (!label)
> continue;
>
> seq_printf(s, " gpio-%-3d P%c%-2d (%-12s) %s %s %s",
> chip->base + i, bank, i,
> - chip->requested[i],
> + label,
> (osr & mask) ? "out" : "in ",
> (mask & pdsr) ? "hi" : "lo",
> (mask & pusr) ? " " : "up");
> --- at91.orig/drivers/spi/mcp23s08.c2007-11-27 14:29:20.0 -0800
> +++ at91/drivers/spi/mcp23s08.c 2007-11-27 14:30:04.0 -0800
> @@ -184,12 +184,14 @@ static void mcp23s08_dbg_show(struct seq
> }
>
> for (t = 0, mask = 1; t &l
Re: [patch/rfc 2.6.24-rc3-mm] gpiolib grows a gpio_desc
On Nov 28, 2007 11:15 AM, David Brownell [EMAIL PROTECTED] wrote:
Update gpiolib to use a table of per-GPIO struct gpio_desc instead of
a table of struct gpio_chip.
- Change is_out and requested from arrays in struct gpio_chip to
bit fields in struct gpio_desc, eliminating ARCH_GPIOS_PER_CHIP.
- Stop overloading requested flag with label tracked for debugfs.
- Change gpiochip_is_requested() into a regular function, since it
now accesses data that's not exported from the gpiolib code. Also
change its signature, for the same reason.
- Reduce default ARCH_NR_GPIOS to 256 to shrink gpio_desc table cost.
On 32-bit platforms without debugfs, that table size is 2KB.
This makes it easier to work with chips with different numbers of GPIOs,
and to avoid holes in GPIOs number sequences. Those holes can cost a
lot of unusable irq_desc space for GPIOs that act as IRQs.
Based on a patch from Eric Miao.
# NOT signed-off yet ... purely for comment. It's been sanity tested.
---
The question I'm most interested in is whether it's worth paying the
extra data memory. I'm currently leaning towards yes, mostly since
it'll let me be lazy about some development boards with four different
kinds of GPIO controller, each with different numbers of GPIOs.
Note that the ARM AT91 updates are against a patch which has been
circulated for comment but not yet submitted. The at32ap and mcp23s08
parts are currently in the MM tree. The PXA platform support didn't
need changes; DaVinci won't either. The OMAP support (not recently
updated) will need slightly more updates than those shown here.
arch/arm/mach-at91/gpio.c|7 -
arch/avr32/mach-at32ap/pio.c |7 -
drivers/spi/mcp23s08.c |8 -
include/asm-avr32/arch-at32ap/gpio.h |2
include/asm-generic/gpio.h | 45 +---
lib/gpiolib.c| 194
++-
6 files changed, 129 insertions(+), 134 deletions(-)
--- at91.orig/arch/arm/mach-at91/gpio.c 2007-11-27 14:31:05.0 -0800
+++ at91/arch/arm/mach-at91/gpio.c 2007-11-27 14:32:01.0 -0800
@@ -484,7 +484,10 @@ at91_bank_show(struct seq_file *s, struc
mdsr = __raw_readl(pio + PIO_MDSR);
for (i = 0, mask = 1; i chip-ngpio; i++, mask = 1) {
- if (!gpiochip_is_requested(chip, i)) {
+ const char *label;
+
+ label = gpiochip_is_requested(chip, i);
+ if (!label) {
/* peripheral-A or peripheral B?
* else unused/unrequested GPIO; ignore.
*/
@@ -501,7 +504,7 @@ at91_bank_show(struct seq_file *s, struc
*/
seq_printf(s, gpio-%-3d P%c%-2d (%-12s) %s %s %s,
chip-base + i, 'A' + bank_num, i,
- chip-requested[i],
+ label,
(osr mask) ? out : in ,
(mask pdsr) ? hi : lo,
(mask pusr) ?: up);
--- at91.orig/arch/avr32/mach-at32ap/pio.c 2007-11-27 14:30:03.0
-0800
+++ at91/arch/avr32/mach-at32ap/pio.c 2007-11-27 14:30:04.0 -0800
@@ -315,12 +315,15 @@ static void pio_bank_show(struct seq_fil
bank = 'A' + pio-pdev-id;
for (i = 0, mask = 1; i 32; i++, mask = 1) {
- if (!gpiochip_is_requested(chip, i))
+ const char *label;
+
+ label = gpiochip_is_requested(chip, i);
+ if (!label)
continue;
seq_printf(s, gpio-%-3d P%c%-2d (%-12s) %s %s %s,
chip-base + i, bank, i,
- chip-requested[i],
+ label,
(osr mask) ? out : in ,
(mask pdsr) ? hi : lo,
(mask pusr) ?: up);
--- at91.orig/drivers/spi/mcp23s08.c2007-11-27 14:29:20.0 -0800
+++ at91/drivers/spi/mcp23s08.c 2007-11-27 14:30:04.0 -0800
@@ -184,12 +184,14 @@ static void mcp23s08_dbg_show(struct seq
}
for (t = 0, mask = 1; t 8; t++, mask = 1) {
- if (!gpiochip_is_requested(chip, t))
+ const char *label;
+
+ label = gpiochip_is_requested(chip, t);
+ if (!label)
continue;
seq_printf(s, gpio-%-3d P%c.%d (%-12s) %s %s %s,
- chip-base + t, bank, t,
- chip-requested[t],
+ chip-base + t, bank, t, label,
(mcp-cache[MCP_IODIR] mask) ? in : out,
(mcp-cache[MCP_GPIO] mask) ? hi : lo,
(mcp-cache[MCP_GPPU] mask) ?: up);
--- at91.orig/include/asm-avr32/arch-at32ap/gpio.h 2007-11-27
14:30:03.0
Re: [patch/rfc 1/4] GPIO implementation framework
pio);
/* now we know the gpio is valid and chip won't vanish */
@@ -238,7 +218,7 @@ int gpio_direction_input(unsigned gpio)
status = chip->direction_input(chip, gpio);
if (status == 0)
- clear_bit(gpio, chip->is_out);
+ desc->is_out = 0;
return status;
fail:
spin_unlock_irqrestore(_lock, flags);
@@ -250,17 +230,22 @@ int gpio_direction_output(unsigned gpio, int value)
{
unsigned long flags;
struct gpio_chip*chip;
+ struct gpio_desc*desc;
int status = -EINVAL;
spin_lock_irqsave(_lock, flags);
- chip = gpio_to_chip(gpio);
+ desc = _desc[gpio];
+ chip = desc->chip;
+
+ gpio_ensure_requested(desc, gpio);
+
if (!chip || !chip->set || !chip->direction_output)
goto fail;
+
gpio -= chip->base;
if (gpio >= chip->ngpio)
goto fail;
- gpio_ensure_requested(chip, gpio);
/* now we know the gpio is valid and chip won't vanish */
@@ -270,7 +255,7 @@ int gpio_direction_output(unsigned gpio, int value)
status = chip->direction_output(chip, gpio, value);
if (status == 0)
- set_bit(gpio, chip->is_out);
+ desc->is_out = 1;
return status;
fail:
spin_unlock_irqrestore(_lock, flags);
@@ -363,29 +348,39 @@ EXPORT_SYMBOL_GPL(gpio_set_value_cansleep);
#include
#include
-
-static void gpiolib_dbg_show(struct seq_file *s, struct gpio_chip *chip)
+static int gpiolib_show(struct seq_file *s, void *unused)
{
- unsignedi;
+ unsignedgpio = 0;
+ unsignedoffset;
+
+ /* REVISIT this isn't locked against gpio_chip removal ... */
- for (i = 0; i < chip->ngpio; i++) {
- unsignedgpio;
- int is_out;
+ seq_printf(s, "gpio chip_namerequested direction value irq\n");
- if (!chip->requested[i])
+ while (gpio < ARCH_NR_GPIOS) {
+ struct gpio_desc *desc = _desc[gpio];
+ struct gpio_chip *chip = desc->chip;
+
+ if (chip == NULL)
continue;
- gpio = chip->base + i;
- is_out = test_bit(i, chip->is_out);
+ if (chip->dbg_show) {
+ chip->dbg_show(s, chip);
+ gpio += chip->ngpio;
+ continue;
+ }
+
+ offset = gpio - chip->base;
- seq_printf(s, " gpio-%-3d (%-12s) %s %s",
- gpio, chip->requested[i],
- is_out ? "out" : "in ",
- chip->get
- ? (chip->get(chip, i) ? "hi" : "lo")
- : "? ");
+ seq_printf(s, " %3d %11.11s %10.10s %9.9s %5.5s", gpio,
+ chip->label,
+ desc->requested_label,
+ (desc->is_out) ? "out" : "in",
+ (chip->get) ?
+ (chip->get(chip, offset) ? "hi" : "lo")
+ : "?");
- if (!is_out) {
+ if (!desc->is_out) {
int irq = gpio_to_irq(gpio);
struct irq_desc *desc = irq_desc + irq;
@@ -430,32 +425,7 @@ static void gpiolib_dbg_show(struct seq_file *s,
struct gpio_chip *chip)
}
seq_printf(s, "\n");
- }
-}
-
-static int gpiolib_show(struct seq_file *s, void *unused)
-{
- struct gpio_chip*chip;
- unsignedid;
- int started = 0;
-
- /* REVISIT this isn't locked against gpio_chip removal ... */
-
- for (id = 0; id < ARRAY_SIZE(chips); id++) {
- chip = chips[id];
- if (!chip)
- continue;
-
- seq_printf(s, "%sGPIOs %d-%d, %s%s:\n",
- started ? "\n" : "",
- chip->base, chip->base + chip->ngpio - 1,
- chip->label ? : "generic",
- chip->can_sleep ? ", can sleep" : "");
- started = 1;
- if (chip->dbg_show)
- chip->dbg_show(s, chip);
- else
- gpiolib_dbg_show(s, chip);
+ gpio++;
}
return 0;
}
--
1.5.2.5.GIT
On Nov 28, 2007 3:29 AM, David Brow
Re: [patch/rfc 1/4] GPIO implementation framework
OK, here's the all-in-one patch based on David's most recent gpiolib fix,
Changes include:
1. use per gpio structure "gpio_desc", thus eliminating the restriction of
ARCH_GPIOS_PER_CHIP, thus making it possible leaving no holes in GPIOs
numbering
Note: the number of GPIOs on different GPIO expander chips may vary
much, from 1-2 GPIOs on some audio codecs to dedicated 16-pin GPIO
expander chips. The ARCH_GPIOS_PER_CHIP might not be fair enough.
this change introduces the following small changes:
a) removal of "gpio_chips[]" and use "gpio_desc[]" instead
b) move of "is_out" and "requested" from "struct gpio_chip" to "struct
gpio_desc" and make them bit fields
c) removal of "gpiochip_is_requested()", and use "gpio_desc->requested"
instead
Note: I do want a reference count field within gpio_chip to record the
number of requested GPIOs within the chip, leave this to next patch
d) make gpio_ensure_requested() use gpio_desc, and simplify the code a
bit
2. reduce ARCH_NR_GPIOS to 256, which is moderate for most sane platforms,
and thus saving some memory of the per gpio structures
3. dedicated "gpio_desc.requested_label" field for use with debugfs
4. use a loop for "gpio_desc[]" instead of a loop for "gpio_chips[]" in
gpiolib_show(), change is straight forward; since it is now per gpio
based, the gpio_chip.dbg_show() is removed as well
-- >8 ---
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 869b739..e3b2c8f 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -14,14 +14,20 @@
*/
#ifndef ARCH_NR_GPIOS
-#define ARCH_NR_GPIOS 512
-#endif
-
-#ifndef ARCH_GPIOS_PER_CHIP
-#define ARCH_GPIOS_PER_CHIPBITS_PER_LONG
+#define ARCH_NR_GPIOS 256
#endif
struct seq_file;
+struct gpio_chip;
+
+struct gpio_desc {
+ struct gpio_chip*chip;
+ unsignedis_out:1;
+ unsignedrequested:1;
+#ifdef CONFIG_DEBUG_FS
+ const char *requested_label;
+#endif
+};
/**
* struct gpio_chip - abstract a GPIO controller
@@ -41,8 +47,6 @@ struct seq_file;
* (base + ngpio - 1).
* @can_sleep: flag must be set iff get()/set() methods sleep, as they
* must while accessing GPIO expander chips over I2C or SPI
- * @is_out: bit array where bit N is true iff GPIO with offset N has been
- * called successfully to configure this as an output
*
* A gpio_chip can help platforms abstract various sources of GPIOs so
* they can all be accessed through a common programing interface.
@@ -65,37 +69,11 @@ struct gpio_chip {
unsigned offset, int value);
void(*set)(struct gpio_chip *chip,
unsigned offset, int value);
- void(*dbg_show)(struct seq_file *s,
- struct gpio_chip *chip);
int base;
u16 ngpio;
unsignedcan_sleep:1;
-
- /* other fields are modified by the gpio library only */
- DECLARE_BITMAP(is_out, ARCH_GPIOS_PER_CHIP);
-
-#ifdef CONFIG_DEBUG_FS
- /* fat bits */
- const char *requested[ARCH_GPIOS_PER_CHIP];
-#else
- /* thin bits */
- DECLARE_BITMAP(requested, ARCH_GPIOS_PER_CHIP);
-#endif
};
-/* returns true iff a given gpio signal has been requested;
- * primarily for code dumping gpio_chip state.
- */
-static inline int
-gpiochip_is_requested(struct gpio_chip *chip, unsigned offset)
-{
-#ifdef CONFIG_DEBUG_FS
- return chip->requested[offset] != NULL;
-#else
- return test_bit(offset, chip->requested);
-#endif
-}
-
/* add/remove chips */
extern int gpiochip_add(struct gpio_chip *chip);
extern int __must_check gpiochip_remove(struct gpio_chip *chip);
diff --git a/lib/gpiolib.c b/lib/gpiolib.c
index a853715..f24182e 100644
--- a/lib/gpiolib.c
+++ b/lib/gpiolib.c
@@ -28,39 +28,30 @@
#defineextra_checks0
#endif
-/* gpio_lock protects the table of chips and gpio_chip->requested.
+/* gpio_lock protects the table of gpio_desc[] and desc->requested.
* While any GPIO is requested, its gpio_chip is not removable;
* each GPIO's "requested" flag serves as a lock and refcount.
*/
static DEFINE_SPINLOCK(gpio_lock);
-static struct gpio_chip *chips[DIV_ROUND_UP(ARCH_NR_GPIOS,
- ARCH_GPIOS_PER_CHIP)];
-
+struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
/* Warn when drivers omit gpio_request() calls -- legal but
* ill-advised when setting direction, and otherwise illegal.
*/
-static void gpio_ensure_requested(struct gpio_chip *chip, unsigned offset)
+static void gpio_ensure_requested(struct gpio_desc *desc, unsigned gpio)
{
- int requested;
-
#ifdef CONFIG_DEBUG_FS
- requested = (int)
Re: [patch/rfc 1/4] GPIO implementation framework
OK, here's the all-in-one patch based on David's most recent gpiolib fix,
Changes include:
1. use per gpio structure gpio_desc, thus eliminating the restriction of
ARCH_GPIOS_PER_CHIP, thus making it possible leaving no holes in GPIOs
numbering
Note: the number of GPIOs on different GPIO expander chips may vary
much, from 1-2 GPIOs on some audio codecs to dedicated 16-pin GPIO
expander chips. The ARCH_GPIOS_PER_CHIP might not be fair enough.
this change introduces the following small changes:
a) removal of gpio_chips[] and use gpio_desc[] instead
b) move of is_out and requested from struct gpio_chip to struct
gpio_desc and make them bit fields
c) removal of gpiochip_is_requested(), and use gpio_desc-requested
instead
Note: I do want a reference count field within gpio_chip to record the
number of requested GPIOs within the chip, leave this to next patch
d) make gpio_ensure_requested() use gpio_desc, and simplify the code a
bit
2. reduce ARCH_NR_GPIOS to 256, which is moderate for most sane platforms,
and thus saving some memory of the per gpio structures
3. dedicated gpio_desc.requested_label field for use with debugfs
4. use a loop for gpio_desc[] instead of a loop for gpio_chips[] in
gpiolib_show(), change is straight forward; since it is now per gpio
based, the gpio_chip.dbg_show() is removed as well
-- 8 ---
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 869b739..e3b2c8f 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -14,14 +14,20 @@
*/
#ifndef ARCH_NR_GPIOS
-#define ARCH_NR_GPIOS 512
-#endif
-
-#ifndef ARCH_GPIOS_PER_CHIP
-#define ARCH_GPIOS_PER_CHIPBITS_PER_LONG
+#define ARCH_NR_GPIOS 256
#endif
struct seq_file;
+struct gpio_chip;
+
+struct gpio_desc {
+ struct gpio_chip*chip;
+ unsignedis_out:1;
+ unsignedrequested:1;
+#ifdef CONFIG_DEBUG_FS
+ const char *requested_label;
+#endif
+};
/**
* struct gpio_chip - abstract a GPIO controller
@@ -41,8 +47,6 @@ struct seq_file;
* (base + ngpio - 1).
* @can_sleep: flag must be set iff get()/set() methods sleep, as they
* must while accessing GPIO expander chips over I2C or SPI
- * @is_out: bit array where bit N is true iff GPIO with offset N has been
- * called successfully to configure this as an output
*
* A gpio_chip can help platforms abstract various sources of GPIOs so
* they can all be accessed through a common programing interface.
@@ -65,37 +69,11 @@ struct gpio_chip {
unsigned offset, int value);
void(*set)(struct gpio_chip *chip,
unsigned offset, int value);
- void(*dbg_show)(struct seq_file *s,
- struct gpio_chip *chip);
int base;
u16 ngpio;
unsignedcan_sleep:1;
-
- /* other fields are modified by the gpio library only */
- DECLARE_BITMAP(is_out, ARCH_GPIOS_PER_CHIP);
-
-#ifdef CONFIG_DEBUG_FS
- /* fat bits */
- const char *requested[ARCH_GPIOS_PER_CHIP];
-#else
- /* thin bits */
- DECLARE_BITMAP(requested, ARCH_GPIOS_PER_CHIP);
-#endif
};
-/* returns true iff a given gpio signal has been requested;
- * primarily for code dumping gpio_chip state.
- */
-static inline int
-gpiochip_is_requested(struct gpio_chip *chip, unsigned offset)
-{
-#ifdef CONFIG_DEBUG_FS
- return chip-requested[offset] != NULL;
-#else
- return test_bit(offset, chip-requested);
-#endif
-}
-
/* add/remove chips */
extern int gpiochip_add(struct gpio_chip *chip);
extern int __must_check gpiochip_remove(struct gpio_chip *chip);
diff --git a/lib/gpiolib.c b/lib/gpiolib.c
index a853715..f24182e 100644
--- a/lib/gpiolib.c
+++ b/lib/gpiolib.c
@@ -28,39 +28,30 @@
#defineextra_checks0
#endif
-/* gpio_lock protects the table of chips and gpio_chip-requested.
+/* gpio_lock protects the table of gpio_desc[] and desc-requested.
* While any GPIO is requested, its gpio_chip is not removable;
* each GPIO's requested flag serves as a lock and refcount.
*/
static DEFINE_SPINLOCK(gpio_lock);
-static struct gpio_chip *chips[DIV_ROUND_UP(ARCH_NR_GPIOS,
- ARCH_GPIOS_PER_CHIP)];
-
+struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
/* Warn when drivers omit gpio_request() calls -- legal but
* ill-advised when setting direction, and otherwise illegal.
*/
-static void gpio_ensure_requested(struct gpio_chip *chip, unsigned offset)
+static void gpio_ensure_requested(struct gpio_desc *desc, unsigned gpio)
{
- int requested;
-
#ifdef CONFIG_DEBUG_FS
- requested = (int) chip-requested[offset];
- if (!requested)
Re: [patch/rfc 1/4] GPIO implementation framework
:
spin_unlock_irqrestore(gpio_lock, flags);
@@ -250,17 +230,22 @@ int gpio_direction_output(unsigned gpio, int value)
{
unsigned long flags;
struct gpio_chip*chip;
+ struct gpio_desc*desc;
int status = -EINVAL;
spin_lock_irqsave(gpio_lock, flags);
- chip = gpio_to_chip(gpio);
+ desc = gpio_desc[gpio];
+ chip = desc-chip;
+
+ gpio_ensure_requested(desc, gpio);
+
if (!chip || !chip-set || !chip-direction_output)
goto fail;
+
gpio -= chip-base;
if (gpio = chip-ngpio)
goto fail;
- gpio_ensure_requested(chip, gpio);
/* now we know the gpio is valid and chip won't vanish */
@@ -270,7 +255,7 @@ int gpio_direction_output(unsigned gpio, int value)
status = chip-direction_output(chip, gpio, value);
if (status == 0)
- set_bit(gpio, chip-is_out);
+ desc-is_out = 1;
return status;
fail:
spin_unlock_irqrestore(gpio_lock, flags);
@@ -363,29 +348,39 @@ EXPORT_SYMBOL_GPL(gpio_set_value_cansleep);
#include linux/debugfs.h
#include linux/seq_file.h
-
-static void gpiolib_dbg_show(struct seq_file *s, struct gpio_chip *chip)
+static int gpiolib_show(struct seq_file *s, void *unused)
{
- unsignedi;
+ unsignedgpio = 0;
+ unsignedoffset;
+
+ /* REVISIT this isn't locked against gpio_chip removal ... */
- for (i = 0; i chip-ngpio; i++) {
- unsignedgpio;
- int is_out;
+ seq_printf(s, gpio chip_namerequested direction value irq\n);
- if (!chip-requested[i])
+ while (gpio ARCH_NR_GPIOS) {
+ struct gpio_desc *desc = gpio_desc[gpio];
+ struct gpio_chip *chip = desc-chip;
+
+ if (chip == NULL)
continue;
- gpio = chip-base + i;
- is_out = test_bit(i, chip-is_out);
+ if (chip-dbg_show) {
+ chip-dbg_show(s, chip);
+ gpio += chip-ngpio;
+ continue;
+ }
+
+ offset = gpio - chip-base;
- seq_printf(s, gpio-%-3d (%-12s) %s %s,
- gpio, chip-requested[i],
- is_out ? out : in ,
- chip-get
- ? (chip-get(chip, i) ? hi : lo)
- : ? );
+ seq_printf(s, %3d %11.11s %10.10s %9.9s %5.5s, gpio,
+ chip-label,
+ desc-requested_label,
+ (desc-is_out) ? out : in,
+ (chip-get) ?
+ (chip-get(chip, offset) ? hi : lo)
+ : ?);
- if (!is_out) {
+ if (!desc-is_out) {
int irq = gpio_to_irq(gpio);
struct irq_desc *desc = irq_desc + irq;
@@ -430,32 +425,7 @@ static void gpiolib_dbg_show(struct seq_file *s,
struct gpio_chip *chip)
}
seq_printf(s, \n);
- }
-}
-
-static int gpiolib_show(struct seq_file *s, void *unused)
-{
- struct gpio_chip*chip;
- unsignedid;
- int started = 0;
-
- /* REVISIT this isn't locked against gpio_chip removal ... */
-
- for (id = 0; id ARRAY_SIZE(chips); id++) {
- chip = chips[id];
- if (!chip)
- continue;
-
- seq_printf(s, %sGPIOs %d-%d, %s%s:\n,
- started ? \n : ,
- chip-base, chip-base + chip-ngpio - 1,
- chip-label ? : generic,
- chip-can_sleep ? , can sleep : );
- started = 1;
- if (chip-dbg_show)
- chip-dbg_show(s, chip);
- else
- gpiolib_dbg_show(s, chip);
+ gpio++;
}
return 0;
}
--
1.5.2.5.GIT
On Nov 28, 2007 3:29 AM, David Brownell [EMAIL PROTECTED] wrote:
On Tuesday 27 November 2007, eric miao wrote:
status = chip-direction_input(chip, gpio);
-if (status == 0)
-clear_bit(gpio, chip-is_out);
+if (status)
+desc-is_out = 0;
You added that same bug in two places (direction_output too).
Only zero status means success; otherwise it's negative errno.
Clearly this patch wasn't tested at all.
--
Cheers
- eric
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 0/4 Support for Toshiba TMIO multifunction devices
On Nov 21, 2007 11:54 AM, ian <[EMAIL PROTECTED]> wrote: > On Wed, 2007-11-21 at 10:23 +0800, eric miao wrote: > > Roughly went through the patch, looks good, here comes the remind, though > > :-) > > > > 1. is it possible to use some name other than "soc_core", maybe > > "tmio_core" so that other multifunction chips sharing a core base > > will live easier. > > It's (soc-core) not tmio MFD specific - its already used by other MFD > chips (although obviously not ones in mainline (yet!) > > it might be better named 'mfd-core' though, as thats its intended use... > > > 2. those C++ style comments "//" are not so pleasant... > > Should I clean them up and resubmit? > Will be nice then, anyway, could you inline them so others can comment? > More to the point, who should I be submitting them to? the files under > arm/ are obviously for RMK to peruse, but I couldnt find an entry for > drivers/mfd in MAINTAINERS... > Well, I briefly went through the git history, looks like Russell is the proper one you could sent them to (probably not) :-) > > -- Cheers - eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 0/4 Support for Toshiba TMIO multifunction devices
Roughly went through the patch, looks good, here comes the remind, though :-) 1. is it possible to use some name other than "soc_core", maybe "tmio_core" so that other multifunction chips sharing a core base will live easier. 2. those C++ style comments "//" are not so pleasant... - eric On Nov 21, 2007 6:20 AM, ian <[EMAIL PROTECTED]> wrote: > On Wed, 2007-11-21 at 01:04 +0300, Dmitry Baryshkov wrote: > > Just to note, that there is an alternative implementation for at least > > the tc6393 chip devices. Most current version of those patches can be > > found in the OpenEmbedded monotone. > > Yes, this is true. The core code in both cases originates from my and > Dirks work. > > I'd just like to get something pushed up to mainline so that work can > begin on expanding the number of chips supported. > > This would include the ASICs found in many iPAQ PDAs (their MMC module > seems to be an IRQ-less TMIO chip). > > I havent submitted the subdevice drivers yet, only the base/core > drivers. > > The OE versions probably have better USB and video subdevice support > (which I shall evaluate as I go on), wheras the NAND flash and MMC > drivers in hh.org are probably more up to date (I run root on SD usinf > the hh.org tmio_mmc driver on all three of the MFD chips in this patch > series on a daily basis). > > merging the best of these patch series is my goal and it shouldnt be too > hard. > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Cheers - eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
