[PATCH 0/5] OMAP3530evm misc fixes for linux-omap

[PATCH 0/5] OMAP3530evm misc fixes for linux-omap

[Zumeng Chen]

These patches fix misc problems when reflash ti-omap3530evm for
master branch on Linux-omap. Currently they have been tested on
3530evm but were not ack'ed.

Most of them are the leftovers from the great original developers
with my the latest updates for adapting to the current kernel, so
I add you directly into SOB(If not proper, please let me know).

The series is based upon the latest linux-omap master branch from
Tony (3.5-rc1).

Zumeng Chen (5):
      ARM: OMAP3EVM: Add NAND flash definition
      ARM: OMAP3EVM: Adding USB internal LDOs board file
      ARM: omap3evm: enable VBUS switch for EHCI tranceiver
      MFD: OMAP3EVM: USB: cosmetic fix to failed parent clk set
      Input: ads7846: set proper debounce time in driver level

 arch/arm/mach-omap2/board-omap3evm.c |   75 ++++++++++++++++++++++++++++++++++
 drivers/input/touchscreen/ads7846.c  |    2 +
 drivers/mfd/omap-usb-host.c          |    4 +-
 3 files changed, 80 insertions(+), 1 deletions(-)

[PATCH 1/5] ARM: OMAP3EVM: Add NAND flash definition

[Zumeng Chen]

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Tested-by: Zumeng Chen <zumeng.chen@gmail.com>
---
 arch/arm/mach-omap2/board-omap3evm.c |   39 ++++++++++++++++++++++++++++++++++
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 639bd07..fef911d 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -24,6 +24,10 @@
 #include <linux/leds.h>
 #include <linux/interrupt.h>
 
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/nand.h>
+
 #include <linux/spi/spi.h>
 #include <linux/spi/ads7846.h>
 #include <linux/i2c/twl.h>
@@ -43,6 +47,7 @@
 
 #include <plat/board.h>
 #include <plat/usb.h>
+#include <plat/nand.h>
 #include "common.h"
 #include <plat/mcspi.h>
 #include <video/omapdss.h>
@@ -607,6 +612,37 @@ static struct regulator_consumer_supply dummy_supplies[] = {
 	REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
 };
 
+static struct mtd_partition omap3evm_nand_partitions[] = {
+	/* All the partition sizes are listed in terms of NAND block size */
+	{
+		.name           = "xloader-nand",
+		.offset         = 0,
+		.size           = 4*(SZ_128K),
+		.mask_flags     = MTD_WRITEABLE
+	},
+	{
+		.name           = "uboot-nand",
+		.offset         = MTDPART_OFS_APPEND,
+		.size           = 14*(SZ_128K),
+		.mask_flags     = MTD_WRITEABLE
+	},
+	{
+		.name           = "params-nand",
+		.offset         = MTDPART_OFS_APPEND,
+		.size           = 2*(SZ_128K)
+	},
+	{
+		.name           = "linux-nand",
+		.offset         = MTDPART_OFS_APPEND,
+		.size           = 40*(SZ_128K)
+	},
+	{
+		.name           = "jffs2-nand",
+		.size           = MTDPART_SIZ_FULL,
+		.offset         = MTDPART_OFS_APPEND,
+	},
+};
+
 static void __init omap3_evm_init(void)
 {
 	struct omap_board_mux *obm;
@@ -656,6 +692,9 @@ static void __init omap3_evm_init(void)
 	}
 	usb_musb_init(&musb_board_data);
 	usbhs_init(&usbhs_bdata);
+	omap_nand_flash_init(NAND_BUSWIDTH_16, omap3evm_nand_partitions,
+			     ARRAY_SIZE(omap3evm_nand_partitions));
+
 	omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
 	omap3evm_init_smsc911x();
 	omap3_evm_display_init();
-- 
1.7.5.4

[PATCH 1/5] ARM: OMAP3EVM: Add NAND flash definition

[Jon Hunter]

On 06/11/2012 09:00 AM, Zumeng Chen wrote:
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Tested-by: Zumeng Chen <zumeng.chen@gmail.com>

I think that you need to have something in the changelog above, even if
this is a trivial change.

> ---
>  arch/arm/mach-omap2/board-omap3evm.c |   39 ++++++++++++++++++++++++++++++++++
>  1 files changed, 39 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
> index 639bd07..fef911d 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -24,6 +24,10 @@
>  #include <linux/leds.h>
>  #include <linux/interrupt.h>
>  
> +#include <linux/mtd/mtd.h>
> +#include <linux/mtd/partitions.h>
> +#include <linux/mtd/nand.h>
> +
>  #include <linux/spi/spi.h>
>  #include <linux/spi/ads7846.h>
>  #include <linux/i2c/twl.h>
> @@ -43,6 +47,7 @@
>  
>  #include <plat/board.h>
>  #include <plat/usb.h>
> +#include <plat/nand.h>
>  #include "common.h"
>  #include <plat/mcspi.h>
>  #include <video/omapdss.h>
> @@ -607,6 +612,37 @@ static struct regulator_consumer_supply dummy_supplies[] = {
>  	REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
>  };
>  
> +static struct mtd_partition omap3evm_nand_partitions[] = {
> +	/* All the partition sizes are listed in terms of NAND block size */
> +	{
> +		.name           = "xloader-nand",

Is this the only non-volatile memory on the EVM? If so, you can probably
drop the "-nand" part from the name. Also, if you look at other board
files to be consistent in naming they use "X-Loader".

> +		.offset         = 0,
> +		.size           = 4*(SZ_128K),
> +		.mask_flags     = MTD_WRITEABLE
> +	},
> +	{
> +		.name           = "uboot-nand",

"U-Boot"

> +		.offset         = MTDPART_OFS_APPEND,
> +		.size           = 14*(SZ_128K),
> +		.mask_flags     = MTD_WRITEABLE
> +	},
> +	{
> +		.name           = "params-nand",

"U-Boot Env"

> +		.offset         = MTDPART_OFS_APPEND,
> +		.size           = 2*(SZ_128K)
> +	},
> +	{
> +		.name           = "linux-nand",

"Kernel"

> +		.offset         = MTDPART_OFS_APPEND,
> +		.size           = 40*(SZ_128K)
> +	},
> +	{
> +		.name           = "jffs2-nand",

"File System"
> +		.size           = MTDPART_SIZ_FULL,
> +		.offset         = MTDPART_OFS_APPEND,
> +	},
> +};
> +
>  static void __init omap3_evm_init(void)
>  {
>  	struct omap_board_mux *obm;
> @@ -656,6 +692,9 @@ static void __init omap3_evm_init(void)
>  	}
>  	usb_musb_init(&musb_board_data);
>  	usbhs_init(&usbhs_bdata);
> +	omap_nand_flash_init(NAND_BUSWIDTH_16, omap3evm_nand_partitions,
> +			     ARRAY_SIZE(omap3evm_nand_partitions));
> +
>  	omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
>  	omap3evm_init_smsc911x();
>  	omap3_evm_display_init();

Cheers
Jon

[PATCH 1/5] ARM: OMAP3EVM: Add NAND flash definition

[Zumeng Chen]

Hi Jon,

Many thanks for your quickly reply, please see my in-line reply

2012/6/11 Jon Hunter <jon-hunter@ti.com>

>
>
> On 06/11/2012 09:00 AM, Zumeng Chen wrote:
> > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > Tested-by: Zumeng Chen <zumeng.chen@gmail.com>
>
> I think that you need to have something in the changelog above, even if
> this is a trivial change.
>
Yes, I'll add it in V2

>
> > ---
> >  arch/arm/mach-omap2/board-omap3evm.c |   39
> ++++++++++++++++++++++++++++++++++
> >  1 files changed, 39 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-omap3evm.c
> b/arch/arm/mach-omap2/board-omap3evm.c
> > index 639bd07..fef911d 100644
> > --- a/arch/arm/mach-omap2/board-omap3evm.c
> > +++ b/arch/arm/mach-omap2/board-omap3evm.c
> > @@ -24,6 +24,10 @@
> >  #include <linux/leds.h>
> >  #include <linux/interrupt.h>
> >
> > +#include <linux/mtd/mtd.h>
> > +#include <linux/mtd/partitions.h>
> > +#include <linux/mtd/nand.h>
> > +
> >  #include <linux/spi/spi.h>
> >  #include <linux/spi/ads7846.h>
> >  #include <linux/i2c/twl.h>
> > @@ -43,6 +47,7 @@
> >
> >  #include <plat/board.h>
> >  #include <plat/usb.h>
> > +#include <plat/nand.h>
> >  #include "common.h"
> >  #include <plat/mcspi.h>
> >  #include <video/omapdss.h>
> > @@ -607,6 +612,37 @@ static struct regulator_consumer_supply
> dummy_supplies[] = {
> >       REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
> >  };
> >
> > +static struct mtd_partition omap3evm_nand_partitions[] = {
> > +     /* All the partition sizes are listed in terms of NAND block size
> */
> > +     {
> > +             .name           = "xloader-nand",
>
> Is this the only non-volatile memory on the EVM? If so, you can probably
> drop the "-nand" part from the name. Also, if you look at other board
> files to be consistent in naming they use "X-Loader".
>
As this kind usage, yes, the only memory. so I'll remove "nand" for all.

>
> > +             .offset         = 0,
> > +             .size           = 4*(SZ_128K),
> > +             .mask_flags     = MTD_WRITEABLE
> > +     },
> > +     {
> > +             .name           = "uboot-nand",
>
> "U-Boot"
>
> > +             .offset         = MTDPART_OFS_APPEND,
> > +             .size           = 14*(SZ_128K),
> > +             .mask_flags     = MTD_WRITEABLE
> > +     },
> > +     {
> > +             .name           = "params-nand",
>
> "U-Boot Env"
>
> > +             .offset         = MTDPART_OFS_APPEND,
> > +             .size           = 2*(SZ_128K)
> > +     },
> > +     {
> > +             .name           = "linux-nand",
>
> "Kernel"
>
> > +             .offset         = MTDPART_OFS_APPEND,
> > +             .size           = 40*(SZ_128K)
> > +     },
> > +     {
> > +             .name           = "jffs2-nand",
>
> "File System"
> > +             .size           = MTDPART_SIZ_FULL,
> > +             .offset         = MTDPART_OFS_APPEND,
> > +     },
> > +};
> > +
> >  static void __init omap3_evm_init(void)
> >  {
> >       struct omap_board_mux *obm;
> > @@ -656,6 +692,9 @@ static void __init omap3_evm_init(void)
> >       }
> >       usb_musb_init(&musb_board_data);
> >       usbhs_init(&usbhs_bdata);
> > +     omap_nand_flash_init(NAND_BUSWIDTH_16, omap3evm_nand_partitions,
> > +                          ARRAY_SIZE(omap3evm_nand_partitions));
> > +
> >       omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
> >       omap3evm_init_smsc911x();
> >       omap3_evm_display_init();
>
All fixed in V2.

Regards,
Zumeng

>
> Cheers
> Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120612/cad88cf4/attachment-0001.html>

[PATCH 2/5] ARM: OMAP3EVM: Adding USB internal LDOs board file

[Zumeng Chen]

EHCI PHY requires these regulators:
        EVM Rev >=E  --> VAUX2
        EVM Rev < E  --> VUSB1V5, VUSB1V8

Adding USB internal LDOs (vusb1v5 & vusb1v8) and VAUX2 to omap3evm
board file. Also removing vaux2_{1/2/3} supplies as they are not
used on omap3 evm.

But we need not to add vaux2 in twl4030_platform_data since it will
be added conditionally.

Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com>
---
 arch/arm/mach-omap2/board-omap3evm.c |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index fef911d..7e5e18f 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -466,6 +466,30 @@ struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
 };
 #endif
 
+/* VAUX2 for USB */
+static struct regulator_consumer_supply omap3evm_vaux2_supplies[] = {
+	REGULATOR_SUPPLY("VDD_CSIPHY1", "omap3isp"),	/* OMAP ISP */
+	REGULATOR_SUPPLY("VDD_CSIPHY2", "omap3isp"),	/* OMAP ISP */
+	REGULATOR_SUPPLY("hsusb1", "ehci-omap.0"),
+	{
+		.supply		= "vaux2",
+	}
+};
+
+static struct regulator_init_data omap3evm_vaux2 = {
+	.constraints = {
+		.min_uV		= 2800000,
+		.max_uV		= 2800000,
+		.apply_uV	= true,
+		.valid_modes_mask	= REGULATOR_MODE_NORMAL
+					| REGULATOR_MODE_STANDBY,
+		.valid_ops_mask		= REGULATOR_CHANGE_MODE
+					| REGULATOR_CHANGE_STATUS,
+	},
+	.num_consumer_supplies		= ARRAY_SIZE(omap3evm_vaux2_supplies),
+	.consumer_supplies		= omap3evm_vaux2_supplies,
+};
+
 static struct twl4030_platform_data omap3evm_twldata = {
 	/* platform_data for children goes here */
 	.keypad		= &omap3evm_kp_data,
@@ -659,6 +683,9 @@ static void __init omap3_evm_init(void)
 	omap_mux_init_gpio(63, OMAP_PIN_INPUT);
 	omap_hsmmc_init(mmc);
 
+	if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
+		omap3evm_twldata.vaux2 = &omap3evm_vaux2;
+
 	omap3_evm_i2c_init();
 
 	omap_display_init(&omap3_evm_dss_data);
-- 
1.7.5.4

[PATCH 3/5] ARM: omap3evm: enable VBUS switch for EHCI tranceiver

[Zumeng Chen]

TWL4030.GPIO2-...->(T2_GPIO2_3V3)U131-..>nUSB2_EN-..>U134-..>EXP_nUSB2_1V8
which starts EHCI tranceiver USB3320.

Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com>
---
 arch/arm/mach-omap2/board-omap3evm.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 7e5e18f..3806f0e 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -360,6 +360,15 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
 
 	platform_device_register(&leds_gpio);
 
+	/* Enable VBUS switch by setting TWL4030.GPIO2DIR as output
+	 * for starting USB tranceiver
+	 */
+	if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2) {
+		u8 val;
+		twl_i2c_read_u8(TWL4030_MODULE_GPIO, &val, REG_GPIODATADIR1);
+		val |= 0x04; /* TWL4030.GPIO2DIR BIT at GPIODATADIR1(0x9B) */
+		twl_i2c_write_u8(TWL4030_MODULE_GPIO, val, REG_GPIODATADIR1);
+	}
 	return 0;
 }
 
