Re: [PATCH] ARM:iommu support for OMAP4
On Fri, Apr 16, 2010 at 7:17 PM, Kanigeri, Hari h-kanige...@ti.com wrote: From 708914e1a82a608d423b050cb31b4deb46eb8411 Mon Sep 17 00:00:00 2001 From: Hari Kanigeri h-kanige...@ti.com Date: Mon, 8 Mar 2010 17:55:21 -0600 Subject: [PATCH] ARM:iommu support for OMAP4 This patch provides the iommu support for OMAP4 co-processors. Signed-off-by: Hari Kanigeri h-kanige...@ti.com This looks like based on an old version of omap3-iommu.c; maybe you should update it. -- Felipe Contreras -- 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 2/3] OMAP3630: PM: implement Foward Body-Bias for OPP1G
Hello Mike,
On Fri, Apr 16, 2010 at 11:33:22PM +0200, ext Mike Turquette wrote:
Introduces voltscale_adaptive_body_bias function to voltage.c.
voltscale_adaptive_body_bias is called by omap_voltage_scale after a
voltage transition has occured. Currently voltscale_adaptive_body_bias
only implements Forward Body-Bias (FBB) for OMAP3630 when MPU runs at
1GHz or higher. In the future Reverse Body-Bias might be included.
FBB is an Adaptive Body-Bias technique to boost performance for weak
process devices at high OPPs. This results in voltage boost on the VDD1
PMOS back gates when running at maximum OPP. Current recommendations
are to enable FBB on all 3630 regardless of silicon characteristics and
EFUSE values.
ABB applies to all OMAP silicon based on 45nm process, which includes
OMAP4. OMAP4 recommendations for ABB are not complete and will be added
to voltscale_adaptive_body_bias in the future.
Nice !
Signed-off-by: Mike Turquette mturque...@ti.com
---
arch/arm/mach-omap2/voltage.c | 129
-
1 files changed, 127 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index c2c8192..98d8bb3 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -37,6 +37,11 @@
#define VP_IDLE_TIMEOUT 200
#define VP_TRANXDONE_TIMEOUT 300
+#define ABB_MAX_SETTLING_TIME30
+#define ABB_FAST_OPP 1
+#define ABB_NOMINAL_OPP 2
+#define ABB_SLOW_OPP 3
+
/**
* OMAP3 Voltage controller SR parameters. TODO: Pass this info as part of
* board data or PMIC data
@@ -635,6 +640,118 @@ static int vp_forceupdate_scale_voltage(u32 vdd,
unsigned long target_volt,
}
/**
+ * voltscale_adaptive_body_bias - controls ABB ldo during voltage scaling
+ * @target_volt: target voltage determines if ABB ldo is active or bypassed
+ *
+ * Adaptive Body-Bias is a technique in all OMAP silicon that uses the 45nm
+ * process. ABB can boost voltage in high OPPs for silicon with weak
+ * characteristics (forward Body-Bias) as well as lower voltage in low OPPs
+ * for silicon with strong characteristics (Reverse Body-Bias).
+ *
+ * Only Foward Body-Bias for operating at high OPPs is implemented below, per
+ * recommendations from silicon team.
+ * Reverse Body-Bias for saving power in active cases and sleep cases is not
+ * yet implemented.
+ * OMAP4 hardward also supports ABB ldo, but no recommendations have been
made
+ * to implement it yet.
+ */
+int voltscale_adaptive_body_bias(unsigned long target_volt)
+{
+ u32 sr2en_enabled;
+ int timeout;
+ int sr2_wtcnt_value;
+
+ /* calculate SR2_WTCNT_VALUE settling time */
+ sr2_wtcnt_value = (ABB_MAX_SETTLING_TIME *
+ (clk_get_rate(sys_ck) / 100) / 8);
+
+ /* has SR2EN been enabled previously? */
+ sr2en_enabled = (prm_read_mod_reg(OMAP3430_GR_MOD,
+ OMAP3_PRM_LDO_ABB_CTRL_OFFSET)
+ OMAP3630_SR2EN);
+
+ /* select fast, nominal or slow OPP for ABB ldo */
+ /* FIXME: include OMAP4 once recommendations are complete */
+ if (cpu_is_omap3630() (target_volt = 135)) {
You are creating two steps to decide if you apply or not FBB.
Here and also bellow (omap voltage scale). Would it make sense to bind it
per opp? I mean just a flag on opp dat then you apply or not based on that flag.
Same for RBB.
+ /* program for fast opp - enable FBB */
+ prm_rmw_mod_reg_bits(OMAP3630_OPP_SEL_MASK,
+ (ABB_FAST_OPP OMAP3630_OPP_SEL_SHIFT),
+ OMAP3430_GR_MOD,
+ OMAP3_PRM_LDO_ABB_SETUP_OFFSET);
+
+ /* enable the ABB ldo if not done already */
+ if (!sr2en_enabled)
+ prm_set_mod_reg_bits(OMAP3630_SR2EN,
+ OMAP3430_GR_MOD,
+ OMAP3_PRM_LDO_ABB_CTRL_OFFSET);
+ } else if (sr2en_enabled) {
+ /* program for nominal opp - bypass ABB ldo */
+ prm_rmw_mod_reg_bits(OMAP3630_OPP_SEL_MASK,
+ (ABB_NOMINAL_OPP OMAP3630_OPP_SEL_SHIFT),
+ OMAP3430_GR_MOD,
+ OMAP3_PRM_LDO_ABB_SETUP_OFFSET);
+ } else {
+ /* nothing to do here yet... might enable RBB here someday */
+ return 0;
+ }
+
+ /* set ACTIVE_FBB_SEL for all 45nm silicon */
+ prm_set_mod_reg_bits(OMAP3630_ACTIVE_FBB_SEL,
+ OMAP3430_GR_MOD,
+ OMAP3_PRM_LDO_ABB_CTRL_OFFSET);
+
+ /* program settling time of 30us for ABB ldo transition */
+ prm_rmw_mod_reg_bits(OMAP3630_SR2_WTCNT_VALUE_MASK,
+ (sr2_wtcnt_value OMAP3630_SR2_WTCNT_VALUE_SHIFT),
+
32-bit transfers broken in OMAP SPI driver?
Ran across drivers/spi/omap_spi_100k.c and its handling of 16-bit transfers seems buggy to me. Firstly, addresses do not get incremented in omap1_spi100k_txrx_pio() (word_len = 32) case, a fix for which seems to be obvious, secondly, spi100k_write_data() and spi100k_read_data() only write / read 16-bit data blocks, for which I'm not adventurous enough to propose a patch without even touching the hardware;) Am I right? Maybe just disable 16-bit transfers altogether, since they are broken, and thus, obviously, unused. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.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
Re: [PATCH] mmc: fix race condition between dma and omap_hsmmc callback
Venkatraman S wrote: On Tue, Apr 13, 2010 at 3:17 PM, Adrian Hunter adrian.hun...@nokia.com wrote: Venkatraman S wrote: This patch addresses the possible race condition between the dma callback and hsmmc callback. Can you explain the problem in more detail? If the final DMA interrupt comes before TC then all should be well. Actually it isn't, with descriptor loading. If the DMA callback arrives too early, the MMC TC is missed sometimes. The last transfer in the log below is actually stalled waiting for TC. This happens more often when the transfer is large ( 300 blocks) You seem to be saying that, in the case of descriptor loading, the DMA callback does not indicate that the DMA is complete. Isn't that a problem with descriptor loading? If it comes after, then we need to be sure that the DMA has finished - particularly in the read case. Neither the existing code nor this patch seems to address that issue. With this patch the assumption is that MMC TC correctly signals the end of read / write as requested. I don't know if there are any specific reasons to believe otherwise. It would be nice if there were a way to check that the DMA is complete. i.e. if TC is received but DMA is not complete then set an error by calling omap_hsmmc_dma_cleanup() instead of omap_hsmmc_xfer_done() Also, how can we be sure the final DMA interrupt doesn't race with the start of the next request? Till the time omap_hsmmc_xfer_done is called, the next request is not expected to arrive. The requests are implicitly serialised by host-sem, which is released only on the DMA callback. The code releases the semaphore only after freeing the DMA channel. - mmc0: starting CMD17 arg 0066 flags 00b5 mmc0: blksz 512 blocks 1 flags 0200 tsac 100 ms nsac 0 mmci-omap-hs mmci-omap-hs.0: mmc0: CMD17, argument 0x0066 mmci-omap-hs mmci-omap-hs.0: IRQ Status is 1 mmci-omap-hs mmci-omap-hs.0: final dma callback mmci-omap-hs mmci-omap-hs.0: IRQ Status is 2 mmc0: req done (CMD17): 0: 0900 mmc0: 512 bytes transferred: 0 mmc0: starting CMD18 arg 25df flags 00b5 mmc0: blksz 512 blocks 32 flags 0200 tsac 100 ms nsac 0 mmc0: CMD12 arg flags 049d mmci-omap-hs mmci-omap-hs.0: mmc0: CMD18, argument 0x25df mmci-omap-hs mmci-omap-hs.0: IRQ Status is 1 mmci-omap-hs mmci-omap-hs.0: IRQ Status is 2 mmci-omap-hs mmci-omap-hs.0: mmc0: CMD12, argument 0x mmci-omap-hs mmci-omap-hs.0: final dma callback mmci-omap-hs mmci-omap-hs.0: IRQ Status is 3 mmc0: req done (CMD18): 0: 0900 mmc0: 16384 bytes transferred: 0 mmc0: (CMD12): 0: 0b00 mmc0: starting CMD18 arg 25ff flags 00b5 mmc0: blksz 512 blocks 192 flags 0200 tsac 100 ms nsac 0 mmc0: CMD12 arg flags 049d mmci-omap-hs mmci-omap-hs.0: new sglist 9fd0 len =23 mmci-omap-hs mmci-omap-hs.0: mmc0: CMD18, argument 0x25ff mmci-omap-hs mmci-omap-hs.0: IRQ Status is 1 mmci-omap-hs mmci-omap-hs.0: final dma callback mmci-omap-hs mmci-omap-hs.0: IRQ Status is 2 mmci-omap-hs mmci-omap-hs.0: mmc0: CMD12, argument 0x mmci-omap-hs mmci-omap-hs.0: IRQ Status is 3 mmc0: req done (CMD18): 0: 0900 mmc0: 98304 bytes transferred: 0 mmc0: (CMD12): 0: 0b00 mmc0: starting CMD18 arg 26bf flags 00b5 mmc0: blksz 512 blocks 512 flags 0200 tsac 100 ms nsac 0 mmc0: CMD12 arg flags 049d mmci-omap-hs mmci-omap-hs.0: new sglist 9fd0 len =26 mmci-omap-hs mmci-omap-hs.0: mmc0: CMD18, argument 0x26bf mmci-omap-hs mmci-omap-hs.0: IRQ Status is 1 mmci-omap-hs mmci-omap-hs.0: final dma callback -- 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] ARM: OMAP add TLB preservation support to IOMMU
Hi Hari,
From: ext Kanigeri, Hari h-kanige...@ti.com
Subject: [PATCH] ARM: OMAP add TLB preservation support to IOMMU
Date: Fri, 16 Apr 2010 18:18:59 +0200
From bcdd232666a163d2661d704f9c21d055bacfd178 Mon Sep 17 00:00:00 2001
From: Hari Kanigeri h-kanige...@ti.com
Date: Mon, 8 Mar 2010 18:00:36 -0600
Subject: [PATCH] ARM: OMAP add TLB preservation support to IOMMU
This patch adds TLB preservation support to IOMMU module
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/mach-omap2/iommu2.c |7 +--
arch/arm/plat-omap/iommu.c | 16 +---
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 6f4b7cc..2735bd7 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -146,6 +146,8 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32
*ra)
printk(\n);
iommu_write_reg(obj, stat, MMU_IRQSTATUS);
+ /* Disable MMU to stop continuous generation of MMU faults */
+ omap2_iommu_disable(obj);
The above comment may look a bit redundant.
return stat;
}
@@ -183,7 +185,7 @@ static struct cr_regs *omap2_alloc_cr(struct iommu *obj,
struct iotlb_entry *e)
if (!cr)
return ERR_PTR(-ENOMEM);
- cr-cam = (e-da MMU_CAM_VATAG_MASK) | e-prsvd | e-pgsz;
+ cr-cam = (e-da MMU_CAM_VATAG_MASK) | e-prsvd | e-pgsz | e-valid;
cr-ram = e-pa | e-endian | e-elsz | e-mixed;
Good finding. This can be a separate patch.
return cr;
@@ -211,7 +213,8 @@ static ssize_t omap2_dump_cr(struct iommu *obj, struct
cr_regs *cr, char *buf)
char *p = buf;
/* FIXME: Need more detail analysis of cam/ram */
- p += sprintf(p, %08x %08x\n, cr-cam, cr-ram);
+ p += sprintf(p, %08x %08x %01x\n, cr-cam, cr-ram,
+ (cr-cam MMU_CAM_P) ? 1 : 0);
This is ok for now.
As described in FIXME comment, this cam/ram whole anaylysis can be
improved/implemented in order to display all items/bits in the end.
return p - buf;
}
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 5186728..64d676e 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -171,15 +171,12 @@ static void iotlb_lock_get(struct iommu *obj, struct
iotlb_lock *l)
l-base = MMU_LOCK_BASE(val);
l-vict = MMU_LOCK_VICT(val);
- BUG_ON(l-base != 0); /* Currently no preservation is used */
}
static void iotlb_lock_set(struct iommu *obj, struct iotlb_lock *l)
{
u32 val;
- BUG_ON(l-base != 0); /* Currently no preservation is used */
-
val = (l-base MMU_LOCK_BASE_SHIFT);
val |= (l-vict MMU_LOCK_VICT_SHIFT);
@@ -241,7 +238,7 @@ int load_iotlb_entry(struct iommu *obj, struct
iotlb_entry *e)
break;
}
- if (i == obj-nr_tlb_entries) {
+ if (i == obj-nr_tlb_entries || (l.base == obj-nr_tlb_entries)) {
The above should be dealt separately, since no vacant entry is normal,
but no room to be replaced because of preservation should be warned,
at least.
dev_dbg(obj-dev, %s: full: no entry\n, __func__);
err = -EBUSY;
goto out;
@@ -252,13 +249,18 @@ int load_iotlb_entry(struct iommu *obj, struct
iotlb_entry *e)
clk_disable(obj-clk);
return PTR_ERR(cr);
}
-
iotlb_load_cr(obj, cr);
kfree(cr);
+ /* Increment base number if preservation is set */
+ if (e-prsvd)
+ l.base++;
redundant comment? It tells what the code does.
/* increment victim for next tlb load */
Although the above is my comment, this looks redundant now too.
- if (++l.vict == obj-nr_tlb_entries)
- l.vict = 0;
+ if (++l.vict == obj-nr_tlb_entries) {
+ l.vict = l.base;
+ goto out;
+ }
Does the above work?
+
iotlb_lock_set(obj, l);
out:
clk_disable(obj-clk);
--
1.7.0
Thank you,
Best regards,
Hari
--
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 0/9] Some am3517 related patches [V2]
Changes from V2: 1, Removed the controversial patches. I will submit them later. Some am3517 related patches. The detaild changelog is below: Stanley.Miao (9): omap: fix the compile error if CONFIG_MTD_NAND_OMAP2 is not enabled omap: remove one of the define of INT_34XX_BENCH_MPU_EMUL AM3517: rename the i2c boardinfo to make it more readable AM3517: Add platform init code for regulator driver AM3517: Add audio codec platform data AM3517: initialize i2c subsystem after mux subsystem OMAP: fix a gpmc nand problem omap: init the gpio pinmux for mmc omap hsmmc: fix the hsmmc driver for am3517. arch/arm/mach-omap2/board-am3517evm.c | 149 +--- arch/arm/mach-omap2/devices.c |7 ++ arch/arm/mach-omap2/gpmc-nand.c|3 + arch/arm/mach-omap2/hsmmc.c| 32 +-- arch/arm/plat-omap/include/plat/irqs.h |2 - arch/arm/plat-omap/include/plat/nand.h |7 ++ 6 files changed, 178 insertions(+), 22 deletions(-) -- 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 2/9] omap: remove one of the define of INT_34XX_BENCH_MPU_EMUL
INT_34XX_BENCH_MPU_EMUL was defined twice, another is at Line 312. Signed-off-by: Stanley.Miao stanley.m...@windriver.com --- arch/arm/plat-omap/include/plat/irqs.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h index b65088a..4017019 100644 --- a/arch/arm/plat-omap/include/plat/irqs.h +++ b/arch/arm/plat-omap/include/plat/irqs.h @@ -345,8 +345,6 @@ #define INT_34XX_MMC3_IRQ 94 #define INT_34XX_GPT12_IRQ 95 -#defineINT_34XX_BENCH_MPU_EMUL 3 - #define INT_35XX_HECC0_IRQ 24 #define INT_35XX_HECC1_IRQ 28 #define INT_35XX_EMAC_C0_RXTHRESH_IRQ 67 -- 1.5.4.3 -- 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 6/9] AM3517: initialize i2c subsystem after mux subsystem
The initialize of i2c subsystem will set pinmux, so it should be done
after the initialize of mux subsystem initialization.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
arch/arm/mach-omap2/board-am3517evm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index f24e367..f8f99b8 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -419,9 +419,9 @@ static struct omap_board_mux board_mux[] __initdata = {
static void __init am3517_evm_init(void)
{
- am3517_evm_i2c_init();
-
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+
+ am3517_evm_i2c_init();
platform_add_devices(am3517_evm_devices,
ARRAY_SIZE(am3517_evm_devices));
--
1.5.4.3
--
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 9/9] omap hsmmc: fix the hsmmc driver for am3517.
AM3517 don't have the register OMAP343X_CONTROL_PBIAS_LITE and the regulators
like vmmc, so we set a noop set_power function for it.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
arch/arm/mach-omap2/hsmmc.c | 32
1 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 9ad2295..5f46797 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -139,6 +139,12 @@ static void hsmmc23_before_set_reg(struct device *dev, int
slot,
}
}
+static int am3517_mmc_set_power(struct device *dev, int slot, int power_on,
+ int vdd)
+{
+ return 0;
+}
+
static struct omap_mmc_platform_data *hsmmc_data[OMAP34XX_NR_MMC] __initdata;
void __init omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
@@ -150,7 +156,7 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
if (cpu_is_omap2430()) {
control_pbias_offset = OMAP243X_CONTROL_PBIAS_LITE;
control_devconf1_offset = OMAP243X_CONTROL_DEVCONF1;
- } else {
+ } else if (!cpu_is_omap3517() !cpu_is_omap3505()) {
control_pbias_offset = OMAP343X_CONTROL_PBIAS_LITE;
control_devconf1_offset = OMAP343X_CONTROL_DEVCONF1;
}
@@ -216,12 +222,25 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
*/
mmc-slots[0].ocr_mask = c-ocr_mask;
+ if (!cpu_is_omap3517() !cpu_is_omap3505()) {
+ switch (c-mmc) {
+ case 1:
+ /* on-chip level shifting via PBIAS0/PBIAS1 */
+ mmc-slots[0].before_set_reg =
hsmmc1_before_set_reg;
+ mmc-slots[0].after_set_reg =
hsmmc1_after_set_reg;
+ break;
+ case 2:
+ case 3:
+ /* off-chip level shifting, or none */
+ mmc-slots[0].before_set_reg =
hsmmc23_before_set_reg;
+ mmc-slots[0].after_set_reg = NULL;
+ break;
+ }
+ } else /* cpu_is_omap3517() || cpu_is_omap3505() */
+ mmc-slots[0].set_power = am3517_mmc_set_power;
+
switch (c-mmc) {
case 1:
- /* on-chip level shifting via PBIAS0/PBIAS1 */
- mmc-slots[0].before_set_reg = hsmmc1_before_set_reg;
- mmc-slots[0].after_set_reg = hsmmc1_after_set_reg;
-
/* Omap3630 HSMMC1 supports only 4-bit */
if (cpu_is_omap3630() c-wires 4) {
c-wires = 4;
@@ -235,9 +254,6 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
c-wires = 4;
/* FALLTHROUGH */
case 3:
- /* off-chip level shifting, or none */
- mmc-slots[0].before_set_reg = hsmmc23_before_set_reg;
- mmc-slots[0].after_set_reg = NULL;
break;
default:
pr_err(MMC%d configuration not supported!\n, c-mmc);
--
1.5.4.3
--
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 v5 3/5] omap3: pm: Generic TRITON power scripts for OMAP3 based boards
This pacth will create the generic TRITON power scripts which can be used
by different OMAP3 boards with the same power companion chip (TWL4030 series).
Added the api(twl4030_get_scripts/twl4030_get_vc_timings) to update
the sleep/wakeup/warm_rest sequence voltsetup_time in the board file.
Signed-off-by: Lesly A M x0080...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/mach-omap2/twl4030.c | 154 +
arch/arm/mach-omap2/twl4030.h | 15
arch/arm/mach-omap2/voltage.c |5 +-
3 files changed, 171 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-omap2/twl4030.c
create mode 100644 arch/arm/mach-omap2/twl4030.h
diff --git a/arch/arm/mach-omap2/twl4030.c b/arch/arm/mach-omap2/twl4030.c
new file mode 100644
index 000..6647156
--- /dev/null
+++ b/arch/arm/mach-omap2/twl4030.c
@@ -0,0 +1,154 @@
+/*
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Lesly A M x0080...@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 the Free Software Foundation.
+ */
+
+#ifdef CONFIG_TWL4030_POWER
+
+#include twl4030.h
+
+static struct prm_setup_vc twl4030_voltsetup_time = {
+ /* VOLT SETUPTIME for RET */
+ .ret = {
+ .voltsetup1_vdd1 = 0x005B,
+ .voltsetup1_vdd2 = 0x0055,
+ .voltsetup2 = 0x0,
+ .voltoffset = 0x0,
+ },
+ /* VOLT SETUPTIME for OFF */
+ .off = {
+ .voltsetup1_vdd1 = 0x00B3,
+ .voltsetup1_vdd2 = 0x00A0,
+ .voltsetup2 = 0x118,
+ .voltoffset = 0x32,
+ },
+};
+
+/*
+ * Sequence to control the TRITON Power resources,
+ * when the system goes into sleep.
+ * Executed upon P1_P2/P3 transition for sleep.
+ */
+static struct twl4030_ins __initdata sleep_on_seq[] = {
+ /* Broadcast message to put res to sleep */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
+ RES_STATE_SLEEP), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_SLEEP), 2},
+};
+
+static struct twl4030_script sleep_on_script __initdata = {
+ .script = sleep_on_seq,
+ .size = ARRAY_SIZE(sleep_on_seq),
+ .flags = TWL4030_SLEEP_SCRIPT,
+};
+
+/*
+ * Sequence to control the TRITON Power resources,
+ * when the system wakeup from sleep.
+ * Executed upon P1_P2 transition for wakeup.
+ */
+static struct twl4030_ins wakeup_p12_seq[] __initdata = {
+ /* Broadcast message to put res to active */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
+ RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wakeup_p12_script __initdata = {
+ .script = wakeup_p12_seq,
+ .size = ARRAY_SIZE(wakeup_p12_seq),
+ .flags = TWL4030_WAKEUP12_SCRIPT,
+};
+
+/*
+ * Sequence to control the TRITON Power resources,
+ * when the system wakeup from sleep.
+ * Executed upon P3 transition for wakeup.
+ */
+static struct twl4030_ins wakeup_p3_seq[] __initdata = {
+ /* Broadcast message to put res to active */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wakeup_p3_script __initdata = {
+ .script = wakeup_p3_seq,
+ .size = ARRAY_SIZE(wakeup_p3_seq),
+ .flags = TWL4030_WAKEUP3_SCRIPT,
+};
+
+/*
+ * Sequence to reset the TRITON Power resources,
+ * when the system gets warm reset.
+ * Executed upon warm reset signal.
+ */
+static struct twl4030_ins wrst_seq[] __initdata = {
+/*
+ * Reset twl4030.
+ * Reset Main_Ref.
+ * Reset All type2_group2.
+ * Reset VUSB_3v1.
+ * Reset All type2_group1.
+ * Reset RC.
+ * Reenable twl4030.
+ */
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_OFF), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_Main_Ref, RES_STATE_WRST), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_WRST), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_VUSB_3V1, RES_STATE_WRST), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
+ RES_STATE_WRST), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_RC, RES_TYPE_ALL, RES_TYPE2_R0,
+ RES_STATE_WRST), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wrst_script __initdata = {
+ .script = wrst_seq,
+ .size = ARRAY_SIZE(wrst_seq),
+ .flags =
[PATCH v5 4/5] omap3: pm: Use generic TRITON power scripts for 3430SDP board
This patch will removed the sleep/wakeup/warm_rest sequence from the
3430SDP board file and use the generic script.
Modified the resource config structure in the board file for using
generic script. Updating the sleep/wakeup/warm_rest sequence voltsetup_time
in the board file from generic script file.
Signed-off-by: Lesly A M x0080...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-3430sdp.c | 108 --
include/linux/i2c/twl.h |4 +
3 files changed, 32 insertions(+), 83 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 184badd..f60dca3 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -127,7 +127,8 @@ obj-$(CONFIG_MACH_OMAP3_PANDORA)+= board-omap3pandora.o
\
hsmmc.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \
hsmmc.o \
- board-sdp-flash.o
+ board-sdp-flash.o \
+ twl4030.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
board-rx51-sdram.o \
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 9cc8569..5c3f74d 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -49,6 +49,7 @@
#include sdram-qimonda-hyb18m512160af-6.h
#include hsmmc.h
#include voltage.h
+#include twl4030.h
#include omap3-opp.h
#include smartreflex-class3.h
@@ -425,93 +426,35 @@ static struct twl4030_madc_platform_data
sdp3430_madc_data = {
.irq_line = 1,
};
-
-static struct twl4030_ins __initdata sleep_on_seq[] = {
- /* Turn off HFCLKOUT */
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_OFF), 2},
- /* Turn OFF VDD1 */
- {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_OFF), 2},
- /* Turn OFF VDD2 */
- {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_OFF), 2},
- /* Turn OFF VPLL1 */
- {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_OFF), 2},
-};
-
-static struct twl4030_script sleep_on_script __initdata = {
- .script = sleep_on_seq,
- .size = ARRAY_SIZE(sleep_on_seq),
- .flags = TWL4030_SLEEP_SCRIPT,
-};
-
-static struct twl4030_ins wakeup_p12_seq[] __initdata = {
- /* Turn on HFCLKOUT */
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
- /* Turn ON VDD1 */
- {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_ACTIVE), 2},
- /* Turn ON VDD2 */
- {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_ACTIVE), 2},
- /* Turn ON VPLL1 */
- {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_ACTIVE), 2},
-};
-
-static struct twl4030_script wakeup_p12_script __initdata = {
- .script = wakeup_p12_seq,
- .size = ARRAY_SIZE(wakeup_p12_seq),
- .flags = TWL4030_WAKEUP12_SCRIPT,
-};
-
-static struct twl4030_ins wakeup_p3_seq[] __initdata = {
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
-};
-
-static struct twl4030_script wakeup_p3_script __initdata = {
- .script = wakeup_p3_seq,
- .size = ARRAY_SIZE(wakeup_p3_seq),
- .flags = TWL4030_WAKEUP3_SCRIPT,
-};
-
-static struct twl4030_ins wrst_seq[] __initdata = {
-/*
- * Reset twl4030.
- * Reset VDD1 regulator.
- * Reset VDD2 regulator.
- * Reset VPLL1 regulator.
- * Enable sysclk output.
- * Reenable twl4030.
- */
- {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
- {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
- {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
- {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
- {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
-};
-static struct twl4030_script wrst_script __initdata = {
- .script = wrst_seq,
- .size = ARRAY_SIZE(wrst_seq),
- .flags = TWL4030_WRST_SCRIPT,
-};
-
-static struct twl4030_script *twl4030_scripts[] __initdata = {
- sleep_on_script,
- wakeup_p12_script,
- wakeup_p3_script,
- wrst_script,
-};
-
static struct twl4030_resconfig twl4030_rconfig[] = {
- { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
- .type2 = -1 },
- { .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
- .type2 = -1 },
- { .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
- .type2 = -1 },
+ { .resource = RES_VPLL1, .devgroup = DEV_GRP_P1, .type = 3,
+ .type2 = 1, .remap_sleep = RES_STATE_OFF },
+ { .resource = RES_VINTANA1, .devgroup = DEV_GRP_ALL, .type = 1,
+
[PATCH v5 5/5] omap3: pm: Use generic TRITON power scripts for ZOOM[2,3], 3630SDP board
Adding the power script data for zoom board to TWL4030 platform data.
Updating the sleep/wakeup/warm_rest sequence voltsetup_time
from generic script file.
Signed-off-by: Lesly A M x0080...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/mach-omap2/Makefile |9 --
arch/arm/mach-omap2/board-zoom-peripherals.c | 36 ++
2 files changed, 42 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f60dca3..ba3de05 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -137,14 +137,17 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o
\
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
board-zoom-peripherals.o \
hsmmc.o \
- board-zoom-debugboard.o
+ board-zoom-debugboard.o \
+ twl4030.o
obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
board-zoom-peripherals.o \
hsmmc.o \
- board-zoom-debugboard.o
+ board-zoom-debugboard.o \
+ twl4030.o
obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o \
board-zoom-peripherals.o \
- hsmmc.o
+ hsmmc.o \
+ twl4030.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
hsmmc.o
obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o \
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..ce3ff8b 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -26,6 +26,7 @@
#include mux.h
#include hsmmc.h
+#include twl4030.h
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
@@ -94,6 +95,38 @@ static struct twl4030_keypad_data zoom_kp_twl4030_data = {
.rep= 1,
};
+static struct twl4030_resconfig twl4030_rconfig[] = {
+ { .resource = RES_VPLL1, .devgroup = DEV_GRP_P1, .type = 3,
+ .type2 = 1, .remap_sleep = RES_STATE_OFF },
+ { .resource = RES_VINTANA1, .devgroup = DEV_GRP_ALL, .type = 1,
+ .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
+ { .resource = RES_VINTANA2, .devgroup = DEV_GRP_ALL, .type = 0,
+ .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
+ { .resource = RES_VINTDIG, .devgroup = DEV_GRP_ALL, .type = 1,
+ .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
+ { .resource = RES_VIO, .devgroup = DEV_GRP_ALL, .type = 2,
+ .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
+ { .resource = RES_VDD1, .devgroup = DEV_GRP_P1,
+ .type = 4, .type2 = 1, .remap_sleep = RES_STATE_OFF },
+ { .resource = RES_VDD2, .devgroup = DEV_GRP_P1,
+ .type = 3, .type2 = 1, .remap_sleep = RES_STATE_OFF },
+ { .resource = RES_REGEN, .devgroup = DEV_GRP_ALL, .type = 2,
+ .type2 = 1, .remap_sleep = RES_STATE_SLEEP },
+ { .resource = RES_NRES_PWRON, .devgroup = DEV_GRP_ALL, .type = 0,
+ .type2 = 1, .remap_sleep = RES_STATE_SLEEP },
+ { .resource = RES_CLKEN, .devgroup = DEV_GRP_ALL, .type = 3,
+ .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
+ { .resource = RES_SYSEN, .devgroup = DEV_GRP_ALL, .type = 6,
+ .type2 = 1, .remap_sleep = RES_STATE_SLEEP },
+ { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3,
+ .type = 0, .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
+ { 0, 0},
+};
+
+static struct twl4030_power_data zoom_t2scripts_data __initdata = {
+ .resource_config = twl4030_rconfig,
+};
+
static struct regulator_consumer_supply zoom_vmmc1_supply = {
.supply = vmmc,
};
@@ -239,6 +272,7 @@ static struct twl4030_platform_data zoom_twldata = {
.usb= zoom_usb_data,
.gpio = zoom_gpio_data,
.keypad = zoom_kp_twl4030_data,
+ .power = zoom_t2scripts_data,
.codec = zoom_codec_data,
.vmmc1 = zoom_vmmc1,
.vmmc2 = zoom_vmmc2,
@@ -279,6 +313,8 @@ static void enable_board_wakeup_source(void)
void __init zoom_peripherals_init(void)
{
+ twl4030_get_scripts(zoom_t2scripts_data);
+
omap_i2c_init();
usb_musb_init(musb_board_data);
enable_board_wakeup_source();
--
1.6.0.4
--
To unsubscribe from
Upstream linux-omap kernel on Nokia N900?
Hi, Nokia N900 is shipped to users with a 2.6.28 omap kernel. Many patches for the hardware and various features have been pushed upstream by Nokia developers and possibly others. Those are now available in current l-o tree. Nonetheless, many drivers and various features are still missing upstream. Simply put, one cannot expect to run a current l-o kernel on the device (and expect to get a GUI and/or make call with the device). To get an idea of what it would take to achieve that, I started looking at what is missing upstream, what is already there and what is currently being pushed. I started putting some notes on this triage work and a set of patches here: http://natisbad.org/N900/n900-current-linux-omap-kernel.html If some among you are interested and/or have comments on the topic, they are welcome. Among other things, I am worried about the OMAP 3430 GPU code: if some people from TI can provide some advice on that aspect, that would be great! Cheers, a+ -- 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: Upstream linux-omap kernel on Nokia N900?
Hi, On Mon, Apr 19, 2010 at 01:49:15PM +0200, ext Arnaud Ebalard wrote: Nokia N900 is shipped to users with a 2.6.28 omap kernel. Many patches for the hardware and various features have been pushed upstream by Nokia developers and possibly others. Those are now available in current l-o tree. Nonetheless, many drivers and various features are still missing upstream. Simply put, one cannot expect to run a current l-o kernel on the device (and expect to get a GUI and/or make call with the device). tell me about it :-p Thing is that it doesn't really depend only on Nokia to get those parts done. Well, we can get the kernel part done by just cleaning up and porting the 2.6.28 drivers to current mainline, but in case of e.g. SGX we still miss the xorg driver and I don't think that'll be released any time soon. Another problem is that the bootloader believes it can pass all the obsoleted OMAP TAGs to kernel and the 2.6.28 kernel depends on those, maybe that can be worked around. I don't know whether kernel simply drops invalid TAGs or not... Good work anyways... At least it's now documented ;-) PS: BTW, CBUS isn't really necessary for n900 and I have almost 40 patches cleaning that up pending in this mailing list :-p -- balbi -- 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: Upstream linux-omap kernel on Nokia N900?
Balbi Felipe (Nokia-D/Helsinki) wrote: Hi, On Mon, Apr 19, 2010 at 01:49:15PM +0200, ext Arnaud Ebalard wrote: Nokia N900 is shipped to users with a 2.6.28 omap kernel. Many patches for the hardware and various features have been pushed upstream by Nokia developers and possibly others. Those are now available in current l-o tree. Nonetheless, many drivers and various features are still missing upstream. Simply put, one cannot expect to run a current l-o kernel on the device (and expect to get a GUI and/or make call with the device). tell me about it :-p Thing is that it doesn't really depend only on Nokia to get those parts done. Well, we can get the kernel part done by just cleaning up and porting the 2.6.28 drivers to current mainline, but in case of e.g. SGX we still miss the xorg driver and I don't think that'll be released any time soon. Another problem is that the bootloader believes it can pass all the obsoleted OMAP TAGs to kernel and the 2.6.28 kernel depends on those, maybe that can be worked around. I don't know whether kernel simply drops invalid TAGs or not... Yes kernel simply drops unrecognized TAGs and just prints a warning message. Good work anyways... At least it's now documented ;-) PS: BTW, CBUS isn't really necessary for n900 and I have almost 40 patches cleaning that up pending in this mailing list :-p -- 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
DSS2 V4L2
I'm trying to get the DVSDK (3.01.00.03) working. It uses 2.6.32 + DSS2 + V4L2. What I'm having trouble with is how to configure/create/setup a video overlay such that I get V4L2 device for the display. In particular, what magic is required to create /dev/video1? Note: I'd be glad to send this question to a more targeted list, but the only one mentioned in the DVSDK documentation does not really exist :-( -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: Upstream linux-omap kernel on Nokia N900?
Felipe Balbi felipe.ba...@nokia.com writes: On Mon, Apr 19, 2010 at 02:23:39PM +0200, ext Arnaud Ebalard wrote: The other main obstacle was the code to interface with the phone stack (SSI MacSAAB, CMT stuff). Felipe, do you know if someone @nokia has some more recent version available which could be shared if there is good news from TI on SGX aspect. personally I really dislike the way the whole SSI were written but that's only my opinion. And I don't whether anyone would have other version of that. Maybe you can contact the original author which should be listed in the files' header. Carlos Chinea (@nokia). I sent him an eamil two weeks ago but got no response yet. I will wait a bit more (he may be busy) and take a look at the code meanwhile. Cheers, a+ -- 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
Please use proper threading while sending patches
Hi, I've noticed that many people use bad threading while sending patches. Bad: http://thread.gmane.org/gmane.linux.ports.arm.omap/34138 Good: http://thread.gmane.org/gmane.linux.ports.arm.omap/33112 In order to configure git to use proper threading do this: % git config sendemail.chainreplyto false This is already the default in git 1.7. I've also updated omapmedia accordingly: http://omappedia.org/wiki/Releasing_to_Linux_kernel_using_patches_and_emails Cheers. -- Felipe Contreras -- 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: 32-bit transfers broken in OMAP SPI driver?
Cory, can you please take a look at this? Thanks, g. On Mon, Apr 19, 2010 at 1:58 AM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Ran across drivers/spi/omap_spi_100k.c and its handling of 16-bit transfers seems buggy to me. Firstly, addresses do not get incremented in omap1_spi100k_txrx_pio() (word_len = 32) case, a fix for which seems to be obvious, secondly, spi100k_write_data() and spi100k_read_data() only write / read 16-bit data blocks, for which I'm not adventurous enough to propose a patch without even touching the hardware;) Am I right? Maybe just disable 16-bit transfers altogether, since they are broken, and thus, obviously, unused. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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: DSS2 V4L2
Op 19 apr 2010, om 14:29 heeft Gary Thomas het volgende geschreven: I'm trying to get the DVSDK (3.01.00.03) working. It uses 2.6.32 + DSS2 + V4L2. What I'm having trouble with is how to configure/create/setup a video overlay such that I get V4L2 device for the display. In particular, what magic is required to create /dev/video1? The trick is usually do not create 2 framebuffers. My understanding is that an overlay can either be a framebuffer or a v4l device, but not both. regards, Koen-- 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: DSS2 V4L2
On 04/19/2010 06:58 AM, Koen Kooi wrote: Op 19 apr 2010, om 14:29 heeft Gary Thomas het volgende geschreven: I'm trying to get the DVSDK (3.01.00.03) working. It uses 2.6.32 + DSS2 + V4L2. What I'm having trouble with is how to configure/create/setup a video overlay such that I get V4L2 device for the display. In particular, what magic is required to create /dev/video1? The trick is usually do not create2 framebuffers. My understanding is that an overlay can either be a framebuffer or a v4l device, but not both. That was it, thanks! -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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 1/2] omap: rx51_defconfig: Remove duplicate phonet
Phonet is enabled by the commit bce54fed941e03695ab557100a4bd1e457abca42 and this duplicate gives a warning when doing make rx51_defconfig. Signed-off-by: Jarkko Nikula jhnik...@gmail.com Cc: Felipe Balbi felipe.ba...@nokia.com --- arch/arm/configs/rx51_defconfig |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/rx51_defconfig b/arch/arm/configs/rx51_defconfig index 45135ff..cc6a32a 100644 --- a/arch/arm/configs/rx51_defconfig +++ b/arch/arm/configs/rx51_defconfig @@ -480,7 +480,6 @@ CONFIG_BT_HIDP=m # CONFIG_BT_HCIBFUSB is not set # CONFIG_BT_HCIVHCI is not set # CONFIG_AF_RXRPC is not set -# CONFIG_PHONET is not set CONFIG_WIRELESS=y CONFIG_CFG80211=y # CONFIG_CFG80211_REG_DEBUG is not set -- 1.7.0 -- 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] Drivers: w1: omap_hdq: Fix missing include sched.h
In commit f6a570333e554b48ad589e7137c77c57809eee81 #include sched.h was removed from module.h and not added in omap_hdq.c . The definition for TASK_UNINTERRUPTIBLE and schedule_timeout_uninterruptible are missing. This patch fixes the missing definition. Signed-off-by: Thomas Weber we...@corscience.de --- drivers/w1/masters/omap_hdq.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c index ef36fca..3a7e9ff 100644 --- a/drivers/w1/masters/omap_hdq.c +++ b/drivers/w1/masters/omap_hdq.c @@ -16,6 +16,7 @@ #include linux/err.h #include linux/clk.h #include linux/io.h +#include linux/sched.h #include asm/irq.h #include mach/hardware.h -- 1.6.4.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: [PATCH 0/8 RFC] OMAP: GPIO: Split OMAP1 and OMAP2PLUS
Varadarajan, Charulatha ch...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, April 07, 2010 4:01 AM To: Varadarajan, Charulatha Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com; t...@atomide.com Subject: Re: [PATCH 0/8 RFC] OMAP: GPIO: Split OMAP1 and OMAP2PLUS Charulatha V ch...@ti.com writes: This patch series is in preparation to adapt GPIO to HWMOD FW. It creates OMAP architecture specific gpio files to handle SoC specific gpio_init. The common plat-omap/gpio.c handles all common GPIO APIs. OMAP2PLUS GPIO module is implemented as early platform device and OMAP1 GPIO is still handled in old way via gpio_init from board files. Save/restore context, gpio_prepare_for_retention and gpio_resume_after_retention APIs are also handled in plat-omap layer. These APIs are currently not used in OMAP1, but still they might become common for different OMAP architectures in the future. Hence they are handled in plat-omap layer. If they need to be moved to mach-omap2 layer, additional patches may be sent during next version of this patch series. This patch series is generated on top of linux-omap-2.6 branch: master and tested on 3430SDP, 4430SDP zoom3. I have many problems with this series, but without going into the specifics of each patch, I have a big problem with the general approach being taken here. You say this is in preparation for adaptation to hwmod, but in fact, this series is duplicating a lot of the work you would get for free by starting with hwmod. You're generating a bunch of code that will be completely thrown away with a hwmod conversion. Instead, you should *start* by using hwmod + omap_device to generate the platform_devices for you. Doing this, you will drop patches 2, 3 and 4 entirely (they are mostly identical anyways, except for the search-and-replace) and also eliminate the need for patch 5. What is needed here is a way to introduce the platform_device conversion without introducing signifcant functional changes at the same time. Here's a proposal to do that, and which should also be considerably easier to review for sanity: - use hwmod + omap_device to generate (early) platform_devices - modify plat-omap/gpio.c to use base addr and IRQ from platform_device - modify plat-omap/gpio.c to get clocks based on 'struct device' For an example, you can see the pm-wip/hwmods branch in my tree for how this was done for UART and the pm-wip/mmc branch for how this was done for MMC. I agree that most of the code would be thrown away once HWMOD comes into picture. Since hwmod patches would be gated for a long time, we decided to first proceed in pushing GPIO as early init patch series to mainline first, so that hwmods branch and mainline would not differ much. Tony/Kevin, Please suggest which approach is better 1. to send early init GPIO patches to mainline due to above mentioned reason (or) 2. to make GPIO as a HWMOD FW adapted driver and gate it in hwmods branch. Please do option 2 to avoid massive duplication of work. 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
[PATCH v4 1/2] input: touchscreen: introduce tsc2005 driver
From: Lauri Leukkunen lauri.leukku...@nokia.com Introduce a driver for the Texas Instruments TSC2005 touchscreen controller (http://focus.ti.com/docs/prod/folders/print/tsc2005.html). The patch is based on a driver by Lauri Leukkunen, with modifications by David Brownell, Phil Carmody, Imre Deak, Hiroshi DOYU, Ari Kauppi, Tony Lindgren, Jarkko Nikula, Eero Nurkkala and Roman Tereshonkov. Signed-off-by: Lauri Leukkunen lauri.leukku...@nokia.com [aaro.koski...@nokia.com: patch description, rebasing cleanup] Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com Cc: David Brownell dbrown...@users.sourceforge.net Cc: Phil Carmody ext-phil.2.carm...@nokia.com Cc: Imre Deak imre.d...@nokia.com Cc: Hiroshi DOYU hiroshi.d...@nokia.com Cc: Ari Kauppi ext-ari.kau...@nokia.com Cc: Tony Lindgren t...@atomide.com Cc: Jarkko Nikula jhnik...@gmail.com Cc: Eero Nurkkala ext-eero.nurkk...@nokia.com Cc: Roman Tereshonkov roman.tereshon...@nokia.com --- v4: Refreshed the patches against the current mainline (13bd8e4673d527a9e48f41956b11d391e7c2cfe0). No other changes as no comments were received. The v3 has some major modifications. I have tried to clean up and simplify the driver. All action takes place in thread context, SPI transfers are synchronous, the spinlock is removed, and there are no long sections with interrupts disabled. The driver should be now SMP safe. Also the following review comments are addressed: - Use del_timer_sync() instead of del_timer(). - Use mod_timer() always instead of add_timer(). - Use attribute_group. - Delete filtering and averaging which belong to upper layers. - Delete pen_down sysfs file. The previous version and comments can be seen here: http://marc.info/?t=12573411564r=1w=2 drivers/input/touchscreen/Kconfig | 11 + drivers/input/touchscreen/Makefile |1 + drivers/input/touchscreen/tsc2005.c | 678 +++ include/linux/spi/tsc2005.h | 41 +++ 4 files changed, 731 insertions(+), 0 deletions(-) create mode 100644 drivers/input/touchscreen/tsc2005.c create mode 100644 include/linux/spi/tsc2005.h diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index dfafc76..72c1797 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -548,6 +548,17 @@ config TOUCHSCREEN_TOUCHIT213 To compile this driver as a module, choose M here: the module will be called touchit213. +config TOUCHSCREEN_TSC2005 +tristate TSC2005 based touchscreens +depends on SPI_MASTER +help + Say Y here if you have a TSC2005 based touchscreen. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called tsc2005. + config TOUCHSCREEN_TSC2007 tristate TSC2007 based touchscreens depends on I2C diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile index d61a3b4..61fa8b5 100644 --- a/drivers/input/touchscreen/Makefile +++ b/drivers/input/touchscreen/Makefile @@ -33,6 +33,7 @@ obj-$(CONFIG_TOUCHSCREEN_S3C2410) += s3c2410_ts.o obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213) += touchit213.o obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT) += touchright.o obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o +obj-$(CONFIG_TOUCHSCREEN_TSC2005) += tsc2005.o obj-$(CONFIG_TOUCHSCREEN_TSC2007) += tsc2007.o obj-$(CONFIG_TOUCHSCREEN_UCB1400) += ucb1400_ts.o obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001) += wacom_w8001.o diff --git a/drivers/input/touchscreen/tsc2005.c b/drivers/input/touchscreen/tsc2005.c new file mode 100644 index 000..27ee361 --- /dev/null +++ b/drivers/input/touchscreen/tsc2005.c @@ -0,0 +1,678 @@ +/* + * TSC2005 touchscreen driver + * + * Copyright (C) 2006-2010 Nokia Corporation + * + * Author: Lauri Leukkunen lauri.leukku...@nokia.com + * based on TSC2301 driver by Klaus K. Pedersen klaus.k.peder...@nokia.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * 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, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include linux/kernel.h +#include linux/module.h +#include linux/input.h +#include linux/interrupt.h +#include linux/delay.h +#include linux/spi/spi.h +#include linux/spi/tsc2005.h + +/* + * The touchscreen interface operates as follows: + * + * 1) Pen is
[PATCH v4 2/2] omap: rx-51: enable tsc2005
Enable TSC2005 touchscreen driver on the RX-51 board.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/configs/rx51_defconfig |1 +
arch/arm/mach-omap2/board-rx51-peripherals.c | 57 ++
2 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/arm/configs/rx51_defconfig b/arch/arm/configs/rx51_defconfig
index 45135ff..2ebfdb9 100644
--- a/arch/arm/configs/rx51_defconfig
+++ b/arch/arm/configs/rx51_defconfig
@@ -804,6 +804,7 @@ CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
+CONFIG_TOUCHSCREEN_TSC2005=m
# CONFIG_TOUCHSCREEN_TSC2007 is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_ATI_REMOTE is not set
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 4377a4c..0fafac4 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -14,6 +14,7 @@
#include linux/input.h
#include linux/input/matrix_keypad.h
#include linux/spi/spi.h
+#include linux/spi/tsc2005.h
#include linux/spi/wl12xx.h
#include linux/i2c.h
#include linux/i2c/twl.h
@@ -42,18 +43,28 @@
#define RX51_WL1251_POWER_GPIO 87
#define RX51_WL1251_IRQ_GPIO 42
+#define RX51_TSC2005_RESET_GPIO104
+#define RX51_TSC2005_IRQ_GPIO 100
+
/* list all spi devices here */
enum {
RX51_SPI_WL1251,
+ RX51_SPI_TSC2005,
};
static struct wl12xx_platform_data wl1251_pdata;
+static struct tsc2005_platform_data tsc2005_pdata;
static struct omap2_mcspi_device_config wl1251_mcspi_config = {
.turbo_mode = 0,
.single_channel = 1,
};
+static struct omap2_mcspi_device_config tsc2005_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1,
+};
+
static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = {
[RX51_SPI_WL1251] = {
.modalias = wl1251,
@@ -64,6 +75,15 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
.controller_data= wl1251_mcspi_config,
.platform_data = wl1251_pdata,
},
+ [RX51_SPI_TSC2005] = {
+ .modalias = tsc2005,
+ .bus_num= 1,
+ .chip_select= 0,
+ .irq= OMAP_GPIO_IRQ(RX51_TSC2005_IRQ_GPIO),
+ .max_speed_hz = 600,
+ .controller_data= tsc2005_mcspi_config,
+ .platform_data = tsc2005_pdata,
+ },
};
#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
@@ -703,6 +723,42 @@ static inline void board_onenand_init(void)
#endif
+static struct tsc2005_platform_data tsc2005_pdata = {
+ .ts_pressure_max = 2048,
+ .ts_pressure_fudge = 2,
+ .ts_x_max = 4096,
+ .ts_x_fudge= 4,
+ .ts_y_max = 4096,
+ .ts_y_fudge= 7,
+ .ts_x_plate_ohm= 280,
+ .esd_timeout_ms= 8000,
+};
+
+static void rx51_tsc2005_set_reset(bool enable)
+{
+ gpio_set_value(RX51_TSC2005_RESET_GPIO, enable);
+}
+
+static void __init rx51_init_tsc2005(void)
+{
+ int r;
+
+ r = gpio_request(RX51_TSC2005_IRQ_GPIO, tsc2005 IRQ);
+ if (r = 0)
+ gpio_direction_input(RX51_TSC2005_IRQ_GPIO);
+ else
+ printk(KERN_ERR unable to get %s GPIO\n, tsc2005 IRQ);
+
+ r = gpio_request(RX51_TSC2005_RESET_GPIO, tsc2005 reset);
+ if (r = 0) {
+ gpio_direction_output(RX51_TSC2005_RESET_GPIO, 1);
+ tsc2005_pdata.set_reset = rx51_tsc2005_set_reset;
+ } else {
+ printk(KERN_ERR unable to get %s GPIO\n, tsc2005 reset);
+ tsc2005_pdata.esd_timeout_ms = 0;
+ }
+}
+
#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
static struct omap_smc91x_platform_data board_smc91x_data = {
@@ -787,6 +843,7 @@ void __init rx51_peripherals_init(void)
board_smc91x_init();
rx51_add_gpio_keys();
rx51_init_wl1251();
+ rx51_init_tsc2005();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
omap2_hsmmc_init(mmc);
--
1.6.3.3
--
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][PATCH] [I2C]pass scll, sclh through board file for Errata i585
From: Balaji T K balaj...@ti.com
Errata ID: i535 - I2C1 to 3 SCL low period is shorter in FS mode
Due to IO cell influence, I2C1 to 3 SCL low period can be shorter than
expected.
As a result, I2C AC timing (SCL minimum low period) in FS mode may not meet
the timing configured by software.
I2C1 to 3, SCL low period is programmable and proper adjustments
to the SCLL/HSSCLL values can avoid the issue.
This patch provides flexibility to control tLOW, tHIGH for different boards.
scll, sclh values are to be provide in board data
for differents modes (standard, fast and high speed mode)
as the scl rate (I2C bus speed) can be changed by bootargs.
If scll, sclh values are not provided, scll and sclh values will be computed
for duty cycle tHIGH:tLOW of 1:2 (for HS, FS) and 1:1 for Standard as before
Other board file changes are yet to be done.
arch/arm/mach-omap1/board-ams-delta.c
arch/arm/mach-omap1/board-fsample.c
arch/arm/mach-omap1/board-generic.c
arch/arm/mach-omap1/board-h2.c
arch/arm/mach-omap1/board-h3.c
arch/arm/mach-omap1/board-innovator.c
arch/arm/mach-omap1/board-nokia770.c
arch/arm/mach-omap1/board-osk.c
arch/arm/mach-omap1/board-palmte.c
arch/arm/mach-omap1/board-palmtt.c
arch/arm/mach-omap1/board-palmz71.c
arch/arm/mach-omap1/board-perseus2.c
arch/arm/mach-omap1/board-sx1.c
arch/arm/mach-omap1/board-voiceblue.c
arch/arm/mach-omap2/board-2430sdp.c
arch/arm/mach-omap2/board-3430sdp.c
arch/arm/mach-omap2/board-am3517evm.c
arch/arm/mach-omap2/board-cm-t35.c
arch/arm/mach-omap2/board-devkit8000.c
arch/arm/mach-omap2/board-igep0020.c
arch/arm/mach-omap2/board-ldp.c
arch/arm/mach-omap2/board-n8x0.c
arch/arm/mach-omap2/board-omap3beagle.c
arch/arm/mach-omap2/board-omap3evm.c
arch/arm/mach-omap2/board-omap3pandora.c
arch/arm/mach-omap2/board-omap3touchbook.c
arch/arm/mach-omap2/board-overo.c
arch/arm/mach-omap2/board-rx51-peripherals.c
arch/arm/mach-omap2/board-zoom-peripherals.c
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 26 ++--
arch/arm/plat-omap/i2c.c | 38 +++-
arch/arm/plat-omap/include/plat/i2c.h | 37 ++-
drivers/i2c/busses/i2c-omap.c | 52 ++--
4 files changed, 124 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 5822bcf..839306e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -594,6 +594,26 @@ static struct twl4030_platform_data sdp3430_twldata = {
.vpll2 = sdp3430_vpll2,
};
+static struct omap_i2c_scl_data __initdata sdp3430_i2c1_scl_data = {
+ .rate = 2600,
+ .standard_scll = 20, /* For 100Khz */
+ .standard_sclh = 20, /* For 100Khz */
+ .fast_mode_scll = 16, /* For 400Khz */
+ .fast_mode_sclh = 8,/* For 400Khz */
+ .hs_phase1_scll = 32, /* For 2600Khz */
+ .hs_phase1_sclh = 16, /* For 2600Khz */
+ .hs_phase2_scll = 24, /* For 2600Khz */
+ .hs_phase2_sclh = 12, /* For 2600Khz */
+};
+
+static struct omap_i2c_scl_data __initdata sdp3430_i2c2_scl_data = {
+ .rate = 400,
+};
+
+static struct omap_i2c_scl_data __initdata sdp3430_i2c3_scl_data = {
+ .rate = 400,
+};
+
static struct i2c_board_info __initdata sdp3430_i2c_boardinfo[] = {
{
I2C_BOARD_INFO(twl4030, 0x48),
@@ -606,12 +626,12 @@ static struct i2c_board_info __initdata
sdp3430_i2c_boardinfo[] = {
static int __init omap3430_i2c_init(void)
{
/* i2c1 for PMIC only */
- omap_register_i2c_bus(1, 2600, sdp3430_i2c_boardinfo,
+ omap_register_i2c_bus(1, sdp3430_i2c1_scl_data, sdp3430_i2c_boardinfo,
ARRAY_SIZE(sdp3430_i2c_boardinfo));
/* i2c2 on camera connector (for sensor control) and optional isp1301 */
- omap_register_i2c_bus(2, 400, NULL, 0);
+ omap_register_i2c_bus(2, sdp3430_i2c2_scl_data, NULL, 0);
/* i2c3 on display connector (for DVI, tfp410) */
- omap_register_i2c_bus(3, 400, NULL, 0);
+ omap_register_i2c_bus(3, sdp3430_i2c3_scl_data, NULL, 0);
return 0;
}
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 624e262..81c9d3e 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -70,14 +70,14 @@ static struct resource i2c_resources[][2] = {
}, \
}
-static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
+static struct omap_i2c_platform_data i2c_pdata[ARRAY_SIZE(i2c_resources)];
static struct platform_device omap_i2c_devices[] = {
- I2C_DEV_BUILDER(1, i2c_resources[0], i2c_rate[0]),
+
[PATCH v4] OMAP: Fix for bus width which improves SD card's peformance.
The previous patch was Line wrapped , resending
correct patch.
NM, Sorry I miss spelled your name correcting this time.
Regards,
Kishore
From: Kishore Kadiyala kishore.kadiy...@ti.com
This patch improves low speeds for SD cards.
OMAP-MMC controller's can support maximum bus width of '8'.
when bus width is mentioned as 8 in controller data,the SD
stack will check whether bus width is 4 and if not it will
set bus width to 1 and there by degrading performance.
This patch fixes the issue and improves the performance of
SD cards.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Acked-by: Madhusudhan Chikkature madhu...@ti.com
Tested-by: Jarkko Nikula jhnik...@gmail.com
---
In V4 : Updated with Nishant's comments and appened his Signed-off
In V3 : Updated with Madhu's comments and appended Tested by Nikula
In V2 : Appended Signed-off by Venkat and Ack by Madhu
Here are my experiment numbers, on a Class 6 SDHC card:
Read peformance is increased by 220%
Write Performance is increased by 52%
drivers/mmc/host/omap_hsmmc.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 8c97c22..9c1a60e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2091,10 +2091,23 @@ static int __init omap_hsmmc_probe(struct
mmc-caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
MMC_CAP_WAIT_WHILE_BUSY;
- if (mmc_slot(host).wires = 8)
- mmc-caps |= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA);
- else if (mmc_slot(host).wires = 4)
+ switch (mmc_slot(host).wires) {
+ case 8:
+ mmc-caps |= MMC_CAP_8_BIT_DATA;
+ /* Fall through */
+ case 4:
mmc-caps |= MMC_CAP_4_BIT_DATA;
+ break;
+ case 1:
+ /* Nothing to crib here */
+ case 0:
+ /* Assuming nothing was given by board, Core use's 1-Bit */
+break;
+ default:
+ /* Completely unexpected.. Core goes with 1-Bit Width */
+ dev_crit(mmc_dev(host-mmc), Invalid width %d\n used!
+ using 1 instead\n, mmc_slot(host).wires);
+ }
if (mmc_slot(host).nonremovable)
mmc-caps |= MMC_CAP_NONREMOVABLE;
--
1.6.3.3
--
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 5/9] AM3517: Add audio codec platform data
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Stanley.Miao
Sent: Monday, April 19, 2010 3:51 PM
To: linux-omap@vger.kernel.org
Cc: t...@atomide.com; Hiremath, Vaibhav; Govindarajan, Sriramakrishnan
Subject: [PATCH 5/9] AM3517: Add audio codec platform data
Codec tlv320aic23 is on the second i2c bus. Add the tlv320aic23 info in
i2c2 board_info.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
arch/arm/mach-omap2/board-am3517evm.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-
omap2/board-am3517evm.c
index 41f766c..f24e367 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -199,6 +199,9 @@ static struct pca953x_platform_data
am3517evm_gpio_expander_info_0 = {
};
static struct i2c_board_info __initdata am3517evm_i2c2_boardinfo[] = {
{
+ I2C_BOARD_INFO(tlv320aic23, 0x1A),
+ },
+ {
I2C_BOARD_INFO(tca6416, 0x21),
.platform_data = am3517evm_gpio_expander_info_0,
},
[Aggarwal, Anuj] Similar patch exists at:
http://marc.info/?l=linux-omapm=125684238323749w=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 4/9] AM3517: Add platform init code for regulator driver
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Stanley.Miao
Sent: Monday, April 19, 2010 3:51 PM
To: linux-omap@vger.kernel.org
Cc: t...@atomide.com; Hiremath, Vaibhav; Govindarajan, Sriramakrishnan
Subject: [PATCH 4/9] AM3517: Add platform init code for regulator driver
Add platform init code for regulator driver.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
arch/arm/mach-omap2/board-am3517evm.c | 122
+
1 files changed, 122 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-
omap2/board-am3517evm.c
index 3acfcae..41f766c 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -21,6 +21,7 @@
#include linux/platform_device.h
#include linux/gpio.h
#include linux/i2c/pca953x.h
+#include linux/regulator/machine.h
#include mach/hardware.h
#include mach/am35xx.h
@@ -46,6 +47,122 @@ static struct i2c_board_info __initdata
am3517evm_i2c1_boardinfo[] = {
},
};
+/* TPS65023 specific initialization */
+/* VDCDC1 - VDD_CORE */
+static struct regulator_consumer_supply am3517_evm_vdcdc1_supplies[] = {
+ {
+ .supply = vdd_core,
+ },
+};
+
+/* VDCDC2 - VDDSHV */
+static struct regulator_consumer_supply am3517_evm_vdcdc2_supplies[] = {
+ {
+ .supply = vddshv,
+ },
+};
+
+/* VDCDC2 |- VDDS
+|- VDDS_SRAM_CORE_BG
+|- VDDS_SRAM_MPU */
+static struct regulator_consumer_supply am3517_evm_vdcdc3_supplies[] = {
+ {
+ .supply = vdds,
+ },
+ {
+ .supply = vdds_sram_core_bg,
+ },
+ {
+ .supply = vdds_sram_mpu,
+ },
+};
+
+/* LDO1 |- VDDA1P8V_USBPHY
+ |- VDDA_DAC */
+static struct regulator_consumer_supply am3517_evm_ldo1_supplies[] = {
+ {
+ .supply = vdda1p8v_usbphy,
+ },
+ {
+ .supply = vdda_dac,
+ },
+};
+
+/* LDO2 - VDDA3P3V_USBPHY */
+static struct regulator_consumer_supply am3517_evm_ldo2_supplies[] = {
+ {
+ .supply = vdda3p3v_usbphy,
+ },
+};
+
+static struct regulator_init_data am3517_evm_regulator_data[] = {
+ /* DCDC1 */
+ {
+ .constraints = {
+ .min_uV = 120,
+ .max_uV = 120,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .always_on = true,
+ .apply_uV = false,
+ },
+ .num_consumer_supplies =
ARRAY_SIZE(am3517_evm_vdcdc1_supplies),
+ .consumer_supplies = am3517_evm_vdcdc1_supplies,
+ },
+ /* DCDC2 */
+ {
+ .constraints = {
+ .min_uV = 330,
+ .max_uV = 330,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .always_on = true,
+ .apply_uV = false,
+ },
+ .num_consumer_supplies =
ARRAY_SIZE(am3517_evm_vdcdc2_supplies),
+ .consumer_supplies = am3517_evm_vdcdc2_supplies,
+ },
+ /* DCDC3 */
+ {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .always_on = true,
+ .apply_uV = false,
+ },
+ .num_consumer_supplies =
ARRAY_SIZE(am3517_evm_vdcdc3_supplies),
+ .consumer_supplies = am3517_evm_vdcdc3_supplies,
+ },
+ /* LDO1 */
+ {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .always_on = false,
+ .apply_uV = false,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(am3517_evm_ldo1_supplies),
+ .consumer_supplies = am3517_evm_ldo1_supplies,
+ },
+ /* LDO2 */
+ {
+ .constraints = {
+ .min_uV = 330,
+ .max_uV = 330,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .always_on = false,
+ .apply_uV = false,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(am3517_evm_ldo2_supplies),
+ .consumer_supplies = am3517_evm_ldo2_supplies,
+ },
+};
+
/*
* RTC -
[PATCH 1/5v2] DSPBRIDGE: Use node id instead of kernel address
From d9b80a431afa72558d71fa074c49aa2d15e09fd0 Mon Sep 17 00:00:00 2001
From: Ernesto Ramos erne...@ti.com
Date: Mon, 19 Apr 2010 11:58:57 -0500
Subject: [PATCH 1/5] DSPBRIDGE: Use node id instead of kernel address
Use idr kernel library to send/receive node ids to the
user instead of kernel address.
This id will be use to access the node handles at the
kernel side, if id does not match to any handle
DSP error DSP_EHANDlE is returned.
Signed-off-by: Ernesto Ramos erne...@ti.com
---
arch/arm/plat-omap/include/dspbridge/drv.h |6 +-
arch/arm/plat-omap/include/dspbridge/node.h|4 +-
.../plat-omap/include/dspbridge/resourcecleanup.h |5 -
drivers/dsp/bridge/pmgr/wcd.c | 158 +---
drivers/dsp/bridge/rmgr/drv.c | 150 ++-
drivers/dsp/bridge/rmgr/drv_interface.c|7 +-
drivers/dsp/bridge/rmgr/node.c | 100 +++--
7 files changed, 246 insertions(+), 184 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h
b/arch/arm/plat-omap/include/dspbridge/drv.h
index 947cbdd..02f93f5 100644
--- a/arch/arm/plat-omap/include/dspbridge/drv.h
+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
@@ -24,6 +24,7 @@
#include dspbridge/devdefs.h
#include dspbridge/drvdefs.h
+#include linux/idr.h
#define DRV_ASSIGN 1
#define DRV_RELEASE0
@@ -81,7 +82,7 @@ struct node_res_object {
s32 node_allocated; /* Node status */
s32 heap_allocated; /* Heap status */
s32 streams_allocated; /* Streams status */
- struct node_res_object *next;
+ int id;
};
/* Used for DMM mapped memory accounting */
@@ -131,8 +132,7 @@ struct process_context {
void *hprocessor;
/* DSP Node resources */
- struct node_res_object *node_list;
- struct mutex node_mutex;
+ struct idr *node_idp;
/* DMM mapped memory resources */
struct list_head dmm_map_list;
diff --git a/arch/arm/plat-omap/include/dspbridge/node.h
b/arch/arm/plat-omap/include/dspbridge/node.h
index ec0dcf3..f2375a2 100644
--- a/arch/arm/plat-omap/include/dspbridge/node.h
+++ b/arch/arm/plat-omap/include/dspbridge/node.h
@@ -60,7 +60,7 @@ extern dsp_status node_allocate(struct proc_object
*hprocessor,
OPTIONAL IN CONST struct dsp_cbdata
*pargs, OPTIONAL IN CONST struct dsp_nodeattrin
*attr_in,
- OUT struct node_object **ph_node,
+ OUT struct node_res_object **noderes,
struct process_context *pr_ctxt);
/*
@@ -261,7 +261,7 @@ extern dsp_status node_create_mgr(OUT struct node_mgr
**phNodeMgr,
* Ensures:
* DSP_SOK:hnode is invalid.
*/
-extern dsp_status node_delete(struct node_object *hnode,
+extern dsp_status node_delete(struct node_res_object *hnoderes,
struct process_context *pr_ctxt);
/*
diff --git a/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
b/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
index ef18477..00d5148 100644
--- a/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
+++ b/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
@@ -34,16 +34,11 @@ extern dsp_status drv_remove_all_resources(bhandle pPctxt);
extern dsp_status drv_remove_proc_context(struct drv_object *hDRVObject,
bhandle pr_ctxt);
-extern dsp_status drv_get_node_res_element(bhandle hnode, bhandle node_res,
- bhandle ctxt);
-
extern dsp_status drv_insert_node_res_element(bhandle hnode, bhandle node_res,
bhandle ctxt);
extern void drv_proc_node_update_heap_status(bhandle hNodeRes, s32 status);
-extern dsp_status drv_remove_node_res_element(bhandle node_res, bhandle
status);
-
extern void drv_proc_node_update_status(bhandle hNodeRes, s32 status);
extern dsp_status drv_proc_update_strm_res(u32 num_bufs, bhandle strm_res);
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 15a05a6..20e02f1 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1021,6 +1021,20 @@ u32 procwrap_stop(union Trapped_Args *args, void
*pr_ctxt)
}
/*
+ * find_handle =
+ */
+inline void find_node_handle(struct node_res_object **noderes,
+ void *pr_ctxt, void *hnode)
+{
+ rcu_read_lock();
+ *noderes = idr_find(((struct process_context *)pr_ctxt)-node_idp,
+ (int)hnode);
+ rcu_read_unlock();
+ return;
+}
+
+
+/*
* nodewrap_allocate
*/
u32 nodewrap_allocate(union Trapped_Args *args, void *pr_ctxt)
@@ -1031,7 +1045,7 @@ u32 nodewrap_allocate(union Trapped_Args *args, void
[PATCH 4/5v2] DSPBRIDGE: Use stream id instead of kernel address
From 04280fc2f09e509c83bd6d290365d3881e378ef8 Mon Sep 17 00:00:00 2001
From: Ernesto Ramos erne...@ti.com
Date: Mon, 19 Apr 2010 12:13:49 -0500
Subject: [PATCH 4/5] DSPBRIDGE: Use stream id instead of kernel address
Send stream ids to the user instead of handles, then when
the id is coming from user dspbridge can retrive the handle
using id and avoid using invalid handles.
Signed-off-by: Ernesto Ramos erne...@ti.com
---
arch/arm/plat-omap/include/dspbridge/drv.h |5 +-
.../plat-omap/include/dspbridge/resourcecleanup.h |6 -
arch/arm/plat-omap/include/dspbridge/strm.h|8 +-
drivers/dsp/bridge/pmgr/wcd.c | 103 +++--
drivers/dsp/bridge/rmgr/drv.c | 151 +++-
drivers/dsp/bridge/rmgr/drv_interface.c| 13 ++-
drivers/dsp/bridge/rmgr/strm.c | 75 +-
7 files changed, 187 insertions(+), 174 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h
b/arch/arm/plat-omap/include/dspbridge/drv.h
index 02f93f5..9307001 100644
--- a/arch/arm/plat-omap/include/dspbridge/drv.h
+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
@@ -114,7 +114,7 @@ struct strm_res_object {
void *hstream;
u32 num_bufs;
u32 dir;
- struct strm_res_object *next;
+ int id;
};
/* Overall Bridge process resource usage state */
@@ -146,8 +146,7 @@ struct process_context {
struct dspheap_res_object *pdspheap_list;
/* Stream resources */
- struct strm_res_object *pstrm_list;
- struct mutex strm_mutex;
+ struct idr *strm_idp;
};
/*
diff --git a/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
b/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
index 00d5148..4e93446 100644
--- a/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
+++ b/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
@@ -47,12 +47,6 @@ extern dsp_status drv_proc_insert_strm_res_element(bhandle
hStrm,
bhandle strm_res,
bhandle pPctxt);
-extern dsp_status drv_get_strm_res_element(bhandle hStrm, bhandle strm_res,
- bhandle ctxt);
-
-extern dsp_status drv_proc_remove_strm_res_element(bhandle strm_res,
- bhandle ctxt);
-
extern dsp_status drv_remove_all_strm_res_elements(bhandle ctxt);
extern enum node_state node_get_state(bhandle hnode);
diff --git a/arch/arm/plat-omap/include/dspbridge/strm.h
b/arch/arm/plat-omap/include/dspbridge/strm.h
index 51a897f..4f12989 100644
--- a/arch/arm/plat-omap/include/dspbridge/strm.h
+++ b/arch/arm/plat-omap/include/dspbridge/strm.h
@@ -44,7 +44,7 @@
* ap_buffer != NULL.
* Ensures:
*/
-extern dsp_status strm_allocate_buffer(struct strm_object *hStrm,
+extern dsp_status strm_allocate_buffer(struct strm_res_object *strmres,
u32 usize,
OUT u8 **ap_buffer,
u32 num_bufs,
@@ -66,7 +66,7 @@ extern dsp_status strm_allocate_buffer(struct strm_object
*hStrm,
* strm_init(void) called.
* Ensures:
*/
-extern dsp_status strm_close(struct strm_object *hStrm,
+extern dsp_status strm_close(struct strm_res_object *strmres,
struct process_context *pr_ctxt);
/*
@@ -137,7 +137,7 @@ extern void strm_exit(void);
* ap_buffer != NULL.
* Ensures:
*/
-extern dsp_status strm_free_buffer(struct strm_object *hStrm,
+extern dsp_status strm_free_buffer(struct strm_res_object *strmres,
u8 **ap_buffer, u32 num_bufs,
struct process_context *pr_ctxt);
@@ -273,7 +273,7 @@ extern dsp_status strm_issue(struct strm_object *hStrm, IN
u8 * pbuf,
*/
extern dsp_status strm_open(struct node_object *hnode, u32 dir,
u32 index, IN struct strm_attr *pattr,
- OUT struct strm_object **phStrm,
+ OUT struct strm_res_object **strmres,
struct process_context *pr_ctxt);
/*
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 61a4ab9..9d63b1f 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1491,6 +1491,19 @@ func_cont:
}
/*
+ * find_strm_handle =
+ */
+inline void find_strm_handle(struct strm_res_object **strmres,
+ void *pr_ctxt, void *hstream)
+{
+ rcu_read_lock();
+ *strmres = idr_find(((struct process_context *)pr_ctxt)-strm_idp,
+ (int)hstream);
+ rcu_read_unlock();
+ return;
+}
+
+/*
* strmwrap_allocate_buffer
*/
u32 strmwrap_allocate_buffer(union Trapped_Args *args, void *pr_ctxt)
@@
RE: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT
Hi all,
I have found the really issue here:
The problem here is that after MMUFault the DSP is allowed to continue
executing until here revices the message informing about the MMUFault and this
problem since the patches for mailbox migration.
Previous code:
if (DSP_SUCCEEDED(status)) {
hwStatus = HW_MMU_TLBAdd(resources.dwDmmuBase,
memPhysical, faultAddr,
HW_PAGE_SIZE_4KB, 1, mapAttrs,
HW_SET, HW_SET);
we add the dummy entry in the TBL, so that MMU module can translate the
address, we always map pages so it does not matter if we pass the complete
addrees (page + offset) or only the page aligned addres (page) we will write
only the page.
}
/* send an interrupt to DSP */
HW_MBOX_MsgWrite(resources.dwMboxBase, MBOX_ARM2DSP,
MBX_DEH_CLASS | MBX_DEH_EMMU);
we send a mailbox message to the DSP to inform it about MMUFault, this
function write the message into mailbox and trigger mailbox interrupt in the
DSP side.
/* Clear MMU interrupt */
HW_MMU_EventAck(resources.dwDmmuBase,
HW_MMU_TRANSLATION_FAULT);
we acked the MMU faul interrupt (transition fault interrupt). After MMUFault
MMU module stops DSP execution until the MMUfault flag is acked and it can find
the physical address of the virtual address requested by the DSP. So in this
moment the DSP continue executing again but before it can use the address
translated it had to attend mailbox interrupt (hardware interrupt) so it change
context to mailbox ISR and the DSP is stuck in infinite while loop.
However after mailbox migration patches the code looks like:
if (DSP_SUCCEEDED(status)) {
hw_status_obj =
hw_mmu_tlb_add(resources.dw_dmmu_base,
mem_physical, fault_addr,
HW_PAGE_SIZE4KB, 1,
map_attrs, HW_SET, HW_SET);
}
/* send an interrupt to DSP */
omap_mbox_msg_send(dev_context-mbox,
MBX_DEH_CLASS | MBX_DEH_EMMU);
the code looks pretty similar, however there is a difference inside
omap_mbox_msg_send function, this function does not write directly the mailbox
register to put the new messages, instead of schedule a workqueue that will the
in charge of doing that job
/* Clear MMU interrupt */
hw_mmu_event_ack(resources.dw_dmmu_base,
HW_MMU_TRANSLATION_FAULT);
So after we ack the MMU fault event the MMU lets DSP to continue executing,
like the mailbox interrupt was not trigger in this moment (because of the
latency of the workque) and if the fault address was being used in the DSP to
write, it can corrupt memory.
The patch send to linux-omap list (DSPBRIDGE:Fix Kernel memory poison
overwritten after DSP_MMUFAULT) is just hidden the problem. Because in case the
MPU had a lot of work the workqueue execution will be delay even more and the
DSP side could reach the limit of the dummy page allocated and corrupt memory,
or write memory in a downward way and corrupt preview memory maybe already map
but not allowed to DSP write the entry page.
Also the way we are using the dummymemory to allow DSP write/read from that is
not correct. Because the offset of the dummymemory and the offset of the DSP
fault address should be match.
These values are taken from nokia logs:
Fault address: 0x21fa0040
dmm_va_addr: 0xdf16d140
mem_physical: 0x9f16d000
The address returned by kmalloc is 0xccbd2080, so we can write I this buffer
from 0xdf16d140 until the end of the page and in physical memory from
0x9f16d140 until the end of the page. And in the DSP we map 0x9f16d000 =
0x21fa and when it tries to write into 0x21fa0040 it is actually writing to
0x9f16d040 corrupting the memory. But in the previous code we did not allowed
to the DSP do anything more after the MMU fault, that why we did not see that
problem before.
The patch DSPBRIDGE: MMU-Fault debugging enhancements already sent to
linux-omap list fix this problem indirectly. Now the way to inform about the
MMUFault is not using a mailbox message, instead of we the GTP8 overflow
interrupt.
omap_dm_timer_set_load_start(timer, 0,
0xfffe);
we set timer counter almost to overflue
/* Wait 80us for
Re: Upstream linux-omap kernel on Nokia N900?
* Roger Quadros roger.quad...@nokia.com [100419 05:06]: Balbi Felipe (Nokia-D/Helsinki) wrote: Hi, On Mon, Apr 19, 2010 at 01:49:15PM +0200, ext Arnaud Ebalard wrote: Nokia N900 is shipped to users with a 2.6.28 omap kernel. Many patches for the hardware and various features have been pushed upstream by Nokia developers and possibly others. Those are now available in current l-o tree. Nonetheless, many drivers and various features are still missing upstream. Simply put, one cannot expect to run a current l-o kernel on the device (and expect to get a GUI and/or make call with the device). tell me about it :-p Thing is that it doesn't really depend only on Nokia to get those parts done. Well, we can get the kernel part done by just cleaning up and porting the 2.6.28 drivers to current mainline, but in case of e.g. SGX we still miss the xorg driver and I don't think that'll be released any time soon. Another problem is that the bootloader believes it can pass all the obsoleted OMAP TAGs to kernel and the 2.6.28 kernel depends on those, maybe that can be worked around. I don't know whether kernel simply drops invalid TAGs or not... Yes kernel simply drops unrecognized TAGs and just prints a warning message. All the the custom tags should be replaced with platform_data. If something is needed for revision detection of the board, there is arm-linux common ATAG_REVISION. However, also Maemo userspace depends on some things set by the custom tags. As this is non-standard, we should not spend much effort on that. Instead we should concentrate on making N900 work with any distro the standard Linux way. So I recommend using kexec patched Maemo kernel, then boot the new mainline kernel from Maemo kernel and mount root directly on the eMMC. As Maemo user space has some dependencies to the partition layout, you need to keep the existing partition layout too. In any case, I ended up resizing the eMMC partitions and using /dev/mmcblk0p2 (mounted as /home in Maemo) as the new root partition. Cheers, Tony -- 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 00/10] dsp-bridge: deh: general cleanups
On 4/15/2010 7:12 AM, Felipe Contreras wrote: On Wed, Mar 24, 2010 at 12:25 AM, Felipe Contreras felipe.contre...@gmail.com wrote: While trying to fix the recovery feature I stumbled many areas of improvments in 'deh' (whatever that means). I quickly tested tesed these changes in Nokia hw, there should be essentially no functional changes. Cheers. Felipe Contreras (10): dsp-bridge: deh: remove obvious comments dsp-bridge: deh: trivial cleanups dsp-bridge: deh: remove unnecessary casts dsp-bridge: deh: improve logging stuff dsp-bridge: deh: report mmu faults as errors dsp-bridge: deh: decrease nesting levels dsp-bridge: deh: fix obvious return codes dsp-bridge: deh: reorganize create() dsp-bridge: deh: fix hdeh_mgr silliness dsp-bridge: deh: fix dummy_va_addr arch/arm/plat-omap/include/dspbridge/wmddeh.h | 24 +- drivers/dsp/bridge/wmd/ue_deh.c | 392 +++-- 2 files changed, 191 insertions(+), 225 deletions(-) I guess these patches don't apply any more. Shall I rebase them? If so... where? As noted in a private mail, your patches were rebased and now pushed to dspbridge. Only this patch was dropped dsp-bridge: deh: trivial cleanups[1] I removed the trivial checkpatch warnings (80 char limit and space after comma) from 2 of them. Omar --- [1] http://marc.info/?l=linux-omapm=126938906708916w=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 1/3] OMAP: PM: update PRM registers for ABB
Hello Mike The functional content of these macros looks fine to me (based on the OMAP3630 TRM Rev C) but please make a few minor style changes: On Fri, 16 Apr 2010, Mike Turquette wrote: PRCM on OMAP devices using the 45nm process support Adaptive Body Bias ldo as well as some new MPU interrupts related to voltage control. These devices currently include OMAP 3630 and 4430. This patch adds these bitfields to the appropriate headers. Also adds register offset for OMAP36XX_CONTROL_VBBLDO_EFUSE_CTRL. Though currently unused it might be used in the future to enable other ABB features such as active RBB and sleep RBB based on silicon characteristics. OMAP3630_VC_BYPASS_ACK_EN, OMAP3630_VC_VP1_ACK_EN OMAP3630_ABB_LDO_TRANXDONE_EN have been added for completeness sake, but these interrupts do not have to be enabled to poll on their corresponding status bits. Signed-off-by: Mike Turquette mturque...@ti.com --- arch/arm/mach-omap2/prm-regbits-34xx.h| 22 ++ arch/arm/mach-omap2/prm.h |6 ++ arch/arm/plat-omap/include/plat/control.h |4 3 files changed, 32 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h b/arch/arm/mach-omap2/prm-regbits-34xx.h index 0066693..58c9765 100644 --- a/arch/arm/mach-omap2/prm-regbits-34xx.h +++ b/arch/arm/mach-omap2/prm-regbits-34xx.h @@ -212,6 +212,9 @@ /* PRM_SYSCONFIG specific bits */ /* PRM_IRQSTATUS_MPU specific bits */ +#define OMAP3630_VC_BYPASS_ACK_ST(1 28) +#define OMAP3630_VC_VP1_ACK_ST (1 27) +#define OMAP3630_ABB_LDO_TRANXDONE_ST(1 26) Please append _MASK to the names of all register bitfield macros. This is not consistent in the current macro include files, but will be soon. #define OMAP3430ES2_SND_PERIPH_DPLL_ST_SHIFT 25 #define OMAP3430ES2_SND_PERIPH_DPLL_ST (1 25) #define OMAP3430_VC_TIMEOUTERR_ST(1 24) @@ -244,6 +247,9 @@ #define OMAP3430_FS_USB_WKUP_ST (1 1) /* PRM_IRQENABLE_MPU specific bits */ +#define OMAP3630_VC_BYPASS_ACK_EN(1 28) +#define OMAP3630_VC_VP1_ACK_EN (1 27) +#define OMAP3630_ABB_LDO_TRANXDONE_EN(1 26) as above #define OMAP3430ES2_SND_PERIPH_DPLL_RECAL_EN_SHIFT 25 #define OMAP3430ES2_SND_PERIPH_DPLL_RECAL_EN (1 25) #define OMAP3430_VC_TIMEOUTERR_EN(1 24) @@ -581,6 +587,22 @@ /* PRM_VP2_STATUS specific bits */ +/* PRM_LDO_ABB_SETUP specific bits */ +#define OMAP3630_SR2_IN_TRANSITION (1 6) as above +#define OMAP3630_SR2_STATUS_SHIFT3 +#define OMAP3630_SR2_STATUS_MASK (3 3) +#define OMAP3630_OPP_CHANGE (1 2) as above +#define OMAP3630_OPP_SEL_SHIFT 0 +#define OMAP3630_OPP_SEL_MASK(3 0) + +/* PRM_LDO_ABB_CTRL specific bits */ +#define OMAP3630_SR2_WTCNT_VALUE_SHIFT 8 +#define OMAP3630_SR2_WTCNT_VALUE_MASK(0xff 8) +#define OMAP3630_SLEEP_RBB_SEL (1 3) +#define OMAP3630_ACTIVE_FBB_SEL (1 2) +#define OMAP3630_ACTIVE_RBB_SEL (1 1) +#define OMAP3630_SR2EN (1 0) as above + /* RM_RSTST_NEON specific bits */ /* PM_WKDEP_NEON specific bits */ diff --git a/arch/arm/mach-omap2/prm.h b/arch/arm/mach-omap2/prm.h index 5fba2aa..2a58847 100644 --- a/arch/arm/mach-omap2/prm.h +++ b/arch/arm/mach-omap2/prm.h @@ -160,6 +160,12 @@ #define OMAP3430_PRM_VP2_VOLTAGE OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, 0x00e0) #define OMAP3_PRM_VP2_STATUS_OFFSET 0x00e4 #define OMAP3430_PRM_VP2_STATUS OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, 0x00e4) +#define OMAP3_PRM_LDO_ABB_SETUP_OFFSET 0X00f0 Please use a lowercase 'x' in the macro value, as per the style of the rest of this file. Also, if this register was only introduced with 3630, then the name of the macro should be 'OMAP3630_PRM_LDO_ABB_SETUP_OFFSET' to indicate this. (Only macro names for registers that are available on all OMAP3-family chips should start with OMAP3_.) +#define OMAP3630_PRM_LDO_ABB_SETUP OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, \ + 0X00f0) +#define OMAP3_PRM_LDO_ABB_CTRL_OFFSET0X00f4 +#define OMAP3630_PRM_LDO_ABB_CTRLOMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, \ + 0X00f4) as above #define OMAP3_PRM_CLKSEL_OFFSET 0x0040 #define OMAP3430_PRM_CLKSEL OMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD,
RE: [PATCH 2/5] DSPBRIDGE: Remove checkpatch errors: 80 char lines
Please let me know the mail thread mentioning this rule has been removed. I
still see it under CodingStyle as the preferred approach.
Anyway, I have am sending a second version of this patch removing this ugly
indenting.
Best regards,
Armando.
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Saturday, April 17, 2010 2:10 PM
To: Uribe de Leon, Armando
Cc: linux-omap@vger.kernel.org; hiroshi.d...@nokia.com;
ameya.pala...@nokia.com; felipe.contre...@nokia.com
Subject: Re: [PATCH 2/5] DSPBRIDGE: Remove checkpatch errors: 80 char lines
On Sat, Apr 17, 2010 at 9:44 PM, Uribe de Leon, Armando x0095...@ti.com wrote:
From 27145cb2f0aa004a9c4159ad094c0ae60f75a3b3 Mon Sep 17 00:00:00 2001
From: Armando Uribe De Leon x0095...@ti.com
Date: Thu, 8 Apr 2010 15:20:09 -0500
Subject: [PATCH 2/5] DSPBRIDGE: Remove checkpatch errors: 80 char lines
This patch removes checkptach errors regarding with lines exceeded 80
chatacters.
Those are warnings, not errors, and I believe this 80 char lines
guideline has been removed.
- if (DSP_FAILED(status)) {
- if (status == DSP_ETIMEOUT) {
- status = (*intf_fxns-pfn_msg_put)
- (hnode-msg_queue_obj, killmsg,
- hnode-utimeout);
- if (DSP_SUCCEEDED(status)) {
- status = sync_wait_on_event
- (hnode-sync_done,
- kill_time_out / 2);
- if (DSP_FAILED(status)) {
- /* Here it goes the
part
- * of the simulation
of
- * the DSP exception
*/
- dev_get_deh_mgr
-
(hnode_mgr-hdev_obj,
- hdeh_mgr);
- if (hdeh_mgr) {
- (*intf_fxns-
-
pfn_deh_notify)
- (hdeh_mgr,
-
DSP_SYSERROR,
-
DSP_EXCEPTIONABORT);
- status =
- DSP_EFAIL;
- }
- } else
- status = DSP_SOK;
- }
- } else
- status = DSP_EFAIL;
- } else /* Convert SYNC status to DSP status */
- status = DSP_SOK;
+ if (status == DSP_ETIMEOUT) {
+ status = (*intf_fxns-pfn_msg_put)
+ (hnode-msg_queue_obj, killmsg,
+ hnode-utimeout);
+ if (DSP_SUCCEEDED(status)) {
+ status = sync_wait_on_event
+ (hnode-sync_done,
+ kill_time_out / 2);
+ if (DSP_FAILED(status)) {
+ /* Here it goes the part
+ * of the simulation of
+ * the DSP exception */
+ dev_get_deh_mgr
+ (hnode_mgr-hdev_obj,
+ hdeh_mgr);
+ if (hdeh_mgr) {
+ (*intf_fxns-
+ pfn_deh_notify)
+ (hdeh_mgr,
+ DSP_SYSERROR,
+ DSP_EXCEPTIONABORT);
+ status = DSP_EFAIL;
+ }
+ } else
+
[PATCH 2/5v2] DSPBRIDGE: Remove checkpatch warnings: 80 char lines
From ff68a8b932f4a542d0ec464a40d9abce93327291 Mon Sep 17 00:00:00 2001
From: Armando Uribe De Leon x0095...@ti.com
Date: Mon, 19 Apr 2010 16:51:00 -0500
Subject: [PATCH 2/5] DSPBRIDGE: Remove checkpatch warnings: 80 char lines
This patch removes checkpatch warning regarding with
lines exceeded 80 characters.
Signed-off-by: Armando Uribe De Leon x0095...@ti.com
---
arch/arm/plat-omap/include/dspbridge/dev.h|2 +-
arch/arm/plat-omap/include/dspbridge/wmdmsg.h |3 +-
drivers/dsp/bridge/pmgr/dev.c |3 +-
drivers/dsp/bridge/rmgr/node.c| 67 ++--
drivers/dsp/bridge/rmgr/pwr.c |8 ++--
drivers/dsp/bridge/wmd/chnl_sm.c |4 +-
6 files changed, 39 insertions(+), 48 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dev.h
b/arch/arm/plat-omap/include/dspbridge/dev.h
index 13b0cad..7224bc7 100644
--- a/arch/arm/plat-omap/include/dspbridge/dev.h
+++ b/arch/arm/plat-omap/include/dspbridge/dev.h
@@ -396,7 +396,7 @@ extern struct dev_object *dev_get_first(void);
* else: *ppIntfFxns is NULL.
*/
extern dsp_status dev_get_intf_fxns(struct dev_object *hdev_obj,
- OUT struct bridge_drv_interface
**ppIntfFxns);
+ OUT struct bridge_drv_interface **ppIntfFxns);
/*
* dev_get_io_mgr
diff --git a/arch/arm/plat-omap/include/dspbridge/wmdmsg.h
b/arch/arm/plat-omap/include/dspbridge/wmdmsg.h
index f8005ea..74d6cbb 100644
--- a/arch/arm/plat-omap/include/dspbridge/wmdmsg.h
+++ b/arch/arm/plat-omap/include/dspbridge/wmdmsg.h
@@ -50,6 +50,7 @@ extern dsp_status bridge_msg_register_notify(struct msg_queue
*msg_queue_obj,
struct dsp_notification
*hnotification);
-extern void bridge_msg_set_queue_id(struct msg_queue *msg_queue_obj, u32
msgq_id);
+extern void bridge_msg_set_queue_id(struct msg_queue *msg_queue_obj,
+ u32 msgq_id);
#endif /* WMDMSG_ */
diff --git a/drivers/dsp/bridge/pmgr/dev.c b/drivers/dsp/bridge/pmgr/dev.c
index 5bc16e9..0005c2b 100644
--- a/drivers/dsp/bridge/pmgr/dev.c
+++ b/drivers/dsp/bridge/pmgr/dev.c
@@ -68,7 +68,8 @@ struct dev_object {
u32 dw_signature; /* Used for object validation. */
struct cfg_devnode *dev_node_obj; /* Platform specific dev id */
struct wmd_dev_context *hwmd_context; /* WMD Context Handle */
- struct bridge_drv_interface wmd_interface; /* Function interface
to WMD. */
+ struct bridge_drv_interface wmd_interface; /* Function interface to
+* WMD. */
struct brd_object *lock_owner; /* Client with exclusive access. */
struct cod_manager *cod_mgr;/* Code manager handle. */
struct chnl_mgr *hchnl_mgr; /* Channel manager. */
diff --git a/drivers/dsp/bridge/rmgr/node.c b/drivers/dsp/bridge/rmgr/node.c
index 32df890..0fe5f0c 100644
--- a/drivers/dsp/bridge/rmgr/node.c
+++ b/drivers/dsp/bridge/rmgr/node.c
@@ -2450,45 +2450,34 @@ dsp_status node_terminate(struct node_object *hnode,
OUT dsp_status *pstatus)
status = (*intf_fxns-pfn_msg_put) (hnode-msg_queue_obj, msg,
hnode-utimeout);
/* FIXME */
- if (DSP_SUCCEEDED(status)) {
- /* Wait on synchronization object that will be
-* posted in the callback on receiving RMS_EXIT
-* message, or by node_delete. Check for valid hnode,
-* in case posted by node_delete(). */
- status = sync_wait_on_event(hnode-sync_done,
- kill_time_out / 2);
- if (DSP_FAILED(status)) {
- if (status == DSP_ETIMEOUT) {
- status = (*intf_fxns-pfn_msg_put)
- (hnode-msg_queue_obj, killmsg,
-hnode-utimeout);
- if (DSP_SUCCEEDED(status)) {
- status = sync_wait_on_event
- (hnode-sync_done,
-kill_time_out / 2);
- if (DSP_FAILED(status)) {
- /* Here it goes the part
-* of the simulation of
-* the DSP exception */
- dev_get_deh_mgr
- (hnode_mgr-hdev_obj,
-
Re: [PATCH 2/5v2] DSPBRIDGE: Remove checkpatch warnings: 80 char lines
On 4/19/2010 5:26 PM, Uribe de Leon, Armando wrote: [...] --- a/drivers/dsp/bridge/rmgr/node.c +++ b/drivers/dsp/bridge/rmgr/node.c @@ -2450,45 +2450,34 @@ dsp_status node_terminate(struct node_object *hnode, OUT dsp_status *pstatus) status = (*intf_fxns-pfn_msg_put) (hnode-msg_queue_obj,msg, hnode-utimeout); /* FIXME */ If you don't mind I'll remove my ambiguous FIXME comment if this patch is pushed... this was placed to fix the indentation. - 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
[PATCH] DSPBRIDGE: Fix declaration and initialization of sync objects.
From 2edd80839e6d3bbe6e92914c3097a6dedca23784 Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Sun, 18 Apr 2010 00:32:01 -0500
Subject: [PATCH] DSPBRIDGE: Fix declaration and initialization of sync objects.
This patch fixes declaration of completions for sync in
drv_interface and also initialize sync-done object in
msg_sm.c
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/rmgr/drv_interface.c |4 ++--
drivers/dsp/bridge/wmd/msg_sm.c |6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index d62e508..1dd635e 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -98,8 +98,8 @@ static int tc_wordswapon; /* Default value is always
false */
static atomic_t bridge_cref; /* number of bridge open handles */
static struct workqueue_struct *bridge_rec_queue;
static struct work_struct bridge_recovery_work;
-static DECLARE_COMPLETION_ONSTACK(bridge_comp);
-static DECLARE_COMPLETION_ONSTACK(bridge_open_comp);
+static DECLARE_COMPLETION(bridge_comp);
+static DECLARE_COMPLETION(bridge_open_comp);
static bool recover;
#endif
diff --git a/drivers/dsp/bridge/wmd/msg_sm.c b/drivers/dsp/bridge/wmd/msg_sm.c
index 19e3cee..6f00071 100644
--- a/drivers/dsp/bridge/wmd/msg_sm.c
+++ b/drivers/dsp/bridge/wmd/msg_sm.c
@@ -185,8 +185,8 @@ dsp_status bridge_msg_create_queue(struct msg_mgr *hmsg_mgr,
if (DSP_SUCCEEDED(status)) {
msg_q-sync_done = kzalloc(sizeof(struct sync_object),
GFP_KERNEL);
- if (msg_q-sync_event)
- sync_init_event(msg_q-sync_event);
+ if (msg_q-sync_done)
+ sync_init_event(msg_q-sync_done);
else
status = DSP_EMEMORY;
}
@@ -194,7 +194,7 @@ dsp_status bridge_msg_create_queue(struct msg_mgr *hmsg_mgr,
if (DSP_SUCCEEDED(status)) {
msg_q-sync_done_ack = kzalloc(sizeof(struct sync_object),
GFP_KERNEL);
- if (msg_q-sync_event)
+ if (msg_q-sync_done_ack)
sync_init_event(msg_q-sync_done_ack);
else
status = DSP_EMEMORY;
--
1.6.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
Re: [PATCH] DSPBRIDGE: Fix declaration and initialization of sync objects.
Guzman Lugo, Fernando wrote:
From 2edd80839e6d3bbe6e92914c3097a6dedca23784 Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Sun, 18 Apr 2010 00:32:01 -0500
Subject: [PATCH] DSPBRIDGE: Fix declaration and initialization of sync objects.
This patch fixes declaration of completions for sync in
drv_interface and also initialize sync-done object in
msg_sm.c
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/rmgr/drv_interface.c |4 ++--
drivers/dsp/bridge/wmd/msg_sm.c |6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index d62e508..1dd635e 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -98,8 +98,8 @@ static int tc_wordswapon; /* Default value is always
false */
static atomic_t bridge_cref; /* number of bridge open handles */
static struct workqueue_struct *bridge_rec_queue;
static struct work_struct bridge_recovery_work;
-static DECLARE_COMPLETION_ONSTACK(bridge_comp);
-static DECLARE_COMPLETION_ONSTACK(bridge_open_comp);
+static DECLARE_COMPLETION(bridge_comp);
+static DECLARE_COMPLETION(bridge_open_comp);
static bool recover;
#endif
diff --git a/drivers/dsp/bridge/wmd/msg_sm.c b/drivers/dsp/bridge/wmd/msg_sm.c
index 19e3cee..6f00071 100644
--- a/drivers/dsp/bridge/wmd/msg_sm.c
+++ b/drivers/dsp/bridge/wmd/msg_sm.c
@@ -185,8 +185,8 @@ dsp_status bridge_msg_create_queue(struct msg_mgr *hmsg_mgr,
if (DSP_SUCCEEDED(status)) {
msg_q-sync_done = kzalloc(sizeof(struct sync_object),
GFP_KERNEL);
- if (msg_q-sync_event)
- sync_init_event(msg_q-sync_event);
+ if (msg_q-sync_done)
+ sync_init_event(msg_q-sync_done);
else
status = DSP_EMEMORY;
}
@@ -194,7 +194,7 @@ dsp_status bridge_msg_create_queue(struct msg_mgr *hmsg_mgr,
if (DSP_SUCCEEDED(status)) {
msg_q-sync_done_ack = kzalloc(sizeof(struct sync_object),
GFP_KERNEL);
- if (msg_q-sync_event)
+ if (msg_q-sync_done_ack)
sync_init_event(msg_q-sync_done_ack);
else
status = DSP_EMEMORY;
Acked-by: Deepak Chitriki deepak.chitr...@ti.com
Deepak
--
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] OMAP2/3: I2C: Errata ID i207: Clear wrong RDR interrupt
On Thu, Apr 15, 2010 at 03:08:16PM +0300, Aaro Koskinen wrote:
Hi,
Manjunatha GK wrote:
Under certain rare conditions, I2C_STAT[13].RDR bit may be set
and the corresponding interrupt fire, even there is no data in
the receive FIFO, or the I2C data transfer is still ongoing.
These spurious RDR events must be ignored by the software.
This patch handles and ignores RDR spurious interrupts.
The below sequence is required in interrupt handler for
handling this errata:
1. If RDR is set to 1, clear RDR
2. Read I2C status register and check for BusBusy bit. If BusBusy
bit is set, skip remaining steps.
3. If BusBusy bit is not set, perform read operation on I2C status
register.
4. If RDR is set, clear the same. Check RDR again and clear if it sets
RDR bit again.
5. Perform I2C Data Read operation N number of times(where N is value
read from the register BUFSTAT-RXSTAT bit fields).
Note : This errata is applicable for OMAP2 and OMAP3 platforms only.
It is not applicable for OMAP4.
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: linux-...@vger.kernel.org
Cc: ben-li...@fluff.org
Cc: Kalliguddi, Hema hem...@ti.com
Cc: Nishanth Menon n...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ae6f5c1..d1648da 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -733,6 +733,34 @@ complete:
}
if (stat (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
u8 num_bytes = 1;
+
+ /*
+* I2C Errata(Errata Nos. OMAP2: 1.67, OMAP3: 1.8)
+* Not applicable for OMAP4.
+* Under certain rare conditions, RDR could be set again
+* when the bus is busy, then ignore the interrupt and
+* clear the interrupt.
+*/
+ if ((stat OMAP_I2C_STAT_RDR) !cpu_is_omap44xx()) {
+ /* Step 1: If RDR is set, clear it */
+ omap_i2c_ack_stat(dev, stat
OMAP_I2C_STAT_RDR);
You know the bit is set, so just: omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
+
+ /* Step 2: */
+ if(!(omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)
+OMAP_I2C_STAT_BB)) {
+ /* Step 3: */
+ if(omap_i2c_read_reg(dev,
+ OMAP_I2C_STAT_REG)
+OMAP_I2C_STAT_RDR) {
+ omap_i2c_ack_stat(dev, stat
+OMAP_I2C_STAT_RDR);
Same here.
+ dev_err(dev-dev,
+ I2C : RDR when the bus is
busy.\n);
Remove the I2C : from the log, it's redundant.
I'd agree, we're already prefixing this with the device name and
driver name from the dev_err() call. No need to add any more.
If it is in use elsewhere in the file, I'd prefer to see it removed
from the other points.
+ continue;
+ }
+
+ }
+ }
if (dev-fifo_size) {
if (stat OMAP_I2C_STAT_RRDY)
num_bytes = dev-fifo_size;
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben (b...@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
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 v4] OMAP2/3: I2C: Errata ID i207: Clear wrong RDR interrupt
On Mon, Apr 19, 2010 at 12:44:22PM +0530, Manjunatha GK wrote:
Under certain rare conditions, I2C_STAT[13].RDR bit may be set
and the corresponding interrupt fire, even there is no data in
the receive FIFO, or the I2C data transfer is still ongoing.
These spurious RDR events must be ignored by the software.
This patch handles and ignores RDR spurious interrupts.
The below sequence is required in interrupt handler for
handling this errata:
1. If RDR is set to 1, clear RDR
2. Read I2C status register and check for BusBusy bit. If BusBusy
bit is set, skip remaining steps.
3. If BusBusy bit is not set, perform read operation on I2C status
register.
4. If RDR is set, clear the same. Check RDR again and clear if it sets
RDR bit again.
5. Perform I2C Data Read operation N number of times(where N is value
read from the register BUFSTAT-RXSTAT bit fields).
Note : This errata is applicable for OMAP2 and OMAP3 platforms only.
It is not applicable for OMAP4.
If people can give me a yes/no before the end of play tomorrow (ie,
2300GMT) then I will get this applied to for-linus/i2c and send it
for -rc.
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: linux-...@vger.kernel.org
Cc: ben-li...@fluff.org
Cc: Kalliguddi, Hema hem...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
---
drivers/i2c/busses/i2c-omap.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f2019d2..8309eac 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -796,6 +796,34 @@ complete:
}
if (stat (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
u8 num_bytes = 1;
+
+ /*
+ * I2C Errata(Errata Nos. OMAP2: 1.67, OMAP3: 1.8)
+ * Not applicable for OMAP4.
+ * Under certain rare conditions, RDR could be set again
+ * when the bus is busy, then ignore the interrupt and
+ * clear the interrupt.
+ */
+ if ((stat OMAP_I2C_STAT_RDR) !cpu_is_omap44xx()) {
+ /* Step 1: If RDR is set, clear it */
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
+
+ /* Step 2: */
+ if(!(omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)
+ OMAP_I2C_STAT_BB)) {
+ /* Step 3: */
+ if(omap_i2c_read_reg(dev,
+ OMAP_I2C_STAT_REG)
+ OMAP_I2C_STAT_RDR) {
+ omap_i2c_ack_stat(dev,
+ OMAP_I2C_STAT_RDR);
+ dev_err(dev-dev,
+ RDR when the bus is busy.\n);
+ continue;
+ }
+
+ }
+ }
if (dev-fifo_size) {
if (stat OMAP_I2C_STAT_RRDY)
num_bytes = dev-fifo_size;
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben (b...@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
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 2/3] OMAP3630: PM: implement Foward Body-Bias for OPP1G
Hi Mike,
some comments.
On Fri, 16 Apr 2010, Mike Turquette wrote:
Introduces voltscale_adaptive_body_bias function to voltage.c.
voltscale_adaptive_body_bias is called by omap_voltage_scale after a
voltage transition has occured. Currently voltscale_adaptive_body_bias
only implements Forward Body-Bias (FBB) for OMAP3630 when MPU runs at
1GHz or higher. In the future Reverse Body-Bias might be included.
FBB is an Adaptive Body-Bias technique to boost performance for weak
process devices at high OPPs. This results in voltage boost on the VDD1
PMOS back gates when running at maximum OPP. Current recommendations
are to enable FBB on all 3630 regardless of silicon characteristics and
EFUSE values.
ABB applies to all OMAP silicon based on 45nm process, which includes
OMAP4. OMAP4 recommendations for ABB are not complete and will be added
to voltscale_adaptive_body_bias in the future.
Great work on the patch changelog and kerneldoc on the functions - I wish
everyone wrote patch changelogs like this.
Signed-off-by: Mike Turquette mturque...@ti.com
---
arch/arm/mach-omap2/voltage.c | 129
-
1 files changed, 127 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index c2c8192..98d8bb3 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
Please move this code to a separate file - would suggest mach-omap2/abb.c.
The rationale here is that many OMAP2+ platforms won't need this code, and
we can skip compiling it in those cases.
@@ -37,6 +37,11 @@
#define VP_IDLE_TIMEOUT 200
#define VP_TRANXDONE_TIMEOUT 300
Please add a bit of documentation here to indicate what unit
ABB_MAX_SETTLING_TIME is in, and where this number comes from.
+#define ABB_MAX_SETTLING_TIME30
Please add some documentation here to to note that these are the
PRM_LDO_ABB_SETUP.OPP_SEL register bitfield values.
+#define ABB_FAST_OPP 1
+#define ABB_NOMINAL_OPP 2
+#define ABB_SLOW_OPP 3
+
/**
* OMAP3 Voltage controller SR parameters. TODO: Pass this info as part of
* board data or PMIC data
@@ -635,6 +640,118 @@ static int vp_forceupdate_scale_voltage(u32 vdd,
unsigned long target_volt,
}
/**
+ * voltscale_adaptive_body_bias - controls ABB ldo during voltage scaling
+ * @target_volt: target voltage determines if ABB ldo is active or bypassed
+ *
+ * Adaptive Body-Bias is a technique in all OMAP silicon that uses the 45nm
+ * process. ABB can boost voltage in high OPPs for silicon with weak
+ * characteristics (forward Body-Bias) as well as lower voltage in low OPPs
+ * for silicon with strong characteristics (Reverse Body-Bias).
+ *
+ * Only Foward Body-Bias for operating at high OPPs is implemented below, per
+ * recommendations from silicon team.
+ * Reverse Body-Bias for saving power in active cases and sleep cases is not
+ * yet implemented.
+ * OMAP4 hardward also supports ABB ldo, but no recommendations have been
made
+ * to implement it yet.
Please consider adding a short section describing the function return
values (per Documentation/kernel-doc-nano-HOWTO.txt).
+ */
+int voltscale_adaptive_body_bias(unsigned long target_volt)
Since this code appears to be OMAP36xx-specific, please note that in the
function name. Also this is VDD1-specific, so might be worth noting that
there as well.
It's probably worth splitting this single function up into init(),
enable(), disable(), and probably a _transition_poll() function.
+{
+ u32 sr2en_enabled;
+ int timeout;
+ int sr2_wtcnt_value;
+
+ /* calculate SR2_WTCNT_VALUE settling time */
+ sr2_wtcnt_value = (ABB_MAX_SETTLING_TIME *
+ (clk_get_rate(sys_ck) / 100) / 8);
+
+ /* has SR2EN been enabled previously? */
+ sr2en_enabled = (prm_read_mod_reg(OMAP3430_GR_MOD,
+ OMAP3_PRM_LDO_ABB_CTRL_OFFSET)
+ OMAP3630_SR2EN);
The above code should be separated out into a function that is run once at
init. (and then perhaps once every time these registers are changed -
will the ROM code touch these when entering or exiting off-mode?) No point
always executing this stuff for every OPP change if it only needs to be
done infrequently. PRM accesses, especially reads, slow the ARM down, so
it's worthwhile avoiding them.
+
+ /* select fast, nominal or slow OPP for ABB ldo */
+ /* FIXME: include OMAP4 once recommendations are complete */
+ if (cpu_is_omap3630() (target_volt = 135)) {
Please integrate this type of information into the OPP table or
somewhere similar, since this is SoC-specific configuration data.
+ /* program for fast opp - enable FBB */
+ prm_rmw_mod_reg_bits(OMAP3630_OPP_SEL_MASK,
+ (ABB_FAST_OPP OMAP3630_OPP_SEL_SHIFT),
+
