Re: Bringing back gptimer_wakeup
On Mon, Jun 18, 2012 at 11:31 PM, Kevin Hilman khil...@ti.com wrote: Tasslehoff Kjappfot tasskj...@gmail.com writes: The support for using a timer to wake from suspend was removed in: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98e182a26bbbf5575457622337684ef61493e864 I found an alternative patch (http://www.mail-archive.com/linux-omap@vger.kernel.org/msg47836.html) that claimed to keep it working using GPTIMER1 instead, but I haven't been able to make it work (likely because the timer code has changed a good deal since the patch was posted). Anyone got a) a patch that enables this feature on newer kernels, or b) an idea how the patch above can be made to work? The branch below (based on v3.4) will work (at least on OMAP3) We've been holding off on putting this back becasue the timer interface has been going through some major cleanup/rework, but I would like to see this make it back in soonish. I got an off-list message from Tasslehoff, that the patch I sent worked for him. Regards Santosh -- 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: RFC: PATCH TI81xx fix MUSB software mode setting
- Original Message - From: Andrea Scian [mailto:r...@dave-tech.it] Sent: Monday, June 18, 2012 08:25 PM To: linux-omap@vger.kernel.org linux-omap@vger.kernel.org Subject: RFC: PATCH TI81xx fix MUSB software mode setting Dear all, when configuring our platform (DM8148 based) to work with USB0 as device and USB1 as host I've found some problems. It seems that you created the patch against the ti-psp release, there is another way to achieve this (one port as host and other port as device). Please refer to release/user's guide. Moreover, you should create a patch against mainline, where the musb_dsps.c is used instead of ti81xx.c, where there is no host-only or device-only mode, by default OTG mode is used. It was fine if I configure both as device or both as host or enable only one port, but configure both in different modes lead to a not working configuration. After a bit of debug I've found that probably the problem is inside ti81xx_musb_set_mode() because this configure the controller but does not set musb-board_mode. IIUC, without setting this structure the whole musb generic state machine does not work correctly. Attached you can find the patch that fixed the problem on our board. I hope -this can help others too and can be integrated inside the main tree. Feel free to comment and tell me if I've done something wrong. I hope the the patch format is quite correct for you. Best Regards, -- Andrea SCIAN -- 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: Please help! AM35xx mm/slab.c BUG
Hi,
On Tue, Jun 19, 2012 at 06:59:42, CF Adad wrote:
Anyway, we have advanced our kernel to today's latest l-o (3.5-rc2). Though
we are not considering the GPMC a likely source of the error at this moment,
I'm considering exploring this patchset. Unfortunately, the NAND is very
critical to our current efforts. So I'm trying to find a time where it would
be OK to disable it as you suggested to try this. Since these values are
being set now in Linux, do I need to rework my bootloaders as well? In my
current case, these settings are all done in u-boot. I do not believe Linux
did anything with them. Do I need to remove those in order to use your
patches? If I do, do I not lose access to those things while in the
bootloaders?
Please sent me your board file, I will modify it to use the
new interface with NAND relying on bootloader settings and
SMSC relying on Kernel.
No bootloader modifications are required.
Regards
Afzal
[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69501.html
[2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69881.html
[3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69891.html
[4] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69897.html
[5] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69917.html
[5.x] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69924.html
[6]
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 4bfe721..34816b9 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -105,12 +105,12 @@ static void gpmc_smsc911x_timing(struct gpmc_time_ctrl
*time_ctrl,
{
struct gpmc_timings t;
/* SMSC 9220 timings */
- unsigned tcycle_r = 165;
+ unsigned tcycle_r = 45;
unsigned tcsl_r = 32;
unsigned tcsh_r = 133;
unsigned tcsdv_r = 30;
unsigned tdoff_r = 9;
- unsigned tcycle_w = 165;
+ unsigned tcycle_w = 45;
unsigned tcsl_w = 32;
unsigned tcsh_w = 133;
unsigned tdsu_w = 7;
--
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: RFC: PATCH TI81xx fix MUSB software mode setting
Dear Ravi, Dear all, when configuring our platform (DM8148 based) to work with USB0 as device and USB1 as host I've found some problems. It seems that you created the patch against the ti-psp release, there is another way to achieve this (one port as host and other port as device). Yes you are correct, I'm using ti-psp by cloning this tree: http://arago-project.org/git/projects/linux-omap3.git Please refer to release/user's guide. I've looked here: http://processors.wiki.ti.com/index.php/Usbgeneralpage#One_port_as_host_and_other_port_as_Gadget_.28for_DM81XX.29 but this setup does not work. Both ports starts from b_idle state and always stay there. I've try both software setting and from hardware pin (I've left ID pin floating for USB0, device, and set ID pin to gnd for USB1, host only) without success. However if I configure both port as host or device (thus disabling OTG support) they work correctly (of course, only the device port works as device and host port as host in either case ;-) ) Moreover, you should create a patch against mainline, where the musb_dsps.c is used instead of ti81xx.c, where there is no host-only or device-only mode, by default OTG mode is used. Ok, but I've found here: http://processors.wiki.ti.com/index.php/TI81XX_USB_Driver_User_Guide#OTG_support_.28TI816X.2FTI814X.2FTI813x.29 that OTG is not supported for TI81xx. Am I wrong? Maybe the situation is different in the mainline? Best Regards and thank for you prompt answer, Andrea -- 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: Bringing back gptimer_wakeup
On 06/19/2012 08:07 AM, Shilimkar, Santosh wrote: On Mon, Jun 18, 2012 at 11:31 PM, Kevin Hilmankhil...@ti.com wrote: Tasslehoff Kjappfottasskj...@gmail.com writes: The support for using a timer to wake from suspend was removed in: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98e182a26bbbf5575457622337684ef61493e864 I found an alternative patch (http://www.mail-archive.com/linux-omap@vger.kernel.org/msg47836.html) that claimed to keep it working using GPTIMER1 instead, but I haven't been able to make it work (likely because the timer code has changed a good deal since the patch was posted). Anyone got a) a patch that enables this feature on newer kernels, or b) an idea how the patch above can be made to work? The branch below (based on v3.4) will work (at least on OMAP3) We've been holding off on putting this back becasue the timer interface has been going through some major cleanup/rework, but I would like to see this make it back in soonish. I got an off-list message from Tasslehoff, that the patch I sent worked for him. Regards Santosh Ah, that was meant to be an on-list message. Santosh' fix worked well on my 3.2.18 kernel. - Tasslehoff -- 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 v3 4/4] memory: emif: add device tree support to emif driver
On Fri, Jun 15, 2012 at 12:36 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Thu, Jun 14, 2012 at 9:18 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Thu, Jun 14, 2012 at 03:59:24PM +0530, Santosh Shilimkar wrote:
[..]
@@ -1267,7 +1534,13 @@ static int __init_or_module emif_probe(struct
platform_device *pdev)
struct resource *res;
int irq;
- emif = get_device_details(pdev);
+#if defined(CONFIG_OF)
+ if (pdev-dev.of_node)
+ emif = of_get_device_details(pdev-dev.of_node,
pdev-dev);
+ else
+#endif
+ emif = get_device_details(pdev);
+
Can't you do this without the #ifdef?
Can be done. Just need to have empty of_get_device_details()
for the !CONFIG_OF build to avoid build break.
Will fix that.
Updated patch below with the fix.
Regards
Santosh
From 85d38108fbf1f9f9be76a6086ca3b3ba8f53995a Mon Sep 17 00:00:00 2001
From: Aneesh V ane...@ti.com
Date: Mon, 30 Jan 2012 20:06:30 +0530
Subject: [PATCH v3 4/4] memory: emif: add device tree support to emif driver
Device tree support for the EMIF driver.
Reviewed-by: Benoit Cousson b-cous...@ti.com
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
[santosh.shilim...@ti.com: Rebased against 3.5-rc]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/memory/emif.c | 293 -
1 files changed, 292 insertions(+), 1 deletions(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 33a4396..4c168df 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -18,6 +18,7 @@
#include linux/platform_device.h
#include linux/interrupt.h
#include linux/slab.h
+#include linux/of.h
#include linux/debugfs.h
#include linux/seq_file.h
#include linux/module.h
@@ -49,6 +50,7 @@
* frequency in effect at the moment)
* @plat_data: Pointer to saved platform data.
* @debugfs_root: dentry to the root folder for EMIF in debugfs
+ * @np_ddr:Pointer to ddr device tree node
*/
struct emif_data {
u8 duplicate;
@@ -63,6 +65,7 @@ struct emif_data {
struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
struct dentry *debugfs_root;
+ struct device_node *np_ddr;
};
static struct emif_data *emif1;
@@ -1148,6 +1151,278 @@ static int is_custom_config_valid(struct
emif_custom_configs *cust_cfgs,
return valid;
}
+#if defined(CONFIG_OF)
+static void __init_or_module of_get_custom_configs(struct device_node *np_emif,
+ struct emif_data *emif)
+{
+ struct emif_custom_configs *cust_cfgs = NULL;
+ int len;
+ const int *lpmode, *poll_intvl;
+
+ lpmode = of_get_property(np_emif, low-power-mode, len);
+ poll_intvl = of_get_property(np_emif, temp-alert-poll-interval, len);
+
+ if (lpmode || poll_intvl)
+ cust_cfgs = devm_kzalloc(emif-dev, sizeof(*cust_cfgs),
+ GFP_KERNEL);
+
+ if (!cust_cfgs)
+ return;
+
+ if (lpmode) {
+ cust_cfgs-mask |= EMIF_CUSTOM_CONFIG_LPMODE;
+ cust_cfgs-lpmode = *lpmode;
+ of_property_read_u32(np_emif,
+ low-power-mode-timeout-performance,
+ cust_cfgs-lpmode_timeout_performance);
+ of_property_read_u32(np_emif,
+ low-power-mode-timeout-power,
+ cust_cfgs-lpmode_timeout_power);
+ of_property_read_u32(np_emif,
+ low-power-mode-freq-threshold,
+ cust_cfgs-lpmode_freq_threshold);
+ }
+
+ if (poll_intvl) {
+ cust_cfgs-mask |=
+ EMIF_CUSTOM_CONFIG_TEMP_ALERT_POLL_INTERVAL;
+ cust_cfgs-temp_alert_poll_interval_ms = *poll_intvl;
+ }
+
+ if (!is_custom_config_valid(cust_cfgs, emif-dev)) {
+ devm_kfree(emif-dev, cust_cfgs);
+ return;
+ }
+
+ emif-plat_data-custom_configs = cust_cfgs;
+}
+
+static void __init_or_module of_get_min_tck(struct device_node *np,
+ struct emif_data *emif)
+{
+ int ret = 0;
+ struct lpddr2_min_tck *min;
+
+ min = devm_kzalloc(emif-dev, sizeof(*min), GFP_KERNEL);
+ if (!min)
+ goto default_min_tck;
+
+ ret |= of_property_read_u32(np, tRPab-min-tck, min-tRPab);
+ ret |= of_property_read_u32(np, tRCD-min-tck, min-tRCD);
+ ret |= of_property_read_u32(np, tWR-min-tck, min-tWR);
+ ret |= of_property_read_u32(np,
Re: [PATCHv8 13/13] I2C: OMAP: simplify omap_i2c_ack_stat()
On Mon, Jun 18, 2012 at 9:00 PM, Wolfram Sang w.s...@pengutronix.de wrote:
On Mon, Jun 18, 2012 at 08:00:28PM +0530, Shubhrajyoti D wrote:
From: Felipe Balbi ba...@ti.com
stat BIT(1) is the same as BIT(1),
Not true. I'd guess you are missing some context in the patch
description.
See the explanation , hope I understood your concern correctly.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70277.html
so let's
simplify things a bit by removing stat from
all omap_i2c_ack_stat() calls.
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 6a79089..bac6305 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -763,7 +763,7 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev,
u16 *stat, int *err)
while (--timeout !(*stat OMAP_I2C_STAT_XUDF)) {
if (*stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, *stat (OMAP_I2C_STAT_XRDY |
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
return -ETIMEDOUT;
}
@@ -824,10 +824,11 @@ complete:
*/
if (stat (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, stat
- (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
- OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR |
- OMAP_I2C_STAT_ARDY));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR |
+ OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR |
+ OMAP_I2C_STAT_ARDY));
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
@@ -874,8 +875,8 @@ complete:
}
}
}
- omap_i2c_ack_stat(dev,
- stat (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR));
continue;
}
@@ -922,8 +923,8 @@ complete:
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
- omap_i2c_ack_stat(dev,
- stat (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR));
continue;
}
--
1.7.5.4
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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] spi: omap2-mcspi: fix section mismatch regression in probe
Commit 7d6b6d83(make it behave as a module) annotated probe with
__devinit, but a referenced function was not.
This introduced a section mismatch warning:
WARNING: vmlinux.o(.devinit.text+0x3eec): Section mismatch in reference
from the function omap2_mcspi_probe() to the function
.init.text:omap2_mcspi_master_setup()
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/spi/spi-omap2-mcspi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 46ef5fe..1618e89 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1031,7 +1031,7 @@ static int omap2_mcspi_transfer_one_message(struct
spi_master *master,
return 0;
}
-static int __init omap2_mcspi_master_setup(struct omap2_mcspi *mcspi)
+static int __devinit omap2_mcspi_master_setup(struct omap2_mcspi *mcspi)
{
struct spi_master *master = mcspi-master;
struct omap2_mcspi_regs *ctx = mcspi-ctx;
--
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
[PATCH v2 1/4] ARM: new cache maintenance api for iommu mem flush
From 785a1f2854002ce7c1c8880bc5d8d92a7868bf1c Mon Sep 17 00:00:00 2001
From: Ramesh Gupta G grgu...@ti.com
Date: Fri, 15 Jun 2012 16:37:20 +0530
Subject: [PATCH v2 1/4] ARM: new cache maintenance api for iommu mem flush
non-coherent IOMMUs need to make sure that the
data held in the caches need to be visible for the
MMU hardware. A new L1 cache maintenance api has been
created to handle this. Thanks to RMK's suggestions on
creating a dedicated API for this purpose.
ref:
http://marc.info/?l=linux-kernelm=131316512713815w=2
Signed-off-by: Ramesh Gupta G grgu...@ti.com
---
arch/arm/include/asm/cacheflush.h | 17 +
arch/arm/include/asm/glue-cache.h |1 +
arch/arm/mm/proc-macros.S |1 +
3 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/cacheflush.h
b/arch/arm/include/asm/cacheflush.h
index d5d8d5c..2b4f5aa 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -84,6 +84,11 @@
* - kaddr - page address
* - size - region size
*
+ * flush_mem(start, end)
+ *
+ * Clean and invalidate the specified virtual address range.
+ * - start - virtual start address
+ * - end- virtual end address
* DMA Cache Coherency
* ===
*
@@ -108,6 +113,7 @@ struct cpu_cache_fns {
void (*dma_unmap_area)(const void *, size_t, int);
void (*dma_flush_range)(const void *, const void *);
+ void (*flush_mem)(const void *, const void *);
};
/*
@@ -135,6 +141,12 @@ extern struct cpu_cache_fns cpu_cache;
#define dmac_unmap_areacpu_cache.dma_unmap_area
#define dmac_flush_range cpu_cache.dma_flush_range
+/* This API is to support non-coherent IOMMUs. The purpose of
+ * this API is to ensure that data held in the cache is visible
+ * to MMU.
+ */
+#define flush_mem cpu_cache.flush_mem
+
#else
extern void __cpuc_flush_icache_all(void);
@@ -155,6 +167,11 @@ extern void dmac_map_area(const void *, size_t, int);
extern void dmac_unmap_area(const void *, size_t, int);
extern void dmac_flush_range(const void *, const void *);
+/* This API is to support non-coherent IOMMUs. The purpose of
+ * this API is to ensure that data held in the cache is visible
+ * to MMU.
+ */
+extern void flush_mem(const void *, const void *);
#endif
/*
diff --git a/arch/arm/include/asm/glue-cache.h
b/arch/arm/include/asm/glue-cache.h
index 7e30874..59818a4 100644
--- a/arch/arm/include/asm/glue-cache.h
+++ b/arch/arm/include/asm/glue-cache.h
@@ -141,6 +141,7 @@
#define dmac_map_area __glue(_CACHE,_dma_map_area)
#define dmac_unmap_area__glue(_CACHE,_dma_unmap_area)
#define dmac_flush_range __glue(_CACHE,_dma_flush_range)
+#define flush_mem __glue(_CACHE,_flush_mem)
#endif
#endif
diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
index 2d8ff3a..f48a5ab 100644
--- a/arch/arm/mm/proc-macros.S
+++ b/arch/arm/mm/proc-macros.S
@@ -307,6 +307,7 @@ ENTRY(\name\()_cache_fns)
.long \name\()_dma_map_area
.long \name\()_dma_unmap_area
.long \name\()_dma_flush_range
+ .long \name\()_flush_mem
.size \name\()_cache_fns, . - \name\()_cache_fns
.endm
--
1.7.0.4
--
regards
Ramesh Gupta G
--
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 2/4] ARM: add flush_mem api for ARMv6
From 630a3a8f341eb7f58f9a63bf786d732b5bdfd01e Mon Sep 17 00:00:00 2001 From: Ramesh Gupta G grgu...@ti.com Date: Fri, 15 Jun 2012 16:39:21 +0530 Subject: [PATCH v2 2/4] ARM: add flush_mem api for ARMv6 Added flush_mem cache maintenance api for ARMv6. The implementation is based on dma_flush_range. Signed-off-by: Ramesh Gupta G grgu...@ti.com --- arch/arm/mm/cache-v6.S | 28 1 files changed, 28 insertions(+), 0 deletions(-) diff --git a/arch/arm/mm/cache-v6.S b/arch/arm/mm/cache-v6.S index 74c2e5a..f91d847 100644 --- a/arch/arm/mm/cache-v6.S +++ b/arch/arm/mm/cache-v6.S @@ -328,6 +328,34 @@ ENTRY(v6_dma_unmap_area) mov pc, lr ENDPROC(v6_dma_unmap_area) +/* + * v6_flush_mem(start,end) + * - start - virtual start address of region + * - end - virtual end address of region + */ +ENTRY(v6_flush_mem) +#ifdef CONFIG_DMA_CACHE_RWFO + ldrbr2, [r0]@ read for ownership + strbr2, [r0]@ write for ownership +#endif + bic r0, r0, #D_CACHE_LINE_SIZE - 1 +1: +#ifdef HARVARD_CACHE + mcr p15, 0, r0, c7, c14, 1 @ clean invalidate D line +#else + mcr p15, 0, r0, c7, c15, 1 @ clean invalidate line +#endif + add r0, r0, #D_CACHE_LINE_SIZE + cmp r0, r1 +#ifdef CONFIG_DMA_CACHE_RWFO + ldrlob r2, [r0]@ read for ownership + strlob r2, [r0]@ write for ownership +#endif + blo 1b + mov r0, #0 + mcr p15, 0, r0, c7, c10, 4 @ drain write buffer + mov pc, lr +ENDPROC(v6_flush_mem) __INITDATA @ define struct cpu_cache_fns (see asm/cacheflush.h and proc-macros.S) -- 1.7.0.4 -- regards Ramesh Gupta G -- 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/4] ARM: add flush_mem api for ARMv7
From 635d33cf6c6758fb2063aa2adc03b69ce0d2799a Mon Sep 17 00:00:00 2001 From: Ramesh Gupta G grgu...@ti.com Date: Fri, 15 Jun 2012 16:45:41 +0530 Subject: [PATCH v2 3/4] ARM: add flush_mem api for ARMv7 Added flush_mem cache maintenance api for ARMv7. The implementation is based on dma_flush_range. Signed-off-by: Ramesh Gupta G grgu...@ti.com --- arch/arm/mm/cache-v7.S | 21 + 1 files changed, 21 insertions(+), 0 deletions(-) diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index a655d3d..2e041c8 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -322,6 +322,27 @@ ENTRY(v7_dma_flush_range) dsb mov pc, lr ENDPROC(v7_dma_flush_range) +/* + * v7_flush_mem(start,end) + * - start - virtual start address of region + * - end - virtual end address of region + */ +ENTRY(v7_flush_mem) + dcache_line_size r2, r3 + sub r3, r2, #1 + bic r0, r0, r3 +#ifdef CONFIG_ARM_ERRATA_764369 + ALT_SMP(W(dsb)) + ALT_UP(W(nop)) +#endif +1: + mcr p15, 0, r0, c7, c14, 1 @ clean invalidate D / U line + add r0, r0, r2 + cmp r0, r1 + blo 1b + dsb + mov pc, lr +ENDPROC(v7_flush_mem) /* * dma_map_area(start, size, dir) -- 1.7.0.4 -- regards Ramesh Gupta G -- 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 4/4] OMAP:IOMMU:flush L1 and L2 caches
From eb07a74132cd9305c1b82610dd1c2a9adfc72986 Mon Sep 17 00:00:00 2001
From: Ramesh Gupta G grgu...@ti.com
Date: Fri, 15 Jun 2012 16:46:46 +0530
Subject: [PATCH 4/4] OMAP:IOMMU:flush L1 and L2 caches
IOMMU need to make sure that data in L1 and L2 caches
is visible to the MMU hardware whenever the pagetables are
updated. The current code only takes care of L1 cache using
assembly.Added code to take care of both L1 and L2 caches
using a new L1 cache flush function and the outer cache function.
Signed-off-by: Ramesh Gupta G grgu...@ti.com
---
drivers/iommu/omap-iommu.c | 26 +-
1 files changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 6899dcd..6344fbc 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -469,22 +469,14 @@ EXPORT_SYMBOL_GPL(omap_foreach_iommu_device);
*/
static void flush_iopgd_range(u32 *first, u32 *last)
{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pgd
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
+ flush_mem(first, last);
+ outer_flush_range(virt_to_phys(first), virt_to_phys(last));
}
static void flush_iopte_range(u32 *first, u32 *last)
{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pte
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
+ flush_mem(first, last);
+ outer_flush_range(virt_to_phys(first), virt_to_phys(last));
}
static void iopte_free(u32 *iopte)
@@ -513,7 +505,7 @@ static u32 *iopte_alloc(struct omap_iommu *obj,
u32 *iopgd, u32 da)
return ERR_PTR(-ENOMEM);
*iopgd = virt_to_phys(iopte) | IOPGD_TABLE;
- flush_iopgd_range(iopgd, iopgd);
+ flush_iopgd_range(iopgd, iopgd + 1);
dev_vdbg(obj-dev, %s: a new pte:%p\n, __func__, iopte);
} else {
@@ -542,7 +534,7 @@ static int iopgd_alloc_section(struct omap_iommu
*obj, u32 da, u32 pa, u32 prot)
}
*iopgd = (pa IOSECTION_MASK) | prot | IOPGD_SECTION;
- flush_iopgd_range(iopgd, iopgd);
+ flush_iopgd_range(iopgd, iopgd + 1);
return 0;
}
@@ -559,7 +551,7 @@ static int iopgd_alloc_super(struct omap_iommu
*obj, u32 da, u32 pa, u32 prot)
for (i = 0; i 16; i++)
*(iopgd + i) = (pa IOSUPER_MASK) | prot | IOPGD_SUPER;
- flush_iopgd_range(iopgd, iopgd + 15);
+ flush_iopgd_range(iopgd, iopgd + 16);
return 0;
}
@@ -700,7 +692,7 @@ static size_t iopgtable_clear_entry_core(struct
omap_iommu *obj, u32 da)
}
bytes *= nent;
memset(iopte, 0, nent * sizeof(*iopte));
- flush_iopte_range(iopte, iopte + (nent - 1) * sizeof(*iopte));
+ flush_iopte_range(iopte, iopte + nent * sizeof(*iopte));
/*
* do table walk to check if this table is necessary or not
@@ -722,7 +714,7 @@ static size_t iopgtable_clear_entry_core(struct
omap_iommu *obj, u32 da)
bytes *= nent;
}
memset(iopgd, 0, nent * sizeof(*iopgd));
- flush_iopgd_range(iopgd, iopgd + (nent - 1) * sizeof(*iopgd));
+ flush_iopgd_range(iopgd, iopgd + nent * sizeof(*iopgd));
out:
return bytes;
}
--
1.7.0.4
--
regards
Ramesh Gupta G
--
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
[RESEND][PATCH v2 0/4] OMAP:IOMMU:Add L1 and L2 cache flush
From 639d8228c118f884e0d04d1338bf9561700e Mon Sep 17 00:00:00 2001 From: Ramesh Gupta G grgu...@ti.com Date: Fri, 15 Jun 2012 17:06:14 +0530 Subject: [PATCH v2 0/4] OMAP:IOMMU:Add L1 and L2 cache flush This patch series is second version to - add a new cache maintenance api to flush L1 cache. - flush both L1 and L2 caches from iommu whenever the pagetable memory is updated. Added the new api support for ARMv6 and ARMv7 based on the dma functions. The implementation of the new api is based on the approach[1] discussed some time back. [1]http://marc.info/?l=linux-kernelm=131316512713815w=2 These patches have been validated on Panda Board. Signed-off-by: Ramesh Gupta G grgu...@ti.com Ramesh Gupta G (4): ARM: new cache maintenance api for iommu mem flush ARM: add flush_mem api for ARMv6 ARM: add flush_mem api for ARMv7 OMAP:IOMMU: flush L1 and L2 caches arch/arm/include/asm/cacheflush.h | 17 + arch/arm/include/asm/glue-cache.h | 1 + arch/arm/mm/cache-v6.S | 28 arch/arm/mm/cache-v7.S | 21 + arch/arm/mm/proc-macros.S | 1 + drivers/iommu/omap-iommu.c | 26 +- 6 files changed, 77 insertions(+), 17 deletions(-) -- regards Ramesh Gupta G -- 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 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
Hi Omar,
On 6/16/2012 3:56 AM, Omar Ramirez Luna wrote:
Add mmu hwmod data for ipu and dsp.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 136
+++-
1 files changed, 134 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ebf9657..3879e9c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -30,6 +30,7 @@
#include plat/mmc.h
#include plat/dmtimer.h
#include plat/common.h
+#include plat/iommu.h
#include omap_hwmod_common_data.h
@@ -614,7 +615,6 @@ static struct omap_hwmod_irq_info omap44xx_dsp_irqs[] = {
static struct omap_hwmod_rst_info omap44xx_dsp_resets[] = {
{ .name = dsp, .rst_shift = 0 },
- { .name = mmu_cache, .rst_shift = 1 },
};
static struct omap_hwmod omap44xx_dsp_hwmod = {
@@ -1629,7 +1629,6 @@ static struct omap_hwmod_irq_info omap44xx_ipu_irqs[] =
{
static struct omap_hwmod_rst_info omap44xx_ipu_resets[] = {
{ .name = cpu0, .rst_shift = 0 },
{ .name = cpu1, .rst_shift = 1 },
- { .name = mmu_cache, .rst_shift = 2 },
};
static struct omap_hwmod omap44xx_ipu_hwmod = {
@@ -2436,6 +2435,137 @@ static struct omap_hwmod omap44xx_mmc5_hwmod = {
};
/*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address
translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig mmu_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_mmu_hwmod_class = {
+ .name = mmu,
+ .sysc = mmu_sysc,
+};
+
+/* ipu mmu */
+
+static struct omap_mmu_dev_attr ipu_mmu_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xf000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_ipu_mmu_hwmod;
+static struct omap_hwmod_irq_info omap44xx_ipu_mmu_irqs[] = {
+ { .irq = 100 + OMAP44XX_IRQ_GIC_START, },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap44xx_ipu_mmu_resets[] = {
+ { .name = mmu_cache, .rst_shift = 2 },
+};
+
+static struct omap_hwmod_addr_space omap44xx_ipu_mmu_addrs[] = {
+ {
+ .pa_start = 0x55082000,
+ .pa_end = 0x550820ff,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l3_main_2 - ipu_mmu */
+static struct omap_hwmod_ocp_if omap44xx_l3_main_2__ipu_mmu = {
+ .master = omap44xx_l3_main_2_hwmod,
+ .slave = omap44xx_ipu_mmu_hwmod,
+ .clk= l3_div_ck,
+ .addr = omap44xx_ipu_mmu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
+ .name = ipu_mmu,
+ .class = omap44xx_mmu_hwmod_class,
+ .clkdm_name = ducati_clkdm,
+ .mpu_irqs = omap44xx_ipu_mmu_irqs,
+ .rst_lines = omap44xx_ipu_mmu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
+ .main_clk = ipu_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .dev_attr = ipu_mmu_dev_attr,
+};
In fact, the MMU_IPU hwmod is now almost the same one than the previous IPU
one...
If we do that we should maybe just rename the IPU - MMU_IPU and DSP - MMU_DSP.
But by doing that we will assume that the MMU does represent the subsystem,
which is not necessarily super nice.
I guess that a much better representation will be to keep the subsystem (IPU)
to handle the PRCM part:
+ .main_clk = ipu_fck,
+ .prcm = {
+ .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
And then the MMU_IPU will handle the configuration registers part and the reset
+ irq.
But then, you will have to create a parent child dependency between your
devices to ensure that the IPU subsystem device will be enabled before trying
to access the MMU_IPU.
This is what the DSS is about to do to handle the same kind of power
dependency. The DSS device is the parent of all the
Re: [PATCHv3 6/7] ARM: OMAP2+: CM: increase the module disable timeout
Hello. On 18-06-2012 10:16, Paul Walmsley wrote: Increase the timeout for disabling an IP block to five milliseconds. This is to handle the usb_host_fs idle latency, which takes almost four milliseconds after a host controller reset. This is the second of two patches needed to resolve the following boot warning: omap_hwmod: usb_host_fs: _wait_target_disable failed Signed-off-by: Paul Walmsleyp...@pwsan.com Cc: Tero Kristot-kri...@ti.com [...] diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index 6b0aedc..a428305 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -30,6 +30,7 @@ #includeplat/mmc.h #includeplat/dmtimer.h #includeplat/common.h +#includeplat/usb.h How this hunk is related? WBR, Sergei -- 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: [PATCHv8 13/13] I2C: OMAP: simplify omap_i2c_ack_stat()
On Tue, Jun 19, 2012 at 02:50:23PM +0530, Shubhrajyoti Datta wrote: On Mon, Jun 18, 2012 at 9:00 PM, Wolfram Sang w.s...@pengutronix.de wrote: On Mon, Jun 18, 2012 at 08:00:28PM +0530, Shubhrajyoti D wrote: From: Felipe Balbi ba...@ti.com stat BIT(1) is the same as BIT(1), Not true. I'd guess you are missing some context in the patch description. See the explanation , hope I understood your concern correctly. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70277.html The code may be right, but as Russell pointed out, the patch description is very weak. I could read the mail now to understand, but I prefer to wait for a better patch description. Because I need to ensure other people reading the git history later will understand easily without having to search the web. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH] pinctrl: Add one-register-per-pin type device tree based pinctrl driver
Hi, Below is the pinctrl-single patch updated with hopefully all the Stephen's comments addressed. The binding still needs to be looked at, see relevant parts of the discussion below. * Tony Lindgren t...@atomide.com [120617 22:55]: * Stephen Warren swar...@wwwdotorg.org [120615 09:21]: On 06/15/2012 03:49 AM, Tony Lindgren wrote: (Arnd, Grant, Rob, CC'ing you mainly re: the very last set of comments in this email; can you take a look at Tony's patch and comment on the binding) Yes please take a look. One final comment: A little while before Linaro Connect in San Francisco, we were all having difficulty coming up with any kind of DT binding for pinctrl. I had suggested the possibility of creating a binding which just said write value X to register Y, write value P to register Q, This was rejected at connect, because a raw list of register writes didn't document anything or describe semantics - it was too much of a binary blob. This driver seems to be doing almost the exact same thing. In order to avoid that assertion, it'd need to truly have individual representations of which pins exist, which pingroups exist, which functions exist, and which functions can be selected onto which pins/pingroups. That would be a radically different binding. I wonder what's changed such that this kind of driver wasn't acceptable then, but is now? Well that's why I had two bindings earlier: The current binding for the bulk pins that's faster to parse, and a more verbose binding for drivers that allows naming the functions. In your previous comments at [1] you seemed to prefer this current binding based on the Why not only allow (1)? comment. Maybe you had something else in mind, care to clarify that a bit too? Well, first I thought about semantics vs. just banging a register list a tiny bit more, and remembered the previous discussion. But my comment at [1] wasn't so much about why not just have a raw register list, but more regarding why support two different representations within the same binding; it wasn't really clear to me from reading the original email what the difference between the two representations; why have two representations, why/when-to use one vs. the other, that the difference was about providing a semantic list of pins/pingroups/functions vs. providing a raw register list. I too would prefer more verbose .dts files. Unfortunately the parsing of several hundred board specific pins adds quite a bit of overhead. IIRC, the pushback on a raw bang these registers representation came from Grant and/or Arnd. It'd be a good idea if they (and indeed Rob) could comment on this binding proposal. If they're OK with this kind of pretty raw representation, I'm not going to object, but I have a feeling they might not like it? Yes let's see if anybody has better ideas. Regards, Tony [1] http://article.gmane.org/gmane.linux.kernel/1291838 From: Tony Lindgren t...@atomide.com Date: Wed, 6 Jun 2012 04:18:18 -0700 Subject: [PATCH] pinctrl: Add one-register-per-pin type device tree based pinctrl driver Add one-register-per-pin type device tree based pinctrl driver. Currently this driver only works on omap2+ series of processors, where there is either an 8 or 16-bit padconf register for each pin. Support for other similar pinmux controllers can be added. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt new file mode 100644 index 000..929254c --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt @@ -0,0 +1,106 @@ +One-register-per-pin type device tree based pinctrl driver + +Required properties: +- compatible : pinctrl-single + +- reg : offset and length of the register set for the mux registers + +- pinctrl-single,register-width : pinmux register access width in bits + +- pinctrl-single,function-mask : mask of allowed pinmux function bits + in the pinmux register + +- pinctrl-single,pinconf-mask : mask of allowed pinconf bits in the + pinmux register; this gets combined with pinconf mask but is a separate + mask to allow the option of setting pinconf separatately from the + function + +- pinctrl-single,function-off : function off mode for disabled state if + available and same for all registers; if not, use a value larger than + function-mask to ignore disabling of registers + +This driver assumes that there is only one register for each pin, +and uses the common pinctrl bindings as specified in the pinctrl-bindings.txt +document in this directory. + +The pinctrl register offsets and default values are specified as pairs +using pinctrl-single,pins. For example, setting a pin for a device +could be done with: + + pinctrl-single,pins = 0xdc 0x118; + +Where 0xdc is the offset from the pinctrl
[PATCH RESEND] OMAP: beagle: Set USB Host Port 1 to OMAP_USBHS_PORT_MODE_UNUSED
The beagleboard USB Host Port that is used is Port 2. The platform driver sets
MODE_PHY for port 1 causing pin muxing to override the pins on the expansion
connector P17 when using board_mux[]. Since USBHS Port 1 is not connected
remove the case for muxing the USB Port1 pins by default.
Patch is based off of 3.5-rc2 from ASoC for-next branch
Tested with BeagleBoard xM revC and checked the userguides for Beagle xM and
revC to be sure USB Port2 is what is used.
Signed-off-by: Brian Austin brian.aus...@cirrus.com
---
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 79c6909..75eb88a 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -435,7 +435,7 @@ static struct platform_device *omap3_beagle_devices[]
__initdata = {
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
- .port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
+ .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
--
1.7.10.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
Re: [RESEND/PATCHv5 1/2] drivers: input: keypad: Add device tree support
+cc linux-omap
On Fri, Jun 8, 2012 at 4:22 PM, Sourav Poddar sourav.pod...@ti.com wrote:
Update the Documentation with omap4 keypad device tree
binding information.
Add device tree support for omap4 keypad driver.
Tested on omap4430 sdp.
Cc: Andrew Morton a...@linux-foundation.org
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Felipe Balbi ba...@ti.com
Cc: Dmitry Torokhov d...@mail.ru
Cc: Randy Dunlap rdun...@xenotime.net
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
changes since v4:
- Developed it on top of dmitry's 'next' branch due to
dependency on generic matrix_keypad_build_keymap api
patches queued in that branch
- Adapted the driver to fill keymap in device tree
using matrix_keypad_build_keymap api defined in
drivers/input/matrix-keymap.c
.../devicetree/bindings/input/omap-keypad.txt | 31 ++
drivers/input/keyboard/omap4-keypad.c | 108
+++-
2 files changed, 111 insertions(+), 28 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/omap-keypad.txt
diff --git a/Documentation/devicetree/bindings/input/omap-keypad.txt
b/Documentation/devicetree/bindings/input/omap-keypad.txt
new file mode 100644
index 000..722425b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/omap-keypad.txt
@@ -0,0 +1,31 @@
+* TI's Keypad Controller device tree bindings
+
+TI's Keypad controller is used to interface a SoC with a matrix-type
+keypad device. The keypad controller supports multiple row and column lines.
+A key can be placed at each intersection of a unique row and a unique column.
+The keypad controller can sense a key-press and key-release and report the
+event using a interrupt to the cpu.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+ - ti,omap4-keypad: For controllers compatible with omap4 keypad
+ controller.
+
+Required Board Specific Properties, in addition to those specified by
+the shared matrix-keyboard bindings:
+- keypad,num-rows: Number of row lines connected to the keypad
+ controller.
+
+- keypad,num-columns: Number of column lines connected to the
+ keypad controller.
+
+Optional Properties specific to linux:
+- linux,keypad-no-autorepeat: do no enable autorepeat feature.
+
+Example:
+ keypad@4ae1c000{
+ compatible = ti,omap4-keypad;
+ keypad,num-rows = 2;
+ keypad,num-columns = 8;
+ linux,keypad-no-autorepeat;
+ };
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index aed5f69..d5a2d1a 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -27,6 +27,7 @@
#include linux/platform_device.h
#include linux/errno.h
#include linux/io.h
+#include linux/of.h
#include linux/input.h
#include linux/slab.h
#include linux/pm_runtime.h
@@ -75,6 +76,7 @@ enum {
struct omap4_keypad {
struct input_dev *input;
+ struct matrix_keymap_data *keymap_data;
void __iomem *base;
unsigned int irq;
@@ -84,6 +86,7 @@ struct omap4_keypad {
u32 reg_offset;
u32 irqreg_offset;
unsigned int row_shift;
+ bool no_autorepeat;
unsigned char key_state[8];
unsigned short keymap[];
};
@@ -208,25 +211,74 @@ static void omap4_keypad_close(struct input_dev *input)
pm_runtime_put_sync(input-dev.parent);
}
+static struct omap4_keypad *omap_keypad_parse_dt(struct device *dev,
+ uint32_t rows, uint32_t cols,
+ struct input_dev *input_dev)
+{
+ struct device_node *np = dev-of_node;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap4_keypad *keypad_data = platform_get_drvdata(pdev);
+ int error;
+
+ error = matrix_keypad_build_keymap(NULL, linux,keymap,
+ rows, cols, keypad_data-keymap, input_dev);
+ if (error) {
+ dev_err(pdev-dev, failed to build keymap\n);
+ input_free_device(input_dev);
+ }
+
+ if (of_get_property(np, linux,input-no-autorepeat, NULL))
+ keypad_data-no_autorepeat = true;
+
+ return keypad_data;
+}
+
static int __devinit omap4_keypad_probe(struct platform_device *pdev)
{
+ struct device *dev = pdev-dev;
+ struct device_node *np = dev-of_node;
const struct omap4_keypad_platform_data *pdata;
struct omap4_keypad *keypad_data;
struct input_dev *input_dev;
struct resource *res;
resource_size_t size;
- unsigned int row_shift, max_keys;
+ unsigned int row_shift = 0, max_keys = 0;
+ uint32_t num_rows = 0, num_cols = 0;
int rev;
int irq;
int error;
/* platform
Re: [PATCH] OMAP: beagle: Set USB Host Port 1 to OMAP_USBHS_PORT_MODE_UNUSED
You'll probably have to fix your sing/sign typo, but otherwise it looks good Yeah, I dont sing... resend on the way Acked-by: Russ Dill russ.d...@ti.com -- 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: [RESEND/PATCHv5 2/2] arm/dts: omap4-sdp: Add keypad data
+cc linux-omap
On Fri, Jun 8, 2012 at 4:23 PM, Sourav Poddar sourav.pod...@ti.com wrote:
Add keypad data node in omap4 device tree file.
Also fill the device tree binding parameters
with the required value in omap4-sdp dts file.
Tested on omap4430 sdp with dmitry's 'next' branch.
Cc: Andrew Morton a...@linux-foundation.org
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Felipe Balbi ba...@ti.com
Cc: Dmitry Torokhov d...@mail.ru
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 63
+++
arch/arm/boot/dts/omap4.dtsi | 5 +++
2 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 63c6b2b..0c9b3bf 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -17,4 +17,67 @@
device_type = memory;
reg = 0x8000 0x4000; /* 1 GB */
};
+
+ keypad@4ae1c000 {
+ keypad,num-rows = 8;
+ keypad,num-columns = 8;
+ linux,keymap = 0x0012
+ 0x00010013
+ 0x00020014
+ 0x00030066
+ 0x0004003f
+ 0x00060017
+ 0x0007002a
+ 0x0120
+ 0x01010021
+ 0x01020022
+ 0x01030054
+ 0x01040040
+ 0x01060025
+ 0x0107001c
+ 0x022d
+ 0x0201002e
+ 0x0202002f
+ 0x0203006b
+ 0x02040041
+ 0x02060034
+ 0x0207003a
+ 0x032c
+ 0x0301004e
+ 0x03020030
+ 0x0303003b
+ 0x03040042
+ 0x03060018
+ 0x03070039
+ 0x0411
+ 0x04010015
+ 0x04020016
+ 0x0403003c
+ 0x04040073
+ 0x04060026
+ 0x04070069
+ 0x051f
+ 0x05010023
+ 0x05020024
+ 0x0503003d
+ 0x05040043
+ 0x05050072
+ 0x05060032
+ 0x0507006a
+ 0x0610
+ 0x0601001e
+ 0x06020031
+ 0x0603005c
+ 0x0604000e
+ 0x06060019
+ 0x06070067
+ 0x0794
+ 0x07010095
+ 0x070200ca
+ 0x070300cb
+ 0x0704003e
+ 0x07060160
+ 0x0707006c ;
+ linux,input-no-autorepeat;
+ };
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 3d35559..e0f678a 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -156,4 +156,9 @@
ti,hwmods = i2c4;
};
};
+
+ keypad@4ae1c000 {
+ compatible = ti,omap4-keypad;
+ ti,hwmods = kbd;
+ };
};
--
1.7.1
N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¥{±¢f©{ayº ÊÚë,j¢f£¢·hàz¹ ®w¥¢¸
¢·¦j:+v¨wèjØm¶ÿ¾«êçzZ+ùÝ¢jú!¶i
Re: [RFC] ARM: OMAP4: hwmod data: add HWMOD_SWSUP_SIDLE to dss_hdmi to data
On 06/18/2012 04:22 PM, Paul Walmsley wrote: Hi On Sat, 16 Jun 2012, Ricardo Neri wrote: 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? Yep that's indeed a good summary of the situation. Since your patch fixes a functionality problem, maybe update the inline comment that you add to the data file to summarize what you wrote above: that this is simply a temporary workaround until the device driver has the ability to control the idle behavior. Also if you want this patch to go in during the 3.5-rc fixes cycle, please document further in the patch description what specific problem this fixes (e.g., choppy/broken audio, etc.) Thanks Paul! I will resend the patch with the updated comments. Ricardo - Paul -- 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 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
Hi Benoit,
On 19 June 2012 07:36, Cousson, Benoit b-cous...@ti.com wrote:
On 6/16/2012 3:56 AM, Omar Ramirez Luna wrote:
...
+static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
+ .name = ipu_mmu,
+ .class = omap44xx_mmu_hwmod_class,
+ .clkdm_name = ducati_clkdm,
+ .mpu_irqs = omap44xx_ipu_mmu_irqs,
+ .rst_lines = omap44xx_ipu_mmu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
+ .main_clk = ipu_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .dev_attr = ipu_mmu_dev_attr,
+};
In fact, the MMU_IPU hwmod is now almost the same one than the previous IPU
one...
If we do that we should maybe just rename the IPU - MMU_IPU and DSP -
MMU_DSP.
But by doing that we will assume that the MMU does represent the subsystem,
which is not necessarily super nice.
I guess that a much better representation will be to keep the subsystem (IPU)
to handle the PRCM part:
+ .main_clk = ipu_fck,
+ .prcm = {
+ .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
And then the MMU_IPU will handle the configuration registers part and the
reset + irq.
But then, you will have to create a parent child dependency between your
devices to ensure that the IPU subsystem device will be enabled before trying
to access the MMU_IPU.
This is what the DSS is about to do to handle the same kind of power
dependency. The DSS device is the parent of all the DSS IPs (DISPC, HDMI...)
and thus pm_runtime will ensure that the parent is enabled before trying to
enable the children.
In term of DT, just to illustrate the situation, it will be something like
that:
ipu {
compatible = simple-bus;
ti,hwmods = ipu;
ipu_mmu: mmu@4a066000 {
compatible = omap-mmu;
ti,hwmods = mmu_ipu;
reg...;
irqs...;
}
}
Is it something you can handle with your current framework?
I agree it would be nice only IPU managed the prcm, however we can't
do that right now because hwmod expects the IP block to be out of
reset to continue the _enable sequence. On IPU both reset lines are
asserted at that point and hence _are_any_hardreset_lines_asserted
check will bail out, and ipu resets can't be lifted without a
configured iommu otherwise it might execute random garbage.
So, for IPU and DSP the mmu must be deasserted and configured before
the processor reset line (which is more like a parking brake) is
deasserted, and the latter should be made before _enable is called so
it can fully execute the enable sequence.
Regards,
Omar
--
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/RFT 2/3] ARM: OMAP3: PM: call pre/post transition per powerdomain
On 04/24/2012 07:23 AM, Kevin Hilman wrote:
We only need to call the pre/post transtion methods when we know the
power state is changing. First, split up the pre/post transition
calls to be per-powerdomain, and then make them conditional on whether
the power domain is actually changing states.
Signed-off-by: Kevin Hilmankhil...@ti.com
This patch introduced a regression where the transition counts for NEON
were no longer accurate because I forgot to call the notifiers for NEON
when calling them for MPU.
The diff below will be folded into this patch before submitting for v3.6.
Kevin
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 8bd7daf..6226d10 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -306,8 +306,10 @@ void omap_sram_idle(void)
omap3_enable_io_chain();
}
- if (mpu_next_state PWRDM_POWER_ON)
+ if (mpu_next_state PWRDM_POWER_ON) {
pwrdm_pre_transition(mpu_pwrdm);
+ pwrdm_pre_transition(neon_pwrdm);
+ }
/* PER */
if (per_next_state PWRDM_POWER_ON) {
@@ -391,8 +393,10 @@ void omap_sram_idle(void)
omap3_disable_io_chain();
}
- if (mpu_next_state PWRDM_POWER_ON)
+ if (mpu_next_state PWRDM_POWER_ON) {
pwrdm_post_transition(mpu_pwrdm);
+ pwrdm_post_transition(neon_pwrdm);
+ }
}
static void omap3_pm_idle(void)
--
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 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
On 6/19/2012 6:39 PM, Omar Ramirez Luna wrote:
Hi Benoit,
On 19 June 2012 07:36, Cousson, Benoit b-cous...@ti.com wrote:
On 6/16/2012 3:56 AM, Omar Ramirez Luna wrote:
...
+static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
+ .name = ipu_mmu,
+ .class = omap44xx_mmu_hwmod_class,
+ .clkdm_name = ducati_clkdm,
+ .mpu_irqs = omap44xx_ipu_mmu_irqs,
+ .rst_lines = omap44xx_ipu_mmu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
+ .main_clk = ipu_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .dev_attr = ipu_mmu_dev_attr,
+};
In fact, the MMU_IPU hwmod is now almost the same one than the previous IPU
one...
If we do that we should maybe just rename the IPU - MMU_IPU and DSP - MMU_DSP.
But by doing that we will assume that the MMU does represent the subsystem,
which is not necessarily super nice.
I guess that a much better representation will be to keep the subsystem (IPU)
to handle the PRCM part:
+ .main_clk = ipu_fck,
+ .prcm = {
+ .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
And then the MMU_IPU will handle the configuration registers part and the reset
+ irq.
But then, you will have to create a parent child dependency between your
devices to ensure that the IPU subsystem device will be enabled before trying
to access the MMU_IPU.
This is what the DSS is about to do to handle the same kind of power
dependency. The DSS device is the parent of all the DSS IPs (DISPC, HDMI...)
and thus pm_runtime will ensure that the parent is enabled before trying to
enable the children.
In term of DT, just to illustrate the situation, it will be something like that:
ipu {
compatible = simple-bus;
ti,hwmods = ipu;
ipu_mmu: mmu@4a066000 {
compatible = omap-mmu;
ti,hwmods = mmu_ipu;
reg...;
irqs...;
}
}
Is it something you can handle with your current framework?
I agree it would be nice only IPU managed the prcm, however we can't
do that right now because hwmod expects the IP block to be out of
reset to continue the _enable sequence. On IPU both reset lines are
asserted at that point and hence _are_any_hardreset_lines_asserted
check will bail out, and ipu resets can't be lifted without a
configured iommu otherwise it might execute random garbage.
That's a good point, but like Paul said, the hard reset was removed
outside of the fmwk due to the lack of understanding about the real
usage / need for it.
If we do have a better understanding, we might add some more support in
the fmwk or at least improve it.
I'm now realizing that aborting the init if some reset lines are
asserted is not what we want to do for the IPU SS hwmod that will
contain the IPU (processor) reset control.
In fact the previous approach with a fake hwmod for the ipu_c0 processor
would have been avoided that issue.
If we do not want to go back with that, we should clearly revise the
_are_any_hardreset_lines_asserted approach and not prevent the init in
such case since it will prevent all the subsystem to start properly.
So, for IPU and DSP the mmu must be deasserted and configured before
the processor reset line (which is more like a parking brake) is
deasserted, and the latter should be made before _enable is called so
it can fully execute the enable sequence.
Yep, so we have to change the way it is handled today.
Paul,
If we consider that the reset lines are stored in the subsystem hwmod
(IPU, DSP or IVA), we cannot prevent the init phase because some line
are asserted. Otherwise we will never allow the MMU or processor to be
enabled later.
We might have to remove that check, maybe based on flag if we want to
keep that functionality or do an explicit reset control like we use to do.
What do you think?
Regards,
Benoit
--
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: MFD USB host: prevents CORE retention in idle
Munegowda, Keshava keshava_mgo...@ti.com writes: On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi Keshava, On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: hi kevin now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp. I am seeing the following error followed by a crash echo mem /sys/power/state [ 35.609252] PM: Syncing filesystems ... done. [ 35.614654] PM: Preparing system for mem sleep [ 35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 35.697692] PM: Entering mem sleep [ 35.722442] usb usb1: usb auto-resume [ 35.726409] ehci-omap ehci-omap.0: resume root hub [ 35.775451] hub 1-0:1.0: hub_resume [ 35.779846] hub 1-0:1.0: hub_suspend [ 35.784240] usb usb1: bus suspend, wakeup 0 [ 35.788665] ehci-omap ehci-omap.0: suspend root hub [ 35.805786] PM: suspend of devices complete after 99.304 msecs [ 35.816497] PM: late suspend of devices complete after 4.364 msecs [ 35.831573] PM: noirq suspend of devices complete after 8.331 msecs [ 35.838500] Disabling non-boot CPUs ... [ 36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [ 36.318481] Could not enter target state in pm_suspend [ 36.324859] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 36.333557] pgd = c628 [ 36.336639] [0018] *pgd=85c8f831, *pte=, *ppte= [ 36.343414] Internal error: Oops: 17 [#1] SMP ARM [ 36.348388] Modules linked in: [ 36.351623] CPU: 0 Tainted: G W (3.5.0-rc1 #1) [ 36.357574] PC is at _od_resume_noirq+0x14/0x58 [ 36.362365] LR is at dpm_run_callback+0x2c/0x74 You need the fix from https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb Hope this helps! Regards, Jean thanks Jean I used this patch; this solved the crash issue, but suspend/resume is still failing. Failing in what way? Did you debug any further? It may be failing because of problems with the USB host driver, which is what I'm needing you to debug. I'm convinced now that these USB host PM changes were not very well tested at all as they seem to be causing a variety of different problems on my boards: faults during boot, preventing CORE idle retention, hanging suspend/resume. Anyways... To get current l-o master to succesfully suspend/resume, you need 3 things: 1) the DSS fixes that Jean mentioned above (these are merged in v3.5-rc3, but not yet into l-o master) 2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n 3) for for 32k timer which is also preventing CORE retention http://marc.info/?l=linux-omapm=13453229888w=2 With that setup on top of current l-o master, suspend/resume is working for me on several OMAP3/4 platforms. Kevin -- 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] omap2+: add drm device
Tony,
Please queue this patch at your earliest convenience.
We had some discussion on the splitting out of the DMM/Tiler driver
from the omapdrm driver. There might be some interest in leveraging
the Tiler for omapfb. However, we agreed this can be deferred until
some other device (omapfb or otherwise) needs to use the Tiler.
Regards,
Andy Gross
On Mon, Jun 11, 2012 at 10:51 AM, Rob Clark rob.cl...@linaro.org wrote:
On Wed, May 23, 2012 at 3:08 PM, Andy Gross andy.gr...@ti.com wrote:
Register OMAP DRM/KMS platform device. DMM is split into a
separate device using hwmod.
Signed-off-by: Andy Gross andy.gr...@ti.com
Signed-off-by: Rob Clark rob.cl...@linaro.org
---
arch/arm/mach-omap2/Makefile | 4 ++
arch/arm/mach-omap2/drm.c | 61
drivers/staging/omapdrm/omap_drv.h | 2 +-
drivers/staging/omapdrm/omap_priv.h | 55
include/linux/platform_data/omap_drm.h | 52 +++
5 files changed, 118 insertions(+), 56 deletions(-)
create mode 100644 arch/arm/mach-omap2/drm.c
delete mode 100644 drivers/staging/omapdrm/omap_priv.h
create mode 100644 include/linux/platform_data/omap_drm.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 49f92bc..c301ab7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -187,6 +187,10 @@ ifneq ($(CONFIG_TIDSPBRIDGE),)
obj-y += dsp.o
endif
+ifneq ($(CONFIG_DRM_OMAP),)
+obj-y += drm.o
+endif
+
# Specific board support
obj-$(CONFIG_MACH_OMAP_GENERIC) += board-generic.o
obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
new file mode 100644
index 000..72e0f01b
--- /dev/null
+++ b/arch/arm/mach-omap2/drm.c
@@ -0,0 +1,61 @@
+/*
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark rob.cl...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as
published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/dma-mapping.h
+
+#include plat/omap_device.h
+#include plat/omap_hwmod.h
+
+#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
+
+static struct platform_device omap_drm_device = {
+ .dev = {
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+ .name = omapdrm,
+ .id = 0,
+};
+
+static int __init omap_init_drm(void)
+{
+ struct omap_hwmod *oh = NULL;
+ struct platform_device *pdev;
+
+ /* lookup and populate the DMM information, if present - OMAP4+ */
+ oh = omap_hwmod_lookup(dmm);
+
+ if (oh) {
+ pdev = omap_device_build(oh-name, -1, oh, NULL, 0, NULL, 0,
+ false);
+ WARN(IS_ERR(pdev), Could not build omap_device for %s\n,
+ oh-name);
+ }
+
+ return platform_device_register(omap_drm_device);
+
+}
+
+arch_initcall(omap_init_drm);
+
+#endif
diff --git a/drivers/staging/omapdrm/omap_drv.h
b/drivers/staging/omapdrm/omap_drv.h
index b7e0f07..96296e0 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -25,8 +25,8 @@
#include linux/types.h
#include drm/drmP.h
#include drm/drm_crtc_helper.h
+#include linux/platform_data/omap_drm.h
#include omap_drm.h
-#include omap_priv.h
#define DBG(fmt, ...) DRM_DEBUG(fmt\n, ##__VA_ARGS__)
#define VERB(fmt, ...) if (0) DRM_DEBUG(fmt, ##__VA_ARGS__) /* verbose
debug */
diff --git a/drivers/staging/omapdrm/omap_priv.h
b/drivers/staging/omapdrm/omap_priv.h
deleted file mode 100644
index ef64414..000
--- a/drivers/staging/omapdrm/omap_priv.h
+++ /dev/null
@@ -1,55 +0,0 @@
-/*
- * include/drm/omap_priv.h
- *
- * Copyright (C) 2011 Texas Instruments
- * Author: Rob Clark r...@ti.com
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as
published by
Re: [PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level
于 2012年06月14日 14:59, Zumeng Chen 写道: 于 2012年06月14日 14:31, Hiremath, Vaibhav 写道: On Thu, Jun 14, 2012 at 10:16:55, Zumeng Chen wrote: 于 2012年06月13日 20:18, Hiremath, Vaibhav 写道: On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote: From: Zumeng 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 Zumeng, With my sign-off you are changing the original code, that too without my sign-off and ack. I wouldn't mind you to submit patches from my tree, but the expectation is if you are changing the original code, it should be under your sign-off. Thanks, good to learn. I'll remove in next time. Coming to the patch, #ifdef in driver is not recommended, and this 10msec delay is specific to OMAP GPIO and driver should not be aware of this, that's where you will find the original patch handling it in board file. According to the git blame of the board-omap3evm.c I think 96974a24 did a good thing to all the related codes for omap3 boards. So I think we can call board and driver as BSP level :-) If #ifdef in driver can save many codes, I guess it's deserved. No, not really. In the same commit, the debounce time is already handled as an argument to the function omap_ads7846_init(), and that’s the way it should be. That means you'd like to implement the same get_pendown_state for every omap3 board? Currently, board_pdata is NULL. And actually, the reason why I agree 96974a24 is that get_pendown_state for all omap3 boards is the common chip level gpio operations. so I think we should set debounce for them in one common point. But since Igor and you don't like them, I have created and tested the attachment patch, and I'd like Mike to check if convenience too But obviously there are more codes than mine before :-) Hi Mike, I'll send V3 with the change on the attachment to you for 5/5, if you happen to get it, it's high appreciated to review it. Regards, Zumeng Regards, Zumeng So no need for #ifdefs in driver... Thanks, Vaibhav -- 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