-- 
1.7.5.4

[PATCH 4/5] MFD: OMAP3EVM: USB: cosmetic fix to failed parent clk set

[Zumeng Chen]

A typo fix for this cosmetic change and mute a failed message from
a unnecessary setting of some parent clk for usbhs_omap on OMAP3EVM.

Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com>
---
 drivers/mfd/omap-usb-host.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 7e96bb2..9aaaf3c 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -698,8 +698,9 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 		goto err_usbtll_p2_fck;
 	}
 
+#ifndef CONFIG_MACH_OMAP3EVM
+	/* for OMAP3 , the clk set parent fails */
 	if (is_ehci_phy_mode(pdata->port_mode[0])) {
-		/* for OMAP3 , the clk set paretn fails */
 		ret = clk_set_parent(omap->utmi_p1_fck,
 					omap->xclk60mhsp1_ck);
 		if (ret != 0)
@@ -726,6 +727,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 			dev_err(dev, "init_60m_fclk set parent"
 				"failed error:%d\n", ret);
 	}
+#endif
 
 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "uhh");
 	if (!res) {
-- 
1.7.5.4

[PATCH 4/5] MFD: OMAP3EVM: USB: cosmetic fix to failed parent clk set

[Jon Hunter]

On 06/11/2012 09:00 AM, Zumeng Chen wrote:
> A typo fix for this cosmetic change and mute a failed message from
> a unnecessary setting of some parent clk for usbhs_omap on OMAP3EVM.
> 
> Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com>
> ---
>  drivers/mfd/omap-usb-host.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index 7e96bb2..9aaaf3c 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -698,8 +698,9 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>  		goto err_usbtll_p2_fck;
>  	}
>  
> +#ifndef CONFIG_MACH_OMAP3EVM
> +	/* for OMAP3 , the clk set parent fails */
>  	if (is_ehci_phy_mode(pdata->port_mode[0])) {
> -		/* for OMAP3 , the clk set paretn fails */
>  		ret = clk_set_parent(omap->utmi_p1_fck,
>  					omap->xclk60mhsp1_ck);
>  		if (ret != 0)

This begs the question, why is port_mode[0] set to ehci phy mode if this
is failing? Something does not seem right here but this does not look
like the right fix.

Cheers
Jon

[PATCH 4/5] MFD: OMAP3EVM: USB: cosmetic fix to failed parent clk set

[Zumeng Chen]

2012/6/11 Jon Hunter <jon-hunter@ti.com>

>
> On 06/11/2012 09:00 AM, Zumeng Chen wrote:
> > A typo fix for this cosmetic change and mute a failed message from
> > a unnecessary setting of some parent clk for usbhs_omap on OMAP3EVM.
> >
> > Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com>
> > ---
> >  drivers/mfd/omap-usb-host.c |    4 +++-
> >  1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> > index 7e96bb2..9aaaf3c 100644
> > --- a/drivers/mfd/omap-usb-host.c
> > +++ b/drivers/mfd/omap-usb-host.c
> > @@ -698,8 +698,9 @@ static int __devinit usbhs_omap_probe(struct
> platform_device *pdev)
> >               goto err_usbtll_p2_fck;
> >       }
> >
> > +#ifndef CONFIG_MACH_OMAP3EVM
> > +     /* for OMAP3 , the clk set parent fails */
> >       if (is_ehci_phy_mode(pdata->port_mode[0])) {
> > -             /* for OMAP3 , the clk set paretn fails */
> >               ret = clk_set_parent(omap->utmi_p1_fck,
> >                                       omap->xclk60mhsp1_ck);
> >               if (ret != 0)
>
> This begs the question, why is port_mode[0] set to ehci phy mode if this
> is failing? Something does not seem right here but this does not look
> like the right fix.
>
Actually, for omap3530evm, there is only port-mode[1] is valid, so
port_mode[0]
will be skipped by "if". And it will report "xclk60mhsp2_ck set parent
failed"

But why I bracket both of them, because, both xclk60mhsp2_ck and
xclk60mhsp1_ck
have dummy_ck clk for omap3530evm. So we can skip them directly.

Regards,
Zumeng

>
> Cheers
> Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120612/54329126/attachment-0001.html>

[PATCH 4/5] MFD: OMAP3EVM: USB: cosmetic fix to failed parent clk set

[Jon Hunter]

On 06/11/2012 09:30 PM, Zumeng Chen wrote:
> 
> 
> 2012/6/11 Jon Hunter <jon-hunter at ti.com <mailto:jon-hunter@ti.com>>
> 
> 
>     On 06/11/2012 09:00 AM, Zumeng Chen wrote:
>     > A typo fix for this cosmetic change and mute a failed message from
>     > a unnecessary setting of some parent clk for usbhs_omap on OMAP3EVM.
>     >
>     > Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com
>     <mailto:zumeng.chen@gmail.com>>
>     > ---
>     >  drivers/mfd/omap-usb-host.c |    4 +++-
>     >  1 files changed, 3 insertions(+), 1 deletions(-)
>     >
>     > diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>     > index 7e96bb2..9aaaf3c 100644
>     > --- a/drivers/mfd/omap-usb-host.c
>     > +++ b/drivers/mfd/omap-usb-host.c
>     > @@ -698,8 +698,9 @@ static int __devinit usbhs_omap_probe(struct
>     platform_device *pdev)
>     >               goto err_usbtll_p2_fck;
>     >       }
>     >
>     > +#ifndef CONFIG_MACH_OMAP3EVM
>     > +     /* for OMAP3 , the clk set parent fails */
>     >       if (is_ehci_phy_mode(pdata->port_mode[0])) {
>     > -             /* for OMAP3 , the clk set paretn fails */
>     >               ret = clk_set_parent(omap->utmi_p1_fck,
>     >                                       omap->xclk60mhsp1_ck);
>     >               if (ret != 0)
> 
>     This begs the question, why is port_mode[0] set to ehci phy mode if this
>     is failing? Something does not seem right here but this does not look
>     like the right fix.
> 
> Actually, for omap3530evm, there is only port-mode[1] is valid, so
> port_mode[0]
> will be skipped by "if". And it will report "xclk60mhsp2_ck set parent
> failed"
> 
> But why I bracket both of them, because, both xclk60mhsp2_ck and
> xclk60mhsp1_ck
> have dummy_ck clk for omap3530evm. So we can skip them directly.

How about something like this ...

diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 62ec5c4..c1335f1 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -149,6 +149,10 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
        if (!arch_clock || !arch_clock->clk_set_parent)
                return ret;

+       /* If the clock is a dummy clock just return */
+       if (!strcmp(clk->name, dummy_ck.name))
+               return 0;
+
        spin_lock_irqsave(&clockfw_lock, flags);
        if (clk->usecount == 0) {
                ret = arch_clock->clk_set_parent(clk, parent);

Can you give this a try?

Cheers
Jon

[PATCH 4/5] MFD: OMAP3EVM: USB: cosmetic fix to failed parent clk set

[Zumeng Chen]

2012/6/13 Jon Hunter <jon-hunter@ti.com>

>
> On 06/11/2012 09:30 PM, Zumeng Chen wrote:
> >
> >
> > 2012/6/11 Jon Hunter <jon-hunter at ti.com <mailto:jon-hunter@ti.com>>
> >
> >
> >     On 06/11/2012 09:00 AM, Zumeng Chen wrote:
> >     > A typo fix for this cosmetic change and mute a failed message from
> >     > a unnecessary setting of some parent clk for usbhs_omap on
> OMAP3EVM.
> >     >
> >     > Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com
> >     <mailto:zumeng.chen@gmail.com>>
> >     > ---
> >     >  drivers/mfd/omap-usb-host.c |    4 +++-
> >     >  1 files changed, 3 insertions(+), 1 deletions(-)
> >     >
> >     > diff --git a/drivers/mfd/omap-usb-host.c
> b/drivers/mfd/omap-usb-host.c
> >     > index 7e96bb2..9aaaf3c 100644
> >     > --- a/drivers/mfd/omap-usb-host.c
> >     > +++ b/drivers/mfd/omap-usb-host.c
> >     > @@ -698,8 +698,9 @@ static int __devinit usbhs_omap_probe(struct
> >     platform_device *pdev)
> >     >               goto err_usbtll_p2_fck;
> >     >       }
> >     >
> >     > +#ifndef CONFIG_MACH_OMAP3EVM
> >     > +     /* for OMAP3 , the clk set parent fails */
> >     >       if (is_ehci_phy_mode(pdata->port_mode[0])) {
> >     > -             /* for OMAP3 , the clk set paretn fails */
> >     >               ret = clk_set_parent(omap->utmi_p1_fck,
> >     >                                       omap->xclk60mhsp1_ck);
> >     >               if (ret != 0)
> >
> >     This begs the question, why is port_mode[0] set to ehci phy mode if
> this
> >     is failing? Something does not seem right here but this does not look
> >     like the right fix.
> >
> > Actually, for omap3530evm, there is only port-mode[1] is valid, so
> > port_mode[0]
> > will be skipped by "if". And it will report "xclk60mhsp2_ck set parent
> > failed"
> >
> > But why I bracket both of them, because, both xclk60mhsp2_ck and
> > xclk60mhsp1_ck
> > have dummy_ck clk for omap3530evm. So we can skip them directly.
>
> How about something like this ...
>
> diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
> index 62ec5c4..c1335f1 100644
> --- a/arch/arm/plat-omap/clock.c
> +++ b/arch/arm/plat-omap/clock.c
> @@ -149,6 +149,10 @@ int clk_set_parent(struct clk *clk, struct clk
> *parent)
>        if (!arch_clock || !arch_clock->clk_set_parent)
>                return ret;
>
> +       /* If the clock is a dummy clock just return */
> +       if (!strcmp(clk->name, dummy_ck.name))
> +               return 0;
> +
>
Yes, this is a good fixes, thanks I'll try it.

Regards,
Zumeng

>        spin_lock_irqsave(&clockfw_lock, flags);
>        if (clk->usecount == 0) {
>                ret = arch_clock->clk_set_parent(clk, parent);
>
> Can you give this a try?
>
> Cheers
> Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120613/a564cd36/attachment-0001.html>

[PATCH 4/5] MFD: OMAP3EVM: USB: cosmetic fix to failed parent clk set

[Igor Grinberg]

On 06/11/12 17:00, Zumeng Chen wrote:
> A typo fix for this cosmetic change and mute a failed message from
> a unnecessary setting of some parent clk for usbhs_omap on OMAP3EVM.
> 
> Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com>
> ---
>  drivers/mfd/omap-usb-host.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index 7e96bb2..9aaaf3c 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -698,8 +698,9 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>  		goto err_usbtll_p2_fck;
>  	}
>  
> +#ifndef CONFIG_MACH_OMAP3EVM
> +	/* for OMAP3 , the clk set parent fails */
>  	if (is_ehci_phy_mode(pdata->port_mode[0])) {
> -		/* for OMAP3 , the clk set paretn fails */
>  		ret = clk_set_parent(omap->utmi_p1_fck,
>  					omap->xclk60mhsp1_ck);
>  		if (ret != 0)
> @@ -726,6 +727,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>  			dev_err(dev, "init_60m_fclk set parent"
>  				"failed error:%d\n", ret);
>  	}
> +#endif

I agree with John, this is a bad fix. Fix the problem, don't hide it...

>  
>  	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "uhh");
>  	if (!res) {

-- 
Regards,
Igor.

[PATCH 5/5] Input: ads7846: set proper debounce time in driver level

[Zumeng Chen]

If we don't set proper debouce time for ads7846, then there are
flooded interrupt counters of ads7846 responding to one time
touch on screen, so the driver couldn't work well.

And since most OMAP3 series boards pass NULL pointer of board_pdata
to omap_ads7846_init, so it's more proper to set it in driver level
after having gpio_request done.

This patch has been validated on 3530evm.

Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com>
Signed-off-by: Syed Mohammed Khasim <khasim@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 drivers/input/touchscreen/ads7846.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index f02028e..a82a5fb 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -61,6 +61,7 @@
 
 /* this driver doesn't aim at the peak continuous sample rate */
 #define	SAMPLE_BITS	(8 /*cmd*/ + 16 /*sample*/ + 2 /* before, after */)
+#define	DEBOUNCE_TIME	310 /* About 10 ms */
 
 struct ts_event {
 	/*
@@ -980,6 +981,7 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
 		}
 
 		ts->gpio_pendown = pdata->gpio_pendown;
+		gpio_set_debounce(pdata->gpio_pendown, DEBOUNCE_TIME);
 
 	} else {
 		dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");
-- 
1.7.5.4

[PATCH 5/5] Input: ads7846: set proper debounce time in driver level

[Igor Grinberg]

Hi,

This is input subsystem, add Dmitry and linux-input.

On 06/11/12 17:00, Zumeng Chen wrote:
> If we don't set proper debouce time for ads7846, then there are
> flooded interrupt counters of ads7846 responding to one time
> touch on screen, so the driver couldn't work well.
> 
> And since most OMAP3 series boards pass NULL pointer of board_pdata
> to omap_ads7846_init, so it's more proper to set it in driver level
> after having gpio_request done.

What about other non-OMAP platforms?

NULL pointer for board_pdata, only means that the default pdata is used.
Please, see the common-board-devices.c file more closely.

> 
> This patch has been validated on 3530evm.
> 
> Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com>
> Signed-off-by: Syed Mohammed Khasim <khasim@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>  drivers/input/touchscreen/ads7846.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
> index f02028e..a82a5fb 100644
> --- a/drivers/input/touchscreen/ads7846.c
> +++ b/drivers/input/touchscreen/ads7846.c
> @@ -61,6 +61,7 @@
>  
>  /* this driver doesn't aim at the peak continuous sample rate */
>  #define	SAMPLE_BITS	(8 /*cmd*/ + 16 /*sample*/ + 2 /* before, after */)
> +#define	DEBOUNCE_TIME	310 /* About 10 ms */

I think hard coding this value is wrong.
Can't it be derived from the pdata->debounce_* fields?

>  
>  struct ts_event {
>  	/*
> @@ -980,6 +981,7 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
>  		}
>  
>  		ts->gpio_pendown = pdata->gpio_pendown;
> +		gpio_set_debounce(pdata->gpio_pendown, DEBOUNCE_TIME);
>  
>  	} else {
>  		dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");

-- 
Regards,
Igor.

[PATCH 5/5] Input: ads7846: set proper debounce time in driver level

[Zumeng Chen]

2012/6/11 Igor Grinberg <grinberg@compulab.co.il>

> Hi,
>
> This is input subsystem, add Dmitry and linux-input.
>
> On 06/11/12 17:00, Zumeng Chen wrote:
> > If we don't set proper debouce time for ads7846, then there are
> > flooded interrupt counters of ads7846 responding to one time
> > touch on screen, so the driver couldn't work well.
> >
> > And since most OMAP3 series boards pass NULL pointer of board_pdata
> > to omap_ads7846_init, so it's more proper to set it in driver level
> > after having gpio_request done.
>
> What about other non-OMAP platforms?
>
Good point, I thought it should be the same situation, and I have no other
boards
to validate it :) Then I'll fall back on my original patch to bracket them
with OMAP3EVM

>
> NULL pointer for board_pdata, only means that the default pdata is used.
> Please, see the common-board-devices.c file more closely.
>
Yes,  I just went through again, two points:

1 )  get_pendown_state is not set for OMAP3 boards, and the state
      will be get by gpio_get_value(gpio-omap.c)
      The second path will be available in the ads7846_setup_pendown
      if (pdata->get_pendown_state) {
                ts->get_pendown_state = pdata->get_pendown_state;
      } else if (gpio_is_valid(pdata->gpio_pendown)) {

2 )  All omap3 boards set gpio_pendown for pdata.
      So it had better we set_debounce in driver level after
gpio_request_one
      having done
      I'll remove DEBOUNCE_TIME in V2 and change into like following:

+#ifdef CONFIG_MACH_OMAP3EVM
+               /* 310 means 10 microsecond for omap3 */
+               gpio_set_debounce(pdata->gpio_pendown, 310);
+#endif


> >
> > This patch has been validated on 3530evm.
> >
> > Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com>
> > Signed-off-by: Syed Mohammed Khasim <khasim@ti.com>
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> >  drivers/input/touchscreen/ads7846.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/ads7846.c
> b/drivers/input/touchscreen/ads7846.c
> > index f02028e..a82a5fb 100644
> > --- a/drivers/input/touchscreen/ads7846.c
> > +++ b/drivers/input/touchscreen/ads7846.c
> > @@ -61,6 +61,7 @@
> >
> >  /* this driver doesn't aim at the peak continuous sample rate */
> >  #define      SAMPLE_BITS     (8 /*cmd*/ + 16 /*sample*/ + 2 /* before,
> after */)
> > +#define      DEBOUNCE_TIME   310 /* About 10 ms */
>
> I think hard coding this value is wrong.
>
Yes, me too.

> Can't it be derived from the pdata->debounce_* fields?
>
Yes, I agreed this way, and to be honest, my first choice
is to find if there is a member for debounce, but no. And
there is no more sense to derive it from debounce_max,
although which is the right value for us.

So I have to use the hardcode here.

Regards,
Zumeng


> >
> >  struct ts_event {
> >       /*
> > @@ -980,6 +981,7 @@ static int __devinit ads7846_setup_pendown(struct
> spi_device *spi, struct ads784
> >               }
> >
> >               ts->gpio_pendown = pdata->gpio_pendown;
> > +             gpio_set_debounce(pdata->gpio_pendown, DEBOUNCE_TIME);
> >
> >       } else {
> >               dev_err(&spi->dev, "no get_pendown_state nor
> gpio_pendown?\n");
>
> --
> Regards,
> Igor.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120612/53374852/attachment-0001.html>

[PATCH 5/5] Input: ads7846: set proper debounce time in driver level

[Igor Grinberg]

On 06/12/12 05:49, Zumeng Chen wrote:
> 
> 
> 2012/6/11 Igor Grinberg <grinberg at compulab.co.il <mailto:grinberg@compulab.co.il>>
> 
>     Hi,
> 
>     This is input subsystem, add Dmitry and linux-input.
> 
>     On 06/11/12 17:00, Zumeng Chen wrote:
>     > If we don't set proper debouce time for ads7846, then there are
>     > flooded interrupt counters of ads7846 responding to one time
>     > touch on screen, so the driver couldn't work well.
>     >
>     > And since most OMAP3 series boards pass NULL pointer of board_pdata
>     > to omap_ads7846_init, so it's more proper to set it in driver level
>     > after having gpio_request done.
> 
>     What about other non-OMAP platforms?
> 
> Good point, I thought it should be the same situation, and I have no other boards
> to validate it :) Then I'll fall back on my original patch to bracket them with OMAP3EVM

This isn't a good solution either...

> 
> 
>     NULL pointer for board_pdata, only means that the default pdata is used.
>     Please, see the common-board-devices.c file more closely.
> 
> Yes,  I just went through again, two points:
> 
> 1 )  get_pendown_state is not set for OMAP3 boards, and the state

You can supply your own pdata and provide the get_pendown_state() callback.

>       will be get by gpio_get_value(gpio-omap.c)
>       The second path will be available in the ads7846_setup_pendown
>       if (pdata->get_pendown_state) {
>                 ts->get_pendown_state = pdata->get_pendown_state;
>       } else if (gpio_is_valid(pdata->gpio_pendown)) {
> 
> 2 )  All omap3 boards set gpio_pendown for pdata.
>       So it had better we set_debounce in driver level after gpio_request_one
>       having done
>       I'll remove DEBOUNCE_TIME in V2 and change into like following:
> 
> +#ifdef CONFIG_MACH_OMAP3EVM
> +               /* 310 means 10 microsecond for omap3 */
> +               gpio_set_debounce(pdata->gpio_pendown, 310);
> +#endif

I don't think this kind of fix is acceptable...

> 
> 
>     >
>     > This patch has been validated on 3530evm.
>     >
>     > Signed-off-by: Zumeng Chen <zumeng.chen at gmail.com <mailto:zumeng.chen@gmail.com>>
>     > Signed-off-by: Syed Mohammed Khasim <khasim at ti.com <mailto:khasim@ti.com>>
>     > Signed-off-by: Tony Lindgren <tony at atomide.com <mailto:tony@atomide.com>>
>     > ---
>     >  drivers/input/touchscreen/ads7846.c |    2 ++
>     >  1 files changed, 2 insertions(+), 0 deletions(-)
>     >
>     > diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
>     > index f02028e..a82a5fb 100644
>     > --- a/drivers/input/touchscreen/ads7846.c
>     > +++ b/drivers/input/touchscreen/ads7846.c
>     > @@ -61,6 +61,7 @@
>     >
>     >  /* this driver doesn't aim at the peak continuous sample rate */
>     >  #define      SAMPLE_BITS     (8 /*cmd*/ + 16 /*sample*/ + 2 /* before, after */)
>     > +#define      DEBOUNCE_TIME   310 /* About 10 ms */
> 
>     I think hard coding this value is wrong.
> 
> Yes, me too.
> 
>     Can't it be derived from the pdata->debounce_* fields?
> 
> Yes, I agreed this way, and to be honest, my first choice
> is to find if there is a member for debounce, but no. And
> there is no more sense to derive it from debounce_max,
> although which is the right value for us.

It makes sense to me... Why do you think there is no sense?


-- 
Regards,
Igor.

[PATCH 5/5] Input: ads7846: set proper debounce time in driver level

[Tony Lindgren]

* Zumeng Chen <zumeng.chen@gmail.com> [120611 07:05]:
> If we don't set proper debouce time for ads7846, then there are
> flooded interrupt counters of ads7846 responding to one time
> touch on screen, so the driver couldn't work well.
> 
> And since most OMAP3 series boards pass NULL pointer of board_pdata
> to omap_ads7846_init, so it's more proper to set it in driver level
> after having gpio_request done.
> 
> This patch has been validated on 3530evm.
> 
> Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com>
> Signed-off-by: Syed Mohammed Khasim <khasim@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Please remove my Signed-off-by, where does that come from?

Tony


>  drivers/input/touchscreen/ads7846.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
> index f02028e..a82a5fb 100644
> --- a/drivers/input/touchscreen/ads7846.c
> +++ b/drivers/input/touchscreen/ads7846.c
> @@ -61,6 +61,7 @@
>  
>  /* this driver doesn't aim at the peak continuous sample rate */
>  #define	SAMPLE_BITS	(8 /*cmd*/ + 16 /*sample*/ + 2 /* before, after */)
> +#define	DEBOUNCE_TIME	310 /* About 10 ms */
>  
>  struct ts_event {
>  	/*
> @@ -980,6 +981,7 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
>  		}
>  
>  		ts->gpio_pendown = pdata->gpio_pendown;
> +		gpio_set_debounce(pdata->gpio_pendown, DEBOUNCE_TIME);
>  
>  	} else {
>  		dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");
> -- 
> 1.7.5.4
> 

[PATCH 5/5] Input: ads7846: set proper debounce time in driver level

[Zumeng Chen]

2012/6/12 Tony Lindgren <tony@atomide.com>

> * Zumeng Chen <zumeng.chen@gmail.com> [120611 07:05]:
> > If we don't set proper debouce time for ads7846, then there are
> > flooded interrupt counters of ads7846 responding to one time
> > touch on screen, so the driver couldn't work well.
> >
> > And since most OMAP3 series boards pass NULL pointer of board_pdata
> > to omap_ads7846_init, so it's more proper to set it in driver level
> > after having gpio_request done.
> >
> > This patch has been validated on 3530evm.
> >
> > Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com>
> > Signed-off-by: Syed Mohammed Khasim <khasim@ti.com>
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> Please remove my Signed-off-by, where does that come from?
>
HI Tony,

This comes from git://arago-project.org/git/projects/linux-omap3.git
The commit ID is 53c5ec31, we set gpio_debounce in arch/board
level.

+static void ads7846_dev_init(void)
+{
+       if (gpio_request(OMAP3_EVM_TS_GPIO, "ADS7846 pendown") < 0)
+               printk(KERN_ERR "can't get ads7846 pen down GPIO\n");
+
+       gpio_direction_input(OMAP3_EVM_TS_GPIO);
+
+       omap_set_gpio_debounce(OMAP3_EVM_TS_GPIO, 1);
+       omap_set_gpio_debounce_time(OMAP3_EVM_TS_GPIO, 0xa);
+}

in 3.4 kernel, I think we can set pendown in driver level. this is the
story.

Regards,
Zumeng

>
> Tony
>
>
> >  drivers/input/touchscreen/ads7846.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/ads7846.c
> b/drivers/input/touchscreen/ads7846.c
> > index f02028e..a82a5fb 100644
> > --- a/drivers/input/touchscreen/ads7846.c
> > +++ b/drivers/input/touchscreen/ads7846.c
> > @@ -61,6 +61,7 @@
> >
> >  /* this driver doesn't aim at the peak continuous sample rate */
> >  #define      SAMPLE_BITS     (8 /*cmd*/ + 16 /*sample*/ + 2 /* before,
> after */)
> > +#define      DEBOUNCE_TIME   310 /* About 10 ms */
> >
> >  struct ts_event {
> >       /*
> > @@ -980,6 +981,7 @@ static int __devinit ads7846_setup_pendown(struct
> spi_device *spi, struct ads784
> >               }
> >
> >               ts->gpio_pendown = pdata->gpio_pendown;
> > +             gpio_set_debounce(pdata->gpio_pendown, DEBOUNCE_TIME);
> >
> >       } else {
> >               dev_err(&spi->dev, "no get_pendown_state nor
> gpio_pendown?\n");
> > --
> > 1.7.5.4
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120613/899bd633/attachment-0001.html>

[PATCH 5/5] Input: ads7846: set proper debounce time in driver level

[Tony Lindgren]

* Zumeng Chen <zumeng.chen@gmail.com> [120612 09:41]:
> 2012/6/12 Tony Lindgren <tony@atomide.com>
> 
> > * Zumeng Chen <zumeng.chen@gmail.com> [120611 07:05]:
> > > If we don't set proper debouce time for ads7846, then there are
> > > flooded interrupt counters of ads7846 responding to one time
> > > touch on screen, so the driver couldn't work well.
> > >
> > > And since most OMAP3 series boards pass NULL pointer of board_pdata
> > > to omap_ads7846_init, so it's more proper to set it in driver level
> > > after having gpio_request done.
> > >
> > > This patch has been validated on 3530evm.
> > >
> > > Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com>
> > > Signed-off-by: Syed Mohammed Khasim <khasim@ti.com>
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> >
> > Please remove my Signed-off-by, where does that come from?
> >
> HI Tony,
> 
> This comes from git://arago-project.org/git/projects/linux-omap3.git
> The commit ID is 53c5ec31, we set gpio_debounce in arch/board
> level.

Weird, I have no recollection of doing anything with that file..
Just remove my Signed-off-by please.

Tony

[PATCH 5/5] Input: ads7846: set proper debounce time in driver level

[Zumeng Chen]

2012/6/13 Tony Lindgren <tony@atomide.com>

> * Zumeng Chen <zumeng.chen@gmail.com> [120612 09:41]:
> > 2012/6/12 Tony Lindgren <tony@atomide.com>
> >
> > > * Zumeng Chen <zumeng.chen@gmail.com> [120611 07:05]:
> > > > If we don't set proper debouce time for ads7846, then there are
> > > > flooded interrupt counters of ads7846 responding to one time
> > > > touch on screen, so the driver couldn't work well.
> > > >
> > > > And since most OMAP3 series boards pass NULL pointer of board_pdata
> > > > to omap_ads7846_init, so it's more proper to set it in driver level
> > > > after having gpio_request done.
> > > >
> > > > This patch has been validated on 3530evm.
> > > >
> > > > Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com>
> > > > Signed-off-by: Syed Mohammed Khasim <khasim@ti.com>
> > > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > >
> > > Please remove my Signed-off-by, where does that come from?
> > >
> > HI Tony,
> >
> > This comes from git://arago-project.org/git/projects/linux-omap3.git
> > The commit ID is 53c5ec31, we set gpio_debounce in arch/board
> > level.
>
> Weird, I have no recollection of doing anything with that file..
> Just remove my Signed-off-by please.
>
NP, Tony, done on V2.

Regards,
Zumeng

>
> Tony
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120614/7cb3dde7/attachment-0001.html>

[PATCH 5/5] Input: ads7846: set proper debounce time in driver level

[Zumeng Chen]

? 2012?06?13? 20:55, Tony Lindgren ??:
> * Zumeng Chen<zumeng.chen@gmail.com>  [120612 09:41]:
>> 2012/6/12 Tony Lindgren<tony@atomide.com>
>>
>>> * Zumeng Chen<zumeng.chen@gmail.com>  [120611 07:05]:
>>>> If we don't set proper debouce time for ads7846, then there are
>>>> flooded interrupt counters of ads7846 responding to one time
>>>> touch on screen, so the driver couldn't work well.
>>>>
>>>> And since most OMAP3 series boards pass NULL pointer of board_pdata
>>>> to omap_ads7846_init, so it's more proper to set it in driver level
>>>> after having gpio_request done.
>>>>
>>>> This patch has been validated on 3530evm.
>>>>
>>>> Signed-off-by: Zumeng Chen<zumeng.chen@gmail.com>
>>>> Signed-off-by: Syed Mohammed Khasim<khasim@ti.com>
>>>> Signed-off-by: Tony Lindgren<tony@atomide.com>
>>> Please remove my Signed-off-by, where does that come from?
>>>
>> HI Tony,
>>
>> This comes from git://arago-project.org/git/projects/linux-omap3.git
>> The commit ID is 53c5ec31, we set gpio_debounce in arch/board
>> level.
> Weird, I have no recollection of doing anything with that file..
> Just remove my Signed-off-by please.
NP, Tony, done, sorry for inconvenience.

Regards,
Zumeng
> Tony

[PATCH 0/5] OMAP3530evm misc fixes for linux-omap

[Jon Hunter]

On 06/11/2012 09:00 AM, Zumeng Chen wrote:
> These patches fix misc problems when reflash ti-omap3530evm for
> master branch on Linux-omap. Currently they have been tested on
> 3530evm but were not ack'ed.
> 
> Most of them are the leftovers from the great original developers
> with my the latest updates for adapting to the current kernel, so
> I add you directly into SOB(If not proper, please let me know).

I don't see any references to the original patches in the changelogs. If
you have references you may wish to add them for historical purposes.

Cheers
Jon

[PATCH 0/5] OMAP3530evm misc fixes for linux-omap

[Zumeng Chen]

2012/6/11 Jon Hunter <jon-hunter@ti.com>

>
> On 06/11/2012 09:00 AM, Zumeng Chen wrote:
> > These patches fix misc problems when reflash ti-omap3530evm for
> > master branch on Linux-omap. Currently they have been tested on
> > 3530evm but were not ack'ed.
> >
> > Most of them are the leftovers from the great original developers
> > with my the latest updates for adapting to the current kernel, so
> > I add you directly into SOB(If not proper, please let me know).
>
> I don't see any references to the original patches in the changelogs. If
> you have references you may wish to add them for historical purposes.
>
I'll add them in V2.

Regards,
Zumeng

>
> Cheers
> Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120612/b621f9db/attachment-0001.html>

[PATCH v2 0/5] ARM OMAP3530evm misc fixes for linux-omap

[Zumeng Chen]

These patches fix misc problems when reflash ti-omap3530evm for
master branch on Linux-omap.

The series is based upon the latest linux-omap master branch from
Tony (3.5-rc1).

Changes vs V1:

 1. NAND flash definition changes as Jon's comments.
 2. Add more shortlog for VBUS switch from a kind people.
 3. Jon's cosmetic fix seems more fit.
 4. Debounce time I still leave a ugly hardcode in driver level
    with bracketing by ARCH_OMAP3. Anyway, Igor's comments are
    more sense.

 If you guy don't like patch 4 or 5, feel free to drop them :-)
 I'm OK for that, thanks all of your kind RR from Jon, Igor, and
 Tony.

 Zumeng Chen (5):
      ARM: OMAP3EVM: Add NAND flash definition
      ARM: OMAP3EVM: Adding USB internal LDOs board file
      ARM: omap3evm: enable VBUS switch for EHCI tranceiver
      ARM: OMAP3EVM: cosmetic fixes for parent clk set
      Input: ads7846: set proper debounce time in driver level

 arch/arm/mach-omap2/board-omap3evm.c |   75 ++++++++++++++++++++++++++++++++++
 arch/arm/plat-omap/clock.c           |    4 ++
 drivers/input/touchscreen/ads7846.c  |    4 ++
 drivers/mfd/omap-usb-host.c          |    2 +-
 4 files changed, 84 insertions(+), 1 deletions(-)
 

[PATCH V2 1/5] ARM: OMAP3EVM: Add NAND flash definition

[Zumeng Chen]

From: Zumeng Chen <zumeng.chen@windriver.com>

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Tested-by: Zumeng Chen <zumeng.chen@windriver.com>
---
 arch/arm/mach-omap2/board-omap3evm.c |   39 ++++++++++++++++++++++++++++++++++
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 639bd07..0b83d0e 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -24,6 +24,10 @@
 #include <linux/leds.h>
 #include <linux/interrupt.h>
 
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/nand.h>
+
 #include <linux/spi/spi.h>
 #include <linux/spi/ads7846.h>
 #include <linux/i2c/twl.h>
@@ -43,6 +47,7 @@
 
 #include <plat/board.h>
 #include <plat/usb.h>
+#include <plat/nand.h>
 #include "common.h"
 #include <plat/mcspi.h>
 #include <video/omapdss.h>
@@ -607,6 +612,37 @@ static struct regulator_consumer_supply dummy_supplies[] = {
 	REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
 };
 
+static struct mtd_partition omap3evm_nand_partitions[] = {
+	/* All the partition sizes are listed in terms of NAND block size */
+	{
+		.name           = "X-Loader",
+		.offset         = 0,
+		.size           = 4*(SZ_128K),
+		.mask_flags     = MTD_WRITEABLE
+	},
+	{
+		.name           = "U-Boot",
+		.offset         = MTDPART_OFS_APPEND,
+		.size           = 14*(SZ_128K),
+		.mask_flags     = MTD_WRITEABLE
+	},
+	{
+		.name           = "U-Boot Env",
+		.offset         = MTDPART_OFS_APPEND,
+		.size           = 2*(SZ_128K)
+	},
+	{
+		.name           = "Kernel",
+		.offset         = MTDPART_OFS_APPEND,
+		.size           = 40*(SZ_128K)
+	},
+	{
+		.name           = "File system",
+		.size           = MTDPART_SIZ_FULL,
+		.offset         = MTDPART_OFS_APPEND,
+	},
+};
+
 static void __init omap3_evm_init(void)
 {
 	struct omap_board_mux *obm;
@@ -656,6 +692,9 @@ static void __init omap3_evm_init(void)
 	}
 	usb_musb_init(&musb_board_data);
 	usbhs_init(&usbhs_bdata);
+	omap_nand_flash_init(NAND_BUSWIDTH_16, omap3evm_nand_partitions,
+			     ARRAY_SIZE(omap3evm_nand_partitions));
+
 	omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
 	omap3evm_init_smsc911x();
 	omap3_evm_display_init();
-- 
1.7.5.4

[PATCH V2 1/5] ARM: OMAP3EVM: Add NAND flash definition

[Igor Grinberg]

On 06/13/12 04:44, Zumeng Chen wrote:
> From: Zumeng Chen <zumeng.chen@windriver.com>
> 
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Tested-by: Zumeng Chen <zumeng.chen@windriver.com>
> ---
>  arch/arm/mach-omap2/board-omap3evm.c |   39 ++++++++++++++++++++++++++++++++++
>  1 files changed, 39 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
> index 639bd07..0b83d0e 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -24,6 +24,10 @@
>  #include <linux/leds.h>
>  #include <linux/interrupt.h>
>  
> +#include <linux/mtd/mtd.h>
> +#include <linux/mtd/partitions.h>
> +#include <linux/mtd/nand.h>
> +
>  #include <linux/spi/spi.h>
>  #include <linux/spi/ads7846.h>
>  #include <linux/i2c/twl.h>
> @@ -43,6 +47,7 @@
>  
>  #include <plat/board.h>
>  #include <plat/usb.h>
> +#include <plat/nand.h>
>  #include "common.h"
>  #include <plat/mcspi.h>
>  #include <video/omapdss.h>
> @@ -607,6 +612,37 @@ static struct regulator_consumer_supply dummy_supplies[] = {
>  	REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
>  };
>  
> +static struct mtd_partition omap3evm_nand_partitions[] = {
> +	/* All the partition sizes are listed in terms of NAND block size */
> +	{
> +		.name           = "X-Loader",
> +		.offset         = 0,
> +		.size           = 4*(SZ_128K),
> +		.mask_flags     = MTD_WRITEABLE
> +	},
> +	{
> +		.name           = "U-Boot",
> +		.offset         = MTDPART_OFS_APPEND,
> +		.size           = 14*(SZ_128K),
> +		.mask_flags     = MTD_WRITEABLE
> +	},
> +	{
> +		.name           = "U-Boot Env",
> +		.offset         = MTDPART_OFS_APPEND,
> +		.size           = 2*(SZ_128K)
> +	},
> +	{
> +		.name           = "Kernel",
> +		.offset         = MTDPART_OFS_APPEND,
> +		.size           = 40*(SZ_128K)
> +	},
> +	{
> +		.name           = "File system",
> +		.size           = MTDPART_SIZ_FULL,
> +		.offset         = MTDPART_OFS_APPEND,
> +	},
> +};
> +
>  static void __init omap3_evm_init(void)
>  {
>  	struct omap_board_mux *obm;
> @@ -656,6 +692,9 @@ static void __init omap3_evm_init(void)
>  	}
>  	usb_musb_init(&musb_board_data);
>  	usbhs_init(&usbhs_bdata);
> +	omap_nand_flash_init(NAND_BUSWIDTH_16, omap3evm_nand_partitions,
> +			     ARRAY_SIZE(omap3evm_nand_partitions));
> +

I think, this will interfere with Afzal's patches [1]?

>  	omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
>  	omap3evm_init_smsc911x();
>  	omap3_evm_display_init();

[1] http://www.spinics.net/lists/arm-kernel/msg178664.html

-- 
Regards,
Igor.

[PATCH V2 1/5] ARM: OMAP3EVM: Add NAND flash definition

[Zumeng Chen]

? 2012?06?13? 15:57, Igor Grinberg ??:
> On 06/13/12 04:44, Zumeng Chen wrote:
>> From: Zumeng Chen<zumeng.chen@windriver.com>
>>
>> Signed-off-by: Vaibhav Hiremath<hvaibhav@ti.com>
>> Tested-by: Zumeng Chen<zumeng.chen@windriver.com>
>> ---
>>   arch/arm/mach-omap2/board-omap3evm.c |   39 ++++++++++++++++++++++++++++++++++
>>   1 files changed, 39 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
>> index 639bd07..0b83d0e 100644
>> --- a/arch/arm/mach-omap2/board-omap3evm.c
>> +++ b/arch/arm/mach-omap2/board-omap3evm.c
>> @@ -24,6 +24,10 @@
>>   #include<linux/leds.h>
>>   #include<linux/interrupt.h>
>>
>> +#include<linux/mtd/mtd.h>
>> +#include<linux/mtd/partitions.h>
>> +#include<linux/mtd/nand.h>
>> +
>>   #include<linux/spi/spi.h>
>>   #include<linux/spi/ads7846.h>
>>   #include<linux/i2c/twl.h>
>> @@ -43,6 +47,7 @@
>>
>>   #include<plat/board.h>
>>   #include<plat/usb.h>
>> +#include<plat/nand.h>
>>   #include "common.h"
>>   #include<plat/mcspi.h>
>>   #include<video/omapdss.h>
>> @@ -607,6 +612,37 @@ static struct regulator_consumer_supply dummy_supplies[] = {
>>   	REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
>>   };
>>
>> +static struct mtd_partition omap3evm_nand_partitions[] = {
>> +	/* All the partition sizes are listed in terms of NAND block size */
>> +	{
>> +		.name           = "X-Loader",
>> +		.offset         = 0,
>> +		.size           = 4*(SZ_128K),
>> +		.mask_flags     = MTD_WRITEABLE
>> +	},
>> +	{
>> +		.name           = "U-Boot",
>> +		.offset         = MTDPART_OFS_APPEND,
>> +		.size           = 14*(SZ_128K),
>> +		.mask_flags     = MTD_WRITEABLE
>> +	},
>> +	{
>> +		.name           = "U-Boot Env",
>> +		.offset         = MTDPART_OFS_APPEND,
>> +		.size           = 2*(SZ_128K)
>> +	},
>> +	{
>> +		.name           = "Kernel",
>> +		.offset         = MTDPART_OFS_APPEND,
>> +		.size           = 40*(SZ_128K)
>> +	},
>> +	{
>> +		.name           = "File system",
>> +		.size           = MTDPART_SIZ_FULL,
>> +		.offset         = MTDPART_OFS_APPEND,
>> +	},
>> +};
>> +
>>   static void __init omap3_evm_init(void)
>>   {
>>   	struct omap_board_mux *obm;
>> @@ -656,6 +692,9 @@ static void __init omap3_evm_init(void)
>>   	}
>>   	usb_musb_init(&musb_board_data);
>>   	usbhs_init(&usbhs_bdata);
>> +	omap_nand_flash_init(NAND_BUSWIDTH_16, omap3evm_nand_partitions,
>> +			     ARRAY_SIZE(omap3evm_nand_partitions));
>> +
> I think, this will interfere with Afzal's patches [1]?
Yes, Igor, thanks for your kind reminder, I have already
noticed Afzal's GPMC patches when at [PATCH v4 00/39]

But I didn't read recently, I'll check them again to see if they
have been in Tony's queue :-)

Regards,
Zumeng

>>   	omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
>>   	omap3evm_init_smsc911x();
>>   	omap3_evm_display_init();
> [1] http://www.spinics.net/lists/arm-kernel/msg178664.html
>

[PATCH V2 2/5] ARM: OMAP3EVM: Adding USB internal LDOs board file

[Zumeng Chen]

From: Zumeng Chen <zumeng.chen@windriver.com>

EHCI PHY requires these regulators:
        EVM Rev >=E  --> VAUX2
        EVM Rev < E  --> VUSB1V5, VUSB1V8

Adding USB internal LDOs (vusb1v5 & vusb1v8) and VAUX2 to omap3evm
board file. Also removing vaux2_{1/2/3} supplies as they are not
used on omap3 evm.

But we need not to add vaux2 in twl4030_platform_data since it will
be added conditionally.

Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com>
---
 arch/arm/mach-omap2/board-omap3evm.c |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 0b83d0e..3c91534 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -466,6 +466,30 @@ struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
 };
 #endif
 
+/* VAUX2 for USB */
+static struct regulator_consumer_supply omap3evm_vaux2_supplies[] = {
+	REGULATOR_SUPPLY("VDD_CSIPHY1", "omap3isp"),	/* OMAP ISP */
+	REGULATOR_SUPPLY("VDD_CSIPHY2", "omap3isp"),	/* OMAP ISP */
+	REGULATOR_SUPPLY("hsusb1", "ehci-omap.0"),
+	{
+		.supply		= "vaux2",
+	}
+};
+
+static struct regulator_init_data omap3evm_vaux2 = {
+	.constraints = {
+		.min_uV		= 2800000,
+		.max_uV		= 2800000,
+		.apply_uV	= true,
+		.valid_modes_mask	= REGULATOR_MODE_NORMAL
+					| REGULATOR_MODE_STANDBY,
+		.valid_ops_mask		= REGULATOR_CHANGE_MODE
+					| REGULATOR_CHANGE_STATUS,
+	},
+	.num_consumer_supplies		= ARRAY_SIZE(omap3evm_vaux2_supplies),
+	.consumer_supplies		= omap3evm_vaux2_supplies,
+};
+
 static struct twl4030_platform_data omap3evm_twldata = {
 	/* platform_data for children goes here */
 	.keypad		= &omap3evm_kp_data,
@@ -659,6 +683,9 @@ static void __init omap3_evm_init(void)
 	omap_mux_init_gpio(63, OMAP_PIN_INPUT);
 	omap_hsmmc_init(mmc);
 
+	if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
+		omap3evm_twldata.vaux2 = &omap3evm_vaux2;
+
 	omap3_evm_i2c_init();
 
 	omap_display_init(&omap3_evm_dss_data);
-- 
1.7.5.4

[PATCH V2 2/5] ARM: OMAP3EVM: Adding USB internal LDOs board file

[Igor Grinberg]

On 06/13/12 04:44, Zumeng Chen wrote:
> From: Zumeng Chen <zumeng.chen@windriver.com>
> 
> EHCI PHY requires these regulators:
>         EVM Rev >=E  --> VAUX2
>         EVM Rev < E  --> VUSB1V5, VUSB1V8
> 
> Adding USB internal LDOs (vusb1v5 & vusb1v8) and VAUX2 to omap3evm
> board file. Also removing vaux2_{1/2/3} supplies as they are not
> used on omap3 evm.
> 
> But we need not to add vaux2 in twl4030_platform_data since it will
> be added conditionally.
> 
> Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com>
> ---
>  arch/arm/mach-omap2/board-omap3evm.c |   27 +++++++++++++++++++++++++++
>  1 files changed, 27 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
> index 0b83d0e..3c91534 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -466,6 +466,30 @@ struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
>  };
>  #endif
>  
> +/* VAUX2 for USB */
> +static struct regulator_consumer_supply omap3evm_vaux2_supplies[] = {
> +	REGULATOR_SUPPLY("VDD_CSIPHY1", "omap3isp"),	/* OMAP ISP */
> +	REGULATOR_SUPPLY("VDD_CSIPHY2", "omap3isp"),	/* OMAP ISP */
> +	REGULATOR_SUPPLY("hsusb1", "ehci-omap.0"),
> +	{
> +		.supply		= "vaux2",
> +	}

This too can use the REGULATOR_SUPPLY() macro, why not use it?

> +};
> +
> +static struct regulator_init_data omap3evm_vaux2 = {
> +	.constraints = {
> +		.min_uV		= 2800000,
> +		.max_uV		= 2800000,
> +		.apply_uV	= true,
> +		.valid_modes_mask	= REGULATOR_MODE_NORMAL
> +					| REGULATOR_MODE_STANDBY,
> +		.valid_ops_mask		= REGULATOR_CHANGE_MODE
> +					| REGULATOR_CHANGE_STATUS,
> +	},
> +	.num_consumer_supplies		= ARRAY_SIZE(omap3evm_vaux2_supplies),
> +	.consumer_supplies		= omap3evm_vaux2_supplies,
> +};
> +
>  static struct twl4030_platform_data omap3evm_twldata = {
>  	/* platform_data for children goes here */
>  	.keypad		= &omap3evm_kp_data,
> @@ -659,6 +683,9 @@ static void __init omap3_evm_init(void)
>  	omap_mux_init_gpio(63, OMAP_PIN_INPUT);
>  	omap_hsmmc_init(mmc);
>  
> +	if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
> +		omap3evm_twldata.vaux2 = &omap3evm_vaux2;
> +
>  	omap3_evm_i2c_init();
>  
>  	omap_display_init(&omap3_evm_dss_data);

-- 
Regards,
Igor.

[PATCH V2 2/5] ARM: OMAP3EVM: Adding USB internal LDOs board file

[Zumeng Chen]

? 2012?06?13? 16:16, Igor Grinberg ??:
> On 06/13/12 04:44, Zumeng Chen wrote:
>> From: Zumeng Chen<zumeng.chen@windriver.com>
>>
>> EHCI PHY requires these regulators:
>>          EVM Rev>=E  -->  VAUX2
>>          EVM Rev<  E  -->  VUSB1V5, VUSB1V8
>>
>> Adding USB internal LDOs (vusb1v5&  vusb1v8) and VAUX2 to omap3evm
>> board file. Also removing vaux2_{1/2/3} supplies as they are not
>> used on omap3 evm.
>>
>> But we need not to add vaux2 in twl4030_platform_data since it will
>> be added conditionally.
>>
>> Signed-off-by: Ajay Kumar Gupta<ajay.gupta@ti.com>
>> Signed-off-by: Vaibhav Hiremath<hvaibhav@ti.com>
>> Signed-off-by: Zumeng Chen<zumeng.chen@windriver.com>
>> ---
>>   arch/arm/mach-omap2/board-omap3evm.c |   27 +++++++++++++++++++++++++++
>>   1 files changed, 27 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
>> index 0b83d0e..3c91534 100644
>> --- a/arch/arm/mach-omap2/board-omap3evm.c
>> +++ b/arch/arm/mach-omap2/board-omap3evm.c
>> @@ -466,6 +466,30 @@ struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
>>   };
>>   #endif
>>
>> +/* VAUX2 for USB */
>> +static struct regulator_consumer_supply omap3evm_vaux2_supplies[] = {
>> +	REGULATOR_SUPPLY("VDD_CSIPHY1", "omap3isp"),	/* OMAP ISP */
>> +	REGULATOR_SUPPLY("VDD_CSIPHY2", "omap3isp"),	/* OMAP ISP */
>> +	REGULATOR_SUPPLY("hsusb1", "ehci-omap.0"),
>> +	{
>> +		.supply		= "vaux2",
>> +	}
> This too can use the REGULATOR_SUPPLY() macro, why not use it?
Yes, Of course from me, I'll try to see if there is other considerations
from the original patch. If no I'll change it.

Regards,
Zumeng
>> +};
>> +
>> +static struct regulator_init_data omap3evm_vaux2 = {
>> +	.constraints = {
>> +		.min_uV		= 2800000,
>> +		.max_uV		= 2800000,
>> +		.apply_uV	= true,
>> +		.valid_modes_mask	= REGULATOR_MODE_NORMAL
>> +					| REGULATOR_MODE_STANDBY,
>> +		.valid_ops_mask		= REGULATOR_CHANGE_MODE
>> +					| REGULATOR_CHANGE_STATUS,
>> +	},
>> +	.num_consumer_supplies		= ARRAY_SIZE(omap3evm_vaux2_supplies),
>> +	.consumer_supplies		= omap3evm_vaux2_supplies,
>> +};
>> +
>>   static struct twl4030_platform_data omap3evm_twldata = {
>>   	/* platform_data for children goes here */
>>   	.keypad		=&omap3evm_kp_data,
>> @@ -659,6 +683,9 @@ static void __init omap3_evm_init(void)
>>   	omap_mux_init_gpio(63, OMAP_PIN_INPUT);
>>   	omap_hsmmc_init(mmc);
>>
>> +	if (get_omap3_evm_rev()>= OMAP3EVM_BOARD_GEN_2)
>> +		omap3evm_twldata.vaux2 =&omap3evm_vaux2;
>> +
>>   	omap3_evm_i2c_init();
>>
>>   	omap_display_init(&omap3_evm_dss_data);

[PATCH V2 3/5] ARM: omap3evm: enable VBUS switch for EHCI tranceiver

[Zumeng Chen]

From: Zumeng Chen <zumeng.chen@windriver.com>

This was chosen by following the trace on the schematic from component U131
and U134 to the CPEN pin on the USB3320 device.

TWL4030.GPIO2-...->(T2_GPIO2_3V3)U131-..>nUSB2_EN-..>U134-..>EXP_nUSB2_1V8
which starts EHCI tranceiver USB3320.

This will set TWL4030.GPIO2 as output pin to drive EHCI tranceiver.

Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com>
---
 arch/arm/mach-omap2/board-omap3evm.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 3c91534..63bb865 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -360,6 +360,15 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
 
 	platform_device_register(&leds_gpio);
 
+	/* Enable VBUS switch by setting TWL4030.GPIO2DIR as output
+	 * for starting USB tranceiver
+	 */
+	if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2) {
+		u8 val;
+		twl_i2c_read_u8(TWL4030_MODULE_GPIO, &val, REG_GPIODATADIR1);
+		val |= 0x04; /* TWL4030.GPIO2DIR BIT at GPIODATADIR1(0x9B) */
+		twl_i2c_write_u8(TWL4030_MODULE_GPIO, val, REG_GPIODATADIR1);
+	}
 	return 0;
 }
 
-- 
1.7.5.4

[PATCH V2 4/5] ARM: OMAP3EVM: cosmetic fixes for parent clk set

[Zumeng Chen]

From: Zumeng Chen <zumeng.chen@windriver.com>

Since set parent for dummy clock will dump failed message,
so we can just ignore to mute it.

Signed-off-by: Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com>
---
 arch/arm/plat-omap/clock.c  |    4 ++++
 drivers/mfd/omap-usb-host.c |    2 +-
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 62ec5c4..c7e26e4 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -149,6 +149,10 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
 	if (!arch_clock || !arch_clock->clk_set_parent)
 		return ret;
 
+	/* If the clock is a dummy clock just return */
+	if (clk == &dummy_ck)
+		return 0;
+
 	spin_lock_irqsave(&clockfw_lock, flags);
 	if (clk->usecount == 0) {
 		ret = arch_clock->clk_set_parent(clk, parent);
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 7e96bb2..c9d27c4 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -699,7 +699,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 	}
 
 	if (is_ehci_phy_mode(pdata->port_mode[0])) {
-		/* for OMAP3 , the clk set paretn fails */
+		/* for OMAP3 , the clk set parent fails */
 		ret = clk_set_parent(omap->utmi_p1_fck,
 					omap->xclk60mhsp1_ck);
 		if (ret != 0)
-- 
1.7.5.4

[PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level

[Zumeng Chen]

From: Zumeng Chen <zumeng.chen@windriver.com>

If we don't set proper debouce time for ads7846, then there are
flooded interrupt counters of ads7846 responding to one time
touch on screen, so the driver couldn't work well.

And since most OMAP3 series boards pass NULL pointer of board_pdata
to omap_ads7846_init, so it's more proper to set it in driver level
after having gpio_request done.

This patch has been validated on 3530evm.

Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com>
Signed-off-by: Syed Mohammed Khasim <khasim@ti.com>
---
 drivers/input/touchscreen/ads7846.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index f02028e..459ff29 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
 		}
 
 		ts->gpio_pendown = pdata->gpio_pendown;
+#ifdef CONFIG_ARCH_OMAP3
+		/* 310 means about 10 microsecond for omap3 */
+		gpio_set_debounce(pdata->gpio_pendown, 310);
+#endif
 
 	} else {
 		dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");
-- 
1.7.5.4

[PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level

[Igor Grinberg]

On 06/13/12 04:44, Zumeng Chen wrote:
> From: Zumeng Chen <zumeng.chen@windriver.com>
> 
> If we don't set proper debouce time for ads7846, then there are
> flooded interrupt counters of ads7846 responding to one time
> touch on screen, so the driver couldn't work well.
> 
> And since most OMAP3 series boards pass NULL pointer of board_pdata
> to omap_ads7846_init, so it's more proper to set it in driver level
> after having gpio_request done.
> 
> This patch has been validated on 3530evm.
> 
> Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com>
> Signed-off-by: Syed Mohammed Khasim <khasim@ti.com>
> ---
>  drivers/input/touchscreen/ads7846.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
> index f02028e..459ff29 100644
> --- a/drivers/input/touchscreen/ads7846.c
> +++ b/drivers/input/touchscreen/ads7846.c
> @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
>  		}
>  
>  		ts->gpio_pendown = pdata->gpio_pendown;
> +#ifdef CONFIG_ARCH_OMAP3
> +		/* 310 means about 10 microsecond for omap3 */
> +		gpio_set_debounce(pdata->gpio_pendown, 310);
> +#endif

Unless this concerns many boards/archs/platforms, I'd suggest you to implement
the get_pendown_state() method in the board file.
If more users will need this, it can be facilitated in the driver.
(and of course not with the ugly ifdefs...)

>  
>  	} else {
>  		dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");

-- 
Regards,
Igor.

[PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level

[Zumeng Chen]

? 2012?06?13? 15:51, Igor Grinberg ??:
> On 06/13/12 04:44, Zumeng Chen wrote:
>> From: Zumeng Chen<zumeng.chen@windriver.com>
>>
>> If we don't set proper debouce time for ads7846, then there are
>> flooded interrupt counters of ads7846 responding to one time
>> touch on screen, so the driver couldn't work well.
>>
>> And since most OMAP3 series boards pass NULL pointer of board_pdata
>> to omap_ads7846_init, so it's more proper to set it in driver level
>> after having gpio_request done.
>>
>> This patch has been validated on 3530evm.
>>
>> Signed-off-by: Zumeng Chen<zumeng.chen@windriver.com>
>> Signed-off-by: Syed Mohammed Khasim<khasim@ti.com>
>> ---
>>   drivers/input/touchscreen/ads7846.c |    4 ++++
>>   1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
>> index f02028e..459ff29 100644
>> --- a/drivers/input/touchscreen/ads7846.c
>> +++ b/drivers/input/touchscreen/ads7846.c
>> @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
>>   		}
>>
>>   		ts->gpio_pendown = pdata->gpio_pendown;
>> +#ifdef CONFIG_ARCH_OMAP3
>> +		/* 310 means about 10 microsecond for omap3 */
>> +		gpio_set_debounce(pdata->gpio_pendown, 310);
>> +#endif
> Unless this concerns many boards/archs/platforms,
Yes, this is the case.
> I'd suggest you to implement
> the get_pendown_state() method in the board file.
it seems they are different way between gpio and
get_pendown_state, and gpio way is used for omap3
to drive ads7846, so I guess we may have to do like this.

Regards,
Zumeng
> If more users will need this, it can be facilitated in the driver.
> (and of course not with the ugly ifdefs...)
>
>>
>>   	} else {
>>   		dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");

[PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level

[Igor Grinberg]

On 06/13/12 12:03, Zumeng Chen wrote:
> ? 2012?06?13? 15:51, Igor Grinberg ??:
>> On 06/13/12 04:44, Zumeng Chen wrote:
>>> From: Zumeng Chen<zumeng.chen@windriver.com>
>>>
>>> If we don't set proper debouce time for ads7846, then there are
>>> flooded interrupt counters of ads7846 responding to one time
>>> touch on screen, so the driver couldn't work well.
>>>
>>> And since most OMAP3 series boards pass NULL pointer of board_pdata
>>> to omap_ads7846_init, so it's more proper to set it in driver level
>>> after having gpio_request done.
>>>
>>> This patch has been validated on 3530evm.
>>>
>>> Signed-off-by: Zumeng Chen<zumeng.chen@windriver.com>
>>> Signed-off-by: Syed Mohammed Khasim<khasim@ti.com>
>>> ---
>>>   drivers/input/touchscreen/ads7846.c |    4 ++++
>>>   1 files changed, 4 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
>>> index f02028e..459ff29 100644
>>> --- a/drivers/input/touchscreen/ads7846.c
>>> +++ b/drivers/input/touchscreen/ads7846.c
>>> @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
>>>           }
>>>
>>>           ts->gpio_pendown = pdata->gpio_pendown;
>>> +#ifdef CONFIG_ARCH_OMAP3
>>> +        /* 310 means about 10 microsecond for omap3 */
>>> +        gpio_set_debounce(pdata->gpio_pendown, 310);
>>> +#endif
>> Unless this concerns many boards/archs/platforms,
> Yes, this is the case.
>> I'd suggest you to implement
>> the get_pendown_state() method in the board file.
> it seems they are different way between gpio and
> get_pendown_state, and gpio way is used for omap3
> to drive ads7846, so I guess we may have to do like this.

No, this is not (and does not have to be) OMAP wide.
The decision for this is made on per-board basis.

> 
> Regards,
> Zumeng
>> If more users will need this, it can be facilitated in the driver.
>> (and of course not with the ugly ifdefs...)
>>
>>>
>>>       } else {
>>>           dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Regards,
Igor.

[PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level

[Marek Vasut]

Dear Igor Grinberg,

> On 06/13/12 12:03, Zumeng Chen wrote:
> > ? 2012?06?13? 15:51, Igor Grinberg ??:
> >> On 06/13/12 04:44, Zumeng Chen wrote:
> >>> From: Zumeng Chen<zumeng.chen@windriver.com>
> >>> 
> >>> If we don't set proper debouce time for ads7846, then there are
> >>> flooded interrupt counters of ads7846 responding to one time
> >>> touch on screen, so the driver couldn't work well.
> >>> 
> >>> And since most OMAP3 series boards pass NULL pointer of board_pdata
> >>> to omap_ads7846_init, so it's more proper to set it in driver level
> >>> after having gpio_request done.
> >>> 
> >>> This patch has been validated on 3530evm.
> >>> 
> >>> Signed-off-by: Zumeng Chen<zumeng.chen@windriver.com>
> >>> Signed-off-by: Syed Mohammed Khasim<khasim@ti.com>
> >>> ---
> >>> 
> >>>   drivers/input/touchscreen/ads7846.c |    4 ++++
> >>>   1 files changed, 4 insertions(+), 0 deletions(-)
> >>> 
> >>> diff --git a/drivers/input/touchscreen/ads7846.c
> >>> b/drivers/input/touchscreen/ads7846.c index f02028e..459ff29 100644
> >>> --- a/drivers/input/touchscreen/ads7846.c
> >>> +++ b/drivers/input/touchscreen/ads7846.c
> >>> @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct
> >>> spi_device *spi, struct ads784
> >>> 
> >>>           }
> >>>           
> >>>           ts->gpio_pendown = pdata->gpio_pendown;
> >>> 
> >>> +#ifdef CONFIG_ARCH_OMAP3
> >>> +        /* 310 means about 10 microsecond for omap3 */
> >>> +        gpio_set_debounce(pdata->gpio_pendown, 310);
> >>> +#endif
> >> 
> >> Unless this concerns many boards/archs/platforms,
> > 
> > Yes, this is the case.
> > 
> >> I'd suggest you to implement
> >> the get_pendown_state() method in the board file.
> > 
> > it seems they are different way between gpio and
> > get_pendown_state, and gpio way is used for omap3
> > to drive ads7846, so I guess we may have to do like this.
> 
> No, this is not (and does not have to be) OMAP wide.
> The decision for this is made on per-board basis.

+1 agreed

> > Regards,
> > Zumeng
> > 
> >> If more users will need this, it can be facilitated in the driver.
> >> (and of course not with the ugly ifdefs...)
> >> 
> >>>       } else {
> >>>       
> >>>           dev_err(&spi->dev, "no get_pendown_state nor
> >>>           gpio_pendown?\n");

Best regards,
Marek Vasut

[PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level

[Hiremath, Vaibhav]

On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
> From: Zumeng Chen <zumeng.chen@windriver.com>
> 
> If we don't set proper debouce time for ads7846, then there are
> flooded interrupt counters of ads7846 responding to one time
> touch on screen, so the driver couldn't work well.
> 
> And since most OMAP3 series boards pass NULL pointer of board_pdata
> to omap_ads7846_init, so it's more proper to set it in driver level
> after having gpio_request done.
> 
> This patch has been validated on 3530evm.
> 
> Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com>
> Signed-off-by: Syed Mohammed Khasim <khasim@ti.com>
> ---
>  drivers/input/touchscreen/ads7846.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
> index f02028e..459ff29 100644
> --- a/drivers/input/touchscreen/ads7846.c
> +++ b/drivers/input/touchscreen/ads7846.c
> @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
>  		}
>  
>  		ts->gpio_pendown = pdata->gpio_pendown;
> +#ifdef CONFIG_ARCH_OMAP3
> +		/* 310 means about 10 microsecond for omap3 */
> +		gpio_set_debounce(pdata->gpio_pendown, 310);
> +#endif
>  

Zumeng,

With my sign-off you are changing the original code, that too
without my sign-off and ack. 
I wouldn't mind you to submit patches from my tree, but the expectation is 
if you are changing the original code, it should be under your sign-off.

Coming to the patch, #ifdef in driver is not recommended, and this 10msec 
delay is specific to OMAP GPIO and driver should not be aware of this, 
that's where you will find the original patch handling it in board file.

Thanks,
Vaibhav
>  	} else {
>  		dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");
> -- 
> 1.7.5.4
> 
> 

[PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level

[Zumeng Chen]

2012/6/13 Hiremath, Vaibhav <hvaibhav@ti.com>

> On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
> > From: Zumeng Chen <zumeng.chen@windriver.com>
> >
> > If we don't set proper debouce time for ads7846, then there are
> > flooded interrupt counters of ads7846 responding to one time
> > touch on screen, so the driver couldn't work well.
> >
> > And since most OMAP3 series boards pass NULL pointer of board_pdata
> > to omap_ads7846_init, so it's more proper to set it in driver level
> > after having gpio_request done.
> >
> > This patch has been validated on 3530evm.
> >
> > Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com>
> > Signed-off-by: Syed Mohammed Khasim <khasim@ti.com>
> > ---
> >  drivers/input/touchscreen/ads7846.c |    4 ++++
> >  1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/ads7846.c
> b/drivers/input/touchscreen/ads7846.c
> > index f02028e..459ff29 100644
> > --- a/drivers/input/touchscreen/ads7846.c
> > +++ b/drivers/input/touchscreen/ads7846.c
> > @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct
> spi_device *spi, struct ads784
> >               }
> >
> >               ts->gpio_pendown = pdata->gpio_pendown;
> > +#ifdef CONFIG_ARCH_OMAP3
> > +             /* 310 means about 10 microsecond for omap3 */
> > +             gpio_set_debounce(pdata->gpio_pendown, 310);
> > +#endif
> >
>
> Zumeng,
>
> With my sign-off you are changing the original code, that too
> without my sign-off and ack.
> I wouldn't mind you to submit patches from my tree, but the expectation is
> if you are changing the original code, it should be under your sign-off.
>
Many thanks for your information, good to learn. I'll remove too. Sorry for
inconvenience.

>
> Coming to the patch, #ifdef in driver is not recommended, and this 10msec
> delay is specific to OMAP GPIO and driver should not be aware of this,
> that's where you will find the original patch handling it in board file.
>
Yes, I just went through again the board related codes, there is a commit
from
Mike, I think that's the basic thoughts for me to do this patch for all
omap3 about
ads7846 :-)

Regards,
Zumeng


>
> Thanks,
> Vaibhav
> >       } else {
> >               dev_err(&spi->dev, "no get_pendown_state nor
> gpio_pendown?\n");
> > --
> > 1.7.5.4
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120614/326deab1/attachment-0001.html>

[PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level

[Zumeng Chen]

? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
> On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
>> From: Zumeng Chen<zumeng.chen@windriver.com>
>>
>> If we don't set proper debouce time for ads7846, then there are
>> flooded interrupt counters of ads7846 responding to one time
>> touch on screen, so the driver couldn't work well.
>>
>> And since most OMAP3 series boards pass NULL pointer of board_pdata
>> to omap_ads7846_init, so it's more proper to set it in driver level
>> after having gpio_request done.
>>
>> This patch has been validated on 3530evm.
>>
>> Signed-off-by: Zumeng Chen<zumeng.chen@windriver.com>
>> Signed-off-by: Syed Mohammed Khasim<khasim@ti.com>
>> ---
>>   drivers/input/touchscreen/ads7846.c |    4 ++++
>>   1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
>> index f02028e..459ff29 100644
>> --- a/drivers/input/touchscreen/ads7846.c
>> +++ b/drivers/input/touchscreen/ads7846.c
>> @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
>>   		}
>>
>>   		ts->gpio_pendown = pdata->gpio_pendown;
>> +#ifdef CONFIG_ARCH_OMAP3
>> +		/* 310 means about 10 microsecond for omap3 */
>> +		gpio_set_debounce(pdata->gpio_pendown, 310);
>> +#endif
>>
> Zumeng,
>
> With my sign-off you are changing the original code, that too
> without my sign-off and ack.
> I wouldn't mind you to submit patches from my tree, but the expectation is
> if you are changing the original code, it should be under your sign-off.
Thanks, good to learn. I'll remove in next time.
> Coming to the patch, #ifdef in driver is not recommended, and this 10msec
> delay is specific to OMAP GPIO and driver should not be aware of this,
> that's where you will find the original patch handling it in board file.
According to the git blame of the board-omap3evm.c I think
96974a24 did a good thing to all the related codes for omap3
boards. So I think we can call board and driver as BSP level :-)

If #ifdef in driver can save many codes, I guess it's deserved.

Regards,
Zumeng
> Thanks,
> Vaibhav
>>   	} else {
>>   		dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");
>> -- 
>> 1.7.5.4
>>
>>

[PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level

[Hiremath, Vaibhav]

On Thu, Jun 14, 2012 at 10:16:55, Zumeng Chen wrote:
> ? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
> > On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
> >> From: Zumeng Chen<zumeng.chen@windriver.com>
> >>
> >> If we don't set proper debouce time for ads7846, then there are
> >> flooded interrupt counters of ads7846 responding to one time
> >> touch on screen, so the driver couldn't work well.
> >>
> >> And since most OMAP3 series boards pass NULL pointer of board_pdata
> >> to omap_ads7846_init, so it's more proper to set it in driver level
> >> after having gpio_request done.
> >>
> >> This patch has been validated on 3530evm.
> >>
> >> Signed-off-by: Zumeng Chen<zumeng.chen@windriver.com>
> >> Signed-off-by: Syed Mohammed Khasim<khasim@ti.com>
> >> ---
> >>   drivers/input/touchscreen/ads7846.c |    4 ++++
> >>   1 files changed, 4 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
> >> index f02028e..459ff29 100644
> >> --- a/drivers/input/touchscreen/ads7846.c
> >> +++ b/drivers/input/touchscreen/ads7846.c
> >> @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
> >>   		}
> >>
> >>   		ts->gpio_pendown = pdata->gpio_pendown;
> >> +#ifdef CONFIG_ARCH_OMAP3
> >> +		/* 310 means about 10 microsecond for omap3 */
> >> +		gpio_set_debounce(pdata->gpio_pendown, 310);
> >> +#endif
> >>
> > Zumeng,
> >
> > With my sign-off you are changing the original code, that too
> > without my sign-off and ack.
> > I wouldn't mind you to submit patches from my tree, but the expectation is
> > if you are changing the original code, it should be under your sign-off.
> Thanks, good to learn. I'll remove in next time.
> > Coming to the patch, #ifdef in driver is not recommended, and this 10msec
> > delay is specific to OMAP GPIO and driver should not be aware of this,
> > that's where you will find the original patch handling it in board file.
> According to the git blame of the board-omap3evm.c I think
> 96974a24 did a good thing to all the related codes for omap3
> boards. So I think we can call board and driver as BSP level :-)
> 
> If #ifdef in driver can save many codes, I guess it's deserved.
> 

No, not really.

In the same commit, the debounce time is already handled as an argument to 
the function omap_ads7846_init(), and that?s the way it should be.
So no need for #ifdefs in driver...

Thanks,
Vaibhav

[PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level

[Zumeng Chen]

? 2012?06?14? 14:31, Hiremath, Vaibhav ??:
> On Thu, Jun 14, 2012 at 10:16:55, Zumeng Chen wrote:
>> ? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
>>> On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
>>>> From: Zumeng Chen<zumeng.chen@windriver.com>
>>>>
>>>> If we don't set proper debouce time for ads7846, then there are
>>>> flooded interrupt counters of ads7846 responding to one time
>>>> touch on screen, so the driver couldn't work well.
>>>>
>>>> And since most OMAP3 series boards pass NULL pointer of board_pdata
>>>> to omap_ads7846_init, so it's more proper to set it in driver level
>>>> after having gpio_request done.
>>>>
>>>> This patch has been validated on 3530evm.
>>>>
>>>> Signed-off-by: Zumeng Chen<zumeng.chen@windriver.com>
>>>> Signed-off-by: Syed Mohammed Khasim<khasim@ti.com>
>>>> ---
>>>>   drivers/input/touchscreen/ads7846.c |    4 ++++
>>>>   1 files changed, 4 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
>>>> index f02028e..459ff29 100644
>>>> --- a/drivers/input/touchscreen/ads7846.c
>>>> +++ b/drivers/input/touchscreen/ads7846.c
>>>> @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
>>>>   		}
>>>>
>>>>   		ts->gpio_pendown = pdata->gpio_pendown;
>>>> +#ifdef CONFIG_ARCH_OMAP3
>>>> +		/* 310 means about 10 microsecond for omap3 */
>>>> +		gpio_set_debounce(pdata->gpio_pendown, 310);
>>>> +#endif
>>>>
>>> Zumeng,
>>>
>>> With my sign-off you are changing the original code, that too
>>> without my sign-off and ack.
>>> I wouldn't mind you to submit patches from my tree, but the expectation is
>>> if you are changing the original code, it should be under your sign-off.
>> Thanks, good to learn. I'll remove in next time.
>>> Coming to the patch, #ifdef in driver is not recommended, and this 10msec
>>> delay is specific to OMAP GPIO and driver should not be aware of this,
>>> that's where you will find the original patch handling it in board file.
>> According to the git blame of the board-omap3evm.c I think
>> 96974a24 did a good thing to all the related codes for omap3
>> boards. So I think we can call board and driver as BSP level :-)
>>
>> If #ifdef in driver can save many codes, I guess it's deserved.
>>
> No, not really.
>
> In the same commit, the debounce time is already handled as an argument to 
> the function omap_ads7846_init(), and that?s the way it should be.
That means you'd like to implement the same get_pendown_state for every
omap3 board? Currently, board_pdata is NULL.

And actually, the reason why I agree 96974a24 is that get_pendown_state
for all omap3 boards is the common chip level gpio operations. so I think
we should set debounce for them in one common point.

But since Igor and you don't like them, I have created and tested the
attachment
patch, and I'd like Mike to check if convenience too
But obviously there are more codes than mine before :-)

