Re: [PATCH v2 03/20] mmc: support embedded data field in mmc_host
Hi Vitaly,
On Wed, Jul 28, 2010 at 10:47 PM, Vitaly Wool vitalyw...@gmail.com wrote:
On Wed, Jul 21, 2010 at 7:33 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Add support to set/get mmc_host private embedded
data.
This is needed to allow software to dynamically
create (and remove) SDIO functions which represents
embedded SDIO devices.
snip
@@ -209,6 +209,8 @@ struct mmc_host {
struct led_trigger *led; /* activity led */
#endif
+ void *embedded_data;
+
To my understanding, this data doesn't belong to mmc_host. It's not a
host data at all. E. g. imagine a GPIO IRQ for some SDIO chip -- it's
totally unrelated to host.
I think a cleaner way would be to introduce something similar to what
we have for SPI, e. g. struct sdio_board_info. This board info will
contain platform-specific stuff and vendor id/chip id for each onboard
SDIO device. Then the SDIO core will pick up the appropriate data
basing on vendor id/chip id.
Can you please elaborate some more about your proposal (specifically
where does this sdio_board_info get set and how do function drivers
access it) ?
If I understand you correctly, you suggest to have a global,
board-specific table of sdio_board_info structures, which would be
accessible to the SDIO core (through the host driver ?). When a new
SDIO device is found the core would search this table for the
appropriate sdio_board_info struct and make it accessible to the SDIO
function driver ?
Thanks,
Ohad.
~Vitaly
--
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] twl4030 reboot workaround
On Wed, Jul 28, 2010 at 12:18:11PM +0200, De-Schrijver Peter (Nokia-MS/Helsinki) wrote: On Wed, Jul 28, 2010 at 11:41:32AM +0200, Rapeli Mikko (EXT-Ixonos/Oulu) wrote: From: Mikko Rapeli ext-mikko.rap...@nokia.com Original patch: http://marc.info/?l=linux-omapm=126522625032441w=2 Removes TWL4030 sleep script prior to rebooting, only on OMAP3. This is necessary since DPLL3 reset causes SYS_OFFMODE pin to go low, resulting in the sleep script being executed on TWL4030. This usually results in VDD1 VDD2 voltage collapse while ROM code is executing, followed by an MPU Watch Dog reset or worse, an irrecoverable hang. Original patch resulted in a crash due to sleeping i2c calls late in the reboot sequence. Here's how to trigger the crash: # cat /dev/urandom /foo sync(); reboot(LINUX_REBOOT_CMD_RESTART2); Kernel trace from 2.6.32: Unable to handle kernel NULL pointer dereference at virtual address pgd = c0004000 [] *pgd= Internal error: Oops: 805 [#2] PREEMPT ... [c00b3210] (exit_mmap+0x1d4/0x1f8) from [c006069c] (mmput+0x34/0x110) [c006069c] (mmput+0x34/0x110) from [c0064a90] (exit_mm+0x140/0x180) [c0064a90] (exit_mm+0x140/0x180) from [c00668ec] (do_exit+0x5d8/0x6ac) [c00668ec] (do_exit+0x5d8/0x6ac) from [c0035858] (die+0x2d4/0x2e0) [c0035858] (die+0x2d4/0x2e0) from [c0035904] (baddataabort+0x0/0x50) [c0035904] (baddataabort+0x0/0x50) from [c0274ff4] (i2c_transfer+0xec/0x104) [c0274ff4] (i2c_transfer+0xec/0x104) from [0001] (0x1) Fix is to move reboot preparations into a reboot notifier. And what if we get an OMAP3 watchdog reset ? In this case there is no software to remove the script... Well, I don't know. We have seen boot and reboot failures and this remove script patch set has helped to reduce those failures. -Mikko -- 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] twl4030 reboot workaround
On Wed, Jul 28, 2010 at 12:07:32PM +0200, ext Gopinath, Thara wrote: Minor nit. Insert a blank line. Thanks, will send a new version. -Mikko -- 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] twl4030 reboot workaround
On Wed, Jul 28, 2010 at 05:47:36PM +0200, ext Mike Turquette wrote: This method is much better than the method I proposed before. Taking into account the comments from others, ACK. Thanks, I'll send an updated version with that one new line. Do you have an idea how the watchdog reset case should be handled? Can the boot loader do something about this or must the script removal be done before reboot? -Mikko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] twl4030 reboot workaround
From: Mikko Rapeli ext-mikko.rap...@nokia.com
Original patch: http://marc.info/?l=linux-omapm=126522625032441w=2
Removes TWL4030 sleep script prior to rebooting, only on OMAP3. This is
necessary since DPLL3 reset causes SYS_OFFMODE pin to go low, resulting
in the sleep script being executed on TWL4030. This usually results in
VDD1 VDD2 voltage collapse while ROM code is executing, followed by an
MPU Watch Dog reset or worse, an irrecoverable hang.
Original patch resulted in a crash due to sleeping i2c calls late in the
reboot sequence. Here's how to trigger the crash:
# cat /dev/urandom /foo
sync();
reboot(LINUX_REBOOT_CMD_RESTART2);
Kernel trace from 2.6.32:
Unable to handle kernel NULL pointer dereference at virtual address
pgd = c0004000
[] *pgd=
Internal error: Oops: 805 [#2] PREEMPT
...
[c00b3210] (exit_mmap+0x1d4/0x1f8) from [c006069c] (mmput+0x34/0x110)
[c006069c] (mmput+0x34/0x110) from [c0064a90] (exit_mm+0x140/0x180)
[c0064a90] (exit_mm+0x140/0x180) from [c00668ec] (do_exit+0x5d8/0x6ac)
[c00668ec] (do_exit+0x5d8/0x6ac) from [c0035858] (die+0x2d4/0x2e0)
[c0035858] (die+0x2d4/0x2e0) from [c0035904] (baddataabort+0x0/0x50)
[c0035904] (baddataabort+0x0/0x50) from [c0274ff4] (i2c_transfer+0xec/0x104)
[c0274ff4] (i2c_transfer+0xec/0x104) from [0001] (0x1)
Fix is to move reboot preparations into a reboot notifier.
Signed-off-by: Mikko Rapeli ext-mikko.rap...@nokia.com
Acked-by: Mike Turquette mturque...@ti.com
---
v2: added a new line after variable declarations
v1: http://marc.info/?l=linux-omapm=128031011323970w=2
drivers/mfd/twl4030-power.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 7efa878..5c6da1e 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -28,6 +28,7 @@
#include linux/pm.h
#include linux/i2c/twl.h
#include linux/platform_device.h
+#include linux/reboot.h
#include asm/mach-types.h
@@ -127,6 +128,30 @@ static u8 res_config_addrs[] = {
[RES_Main_Ref] = 0x94,
};
+/*
+ * PRCM on OMAP3 will drive SYS_OFFMODE low during DPLL3 warm reset.
+ * This causes Gaia sleep script to execute, usually killing VDD1 and
+ * VDD2 while code is running. WA is to disable the sleep script
+ * before warm reset.
+ */
+static int twl4030_prepare_for_reboot(struct notifier_block *this,
+ unsigned long cmd, void *p)
+{
+ int err;
+
+ err = twl4030_remove_script(TWL4030_SLEEP_SCRIPT);
+ if (err)
+ pr_err(TWL4030: error trying to disable sleep script!\n);
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block twl4030_reboot_notifier = {
+ .notifier_call = twl4030_prepare_for_reboot,
+ .next = NULL,
+ .priority = 0
+};
+
static int __init twl4030_write_script_byte(u8 address, u8 byte)
{
int err;
@@ -549,6 +574,11 @@ void __init twl4030_power_init(struct twl4030_power_data
*twl4030_scripts)
err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0, R_PROTECT_KEY);
if (err)
pr_err(TWL4030 Unable to relock registers\n);
+
+ err = register_reboot_notifier(twl4030_reboot_notifier);
+ if (err)
+ pr_err(TWL4030 Failed to register reboot notifier\n);
+
return;
unlock:
--
1.5.6.5
--
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/1] DSPBRIDGE: cache operation against kernel address instead of user's
Hi Felipe,
On Sun, 25 Jul 2010 22:10:32 +0200
ext Felipe Contreras felipe.contre...@gmail.com wrote:
Hi,
While investigating a bug in maemo[1] I found that this patch triggers
it, I think I found the reason.
It probably doesn't matter for upstream anymore.
On Fri, Nov 6, 2009 at 3:34 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
@@ -690,14 +732,19 @@ static int memory_check_vma(unsigned long start, u32
len)
if (end = start)
return -EINVAL;
- down_read(current-mm-mmap_sem);
-
while ((vma = find_vma(current-mm, start)) != NULL) {
+ ssize_t size;
- if (vma-vm_start start) {
- err = -EINVAL;
+ if (vma-vm_flags (VM_IO | VM_PFNMAP))
+ return -EINVAL;
+
+ if (vma-vm_start start)
+ return -EINVAL;
+
+ size = min_t(ssize_t, vma-vm_end - start, len);
This 'len' is the total length, which is not what we want; in each
iteration the length should be decreased so that it's always the
remaining length. Right?
len -= size;
Great finding and I'm so sorry for this bug...
+ err = memory_sync_page(vma, start, size, ftype);
+ if (err)
break;
- }
if (end = vma-vm_end)
break;
[1] https://bugs.maemo.org/show_bug.cgi?id=10813
--
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 5/5 v4] omap2/3/4: serial: errata i202: fix for MDR1 access
Hi,
On 06/23/2010 07:17 AM, ext Nishanth Menon wrote:
From: Deepak Kdeepa...@ti.com
Original patch:
http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=42d4a342c009bd9727c100abc8a4bc3063c22f0c
Errata i202 (OMAP3430 - 1.12, OMAP3630 - 1.6):
UART module MDR1 register access can cause a dummy underrun
condition which could result in a freeze in the case of IrDA
communication or if used as UART, corrupted data.
Workaround is as follows for everytime MDR1 register is changed:
* setup all required UART registers
* setup MDR1.MODE_SELECT bit field
* Wait 5 L4 clk cycles + 5 UART functional clock cycles
* Clear the Tx and RX fifo using FCR register
Note: The following step is not done as I am assuming it is not
needed due to reconfiguration being done and there is no halted
operation perse.
* Read if required, the RESUME register to resume halted operation
Cc: Govindraj Rgovindraj.r...@ti.com
Cc: Kevin Hilmankhil...@deeprootsystems.com
Cc: Tero Kristotero.kri...@nokia.com
Cc: Tony Lindgrent...@atomide.com
Signed-off-by: Deepak Kdeepa...@ti.com
Signed-off-by: Nishanth Menonn...@ti.com
---
arch/arm/mach-omap2/serial.c | 52 +++--
1 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 009b63f..566e991 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -38,6 +38,7 @@
#define UART_OMAP_WER 0x17/* Wake-up enable register */
#define UART_ERRATA_FIFO_FULL_ABORT (0x1 0)
+#define UART_ERRATA_i202_MDR1_ACCESS (0x1 1)
/*
* NOTE: By default the serial timeout is disabled as it causes lost
characters
@@ -184,6 +185,42 @@ static inline void __init omap_uart_reset(struct
omap_uart_state *uart)
#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3)
+/*
+ * Work Around for Errata i202 (3430 - 1.12, 3630 - 1.6)
+ * The access to uart register after MDR1 Access
+ * causes UART to corrupt data.
+ *
+ * Need a delay =
+ * 5 L4 clock cycles + 5 UART functional clock cycle (@48MHz = ~0.2uS)
+ * give 10 times as much
+ */
+static void omap_uart_mdr1_errataset(struct omap_uart_state *uart, u8 mdr1_val,
+ u8 fcr_val)
+{
+ struct plat_serial8250_port *p = uart-p;
+ u8 timeout = 255;
+
+ serial_write_reg(p, UART_OMAP_MDR1, mdr1_val);
+ udelay(2);
+ serial_write_reg(p, UART_FCR, fcr_val | UART_FCR_CLEAR_XMIT |
+ UART_FCR_CLEAR_RCVR);
+ /*
+* Wait for FIFO to empty: when empty, RX_FIFO_E bit is 0 and
+* TX_FIFO_E bit is 1.
+*/
+ while (UART_LSR_THRE != (serial_read_reg(p, UART_LSR)
+ (UART_LSR_THRE | UART_LSR_DR))) {
+ timeout--;
+ if (!timeout) {
+ /* Should *never* happen. we warn and carry on */
+ dev_crit(uart-pdev.dev, Errata i202: timedout %x\n,
+ serial_read_reg(p, UART_LSR));
+ break;
+ }
+ udelay(1);
+ }
+}
+
static void omap_uart_save_context(struct omap_uart_state *uart)
{
u16 lcr = 0;
@@ -221,7 +258,10 @@ static void omap_uart_restore_context(struct
omap_uart_state *uart)
uart-context_valid = 0;
- serial_write_reg(p, UART_OMAP_MDR1, 0x7);
+ if (uart-errata UART_ERRATA_i202_MDR1_ACCESS)
+ omap_uart_mdr1_errataset(uart, 0x07, 0xA0);
If errata you set both MDR1 and FCR
+ else
+ serial_write_reg(p, UART_OMAP_MDR1, 0x7);
If not errata you set only MDR1
serial_write_reg(p, UART_LCR, 0xBF); /* Config B mode */
efr = serial_read_reg(p, UART_EFR);
serial_write_reg(p, UART_EFR, UART_EFR_ECB);
@@ -234,14 +274,16 @@ static void omap_uart_restore_context(struct
omap_uart_state *uart)
serial_write_reg(p, UART_IER, uart-ier);
serial_write_reg(p, UART_LCR, 0x80);
serial_write_reg(p, UART_MCR, uart-mcr);
- serial_write_reg(p, UART_FCR, 0xA1);
If not errata, FCR is never set.
serial_write_reg(p, UART_LCR, 0xBF); /* Config B mode */
serial_write_reg(p, UART_EFR, efr);
serial_write_reg(p, UART_LCR, UART_LCR_WLEN8);
serial_write_reg(p, UART_OMAP_SCR, uart-scr);
serial_write_reg(p, UART_OMAP_WER, uart-wer);
serial_write_reg(p, UART_OMAP_SYSC, uart-sysc);
- serial_write_reg(p, UART_OMAP_MDR1, 0x00); /* UART 16x mode */
+ if (uart-errata UART_ERRATA_i202_MDR1_ACCESS)
+ omap_uart_mdr1_errataset(uart, 0x00, 0xA1);
+ else
+ serial_write_reg(p, UART_OMAP_MDR1, 0x00); /* UART 16x mode */
same here
FCR is never touched if no errata condition?
Is this going to be a problem for non erroneous devices?
}
#else
static inline void omap_uart_save_context(struct omap_uart_state *uart) {}
@@ -769,6 +811,10 @@ void __init omap_serial_init_port(int port)
[PATCH 00/11] OMAP: DMA: HWMOD and DMA as platform driver
This patch series is refined version of earlier patches posted at: http://www.spinics.net/lists/linux-omap/index.html#33393 These changes are based on comments received during internal discussions which has changes(compared to previous version) such as: - Code optimization - Patches are rearranged in more meaningful way so that git bisect works at any intermediate patch in the series. - Build tested for all omap's(OMAP1 and OMAP2PLUS) - Boot tested for OMAP3 and OMAP4(appreciate if some one tests on OMAP1/2) - Applicalbe tests are executed on OMAP3 and OMAP4 boards - Rebased and added descriptor autoloading feature(only for omap3630 and omap4) This patch series applies on top of: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git Branch: pm-wip/hwmods-omap4 commit f1c79ab452ed9cf7b5ff6488335c1ddf15d5c92a Author: Benoit Cousson b-cous...@ti.com Date: Wed May 12 17:54:37 2010 +0200 OMAP4: hwmod: Enable omap_hwmod build for OMAP4 Patch series summary: = Manjunatha GK (10): OMAP: DMA: Introduce DMA device attributes OMAP2420: DMA: HWMOD: Add hwmod data structures OMAP2430: DMA: HWMOD: Add hwmod data structures OMAP3: DMA: HWMOD: Add hwmod data structures OMAP4: DMA: HWMOD: update OMAP4 data base OMAP1: DMA: Introduce DMA driver as platform driver OMAP2/3/4: DMA: HWMOD: Device registration OMAP: DMA: Convert DMA library into DMA platform Driver OMAP: DMA: Implement generic errata handling OMAP: DMA: Use DMA device attributes Venkatraman S (1): sDMA: descriptor autoloading feature arch/arm/mach-omap1/Makefile |2 +- arch/arm/mach-omap1/dma.c | 446 arch/arm/mach-omap1/include/mach/dma.h | 148 +++ arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/dma.c | 1380 + arch/arm/mach-omap2/include/mach/dma.h | 378 +++ arch/arm/mach-omap2/omap_hwmod_2420_data.c | 89 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 89 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 89 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 19 +- arch/arm/plat-omap/dma.c | 1515 +++- arch/arm/plat-omap/include/plat/dma.h | 222 + 12 files changed, 2850 insertions(+), 1529 deletions(-) create mode 100644 arch/arm/mach-omap1/dma.c create mode 100644 arch/arm/mach-omap1/include/mach/dma.h create mode 100644 arch/arm/mach-omap2/dma.c create mode 100644 arch/arm/mach-omap2/include/mach/dma.h -- 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 03/11] OMAP2430: DMA: HWMOD: Add hwmod data structures
This patch adds OMAP2430 DMA hwmod structures.
Signed-off-by: Manjunatha GK manj...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 89
1 files changed, 89 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index c0f3311..5463199 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -32,6 +32,7 @@
static struct omap_hwmod omap2430_mpu_hwmod;
static struct omap_hwmod omap2430_l3_main_hwmod;
static struct omap_hwmod omap2430_l4_core_hwmod;
+static struct omap_hwmod omap2430_dma_system_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2430_l3_main__l4_core = {
@@ -138,11 +139,99 @@ static struct omap_hwmod omap2430_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
+/* dma_system */
+static struct omap_hwmod_class_sysconfig omap2430_dma_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x002c,
+ .syss_offs = 0x0028,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_dma_hwmod_class = {
+ .name = dma,
+ .sysc = omap2430_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+ .dma_dev_attr = DMA_LINKED_LCH | GLOBAL_PRIORITY |
+ IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORIY,
+ .dma_lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT,
+};
+
+static struct omap_hwmod_irq_info omap2430_dma_system_irqs[] = {
+ { .name = dma_0, .irq = INT_24XX_SDMA_IRQ0 },
+ { .name = dma_1, .irq = INT_24XX_SDMA_IRQ1 },
+ { .name = dma_2, .irq = INT_24XX_SDMA_IRQ2 },
+ { .name = dma_3, .irq = INT_24XX_SDMA_IRQ3 },
+};
+
+static struct omap_hwmod_addr_space omap2430_dma_system_addrs[] = {
+ {
+ .pa_start = 0x48056000,
+ .pa_end = 0x4a0560ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap2430_dma_system__l3 = {
+ .master = omap2430_dma_system_hwmod,
+ .slave = omap2430_l3_main_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap2430_dma_system_masters[] = {
+ omap2430_dma_system__l3,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap2430_l4_core__dma_system = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_dma_system_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap2430_dma_system_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_dma_system_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap2430_dma_system_slaves[] = {
+ omap2430_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap2430_dma_system_hwmod = {
+ .name = dma,
+ .class = omap2430_dma_hwmod_class,
+ .mpu_irqs = omap2430_dma_system_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2430_dma_system_irqs),
+ .main_clk = l3_div_ck,
+ .prcm = {
+ .omap2 = {
+ /*.clkctrl_reg = NULL, */
+ },
+ },
+ .slaves = omap2430_dma_system_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2430_dma_system_slaves),
+ .masters= omap2430_dma_system_masters,
+ .masters_cnt= ARRAY_SIZE(omap2430_dma_system_masters),
+ .dev_attr = dma_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+};
+
static __initdata struct omap_hwmod *omap2430_hwmods[] = {
omap2430_l3_main_hwmod,
omap2430_l4_core_hwmod,
omap2430_l4_wkup_hwmod,
omap2430_mpu_hwmod,
+ omap2430_dma_system_hwmod,
NULL,
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/11] OMAP2420: DMA: HWMOD: Add hwmod data structures
This patch adds OMAP2420 DMA hwmod structures.
Signed-off-by: Manjunatha GK manj...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 89
1 files changed, 89 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 8c90b27..83370e2 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -32,6 +32,7 @@
static struct omap_hwmod omap2420_mpu_hwmod;
static struct omap_hwmod omap2420_l3_main_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
+static struct omap_hwmod omap2420_dma_system_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -136,11 +137,99 @@ static struct omap_hwmod omap2420_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
};
+/* system dma */
+static struct omap_hwmod_class_sysconfig omap2420_dma_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x002c,
+ .syss_offs = 0x0028,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_dma_hwmod_class = {
+ .name = dma,
+ .sysc = omap2420_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+ .dma_dev_attr = DMA_LINKED_LCH | GLOBAL_PRIORITY |
+ IS_CSSA_32 | IS_CDSA_32,
+ .dma_lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT,
+};
+
+static struct omap_hwmod_irq_info omap2420_dma_system_irqs[] = {
+ { .name = dma_0, .irq = INT_24XX_SDMA_IRQ0 },
+ { .name = dma_1, .irq = INT_24XX_SDMA_IRQ1 },
+ { .name = dma_2, .irq = INT_24XX_SDMA_IRQ2 },
+ { .name = dma_3, .irq = INT_24XX_SDMA_IRQ3 },
+};
+
+static struct omap_hwmod_addr_space omap2420_dma_system_addrs[] = {
+ {
+ .pa_start = 0x48056000,
+ .pa_end = 0x4a0560ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap2420_dma_system__l3 = {
+ .master = omap2420_dma_system_hwmod,
+ .slave = omap2420_l3_main_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap2420_dma_system_masters[] = {
+ omap2420_dma_system__l3,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap2420_l4_core__dma_system = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_dma_system_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap2420_dma_system_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_dma_system_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap2420_dma_system_slaves[] = {
+ omap2420_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap2420_dma_system_hwmod = {
+ .name = dma,
+ .class = omap2420_dma_hwmod_class,
+ .mpu_irqs = omap2420_dma_system_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_dma_system_irqs),
+ .main_clk = l3_div_ck,
+ .prcm = {
+ .omap2 = {
+ /* .clkctrl_reg = NULL, */
+ },
+ },
+ .slaves = omap2420_dma_system_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_dma_system_slaves),
+ .masters= omap2420_dma_system_masters,
+ .masters_cnt= ARRAY_SIZE(omap2420_dma_system_masters),
+ .dev_attr = dma_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+};
+
static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_l3_main_hwmod,
omap2420_l4_core_hwmod,
omap2420_l4_wkup_hwmod,
omap2420_mpu_hwmod,
+ omap2420_dma_system_hwmod,
NULL,
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/11] OMAP3: DMA: HWMOD: Add hwmod data structures
This patch adds OMAP3 DMA hwmod structures.
Signed-off-by: Manjunatha GK manj...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 89
1 files changed, 89 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index d3bf85b..07f2794 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -36,6 +36,7 @@ static struct omap_hwmod omap3xxx_iva_hwmod;
static struct omap_hwmod omap3xxx_l3_main_hwmod;
static struct omap_hwmod omap3xxx_l4_core_hwmod;
static struct omap_hwmod omap3xxx_l4_per_hwmod;
+static struct omap_hwmod omap3xxx_dma_system_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -197,6 +198,93 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
};
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap3xxx_dma_system__l3 = {
+ .master = omap3xxx_dma_system_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+ .dma_dev_attr = DMA_LINKED_LCH | GLOBAL_PRIORITY |
+ IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORIY,
+ .dma_lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT,
+};;
+
+static struct omap_hwmod_class_sysconfig omap3xxx_dma_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x002c,
+ .syss_offs = 0x0028,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_dma_hwmod_class = {
+ .name = dma,
+ .sysc = omap3xxx_dma_sysc,
+};
+
+/* dma_system */
+static struct omap_hwmod_irq_info omap3xxx_dma_system_irqs[] = {
+ { .name = dma_0, .irq = INT_24XX_SDMA_IRQ0 },
+ { .name = dma_1, .irq = INT_24XX_SDMA_IRQ1 },
+ { .name = dma_2, .irq = INT_24XX_SDMA_IRQ2 },
+ { .name = dma_3, .irq = INT_24XX_SDMA_IRQ3 },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_dma_system_addrs[] = {
+ {
+ .pa_start = 0x48056000,
+ .pa_end = 0x4a0560ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dma_system_masters[] = {
+ omap3xxx_dma_system__l3,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__dma_system = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_dma_system_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap3xxx_dma_system_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_dma_system_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dma_system_slaves[] = {
+ omap3xxx_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap3xxx_dma_system_hwmod = {
+ .name = dma,
+ .class = omap3xxx_dma_hwmod_class,
+ .mpu_irqs = omap3xxx_dma_system_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_dma_system_irqs),
+ .main_clk = l3_div_ck,
+ .prcm = {
+ .omap2 = {
+ /* .clkctrl_reg = NULL, */
+ },
+ },
+ .slaves = omap3xxx_dma_system_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_dma_system_slaves),
+ .masters= omap3xxx_dma_system_masters,
+ .masters_cnt= ARRAY_SIZE(omap3xxx_dma_system_masters),
+ .dev_attr = dma_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l3_main_hwmod,
omap3xxx_l4_core_hwmod,
@@ -204,6 +292,7 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l4_wkup_hwmod,
omap3xxx_mpu_hwmod,
omap3xxx_iva_hwmod,
+ omap3xxx_dma_system_hwmod,
NULL,
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/11] OMAP4: DMA: HWMOD: update OMAP4 data base
The OMAP4 hwmod data base is updated with DMA controller attributes.
Signed-off-by: Manjunatha GK manj...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 19 ++-
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 20f5f8c..ee589c5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,7 @@
#include plat/omap_hwmod.h
#include plat/cpu.h
+#include plat/dma.h
#include omap_hwmod_common_data.h
@@ -750,12 +751,19 @@ static struct omap_hwmod_class omap44xx_dma_hwmod_class =
{
.sysc = omap44xx_dma_sysc,
};
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+ .dma_dev_attr = DMA_LINKED_LCH | GLOBAL_PRIORITY |
+ IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORIY,
+ .dma_lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT,
+};
+
/* dma_system */
static struct omap_hwmod_irq_info omap44xx_dma_system_irqs[] = {
- { .name = 0, .irq = 12 + OMAP44XX_IRQ_GIC_START },
- { .name = 1, .irq = 13 + OMAP44XX_IRQ_GIC_START },
- { .name = 2, .irq = 14 + OMAP44XX_IRQ_GIC_START },
- { .name = 3, .irq = 15 + OMAP44XX_IRQ_GIC_START },
+ { .name = dma_0, .irq = 12 + OMAP44XX_IRQ_GIC_START },
+ { .name = dma_1, .irq = 13 + OMAP44XX_IRQ_GIC_START },
+ { .name = dma_2, .irq = 14 + OMAP44XX_IRQ_GIC_START },
+ { .name = dma_3, .irq = 15 + OMAP44XX_IRQ_GIC_START },
};
static struct omap_hwmod_addr_space omap44xx_dma_system_addrs[] = {
@@ -801,6 +809,7 @@ static struct omap_hwmod omap44xx_dma_system_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_dma_system_slaves),
.masters= omap44xx_dma_system_masters,
.masters_cnt= ARRAY_SIZE(omap44xx_dma_system_masters),
+ .dev_attr = dma_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
@@ -4789,7 +4798,7 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* counter class */
omap44xx_counter_32k_hwmod,
/* dma class */
-/* omap44xx_dma_system_hwmod, */
+ omap44xx_dma_system_hwmod,
/* dmic class */
/* omap44xx_dmic_hwmod, */
/* dsp class */
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/11] OMAP: DMA: Introduce DMA device attributes
This patches introduces OMAP DMA device attributes for using the same in
DMA platform driver for all OMAP's and HWMOD database(OMAP2PLUS onwards)
Signed-off-by: Manjunatha GK manj...@ti.com
---
arch/arm/plat-omap/include/plat/dma.h | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index 02232ca..ff60f11 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -398,6 +398,22 @@
#define DMA_CH_PRIO_HIGH 0x1
#define DMA_CH_PRIO_LOW0x0 /* Def */
+/* Attributes for OMAP DMA Contrllers */
+#define ENABLE_1510_MODE (1 0)
+#define DMA_LINKED_LCH (1 1)
+#define GLOBAL_PRIORITY(1 2)
+#define RESERVE_CHANNEL(1 3)
+#define SRC_PORT (2 3)
+#define DST_PORT (2 4)
+#define IS_CSSA_32 (2 5)
+#define IS_CDSA_32 (2 6)
+#define SRC_INDEX (4 6)
+#define DST_INDEX (4 7)
+#define IS_BURST_ONLY4 (4 8)
+#define CLEAR_CSR_ON_READ (4 9)
+#define IS_WORD_16 (8 9)
+#define IS_RW_PRIORIY (8 0xA)
+
enum omap_dma_burst_mode {
OMAP_DMA_DATA_BURST_DIS = 0,
OMAP_DMA_DATA_BURST_4,
@@ -463,6 +479,12 @@ struct omap_dma_channel_params {
#endif
};
+struct omap_dma_dev_attr {
+ u32 dma_dev_attr;
+ u16 dma_lch_count;
+ u16 dma_chan_count;
+ struct omap_dma_lch *dma_chan;
+};
extern void omap_set_dma_priority(int lch, int dst_port, int priority);
extern int omap_request_dma(int dev_id, const char *dev_name,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/11] OMAP1: DMA: Introduce DMA driver as platform driver
This patch introduces OMAP1 DMA driver as platform device
and adds support for registering through platform device
layer.
Signed-off-by: Manjunatha GK manj...@ti.com
---
arch/arm/mach-omap1/dma.c | 234
arch/arm/mach-omap1/include/mach/dma.h | 80 +++
2 files changed, 314 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap1/dma.c
create mode 100644 arch/arm/mach-omap1/include/mach/dma.h
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
new file mode 100644
index 000..0df2b82
--- /dev/null
+++ b/arch/arm/mach-omap1/dma.c
@@ -0,0 +1,234 @@
+/*
+ * dma.c - OMAP1/OMAP7xx-specific DMA code
+ *
+ * Copyright (C) 2003 - 2008 Nokia Corporation
+ * Author: Juha Yrjölä juha.yrj...@nokia.com
+ * DMA channel linking for 1610 by Samuel Ortiz samuel.or...@nokia.com
+ * Graphics DMA and LCD DMA graphics tranformations
+ * by Imre Deak imre.d...@nokia.com
+ * OMAP2/3 support Copyright (C) 2004-2007 Texas Instruments, Inc.
+ * Some functions based on earlier dma-omap.c Copyright (C) 2001 RidgeRun, Inc.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Converted DMA library into platform driver by Manjunatha GK manj...@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.
+ */
+
+#include linux/err.h
+#include linux/slab.h
+#include linux/pm_runtime.h
+#include linux/io.h
+#include linux/module.h
+#include linux/init.h
+#include linux/sched.h
+#include linux/spinlock.h
+#include linux/errno.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/device.h
+
+#include plat/dma.h
+#include plat/tc.h
+
+#define dma_read(reg) \
+({ \
+ u32 __val; \
+ __val = __raw_readw(dma_base + OMAP1_DMA_##reg);\
+ __val; \
+})
+
+#define dma_write(val, reg)\
+({ \
+ __raw_writew((val), dma_base + OMAP1_DMA_##reg);\
+})
+
+static struct resource res[] __initdata = {
+ [0] = {
+ .start = OMAP1_DMA_BASE,
+ .end= OMAP1_DMA_BASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .name = system_dma_0,
+ .start = INT_DMA_CH0_6,
+ .flags = IORESOURCE_IRQ,
+ },
+ [2] = {
+ .name = system_dma_1,
+ .start = INT_DMA_CH1_7,
+ .flags = IORESOURCE_IRQ,
+ },
+ [3] = {
+ .name = system_dma_2,
+ .start = INT_DMA_CH2_8,
+ .flags = IORESOURCE_IRQ,
+ },
+ [4] = {
+ .name = system_dma_3,
+ .start = INT_DMA_CH3,
+ .flags = IORESOURCE_IRQ,
+ },
+ [5] = {
+ .name = system_dma_4,
+ .start = INT_DMA_CH4,
+ .flags = IORESOURCE_IRQ,
+ },
+ [6] = {
+ .name = system_dma_5,
+ .start = INT_DMA_CH5,
+ .flags = IORESOURCE_IRQ,
+ },
+ [7] = {
+ .name = system_dma_6,
+ .start = INT_DMA_LCD,
+ .flags = IORESOURCE_IRQ,
+ },
+ /* irq's for omap16xx and omap7xx */
+ [8] = {
+ .name = system_dma_7,
+ .start = 53 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [9] = {
+ .name = system_dma_8,
+ .start = 54 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [10] = {
+ .name = system_dma_9,
+ .start = 55 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [11] = {
+ .name = system_dma_10,
+ .start = 56 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [12] = {
+ .name = system_dma_11,
+ .start = 57 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [13] = {
+ .name = system_dma_12,
+ .start = 58 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [14] = {
+ .name = system_dma_13,
+ .start = 59 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [15] = {
+ .name = system_dma_14,
+ .start = 60 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [16] = {
+ .name = system_dma_15,
+ .start = 61 + IH2_BASE,
+ .flags =
[PATCH 11/11] sDMA: descriptor autoloading feature
From: Venkatraman S svenk...@ti.com
Add sDMA driver support for descriptor autoloading feature.
Descriptor autoloading is OMAP sDMA v5 hardware capability that can be exploited
for scatter gather scenarios, currently available in OMAP3630 and OMAP4430.
The feature works as described below.
1. A sDMA channel is programmed to be in 'linked list' mode.
2) The client (sDMA user) provides a list of descriptors in a linked list format
3) Each of the 'descriptor' (element in the linked list) contains an updated set
of DMA configuration register values.
4) Client starts DMA transfer.
5) sDMA controller loads the first element to its register configuration memory
and executes the transfer.
6) After completion, loads the next element (in linked list) to configuration
memory and executes the transfer, without MCU intervention.
7) Interrupt is generated after all transfers are completed; this can be
configured to be done differently.
Configurations and additional features
1) Fast mode non-fast mode
Fast mode/non-fast decides on how the first transfer begins. In non-fast mode,
the first element in the linked list is loaded only after completing the
transfer according to the configurations already in the sDMA channel registers.
In fast mode, the loading of the first element precedes the transfer.
2) Pause / resume of transfers
A transfer can be paused after a descriptor set has been loaded, provided the
pause bit' is set in the linked list element.
An ongoing transfer cannot be paused. If the 'pause bit' is set, transfer is not
started after loading the register set from memory.
Such a transfer can be resumed later.
3) Descriptor types
Three possible configurations of descriptors (initialized as linked list
elements) are possible.
Type 1 provides the maximum flexibility, which contains most register
definitions of a DMA logical channel.
Fewer options are present in type 2.
Type 3 can just modify source/destinations address of transfers. In all
transfers, unmodified registers settings are maintained for the next transfer.
Patch provides options / API for
1) Setting up a descriptor loading for DMA channel for sg type transfers
2) configuration with linked list elements
3) Starting / pause and resume of the said transfers, query state
4) Clearing the sglist mode
Signed-off-by: Venkatraman S svenk...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
---
arch/arm/mach-omap1/dma.c |5 +
arch/arm/mach-omap1/include/mach/dma.h |2 +
arch/arm/mach-omap2/dma.c | 254
arch/arm/mach-omap2/include/mach/dma.h | 194
arch/arm/plat-omap/dma.c |1 +
5 files changed, 456 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index eadc160..1f10f62 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -304,6 +304,11 @@ void omap_dma_set_global_params(int arb_rate, int
max_fifo_depth, int tparams)
}
EXPORT_SYMBOL(omap_dma_set_global_params);
+void omap_clear_dma_sglist_mode(int lch)
+{
+ return;
+}
+
static int __init omap1_system_dma_init(void)
{
struct platform_device *pdev;
diff --git a/arch/arm/mach-omap1/include/mach/dma.h
b/arch/arm/mach-omap1/include/mach/dma.h
index 1eb0d31..afe486b 100644
--- a/arch/arm/mach-omap1/include/mach/dma.h
+++ b/arch/arm/mach-omap1/include/mach/dma.h
@@ -143,4 +143,6 @@ struct omap_dma_lch {
long flags;
};
+/* Dummy function */
+extern void omap_clear_dma_sglist_mode(int lch);
#endif /* __ASM_ARCH_OMAP1_DMA_H */
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index 390c428..c24ed00 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -204,6 +204,77 @@ static void dma_ocpsysconfig_errata(u32 *sys_cf, bool flag)
dma_write(*sys_cf, OCP_SYSCONFIG);
}
+static inline void omap_dma_list_set_ntype(struct omap_dma_sglist_node *node,
+ int value)
+{
+ node-num_of_elem |= ((value) 29);
+}
+
+static void omap_set_dma_sglist_pausebit(
+ struct omap_dma_list_config_params *lcfg, int nelem, int set)
+{
+ struct omap_dma_sglist_node *sgn = lcfg-sghead;
+
+ if (nelem 0 nelem lcfg-num_elem) {
+ lcfg-pausenode = nelem;
+ sgn += nelem;
+
+ if (set)
+ sgn-next_desc_add_ptr |= DMA_LIST_DESC_PAUSE;
+ else
+ sgn-next_desc_add_ptr = ~(DMA_LIST_DESC_PAUSE);
+ }
+}
+
+static int dma_sglist_set_phy_params(struct omap_dma_sglist_node *sghead,
+ dma_addr_t phyaddr, int nelem)
+{
+ struct omap_dma_sglist_node *sgcurr, *sgprev;
+ dma_addr_t elem_paddr = phyaddr;
+
+ for (sgprev = sghead;
+ sgprev sghead + nelem;
+ sgprev++) {
+
+ sgcurr = sgprev + 1;
+ sgprev-next = sgcurr;
+
[PATCH 07/11] OMAP2/3/4: DMA: HWMOD: Device registration
This patch converts omap2/3/4 dma driver into platform
devices through using omap hwmod, omap device and runtime pm
frameworks.
Signed-off-by: Manjunatha GK manj...@ti.com
---
arch/arm/mach-omap2/dma.c | 134
arch/arm/mach-omap2/include/mach/dma.h | 80 +++
2 files changed, 214 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/dma.c
create mode 100644 arch/arm/mach-omap2/include/mach/dma.h
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
new file mode 100644
index 000..da76c34
--- /dev/null
+++ b/arch/arm/mach-omap2/dma.c
@@ -0,0 +1,134 @@
+/*
+ * dma.c - OMAP2 specific DMA code
+ *
+ * Copyright (C) 2003 - 2008 Nokia Corporation
+ * Author: Juha Yrjölä juha.yrj...@nokia.com
+ * DMA channel linking for 1610 by Samuel Ortiz samuel.or...@nokia.com
+ * Graphics DMA and LCD DMA graphics tranformations
+ * by Imre Deak imre.d...@nokia.com
+ * OMAP2/3 support Copyright (C) 2004-2007 Texas Instruments, Inc.
+ * Some functions based on earlier dma-omap.c Copyright (C) 2001 RidgeRun, Inc.
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Converted DMA library into platform driver by Manjunatha GK manj...@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.
+ */
+
+#include linux/err.h
+#include linux/slab.h
+#include linux/pm_runtime.h
+#include linux/io.h
+#include linux/module.h
+#include linux/init.h
+#include linux/sched.h
+#include linux/spinlock.h
+#include linux/errno.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/device.h
+
+#include plat/irqs.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+#include plat/dma.h
+
+#define dma_read(reg) \
+({ \
+ u32 __val; \
+ __val = __raw_readl(dma_base + OMAP_DMA4_##reg);\
+ __val; \
+})
+
+#define dma_write(val, reg)\
+({ \
+ __raw_writel((val), dma_base + OMAP_DMA4_##reg);\
+})
+
+static struct omap_dma_dev_attr *d;
+static void __iomem *dma_base;
+static struct omap_system_dma_plat_info *omap2_pdata;
+static int dma_caps0_status;
+
+static struct omap_device_pm_latency omap2_dma_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+/* One time initializations */
+static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void *user)
+{
+ struct omap_device *od;
+ struct omap_system_dma_plat_info *pdata;
+ struct resource *mem;
+ char *name = dma;
+
+ pdata = kzalloc(sizeof(struct omap_system_dma_plat_info), GFP_KERNEL);
+ if (!pdata) {
+ pr_err(%s: Unable to allocate pdata for %s:%s\n,
+ __func__, name, oh-name);
+ return -ENOMEM;
+ }
+
+ pdata-dma_attr = (struct omap_dma_dev_attr *)oh-dev_attr;
+
+ od = omap_device_build(name, 0, oh, pdata, sizeof(*pdata),
+ omap2_dma_latency, ARRAY_SIZE(omap2_dma_latency), 0);
+
+ if (IS_ERR(od)) {
+ pr_err(%s: Cant build omap_device for %s:%s.\n,
+ __func__, name, oh-name);
+ kfree(pdata);
+ return 0;
+ }
+
+ mem = platform_get_resource(od-pdev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(od-pdev.dev, %s: no mem resource\n, __func__);
+ return -EINVAL;
+ }
+
+ dma_base = ioremap(mem-start, resource_size(mem));
+ if (!dma_base) {
+ dev_err(od-pdev.dev, %s: ioremap fail\n, __func__);
+ return -ENOMEM;
+ }
+
+ /* Get DMA device attributes from hwmod data base */
+ d = (struct omap_dma_dev_attr *)oh-dev_attr;
+
+ /* OMAP2 Plus: physical and logical channel count is same */
+ d-dma_chan_count = d-dma_lch_count;
+
+ d-dma_chan = kzalloc(sizeof(struct omap_dma_lch) *
+ (d-dma_lch_count), GFP_KERNEL);
+
+ if (!d-dma_chan) {
+ dev_err(od-pdev.dev, %s: kzalloc fail\n, __func__);
+ return -ENOMEM;
+ }
+
+ omap2_pdata = pdata;
+ dma_caps0_status= dma_read(CAPS_0);
+
+ return 0;
+}
+
+static int __init omap2_system_dma_init(void)
+{
+ int ret;
+
+
[PATCH 08/11] OMAP: DMA: Convert DMA library into DMA platform Driver
This patch converts DMA library into DMA platform driver and make use
of platform data provided by HWMOD data base for OMAP2PLUS onwards.
For OMAP1 processors, the DMA driver in mach-omap uses resource structures
for getting platform data.
Signed-off-by: Manjunatha GK manj...@ti.com
---
arch/arm/mach-omap1/Makefile |2 +-
arch/arm/mach-omap1/include/mach/dma.h | 66 ++
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/include/mach/dma.h | 83
arch/arm/plat-omap/dma.c | 224
arch/arm/plat-omap/include/plat/dma.h | 157 ++-
6 files changed, 271 insertions(+), 263 deletions(-)
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index fd4df71..a159af4 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o
+obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o dma.o
obj-y += clock.o clock_data.o opp_data.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap1/include/mach/dma.h
b/arch/arm/mach-omap1/include/mach/dma.h
index d446cdd..1eb0d31 100644
--- a/arch/arm/mach-omap1/include/mach/dma.h
+++ b/arch/arm/mach-omap1/include/mach/dma.h
@@ -77,4 +77,70 @@
#define OMAP1_DMA_CCR2(n) (0x40 * (n) + 0x24)
#define OMAP1_DMA_LCH_CTRL(n) (0x40 * (n) + 0x2a)
+/* Dummy defines to support multi omap code */
+/* Channel specific registers */
+#define OMAP_DMA4_CCR(n) 0
+#define OMAP_DMA4_CSDP(n) 0
+#define OMAP_DMA4_CEN(n) 0
+#define OMAP_DMA4_CFN(n) 0
+#define OMAP_DMA4_COLOR(n) 0
+#define OMAP_DMA4_CSSA(n) 0
+#define OMAP_DMA4_CSEI(n) 0
+#define OMAP_DMA4_CSFI(n) 0
+#define OMAP_DMA4_CDSA(n) 0
+#define OMAP_DMA4_CDEI(n) 0
+#define OMAP_DMA4_CDFI(n) 0
+#define OMAP_DMA4_CSR(n) 0
+#define OMAP_DMA4_CICR(n) 0
+#define OMAP_DMA4_CLNK_CTRL(n) 0
+#define OMAP_DMA4_CH_BASE(n) 0
+#define OMAP_DMA4_CDAC(n) 0
+#define OMAP_DMA4_CSAC(n) 0
+
+/* Common registers */
+#define OMAP_DMA4_IRQENABLE_L0 0
+#define OMAP_DMA4_OCP_SYSCONFIG0
+#define OMAP_DMA4_GCR 0
+#define OMAP_DMA4_IRQSTATUS_L0 0
+#define OMAP_DMA4_CAPS_2 0
+#define OMAP_DMA4_CAPS_3 0
+#define OMAP_DMA4_CAPS_4 0
+#define OMAP_DMA4_REVISION 0
+
+#define OMAP_DMA4_CCR2(n) 0
+#define OMAP_DMA4_LCH_CTRL(n) 0
+#define OMAP_DMA4_COLOR_L(n) 0
+#define OMAP_DMA4_COLOR_U(n) 0
+#define OMAP1_DMA_COLOR(n) 0
+#define OMAP_DMA4_CSSA_U(n)0
+#define OMAP_DMA4_CSSA_L(n)0
+#define OMAP1_DMA_CSSA(n) 0
+#define OMAP_DMA4_CDSA_U(n)0
+#define OMAP_DMA4_CDSA_L(n)0
+#define OMAP1_DMA_CDSA(n) 0
+#define OMAP_DMA4_CPC(n) 0
+
+#define OMAP1_DMA_IRQENABLE_L0 0
+#define OMAP1_DMA_IRQENABLE_L0 0
+#define OMAP1_DMA_IRQSTATUS_L0 0
+#define OMAP1_DMA_OCP_SYSCONFIG0
+#define OMAP_DMA4_HW_ID0
+#define OMAP_DMA4_CAPS_0_U 0
+#define OMAP_DMA4_CAPS_0_L 0
+#define OMAP_DMA4_CAPS_1_U 0
+#define OMAP_DMA4_CAPS_1_L 0
+#define OMAP_DMA4_GSCR 0
+#define OMAP1_DMA_REVISION 0
+
+struct omap_dma_lch {
+ int next_lch;
+ int dev_id;
+ u16 saved_csr;
+ u16 enabled_irqs;
+ const char *dev_name;
+ void (*callback)(int lch, u16 ch_status, void *data);
+ void *data;
+ long flags;
+};
+
#endif /* __ASM_ARCH_OMAP1_DMA_H */
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ae5f36f..3c5557a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o
+obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o dma.o
omap-2-3-common= irq.o sdrc.o
hwmod-common = omap_hwmod.o \
diff --git a/arch/arm/mach-omap2/include/mach/dma.h
b/arch/arm/mach-omap2/include/mach/dma.h
index 3eca7d8..22f4b41 100644
--- a/arch/arm/mach-omap2/include/mach/dma.h
+++ b/arch/arm/mach-omap2/include/mach/dma.h
@@ -77,4 +77,87 @@
#define OMAP_DMA4_CNDP(n) (0x60 * (n) + 0xd4)
#define OMAP_DMA4_CCDN(n) (0x60 * (n) + 0xd8)
+
+/* Dummy defines for support multi omap code */
+/* Common registers */
+#define OMAP1_DMA_GCR 0
+#define OMAP1_DMA_HW_ID0
+#define OMAP1_DMA_CAPS_0_U
RE: [PATCH 11/11] sDMA: descriptor autoloading feature
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of G,
Manjunath Kondaiah
Sent: Thursday, July 29, 2010 3:29 PM
To: linux-omap@vger.kernel.org
Cc: S, Venkatraman; Cousson, Benoit; Kevin Hilman; Paul
Walmsley; Tony Lindgren; Sawant, Anand; Shilimkar, Santosh;
Nayak, Rajendra; Basak, Partha; Varadarajan, Charulatha
Subject: [PATCH 11/11] sDMA: descriptor autoloading feature
From: Venkatraman S svenk...@ti.com
Add sDMA driver support for descriptor autoloading feature.
Descriptor autoloading is OMAP sDMA v5 hardware capability
that can be exploited
for scatter gather scenarios, currently available in OMAP3630
and OMAP4430.
The feature works as described below.
1. A sDMA channel is programmed to be in 'linked list' mode.
2) The client (sDMA user) provides a list of descriptors in a
linked list format
3) Each of the 'descriptor' (element in the linked list)
contains an updated set
of DMA configuration register values.
4) Client starts DMA transfer.
5) sDMA controller loads the first element to its register
configuration memory
and executes the transfer.
6) After completion, loads the next element (in linked list)
to configuration
memory and executes the transfer, without MCU intervention.
7) Interrupt is generated after all transfers are completed;
this can be
configured to be done differently.
Configurations and additional features
1) Fast mode non-fast mode
Fast mode/non-fast decides on how the first transfer begins.
In non-fast mode,
the first element in the linked list is loaded only after
completing the
transfer according to the configurations already in the sDMA
channel registers.
In fast mode, the loading of the first element precedes the transfer.
2) Pause / resume of transfers
A transfer can be paused after a descriptor set has been
loaded, provided the
pause bit' is set in the linked list element.
An ongoing transfer cannot be paused. If the 'pause bit' is
set, transfer is not
started after loading the register set from memory.
Such a transfer can be resumed later.
3) Descriptor types
Three possible configurations of descriptors (initialized as
linked list
elements) are possible.
Type 1 provides the maximum flexibility, which contains most register
definitions of a DMA logical channel.
Fewer options are present in type 2.
Type 3 can just modify source/destinations address of
transfers. In all
transfers, unmodified registers settings are maintained for
the next transfer.
Patch provides options / API for
1) Setting up a descriptor loading for DMA channel for sg
type transfers
2) configuration with linked list elements
3) Starting / pause and resume of the said transfers, query state
4) Clearing the sglist mode
Signed-off-by: Venkatraman S svenk...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
---
arch/arm/mach-omap1/dma.c |5 +
arch/arm/mach-omap1/include/mach/dma.h |2 +
arch/arm/mach-omap2/dma.c | 254
arch/arm/mach-omap2/include/mach/dma.h | 194
arch/arm/plat-omap/dma.c |1 +
5 files changed, 456 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index eadc160..1f10f62 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -304,6 +304,11 @@ void omap_dma_set_global_params(int
arb_rate, int max_fifo_depth, int tparams)
}
EXPORT_SYMBOL(omap_dma_set_global_params);
+void omap_clear_dma_sglist_mode(int lch)
+{
+ return;
+}
+
static int __init omap1_system_dma_init(void)
{
struct platform_device *pdev;
diff --git a/arch/arm/mach-omap1/include/mach/dma.h
b/arch/arm/mach-omap1/include/mach/dma.h
index 1eb0d31..afe486b 100644
--- a/arch/arm/mach-omap1/include/mach/dma.h
+++ b/arch/arm/mach-omap1/include/mach/dma.h
@@ -143,4 +143,6 @@ struct omap_dma_lch {
long flags;
};
+/* Dummy function */
+extern void omap_clear_dma_sglist_mode(int lch);
#endif /* __ASM_ARCH_OMAP1_DMA_H */
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index 390c428..c24ed00 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -204,6 +204,77 @@ static void dma_ocpsysconfig_errata(u32
*sys_cf, bool flag)
dma_write(*sys_cf, OCP_SYSCONFIG);
}
+static inline void omap_dma_list_set_ntype(struct
omap_dma_sglist_node *node,
+int value)
+{
+ node-num_of_elem |= ((value) 29);
+}
+
+static void omap_set_dma_sglist_pausebit(
+ struct omap_dma_list_config_params *lcfg, int
nelem, int set)
+{
+ struct omap_dma_sglist_node *sgn = lcfg-sghead;
+
+ if (nelem 0 nelem lcfg-num_elem) {
+ lcfg-pausenode = nelem;
+ sgn += nelem;
+
+ if (set)
+
RE: [PATCH resend] OMAP: DSS2: Replace strncmp() with sysfs_streq() in overlay_manager_store()
-Original Message- From: Taneja, Archit Sent: Thursday, July 29, 2010 11:27 AM To: Premi, Sanjeev; tomi.valkei...@nokia.com Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH resend] OMAP: DSS2: Replace strncmp() with sysfs_streq() in overlay_manager_store() [snip]...[snip] [sp] sysfs_streq() ignores trailing newlines during comparison. So, the possibility mentioned in the description still stays. The aim is to compare one string which is a sysfs input and the other which is in the kernel. I am not familiar with overall context; but wouldn't srtcmp() be the right choice? unless, of course, either of strings being compared are not null terminated. The sysfs input will have a newline and null at the end whereas the other string will only have null, strcmp will fail when we want the two strings to match. Eg. Sysfs input lcd\n\0 Kernel string lcd\0 strcmp will fail here [sp] If the patch is intending to fix this condition, then it isn't evident from the description. You should consider updating the description. The patch isn't intending to fix this condition, this condition doesn't occur at all in the existing code. I explained this to tell you why strcmp is a bad choice, the patch description tells why sysfs_streq is a better choice over strncmp. [sp] Can you explain the real condition and how/why it can't be handled by strcmp() Okay, the real condition (why this patch was sent) is this (please have a look at the whole function body while reading the explanation): The user enters lcd via sysfs input to change the overlay's manager to lcd, this input will be converted to lcd\n\0, the function will try to comapre this name with all the existing managers names. Consider the case where buf (sysfs input) is lcd\n\0 and mgr-name is lcd2\0. Now, len is calculated as 3 and is passed as the parameter to stncmp, in this case, lcd and lcd2 will match because only the first 3 characters are compared. This is what I meant by buf being a prefix string of mgr-name. This above is the condition which the patch tries to resolve. strcmp will work like a charm here and ignore false positives, but it will generate a false negative which didn't occur previously at all, an example: If buf is lcd\n\0 and mgr-name is lcd\0 the code should match this, but strcmp won't. [sp] This explains. And my earlier comment was to update the description with need for change. I believe quick summary the discussion above will be good for the patch. Hence, to prevent both false positives and false negatives sysfs_streq is used. If you want to use strcmp, you will have to manually strip off the newlines. I have also shared the patch link below which intrioduces sysfs_streq in the kernel and explains why it has been introduced in the first place: http://kerneltrap.org/mailarchive/git-commits-head/2008/5/1/1688084 [sp] I am aware of it. See my first comment. I hope this explanation elaborates things clearly. Thanks, Archit -- 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 resend] OMAP: DSS2: Replace strncmp() with sysfs_streq() in overlay_manager_store()
[snip] [sp] This explains. And my earlier comment was to update the description with need for change. I believe quick summary the discussion above will be good for the patch. Okay, will do. But what am is supposed to add more in the summary? Should I add how sysfs_streq is a better choice over strcmp? Or should I emphasize more how the false positive scenario can occur with strncmp? Thanks, Archit-- 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 resend] OMAP: DSS2: Replace strncmp() with sysfs_streq() in overlay_manager_store()
-Original Message- From: Taneja, Archit Sent: Thursday, July 29, 2010 4:40 PM To: Premi, Sanjeev; tomi.valkei...@nokia.com Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH resend] OMAP: DSS2: Replace strncmp() with sysfs_streq() in overlay_manager_store() [snip] [sp] This explains. And my earlier comment was to update the description with need for change. I believe quick summary the discussion above will be good for the patch. Okay, will do. But what am is supposed to add more in the summary? Should I add how sysfs_streq is a better choice over strcmp? Or should I emphasize more how the false positive scenario can occur with strncmp? I believe it should indicate problem being fixed. sysfs_streq() vs strncmp() is means of arriving at solution. Thanks, Archit-- 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 01/11] OMAP: DMA: Introduce DMA device attributes
Hi Manjunatha,
I just have a couple of minor comments.
On 7/29/2010 11:58 AM, G, Manjunath Kondaiah wrote:
This patches introduces OMAP DMA device attributes for using the same in
DMA platform driver for all OMAP's and HWMOD database(OMAP2PLUS onwards)
Signed-off-by: Manjunatha GKmanj...@ti.com
---
arch/arm/plat-omap/include/plat/dma.h | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index 02232ca..ff60f11 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -398,6 +398,22 @@
#define DMA_CH_PRIO_HIGH 0x1
#define DMA_CH_PRIO_LOW 0x0 /* Def */
+/* Attributes for OMAP DMA Contrllers */
+#define ENABLE_1510_MODE (1 0)
+#define DMA_LINKED_LCH (1 1)
+#define GLOBAL_PRIORITY(1 2)
+#define RESERVE_CHANNEL(1 3)
+#define SRC_PORT (2 3)
+#define DST_PORT (2 4)
+#define IS_CSSA_32 (2 5)
+#define IS_CDSA_32 (2 6)
+#define SRC_INDEX (4 6)
+#define DST_INDEX (4 7)
+#define IS_BURST_ONLY4 (4 8)
+#define CLEAR_CSR_ON_READ (4 9)
+#define IS_WORD_16 (8 9)
+#define IS_RW_PRIORIY (8 0xA)
It is a minor detail, but why are you shifting both side of the
operator? It is really confusing, cannot you just do 1 X?
With 0 X 13.
+
enum omap_dma_burst_mode {
OMAP_DMA_DATA_BURST_DIS = 0,
OMAP_DMA_DATA_BURST_4,
@@ -463,6 +479,12 @@ struct omap_dma_channel_params {
#endif
};
+struct omap_dma_dev_attr {
+ u32 dma_dev_attr;
That name is not very meaningful, maybe dma_cap for capability or
something else will be better.
+ u16 dma_lch_count;
+ u16 dma_chan_count;
+ struct omap_dma_lch *dma_chan;
In general, I think that there are too many dma_ prefix in that
structure. It is already inside a dma_XXX struct so I don't think that
adding an extra prefix to every attribute is needed.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/11] OMAP4: DMA: HWMOD: update OMAP4 data base
Some more comments about dma_ prefix...
On 7/29/2010 11:58 AM, G, Manjunath Kondaiah wrote:
The OMAP4 hwmod data base is updated with DMA controller attributes.
Signed-off-by: Manjunatha GKmanj...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 19 ++-
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 20f5f8c..ee589c5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,7 @@
#includeplat/omap_hwmod.h
#includeplat/cpu.h
+#includeplat/dma.h
#include omap_hwmod_common_data.h
@@ -750,12 +751,19 @@ static struct omap_hwmod_class omap44xx_dma_hwmod_class =
{
.sysc =omap44xx_dma_sysc,
};
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+ .dma_dev_attr = DMA_LINKED_LCH | GLOBAL_PRIORITY |
+ IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORIY,
+ .dma_lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT,
+};
+
/* dma_system */
static struct omap_hwmod_irq_info omap44xx_dma_system_irqs[] = {
- { .name = 0, .irq = 12 + OMAP44XX_IRQ_GIC_START },
- { .name = 1, .irq = 13 + OMAP44XX_IRQ_GIC_START },
- { .name = 2, .irq = 14 + OMAP44XX_IRQ_GIC_START },
- { .name = 3, .irq = 15 + OMAP44XX_IRQ_GIC_START },
+ { .name = dma_0, .irq = 12 + OMAP44XX_IRQ_GIC_START },
+ { .name = dma_1, .irq = 13 + OMAP44XX_IRQ_GIC_START },
+ { .name = dma_2, .irq = 14 + OMAP44XX_IRQ_GIC_START },
+ { .name = dma_3, .irq = 15 + OMAP44XX_IRQ_GIC_START },
0, 1, 2, and 3 are maybe not very meaningful name, but what
information the dma_ prefix will bring us?
That name will only be used inside the dma driver, so there is no
namespace confusion. The shorter, the better.
Regards,
Benoit
};
static struct omap_hwmod_addr_space omap44xx_dma_system_addrs[] = {
@@ -801,6 +809,7 @@ static struct omap_hwmod omap44xx_dma_system_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_dma_system_slaves),
.masters= omap44xx_dma_system_masters,
.masters_cnt= ARRAY_SIZE(omap44xx_dma_system_masters),
+ .dev_attr =dma_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
@@ -4789,7 +4798,7 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* counter class */
omap44xx_counter_32k_hwmod,
/* dma class */
-/* omap44xx_dma_system_hwmod, */
+ omap44xx_dma_system_hwmod,
/* dmic class */
/*omap44xx_dmic_hwmod, */
/* dsp class */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] omap:hwspinlock-added hwspinlock driver
Yogesh,
Nice to see your email.
+/* Release a spinlock */
+int hwspinlock_unlock(struct hwspinlock *handle)
+{
+ if (WARN_ON(handle == NULL))
+ return -EINVAL;
+
+ /* Release it by writing 0 to it */
+ writel(0, handle-lock_reg);
[[Yogesh Marathe]] Releasing the spinlock without knowing who owns it is
risky. There should be a check for ownership and if authenticated user has
called this api only then it should be released otherwise permission
denied error should be returned.
-- I think if there is another Kernel client that is trying to release that is
not owned by it then that Kernel client itself is buggy and needs to be fixed.
Please share your thoughts on how we can ensure that we can add some protection.
+
+ pm_runtime_put(handle-pdev-dev);
+
+ return 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
Re: [PATCH 3/5] omap:hwspinlock-added hwspinlock driver
On 7/29/2010 3:14 PM, Kanigeri, Hari wrote:
Yogesh,
Nice to see your email.
+/* Release a spinlock */
+int hwspinlock_unlock(struct hwspinlock *handle)
+{
+ if (WARN_ON(handle == NULL))
+ return -EINVAL;
+
+ /* Release it by writing 0 to it */
+ writel(0, handle-lock_reg);
[[Yogesh Marathe]] Releasing the spinlock without knowing who owns it is
risky. There should be a check for ownership and if authenticated user has
called this api only then it should be released otherwise permission
denied error should be returned.
-- I think if there is another Kernel client that is trying to release that is
not owned by it then that Kernel client itself is buggy and needs to be fixed.
Please share your thoughts on how we can ensure that we can add some protection.
Yes, I think so as well. The hwspinlock itself was done to be simple.
The HW is not even checking that the processor that is taking the
spinlock is the one that will release it.
This is maybe not the ideal and safe way to do that, but I'm not sure
that we need to add some more complexity than needed for such a basic IP.
BTW, is a Linux kernel spinlock taking care of ownership?
Benoit
+
+ pm_runtime_put(handle-pdev-dev);
+
+ return 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
RE: [PATCH 3/5] omap:hwspinlock-added hwspinlock driver
Sanjeev, Thanks for your comments. -Original Message- From: Premi, Sanjeev Sent: Wednesday, July 28, 2010 11:58 AM To: Kanigeri, Hari; Linux Omap; Tony Lindgren Cc: Shilimkar, Santosh; Cousson, Benoit; Que, Simon Subject: RE: [PATCH 3/5] omap:hwspinlock-added hwspinlock driver -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kanigeri, Hari Sent: Monday, July 19, 2010 10:20 PM To: Linux Omap; Tony Lindgren Cc: Shilimkar, Santosh; Cousson, Benoit; Que, Simon; Kanigeri, Hari Subject: [PATCH 3/5] omap:hwspinlock-added hwspinlock driver From: Simon Que s...@ti.com Created driver for OMAP hardware spinlock. This driver supports: - Reserved spinlocks for internal use [sp] How do we reserver the spinlocks? I didn't see any API or parameter used to reserve them. If this refers to hwspinlock_request_specific(), then it isn't really reservation. Reservation is usually is blocks and I would expect range input. hwspinlock_request_specific() is the one. If you want range you can either call hwspinlock_request_specific() in a loop or we can create a new function to handle it. It shouldn't be difficult to add a new function to reserve range of spinlocks but I would rather wait till we hit that use-case. How is this reservation made known to other processors who would be attempting to use these spinlocks - in a multi processor scenario e.g. OMAP4. Both processors need to be aware of this reservation. This should be handled either: - Based on pre-agreement on what spinlock should be used by its counter-part on Co-Processor. - Communicate this information using IPC call. - Dynamic allocation of unreserved locks - Lock, unlock, and trylock functions, with or without disabling irqs/preempt - Registered as a platform device driver The device initialization uses hwmod to configure the devices. One device will be created for each IP. It will pass spinlock register offset info to the driver. The device initialization file is: arch/arm/mach-omap2/hwspinlocks.c The driver takes in register offset info passed in device initialization. It uses hwmod to obtain the base address of the hardware spinlock module. Then it reads info from the registers. The function hwspinlock_probe() initializes the array of spinlock structures, each containing a spinlock register address calculated from the base address and lock offsets. The device driver file is: arch/arm/plat-omap/hwspinlock.c Here's an API summary: int hwspinlock_lock(struct hwspinlock *); Attempt to lock a hardware spinlock. If it is busy, the function will keep trying until it succeeds. This is a blocking function. int hwspinlock_trylock(struct hwspinlock *); Attempt to lock a hardware spinlock. If it is busy, the function will return BUSY. If it succeeds in locking, the function will return ACQUIRED. This is a non-blocking function. int hwspinlock_unlock(struct hwspinlock *); Unlock a hardware spinlock. struct hwspinlock *hwspinlock_request(void); Provides for dynamic allocation of a hardware spinlock. It returns the handle to the next available (unallocated) spinlock. If no more locks are available, it returns NULL. struct hwspinlock *hwspinlock_request_specific(unsigned int); Provides for static allocation of a specific hardware spinlock. This allows the system to use a specific spinlock, identified by an ID. If the ID is invalid or if the desired lock is already allocated, this will return NULL. Otherwise it returns a spinlock handle. int hwspinlock_free(struct hwspinlock *); Frees an allocated hardware spinlock (either reserved or unreserved). Signed-off-by: Simon Que s...@ti.com Signed-off-by: Hari Kanigeri h-kanige...@ti.com --- arch/arm/mach-omap2/hwspinlocks.c| 70 ++ arch/arm/plat-omap/hwspinlock.c | 335 ++ arch/arm/plat-omap/include/plat/hwspinlock.h | 29 +++ 3 files changed, 434 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/hwspinlocks.c create mode 100644 arch/arm/plat-omap/hwspinlock.c create mode 100644 arch/arm/plat-omap/include/plat/hwspinlock.h diff --git a/arch/arm/mach-omap2/hwspinlocks.c b/arch/arm/mach-omap2/hwspinlocks.c new file mode 100644 index 000..f0f05e1 --- /dev/null +++ b/arch/arm/mach-omap2/hwspinlocks.c @@ -0,0 +1,70 @@ +/* + * OMAP hardware spinlock device initialization + * + * Copyright (C) 2010 Texas Instruments. All rights reserved. + * + * Contact: Simon Que s...@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
Re: [PATCH 3/5] omap:hwspinlock-added hwspinlock driver
Kanigeri, Hari had written, on 07/19/2010 11:50 AM, the following: From: Simon Que s...@ti.com Created driver for OMAP hardware spinlock. This driver supports: - Reserved spinlocks for internal use - Dynamic allocation of unreserved locks - Lock, unlock, and trylock functions, with or without disabling irqs/preempt - Registered as a platform device driver The device initialization uses hwmod to configure the devices. One device will be created for each IP. It will pass spinlock register offset info to the driver. The device initialization file is: arch/arm/mach-omap2/hwspinlocks.c The driver takes in register offset info passed in device initialization. It uses hwmod to obtain the base address of the hardware spinlock module. Then it reads info from the registers. The function hwspinlock_probe() initializes the array of spinlock structures, each containing a spinlock register address calculated from the base address and lock offsets. The device driver file is: arch/arm/plat-omap/hwspinlock.c just a curious question: Is there no h/w spinlock implementation for other architectures in linux? I mean the concept does not seem unique for a heterogenous processor environments now a days.. if it does exist, maybe we have two options: * extend standard spinlock architecture to handle h/w spinlocks as well * establish a new framework for h/w spinlocks.. [...] -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/20] mmc: support embedded data field in mmc_host
Hi Ohad, On Thu, Jul 29, 2010 at 8:00 AM, Ohad Ben-Cohen o...@wizery.com wrote: To my understanding, this data doesn't belong to mmc_host. It's not a host data at all. E. g. imagine a GPIO IRQ for some SDIO chip -- it's totally unrelated to host. I think a cleaner way would be to introduce something similar to what we have for SPI, e. g. struct sdio_board_info. This board info will contain platform-specific stuff and vendor id/chip id for each onboard SDIO device. Then the SDIO core will pick up the appropriate data basing on vendor id/chip id. Can you please elaborate some more about your proposal (specifically where does this sdio_board_info get set and how do function drivers access it) ? If I understand you correctly, you suggest to have a global, board-specific table of sdio_board_info structures, which would be accessible to the SDIO core (through the host driver ?). When a new SDIO device is found the core would search this table for the appropriate sdio_board_info struct and make it accessible to the SDIO function driver ? Well, let's look at how it's implemented for SPI. There is the function spi_register_board_info in the SPI core which copies the board info into the local data structure (a linked list, actually). Whenever needed, the core walks through the list to find the appropriate board_info basing on some search key. I think this may be the way to go for SDIO as well. ~Vitaly -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] twl4030 reboot workaround
Hi
On Thu, Jul 29, 2010 at 9:41 AM, Mikko Rapeli
ext-mikko.rap...@nokia.com wrote:
From: Mikko Rapeli ext-mikko.rap...@nokia.com
Original patch: http://marc.info/?l=linux-omapm=126522625032441w=2
Removes TWL4030 sleep script prior to rebooting, only on OMAP3. This is
necessary since DPLL3 reset causes SYS_OFFMODE pin to go low, resulting
in the sleep script being executed on TWL4030. This usually results in
VDD1 VDD2 voltage collapse while ROM code is executing, followed by an
MPU Watch Dog reset or worse, an irrecoverable hang.
I had a similar issue when my system hanged on hard reset when there
was a TWL sleep script installed.
The workaround I've found was to install the sleep script immediately
before entering the suspend state and remove the script on the resume
path.
If you think that such approach is appropriate I can send a patch.
Original patch resulted in a crash due to sleeping i2c calls late in the
reboot sequence. Here's how to trigger the crash:
# cat /dev/urandom /foo
sync();
reboot(LINUX_REBOOT_CMD_RESTART2);
Kernel trace from 2.6.32:
Unable to handle kernel NULL pointer dereference at virtual address
pgd = c0004000
[] *pgd=
Internal error: Oops: 805 [#2] PREEMPT
...
[c00b3210] (exit_mmap+0x1d4/0x1f8) from [c006069c] (mmput+0x34/0x110)
[c006069c] (mmput+0x34/0x110) from [c0064a90] (exit_mm+0x140/0x180)
[c0064a90] (exit_mm+0x140/0x180) from [c00668ec] (do_exit+0x5d8/0x6ac)
[c00668ec] (do_exit+0x5d8/0x6ac) from [c0035858] (die+0x2d4/0x2e0)
[c0035858] (die+0x2d4/0x2e0) from [c0035904] (baddataabort+0x0/0x50)
[c0035904] (baddataabort+0x0/0x50) from [c0274ff4]
(i2c_transfer+0xec/0x104)
[c0274ff4] (i2c_transfer+0xec/0x104) from [0001] (0x1)
Fix is to move reboot preparations into a reboot notifier.
Signed-off-by: Mikko Rapeli ext-mikko.rap...@nokia.com
Acked-by: Mike Turquette mturque...@ti.com
---
v2: added a new line after variable declarations
v1: http://marc.info/?l=linux-omapm=128031011323970w=2
drivers/mfd/twl4030-power.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 7efa878..5c6da1e 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -28,6 +28,7 @@
#include linux/pm.h
#include linux/i2c/twl.h
#include linux/platform_device.h
+#include linux/reboot.h
#include asm/mach-types.h
@@ -127,6 +128,30 @@ static u8 res_config_addrs[] = {
[RES_Main_Ref] = 0x94,
};
+/*
+ * PRCM on OMAP3 will drive SYS_OFFMODE low during DPLL3 warm reset.
+ * This causes Gaia sleep script to execute, usually killing VDD1 and
+ * VDD2 while code is running. WA is to disable the sleep script
+ * before warm reset.
+ */
+static int twl4030_prepare_for_reboot(struct notifier_block *this,
+ unsigned long cmd, void *p)
+{
+ int err;
+
+ err = twl4030_remove_script(TWL4030_SLEEP_SCRIPT);
+ if (err)
+ pr_err(TWL4030: error trying to disable sleep script!\n);
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block twl4030_reboot_notifier = {
+ .notifier_call = twl4030_prepare_for_reboot,
+ .next = NULL,
+ .priority = 0
+};
+
static int __init twl4030_write_script_byte(u8 address, u8 byte)
{
int err;
@@ -549,6 +574,11 @@ void __init twl4030_power_init(struct twl4030_power_data
*twl4030_scripts)
err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0, R_PROTECT_KEY);
if (err)
pr_err(TWL4030 Unable to relock registers\n);
+
+ err = register_reboot_notifier(twl4030_reboot_notifier);
+ if (err)
+ pr_err(TWL4030 Failed to register reboot notifier\n);
+
return;
unlock:
--
1.5.6.5
--
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
--
Sincerely Yours,
Mike.
--
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/1] DSPBRIDGE: cache operation against kernel address instead of user's
On Thu, Jul 29, 2010 at 10:08 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
On Sun, 25 Jul 2010 22:10:32 +0200
ext Felipe Contreras felipe.contre...@gmail.com wrote:
On Fri, Nov 6, 2009 at 3:34 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
@@ -690,14 +732,19 @@ static int memory_check_vma(unsigned long start, u32
len)
if (end = start)
return -EINVAL;
- down_read(current-mm-mmap_sem);
-
while ((vma = find_vma(current-mm, start)) != NULL) {
+ ssize_t size;
- if (vma-vm_start start) {
- err = -EINVAL;
+ if (vma-vm_flags (VM_IO | VM_PFNMAP))
+ return -EINVAL;
+
+ if (vma-vm_start start)
+ return -EINVAL;
+
+ size = min_t(ssize_t, vma-vm_end - start, len);
This 'len' is the total length, which is not what we want; in each
iteration the length should be decreased so that it's always the
remaining length. Right?
len -= size;
Great finding and I'm so sorry for this bug...
All right, thanks for confirming :)
--
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
OMAP DSS2 coming out of OFF mode without restoring context
Hi, I'm having a problem where the DSS driver isn't restoring the framebuffer parameters after going in and out of blanking with OFF mode enabled. The problem appears to be in dss_get_ctx_id() in that pdata-get_last_off_on_transaction_id is 0. Commenting out the call to dss_need_ctx_restore() in dss_clk_enable() appears to do the right thing. I'm using the current master branch of linux-omap. -- Laine Walker-Avina Firmware Engineer PASCO scientific -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] OMAP: Make set_gpmc_timing_reg aware of the TIMEPARAGRANULARITY flag
This patch modifies the math used to convert clock ticks to nanoseconds
so that it is aware of the effect of the TIMEPARAGRANULARITY flag which
acts as a divide by 2 to the GPMC timing registers. This enables the use
of slower devices on the GPMC bus.
---
arch/arm/mach-omap2/gpmc.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5bc3ca0..6c3a786 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -171,12 +171,15 @@ static int set_gpmc_timing_reg(int cs, int reg, int
st_bit, int end_bit,
#endif
{
u32 l;
- int ticks, mask, nr_bits;
+ int ticks, mask, nr_bits, para_gran;
+
+ para_gran = (gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1)
+ GPMC_CONFIG1_TIME_PARA_GRAN ? 2:1);
if (time == 0)
ticks = 0;
else
- ticks = gpmc_ns_to_ticks(time);
+ ticks = gpmc_ns_to_ticks(time/para_gran);
nr_bits = end_bit - st_bit + 1;
if (ticks = 1 nr_bits) {
#ifdef DEBUG
@@ -191,8 +194,8 @@ static int set_gpmc_timing_reg(int cs, int reg, int st_bit,
int end_bit,
#ifdef DEBUG
printk(KERN_INFO
GPMC CS%d: %-10s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n,
- cs, name, ticks, gpmc_get_fclk_period() * ticks / 1000,
- (l st_bit) mask, time);
+ cs, name, ticks, gpmc_get_fclk_period() * para_gran *
+ ticks / 1000, (l st_bit) mask, time);
#endif
l = ~(mask st_bit);
l |= ticks st_bit;
--
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 01/11] OMAP: DMA: Introduce DMA device attributes
-Original Message-
From: Cousson, Benoit
Sent: Thursday, July 29, 2010 6:06 PM
To: G, Manjunath Kondaiah
Cc: linux-omap@vger.kernel.org; Kevin Hilman; Paul Walmsley;
Tony Lindgren; Sawant, Anand; Shilimkar, Santosh; Nayak,
Rajendra; Basak, Partha; Varadarajan, Charulatha
Subject: Re: [PATCH 01/11] OMAP: DMA: Introduce DMA device attributes
Hi Manjunatha,
I just have a couple of minor comments.
On 7/29/2010 11:58 AM, G, Manjunath Kondaiah wrote:
This patches introduces OMAP DMA device attributes for
using the same in
DMA platform driver for all OMAP's and HWMOD
database(OMAP2PLUS onwards)
Signed-off-by: Manjunatha GKmanj...@ti.com
---
arch/arm/plat-omap/include/plat/dma.h | 22
++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index 02232ca..ff60f11 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -398,6 +398,22 @@
#define DMA_CH_PRIO_HIGH 0x1
#define DMA_CH_PRIO_LOW 0x0 /* Def */
+/* Attributes for OMAP DMA Contrllers */
+#define ENABLE_1510_MODE (1 0)
+#define DMA_LINKED_LCH (1 1)
+#define GLOBAL_PRIORITY(1 2)
+#define RESERVE_CHANNEL(1 3)
+#define SRC_PORT (2 3)
+#define DST_PORT (2 4)
+#define IS_CSSA_32 (2 5)
+#define IS_CDSA_32 (2 6)
+#define SRC_INDEX (4 6)
+#define DST_INDEX (4 7)
+#define IS_BURST_ONLY4 (4 8)
+#define CLEAR_CSR_ON_READ (4 9)
+#define IS_WORD_16 (8 9)
+#define IS_RW_PRIORIY (8 0xA)
It is a minor detail, but why are you shifting both side of the
operator? It is really confusing, cannot you just do 1 X?
With 0 X 13.
I can change this if it is confusing to others.
+
enum omap_dma_burst_mode {
OMAP_DMA_DATA_BURST_DIS = 0,
OMAP_DMA_DATA_BURST_4,
@@ -463,6 +479,12 @@ struct omap_dma_channel_params {
#endif
};
+struct omap_dma_dev_attr {
+ u32 dma_dev_attr;
That name is not very meaningful, maybe dma_cap for capability or
something else will be better.
Makes sense. I will change this also.
+ u16 dma_lch_count;
+ u16 dma_chan_count;
+ struct omap_dma_lch *dma_chan;
In general, I think that there are too many dma_ prefix in that
structure. It is already inside a dma_XXX struct so I don't
think that
adding an extra prefix to every attribute is needed.
These variables are part of legacy code which I used as is.
I can remove these prefixes.
-Manjunath
--
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 resend 11/11] sDMA: descriptor autoloading feature
From: Venkatraman S svenk...@ti.com
Add sDMA driver support for descriptor autoloading feature.
Descriptor autoloading is OMAP sDMA v5 hardware capability that can be exploited
for scatter gather scenarios, currently available in OMAP3630 and OMAP4430.
The feature works as described below.
1. A sDMA channel is programmed to be in 'linked list' mode.
2) The client (sDMA user) provides a list of descriptors in a linked list format
3) Each of the 'descriptor' (element in the linked list) contains an updated set
of DMA configuration register values.
4) Client starts DMA transfer.
5) sDMA controller loads the first element to its register configuration memory
and executes the transfer.
6) After completion, loads the next element (in linked list) to configuration
memory and executes the transfer, without MCU intervention.
7) Interrupt is generated after all transfers are completed; this can be
configured to be done differently.
Configurations and additional features
1) Fast mode non-fast mode
Fast mode/non-fast decides on how the first transfer begins. In non-fast mode,
the first element in the linked list is loaded only after completing the
transfer according to the configurations already in the sDMA channel registers.
In fast mode, the loading of the first element precedes the transfer.
2) Pause / resume of transfers
A transfer can be paused after a descriptor set has been loaded, provided the
pause bit' is set in the linked list element.
An ongoing transfer cannot be paused. If the 'pause bit' is set, transfer is not
started after loading the register set from memory.
Such a transfer can be resumed later.
3) Descriptor types
Three possible configurations of descriptors (initialized as linked list
elements) are possible.
Type 1 provides the maximum flexibility, which contains most register
definitions of a DMA logical channel.
Fewer options are present in type 2.
Type 3 can just modify source/destinations address of transfers. In all
transfers, unmodified registers settings are maintained for the next transfer.
Patch provides options / API for
1) Setting up a descriptor loading for DMA channel for sg type transfers
2) configuration with linked list elements
3) Starting / pause and resume of the said transfers, query state
4) Clearing the sglist mode
Signed-off-by: Venkatraman S svenk...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
---
arch/arm/mach-omap1/dma.c |5 +
arch/arm/mach-omap1/include/mach/dma.h |2 +
arch/arm/mach-omap2/dma.c | 254
arch/arm/mach-omap2/include/mach/dma.h | 194
arch/arm/plat-omap/dma.c |1 +
5 files changed, 456 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index eadc160..1f10f62 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -304,6 +304,11 @@ void omap_dma_set_global_params(int arb_rate, int
max_fifo_depth, int tparams)
}
EXPORT_SYMBOL(omap_dma_set_global_params);
+void omap_clear_dma_sglist_mode(int lch)
+{
+ return;
+}
+
static int __init omap1_system_dma_init(void)
{
struct platform_device *pdev;
diff --git a/arch/arm/mach-omap1/include/mach/dma.h
b/arch/arm/mach-omap1/include/mach/dma.h
index 1eb0d31..afe486b 100644
--- a/arch/arm/mach-omap1/include/mach/dma.h
+++ b/arch/arm/mach-omap1/include/mach/dma.h
@@ -143,4 +143,6 @@ struct omap_dma_lch {
long flags;
};
+/* Dummy function */
+extern void omap_clear_dma_sglist_mode(int lch);
#endif /* __ASM_ARCH_OMAP1_DMA_H */
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index 390c428..c24ed00 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -204,6 +204,77 @@ static void dma_ocpsysconfig_errata(u32 *sys_cf, bool flag)
dma_write(*sys_cf, OCP_SYSCONFIG);
}
+static inline void omap_dma_list_set_ntype(struct omap_dma_sglist_node *node,
+ int value)
+{
+ node-num_of_elem |= ((value) 29);
+}
+
+static void omap_set_dma_sglist_pausebit(
+ struct omap_dma_list_config_params *lcfg, int nelem, int set)
+{
+ struct omap_dma_sglist_node *sgn = lcfg-sghead;
+
+ if (nelem 0 nelem lcfg-num_elem) {
+ lcfg-pausenode = nelem;
+ sgn += nelem;
+
+ if (set)
+ sgn-next_desc_add_ptr |= DMA_LIST_DESC_PAUSE;
+ else
+ sgn-next_desc_add_ptr = ~(DMA_LIST_DESC_PAUSE);
+ }
+}
+
+static int dma_sglist_set_phy_params(struct omap_dma_sglist_node *sghead,
+ dma_addr_t phyaddr, int nelem)
+{
+ struct omap_dma_sglist_node *sgcurr, *sgprev;
+ dma_addr_t elem_paddr = phyaddr;
+
+ for (sgprev = sghead;
+ sgprev sghead + nelem;
+ sgprev++) {
+
+ sgcurr = sgprev + 1;
+ sgprev-next = sgcurr;
+
Re: [PATCH v2] twl4030 reboot workaround
On Thu, Jul 29, 2010 at 09:10:43PM +0200, ext Mike Rapoport wrote: On Thu, Jul 29, 2010 at 9:41 AM, Mikko Rapeli ext-mikko.rap...@nokia.com wrote: From: Mikko Rapeli ext-mikko.rap...@nokia.com Original patch: http://marc.info/?l=linux-omapm=126522625032441w=2 Removes TWL4030 sleep script prior to rebooting, only on OMAP3. This is necessary since DPLL3 reset causes SYS_OFFMODE pin to go low, resulting in the sleep script being executed on TWL4030. This usually results in VDD1 VDD2 voltage collapse while ROM code is executing, followed by an MPU Watch Dog reset or worse, an irrecoverable hang. I had a similar issue when my system hanged on hard reset when there was a TWL sleep script installed. The workaround I've found was to install the sleep script immediately before entering the suspend state and remove the script on the resume path. If you think that such approach is appropriate I can send a patch. Yes, I think this patch would be a good idea too since it fixes a real issue. -Mikko -- 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
