Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On Friday 15 June 2012, Mitch Bradley wrote:
#address-cells =1;
#size-cells =1;
ranges;
In light of the reg entries below, perhaps #size-cells=0 ?
dmae@0xfe008020{
compatible = renesas,sh-dma;
reg =0xfe008020 0xfe00828f
0xfe009000 0xfe00900b
interrupts =0x20c0 0x2000 0x2020 0x2040 0x2060
0x2080 0x20a0;
};
These are actually ranges I copied from the static resource definitions,
I just forgot to change the format from start-end to start-length.
It should really be
reg =0xfe008020 0x270 0xfe009000 0xc;
Sorry about that.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] Prepare for GPMC driver conversion
Hi,
Objective of this series is to make things easy for GPMC driver
conversion series by separating out more things from driver
conversion series.
This series,
1. Unifies NAND platform initialization functions
2. Prepares OneNAND platform code for gpmc driver migration
3. Handles additional timings in Kernel
This series is based on 3.5-rc1 made on top of
[PATCH v2 00/10] Prepare for GPMC driver conversion (w.r.t MTD)
{http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70096.html}
These changes has been tested with omap3evm beagle board. Relevant
GPMC peripherals that got tested by this were NAND (beagle) and
OneNAND (using local patches for omap3evm)
Hi Jon,
If you can test these changes on boards having NAND it would be
really helpful. Tony's remaining concern with this series is
whether this would cause NAND filesystem corruption
Regards
Afzal
v2:
1. Make use of timing api for setting clock activation time, and
remove direct writing to register for clock activation. Peripherals
making use of it were tusb6010 onenand
2. Move ensuring that async mode in OneNAND has been setup from
set_sync to setup function, improve commit message
Afzal Mohammed (3):
ARM: OMAP2+: nand: unify init functions
ARM: OMAP2+: onenand: prepare for gpmc driver migration
ARM: OMAP2+: gpmc: handle additional timings
arch/arm/mach-omap2/board-devkit8000.c |8 +++--
arch/arm/mach-omap2/board-flash.c | 45 ++-
arch/arm/mach-omap2/board-flash.h |6 ++--
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-ldp.c|4 +--
arch/arm/mach-omap2/board-omap3beagle.c|8 +++--
arch/arm/mach-omap2/board-omap3touchbook.c |8 +++--
arch/arm/mach-omap2/board-overo.c |7 +++--
arch/arm/mach-omap2/board-zoom.c |5 +--
arch/arm/mach-omap2/common-board-devices.c | 46
arch/arm/mach-omap2/common-board-devices.h |1 -
arch/arm/mach-omap2/gpmc-onenand.c | 28 -
arch/arm/mach-omap2/gpmc.c |6
arch/arm/mach-omap2/usb-tusb6010.c |3 +-
arch/arm/plat-omap/include/plat/gpmc.h |6
15 files changed, 82 insertions(+), 101 deletions(-)
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] ARM: OMAP2+: nand: unify init functions
Helper function for updating nand platform data has been
added the capability to take timing structure arguement.
Usage of omap_nand_flash_init() has been replaced by modifed
one, omap_nand_flash_init was doing things similar to
board_nand_init except that NAND CS# were being acquired
based on bootloader setting. As CS# is hardwired for a given
board, acquiring gpmc CS# has been removed, and updated with
the value on board.
NAND CS# used in beagle board was found to be CS0.
Thomas Weber thomas.weber.li...@googlemail.com reported
that value of devkit8000 to be CS0. Overo board was found
to be using CS0 based on u-boot, while google grep says
omap3touchbook too has CS0.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/board-devkit8000.c |8 +++--
arch/arm/mach-omap2/board-flash.c | 45 ++-
arch/arm/mach-omap2/board-flash.h |6 ++--
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-ldp.c|4 +--
arch/arm/mach-omap2/board-omap3beagle.c|8 +++--
arch/arm/mach-omap2/board-omap3touchbook.c |8 +++--
arch/arm/mach-omap2/board-overo.c |7 +++--
arch/arm/mach-omap2/board-zoom.c |5 +--
arch/arm/mach-omap2/common-board-devices.c | 46
arch/arm/mach-omap2/common-board-devices.h |1 -
11 files changed, 56 insertions(+), 84 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 6567c1c..6ee429a 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -59,8 +59,11 @@
#include mux.h
#include hsmmc.h
+#include board-flash.h
#include common-board-devices.h
+#defineNAND_CS 0
+
#define OMAP_DM9000_GPIO_IRQ 25
#define OMAP3_DEVKIT_TS_GPIO 27
@@ -628,8 +631,9 @@ static void __init devkit8000_init(void)
usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
- omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
-ARRAY_SIZE(devkit8000_nand_partitions));
+ board_nand_init(devkit8000_nand_partitions,
+ ARRAY_SIZE(devkit8000_nand_partitions), NAND_CS,
+ NAND_BUSWIDTH_16, NULL);
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 70a81f9..0ee820b 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -108,41 +108,41 @@ __init board_onenand_init(struct mtd_partition
*nor_parts, u8 nr_parts, u8 cs)
defined(CONFIG_MTD_NAND_OMAP2_MODULE)
/* Note that all values in this struct are in nanoseconds */
-static struct gpmc_timings nand_timings = {
+struct gpmc_timings nand_default_timings[1] = {
+ {
+ .sync_clk = 0,
- .sync_clk = 0,
+ .cs_on = 0,
+ .cs_rd_off = 36,
+ .cs_wr_off = 36,
- .cs_on = 0,
- .cs_rd_off = 36,
- .cs_wr_off = 36,
+ .adv_on = 6,
+ .adv_rd_off = 24,
+ .adv_wr_off = 36,
- .adv_on = 6,
- .adv_rd_off = 24,
- .adv_wr_off = 36,
+ .we_off = 30,
+ .oe_off = 48,
- .we_off = 30,
- .oe_off = 48,
+ .access = 54,
+ .rd_cycle = 72,
+ .wr_cycle = 72,
- .access = 54,
- .rd_cycle = 72,
- .wr_cycle = 72,
-
- .wr_access = 30,
- .wr_data_mux_bus = 0,
+ .wr_access = 30,
+ .wr_data_mux_bus = 0,
+ },
};
-static struct omap_nand_platform_data board_nand_data = {
- .gpmc_t = nand_timings,
-};
+static struct omap_nand_platform_data board_nand_data;
void
-__init board_nand_init(struct mtd_partition *nand_parts,
- u8 nr_parts, u8 cs, int nand_type)
+__init board_nand_init(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs,
+ int nand_type, struct gpmc_timings *gpmc_t)
{
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
+ board_nand_data.gpmc_t = gpmc_t;
board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
@@ -243,5 +243,6 @@ void __init board_flash_init(struct flash_partitions
partition_info[],
pr_err(NAND: Unable to find configuration in GPMC\n);
else
board_nand_init(partition_info[2].parts,
- partition_info[2].nr_parts, nandcs, nand_type);
+ partition_info[2].nr_parts, nandcs,
+ nand_type,
[PATCH v2 2/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Reorganize gpmc-onenand initialization so that changes
required for gpmc driver migration can be made smooth.
Ensuring sync read/write are disabled in onenand cannot
be expected to work properly unless GPMC is setup, this
has been removed. And invocation of set_async has been
moved from set_sync to gpmc_onenand_init function; gpmc
for onenand needs to be initialized to async mode (even
for sync mode initially). Ensuring that onenand part
has been setup for async mode has been moved now to
setup function.
Thanks to Jon for his suggestions on improving this change.
Signed-off-by: Afzal Mohammed af...@ti.com
---
v2: Move ensuring that async mode in OneNAND has been setup from
set_sync to setup function, improve commit message
arch/arm/mach-omap2/gpmc-onenand.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 71d7c07..975c1f9 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -38,10 +38,9 @@ static struct platform_device gpmc_onenand_device = {
.resource = gpmc_onenand_resource,
};
-static int omap2_onenand_set_async_mode(int cs, void __iomem *onenand_base)
+static int omap2_onenand_set_async_mode(int cs)
{
struct gpmc_timings t;
- u32 reg;
int err;
const int t_cer = 15;
@@ -55,11 +54,6 @@ static int omap2_onenand_set_async_mode(int cs, void __iomem
*onenand_base)
const int t_wpl = 40;
const int t_wph = 30;
- /* Ensure sync read and sync write are disabled */
- reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
- reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
- writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
-
memset(t, 0, sizeof(t));
t.sync_clk = 0;
t.cs_on = 0;
@@ -95,10 +89,6 @@ static int omap2_onenand_set_async_mode(int cs, void __iomem
*onenand_base)
if (err)
return err;
- /* Ensure sync read and sync write are disabled */
- reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
- reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
- writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
return 0;
}
@@ -197,13 +187,10 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
sync_read = 1;
sync_write = 1;
} else
- return omap2_onenand_set_async_mode(cs, onenand_base);
+ return 0;
if (!freq) {
/* Very first call freq is not known */
- err = omap2_onenand_set_async_mode(cs, onenand_base);
- if (err)
- return err;
freq = omap2_onenand_get_freq(cfg, onenand_base, clk_dep);
first_time = 1;
}
@@ -385,6 +372,12 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
static int gpmc_onenand_setup(void __iomem *onenand_base, int *freq_ptr)
{
struct device *dev = gpmc_onenand_device.dev;
+ u32 reg;
+
+ /* Ensure sync read and sync write are disabled */
+ reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
+ reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
+ writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
/* Set sync timings in GPMC */
if (omap2_onenand_set_sync_mode(gpmc_onenand_data, onenand_base,
@@ -421,6 +414,8 @@ void __init gpmc_onenand_init(struct
omap_onenand_platform_data *_onenand_data)
gpmc_onenand_resource.end = gpmc_onenand_resource.start +
ONENAND_IO_SIZE - 1;
+ omap2_onenand_set_async_mode(gpmc_onenand_data-cs);
+
if (platform_device_register(gpmc_onenand_device) 0) {
pr_err(%s: Unable to register OneNAND device\n, __func__);
gpmc_cs_free(gpmc_onenand_data-cs);
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] ARM: OMAP2+: gpmc: handle additional timings
Configure busturnaround, cycle2cycledelay, waitmonitoringtime,
clkactivationtime in gpmc_cs_set_timings(). This is done so
that boards can configure these parameters of gpmc in Kernel
instead of relying on bootloader.
This needed change to two existing users that were configuring
clk activation time by directly writing to registers. Thanks to
Tony for making me aware of the issue being kind enough to
test this change.
Signed-off-by: Afzal Mohammed af...@ti.com
---
v2: Make use of timings api for setting clock activation time, and
remove direct writing to register for clock activation. Peripherals
making use of it were tusb6010 onenand
arch/arm/mach-omap2/gpmc-onenand.c |3 ++-
arch/arm/mach-omap2/gpmc.c |6 ++
arch/arm/mach-omap2/usb-tusb6010.c |3 ++-
arch/arm/plat-omap/include/plat/gpmc.h |6 ++
4 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 975c1f9..476b18c 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -316,6 +316,8 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
t.rd_cycle = gpmc_ticks_to_ns(fclk_offset + (latency + 1) * div +
ticks_cez);
+ t.clk_activation = fclk_offset_ns;
+
/* Write */
if (sync_write) {
t.adv_wr_off = t.adv_rd_off;
@@ -349,7 +351,6 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
(sync_read ? GPMC_CONFIG1_READTYPE_SYNC : 0) |
(sync_write ? GPMC_CONFIG1_WRITEMULTIPLE_SUPP : 0) |
(sync_write ? GPMC_CONFIG1_WRITETYPE_SYNC : 0) |
- GPMC_CONFIG1_CLKACTIVATIONTIME(fclk_offset) |
GPMC_CONFIG1_PAGE_LEN(2) |
(cpu_is_omap34xx() ? 0 :
(GPMC_CONFIG1_WAIT_READ_MON |
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 578fd4c..517953f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -313,6 +313,12 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
GPMC_SET_ONE(GPMC_CS_CONFIG5, 24, 27, page_burst_access);
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 0, 3, bus_turnaround);
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 8, 11, cycle2cycle_delay);
+
+ GPMC_SET_ONE(GPMC_CS_CONFIG1, 18, 19, wait_monitoring);
+ GPMC_SET_ONE(GPMC_CS_CONFIG1, 25, 26, clk_activation);
+
if (cpu_is_omap34xx()) {
GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
diff --git a/arch/arm/mach-omap2/usb-tusb6010.c
b/arch/arm/mach-omap2/usb-tusb6010.c
index db84a46..5c98755 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -174,6 +174,8 @@ static int tusb_set_sync_mode(unsigned sysclk_ps, unsigned
fclk_ps)
tmp = t.cs_wr_off * 1000 + 7000 /* t_scsn_rdy_z */;
t.wr_cycle = next_clk(t.cs_wr_off, tmp, fclk_ps);
+ t.clk_activation = gpmc_ticks_to_ns(1);
+
return gpmc_cs_set_timings(sync_cs, t);
}
@@ -283,7 +285,6 @@ tusb6010_setup_interface(struct musb_hdrc_platform_data
*data,
| GPMC_CONFIG1_READTYPE_SYNC
| GPMC_CONFIG1_WRITEMULTIPLE_SUPP
| GPMC_CONFIG1_WRITETYPE_SYNC
- | GPMC_CONFIG1_CLKACTIVATIONTIME(1)
| GPMC_CONFIG1_PAGE_LEN(2)
| GPMC_CONFIG1_WAIT_READ_MON
| GPMC_CONFIG1_WAIT_WRITE_MON
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 2e6e259..802fb22 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -128,6 +128,12 @@ struct gpmc_timings {
u16 rd_cycle; /* Total read cycle time */
u16 wr_cycle; /* Total write cycle time */
+ u16 bus_turnaround;
+ u16 cycle2cycle_delay;
+
+ u16 wait_monitoring;
+ u16 clk_activation;
+
/* The following are only on OMAP3430 */
u16 wr_access; /* WRACCESSTIME */
u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Tony, On Fri, Jun 15, 2012 at 18:15:20, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120615 03:26]: Here clock is required even before driver is probed, i.e for platform to calculate timings, that has to be passed through platform data. Eventually we should be able to move the gpmc registration to the driver probe, especially with device tree. There's no need to set up gpmc before the driver probe runs for the device using gpmc. Just how the gpmc init gets called from the driver probe is still a bit open though.. Sorry, I did not get you, can you please clarify By gpmc registration, if you meant registering platform device for gpmc peripherals, for a board that uses the new gpmc driver interface*, it will be done in probe only. All the responsibilities of old gpmc init is now taken care by probe; probe in addition does setting up gpmc for each peripheral, registering platform device (if the board makes use of new driver interface). If a board uses new gpmc driver interface, gpmc for that device is not setup before gpmc probe. It may require some bus level hooks, or wrapper drivers for the generic device drivers like smsc911x. This too, not sure whether I follow you I understand the necessity for clk rate information in driver, but seems unless we have a generic way to scale timings for all the kinds of peripheral, having it may not be of much help. We should not need to pass clock handles around. It's better to export some helper functions in the gpmc code for the calculation. Currently we have helper function in gpmc.c for the same, were you referring those ? Regards Afzal *: [1] converts omap3evm beagle board to use new interface, in addition to [1], similar to it, one more series would be posted to convert remaining boards also to use the new gpmc driver interface. As these cannot be tested by me and as it depends on final shape of this basic driver conversion series (or the present series), they have not yet been converted [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69917.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] SPI: OMAP: fix over-eager devm_xxx() conversion (was: Re: [CFT 07/11] spi: omap2-mcspi: add DMA engine support)
Okay, I'm going to queue this up in my tree for -rc as no one seems to
be listening to any of the emails I've sent on Thursday.
On Thu, Jun 14, 2012 at 03:07:12PM +0100, Russell King - ARM Linux wrote:
From: Russell King rmk+ker...@arm.linux.org.uk
Subject: [PATCH] SPI: OMAP: fix over-eager devm_xxx() conversion
1a77b127ae (OMAP : SPI : use devm_* functions) converted the SPI
device controller state to use devm_kzalloc(). Unfortunately, this
is used against an unbound struct device, which results in the
following when the device is eventually bound to its driver:
[ cut here ]
WARNING: at /home/rmk/git/linux-rmk/drivers/base/dd.c:257
driver_probe_device+0x78/0x21c()
Modules linked in:
Backtrace:
[c0017d0c] (dump_backtrace+0x0/0x10c) from [c033e208]
(dump_stack+0x18/0x1c) r7: r6:c01ff28c r5:c040050c r4:0101
[c033e1f0] (dump_stack+0x0/0x1c) from [c00337ec]
(warn_slowpath_common+0x58/0x70)
[c0033794] (warn_slowpath_common+0x0/0x70) from [c0033828]
(warn_slowpath_null+0x24/0x2c)
[c0033804] (warn_slowpath_null+0x0/0x2c) from [c01ff28c]
(driver_probe_device+0x78/0x21c)
[c01ff214] (driver_probe_device+0x0/0x21c) from [c01ff49c]
(__driver_attach+0x6c/0x90)
[c01ff430] (__driver_attach+0x0/0x90) from [c01fda70]
(bus_for_each_dev+0x58/0x98)
[c01fda18] (bus_for_each_dev+0x0/0x98) from [c01ff0f4]
(driver_attach+0x20/0x28)
[c01ff0d4] (driver_attach+0x0/0x28) from [c01fe2f4]
(bus_add_driver+0xb4/0x230)
[c01fe240] (bus_add_driver+0x0/0x230) from [c01ffb24]
(driver_register+0xac/0x138)
[c01ffa78] (driver_register+0x0/0x138) from [c0215d4c]
(spi_register_driver+0x4c/0x60)
[c0215d00] (spi_register_driver+0x0/0x60) from [c045414c]
(ks8851_init+0x14/0x1c)
[c0454138] (ks8851_init+0x0/0x1c) from [c0008770]
(do_one_initcall+0x9c/0x164)
[c00086d4] (do_one_initcall+0x0/0x164) from [c0436410]
(kernel_init+0x128/0x210)
[c04362e8] (kernel_init+0x0/0x210) from [c0038754] (do_exit+0x0/0x72c)
---[ end trace 4dcda79f5e89dd84 ]---
ks8851 spi1.0: message enable is 0
ks8851 spi1.0: eth0: revision 0, MAC 08:00:28:01:4d:c6, IRQ 194, has EEPROM
Fix this by partially reverting the original commit.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/spi/spi-omap2-mcspi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 9d3409a..6263b0f 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -829,7 +829,7 @@ static int omap2_mcspi_setup(struct spi_device *spi)
mcspi_dma = mcspi-dma_channels[spi-chip_select];
if (!cs) {
- cs = devm_kzalloc(spi-dev , sizeof *cs, GFP_KERNEL);
+ cs = kzalloc(sizeof *cs, GFP_KERNEL);
if (!cs)
return -ENOMEM;
cs-base = mcspi-base + spi-chip_select * 0x14;
@@ -869,6 +869,7 @@ static void omap2_mcspi_cleanup(struct spi_device *spi)
cs = spi-controller_state;
list_del(cs-node);
+ kfree(cs);
}
if (spi-chip_select spi-master-num_chipselect) {
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level
Dear Igor Grinberg,
On 06/13/12 12:03, Zumeng Chen wrote:
于 2012年06月13日 15:51, Igor Grinberg 写道:
On 06/13/12 04:44, Zumeng Chen wrote:
From: Zumeng Chenzumeng.c...@windriver.com
If we don't set proper debouce time for ads7846, then there are
flooded interrupt counters of ads7846 responding to one time
touch on screen, so the driver couldn't work well.
And since most OMAP3 series boards pass NULL pointer of board_pdata
to omap_ads7846_init, so it's more proper to set it in driver level
after having gpio_request done.
This patch has been validated on 3530evm.
Signed-off-by: Zumeng Chenzumeng.c...@windriver.com
Signed-off-by: Syed Mohammed Khasimkha...@ti.com
---
drivers/input/touchscreen/ads7846.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c
b/drivers/input/touchscreen/ads7846.c index f02028e..459ff29 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct
spi_device *spi, struct ads784
}
ts-gpio_pendown = pdata-gpio_pendown;
+#ifdef CONFIG_ARCH_OMAP3
+/* 310 means about 10 microsecond for omap3 */
+gpio_set_debounce(pdata-gpio_pendown, 310);
+#endif
Unless this concerns many boards/archs/platforms,
Yes, this is the case.
I'd suggest you to implement
the get_pendown_state() method in the board file.
it seems they are different way between gpio and
get_pendown_state, and gpio way is used for omap3
to drive ads7846, so I guess we may have to do like this.
No, this is not (and does not have to be) OMAP wide.
The decision for this is made on per-board basis.
+1 agreed
Regards,
Zumeng
If more users will need this, it can be facilitated in the driver.
(and of course not with the ugly ifdefs...)
} else {
dev_err(spi-dev, no get_pendown_state nor
gpio_pendown?\n);
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gpio/omap: fix irq loss while in idle with debounce on
It seems that currently GPIO module is not working correctly during idle
when debounce is enabled - the system almost never responds to button
presses (observed on OMAP3530 ES2.1 and OMAP3630 ES1.2 pandora boards).
Even though wakeups are probably working, it seems that the GPIO module
itself is unable to detect input events and generate interrupts.
OMAP35x TRM also states that:
If the debounce clock is inactive, the debounce cell gates all
input signals and thus cannot be used.
So whenever we are disabling debounce clocks (for PM or other reasons),
be sure the module's debounce feature is disabled too.
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/gpio/gpio-omap.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index c4ed172..ff213e7 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -174,12 +174,22 @@ static inline void _gpio_dbck_enable(struct gpio_bank
*bank)
if (bank-dbck_enable_mask !bank-dbck_enabled) {
clk_enable(bank-dbck);
bank-dbck_enabled = true;
+
+ __raw_writel(bank-dbck_enable_mask,
+bank-base + bank-regs-debounce_en);
}
}
static inline void _gpio_dbck_disable(struct gpio_bank *bank)
{
if (bank-dbck_enable_mask bank-dbck_enabled) {
+ /*
+* Disable debounce before cutting it's clock. If debounce is
+* enabled but the clock is not, GPIO module seems to be unable
+* to detect events and generate interrupts at least on OMAP3.
+*/
+ __raw_writel(0, bank-base + bank-regs-debounce_en);
+
clk_disable(bank-dbck);
bank-dbck_enabled = false;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] ARM: OMAP4: hwmod data: add HWMOD_SWSUP_SIDLE to dss_hdmi to data
I would like to revive an old discussion regarding how to use a particular
idle mode for a specific use-case[1].
As per the OMAP4 documentation, audio over HDMI should be transmitted in
no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmode uses
no-idle/force-idle settings instead of smart-idle.
However, if this flag is used, smart-idle nor smart-idle wakeup-capable
features could not be used. This would not be ideal if we want, for instance,
to wake up using a HDMI cable connect event.
Ideally, the HDMI module should be set to no-idle when transmitting audio
and then go back to whatever mode it was (e.g., smart-idle) when audio
transmission is over. I am not sure how to do that, though.
In the past, it was suggested to use an integration function through
platform_data[2], which didn't seem to be suitable from the device tree
perspective; although there were no other alternatives[3].
It was also suggested to add functions to allow/block smart-idle
momentarily[4], but how would the driver let know omap_hwmod when to
allow/block smart-idle without using platform_data/integration function?
Thanks for your comments!
Ricardo
[1].http://www.mail-archive.com/linux-omap@vger.kernel.org/msg60226.html
[2].http://www.mail-archive.com/linux-omap@vger.kernel.org/msg60236.html
[3].http://www.mail-archive.com/linux-omap@vger.kernel.org/msg60316.html
[4].http://www.mail-archive.com/linux-omap@vger.kernel.org/msg60252.html
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 950454a..3568b3b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -865,6 +865,11 @@ static struct omap_hwmod omap44xx_dss_hdmi_hwmod = {
},
.opt_clks = dss_hdmi_opt_clks,
.opt_clks_cnt = ARRAY_SIZE(dss_hdmi_opt_clks),
+ /*
+* HDMI audio requires to not rely on smart idle and
+* use no-idle instead. Hence, set idle mode by software.
+*/
+ .flags = HWMOD_SWSUP_SIDLE,
};
/*
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