Regards,
Zumeng
> So no need for #ifdefs in driver...
>
> Thanks,
> Vaibhav

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ads7846-common.diff
Type: text/x-patch
Size: 2373 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120614/4c860188/attachment.bin>

[PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level

[zumeng.chen]

On 2012?06?14? 14:59, Zumeng Chen wrote:
> ? 2012?06?14? 14:31, Hiremath, Vaibhav ??:
>> On Thu, Jun 14, 2012 at 10:16:55, Zumeng Chen wrote:
>>> ? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
>>>> On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
>>>>> From: Zumeng Chen<zumeng.chen@windriver.com>
>>>>>
>>>>> If we don't set proper debouce time for ads7846, then there are
>>>>> flooded interrupt counters of ads7846 responding to one time
>>>>> touch on screen, so the driver couldn't work well.
>>>>>
>>>>> And since most OMAP3 series boards pass NULL pointer of board_pdata
>>>>> to omap_ads7846_init, so it's more proper to set it in driver level
>>>>> after having gpio_request done.
>>>>>
>>>>> This patch has been validated on 3530evm.
>>>>>
>>>>> Signed-off-by: Zumeng Chen<zumeng.chen@windriver.com>
>>>>> Signed-off-by: Syed Mohammed Khasim<khasim@ti.com>
>>>>> ---
>>>>>   drivers/input/touchscreen/ads7846.c |    4 ++++
>>>>>   1 files changed, 4 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
>>>>> index f02028e..459ff29 100644
>>>>> --- a/drivers/input/touchscreen/ads7846.c
>>>>> +++ b/drivers/input/touchscreen/ads7846.c
>>>>> @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
>>>>>   		}
>>>>>
>>>>>   		ts->gpio_pendown = pdata->gpio_pendown;
>>>>> +#ifdef CONFIG_ARCH_OMAP3
>>>>> +		/* 310 means about 10 microsecond for omap3 */
>>>>> +		gpio_set_debounce(pdata->gpio_pendown, 310);
>>>>> +#endif
>>>>>
>>>> Zumeng,
>>>>
>>>> With my sign-off you are changing the original code, that too
>>>> without my sign-off and ack.
>>>> I wouldn't mind you to submit patches from my tree, but the expectation is
>>>> if you are changing the original code, it should be under your sign-off.
>>> Thanks, good to learn. I'll remove in next time.
>>>> Coming to the patch, #ifdef in driver is not recommended, and this 10msec
>>>> delay is specific to OMAP GPIO and driver should not be aware of this,
>>>> that's where you will find the original patch handling it in board file.
>>> According to the git blame of the board-omap3evm.c I think
>>> 96974a24 did a good thing to all the related codes for omap3
>>> boards. So I think we can call board and driver as BSP level :-)
>>>
>>> If #ifdef in driver can save many codes, I guess it's deserved.
>>>
>> No, not really.
>>
>> In the same commit, the debounce time is already handled as an argument to 
>> the function omap_ads7846_init(), and that?s the way it should be.
> That means you'd like to implement the same get_pendown_state for every
> omap3 board? Currently, board_pdata is NULL.
>
> And actually, the reason why I agree 96974a24 is that get_pendown_state
> for all omap3 boards is the common chip level gpio operations. so I think
> we should set debounce for them in one common point.
>
> But since Igor and you don't like them, I have created and tested the
> attachment
> patch, and I'd like Mike to check if convenience too
> But obviously there are more codes than mine before :-)
Tony & Mike,

