[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

Re: [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

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

[Zumeng Chen]

[-- Attachment #1.1: Type: text/plain, Size: 3512 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 5358 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[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

Re: [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

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

[Zumeng Chen]

[-- Attachment #1.1: Type: text/plain, Size: 1613 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 2371 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [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@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

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

[Zumeng Chen]

[-- Attachment #1.1: Type: text/plain, Size: 2742 bytes --]

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@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
>

[-- Attachment #1.2: Type: text/html, Size: 3975 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [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

Re: [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.

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

[Zumeng Chen]

[-- Attachment #1.1: Type: text/plain, Size: 3265 bytes --]

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.
>

[-- Attachment #1.2: Type: text/html, Size: 4770 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [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@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@gmail.com <mailto:zumeng.chen@gmail.com>>
>     > Signed-off-by: Syed Mohammed Khasim <khasim@ti.com <mailto:khasim@ti.com>>
>     > Signed-off-by: Tony Lindgren <tony@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.

Re: [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
> 

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

[Zumeng Chen]

[-- Attachment #1.1: Type: text/plain, Size: 2363 bytes --]

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
> >
>

[-- Attachment #1.2: Type: text/html, Size: 3537 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [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

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

[Zumeng Chen]

[-- Attachment #1.1: Type: text/plain, Size: 1257 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 2364 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [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

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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

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

[Zumeng Chen]

[-- Attachment #1.1: Type: text/plain, Size: 679 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 1261 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel