OMAP3530evm misc fixes for linux-omap
Subsystems (7)
cover OMAP3530evm misc fixes for linux-omap
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
--- arch/arm/mach-omap2/board-omap3evm.c | 39 ++++++++++++++++++++++++++++++++++ 1 files changed, 39 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3evm.c +39 -0
@@ -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 ();
Signature · 1 line
1.7.5.4
PATCH 1/5 ARM: OMAP3EVM: Add NAND flash definition
Quoted 2 lines · Zumeng Chen
Signed-off-by Vaibhav Hiremath <[email protected]>Tested-by Zumeng Chen <[email protected]>
I think that you need to have something in the changelog above, even if this is a trivial change.
Quoted 28 lines
--- arch/arm/mach-omap2/board-omap3evm.c | 39 ++++++++++++++++++++++++++++++++++ 1 files changed, 39 insertions(+), 0 deletions(-)arch/arm/mach-omap2/board-omap3evm.c +5
-0@@ -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>
arch/arm/mach-omap2/board-omap3evm.c static struct regulator_consumer_supply dummy_supplies[] = { · line 618
Quoted 7 lines
arch/arm/mach-omap2/board-omap3evm.c +4
-0@@ -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".
arch/arm/mach-omap2/board-omap3evm.c static struct regulator_consumer_supply dummy_supplies[] = { · line 624
Quoted 6 lines
arch/arm/mach-omap2/board-omap3evm.c +6
-0+ .offset = 0, + .size = 4*(SZ_128K), + .mask_flags =MTD_WRITEABLE + }, + { + .name = "uboot-nand",
"U-Boot"
arch/arm/mach-omap2/board-omap3evm.c static struct regulator_consumer_supply dummy_supplies[] = { · line 630
Quoted 6 lines
arch/arm/mach-omap2/board-omap3evm.c +6
-0+ .offset = MTDPART_OFS_APPEND, + .size = 14*(SZ_128K), + .mask_flags =MTD_WRITEABLE + }, + { + .name = "params-nand",
"U-Boot Env"
arch/arm/mach-omap2/board-omap3evm.c static struct regulator_consumer_supply dummy_supplies[] = { · line 635
Quoted 5 lines
arch/arm/mach-omap2/board-omap3evm.c +5
-0+ .offset = MTDPART_OFS_APPEND, + .size = 2*(SZ_128K) + }, + { + .name = "linux-nand",
"Kernel"
arch/arm/mach-omap2/board-omap3evm.c static struct regulator_consumer_supply dummy_supplies[] = { · line 640
Quoted 5 lines
arch/arm/mach-omap2/board-omap3evm.c +5
-0+ .offset = MTDPART_OFS_APPEND, + .size = 40*(SZ_128K) + }, + { + .name = "jffs2-nand",
"File System"
Quoted 9 lines
arch/arm/mach-omap2/board-omap3evm.c +5
-0+ .size = MTDPART_SIZ_FULL, + .offset = MTDPART_OFS_APPEND, + }, +}; +static void __init omap3_evm_init (void ) {struct omap_board_mux *obm;
arch/arm/mach-omap2/board-omap3evm.c static void __init omap3_evm_init(void) · line 700
Quoted 9 lines
arch/arm/mach-omap2/board-omap3evm.c +3
-0@@ -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
Hi Jon,
Many thanks for your quickly reply, please see my in-line reply
2012/6/11 Jon Hunter <[email protected]>
Quoted 9 lines · Zumeng Chen
Quoted 2 lines
Signed-off-by Vaibhav Hiremath <[email protected]>Tested-by Zumeng Chen <[email protected]>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
Quoted 37 lines
Quoted 3 lines
--- arch/arm/mach-omap2/board-omap3evm.c | 39++++++++++++++++++++++++++++++++++
Review
Quoted 3 lines
1 files changed, 39 insertions(+), 0 deletions(-)(quoted diff) +0
-0
b/arch/arm/mach-omap2/board-omap3evm.carch/arm/mach-omap2/board-omap3evm.c static struct regulator_consumer_supply
Quoted 23 lines
index 639bd07..fef911d 100644
arch/arm/mach-omap2/board-omap3evm.c +5
-0@@ -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_supplydummy_supplies[] = {
arch/arm/mach-omap2/board-omap3evm.c static struct regulator_consumer_supply dummy_supplies[] = {
Quoted 5 lines
arch/arm/mach-omap2/board-omap3evm.c +2
-0REGULATOR_SUPPLY("vdd33a", "smsc911x.0"), }; +static struct mtd_partition omap3evm_nand_partitions[] = { +/* All the partition sizes are listed in terms of NAND block size
Quoted 8 lines
*/
arch/arm/mach-omap2/board-omap3evm.c static struct regulator_consumer_supply dummy_supplies[] = { · line 618
Quoted 2 lines
arch/arm/mach-omap2/board-omap3evm.c +2
-0+ { + .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.
Quoted 44 lines
arch/arm/mach-omap2/board-omap3evm.c static struct regulator_consumer_supply dummy_supplies[] = { · line 624
Quoted 7 lines
arch/arm/mach-omap2/board-omap3evm.c +6
-0+ .offset = 0, + .size = 4*(SZ_128K), + .mask_flags =MTD_WRITEABLE + }, + { + .name = "uboot-nand","U-Boot"
arch/arm/mach-omap2/board-omap3evm.c static struct regulator_consumer_supply dummy_supplies[] = { · line 630
Quoted 6 lines
arch/arm/mach-omap2/board-omap3evm.c +6
-0+ .offset = MTDPART_OFS_APPEND, + .size = 14*(SZ_128K), + .mask_flags =MTD_WRITEABLE + }, + { + .name = "params-nand","U-Boot Env"
arch/arm/mach-omap2/board-omap3evm.c static struct regulator_consumer_supply dummy_supplies[] = { · line 635
Quoted 5 lines
arch/arm/mach-omap2/board-omap3evm.c +5
-0+ .offset = MTDPART_OFS_APPEND, + .size = 2*(SZ_128K) + }, + { + .name = "linux-nand","Kernel"
arch/arm/mach-omap2/board-omap3evm.c static struct regulator_consumer_supply dummy_supplies[] = { · line 640
Quoted 5 lines
arch/arm/mach-omap2/board-omap3evm.c +5
-0+ .offset = MTDPART_OFS_APPEND, + .size = 40*(SZ_128K) + }, + { + .name = "jffs2-nand","File System"
Quoted 10 lines
arch/arm/mach-omap2/board-omap3evm.c +5
-0+ .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) }
Quoted 9 lines
arch/arm/mach-omap2/board-omap3evm.c static void __init omap3_evm_init(void) · line 700
Quoted 8 lines
arch/arm/mach-omap2/board-omap3evm.c +3
-0usb_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
Quoted 4 lines
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
In reply to Zumeng ChenEHCI PHY requires these regulators:
EVM Rev >=E --> VAUX2
EVM Rev < E --> VUSB1V5, VUSB1V8Adding 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.
--- arch/arm/mach-omap2/board-omap3evm.c | 27 +++++++++++++++++++++++++++ 1 files changed, 27 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3evm.c +27 -0
@@ -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);
Signature · 1 line
1.7.5.4
PATCH 3/5 ARM: omap3evm: enable VBUS switch for EHCI tranceiver
In reply to Zumeng ChenTWL4030.GPIO2-...->(T2_GPIO2_3V3)U131-..>nUSB2_EN-..>U134-..>EXP_nUSB2_1V8 which starts EHCI tranceiver USB3320.
--- arch/arm/mach-omap2/board-omap3evm.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3evm.c +9 -0
@@ -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 ; }
Signature · 1 line
1.7.5.4
PATCH 4/5 MFD: OMAP3EVM: USB: cosmetic fix to failed parent clk set
In reply to Zumeng ChenA typo fix for this cosmetic change and mute a failed message from a unnecessary setting of some parent clk for usbhs_omap on OMAP3EVM.
--- drivers/mfd/omap-usb-host.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
drivers/mfd/omap-usb-host.c +3 -1
@@ -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) {
Signature · 1 line
1.7.5.4
PATCH 4/5 MFD: OMAP3EVM: USB: cosmetic fix to failed parent clk set
Quoted 13 lines · Zumeng Chen
A typo fix for this cosmetic change and mute a failed message from a unnecessary setting of some parent clk for
usbhs_omapon OMAP3EVM.Signed-off-by Zumeng Chen <[email protected]>--- drivers/mfd/omap-usb-host.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)drivers/mfd/omap-usb-host.c +0
-0
drivers/mfd/omap-usb-host.c static int __devinit usbhs_omap_probe(struct platform_device *pdev) · line 706
Quoted 10 lines
drivers/mfd/omap-usb-host.c +2
-1@@ -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
2012/6/11 Jon Hunter <[email protected]>
Quoted 27 lines · Zumeng Chen
drivers/mfd/omap-usb-host.c static int __devinit usbhs_omap_probe(struct
Quoted 13 lines
A typo fix for this cosmetic change and mute a failed message from a unnecessary setting of some parent clk for
usbhs_omapon OMAP3EVM.Signed-off-by Zumeng Chen <[email protected]>--- drivers/mfd/omap-usb-host.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)drivers/mfd/omap-usb-host.c +0
-0@@ -698,8 +698,9 @@ static int __devinit usbhs_omap_probe(struct
platform_device*pdev)drivers/mfd/omap-usb-host.c static int __devinit usbhs_omap_probe(struct platform_device *pdev) · line 706
Quoted 10 lines
drivers/mfd/omap-usb-host.c +2
-1goto 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 )
Quoted 4 lines
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
Quoted 4 lines
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
Quoted 36 lines · Zumeng Chen
2012/6/11 Jon Hunter <jon-hunter at ti.com <mailto:[email protected]>>
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 <[email protected] <mailto:[email protected]>> > --- > 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.
Quoted 8 lines
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_ckset parent failed"But why I bracket both of them, because, both
xclk60mhsp2_ckandxclk60mhsp1_ck
havedummy_ckclk for omap3530evm. So we can skip them directly.
How about something like this ...
arch/arm/plat-omap/clock.c +4 -0
@@ -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
2012/6/13 Jon Hunter <[email protected]>
Quoted 57 lines · Zumeng Chen
Quoted 8 lines
2012/6/11 Jon Hunter <jon-hunter at ti.com <mailto:[email protected]>>
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 forusbhs_omaponOMAP3EVM.
Quoted 8 lines
Quoted 2 lines
Signed-off-by Zumeng Chen <[email protected]<mailto:[email protected]>> > --- > 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.cQuoted 9 lines
drivers/mfd/omap-usb-host.c static int __devinit usbhs_omap_probe(struct
Quoted 4 lines
index 7e96bb2..9aaaf3c 100644
drivers/mfd/omap-usb-host.c +0
-0@@ -698,8 +698,9 @@ static int __devinit usbhs_omap_probe(structplatform_device *pdev) > goto err_usbtll_p2_fck; > } > > +#ifndef CONFIG_MACH_OMAP3EVMQuoted 8 lines
> + /* 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 ifthis
Quoted 11 lines
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_ckset parent failed"But why I bracket both of them, because, both
xclk60mhsp2_ckandxclk60mhsp1_ck
havedummy_ckclk for omap3530evm. So we can skip them directly.How about something like this ...
arch/arm/plat-omap/clock.c +0
-0
arch/arm/plat-omap/clock.c int clk_set_parent(struct clk *clk, struct clk · line 157
Quoted 9 lines
arch/arm/plat-omap/clock.c +4
-0@@ -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
Quoted 9 lines
arch/arm/plat-omap/clock.c +0
-0spin_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
In reply to Zumeng ChenQuoted 24 lines · Zumeng Chen
A typo fix for this cosmetic change and mute a failed message from a unnecessary setting of some parent clk for
usbhs_omapon OMAP3EVM.Signed-off-by Zumeng Chen <[email protected]>--- drivers/mfd/omap-usb-host.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)drivers/mfd/omap-usb-host.c +2
-1@@ -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 )
drivers/mfd/omap-usb-host.c static int __devinit usbhs_omap_probe(struct platform_device *pdev) · line 730
Quoted 4 lines
drivers/mfd/omap-usb-host.c +1
-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...
Quoted 3 lines
drivers/mfd/omap-usb-host.c +0
-0res =platform_get_resource_byname (pdev,IORESOURCE_MEM ,"uhh" );if (!res) {
Signature · 2 lines
Regards, Igor.
PATCH 5/5 Input: ads7846: set proper debounce time in driver level
In reply to Zumeng ChenIf 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.
--- drivers/input/touchscreen/ads7846.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
drivers/input/touchscreen/ads7846.c +2 -0
@@ -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" );
Signature · 1 line
1.7.5.4
PATCH 5/5 Input: ads7846: set proper debounce time in driver level
Hi,
This is input subsystem, add Dmitry and linux-input.
Quoted 7 lines · 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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.
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.
Quoted 15 lines
This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen <[email protected]>Signed-off-by Syed Mohammed Khasim <[email protected]>Signed-off-by Tony Lindgren <[email protected]>--- drivers/input/touchscreen/ads7846.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)drivers/input/touchscreen/ads7846.c +0
-0
drivers/input/touchscreen/ads7846.c line 64
Quoted 4 lines
drivers/input/touchscreen/ads7846.c +1
-0@@ -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?
Quoted 11 lines
drivers/input/touchscreen/ads7846.c +1
-0struct 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" );
Signature · 2 lines
Regards, Igor.
PATCH 5/5 Input: ads7846: set proper debounce time in driver level
2012/6/11 Igor Grinberg <[email protected]>
Quoted 9 lines
Hi,
This is input subsystem, add Dmitry and linux-input.
Quoted 4 lines · 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.
Quoted 6 lines
Quoted 3 lines
And since most OMAP3 series boards pass NULL pointer of
board_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.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
Quoted 4 lines
NULL pointer for
board_pdata, only means that the default pdata is used. Please, see thecommon-board-devices.cfile 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 aftergpio_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
Quoted 17 lines
Review
Quoted 11 lines
This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen <[email protected]>Signed-off-by Syed Mohammed Khasim <[email protected]>Signed-off-by Tony Lindgren <[email protected]>--- drivers/input/touchscreen/ads7846.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)(quoted diff) +0
-0
b/drivers/input/touchscreen/ads7846.cQuoted 5 lines
index f02028e..a82a5fb 100644
drivers/input/touchscreen/ads7846.c +0
-0@@ -61,6 +61,7 @@
Quoted 7 lines
drivers/input/touchscreen/ads7846.c line 63
Quoted 2 lines
drivers/input/touchscreen/ads7846.c +0
-0/* this driver doesn't aim at the peak continuous sample rate */ #define SAMPLE_BITS (8/*cmd*/ +16 /*sample*/ +2 /* before, after */)
drivers/input/touchscreen/ads7846.c line 64
Quoted 1 line
drivers/input/touchscreen/ads7846.c +1
-0+#define DEBOUNCE_TIME 310/* About 10 ms */ I think hard coding this value is wrong.
Yes, me too.
Quoted 2 lines
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
Quoted 10 lines
drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct
Quoted 4 lines
drivers/input/touchscreen/ads7846.c +0
-0struct ts_event {/* @@ -980,6 +981,7 @@ static int __devinit ads7846_setup_pendown(struct
spi_device*spi, struct ads784Quoted 5 lines
drivers/input/touchscreen/ads7846.c +1
-0} ts->gpio_pendown = pdata->gpio_pendown; +gpio_set_debounce (pdata->gpio_pendown,DEBOUNCE_TIME );
Quoted 8 lines
drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct · line 987
Quoted 2 lines
drivers/input/touchscreen/ads7846.c +0
-0}else { dev_err(&spi->dev, "no get_pendown_state norgpio_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
Quoted 13 lines · Zumeng Chen
2012/6/11 Igor Grinberg <grinberg at compulab.co.il <mailto:[email protected]>>
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.
>
Quoted 8 lines
> And since most OMAP3 series boards pass NULL pointer of
board_pdata> toomap_ads7846_init, so it's more proper to set it in driver level > after havinggpio_requestdone.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...
Quoted 8 lines
NULL pointer for
board_pdata, only means that the default pdata is used. Please, see thecommon-board-devices.cfile more closely.Yes, I just went through again, two points:
1 )
get_pendown_stateis not set for OMAP3 boards, and the state
You can supply your own pdata and provide the get_pendown_state() callback.
Quoted 11 lines
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_pendownfor pdata.
So it had better weset_debouncein driver level aftergpio_request_onehaving done
I'll removeDEBOUNCE_TIMEin V2 and change into like following:
Review
Quoted 4 lines
(quoted diff) +4
-0+#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...
Quoted 24 lines
Quoted 17 lines
This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen <zumeng.chen at gmail.com <mailto:[email protected]>>Signed-off-by Syed Mohammed Khasim <khasim at ti.com <mailto:[email protected]>>Signed-off-by Tony Lindgren <tony at atomide.com <mailto:[email protected]>>--- drivers/input/touchscreen/ads7846.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)drivers/input/touchscreen/ads7846.c +0
-0drivers/input/touchscreen/ads7846.c line 64
Quoted 4 lines
drivers/input/touchscreen/ads7846.c +1
-0@@ -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.
Quoted 8 lines
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?
Signature · 2 lines
Regards, Igor.
Tony Lindgren
maintainerPATCH 5/5 Input: ads7846: set proper debounce time in driver level
In reply to Zumeng ChenQuoted 8 lines · 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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.
Quoted 5 lines
This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen <[email protected]>Signed-off-by Syed Mohammed Khasim <[email protected]>Signed-off-by Tony Lindgren <[email protected]>
Please remove my Signed-off-by, where does that come from?
Tony
Quoted 26 lines
drivers/input/touchscreen/ads7846.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)drivers/input/touchscreen/ads7846.c +2
-0@@ -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" );Signature · 1 line
1.7.5.4
PATCH 5/5 Input: ads7846: set proper debounce time in driver level
2012/6/12 Tony Lindgren <[email protected]>
Quoted 9 lines · Zumeng Chen
Quoted 8 lines
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.
Quoted 8 lines
Quoted 5 lines
This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen <[email protected]>Signed-off-by Syed Mohammed Khasim <[email protected]>Signed-off-by Tony Lindgren <[email protected]>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
Quoted 23 lines
Tony
Review
Quoted 4 lines
drivers/input/touchscreen/ads7846.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)(quoted diff) +0
-0
b/drivers/input/touchscreen/ads7846.cdrivers/input/touchscreen/ads7846.c line 63
Quoted 7 lines
index f02028e..a82a5fb 100644
drivers/input/touchscreen/ads7846.c +0
-0@@ -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 */)
drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct
Quoted 5 lines
drivers/input/touchscreen/ads7846.c +1
-0+#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
Quoted 12 lines
drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784
Quoted 7 lines
drivers/input/touchscreen/ads7846.c +1
-0} ts->gpio_pendown = pdata->gpio_pendown; +gpio_set_debounce (pdata->gpio_pendown,DEBOUNCE_TIME ); }else { dev_err(&spi->dev, "no get_pendown_state norgpio_pendown?\n");
Quoted 3 lines
--
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>
Tony Lindgren
maintainerPATCH 5/5 Input: ads7846: set proper debounce time in driver level
Quoted 17 lines · Zumeng Chen
2012/6/12 Tony Lindgren <[email protected]>
Quoted 15 lines · Zumeng Chen
Quoted 13 lines
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen <[email protected]>Signed-off-by Syed Mohammed Khasim <[email protected]>Signed-off-by Tony Lindgren <[email protected]>
Quoted 7 lines
Quoted 2 lines
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 is53c5ec31, we setgpio_debounceinarch/boardlevel.
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
2012/6/13 Tony Lindgren <[email protected]>
Quoted 20 lines · Zumeng Chen
Quoted 19 lines
2012/6/12 Tony Lindgren <[email protected]>
Quoted 17 lines · Zumeng Chen
Quoted 8 lines
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.Quoted 5 lines
This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen <[email protected]>Signed-off-by Syed Mohammed Khasim <[email protected]>Signed-off-by Tony Lindgren <[email protected]>Please remove my Signed-off-by, where does that come from?
Quoted 9 lines
Quoted 5 lines
HI Tony,
This comes from
git://arago-project.org/git/projects/linux-omap3.git
The commit ID is53c5ec31, we setgpio_debounceinarch/boardlevel.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
Quoted 3 lines
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
In reply to Tony Lindgren? 2012?06?13? 20:55, Tony Lindgren ??:
Quoted 19 lines · Zumeng Chen
Quoted 18 lines
2012/6/12 Tony Lindgren<[email protected]>
Quoted 16 lines · Zumeng Chen
Quoted 8 lines
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.Quoted 5 lines
This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen<[email protected]>Signed-off-by Syed Mohammed Khasim<[email protected]>Signed-off-by Tony Lindgren<[email protected]>Please remove my Signed-off-by, where does that come from?
Quoted 7 lines
Quoted 5 lines
HI Tony,
This comes from
git://arago-project.org/git/projects/linux-omap3.git
The commit ID is53c5ec31, we setgpio_debounceinarch/boardlevel.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
Quoted 1 line
Tony
cover OMAP3530evm misc fixes for linux-omap
In reply to Zumeng ChenQuoted 7 lines · 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).
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
cover OMAP3530evm misc fixes for linux-omap
2012/6/11 Jon Hunter <[email protected]>
Quoted 6 lines · Zumeng Chen
Quoted 4 lines
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.
Quoted 7 lines
Quoted 3 lines
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
Quoted 4 lines
Cheers
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120612/b621f9db/attachment-0001.html>
v2 cover ARM OMAP3530evm misc fixes for linux-omap
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
From: Zumeng Chen <[email protected]>
--- arch/arm/mach-omap2/board-omap3evm.c | 39 ++++++++++++++++++++++++++++++++++ 1 files changed, 39 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3evm.c +39 -0
@@ -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 ();
Signature · 1 line
1.7.5.4
PATCH v2 1/5 ARM: OMAP3EVM: Add NAND flash definition
Quoted 70 lines · Zumeng Chen
From: Zumeng Chen <[email protected]>
Signed-off-by Vaibhav Hiremath <[email protected]>Tested-by Zumeng Chen <[email protected]>--- arch/arm/mach-omap2/board-omap3evm.c | 39 ++++++++++++++++++++++++++++++++++ 1 files changed, 39 insertions(+), 0 deletions(-)arch/arm/mach-omap2/board-omap3evm.c +36
-0@@ -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;
arch/arm/mach-omap2/board-omap3evm.c static void __init omap3_evm_init(void) · line 697
Quoted 6 lines
arch/arm/mach-omap2/board-omap3evm.c +3
-0@@ -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]?
arch/arm/mach-omap2/board-omap3evm.c static void __init omap3_evm_init(void) · line 700
Quoted 3 lines
arch/arm/mach-omap2/board-omap3evm.c +0
-0omap_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
Signature · 2 lines
Regards, Igor.
PATCH v2 1/5 ARM: OMAP3EVM: Add NAND flash definition
? 2012?06?13? 15:57, Igor Grinberg ??:
Quoted 70 lines · Zumeng Chen
Quoted 69 lines
From: Zumeng Chen<[email protected]>
Signed-off-by Vaibhav Hiremath<[email protected]>Tested-by Zumeng Chen<[email protected]>--- arch/arm/mach-omap2/board-omap3evm.c | 39 ++++++++++++++++++++++++++++++++++ 1 files changed, 39 insertions(+), 0 deletions(-)arch/arm/mach-omap2/board-omap3evm.c +36
-0@@ -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;
Quoted 8 lines
arch/arm/mach-omap2/board-omap3evm.c static void __init omap3_evm_init(void) · line 697
Quoted 7 lines
arch/arm/mach-omap2/board-omap3evm.c +3
-0@@ -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
Quoted 5 lines
arch/arm/mach-omap2/board-omap3evm.c static void __init omap3_evm_init(void) · line 700
Quoted 3 lines
arch/arm/mach-omap2/board-omap3evm.c +0
-0omap_ads7846_init (1 ,OMAP3_EVM_TS_GPIO ,310 ,NULL );omap3evm_init_smsc911x ();omap3_evm_display_init ();
PATCH v2 2/5 ARM: OMAP3EVM: Adding USB internal LDOs board file
In reply to Zumeng ChenFrom: Zumeng Chen <[email protected]>
EHCI PHY requires these regulators:
EVM Rev >=E --> VAUX2
EVM Rev < E --> VUSB1V5, VUSB1V8Adding 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.
--- arch/arm/mach-omap2/board-omap3evm.c | 27 +++++++++++++++++++++++++++ 1 files changed, 27 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3evm.c +27 -0
@@ -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);
Signature · 1 line
1.7.5.4
PATCH v2 2/5 ARM: OMAP3EVM: Adding USB internal LDOs board file
Quoted 26 lines · Zumeng Chen
From: Zumeng Chen <[email protected]>
EHCI PHY requires these regulators:
EVM Rev >=E --> VAUX2 EVM Rev < E --> VUSB1V5, VUSB1V8Adding 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_datasince it will be added conditionally.Signed-off-by Ajay Kumar Gupta <[email protected]>Signed-off-by Vaibhav Hiremath <[email protected]>Signed-off-by Zumeng Chen <[email protected]>--- arch/arm/mach-omap2/board-omap3evm.c | 27 +++++++++++++++++++++++++++ 1 files changed, 27 insertions(+), 0 deletions(-)arch/arm/mach-omap2/board-omap3evm.c +0
-0@@ -466,6 +466,30 @@ struct wl12xx_platform_data omap3evm_wlan_data __initdata = { };
arch/arm/mach-omap2/board-omap3evm.c struct wl12xx_platform_data omap3evm_wlan_data __initdata = { · line 476
Quoted 10 lines
arch/arm/mach-omap2/board-omap3evm.c +8
-0#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?
Quoted 29 lines
arch/arm/mach-omap2/board-omap3evm.c +19
-0+}; + +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);
Signature · 2 lines
Regards, Igor.
PATCH v2 2/5 ARM: OMAP3EVM: Adding USB internal LDOs board file
? 2012?06?13? 16:16, Igor Grinberg ??:
Quoted 29 lines · Zumeng Chen
Quoted 28 lines
From: Zumeng Chen<[email protected]>
EHCI PHY requires these regulators:
EVM Rev>=E --> VAUX2 EVM Rev< E --> VUSB1V5, VUSB1V8Adding 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_datasince it will be added conditionally.Signed-off-by Ajay Kumar Gupta<[email protected]>Signed-off-by Vaibhav Hiremath<[email protected]>Signed-off-by Zumeng Chen<[email protected]>--- arch/arm/mach-omap2/board-omap3evm.c | 27 +++++++++++++++++++++++++++ 1 files changed, 27 insertions(+), 0 deletions(-)arch/arm/mach-omap2/board-omap3evm.c +0
-0@@ -466,6 +466,30 @@ struct wl12xx_platform_data omap3evm_wlan_data __initdata = { };#endif
Quoted 9 lines
arch/arm/mach-omap2/board-omap3evm.c struct wl12xx_platform_data omap3evm_wlan_data __initdata = { · line 476
Quoted 8 lines
arch/arm/mach-omap2/board-omap3evm.c +8
-0+/* 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
Quoted 29 lines
Quoted 29 lines
arch/arm/mach-omap2/board-omap3evm.c +19
-0+}; + +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
In reply to Zumeng ChenFrom: Zumeng Chen <[email protected]>
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.
--- arch/arm/mach-omap2/board-omap3evm.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3evm.c +9 -0
@@ -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 ; }
Signature · 1 line
1.7.5.4
PATCH v2 4/5 ARM: OMAP3EVM: cosmetic fixes for parent clk set
In reply to Zumeng ChenFrom: Zumeng Chen <[email protected]>
Since set parent for dummy clock will dump failed message, so we can just ignore to mute it.
--- arch/arm/plat-omap/clock.c | 4 ++++ drivers/mfd/omap-usb-host.c | 2 +- 2 files changed, 5 insertions(+), 1 deletions(-)
arch/arm/plat-omap/clock.c +4 -0
@@ -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);
drivers/mfd/omap-usb-host.c +1 -1
@@ -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 )
Signature · 1 line
1.7.5.4
PATCH v2 5/5 Input: ads7846: set proper debounce time in driver level
In reply to Zumeng ChenFrom: Zumeng Chen <[email protected]>
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.
--- drivers/input/touchscreen/ads7846.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
drivers/input/touchscreen/ads7846.c +4 -0
@@ -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" );
Signature · 1 line
1.7.5.4
PATCH v2 5/5 Input: ads7846: set proper debounce time in driver level
Quoted 23 lines · Zumeng Chen
From: Zumeng Chen <[email protected]>
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen <[email protected]>Signed-off-by Syed Mohammed Khasim <[email protected]>--- drivers/input/touchscreen/ads7846.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)drivers/input/touchscreen/ads7846.c +0
-0
drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 · line 986
Quoted 7 lines
drivers/input/touchscreen/ads7846.c +4
-0@@ -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...)
Quoted 3 lines
drivers/input/touchscreen/ads7846.c +0
-0}else {dev_err (&spi->dev,"no get_pendown_state nor gpio_pendown?\n" );
Signature · 2 lines
Regards, Igor.
PATCH v2 5/5 Input: ads7846: set proper debounce time in driver level
? 2012?06?13? 15:51, Igor Grinberg ??:
Quoted 26 lines · Zumeng Chen
Quoted 25 lines
From: Zumeng Chen<[email protected]>
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen<[email protected]>Signed-off-by Syed Mohammed Khasim<[email protected]>--- drivers/input/touchscreen/ads7846.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)drivers/input/touchscreen/ads7846.c +0
-0@@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 }
Quoted 6 lines
drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 · line 986
Quoted 5 lines
drivers/input/touchscreen/ads7846.c +4
-0ts->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.
Quoted 2 lines
I'd suggest you to implement
theget_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
Quoted 6 lines
If more users will need this, it can be facilitated in the driver. (and of course not with the ugly ifdefs...)
Quoted 3 lines
drivers/input/touchscreen/ads7846.c +0
-0}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
Quoted 33 lines · Zumeng Chen
? 2012?06?13? 15:51, Igor Grinberg ??:
Quoted 26 lines · Zumeng Chen
Quoted 25 lines
From: Zumeng Chen<[email protected]>
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen<[email protected]>Signed-off-by Syed Mohammed Khasim<[email protected]>--- drivers/input/touchscreen/ads7846.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)drivers/input/touchscreen/ads7846.c +0
-0@@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 }Quoted 6 lines
drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 · line 986
Quoted 5 lines
drivers/input/touchscreen/ads7846.c +4
-0ts->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,
Quoted 6 lines
Yes, this is the case.
Quoted 2 lines
I'd suggest you to implement
theget_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.
Quoted 15 lines
Regards,
ZumengQuoted 6 lines
If more users will need this, it can be facilitated in the driver. (and of course not with the ugly ifdefs...)
Quoted 3 lines
drivers/input/touchscreen/ads7846.c +0
-0}else {dev_err (&spi->dev,"no get_pendown_state nor gpio_pendown?\n" );Signature · 3 lines
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
Signature · 2 lines
Regards, Igor.
PATCH v2 5/5 Input: ads7846: set proper debounce time in driver level
Dear Igor Grinberg,
Quoted 45 lines · Zumeng Chen
Quoted 44 lines
? 2012?06?13? 15:51, Igor Grinberg ??:
Quoted 29 lines · Zumeng Chen
Quoted 28 lines
From: Zumeng Chen<[email protected]>
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen<[email protected]>Signed-off-by Syed Mohammed Khasim<[email protected]>---
drivers/input/touchscreen/ads7846.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)(quoted diff) +0
-0
b/drivers/input/touchscreen/ads7846.cindex f02028e..459ff29 100644drivers/input/touchscreen/ads7846.c +0
-0@@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct
spi_device*spi, struct ads784}Quoted 8 lines
drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 · line 986
Quoted 6 lines
ts->gpio_pendown = pdata->gpio_pendown;drivers/input/touchscreen/ads7846.c +4
-0+#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.
Quoted 2 lines
I'd suggest you to implement
theget_pendown_state()method in the board file.
Quoted 6 lines
Quoted 3 lines
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
Quoted 10 lines
Quoted 10 lines
Regards,
ZumengQuoted 7 lines
If more users will need this, it can be facilitated in the driver. (and of course not with the ugly ifdefs...)
Quoted 4 lines
} 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
In reply to Zumeng ChenQuoted 23 lines · Zumeng Chen
From: Zumeng Chen <[email protected]>
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen <[email protected]>Signed-off-by Syed Mohammed Khasim <[email protected]>--- drivers/input/touchscreen/ads7846.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)drivers/input/touchscreen/ads7846.c +0
-0
drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 · line 987
Quoted 8 lines
drivers/input/touchscreen/ads7846.c +4
-0@@ -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
Quoted 6 lines
drivers/input/touchscreen/ads7846.c +0
-0}else {dev_err (&spi->dev,"no get_pendown_state nor gpio_pendown?\n" );Signature · 1 line
1.7.5.4
PATCH v2 5/5 Input: ads7846: set proper debounce time in driver level
2012/6/13 Hiremath, Vaibhav <[email protected]>
Quoted 37 lines · Zumeng Chen
Quoted 12 lines
From: Zumeng Chen <[email protected]>
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.This patch has been validated on 3530evm.
Review
Quoted 7 lines
Signed-off-by Zumeng Chen <[email protected]>Signed-off-by Syed Mohammed Khasim <[email protected]>--- drivers/input/touchscreen/ads7846.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)(quoted diff) +0
-0
b/drivers/input/touchscreen/ads7846.cdrivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct
Quoted 4 lines
index f02028e..459ff29 100644
drivers/input/touchscreen/ads7846.c +0
-0@@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct
spi_device*spi, struct ads784drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 · line 987
Quoted 8 lines
drivers/input/touchscreen/ads7846.c +4
-0} 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,
Quoted 5 lines
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.
Quoted 5 lines
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
Quoted 12 lines
Thanks,
Vaibhavdrivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct · line 989
Quoted 2 lines
drivers/input/touchscreen/ads7846.c +0
-0}else { dev_err(&spi->dev, "no get_pendown_state norgpio_pendown?\n");
Quoted 4 lines
--
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
In reply to Hiremath, Vaibhav? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
Quoted 34 lines · Zumeng Chen
Quoted 23 lines
From: Zumeng Chen<[email protected]>
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen<[email protected]>Signed-off-by Syed Mohammed Khasim<[email protected]>--- drivers/input/touchscreen/ads7846.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)drivers/input/touchscreen/ads7846.c +0
-0drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 · line 987
Quoted 8 lines
drivers/input/touchscreen/ads7846.c +4
-0@@ -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,
Quoted 4 lines
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.
Quoted 3 lines
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
Quoted 8 lines
Thanks,
VaibhavQuoted 6 lines
drivers/input/touchscreen/ads7846.c +0
-0}else {dev_err (&spi->dev,"no get_pendown_state nor gpio_pendown?\n" );Signature · 1 line
1.7.5.4
PATCH v2 5/5 Input: ads7846: set proper debounce time in driver level
Quoted 40 lines · Zumeng Chen
? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
Quoted 34 lines · Zumeng Chen
Quoted 23 lines
From: Zumeng Chen<[email protected]>
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen<[email protected]>Signed-off-by Syed Mohammed Khasim<[email protected]>--- drivers/input/touchscreen/ads7846.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)drivers/input/touchscreen/ads7846.c +0
-0drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 · line 987
Quoted 8 lines
drivers/input/touchscreen/ads7846.c +4
-0@@ -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,
Quoted 4 lines
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.
Quoted 9 lines
Quoted 3 lines
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.cI think96974a24did 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
? 2012?06?14? 14:31, Hiremath, Vaibhav ??:
Quoted 48 lines · Zumeng Chen
Quoted 47 lines
? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
Quoted 34 lines · Zumeng Chen
Quoted 23 lines
From: Zumeng Chen<[email protected]>
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen<[email protected]>Signed-off-by Syed Mohammed Khasim<[email protected]>--- drivers/input/touchscreen/ads7846.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)drivers/input/touchscreen/ads7846.c +0
-0drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 · line 987
Quoted 8 lines
drivers/input/touchscreen/ads7846.c +4
-0@@ -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,
Quoted 4 lines
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.
Quoted 3 lines
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.cI think96974a24did a good thing to all the related codes for omap3 boards. So I think we can call board and driver as BSP level :-)
Quoted 6 lines
Quoted 2 lines
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
Quoted 4 lines
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
Quoted 58 lines · Zumeng Chen
? 2012?06?14? 14:31, Hiremath, Vaibhav ??:
Quoted 48 lines · Zumeng Chen
Quoted 47 lines
? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
Quoted 34 lines · Zumeng Chen
Quoted 23 lines
From: Zumeng Chen<[email protected]>
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen<[email protected]>Signed-off-by Syed Mohammed Khasim<[email protected]>--- drivers/input/touchscreen/ads7846.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)drivers/input/touchscreen/ads7846.c +0
-0drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 · line 987
Quoted 8 lines
drivers/input/touchscreen/ads7846.c +4
-0@@ -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,
Quoted 4 lines
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.
Quoted 3 lines
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.cI think96974a24did a good thing to all the related codes for omap3 boards. So I think we can call board and driver as BSP level :-)Quoted 6 lines
Quoted 2 lines
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_statefor every omap3 board? Currently,board_pdatais NULL.
Quoted 8 lines
And actually, the reason why I agree
96974a24is thatget_pendown_statefor 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
Quoted 6 lines
Regards,
ZumengQuoted 4 lines
So no need for #ifdefs in driver...
Thanks,
Vaibhav
PATCH v2 5/5 Input: ads7846: set proper debounce time in driver level
In reply to Zumeng Chen? 2012?06?14? 14:59, Zumeng Chen ??:
Quoted 58 lines
? 2012?06?14? 14:31, Hiremath, Vaibhav ??:
Quoted 48 lines · Zumeng Chen
Quoted 47 lines
? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
Quoted 34 lines · Zumeng Chen
Quoted 23 lines
From: Zumeng Chen<[email protected]>
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen<[email protected]>Signed-off-by Syed Mohammed Khasim<[email protected]>--- drivers/input/touchscreen/ads7846.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)drivers/input/touchscreen/ads7846.c +0
-0drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 · line 987
Quoted 8 lines
drivers/input/touchscreen/ads7846.c +4
-0@@ -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,
Quoted 4 lines
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.
Quoted 3 lines
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.cI think96974a24did a good thing to all the related codes for omap3 boards. So I think we can call board and driver as BSP level :-)Quoted 6 lines
Quoted 2 lines
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_statefor every omap3 board? Currently,board_pdatais NULL.
Quoted 8 lines
And actually, the reason why I agree
96974a24is thatget_pendown_statefor 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
Quoted 7 lines
Regards,
ZumengQuoted 4 lines
So no need for #ifdefs in driver...
Thanks,
Vaibhav
PATCH v2 5/5 Input: ads7846: set proper debounce time in driver level
In reply to Zumeng ChenQuoted 40 lines · Zumeng Chen
? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
Quoted 34 lines · Zumeng Chen
Quoted 23 lines
From: Zumeng Chen<[email protected]>
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen<[email protected]>Signed-off-by Syed Mohammed Khasim<[email protected]>--- drivers/input/touchscreen/ads7846.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)drivers/input/touchscreen/ads7846.c +0
-0drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 · line 987
Quoted 8 lines
drivers/input/touchscreen/ads7846.c +4
-0@@ -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,
Quoted 4 lines
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.
Quoted 8 lines
Quoted 3 lines
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.cI think96974a24did 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?
Signature · 9 lines
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
? 2012?06?14? 14:44, Igor Grinberg ??:
Quoted 44 lines · Zumeng Chen
Quoted 43 lines
Quoted 43 lines
? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
Quoted 32 lines
Quoted 32 lines · Zumeng Chen
Quoted 31 lines
Quoted 31 lines
From: Zumeng Chen<[email protected]>
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen<[email protected]>Signed-off-by Syed Mohammed Khasim<[email protected]>---
drivers/input/touchscreen/ads7846.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)diff --git
a/drivers/input/touchscreen/ads7846.cb/drivers/input/touchscreen/ads7846.cindex f02028e..459ff29 100644
---a/drivers/input/touchscreen/ads7846.c
+++b/drivers/input/touchscreen/ads7846.c
@@ -980,6 +980,10 @@ static int__devinitads7846_setup_pendown(structspi_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);
+#endifQuoted 6 lines
Quoted 6 lines
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.
Quoted 3 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 5 lines
Quoted 5 lines
According to the git blame of the
board-omap3evm.cI think96974a24did 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
Quoted 39 lines
-- Regards, Igor.
ads7846.patcharch/arm/mach-omap2/common-board-devices.c +9
-10@@ -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 );
arch/arm/mach-omap2/common-board-devices.c void __init omap_ads7846_init(int bus_num, int gpio_pendown, int gpio_debounce, · line 92
Quoted 10 lines
arch/arm/mach-omap2/common-board-devices.c +3
-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
Quoted 49 lines · Zumeng Chen
? 2012?06?14? 14:44, Igor Grinberg ??:
Quoted 48 lines · Zumeng Chen
Quoted 47 lines
Quoted 47 lines
? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
Quoted 34 lines
Quoted 34 lines · Zumeng Chen
Quoted 25 lines
Quoted 25 lines
From: Zumeng Chen<[email protected]>
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen<[email protected]>Signed-off-by Syed Mohammed Khasim<[email protected]>--- drivers/input/touchscreen/ads7846.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)drivers/input/touchscreen/ads7846.c +0
-0@@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 }Quoted 6 lines
drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 · line 987
Quoted 6 lines
drivers/input/touchscreen/ads7846.c +4
-0ts->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,
Quoted 4 lines
Quoted 4 lines
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.
Quoted 3 lines
Quoted 3 lines
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.cI think96974a24did a good thing to all the related codes for omap3 boards. So I think we can call board and driver as BSP level :-)
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
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_stateas 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.
Quoted 53 lines
Regards,
ZumengQuoted 49 lines
-- Regards, Igor.
ads7846.patcharch/arm/mach-omap2/common-board-devices.c +12
-10@@ -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
Signature · 2 lines
Regards, Igor.
PATCH v2 5/5 Input: ads7846: set proper debounce time in driver level
? 2012?06?14? 16:06, Igor Grinberg ??:
Quoted 54 lines · Zumeng Chen
Quoted 53 lines
? 2012?06?14? 14:44, Igor Grinberg ??:
Quoted 52 lines · Zumeng Chen
Quoted 40 lines
Quoted 40 lines
? 2012?06?13? 20:18, Hiremath, Vaibhav ??:
Quoted 34 lines
Quoted 34 lines · Zumeng Chen
Quoted 25 lines
Quoted 25 lines
From: Zumeng Chen<[email protected]>
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_pdatatoomap_ads7846_init, so it's more proper to set it in driver level after havinggpio_requestdone.This patch has been validated on 3530evm.
Signed-off-by Zumeng Chen<[email protected]>Signed-off-by Syed Mohammed Khasim<[email protected]>--- drivers/input/touchscreen/ads7846.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)drivers/input/touchscreen/ads7846.c +0
-0@@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 }Quoted 6 lines
drivers/input/touchscreen/ads7846.c static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 · line 987
Quoted 6 lines
drivers/input/touchscreen/ads7846.c +4
-0ts->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,
Quoted 4 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
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.cI think96974a24did 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?
Quoted 6 lines
Quoted 3 lines
Sorry Igor, I just read your patch, yes, most are there, and we just have to set
get_pendown_stateas 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 theboard-omap3evm.cADS7846 related code. So, I'm going to submit my patch properly.
Feel free to do that
Quoted 51 lines
Quoted 51 lines
Regards,
ZumengQuoted 49 lines
-- Regards, Igor.
ads7846.patcharch/arm/mach-omap2/common-board-devices.c +12
-10@@ -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