How about your comments on this issue? Do you think the following is
acceptable VS my last email _attachment_.

+#ifdef CONFIG_ARCH_OMAP3
+		/* 310 means about 10 microsecond for omap3 */
+		gpio_set_debounce(pdata->gpio_pendown, 310);
+#endif


Regards,
Zumeng


> Regards,
> Zumeng
>> So no need for #ifdefs in driver...
>>
>> Thanks,
>> Vaibhav

[PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level

[Zumeng Chen]

? 2012?06?14? 14:59, Zumeng Chen ??:
> ? 2012?06?14? 14:31, Hiremath, Vaibhav ??:
>> On Thu, Jun 14, 2012 at 10:16:55, Zumeng Chen wrote:
>>> ? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
>>>> On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
>>>>> From: Zumeng Chen<zumeng.chen@windriver.com>
>>>>>
>>>>> If we don't set proper debouce time for ads7846, then there are
>>>>> flooded interrupt counters of ads7846 responding to one time
>>>>> touch on screen, so the driver couldn't work well.
>>>>>
>>>>> And since most OMAP3 series boards pass NULL pointer of board_pdata
>>>>> to omap_ads7846_init, so it's more proper to set it in driver level
>>>>> after having gpio_request done.
>>>>>
>>>>> This patch has been validated on 3530evm.
>>>>>
>>>>> Signed-off-by: Zumeng Chen<zumeng.chen@windriver.com>
>>>>> Signed-off-by: Syed Mohammed Khasim<khasim@ti.com>
>>>>> ---
>>>>>   drivers/input/touchscreen/ads7846.c |    4 ++++
>>>>>   1 files changed, 4 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
>>>>> index f02028e..459ff29 100644
>>>>> --- a/drivers/input/touchscreen/ads7846.c
>>>>> +++ b/drivers/input/touchscreen/ads7846.c
>>>>> @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
>>>>>   		}
>>>>>
>>>>>   		ts->gpio_pendown = pdata->gpio_pendown;
>>>>> +#ifdef CONFIG_ARCH_OMAP3
>>>>> +		/* 310 means about 10 microsecond for omap3 */
>>>>> +		gpio_set_debounce(pdata->gpio_pendown, 310);
>>>>> +#endif
>>>>>
>>>> Zumeng,
>>>>
>>>> With my sign-off you are changing the original code, that too
>>>> without my sign-off and ack.
>>>> I wouldn't mind you to submit patches from my tree, but the expectation is
>>>> if you are changing the original code, it should be under your sign-off.
>>> Thanks, good to learn. I'll remove in next time.
>>>> Coming to the patch, #ifdef in driver is not recommended, and this 10msec
>>>> delay is specific to OMAP GPIO and driver should not be aware of this,
>>>> that's where you will find the original patch handling it in board file.
>>> According to the git blame of the board-omap3evm.c I think
>>> 96974a24 did a good thing to all the related codes for omap3
>>> boards. So I think we can call board and driver as BSP level :-)
>>>
>>> If #ifdef in driver can save many codes, I guess it's deserved.
>>>
>> No, not really.
>>
>> In the same commit, the debounce time is already handled as an argument to 
>> the function omap_ads7846_init(), and that?s the way it should be.
> That means you'd like to implement the same get_pendown_state for every
> omap3 board? Currently, board_pdata is NULL.
>
> And actually, the reason why I agree 96974a24 is that get_pendown_state
> for all omap3 boards is the common chip level gpio operations. so I think
> we should set debounce for them in one common point.
>
> But since Igor and you don't like them, I have created and tested the
> attachment
> patch, and I'd like Mike to check if convenience too
> But obviously there are more codes than mine before :-)
Hi Mike,

I'll send V3 with the change on the attachment to you for 5/5,
if you happen to get it, it's high appreciated to review it.

Regards,
Zumeng
>
> Regards,
> Zumeng
>> So no need for #ifdefs in driver...
>>
>> Thanks,
>> Vaibhav

[PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level

[Igor Grinberg]

On 06/14/12 07:46, Zumeng Chen wrote:
> ? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
>> On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
>>> From: Zumeng Chen<zumeng.chen@windriver.com>
>>>
>>> If we don't set proper debouce time for ads7846, then there are
>>> flooded interrupt counters of ads7846 responding to one time
>>> touch on screen, so the driver couldn't work well.
>>>
>>> And since most OMAP3 series boards pass NULL pointer of board_pdata
>>> to omap_ads7846_init, so it's more proper to set it in driver level
>>> after having gpio_request done.
>>>
>>> This patch has been validated on 3530evm.
>>>
>>> Signed-off-by: Zumeng Chen<zumeng.chen@windriver.com>
>>> Signed-off-by: Syed Mohammed Khasim<khasim@ti.com>
>>> ---
>>>   drivers/input/touchscreen/ads7846.c |    4 ++++
>>>   1 files changed, 4 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
>>> index f02028e..459ff29 100644
>>> --- a/drivers/input/touchscreen/ads7846.c
>>> +++ b/drivers/input/touchscreen/ads7846.c
>>> @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
>>>           }
>>>
>>>           ts->gpio_pendown = pdata->gpio_pendown;
>>> +#ifdef CONFIG_ARCH_OMAP3
>>> +        /* 310 means about 10 microsecond for omap3 */
>>> +        gpio_set_debounce(pdata->gpio_pendown, 310);
>>> +#endif
>>>
>> Zumeng,
>>
>> With my sign-off you are changing the original code, that too
>> without my sign-off and ack.
>> I wouldn't mind you to submit patches from my tree, but the expectation is
>> if you are changing the original code, it should be under your sign-off.
> Thanks, good to learn. I'll remove in next time.
>> Coming to the patch, #ifdef in driver is not recommended, and this 10msec
>> delay is specific to OMAP GPIO and driver should not be aware of this,
>> that's where you will find the original patch handling it in board file.
> According to the git blame of the board-omap3evm.c I think
> 96974a24 did a good thing to all the related codes for omap3
> boards. So I think we can call board and driver as BSP level :-)
> 
> If #ifdef in driver can save many codes, I guess it's deserved.

No, platform/board specific ifdefs in the generic driver code are never
deserved.
How about the attached patch, does it fix the problem for you?


-- 
Regards,
Igor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ads7846.patch
Type: text/x-patch
Size: 1432 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120614/f22a4b45/attachment.bin>

[PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level

[Zumeng Chen]

? 2012?06?14? 14:44, Igor Grinberg ??:
> On 06/14/12 07:46, Zumeng Chen wrote:
>> >  ? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
>>> >>  On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
>>>> >>>  From: Zumeng Chen<zumeng.chen@windriver.com>
>>>> >>>
>>>> >>>  If we don't set proper debouce time for ads7846, then there are
>>>> >>>  flooded interrupt counters of ads7846 responding to one time
>>>> >>>  touch on screen, so the driver couldn't work well.
>>>> >>>
>>>> >>>  And since most OMAP3 series boards pass NULL pointer of board_pdata
>>>> >>>  to omap_ads7846_init, so it's more proper to set it in driver level
>>>> >>>  after having gpio_request done.
>>>> >>>
>>>> >>>  This patch has been validated on 3530evm.
>>>> >>>
>>>> >>>  Signed-off-by: Zumeng Chen<zumeng.chen@windriver.com>
>>>> >>>  Signed-off-by: Syed Mohammed Khasim<khasim@ti.com>
>>>> >>>  ---
>>>> >>>     drivers/input/touchscreen/ads7846.c |    4 ++++
>>>> >>>     1 files changed, 4 insertions(+), 0 deletions(-)
>>>> >>>
>>>> >>>  diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
>>>> >>>  index f02028e..459ff29 100644
>>>> >>>  --- a/drivers/input/touchscreen/ads7846.c
>>>> >>>  +++ b/drivers/input/touchscreen/ads7846.c
>>>> >>>  @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
>>>> >>>             }
>>>> >>>
>>>> >>>             ts->gpio_pendown = pdata->gpio_pendown;
>>>> >>>  +#ifdef CONFIG_ARCH_OMAP3
>>>> >>>  +        /* 310 means about 10 microsecond for omap3 */
>>>> >>>  +        gpio_set_debounce(pdata->gpio_pendown, 310);
>>>> >>>  +#endif
>>>> >>>
>>> >>  Zumeng,
>>> >>
>>> >>  With my sign-off you are changing the original code, that too
>>> >>  without my sign-off and ack.
>>> >>  I wouldn't mind you to submit patches from my tree, but the expectation is
>>> >>  if you are changing the original code, it should be under your sign-off.
>> >  Thanks, good to learn. I'll remove in next time.
>>> >>  Coming to the patch, #ifdef in driver is not recommended, and this 10msec
>>> >>  delay is specific to OMAP GPIO and driver should not be aware of this,
>>> >>  that's where you will find the original patch handling it in board file.
>> >  According to the git blame of the board-omap3evm.c I think
>> >  96974a24 did a good thing to all the related codes for omap3
>> >  boards. So I think we can call board and driver as BSP level:-)
>> >  
>> >  If #ifdef in driver can save many codes, I guess it's deserved.
> No, platform/board specific ifdefs in the generic driver code are never
> deserved.
> How about the attached patch, does it fix the problem for you?
Sorry Igor, I just read your patch, yes, most are there, and we
just have to set get_pendown_state as you early said. Really
*thanks* for your drive :)

Regards,
Zumeng
> -- Regards, Igor.
> ads7846.patch
>
>
> diff --git a/arch/arm/mach-omap2/common-board-devices.c b/arch/arm/mach-omap2/common-board-devices.c
> index 1706ebc..c187586 100644
> --- a/arch/arm/mach-omap2/common-board-devices.c
> +++ b/arch/arm/mach-omap2/common-board-devices.c
> @@ -63,28 +63,30 @@ void __init omap_ads7846_init(int bus_num, int gpio_pendown, int gpio_debounce,
>   	struct spi_board_info *spi_bi =&ads7846_spi_board_info;
>   	int err;
>
> -	if (board_pdata&&  board_pdata->get_pendown_state) {
> -		err = gpio_request_one(gpio_pendown, GPIOF_IN, "TSPenDown");
> -		if (err) {
> -			pr_err("Couldn't obtain gpio for TSPenDown: %d\n", err);
> -			return;
> -		}
> -		gpio_export(gpio_pendown, 0);
> -
> -		if (gpio_debounce)
> -			gpio_set_debounce(gpio_pendown, gpio_debounce);
> +	err = gpio_request_one(gpio_pendown, GPIOF_IN, "TSPenDown");
> +	if (err) {
> +		pr_err("Couldn't obtain gpio for TSPenDown: %d\n", err);
> +		return;
>   	}
>   	
> +	if (gpio_debounce)
> +		gpio_set_debounce(gpio_pendown, gpio_debounce);
> +
>   	spi_bi->bus_num	= bus_num;
>   	spi_bi->irq	= gpio_to_irq(gpio_pendown);
>
>   	if (board_pdata) {
>   		board_pdata->gpio_pendown = gpio_pendown;
>   		spi_bi->platform_data = board_pdata;
> +		if (board_pdata->get_pendown_state)
> +			gpio_export(gpio_pendown, 0);
>   	} else {
>   		ads7846_config.gpio_pendown = gpio_pendown;
>   	}
>
> +	if (!board_pdata || (board_pdata&&  !board_pdata->get_pendown_state))
> +		gpio_free(gpio_pendown);
> +
>   	spi_register_board_info(&ads7846_spi_board_info, 1);
>   }
>   #else

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120614/23df068c/attachment-0001.html>

[PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level

[Igor Grinberg]

On 06/14/12 10:08, Zumeng Chen wrote:
> ? 2012?06?14? 14:44, Igor Grinberg ??:
>> On 06/14/12 07:46, Zumeng Chen wrote:
>>> > ? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
>>>> >> On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
>>>>> >>> From: Zumeng Chen<zumeng.chen@windriver.com>
>>>>> >>>
>>>>> >>> If we don't set proper debouce time for ads7846, then there are
>>>>> >>> flooded interrupt counters of ads7846 responding to one time
>>>>> >>> touch on screen, so the driver couldn't work well.
>>>>> >>>
>>>>> >>> And since most OMAP3 series boards pass NULL pointer of board_pdata
>>>>> >>> to omap_ads7846_init, so it's more proper to set it in driver level
>>>>> >>> after having gpio_request done.
>>>>> >>>
>>>>> >>> This patch has been validated on 3530evm.
>>>>> >>>
>>>>> >>> Signed-off-by: Zumeng Chen<zumeng.chen@windriver.com>
>>>>> >>> Signed-off-by: Syed Mohammed Khasim<khasim@ti.com>
>>>>> >>> ---
>>>>> >>>   drivers/input/touchscreen/ads7846.c |    4 ++++
>>>>> >>>   1 files changed, 4 insertions(+), 0 deletions(-)
>>>>> >>>
>>>>> >>> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
>>>>> >>> index f02028e..459ff29 100644
>>>>> >>> --- a/drivers/input/touchscreen/ads7846.c
>>>>> >>> +++ b/drivers/input/touchscreen/ads7846.c
>>>>> >>> @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
>>>>> >>>           }
>>>>> >>>
>>>>> >>>           ts->gpio_pendown = pdata->gpio_pendown;
>>>>> >>> +#ifdef CONFIG_ARCH_OMAP3
>>>>> >>> +        /* 310 means about 10 microsecond for omap3 */
>>>>> >>> +        gpio_set_debounce(pdata->gpio_pendown, 310);
>>>>> >>> +#endif
>>>>> >>>
>>>> >> Zumeng,
>>>> >>
>>>> >> With my sign-off you are changing the original code, that too
>>>> >> without my sign-off and ack.
>>>> >> I wouldn't mind you to submit patches from my tree, but the expectation is
>>>> >> if you are changing the original code, it should be under your sign-off.
>>> > Thanks, good to learn. I'll remove in next time.
>>>> >> Coming to the patch, #ifdef in driver is not recommended, and this 10msec
>>>> >> delay is specific to OMAP GPIO and driver should not be aware of this,
>>>> >> that's where you will find the original patch handling it in board file.
>>> > According to the git blame of the board-omap3evm.c I think
>>> > 96974a24 did a good thing to all the related codes for omap3
>>> > boards. So I think we can call board and driver as BSP level :-)
>>> > 
>>> > If #ifdef in driver can save many codes, I guess it's deserved.
>> No, platform/board specific ifdefs in the generic driver code are never
>> deserved.
>> How about the attached patch, does it fix the problem for you?
> Sorry Igor, I just read your patch, yes, most are there, and we
> just have to set get_pendown_state as you early said. Really
> *thanks* for your drive :)

No, with my patch, you don't need the get_pendown_state() and
you don't need to change the board-omap3evm.c ADS7846 related code.
So, I'm going to submit my patch properly.

> 
> Regards,
> Zumeng
>> -- Regards, Igor.
>> ads7846.patch
>>
>>
>> diff --git a/arch/arm/mach-omap2/common-board-devices.c b/arch/arm/mach-omap2/common-board-devices.c
>> index 1706ebc..c187586 100644
>> --- a/arch/arm/mach-omap2/common-board-devices.c
>> +++ b/arch/arm/mach-omap2/common-board-devices.c
>> @@ -63,28 +63,30 @@ void __init omap_ads7846_init(int bus_num, int gpio_pendown, int gpio_debounce,
>>  	struct spi_board_info *spi_bi = &ads7846_spi_board_info;
>>  	int err;
>>  
>> -	if (board_pdata && board_pdata->get_pendown_state) {
>> -		err = gpio_request_one(gpio_pendown, GPIOF_IN, "TSPenDown");
>> -		if (err) {
>> -			pr_err("Couldn't obtain gpio for TSPenDown: %d\n", err);
>> -			return;
>> -		}
>> -		gpio_export(gpio_pendown, 0);
>> -
>> -		if (gpio_debounce)
>> -			gpio_set_debounce(gpio_pendown, gpio_debounce);
>> +	err = gpio_request_one(gpio_pendown, GPIOF_IN, "TSPenDown");
>> +	if (err) {
>> +		pr_err("Couldn't obtain gpio for TSPenDown: %d\n", err);
>> +		return;
>>  	}
>>  	
>> +	if (gpio_debounce)
>> +		gpio_set_debounce(gpio_pendown, gpio_debounce);
>> +
>>  	spi_bi->bus_num	= bus_num;
>>  	spi_bi->irq	= gpio_to_irq(gpio_pendown);
>>  
>>  	if (board_pdata) {
>>  		board_pdata->gpio_pendown = gpio_pendown;
>>  		spi_bi->platform_data = board_pdata;
>> +		if (board_pdata->get_pendown_state)
>> +			gpio_export(gpio_pendown, 0);
>>  	} else {
>>  		ads7846_config.gpio_pendown = gpio_pendown;
>>  	}
>>  
>> +	if (!board_pdata || (board_pdata && !board_pdata->get_pendown_state))
>> +		gpio_free(gpio_pendown);
>> +
>>  	spi_register_board_info(&ads7846_spi_board_info, 1);
>>  }
>>  #else
> 

-- 
Regards,
Igor.

[PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level

[Zumeng Chen]

? 2012?06?14? 16:06, Igor Grinberg ??:
> On 06/14/12 10:08, Zumeng Chen wrote:
>> ? 2012?06?14? 14:44, Igor Grinberg ??:
>>> On 06/14/12 07:46, Zumeng Chen wrote:
>>>>> ? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
>>>>>>> On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
>>>>>>>>> From: Zumeng Chen<zumeng.chen@windriver.com>
>>>>>>>>>
>>>>>>>>> If we don't set proper debouce time for ads7846, then there are
>>>>>>>>> flooded interrupt counters of ads7846 responding to one time
>>>>>>>>> touch on screen, so the driver couldn't work well.
>>>>>>>>>
>>>>>>>>> And since most OMAP3 series boards pass NULL pointer of board_pdata
>>>>>>>>> to omap_ads7846_init, so it's more proper to set it in driver level
>>>>>>>>> after having gpio_request done.
>>>>>>>>>
>>>>>>>>> This patch has been validated on 3530evm.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Zumeng Chen<zumeng.chen@windriver.com>
>>>>>>>>> Signed-off-by: Syed Mohammed Khasim<khasim@ti.com>
>>>>>>>>> ---
>>>>>>>>>    drivers/input/touchscreen/ads7846.c |    4 ++++
>>>>>>>>>    1 files changed, 4 insertions(+), 0 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
>>>>>>>>> index f02028e..459ff29 100644
>>>>>>>>> --- a/drivers/input/touchscreen/ads7846.c
>>>>>>>>> +++ b/drivers/input/touchscreen/ads7846.c
>>>>>>>>> @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
>>>>>>>>>            }
>>>>>>>>>
>>>>>>>>>            ts->gpio_pendown = pdata->gpio_pendown;
>>>>>>>>> +#ifdef CONFIG_ARCH_OMAP3
>>>>>>>>> +        /* 310 means about 10 microsecond for omap3 */
>>>>>>>>> +        gpio_set_debounce(pdata->gpio_pendown, 310);
>>>>>>>>> +#endif
>>>>>>>>>
>>>>>>> Zumeng,
>>>>>>>
>>>>>>> With my sign-off you are changing the original code, that too
>>>>>>> without my sign-off and ack.
>>>>>>> I wouldn't mind you to submit patches from my tree, but the expectation is
>>>>>>> if you are changing the original code, it should be under your sign-off.
>>>>> Thanks, good to learn. I'll remove in next time.
>>>>>>> Coming to the patch, #ifdef in driver is not recommended, and this 10msec
>>>>>>> delay is specific to OMAP GPIO and driver should not be aware of this,
>>>>>>> that's where you will find the original patch handling it in board file.
>>>>> According to the git blame of the board-omap3evm.c I think
>>>>> 96974a24 did a good thing to all the related codes for omap3
>>>>> boards. So I think we can call board and driver as BSP level :-)
>>>>>
>>>>> If #ifdef in driver can save many codes, I guess it's deserved.
>>> No, platform/board specific ifdefs in the generic driver code are never
>>> deserved.
>>> How about the attached patch, does it fix the problem for you?
>> Sorry Igor, I just read your patch, yes, most are there, and we
>> just have to set get_pendown_state as you early said. Really
>> *thanks* for your drive :)
> No, with my patch, you don't need the get_pendown_state() and
> you don't need to change the board-omap3evm.c ADS7846 related code.
> So, I'm going to submit my patch properly.
Feel free to do that

>> Regards,
>> Zumeng
>>> -- Regards, Igor.
>>> ads7846.patch
>>>
>>>
>>> diff --git a/arch/arm/mach-omap2/common-board-devices.c b/arch/arm/mach-omap2/common-board-devices.c
>>> index 1706ebc..c187586 100644
>>> --- a/arch/arm/mach-omap2/common-board-devices.c
>>> +++ b/arch/arm/mach-omap2/common-board-devices.c
>>> @@ -63,28 +63,30 @@ void __init omap_ads7846_init(int bus_num, int gpio_pendown, int gpio_debounce,
>>>   	struct spi_board_info *spi_bi =&ads7846_spi_board_info;
>>>   	int err;
>>>
>>> -	if (board_pdata&&  board_pdata->get_pendown_state) {
>>> -		err = gpio_request_one(gpio_pendown, GPIOF_IN, "TSPenDown");
>>> -		if (err) {
>>> -			pr_err("Couldn't obtain gpio for TSPenDown: %d\n", err);
>>> -			return;
>>> -		}
>>> -		gpio_export(gpio_pendown, 0);
>>> -
>>> -		if (gpio_debounce)
>>> -			gpio_set_debounce(gpio_pendown, gpio_debounce);
>>> +	err = gpio_request_one(gpio_pendown, GPIOF_IN, "TSPenDown");
>>> +	if (err) {
>>> +		pr_err("Couldn't obtain gpio for TSPenDown: %d\n", err);
>>> +		return;
>>>   	}
>>>   	
>>> +	if (gpio_debounce)
>>> +		gpio_set_debounce(gpio_pendown, gpio_debounce);
>>> +
>>>   	spi_bi->bus_num	= bus_num;
>>>   	spi_bi->irq	= gpio_to_irq(gpio_pendown);
>>>
>>>   	if (board_pdata) {
>>>   		board_pdata->gpio_pendown = gpio_pendown;
>>>   		spi_bi->platform_data = board_pdata;
>>> +		if (board_pdata->get_pendown_state)
>>> +			gpio_export(gpio_pendown, 0);
>>>   	} else {
>>>   		ads7846_config.gpio_pendown = gpio_pendown;
>>>   	}
>>>
>>> +	if (!board_pdata || (board_pdata&&  !board_pdata->get_pendown_state))
>>> +		gpio_free(gpio_pendown);
>>> +
>>>   	spi_register_board_info(&ads7846_spi_board_info, 1);
>>>   }
>>>   #else