From nsekhar at ti.com  Mon Feb  1 00:05:17 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 1 Feb 2010 11:35:17 +0530
Subject: [PATCH v3 1/2] i2c: Add SDA and SCL pin numbers to i2c platform
	data
In-Reply-To: <1263295031.3437.16.camel@localhost.localdomain>
References: <1263295031.3437.16.camel@localhost.localdomain>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E235A3DA@dbde02.ent.ti.com>

Hi Philby,

On Tue, Jan 12, 2010 at 16:47:11, Philby John wrote:
> >From cb3347e45449ff16a332aa164eae24ef6a2432e6 Mon Sep 17 00:00:00 2001
> From: Philby John <pjohn at in.mvista.com>
> Date: Mon, 11 Jan 2010 15:53:31 +0530
> Subject: [PATCH 1/2] Add SDA and SCL pin numbers to i2c platform data
>
> Patch adds SDA and SCL pin numbers to the i2c platform data
> structure for Davinci DM355 and DM6446. This at present is
> used for i2c bus recovery.
> TODO: Add SDA and SCL pin number information to include all
> Davinci platforms such as dm355-leopard, dm365, dm646x, da8xx etc.
>
> Signed-off-by: Philby John <pjohn at in.mvista.com>
> ---
>  arch/arm/mach-davinci/board-dm355-evm.c  |    2 ++
>  arch/arm/mach-davinci/board-dm644x-evm.c |    2 ++
>  arch/arm/mach-davinci/include/mach/i2c.h |    2 ++
>  3 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
> index 077ecf4..aa48e3f 100644
> --- a/arch/arm/mach-davinci/board-dm355-evm.c
> +++ b/arch/arm/mach-davinci/board-dm355-evm.c
> @@ -111,6 +111,8 @@ static struct platform_device davinci_nand_device = {
>  static struct davinci_i2c_platform_data i2c_pdata = {
>       .bus_freq       = 400   /* kHz */,
>       .bus_delay      = 0     /* usec */,
> +     .sda_pin        = 15,
> +     .scl_pin        = 14,
>  };
>
>  static struct snd_platform_data dm355_evm_snd_data;
> diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
> index e9612cf..976e11b 100644
> --- a/arch/arm/mach-davinci/board-dm644x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
> @@ -629,6 +629,8 @@ static struct i2c_board_info __initdata i2c_info[] =  {
>  static struct davinci_i2c_platform_data i2c_pdata = {
>       .bus_freq       = 20 /* kHz */,
>       .bus_delay      = 100 /* usec */,
> +     .sda_pin        = 44,
> +     .scl_pin        = 43,
>  };
>
>  static void __init evm_init_i2c(void)
> diff --git a/arch/arm/mach-davinci/include/mach/i2c.h b/arch/arm/mach-davinci/include/mach/i2c.h
> index c248e9b..39fdcea 100644
> --- a/arch/arm/mach-davinci/include/mach/i2c.h
> +++ b/arch/arm/mach-davinci/include/mach/i2c.h
> @@ -16,6 +16,8 @@
>  struct davinci_i2c_platform_data {
>       unsigned int    bus_freq;       /* standard bus frequency (kHz) */
>       unsigned int    bus_delay;      /* post-transaction delay (usec) */
> +     unsigned int    sda_pin;        /* GPIO pin ID to use for SDA */

It doesn't look like you need the SDA pin to be
a GPIO in patch 2/2 - can you drop it from platform
data in that case?

Thanks,
Sekhar

> +     unsigned int    scl_pin;        /* GPIO pin ID to use for SCL */
>  };
>
>  /* for board setup code */
> --
> 1.6.3.3.MVISTA
>
>
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>


From rohan_javed at yahoo.co.uk  Mon Feb  1 05:28:12 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Mon, 1 Feb 2010 03:28:12 -0800 (PST)
Subject: Problem using u-boot loadb command
Message-ID: <75017.81250.qm@web24105.mail.ird.yahoo.com>

hello everyone I am using DM6446 have made our own custom board for some reasons have not used the ethernet interface in our design so i have to flash the uImage(kernel) image and the filesystem by transferring using the loadb command in the u-boot but when i load the binary using the loadb command and try to tranfer it using kermit mode it gets no response and finally i get a dialogue box error limit exceeds


Anyone encountered this kind of error

Regard's
Rohan Tabish



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100201/33498479/attachment.html>

From tarkandogu at gmail.com  Mon Feb  1 08:42:37 2010
From: tarkandogu at gmail.com (Tarkan DOGU)
Date: Mon, 1 Feb 2010 16:42:37 +0200
Subject: Is 6446 supporting TS MPEG2 packet decoding?
Message-ID: <bb0fe03d1002010642j7dc79904g1a6364c9047fc8c9@mail.gmail.com>

Hi All,

 I need a basic knowledge about TI 6446 current status. I need to decode a
MPEG2 TS  formatted packets  over the network. Does the TI 6446
software/firmware support this type of decoding? As far as I can see from
the demo scripts, It seems there are  support  only H.264 TS  formatted
packets.
Could u please pass a detail information about it?

Thanks in advance...
B.R
Tarkan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100201/7ab3ccde/attachment.html>

From s-paulraj at ti.com  Mon Feb  1 08:51:02 2010
From: s-paulraj at ti.com (s-paulraj at ti.com)
Date: Mon,  1 Feb 2010 09:51:02 -0500
Subject: [PATCH 1/4] TI DaVinci: Adding header file for SPI support.
Message-ID: <1265035862-12259-1-git-send-email-s-paulraj@ti.com>

From: Sandeep Paulraj <s-paulraj at ti.com>

This patch adds "spi.h" header file that will be used by board and
architecture specific code.

Signed-off-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/include/mach/spi.h |   44 ++++++++++++++++++++++++++++++
 1 files changed, 44 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-davinci/include/mach/spi.h

diff --git a/arch/arm/mach-davinci/include/mach/spi.h b/arch/arm/mach-davinci/include/mach/spi.h
new file mode 100644
index 0000000..910efbf
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/spi.h
@@ -0,0 +1,44 @@
+/*
+ * Copyright 2009 Texas Instruments.
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __ARCH_ARM_DAVINCI_SPI_H
+#define __ARCH_ARM_DAVINCI_SPI_H
+
+enum {
+	SPI_VERSION_1, /* For DM355/DM365/DM6467 */
+	SPI_VERSION_2, /* For DA8xx */
+};
+
+struct davinci_spi_platform_data {
+	u8	version;
+	u8	num_chipselect;
+	u8	wdelay;
+	u8	odd_parity;
+	u8	parity_enable;
+	u8	wait_enable;
+	u8	timer_disable;
+	u8	clk_internal;
+	u8	cs_hold;
+	u8	intr_level;
+	u8	poll_mode;
+	u8	use_dma;
+	u8	c2tdelay;
+	u8	t2cdelay;
+};
+
+#endif	/* __ARCH_ARM_DAVINCI_SPI_H */
-- 
1.6.0.4


From s-paulraj at ti.com  Mon Feb  1 08:51:15 2010
From: s-paulraj at ti.com (s-paulraj at ti.com)
Date: Mon,  1 Feb 2010 09:51:15 -0500
Subject: [PATCH 2/4] DaVinci DM355: Modifications to DM355 SPI support
Message-ID: <1265035875-12290-1-git-send-email-s-paulraj@ti.com>

From: Sandeep Paulraj <s-paulraj at ti.com>

This patch does the following

1) Minor change to the SPI clocks making it
similar to DM365.
2) Changing the interrupt used by SPI0
3) Adding EDMA resources that can be used by SPI0
4) Adding platform specific data.

Signed-off-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/dm355.c |   39 ++++++++++++++++++++++++++++-----------
 1 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 682fc18..3dc0a88 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -29,6 +29,7 @@
 #include <mach/serial.h>
 #include <mach/common.h>
 #include <mach/asp.h>
+#include <mach/spi.h>
 
 #include "clock.h"
 #include "mux.h"
@@ -362,9 +363,9 @@ static struct clk_lookup dm355_clks[] = {
 	CLK("davinci-asp.1", NULL, &asp1_clk),
 	CLK("davinci_mmc.0", NULL, &mmcsd0_clk),
 	CLK("davinci_mmc.1", NULL, &mmcsd1_clk),
-	CLK(NULL, "spi0", &spi0_clk),
-	CLK(NULL, "spi1", &spi1_clk),
-	CLK(NULL, "spi2", &spi2_clk),
+	CLK("spi_davinci.0", NULL, &spi0_clk),
+	CLK("spi_davinci.1", NULL, &spi1_clk),
+	CLK("spi_davinci.2", NULL, &spi2_clk),
 	CLK(NULL, "gpio", &gpio_clk),
 	CLK(NULL, "aemif", &aemif_clk),
 	CLK(NULL, "pwm0", &pwm0_clk),
@@ -391,24 +392,40 @@ static struct resource dm355_spi0_resources[] = {
 		.flags = IORESOURCE_MEM,
 	},
 	{
-		.start = IRQ_DM355_SPINT0_1,
+		.start = IRQ_DM355_SPINT0_0,
 		.flags = IORESOURCE_IRQ,
 	},
-	/* Not yet used, so not included:
-	 * IORESOURCE_IRQ:
-	 *  - IRQ_DM355_SPINT0_0
-	 * IORESOURCE_DMA:
-	 *  - DAVINCI_DMA_SPI_SPIX
-	 *  - DAVINCI_DMA_SPI_SPIR
-	 */
+	{
+		.start = 17,
+		.flags = IORESOURCE_DMA,
+	},
+	{
+		.start = 16,
+		.flags = IORESOURCE_DMA,
+	},
+	{
+		.start = EVENTQ_1,
+		.flags = IORESOURCE_DMA,
+	},
 };
 
+static struct davinci_spi_platform_data dm355_spi0_pdata = {
+	.version 	= SPI_VERSION_1,
+	.num_chipselect = 2,
+	.clk_internal	= 1,
+	.cs_hold	= 1,
+	.intr_level	= 0,
+	.poll_mode	= 1,	/* 0 -> interrupt mode 1-> polling mode */
+	.c2tdelay	= 0,
+	.t2cdelay	= 0,
+};
 static struct platform_device dm355_spi0_device = {
 	.name = "spi_davinci",
 	.id = 0,
 	.dev = {
 		.dma_mask = &dm355_spi0_dma_mask,
 		.coherent_dma_mask = DMA_BIT_MASK(32),
+		.platform_data = &dm355_spi0_pdata,
 	},
 	.num_resources = ARRAY_SIZE(dm355_spi0_resources),
 	.resource = dm355_spi0_resources,
-- 
1.6.0.4


From s-paulraj at ti.com  Mon Feb  1 08:51:31 2010
From: s-paulraj at ti.com (s-paulraj at ti.com)
Date: Mon,  1 Feb 2010 09:51:31 -0500
Subject: [PATCH 3/4] DaVinci DM365: Adding DM365 SPI support
Message-ID: <1265035891-12322-1-git-send-email-s-paulraj@ti.com>

From: Sandeep Paulraj <s-paulraj at ti.com>

This patch adds SPI init for DM365.
It does the following
1) Initializes SPI0
2) Defines resources to be used by SPI0
3) Adds platform data for SPI0


Signed-off-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/dm365.c              |   70 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/dm365.h |    2 +
 2 files changed, 72 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index c63afc0..4f41b7b 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -18,6 +18,7 @@
 #include <linux/platform_device.h>
 #include <linux/dma-mapping.h>
 #include <linux/gpio.h>
+#include <linux/spi/spi.h>
 
 #include <asm/mach/map.h>
 
@@ -32,6 +33,8 @@
 #include <mach/common.h>
 #include <mach/asp.h>
 #include <mach/keyscan.h>
+#include <mach/spi.h>
+
 
 #include "clock.h"
 #include "mux.h"
@@ -609,6 +612,73 @@ EVT_CFG(DM365,	EVT3_ASP_RX,         1,     1,    0,     false)
 #endif
 };
 
+static u64 dm365_spi0_dma_mask = DMA_BIT_MASK(32);
+
+static struct davinci_spi_platform_data dm365_spi0_pdata = {
+	.version 	= SPI_VERSION_1,
+	.num_chipselect = 2,
+	.clk_internal	= 1,
+	.cs_hold	= 1,
+	.intr_level	= 0,
+	.poll_mode	= 1,	/* 0 -> interrupt mode 1-> polling mode */
+	.c2tdelay	= 0,
+	.t2cdelay	= 0,
+};
+
+static struct resource dm365_spi0_resources[] = {
+	{
+		.start = 0x01c66000,
+		.end   = 0x01c667ff,
+		.flags = IORESOURCE_MEM,
+	},
+	{
+		.start = IRQ_DM365_SPIINT0_0,
+		.flags = IORESOURCE_IRQ,
+	},
+	{
+		.start = 17,
+		.flags = IORESOURCE_DMA,
+	},
+	{
+		.start = 16,
+		.flags = IORESOURCE_DMA,
+	},
+	{
+		.start = EVENTQ_3,
+		.flags = IORESOURCE_DMA,
+	},
+};
+
+static struct platform_device dm365_spi0_device = {
+	.name = "spi_davinci",
+	.id = 0,
+	.dev = {
+		.dma_mask = &dm365_spi0_dma_mask,
+		.coherent_dma_mask = DMA_BIT_MASK(32),
+		.platform_data = &dm365_spi0_pdata,
+	},
+	.num_resources = ARRAY_SIZE(dm365_spi0_resources),
+	.resource = dm365_spi0_resources,
+};
+
+void __init dm365_init_spi0(unsigned chipselect_mask,
+		struct spi_board_info *info, unsigned len)
+{
+	davinci_cfg_reg(DM365_SPI0_SCLK);
+	davinci_cfg_reg(DM365_SPI0_SDI);
+	davinci_cfg_reg(DM365_SPI0_SDO);
+
+	/* not all slaves will be wired up */
+	if (chipselect_mask & BIT(0))
+		davinci_cfg_reg(DM365_SPI0_SDENA0);
+	if (chipselect_mask & BIT(1))
+		davinci_cfg_reg(DM365_SPI0_SDENA1);
+
+	spi_register_board_info(info, len);
+
+	platform_device_register(&dm365_spi0_device);
+}
+
 static struct emac_platform_data dm365_emac_pdata = {
 	.ctrl_reg_offset	= DM365_EMAC_CNTRL_OFFSET,
 	.ctrl_mod_reg_offset	= DM365_EMAC_CNTRL_MOD_OFFSET,
diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h
index 3c07a88..6728317 100644
--- a/arch/arm/mach-davinci/include/mach/dm365.h
+++ b/arch/arm/mach-davinci/include/mach/dm365.h
@@ -35,5 +35,7 @@ void __init dm365_init(void);
 void __init dm365_init_asp(struct snd_platform_data *pdata);
 void __init dm365_init_ks(struct davinci_ks_platform_data *pdata);
 void __init dm365_init_rtc(void);
+void dm365_init_spi0(unsigned chipselect_mask,
+			struct spi_board_info *info, unsigned len);
 
 #endif /* __ASM_ARCH_DM365_H */
-- 
1.6.0.4


From s-paulraj at ti.com  Mon Feb  1 08:51:45 2010
From: s-paulraj at ti.com (s-paulraj at ti.com)
Date: Mon,  1 Feb 2010 09:51:45 -0500
Subject: [PATCH 4/4] DaVinci DM365: Adding support for SPI EEPROM
Message-ID: <1265035905-12356-1-git-send-email-s-paulraj@ti.com>

From: Sandeep Paulraj <s-paulraj at ti.com>

The DM365 Spectrum Digital EVM comes with an EEPROM
connected to SPI0.
This patch adds support for the SPI EEPROM.

Signed-off-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/board-dm365-evm.c |   23 +++++++++++++++++++++++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index 5c2636c..aab0755 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -24,6 +24,8 @@
 #include <linux/mtd/partitions.h>
 #include <linux/mtd/nand.h>
 #include <linux/input.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/eeprom.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -503,6 +505,24 @@ static void __init dm365_evm_map_io(void)
 	dm365_init();
 }
 
+static struct spi_eeprom at25640 = {
+	.byte_len	= SZ_64K / 8,
+	.name		= "at25640",
+	.page_size	= 32,
+	.flags		= EE_ADDR2,
+};
+
+static struct spi_board_info dm365_evm_spi_info[] __initconst = {
+	{
+		.modalias	= "at25",
+		.platform_data	= &at25640,
+		.max_speed_hz	= 10 * 1000 * 1000,
+		.bus_num	= 0,
+		.chip_select	= 0,
+		.mode		= SPI_MODE_0,
+	},
+};
+
 static __init void dm365_evm_init(void)
 {
 	evm_init_i2c();
@@ -519,6 +539,9 @@ static __init void dm365_evm_init(void)
 	dm365_init_asp(&dm365_evm_snd_data);
 	dm365_init_rtc();
 	dm365_init_ks(&dm365evm_ks_data);
+
+	dm365_init_spi0(BIT(0), dm365_evm_spi_info,
+			ARRAY_SIZE(dm365_evm_spi_info));
 }
 
 static __init void dm365_evm_irq_init(void)
-- 
1.6.0.4


From khilman at deeprootsystems.com  Mon Feb  1 13:40:01 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 01 Feb 2010 11:40:01 -0800
Subject: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E235A3C2@dbde02.ent.ti.com>
	(Sekhar Nori's message of "Mon\, 1 Feb 2010 11\:27\:15 +0530")
References: <1264549293-25556-1-git-send-email-khilman@deeprootsystems.com>
	<1264549293-25556-7-git-send-email-khilman@deeprootsystems.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E235A3C2@dbde02.ent.ti.com>
Message-ID: <87ljfchhim.fsf@deeprootsystems.com>

"Nori, Sekhar" <nsekhar at ti.com> writes:

> Hi Philby,
>
> On Wed, Jan 27, 2010 at 05:11:33, Kevin Hilman wrote:
>> From: Philby John <pjohn at in.mvista.com>
>>
>> Come out of i2c time out condition by following the
>> bus recovery procedure outlined in the i2c protocol v3 spec.
>> The kernel must be robust enough to gracefully recover
>> from i2c bus failure without having to reset the machine.
>> This is done by first NACKing the slave, pulsing the SCL
>> line 9 times and then sending the stop command.
>>
>> This patch has been tested on a DM6446 and DM355
>>
>> Signed-off-by: Philby John <pjohn at in.mvista.com>
>> Signed-off-by: Srinivasan, Nageswari <nageswari at ti.com>
>> Acked-by: Kevin Hilman <khilman at deeprootsystems.com>
>> ---
>>  drivers/i2c/busses/i2c-davinci.c |   57 +++++++++++++++++++++++++++++++++++--
>>  1 files changed, 53 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
>> index 35f9daa..5459065 100644
>> --- a/drivers/i2c/busses/i2c-davinci.c
>> +++ b/drivers/i2c/busses/i2c-davinci.c
>> @@ -36,6 +36,7 @@
>>  #include <linux/platform_device.h>
>>  #include <linux/io.h>
>>  #include <linux/cpufreq.h>
>> +#include <linux/gpio.h>
>>
>>  #include <mach/hardware.h>
>>  #include <mach/i2c.h>
>> @@ -43,6 +44,7 @@
>>  /* ----- global defines ----------------------------------------------- */
>>
>>  #define DAVINCI_I2C_TIMEOUT  (1*HZ)
>> +#define DAVINCI_I2C_MAX_TRIES        2
>>  #define I2C_DAVINCI_INTR_ALL    (DAVINCI_I2C_IMR_AAS | \
>>                                DAVINCI_I2C_IMR_SCD | \
>>                                DAVINCI_I2C_IMR_ARDY | \
>> @@ -130,6 +132,44 @@ static inline u16 davinci_i2c_read_reg(struct davinci_i2c_dev *i2c_dev, int reg)
>>       return __raw_readw(i2c_dev->base + reg);
>>  }
>>
>> +/* Generate a pulse on the i2c clock pin. */
>> +static void generic_i2c_clock_pulse(unsigned int scl_pin)
>> +{
>> +     u16 i;
>> +
>> +     if (scl_pin) {
>> +             /* Send high and low on the SCL line */
>> +             for (i = 0; i < 9; i++) {
>> +                     gpio_set_value(scl_pin, 0);
>> +                     udelay(20);
>> +                     gpio_set_value(scl_pin, 1);
>> +                     udelay(20);
>> +             }
>
> Before using the pins as GPIO, you would have to set the
> functionality of these pins as GPIO. You had this code in
> previous incarnations of this patch - not sure why it is
> dropped now.
>
> Couple of good to haves:
>
> It will be good to do a gpio_request() before using the pins
> as GPIO - though I can see it may have been deemed unnecessary
> - the pins are owned by I2C already - even so it may help catch
> system configuration errors in later platforms.
>
> The I2C peripheral on da8xx itself contains a mode where its
> pins could be used as GPIO - so no need for SoC level muxing
> and need for the platform data. This seems to be missing from
> DM355 though. Thankfully there is a revision id within the I2C
> memory map which will help you differentiate the two cases
> (revision 0x5 vs 0x6)
>

Philby,

Please update with comments from Sekhar soon so I can get this one queued
for 2.6.34.

Kevin


From nkansara at irvine-sensors.com  Mon Feb  1 15:49:42 2010
From: nkansara at irvine-sensors.com (Naresh Kansara)
Date: Mon, 1 Feb 2010 13:49:42 -0800
Subject: question on RAMDISK
Message-ID: <B4CC737B5C72E74A877F33104AD30A6002A8A6CA@excirvca2a.corp.irvine-sensors.com>

Hello All,

I have two questions.

1.	Is there a limit of 32MB on Ramdisk? I tried to use 64MB size
and I got some errors
2.	Has anybody tried to use two RAMDISK? If yes how to use two
ramdisk?

 

Thank you for your help.

Regards,

Naresh

 

 

Naresh Kansara

Irvine Sensors Corporation

phone: (714)-435-8928

email: nkansara at irvine-sensors.com

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100201/1712bf17/attachment.html>

From m-karicheri2 at ti.com  Mon Feb  1 16:27:13 2010
From: m-karicheri2 at ti.com (m-karicheri2 at ti.com)
Date: Mon,  1 Feb 2010 17:27:13 -0500
Subject: [PATCH v3 6/6] DaVinci - Adding platform & board changes for vpfe
	capture on DM365
Message-ID: <1265063238-29072-1-git-send-email-m-karicheri2@ti.com>

From: Murali Karicheri <m-karicheri2 at ti.com>

This patch adds following changes:-
	1) add sub device configuration data for TVP5146 used by vpfe capture
	2) registers platform devices for vpfe_capture, isif and vpss
	3) defines hardware resources for the devices listed under 2)
	4) defines clock aliase for isif driver
	5) adding setup_pinmux() for isif

Reviewed-by: Kevin Hilman <khilman at deeprootsystems.com>
Signed-off-by: Murali Karicheri <m-karicheri2 at ti.com>
---
Applies to linux-next of v4l-dvb
 - updated to add clock aliase (v3) and rebased to latest for merge
 - review comments incorporated (v2)
 arch/arm/mach-davinci/board-dm365-evm.c    |   71 +++++++++++++++++++
 arch/arm/mach-davinci/dm365.c              |  102 +++++++++++++++++++++++++++-
 arch/arm/mach-davinci/include/mach/dm365.h |    2 +
 3 files changed, 174 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index b476395..c216783 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -37,6 +37,8 @@
 #include <mach/nand.h>
 #include <mach/keyscan.h>
 
+#include <media/tvp514x.h>
+
 static inline int have_imager(void)
 {
 	/* REVISIT when it's supported, trigger via Kconfig */
@@ -306,6 +308,73 @@ static void dm365evm_mmc_configure(void)
 	davinci_cfg_reg(DM365_SD1_DATA0);
 }
 
+static struct tvp514x_platform_data tvp5146_pdata = {
+	.clk_polarity = 0,
+	.hs_polarity = 1,
+	.vs_polarity = 1
+};
+
+#define TVP514X_STD_ALL        (V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+	{
+		.index = 0,
+		.name = "Composite",
+		.type = V4L2_INPUT_TYPE_CAMERA,
+		.std = TVP514X_STD_ALL,
+	},
+	{
+		.index = 1,
+		.name = "S-Video",
+		.type = V4L2_INPUT_TYPE_CAMERA,
+		.std = TVP514X_STD_ALL,
+	},
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+	{
+		.input = INPUT_CVBS_VI2B,
+		.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+	},
+{
+		.input = INPUT_SVIDEO_VI2C_VI1C,
+		.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+	},
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+	{
+		.name = "tvp5146",
+		.grp_id = 0,
+		.num_inputs = ARRAY_SIZE(tvp5146_inputs),
+		.inputs = tvp5146_inputs,
+		.routes = tvp5146_routes,
+		.can_route = 1,
+		.ccdc_if_params = {
+			.if_type = VPFE_BT656,
+			.hdpol = VPFE_PINPOL_POSITIVE,
+			.vdpol = VPFE_PINPOL_POSITIVE,
+		},
+		.board_info = {
+			I2C_BOARD_INFO("tvp5146", 0x5d),
+			.platform_data = &tvp5146_pdata,
+		},
+	},
+};
+
+static struct vpfe_config vpfe_cfg = {
+       .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+       .sub_devs = vpfe_sub_devs,
+	.i2c_adapter_id = 1,
+       .card_name = "DM365 EVM",
+       .ccdc = "ISIF",
+};
+
 static void __init evm_init_i2c(void)
 {
 	davinci_init_i2c(&i2c_pdata);
@@ -497,6 +566,8 @@ static struct davinci_uart_config uart_config __initdata = {
 
 static void __init dm365_evm_map_io(void)
 {
+	/* setup input configuration for VPFE input devices */
+	dm365_set_vpfe_config(&vpfe_cfg);
 	dm365_init();
 }
 
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index f53735c..ce9da43 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1008,6 +1008,97 @@ void __init dm365_init(void)
 	davinci_common_init(&davinci_soc_info_dm365);
 }
 
+static struct resource dm365_vpss_resources[] = {
+	{
+		/* VPSS ISP5 Base address */
+		.name           = "isp5",
+		.start          = 0x01c70000,
+		.end            = 0x01c70000 + 0xff,
+		.flags          = IORESOURCE_MEM,
+	},
+	{
+		/* VPSS CLK Base address */
+		.name           = "vpss",
+		.start          = 0x01c70200,
+		.end            = 0x01c70200 + 0xff,
+		.flags          = IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device dm365_vpss_device = {
+       .name                   = "vpss",
+       .id                     = -1,
+       .dev.platform_data      = "dm365_vpss",
+       .num_resources          = ARRAY_SIZE(dm365_vpss_resources),
+       .resource               = dm365_vpss_resources,
+};
+
+static struct resource vpfe_resources[] = {
+	{
+		.start          = IRQ_VDINT0,
+		.end            = IRQ_VDINT0,
+		.flags          = IORESOURCE_IRQ,
+	},
+	{
+		.start          = IRQ_VDINT1,
+		.end            = IRQ_VDINT1,
+		.flags          = IORESOURCE_IRQ,
+	},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct platform_device vpfe_capture_dev = {
+	.name           = CAPTURE_DRV_NAME,
+	.id             = -1,
+	.num_resources  = ARRAY_SIZE(vpfe_resources),
+	.resource       = vpfe_resources,
+	.dev = {
+		.dma_mask               = &vpfe_capture_dma_mask,
+		.coherent_dma_mask      = DMA_BIT_MASK(32),
+	},
+};
+
+static void dm365_isif_setup_pinmux(void)
+{
+	davinci_cfg_reg(DM365_VIN_CAM_WEN);
+	davinci_cfg_reg(DM365_VIN_CAM_VD);
+	davinci_cfg_reg(DM365_VIN_CAM_HD);
+	davinci_cfg_reg(DM365_VIN_YIN4_7_EN);
+	davinci_cfg_reg(DM365_VIN_YIN0_3_EN);
+}
+
+static struct resource isif_resource[] = {
+	/* ISIF Base address */
+	{
+		.start          = 0x01c71000,
+		.end            = 0x01c71000 + 0x1ff,
+		.flags          = IORESOURCE_MEM,
+	},
+	/* ISIF Linearization table 0 */
+	{
+		.start          = 0x1C7C000,
+		.end            = 0x1C7C000 + 0x2ff,
+		.flags          = IORESOURCE_MEM,
+	},
+	/* ISIF Linearization table 1 */
+	{
+		.start          = 0x1C7C400,
+		.end            = 0x1C7C400 + 0x2ff,
+		.flags          = IORESOURCE_MEM,
+	},
+};
+static struct platform_device dm365_isif_dev = {
+	.name           = "isif",
+	.id             = -1,
+	.num_resources  = ARRAY_SIZE(isif_resource),
+	.resource       = isif_resource,
+	.dev = {
+		.dma_mask               = &vpfe_capture_dma_mask,
+		.coherent_dma_mask      = DMA_BIT_MASK(32),
+		.platform_data		= dm365_isif_setup_pinmux,
+	},
+};
+
 static int __init dm365_init_devices(void)
 {
 	if (!cpu_is_davinci_dm365())
@@ -1016,7 +1107,16 @@ static int __init dm365_init_devices(void)
 	davinci_cfg_reg(DM365_INT_EDMA_CC);
 	platform_device_register(&dm365_edma_device);
 	platform_device_register(&dm365_emac_device);
-
+	/* Add isif clock alias */
+	clk_add_alias("master", dm365_isif_dev.name, "vpss_master", NULL);
+	platform_device_register(&dm365_vpss_device);
+	platform_device_register(&dm365_isif_dev);
+	platform_device_register(&vpfe_capture_dev);
 	return 0;
 }
 postcore_initcall(dm365_init_devices);
+
+void dm365_set_vpfe_config(struct vpfe_config *cfg)
+{
+       vpfe_capture_dev.dev.platform_data = cfg;
+}
diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h
index f1710a3..9fc5a64 100644
--- a/arch/arm/mach-davinci/include/mach/dm365.h
+++ b/arch/arm/mach-davinci/include/mach/dm365.h
@@ -18,6 +18,7 @@
 #include <mach/emac.h>
 #include <mach/asp.h>
 #include <mach/keyscan.h>
+#include <media/davinci/vpfe_capture.h>
 
 #define DM365_EMAC_BASE			(0x01D07000)
 #define DM365_EMAC_CNTRL_OFFSET		(0x0000)
@@ -36,4 +37,5 @@ void __init dm365_init_asp(struct snd_platform_data *pdata);
 void __init dm365_init_ks(struct davinci_ks_platform_data *pdata);
 void __init dm365_init_rtc(void);
 
+void dm365_set_vpfe_config(struct vpfe_config *cfg);
 #endif /* __ASM_ARCH_DM365_H */
-- 
1.6.0.4


From m-karicheri2 at ti.com  Mon Feb  1 16:27:15 2010
From: m-karicheri2 at ti.com (m-karicheri2 at ti.com)
Date: Mon,  1 Feb 2010 17:27:15 -0500
Subject: [PATCH v3 1/6] V4L - vpfe capture - header files for ISIF driver
In-Reply-To: <1265063238-29072-2-git-send-email-m-karicheri2@ti.com>
References: <1265063238-29072-1-git-send-email-m-karicheri2@ti.com>
	<1265063238-29072-2-git-send-email-m-karicheri2@ti.com>
Message-ID: <1265063238-29072-3-git-send-email-m-karicheri2@ti.com>

From: Murali Karicheri <m-karicheri2 at ti.com>

This is the header file for ISIF driver on DM365.  ISIF driver is equivalent
to CCDC driver on DM355 and DM644x. This driver is tested for
YUV capture from TVP514x driver. This patch contains the header files required for
this driver. The name of the file is changed to reflect the name of IP.

Reviewed-by: Nori, Sekhar <nsekhar at ti.com>
Reviewed-by: Hans Verkuil <hverkuil at xs4all.nl>

Signed-off-by: Hans Verkuil <hverkuil at xs4all.nl> 
Signed-off-by: Muralidharan Karicheri <m-karicheri2 at ti.com>
---
Applies to linux-next tree of v4l-dvb
 - rebasing to latest for merge (v3) 
 - Updated based on comments against v1 of the patch (v2)
 drivers/media/video/davinci/isif_regs.h |  269 ++++++++++++++++
 include/media/davinci/isif.h            |  531 +++++++++++++++++++++++++++++++
 2 files changed, 800 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/isif_regs.h
 create mode 100644 include/media/davinci/isif.h

diff --git a/drivers/media/video/davinci/isif_regs.h b/drivers/media/video/davinci/isif_regs.h
new file mode 100644
index 0000000..f7b8893
--- /dev/null
+++ b/drivers/media/video/davinci/isif_regs.h
@@ -0,0 +1,269 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * 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
+ */
+#ifndef _ISIF_REGS_H
+#define _ISIF_REGS_H
+
+/* ISIF registers relative offsets */
+#define SYNCEN					0x00
+#define MODESET					0x04
+#define HDW					0x08
+#define VDW					0x0c
+#define PPLN					0x10
+#define LPFR					0x14
+#define SPH					0x18
+#define LNH					0x1c
+#define SLV0					0x20
+#define SLV1					0x24
+#define LNV					0x28
+#define CULH					0x2c
+#define CULV					0x30
+#define HSIZE					0x34
+#define SDOFST					0x38
+#define CADU					0x3c
+#define CADL					0x40
+#define LINCFG0					0x44
+#define LINCFG1					0x48
+#define CCOLP					0x4c
+#define CRGAIN 					0x50
+#define CGRGAIN					0x54
+#define CGBGAIN					0x58
+#define CBGAIN					0x5c
+#define COFSTA					0x60
+#define FLSHCFG0				0x64
+#define FLSHCFG1				0x68
+#define FLSHCFG2				0x6c
+#define VDINT0					0x70
+#define VDINT1					0x74
+#define VDINT2					0x78
+#define MISC 					0x7c
+#define CGAMMAWD				0x80
+#define REC656IF				0x84
+#define CCDCFG					0x88
+/*****************************************************
+* Defect Correction registers
+*****************************************************/
+#define DFCCTL					0x8c
+#define VDFSATLV				0x90
+#define DFCMEMCTL				0x94
+#define DFCMEM0					0x98
+#define DFCMEM1					0x9c
+#define DFCMEM2					0xa0
+#define DFCMEM3					0xa4
+#define DFCMEM4					0xa8
+/****************************************************
+* Black Clamp registers
+****************************************************/
+#define CLAMPCFG				0xac
+#define CLDCOFST				0xb0
+#define CLSV					0xb4
+#define CLHWIN0					0xb8
+#define CLHWIN1					0xbc
+#define CLHWIN2					0xc0
+#define CLVRV					0xc4
+#define CLVWIN0					0xc8
+#define CLVWIN1					0xcc
+#define CLVWIN2					0xd0
+#define CLVWIN3					0xd4
+/****************************************************
+* Lense Shading Correction
+****************************************************/
+#define DATAHOFST				0xd8
+#define DATAVOFST				0xdc
+#define LSCHVAL					0xe0
+#define LSCVVAL					0xe4
+#define TWODLSCCFG				0xe8
+#define TWODLSCOFST				0xec
+#define TWODLSCINI				0xf0
+#define TWODLSCGRBU				0xf4
+#define TWODLSCGRBL				0xf8
+#define TWODLSCGROF				0xfc
+#define TWODLSCORBU				0x100
+#define TWODLSCORBL				0x104
+#define TWODLSCOROF				0x108
+#define TWODLSCIRQEN				0x10c
+#define TWODLSCIRQST				0x110
+/****************************************************
+* Data formatter
+****************************************************/
+#define FMTCFG					0x114
+#define FMTPLEN					0x118
+#define FMTSPH					0x11c
+#define FMTLNH					0x120
+#define FMTSLV					0x124
+#define FMTLNV					0x128
+#define FMTRLEN					0x12c
+#define FMTHCNT					0x130
+#define FMTAPTR_BASE				0x134
+/* Below macro for addresses FMTAPTR0 - FMTAPTR15 */
+#define FMTAPTR(i)			(FMTAPTR_BASE + (i * 4))
+#define FMTPGMVF0				0x174
+#define FMTPGMVF1				0x178
+#define FMTPGMAPU0				0x17c
+#define FMTPGMAPU1				0x180
+#define FMTPGMAPS0				0x184
+#define FMTPGMAPS1				0x188
+#define FMTPGMAPS2				0x18c
+#define FMTPGMAPS3				0x190
+#define FMTPGMAPS4				0x194
+#define FMTPGMAPS5				0x198
+#define FMTPGMAPS6				0x19c
+#define FMTPGMAPS7				0x1a0
+/************************************************
+* Color Space Converter
+************************************************/
+#define CSCCTL					0x1a4
+#define CSCM0					0x1a8
+#define CSCM1					0x1ac
+#define CSCM2					0x1b0
+#define CSCM3					0x1b4
+#define CSCM4					0x1b8
+#define CSCM5					0x1bc
+#define CSCM6					0x1c0
+#define CSCM7					0x1c4
+#define OBWIN0					0x1c8
+#define OBWIN1					0x1cc
+#define OBWIN2					0x1d0
+#define OBWIN3					0x1d4
+#define OBVAL0					0x1d8
+#define OBVAL1					0x1dc
+#define OBVAL2					0x1e0
+#define OBVAL3					0x1e4
+#define OBVAL4					0x1e8
+#define OBVAL5					0x1ec
+#define OBVAL6					0x1f0
+#define OBVAL7					0x1f4
+#define CLKCTL					0x1f8
+
+/* Masks & Shifts below */
+#define START_PX_HOR_MASK			0x7FFF
+#define NUM_PX_HOR_MASK				0x7FFF
+#define START_VER_ONE_MASK			0x7FFF
+#define START_VER_TWO_MASK			0x7FFF
+#define NUM_LINES_VER				0x7FFF
+
+/* gain - offset masks */
+#define GAIN_INTEGER_SHIFT			9
+#define OFFSET_MASK			  	0xFFF
+#define GAIN_SDRAM_EN_SHIFT			12
+#define GAIN_IPIPE_EN_SHIFT			13
+#define GAIN_H3A_EN_SHIFT			14
+#define OFST_SDRAM_EN_SHIFT			8
+#define OFST_IPIPE_EN_SHIFT			9
+#define OFST_H3A_EN_SHIFT			10
+#define GAIN_OFFSET_EN_MASK			0x7700
+
+/* Culling */
+#define CULL_PAT_EVEN_LINE_SHIFT		8
+
+/* CCDCFG register */
+#define ISIF_YCINSWP_RAW			(0x00 << 4)
+#define ISIF_YCINSWP_YCBCR			(0x01 << 4)
+#define ISIF_CCDCFG_FIDMD_LATCH_VSYNC		(0x00 << 6)
+#define ISIF_CCDCFG_WENLOG_AND			(0x00 << 8)
+#define ISIF_CCDCFG_TRGSEL_WEN			(0x00 << 9)
+#define ISIF_CCDCFG_EXTRG_DISABLE		(0x00 << 10)
+#define ISIF_LATCH_ON_VSYNC_DISABLE		(0x01 << 15)
+#define ISIF_LATCH_ON_VSYNC_ENABLE		(0x00 << 15)
+#define ISIF_DATA_PACK_MASK			3
+#define ISIF_DATA_PACK16			0
+#define ISIF_DATA_PACK12			1
+#define ISIF_DATA_PACK8				2
+#define ISIF_PIX_ORDER_SHIFT			11
+#define ISIF_BW656_ENABLE			(0x01 << 5)
+
+/* MODESET registers */
+#define ISIF_VDHDOUT_INPUT			(0x00 << 0)
+#define ISIF_INPUT_SHIFT			12
+#define ISIF_RAW_INPUT_MODE			0
+#define ISIF_FID_POL_SHIFT			4
+#define ISIF_HD_POL_SHIFT			3
+#define ISIF_VD_POL_SHIFT			2
+#define ISIF_DATAPOL_NORMAL			0
+#define ISIF_DATAPOL_SHIFT			6
+#define ISIF_EXWEN_DISABLE 			0
+#define ISIF_EXWEN_SHIFT			5
+#define ISIF_FRM_FMT_SHIFT			7
+#define ISIF_DATASFT_SHIFT			8
+#define ISIF_LPF_SHIFT				14
+#define ISIF_LPF_MASK				1
+
+/* GAMMAWD registers */
+#define ISIF_ALAW_GAMA_WD_MASK			0xF
+#define ISIF_ALAW_GAMA_WD_SHIFT			1
+#define ISIF_ALAW_ENABLE			1
+#define ISIF_GAMMAWD_CFA_SHIFT			5
+
+/* HSIZE registers */
+#define ISIF_HSIZE_FLIP_MASK			1
+#define ISIF_HSIZE_FLIP_SHIFT			12
+
+/* MISC registers */
+#define ISIF_DPCM_EN_SHIFT			12
+#define ISIF_DPCM_PREDICTOR_SHIFT		13
+
+/* Black clamp related */
+#define ISIF_BC_MODE_COLOR_SHIFT		4
+#define ISIF_HORZ_BC_MODE_SHIFT			1
+#define ISIF_HORZ_BC_WIN_SEL_SHIFT		5
+#define ISIF_HORZ_BC_PIX_LIMIT_SHIFT		6
+#define ISIF_HORZ_BC_WIN_H_SIZE_SHIFT		8
+#define ISIF_HORZ_BC_WIN_V_SIZE_SHIFT		12
+#define	ISIF_VERT_BC_RST_VAL_SEL_SHIFT		4
+#define ISIF_VERT_BC_LINE_AVE_COEF_SHIFT	8
+
+/* VDFC registers */
+#define ISIF_VDFC_EN_SHIFT			4
+#define ISIF_VDFC_CORR_MOD_SHIFT		5
+#define ISIF_VDFC_CORR_WHOLE_LN_SHIFT		7
+#define ISIF_VDFC_LEVEL_SHFT_SHIFT		8
+#define ISIF_VDFC_POS_MASK			0x1FFF
+#define ISIF_DFCMEMCTL_DFCMARST_SHIFT		2
+
+/* CSC registers */
+#define ISIF_CSC_COEF_INTEG_MASK		7
+#define ISIF_CSC_COEF_DECIMAL_MASK		0x1f
+#define ISIF_CSC_COEF_INTEG_SHIFT		5
+#define ISIF_CSCM_MSB_SHIFT			8
+#define ISIF_DF_CSC_SPH_MASK			0x1FFF
+#define ISIF_DF_CSC_LNH_MASK			0x1FFF
+#define ISIF_DF_CSC_SLV_MASK			0x1FFF
+#define ISIF_DF_CSC_LNV_MASK			0x1FFF
+#define ISIF_DF_NUMLINES			0x7FFF
+#define ISIF_DF_NUMPIX				0x1FFF
+
+/* Offsets for LSC/DFC/Gain */
+#define ISIF_DATA_H_OFFSET_MASK			0x1FFF
+#define ISIF_DATA_V_OFFSET_MASK			0x1FFF
+
+/* Linearization */
+#define ISIF_LIN_CORRSFT_SHIFT			4
+#define ISIF_LIN_SCALE_FACT_INTEG_SHIFT		10
+
+
+/* Pattern registers */
+#define ISIF_PG_EN				(1 << 3)
+#define ISIF_SEL_PG_SRC				(3 << 4)
+#define ISIF_PG_VD_POL_SHIFT			0
+#define ISIF_PG_HD_POL_SHIFT			1
+
+/*random other junk*/
+#define ISIF_SYNCEN_VDHDEN_MASK			(1 << 0)
+#define ISIF_SYNCEN_WEN_MASK			(1 << 1)
+#define ISIF_SYNCEN_WEN_SHIFT			1
+
+#endif
diff --git a/include/media/davinci/isif.h b/include/media/davinci/isif.h
new file mode 100644
index 0000000..b0b74ad
--- /dev/null
+++ b/include/media/davinci/isif.h
@@ -0,0 +1,531 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * 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
+ *
+ * isif header file
+ */
+#ifndef _ISIF_H
+#define _ISIF_H
+
+#include <media/davinci/ccdc_types.h>
+#include <media/davinci/vpfe_types.h>
+
+/* isif float type S8Q8/U8Q8 */
+struct isif_float_8 {
+	/* 8 bit integer part */
+	__u8 integer;
+	/* 8 bit decimal part */
+	__u8 decimal;
+};
+
+/* isif float type U16Q16/S16Q16 */
+struct isif_float_16 {
+	/* 16 bit integer part */
+	__u16 integer;
+	/* 16 bit decimal part */
+	__u16 decimal;
+};
+
+/************************************************************************
+ *   Vertical Defect Correction parameters
+ ***********************************************************************/
+/* Defect Correction (DFC) table entry */
+struct isif_vdfc_entry {
+	/* vertical position of defect */
+	__u16 pos_vert;
+	/* horizontal position of defect */
+	__u16 pos_horz;
+	/*
+	 * Defect level of Vertical line defect position. This is subtracted
+	 * from the data at the defect position
+	 */
+	__u8 level_at_pos;
+	/*
+	 * Defect level of the pixels upper than the vertical line defect.
+	 * This is subtracted from the data
+	 */
+	__u8 level_up_pixels;
+	/*
+	 * Defect level of the pixels lower than the vertical line defect.
+	 * This is subtracted from the data
+	 */
+	__u8 level_low_pixels;
+};
+
+#define ISIF_VDFC_TABLE_SIZE		8
+struct isif_dfc {
+	/* enable vertical defect correction */
+	__u8 en;
+	/* Defect level subtraction. Just fed through if saturating */
+#define	ISIF_VDFC_NORMAL		0
+	/*
+	 * Defect level subtraction. Horizontal interpolation ((i-2)+(i+2))/2
+	 * if data saturating
+	 */
+#define ISIF_VDFC_HORZ_INTERPOL_IF_SAT	1
+	/* Horizontal interpolation (((i-2)+(i+2))/2) */
+#define	ISIF_VDFC_HORZ_INTERPOL		2
+	/* one of the vertical defect correction modes above */
+	__u8 corr_mode;
+	/* 0 - whole line corrected, 1 - not pixels upper than the defect */
+	__u8 corr_whole_line;
+#define ISIF_VDFC_NO_SHIFT		0
+#define ISIF_VDFC_SHIFT_1		1
+#define ISIF_VDFC_SHIFT_2		2
+#define ISIF_VDFC_SHIFT_3		3
+#define ISIF_VDFC_SHIFT_4		4
+	/*
+	 * defect level shift value. level_at_pos, level_upper_pos,
+	 * and level_lower_pos can be shifted up by this value. Choose
+	 * one of the values above
+	 */
+	__u8 def_level_shift;
+	/* defect saturation level */
+	__u16 def_sat_level;
+	/* number of vertical defects. Max is ISIF_VDFC_TABLE_SIZE */
+	__u16 num_vdefects;
+	/* VDFC table ptr */
+	struct isif_vdfc_entry table[ISIF_VDFC_TABLE_SIZE];
+};
+
+struct isif_horz_bclamp {
+
+	/* Horizontal clamp disabled. Only vertical clamp value is subtracted */
+#define	ISIF_HORZ_BC_DISABLE		0
+	/*
+	 * Horizontal clamp value is calculated and subtracted from image data
+	 * along with vertical clamp value
+	 */
+#define ISIF_HORZ_BC_CLAMP_CALC_ENABLED	1
+	/*
+	 * Horizontal clamp value calculated from previous image is subtracted
+	 * from image data along with vertical clamp value.
+	 */
+#define ISIF_HORZ_BC_CLAMP_NOT_UPDATED	2
+	/* horizontal clamp mode. One of the values above */
+	__u8 mode;
+	/*
+	 * pixel value limit enable.
+	 *  0 - limit disabled
+	 *  1 - pixel value limited to 1023
+	 */
+	__u8 clamp_pix_limit;
+	/* Select Most left window for bc calculation */
+#define	ISIF_SEL_MOST_LEFT_WIN		0
+	/* Select Most right window for bc calculation */
+#define ISIF_SEL_MOST_RIGHT_WIN		1
+	/* Select most left or right window for clamp val calculation */
+	__u8 base_win_sel_calc;
+	/* Window count per color for calculation. range 1-32 */
+	__u8 win_count_calc;
+	/* Window start position - horizontal for calculation. 0 - 8191 */
+	__u16 win_start_h_calc;
+	/* Window start position - vertical for calculation 0 - 8191 */
+	__u16 win_start_v_calc;
+#define ISIF_HORZ_BC_SZ_H_2PIXELS	0
+#define ISIF_HORZ_BC_SZ_H_4PIXELS	1
+#define ISIF_HORZ_BC_SZ_H_8PIXELS	2
+#define ISIF_HORZ_BC_SZ_H_16PIXELS	3
+	/* Width of the sample window in pixels for calculation */
+	__u8 win_h_sz_calc;
+#define ISIF_HORZ_BC_SZ_V_32PIXELS	0
+#define ISIF_HORZ_BC_SZ_V_64PIXELS	1
+#define	ISIF_HORZ_BC_SZ_V_128PIXELS	2
+#define ISIF_HORZ_BC_SZ_V_256PIXELS	3
+	/* Height of the sample window in pixels for calculation */
+	__u8 win_v_sz_calc;
+};
+
+/************************************************************************
+ *  Black Clamp parameters
+ ***********************************************************************/
+struct isif_vert_bclamp {
+	/* Reset value used is the clamp value calculated */
+#define	ISIF_VERT_BC_USE_HORZ_CLAMP_VAL		0
+	/* Reset value used is reset_clamp_val configured */
+#define	ISIF_VERT_BC_USE_CONFIG_CLAMP_VAL	1
+	/* No update, previous image value is used */
+#define	ISIF_VERT_BC_NO_UPDATE			2
+	/*
+	 * Reset value selector for vertical clamp calculation. Use one of
+	 * the above values
+	 */
+	__u8 reset_val_sel;
+	/* U8Q8. Line average coefficient used in vertical clamp calculation */
+	__u8 line_ave_coef;
+	/* Height of the optical black region for calculation */
+	__u16 ob_v_sz_calc;
+	/* Optical black region start position - horizontal. 0 - 8191 */
+	__u16 ob_start_h;
+	/* Optical black region start position - vertical 0 - 8191 */
+	__u16 ob_start_v;
+};
+
+struct isif_black_clamp {
+	/*
+	 * This offset value is added irrespective of the clamp enable status.
+	 * S13
+	 */
+	__u16 dc_offset;
+	/*
+	 * Enable black/digital clamp value to be subtracted from the image data
+	 */
+	__u8 en;
+	/*
+	 * black clamp mode. same/separate clamp for 4 colors
+	 * 0 - disable - same clamp value for all colors
+	 * 1 - clamp value calculated separately for all colors
+	 */
+	__u8 bc_mode_color;
+	/* Vrtical start position for bc subtraction */
+	__u16 vert_start_sub;
+	/* Black clamp for horizontal direction */
+	struct isif_horz_bclamp horz;
+	/* Black clamp for vertical direction */
+	struct isif_vert_bclamp vert;
+};
+
+/*************************************************************************
+** Color Space Convertion (CSC)
+*************************************************************************/
+#define ISIF_CSC_NUM_COEFF	16
+struct isif_color_space_conv {
+	/* Enable color space conversion */
+	__u8 en;
+	/*
+	 * csc coeffient table. S8Q5, M00 at index 0, M01 at index 1, and
+	 * so forth
+	 */
+	struct isif_float_8 coeff[ISIF_CSC_NUM_COEFF];
+};
+
+
+/*************************************************************************
+**  Black  Compensation parameters
+*************************************************************************/
+struct isif_black_comp {
+	/* Comp for Red */
+	__s8 r_comp;
+	/* Comp for Gr */
+	__s8 gr_comp;
+	/* Comp for Blue */
+	__s8 b_comp;
+	/* Comp for Gb */
+	__s8 gb_comp;
+};
+
+/*************************************************************************
+**  Gain parameters
+*************************************************************************/
+struct isif_gain {
+	/* Gain for Red or ye */
+	struct isif_float_16 r_ye;
+	/* Gain for Gr or cy */
+	struct isif_float_16 gr_cy;
+	/* Gain for Gb or g */
+	struct isif_float_16 gb_g;
+	/* Gain for Blue or mg */
+	struct isif_float_16 b_mg;
+};
+
+#define ISIF_LINEAR_TAB_SIZE	192
+/*************************************************************************
+**  Linearization parameters
+*************************************************************************/
+struct isif_linearize {
+	/* Enable or Disable linearization of data */
+	__u8 en;
+	/* Shift value applied */
+	__u8 corr_shft;
+	/* scale factor applied U11Q10 */
+	struct isif_float_16 scale_fact;
+	/* Size of the linear table */
+	__u16 table[ISIF_LINEAR_TAB_SIZE];
+};
+
+/* Color patterns */
+#define ISIF_RED	0
+#define	ISIF_GREEN_RED	1
+#define ISIF_GREEN_BLUE	2
+#define ISIF_BLUE	3
+struct isif_col_pat {
+	__u8 olop;
+	__u8 olep;
+	__u8 elop;
+	__u8 elep;
+};
+
+/*************************************************************************
+**  Data formatter parameters
+*************************************************************************/
+struct isif_fmtplen {
+	/*
+	 * number of program entries for SET0, range 1 - 16
+	 * when fmtmode is ISIF_SPLIT, 1 - 8 when fmtmode is
+	 * ISIF_COMBINE
+	 */
+	__u16 plen0;
+	/*
+	 * number of program entries for SET1, range 1 - 16
+	 * when fmtmode is ISIF_SPLIT, 1 - 8 when fmtmode is
+	 * ISIF_COMBINE
+	 */
+	__u16 plen1;
+	/**
+	 * number of program entries for SET2, range 1 - 16
+	 * when fmtmode is ISIF_SPLIT, 1 - 8 when fmtmode is
+	 * ISIF_COMBINE
+	 */
+	__u16 plen2;
+	/**
+	 * number of program entries for SET3, range 1 - 16
+	 * when fmtmode is ISIF_SPLIT, 1 - 8 when fmtmode is
+	 * ISIF_COMBINE
+	 */
+	__u16 plen3;
+};
+
+struct isif_fmt_cfg {
+#define ISIF_SPLIT		0
+#define ISIF_COMBINE		1
+	/* Split or combine or line alternate */
+	__u8 fmtmode;
+	/* enable or disable line alternating mode */
+	__u8 ln_alter_en;
+#define ISIF_1LINE		0
+#define	ISIF_2LINES		1
+#define	ISIF_3LINES		2
+#define	ISIF_4LINES		3
+	/* Split/combine line number */
+	__u8 lnum;
+	/* Address increment Range 1 - 16 */
+	__u8 addrinc;
+};
+
+struct isif_fmt_addr_ptr {
+	/* Initial address */
+	__u32 init_addr;
+	/* output line number */
+#define ISIF_1STLINE		0
+#define	ISIF_2NDLINE		1
+#define	ISIF_3RDLINE		2
+#define	ISIF_4THLINE		3
+	__u8 out_line;
+};
+
+struct isif_fmtpgm_ap {
+	/* program address pointer */
+	__u8 pgm_aptr;
+	/* program address increment or decrement */
+	__u8 pgmupdt;
+};
+
+struct isif_data_formatter {
+	/* Enable/Disable data formatter */
+	__u8 en;
+	/* data formatter configuration */
+	struct isif_fmt_cfg cfg;
+	/* Formatter program entries length */
+	struct isif_fmtplen plen;
+	/* first pixel in a line fed to formatter */
+	__u16 fmtrlen;
+	/* HD interval for output line. Only valid when split line */
+	__u16 fmthcnt;
+	/* formatter address pointers */
+	struct isif_fmt_addr_ptr fmtaddr_ptr[16];
+	/* program enable/disable */
+	__u8 pgm_en[32];
+	/* program address pointers */
+	struct isif_fmtpgm_ap fmtpgm_ap[32];
+};
+
+struct isif_df_csc {
+	/* Color Space Conversion confguration, 0 - csc, 1 - df */
+	__u8 df_or_csc;
+	/* csc configuration valid if df_or_csc is 0 */
+	struct isif_color_space_conv csc;
+	/* data formatter configuration valid if df_or_csc is 1 */
+	struct isif_data_formatter df;
+	/* start pixel in a line at the input */
+	__u32 start_pix;
+	/* number of pixels in input line */
+	__u32 num_pixels;
+	/* start line at the input */
+	__u32 start_line;
+	/* number of lines at the input */
+	__u32 num_lines;
+};
+
+struct isif_gain_offsets_adj {
+	/* Gain adjustment per color */
+	struct isif_gain gain;
+	/* Offset adjustment */
+	__u16 offset;
+	/* Enable or Disable Gain adjustment for SDRAM data */
+	__u8 gain_sdram_en;
+	/* Enable or Disable Gain adjustment for IPIPE data */
+	__u8 gain_ipipe_en;
+	/* Enable or Disable Gain adjustment for H3A data */
+	__u8 gain_h3a_en;
+	/* Enable or Disable Gain adjustment for SDRAM data */
+	__u8 offset_sdram_en;
+	/* Enable or Disable Gain adjustment for IPIPE data */
+	__u8 offset_ipipe_en;
+	/* Enable or Disable Gain adjustment for H3A data */
+	__u8 offset_h3a_en;
+};
+
+struct isif_cul {
+	/* Horizontal Cull pattern for odd lines */
+	__u8 hcpat_odd;
+	/* Horizontal Cull pattern for even lines */
+	__u8 hcpat_even;
+	/* Vertical Cull pattern */
+	__u8 vcpat;
+	/* Enable or disable lpf. Apply when cull is enabled */
+	__u8 en_lpf;
+};
+
+struct isif_compress {
+#define ISIF_ALAW		0
+#define ISIF_DPCM		1
+#define ISIF_NO_COMPRESSION	2
+	/* Compression Algorithm used */
+	__u8 alg;
+	/* Choose Predictor1 for DPCM compression */
+#define ISIF_DPCM_PRED1		0
+	/* Choose Predictor2 for DPCM compression */
+#define ISIF_DPCM_PRED2		1
+	/* Predictor for DPCM compression */
+	__u8 pred;
+};
+
+/* all the stuff in this struct will be provided by userland */
+struct isif_config_params_raw {
+	/* Linearization parameters for image sensor data input */
+	struct isif_linearize linearize;
+	/* Data formatter or CSC */
+	struct isif_df_csc df_csc;
+	/* Defect Pixel Correction (DFC) confguration */
+	struct isif_dfc dfc;
+	/* Black/Digital Clamp configuration */
+	struct isif_black_clamp bclamp;
+	/* Gain, offset adjustments */
+	struct isif_gain_offsets_adj gain_offset;
+	/* Culling */
+	struct isif_cul culling;
+	/* A-Law and DPCM compression options */
+	struct isif_compress compress;
+	/* horizontal offset for Gain/LSC/DFC */
+	__u16 horz_offset;
+	/* vertical offset for Gain/LSC/DFC */
+	__u16 vert_offset;
+	/* color pattern for field 0 */
+	struct isif_col_pat col_pat_field0;
+	/* color pattern for field 1 */
+	struct isif_col_pat col_pat_field1;
+#define ISIF_NO_SHIFT		0
+#define	ISIF_1BIT_SHIFT		1
+#define	ISIF_2BIT_SHIFT		2
+#define	ISIF_3BIT_SHIFT		3
+#define	ISIF_4BIT_SHIFT		4
+#define ISIF_5BIT_SHIFT		5
+#define ISIF_6BIT_SHIFT		6
+	/* Data shift applied before storing to SDRAM */
+	__u8 data_shift;
+	/* enable input test pattern generation */
+	__u8 test_pat_gen;
+};
+
+#ifdef __KERNEL__
+struct isif_ycbcr_config {
+	/* isif pixel format */
+	enum ccdc_pixfmt pix_fmt;
+	/* isif frame format */
+	enum ccdc_frmfmt frm_fmt;
+	/* ISIF crop window */
+	struct v4l2_rect win;
+	/* field polarity */
+	enum vpfe_pin_pol fid_pol;
+	/* interface VD polarity */
+	enum vpfe_pin_pol vd_pol;
+	/* interface HD polarity */
+	enum vpfe_pin_pol hd_pol;
+	/* isif pix order. Only used for ycbcr capture */
+	enum ccdc_pixorder pix_order;
+	/* isif buffer type. Only used for ycbcr capture */
+	enum ccdc_buftype buf_type;
+};
+
+/* MSB of image data connected to sensor port */
+enum isif_data_msb {
+	ISIF_BIT_MSB_15,
+	ISIF_BIT_MSB_14,
+	ISIF_BIT_MSB_13,
+	ISIF_BIT_MSB_12,
+	ISIF_BIT_MSB_11,
+	ISIF_BIT_MSB_10,
+	ISIF_BIT_MSB_9,
+	ISIF_BIT_MSB_8,
+	ISIF_BIT_MSB_7
+};
+
+enum isif_cfa_pattern {
+	ISIF_CFA_PAT_MOSAIC,
+	ISIF_CFA_PAT_STRIPE
+};
+
+struct isif_params_raw {
+	/* isif pixel format */
+	enum ccdc_pixfmt pix_fmt;
+	/* isif frame format */
+	enum ccdc_frmfmt frm_fmt;
+	/* video window */
+	struct v4l2_rect win;
+	/* field polarity */
+	enum vpfe_pin_pol fid_pol;
+	/* interface VD polarity */
+	enum vpfe_pin_pol vd_pol;
+	/* interface HD polarity */
+	enum vpfe_pin_pol hd_pol;
+	/* buffer type. Applicable for interlaced mode */
+	enum ccdc_buftype buf_type;
+	/* Gain values */
+	struct isif_gain gain;
+	/* cfa pattern */
+	enum isif_cfa_pattern cfa_pat;
+	/* Data MSB position */
+	enum isif_data_msb data_msb;
+	/* Enable horizontal flip */
+	unsigned char horz_flip_en;
+	/* Enable image invert vertically */
+	unsigned char image_invert_en;
+
+	/* all the userland defined stuff*/
+	struct isif_config_params_raw config_params;
+};
+
+enum isif_data_pack {
+	ISIF_PACK_16BIT,
+	ISIF_PACK_12BIT,
+	ISIF_PACK_8BIT
+};
+
+#define ISIF_WIN_NTSC				{0, 0, 720, 480}
+#define ISIF_WIN_VGA				{0, 0, 640, 480}
+
+#endif
+#endif
-- 
1.6.0.4


From m-karicheri2 at ti.com  Mon Feb  1 16:27:14 2010
From: m-karicheri2 at ti.com (m-karicheri2 at ti.com)
Date: Mon,  1 Feb 2010 17:27:14 -0500
Subject: [PATCH v3 5/6] V4L - vpfe capture - build environment for isif driver
In-Reply-To: <1265063238-29072-1-git-send-email-m-karicheri2@ti.com>
References: <1265063238-29072-1-git-send-email-m-karicheri2@ti.com>
Message-ID: <1265063238-29072-2-git-send-email-m-karicheri2@ti.com>

From: Murali Karicheri <m-karicheri2 at ti.com>

Adding Makefile and Kconfig for ISIF driver

Reviewed-by: Hans Verkuil <hverkuil at xs4all.nl>
Reviewed-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>

Signed-off-by: Hans Verkuil <hverkuil at xs4all.nl>
Signed-off-by: Murali Karicheri <m-karicheri2 at ti.com>
---
Applies to linux-next tree
 - rebasing to latest tree for merge (v3)
 drivers/media/video/Kconfig          |   14 +++++++++++++-
 drivers/media/video/davinci/Makefile |    1 +
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 64682bf..d92268d 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -548,7 +548,6 @@ config VIDEO_VPSS_SYSTEM
 	depends on ARCH_DAVINCI
 	help
 	  Support for vpss system module for video driver
-	default y
 
 config VIDEO_VPFE_CAPTURE
 	tristate "VPFE Video Capture Driver"
@@ -592,6 +591,19 @@ config VIDEO_DM355_CCDC
 	   To compile this driver as a module, choose M here: the
 	   module will be called vpfe.
 
+config VIDEO_ISIF
+	tristate "ISIF HW module"
+	depends on ARCH_DAVINCI_DM365 && VIDEO_VPFE_CAPTURE
+	select VIDEO_VPSS_SYSTEM
+	default y
+	help
+	   Enables ISIF hw module. This is the hardware module for
+	   configuring ISIF in VPFE to capture Raw Bayer RGB data  from
+	   a image sensor or YUV data from a YUV source.
+
+	   To compile this driver as a module, choose M here: the
+	   module will be called vpfe.
+
 source "drivers/media/video/bt8xx/Kconfig"
 
 config VIDEO_PMS
diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile
index 1a8b8f3..a379557 100644
--- a/drivers/media/video/davinci/Makefile
+++ b/drivers/media/video/davinci/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o
 obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o
 obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o
 obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o
+obj-$(CONFIG_VIDEO_ISIF) += isif.o
-- 
1.6.0.4


From m-karicheri2 at ti.com  Mon Feb  1 16:27:17 2010
From: m-karicheri2 at ti.com (m-karicheri2 at ti.com)
Date: Mon,  1 Feb 2010 17:27:17 -0500
Subject: [PATCH v3 3/6] V4L - vpfe capture - vpss driver enhancements for DM365
In-Reply-To: <1265063238-29072-4-git-send-email-m-karicheri2@ti.com>
References: <1265063238-29072-1-git-send-email-m-karicheri2@ti.com>
	<1265063238-29072-2-git-send-email-m-karicheri2@ti.com>
	<1265063238-29072-3-git-send-email-m-karicheri2@ti.com>
	<1265063238-29072-4-git-send-email-m-karicheri2@ti.com>
Message-ID: <1265063238-29072-5-git-send-email-m-karicheri2@ti.com>

From: Murali Karicheri <m-karicheri2 at ti.com>

Enhancements to support DM365 ISP5 and VPSS module configuration.
Also cleaned up the driver by removing redundant variables.

Reviewed-by: Hans Verkuil <hverkuil at xs4all.nl>

Signed-off-by: Hans Verkuil <hverkuil at xs4all.nl>
Signed-off-by: Muralidharan Karicheri <m-karicheri2 at ti.com>
---
Applies to linux-next v4l-dvb tree
 - Rebasing to latest tree for merge (v3)
 - review comments incorporated (v1)
 drivers/media/video/davinci/vpss.c |  289 +++++++++++++++++++++++++++++-------
 include/media/davinci/vpss.h       |   41 +++++-
 2 files changed, 275 insertions(+), 55 deletions(-)

diff --git a/drivers/media/video/davinci/vpss.c b/drivers/media/video/davinci/vpss.c
index 7ee72ec..7918680 100644
--- a/drivers/media/video/davinci/vpss.c
+++ b/drivers/media/video/davinci/vpss.c
@@ -15,7 +15,7 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  *
- * common vpss driver for all video drivers.
+ * common vpss system module platform driver for all video drivers.
  */
 #include <linux/kernel.h>
 #include <linux/sched.h>
@@ -35,12 +35,52 @@ MODULE_AUTHOR("Texas Instruments");
 /* DM644x defines */
 #define DM644X_SBL_PCR_VPSS		(4)
 
+#define DM355_VPSSBL_INTSEL		0x10
+#define DM355_VPSSBL_EVTSEL		0x14
 /* vpss BL register offsets */
 #define DM355_VPSSBL_CCDCMUX		0x1c
 /* vpss CLK register offsets */
 #define DM355_VPSSCLK_CLKCTRL		0x04
 /* masks and shifts */
 #define VPSS_HSSISEL_SHIFT		4
+/*
+ * VDINT0 - vpss_int0, VDINT1 - vpss_int1, H3A - vpss_int4,
+ * IPIPE_INT1_SDR - vpss_int5
+ */
+#define DM355_VPSSBL_INTSEL_DEFAULT	0xff83ff10
+/* VENCINT - vpss_int8 */
+#define DM355_VPSSBL_EVTSEL_DEFAULT	0x4
+
+#define DM365_ISP5_PCCR 		0x04
+#define DM365_ISP5_INTSEL1		0x10
+#define DM365_ISP5_INTSEL2		0x14
+#define DM365_ISP5_INTSEL3		0x18
+#define DM365_ISP5_CCDCMUX 		0x20
+#define DM365_ISP5_PG_FRAME_SIZE 	0x28
+#define DM365_VPBE_CLK_CTRL 		0x00
+/*
+ * vpss interrupts. VDINT0 - vpss_int0, VDINT1 - vpss_int1,
+ * AF - vpss_int3
+ */
+#define DM365_ISP5_INTSEL1_DEFAULT	0x0b1f0100
+/* AEW - vpss_int6, RSZ_INT_DMA - vpss_int5 */
+#define DM365_ISP5_INTSEL2_DEFAULT	0x1f0a0f1f
+/* VENC - vpss_int8 */
+#define DM365_ISP5_INTSEL3_DEFAULT	0x00000015
+
+/* masks and shifts for DM365*/
+#define DM365_CCDC_PG_VD_POL_SHIFT 	0
+#define DM365_CCDC_PG_HD_POL_SHIFT 	1
+
+#define CCD_SRC_SEL_MASK		(BIT_MASK(5) | BIT_MASK(4))
+#define CCD_SRC_SEL_SHIFT		4
+
+/* Different SoC platforms supported by this driver */
+enum vpss_platform_type {
+	DM644X,
+	DM355,
+	DM365,
+};
 
 /*
  * vpss operations. Depends on platform. Not all functions are available
@@ -59,13 +99,9 @@ struct vpss_hw_ops {
 
 /* vpss configuration */
 struct vpss_oper_config {
-	__iomem void *vpss_bl_regs_base;
-	__iomem void *vpss_regs_base;
-	struct resource		*r1;
-	resource_size_t		len1;
-	struct resource		*r2;
-	resource_size_t		len2;
-	char vpss_name[32];
+	__iomem void *vpss_regs_base0;
+	__iomem void *vpss_regs_base1;
+	enum vpss_platform_type platform;
 	spinlock_t vpss_lock;
 	struct vpss_hw_ops hw_ops;
 };
@@ -75,22 +111,46 @@ static struct vpss_oper_config oper_cfg;
 /* register access routines */
 static inline u32 bl_regr(u32 offset)
 {
-	return __raw_readl(oper_cfg.vpss_bl_regs_base + offset);
+	return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
 }
 
 static inline void bl_regw(u32 val, u32 offset)
 {
-	__raw_writel(val, oper_cfg.vpss_bl_regs_base + offset);
+	__raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
 }
 
 static inline u32 vpss_regr(u32 offset)
 {
-	return __raw_readl(oper_cfg.vpss_regs_base + offset);
+	return __raw_readl(oper_cfg.vpss_regs_base1 + offset);
 }
 
 static inline void vpss_regw(u32 val, u32 offset)
 {
-	__raw_writel(val, oper_cfg.vpss_regs_base + offset);
+	__raw_writel(val, oper_cfg.vpss_regs_base1 + offset);
+}
+
+/* For DM365 only */
+static inline u32 isp5_read(u32 offset)
+{
+	return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
+}
+
+/* For DM365 only */
+static inline void isp5_write(u32 val, u32 offset)
+{
+	__raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
+}
+
+static void dm365_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+	u32 temp = isp5_read(DM365_ISP5_CCDCMUX) & ~CCD_SRC_SEL_MASK;
+
+	/* if we are using pattern generator, enable it */
+	if (src_sel == VPSS_PGLPBK || src_sel == VPSS_CCDCPG)
+		temp |= 0x08;
+
+	temp |= (src_sel << CCD_SRC_SEL_SHIFT);
+	isp5_write(temp, DM365_ISP5_CCDCMUX);
 }
 
 static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
@@ -101,9 +161,9 @@ static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
 int vpss_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
 {
 	if (!oper_cfg.hw_ops.select_ccdc_source)
-		return -1;
+		return -EINVAL;
 
-	dm355_select_ccdc_source(src_sel);
+	oper_cfg.hw_ops.select_ccdc_source(src_sel);
 	return 0;
 }
 EXPORT_SYMBOL(vpss_select_ccdc_source);
@@ -114,7 +174,7 @@ static int dm644x_clear_wbl_overflow(enum vpss_wbl_sel wbl_sel)
 
 	if (wbl_sel < VPSS_PCR_AEW_WBL_0 ||
 	    wbl_sel > VPSS_PCR_CCDC_WBL_O)
-		return -1;
+		return -EINVAL;
 
 	/* writing a 0 clear the overflow */
 	mask = ~(mask << wbl_sel);
@@ -126,7 +186,7 @@ static int dm644x_clear_wbl_overflow(enum vpss_wbl_sel wbl_sel)
 int vpss_clear_wbl_overflow(enum vpss_wbl_sel wbl_sel)
 {
 	if (!oper_cfg.hw_ops.clear_wbl_overflow)
-		return -1;
+		return -EINVAL;
 
 	return oper_cfg.hw_ops.clear_wbl_overflow(wbl_sel);
 }
@@ -166,7 +226,7 @@ static int dm355_enable_clock(enum vpss_clock_sel clock_sel, int en)
 	default:
 		printk(KERN_ERR "dm355_enable_clock:"
 				" Invalid selector: %d\n", clock_sel);
-		return -1;
+		return -EINVAL;
 	}
 
 	spin_lock_irqsave(&oper_cfg.vpss_lock, flags);
@@ -181,100 +241,221 @@ static int dm355_enable_clock(enum vpss_clock_sel clock_sel, int en)
 	return 0;
 }
 
+static int dm365_enable_clock(enum vpss_clock_sel clock_sel, int en)
+{
+	unsigned long flags;
+	u32 utemp, mask = 0x1, shift = 0, offset = DM365_ISP5_PCCR;
+	u32 (*read)(u32 offset) = isp5_read;
+	void(*write)(u32 val, u32 offset) = isp5_write;
+
+	switch (clock_sel) {
+	case VPSS_BL_CLOCK:
+		break;
+	case VPSS_CCDC_CLOCK:
+		shift = 1;
+		break;
+	case VPSS_H3A_CLOCK:
+		shift = 2;
+		break;
+	case VPSS_RSZ_CLOCK:
+		shift = 3;
+		break;
+	case VPSS_IPIPE_CLOCK:
+		shift = 4;
+		break;
+	case VPSS_IPIPEIF_CLOCK:
+		shift = 5;
+		break;
+	case VPSS_PCLK_INTERNAL:
+		shift = 6;
+		break;
+	case VPSS_PSYNC_CLOCK_SEL:
+		shift = 7;
+		break;
+	case VPSS_VPBE_CLOCK:
+		read = vpss_regr;
+		write = vpss_regw;
+		offset = DM365_VPBE_CLK_CTRL;
+		break;
+	case VPSS_VENC_CLOCK_SEL:
+		shift = 2;
+		read = vpss_regr;
+		write = vpss_regw;
+		offset = DM365_VPBE_CLK_CTRL;
+		break;
+	case VPSS_LDC_CLOCK:
+		shift = 3;
+		read = vpss_regr;
+		write = vpss_regw;
+		offset = DM365_VPBE_CLK_CTRL;
+		break;
+	case VPSS_FDIF_CLOCK:
+		shift = 4;
+		read = vpss_regr;
+		write = vpss_regw;
+		offset = DM365_VPBE_CLK_CTRL;
+		break;
+	case VPSS_OSD_CLOCK_SEL:
+		shift = 6;
+		read = vpss_regr;
+		write = vpss_regw;
+		offset = DM365_VPBE_CLK_CTRL;
+		break;
+	case VPSS_LDC_CLOCK_SEL:
+		shift = 7;
+		read = vpss_regr;
+		write = vpss_regw;
+		offset = DM365_VPBE_CLK_CTRL;
+		break;
+	default:
+		printk(KERN_ERR "dm365_enable_clock: Invalid selector: %d\n",
+		       clock_sel);
+		return -1;
+	}
+
+	spin_lock_irqsave(&oper_cfg.vpss_lock, flags);
+	utemp = read(offset);
+	if (!en) {
+		mask = ~mask;
+		utemp &= (mask << shift);
+	} else
+		utemp |= (mask << shift);
+
+	write(utemp, offset);
+	spin_unlock_irqrestore(&oper_cfg.vpss_lock, flags);
+
+	return 0;
+}
+
 int vpss_enable_clock(enum vpss_clock_sel clock_sel, int en)
 {
 	if (!oper_cfg.hw_ops.enable_clock)
-		return -1;
+		return -EINVAL;
 
 	return oper_cfg.hw_ops.enable_clock(clock_sel, en);
 }
 EXPORT_SYMBOL(vpss_enable_clock);
 
+void dm365_vpss_set_sync_pol(struct vpss_sync_pol sync)
+{
+	int val = 0;
+	val = isp5_read(DM365_ISP5_CCDCMUX);
+
+	val |= (sync.ccdpg_hdpol << DM365_CCDC_PG_HD_POL_SHIFT);
+	val |= (sync.ccdpg_vdpol << DM365_CCDC_PG_VD_POL_SHIFT);
+
+	isp5_write(val, DM365_ISP5_CCDCMUX);
+}
+EXPORT_SYMBOL(dm365_vpss_set_sync_pol);
+
+void dm365_vpss_set_pg_frame_size(struct vpss_pg_frame_size frame_size)
+{
+	int current_reg = ((frame_size.hlpfr >> 1) - 1) << 16;
+
+	current_reg |= (frame_size.pplen - 1);
+	isp5_write(current_reg, DM365_ISP5_PG_FRAME_SIZE);
+}
+EXPORT_SYMBOL(dm365_vpss_set_pg_frame_size);
+
 static int __init vpss_probe(struct platform_device *pdev)
 {
-	int status, dm355 = 0;
+	struct resource		*r1, *r2;
+	char *platform_name;
+	int status;
 
 	if (!pdev->dev.platform_data) {
 		dev_err(&pdev->dev, "no platform data\n");
 		return -ENOENT;
 	}
-	strcpy(oper_cfg.vpss_name, pdev->dev.platform_data);
 
-	if (!strcmp(oper_cfg.vpss_name, "dm355_vpss"))
-		dm355 = 1;
-	else if (strcmp(oper_cfg.vpss_name, "dm644x_vpss")) {
+	platform_name = pdev->dev.platform_data;
+	if (!strcmp(platform_name, "dm355_vpss"))
+		oper_cfg.platform = DM355;
+	else if (!strcmp(platform_name, "dm365_vpss"))
+		oper_cfg.platform = DM365;
+	else if (!strcmp(platform_name, "dm644x_vpss"))
+		oper_cfg.platform = DM644X;
+	else {
 		dev_err(&pdev->dev, "vpss driver not supported on"
 			" this platform\n");
 		return -ENODEV;
 	}
 
-	dev_info(&pdev->dev, "%s vpss probed\n", oper_cfg.vpss_name);
-	oper_cfg.r1 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (!oper_cfg.r1)
+	dev_info(&pdev->dev, "%s vpss probed\n", platform_name);
+	r1 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!r1)
 		return -ENOENT;
 
-	oper_cfg.len1 = oper_cfg.r1->end - oper_cfg.r1->start + 1;
-
-	oper_cfg.r1 = request_mem_region(oper_cfg.r1->start, oper_cfg.len1,
-					 oper_cfg.r1->name);
-	if (!oper_cfg.r1)
+	r1 = request_mem_region(r1->start, resource_size(r1), r1->name);
+	if (!r1)
 		return -EBUSY;
 
-	oper_cfg.vpss_bl_regs_base = ioremap(oper_cfg.r1->start, oper_cfg.len1);
-	if (!oper_cfg.vpss_bl_regs_base) {
+	oper_cfg.vpss_regs_base0 = ioremap(r1->start, resource_size(r1));
+	if (!oper_cfg.vpss_regs_base0) {
 		status = -EBUSY;
 		goto fail1;
 	}
 
-	if (dm355) {
-		oper_cfg.r2 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-		if (!oper_cfg.r2) {
+	if (oper_cfg.platform == DM355 || oper_cfg.platform == DM365) {
+		r2 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+		if (!r2) {
 			status = -ENOENT;
 			goto fail2;
 		}
-		oper_cfg.len2 = oper_cfg.r2->end - oper_cfg.r2->start + 1;
-		oper_cfg.r2 = request_mem_region(oper_cfg.r2->start,
-						 oper_cfg.len2,
-						 oper_cfg.r2->name);
-		if (!oper_cfg.r2) {
+		r2 = request_mem_region(r2->start, resource_size(r2), r2->name);
+		if (!r2) {
 			status = -EBUSY;
 			goto fail2;
 		}
 
-		oper_cfg.vpss_regs_base = ioremap(oper_cfg.r2->start,
-						  oper_cfg.len2);
-		if (!oper_cfg.vpss_regs_base) {
+		oper_cfg.vpss_regs_base1 = ioremap(r2->start,
+						   resource_size(r2));
+		if (!oper_cfg.vpss_regs_base1) {
 			status = -EBUSY;
 			goto fail3;
 		}
 	}
 
-	if (dm355) {
+	if (oper_cfg.platform == DM355) {
 		oper_cfg.hw_ops.enable_clock = dm355_enable_clock;
 		oper_cfg.hw_ops.select_ccdc_source = dm355_select_ccdc_source;
+		/* Setup vpss interrupts */
+		bl_regw(DM355_VPSSBL_INTSEL_DEFAULT, DM355_VPSSBL_INTSEL);
+		bl_regw(DM355_VPSSBL_EVTSEL_DEFAULT, DM355_VPSSBL_EVTSEL);
+	} else if (oper_cfg.platform == DM365) {
+		oper_cfg.hw_ops.enable_clock = dm365_enable_clock;
+		oper_cfg.hw_ops.select_ccdc_source = dm365_select_ccdc_source;
+		/* Setup vpss interrupts */
+		isp5_write(DM365_ISP5_INTSEL1_DEFAULT, DM365_ISP5_INTSEL1);
+		isp5_write(DM365_ISP5_INTSEL2_DEFAULT, DM365_ISP5_INTSEL2);
+		isp5_write(DM365_ISP5_INTSEL3_DEFAULT, DM365_ISP5_INTSEL3);
 	} else
 		oper_cfg.hw_ops.clear_wbl_overflow = dm644x_clear_wbl_overflow;
 
 	spin_lock_init(&oper_cfg.vpss_lock);
-	dev_info(&pdev->dev, "%s vpss probe success\n", oper_cfg.vpss_name);
+	dev_info(&pdev->dev, "%s vpss probe success\n", platform_name);
 	return 0;
 
 fail3:
-	release_mem_region(oper_cfg.r2->start, oper_cfg.len2);
+	release_mem_region(r2->start, resource_size(r2));
 fail2:
-	iounmap(oper_cfg.vpss_bl_regs_base);
+	iounmap(oper_cfg.vpss_regs_base0);
 fail1:
-	release_mem_region(oper_cfg.r1->start, oper_cfg.len1);
+	release_mem_region(r1->start, resource_size(r1));
 	return status;
 }
 
 static int __devexit vpss_remove(struct platform_device *pdev)
 {
-	iounmap(oper_cfg.vpss_bl_regs_base);
-	release_mem_region(oper_cfg.r1->start, oper_cfg.len1);
-	if (!strcmp(oper_cfg.vpss_name, "dm355_vpss")) {
-		iounmap(oper_cfg.vpss_regs_base);
-		release_mem_region(oper_cfg.r2->start, oper_cfg.len2);
+	struct resource		*res;
+
+	iounmap(oper_cfg.vpss_regs_base0);
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	release_mem_region(res->start, resource_size(res));
+	if (oper_cfg.platform == DM355 || oper_cfg.platform == DM365) {
+		iounmap(oper_cfg.vpss_regs_base1);
+		res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+		release_mem_region(res->start, resource_size(res));
 	}
 	return 0;
 }
diff --git a/include/media/davinci/vpss.h b/include/media/davinci/vpss.h
index fcdff74..c59cc02 100644
--- a/include/media/davinci/vpss.h
+++ b/include/media/davinci/vpss.h
@@ -29,7 +29,19 @@
 /* selector for ccdc input selection on DM355 */
 enum vpss_ccdc_source_sel {
 	VPSS_CCDCIN,
-	VPSS_HSSIIN
+	VPSS_HSSIIN,
+	VPSS_PGLPBK,	/* for DM365 only */
+	VPSS_CCDCPG	/* for DM365 only */
+};
+
+struct vpss_sync_pol {
+	unsigned int ccdpg_hdpol:1;
+	unsigned int ccdpg_vdpol:1;
+};
+
+struct vpss_pg_frame_size {
+	short hlpfr;
+	short pplen;
 };
 
 /* Used for enable/diable VPSS Clock */
@@ -47,12 +59,38 @@ enum vpss_clock_sel {
 	 */
 	VPSS_VENC_CLOCK_SEL,
 	VPSS_VPBE_CLOCK,
+	/* DM365 only clocks */
+	VPSS_IPIPEIF_CLOCK,
+	VPSS_RSZ_CLOCK,
+	VPSS_BL_CLOCK,
+	/*
+	 * When using VPSS_PCLK_INTERNAL in vpss_enable_clock() api
+	 * following applies:-
+	 * en = 0 disable internal PCLK
+	 * en = 1 enables internal PCLK
+	 */
+	VPSS_PCLK_INTERNAL,
+	/*
+	 * When using VPSS_PSYNC_CLOCK_SEL in vpss_enable_clock() api
+	 * following applies:-
+	 * en = 0 enables MMR clock
+	 * en = 1 enables VPSS clock
+	 */
+	VPSS_PSYNC_CLOCK_SEL,
+	VPSS_LDC_CLOCK_SEL,
+	VPSS_OSD_CLOCK_SEL,
+	VPSS_FDIF_CLOCK,
+	VPSS_LDC_CLOCK
 };
 
 /* select input to ccdc on dm355 */
 int vpss_select_ccdc_source(enum vpss_ccdc_source_sel src_sel);
 /* enable/disable a vpss clock, 0 - success, -1 - failure */
 int vpss_enable_clock(enum vpss_clock_sel clock_sel, int en);
+/* set sync polarity, only for DM365*/
+void dm365_vpss_set_sync_pol(struct vpss_sync_pol);
+/* set the PG_FRAME_SIZE register, only for DM365 */
+void dm365_vpss_set_pg_frame_size(struct vpss_pg_frame_size);
 
 /* wbl reset for dm644x */
 enum vpss_wbl_sel {
@@ -65,5 +103,6 @@ enum vpss_wbl_sel {
 	VPSS_PCR_PREV_WBL_0,
 	VPSS_PCR_CCDC_WBL_O,
 };
+/* clear wbl overflow flag for DM6446 */
 int vpss_clear_wbl_overflow(enum vpss_wbl_sel wbl_sel);
 #endif
-- 
1.6.0.4


From m-karicheri2 at ti.com  Mon Feb  1 16:27:16 2010
From: m-karicheri2 at ti.com (m-karicheri2 at ti.com)
Date: Mon,  1 Feb 2010 17:27:16 -0500
Subject: [PATCH v3 2/6] V4L - vpfe capture - source for ISIF driver on DM365
In-Reply-To: <1265063238-29072-3-git-send-email-m-karicheri2@ti.com>
References: <1265063238-29072-1-git-send-email-m-karicheri2@ti.com>
	<1265063238-29072-2-git-send-email-m-karicheri2@ti.com>
	<1265063238-29072-3-git-send-email-m-karicheri2@ti.com>
Message-ID: <1265063238-29072-4-git-send-email-m-karicheri2@ti.com>

From: Murali Karicheri <m-karicheri2 at ti.com>

This is the source file for ISIF driver for DM365.  ISIF driver is equivalent
to CCDC driver on DM355 and DM644x. This driver is tested for
YUV capture from TVP514x driver. This patch contains the header files required for
this driver. The name of the file is changed to reflect the name of IP.

Reviewed-by: Nori, Sekhar <nsekhar at ti.com>
Reviewed-by: Hans Verkuil <hverkuil at xs4all.nl>

Signed-off-by: Hans Verkuil <hverkuil at xs4all.nl>
Signed-off-by: Murali Karicheri <m-karicheri2 at ti.com>
---
Applies to linux-next tree of v4l-dvb 
 - Rebasing to latest tree for merge (v3)
 - Updated based on comments against v1 of the patch (v2).
 drivers/media/video/davinci/isif.c | 1513 ++++++++++++++++++++++++++++++++++++
 1 files changed, 1513 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/isif.c

diff --git a/drivers/media/video/davinci/isif.c b/drivers/media/video/davinci/isif.c
new file mode 100644
index 0000000..343a74d
--- /dev/null
+++ b/drivers/media/video/davinci/isif.c
@@ -0,0 +1,1513 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * 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
+ *
+ * Image Sensor Interface (ISIF) driver
+ *
+ * This driver is for configuring the ISIF IP available on DM365 or any other
+ * TI SoCs. This is used for capturing yuv or bayer video or image data
+ * from a decoder or sensor. This IP is similar to the CCDC IP on DM355
+ * and DM6446, but with enhanced or additional ip blocks. The driver
+ * configures the ISIF upon commands from the vpfe bridge driver through
+ * ccdc_hw_device interface.
+ *
+ * TODO: 1) Raw bayer parameter settings and bayer capture
+ *	 2) Add support for control ioctl
+ */
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+#include <linux/uaccess.h>
+#include <linux/io.h>
+#include <linux/videodev2.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+
+#include <mach/mux.h>
+
+#include <media/davinci/isif.h>
+#include <media/davinci/vpss.h>
+
+#include "isif_regs.h"
+#include "ccdc_hw_device.h"
+
+/* Defaults for module configuration parameters */
+static struct isif_config_params_raw isif_config_defaults = {
+	.linearize = {
+		.en = 0,
+		.corr_shft = ISIF_NO_SHIFT,
+		.scale_fact = {1, 0},
+	},
+	.df_csc = {
+		.df_or_csc = 0,
+		.csc = {
+			.en = 0,
+		},
+	},
+	.dfc = {
+		.en = 0,
+	},
+	.bclamp = {
+		.en = 0,
+	},
+	.gain_offset = {
+		.gain = {
+			.r_ye = {1, 0},
+			.gr_cy = {1, 0},
+			.gb_g = {1, 0},
+			.b_mg = {1, 0},
+		},
+	},
+	.culling = {
+		.hcpat_odd = 0xff,
+		.hcpat_even = 0xff,
+		.vcpat = 0xff,
+	},
+	.compress = {
+		.alg = ISIF_ALAW,
+	},
+};
+
+/* ISIF operation configuration */
+static struct isif_oper_config {
+	struct device *dev;
+	enum vpfe_hw_if_type if_type;
+	struct isif_ycbcr_config ycbcr;
+	struct isif_params_raw bayer;
+	enum isif_data_pack data_pack;
+	/* Master clock */
+	struct clk *mclk;
+	/* ISIF base address */
+	void __iomem *base_addr;
+	/* ISIF Linear Table 0 */
+	void __iomem *linear_tbl0_addr;
+	/* ISIF Linear Table 1 */
+	void __iomem *linear_tbl1_addr;
+} isif_cfg = {
+	.ycbcr = {
+		.pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+		.frm_fmt = CCDC_FRMFMT_INTERLACED,
+		.win = ISIF_WIN_NTSC,
+		.fid_pol = VPFE_PINPOL_POSITIVE,
+		.vd_pol = VPFE_PINPOL_POSITIVE,
+		.hd_pol = VPFE_PINPOL_POSITIVE,
+		.pix_order = CCDC_PIXORDER_CBYCRY,
+		.buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED,
+	},
+	.bayer = {
+		.pix_fmt = CCDC_PIXFMT_RAW,
+		.frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+		.win = ISIF_WIN_VGA,
+		.fid_pol = VPFE_PINPOL_POSITIVE,
+		.vd_pol = VPFE_PINPOL_POSITIVE,
+		.hd_pol = VPFE_PINPOL_POSITIVE,
+		.gain = {
+			.r_ye = {1, 0},
+			.gr_cy = {1, 0},
+			.gb_g = {1, 0},
+			.b_mg = {1, 0},
+		},
+		.cfa_pat = ISIF_CFA_PAT_MOSAIC,
+		.data_msb = ISIF_BIT_MSB_11,
+		.config_params = {
+			.data_shift = ISIF_NO_SHIFT,
+			.col_pat_field0 = {
+				.olop = ISIF_GREEN_BLUE,
+				.olep = ISIF_BLUE,
+				.elop = ISIF_RED,
+				.elep = ISIF_GREEN_RED,
+			},
+			.col_pat_field1 = {
+				.olop = ISIF_GREEN_BLUE,
+				.olep = ISIF_BLUE,
+				.elop = ISIF_RED,
+				.elep = ISIF_GREEN_RED,
+			},
+			.test_pat_gen = 0,
+		},
+	},
+	.data_pack = ISIF_DATA_PACK8,
+};
+
+/* Raw Bayer formats */
+static const u32 isif_raw_bayer_pix_formats[] =
+		{V4L2_PIX_FMT_SBGGR8, V4L2_PIX_FMT_SBGGR16};
+
+/* Raw YUV formats */
+static const u32 isif_raw_yuv_pix_formats[] =
+		{V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YUYV};
+
+/* register access routines */
+static inline u32 regr(u32 offset)
+{
+	return __raw_readl(isif_cfg.base_addr + offset);
+}
+
+static inline void regw(u32 val, u32 offset)
+{
+	__raw_writel(val, isif_cfg.base_addr + offset);
+}
+
+/* reg_modify() - read, modify and write register */
+static inline u32 reg_modify(u32 mask, u32 val, u32 offset)
+{
+	u32 new_val = (regr(offset) & ~mask) | (val & mask);
+
+	regw(new_val, offset);
+	return new_val;
+}
+
+static inline void regw_lin_tbl(u32 val, u32 offset, int i)
+{
+	if (!i)
+		__raw_writel(val, isif_cfg.linear_tbl0_addr + offset);
+	else
+		__raw_writel(val, isif_cfg.linear_tbl1_addr + offset);
+}
+
+static void isif_disable_all_modules(void)
+{
+	/* disable BC */
+	regw(0, CLAMPCFG);
+	/* disable vdfc */
+	regw(0, DFCCTL);
+	/* disable CSC */
+	regw(0, CSCCTL);
+	/* disable linearization */
+	regw(0, LINCFG0);
+	/* disable other modules here as they are supported */
+}
+
+static void isif_enable(int en)
+{
+	if (!en) {
+		/* Before disable isif, disable all ISIF modules */
+		isif_disable_all_modules();
+		/*
+		 * wait for next VD. Assume lowest scan rate is 12 Hz. So
+		 * 100 msec delay is good enough
+		 */
+		msleep(100);
+	}
+	reg_modify(ISIF_SYNCEN_VDHDEN_MASK, en, SYNCEN);
+}
+
+static void isif_enable_output_to_sdram(int en)
+{
+	reg_modify(ISIF_SYNCEN_WEN_MASK, en << ISIF_SYNCEN_WEN_SHIFT, SYNCEN);
+}
+
+static void isif_config_culling(struct isif_cul *cul)
+{
+	u32 val;
+
+	/* Horizontal pattern */
+	val = (cul->hcpat_even << CULL_PAT_EVEN_LINE_SHIFT) | cul->hcpat_odd;
+	regw(val, CULH);
+
+	/* vertical pattern */
+	regw(cul->vcpat, CULV);
+
+	/* LPF */
+	reg_modify(ISIF_LPF_MASK << ISIF_LPF_SHIFT,
+		  cul->en_lpf << ISIF_LPF_SHIFT, MODESET);
+}
+
+static void isif_config_gain_offset(void)
+{
+	struct isif_gain_offsets_adj *gain_off_p =
+		&isif_cfg.bayer.config_params.gain_offset;
+	u32 val;
+
+	val = (!!gain_off_p->gain_sdram_en << GAIN_SDRAM_EN_SHIFT) |
+	      (!!gain_off_p->gain_ipipe_en << GAIN_IPIPE_EN_SHIFT) |
+	      (!!gain_off_p->gain_h3a_en << GAIN_H3A_EN_SHIFT) |
+	      (!!gain_off_p->offset_sdram_en << OFST_SDRAM_EN_SHIFT) |
+	      (!!gain_off_p->offset_ipipe_en << OFST_IPIPE_EN_SHIFT) |
+	      (!!gain_off_p->offset_h3a_en << OFST_H3A_EN_SHIFT);
+
+	reg_modify(GAIN_OFFSET_EN_MASK, val, CGAMMAWD);
+
+	val = (gain_off_p->gain.r_ye.integer << GAIN_INTEGER_SHIFT) |
+	       gain_off_p->gain.r_ye.decimal;
+	regw(val, CRGAIN);
+
+	val = (gain_off_p->gain.gr_cy.integer << GAIN_INTEGER_SHIFT) |
+	       gain_off_p->gain.gr_cy.decimal;
+	regw(val, CGRGAIN);
+
+	val = (gain_off_p->gain.gb_g.integer << GAIN_INTEGER_SHIFT) |
+	       gain_off_p->gain.gb_g.decimal;
+	regw(val, CGBGAIN);
+
+	val = (gain_off_p->gain.b_mg.integer << GAIN_INTEGER_SHIFT) |
+	       gain_off_p->gain.b_mg.decimal;
+	regw(val, CBGAIN);
+
+	regw(gain_off_p->offset, COFSTA);
+}
+
+static void isif_restore_defaults(void)
+{
+	enum vpss_ccdc_source_sel source = VPSS_CCDCIN;
+
+	dev_dbg(isif_cfg.dev, "\nstarting isif_restore_defaults...");
+	isif_cfg.bayer.config_params = isif_config_defaults;
+	/* Enable clock to ISIF, IPIPEIF and BL */
+	vpss_enable_clock(VPSS_CCDC_CLOCK, 1);
+	vpss_enable_clock(VPSS_IPIPEIF_CLOCK, 1);
+	vpss_enable_clock(VPSS_BL_CLOCK, 1);
+	/* Set default offset and gain */
+	isif_config_gain_offset();
+	vpss_select_ccdc_source(source);
+	dev_dbg(isif_cfg.dev, "\nEnd of isif_restore_defaults...");
+}
+
+static int isif_open(struct device *device)
+{
+	isif_restore_defaults();
+	return 0;
+}
+
+/* This function will configure the window size to be capture in ISIF reg */
+static void isif_setwin(struct v4l2_rect *image_win,
+			enum ccdc_frmfmt frm_fmt, int ppc)
+{
+	int horz_start, horz_nr_pixels;
+	int vert_start, vert_nr_lines;
+	int mid_img = 0;
+
+	dev_dbg(isif_cfg.dev, "\nStarting isif_setwin...");
+	/*
+	 * ppc - per pixel count. indicates how many pixels per cell
+	 * output to SDRAM. example, for ycbcr, it is one y and one c, so 2.
+	 * raw capture this is 1
+	 */
+	horz_start = image_win->left << (ppc - 1);
+	horz_nr_pixels = ((image_win->width) << (ppc - 1)) - 1;
+
+	/* Writing the horizontal info into the registers */
+	regw(horz_start & START_PX_HOR_MASK, SPH);
+	regw(horz_nr_pixels & NUM_PX_HOR_MASK, LNH);
+	vert_start = image_win->top;
+
+	if (frm_fmt == CCDC_FRMFMT_INTERLACED) {
+		vert_nr_lines = (image_win->height >> 1) - 1;
+		vert_start >>= 1;
+		/* To account for VD since line 0 doesn't have any data */
+		vert_start += 1;
+	} else {
+		/* To account for VD since line 0 doesn't have any data */
+		vert_start += 1;
+		vert_nr_lines = image_win->height - 1;
+		/* configure VDINT0 and VDINT1 */
+		mid_img = vert_start + (image_win->height / 2);
+		regw(mid_img, VDINT1);
+	}
+
+	regw(0, VDINT0);
+	regw(vert_start & START_VER_ONE_MASK, SLV0);
+	regw(vert_start & START_VER_TWO_MASK, SLV1);
+	regw(vert_nr_lines & NUM_LINES_VER, LNV);
+}
+
+static void isif_config_bclamp(struct isif_black_clamp *bc)
+{
+	u32 val;
+
+	/*
+	 * DC Offset is always added to image data irrespective of bc enable
+	 * status
+	 */
+	regw(bc->dc_offset, CLDCOFST);
+
+	if (bc->en) {
+		val = bc->bc_mode_color << ISIF_BC_MODE_COLOR_SHIFT;
+
+		/* Enable BC and horizontal clamp caculation paramaters */
+		val = val | 1 | (bc->horz.mode << ISIF_HORZ_BC_MODE_SHIFT);
+
+		regw(val, CLAMPCFG);
+
+		if (bc->horz.mode != ISIF_HORZ_BC_DISABLE) {
+			/*
+			 * Window count for calculation
+			 * Base window selection
+			 * pixel limit
+			 * Horizontal size of window
+			 * vertical size of the window
+			 * Horizontal start position of the window
+			 * Vertical start position of the window
+			 */
+			val = bc->horz.win_count_calc |
+			      ((!!bc->horz.base_win_sel_calc) <<
+				ISIF_HORZ_BC_WIN_SEL_SHIFT) |
+			      ((!!bc->horz.clamp_pix_limit) <<
+				ISIF_HORZ_BC_PIX_LIMIT_SHIFT) |
+			      (bc->horz.win_h_sz_calc <<
+				ISIF_HORZ_BC_WIN_H_SIZE_SHIFT) |
+			      (bc->horz.win_v_sz_calc <<
+				ISIF_HORZ_BC_WIN_V_SIZE_SHIFT);
+			regw(val, CLHWIN0);
+
+			regw(bc->horz.win_start_h_calc, CLHWIN1);
+			regw(bc->horz.win_start_v_calc, CLHWIN2);
+		}
+
+		/* vertical clamp caculation paramaters */
+
+		/* Reset clamp value sel for previous line */
+		val |=
+		(bc->vert.reset_val_sel << ISIF_VERT_BC_RST_VAL_SEL_SHIFT) |
+		(bc->vert.line_ave_coef << ISIF_VERT_BC_LINE_AVE_COEF_SHIFT);
+		regw(val, CLVWIN0);
+
+		/* Optical Black horizontal start position */
+		regw(bc->vert.ob_start_h, CLVWIN1);
+		/* Optical Black vertical start position */
+		regw(bc->vert.ob_start_v, CLVWIN2);
+		/* Optical Black vertical size for calculation */
+		regw(bc->vert.ob_v_sz_calc, CLVWIN3);
+		/* Vertical start position for BC subtraction */
+		regw(bc->vert_start_sub, CLSV);
+	}
+}
+
+static void isif_config_linearization(struct isif_linearize *linearize)
+{
+	u32 val, i;
+
+	if (!linearize->en) {
+		regw(0, LINCFG0);
+		return;
+	}
+
+	/* shift value for correction & enable linearization (set lsb) */
+	val = (linearize->corr_shft << ISIF_LIN_CORRSFT_SHIFT) | 1;
+	regw(val, LINCFG0);
+
+	/* Scale factor */
+	val = ((!!linearize->scale_fact.integer) <<
+	       ISIF_LIN_SCALE_FACT_INTEG_SHIFT) |
+	       linearize->scale_fact.decimal;
+	regw(val, LINCFG1);
+
+	for (i = 0; i < ISIF_LINEAR_TAB_SIZE; i++) {
+		if (i % 2)
+			regw_lin_tbl(linearize->table[i], ((i >> 1) << 2), 1);
+		else
+			regw_lin_tbl(linearize->table[i], ((i >> 1) << 2), 0);
+	}
+}
+
+static int isif_config_dfc(struct isif_dfc *vdfc)
+{
+	/* initialize retries to loop for max ~ 250 usec */
+	u32 val, count, retries = loops_per_jiffy / (4000/HZ);
+	int i;
+
+	if (!vdfc->en)
+		return 0;
+
+	/* Correction mode */
+	val = (vdfc->corr_mode << ISIF_VDFC_CORR_MOD_SHIFT);
+
+	/* Correct whole line or partial */
+	if (vdfc->corr_whole_line)
+		val |= 1 << ISIF_VDFC_CORR_WHOLE_LN_SHIFT;
+
+	/* level shift value */
+	val |= vdfc->def_level_shift << ISIF_VDFC_LEVEL_SHFT_SHIFT;
+
+	regw(val, DFCCTL);
+
+	/* Defect saturation level */
+	regw(vdfc->def_sat_level, VDFSATLV);
+
+	regw(vdfc->table[0].pos_vert, DFCMEM0);
+	regw(vdfc->table[0].pos_horz, DFCMEM1);
+	if (vdfc->corr_mode == ISIF_VDFC_NORMAL ||
+	    vdfc->corr_mode == ISIF_VDFC_HORZ_INTERPOL_IF_SAT) {
+		regw(vdfc->table[0].level_at_pos, DFCMEM2);
+		regw(vdfc->table[0].level_up_pixels, DFCMEM3);
+		regw(vdfc->table[0].level_low_pixels, DFCMEM4);
+	}
+
+	/* set DFCMARST and set DFCMWR */
+	val = regr(DFCMEMCTL) | (1 << ISIF_DFCMEMCTL_DFCMARST_SHIFT) | 1;
+	regw(val, DFCMEMCTL);
+
+	count = retries;
+	while (count && (regr(DFCMEMCTL) & 0x1))
+		count--;
+
+	if (!count) {
+		dev_dbg(isif_cfg.dev, "defect table write timeout !!!\n");
+		return -1;
+	}
+
+	for (i = 1; i < vdfc->num_vdefects; i++) {
+		regw(vdfc->table[i].pos_vert, DFCMEM0);
+		regw(vdfc->table[i].pos_horz, DFCMEM1);
+		if (vdfc->corr_mode == ISIF_VDFC_NORMAL ||
+		    vdfc->corr_mode == ISIF_VDFC_HORZ_INTERPOL_IF_SAT) {
+			regw(vdfc->table[i].level_at_pos, DFCMEM2);
+			regw(vdfc->table[i].level_up_pixels, DFCMEM3);
+			regw(vdfc->table[i].level_low_pixels, DFCMEM4);
+		}
+		val = regr(DFCMEMCTL);
+		/* clear DFCMARST and set DFCMWR */
+		val &= ~BIT(ISIF_DFCMEMCTL_DFCMARST_SHIFT);
+		val |= 1;
+		regw(val, DFCMEMCTL);
+
+		count = retries;
+		while (count && (regr(DFCMEMCTL) & 0x1))
+			count--;
+
+		if (!count) {
+			dev_err(isif_cfg.dev,
+				"defect table write timeout !!!\n");
+			return -1;
+		}
+	}
+	if (vdfc->num_vdefects < ISIF_VDFC_TABLE_SIZE) {
+		/* Extra cycle needed */
+		regw(0, DFCMEM0);
+		regw(0x1FFF, DFCMEM1);
+		regw(1, DFCMEMCTL);
+	}
+
+	/* enable VDFC */
+	reg_modify((1 << ISIF_VDFC_EN_SHIFT), (1 << ISIF_VDFC_EN_SHIFT),
+		   DFCCTL);
+	return 0;
+}
+
+static void isif_config_csc(struct isif_df_csc *df_csc)
+{
+	u32 val1 = 0, val2 = 0, i;
+
+	if (!df_csc->csc.en) {
+		regw(0, CSCCTL);
+		return;
+	}
+	for (i = 0; i < ISIF_CSC_NUM_COEFF; i++) {
+		if ((i % 2) == 0) {
+			/* CSCM - LSB */
+			val1 = (df_csc->csc.coeff[i].integer <<
+				ISIF_CSC_COEF_INTEG_SHIFT) |
+				df_csc->csc.coeff[i].decimal;
+		} else {
+
+			/* CSCM - MSB */
+			val2 = (df_csc->csc.coeff[i].integer <<
+				ISIF_CSC_COEF_INTEG_SHIFT) |
+				df_csc->csc.coeff[i].decimal;
+			val2 <<= ISIF_CSCM_MSB_SHIFT;
+			val2 |= val1;
+			regw(val2, (CSCM0 + ((i - 1) << 1)));
+		}
+	}
+
+	/* program the active area */
+	regw(df_csc->start_pix, FMTSPH);
+	/*
+	 * one extra pixel as required for CSC. Actually number of
+	 * pixel - 1 should be configured in this register. So we
+	 * need to subtract 1 before writing to FMTSPH, but we will
+	 * not do this since csc requires one extra pixel
+	 */
+	regw(df_csc->num_pixels, FMTLNH);
+	regw(df_csc->start_line, FMTSLV);
+	/*
+	 * one extra line as required for CSC. See reason documented for
+	 * num_pixels
+	 */
+	regw(df_csc->num_lines, FMTLNV);
+
+	/* Enable CSC */
+	regw(1, CSCCTL);
+}
+
+static int isif_config_raw(void)
+{
+	struct isif_params_raw *params = &isif_cfg.bayer;
+	struct isif_config_params_raw *module_params =
+		&isif_cfg.bayer.config_params;
+	struct vpss_pg_frame_size frame_size;
+	struct vpss_sync_pol sync;
+	u32 val;
+
+	dev_dbg(isif_cfg.dev, "\nStarting isif_config_raw..\n");
+
+	/*
+	 * Configure CCDCFG register:-
+	 * Set CCD Not to swap input since input is RAW data
+	 * Set FID detection function to Latch at V-Sync
+	 * Set WENLOG - isif valid area
+	 * Set TRGSEL
+	 * Set EXTRG
+	 * Packed to 8 or 16 bits
+	 */
+
+	val = ISIF_YCINSWP_RAW | ISIF_CCDCFG_FIDMD_LATCH_VSYNC |
+		ISIF_CCDCFG_WENLOG_AND | ISIF_CCDCFG_TRGSEL_WEN |
+		ISIF_CCDCFG_EXTRG_DISABLE | isif_cfg.data_pack;
+
+	dev_dbg(isif_cfg.dev, "Writing 0x%x to ...CCDCFG \n", val);
+	regw(val, CCDCFG);
+
+	/*
+	 * Configure the vertical sync polarity(MODESET.VDPOL)
+	 * Configure the horizontal sync polarity (MODESET.HDPOL)
+	 * Configure frame id polarity (MODESET.FLDPOL)
+	 * Configure data polarity
+	 * Configure External WEN Selection
+	 * Configure frame format(progressive or interlace)
+	 * Configure pixel format (Input mode)
+	 * Configure the data shift
+	 */
+
+	val = ISIF_VDHDOUT_INPUT | (params->vd_pol << ISIF_VD_POL_SHIFT) |
+		(params->hd_pol << ISIF_HD_POL_SHIFT) |
+		(params->fid_pol << ISIF_FID_POL_SHIFT) |
+		(ISIF_DATAPOL_NORMAL << ISIF_DATAPOL_SHIFT) |
+		(ISIF_EXWEN_DISABLE << ISIF_EXWEN_SHIFT) |
+		(params->frm_fmt << ISIF_FRM_FMT_SHIFT) |
+		(params->pix_fmt << ISIF_INPUT_SHIFT) |
+		(params->config_params.data_shift << ISIF_DATASFT_SHIFT);
+
+	regw(val, MODESET);
+	dev_dbg(isif_cfg.dev, "Writing 0x%x to MODESET...\n", val);
+
+	/*
+	 * Configure GAMMAWD register
+	 * CFA pattern setting
+	 */
+	val = params->cfa_pat << ISIF_GAMMAWD_CFA_SHIFT;
+
+	/* Gamma msb */
+	if (module_params->compress.alg == ISIF_ALAW)
+		val |= ISIF_ALAW_ENABLE;
+
+	val |= (params->data_msb << ISIF_ALAW_GAMA_WD_SHIFT);
+	regw(val, CGAMMAWD);
+
+	/* Configure DPCM compression settings */
+	if (module_params->compress.alg == ISIF_DPCM) {
+		val =  BIT(ISIF_DPCM_EN_SHIFT) |
+		       (module_params->compress.pred <<
+		       ISIF_DPCM_PREDICTOR_SHIFT);
+	}
+
+	regw(val, MISC);
+
+	/* Configure Gain & Offset */
+	isif_config_gain_offset();
+
+	/* Configure Color pattern */
+	val = (params->config_params.col_pat_field0.olop) |
+	      (params->config_params.col_pat_field0.olep << 2) |
+	      (params->config_params.col_pat_field0.elop << 4) |
+	      (params->config_params.col_pat_field0.elep << 6) |
+	      (params->config_params.col_pat_field1.olop << 8) |
+	      (params->config_params.col_pat_field1.olep << 10) |
+	      (params->config_params.col_pat_field1.elop << 12) |
+	      (params->config_params.col_pat_field1.elep << 14);
+	regw(val, CCOLP);
+	dev_dbg(isif_cfg.dev, "Writing %x to CCOLP ...\n", val);
+
+	/* Configure HSIZE register  */
+	val = (!!params->horz_flip_en) << ISIF_HSIZE_FLIP_SHIFT;
+
+	/* calculate line offset in 32 bytes based on pack value */
+	if (isif_cfg.data_pack == ISIF_PACK_8BIT)
+		val |= ((params->win.width + 31) >> 5);
+	else if (isif_cfg.data_pack == ISIF_PACK_12BIT)
+		val |= (((params->win.width +
+		       (params->win.width >> 2)) + 31) >> 5);
+	else
+		val |= (((params->win.width * 2) + 31) >> 5);
+	regw(val, HSIZE);
+
+	/* Configure SDOFST register  */
+	if (params->frm_fmt == CCDC_FRMFMT_INTERLACED) {
+		if (params->image_invert_en) {
+			/* For interlace inverse mode */
+			regw(0x4B6D, SDOFST);
+			dev_dbg(isif_cfg.dev, "Writing 0x4B6D to SDOFST...\n");
+		} else {
+			/* For interlace non inverse mode */
+			regw(0x0B6D, SDOFST);
+			dev_dbg(isif_cfg.dev, "Writing 0x0B6D to SDOFST...\n");
+		}
+	} else if (params->frm_fmt == CCDC_FRMFMT_PROGRESSIVE) {
+		if (params->image_invert_en) {
+			/* For progressive inverse mode */
+			regw(0x4000, SDOFST);
+			dev_dbg(isif_cfg.dev, "Writing 0x4000 to SDOFST...\n");
+		} else {
+			/* For progressive non inverse mode */
+			regw(0x0000, SDOFST);
+			dev_dbg(isif_cfg.dev, "Writing 0x0000 to SDOFST...\n");
+		}
+	}
+
+	/* Configure video window */
+	isif_setwin(&params->win, params->frm_fmt, 1);
+
+	/* Configure Black Clamp */
+	isif_config_bclamp(&module_params->bclamp);
+
+	/* Configure Vertical Defection Pixel Correction */
+	if (isif_config_dfc(&module_params->dfc) < 0)
+		return -EFAULT;
+
+	if (!module_params->df_csc.df_or_csc)
+		/* Configure Color Space Conversion */
+		isif_config_csc(&module_params->df_csc);
+
+	isif_config_linearization(&module_params->linearize);
+
+	/* Configure Culling */
+	isif_config_culling(&module_params->culling);
+
+	/* Configure horizontal and vertical offsets(DFC,LSC,Gain) */
+	regw(module_params->horz_offset, DATAHOFST);
+	regw(module_params->vert_offset, DATAVOFST);
+
+	/* Setup test pattern if enabled */
+	if (params->config_params.test_pat_gen) {
+		/* Use the HD/VD pol settings from user */
+		sync.ccdpg_hdpol = params->hd_pol;
+		sync.ccdpg_vdpol = params->vd_pol;
+		dm365_vpss_set_sync_pol(sync);
+		frame_size.hlpfr = isif_cfg.bayer.win.width;
+		frame_size.pplen = isif_cfg.bayer.win.height;
+		dm365_vpss_set_pg_frame_size(frame_size);
+		vpss_select_ccdc_source(VPSS_PGLPBK);
+	}
+
+	dev_dbg(isif_cfg.dev, "\nEnd of isif_config_ycbcr...\n");
+	return 0;
+}
+
+static int isif_validate_linearization_params(struct isif_linearize *linearize)
+{
+	int err = -EINVAL, i;
+
+	if (!linearize->en)
+		return 0;
+
+	if (linearize->corr_shft > 6) {
+		dev_dbg(isif_cfg.dev, "invalid linearization corr_shft val\n");
+		return err;
+	}
+
+	if (linearize->scale_fact.integer > 1 ||
+	    linearize->scale_fact.decimal > 0x3FF) {
+		dev_dbg(isif_cfg.dev, "invalid linearization scale_fact val\n");
+		return err;
+	}
+
+	for (i = 0; i < ISIF_LINEAR_TAB_SIZE; i++) {
+		if (linearize->table[i] > 0x3FF) {
+			dev_dbg(isif_cfg.dev,
+				"invalid linear table value at index %d\n", i);
+			return err;
+		}
+	}
+	return 0;
+}
+
+static int isif_validate_df_csc_params(struct isif_df_csc *df_csc)
+{
+	struct isif_color_space_conv *csc = &df_csc->csc;
+	int i, err = -EINVAL;
+
+	if (!df_csc->df_or_csc && csc->en) {
+		for (i = 0; i < ISIF_CSC_NUM_COEFF; i++) {
+			if (csc->coeff[i].integer > ISIF_CSC_COEF_INTEG_MASK ||
+			    csc->coeff[i].decimal >
+					ISIF_CSC_COEF_DECIMAL_MASK) {
+				dev_dbg(isif_cfg.dev,
+				       "invalid csc coefficients \n");
+				return err;
+			}
+		}
+	}
+
+	if (df_csc->start_pix > ISIF_DF_CSC_SPH_MASK) {
+		dev_dbg(isif_cfg.dev, "invalid df_csc start pix value \n");
+		return err;
+	}
+	if (df_csc->num_pixels > ISIF_DF_NUMPIX) {
+		dev_dbg(isif_cfg.dev, "invalid df_csc num pixels value \n");
+		return err;
+	}
+	if (df_csc->start_line > ISIF_DF_CSC_LNH_MASK) {
+		dev_dbg(isif_cfg.dev, "invalid df_csc start_line value \n");
+		return err;
+	}
+	if (df_csc->num_lines > ISIF_DF_NUMLINES) {
+		dev_dbg(isif_cfg.dev, "invalid df_csc num_lines value \n");
+		return err;
+	}
+	return 0;
+}
+
+static int isif_validate_dfc_params(struct isif_dfc *dfc)
+{
+	int err = -EINVAL;
+	int i;
+
+	if (!dfc->en)
+		return 0;
+
+	if (dfc->corr_whole_line > 1) {
+		dev_dbg(isif_cfg.dev, "invalid dfc corr_whole_line value\n");
+		return err;
+	}
+	if (dfc->corr_mode > 2) {
+		dev_dbg(isif_cfg.dev, "invalid dfc corr_mode value\n");
+		return err;
+	}
+
+	if (dfc->def_level_shift > 4) {
+		dev_dbg(isif_cfg.dev, "invalid dfc def_level_shift value\n");
+		return err;
+	}
+
+	if (dfc->def_sat_level > 4095) {
+		dev_dbg(isif_cfg.dev, "invalid dfc def_sat_level value \n");
+		return err;
+	}
+	if ((!dfc->num_vdefects) || (dfc->num_vdefects > 8)) {
+		dev_dbg(isif_cfg.dev, "invalid dfc num_vdefects value \n");
+		return err;
+	}
+	for (i = 0; i < ISIF_VDFC_TABLE_SIZE; i++) {
+		if (dfc->table[i].pos_vert > 0x1fff) {
+			dev_dbg(isif_cfg.dev, "invalid dfc pos_vert value \n");
+			return err;
+		}
+		if (dfc->table[i].pos_horz > 0x1fff) {
+			dev_dbg(isif_cfg.dev, "invalid dfc pos_horz value \n");
+			return err;
+		}
+	}
+	return 0;
+}
+
+static int isif_validate_bclamp_params(struct isif_black_clamp *bclamp)
+{
+	int err = -EINVAL;
+
+	if (bclamp->dc_offset > 0x1fff) {
+		dev_dbg(isif_cfg.dev, "invalid bclamp dc_offset value \n");
+		return err;
+	}
+
+	if (!bclamp->en)
+		return 0;
+
+	if (bclamp->bc_mode_color > 1) {
+		dev_dbg(isif_cfg.dev,
+		       "invalid bclamp bc_mode_color value \n");
+		return err;
+	}
+
+	if (bclamp->vert_start_sub > 0x1FFF) {
+		dev_dbg(isif_cfg.dev,
+		       "invalid bclamp vert_start_sub value \n");
+		return err;
+	}
+
+	if (bclamp->horz.mode > 2) {
+		dev_dbg(isif_cfg.dev,
+		       "invalid bclamp horz mode value \n");
+		return err;
+	}
+
+	if (bclamp->horz.clamp_pix_limit > 1) {
+		dev_dbg(isif_cfg.dev,
+		       "invalid bclamp horz clamp_pix_limit value \n");
+		return err;
+	}
+
+	if (bclamp->horz.win_h_sz_calc > 3) {
+		dev_dbg(isif_cfg.dev,
+		       "invalid bclamp horz win_h_sz_calc value \n");
+		return err;
+	}
+
+	if (bclamp->horz.win_v_sz_calc > 3) {
+		dev_dbg(isif_cfg.dev,
+		       "invalid bclamp horz win_v_sz_calc value \n");
+		return err;
+	}
+
+	if (bclamp->horz.win_count_calc < 1 ||
+	    bclamp->horz.win_count_calc > 32) {
+		dev_dbg(isif_cfg.dev,
+		       "invalid bclamp horz win_count_calc value \n");
+		return err;
+	}
+
+	if (bclamp->horz.win_start_h_calc > 0x1fff) {
+		dev_dbg(isif_cfg.dev,
+		       "invalid bclamp win_start_h_calc value \n");
+		return err;
+	}
+
+	if (bclamp->horz.win_start_v_calc > 0x1fff) {
+		dev_dbg(isif_cfg.dev,
+		       "invalid bclamp win_start_v_calc value \n");
+		return err;
+	}
+
+	if (bclamp->vert.reset_val_sel > 2) {
+		dev_dbg(isif_cfg.dev,
+		       "invalid bclamp vert reset_val_sel value \n");
+		return err;
+	}
+
+	if (bclamp->vert.ob_v_sz_calc > 0x1fff) {
+		dev_dbg(isif_cfg.dev, "invalid bclamp ob_v_sz_calc value \n");
+		return err;
+	}
+
+	if (bclamp->vert.ob_start_h > 0x1fff) {
+		dev_dbg(isif_cfg.dev, "invalid bclamp ob_start_h value \n");
+		return err;
+	}
+
+	if (bclamp->vert.ob_start_v > 0x1fff) {
+		dev_dbg(isif_cfg.dev, "invalid bclamp ob_start_h value \n");
+		return err;
+	}
+	return 0;
+}
+
+static int isif_validate_gain_ofst_params(struct isif_gain_offsets_adj
+					  *gain_offset)
+{
+	int err = -EINVAL;
+
+	if (gain_offset->gain_sdram_en ||
+	    gain_offset->gain_ipipe_en ||
+	    gain_offset->gain_h3a_en) {
+		if ((gain_offset->gain.r_ye.integer > 7) ||
+		    (gain_offset->gain.r_ye.decimal > 0x1ff)) {
+			dev_dbg(isif_cfg.dev, "invalid  gain r_ye\n");
+			return err;
+		}
+		if ((gain_offset->gain.gr_cy.integer > 7) ||
+		    (gain_offset->gain.gr_cy.decimal > 0x1ff)) {
+			dev_dbg(isif_cfg.dev, "invalid  gain gr_cy\n");
+			return err;
+		}
+		if ((gain_offset->gain.gb_g.integer > 7) ||
+		    (gain_offset->gain.gb_g.decimal > 0x1ff)) {
+			dev_dbg(isif_cfg.dev, "invalid  gain gb_g\n");
+			return err;
+		}
+		if ((gain_offset->gain.b_mg.integer > 7) ||
+		    (gain_offset->gain.b_mg.decimal > 0x1ff)) {
+			dev_dbg(isif_cfg.dev, "invalid  gain b_mg\n");
+			return err;
+		}
+	}
+	if (gain_offset->offset_sdram_en ||
+	    gain_offset->offset_ipipe_en ||
+	    gain_offset->offset_h3a_en) {
+		if (gain_offset->offset > 0xfff) {
+			dev_dbg(isif_cfg.dev, "invalid  gain b_mg\n");
+			return err;
+		}
+
+	}
+	return 0;
+}
+
+static int
+validate_isif_config_params_raw(struct isif_config_params_raw *params)
+{
+	int err = -EINVAL;
+
+	if (params->compress.alg > ISIF_NO_COMPRESSION) {
+		dev_dbg(isif_cfg.dev, "invalid compress algorithm\n");
+		return err;
+	}
+
+	if ((params->compress.alg == ISIF_DPCM) &&
+	    (params->compress.pred > ISIF_DPCM_PRED2)) {
+		dev_dbg(isif_cfg.dev, "invalid DPCM predicator\n");
+		return err;
+	}
+
+	if (params->gain_offset.offset_sdram_en ||
+	    params->gain_offset.offset_ipipe_en ||
+	    params->gain_offset.offset_h3a_en ||
+	    params->dfc.en) {
+		/* common offset values for DFC and Gain-offset */
+		if (params->horz_offset > ISIF_DATA_H_OFFSET_MASK) {
+			dev_dbg(isif_cfg.dev,
+				"invalid Horizontal offset value\n");
+			return err;
+		}
+
+		if (params->vert_offset  > ISIF_DATA_V_OFFSET_MASK) {
+			dev_dbg(isif_cfg.dev,
+				"invalid vertical offset value\n");
+			return err;
+		}
+	}
+	err = isif_validate_linearization_params(&params->linearize);
+	if (err)
+		return err;
+	err = isif_validate_df_csc_params(&params->df_csc);
+	if (err)
+		return err;
+	err = isif_validate_dfc_params(&params->dfc);
+	if (err)
+		return err;
+	err = isif_validate_bclamp_params(&params->bclamp);
+	if (err)
+		return err;
+	err = isif_validate_gain_ofst_params(&params->gain_offset);
+	return err;
+}
+
+static int isif_set_buftype(enum ccdc_buftype buf_type)
+{
+	if (isif_cfg.if_type == VPFE_RAW_BAYER)
+		isif_cfg.bayer.buf_type = buf_type;
+	else
+		isif_cfg.ycbcr.buf_type = buf_type;
+
+	return 0;
+
+}
+static enum ccdc_buftype isif_get_buftype(void)
+{
+	if (isif_cfg.if_type == VPFE_RAW_BAYER)
+		return isif_cfg.bayer.buf_type;
+
+	return isif_cfg.ycbcr.buf_type;
+}
+
+static int isif_enum_pix(u32 *pix, int i)
+{
+	int ret = -EINVAL;
+
+	if (isif_cfg.if_type == VPFE_RAW_BAYER) {
+		if (i < ARRAY_SIZE(isif_raw_bayer_pix_formats)) {
+			*pix = isif_raw_bayer_pix_formats[i];
+			ret = 0;
+		}
+	} else {
+		if (i < ARRAY_SIZE(isif_raw_yuv_pix_formats)) {
+			*pix = isif_raw_yuv_pix_formats[i];
+			ret = 0;
+		}
+	}
+
+	return ret;
+}
+
+static int isif_set_pixel_format(unsigned int pixfmt)
+{
+	if (isif_cfg.if_type == VPFE_RAW_BAYER) {
+		if (pixfmt == V4L2_PIX_FMT_SBGGR8) {
+			if ((isif_cfg.bayer.config_params.compress.alg !=
+			     ISIF_ALAW) &&
+			    (isif_cfg.bayer.config_params.compress.alg !=
+			     ISIF_DPCM)) {
+				dev_dbg(isif_cfg.dev,
+					"Either configure A-Law or DPCM\n");
+				return -EINVAL;
+			}
+			isif_cfg.data_pack = ISIF_PACK_8BIT;
+		} else if (pixfmt == V4L2_PIX_FMT_SBGGR16) {
+			isif_cfg.bayer.config_params.compress.alg =
+					ISIF_NO_COMPRESSION;
+			isif_cfg.data_pack = ISIF_PACK_16BIT;
+		} else
+			return -EINVAL;
+		isif_cfg.bayer.pix_fmt = CCDC_PIXFMT_RAW;
+	} else {
+		if (pixfmt == V4L2_PIX_FMT_YUYV)
+			isif_cfg.ycbcr.pix_order = CCDC_PIXORDER_YCBYCR;
+		else if (pixfmt == V4L2_PIX_FMT_UYVY)
+			isif_cfg.ycbcr.pix_order = CCDC_PIXORDER_CBYCRY;
+		else
+			return -EINVAL;
+		isif_cfg.data_pack = ISIF_PACK_8BIT;
+	}
+	return 0;
+}
+
+static u32 isif_get_pixel_format(void)
+{
+	u32 pixfmt;
+
+	if (isif_cfg.if_type == VPFE_RAW_BAYER)
+		if (isif_cfg.bayer.config_params.compress.alg == ISIF_ALAW ||
+		    isif_cfg.bayer.config_params.compress.alg == ISIF_DPCM)
+			pixfmt = V4L2_PIX_FMT_SBGGR8;
+		else
+			pixfmt = V4L2_PIX_FMT_SBGGR16;
+	else {
+		if (isif_cfg.ycbcr.pix_order == CCDC_PIXORDER_YCBYCR)
+			pixfmt = V4L2_PIX_FMT_YUYV;
+		else
+			pixfmt = V4L2_PIX_FMT_UYVY;
+	}
+	return pixfmt;
+}
+
+static int isif_set_image_window(struct v4l2_rect *win)
+{
+	if (isif_cfg.if_type == VPFE_RAW_BAYER) {
+		isif_cfg.bayer.win.top = win->top;
+		isif_cfg.bayer.win.left = win->left;
+		isif_cfg.bayer.win.width = win->width;
+		isif_cfg.bayer.win.height = win->height;
+	} else {
+		isif_cfg.ycbcr.win.top = win->top;
+		isif_cfg.ycbcr.win.left = win->left;
+		isif_cfg.ycbcr.win.width = win->width;
+		isif_cfg.ycbcr.win.height = win->height;
+	}
+	return 0;
+}
+
+static void isif_get_image_window(struct v4l2_rect *win)
+{
+	if (isif_cfg.if_type == VPFE_RAW_BAYER)
+		*win = isif_cfg.bayer.win;
+	else
+		*win = isif_cfg.ycbcr.win;
+}
+
+static unsigned int isif_get_line_length(void)
+{
+	unsigned int len;
+
+	if (isif_cfg.if_type == VPFE_RAW_BAYER) {
+		if (isif_cfg.data_pack == ISIF_PACK_8BIT)
+			len = ((isif_cfg.bayer.win.width));
+		else if (isif_cfg.data_pack == ISIF_PACK_12BIT)
+			len = (((isif_cfg.bayer.win.width * 2) +
+				 (isif_cfg.bayer.win.width >> 2)));
+		else
+			len = (((isif_cfg.bayer.win.width * 2)));
+	} else
+		len = (((isif_cfg.ycbcr.win.width * 2)));
+	return ALIGN(len, 32);
+}
+
+static int isif_set_frame_format(enum ccdc_frmfmt frm_fmt)
+{
+	if (isif_cfg.if_type == VPFE_RAW_BAYER)
+		isif_cfg.bayer.frm_fmt = frm_fmt;
+	else
+		isif_cfg.ycbcr.frm_fmt = frm_fmt;
+	return 0;
+}
+static enum ccdc_frmfmt isif_get_frame_format(void)
+{
+	if (isif_cfg.if_type == VPFE_RAW_BAYER)
+		return isif_cfg.bayer.frm_fmt;
+	return isif_cfg.ycbcr.frm_fmt;
+}
+
+static int isif_getfid(void)
+{
+	return (regr(MODESET) >> 15) & 0x1;
+}
+
+/* misc operations */
+static void isif_setfbaddr(unsigned long addr)
+{
+	regw((addr >> 21) & 0x07ff, CADU);
+	regw((addr >> 5) & 0x0ffff, CADL);
+}
+
+static int isif_set_hw_if_params(struct vpfe_hw_if_param *params)
+{
+	isif_cfg.if_type = params->if_type;
+
+	switch (params->if_type) {
+	case VPFE_BT656:
+	case VPFE_BT656_10BIT:
+	case VPFE_YCBCR_SYNC_8:
+		isif_cfg.ycbcr.pix_fmt = CCDC_PIXFMT_YCBCR_8BIT;
+		isif_cfg.ycbcr.pix_order = CCDC_PIXORDER_CBYCRY;
+		break;
+	case VPFE_BT1120:
+	case VPFE_YCBCR_SYNC_16:
+		isif_cfg.ycbcr.pix_fmt = CCDC_PIXFMT_YCBCR_16BIT;
+		isif_cfg.ycbcr.pix_order = CCDC_PIXORDER_CBYCRY;
+		break;
+	case VPFE_RAW_BAYER:
+		isif_cfg.bayer.pix_fmt = CCDC_PIXFMT_RAW;
+		break;
+	default:
+		dev_dbg(isif_cfg.dev, "Invalid interface type\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+/* Parameter operations */
+static int isif_get_params(void __user *params)
+{
+	/* only raw module parameters can be set through the IOCTL */
+	if (isif_cfg.if_type != VPFE_RAW_BAYER)
+		return -EINVAL;
+
+	if (copy_to_user(params,
+			&isif_cfg.bayer.config_params,
+			sizeof(isif_cfg.bayer.config_params))) {
+		dev_dbg(isif_cfg.dev,
+			"isif_get_params: error in copying isif params\n");
+		return -EFAULT;
+	}
+	return 0;
+}
+
+/* Parameter operations */
+static int isif_set_params(void __user *params)
+{
+	struct isif_config_params_raw *isif_raw_params;
+	int ret = -EINVAL;
+
+	/* only raw module parameters can be set through the IOCTL */
+	if (isif_cfg.if_type != VPFE_RAW_BAYER)
+		return ret;
+
+	isif_raw_params = kzalloc(sizeof(*isif_raw_params), GFP_KERNEL);
+	if (NULL == isif_raw_params)
+		return -ENOMEM;
+
+	ret = copy_from_user(isif_raw_params,
+			     params, sizeof(*isif_raw_params));
+	if (ret) {
+		dev_dbg(isif_cfg.dev, "isif_set_params: error in copying isif"
+			"params, %d\n", ret);
+		ret = -EFAULT;
+		goto free_out;
+	}
+
+	if (!validate_isif_config_params_raw(isif_raw_params)) {
+		memcpy(&isif_cfg.bayer.config_params,
+			isif_raw_params,
+			sizeof(*isif_raw_params));
+		ret = 0;
+	} else
+		ret = -EINVAL;
+free_out:
+	kfree(isif_raw_params);
+	return ret;
+}
+
+/* This function will configure ISIF for YCbCr parameters. */
+static int isif_config_ycbcr(void)
+{
+	struct isif_ycbcr_config *params = &isif_cfg.ycbcr;
+	struct vpss_pg_frame_size frame_size;
+	u32 modeset = 0, ccdcfg = 0;
+	struct vpss_sync_pol sync;
+
+	dev_dbg(isif_cfg.dev, "\nStarting isif_config_ycbcr...");
+
+	/* configure pixel format or input mode */
+	modeset = modeset | (params->pix_fmt << ISIF_INPUT_SHIFT) |
+		  (params->frm_fmt << ISIF_FRM_FMT_SHIFT) |
+		  (params->fid_pol << ISIF_FID_POL_SHIFT) |
+		  (params->hd_pol << ISIF_HD_POL_SHIFT) |
+		  (params->vd_pol << ISIF_VD_POL_SHIFT);
+
+	/* pack the data to 8-bit ISIFCFG */
+	switch (isif_cfg.if_type) {
+	case VPFE_BT656:
+		if (params->pix_fmt != CCDC_PIXFMT_YCBCR_8BIT) {
+			dev_dbg(isif_cfg.dev, "Invalid pix_fmt(input mode)\n");
+			return -EINVAL;
+		}
+		modeset |= (VPFE_PINPOL_NEGATIVE << ISIF_VD_POL_SHIFT);
+		regw(3, REC656IF);
+		ccdcfg = ccdcfg | ISIF_DATA_PACK8 | ISIF_YCINSWP_YCBCR;
+		break;
+	case VPFE_BT656_10BIT:
+		if (params->pix_fmt != CCDC_PIXFMT_YCBCR_8BIT) {
+			dev_dbg(isif_cfg.dev, "Invalid pix_fmt(input mode)\n");
+			return -EINVAL;
+		}
+		/* setup BT.656, embedded sync  */
+		regw(3, REC656IF);
+		/* enable 10 bit mode in ccdcfg */
+		ccdcfg = ccdcfg | ISIF_DATA_PACK8 | ISIF_YCINSWP_YCBCR |
+			ISIF_BW656_ENABLE;
+		break;
+	case VPFE_BT1120:
+		if (params->pix_fmt != CCDC_PIXFMT_YCBCR_16BIT) {
+			dev_dbg(isif_cfg.dev, "Invalid pix_fmt(input mode)\n");
+			return -EINVAL;
+		}
+		regw(3, REC656IF);
+		break;
+
+	case VPFE_YCBCR_SYNC_8:
+		ccdcfg |= ISIF_DATA_PACK8;
+		ccdcfg |= ISIF_YCINSWP_YCBCR;
+		if (params->pix_fmt != CCDC_PIXFMT_YCBCR_8BIT) {
+			dev_dbg(isif_cfg.dev, "Invalid pix_fmt(input mode)\n");
+			return -EINVAL;
+		}
+		break;
+	case VPFE_YCBCR_SYNC_16:
+		if (params->pix_fmt != CCDC_PIXFMT_YCBCR_16BIT) {
+			dev_dbg(isif_cfg.dev, "Invalid pix_fmt(input mode)\n");
+			return -EINVAL;
+		}
+		break;
+	default:
+		/* should never come here */
+		dev_dbg(isif_cfg.dev, "Invalid interface type\n");
+		return -EINVAL;
+	}
+
+	regw(modeset, MODESET);
+
+	/* Set up pix order */
+	ccdcfg |= params->pix_order << ISIF_PIX_ORDER_SHIFT;
+
+	regw(ccdcfg, CCDCFG);
+
+	/* configure video window */
+	if ((isif_cfg.if_type == VPFE_BT1120) ||
+	    (isif_cfg.if_type == VPFE_YCBCR_SYNC_16))
+		isif_setwin(&params->win, params->frm_fmt, 1);
+	else
+		isif_setwin(&params->win, params->frm_fmt, 2);
+
+	/*
+	 * configure the horizontal line offset
+	 * this is done by rounding up width to a multiple of 16 pixels
+	 * and multiply by two to account for y:cb:cr 4:2:2 data
+	 */
+	regw(((((params->win.width * 2) + 31) & 0xffffffe0) >> 5), HSIZE);
+
+	/* configure the memory line offset */
+	if ((params->frm_fmt == CCDC_FRMFMT_INTERLACED) &&
+	    (params->buf_type == CCDC_BUFTYPE_FLD_INTERLEAVED))
+		/* two fields are interleaved in memory */
+		regw(0x00000249, SDOFST);
+
+	/* Setup test pattern if enabled */
+	if (isif_cfg.bayer.config_params.test_pat_gen) {
+		sync.ccdpg_hdpol = params->hd_pol;
+		sync.ccdpg_vdpol = params->vd_pol;
+		dm365_vpss_set_sync_pol(sync);
+		dm365_vpss_set_pg_frame_size(frame_size);
+	}
+	return 0;
+}
+
+static int isif_configure(void)
+{
+	if (isif_cfg.if_type == VPFE_RAW_BAYER)
+		return isif_config_raw();
+	return isif_config_ycbcr();
+}
+
+static int isif_close(struct device *device)
+{
+	/* copy defaults to module params */
+	isif_cfg.bayer.config_params = isif_config_defaults;
+	return 0;
+}
+
+static struct ccdc_hw_device isif_hw_dev = {
+	.name = "ISIF",
+	.owner = THIS_MODULE,
+	.hw_ops = {
+		.open = isif_open,
+		.close = isif_close,
+		.enable = isif_enable,
+		.enable_out_to_sdram = isif_enable_output_to_sdram,
+		.set_hw_if_params = isif_set_hw_if_params,
+		.set_params = isif_set_params,
+		.get_params = isif_get_params,
+		.configure = isif_configure,
+		.set_buftype = isif_set_buftype,
+		.get_buftype = isif_get_buftype,
+		.enum_pix = isif_enum_pix,
+		.set_pixel_format = isif_set_pixel_format,
+		.get_pixel_format = isif_get_pixel_format,
+		.set_frame_format = isif_set_frame_format,
+		.get_frame_format = isif_get_frame_format,
+		.set_image_window = isif_set_image_window,
+		.get_image_window = isif_get_image_window,
+		.get_line_length = isif_get_line_length,
+		.setfbaddr = isif_setfbaddr,
+		.getfid = isif_getfid,
+	},
+};
+
+static int __init isif_probe(struct platform_device *pdev)
+{
+	void (*setup_pinmux)(void);
+	struct resource	*res;
+	void *__iomem addr;
+	int status = 0, i;
+
+	/*
+	 * first try to register with vpfe. If not correct platform, then we
+	 * don't have to iomap
+	 */
+	status = vpfe_register_ccdc_device(&isif_hw_dev);
+	if (status < 0)
+		return status;
+
+	/* Get and enable Master clock */
+	isif_cfg.mclk = clk_get(&pdev->dev, "master");
+	if (IS_ERR(isif_cfg.mclk)) {
+		status = PTR_ERR(isif_cfg.mclk);
+		goto fail_mclk;
+	}
+	if (clk_enable(isif_cfg.mclk)) {
+		status = -ENODEV;
+		goto fail_mclk;
+	}
+
+	/* Platform data holds setup_pinmux function ptr */
+	if (NULL == pdev->dev.platform_data) {
+		status = -ENODEV;
+		goto fail_mclk;
+	}
+	setup_pinmux = pdev->dev.platform_data;
+	/*
+	 * setup Mux configuration for ccdc which may be different for
+	 * different SoCs using this CCDC
+	 */
+	setup_pinmux();
+
+	i = 0;
+	/* Get the ISIF base address, linearization table0 and table1 addr. */
+	while (i < 3) {
+		res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+		if (!res) {
+			status = -ENODEV;
+			goto fail_nobase_res;
+		}
+		res = request_mem_region(res->start, resource_size(res),
+					 res->name);
+		if (!res) {
+			status = -EBUSY;
+			goto fail_nobase_res;
+		}
+		addr = ioremap_nocache(res->start, resource_size(res));
+		if (!addr) {
+			status = -ENOMEM;
+			goto fail_base_iomap;
+		}
+		switch (i) {
+		case 0:
+			/* ISIF base address */
+			isif_cfg.base_addr = addr;
+			break;
+		case 1:
+			/* ISIF linear tbl0 address */
+			isif_cfg.linear_tbl0_addr = addr;
+			break;
+		default:
+			/* ISIF linear tbl0 address */
+			isif_cfg.linear_tbl1_addr = addr;
+			break;
+		}
+		i++;
+	}
+	isif_cfg.dev = &pdev->dev;
+
+	printk(KERN_NOTICE "%s is registered with vpfe.\n",
+		isif_hw_dev.name);
+	return 0;
+fail_base_iomap:
+	release_mem_region(res->start, resource_size(res));
+	i--;
+fail_nobase_res:
+	if (isif_cfg.base_addr)
+		iounmap(isif_cfg.base_addr);
+	if (isif_cfg.linear_tbl0_addr)
+		iounmap(isif_cfg.linear_tbl0_addr);
+
+	while (i >= 0) {
+		res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+		release_mem_region(res->start, resource_size(res));
+		i--;
+	}
+fail_mclk:
+	clk_put(isif_cfg.mclk);
+	vpfe_unregister_ccdc_device(&isif_hw_dev);
+	return status;
+}
+
+static int isif_remove(struct platform_device *pdev)
+{
+	struct resource	*res;
+	int i = 0;
+
+	iounmap(isif_cfg.base_addr);
+	iounmap(isif_cfg.linear_tbl0_addr);
+	iounmap(isif_cfg.linear_tbl1_addr);
+	while (i < 3) {
+		res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+		if (res)
+			release_mem_region(res->start, resource_size(res));
+		i++;
+	}
+	vpfe_unregister_ccdc_device(&isif_hw_dev);
+	return 0;
+}
+
+static struct platform_driver isif_driver = {
+	.driver = {
+		.name	= "isif",
+		.owner = THIS_MODULE,
+	},
+	.remove = __devexit_p(isif_remove),
+	.probe = isif_probe,
+};
+
+static int __init isif_init(void)
+{
+	return platform_driver_register(&isif_driver);
+}
+
+static void isif_exit(void)
+{
+	platform_driver_unregister(&isif_driver);
+}
+
+module_init(isif_init);
+module_exit(isif_exit);
+
+MODULE_LICENSE("GPL");
-- 
1.6.0.4


From m-karicheri2 at ti.com  Mon Feb  1 16:27:18 2010
From: m-karicheri2 at ti.com (m-karicheri2 at ti.com)
Date: Mon,  1 Feb 2010 17:27:18 -0500
Subject: [PATCH v3 4/6] V4L - vpfe_capture - bug fixes and enhancements
In-Reply-To: <1265063238-29072-5-git-send-email-m-karicheri2@ti.com>
References: <1265063238-29072-1-git-send-email-m-karicheri2@ti.com>
	<1265063238-29072-2-git-send-email-m-karicheri2@ti.com>
	<1265063238-29072-3-git-send-email-m-karicheri2@ti.com>
	<1265063238-29072-4-git-send-email-m-karicheri2@ti.com>
	<1265063238-29072-5-git-send-email-m-karicheri2@ti.com>
Message-ID: <1265063238-29072-6-git-send-email-m-karicheri2@ti.com>

From: Murali Karicheri <m-karicheri2 at ti.com>

Added a experimental IOCTL, to read the ISIF parameters.
Default handler was not getting the original user configuration data
pointer from the core. So a wrapper function added to handle the default
handler properly. 

Reviewed-by: Hans Verkuil <hverkuil at xs4all.nl>

Signed-off-by: Hans Verkuil <hverkuil at xs4all.nl>
Signed-off-by: Muralidharan Karicheri <m-karicheri2 at ti.com>
---
Applies to linux-next of v4l-dvb
 - Rebasing to latest tree (v3) for merge
 - Updated based on comments against v1 of the patch
 drivers/media/video/davinci/vpfe_capture.c |  118 +++++++++++++++++-----------
 include/media/davinci/vpfe_capture.h       |   11 +--
 2 files changed, 77 insertions(+), 52 deletions(-)

diff --git a/drivers/media/video/davinci/vpfe_capture.c b/drivers/media/video/davinci/vpfe_capture.c
index 885cd54..175ae47 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -758,12 +758,83 @@ static unsigned int vpfe_poll(struct file *file, poll_table *wait)
 	return 0;
 }
 
+static long vpfe_param_handler(struct file *file, void *priv,
+		int cmd, void *param)
+{
+	struct vpfe_device *vpfe_dev = video_drvdata(file);
+	int ret = 0;
+
+	v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_param_handler\n");
+
+	if (NULL == param) {
+		v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev,
+			"Invalid user ptr\n");
+		return -EINVAL;
+	}
+
+	if (vpfe_dev->started) {
+		/* only allowed if streaming is not started */
+		v4l2_err(&vpfe_dev->v4l2_dev, "device already started\n");
+		return -EBUSY;
+	}
+
+	switch (cmd) {
+	case VPFE_CMD_S_CCDC_RAW_PARAMS:
+		v4l2_warn(&vpfe_dev->v4l2_dev,
+			  "VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n");
+		ret = mutex_lock_interruptible(&vpfe_dev->lock);
+		if (ret)
+			return ret;
+		ret = ccdc_dev->hw_ops.set_params(param);
+		if (ret) {
+			v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev,
+				"Error in setting parameters in CCDC\n");
+			goto unlock_out;
+		}
+
+		if (vpfe_get_ccdc_image_format(vpfe_dev, &vpfe_dev->fmt) < 0) {
+			v4l2_err(&vpfe_dev->v4l2_dev,
+				"Invalid image format at CCDC\n");
+			ret = -EINVAL;
+		}
+unlock_out:
+		mutex_unlock(&vpfe_dev->lock);
+		break;
+	case VPFE_CMD_G_CCDC_RAW_PARAMS:
+		v4l2_warn(&vpfe_dev->v4l2_dev,
+			  "VPFE_CMD_G_CCDC_RAW_PARAMS: experimental ioctl\n");
+		if (!ccdc_dev->hw_ops.get_params) {
+			ret = -EINVAL;
+			break;
+		}
+		ret = ccdc_dev->hw_ops.get_params(param);
+		if (ret) {
+			v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev,
+				"Error in getting parameters from CCDC\n");
+		}
+		break;
+	default:
+		ret = -EINVAL;
+		break;
+	}
+	return ret;
+}
+
+static long vpfe_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+{
+	if (cmd == VPFE_CMD_S_CCDC_RAW_PARAMS ||
+	    cmd == VPFE_CMD_G_CCDC_RAW_PARAMS)
+		return vpfe_param_handler(file, file->private_data, cmd,
+					 (void *)arg);
+	return video_ioctl2(file, cmd, arg);
+}
+
 /* vpfe capture driver file operations */
 static const struct v4l2_file_operations vpfe_fops = {
 	.owner = THIS_MODULE,
 	.open = vpfe_open,
 	.release = vpfe_release,
-	.unlocked_ioctl = video_ioctl2,
+	.unlocked_ioctl = vpfe_ioctl,
 	.mmap = vpfe_mmap,
 	.poll = vpfe_poll
 };
@@ -1681,50 +1752,6 @@ unlock_out:
 	return ret;
 }
 
-
-static long vpfe_param_handler(struct file *file, void *priv,
-		int cmd, void *param)
-{
-	struct vpfe_device *vpfe_dev = video_drvdata(file);
-	int ret = 0;
-
-	v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_param_handler\n");
-
-	if (vpfe_dev->started) {
-		/* only allowed if streaming is not started */
-		v4l2_err(&vpfe_dev->v4l2_dev, "device already started\n");
-		return -EBUSY;
-	}
-
-	ret = mutex_lock_interruptible(&vpfe_dev->lock);
-	if (ret)
-		return ret;
-
-	switch (cmd) {
-	case VPFE_CMD_S_CCDC_RAW_PARAMS:
-		v4l2_warn(&vpfe_dev->v4l2_dev,
-			  "VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n");
-		ret = ccdc_dev->hw_ops.set_params(param);
-		if (ret) {
-			v4l2_err(&vpfe_dev->v4l2_dev,
-				"Error in setting parameters in CCDC\n");
-			goto unlock_out;
-		}
-		if (vpfe_get_ccdc_image_format(vpfe_dev, &vpfe_dev->fmt) < 0) {
-			v4l2_err(&vpfe_dev->v4l2_dev,
-				"Invalid image format at CCDC\n");
-			goto unlock_out;
-		}
-		break;
-	default:
-		ret = -EINVAL;
-	}
-unlock_out:
-	mutex_unlock(&vpfe_dev->lock);
-	return ret;
-}
-
-
 /* vpfe capture ioctl operations */
 static const struct v4l2_ioctl_ops vpfe_ioctl_ops = {
 	.vidioc_querycap	 = vpfe_querycap,
@@ -1750,7 +1777,6 @@ static const struct v4l2_ioctl_ops vpfe_ioctl_ops = {
 	.vidioc_cropcap		 = vpfe_cropcap,
 	.vidioc_g_crop		 = vpfe_g_crop,
 	.vidioc_s_crop		 = vpfe_s_crop,
-	.vidioc_default		 = vpfe_param_handler,
 };
 
 static struct vpfe_device *vpfe_initialize(void)
diff --git a/include/media/davinci/vpfe_capture.h b/include/media/davinci/vpfe_capture.h
index d863e5e..9bdfaad 100644
--- a/include/media/davinci/vpfe_capture.h
+++ b/include/media/davinci/vpfe_capture.h
@@ -31,8 +31,6 @@
 #include <media/videobuf-dma-contig.h>
 #include <media/davinci/vpfe_types.h>
 
-#define VPFE_CAPTURE_NUM_DECODERS        5
-
 /* Macros */
 #define VPFE_MAJOR_RELEASE              0
 #define VPFE_MINOR_RELEASE              0
@@ -91,9 +89,6 @@ struct vpfe_config {
 	char *card_name;
 	/* ccdc name */
 	char *ccdc;
-	/* vpfe clock */
-	struct clk *vpssclk;
-	struct clk *slaveclk;
 };
 
 struct vpfe_device {
@@ -193,8 +188,12 @@ struct vpfe_config_params {
  * color space conversion, culling etc. This is an experimental ioctl that
  * will change in future kernels. So use this ioctl with care !
  * TODO: This is to be split into multiple ioctls and also explore the
- * possibility of extending the v4l2 api to include this
+ * possibility of extending the v4l2 api to include this.
+ * VPFE_CMD_G_CCDC_RAW_PARAMS - EXPERIMENTAL IOCTL to get the current raw
+ * capture parameters
  **/
 #define VPFE_CMD_S_CCDC_RAW_PARAMS _IOW('V', BASE_VIDIOC_PRIVATE + 1, \
 					void *)
+#define VPFE_CMD_G_CCDC_RAW_PARAMS _IOR('V', BASE_VIDIOC_PRIVATE + 2, \
+					void *)
 #endif				/* _DAVINCI_VPFE_H */
-- 
1.6.0.4


From m-karicheri2 at ti.com  Mon Feb  1 16:33:00 2010
From: m-karicheri2 at ti.com (Karicheri, Muralidharan)
Date: Mon, 1 Feb 2010 16:33:00 -0600
Subject: [PATCH v3 1/6] V4L - vpfe capture - header files for ISIF driver
In-Reply-To: <1265063238-29072-3-git-send-email-m-karicheri2@ti.com>
References: <1265063238-29072-1-git-send-email-m-karicheri2@ti.com>
	<1265063238-29072-2-git-send-email-m-karicheri2@ti.com>
	<1265063238-29072-3-git-send-email-m-karicheri2@ti.com>
Message-ID: <A69FA2915331DC488A831521EAE36FE401630F2E54@dlee06.ent.ti.com>

Hi Kevin,

This patch is already approved by the V4L sub system. I need to get your
approval for the arch part (patch #6). I have updated the clock handling
based on your comments against the last patch (adding clock alias)

I will request Mauro to merge the arch part via the v4l tree. I have a
developer repository set up at linuxtv.org. Hereafter I will be sending
pull request directly using the above repository.

Thanks

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-karicheri2 at ti.com

>-----Original Message-----
>From: Karicheri, Muralidharan
>Sent: Monday, February 01, 2010 5:27 PM
>To: linux-media at vger.kernel.org; khilman at deeprootsystems.com
>Cc: hverkuil at xs4all.nl; davinci-linux-open-source at linux.davincidsp.com;
>Karicheri, Muralidharan
>Subject: [PATCH v3 1/6] V4L - vpfe capture - header files for ISIF driver
>
>From: Murali Karicheri <m-karicheri2 at ti.com>
>
>This is the header file for ISIF driver on DM365.  ISIF driver is
>equivalent
>to CCDC driver on DM355 and DM644x. This driver is tested for
>YUV capture from TVP514x driver. This patch contains the header files
>required for
>this driver. The name of the file is changed to reflect the name of IP.
>
>Reviewed-by: Nori, Sekhar <nsekhar at ti.com>
>Reviewed-by: Hans Verkuil <hverkuil at xs4all.nl>
>
>Signed-off-by: Hans Verkuil <hverkuil at xs4all.nl>
>Signed-off-by: Muralidharan Karicheri <m-karicheri2 at ti.com>
>---
>Applies to linux-next tree of v4l-dvb
> - rebasing to latest for merge (v3)
> - Updated based on comments against v1 of the patch (v2)
> drivers/media/video/davinci/isif_regs.h |  269 ++++++++++++++++
> include/media/davinci/isif.h            |  531
>+++++++++++++++++++++++++++++++
> 2 files changed, 800 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/davinci/isif_regs.h
> create mode 100644 include/media/davinci/isif.h
>
>diff --git a/drivers/media/video/davinci/isif_regs.h
>b/drivers/media/video/davinci/isif_regs.h
>new file mode 100644
>index 0000000..f7b8893
>--- /dev/null
>+++ b/drivers/media/video/davinci/isif_regs.h
>@@ -0,0 +1,269 @@
>+/*
>+ * Copyright (C) 2008-2009 Texas Instruments Inc
>+ *
>+ * 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
>+ */
>+#ifndef _ISIF_REGS_H
>+#define _ISIF_REGS_H
>+
>+/* ISIF registers relative offsets */
>+#define SYNCEN                                        0x00
>+#define MODESET                                       0x04
>+#define HDW                                   0x08
>+#define VDW                                   0x0c
>+#define PPLN                                  0x10
>+#define LPFR                                  0x14
>+#define SPH                                   0x18
>+#define LNH                                   0x1c
>+#define SLV0                                  0x20
>+#define SLV1                                  0x24
>+#define LNV                                   0x28
>+#define CULH                                  0x2c
>+#define CULV                                  0x30
>+#define HSIZE                                 0x34
>+#define SDOFST                                        0x38
>+#define CADU                                  0x3c
>+#define CADL                                  0x40
>+#define LINCFG0                                       0x44
>+#define LINCFG1                                       0x48
>+#define CCOLP                                 0x4c
>+#define CRGAIN                                        0x50
>+#define CGRGAIN                                       0x54
>+#define CGBGAIN                                       0x58
>+#define CBGAIN                                        0x5c
>+#define COFSTA                                        0x60
>+#define FLSHCFG0                              0x64
>+#define FLSHCFG1                              0x68
>+#define FLSHCFG2                              0x6c
>+#define VDINT0                                        0x70
>+#define VDINT1                                        0x74
>+#define VDINT2                                        0x78
>+#define MISC                                  0x7c
>+#define CGAMMAWD                              0x80
>+#define REC656IF                              0x84
>+#define CCDCFG                                        0x88
>+/*****************************************************
>+* Defect Correction registers
>+*****************************************************/
>+#define DFCCTL                                        0x8c
>+#define VDFSATLV                              0x90
>+#define DFCMEMCTL                             0x94
>+#define DFCMEM0                                       0x98
>+#define DFCMEM1                                       0x9c
>+#define DFCMEM2                                       0xa0
>+#define DFCMEM3                                       0xa4
>+#define DFCMEM4                                       0xa8
>+/****************************************************
>+* Black Clamp registers
>+****************************************************/
>+#define CLAMPCFG                              0xac
>+#define CLDCOFST                              0xb0
>+#define CLSV                                  0xb4
>+#define CLHWIN0                                       0xb8
>+#define CLHWIN1                                       0xbc
>+#define CLHWIN2                                       0xc0
>+#define CLVRV                                 0xc4
>+#define CLVWIN0                                       0xc8
>+#define CLVWIN1                                       0xcc
>+#define CLVWIN2                                       0xd0
>+#define CLVWIN3                                       0xd4
>+/****************************************************
>+* Lense Shading Correction
>+****************************************************/
>+#define DATAHOFST                             0xd8
>+#define DATAVOFST                             0xdc
>+#define LSCHVAL                                       0xe0
>+#define LSCVVAL                                       0xe4
>+#define TWODLSCCFG                            0xe8
>+#define TWODLSCOFST                           0xec
>+#define TWODLSCINI                            0xf0
>+#define TWODLSCGRBU                           0xf4
>+#define TWODLSCGRBL                           0xf8
>+#define TWODLSCGROF                           0xfc
>+#define TWODLSCORBU                           0x100
>+#define TWODLSCORBL                           0x104
>+#define TWODLSCOROF                           0x108
>+#define TWODLSCIRQEN                          0x10c
>+#define TWODLSCIRQST                          0x110
>+/****************************************************
>+* Data formatter
>+****************************************************/
>+#define FMTCFG                                        0x114
>+#define FMTPLEN                                       0x118
>+#define FMTSPH                                        0x11c
>+#define FMTLNH                                        0x120
>+#define FMTSLV                                        0x124
>+#define FMTLNV                                        0x128
>+#define FMTRLEN                                       0x12c
>+#define FMTHCNT                                       0x130
>+#define FMTAPTR_BASE                          0x134
>+/* Below macro for addresses FMTAPTR0 - FMTAPTR15 */
>+#define FMTAPTR(i)                    (FMTAPTR_BASE + (i * 4))
>+#define FMTPGMVF0                             0x174
>+#define FMTPGMVF1                             0x178
>+#define FMTPGMAPU0                            0x17c
>+#define FMTPGMAPU1                            0x180
>+#define FMTPGMAPS0                            0x184
>+#define FMTPGMAPS1                            0x188
>+#define FMTPGMAPS2                            0x18c
>+#define FMTPGMAPS3                            0x190
>+#define FMTPGMAPS4                            0x194
>+#define FMTPGMAPS5                            0x198
>+#define FMTPGMAPS6                            0x19c
>+#define FMTPGMAPS7                            0x1a0
>+/************************************************
>+* Color Space Converter
>+************************************************/
>+#define CSCCTL                                        0x1a4
>+#define CSCM0                                 0x1a8
>+#define CSCM1                                 0x1ac
>+#define CSCM2                                 0x1b0
>+#define CSCM3                                 0x1b4
>+#define CSCM4                                 0x1b8
>+#define CSCM5                                 0x1bc
>+#define CSCM6                                 0x1c0
>+#define CSCM7                                 0x1c4
>+#define OBWIN0                                        0x1c8
>+#define OBWIN1                                        0x1cc
>+#define OBWIN2                                        0x1d0
>+#define OBWIN3                                        0x1d4
>+#define OBVAL0                                        0x1d8
>+#define OBVAL1                                        0x1dc
>+#define OBVAL2                                        0x1e0
>+#define OBVAL3                                        0x1e4
>+#define OBVAL4                                        0x1e8
>+#define OBVAL5                                        0x1ec
>+#define OBVAL6                                        0x1f0
>+#define OBVAL7                                        0x1f4
>+#define CLKCTL                                        0x1f8
>+
>+/* Masks & Shifts below */
>+#define START_PX_HOR_MASK                     0x7FFF
>+#define NUM_PX_HOR_MASK                               0x7FFF
>+#define START_VER_ONE_MASK                    0x7FFF
>+#define START_VER_TWO_MASK                    0x7FFF
>+#define NUM_LINES_VER                         0x7FFF
>+
>+/* gain - offset masks */
>+#define GAIN_INTEGER_SHIFT                    9
>+#define OFFSET_MASK                           0xFFF
>+#define GAIN_SDRAM_EN_SHIFT                   12
>+#define GAIN_IPIPE_EN_SHIFT                   13
>+#define GAIN_H3A_EN_SHIFT                     14
>+#define OFST_SDRAM_EN_SHIFT                   8
>+#define OFST_IPIPE_EN_SHIFT                   9
>+#define OFST_H3A_EN_SHIFT                     10
>+#define GAIN_OFFSET_EN_MASK                   0x7700
>+
>+/* Culling */
>+#define CULL_PAT_EVEN_LINE_SHIFT              8
>+
>+/* CCDCFG register */
>+#define ISIF_YCINSWP_RAW                      (0x00 << 4)
>+#define ISIF_YCINSWP_YCBCR                    (0x01 << 4)
>+#define ISIF_CCDCFG_FIDMD_LATCH_VSYNC         (0x00 << 6)
>+#define ISIF_CCDCFG_WENLOG_AND                        (0x00 << 8)
>+#define ISIF_CCDCFG_TRGSEL_WEN                        (0x00 << 9)
>+#define ISIF_CCDCFG_EXTRG_DISABLE             (0x00 << 10)
>+#define ISIF_LATCH_ON_VSYNC_DISABLE           (0x01 << 15)
>+#define ISIF_LATCH_ON_VSYNC_ENABLE            (0x00 << 15)
>+#define ISIF_DATA_PACK_MASK                   3
>+#define ISIF_DATA_PACK16                      0
>+#define ISIF_DATA_PACK12                      1
>+#define ISIF_DATA_PACK8                               2
>+#define ISIF_PIX_ORDER_SHIFT                  11
>+#define ISIF_BW656_ENABLE                     (0x01 << 5)
>+
>+/* MODESET registers */
>+#define ISIF_VDHDOUT_INPUT                    (0x00 << 0)
>+#define ISIF_INPUT_SHIFT                      12
>+#define ISIF_RAW_INPUT_MODE                   0
>+#define ISIF_FID_POL_SHIFT                    4
>+#define ISIF_HD_POL_SHIFT                     3
>+#define ISIF_VD_POL_SHIFT                     2
>+#define ISIF_DATAPOL_NORMAL                   0
>+#define ISIF_DATAPOL_SHIFT                    6
>+#define ISIF_EXWEN_DISABLE                    0
>+#define ISIF_EXWEN_SHIFT                      5
>+#define ISIF_FRM_FMT_SHIFT                    7
>+#define ISIF_DATASFT_SHIFT                    8
>+#define ISIF_LPF_SHIFT                                14
>+#define ISIF_LPF_MASK                         1
>+
>+/* GAMMAWD registers */
>+#define ISIF_ALAW_GAMA_WD_MASK                        0xF
>+#define ISIF_ALAW_GAMA_WD_SHIFT                       1
>+#define ISIF_ALAW_ENABLE                      1
>+#define ISIF_GAMMAWD_CFA_SHIFT                        5
>+
>+/* HSIZE registers */
>+#define ISIF_HSIZE_FLIP_MASK                  1
>+#define ISIF_HSIZE_FLIP_SHIFT                 12
>+
>+/* MISC registers */
>+#define ISIF_DPCM_EN_SHIFT                    12
>+#define ISIF_DPCM_PREDICTOR_SHIFT             13
>+
>+/* Black clamp related */
>+#define ISIF_BC_MODE_COLOR_SHIFT              4
>+#define ISIF_HORZ_BC_MODE_SHIFT                       1
>+#define ISIF_HORZ_BC_WIN_SEL_SHIFT            5
>+#define ISIF_HORZ_BC_PIX_LIMIT_SHIFT          6
>+#define ISIF_HORZ_BC_WIN_H_SIZE_SHIFT         8
>+#define ISIF_HORZ_BC_WIN_V_SIZE_SHIFT         12
>+#define       ISIF_VERT_BC_RST_VAL_SEL_SHIFT          4
>+#define ISIF_VERT_BC_LINE_AVE_COEF_SHIFT      8
>+
>+/* VDFC registers */
>+#define ISIF_VDFC_EN_SHIFT                    4
>+#define ISIF_VDFC_CORR_MOD_SHIFT              5
>+#define ISIF_VDFC_CORR_WHOLE_LN_SHIFT         7
>+#define ISIF_VDFC_LEVEL_SHFT_SHIFT            8
>+#define ISIF_VDFC_POS_MASK                    0x1FFF
>+#define ISIF_DFCMEMCTL_DFCMARST_SHIFT         2
>+
>+/* CSC registers */
>+#define ISIF_CSC_COEF_INTEG_MASK              7
>+#define ISIF_CSC_COEF_DECIMAL_MASK            0x1f
>+#define ISIF_CSC_COEF_INTEG_SHIFT             5
>+#define ISIF_CSCM_MSB_SHIFT                   8
>+#define ISIF_DF_CSC_SPH_MASK                  0x1FFF
>+#define ISIF_DF_CSC_LNH_MASK                  0x1FFF
>+#define ISIF_DF_CSC_SLV_MASK                  0x1FFF
>+#define ISIF_DF_CSC_LNV_MASK                  0x1FFF
>+#define ISIF_DF_NUMLINES                      0x7FFF
>+#define ISIF_DF_NUMPIX                                0x1FFF
>+
>+/* Offsets for LSC/DFC/Gain */
>+#define ISIF_DATA_H_OFFSET_MASK                       0x1FFF
>+#define ISIF_DATA_V_OFFSET_MASK                       0x1FFF
>+
>+/* Linearization */
>+#define ISIF_LIN_CORRSFT_SHIFT                        4
>+#define ISIF_LIN_SCALE_FACT_INTEG_SHIFT               10
>+
>+
>+/* Pattern registers */
>+#define ISIF_PG_EN                            (1 << 3)
>+#define ISIF_SEL_PG_SRC                               (3 << 4)
>+#define ISIF_PG_VD_POL_SHIFT                  0
>+#define ISIF_PG_HD_POL_SHIFT                  1
>+
>+/*random other junk*/
>+#define ISIF_SYNCEN_VDHDEN_MASK                       (1 << 0)
>+#define ISIF_SYNCEN_WEN_MASK                  (1 << 1)
>+#define ISIF_SYNCEN_WEN_SHIFT                 1
>+
>+#endif
>diff --git a/include/media/davinci/isif.h b/include/media/davinci/isif.h
>new file mode 100644
>index 0000000..b0b74ad
>--- /dev/null
>+++ b/include/media/davinci/isif.h
>@@ -0,0 +1,531 @@
>+/*
>+ * Copyright (C) 2008-2009 Texas Instruments Inc
>+ *
>+ * 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
>+ *
>+ * isif header file
>+ */
>+#ifndef _ISIF_H
>+#define _ISIF_H
>+
>+#include <media/davinci/ccdc_types.h>
>+#include <media/davinci/vpfe_types.h>
>+
>+/* isif float type S8Q8/U8Q8 */
>+struct isif_float_8 {
>+      /* 8 bit integer part */
>+      __u8 integer;
>+      /* 8 bit decimal part */
>+      __u8 decimal;
>+};
>+
>+/* isif float type U16Q16/S16Q16 */
>+struct isif_float_16 {
>+      /* 16 bit integer part */
>+      __u16 integer;
>+      /* 16 bit decimal part */
>+      __u16 decimal;
>+};
>+
>+/************************************************************************
>+ *   Vertical Defect Correction parameters
>+ ***********************************************************************/
>+/* Defect Correction (DFC) table entry */
>+struct isif_vdfc_entry {
>+      /* vertical position of defect */
>+      __u16 pos_vert;
>+      /* horizontal position of defect */
>+      __u16 pos_horz;
>+      /*
>+       * Defect level of Vertical line defect position. This is subtracted
>+       * from the data at the defect position
>+       */
>+      __u8 level_at_pos;
>+      /*
>+       * Defect level of the pixels upper than the vertical line defect.
>+       * This is subtracted from the data
>+       */
>+      __u8 level_up_pixels;
>+      /*
>+       * Defect level of the pixels lower than the vertical line defect.
>+       * This is subtracted from the data
>+       */
>+      __u8 level_low_pixels;
>+};
>+
>+#define ISIF_VDFC_TABLE_SIZE          8
>+struct isif_dfc {
>+      /* enable vertical defect correction */
>+      __u8 en;
>+      /* Defect level subtraction. Just fed through if saturating */
>+#define       ISIF_VDFC_NORMAL                0
>+      /*
>+       * Defect level subtraction. Horizontal interpolation ((i-2)+(i+2))/2
>+       * if data saturating
>+       */
>+#define ISIF_VDFC_HORZ_INTERPOL_IF_SAT        1
>+      /* Horizontal interpolation (((i-2)+(i+2))/2) */
>+#define       ISIF_VDFC_HORZ_INTERPOL         2
>+      /* one of the vertical defect correction modes above */
>+      __u8 corr_mode;
>+      /* 0 - whole line corrected, 1 - not pixels upper than the defect */
>+      __u8 corr_whole_line;
>+#define ISIF_VDFC_NO_SHIFT            0
>+#define ISIF_VDFC_SHIFT_1             1
>+#define ISIF_VDFC_SHIFT_2             2
>+#define ISIF_VDFC_SHIFT_3             3
>+#define ISIF_VDFC_SHIFT_4             4
>+      /*
>+       * defect level shift value. level_at_pos, level_upper_pos,
>+       * and level_lower_pos can be shifted up by this value. Choose
>+       * one of the values above
>+       */
>+      __u8 def_level_shift;
>+      /* defect saturation level */
>+      __u16 def_sat_level;
>+      /* number of vertical defects. Max is ISIF_VDFC_TABLE_SIZE */
>+      __u16 num_vdefects;
>+      /* VDFC table ptr */
>+      struct isif_vdfc_entry table[ISIF_VDFC_TABLE_SIZE];
>+};
>+
>+struct isif_horz_bclamp {
>+
>+      /* Horizontal clamp disabled. Only vertical clamp value is subtracted
>*/
>+#define       ISIF_HORZ_BC_DISABLE            0
>+      /*
>+       * Horizontal clamp value is calculated and subtracted from image
>data
>+       * along with vertical clamp value
>+       */
>+#define ISIF_HORZ_BC_CLAMP_CALC_ENABLED       1
>+      /*
>+       * Horizontal clamp value calculated from previous image is
>subtracted
>+       * from image data along with vertical clamp value.
>+       */
>+#define ISIF_HORZ_BC_CLAMP_NOT_UPDATED        2
>+      /* horizontal clamp mode. One of the values above */
>+      __u8 mode;
>+      /*
>+       * pixel value limit enable.
>+       *  0 - limit disabled
>+       *  1 - pixel value limited to 1023
>+       */
>+      __u8 clamp_pix_limit;
>+      /* Select Most left window for bc calculation */
>+#define       ISIF_SEL_MOST_LEFT_WIN          0
>+      /* Select Most right window for bc calculation */
>+#define ISIF_SEL_MOST_RIGHT_WIN               1
>+      /* Select most left or right window for clamp val calculation */
>+      __u8 base_win_sel_calc;
>+      /* Window count per color for calculation. range 1-32 */
>+      __u8 win_count_calc;
>+      /* Window start position - horizontal for calculation. 0 - 8191 */
>+      __u16 win_start_h_calc;
>+      /* Window start position - vertical for calculation 0 - 8191 */
>+      __u16 win_start_v_calc;
>+#define ISIF_HORZ_BC_SZ_H_2PIXELS     0
>+#define ISIF_HORZ_BC_SZ_H_4PIXELS     1
>+#define ISIF_HORZ_BC_SZ_H_8PIXELS     2
>+#define ISIF_HORZ_BC_SZ_H_16PIXELS    3
>+      /* Width of the sample window in pixels for calculation */
>+      __u8 win_h_sz_calc;
>+#define ISIF_HORZ_BC_SZ_V_32PIXELS    0
>+#define ISIF_HORZ_BC_SZ_V_64PIXELS    1
>+#define       ISIF_HORZ_BC_SZ_V_128PIXELS     2
>+#define ISIF_HORZ_BC_SZ_V_256PIXELS   3
>+      /* Height of the sample window in pixels for calculation */
>+      __u8 win_v_sz_calc;
>+};
>+
>+/************************************************************************
>+ *  Black Clamp parameters
>+ ***********************************************************************/
>+struct isif_vert_bclamp {
>+      /* Reset value used is the clamp value calculated */
>+#define       ISIF_VERT_BC_USE_HORZ_CLAMP_VAL         0
>+      /* Reset value used is reset_clamp_val configured */
>+#define       ISIF_VERT_BC_USE_CONFIG_CLAMP_VAL       1
>+      /* No update, previous image value is used */
>+#define       ISIF_VERT_BC_NO_UPDATE                  2
>+      /*
>+       * Reset value selector for vertical clamp calculation. Use one of
>+       * the above values
>+       */
>+      __u8 reset_val_sel;
>+      /* U8Q8. Line average coefficient used in vertical clamp calculation
>*/
>+      __u8 line_ave_coef;
>+      /* Height of the optical black region for calculation */
>+      __u16 ob_v_sz_calc;
>+      /* Optical black region start position - horizontal. 0 - 8191 */
>+      __u16 ob_start_h;
>+      /* Optical black region start position - vertical 0 - 8191 */
>+      __u16 ob_start_v;
>+};
>+
>+struct isif_black_clamp {
>+      /*
>+       * This offset value is added irrespective of the clamp enable status.
>+       * S13
>+       */
>+      __u16 dc_offset;
>+      /*
>+       * Enable black/digital clamp value to be subtracted from the image
>data
>+       */
>+      __u8 en;
>+      /*
>+       * black clamp mode. same/separate clamp for 4 colors
>+       * 0 - disable - same clamp value for all colors
>+       * 1 - clamp value calculated separately for all colors
>+       */
>+      __u8 bc_mode_color;
>+      /* Vrtical start position for bc subtraction */
>+      __u16 vert_start_sub;
>+      /* Black clamp for horizontal direction */
>+      struct isif_horz_bclamp horz;
>+      /* Black clamp for vertical direction */
>+      struct isif_vert_bclamp vert;
>+};
>+
>+/*************************************************************************
>+** Color Space Convertion (CSC)
>+*************************************************************************/
>+#define ISIF_CSC_NUM_COEFF    16
>+struct isif_color_space_conv {
>+      /* Enable color space conversion */
>+      __u8 en;
>+      /*
>+       * csc coeffient table. S8Q5, M00 at index 0, M01 at index 1, and
>+       * so forth
>+       */
>+      struct isif_float_8 coeff[ISIF_CSC_NUM_COEFF];
>+};
>+
>+
>+/*************************************************************************
>+**  Black  Compensation parameters
>+*************************************************************************/
>+struct isif_black_comp {
>+      /* Comp for Red */
>+      __s8 r_comp;
>+      /* Comp for Gr */
>+      __s8 gr_comp;
>+      /* Comp for Blue */
>+      __s8 b_comp;
>+      /* Comp for Gb */
>+      __s8 gb_comp;
>+};
>+
>+/*************************************************************************
>+**  Gain parameters
>+*************************************************************************/
>+struct isif_gain {
>+      /* Gain for Red or ye */
>+      struct isif_float_16 r_ye;
>+      /* Gain for Gr or cy */
>+      struct isif_float_16 gr_cy;
>+      /* Gain for Gb or g */
>+      struct isif_float_16 gb_g;
>+      /* Gain for Blue or mg */
>+      struct isif_float_16 b_mg;
>+};
>+
>+#define ISIF_LINEAR_TAB_SIZE  192
>+/*************************************************************************
>+**  Linearization parameters
>+*************************************************************************/
>+struct isif_linearize {
>+      /* Enable or Disable linearization of data */
>+      __u8 en;
>+      /* Shift value applied */
>+      __u8 corr_shft;
>+      /* scale factor applied U11Q10 */
>+      struct isif_float_16 scale_fact;
>+      /* Size of the linear table */
>+      __u16 table[ISIF_LINEAR_TAB_SIZE];
>+};
>+
>+/* Color patterns */
>+#define ISIF_RED      0
>+#define       ISIF_GREEN_RED  1
>+#define ISIF_GREEN_BLUE       2
>+#define ISIF_BLUE     3
>+struct isif_col_pat {
>+      __u8 olop;
>+      __u8 olep;
>+      __u8 elop;
>+      __u8 elep;
>+};
>+
>+/*************************************************************************
>+**  Data formatter parameters
>+*************************************************************************/
>+struct isif_fmtplen {
>+      /*
>+       * number of program entries for SET0, range 1 - 16
>+       * when fmtmode is ISIF_SPLIT, 1 - 8 when fmtmode is
>+       * ISIF_COMBINE
>+       */
>+      __u16 plen0;
>+      /*
>+       * number of program entries for SET1, range 1 - 16
>+       * when fmtmode is ISIF_SPLIT, 1 - 8 when fmtmode is
>+       * ISIF_COMBINE
>+       */
>+      __u16 plen1;
>+      /**
>+       * number of program entries for SET2, range 1 - 16
>+       * when fmtmode is ISIF_SPLIT, 1 - 8 when fmtmode is
>+       * ISIF_COMBINE
>+       */
>+      __u16 plen2;
>+      /**
>+       * number of program entries for SET3, range 1 - 16
>+       * when fmtmode is ISIF_SPLIT, 1 - 8 when fmtmode is
>+       * ISIF_COMBINE
>+       */
>+      __u16 plen3;
>+};
>+
>+struct isif_fmt_cfg {
>+#define ISIF_SPLIT            0
>+#define ISIF_COMBINE          1
>+      /* Split or combine or line alternate */
>+      __u8 fmtmode;
>+      /* enable or disable line alternating mode */
>+      __u8 ln_alter_en;
>+#define ISIF_1LINE            0
>+#define       ISIF_2LINES             1
>+#define       ISIF_3LINES             2
>+#define       ISIF_4LINES             3
>+      /* Split/combine line number */
>+      __u8 lnum;
>+      /* Address increment Range 1 - 16 */
>+      __u8 addrinc;
>+};
>+
>+struct isif_fmt_addr_ptr {
>+      /* Initial address */
>+      __u32 init_addr;
>+      /* output line number */
>+#define ISIF_1STLINE          0
>+#define       ISIF_2NDLINE            1
>+#define       ISIF_3RDLINE            2
>+#define       ISIF_4THLINE            3
>+      __u8 out_line;
>+};
>+
>+struct isif_fmtpgm_ap {
>+      /* program address pointer */
>+      __u8 pgm_aptr;
>+      /* program address increment or decrement */
>+      __u8 pgmupdt;
>+};
>+
>+struct isif_data_formatter {
>+      /* Enable/Disable data formatter */
>+      __u8 en;
>+      /* data formatter configuration */
>+      struct isif_fmt_cfg cfg;
>+      /* Formatter program entries length */
>+      struct isif_fmtplen plen;
>+      /* first pixel in a line fed to formatter */
>+      __u16 fmtrlen;
>+      /* HD interval for output line. Only valid when split line */
>+      __u16 fmthcnt;
>+      /* formatter address pointers */
>+      struct isif_fmt_addr_ptr fmtaddr_ptr[16];
>+      /* program enable/disable */
>+      __u8 pgm_en[32];
>+      /* program address pointers */
>+      struct isif_fmtpgm_ap fmtpgm_ap[32];
>+};
>+
>+struct isif_df_csc {
>+      /* Color Space Conversion confguration, 0 - csc, 1 - df */
>+      __u8 df_or_csc;
>+      /* csc configuration valid if df_or_csc is 0 */
>+      struct isif_color_space_conv csc;
>+      /* data formatter configuration valid if df_or_csc is 1 */
>+      struct isif_data_formatter df;
>+      /* start pixel in a line at the input */
>+      __u32 start_pix;
>+      /* number of pixels in input line */
>+      __u32 num_pixels;
>+      /* start line at the input */
>+      __u32 start_line;
>+      /* number of lines at the input */
>+      __u32 num_lines;
>+};
>+
>+struct isif_gain_offsets_adj {
>+      /* Gain adjustment per color */
>+      struct isif_gain gain;
>+      /* Offset adjustment */
>+      __u16 offset;
>+      /* Enable or Disable Gain adjustment for SDRAM data */
>+      __u8 gain_sdram_en;
>+      /* Enable or Disable Gain adjustment for IPIPE data */
>+      __u8 gain_ipipe_en;
>+      /* Enable or Disable Gain adjustment for H3A data */
>+      __u8 gain_h3a_en;
>+      /* Enable or Disable Gain adjustment for SDRAM data */
>+      __u8 offset_sdram_en;
>+      /* Enable or Disable Gain adjustment for IPIPE data */
>+      __u8 offset_ipipe_en;
>+      /* Enable or Disable Gain adjustment for H3A data */
>+      __u8 offset_h3a_en;
>+};
>+
>+struct isif_cul {
>+      /* Horizontal Cull pattern for odd lines */
>+      __u8 hcpat_odd;
>+      /* Horizontal Cull pattern for even lines */
>+      __u8 hcpat_even;
>+      /* Vertical Cull pattern */
>+      __u8 vcpat;
>+      /* Enable or disable lpf. Apply when cull is enabled */
>+      __u8 en_lpf;
>+};
>+
>+struct isif_compress {
>+#define ISIF_ALAW             0
>+#define ISIF_DPCM             1
>+#define ISIF_NO_COMPRESSION   2
>+      /* Compression Algorithm used */
>+      __u8 alg;
>+      /* Choose Predictor1 for DPCM compression */
>+#define ISIF_DPCM_PRED1               0
>+      /* Choose Predictor2 for DPCM compression */
>+#define ISIF_DPCM_PRED2               1
>+      /* Predictor for DPCM compression */
>+      __u8 pred;
>+};
>+
>+/* all the stuff in this struct will be provided by userland */
>+struct isif_config_params_raw {
>+      /* Linearization parameters for image sensor data input */
>+      struct isif_linearize linearize;
>+      /* Data formatter or CSC */
>+      struct isif_df_csc df_csc;
>+      /* Defect Pixel Correction (DFC) confguration */
>+      struct isif_dfc dfc;
>+      /* Black/Digital Clamp configuration */
>+      struct isif_black_clamp bclamp;
>+      /* Gain, offset adjustments */
>+      struct isif_gain_offsets_adj gain_offset;
>+      /* Culling */
>+      struct isif_cul culling;
>+      /* A-Law and DPCM compression options */
>+      struct isif_compress compress;
>+      /* horizontal offset for Gain/LSC/DFC */
>+      __u16 horz_offset;
>+      /* vertical offset for Gain/LSC/DFC */
>+      __u16 vert_offset;
>+      /* color pattern for field 0 */
>+      struct isif_col_pat col_pat_field0;
>+      /* color pattern for field 1 */
>+      struct isif_col_pat col_pat_field1;
>+#define ISIF_NO_SHIFT         0
>+#define       ISIF_1BIT_SHIFT         1
>+#define       ISIF_2BIT_SHIFT         2
>+#define       ISIF_3BIT_SHIFT         3
>+#define       ISIF_4BIT_SHIFT         4
>+#define ISIF_5BIT_SHIFT               5
>+#define ISIF_6BIT_SHIFT               6
>+      /* Data shift applied before storing to SDRAM */
>+      __u8 data_shift;
>+      /* enable input test pattern generation */
>+      __u8 test_pat_gen;
>+};
>+
>+#ifdef __KERNEL__
>+struct isif_ycbcr_config {
>+      /* isif pixel format */
>+      enum ccdc_pixfmt pix_fmt;
>+      /* isif frame format */
>+      enum ccdc_frmfmt frm_fmt;
>+      /* ISIF crop window */
>+      struct v4l2_rect win;
>+      /* field polarity */
>+      enum vpfe_pin_pol fid_pol;
>+      /* interface VD polarity */
>+      enum vpfe_pin_pol vd_pol;
>+      /* interface HD polarity */
>+      enum vpfe_pin_pol hd_pol;
>+      /* isif pix order. Only used for ycbcr capture */
>+      enum ccdc_pixorder pix_order;
>+      /* isif buffer type. Only used for ycbcr capture */
>+      enum ccdc_buftype buf_type;
>+};
>+
>+/* MSB of image data connected to sensor port */
>+enum isif_data_msb {
>+      ISIF_BIT_MSB_15,
>+      ISIF_BIT_MSB_14,
>+      ISIF_BIT_MSB_13,
>+      ISIF_BIT_MSB_12,
>+      ISIF_BIT_MSB_11,
>+      ISIF_BIT_MSB_10,
>+      ISIF_BIT_MSB_9,
>+      ISIF_BIT_MSB_8,
>+      ISIF_BIT_MSB_7
>+};
>+
>+enum isif_cfa_pattern {
>+      ISIF_CFA_PAT_MOSAIC,
>+      ISIF_CFA_PAT_STRIPE
>+};
>+
>+struct isif_params_raw {
>+      /* isif pixel format */
>+      enum ccdc_pixfmt pix_fmt;
>+      /* isif frame format */
>+      enum ccdc_frmfmt frm_fmt;
>+      /* video window */
>+      struct v4l2_rect win;
>+      /* field polarity */
>+      enum vpfe_pin_pol fid_pol;
>+      /* interface VD polarity */
>+      enum vpfe_pin_pol vd_pol;
>+      /* interface HD polarity */
>+      enum vpfe_pin_pol hd_pol;
>+      /* buffer type. Applicable for interlaced mode */
>+      enum ccdc_buftype buf_type;
>+      /* Gain values */
>+      struct isif_gain gain;
>+      /* cfa pattern */
>+      enum isif_cfa_pattern cfa_pat;
>+      /* Data MSB position */
>+      enum isif_data_msb data_msb;
>+      /* Enable horizontal flip */
>+      unsigned char horz_flip_en;
>+      /* Enable image invert vertically */
>+      unsigned char image_invert_en;
>+
>+      /* all the userland defined stuff*/
>+      struct isif_config_params_raw config_params;
>+};
>+
>+enum isif_data_pack {
>+      ISIF_PACK_16BIT,
>+      ISIF_PACK_12BIT,
>+      ISIF_PACK_8BIT
>+};
>+
>+#define ISIF_WIN_NTSC                         {0, 0, 720, 480}
>+#define ISIF_WIN_VGA                          {0, 0, 640, 480}
>+
>+#endif
>+#endif
>--
>1.6.0.4


From m-karicheri2 at ti.com  Mon Feb  1 16:38:53 2010
From: m-karicheri2 at ti.com (m-karicheri2 at ti.com)
Date: Mon,  1 Feb 2010 17:38:53 -0500
Subject: [PATCH v3 6/6] DaVinci - Adding platform & board changes for vpfe
	capture on DM365
Message-ID: <1265063933-2425-1-git-send-email-m-karicheri2@ti.com>

From: Murali Karicheri <m-karicheri2 at ti.com>

This patch adds following changes:-
	1) add sub device configuration data for TVP5146 used by vpfe capture
	2) registers platform devices for vpfe_capture, isif and vpss
	3) defines hardware resources for the devices listed under 2)
	4) defines clock aliase for isif driver
	5) adding setup_pinmux() for isif

Reviewed-by: Kevin Hilman <khilman at deeprootsystems.com>
Signed-off-by: Murali Karicheri <m-karicheri2 at ti.com>
---
Applies to linux-next of v4l-dvb
 - removing some white spaces and re-resending........
 - updated to add clock aliase (v3) and rebased to latest for merge
 - review comments incorporated (v2)
 arch/arm/mach-davinci/board-dm365-evm.c    |   71 +++++++++++++++++++
 arch/arm/mach-davinci/dm365.c              |  102 +++++++++++++++++++++++++++-
 arch/arm/mach-davinci/include/mach/dm365.h |    2 +
 3 files changed, 174 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index b476395..38e9033 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -37,6 +37,8 @@
 #include <mach/nand.h>
 #include <mach/keyscan.h>
 
+#include <media/tvp514x.h>
+
 static inline int have_imager(void)
 {
 	/* REVISIT when it's supported, trigger via Kconfig */
@@ -306,6 +308,73 @@ static void dm365evm_mmc_configure(void)
 	davinci_cfg_reg(DM365_SD1_DATA0);
 }
 
+static struct tvp514x_platform_data tvp5146_pdata = {
+	.clk_polarity = 0,
+	.hs_polarity = 1,
+	.vs_polarity = 1
+};
+
+#define TVP514X_STD_ALL        (V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+	{
+		.index = 0,
+		.name = "Composite",
+		.type = V4L2_INPUT_TYPE_CAMERA,
+		.std = TVP514X_STD_ALL,
+	},
+	{
+		.index = 1,
+		.name = "S-Video",
+		.type = V4L2_INPUT_TYPE_CAMERA,
+		.std = TVP514X_STD_ALL,
+	},
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+	{
+		.input = INPUT_CVBS_VI2B,
+		.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+	},
+{
+		.input = INPUT_SVIDEO_VI2C_VI1C,
+		.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+	},
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+	{
+		.name = "tvp5146",
+		.grp_id = 0,
+		.num_inputs = ARRAY_SIZE(tvp5146_inputs),
+		.inputs = tvp5146_inputs,
+		.routes = tvp5146_routes,
+		.can_route = 1,
+		.ccdc_if_params = {
+			.if_type = VPFE_BT656,
+			.hdpol = VPFE_PINPOL_POSITIVE,
+			.vdpol = VPFE_PINPOL_POSITIVE,
+		},
+		.board_info = {
+			I2C_BOARD_INFO("tvp5146", 0x5d),
+			.platform_data = &tvp5146_pdata,
+		},
+	},
+};
+
+static struct vpfe_config vpfe_cfg = {
+	.num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+	.sub_devs = vpfe_sub_devs,
+	.i2c_adapter_id = 1,
+	.card_name = "DM365 EVM",
+	.ccdc = "ISIF",
+};
+
 static void __init evm_init_i2c(void)
 {
 	davinci_init_i2c(&i2c_pdata);
@@ -497,6 +566,8 @@ static struct davinci_uart_config uart_config __initdata = {
 
 static void __init dm365_evm_map_io(void)
 {
+	/* setup input configuration for VPFE input devices */
+	dm365_set_vpfe_config(&vpfe_cfg);
 	dm365_init();
 }
 
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index f53735c..ce9da43 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1008,6 +1008,97 @@ void __init dm365_init(void)
 	davinci_common_init(&davinci_soc_info_dm365);
 }
 
+static struct resource dm365_vpss_resources[] = {
+	{
+		/* VPSS ISP5 Base address */
+		.name           = "isp5",
+		.start          = 0x01c70000,
+		.end            = 0x01c70000 + 0xff,
+		.flags          = IORESOURCE_MEM,
+	},
+	{
+		/* VPSS CLK Base address */
+		.name           = "vpss",
+		.start          = 0x01c70200,
+		.end            = 0x01c70200 + 0xff,
+		.flags          = IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device dm365_vpss_device = {
+       .name                   = "vpss",
+       .id                     = -1,
+       .dev.platform_data      = "dm365_vpss",
+       .num_resources          = ARRAY_SIZE(dm365_vpss_resources),
+       .resource               = dm365_vpss_resources,
+};
+
+static struct resource vpfe_resources[] = {
+	{
+		.start          = IRQ_VDINT0,
+		.end            = IRQ_VDINT0,
+		.flags          = IORESOURCE_IRQ,
+	},
+	{
+		.start          = IRQ_VDINT1,
+		.end            = IRQ_VDINT1,
+		.flags          = IORESOURCE_IRQ,
+	},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct platform_device vpfe_capture_dev = {
+	.name           = CAPTURE_DRV_NAME,
+	.id             = -1,
+	.num_resources  = ARRAY_SIZE(vpfe_resources),
+	.resource       = vpfe_resources,
+	.dev = {
+		.dma_mask               = &vpfe_capture_dma_mask,
+		.coherent_dma_mask      = DMA_BIT_MASK(32),
+	},
+};
+
+static void dm365_isif_setup_pinmux(void)
+{
+	davinci_cfg_reg(DM365_VIN_CAM_WEN);
+	davinci_cfg_reg(DM365_VIN_CAM_VD);
+	davinci_cfg_reg(DM365_VIN_CAM_HD);
+	davinci_cfg_reg(DM365_VIN_YIN4_7_EN);
+	davinci_cfg_reg(DM365_VIN_YIN0_3_EN);
+}
+
+static struct resource isif_resource[] = {
+	/* ISIF Base address */
+	{
+		.start          = 0x01c71000,
+		.end            = 0x01c71000 + 0x1ff,
+		.flags          = IORESOURCE_MEM,
+	},
+	/* ISIF Linearization table 0 */
+	{
+		.start          = 0x1C7C000,
+		.end            = 0x1C7C000 + 0x2ff,
+		.flags          = IORESOURCE_MEM,
+	},
+	/* ISIF Linearization table 1 */
+	{
+		.start          = 0x1C7C400,
+		.end            = 0x1C7C400 + 0x2ff,
+		.flags          = IORESOURCE_MEM,
+	},
+};
+static struct platform_device dm365_isif_dev = {
+	.name           = "isif",
+	.id             = -1,
+	.num_resources  = ARRAY_SIZE(isif_resource),
+	.resource       = isif_resource,
+	.dev = {
+		.dma_mask               = &vpfe_capture_dma_mask,
+		.coherent_dma_mask      = DMA_BIT_MASK(32),
+		.platform_data		= dm365_isif_setup_pinmux,
+	},
+};
+
 static int __init dm365_init_devices(void)
 {
 	if (!cpu_is_davinci_dm365())
@@ -1016,7 +1107,16 @@ static int __init dm365_init_devices(void)
 	davinci_cfg_reg(DM365_INT_EDMA_CC);
 	platform_device_register(&dm365_edma_device);
 	platform_device_register(&dm365_emac_device);
-
+	/* Add isif clock alias */
+	clk_add_alias("master", dm365_isif_dev.name, "vpss_master", NULL);
+	platform_device_register(&dm365_vpss_device);
+	platform_device_register(&dm365_isif_dev);
+	platform_device_register(&vpfe_capture_dev);
 	return 0;
 }
 postcore_initcall(dm365_init_devices);
+
+void dm365_set_vpfe_config(struct vpfe_config *cfg)
+{
+       vpfe_capture_dev.dev.platform_data = cfg;
+}
diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h
index f1710a3..9fc5a64 100644
--- a/arch/arm/mach-davinci/include/mach/dm365.h
+++ b/arch/arm/mach-davinci/include/mach/dm365.h
@@ -18,6 +18,7 @@
 #include <mach/emac.h>
 #include <mach/asp.h>
 #include <mach/keyscan.h>
+#include <media/davinci/vpfe_capture.h>
 
 #define DM365_EMAC_BASE			(0x01D07000)
 #define DM365_EMAC_CNTRL_OFFSET		(0x0000)
@@ -36,4 +37,5 @@ void __init dm365_init_asp(struct snd_platform_data *pdata);
 void __init dm365_init_ks(struct davinci_ks_platform_data *pdata);
 void __init dm365_init_rtc(void);
 
+void dm365_set_vpfe_config(struct vpfe_config *cfg);
 #endif /* __ASM_ARCH_DM365_H */
-- 
1.6.0.4


From rohan_javed at yahoo.co.uk  Tue Feb  2 01:46:36 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Mon, 1 Feb 2010 23:46:36 -0800 (PST)
Subject: MTD Erase failure: -22
Message-ID: <773852.38395.qm@web24103.mail.ird.yahoo.com>

hello everyone 


DM6446

we have our own custom board DM6446 I have used the open source git kernel and u-boot for booting i have sucessfully done the bootin but i am curious about this error when it u-boot i do nand erase i get the following error at various addresses any on knows y i am unable to erase

 NAND 256MiB 1,8V 8-bit: MTD Erase failure: -22

for example nand erase 0x470000



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100201/c671d07e/attachment.html>

From krunal.patil at einfochips.com  Tue Feb  2 02:00:12 2010
From: krunal.patil at einfochips.com (Krunal Patil)
Date: Tue, 02 Feb 2010 13:30:12 +0530
Subject: USB errors while writing to USB HDD.
Message-ID: <4B67DB8C.30605@einfochips.com>

Hi,

I am working with DM355 based (custom hardware) system in which I am
writing JPEG image files to USB 2.0 HDD (having ext3 filesystem). Please
note that the USB HDD is connected through a hub chip.

I am using kernel version 2.6.10 and there are no modification to USB
stack and filesystem.
My application is running from the MMC card (having ext3 filesystem).
When I am writing 9-10 image files (each approx 2 MB) one after another

I am getting following USB and filesystem related  error on UART
terminal and my whole system just get hang including the UART terminal.
Could anyone please suggest
some pointers or solution for this problem?


usb 1-1: scsi_eh_0 timed out on ep0out
hub 1-1:1.0: cannot reset port 3 (err = -110)
usb 1-1: scsi_eh_0 timed out on ep0out
hub 1-1:1.0: cannot reset port 3 (err = -110)
hub 1-1:1.0: Cannot enable port 3.  Maybe the USB cable is bad?
usb 1-1: scsi_eh_0 timed out on ep0out
hub 1-1:1.0: cannot reset port 3 (err = -110)
usb 1-1: scsi_eh_0 timed out on ep0out
hub 1-1:1.0: cannot reset port 3 (err = -110)
hub 1-1:1.0: Cannot enable port 3.  Maybe the USB cable is bad?
usb 1-1: scsi_eh_0 timed out on ep0out
hub 1-1:1.0: cannot disable port 3 (err = -110)
scsi: Device offlined - not ready after error recovery: host 0 channel 0
id 0 lun 0
SCSI error : <0 0 0 0> return code = 0x50000
end_request: I/O error, dev sda, sector 128712760
Buffer I/O error on device sda, logical block 16089095
lost page write due to I/O error on sda
scsi0 (0:0): rejecting I/O to offline device
scsi0 (0:0): rejecting I/O to offline device
Buffer I/O error on device sda, logical block 575
lost page write due to I/O error on sda
Aborting journal on device sda.
usb 1-1: khubd timed out on ep0in
hub 1-1:1.0: hub_port_status failed (err = -110)

-- 
Regards,
Krunal



-- 
_____________________________________________________________________
Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution, copying, or other use of
this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
replying to this message and please delete it from your computer. Any
views expressed in this message are those of the individual sender
unless otherwise stated.Company has taken enough precautions to prevent
the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email.
_____________________________________________________________________
 

From guillaume.gardet at cioinfoindus.fr  Tue Feb  2 04:30:16 2010
From: guillaume.gardet at cioinfoindus.fr (Guillaume GARDET)
Date: Tue, 02 Feb 2010 11:30:16 +0100
Subject: How to load to UBL and U-boot to RAM on DM6467?
In-Reply-To: <A41DC312BCC9DA4E8B8B954805B8C9FDA373CB67A8@CHN-HCLT-EVS06.HCLT.CORP.HCL.IN>
References: <A41DC312BCC9DA4E8B8B954805B8C9FDA373CB67A8@CHN-HCLT-EVS06.HCLT.CORP.HCL.IN>
Message-ID: <4B67FEB8.9070006@cioinfoindus.fr>

I think you want to CC list.


Balaji Sivakumar, ERS, HCLTech a ?crit :
>
> Hi,
>
> Am using DM6467 Evaluation Board, Unfortunately I have erased the 
> *Nand Flash*. Due to that in the serial port, it displays ?BOOTME? only.
>
> Am trying Load the UBL to SPI Boot Mode using CCS and JTAG Emulator, 
> it is asking the path of the bin file and I kept the path of the bin 
> file, its not accepting the Input file.
>

I do not use neither CCS nor JTAG so I cannot help here.

>  
>
> What would be the problem, I didn?t try the serial flasher utility?
>

I use the serial loader (to DDR) to load u-boot since I have some 
problems with NAND Flash on our custom board (based on DM6467).
You can use the serial flasher (to FLASH) to flash UBL and u-boot to 
your nand flash.

Cheers,

Guillaume

>  
>
> /Thanks,/
> / - Balaji S/
>
>  
>
>  
>
> DISCLAIMER:
> -----------------------------------------------------------------------------------------------------------------------
>
> The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. 
> It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
> this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. 
> Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
> this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have 
> received this email in error please delete it and notify the sender immediately. Before opening any mail and 
> attachments please check them for viruses and defect.
>
> -----------------------------------------------------------------------------------------------------------------------
>

From guillaume.gardet at cioinfoindus.fr  Tue Feb  2 05:22:59 2010
From: guillaume.gardet at cioinfoindus.fr (Guillaume GARDET)
Date: Tue, 02 Feb 2010 12:22:59 +0100
Subject: How to load to UBL and U-boot to RAM on DM6467?
In-Reply-To: <13bd74411002020317g4494f0bdhe8cb194bd4b3ff1d@mail.gmail.com>
References: <A41DC312BCC9DA4E8B8B954805B8C9FDA373CB67A8@CHN-HCLT-EVS06.HCLT.CORP.HCL.IN>	
	<4B67FEB8.9070006@cioinfoindus.fr>
	<13bd74411002020317g4494f0bdhe8cb194bd4b3ff1d@mail.gmail.com>
Message-ID: <4B680B13.7080404@cioinfoindus.fr>

This is "Balaji Sivakumar, ERS, HCLTech" who need help, not me, so do 
not forget to CC list.


kirthika varadarajan a ?crit :
> Try DV flasher(serial boot utility ) or  SD booting
>
> On Tue, Feb 2, 2010 at 4:00 PM, Guillaume GARDET 
> <guillaume.gardet at cioinfoindus.fr 
> <mailto:guillaume.gardet at cioinfoindus.fr>> wrote:
>
>     I think you want to CC list.
>
>
>     Balaji Sivakumar, ERS, HCLTech a ?crit :
>
>
>         Hi,
>
>         Am using DM6467 Evaluation Board, Unfortunately I have erased
>         the *Nand Flash*. Due to that in the serial port, it displays
>         ?BOOTME? only.
>
>         Am trying Load the UBL to SPI Boot Mode using CCS and JTAG
>         Emulator, it is asking the path of the bin file and I kept the
>         path of the bin file, its not accepting the Input file.
>
>
>     I do not use neither CCS nor JTAG so I cannot help here.
>
>          
>         What would be the problem, I didn?t try the serial flasher
>         utility?
>
>
>     I use the serial loader (to DDR) to load u-boot since I have some
>     problems with NAND Flash on our custom board (based on DM6467).
>     You can use the serial flasher (to FLASH) to flash UBL and u-boot
>     to your nand flash.
>
>     Cheers,
>
>     Guillaume
>
>          
>         /Thanks,/
>         / - Balaji S/
>
>          
>          
>         DISCLAIMER:
>         -----------------------------------------------------------------------------------------------------------------------
>
>         The contents of this e-mail and any attachment(s) are
>         confidential and intended for the named recipient(s) only. It
>         shall not attach any liability on the originator or HCL or its
>         affiliates. Any views or opinions presented in this email are
>         solely those of the author and may not necessarily reflect the
>         opinions of HCL or its affiliates. Any form of reproduction,
>         dissemination, copying, disclosure, modification, distribution
>         and / or publication of this message without the prior written
>         consent of the author of this e-mail is strictly prohibited.
>         If you have received this email in error please delete it and
>         notify the sender immediately. Before opening any mail and
>         attachments please check them for viruses and defect.
>
>         -----------------------------------------------------------------------------------------------------------------------
>
>     _______________________________________________
>     Davinci-linux-open-source mailing list
>     Davinci-linux-open-source at linux.davincidsp.com
>     <mailto:Davinci-linux-open-source at linux.davincidsp.com>
>     http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>

From brijesh.j at ti.com  Tue Feb  2 07:34:40 2010
From: brijesh.j at ti.com (Jadav, Brijesh R)
Date: Tue, 2 Feb 2010 19:04:40 +0530
Subject: DM6467 component out-NO SYNC
In-Reply-To: <23910586.337511264125938808.JavaMail.weblogic@epml11>
References: <23910586.337511264125938808.JavaMail.weblogic@epml11>
Message-ID: <19F8576C6E063C45BE387C64729E7394044A6B95C0@dbde02.ent.ti.com>

Hi,

Are you saying Dumped decoded streams works correctly on software players? If it works, I think there is some timing parameters mismatch. 

Which mode are you using for the display? Does your TV support the mode you are trying to display?

Thanks,
Brijesh Jadav


-----Original Message-----
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Jaya krishnan
Sent: Friday, January 22, 2010 7:36 AM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: DM6467 component out-NO SYNC

I am  working  on an   application based  on DM6467. I need  to display  the H264 decoded  stream on a component display.
The display is not  steady, in the  sense that it  scrolls vertically often, and  the  display equipment   shows  a NO SYNC sign at that  time. I understand that the 
the problem is  due to lack of SYNC  signal. But why this  happens only to this  stream? The  stream can be decoded and  displayed in software players.
Any  help   would be greatly appreciated.
Thanks & regards
JK

 
   Jayakrishnan M M
Research Engineer
Key Systems Development Group
Security & Imaging             Solutions Division
SAMSUNG TECHWIN CO.,LTD

TEL +82-2-3467-7403
FAX +82-2-3467-7316
Mobile +82-10-6409-3619
E-mail:jaya.krishnan at samsung.com            
 
  
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From opindroch at softhard.sk  Tue Feb  2 08:07:45 2010
From: opindroch at softhard.sk (Ondrej Pindroch)
Date: Tue, 02 Feb 2010 15:07:45 +0100
Subject: DDR2 controler
Message-ID: <WC20100202140745.820068@softhard.sk>

Hi

We are developing our own board with DM365. Most of the board is done 
according to EVM schematic.
The problem is DDR. We are useing the same IC as EVM. However with the same 
registry setup as in EVM it is not working.
I have examined some signals like CLK, RAS, CAS, some data bits, and adrress 
bits, all seems to be OK.

Any suggestion is welcome.
Best regards
Ondrej Pindroch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100202/fc014d0c/attachment.html>

From kirthikaiitm at gmail.com  Tue Feb  2 08:58:52 2010
From: kirthikaiitm at gmail.com (Kiruthika)
Date: Tue, 2 Feb 2010 20:28:52 +0530
Subject: Dear Davinci-Linux-Open-Source@linux.Davincidsp.Com,
	If you can't find in google, try JUSTDIAL.COM
Message-ID: <af2d155a75432e3c3bac39347890f4e1@192.168.1.23>

Dear Davinci-Linux-Open-Source at linux.Davincidsp.Com,I strongly recommend this website www.justdial.com. It's a world class local search service & I've always found anything I've ever wanted.You can find info on any company, product, or service in over 240 cities in India.You can also call them up 24x7, on phone (69999999), a local call in 240 Indian cities.Ask for anything, you'll get the info on the phone and/or by SMS within 30 secs, and this service is at no cost!For a change, it's an original Indian idea and an Indian company with world class service, and with a vision to spread all over the world.Be a proud Indian and forward this to every Indian you know.Best Wishes,KiruthikaClick Here to unsubscribe.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100202/d1ef35be/attachment.html>

From ottavio.campana at dei.unipd.it  Tue Feb  2 10:32:57 2010
From: ottavio.campana at dei.unipd.it (Ottavio Campana)
Date: Tue, 02 Feb 2010 17:32:57 +0100
Subject: question on RAMDISK
In-Reply-To: <B4CC737B5C72E74A877F33104AD30A6002A8A6CA@excirvca2a.corp.irvine-sensors.com>
References: <B4CC737B5C72E74A877F33104AD30A6002A8A6CA@excirvca2a.corp.irvine-sensors.com>
Message-ID: <4B6853B9.5060505@dei.unipd.it>

Il 01/02/10 22.49, Naresh Kansara ha scritto:
> Hello All,
>
> I have two questions.
>
>    1. Is there a limit of 32MB on Ramdisk? I tried to use 64MB size and
>       I got some errors

I don't know, but maybe you're running out of memory....

>    2. Has anybody tried to use two RAMDISK? If yes how to use two ramdisk?

what I do is booting and mounting the rootfs on a ramdisk and 
successively I can mount in tmp a tmpfs volume.


From ottavio.campana at dei.unipd.it  Tue Feb  2 10:33:41 2010
From: ottavio.campana at dei.unipd.it (Ottavio Campana)
Date: Tue, 02 Feb 2010 17:33:41 +0100
Subject: ogg vorbis encoder for dm6446
Message-ID: <4B6853E5.3090400@dei.unipd.it>

is there an encoder for dm6446 for ogg vorbis?

Ottavio

From nkansara at irvine-sensors.com  Tue Feb  2 10:41:49 2010
From: nkansara at irvine-sensors.com (Naresh Kansara)
Date: Tue, 2 Feb 2010 08:41:49 -0800
Subject: question on RAMDISK
In-Reply-To: <13bd74411002011906i35814725q9134931f0a206fee@mail.gmail.com>
References: <B4CC737B5C72E74A877F33104AD30A6002A8A6CA@excirvca2a.corp.irvine-sensors.com>
	<13bd74411002011906i35814725q9134931f0a206fee@mail.gmail.com>
Message-ID: <B4CC737B5C72E74A877F33104AD30A6002A8A7E5@excirvca2a.corp.irvine-sensors.com>

Hi kirthika,

Thank you for your response. From Kernel my RAMDISK size is 4M..
configuring RAMDISK size to 32M through setenv command works, but size
to 64M Fails. Once I get the DVEVM prompt, I issue a command

 

setenv bootargs mem=120M console=ttyS0,115200n8 root=/dev/ram0 rw
init=/bin/ash initrd=0x82000000,32M    -- after following normal
bootcmd, boots correctly

 

But the following procedure fails with message 

setenv bootargs mem=120M console=ttyS0,115200n8 root=/dev/ram0 rw
init=/bin/ash initrd=0x82000000,64M   -- After this I load the ramdisk
through

"loadb 0x82000000"  command through Kermit. After that when I try to 

"setenv bootcmd 'nboot 80700000 0 2060000; bootm'

"boot" Command

But this fails with message 

"Division by zero in kernel"

Any help will be highly appreciated. I need bigger size ramdisk, if
there is way to partition in two ramdisk also will work.

Thanks and Regards,

Naresh

Naresh Kansara

Irvine Sensors Corporation

phone: (714)-435-8928

email: nkansara at irvine-sensors.com

-----------------------------------------------------------

From: kirthika varadarajan [mailto:kirthikaiitm at gmail.com] 
Sent: Monday, February 01, 2010 7:07 PM
To: Naresh Kansara
Subject: Re: question on RAMDISK

 


Hi

  Please check out kernel configuration.

  

  Give   make menuconfig

                            Go to Device Drivers -> Block devices->
Default RAM Disk Size                  

Check out the size here.

 

 

On Tue, Feb 2, 2010 at 3:19 AM, Naresh Kansara
<nkansara at irvine-sensors.com> wrote:

Hello All,

I have two questions.

1.	Is there a limit of 32MB on Ramdisk? I tried to use 64MB size
and I got some errors
2.	Has anybody tried to use two RAMDISK? If yes how to use two
ramdisk?

 

Thank you for your help.

Regards,

Naresh

 

 

Naresh Kansara

Irvine Sensors Corporation

phone: (714)-435-8928

email: nkansara at irvine-sensors.com

 


_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100202/0dfd6cf2/attachment-0001.html>

From herbert.miao at gmail.com  Tue Feb  2 19:53:13 2010
From: herbert.miao at gmail.com (Herbert Miao)
Date: Wed, 3 Feb 2010 09:53:13 +0800
Subject: problem with u-boot on NAND memory with dm6446
In-Reply-To: <417827.66713.qm@web24102.mail.ird.yahoo.com>
References: <868c9e4f1001310639m77a1055h7d051c8e47aa1a7c@mail.gmail.com>
	<417827.66713.qm@web24102.mail.ird.yahoo.com>
Message-ID: <868c9e4f1002021753u10ec2c58w94b0725a59303b74@mail.gmail.com>

pls see
Is there nand flash driver ok on EVM6467?
i have post to davinci-linux-open-source at linux.davincidsp.com
and google search Using the "TMS320DM6467 DMSoC Bootloader"
Maybe this document can help u.
Sorry,there is no time for me to read the document and the uboot source code
now.
but i will do it in future.
good luck to u!
On 2 February 2010 14:38, rohan tabish <rohan_javed at yahoo.co.uk> wrote:

> Have you solved this problem i hav the same problem when i do
>
>
> nand erase 0x60000
>
> The u-boot stops working instead i am doing
>
> nand erase 0x100000 0x200000
>
> and flash my uImage here and it works fine
>
> Regard's
> RT
>
> --- On *Sun, 31/1/10, Herbert Miao <herbert.miao at gmail.com>* wrote:
>
>
> From: Herbert Miao <herbert.miao at gmail.com>
> Subject: Re: problem with u-boot on NAND memory with dm6446
> To: "Ottavio Campana" <ottavio.campana at dei.unipd.it>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Date: Sunday, 31 January, 2010, 19:39
>
>
> > > In any case I would assume that  after 0x60000 (i.e. 384k) no data
> would
> > > be present,  and by erasing it  nothing would happen. But  By erasing
> it
> > > u-boot stops working.
> > >
> > > The commands I give are:
> > >
> > > nand erase 0x00060000 0x00400000
> > > nand write 0x80700000 0x00060000 0x00400000
> > > reset
> > >
> >
> > Do you want to update u-boot from u-boot? I never tried that, I thought
> ubl
> > obb layout and u-boot layout are not compatiple.
> i have the same problem when i run "nand erase 0xa0000" on DM6467 and then
> uboot cannot work.
>
> On 29 January 2010 16:41, Ottavio Campana <ottavio.campana at dei.unipd.it<http://mc/compose?to=ottavio.campana at dei.unipd.it>
> > wrote:
>
>> On Tue, Jan 26, 2010 at 09:42:43AM +0200, Caglar Akyuz wrote:
>> > On Monday 25 January 2010 06:49:23 pm Ottavio Campana wrote:
>> > > I'm trying  to put u-boot on  a custom board  based on dm6446 in  a
>> NAND
>> > > memory.
>> > >
>> > > I find  some mismatches between  the montavista linux kernel  and
>> u-boot
>> > > 2009.11 .
>> > >
>> >
>> > Are they using the same ecc/oob layout? In the past(2.6.10 era), it is
>> known
>> > that u-boot montavista linux kernel do not use the same layout. Does
>> > montavista linux kernel suppose to work with u-boot 2009.11?
>>
>> mmm.. I don't know. By the way, I find a solution, I discovered that
>> u-boot 2009.11 and bootargs "live" in the first MB of the nand, thus as a
>> workaround I consider my nand divided into three parts: 1m of bootloader,
>> 4m for
>> the kernel and the rest for the rootfs.
>>
>> But I still dont' know where u-boot puts its stuf...
>>
>> > > Particularly,  in
>>  linux-2.6.18_pro500/arch/arm/mach-davinci/board-evm.c
>> > > the variable davinci_nand_partitions has 4 elements bootloader of
>> 265KB,
>> > > params 128K, kernel 4M and filesystem the rest of the memory.
>> > >
>> > > But  u-boot  2009.11 has  a  different  partitions layout  specified
>>  by
>> > > mtdparts=davinci_nand.0:384k(bootloader)ro,4m(kernel),-(filesystem)
>> > >
>> >
>> > Correct me if I'm wrong but this is a kernel command line parameter. It
>> has
>> > nothing to do with u-boot partitions. does u-boot even support nand
>> > partitions? By looking at the documentation at [1] I see it is just an
>> > interface to use dynamic partitioning feature of Linux.
>>
>> well, mtdparts seems to be hardcoded in the kernel. By passing the
>> variable
>> nothing changes.
>>
>> > > In any case I would assume that  after 0x60000 (i.e. 384k) no data
>> would
>> > > be present,  and by erasing it  nothing would happen. But  By erasing
>> it
>> > > u-boot stops working.
>> > >
>> > > The commands I give are:
>> > >
>> > > nand erase 0x00060000 0x00400000
>> > > nand write 0x80700000 0x00060000 0x00400000
>> > > reset
>> > >
>> >
>> > Do you want to update u-boot from u-boot? I never tried that, I thought
>> ubl
>> > obb layout and u-boot layout are not compatiple.
>>
>> no, just putting kernel and rootfs on the nand.
>>
>> In any case, it somehow works, I just would like now to understand what
>> u-boot
>> 2009.11 really does.
>>
>> Ottavio
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source at linux.davincidsp.com<http://mc/compose?to=Davinci-linux-open-source at linux.davincidsp.com>
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>>
>
>
> -----Inline Attachment Follows-----
>
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com<http://mc/compose?to=Davinci-linux-open-source at linux.davincidsp.com>
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100203/1b0b599f/attachment.html>

From rohan_javed at yahoo.co.uk  Wed Feb  3 00:12:37 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Tue, 2 Feb 2010 22:12:37 -0800 (PST)
Subject: PHY Detection problem in u-boot
Message-ID: <168167.42295.qm@web24105.mail.ird.yahoo.com>

Hello everyone we have made our own custom board with some revision DM6446.I have sucessfully ported the linux on that board using the open source git kernel but in our new board we have done revision.The PHY that we previously used was LAN 8700 now we have changed the PHY to LAN8710 but the PHY does not gets detected.

The ETH PHY driver in the u-boot is assumed to be generic so it should detect the PHY whenever it boots up it says GENERIC ETH PHY? @ 00.


Here is my u-boot log 

TI UBL Version: 1.31
Booting Catalog Boot Loader
BootMode = NAND
Starting NAND Copy...
Valid magicnum, 0xA1ACED66, found in block 0x00000006.
?? DONE
Jumping to entry point at 0x81080000.


U-Boot 2009.06-rc2 (Oct 15 2009 - 10:32:33)

I2C:?? ready
DRAM:? 256 MB
NAND:? 256 MiB
In:??? serial
Out:?? serial
Err:?? serial
ARM Clock: 297MHz
DDR Clock: 162MHz
Read from EEPROM @ 0x50 failed
Ethernet PHY: GENERIC @ 0x00
Hit any key to stop autoboot:? 0
U-Boot > mii
Usage:
mii - MII utility commands

U-Boot > help mii
mii device???????????????????? - list available devices
mii device <devname>?????????? - set current device
mii info?? <addr>????????????? - display MII PHY info
mii read?? <addr> <reg>??????? - read? MII PHY <addr> register <reg>
mii write? <addr> <reg> <data> - write MII PHY <addr> register <reg>
mii dump?? <addr> <reg>??????? - pretty-print <addr> <reg> (0-5 only)
Addr and/or reg may be ranges, e.g. 2-7.
U-Boot > mii write 2 2 2
U-Boot > mii read 2 2
Error reading from the PHY addr=02 reg=02
U-Boot > ping 172.16.0.90
WARN: emac_send_packet: No link

Do i need to add the support for the new PHY in u-boot what further modifications i will have to do in the kernel to Add the support for LAN 8710.


Regard's
RT



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100202/1cfdb2b1/attachment.html>

From stanley.miao at windriver.com  Wed Feb  3 00:55:11 2010
From: stanley.miao at windriver.com (stanley.miao)
Date: Wed, 03 Feb 2010 14:55:11 +0800
Subject: [PATCH RFC] OHCI: DA8xx/OMAP-L1x glue layer (take 3)
In-Reply-To: <200910022235.57188.sshtylyov@ru.mvista.com>
References: <200910022235.57188.sshtylyov@ru.mvista.com>
Message-ID: <4B691DCF.2050406@windriver.com>

Why was not this patch pushed to git tree ?

Stanley.

Sergei Shtylyov wrote:
> Texas Instruments DA8xx/OMAP-L1x OHCI glue layer.
>
> This OHCI implementation is not without quirks: there's only one physical port
> despite the root hub reporting two; the port's power control and over-current
> status bits are not connected to any pins, however, at least on the DA830 EVM
> board, those signals are connected via GPIO, thus the provision was made for
> overriding the OHCI port power and over-current bits at the board level...
>
> Signed-off-by: Mikhail Cherkashin <mcherkashin at ru.mvista.com>
> Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>
>
> ---
> WARNING: the MUSB and OHCI drivers will only work if your boot loader leaves
> the DA8xx boot configuration registers unlocked, otherwise they will lock up
> the kernel!
>
> The patch is against the recent DaVinci tree.
>
> Changes since the previous take:
> - moved declaration of the platform data to another patch (already committed
>   to the DaVinci tree now);
> - made use of DA8XX_SYSCFG_VIRT() macro instead of IO_ADDRESS();
> - started passing &pdev->dev to clk_get() for the USB 2.0 clock...
>
>  drivers/usb/Kconfig                      |    1 
>  drivers/usb/host/ohci-da8xx.c            |  456 +++++++++++++++++++++++++++++++
>  drivers/usb/host/ohci-hcd.c              |    5 
>  4 files changed, 482 insertions(+)
>
> Index: linux-davinci/drivers/usb/Kconfig
> ===================================================================
> --- linux-davinci.orig/drivers/usb/Kconfig
> +++ linux-davinci/drivers/usb/Kconfig
> @@ -39,6 +39,7 @@ config USB_ARCH_HAS_OHCI
>  	default y if ARCH_AT91
>  	default y if ARCH_PNX4008 && I2C
>  	default y if MFD_TC6393XB
> +	default y if ARCH_DAVINCI_DA8XX
>  	# PPC:
>  	default y if STB03xxx
>  	default y if PPC_MPC52xx
> Index: linux-davinci/drivers/usb/host/ohci-da8xx.c
> ===================================================================
> --- /dev/null
> +++ linux-davinci/drivers/usb/host/ohci-da8xx.c
> @@ -0,0 +1,456 @@
> +/*
> + * OHCI HCD (Host Controller Driver) for USB.
> + *
> + * TI DA8xx (OMAP-L1x) Bus Glue
> + *
> + * Derived from: ohci-omap.c and ohci-s3c2410.c
> + * Copyright (C) 2008-2009 MontaVista Software, Inc. <source at mvista.com>
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include <linux/interrupt.h>
> +#include <linux/jiffies.h>
> +#include <linux/platform_device.h>
> +#include <linux/clk.h>
> +
> +#include <mach/da8xx.h>
> +#include <mach/usb.h>
> +
> +#ifndef CONFIG_ARCH_DAVINCI_DA8XX
> +#error "This file is DA8xx bus glue.  Define CONFIG_ARCH_DAVINCI_DA8XX."
> +#endif
> +
> +#define CFGCHIP2	DA8XX_SYSCFG_VIRT(DA8XX_CFGCHIP2_REG)
> +
> +static struct clk *usb11_clk;
> +static struct clk *usb20_clk;
> +
> +/* Over-current indicator change bitmask */
> +static volatile u16 ocic_mask;
> +
> +static void ohci_da8xx_clock(int on)
> +{
> +	u32 cfgchip2;
> +
> +	cfgchip2 = __raw_readl(CFGCHIP2);
> +	if (on) {
> +		clk_enable(usb11_clk);
> +
> +		/*
> +		 * If USB 1.1 reference clock is sourced from USB 2.0 PHY, we
> +		 * need to enable the USB 2.0 module clocking, start its PHY,
> +		 * and not allow it to stop the clock during USB 2.0 suspend.
> +		 */
> +		if (!(cfgchip2 & CFGCHIP2_USB1PHYCLKMUX)) {
> +			clk_enable(usb20_clk);
> +
> +			cfgchip2 &= ~(CFGCHIP2_RESET | CFGCHIP2_PHYPWRDN);
> +			cfgchip2 |= CFGCHIP2_PHY_PLLON;
> +			__raw_writel(cfgchip2, CFGCHIP2);
> +
> +			pr_info("Waiting for USB PHY clock good...\n");
> +			while (!(__raw_readl(CFGCHIP2) & CFGCHIP2_PHYCLKGD))
> +				cpu_relax();
> +		}
> +
> +		/* Enable USB 1.1 PHY */
> +		cfgchip2 |= CFGCHIP2_USB1SUSPENDM;
> +	} else {
> +		clk_disable(usb11_clk);
> +		if (!(cfgchip2 & CFGCHIP2_USB1PHYCLKMUX))
> +			clk_disable(usb20_clk);
> +
> +		/* Disable USB 1.1 PHY */
> +		cfgchip2 &= ~CFGCHIP2_USB1SUSPENDM;
> +	}
> +	__raw_writel(cfgchip2, CFGCHIP2);
> +}
> +
> +/*
> + * Handle the port over-current indicator change.
> + */
> +static void ohci_da8xx_ocic_handler(struct da8xx_ohci_root_hub *hub,
> +				    unsigned port)
> +{
> +	ocic_mask |= 1 << port;
> +
> +	/* Once over-current is detected, the port needs to be powered down */
> +	if (hub->get_oci(port) > 0)
> +		hub->set_power(port, 0);
> +}
> +
> +static int ohci_da8xx_init(struct usb_hcd *hcd)
> +{
> +	struct device *dev		= hcd->self.controller;
> +	struct da8xx_ohci_root_hub *hub	= dev->platform_data;
> +	struct ohci_hcd	*ohci		= hcd_to_ohci(hcd);
> +	int result;
> +	u32 rh_a;
> +
> +	dev_dbg(dev, "starting USB controller\n");
> +
> +	ohci_da8xx_clock(1);
> +
> +	/*
> +	 * DA8xx only have 1 port connected to the pins but the HC root hub
> +	 * register A reports 2 ports, thus we'll have to override it...
> +	 */
> +	ohci->num_ports = 1;
> +
> +	result = ohci_init(ohci);
> +	if (result < 0)
> +		return result;
> +
> +	/*
> +	 * Since we're providing a board-specific root hub port power control
> +	 * and over-current reporting, we have to override the HC root hub A
> +	 * register's default value, so that ohci_hub_control() could return
> +	 * the correct hub descriptor...
> +	 */
> +	rh_a = ohci_readl(ohci, &ohci->regs->roothub.a);
> +	if (hub->set_power) {
> +		rh_a &= ~RH_A_NPS;
> +		rh_a |=  RH_A_PSM;
> +	}
> +	if (hub->get_oci) {
> +		rh_a &= ~RH_A_NOCP;
> +		rh_a |=  RH_A_OCPM;
> +	}
> +	rh_a &= ~RH_A_POTPGT;
> +	rh_a |= hub->potpgt << 24;
> +	ohci_writel(ohci, rh_a, &ohci->regs->roothub.a);
> +
> +	return result;
> +}
> +
> +static void ohci_da8xx_stop(struct usb_hcd *hcd)
> +{
> +	ohci_stop(hcd);
> +	ohci_da8xx_clock(0);
> +}
> +
> +static int ohci_da8xx_start(struct usb_hcd *hcd)
> +{
> +	struct ohci_hcd	*ohci		= hcd_to_ohci(hcd);
> +	int result;
> +
> +	result = ohci_run(ohci);
> +	if (result < 0)
> +		ohci_da8xx_stop(hcd);
> +
> +	return result;
> +}
> +
> +/*
> + * Update the status data from the hub with the over-current indicator change.
> + */
> +static int ohci_da8xx_hub_status_data(struct usb_hcd *hcd, char *buf)
> +{
> +	int length		= ohci_hub_status_data(hcd, buf);
> +
> +	/* See if we have OCIC bit set on port 1 */
> +	if (ocic_mask & (1 << 1)) {
> +		dev_dbg(hcd->self.controller, "over-current indicator change "
> +			"on port 1\n");
> +
> +		if (!length)
> +			length = 1;
> +
> +		buf[0] |= 1 << 1;
> +	}
> +	return length;
> +}
> +
> +/*
> + * Look at the control requests to the root hub and see if we need to override.
> + */
> +static int ohci_da8xx_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
> +				  u16 wIndex, char *buf, u16 wLength)
> +{
> +	struct device *dev		= hcd->self.controller;
> +	struct da8xx_ohci_root_hub *hub	= dev->platform_data;
> +	int temp;
> +
> +	switch (typeReq) {
> +	case GetPortStatus:
> +		/* Check the port number */
> +		if (wIndex != 1)
> +			break;
> +
> +		dev_dbg(dev, "GetPortStatus(%u)\n", wIndex);
> +
> +		temp = roothub_portstatus(hcd_to_ohci(hcd), wIndex - 1);
> +
> +		/* The port power status (PPS) bit defaults to 1 */
> +		if (hub->get_power && hub->get_power(wIndex) == 0)
> +			temp &= ~RH_PS_PPS;
> +
> +		/* The port over-current indicator (POCI) bit is always 0 */
> +		if (hub->get_oci && hub->get_oci(wIndex) > 0)
> +			temp |=  RH_PS_POCI;
> +
> +		/* The over-current indicator change (OCIC) bit is 0 too */
> +		if (ocic_mask & (1 << wIndex))
> +			temp |=  RH_PS_OCIC;
> +
> +		put_unaligned(cpu_to_le32(temp), (__le32 *)buf);
> +		return 0;
> +	case SetPortFeature:
> +		temp = 1;
> +		goto check_port;
> +	case ClearPortFeature:
> +		temp = 0;
> +
> +check_port:
> +		/* Check the port number */
> +		if (wIndex != 1)
> +			break;
> +
> +		switch (wValue) {
> +		case USB_PORT_FEAT_POWER:
> +			dev_dbg(dev, "%sPortFeature(%u): %s\n",
> +				temp ? "Set" : "Clear", wIndex, "POWER");
> +
> +			if (!hub->set_power)
> +				return -EPIPE;
> +
> +			return hub->set_power(wIndex, temp) ? -EPIPE : 0;
> +		case USB_PORT_FEAT_C_OVER_CURRENT:
> +			dev_dbg(dev, "%sPortFeature(%u): %s\n",
> +				temp ? "Set" : "Clear", wIndex,
> +				"C_OVER_CURRENT");
> +
> +			if (temp)
> +				ocic_mask |= 1 << wIndex;
> +			else
> +				ocic_mask &= ~(1 << wIndex);
> +			return 0;
> +		}
> +	}
> +
> +	return ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
> +}
> +
> +static const struct hc_driver ohci_da8xx_hc_driver = {
> +	.description		= hcd_name,
> +	.product_desc		= "DA8xx OHCI",
> +	.hcd_priv_size		= sizeof(struct ohci_hcd),
> +
> +	/*
> +	 * generic hardware linkage
> +	 */
> +	.irq			= ohci_irq,
> +	.flags			= HCD_USB11 | HCD_MEMORY,
> +
> +	/*
> +	 * basic lifecycle operations
> +	 */
> +	.reset			= ohci_da8xx_init,
> +	.start			= ohci_da8xx_start,
> +	.stop			= ohci_da8xx_stop,
> +	.shutdown		= ohci_shutdown,
> +
> +	/*
> +	 * managing i/o requests and associated device resources
> +	 */
> +	.urb_enqueue		= ohci_urb_enqueue,
> +	.urb_dequeue		= ohci_urb_dequeue,
> +	.endpoint_disable	= ohci_endpoint_disable,
> +
> +	/*
> +	 * scheduling support
> +	 */
> +	.get_frame_number	= ohci_get_frame,
> +
> +	/*
> +	 * root hub support
> +	 */
> +	.hub_status_data	= ohci_da8xx_hub_status_data,
> +	.hub_control		= ohci_da8xx_hub_control,
> +
> +#ifdef	CONFIG_PM
> +	.bus_suspend		= ohci_bus_suspend,
> +	.bus_resume		= ohci_bus_resume,
> +#endif
> +	.start_port_reset	= ohci_start_port_reset,
> +};
> +
> +/*-------------------------------------------------------------------------*/
> +
> +
> +/**
> + * usb_hcd_da8xx_probe - initialize DA8xx-based HCDs
> + * Context: !in_interrupt()
> + *
> + * Allocates basic resources for this USB host controller, and
> + * then invokes the start() method for the HCD associated with it
> + * through the hotplug entry's driver_data.
> + */
> +static int usb_hcd_da8xx_probe(const struct hc_driver *driver,
> +			       struct platform_device *pdev)
> +{
> +	struct da8xx_ohci_root_hub *hub	= pdev->dev.platform_data;
> +	struct usb_hcd	*hcd;
> +	struct resource *mem;
> +	int error, irq;
> +
> +	if (hub == NULL)
> +		return -ENODEV;
> +
> +	usb11_clk = clk_get(&pdev->dev, "usb11");
> +	if (IS_ERR(usb11_clk))
> +		return PTR_ERR(usb11_clk);
> +
> +	usb20_clk = clk_get(&pdev->dev, "usb20");
> +	if (IS_ERR(usb20_clk)) {
> +		error = PTR_ERR(usb20_clk);
> +		goto err0;
> +	}
> +
> +	hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
> +	if (!hcd) {
> +		error = -ENOMEM;
> +		goto err1;
> +	}
> +
> +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!mem) {
> +		error = -ENODEV;
> +		goto err2;
> +	}
> +	hcd->rsrc_start = mem->start;
> +	hcd->rsrc_len = mem->end - mem->start + 1;
> +
> +	if (!request_mem_region(hcd->rsrc_start, hcd->rsrc_len, hcd_name)) {
> +		dev_dbg(&pdev->dev, "request_mem_region failed\n");
> +		error = -EBUSY;
> +		goto err2;
> +	}
> +
> +	hcd->regs = ioremap(hcd->rsrc_start, hcd->rsrc_len);
> +	if (!hcd->regs) {
> +		dev_err(&pdev->dev, "ioremap failed\n");
> +		error = -ENOMEM;
> +		goto err3;
> +	}
> +
> +	ohci_hcd_init(hcd_to_ohci(hcd));
> +
> +	irq = platform_get_irq(pdev, 0);
> +	if (irq < 0) {
> +		error = -ENODEV;
> +		goto err4;
> +	}
> +	error = usb_add_hcd(hcd, irq, IRQF_DISABLED);
> +	if (error)
> +		goto err4;
> +
> +	if (hub->ocic_notify) {
> +		error = hub->ocic_notify(ohci_da8xx_ocic_handler);
> +		if (!error)
> +			return 0;
> +	}
> +
> +	usb_remove_hcd(hcd);
> +err4:
> +	iounmap(hcd->regs);
> +err3:
> +	release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
> +err2:
> +	usb_put_hcd(hcd);
> +err1:
> +	clk_put(usb20_clk);
> +err0:
> +	clk_put(usb11_clk);
> +	return error;
> +}
> +
> +/**
> + * usb_hcd_da8xx_remove - shutdown processing for DA8xx-based HCDs
> + * @dev: USB Host Controller being removed
> + * Context: !in_interrupt()
> + *
> + * Reverses the effect of usb_hcd_da8xx_probe(), first invoking
> + * the HCD's stop() method.  It is always called from a thread
> + * context, normally "rmmod", "apmd", or something similar.
> + */
> +static inline void
> +usb_hcd_da8xx_remove(struct usb_hcd *hcd, struct platform_device *pdev)
> +{
> +	struct da8xx_ohci_root_hub *hub	= pdev->dev.platform_data;
> +
> +	hub->ocic_notify(NULL);
> +	usb_remove_hcd(hcd);
> +	iounmap(hcd->regs);
> +	release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
> +	usb_put_hcd(hcd);
> +	clk_put(usb20_clk);
> +	clk_put(usb11_clk);
> +}
> +
> +static int ohci_hcd_da8xx_drv_probe(struct platform_device *dev)
> +{
> +	return usb_hcd_da8xx_probe(&ohci_da8xx_hc_driver, dev);
> +}
> +
> +static int ohci_hcd_da8xx_drv_remove(struct platform_device *dev)
> +{
> +	struct usb_hcd	*hcd = platform_get_drvdata(dev);
> +
> +	usb_hcd_da8xx_remove(hcd, dev);
> +	platform_set_drvdata(dev, NULL);
> +
> +	return 0;
> +}
> +
> +#ifdef CONFIG_PM
> +static int ohci_da8xx_suspend(struct platform_device *dev, pm_message_t message)
> +{
> +	struct usb_hcd	*hcd	= platform_get_drvdata(dev);
> +	struct ohci_hcd	*ohci	= hcd_to_ohci(hcd);
> +
> +	if (time_before(jiffies, ohci->next_statechange))
> +		msleep(5);
> +	ohci->next_statechange = jiffies;
> +
> +	ohci_da8xx_clock(0);
> +	hcd->state = HC_STATE_SUSPENDED;
> +	dev->dev.power.power_state = PMSG_SUSPEND;
> +	return 0;
> +}
> +
> +static int ohci_da8xx_resume(struct platform_device *dev)
> +{
> +	struct usb_hcd	*hcd	= platform_get_drvdata(dev);
> +	struct ohci_hcd	*ohci	= hcd_to_ohci(hcd);
> +
> +	if (time_before(jiffies, ohci->next_statechange))
> +		msleep(5);
> +	ohci->next_statechange = jiffies;
> +
> +	ohci_da8xx_clock(1);
> +	dev->dev.power.power_state = PMSG_ON;
> +	usb_hcd_resume_root_hub(hcd);
> +	return 0;
> +}
> +#endif
> +
> +/*
> + * Driver definition to register with platform structure.
> + */
> +static struct platform_driver ohci_hcd_da8xx_driver = {
> +	.probe		= ohci_hcd_da8xx_drv_probe,
> +	.remove		= ohci_hcd_da8xx_drv_remove,
> +	.shutdown 	= usb_hcd_platform_shutdown,
> +#ifdef	CONFIG_PM
> +	.suspend	= ohci_da8xx_suspend,
> +	.resume		= ohci_da8xx_resume,
> +#endif
> +	.driver		= {
> +		.owner	= THIS_MODULE,
> +		.name	= "ohci",
> +	},
> +};
> Index: linux-davinci/drivers/usb/host/ohci-hcd.c
> ===================================================================
> --- linux-davinci.orig/drivers/usb/host/ohci-hcd.c
> +++ linux-davinci/drivers/usb/host/ohci-hcd.c
> @@ -1047,6 +1047,11 @@ MODULE_LICENSE ("GPL");
>  #define PLATFORM_DRIVER		usb_hcd_pnx4008_driver
>  #endif
>  
> +#ifdef CONFIG_ARCH_DAVINCI_DA8XX
> +#include "ohci-da8xx.c"
> +#define PLATFORM_DRIVER		ohci_hcd_da8xx_driver
> +#endif
> +
>  #if defined(CONFIG_CPU_SUBTYPE_SH7720) || \
>      defined(CONFIG_CPU_SUBTYPE_SH7721) || \
>      defined(CONFIG_CPU_SUBTYPE_SH7763) || \
>
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>   


From e_gouds at yahoo.co.in  Thu Feb  4 00:19:08 2010
From: e_gouds at yahoo.co.in (ragha vendra)
Date: Thu, 4 Feb 2010 11:49:08 +0530 (IST)
Subject: urgent...Gstreamer video issue
Message-ID: <67348.51757.qm@web8313.mail.in.yahoo.com>

hi,

? ? I am new to gstreamer framewok I tried to run videos on dm6467 when i tried to play 

video files video are

stoping(hanging )at different places like middle of video? or starting of video or it

play till end of file .I? used --gst-debug=*:5 but i did not get any error messages and

whenever video hangs the target do not accept any commands it needs restart again.

?environment:

?montavista 5.0

?dvsdk 2.0

?dm6467

?gstreamer 0.10.21.

using command line:



gst-launch? filesrc location=./file.mp4 ! qtdemux name=demux demux.audio_00 ! queue

max-size-buffers=8000 max-size-time=0 max-size-bytes=0 !? TIAuddec1 codecName=aachedec

engineName=decode? !? alsassink demux.video_00 ! queue max-size-buffers=0 max-size-time=0

max-size-bytes=2097152 ! TIViddec2 codecName=h264dec engineName=decode

genTimeStamps=FALSE !? queue max-size-buffers=2 max-size-time=0 max-size-bytes=0 !

TIDmaiVideoSink videoStd=D1_NTSC? videoOutput=composite displayStd=v4l2

displayDevice=/dev/video2 resizer=FALSE? accelFrameCopy=TRUE



? ?when i play dvsdk decode demos? it playing fine.What is the problem in

gstreamer.Thanks in advance.

Thanks,

Raghav



'


      Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100204/403d1a05/attachment.html>

From bjorn.forsman at gmail.com  Thu Feb  4 00:43:24 2010
From: bjorn.forsman at gmail.com (=?UTF-8?Q?Bj=C3=B8rn_Forsman?=)
Date: Thu, 4 Feb 2010 07:43:24 +0100
Subject: ogg vorbis encoder for dm6446
In-Reply-To: <4B6853E5.3090400@dei.unipd.it>
References: <4B6853E5.3090400@dei.unipd.it>
Message-ID: <5f2b61002032243p19c2e1a5rd6bd31a9cdd75e47@mail.gmail.com>

Hi Ottavio,

On 2 February 2010 17:33, Ottavio Campana <ottavio.campana at dei.unipd.it> wrote:
> is there an encoder for dm6446 for ogg vorbis?

Yes, you can use GStreamer to get ogg/vorbis support on the DM6446.
This codec only runs on the ARM GPP, no DSP.

Best regards,
Bj?rn Forsman

From tarkandogu at gmail.com  Thu Feb  4 03:10:35 2010
From: tarkandogu at gmail.com (Tarkan DOGU)
Date: Thu, 4 Feb 2010 11:10:35 +0200
Subject: "gstreamer" play delay.
Message-ID: <bb0fe03d1002040110w9ebd461s8f1c83c88e69d5b4@mail.gmail.com>

Dear All,

I have encountered a problem while using "gstreamer" on Davinci 6446 board.
There is a min 4 sec and  max. 7 sec. delay before playing the video.
My streams are MPEG4,MPEG2 coded.
I also attached my script below. Is there something wrong during the
execution of the script?
Delay should be less than 1 sec. for a consumer application.
Any ideas or solutions?


Thanks in  advance...
B.R
Tarkan

The script that we have already using to play MPEG4 video files.

FBSINK="TIDmaiVideoSink accelFrameCopy=${ACCEL} videoStd=D1_NTSC
displayDevice=/dev/fb3 displayStd=FBDev resizer=${RESIZER} framerate=10"

    gst-launch \
        filesrc location=$2 ! avidemux name=demux \
        demux.video_00 ! \
        TIViddec2 codecName=mpeg4dec engineName=decode genTimeStamps=true !
\
        $FBSINK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100204/874cb3c8/attachment.html>

From ti.appro at borea.com  Thu Feb  4 03:17:27 2010
From: ti.appro at borea.com (Yves LE HENAFF)
Date: Thu, 04 Feb 2010 10:17:27 +0100
Subject: Strange delay for RBL on DM355
Message-ID: <4B6A90A7.7010809@borea.com>


Hi,

We've have a design where a DM355 needs to initialize very quickly some 
IOs while powered ON.  We have critical peripherals controled in UBL to 
get a very early set-up.

Unfortunately, it seems the DM355 spends 310ms -before- calling UBL 
after reset is removed !  (Measured on GPIO061 controlled by RBL : 
raising just before jump to UBL address. Our UBL is in NAND with the 
right "00" Bootsel bits).

At the beginning of UBL only 290us is required to load prescalers and 
basic hardware registers.
The full UBL execution, with PLL and ECC config, takes only ~80ms to 
load uboot in DDR2 and jump to it. Which is rather short.

So we expected RBL to be in the 500us range, not 310ms ....

I don't understand a such delay. Any explanation / idea ?

Best regards.
Yves LE HENAFF.

From krunal.patil at einfochips.com  Thu Feb  4 12:44:42 2010
From: krunal.patil at einfochips.com (Krunal Patil)
Date: Fri, 5 Feb 2010 00:14:42 +0530 (IST)
Subject: Need fix for TS/RX issue using USB on DM355.
Message-ID: <4027.123.237.98.127.1265309082.squirrel@indiamail.einfochips.com>




Hello Friends,

I looked at the?cocurrent Tx/Rx issue using USB on
DM355 in mail archive. I am facing similar kind of issue with my system. Can
anyone please provide me patch 45 which has fix for this problem? I am using MVL
2.6.10





-- 

Regards, 

Krunal Patil?





-- 
_____________________________________________________________________
Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution, copying, or other use of
this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
replying to this message and please delete it from your computer. Any
views expressed in this message are those of the individual sender
unless otherwise stated.Company has taken enough precautions to prevent
the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email.
_____________________________________________________________________
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100205/dcd7ea0b/attachment.html>

From khilman at deeprootsystems.com  Thu Feb  4 15:32:39 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 04 Feb 2010 13:32:39 -0800
Subject: [PATCH v3 6/6] DaVinci - Adding platform & board changes for vpfe
	capture on DM365
In-Reply-To: <1265063933-2425-1-git-send-email-m-karicheri2@ti.com>
	(m-karicheri2@ti.com's message of "Mon\,
	1 Feb 2010 17\:38\:53 -0500")
References: <1265063933-2425-1-git-send-email-m-karicheri2@ti.com>
Message-ID: <877hqs3cw8.fsf@deeprootsystems.com>

m-karicheri2 at ti.com writes:

> From: Murali Karicheri <m-karicheri2 at ti.com>
>
> This patch adds following changes:-
> 	1) add sub device configuration data for TVP5146 used by vpfe capture
> 	2) registers platform devices for vpfe_capture, isif and vpss
> 	3) defines hardware resources for the devices listed under 2)
> 	4) defines clock aliase for isif driver
> 	5) adding setup_pinmux() for isif
>
> Reviewed-by: Kevin Hilman <khilman at deeprootsystems.com>
> Signed-off-by: Murali Karicheri <m-karicheri2 at ti.com>

Signed-off-by: Kevin Hilman <khilman at deeprootsystems.com>

Mauro, please go ahead and merge this via your tree along with the
rest of the series.

Thanks,

Kevin


> ---
> Applies to linux-next of v4l-dvb
>  - removing some white spaces and re-resending........
>  - updated to add clock aliase (v3) and rebased to latest for merge
>  - review comments incorporated (v2)
>  arch/arm/mach-davinci/board-dm365-evm.c    |   71 +++++++++++++++++++
>  arch/arm/mach-davinci/dm365.c              |  102 +++++++++++++++++++++++++++-
>  arch/arm/mach-davinci/include/mach/dm365.h |    2 +
>  3 files changed, 174 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
> index b476395..38e9033 100644
> --- a/arch/arm/mach-davinci/board-dm365-evm.c
> +++ b/arch/arm/mach-davinci/board-dm365-evm.c
> @@ -37,6 +37,8 @@
>  #include <mach/nand.h>
>  #include <mach/keyscan.h>
>  
> +#include <media/tvp514x.h>
> +
>  static inline int have_imager(void)
>  {
>  	/* REVISIT when it's supported, trigger via Kconfig */
> @@ -306,6 +308,73 @@ static void dm365evm_mmc_configure(void)
>  	davinci_cfg_reg(DM365_SD1_DATA0);
>  }
>  
> +static struct tvp514x_platform_data tvp5146_pdata = {
> +	.clk_polarity = 0,
> +	.hs_polarity = 1,
> +	.vs_polarity = 1
> +};
> +
> +#define TVP514X_STD_ALL        (V4L2_STD_NTSC | V4L2_STD_PAL)
> +/* Inputs available at the TVP5146 */
> +static struct v4l2_input tvp5146_inputs[] = {
> +	{
> +		.index = 0,
> +		.name = "Composite",
> +		.type = V4L2_INPUT_TYPE_CAMERA,
> +		.std = TVP514X_STD_ALL,
> +	},
> +	{
> +		.index = 1,
> +		.name = "S-Video",
> +		.type = V4L2_INPUT_TYPE_CAMERA,
> +		.std = TVP514X_STD_ALL,
> +	},
> +};
> +
> +/*
> + * this is the route info for connecting each input to decoder
> + * ouput that goes to vpfe. There is a one to one correspondence
> + * with tvp5146_inputs
> + */
> +static struct vpfe_route tvp5146_routes[] = {
> +	{
> +		.input = INPUT_CVBS_VI2B,
> +		.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
> +	},
> +{
> +		.input = INPUT_SVIDEO_VI2C_VI1C,
> +		.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
> +	},
> +};
> +
> +static struct vpfe_subdev_info vpfe_sub_devs[] = {
> +	{
> +		.name = "tvp5146",
> +		.grp_id = 0,
> +		.num_inputs = ARRAY_SIZE(tvp5146_inputs),
> +		.inputs = tvp5146_inputs,
> +		.routes = tvp5146_routes,
> +		.can_route = 1,
> +		.ccdc_if_params = {
> +			.if_type = VPFE_BT656,
> +			.hdpol = VPFE_PINPOL_POSITIVE,
> +			.vdpol = VPFE_PINPOL_POSITIVE,
> +		},
> +		.board_info = {
> +			I2C_BOARD_INFO("tvp5146", 0x5d),
> +			.platform_data = &tvp5146_pdata,
> +		},
> +	},
> +};
> +
> +static struct vpfe_config vpfe_cfg = {
> +	.num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
> +	.sub_devs = vpfe_sub_devs,
> +	.i2c_adapter_id = 1,
> +	.card_name = "DM365 EVM",
> +	.ccdc = "ISIF",
> +};
> +
>  static void __init evm_init_i2c(void)
>  {
>  	davinci_init_i2c(&i2c_pdata);
> @@ -497,6 +566,8 @@ static struct davinci_uart_config uart_config __initdata = {
>  
>  static void __init dm365_evm_map_io(void)
>  {
> +	/* setup input configuration for VPFE input devices */
> +	dm365_set_vpfe_config(&vpfe_cfg);
>  	dm365_init();
>  }
>  
> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index f53735c..ce9da43 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -1008,6 +1008,97 @@ void __init dm365_init(void)
>  	davinci_common_init(&davinci_soc_info_dm365);
>  }
>  
> +static struct resource dm365_vpss_resources[] = {
> +	{
> +		/* VPSS ISP5 Base address */
> +		.name           = "isp5",
> +		.start          = 0x01c70000,
> +		.end            = 0x01c70000 + 0xff,
> +		.flags          = IORESOURCE_MEM,
> +	},
> +	{
> +		/* VPSS CLK Base address */
> +		.name           = "vpss",
> +		.start          = 0x01c70200,
> +		.end            = 0x01c70200 + 0xff,
> +		.flags          = IORESOURCE_MEM,
> +	},
> +};
> +
> +static struct platform_device dm365_vpss_device = {
> +       .name                   = "vpss",
> +       .id                     = -1,
> +       .dev.platform_data      = "dm365_vpss",
> +       .num_resources          = ARRAY_SIZE(dm365_vpss_resources),
> +       .resource               = dm365_vpss_resources,
> +};
> +
> +static struct resource vpfe_resources[] = {
> +	{
> +		.start          = IRQ_VDINT0,
> +		.end            = IRQ_VDINT0,
> +		.flags          = IORESOURCE_IRQ,
> +	},
> +	{
> +		.start          = IRQ_VDINT1,
> +		.end            = IRQ_VDINT1,
> +		.flags          = IORESOURCE_IRQ,
> +	},
> +};
> +
> +static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
> +static struct platform_device vpfe_capture_dev = {
> +	.name           = CAPTURE_DRV_NAME,
> +	.id             = -1,
> +	.num_resources  = ARRAY_SIZE(vpfe_resources),
> +	.resource       = vpfe_resources,
> +	.dev = {
> +		.dma_mask               = &vpfe_capture_dma_mask,
> +		.coherent_dma_mask      = DMA_BIT_MASK(32),
> +	},
> +};
> +
> +static void dm365_isif_setup_pinmux(void)
> +{
> +	davinci_cfg_reg(DM365_VIN_CAM_WEN);
> +	davinci_cfg_reg(DM365_VIN_CAM_VD);
> +	davinci_cfg_reg(DM365_VIN_CAM_HD);
> +	davinci_cfg_reg(DM365_VIN_YIN4_7_EN);
> +	davinci_cfg_reg(DM365_VIN_YIN0_3_EN);
> +}
> +
> +static struct resource isif_resource[] = {
> +	/* ISIF Base address */
> +	{
> +		.start          = 0x01c71000,
> +		.end            = 0x01c71000 + 0x1ff,
> +		.flags          = IORESOURCE_MEM,
> +	},
> +	/* ISIF Linearization table 0 */
> +	{
> +		.start          = 0x1C7C000,
> +		.end            = 0x1C7C000 + 0x2ff,
> +		.flags          = IORESOURCE_MEM,
> +	},
> +	/* ISIF Linearization table 1 */
> +	{
> +		.start          = 0x1C7C400,
> +		.end            = 0x1C7C400 + 0x2ff,
> +		.flags          = IORESOURCE_MEM,
> +	},
> +};
> +static struct platform_device dm365_isif_dev = {
> +	.name           = "isif",
> +	.id             = -1,
> +	.num_resources  = ARRAY_SIZE(isif_resource),
> +	.resource       = isif_resource,
> +	.dev = {
> +		.dma_mask               = &vpfe_capture_dma_mask,
> +		.coherent_dma_mask      = DMA_BIT_MASK(32),
> +		.platform_data		= dm365_isif_setup_pinmux,
> +	},
> +};
> +
>  static int __init dm365_init_devices(void)
>  {
>  	if (!cpu_is_davinci_dm365())
> @@ -1016,7 +1107,16 @@ static int __init dm365_init_devices(void)
>  	davinci_cfg_reg(DM365_INT_EDMA_CC);
>  	platform_device_register(&dm365_edma_device);
>  	platform_device_register(&dm365_emac_device);
> -
> +	/* Add isif clock alias */
> +	clk_add_alias("master", dm365_isif_dev.name, "vpss_master", NULL);
> +	platform_device_register(&dm365_vpss_device);
> +	platform_device_register(&dm365_isif_dev);
> +	platform_device_register(&vpfe_capture_dev);
>  	return 0;
>  }
>  postcore_initcall(dm365_init_devices);
> +
> +void dm365_set_vpfe_config(struct vpfe_config *cfg)
> +{
> +       vpfe_capture_dev.dev.platform_data = cfg;
> +}
> diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h
> index f1710a3..9fc5a64 100644
> --- a/arch/arm/mach-davinci/include/mach/dm365.h
> +++ b/arch/arm/mach-davinci/include/mach/dm365.h
> @@ -18,6 +18,7 @@
>  #include <mach/emac.h>
>  #include <mach/asp.h>
>  #include <mach/keyscan.h>
> +#include <media/davinci/vpfe_capture.h>
>  
>  #define DM365_EMAC_BASE			(0x01D07000)
>  #define DM365_EMAC_CNTRL_OFFSET		(0x0000)
> @@ -36,4 +37,5 @@ void __init dm365_init_asp(struct snd_platform_data *pdata);
>  void __init dm365_init_ks(struct davinci_ks_platform_data *pdata);
>  void __init dm365_init_rtc(void);
>  
> +void dm365_set_vpfe_config(struct vpfe_config *cfg);
>  #endif /* __ASM_ARCH_DM365_H */
> -- 
> 1.6.0.4

From jaya.krishnan at samsung.com  Thu Feb  4 20:05:50 2010
From: jaya.krishnan at samsung.com (Jaya krishnan)
Date: Fri, 05 Feb 2010 02:05:50 +0000 (GMT)
Subject: DM6467 component out-NO SYNC
Message-ID: <15905854.311851265335550749.JavaMail.weblogic@epml21>

Yes. Dumped streams work correctly on software  palyers. Also ffmpeg is able to convert it to avi file.
I am using  component   mode in display, which  works well  for  other  streams. It seems the VPIF  is  not able  to output  proper BT1120 streams, and
hence this  artifact. But  what  causes this , is intriguing, as other streams  of  same  resolution (704x480)  is displayed correctly.
There  is no issue  with  the  decoder.(I am using  TI's  multichannel decoder).
Regards
JK


 
 

------- Original Message -------
Sender : Jadav, Brijesh R<brijesh.j at ti.com>
Date   : Feb 02, 2010 22:34 (GMT+09:00)
Title  : RE: DM6467 component out-NO SYNC

Hi,

Are you saying Dumped decoded streams works correctly on software players? If it works, I think there is some timing parameters mismatch. 

Which mode are you using for the display? Does your TV support the mode you are trying to display?

Thanks,
Brijesh Jadav


-----Original Message-----
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Jaya krishnan
Sent: Friday, January 22, 2010 7:36 AM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: DM6467 component out-NO SYNC

I am  working  on an   application based  on DM6467. I need  to display  the H264 decoded  stream on a component display.
The display is not  steady, in the  sense that it  scrolls vertically often, and  the  display equipment   shows  a NO SYNC sign at that  time. I understand that the 
the problem is  due to lack of SYNC  signal. But why this  happens only to this  stream? The  stream can be decoded and  displayed in software players.
Any  help   would be greatly appreciated.
Thanks & regards
JK

 
   Jayakrishnan M M
Research Engineer
Key Systems Development Group
Security & Imaging             Solutions Division
SAMSUNG TECHWIN CO.,LTD

TEL +82-2-3467-7403
FAX +82-2-3467-7316
Mobile +82-10-6409-3619
E-mail:jaya.krishnan at samsung.com            
 
  
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

 
   Jayakrishnan M M
Research Engineer
Key Systems Development Group
Security & Imaging             Solutions Division
SAMSUNG TECHWIN CO.,LTD

TEL +82-2-3467-7403
FAX +82-2-3467-7316
Mobile +82-10-6409-3619
E-mail:jaya.krishnan at samsung.com            
 
  
 
 

From rekha.nimmakayala at gmail.com  Fri Feb  5 00:10:00 2010
From: rekha.nimmakayala at gmail.com (rekha devi)
Date: Fri, 5 Feb 2010 11:40:00 +0530
Subject: THS8200 driver integration
Message-ID: <4201738d1002042210k4615b781m2889775399d974ce@mail.gmail.com>

Hi

I am new to driver tech.
currently we are using TFP410 for DVI output. now we have selected
THS8200 for VGA output. For above modification i want to configure
ths8200 through i2c.
May i know any more information(links aor any.....) and any reference
sample code for THS8200 driver.
I tried to get sample code for ths8200_encoder .c etc related files.
But i couldnt get any full information.Please anyone can u guide me.

Thanks in advance.
Rekha

From ottavio.campana at dei.unipd.it  Fri Feb  5 02:09:15 2010
From: ottavio.campana at dei.unipd.it (Ottavio Campana)
Date: Fri, 5 Feb 2010 09:09:15 +0100
Subject: ogg vorbis encoder for dm6446
In-Reply-To: <5f2b61002032243p19c2e1a5rd6bd31a9cdd75e47@mail.gmail.com>
References: <4B6853E5.3090400@dei.unipd.it>
	<5f2b61002032243p19c2e1a5rd6bd31a9cdd75e47@mail.gmail.com>
Message-ID: <20100205080915.GA11788@dei.unipd.it>

On Thu, Feb 04, 2010 at 07:43:24AM +0100, Bj?rn Forsman wrote:
> Hi Ottavio,
> 
> On 2 February 2010 17:33, Ottavio Campana <ottavio.campana at dei.unipd.it> wrote:
> > is there an encoder for dm6446 for ogg vorbis?
> 
> Yes, you can use GStreamer to get ogg/vorbis support on the DM6446.
> This codec only runs on the ARM GPP, no DSP.

what is the performance running on the GPP? I mean, can I get PAL or NTSC?

From pan at nt.tu-darmstadt.de  Fri Feb  5 02:12:12 2010
From: pan at nt.tu-darmstadt.de (Vladimir Pantelic)
Date: Fri, 05 Feb 2010 09:12:12 +0100
Subject: ogg vorbis encoder for dm6446
In-Reply-To: <20100205080915.GA11788@dei.unipd.it>
References: <4B6853E5.3090400@dei.unipd.it>	<5f2b61002032243p19c2e1a5rd6bd31a9cdd75e47@mail.gmail.com>
	<20100205080915.GA11788@dei.unipd.it>
Message-ID: <4B6BD2DC.7060708@nt.tu-darmstadt.de>

Ottavio Campana wrote:
> On Thu, Feb 04, 2010 at 07:43:24AM +0100, Bj?rn Forsman wrote:
>>  Hi Ottavio,
>>
>>  On 2 February 2010 17:33, Ottavio Campana<ottavio.campana at dei.unipd.it>  wrote:
>>  >  is there an encoder for dm6446 for ogg vorbis?
>>
>>  Yes, you can use GStreamer to get ogg/vorbis support on the DM6446.
>>  This codec only runs on the ARM GPP, no DSP.
>
> what is the performance running on the GPP? I mean, can I get PAL or NTSC?

err, vorbis is an audio codec, no?



From rekha.nimmakayala at gmail.com  Fri Feb  5 03:10:44 2010
From: rekha.nimmakayala at gmail.com (rekha devi)
Date: Fri, 5 Feb 2010 14:40:44 +0530
Subject: THS8200 driver integration
In-Reply-To: <4201738d1002042210k4615b781m2889775399d974ce@mail.gmail.com>
References: <4201738d1002042210k4615b781m2889775399d974ce@mail.gmail.com>
Message-ID: <4201738d1002050110i135048d5p2b5de0e45770cff9@mail.gmail.com>

Hi

I am new to driver tech.
currently we are using TFP410 for DVI output. now we have selected
THS8200 for VGA output. For above modification i want to configure
ths8200 through i2c.
May i know any more information(links aor any.....) and any reference
sample code for THS8200 driver.
I tried to get sample code for ths8200_encoder .c etc related files.
But i couldnt get any full information.Please anyone can u guide me.

Thanks in advance.
Rekha

From yuvraj.pasi at nextbitcpu.com  Fri Feb  5 06:21:02 2010
From: yuvraj.pasi at nextbitcpu.com (Yuvraj Pasi)
Date: Fri, 5 Feb 2010 17:51:02 +0530
Subject: davinci resizer output quality is bad
Message-ID: <d448eead1002050421w6074469ej5eec4c14d5782c12@mail.gmail.com>

Hi,
We are using our custom made board with DM6446 on which i am  resizing an
composite input image 720x576 to 192x160.
My problem is that the output quality is very bad. i am not seeing that
problem when i try to resize a smaller image to larger
size the quality of image is ok but whenever i am resizing larger image to
smaller size the quality of image degrades????
Any suggestions...

-- 
Thanks & regards
yuvraj pasi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100205/5821f5ad/attachment.html>

From brijesh.j at ti.com  Fri Feb  5 06:26:01 2010
From: brijesh.j at ti.com (Jadav, Brijesh R)
Date: Fri, 5 Feb 2010 17:56:01 +0530
Subject: davinci resizer output quality is bad
In-Reply-To: <d448eead1002050421w6074469ej5eec4c14d5782c12@mail.gmail.com>
References: <d448eead1002050421w6074469ej5eec4c14d5782c12@mail.gmail.com>
Message-ID: <19F8576C6E063C45BE387C64729E7394044A776167@dbde02.ent.ti.com>

Are you changing scalar coefficients for downscaling?

Thanks,
Brijesh Jadav



________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Yuvraj Pasi
Sent: Friday, February 05, 2010 5:51 PM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: davinci resizer output quality is bad

Hi,
We are using our custom made board with DM6446 on which i am  resizing an composite input image 720x576 to 192x160.
My problem is that the output quality is very bad. i am not seeing that problem when i try to resize a smaller image to larger
size the quality of image is ok but whenever i am resizing larger image to smaller size the quality of image degrades????
Any suggestions...

--
Thanks & regards
yuvraj pasi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100205/f1f6fbcd/attachment.html>

From yuvraj.pasi at nextbitcpu.com  Fri Feb  5 07:07:14 2010
From: yuvraj.pasi at nextbitcpu.com (Yuvraj Pasi)
Date: Fri, 5 Feb 2010 18:37:14 +0530
Subject: davinci resizer output quality is bad
In-Reply-To: <19F8576C6E063C45BE387C64729E7394044A776167@dbde02.ent.ti.com>
References: <d448eead1002050421w6074469ej5eec4c14d5782c12@mail.gmail.com>
	<19F8576C6E063C45BE387C64729E7394044A776167@dbde02.ent.ti.com>
Message-ID: <d448eead1002050507s548af3cbi9d096de28d8882b4@mail.gmail.com>

Hi,
I have no idea wat that is . I am using the Resize_ API from the DMAI
Interface as it is.
& i'm using the default resizer attributes. given in the resize.c file i.e.
const Resize_Attrs Resize_Attrs_DEFAULT = {
    Resize_FilterType_LOWPASS,
    Resize_FilterType_LOWPASS,
    Resize_WindowType_BLACKMAN,
    Resize_WindowType_BLACKMAN,
    0xe
};


On Fri, Feb 5, 2010 at 5:56 PM, Jadav, Brijesh R <brijesh.j at ti.com> wrote:

>  Are you changing scalar coefficients for downscaling?
>
>
>
> Thanks,
>
> Brijesh Jadav
>
>
>
>
>
>
>  ------------------------------
>
> *From:* davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:
> davinci-linux-open-source-bounces at linux.davincidsp.com] *On Behalf Of *Yuvraj
> Pasi
> *Sent:* Friday, February 05, 2010 5:51 PM
> *To:* davinci-linux-open-source at linux.davincidsp.com
> *Subject:* davinci resizer output quality is bad
>
>
>
> Hi,
> We are using our custom made board with DM6446 on which i am  resizing an
> composite input image 720x576 to 192x160.
> My problem is that the output quality is very bad. i am not seeing that
> problem when i try to resize a smaller image to larger
> size the quality of image is ok but whenever i am resizing larger image to
> smaller size the quality of image degrades????
> Any suggestions...
>
> --
> Thanks & regards
> yuvraj pasi
>



-- 
Thanks & regards
yuvraj pasi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100205/c57d326a/attachment.html>

From pjohn at mvista.com  Fri Feb  5 07:53:43 2010
From: pjohn at mvista.com (Philby John)
Date: Fri, 5 Feb 2010 19:23:43 +0530
Subject: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E235A3C2@dbde02.ent.ti.com>
References: <1264549293-25556-1-git-send-email-khilman@deeprootsystems.com>
	<1264549293-25556-7-git-send-email-khilman@deeprootsystems.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E235A3C2@dbde02.ent.ti.com>
Message-ID: <225d086e1002050553tc1a696avce827cc115f56b1c@mail.gmail.com>

Hello Sekhar,

My apologies for the late mail. Had trouble with our mail server and I
seem to have lost mails. Pulling this thread from the list. Comments
inline...


On Mon, Feb 1, 2010 at 11:27 AM, Nori, Sekhar <nsekhar at ti.com> wrote:
> Hi Philby,
>
> On Wed, Jan 27, 2010 at 05:11:33, Kevin Hilman wrote:
>> From: Philby John <pjohn at in.mvista.com>
>>
>> Come out of i2c time out condition by following the
>> bus recovery procedure outlined in the i2c protocol v3 spec.
>> The kernel must be robust enough to gracefully recover
>> from i2c bus failure without having to reset the machine.
>> This is done by first NACKing the slave, pulsing the SCL
>> line 9 times and then sending the stop command.
>>
>> This patch has been tested on a DM6446 and DM355
>>
>> Signed-off-by: Philby John <pjohn at in.mvista.com>
>> Signed-off-by: Srinivasan, Nageswari <nageswari at ti.com>
>> Acked-by: Kevin Hilman <khilman at deeprootsystems.com>
>> ---
>> ?drivers/i2c/busses/i2c-davinci.c | ? 57 +++++++++++++++++++++++++++++++++++--
>> ?1 files changed, 53 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
>> index 35f9daa..5459065 100644
>> --- a/drivers/i2c/busses/i2c-davinci.c
>> +++ b/drivers/i2c/busses/i2c-davinci.c
>> @@ -36,6 +36,7 @@
>> ?#include <linux/platform_device.h>
>> ?#include <linux/io.h>
>> ?#include <linux/cpufreq.h>
>> +#include <linux/gpio.h>
>>
>> ?#include <mach/hardware.h>
>> ?#include <mach/i2c.h>
>> @@ -43,6 +44,7 @@
>> ?/* ----- global defines ----------------------------------------------- */
>>
>> ?#define DAVINCI_I2C_TIMEOUT ?(1*HZ)
>> +#define DAVINCI_I2C_MAX_TRIES ? ? ? ?2
>> ?#define I2C_DAVINCI_INTR_ALL ? ?(DAVINCI_I2C_IMR_AAS | \
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?DAVINCI_I2C_IMR_SCD | \
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?DAVINCI_I2C_IMR_ARDY | \
>> @@ -130,6 +132,44 @@ static inline u16 davinci_i2c_read_reg(struct davinci_i2c_dev *i2c_dev, int reg)
>> ? ? ? return __raw_readw(i2c_dev->base + reg);
>> ?}
>>
>> +/* Generate a pulse on the i2c clock pin. */
>> +static void generic_i2c_clock_pulse(unsigned int scl_pin)
>> +{
>> + ? ? u16 i;
>> +
>> + ? ? if (scl_pin) {
>> + ? ? ? ? ? ? /* Send high and low on the SCL line */
>> + ? ? ? ? ? ? for (i = 0; i < 9; i++) {
>> + ? ? ? ? ? ? ? ? ? ? gpio_set_value(scl_pin, 0);
>> + ? ? ? ? ? ? ? ? ? ? udelay(20);
>> + ? ? ? ? ? ? ? ? ? ? gpio_set_value(scl_pin, 1);
>> + ? ? ? ? ? ? ? ? ? ? udelay(20);
>> + ? ? ? ? ? ? }
>
> Before using the pins as GPIO, you would have to set the
> functionality of these pins as GPIO. You had this code in
> previous incarnations of this patch - not sure why it is
> dropped now.
>

Don't seem to remember having the code in the old versions at least
not in generic_i2c_clock_pulse(). The functions disable_i2c_pins() and
enable_i2c_pins() were discarded as the i2c protocol spec. did not
specify the need. Moreover bus recovered without it. (Tested on DM355
and Dm6446).

> Couple of good to haves:
>
> It will be good to do a gpio_request() before using the pins
> as GPIO - though I can see it may have been deemed unnecessary
> - the pins are owned by I2C already - even so it may help catch
> system configuration errors in later platforms.

Yes, I could use gpio_request() in generic_i2c_clock_pulse().

>
> The I2C peripheral on da8xx itself contains a mode where its
> pins could be used as GPIO - so no need for SoC level muxing
> and need for the platform data. This seems to be missing from
> DM355 though. Thankfully there is a revision id within the I2C
> memory map which will help you differentiate the two cases
> (revision 0x5 vs 0x6)

I did not entirely follow your above statement. Will usage of
gpio_request() solve the problem for da8xx and DM355 or does it
require a if else condition? A reminder that the present code will
only work for DM6446 and DM355. I do not have a DA8xx to test specific
functionality if it were to be added.

Regards,
Philby

From viral at allaboutif.com  Fri Feb  5 07:53:50 2010
From: viral at allaboutif.com (Viral Sachde)
Date: Fri, 5 Feb 2010 19:23:50 +0530
Subject: THS8200 driver integration
In-Reply-To: <4201738d1002050110i135048d5p2b5de0e45770cff9@mail.gmail.com>
References: <4201738d1002042210k4615b781m2889775399d974ce@mail.gmail.com>
	<4201738d1002050110i135048d5p2b5de0e45770cff9@mail.gmail.com>
Message-ID: <b002f1321002050553g5fe3c23cue3fcb73a372fc137@mail.gmail.com>

On Fri, Feb 5, 2010 at 2:40 PM, rekha devi <rekha.nimmakayala at gmail.com> wrote:
> Hi
>
> I am new to driver tech.
> currently we are using TFP410 for DVI output. now we have selected
> THS8200 for VGA output. For above modification i want to configure
> ths8200 through i2c.
> May i know any more information(links aor any.....) and any reference
> sample code for THS8200 driver.
> I tried to get sample code for ths8200_encoder .c etc related files.
> But i couldnt get any full information.Please anyone can u guide me.
>
> Thanks in advance.
> Rekha
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>


Hi, For starting one can refer spraan0 document & zip file available at
http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spraan0
Zip file contains sample source code. Regards, Viral

From pjohn at mvista.com  Fri Feb  5 07:58:22 2010
From: pjohn at mvista.com (Philby John)
Date: Fri, 5 Feb 2010 19:28:22 +0530
Subject: [PATCH v3 1/2] i2c: Add SDA and SCL pin numbers to i2c platform 
	data
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E235A3DA@dbde02.ent.ti.com>
References: <1263295031.3437.16.camel@localhost.localdomain>
	<B85A65D85D7EB246BE421B3FB0FBB59301E235A3DA@dbde02.ent.ti.com>
Message-ID: <225d086e1002050558n3968f53k83c4267416028be1@mail.gmail.com>

Hello Sekhar,

On Mon, Feb 1, 2010 at 11:35 AM, Nori, Sekhar <nsekhar at ti.com> wrote:
> Hi Philby,
>
> On Tue, Jan 12, 2010 at 16:47:11, Philby John wrote:
>> >From cb3347e45449ff16a332aa164eae24ef6a2432e6 Mon Sep 17 00:00:00 2001
>> From: Philby John <pjohn at in.mvista.com>
>> Date: Mon, 11 Jan 2010 15:53:31 +0530
>> Subject: [PATCH 1/2] Add SDA and SCL pin numbers to i2c platform data
>>
>> Patch adds SDA and SCL pin numbers to the i2c platform data
>> structure for Davinci DM355 and DM6446. This at present is
>> used for i2c bus recovery.
>> TODO: Add SDA and SCL pin number information to include all
>> Davinci platforms such as dm355-leopard, dm365, dm646x, da8xx etc.
>>
>> Signed-off-by: Philby John <pjohn at in.mvista.com>
>> ---
>> ?arch/arm/mach-davinci/board-dm355-evm.c ?| ? ?2 ++
>> ?arch/arm/mach-davinci/board-dm644x-evm.c | ? ?2 ++
>> ?arch/arm/mach-davinci/include/mach/i2c.h | ? ?2 ++
>> ?3 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
>> index 077ecf4..aa48e3f 100644
>> --- a/arch/arm/mach-davinci/board-dm355-evm.c
>> +++ b/arch/arm/mach-davinci/board-dm355-evm.c
>> @@ -111,6 +111,8 @@ static struct platform_device davinci_nand_device = {
>> ?static struct davinci_i2c_platform_data i2c_pdata = {
>> ? ? ? .bus_freq ? ? ? = 400 ? /* kHz */,
>> ? ? ? .bus_delay ? ? ?= 0 ? ? /* usec */,
>> + ? ? .sda_pin ? ? ? ?= 15,
>> + ? ? .scl_pin ? ? ? ?= 14,
>> ?};
>>
>> ?static struct snd_platform_data dm355_evm_snd_data;
>> diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
>> index e9612cf..976e11b 100644
>> --- a/arch/arm/mach-davinci/board-dm644x-evm.c
>> +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
>> @@ -629,6 +629,8 @@ static struct i2c_board_info __initdata i2c_info[] = ?{
>> ?static struct davinci_i2c_platform_data i2c_pdata = {
>> ? ? ? .bus_freq ? ? ? = 20 /* kHz */,
>> ? ? ? .bus_delay ? ? ?= 100 /* usec */,
>> + ? ? .sda_pin ? ? ? ?= 44,
>> + ? ? .scl_pin ? ? ? ?= 43,
>> ?};
>>
>> ?static void __init evm_init_i2c(void)
>> diff --git a/arch/arm/mach-davinci/include/mach/i2c.h b/arch/arm/mach-davinci/include/mach/i2c.h
>> index c248e9b..39fdcea 100644
>> --- a/arch/arm/mach-davinci/include/mach/i2c.h
>> +++ b/arch/arm/mach-davinci/include/mach/i2c.h
>> @@ -16,6 +16,8 @@
>> ?struct davinci_i2c_platform_data {
>> ? ? ? unsigned int ? ?bus_freq; ? ? ? /* standard bus frequency (kHz) */
>> ? ? ? unsigned int ? ?bus_delay; ? ? ?/* post-transaction delay (usec) */
>> + ? ? unsigned int ? ?sda_pin; ? ? ? ?/* GPIO pin ID to use for SDA */
>
> It doesn't look like you need the SDA pin to be
> a GPIO in patch 2/2 - can you drop it from platform
> data in that case?

Yes, SDA pin can be dropped. I merely added it for the sake of completeness.

Regards,
Philby

From nsekhar at ti.com  Mon Feb  8 04:35:39 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 8 Feb 2010 16:05:39 +0530
Subject: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
In-Reply-To: <225d086e1002050553tc1a696avce827cc115f56b1c@mail.gmail.com>
References: <1264549293-25556-1-git-send-email-khilman@deeprootsystems.com>
	<1264549293-25556-7-git-send-email-khilman@deeprootsystems.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E235A3C2@dbde02.ent.ti.com>
	<225d086e1002050553tc1a696avce827cc115f56b1c@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E2639AD8@dbde02.ent.ti.com>

Hi Philby,

On Fri, Feb 05, 2010 at 19:23:43, Philby John wrote:
> Hello Sekhar,
>

[...]

> >> +/* Generate a pulse on the i2c clock pin. */
> >> +static void generic_i2c_clock_pulse(unsigned int scl_pin)
> >> +{
> >> +     u16 i;
> >> +
> >> +     if (scl_pin) {
> >> +             /* Send high and low on the SCL line */
> >> +             for (i = 0; i < 9; i++) {
> >> +                     gpio_set_value(scl_pin, 0);
> >> +                     udelay(20);
> >> +                     gpio_set_value(scl_pin, 1);
> >> +                     udelay(20);
> >> +             }
> >
> > Before using the pins as GPIO, you would have to set the
> > functionality of these pins as GPIO. You had this code in
> > previous incarnations of this patch - not sure why it is
> > dropped now.
> >
>
> Don't seem to remember having the code in the old versions at least
> not in generic_i2c_clock_pulse(). The functions disable_i2c_pins() and
> enable_i2c_pins() were discarded as the i2c protocol spec. did not
> specify the need. Moreover bus recovered without it. (Tested on DM355
> and Dm6446).

Yes, I was referring to the davinci_cfg_reg() calls in
{disable|enable}_i2c_pins() functions. Per the specification
of the DaVinci devices, a pin needs to be muxed as 'GPIO' if
it is to be used as GPIO controlled by GPIO module. It may
have worked on couple of devices but cannot be guaranteed to
work on all DaVinci devices (esp. DA8XX ones).

>
> > Couple of good to haves:
> >

[...]

> >
> > The I2C peripheral on da8xx itself contains a mode where its
> > pins could be used as GPIO - so no need for SoC level muxing
> > and need for the platform data. This seems to be missing from
> > DM355 though. Thankfully there is a revision id within the I2C
> > memory map which will help you differentiate the two cases
> > (revision 0x5 vs 0x6)
>
> I did not entirely follow your above statement. Will usage of
> gpio_request() solve the problem for da8xx and DM355 or does it
> require a if else condition?

You require special casing for I2C version 0x6.
Have a look here: http://focus.ti.com/lit/ug/sprufl9a/sprufl9a.pdf
I was referring to registers described in sections
3.15-3.20

> A reminder that the present code will
> only work for DM6446 and DM355. I do not have a DA8xx to test specific
> functionality if it were to be added.

Right. It is only an enhancement (and only good
to have at that). This should not stop the current
patch from getting in.

Thanks,
Sekhar

From ottavio.campana at dei.unipd.it  Mon Feb  8 04:54:12 2010
From: ottavio.campana at dei.unipd.it (Ottavio Campana)
Date: Mon, 8 Feb 2010 11:54:12 +0100
Subject: ogg vorbis encoder for dm6446
In-Reply-To: <4B6BD2DC.7060708@nt.tu-darmstadt.de>
References: <4B6853E5.3090400@dei.unipd.it>
	<5f2b61002032243p19c2e1a5rd6bd31a9cdd75e47@mail.gmail.com>
	<20100205080915.GA11788@dei.unipd.it>
	<4B6BD2DC.7060708@nt.tu-darmstadt.de>
Message-ID: <20100208105412.GA6831@dei.unipd.it>

On Fri, Feb 05, 2010 at 09:12:12AM +0100, Vladimir Pantelic wrote:
> Ottavio Campana wrote:
>> On Thu, Feb 04, 2010 at 07:43:24AM +0100, Bj?rn Forsman wrote:
>>>  Hi Ottavio,
>>>
>>>  On 2 February 2010 17:33, Ottavio Campana<ottavio.campana at dei.unipd.it>  wrote:
>>>  >  is there an encoder for dm6446 for ogg vorbis?
>>>
>>>  Yes, you can use GStreamer to get ogg/vorbis support on the DM6446.
>>>  This codec only runs on the ARM GPP, no DSP.
>>
>> what is the performance running on the GPP? I mean, can I get PAL or NTSC?
>
> err, vorbis is an audio codec, no?

well, vorbis is for audio and theora is for video and they are both part of ogg.

I made a mistake, I ment the video encoder, not the audio.

Ottavio

From pjohn at mvista.com  Mon Feb  8 09:13:27 2010
From: pjohn at mvista.com (Philby John)
Date: Mon, 08 Feb 2010 20:43:27 +0530
Subject: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E2639AD8@dbde02.ent.ti.com>
References: <1264549293-25556-1-git-send-email-khilman@deeprootsystems.com>	
	<1264549293-25556-7-git-send-email-khilman@deeprootsystems.com>	
	<B85A65D85D7EB246BE421B3FB0FBB59301E235A3C2@dbde02.ent.ti.com>
	<225d086e1002050553tc1a696avce827cc115f56b1c@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E2639AD8@dbde02.ent.ti.com>
Message-ID: <4B702A17.3070104@mvista.com>

Hello Sekhar,

On 02/08/2010 04:05 PM, Nori, Sekhar wrote:
>>>> +static void generic_i2c_clock_pulse(unsigned int scl_pin)
>>>> +{
>>>> +     u16 i;
>>>> +
>>>> +     if (scl_pin) {
>>>> +             /* Send high and low on the SCL line */
>>>> +             for (i = 0; i<  9; i++) {
>>>> +                     gpio_set_value(scl_pin, 0);
>>>> +                     udelay(20);
>>>> +                     gpio_set_value(scl_pin, 1);
>>>> +                     udelay(20);
>>>> +             }
>>>
>>> Before using the pins as GPIO, you would have to set the
>>> functionality of these pins as GPIO. You had this code in
>>> previous incarnations of this patch - not sure why it is
>>> dropped now.
>>>
>>
>> Don't seem to remember having the code in the old versions at least
>> not in generic_i2c_clock_pulse(). The functions disable_i2c_pins() and
>> enable_i2c_pins() were discarded as the i2c protocol spec. did not
>> specify the need. Moreover bus recovered without it. (Tested on DM355
>> and Dm6446).
>
> Yes, I was referring to the davinci_cfg_reg() calls in
> {disable|enable}_i2c_pins() functions. Per the specification
> of the DaVinci devices, a pin needs to be muxed as 'GPIO' if
> it is to be used as GPIO controlled by GPIO module. It may
> have worked on couple of devices but cannot be guaranteed to
> work on all DaVinci devices (esp. DA8XX ones).


I think that using davinci_cfg_reg() in generic_i2c_clock_pulse() is the 
wrong place to put it. This would require adding davinci_cfg_reg() for 
all know davinci platforms. The i2c recovery procedure is correct to 
assume that it owns the SCL line at that very moment.

Instead I believe pinmuxing using davinci_cfg_reg(), should be done way 
early, just like we do for DM6446 in devices.c --> davinci_init_i2c(), 
for all other platforms. What I could do in function 
generic_i2c_clock_pulse() is, set SCL to output, and use gpio_request() 
by checking REVID2 register value (0x6) for DA8xx and 0x5 for others.

Let me know what you think.

Regards,
Philby

From nsekhar at ti.com  Mon Feb  8 10:03:51 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 8 Feb 2010 21:33:51 +0530
Subject: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
In-Reply-To: <4B702A17.3070104@mvista.com>
References: <1264549293-25556-1-git-send-email-khilman@deeprootsystems.com>
	<1264549293-25556-7-git-send-email-khilman@deeprootsystems.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E235A3C2@dbde02.ent.ti.com>
	<225d086e1002050553tc1a696avce827cc115f56b1c@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E2639AD8@dbde02.ent.ti.com>
	<4B702A17.3070104@mvista.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E2639D67@dbde02.ent.ti.com>

On Mon, Feb 08, 2010 at 20:43:27, Philby John wrote:
> Hello Sekhar,
>
> On 02/08/2010 04:05 PM, Nori, Sekhar wrote:
> >>>> +static void generic_i2c_clock_pulse(unsigned int scl_pin)
> >>>> +{
> >>>> +     u16 i;
> >>>> +
> >>>> +     if (scl_pin) {
> >>>> +             /* Send high and low on the SCL line */
> >>>> +             for (i = 0; i<  9; i++) {
> >>>> +                     gpio_set_value(scl_pin, 0);
> >>>> +                     udelay(20);
> >>>> +                     gpio_set_value(scl_pin, 1);
> >>>> +                     udelay(20);
> >>>> +             }
> >>>
> >>> Before using the pins as GPIO, you would have to set the
> >>> functionality of these pins as GPIO. You had this code in
> >>> previous incarnations of this patch - not sure why it is
> >>> dropped now.
> >>>
> >>
> >> Don't seem to remember having the code in the old versions at least
> >> not in generic_i2c_clock_pulse(). The functions disable_i2c_pins() and
> >> enable_i2c_pins() were discarded as the i2c protocol spec. did not
> >> specify the need. Moreover bus recovered without it. (Tested on DM355
> >> and Dm6446).
> >
> > Yes, I was referring to the davinci_cfg_reg() calls in
> > {disable|enable}_i2c_pins() functions. Per the specification
> > of the DaVinci devices, a pin needs to be muxed as 'GPIO' if
> > it is to be used as GPIO controlled by GPIO module. It may
> > have worked on couple of devices but cannot be guaranteed to
> > work on all DaVinci devices (esp. DA8XX ones).
>
>
> I think that using davinci_cfg_reg() in generic_i2c_clock_pulse() is the
> wrong place to put it. This would require adding davinci_cfg_reg() for
> all know davinci platforms. The i2c recovery procedure is correct to
> assume that it owns the SCL line at that very moment.
>
> Instead I believe pinmuxing using davinci_cfg_reg(), should be done way
> early, just like we do for DM6446 in devices.c --> davinci_init_i2c(),
> for all other platforms. What I could do in function
> generic_i2c_clock_pulse() is, set SCL to output, and use gpio_request()
> by checking REVID2 register value (0x6) for DA8xx and 0x5 for others.

But, the pins should remain as I2C pins till you actually
hit a bus lock-up. That's when you need to convert them to GPIO
pins and start the recovery by pulsing SCL.

It you make them GPIO right at the start, they wont be usable
as I2C pins for normal transfers?

Thanks,
Sekhar

From pjohn at mvista.com  Tue Feb  9 04:15:15 2010
From: pjohn at mvista.com (Philby John)
Date: Tue, 09 Feb 2010 15:45:15 +0530
Subject: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E2639D67@dbde02.ent.ti.com>
References: <1264549293-25556-1-git-send-email-khilman@deeprootsystems.com>	
	<1264549293-25556-7-git-send-email-khilman@deeprootsystems.com>	
	<B85A65D85D7EB246BE421B3FB0FBB59301E235A3C2@dbde02.ent.ti.com>
	<225d086e1002050553tc1a696avce827cc115f56b1c@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E2639AD8@dbde02.ent.ti.com>
	<4B702A17.3070104@mvista.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E2639D67@dbde02.ent.ti.com>
Message-ID: <4B7135B3.9080104@mvista.com>

On 02/08/2010 09:33 PM, Nori, Sekhar wrote:
> On Mon, Feb 08, 2010 at 20:43:27, Philby John wrote:
>> Hello Sekhar,
>>
>> On 02/08/2010 04:05 PM, Nori, Sekhar wrote:
>>>>>> +static void generic_i2c_clock_pulse(unsigned int scl_pin)
>>>>>> +{
>>>>>> +     u16 i;
>>>>>> +
>>>>>> +     if (scl_pin) {
>>>>>> +             /* Send high and low on the SCL line */
>>>>>> +             for (i = 0; i<   9; i++) {
>>>>>> +                     gpio_set_value(scl_pin, 0);
>>>>>> +                     udelay(20);
>>>>>> +                     gpio_set_value(scl_pin, 1);
>>>>>> +                     udelay(20);
>>>>>> +             }
>>>>>
>>>>> Before using the pins as GPIO, you would have to set the
>>>>> functionality of these pins as GPIO. You had this code in
>>>>> previous incarnations of this patch - not sure why it is
>>>>> dropped now.
>>>>>
>>>>
>>>> Don't seem to remember having the code in the old versions at least
>>>> not in generic_i2c_clock_pulse(). The functions disable_i2c_pins() and
>>>> enable_i2c_pins() were discarded as the i2c protocol spec. did not
>>>> specify the need. Moreover bus recovered without it. (Tested on DM355
>>>> and Dm6446).
>>>
>>> Yes, I was referring to the davinci_cfg_reg() calls in
>>> {disable|enable}_i2c_pins() functions. Per the specification
>>> of the DaVinci devices, a pin needs to be muxed as 'GPIO' if
>>> it is to be used as GPIO controlled by GPIO module. It may
>>> have worked on couple of devices but cannot be guaranteed to
>>> work on all DaVinci devices (esp. DA8XX ones).
>>
>>
>> I think that using davinci_cfg_reg() in generic_i2c_clock_pulse() is the
>> wrong place to put it. This would require adding davinci_cfg_reg() for
>> all know davinci platforms. The i2c recovery procedure is correct to
>> assume that it owns the SCL line at that very moment.
>>
>> Instead I believe pinmuxing using davinci_cfg_reg(), should be done way
>> early, just like we do for DM6446 in devices.c -->  davinci_init_i2c(),
>> for all other platforms. What I could do in function
>> generic_i2c_clock_pulse() is, set SCL to output, and use gpio_request()
>> by checking REVID2 register value (0x6) for DA8xx and 0x5 for others.
>
> But, the pins should remain as I2C pins till you actually
> hit a bus lock-up. That's when you need to convert them to GPIO
> pins and start the recovery by pulsing SCL.
>
> It you make them GPIO right at the start, they wont be usable
> as I2C pins for normal transfers?


Right. I was also hoping to rid of cpu_is_xxx usage. The only other way 
I could think of is to add pinmux index into i2c platform data struct. 
What do you think is the best approach?


Regards,
Philby

From nsekhar at ti.com  Tue Feb  9 04:52:05 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 9 Feb 2010 16:22:05 +0530
Subject: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
In-Reply-To: <4B7135B3.9080104@mvista.com>
References: <1264549293-25556-1-git-send-email-khilman@deeprootsystems.com>
	<1264549293-25556-7-git-send-email-khilman@deeprootsystems.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E235A3C2@dbde02.ent.ti.com>
	<225d086e1002050553tc1a696avce827cc115f56b1c@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E2639AD8@dbde02.ent.ti.com>
	<4B702A17.3070104@mvista.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E2639D67@dbde02.ent.ti.com>
	<4B7135B3.9080104@mvista.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E263A447@dbde02.ent.ti.com>

On Tue, Feb 09, 2010 at 15:45:15, Philby John wrote:
> On 02/08/2010 09:33 PM, Nori, Sekhar wrote:
> > On Mon, Feb 08, 2010 at 20:43:27, Philby John wrote:
> >> Hello Sekhar,
> >>
> >> On 02/08/2010 04:05 PM, Nori, Sekhar wrote:
> >>>>>> +static void generic_i2c_clock_pulse(unsigned int scl_pin)
> >>>>>> +{
> >>>>>> +     u16 i;
> >>>>>> +
> >>>>>> +     if (scl_pin) {
> >>>>>> +             /* Send high and low on the SCL line */
> >>>>>> +             for (i = 0; i<   9; i++) {
> >>>>>> +                     gpio_set_value(scl_pin, 0);
> >>>>>> +                     udelay(20);
> >>>>>> +                     gpio_set_value(scl_pin, 1);
> >>>>>> +                     udelay(20);
> >>>>>> +             }
> >>>>>
> >>>>> Before using the pins as GPIO, you would have to set the
> >>>>> functionality of these pins as GPIO. You had this code in
> >>>>> previous incarnations of this patch - not sure why it is
> >>>>> dropped now.
> >>>>>
> >>>>
> >>>> Don't seem to remember having the code in the old versions at least
> >>>> not in generic_i2c_clock_pulse(). The functions disable_i2c_pins() and
> >>>> enable_i2c_pins() were discarded as the i2c protocol spec. did not
> >>>> specify the need. Moreover bus recovered without it. (Tested on DM355
> >>>> and Dm6446).
> >>>
> >>> Yes, I was referring to the davinci_cfg_reg() calls in
> >>> {disable|enable}_i2c_pins() functions. Per the specification
> >>> of the DaVinci devices, a pin needs to be muxed as 'GPIO' if
> >>> it is to be used as GPIO controlled by GPIO module. It may
> >>> have worked on couple of devices but cannot be guaranteed to
> >>> work on all DaVinci devices (esp. DA8XX ones).
> >>
> >>
> >> I think that using davinci_cfg_reg() in generic_i2c_clock_pulse() is the
> >> wrong place to put it. This would require adding davinci_cfg_reg() for
> >> all know davinci platforms. The i2c recovery procedure is correct to
> >> assume that it owns the SCL line at that very moment.
> >>
> >> Instead I believe pinmuxing using davinci_cfg_reg(), should be done way
> >> early, just like we do for DM6446 in devices.c -->  davinci_init_i2c(),
> >> for all other platforms. What I could do in function
> >> generic_i2c_clock_pulse() is, set SCL to output, and use gpio_request()
> >> by checking REVID2 register value (0x6) for DA8xx and 0x5 for others.
> >
> > But, the pins should remain as I2C pins till you actually
> > hit a bus lock-up. That's when you need to convert them to GPIO
> > pins and start the recovery by pulsing SCL.
> >
> > It you make them GPIO right at the start, they wont be usable
> > as I2C pins for normal transfers?
>
>
> Right. I was also hoping to rid of cpu_is_xxx usage. The only other way
> I could think of is to add pinmux index into i2c platform data struct.
> What do you think is the best approach?
>

I think passing pinmux index through platform data is fair.

Thanks,
Sekhar

From mohameeed2010 at hotmail.com  Tue Feb  9 07:02:17 2010
From: mohameeed2010 at hotmail.com (Mohamed AbdElwahed)
Date: Tue, 9 Feb 2010 13:02:17 +0000
Subject: How to integrate another decoder to my existing decoder?
In-Reply-To: <mailman.1.1265652001.21729.davinci-linux-open-source@linux.davincidsp.com>
References: <mailman.1.1265652001.21729.davinci-linux-open-source@linux.davincidsp.com>
Message-ID: <COL106-W6532B359A43FA627E9B06DAB500@phx.gbl>


Hi all,

i am using DM6446. i used the video_copy example to implement my codec, and i do it. now i do another one based also on the video_copy example but i want now to integrate both of them.

note:- currently i have 2 seperate folder structures each one contains the folders named ("apps", "buildutils", "codecs", and "servers")

i want to have only one folder structure for the 2 codecs.

Is there any document/URL/HELP/Suggestions to do this? or this is not possible to do this at all?

 

I tryed below but it failed

------------------------

i modified ceapp_init(), that open, (Engine_open()), the codec engine and create, (VIDDEC_create()), two video decoders that attached to it.

as below

--------------------------------------------------------------------------------------

    // reset, load, and start DSP Engine 
    if ((ceHandle = Engine_open(engineName, NULL, NULL)) == NULL) 
    {
        printf("CEapp-> ERROR: can't open engine %s\n", engineName);
        goto init_end;
    }
    else
        printf(">>CEapp-> Engine opened %s\n", engineName);

    // activate DSP trace collection thread 
    TraceUtil_start(engineName);

    // allocate and initialize video decoder on the engine 
    decHandle1 = VIDDEC_create(ceHandle, decoderName1, NULL);
    if (decHandle == NULL) 
    {
        printf("CEapp-> ERROR: can't open codec %s\n", decoderName);
        goto init_end;
    }

    decHandle2 = VIDDEC_create(ceHandle, decoderName2, NULL);
    if (decHandle == NULL) 
    {
        printf("CEapp-> ERROR: can't open codec %s\n", decoderName);
        goto init_end;
    }
    // success 
    status = 0;

------------------------------------------------------------------------------------------------------------------

also i created two functions named ceapp_decodeBuf1() and ceapp_decodeBuf2() each one call the corresponding decoder.

that is all i do, am i right or this is totally wrong or there is still other modifications that should be done and i missed!!!!!!
--------------------------------------

your help is highly appreciated
thanks


Mohamed AbdElwahed Ibrahim 
 		 	   		  
_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
https://signup.live.com/signup.aspx?id=60969
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100209/5710711e/attachment.html>

From jamesnuss at nanometrics.ca  Tue Feb  9 10:21:01 2010
From: jamesnuss at nanometrics.ca (James Nuss)
Date: Tue, 09 Feb 2010 11:21:01 -0500
Subject: OMAP-L13x DDR Self-refresh bug
Message-ID: <4B718B6D.1050902@nanometrics.ca>

Hi,

I have discovered a bug in the cpuidle code for the OMAP-L13x (da8xx) 
platform.

In the state described as "WFI and DDR Self-Refresh", the code is 
actually putting the DDR into the "Power Down" mode which is not the 
same as self-refresh.

So the description string should read "WFI and DDR Power Down".

Putting the DDR into self-refresh and subsequently gating the clocks for 
  greater power savings, requires significantly  more work (Refer to 
Section 2.16 OMAP-L1x DDR2/mDDR Memory Controller User's Guide).

cheers,
James


From nsekhar at ti.com  Tue Feb  9 11:09:34 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 9 Feb 2010 22:39:34 +0530
Subject: OMAP-L13x DDR Self-refresh bug
In-Reply-To: <4B718B6D.1050902@nanometrics.ca>
References: <4B718B6D.1050902@nanometrics.ca>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E263A6D3@dbde02.ent.ti.com>

Hi James,

On Tue, Feb 09, 2010 at 21:51:01, James Nuss wrote:
> Hi,
>
> I have discovered a bug in the cpuidle code for the OMAP-L13x (da8xx)
> platform.
>
> In the state described as "WFI and DDR Self-Refresh", the code is
> actually putting the DDR into the "Power Down" mode which is not the
> same as self-refresh.
>
> So the description string should read "WFI and DDR Power Down".

Yes, going into power down on OMAP-L138 was intentional (it is
supposed to save more power than self-refresh). I agree the state
description could have been conditional on pdata->ddr2_pdown value.

>
> Putting the DDR into self-refresh and subsequently gating the clocks for
>   greater power savings, requires significantly  more work (Refer to
> Section 2.16 OMAP-L1x DDR2/mDDR Memory Controller User's Guide).

This is implemented as part of suspend-to-RAM support. Have a look at
arch/arm/mach-davinci/pm.c file.

Thanks,
Sekhar


From jamesnuss at nanometrics.ca  Tue Feb  9 12:12:36 2010
From: jamesnuss at nanometrics.ca (James Nuss)
Date: Tue, 09 Feb 2010 13:12:36 -0500
Subject: OMAP-L13x DDR Self-refresh bug
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E263A6D3@dbde02.ent.ti.com>
References: <4B718B6D.1050902@nanometrics.ca>
	<B85A65D85D7EB246BE421B3FB0FBB59301E263A6D3@dbde02.ent.ti.com>
Message-ID: <4B71A594.5060004@nanometrics.ca>

Hi Sekhar

Nori, Sekhar wrote:
> Hi James,
> 
> On Tue, Feb 09, 2010 at 21:51:01, James Nuss wrote:
>> Hi,
>>
>> I have discovered a bug in the cpuidle code for the OMAP-L13x (da8xx)
>> platform.
>>
>> In the state described as "WFI and DDR Self-Refresh", the code is
>> actually putting the DDR into the "Power Down" mode which is not the
>> same as self-refresh.
>>
>> So the description string should read "WFI and DDR Power Down".
> 
> Yes, going into power down on OMAP-L138 was intentional (it is
> supposed to save more power than self-refresh). I agree the state
> description could have been conditional on pdata->ddr2_pdown value.
> 
>> Putting the DDR into self-refresh and subsequently gating the clocks for
>>   greater power savings, requires significantly  more work (Refer to
>> Section 2.16 OMAP-L1x DDR2/mDDR Memory Controller User's Guide).
> 
> This is implemented as part of suspend-to-RAM support. Have a look at
> arch/arm/mach-davinci/pm.c file.

I see. So is the DDR self-refresh only feasible as a suspend-to-RAM 
option? i.e. Is it too slow to enter/exit to use in a running state?

I have successfully put the board to sleep using:
echo mem >/sys/power/state

But how do you resume from this suspended state? Do all peripherals have 
support for resuming from suspend right now?

Thanks,
James

> 
> Thanks,
> Sekhar
> 

From rtivy at ti.com  Tue Feb  9 18:25:56 2010
From: rtivy at ti.com (Tivy, Robert)
Date: Tue, 9 Feb 2010 18:25:56 -0600
Subject: How to integrate another decoder to my existing decoder?
In-Reply-To: <COL106-W6532B359A43FA627E9B06DAB500@phx.gbl>
References: <mailman.1.1265652001.21729.davinci-linux-open-source@linux.davincidsp.com>
	<COL106-W6532B359A43FA627E9B06DAB500@phx.gbl>
Message-ID: <6B8224E84039B140AA662F0BB036164301236703FA@dlee04.ent.ti.com>

There is a good manual here, named "Codec Engine Server Integrator User's Guide": http://focus.ti.com/lit/ug/sprued5b/sprued5b.pdf.

It describes what you need to do to put multiple codecs in an application.  You will need to create a Codec Server that contains both your algorithms (codecs), since you can load only one server at a time on the DSP.

You say you tried but didn't state details about what you tried, nor details about it failing.  You will get better support if you provide more detail, but hopefully the guide I pointed to will be enough to get you going in the right direction.

Regards,

- Rob

________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Mohamed AbdElwahed
Sent: Tuesday, February 09, 2010 5:02 AM
To: Davinci Mailing list
Subject: How to integrate another decoder to my existing decoder?

Hi all,
i am using DM6446. i used the video_copy example to implement my codec, and i do it. now i do another one based also on the video_copy example but i want now to integrate both of them.
note:- currently i have 2 seperate folder structures each one contains the folders named ("apps", "buildutils", "codecs", and "servers")
i want to have only one folder structure for the 2 codecs.
Is there any document/URL/HELP/Suggestions to do this? or this is not possible to do this at all?

I tryed below but it failed
------------------------
i modified ceapp_init(), that open, (Engine_open()), the codec engine and create, (VIDDEC_create()), two video decoders that attached to it.
as below
--------------------------------------------------------------------------------------
    // reset, load, and start DSP Engine
    if ((ceHandle = Engine_open(engineName, NULL, NULL)) == NULL)
    {
        printf("CEapp-> ERROR: can't open engine %s\n", engineName);
        goto init_end;
    }
    else
        printf(">>CEapp-> Engine opened %s\n", engineName);
    // activate DSP trace collection thread
    TraceUtil_start(engineName);
    // allocate and initialize video decoder on the engine
    decHandle1 = VIDDEC_create(ceHandle, decoderName1, NULL);
    if (decHandle == NULL)
    {
        printf("CEapp-> ERROR: can't open codec %s\n", decoderName);
        goto init_end;
    }
    decHandle2 = VIDDEC_create(ceHandle, decoderName2, NULL);
    if (decHandle == NULL)
    {
        printf("CEapp-> ERROR: can't open codec %s\n", decoderName);
        goto init_end;
    }
    // success
    status = 0;
------------------------------------------------------------------------------------------------------------------
also i created two functions named ceapp_decodeBuf1() and ceapp_decodeBuf2() each one call the corresponding decoder.
that is all i do, am i right or this is totally wrong or there is still other modifications that should be done and i missed!!!!!!
--------------------------------------
your help is highly appreciated
thanks
Mohamed AbdElwahed Ibrahim [http://graphics.hotmail.com/i.p.emthup.gif]

________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up now.<https://signup.live.com/signup.aspx?id=60969>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100209/f3ecf7d9/attachment.html>

From nsekhar at ti.com  Wed Feb 10 02:30:42 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Wed, 10 Feb 2010 14:00:42 +0530
Subject: OMAP-L13x DDR Self-refresh bug
In-Reply-To: <4B71A594.5060004@nanometrics.ca>
References: <4B718B6D.1050902@nanometrics.ca>
	<B85A65D85D7EB246BE421B3FB0FBB59301E263A6D3@dbde02.ent.ti.com>
	<4B71A594.5060004@nanometrics.ca>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E26C4F42@dbde02.ent.ti.com>

On Tue, Feb 09, 2010 at 23:42:36, James Nuss wrote:
> Hi Sekhar
>
> Nori, Sekhar wrote:
> > On Tue, Feb 09, 2010 at 21:51:01, James Nuss wrote:

[...]

> >
> >> Putting the DDR into self-refresh and subsequently gating the clocks for
> >>   greater power savings, requires significantly  more work (Refer to
> >> Section 2.16 OMAP-L1x DDR2/mDDR Memory Controller User's Guide).
> >
> > This is implemented as part of suspend-to-RAM support. Have a look at
> > arch/arm/mach-davinci/pm.c file.
>
> I see. So is the DDR self-refresh only feasible as a suspend-to-RAM
> option? i.e. Is it too slow to enter/exit to use in a running state?

Putting DDR in self-refresh is feasible from running system. Gating DDR
clock though needs co-operation of peripherals. This is done by invoking
suspend/resume routines of drivers (suspend-to-RAM).

>
> I have successfully put the board to sleep using:
> echo mem >/sys/power/state
>
> But how do you resume from this suspended state? Do all peripherals have
> support for resuming from suspend right now?

You need RTC alarm to wake up. You can use rtcwake command do this.

Example invocation:

rtcwake -s 30 -d /dev/rtc0 -m mem

This command is present in arago filesystem we use for testing. You can
grab the latest version from here: http://arago-project.org/files/releases/

Drivers like MMC/SD, LCD etc already support suspend/resume in Kevin's tree.
We are working towards a release which will support suspend/resume for all
OMAP-L138 drivers (except SATA). The master branch of the tree
http://arago-project.org/git/people/?p=sekhar/linux-omapl1.git;a=summary
hosts the work in progress. It contains patches which have not been submitted,
but provides additional functionality. We will submit the patches back to the
subsystem lists in coming weeks.

Thanks,
Sekhar



From erezk at radvision.com  Wed Feb 10 03:00:11 2010
From: erezk at radvision.com (Erez Kinarti)
Date: Wed, 10 Feb 2010 11:00:11 +0200
Subject: How to integrate another decoder to my existing decoder?
In-Reply-To: <6B8224E84039B140AA662F0BB036164301236703FA@dlee04.ent.ti.com>
References: <mailman.1.1265652001.21729.davinci-linux-open-source@linux.davincidsp.com><COL106-W6532B359A43FA627E9B06DAB500@phx.gbl>
	<6B8224E84039B140AA662F0BB036164301236703FA@dlee04.ent.ti.com>
Message-ID: <10B9B66481AB544596EF70B519D5899601D865DD@rvil-mail1.RADVISION.com>

Hey,

As I understand, you have a single video decoder, and you want two
instances running for two channels of the same decoder.

In this case you are okay with having a single folder inside the
/codecs/ folder for myVidDecoder.

 

I didn't useit yet, but the way you should do it is to declare a single
codec in the server .cfg file (let's say "myVidDec"), build the server
package.

Afterwards, in the app config file you should declare this codec with
the same name.

 

In the source files, in the ceapp_init() function, you should call
VIDDEC_create twice with THE SAME codec name, which is the name you
defined in the .cfg files, but each time with a different decHandle.

>From here on you have two decoder handles, each of them represents a
different decoder instance with its own state (persistent memory).

 

In order to understand how exactly to define the decoder name in the cfg
files, the best way is to see in the video_copy example.

 

Hope I helped,

Erez

 

 

 

From:
davinci-linux-open-source-bounces+erezk=radvision.com at linux.davincidsp.c
om
[mailto:davinci-linux-open-source-bounces+erezk=radvision.com at linux.davi
ncidsp.com] On Behalf Of Tivy, Robert
Sent: Wednesday, February 10, 2010 2:26 AM
To: Mohamed AbdElwahed; Davinci Mailing list
Subject: RE: How to integrate another decoder to my existing decoder?

 

There is a good manual here, named "Codec Engine Server Integrator
User's Guide": http://focus.ti.com/lit/ug/sprued5b/sprued5b.pdf.

 

It describes what you need to do to put multiple codecs in an
application.  You will need to create a Codec Server that contains both
your algorithms (codecs), since you can load only one server at a time
on the DSP.

 

You say you tried but didn't state details about what you tried, nor
details about it failing.  You will get better support if you provide
more detail, but hopefully the guide I pointed to will be enough to get
you going in the right direction.

 

Regards,

 

- Rob

	 

	
________________________________


	From: davinci-linux-open-source-bounces at linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On
Behalf Of Mohamed AbdElwahed
	Sent: Tuesday, February 09, 2010 5:02 AM
	To: Davinci Mailing list
	Subject: How to integrate another decoder to my existing
decoder?

	Hi all,
	i am using DM6446. i used the video_copy example to implement my
codec, and i do it. now i do another one based also on the video_copy
example but i want now to integrate both of them.
	note:- currently i have 2 seperate folder structures each one
contains the folders named ("apps", "buildutils", "codecs", and
"servers")
	i want to have only one folder structure for the 2 codecs.
	Is there any document/URL/HELP/Suggestions to do this? or this
is not possible to do this at all?
	 
	I tryed below but it failed
	------------------------
	i modified ceapp_init(), that open, (Engine_open()), the codec
engine and create, (VIDDEC_create()), two video decoders that attached
to it.
	as below
	
------------------------------------------------------------------------
--------------
	    // reset, load, and start DSP Engine 
	    if ((ceHandle = Engine_open(engineName, NULL, NULL)) ==
NULL) 
	    {
	        printf("CEapp-> ERROR: can't open engine %s\n",
engineName);
	        goto init_end;
	    }
	    else
	        printf(">>CEapp-> Engine opened %s\n", engineName);
	    // activate DSP trace collection thread 
	    TraceUtil_start(engineName);
	    // allocate and initialize video decoder on the engine 
	    decHandle1 = VIDDEC_create(ceHandle, decoderName1, NULL);
	    if (decHandle == NULL) 
	    {
	        printf("CEapp-> ERROR: can't open codec %s\n",
decoderName);
	        goto init_end;
	    }
	    decHandle2 = VIDDEC_create(ceHandle, decoderName2, NULL);
	    if (decHandle == NULL) 
	    {
	        printf("CEapp-> ERROR: can't open codec %s\n",
decoderName);
	        goto init_end;
	    }
	    // success 
	    status = 0;
	
------------------------------------------------------------------------
------------------------------------------
	also i created two functions named ceapp_decodeBuf1() and
ceapp_decodeBuf2() each one call the corresponding decoder.
	that is all i do, am i right or this is totally wrong or there
is still other modifications that should be done and i missed!!!!!!
	--------------------------------------
	your help is highly appreciated
	thanks

	Mohamed AbdElwahed Ibrahim
<http://graphics.hotmail.com/i.p.emthup.gif> 

	 

	
________________________________


	Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
Sign up now. <https://signup.live.com/signup.aspx?id=60969>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100210/39b3fb55/attachment-0001.html>

From mohameeed2010 at hotmail.com  Wed Feb 10 08:06:35 2010
From: mohameeed2010 at hotmail.com (Mohamed AbdElwahed)
Date: Wed, 10 Feb 2010 14:06:35 +0000
Subject: Is there equivalent function to align() on DSP
In-Reply-To: <mailman.970.1265792422.11996.davinci-linux-open-source@linux.davincidsp.com>
References: <mailman.970.1265792422.11996.davinci-linux-open-source@linux.davincidsp.com>
Message-ID: <COL106-W58C50F248D504D1ED2F4FBAB4F0@phx.gbl>


Hi all,

I try to use part of the ffmpeg library to run as my algorithm/codec on the DSP. but i fail to compile the algorithm since the compiler does not know this function "align()", it gives undefined in compilation. and i have to use such function. Is there any equivalent function for the DSP compiler or how to avoid using such function and have the same behavior of as if using it.

Originally the line of code that use this function look like below

#define DECLARE_ASM_CONST(n,t,v)    __declspec(align(n)) static const t v

---------------------

thanks in advance for any help

BEST REGARD

Mohamed AbdElwahed
 		 	   		  
_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
https://signup.live.com/signup.aspx?id=60969
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100210/338d84f1/attachment.html>

From ramiro at lisha.ufsc.br  Wed Feb 10 14:12:12 2010
From: ramiro at lisha.ufsc.br (Ramiro Polla)
Date: Wed, 10 Feb 2010 18:12:12 -0200
Subject: 76Mb memory limit on dm365
Message-ID: <f460258d1002101212s24727a72xaf135805679b0da6@mail.gmail.com>

Hi,

Some documentation for the dm365 (for example
dvsdk_2_10_01_18/dm365_2_10_01_18_release_notes.html) suggests setting
"mem=76M" in the bootargs.

Why is there such a limit? Isn't there more memory available in the board?

Any pointer to more complete documentation on the subject is welcome.

Ramiro Polla

From diego.dompe at ridgerun.com  Wed Feb 10 14:29:42 2010
From: diego.dompe at ridgerun.com (Diego Dompe)
Date: Wed, 10 Feb 2010 14:29:42 -0600
Subject: 76Mb memory limit on dm365
In-Reply-To: <f460258d1002101212s24727a72xaf135805679b0da6@mail.gmail.com>
References: <f460258d1002101212s24727a72xaf135805679b0da6@mail.gmail.com>
Message-ID: <F1EE99FC-4785-451B-A6C7-F201CC8C12DB@ridgerun.com>

Ramiro,

This limit is due the cmem buffers being allocated to this location. If you have more RAM available on your final board, you can just move the cmem buffers to another location and give more memory to the Linux kernel.

Diego

On Feb 10, 2010, at 2:12 PM, Ramiro Polla wrote:

> Hi,
> 
> Some documentation for the dm365 (for example
> dvsdk_2_10_01_18/dm365_2_10_01_18_release_notes.html) suggests setting
> "mem=76M" in the bootargs.
> 
> Why is there such a limit? Isn't there more memory available in the board?
> 
> Any pointer to more complete documentation on the subject is welcome.
> 
> Ramiro Polla
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


From rsanchezs at infoglobal.es  Wed Feb 10 14:33:49 2010
From: rsanchezs at infoglobal.es (=?utf-8?q?Ra=C3=BAl_S=C3=A1nchez_Siles?=)
Date: Wed, 10 Feb 2010 21:33:49 +0100
Subject: DM355 codecs on git kernel.
Message-ID: <201002102133.49514.rsanchezs@infoglobal.es>

  Hello All:

  We have developed a test application that capture video and encode it using 
the mpeg4 codec provided in the dvsdk 2.0.0.22 for DM355. We did some 
successful tests using MVL5.

  Now, we would like to set up a full DM355 system using the git kernel. We 
have focused on 2.6.32-davinci1. System is working and it looks peripherals 
too. We ported cmemk kernel module to build (and hopefully work) with 2.6.32-
davinci1.

  We did the same with dm350mmap kernel, in this case, due to the EDMA API 
change, we are not very sure that this module is correct now. But still we 
went on and build all the necessary components (taken from the above mentioned 
dvsdk) against the new kernel. Application build eventually and now we are on 
the point to execute it.

  It started to run, but it will stall the first time videnc_process is 
called. (see runlog attached for the final messages). It stalls so bad that 
kernel totally freezes (I can't stop CPU using jtag)

  My questions are:

  - Is there any source of information or patches for a dm350mmap kernel 
module ready for latest kernels?
  - Are dvsdk 2.0.0.22 codecs  (or others) supposed to work with latest 
kernels?
  - Could anyone state exactly which dvsdk components depends somehow on 
kernel, and should therefor be rebuild?
  - What are the indications to debug a problem like this?

  TIA, Regards,

-- 
Ra?l S?nchez Siles

Departamento de Montaje

INFOGLOBAL, S. A.

* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarc?n (Madrid), Espa?a
* T: +34 91 506 40 00
* F: +34 91 506 40 01
-------------- next part --------------
@4,518,603us: [+0 T:0x4001f620 S:0xbeb6c7ec] ti.sdo.ce.video1.VIDENC1 - VIDENC1_control> Enter (handle=0x125e98, id=1, dynParams=0xe23b0 (size=0x30), status=0xe22e0 (size=0x9c)                                  
@4,518,908us: [+5 T:0x4001f620 S:0xbeb6c7cc] CV - VISA_enter(visa=0x125e98): algHandle = 0x125ed0        
@4,519,162us: [+0 T:0x4001f620 S:0xbeb6c7bc] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(alg=0x125ed0)                                                                                                    
@4,851,521us: [+0 T:0x4001f620 S:0xbeb6c784] ti.sdo.ce.osal.SemMP - Entered SemMP_pend> sem[0x125a10] timeout[0xffffffff]                                                                                         
@4,851,874us: [+0 T:0x4001f620 S:0xbeb6c784] ti.sdo.ce.osal.SemMP - Leaving SemMP_pend> sem[0x125a10] status[0]                                                                                                   
@4,852,179us: [+0 T:0x4001f620 S:0xbeb6c7cc] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Exit          
@4,852,455us: [+5 T:0x4001f620 S:0xbeb6c7d4] CV - VISA_exit(visa=0x125e98): algHandle = 0x125ed0         
@4,852,762us: [+0 T:0x4001f620 S:0xbeb6c7c4] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter(alg=0x125ed0)                                                                                                  
@4,853,031us: [+0 T:0x4001f620 S:0xbeb6c7a4] ti.sdo.ce.osal.SemMP - Entered SemMP_post> sem[0x125a10]    
@4,853,313us: [+0 T:0x4001f620 S:0xbeb6c7a4] ti.sdo.ce.osal.SemMP - Leaving SemMP_post> sem[0x125a10]    
@4,853,570us: [+0 T:0x4001f620 S:0xbeb6c7d4] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Exit        
@4,853,812us: [+0 T:0x4001f620 S:0xbeb6c7ec] ti.sdo.ce.video1.VIDENC1 - VIDENC1_control> Exit (handle=0x125e98, retVal=0x0)                                                                                       
@4,854,124us: [+0 T:0x4001f620 S:0xbeb6c81c] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Enter (handle=0x125e98, inBufs=0xbeb6c960, outBufs=0xbeb6c954, inArgs=0xbeb6c944, outArgs=0xbeb6c8cc)                    
@4,854,425us: [+5 T:0x4001f620 S:0xbeb6c7fc] CV - VISA_enter(visa=0x125e98): algHandle = 0x125ed0        
@4,854,673us: [+0 T:0x4001f620 S:0xbeb6c7ec] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(alg=0x125ed0)                                                                                                    
@4,854,924us: [+0 T:0x4001f620 S:0xbeb6c7b4] ti.sdo.ce.osal.SemMP - Entered SemMP_pend> sem[0x125a10] timeout[0xffffffff]                                                                                         
@4,855,205us: [+0 T:0x4001f620 S:0xbeb6c7b4] ti.sdo.ce.osal.SemMP - Leaving SemMP_pend> sem[0x125a10] status[0]                                                                                                   
@4,855,543us: [+0 T:0x4001f620 S:0xbeb6c7fc] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Exit 

From cring at ti.com  Wed Feb 10 14:52:22 2010
From: cring at ti.com (Ring, Chris)
Date: Wed, 10 Feb 2010 14:52:22 -0600
Subject: 76Mb memory limit on dm365
In-Reply-To: <F1EE99FC-4785-451B-A6C7-F201CC8C12DB@ridgerun.com>
References: <f460258d1002101212s24727a72xaf135805679b0da6@mail.gmail.com>
	<F1EE99FC-4785-451B-A6C7-F201CC8C12DB@ridgerun.com>
Message-ID: <92CDD168D1E81F4F9D3839DC45903FC66F42E6EA@dlee03.ent.ti.com>

FYI, if you're not familiar with CMEM, there's an overview here:
http://tiexpressdsp.com/index.php/CMEM_Overview

Chris 

> -----Original Message-----
> From: 
> davinci-linux-open-source-bounces+cring=ti.com at linux.davincids
> p.com 
> [mailto:davinci-linux-open-source-bounces+cring=ti.com at linux.d
> avincidsp.com] On Behalf Of Diego Dompe
> Sent: Wednesday, February 10, 2010 12:30 PM
> To: Ramiro Polla
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Subject: Re: 76Mb memory limit on dm365
> 
> Ramiro,
> 
> This limit is due the cmem buffers being allocated to this 
> location. If you have more RAM available on your final board, 
> you can just move the cmem buffers to another location and 
> give more memory to the Linux kernel.
> 
> Diego
> 
> On Feb 10, 2010, at 2:12 PM, Ramiro Polla wrote:
> 
> > Hi,
> > 
> > Some documentation for the dm365 (for example
> > dvsdk_2_10_01_18/dm365_2_10_01_18_release_notes.html) 
> suggests setting
> > "mem=76M" in the bootargs.
> > 
> > Why is there such a limit? Isn't there more memory 
> available in the board?
> > 
> > Any pointer to more complete documentation on the subject 
> is welcome.
> > 
> > Ramiro Polla
> > _______________________________________________
> > Davinci-linux-open-source mailing list
> > Davinci-linux-open-source at linux.davincidsp.com
> > 
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 

From pbansal at ti.com  Wed Feb 10 16:42:50 2010
From: pbansal at ti.com (Bansal, Prateek)
Date: Wed, 10 Feb 2010 16:42:50 -0600
Subject: DM3xx: UART transmit delays
Message-ID: <F39349C6FA641B4A831B7BF4EBF4D4E14175A77B@dlee03.ent.ti.com>

Hi,

When working with DM355 UART1, we are experiencing a strange behavior. When calling the write function for this UART, sometimes it takes 200 ms for the write function to complete. This happens when a write function is called right after another write function. There is not a lot of data sent to the UART at one time, at most 32 bytes. The UART is running at 100,000 baud and would take at most 3.2 ms to send this data, not 200 ms.

We have tested this in non-Linux environment and found there were no delays. Has anyone came across this issue on UART transmits on DM355 devices?

Below is simple test code that re-creates this issue.


static int halUartWrite(int fd, uint8_t* buffer, size_t s)
{
    int num = 0;

    if( fd != invalidHandle )
    {
        num = write(fd, buffer, s);
        tcdrain(fd);
    }

    return num;
}

int main(int argc, char** argv)
{
    char testString[] = "A really long test to see what happens.";
    char buffer[100];
    time_t currentTime;

    int cartridgeSerialPortFileDevice = halUartOpen("/dev/ttyS1", 100000);
    if( cartridgeSerialPortFileDevice == invalidHandle )
    {
        printf("ttyS1 failed\n");
        exit(-1);
    }

    printf("Length of test string (%s) %d\n", testString, sizeof testString);

    currentTime = currentTime_ms();
    halUartWrite(cartridgeSerialPortFileDevice, testString, sizeof testString);
    printf("Elapsed time (ms) after 1st write: %d\n", currentTime_ms() - currentTime);
    halUartWrite(cartridgeSerialPortFileDevice, testString, sizeof testString); // 200 ms delay until this is seen
    printf("Elapsed time (ms) after 2nd write: %d\n", currentTime_ms() - currentTime);

    halUartRead(cartridgeSerialPortFileDevice, buffer, sizeof buffer);
    printf("Finished\n");
}


Thanks,
Prateek Bansal


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100210/c622bd25/attachment-0001.html>

From caglarakyuz at gmail.com  Thu Feb 11 01:04:58 2010
From: caglarakyuz at gmail.com (Caglar Akyuz)
Date: Thu, 11 Feb 2010 09:04:58 +0200
Subject: DM3xx: UART transmit delays
In-Reply-To: <F39349C6FA641B4A831B7BF4EBF4D4E14175A77B@dlee03.ent.ti.com>
References: <F39349C6FA641B4A831B7BF4EBF4D4E14175A77B@dlee03.ent.ti.com>
Message-ID: <201002110904.58135.caglarakyuz@gmail.com>

On Thursday 11 February 2010 12:42:50 am Bansal, Prateek wrote:
> Hi,
> 

Hi,

> When working with DM355 UART1, we are experiencing a strange behavior. When
>  calling the write function for this UART, sometimes it takes 200 ms for
>  the write function to complete. This happens when a write function is
>  called right after another write function. There is not a lot of data sent
>  to the UART at one time, at most 32 bytes. The UART is running at 100,000
>  baud and would take at most 3.2 ms to send this data, not 200 ms.
> 

The exact same problem exists for DM6446, too. Out 1 of 2 write requests to 
the UART is delayed by 200 ms. Haven't investigated the reason though.

Besr regards,
Caglar

> We have tested this in non-Linux environment and found there were no
>  delays. Has anyone came across this issue on UART transmits on DM355
>  devices?
> 
> Below is simple test code that re-creates this issue.
> 
> 
> static int halUartWrite(int fd, uint8_t* buffer, size_t s)
> {
>     int num = 0;
> 
>     if( fd != invalidHandle )
>     {
>         num = write(fd, buffer, s);
>         tcdrain(fd);
>     }
> 
>     return num;
> }
> 
> int main(int argc, char** argv)
> {
>     char testString[] = "A really long test to see what happens.";
>     char buffer[100];
>     time_t currentTime;
> 
>     int cartridgeSerialPortFileDevice = halUartOpen("/dev/ttyS1", 100000);
>     if( cartridgeSerialPortFileDevice == invalidHandle )
>     {
>         printf("ttyS1 failed\n");
>         exit(-1);
>     }
> 
>     printf("Length of test string (%s) %d\n", testString, sizeof
>  testString);
> 
>     currentTime = currentTime_ms();
>     halUartWrite(cartridgeSerialPortFileDevice, testString, sizeof
>  testString); printf("Elapsed time (ms) after 1st write: %d\n",
>  currentTime_ms() - currentTime);
>  halUartWrite(cartridgeSerialPortFileDevice, testString, sizeof
>  testString); // 200 ms delay until this is seen printf("Elapsed time (ms)
>  after 2nd write: %d\n", currentTime_ms() - currentTime);
> 
>     halUartRead(cartridgeSerialPortFileDevice, buffer, sizeof buffer);
>     printf("Finished\n");
> }
> 
> 
> Thanks,
> Prateek Bansal
> 

From rohan_javed at yahoo.co.uk  Thu Feb 11 01:14:14 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Wed, 10 Feb 2010 23:14:14 -0800 (PST)
Subject: DM6446:how to integrate the DSPLINK to GIT kernel
Message-ID: <598925.44150.qm@web24101.mail.ird.yahoo.com>

anyone knows how to use DSP link with the git kernel any page or useful page 


Regard's
Rohan Tabish



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100210/d10aa128/attachment.html>

From bjorn.forsman at gmail.com  Thu Feb 11 02:42:49 2010
From: bjorn.forsman at gmail.com (=?UTF-8?Q?Bj=C3=B8rn_Forsman?=)
Date: Thu, 11 Feb 2010 09:42:49 +0100
Subject: DM6446:how to integrate the DSPLINK to GIT kernel
In-Reply-To: <598925.44150.qm@web24101.mail.ird.yahoo.com>
References: <598925.44150.qm@web24101.mail.ird.yahoo.com>
Message-ID: <5f2b61002110042k408e070fpc1a06271e5c7cc50@mail.gmail.com>

Hi Rohan,

On 11 February 2010 08:14, rohan tabish <rohan_javed at yahoo.co.uk> wrote:

> anyone knows how to use DSP link with the git kernel any page or useful
> page
>
>
OpenEmbedded[1] can build cmem+dsplink with git/Arago-kernel[2].

[1] http://wiki.openembedded.net/index.php/Main_Page
[2] http://arago-project.org/wiki/index.php/Main_Page

Best regards,
Bj?rn Forsman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100211/63a9ef42/attachment.html>

From brian at murphy.dk  Thu Feb 11 03:58:47 2010
From: brian at murphy.dk (Brian Murphy)
Date: Thu, 11 Feb 2010 10:58:47 +0100
Subject: DM3xx: UART transmit delays
Message-ID: <b41414a41002110158r2945cb3bgbacef1cd37c99688@mail.gmail.com>

Hi Folks,
We have been working with L137 and there is an issue where the serial
driver handles
the UART  in a very bad way. This may be the same issue as described
in the other
two mails on this thread.
The issue is that the serial driver 8250.c expects the uart to
generate a fifo empty interrupt
if the FIFO is empty and interrupts are enabled. The UART in the L137
only generates a FIFO
empty interrupt the first time. The serial driver handles this
situation by starting a timer which
times out after 200ms when interrupts are enabled and only then begins
to transmit.
I have rewritten the interrupt handling so the driver maintains a flag
which tells whether the UART
is currently transmitting or not. If not then we begin filling the TX
fifo immediately (we do not
wait for an interrupt which never comes). This fixes the transmit
latency issue for us.

I have attached the patch. It is against the linux-davinci git at
kernel.org as of friday last week.

I have sent the patch to the linux-serial list with no response.

Could you who have problems with serial performance test the patch? I
can try to send it
again to linux-serial if I get good feedback from you.

/Brian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-performance-fix.patch
Type: text/x-diff
Size: 11105 bytes
Desc: not available
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100211/88f6bdf1/attachment-0001.bin>

From caglarakyuz at gmail.com  Thu Feb 11 11:19:17 2010
From: caglarakyuz at gmail.com (Caglar Akyuz)
Date: Thu, 11 Feb 2010 19:19:17 +0200
Subject: DM3xx: UART transmit delays
In-Reply-To: <b41414a41002110158r2945cb3bgbacef1cd37c99688@mail.gmail.com>
References: <b41414a41002110158r2945cb3bgbacef1cd37c99688@mail.gmail.com>
Message-ID: <201002111919.17188.caglarakyuz@gmail.com>

On Thursday 11 February 2010 11:58:47 am Brian Murphy wrote:
> Hi Folks,
> We have been working with L137 and there is an issue where the serial
> driver handles
> the UART  in a very bad way. This may be the same issue as described
> in the other
> two mails on this thread.
> The issue is that the serial driver 8250.c expects the uart to
> generate a fifo empty interrupt
> if the FIFO is empty and interrupts are enabled. The UART in the L137
> only generates a FIFO
> empty interrupt the first time. The serial driver handles this
> situation by starting a timer which
> times out after 200ms when interrupts are enabled and only then begins
> to transmit.
> I have rewritten the interrupt handling so the driver maintains a flag
> which tells whether the UART
> is currently transmitting or not. If not then we begin filling the TX
> fifo immediately (we do not
> wait for an interrupt which never comes). This fixes the transmit
> latency issue for us.
> 
> I have attached the patch. It is against the linux-davinci git at
> kernel.org as of friday last week.
> 
> I have sent the patch to the linux-serial list with no response.
> 
> Could you who have problems with serial performance test the patch? I
> can try to send it
> again to linux-serial if I get good feedback from you.
> 

This patch solves the problem for DM6446. Thanks for sharing your work.

Best Regards,
Caglar

> /Brian
> 

From ramiro at lisha.ufsc.br  Thu Feb 11 14:01:53 2010
From: ramiro at lisha.ufsc.br (Ramiro Polla)
Date: Thu, 11 Feb 2010 18:01:53 -0200
Subject: 76Mb memory limit on dm365
In-Reply-To: <92CDD168D1E81F4F9D3839DC45903FC66F42E6EA@dlee03.ent.ti.com>
References: <f460258d1002101212s24727a72xaf135805679b0da6@mail.gmail.com>
	<F1EE99FC-4785-451B-A6C7-F201CC8C12DB@ridgerun.com>
	<92CDD168D1E81F4F9D3839DC45903FC66F42E6EA@dlee03.ent.ti.com>
Message-ID: <f460258d1002111201n1ccd05dtf8e16acdf0084cb3@mail.gmail.com>

Hi,

Thanks for the information. To give more memory in the bootargs, I
tried to use less memory for the cmem pools. I want to know the exact
number of pools for my application (I use the h264 decoder). I see
that the cmem buffers needed by the decoder are described in SPRS544
in Table 7. It describes the sizes of the buffers, but not the amount.
How were the number of buffers for the default loadmodules.sh that
ships with the board determined?

Thanks,
Ramiro Polla

On Wed, Feb 10, 2010 at 6:52 PM, Ring, Chris <cring at ti.com> wrote:
> FYI, if you're not familiar with CMEM, there's an overview here:
> http://tiexpressdsp.com/index.php/CMEM_Overview
>
> Chris
>
>> -----Original Message-----
>> From:
>> davinci-linux-open-source-bounces+cring=ti.com at linux.davincids
>> p.com
>> [mailto:davinci-linux-open-source-bounces+cring=ti.com at linux.d
>> avincidsp.com] On Behalf Of Diego Dompe
>> Sent: Wednesday, February 10, 2010 12:30 PM
>> To: Ramiro Polla
>> Cc: davinci-linux-open-source at linux.davincidsp.com
>> Subject: Re: 76Mb memory limit on dm365
>>
>> Ramiro,
>>
>> This limit is due the cmem buffers being allocated to this
>> location. If you have more RAM available on your final board,
>> you can just move the cmem buffers to another location and
>> give more memory to the Linux kernel.
>>
>> Diego
>>
>> On Feb 10, 2010, at 2:12 PM, Ramiro Polla wrote:
>>
>> > Hi,
>> >
>> > Some documentation for the dm365 (for example
>> > dvsdk_2_10_01_18/dm365_2_10_01_18_release_notes.html)
>> suggests setting
>> > "mem=76M" in the bootargs.
>> >
>> > Why is there such a limit? Isn't there more memory
>> available in the board?
>> >
>> > Any pointer to more complete documentation on the subject
>> is welcome.
>> >
>> > Ramiro Polla
>> > _______________________________________________
>> > Davinci-linux-open-source mailing list
>> > Davinci-linux-open-source at linux.davincidsp.com
>> >
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>>
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source at linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>>

From sshtylyov at ru.mvista.com  Fri Feb 12 13:52:34 2010
From: sshtylyov at ru.mvista.com (Sergei Shtylyov)
Date: Fri, 12 Feb 2010 23:52:34 +0400
Subject: [PATCH v4] OHCI: DA8xx/OMAP-L1x glue layer
Message-ID: <201002122252.34541.sshtylyov@ru.mvista.com>

Texas Instruments DA8xx/OMAP-L1x OHCI glue layer.

This OHCI implementation is not without quirks: there's only one physical port
despite the root hub reporting two; the port's power control and over-current
status bits are not connected to any pins, however, at least on the DA830 EVM
board, those signals are connected via GPIO, thus the provision was made for
overriding the OHCI port power and over-current bits at the board level...

Signed-off-by: Mikhail Cherkashin <mcherkashin at ru.mvista.com>
Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>

---
The patch is against the recent Linus' tree.

WARNING: the MUSB and OHCI drivers will only work if your boot loader leaves
the DA8xx boot configuration registers unlocked, otherwise they will lock up
the kernel!

Changes since the previous take:
- fixed reject in drivers/usb/Kconfig...

 drivers/usb/Kconfig           |    1 
 drivers/usb/host/ohci-da8xx.c |  456 ++++++++++++++++++++++++++++++++++++++++++
 drivers/usb/host/ohci-hcd.c   |    5 
 3 files changed, 462 insertions(+)

Index: linux-2.6/drivers/usb/Kconfig
===================================================================
--- linux-2.6.orig/drivers/usb/Kconfig
+++ linux-2.6/drivers/usb/Kconfig
@@ -39,6 +39,7 @@ config USB_ARCH_HAS_OHCI
 	default y if ARCH_PNX4008 && I2C
 	default y if MFD_TC6393XB
 	default y if ARCH_W90X900
+	default y if ARCH_DAVINCI_DA8XX
 	# PPC:
 	default y if STB03xxx
 	default y if PPC_MPC52xx
Index: linux-2.6/drivers/usb/host/ohci-da8xx.c
===================================================================
--- /dev/null
+++ linux-2.6/drivers/usb/host/ohci-da8xx.c
@@ -0,0 +1,456 @@
+/*
+ * OHCI HCD (Host Controller Driver) for USB.
+ *
+ * TI DA8xx (OMAP-L1x) Bus Glue
+ *
+ * Derived from: ohci-omap.c and ohci-s3c2410.c
+ * Copyright (C) 2008-2009 MontaVista Software, Inc. <source at mvista.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/jiffies.h>
+#include <linux/platform_device.h>
+#include <linux/clk.h>
+
+#include <mach/da8xx.h>
+#include <mach/usb.h>
+
+#ifndef CONFIG_ARCH_DAVINCI_DA8XX
+#error "This file is DA8xx bus glue.  Define CONFIG_ARCH_DAVINCI_DA8XX."
+#endif
+
+#define CFGCHIP2	DA8XX_SYSCFG_VIRT(DA8XX_CFGCHIP2_REG)
+
+static struct clk *usb11_clk;
+static struct clk *usb20_clk;
+
+/* Over-current indicator change bitmask */
+static volatile u16 ocic_mask;
+
+static void ohci_da8xx_clock(int on)
+{
+	u32 cfgchip2;
+
+	cfgchip2 = __raw_readl(CFGCHIP2);
+	if (on) {
+		clk_enable(usb11_clk);
+
+		/*
+		 * If USB 1.1 reference clock is sourced from USB 2.0 PHY, we
+		 * need to enable the USB 2.0 module clocking, start its PHY,
+		 * and not allow it to stop the clock during USB 2.0 suspend.
+		 */
+		if (!(cfgchip2 & CFGCHIP2_USB1PHYCLKMUX)) {
+			clk_enable(usb20_clk);
+
+			cfgchip2 &= ~(CFGCHIP2_RESET | CFGCHIP2_PHYPWRDN);
+			cfgchip2 |= CFGCHIP2_PHY_PLLON;
+			__raw_writel(cfgchip2, CFGCHIP2);
+
+			pr_info("Waiting for USB PHY clock good...\n");
+			while (!(__raw_readl(CFGCHIP2) & CFGCHIP2_PHYCLKGD))
+				cpu_relax();
+		}
+
+		/* Enable USB 1.1 PHY */
+		cfgchip2 |= CFGCHIP2_USB1SUSPENDM;
+	} else {
+		clk_disable(usb11_clk);
+		if (!(cfgchip2 & CFGCHIP2_USB1PHYCLKMUX))
+			clk_disable(usb20_clk);
+
+		/* Disable USB 1.1 PHY */
+		cfgchip2 &= ~CFGCHIP2_USB1SUSPENDM;
+	}
+	__raw_writel(cfgchip2, CFGCHIP2);
+}
+
+/*
+ * Handle the port over-current indicator change.
+ */
+static void ohci_da8xx_ocic_handler(struct da8xx_ohci_root_hub *hub,
+				    unsigned port)
+{
+	ocic_mask |= 1 << port;
+
+	/* Once over-current is detected, the port needs to be powered down */
+	if (hub->get_oci(port) > 0)
+		hub->set_power(port, 0);
+}
+
+static int ohci_da8xx_init(struct usb_hcd *hcd)
+{
+	struct device *dev		= hcd->self.controller;
+	struct da8xx_ohci_root_hub *hub	= dev->platform_data;
+	struct ohci_hcd	*ohci		= hcd_to_ohci(hcd);
+	int result;
+	u32 rh_a;
+
+	dev_dbg(dev, "starting USB controller\n");
+
+	ohci_da8xx_clock(1);
+
+	/*
+	 * DA8xx only have 1 port connected to the pins but the HC root hub
+	 * register A reports 2 ports, thus we'll have to override it...
+	 */
+	ohci->num_ports = 1;
+
+	result = ohci_init(ohci);
+	if (result < 0)
+		return result;
+
+	/*
+	 * Since we're providing a board-specific root hub port power control
+	 * and over-current reporting, we have to override the HC root hub A
+	 * register's default value, so that ohci_hub_control() could return
+	 * the correct hub descriptor...
+	 */
+	rh_a = ohci_readl(ohci, &ohci->regs->roothub.a);
+	if (hub->set_power) {
+		rh_a &= ~RH_A_NPS;
+		rh_a |=  RH_A_PSM;
+	}
+	if (hub->get_oci) {
+		rh_a &= ~RH_A_NOCP;
+		rh_a |=  RH_A_OCPM;
+	}
+	rh_a &= ~RH_A_POTPGT;
+	rh_a |= hub->potpgt << 24;
+	ohci_writel(ohci, rh_a, &ohci->regs->roothub.a);
+
+	return result;
+}
+
+static void ohci_da8xx_stop(struct usb_hcd *hcd)
+{
+	ohci_stop(hcd);
+	ohci_da8xx_clock(0);
+}
+
+static int ohci_da8xx_start(struct usb_hcd *hcd)
+{
+	struct ohci_hcd	*ohci		= hcd_to_ohci(hcd);
+	int result;
+
+	result = ohci_run(ohci);
+	if (result < 0)
+		ohci_da8xx_stop(hcd);
+
+	return result;
+}
+
+/*
+ * Update the status data from the hub with the over-current indicator change.
+ */
+static int ohci_da8xx_hub_status_data(struct usb_hcd *hcd, char *buf)
+{
+	int length		= ohci_hub_status_data(hcd, buf);
+
+	/* See if we have OCIC bit set on port 1 */
+	if (ocic_mask & (1 << 1)) {
+		dev_dbg(hcd->self.controller, "over-current indicator change "
+			"on port 1\n");
+
+		if (!length)
+			length = 1;
+
+		buf[0] |= 1 << 1;
+	}
+	return length;
+}
+
+/*
+ * Look at the control requests to the root hub and see if we need to override.
+ */
+static int ohci_da8xx_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
+				  u16 wIndex, char *buf, u16 wLength)
+{
+	struct device *dev		= hcd->self.controller;
+	struct da8xx_ohci_root_hub *hub	= dev->platform_data;
+	int temp;
+
+	switch (typeReq) {
+	case GetPortStatus:
+		/* Check the port number */
+		if (wIndex != 1)
+			break;
+
+		dev_dbg(dev, "GetPortStatus(%u)\n", wIndex);
+
+		temp = roothub_portstatus(hcd_to_ohci(hcd), wIndex - 1);
+
+		/* The port power status (PPS) bit defaults to 1 */
+		if (hub->get_power && hub->get_power(wIndex) == 0)
+			temp &= ~RH_PS_PPS;
+
+		/* The port over-current indicator (POCI) bit is always 0 */
+		if (hub->get_oci && hub->get_oci(wIndex) > 0)
+			temp |=  RH_PS_POCI;
+
+		/* The over-current indicator change (OCIC) bit is 0 too */
+		if (ocic_mask & (1 << wIndex))
+			temp |=  RH_PS_OCIC;
+
+		put_unaligned(cpu_to_le32(temp), (__le32 *)buf);
+		return 0;
+	case SetPortFeature:
+		temp = 1;
+		goto check_port;
+	case ClearPortFeature:
+		temp = 0;
+
+check_port:
+		/* Check the port number */
+		if (wIndex != 1)
+			break;
+
+		switch (wValue) {
+		case USB_PORT_FEAT_POWER:
+			dev_dbg(dev, "%sPortFeature(%u): %s\n",
+				temp ? "Set" : "Clear", wIndex, "POWER");
+
+			if (!hub->set_power)
+				return -EPIPE;
+
+			return hub->set_power(wIndex, temp) ? -EPIPE : 0;
+		case USB_PORT_FEAT_C_OVER_CURRENT:
+			dev_dbg(dev, "%sPortFeature(%u): %s\n",
+				temp ? "Set" : "Clear", wIndex,
+				"C_OVER_CURRENT");
+
+			if (temp)
+				ocic_mask |= 1 << wIndex;
+			else
+				ocic_mask &= ~(1 << wIndex);
+			return 0;
+		}
+	}
+
+	return ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+}
+
+static const struct hc_driver ohci_da8xx_hc_driver = {
+	.description		= hcd_name,
+	.product_desc		= "DA8xx OHCI",
+	.hcd_priv_size		= sizeof(struct ohci_hcd),
+
+	/*
+	 * generic hardware linkage
+	 */
+	.irq			= ohci_irq,
+	.flags			= HCD_USB11 | HCD_MEMORY,
+
+	/*
+	 * basic lifecycle operations
+	 */
+	.reset			= ohci_da8xx_init,
+	.start			= ohci_da8xx_start,
+	.stop			= ohci_da8xx_stop,
+	.shutdown		= ohci_shutdown,
+
+	/*
+	 * managing i/o requests and associated device resources
+	 */
+	.urb_enqueue		= ohci_urb_enqueue,
+	.urb_dequeue		= ohci_urb_dequeue,
+	.endpoint_disable	= ohci_endpoint_disable,
+
+	/*
+	 * scheduling support
+	 */
+	.get_frame_number	= ohci_get_frame,
+
+	/*
+	 * root hub support
+	 */
+	.hub_status_data	= ohci_da8xx_hub_status_data,
+	.hub_control		= ohci_da8xx_hub_control,
+
+#ifdef	CONFIG_PM
+	.bus_suspend		= ohci_bus_suspend,
+	.bus_resume		= ohci_bus_resume,
+#endif
+	.start_port_reset	= ohci_start_port_reset,
+};
+
+/*-------------------------------------------------------------------------*/
+
+
+/**
+ * usb_hcd_da8xx_probe - initialize DA8xx-based HCDs
+ * Context: !in_interrupt()
+ *
+ * Allocates basic resources for this USB host controller, and
+ * then invokes the start() method for the HCD associated with it
+ * through the hotplug entry's driver_data.
+ */
+static int usb_hcd_da8xx_probe(const struct hc_driver *driver,
+			       struct platform_device *pdev)
+{
+	struct da8xx_ohci_root_hub *hub	= pdev->dev.platform_data;
+	struct usb_hcd	*hcd;
+	struct resource *mem;
+	int error, irq;
+
+	if (hub == NULL)
+		return -ENODEV;
+
+	usb11_clk = clk_get(&pdev->dev, "usb11");
+	if (IS_ERR(usb11_clk))
+		return PTR_ERR(usb11_clk);
+
+	usb20_clk = clk_get(&pdev->dev, "usb20");
+	if (IS_ERR(usb20_clk)) {
+		error = PTR_ERR(usb20_clk);
+		goto err0;
+	}
+
+	hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
+	if (!hcd) {
+		error = -ENOMEM;
+		goto err1;
+	}
+
+	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!mem) {
+		error = -ENODEV;
+		goto err2;
+	}
+	hcd->rsrc_start = mem->start;
+	hcd->rsrc_len = mem->end - mem->start + 1;
+
+	if (!request_mem_region(hcd->rsrc_start, hcd->rsrc_len, hcd_name)) {
+		dev_dbg(&pdev->dev, "request_mem_region failed\n");
+		error = -EBUSY;
+		goto err2;
+	}
+
+	hcd->regs = ioremap(hcd->rsrc_start, hcd->rsrc_len);
+	if (!hcd->regs) {
+		dev_err(&pdev->dev, "ioremap failed\n");
+		error = -ENOMEM;
+		goto err3;
+	}
+
+	ohci_hcd_init(hcd_to_ohci(hcd));
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		error = -ENODEV;
+		goto err4;
+	}
+	error = usb_add_hcd(hcd, irq, IRQF_DISABLED);
+	if (error)
+		goto err4;
+
+	if (hub->ocic_notify) {
+		error = hub->ocic_notify(ohci_da8xx_ocic_handler);
+		if (!error)
+			return 0;
+	}
+
+	usb_remove_hcd(hcd);
+err4:
+	iounmap(hcd->regs);
+err3:
+	release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
+err2:
+	usb_put_hcd(hcd);
+err1:
+	clk_put(usb20_clk);
+err0:
+	clk_put(usb11_clk);
+	return error;
+}
+
+/**
+ * usb_hcd_da8xx_remove - shutdown processing for DA8xx-based HCDs
+ * @dev: USB Host Controller being removed
+ * Context: !in_interrupt()
+ *
+ * Reverses the effect of usb_hcd_da8xx_probe(), first invoking
+ * the HCD's stop() method.  It is always called from a thread
+ * context, normally "rmmod", "apmd", or something similar.
+ */
+static inline void
+usb_hcd_da8xx_remove(struct usb_hcd *hcd, struct platform_device *pdev)
+{
+	struct da8xx_ohci_root_hub *hub	= pdev->dev.platform_data;
+
+	hub->ocic_notify(NULL);
+	usb_remove_hcd(hcd);
+	iounmap(hcd->regs);
+	release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
+	usb_put_hcd(hcd);
+	clk_put(usb20_clk);
+	clk_put(usb11_clk);
+}
+
+static int ohci_hcd_da8xx_drv_probe(struct platform_device *dev)
+{
+	return usb_hcd_da8xx_probe(&ohci_da8xx_hc_driver, dev);
+}
+
+static int ohci_hcd_da8xx_drv_remove(struct platform_device *dev)
+{
+	struct usb_hcd	*hcd = platform_get_drvdata(dev);
+
+	usb_hcd_da8xx_remove(hcd, dev);
+	platform_set_drvdata(dev, NULL);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM
+static int ohci_da8xx_suspend(struct platform_device *dev, pm_message_t message)
+{
+	struct usb_hcd	*hcd	= platform_get_drvdata(dev);
+	struct ohci_hcd	*ohci	= hcd_to_ohci(hcd);
+
+	if (time_before(jiffies, ohci->next_statechange))
+		msleep(5);
+	ohci->next_statechange = jiffies;
+
+	ohci_da8xx_clock(0);
+	hcd->state = HC_STATE_SUSPENDED;
+	dev->dev.power.power_state = PMSG_SUSPEND;
+	return 0;
+}
+
+static int ohci_da8xx_resume(struct platform_device *dev)
+{
+	struct usb_hcd	*hcd	= platform_get_drvdata(dev);
+	struct ohci_hcd	*ohci	= hcd_to_ohci(hcd);
+
+	if (time_before(jiffies, ohci->next_statechange))
+		msleep(5);
+	ohci->next_statechange = jiffies;
+
+	ohci_da8xx_clock(1);
+	dev->dev.power.power_state = PMSG_ON;
+	usb_hcd_resume_root_hub(hcd);
+	return 0;
+}
+#endif
+
+/*
+ * Driver definition to register with platform structure.
+ */
+static struct platform_driver ohci_hcd_da8xx_driver = {
+	.probe		= ohci_hcd_da8xx_drv_probe,
+	.remove		= ohci_hcd_da8xx_drv_remove,
+	.shutdown 	= usb_hcd_platform_shutdown,
+#ifdef	CONFIG_PM
+	.suspend	= ohci_da8xx_suspend,
+	.resume		= ohci_da8xx_resume,
+#endif
+	.driver		= {
+		.owner	= THIS_MODULE,
+		.name	= "ohci",
+	},
+};
Index: linux-2.6/drivers/usb/host/ohci-hcd.c
===================================================================
--- linux-2.6.orig/drivers/usb/host/ohci-hcd.c
+++ linux-2.6/drivers/usb/host/ohci-hcd.c
@@ -1051,6 +1051,11 @@ MODULE_LICENSE ("GPL");
 #define PLATFORM_DRIVER		usb_hcd_pnx4008_driver
 #endif
 
+#ifdef CONFIG_ARCH_DAVINCI_DA8XX
+#include "ohci-da8xx.c"
+#define PLATFORM_DRIVER		ohci_hcd_da8xx_driver
+#endif
+
 #if defined(CONFIG_CPU_SUBTYPE_SH7720) || \
     defined(CONFIG_CPU_SUBTYPE_SH7721) || \
     defined(CONFIG_CPU_SUBTYPE_SH7763) || \


From nkansara at irvine-sensors.com  Fri Feb 12 18:46:25 2010
From: nkansara at irvine-sensors.com (Naresh Kansara)
Date: Fri, 12 Feb 2010 16:46:25 -0800
Subject: any idea on /dev/fb/0-3 drivers
Message-ID: <B4CC737B5C72E74A877F33104AD30A6002B364E6@excirvca2a.corp.irvine-sensors.com>

Hello All,

I have loaded Linux version 

2.6.10_mv1401-davinci_evm on my Custom board. 

 

I have also taken the ramdisk image that is provided with DVEVM package,
unzipped it and added some other dvevm programs.

I have also loaded the zipped version of this modified ramdisk.gz file
in to DDR memory at location 0x82000000.

My custom board boots correctly and I am at Linux prompt, but when I do
ls on /dev directory, I do not see /dev/fb/0 through /dev/fb/3. 

The problem I am facing is trying to run "encoderdecoder" software on
custom board; it does not find the drivers  /dev/fb/0

Can somebody give me an idea from where to get the device drivers
/dev/fb/0 through /dev/fb/3.  I could not find it in the ramdisk image
or in any other directory on host.

OR if it needs to be built on Target system, how to build it?

 

Thank you & Regards,

Naresh

 

Naresh Kansara

Irvine Sensors Corporation

phone: (714)-435-8928

email: nkansara at irvine-sensors.com

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100212/41eb2fd0/attachment.html>

From viral at allaboutif.com  Sun Feb 14 22:52:18 2010
From: viral at allaboutif.com (Viral Sachde)
Date: Mon, 15 Feb 2010 10:22:18 +0530
Subject: any idea on /dev/fb/0-3 drivers
In-Reply-To: <B4CC737B5C72E74A877F33104AD30A6002B364E6@excirvca2a.corp.irvine-sensors.com>
References: <B4CC737B5C72E74A877F33104AD30A6002B364E6@excirvca2a.corp.irvine-sensors.com>
Message-ID: <b002f1321002142052me7a7c12t101681690c55e0c6@mail.gmail.com>

On Sat, Feb 13, 2010 at 6:16 AM, Naresh Kansara
<nkansara at irvine-sensors.com> wrote:
> Hello All,
>
> I have loaded Linux version
>
> 2.6.10_mv1401-davinci_evm on my Custom board.
>
>
>
> I have also taken the ramdisk image that is provided with DVEVM package,
> unzipped it and added some other dvevm programs.
>
> I have also loaded the zipped version of this modified ramdisk.gz file in to
> DDR memory at location 0x82000000.
>
> My custom board boots correctly and I am at Linux prompt, but when I do ls
> on /dev directory, I do not see /dev/fb/0 through /dev/fb/3.
>
> The problem I am facing is trying to run ?encoderdecoder? software on custom
> board; it does not find the drivers ?/dev/fb/0
>
> Can somebody give me an idea from where to get the device drivers /dev/fb/0
> through /dev/fb/3.? I could not find it in the ramdisk image or in any other
> directory on host.
>
> OR if it needs to be built on Target system, how to build it?
>
>
>
> Thank you & Regards,
>
> Naresh
>
>
>
> Naresh Kansara
>



Hi Naresh,

I suggest you to check
1. "ls /sys/class/graphics/fb* " or
2. "cat /proc/devices  | grep fb "
Also do kernel log / dmesg shows any fb related stuff.

If above logs, shows presence of FB, just create /dev/fb/* using mknod.
Otherwise, you may not have enabled fb driver in kernel config in
driver->graphics tab.

Regards, Viral

From kirthikaiitm at gmail.com  Mon Feb 15 01:12:17 2010
From: kirthikaiitm at gmail.com (Kiruthika)
Date: Mon, 15 Feb 2010 12:42:17 +0530 (IST)
Subject: Hey Davinci-Linux-Open-Source@linux.Davincidsp.Com, I forgot to
	mention...
Message-ID: <5642768.1266217937294.JavaMail.Administrator@pg-2>

An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100215/1939e90f/attachment.html>

From AFOUGERAT at aeta-audio.com  Mon Feb 15 02:05:59 2010
From: AFOUGERAT at aeta-audio.com (Arnaud FOUGERAT)
Date: Mon, 15 Feb 2010 09:05:59 +0100
Subject: DM6446:how to integrate the DSPLINK to GIT kernel
In-Reply-To: <mailman.982.1265882332.11996.davinci-linux-open-source@linux.davincidsp.com>
References: <mailman.982.1265882332.11996.davinci-linux-open-source@linux.davincidsp.com>
Message-ID: <FF8FD8FDA65D58478FB325313C0666224862E9@SERVEUR.aeta.local>

Hi,

I done it for the OMAPL137 with the 2.6.32 kernel. You should apply the
patch for the the dsplink and use the kbuild method (see the davinci
wiki).You need to copy some include files for the montavista
distribution in your current kernel. 

Arnaud

Message: 2
Date: Wed, 10 Feb 2010 23:14:14 -0800 (PST)
From: rohan tabish <rohan_javed at yahoo.co.uk>
To: davinci-linux-open-source at linux.davincidsp.com
Subject: DM6446:how to integrate the DSPLINK to GIT kernel
Message-ID: <598925.44150.qm at web24101.mail.ird.yahoo.com>
Content-Type: text/plain; charset="utf-8"

anyone knows how to use DSP link with the git kernel any page or useful
page 


Regard's
Rohan Tabish



      

From idriss.ghodhbane at gmail.com  Mon Feb 15 04:27:47 2010
From: idriss.ghodhbane at gmail.com (Idriss Ghodhbane)
Date: Mon, 15 Feb 2010 11:27:47 +0100
Subject: MPEG4-streaming
Message-ID: <90d17c5d1002150227u4c96931cp5a978f998c38653a@mail.gmail.com>

Hello

I am preparing my enginner diploma. I look for a help to go deeper in the
implementation of a IP video door phone.
In fact, i am asking about how to implement streaming of MPEG4 using
gstreamer and from a camera source on A DaVinci Texas Instruments DM355
Evaluation Module.
Thanks

I.G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100215/bf7a6ae5/attachment.html>

From rohan_javed at yahoo.co.uk  Mon Feb 15 05:15:58 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Mon, 15 Feb 2010 03:15:58 -0800 (PST)
Subject: No subject
Message-ID: <688876.16184.qm@web24104.mail.ird.yahoo.com>




Hello everyone i am using ELDK cross compiler CC enviroment is 

arm-linux-gnueabi-g++

as shown in the example but the problem is that i am unable to do make it sucessfully.
here is the error what i get 




/root/ELDK/usr/bin/../lib/gcc/arm-linux-gnueabi/4.2.2/../../../../arm-linux-gnueabi/bin/ld:
macaw.o: Relocations in generic ELF (EM: 3)

macaw.o: could not read symbols: File in wrong format

collect2: ld returned 1 exit status

make: *** [macaw] Error 1

my make file is 

#CC = /home/arm/arm9ndc/usr/bin/arm-linux-gnueabi-gcc
#PATH=$PATH:/home/arm/armcomplete/arm/usr/bin/

macaw:??? ??? macaw.h MACAW_Changes.h MACAW_Frames.h MACAW_Generic.h \
??? ??? MACAW_PHY.h MACAW_Timers.h\
??? ??? macaw.o MACAW_Generic.o MACAW_PHY.o MACAWTest.o \
??? ??? MACAW_Timers.o SystemClockResolution.o \
################################################################
??? ??? arm-linux-gnueabi-g++ macaw.o \
??? ??? MACAW_Generic.o MACAW_PHY.o MACAWTest.o \
??? ??? MACAW_Timers.o SystemClockResolution.o \
??? ??? -static -lstdc++ -o macaw



Regard's
RT



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100215/f7022bc7/attachment.html>

From rohan_javed at yahoo.co.uk  Mon Feb 15 05:18:20 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Mon, 15 Feb 2010 03:18:20 -0800 (PST)
Subject: HELP:COMPILATION
Message-ID: <641738.50396.qm@web24103.mail.ird.yahoo.com>

Hello everyone i am using ELDK cross compiler CC enviroment is 

arm-linux-gnueabi-g++

as shown in the example but the problem is that i am unable to do make it sucessfully.
here is the error what i get 




/root/ELDK/usr/bin/../lib/gcc/arm-linux-gnueabi/4.2.2/../../../../arm-linux-gnueabi/bin/ld:
macaw.o: Relocations in generic ELF (EM: 3)

macaw.o: could not read symbols: File in wrong format

collect2: ld returned 1 exit status

make: *** [macaw] Error 1

my make file is 


macaw:??? ??? macaw.h MACAW_Changes.h MACAW_Frames.h MACAW_Generic.h \
??? ??? MACAW_PHY.h MACAW_Timers.h\
??? ??? macaw.o MACAW_Generic.o MACAW_PHY.o MACAWTest.o \
??? ??? MACAW_Timers.o SystemClockResolution.o \
################################################################
??? ??? arm-linux-gnueabi-g++ macaw.o \
??? ??? MACAW_Generic.o MACAW_PHY.o MACAWTest.o \
??? ??? MACAW_Timers.o SystemClockResolution.o \
??? ??? -static -lstdc++ -o macaw

when i change arm-linux-gnueabi-g++ to only g++ it gets sucessfully compiled

Regard's
RT


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100215/d7dcdb71/attachment.html>

From pan at nt.tu-darmstadt.de  Mon Feb 15 05:20:42 2010
From: pan at nt.tu-darmstadt.de (Vladimir Pantelic)
Date: Mon, 15 Feb 2010 12:20:42 +0100
Subject: MPEG4-streaming
In-Reply-To: <90d17c5d1002150227u4c96931cp5a978f998c38653a@mail.gmail.com>
References: <90d17c5d1002150227u4c96931cp5a978f998c38653a@mail.gmail.com>
Message-ID: <4B792E0A.9020509@nt.tu-darmstadt.de>

Idriss Ghodhbane wrote:
> Hello
>
> I am preparing my enginner diploma. I look for a help to go deeper in
> the implementation of a IP video door phone.
> In fact, i am asking about how to implement streaming of MPEG4 using
> gstreamer and from a camera source on A DaVinci Texas Instruments DM355
> Evaluation Module.

and? you have to do it without using google? that's hard....



From sameer.subscriptions at damagehead.com  Mon Feb 15 06:03:34 2010
From: sameer.subscriptions at damagehead.com (Sameer Naik)
Date: Mon, 15 Feb 2010 17:33:34 +0530
Subject: CMEM Memory Map
Message-ID: <1c12dfe71002150403m4d0d6be6p946e8f38e65df868@mail.gmail.com>

Hi,
I am using /dev/cmem module to allocate memory for the dsp algorithms.
My current cmem map looks like this

# insert cmemk, tell it to occupy physical 118MB-128MB (10M).
insmod cmemk.ko phys_start=0x87600000 phys_end=0x88000000
pools=1x3600000,5x829440,2x1244160,1x40960,2x8192

Yes, this is the default map that is specified in the dvsdk 2.0
release, i haven't changed it yet.
Now i want to make sure that the cmem can allocate atleast 16 buffers
of 829440 bytes as H.264 Main Profile can have a atmost 16 reference
frames for B-frames. I am dealing with a H.264 MP Level 3.0 decoder
(maximum resolution 720x576).

One way to achieve this is my simply increasing the cmem memory, so
that the module load line, for example, would look like this:

1.
# insert cmemk, tell it to occupy physical 109MB-128MB (19M).
insmod cmemk.ko phys_start=0x86D00000 phys_end=0x88000000
pools=1x3600000,16x829440,2x1244160,1x40960,2x8192

2.
The other way is to get rid of all other pools that are existing, and
keep only the 829440 bytes sized pool, eg.
# insert cmemk, tell it to occupy physical 115MB-128MB (13M).
insmod cmemk.ko phys_start=0x87300000 phys_end=0x88000000 pools=16x829440

At least currently i am not allocating buffers other than of size
829440, using CMEM, but at the same time i am not sure whether any of
the dsp algorithms allocated memory using CMEM (by guess would be no).
I would want this to be clarified, and whether it is safe to go with
the second option, as it allows better memory utilisation.

Please comment.
Regards
~Sameer

From sureshs at tataelxsi.co.in  Mon Feb 15 06:22:57 2010
From: sureshs at tataelxsi.co.in (sureshs)
Date: Mon, 15 Feb 2010 17:52:57 +0530
Subject: MPEG4-streaming
In-Reply-To: <4B792E0A.9020509@nt.tu-darmstadt.de>
Message-ID: <000f01caae39$9c5b04a0$15053c0a@telxsi.com>

Hi,

We have used live555 to stream the MPEG4. 

Regards,
Suresh .S



-----Original Message-----
From: davinci-linux-open-source-bounces at linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces at linux.davincidsp.com]On Behalf
Of Vladimir Pantelic
Sent: Monday, February 15, 2010 4:51 PM
To: Davinci-linux-open-source at linux.davincidsp.com
Subject: Re: MPEG4-streaming


Idriss Ghodhbane wrote:
> Hello
>
> I am preparing my enginner diploma. I look for a help to go deeper in
> the implementation of a IP video door phone.
> In fact, i am asking about how to implement streaming of MPEG4 using
> gstreamer and from a camera source on A DaVinci Texas Instruments DM355
> Evaluation Module.

and? you have to do it without using google? that's hard....


_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source



From pan at nt.tu-darmstadt.de  Mon Feb 15 06:26:49 2010
From: pan at nt.tu-darmstadt.de (Vladimir Pantelic)
Date: Mon, 15 Feb 2010 13:26:49 +0100
Subject: CMEM Memory Map
In-Reply-To: <1c12dfe71002150403m4d0d6be6p946e8f38e65df868@mail.gmail.com>
References: <1c12dfe71002150403m4d0d6be6p946e8f38e65df868@mail.gmail.com>
Message-ID: <4B793D89.3020001@nt.tu-darmstadt.de>

Sameer Naik wrote:

> One way to achieve this is my simply increasing the cmem memory, so
> that the module load line, for example, would look like this:
>
> 1.
> # insert cmemk, tell it to occupy physical 109MB-128MB (19M).
> insmod cmemk.ko phys_start=0x86D00000 phys_end=0x88000000
> pools=1x3600000,16x829440,2x1244160,1x40960,2x8192
>
> 2.
> The other way is to get rid of all other pools that are existing, and
> keep only the 829440 bytes sized pool, eg.
> # insert cmemk, tell it to occupy physical 115MB-128MB (13M).
> insmod cmemk.ko phys_start=0x87300000 phys_end=0x88000000 pools=16x829440
>
> At least currently i am not allocating buffers other than of size
> 829440, using CMEM, but at the same time i am not sure whether any of
> the dsp algorithms allocated memory using CMEM (by guess would be no).

there should be at least one other CMEM buffer to pass the h264 data fro
the ARM to the DSP. There is something in /proc or /sys where you can
see the cmem memory usage...

Also, with CE_DEBUG=2|3 you should be able to see all cmem allocations
that your codec/setup does.


From bksingh at ti.com  Mon Feb 15 06:32:30 2010
From: bksingh at ti.com (Singh, Brijesh)
Date: Mon, 15 Feb 2010 06:32:30 -0600
Subject: MPEG4-streaming
In-Reply-To: <000f01caae39$9c5b04a0$15053c0a@telxsi.com>
References: <4B792E0A.9020509@nt.tu-darmstadt.de>
	<000f01caae39$9c5b04a0$15053c0a@telxsi.com>
Message-ID: <70ABD7B1D427A94DA659B4C84B0F5D4AE3957F55@dlee06.ent.ti.com>

It can be very easily done using gstreamer.ti.com, see pipeline for network streaming.

http://wiki.davincidsp.com/index.php/Example_GStreamer_Pipelines#Network_Streaming

-Brijesh 

-----Original Message-----
From: davinci-linux-open-source-bounces+bksingh=ti.com at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+bksingh=ti.com at linux.davincidsp.com] On Behalf Of sureshs
Sent: Monday, February 15, 2010 6:23 AM
To: 'Vladimir Pantelic'; Davinci-linux-open-source at linux.davincidsp.com
Subject: RE: MPEG4-streaming

Hi,

We have used live555 to stream the MPEG4. 

Regards,
Suresh .S



-----Original Message-----
From: davinci-linux-open-source-bounces at linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces at linux.davincidsp.com]On Behalf Of Vladimir Pantelic
Sent: Monday, February 15, 2010 4:51 PM
To: Davinci-linux-open-source at linux.davincidsp.com
Subject: Re: MPEG4-streaming


Idriss Ghodhbane wrote:
> Hello
>
> I am preparing my enginner diploma. I look for a help to go deeper in 
> the implementation of a IP video door phone.
> In fact, i am asking about how to implement streaming of MPEG4 using 
> gstreamer and from a camera source on A DaVinci Texas Instruments 
> DM355 Evaluation Module.

and? you have to do it without using google? that's hard....


_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From gasparini at imavis.com  Mon Feb 15 06:39:27 2010
From: gasparini at imavis.com (Andrea Gasparini)
Date: Mon, 15 Feb 2010 13:39:27 +0100
Subject: CMEM Memory Map
In-Reply-To: <1c12dfe71002150403m4d0d6be6p946e8f38e65df868@mail.gmail.com>
References: <1c12dfe71002150403m4d0d6be6p946e8f38e65df868@mail.gmail.com>
Message-ID: <201002151339.27561.gasparini@imavis.com>

Sameer Naik spiffera, alle Monday 15 February 2010 circa:
> At least currently i am not allocating buffers other than of size
> 829440, using CMEM, but at the same time i am not sure whether any of
> the dsp algorithms allocated memory using CMEM (by guess would be no).
> I would want this to be clarified, and whether it is safe to go with
> the second option, as it allows better memory utilisation.
> 

I can't completely catch your problem. If you know that you're using only 
these 16 buffers, why can't you go with option 2 ?
Moreover, cmemk raises an error if doesn't exist a free pool to use, so the 
best option is give it a try ;)

bye.
-- 
Andrea Gasparini 
---- ImaVis S.r.l. ----
web: www.imavis.com

From deepaks at hcl.in  Mon Feb 15 06:42:56 2010
From: deepaks at hcl.in (Deepak Shankar-ERS,HCLTech.)
Date: Mon, 15 Feb 2010 18:12:56 +0530
Subject: Admin attention: Duplicate emails.
Message-ID: <CB9F04694AE7FE4DB7C4EA2DC650B2E2A482361307@CHN-HCLT-EVS06.HCLT.CORP.HCL.IN>

Hi, 

For the past few weeks I'm getting copies of every email from the community.
I'm not sure how to fix this duplication. 
I went through the subscription page and could not think of any reason.

Can someone please suggest me, how to fix this? 

Kindly bear with such emails - however I cant find the necessary info in the subscription page and just am wondering if the admin would see this!
 
Cheers,
Deepak Shankar V

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. 
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. 
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have 
received this email in error please delete it and notify the sender immediately. Before opening any mail and 
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

From bjorn.forsman at gmail.com  Mon Feb 15 06:45:51 2010
From: bjorn.forsman at gmail.com (=?UTF-8?Q?Bj=C3=B8rn_Forsman?=)
Date: Mon, 15 Feb 2010 13:45:51 +0100
Subject: HELP:COMPILATION
In-Reply-To: <641738.50396.qm@web24103.mail.ird.yahoo.com>
References: <641738.50396.qm@web24103.mail.ird.yahoo.com>
Message-ID: <5f2b61002150445x108a4a16ne09bc9ae7664f335@mail.gmail.com>

Hi Rohan,

On 15 February 2010 12:18, rohan tabish <rohan_javed at yahoo.co.uk> wrote:

[snip]

> /root/ELDK/usr/bin/../lib/gcc/arm-linux-gnueabi/4.2.2/../../../../arm-linux-gnueabi/bin/ld: macaw.o: Relocations in generic ELF (EM: 3)
> macaw.o: could not read symbols: File in wrong format
> collect2: ld returned 1 exit status
> make: *** [macaw] Error 1

I think there is something wrong with the build setup that is causing
macaw.o to be built for the build host (native compilation). Try 'file
macaw.o' to verify what arch macaw.o is built for.

Best regards,
Bj?rn Forsman

From sameer.subscriptions at damagehead.com  Mon Feb 15 07:44:20 2010
From: sameer.subscriptions at damagehead.com (Sameer Naik)
Date: Mon, 15 Feb 2010 19:14:20 +0530
Subject: issue davincifb_set_attr_blend call in davincifb.c
Message-ID: <1c12dfe71002150544o7e54dc62me5008289dfeff6bb@mail.gmail.com>

Hi,
I have found that while setting the transparency attributes on OSD1
window the following is done:

        /* since bits_per_pixel = 4, this will truncate the width if it is
	 * not even. Similarly r->dx will be rounded down to an even pixel.
	 * ... Do we want to return an error otherwise?
	 */
	width_bytes = r->width * var->bits_per_pixel / 8;
	start = dm->osd1->fb_base + r->dy * info->fix.line_length
	    + r->dx * var->bits_per_pixel / 8;

	blend = (((u8) r->color & 0xf) << 4) | ((u8) r->color);
	while (r->height--) {
		start += info->fix.line_length;
		memset((void *)start, blend, width_bytes);
	}

As you can see that, in the while loop the 'start' is incremented
before memset is done. Is this correct? Shouldn't memset be done
before incrementing start?
Please comment

Regards
~Sameer

From sameer.subscriptions at damagehead.com  Mon Feb 15 07:52:08 2010
From: sameer.subscriptions at damagehead.com (Sameer Naik)
Date: Mon, 15 Feb 2010 19:22:08 +0530
Subject: CMEM Memory Map
In-Reply-To: <201002151339.27561.gasparini@imavis.com>
References: <1c12dfe71002150403m4d0d6be6p946e8f38e65df868@mail.gmail.com> 
	<201002151339.27561.gasparini@imavis.com>
Message-ID: <1c12dfe71002150552o26bc09ddqea6727e8c8723ecc@mail.gmail.com>

thats right!

On Mon, Feb 15, 2010 at 6:09 PM, Andrea Gasparini <gasparini at imavis.com> wrote:
> Sameer Naik spiffera, alle Monday 15 February 2010 circa:
>> At least currently i am not allocating buffers other than of size
>> 829440, using CMEM, but at the same time i am not sure whether any of
>> the dsp algorithms allocated memory using CMEM (by guess would be no).
>> I would want this to be clarified, and whether it is safe to go with
>> the second option, as it allows better memory utilisation.
>>
>
> I can't completely catch your problem. If you know that you're using only
> these 16 buffers, why can't you go with option 2 ?
> Moreover, cmemk raises an error if doesn't exist a free pool to use, so the
> best option is give it a try ;)
>
> bye.
> --
> Andrea Gasparini
> ---- ImaVis S.r.l. ----
> web: www.imavis.com
>

From nick.thompson at ge.com  Mon Feb 15 07:58:32 2010
From: nick.thompson at ge.com (Nick Thompson)
Date: Mon, 15 Feb 2010 13:58:32 +0000
Subject: DM3xx: UART transmit delays
In-Reply-To: <b41414a41002110158r2945cb3bgbacef1cd37c99688@mail.gmail.com>
References: <b41414a41002110158r2945cb3bgbacef1cd37c99688@mail.gmail.com>
Message-ID: <4B795308.7050509@ge.com>

On 11/02/10 09:58, Brian Murphy wrote:
> Hi Folks,
> We have been working with L137 and there is an issue where the serial
> driver handles
> the UART  in a very bad way. This may be the same issue as described
> in the other
> two mails on this thread.
> The issue is that the serial driver 8250.c expects the uart to
> generate a fifo empty interrupt
> if the FIFO is empty and interrupts are enabled. The UART in the L137
> only generates a FIFO
> empty interrupt the first time. The serial driver handles this
> situation by starting a timer which
> times out after 200ms when interrupts are enabled and only then begins
> to transmit.
> I have rewritten the interrupt handling so the driver maintains a flag
> which tells whether the UART
> is currently transmitting or not. If not then we begin filling the TX
> fifo immediately (we do not
> wait for an interrupt which never comes). This fixes the transmit
> latency issue for us.
> 
> I have attached the patch. It is against the linux-davinci git at
> kernel.org as of friday last week.
> 
> I have sent the patch to the linux-serial list with no response.
> 
> Could you who have problems with serial performance test the patch? I
> can try to send it
> again to linux-serial if I get good feedback from you.
> 
> /Brian

Hi Brian,

I know you developed this on the OMAP-L137 and tested it yourself, but
I can confirm I get the same results here on the same device. (I
had to back port it to MVL5 first.)

I spent quite a bit of time studying the patch and I would be happy to
endorse it (though I'm sure that won't count for anything). It has
a few minor style problems, but the approach looks good to me.

I think it will need testing on many more platforms before it is accepted
though :(

Thanks for sharing. The product I am working on requires efficient serial
ports and this patch has saved me a bunch of time.

Nick.

From david.kondrad at legrand.us  Mon Feb 15 08:50:48 2010
From: david.kondrad at legrand.us (david.kondrad at legrand.us)
Date: Mon, 15 Feb 2010 09:50:48 -0500
Subject: CMEM Memory Map
Message-ID: <OF32D03B9E.CE266749-ON852576CB.0050CD0F-852576CB.00518E31@grpleg.it>


Greetings,

As far as I knew, any XDAIS or XDM spec'd algorithms cannot allocate their
own CMEM buffers.
CMEM allocations are always under application control and thus you can
dictate where the shared memory is allocated.

In fact, you could not use CMEM at all and just have a section of memory
that is non-cached and untouched by the kernel,
but it is easier to use the CMEM driver.

What you may be thinking of the is algorithm heap (sometimes called
DDRALGHEAP) and scratch DDR memory.
These can be requested (and hence denied) by the algorithm from the Codec
Server.

Managing total system memory involves more than just kernel + cmem
allocation.

Fortunately, the davinci wiki has a great write-up about it here:
http://wiki.davincidsp.com/index.php/Changing_the_DVEVM_memory_map

Hope this helps,
David

--
DAVID A. KONDRAD
Software Design Engineer
Legrand Home Systems Division
http://www.legrand.us/onq

This email, and any document attached hereto, may contain
confidential and/or privileged information.  If you are not the
intended recipient (or have received this email in error) please
notify the sender immediately and destroy this email.  Any
unauthorized, direct or indirect, copying, disclosure, distribution
or other use of the material or parts thereof is strictly
forbidden.

From cring at ti.com  Mon Feb 15 11:34:50 2010
From: cring at ti.com (Ring, Chris)
Date: Mon, 15 Feb 2010 11:34:50 -0600
Subject: CMEM Memory Map
In-Reply-To: <OF32D03B9E.CE266749-ON852576CB.0050CD0F-852576CB.00518E31@grpleg.it>
References: <OF32D03B9E.CE266749-ON852576CB.0050CD0F-852576CB.00518E31@grpleg.it>
Message-ID: <92CDD168D1E81F4F9D3839DC45903FC66F5D5948@dlee03.ent.ti.com>

Just a quick [hopefully not confusing] clarifying point...

All this discussion is correct assuming all the codecs are 'remote'; that is, all codecs execute on the DSP.  If any codecs are ARM-based (e.g. all the DM355/365 codecs) and managed by Codec Engine, their XDAIS-requested memory will also be allocated from CMEM.

Chris 

> -----Original Message-----
> From: davinci-linux-open-source-bounces at linux.davincidsp.com 
> [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com
> ] On Behalf Of david.kondrad at legrand.us
> Sent: Monday, February 15, 2010 6:51 AM
> To: Sameer Naik
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Subject: RE: CMEM Memory Map
> 
> 
> Greetings,
> 
> As far as I knew, any XDAIS or XDM spec'd algorithms cannot 
> allocate their
> own CMEM buffers.
> CMEM allocations are always under application control and thus you can
> dictate where the shared memory is allocated.
> 
> In fact, you could not use CMEM at all and just have a 
> section of memory
> that is non-cached and untouched by the kernel,
> but it is easier to use the CMEM driver.
> 
> What you may be thinking of the is algorithm heap (sometimes called
> DDRALGHEAP) and scratch DDR memory.
> These can be requested (and hence denied) by the algorithm 
> from the Codec
> Server.
> 
> Managing total system memory involves more than just kernel + cmem
> allocation.
> 
> Fortunately, the davinci wiki has a great write-up about it here:
> http://wiki.davincidsp.com/index.php/Changing_the_DVEVM_memory_map
> 
> Hope this helps,
> David
> 
> --
> DAVID A. KONDRAD
> Software Design Engineer
> Legrand Home Systems Division
> http://www.legrand.us/onq
> 
> This email, and any document attached hereto, may contain
> confidential and/or privileged information.  If you are not the
> intended recipient (or have received this email in error) please
> notify the sender immediately and destroy this email.  Any
> unauthorized, direct or indirect, copying, disclosure, distribution
> or other use of the material or parts thereof is strictly
> forbidden.
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 

From david.kondrad at legrand.us  Mon Feb 15 11:42:26 2010
From: david.kondrad at legrand.us (david.kondrad at legrand.us)
Date: Mon, 15 Feb 2010 12:42:26 -0500
Subject: CMEM Memory Map
In-Reply-To: <92CDD168D1E81F4F9D3839DC45903FC66F5D5948@dlee03.ent.ti.com>
Message-ID: <OFF30A400D.C459C57D-ON852576CB.006106C2-852576CB.006144D0@grpleg.it>

Chris Ring wrote:

> Just a quick [hopefully not confusing] clarifying point...
>
> All this discussion is correct assuming all the codecs are 'remote';
> that is, all codecs execute on the DSP.  If any codecs are ARM-based
(e.g.
> all the DM355/365 codecs) and managed by Codec Engine,
> their XDAIS-requested memory will also be allocated from CMEM.

Good point.
Thanks Chris, I missed that having come from DM644x world.


DAVID A. KONDRAD
Software Design Engineer
Home Systems Division
Legrand, North America

david.kondrad at legrand.us
http://www.legrand.us/onq

This email, and any document attached hereto, may contain
confidential and/or privileged information.  If you are not the
intended recipient (or have received this email in error) please
notify the sender immediately and destroy this email.  Any
unauthorized, direct or indirect, copying, disclosure, distribution
or other use of the material or parts thereof is strictly
forbidden.

From rtivy at ti.com  Mon Feb 15 12:02:24 2010
From: rtivy at ti.com (Tivy, Robert)
Date: Mon, 15 Feb 2010 12:02:24 -0600
Subject: CMEM Memory Map
In-Reply-To: <4B793D89.3020001@nt.tu-darmstadt.de>
References: <1c12dfe71002150403m4d0d6be6p946e8f38e65df868@mail.gmail.com>
	<4B793D89.3020001@nt.tu-darmstadt.de>
Message-ID: <6B8224E84039B140AA662F0BB03616430123824539@dlee04.ent.ti.com>

> -----Original Message-----
> From: davinci-linux-open-source-bounces at linux.davincidsp.com 
> [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com
> ] On Behalf Of Vladimir Pantelic
> Sent: Monday, February 15, 2010 4:27 AM
> To: davinci-linux-open-source at linux.davincidsp.com
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Subject: Re: CMEM Memory Map
> 
> Sameer Naik wrote:
> 
> > One way to achieve this is my simply increasing the cmem memory, so 
> > that the module load line, for example, would look like this:
> >
> > 1.
> > # insert cmemk, tell it to occupy physical 109MB-128MB (19M).
> > insmod cmemk.ko phys_start=0x86D00000 phys_end=0x88000000
> > pools=1x3600000,16x829440,2x1244160,1x40960,2x8192
> >
> > 2.
> > The other way is to get rid of all other pools that are 
> existing, and 
> > keep only the 829440 bytes sized pool, eg.
> > # insert cmemk, tell it to occupy physical 115MB-128MB (13M).
> > insmod cmemk.ko phys_start=0x87300000 phys_end=0x88000000 
> > pools=16x829440
> >
> > At least currently i am not allocating buffers other than of size 
> > 829440, using CMEM, but at the same time i am not sure 
> whether any of 
> > the dsp algorithms allocated memory using CMEM (by guess 
> would be no).
> 
> there should be at least one other CMEM buffer to pass the 
> h264 data fro the ARM to the DSP. There is something in /proc 
> or /sys where you can see the cmem memory usage...

% cat /proc/cmem

Will show you the state of all CMEM buffers.

Regards,

- Rob


From pbansal at ti.com  Mon Feb 15 15:07:14 2010
From: pbansal at ti.com (Bansal, Prateek)
Date: Mon, 15 Feb 2010 15:07:14 -0600
Subject: DM3xx: UART transmit delays
In-Reply-To: <4B795308.7050509@ge.com>
References: <b41414a41002110158r2945cb3bgbacef1cd37c99688@mail.gmail.com>
	<4B795308.7050509@ge.com>
Message-ID: <F39349C6FA641B4A831B7BF4EBF4D4E1418DFFBA@dlee03.ent.ti.com>

Hi Brian,

Thanks for sharing the patch. We tested this on 2.6.32 kernel on DM355 device and it worked fine however we are yet to get this working with 2.6.30 kernel.  

One of the things that we are trying to investigate is why the transmit FIFO empty interrupts are not generated. If you have more visibility into this, I would appreciate any details. Considering we see this issue across number of devices OMAP-L137, DM6446 and DM355, it points to a software issue rather than hardware one but needs to be confirmed. 

 
Prateek

-----Original Message-----
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Nick Thompson
Sent: Monday, February 15, 2010 5:59 AM
To: Brian Murphy
Cc: davinci-linux-open-source at linux.davincidsp.com
Subject: Re: DM3xx: UART transmit delays

On 11/02/10 09:58, Brian Murphy wrote:
> Hi Folks,
> We have been working with L137 and there is an issue where the serial
> driver handles
> the UART  in a very bad way. This may be the same issue as described
> in the other
> two mails on this thread.
> The issue is that the serial driver 8250.c expects the uart to
> generate a fifo empty interrupt
> if the FIFO is empty and interrupts are enabled. The UART in the L137
> only generates a FIFO
> empty interrupt the first time. The serial driver handles this
> situation by starting a timer which
> times out after 200ms when interrupts are enabled and only then begins
> to transmit.
> I have rewritten the interrupt handling so the driver maintains a flag
> which tells whether the UART
> is currently transmitting or not. If not then we begin filling the TX
> fifo immediately (we do not
> wait for an interrupt which never comes). This fixes the transmit
> latency issue for us.
> 
> I have attached the patch. It is against the linux-davinci git at
> kernel.org as of friday last week.
> 
> I have sent the patch to the linux-serial list with no response.
> 
> Could you who have problems with serial performance test the patch? I
> can try to send it
> again to linux-serial if I get good feedback from you.
> 
> /Brian

Hi Brian,

I know you developed this on the OMAP-L137 and tested it yourself, but
I can confirm I get the same results here on the same device. (I
had to back port it to MVL5 first.)

I spent quite a bit of time studying the patch and I would be happy to
endorse it (though I'm sure that won't count for anything). It has
a few minor style problems, but the approach looks good to me.

I think it will need testing on many more platforms before it is accepted
though :(

Thanks for sharing. The product I am working on requires efficient serial
ports and this patch has saved me a bunch of time.

Nick.
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From viral at allaboutif.com  Mon Feb 15 23:20:24 2010
From: viral at allaboutif.com (Viral Sachde)
Date: Tue, 16 Feb 2010 10:50:24 +0530
Subject: any idea on /dev/fb/0-3 drivers
In-Reply-To: <B4CC737B5C72E74A877F33104AD30A6002B36603@excirvca2a.corp.irvine-sensors.com>
References: <B4CC737B5C72E74A877F33104AD30A6002B364E6@excirvca2a.corp.irvine-sensors.com>
	<b002f1321002142052me7a7c12t101681690c55e0c6@mail.gmail.com>
	<B4CC737B5C72E74A877F33104AD30A6002B36603@excirvca2a.corp.irvine-sensors.com>
Message-ID: <b002f1321002152120s47f2c9cevc1646295feb7fce0@mail.gmail.com>

On Mon, Feb 15, 2010 at 10:48 PM, Naresh Kansara
<nkansara at irvine-sensors.com> wrote:
> Hi Viral,
> Thank you for your help. I do see an entry in /proc/devices file as
> 29 fb
>
> Also my kernel .config file has following lines
>
> #Graphinc support
> CONFIG_FB=y
> CONFIG_FB_DAVINCI=y
>
> But when I try to create device using mknod /dev/fb/0 ?on Target ?-- I get following error
>> mknod /dev/fb/0 c 29 0
>> mknod: /dev/fb/0: No such file or directory
>
> Regards,
> Naresh
>

Hi  Naresh,

First, Keep mailing list in loop
Second, Do not top post.
Third, Make /dev/fb in root fs.

- Viral


>
>
>
> -----Original Message-----
> From: Viral Sachde [mailto:viral at allaboutif.com]
> Sent: Sunday, February 14, 2010 8:52 PM
> To: Naresh Kansara
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Subject: Re: any idea on /dev/fb/0-3 drivers
>
> On Sat, Feb 13, 2010 at 6:16 AM, Naresh Kansara
> <nkansara at irvine-sensors.com> wrote:
>> Hello All,
>>
>> I have loaded Linux version
>>
>> 2.6.10_mv1401-davinci_evm on my Custom board.
>>
>>
>>
>> I have also taken the ramdisk image that is provided with DVEVM package,
>> unzipped it and added some other dvevm programs.
>>
>> I have also loaded the zipped version of this modified ramdisk.gz file in to
>> DDR memory at location 0x82000000.
>>
>> My custom board boots correctly and I am at Linux prompt, but when I do ls
>> on /dev directory, I do not see /dev/fb/0 through /dev/fb/3.
>>
>> The problem I am facing is trying to run "encoderdecoder" software on custom
>> board; it does not find the drivers ?/dev/fb/0
>>
>> Can somebody give me an idea from where to get the device drivers /dev/fb/0
>> through /dev/fb/3.? I could not find it in the ramdisk image or in any other
>> directory on host.
>>
>> OR if it needs to be built on Target system, how to build it?
>>
>>
>>
>> Thank you & Regards,
>>
>> Naresh
>>
>>
>>
>> Naresh Kansara
>>
>
>
>
> Hi Naresh,
>
> I suggest you to check
> 1. "ls /sys/class/graphics/fb* " or
> 2. "cat /proc/devices ?| grep fb "
> Also do kernel log / dmesg shows any fb related stuff.
>
> If above logs, shows presence of FB, just create /dev/fb/* using mknod.
> Otherwise, you may not have enabled fb driver in kernel config in
> driver->graphics tab.
>
> Regards, Viral
>

From sameer.subscriptions at damagehead.com  Tue Feb 16 00:36:32 2010
From: sameer.subscriptions at damagehead.com (Sameer Naik)
Date: Tue, 16 Feb 2010 12:06:32 +0530
Subject: CMEM Memory Map
In-Reply-To: <6B8224E84039B140AA662F0BB03616430123824539@dlee04.ent.ti.com>
References: <1c12dfe71002150403m4d0d6be6p946e8f38e65df868@mail.gmail.com> 
	<4B793D89.3020001@nt.tu-darmstadt.de>
	<6B8224E84039B140AA662F0BB03616430123824539@dlee04.ent.ti.com>
Message-ID: <1c12dfe71002152236r3c173c08n3794b73fba10f198@mail.gmail.com>

thanks a lot you guys. your comments are really helpful.

Regards
~Sameer

On Mon, Feb 15, 2010 at 11:32 PM, Tivy, Robert <rtivy at ti.com> wrote:
>> -----Original Message-----
>> From: davinci-linux-open-source-bounces at linux.davincidsp.com
>> [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com
>> ] On Behalf Of Vladimir Pantelic
>> Sent: Monday, February 15, 2010 4:27 AM
>> To: davinci-linux-open-source at linux.davincidsp.com
>> Cc: davinci-linux-open-source at linux.davincidsp.com
>> Subject: Re: CMEM Memory Map
>>
>> Sameer Naik wrote:
>>
>> > One way to achieve this is my simply increasing the cmem memory, so
>> > that the module load line, for example, would look like this:
>> >
>> > 1.
>> > # insert cmemk, tell it to occupy physical 109MB-128MB (19M).
>> > insmod cmemk.ko phys_start=0x86D00000 phys_end=0x88000000
>> > pools=1x3600000,16x829440,2x1244160,1x40960,2x8192
>> >
>> > 2.
>> > The other way is to get rid of all other pools that are
>> existing, and
>> > keep only the 829440 bytes sized pool, eg.
>> > # insert cmemk, tell it to occupy physical 115MB-128MB (13M).
>> > insmod cmemk.ko phys_start=0x87300000 phys_end=0x88000000
>> > pools=16x829440
>> >
>> > At least currently i am not allocating buffers other than of size
>> > 829440, using CMEM, but at the same time i am not sure
>> whether any of
>> > the dsp algorithms allocated memory using CMEM (by guess
>> would be no).
>>
>> there should be at least one other CMEM buffer to pass the
>> h264 data fro the ARM to the DSP. There is something in /proc
>> or /sys where you can see the cmem memory usage...
>
> % cat /proc/cmem
>
> Will show you the state of all CMEM buffers.
>
> Regards,
>
> - Rob
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>

From sameer.subscriptions at damagehead.com  Tue Feb 16 02:58:48 2010
From: sameer.subscriptions at damagehead.com (Sameer Naik)
Date: Tue, 16 Feb 2010 14:28:48 +0530
Subject: issue davincifb_set_attr_blend call in davincifb.c
In-Reply-To: <1c12dfe71002150544o7e54dc62me5008289dfeff6bb@mail.gmail.com>
References: <1c12dfe71002150544o7e54dc62me5008289dfeff6bb@mail.gmail.com>
Message-ID: <1c12dfe71002160058q1eed149ayed56070763b4bf80@mail.gmail.com>

anybody?

On Mon, Feb 15, 2010 at 7:14 PM, Sameer Naik
<sameer.subscriptions at damagehead.com> wrote:
> Hi,
> I have found that while setting the transparency attributes on OSD1
> window the following is done:
>
> ? ? ? ?/* since bits_per_pixel = 4, this will truncate the width if it is
> ? ? ? ? * not even. Similarly r->dx will be rounded down to an even pixel.
> ? ? ? ? * ... Do we want to return an error otherwise?
> ? ? ? ? */
> ? ? ? ?width_bytes = r->width * var->bits_per_pixel / 8;
> ? ? ? ?start = dm->osd1->fb_base + r->dy * info->fix.line_length
> ? ? ? ? ? ?+ r->dx * var->bits_per_pixel / 8;
>
> ? ? ? ?blend = (((u8) r->color & 0xf) << 4) | ((u8) r->color);
> ? ? ? ?while (r->height--) {
> ? ? ? ? ? ? ? ?start += info->fix.line_length;
> ? ? ? ? ? ? ? ?memset((void *)start, blend, width_bytes);
> ? ? ? ?}
>
> As you can see that, in the while loop the 'start' is incremented
> before memset is done. Is this correct? Shouldn't memset be done
> before incrementing start?
> Please comment
>
> Regards
> ~Sameer
>

From idriss.ghodhbane at gmail.com  Tue Feb 16 03:01:32 2010
From: idriss.ghodhbane at gmail.com (Idriss Ghodhbane)
Date: Tue, 16 Feb 2010 10:01:32 +0100
Subject: VoIP&VideoIP
Message-ID: <90d17c5d1002160101q21e3481vb61de7a040971d1a@mail.gmail.com>

Good Morning,

I am working on video and audio streaming on a local network for video IP
door phone .
After documentation, I have noticed that there are 2 tools to implement
the streaming: The Gstreamer and SIP protocol( with SIP stacks pjsip and
Sofiasip).
I am wondering if someone can clarify how these 2 frameworks interact
between them
and how they work simultaneously.

Best Regards
G.I
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100216/1627779e/attachment.html>

From nick.thompson at ge.com  Tue Feb 16 03:14:35 2010
From: nick.thompson at ge.com (Nick Thompson)
Date: Tue, 16 Feb 2010 09:14:35 +0000
Subject: DM3xx: UART transmit delays
In-Reply-To: <F39349C6FA641B4A831B7BF4EBF4D4E1418DFFBA@dlee03.ent.ti.com>
References: <b41414a41002110158r2945cb3bgbacef1cd37c99688@mail.gmail.com>
	<4B795308.7050509@ge.com>
	<F39349C6FA641B4A831B7BF4EBF4D4E1418DFFBA@dlee03.ent.ti.com>
Message-ID: <4B7A61FB.2090300@ge.com>

On 15/02/10 21:07, Bansal, Prateek wrote:
> Hi Brian,
> 
> Thanks for sharing the patch. We tested this on 2.6.32 kernel on DM355 device and it worked fine however we are yet to get this working with 2.6.30 kernel.  
> 
> One of the things that we are trying to investigate is why the transmit FIFO empty interrupts are not generated. If you have more visibility into this, I would appreciate any details. Considering we see this issue across number of devices OMAP-L137, DM6446 and DM355, it points to a software issue rather than hardware one but needs to be confirmed. 
> 
>  
> Prateek

My understanding of the issue is this:

The UART device only generates a FIFO empty interrupt if interrupts are
enabled and the FIFO goes from not empty to empty. If you then disable
the interrupt and later reenable it, the interrupt is not reasserted to
indicate that the FIFO is still empty.

This seems like reasonable behaviour, but is not how a true 16550A
device should behave. The interrupt should be reasseted if the FIFO is
still empty and the interrupt is reenabled.

The 8250 driver in the Linux kernel is written to depend upon this
reassertion behaviour. It has tests to detect the failure of this
behaviour and enables BUG workarounds (using a 200ms timer), if required.

Brian's patch changes the driver to not depend on this behaviour and
so doesn't need to detect its absence or invoke workarounds. It also
avoids 200ms timer delays - which is the big bonus.

I don't know what you did for your 2.6.30 backport, but I have it working
in a 2.6.18 backport with no real changes.

BTW it is not just a Davinci/OMAP problem I think...

Nick.


From kieranbingham at gmail.com  Tue Feb 16 03:43:36 2010
From: kieranbingham at gmail.com (Kieran Bingham)
Date: Tue, 16 Feb 2010 09:43:36 +0000
Subject: DM365 and 256 Memory with CMEM
Message-ID: <4B7A68C8.2030606@gmail.com>

Hi Guys,

We've got a DM365 board which has 256M of SDRAM.

I can mmap and read write to the upper 128M whilst the kernel command 
line has a mem=60M command line parameter, but when I set my CMEM module 
to have a phys_start address of greater than 0x88000000 (BASE+128M) I 
get kernel page faults - and even the kernel locking up entirely.

We're running the DM365 on the Montavista 2.6.18 at the moment - but is 
anyone aware of anything in the kernel that would specifically prevent 
successful ioremap_cached calls within cmem from succeeding above the 
first 128M of SDRAM?

--
Regards
Kieran Bingham

From Paul_Stuart at seektech.com  Tue Feb 16 15:18:47 2010
From: Paul_Stuart at seektech.com (Paul Stuart)
Date: Tue, 16 Feb 2010 13:18:47 -0800
Subject: Does IPIPE Smoothing Halve our resolution?
Message-ID: <7F1B6BBBDF05C649BBBA3C853F488A6119FCAF9E17@Hawking.deepsea.com>

Hi,
  Looking at the smooth routine in the dvsdk, it seems that de-interlacing is accomplished by taking the first video field and then expanding it by 2x.

>From a comment in Smooth.c
    /*
     * Configure the IPIPE such that its input looks like a buffer half the
     * height of the input buffer, and consisting of every other line in the
     * input buffer.  Smoothing will be done by resizing this half-height
     * buffer to a full size frame.
     */


So, if I'm understanding this correctly, the routine isn't so much de-interlacing the input, as it is throwing half of it away. Am I reading that right? If so, is there a way to smooth the image using the IPIPE and preserve full resolution? 

Thanks!
Paul

From Agraharam_Reddy at mindtree.com  Tue Feb 16 23:38:33 2010
From: Agraharam_Reddy at mindtree.com (Agraharam Samba Siva Reddy)
Date: Wed, 17 Feb 2010 11:08:33 +0530
Subject: cross compilation issues on database.
Message-ID: <F1172CE95E42B4409E3AFBFC9D000333019B758E43@MTW02MSG01.mindtree.com>

Hi,

I have tried to compile sqlite3 with the below steps but  did not get  .so files .


1.       ./configure  --prefix=/database  CC=arm_v5t_le-gcc CFLAG='-0 -g' --host=arm This step for generating the make file.

2.       Make

3.       Make install.

Thanks & Regards
Siva

________________________________
http://www.mindtree.com/email/disclaimer.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100217/8c0e9a01/attachment.html>

From iso at cypress.com  Wed Feb 17 00:23:11 2010
From: iso at cypress.com (Arun Siluvery)
Date: Wed, 17 Feb 2010 11:53:11 +0530
Subject: DM365: Image Sensor interface pins IO levels
In-Reply-To: <7F1B6BBBDF05C649BBBA3C853F488A6119FCAF9E17@Hawking.deepsea.com>
References: <7F1B6BBBDF05C649BBBA3C853F488A6119FCAF9E17@Hawking.deepsea.com>
Message-ID: <2028E5A2F181414B9244EF5C99C3E915@india.cypress.com>

Hello All,

As per the datasheet of dm365, the image sensor interface data pins, sync
signals have supply voltage of Vdd_isif18_33 (switchable 1.8V/3.3V).

Could anyone please tell me how the selection is made between 1.8V and 3.3V
on DM365 Evaluation Module (EVM)?

Is there any jumper/register setting on the EVM or it is upto to the user to
connect suitable voltage (1.8V/3.3V) as per his requirement?

Please clarify.

--
Best Regards
Arun
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


From basharath at acmet.com  Wed Feb 17 02:12:59 2010
From: basharath at acmet.com (basharath)
Date: Wed, 17 Feb 2010 13:42:59 +0530
Subject: U-Boot Problem
Message-ID: <001201caafa9$0836bfa0$b900a8c0@Basharath>

Dear friends,

I have created new Linux kernel following steps specified in "DVEVM
Getting Started Guide (SPRUE668) for Davinci DM6446". When I booted
following information I got on screen..

U-Boot 1.1.3 (Dec  4 2006 - 12:05:38)

U-Boot code: 81080000 -> 81097628  BSS: -> 810A0018
RAM Configuration:
Bank #0: 80000000 256 MB
Flash: 16 MB
In:    serial
Out:   serial
Err:   serial
ARM Clock :- 297MHz
DDR Clock :- 162MHz
Hit any key to stop autoboot:  3  2  1  0 
BOOTP broadcast 1
DHCP client bound to address 192.168.0.136
TFTP from server 192.168.0.207; our IP address is 192.168.0.136
Filename 'uImage'.
Load address: 0x80700000
Loading: *############T ##############################################T
########
	 ###################T
##############################################
	
#################################################################
	 ###########T
######################################################
	 #########################################
done
Bytes transferred = 1538596 (177a24 hex)
## Booting image at 80700000 ...
   Image Name:   Linux-2.6.10_mvl401-davinci_evm
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1538532 Bytes =  1.5 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing
Linu....................................................................
.................................. done, booting the
Linux version 2.6.10_mvl401-davinci_evm (sandeep at evmdm6446) (gcc version
3.4.3 (MontaVista 3.4.3-25.0.104.0600975 2006-07-06)) #1 Wed Feb 17
13:18:22 IST 2010
CPU: ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ)
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets
Machine: DaVinci EVM
Memory policy: ECC disabled, Data cache writeback
DM6443
Built 1 zonelists
Kernel command line: console=ttyS0,115200n8 noinitrd rw ip=dhcp
root=/dev/nfs nfsroot=192.168.0.207:/home/sandeep/work/filesys,nolock
mem=120M meMstdin=serial
PID hash table entries: 512 (order: 9, 8192 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 120MB = 120MB total
Memory: 118272KB available (2656K code, 529K data, 180K init)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
spawn_desched_task(00000000)
desched cpu_callback 3/00000000
ksoftirqd started up.
desched cpu_callback 2/00000000
desched thread 0 started up.
NET: Registered protocol family 16
DaVinci: 71 gpio irqs
Registering platform device 'serial8250.0'. Parent at platform
Registering platform device 'musb_hdrc'. Parent at platform
Registering platform device 'mmc.0'. Parent at platform
DaVinci I2C DEBUG: 13:16:03 Feb 17 2010
Registering platform device 'i2c'. Parent at platform
ch0 default output "COMPOSITE", mode "NTSC"
MUX: initialized LOEEN
MUX: initialized LFLDEN
VPBE Encoder Initialized
LogicPD encoder initialized
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
musb_hdrc: version 2.2a/db-0.4.8 [cppi-dma] [host] [debug=0]
musb_hdrc: ConfigData=0x06 (UTMI-8, dyn FIFOs, SoftConn)
musb_hdrc: MHDRC RTL version 1.300 
musb_hdrc: USB Host mode controller at c8002000 using DMA, IRQ 12
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
MUX: initialized MCBSP0
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
yaffs Feb 17 2010 13:15:36 Installing. 
Registering platform device 'davincifb.0'. Parent at platform
davincifb davincifb.0: dm_osd0_fb: 720x480x16 at 0,0 with framebuffer size
675KB
davincifb davincifb.0: dm_vid0_fb: 0x0x16 at 0,0 with framebuffer size
1020KB
davincifb davincifb.0: dm_osd1_fb: 720x480x4 at 0,0 with framebuffer size
675KB
davincifb davincifb.0: dm_vid1_fb: 0x0x16 at 0,0 with framebuffer size
1020KB
watchdog: TI DaVinci Watchdog Timer: timer margin 64 sec
Registering platform device 'davinci_resizer.2'. Parent at platform
Registering platform device 'davinci_previewer.2'. Parent at platform
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing
disabled
Registering platform device 'serial8250'. Parent at platform
ttyS0 at MMIO 0x1c20000 (irq = 40) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
RAMDISK driver initialized: 1 RAM disks of 32768K size 1024 blocksize
loop: loaded (max 8 devices)
Registering platform device 'ti_davinci_emac'. Parent at platform
TI DaVinci EMAC: MAC address is 00:0e:99:02:5e:39
TI DaVinci EMAC Linux version updated 5.0
TI DaVinci EMAC: Installed 1 instances.
netconsole: not configured, aborting
i2c /dev entries driver
Linux video capture interface: v1.00
Registering platform device 'vpfe.1'. Parent at platform
DaVinci I2C WARNING: i2c: NACK detected
DaVinci I2C WARNING: i2c: NACK detected
DaVinci I2C WARNING: i2c: NACK detected
DaVinci I2C WARNING: i2c: NACK detected
DaVinci I2C WARNING: i2c: NACK detected
vpfe vpfe.1: DaVinci v4l2 capture driver V1.0 loaded
Registering platform device 'DavinciDisplay.1'. Parent at platform
Trying to register davinci display video device.
layer=c71c0c00,layer->video_dev=c71c0d64
Trying to register davinci display video device.
layer=c71c0a00,layer->video_dev=c71c0b64
davinci_init:DaVinci V4L2 Display Driver V1.0 loaded

 Davici AEW Driver cannot be loaded
 VIDEO PORT is not enabledData Flow path from CCDC is disabled

 Davinci AF driver cannot be loaded
 VIDEO PORT is not enabled 
 CCDC needs to be configured<6>Uniform Multi-Platform E-IDE driver
Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with
idebus=xx
MUX: initialized HDIREN
MUX: initialized ATAEN
hda: TOSHIBA MK4032GAX, ATA DISK drive
elevator: using anticipatory as default io scheduler
ide0 at 0xe10661f0-0xe10661f7,0xe10663f6 on irq 22
hda: max request size: 1024KiB
hda: 78140160 sectors (40007 MB), CHS=16383/255/63
 hda: hda1 hda2
    ide0: BM-DMA at 0xe1066000-0xe1066007, BIOS settings: hda:pio,
hdb:pio
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
mmc mmc.0: Supporting 4-bit mode
mmc mmc.0: Using DMA mode
Registering platform device 'davinci-audio.0'. Parent at platform
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.0.136
IP-Config: Complete:
      device=eth0, addr=192.168.0.136, mask=255.255.255.0,
gw=192.168.0.1,
     host=192.168.0.136, domain=andcgateway.com, nis-domain=(none),
     bootserver=0.0.0.0, rootserver=192.168.0.207, rootpath=
Looking up port of RPC 100003/2 on 192.168.0.207
Looking up port of RPC 100005/1 on 192.168.0.207
VFS: Mounted root (nfs filesystem).
Freeing init memory: 180K

INIT: version 2.85 booting

Mounting a tmpfs over /dev...done.
Creating initial device nodes...done.
Activating swap...done. 
Remounting root filesystem...done. 
Calculating module dependencies
Loading modules: 
Checking all file systems: fsck
fsck 1.35 (28-Feb-2004)
Mounting local filesystems: mount mount: fs type relayfs not supported
by kernel
 failed (32: ).
Cleaning: /tmp /var/lock /var/run done.
Setting up networking (ifupdown) ..
Cleaning: /etc/network/run/ifstate done.
Starting network interfaces: done.
Starting hotplug subsystem:
   pci     
   pci      [success]
   usb     
   usb      [success]
   isapnp  
   isapnp   [success]
   ide     
   ide      [success]
   input   
   input    [success]
   scsi    
   scsi     [success]
done.
Starting portmap daemon: portmap. 
done.
Setting pseudo-terminal access permissions...done.
Updating /etc/motd...done.

INIT: Entering runlevel: 3

Starting NFS common utilities: statd lockd. 
Starting internet superserver: inetd.
insmod: can't read '/opt/dvt-dsa/dvt-dsa.ko': No such file or directory
Starting MontaVista target tools daemon: mvltdmvltd version 2.1
MontaVista Software,Inc.
mvltd[1061]: started on port 34577

. 

MontaVista(R) Linux(R) Professional Edition 4.0.1 (0600980)


In above message:

I was unable to understand following things.

1. 

---------------------------------------

Machine: DaVinci EVM
Memory policy: ECC disabled, Data cache writeback
DM6443
----------------------------------------

Here DM6443 is mentioned, I was expecting DM6446. what may be the
problem. Is my perception is wrong.


2. 

------------------------------------------------------

davinci_init:DaVinci V4L2 Display Driver V1.0 loaded

 Davici AEW Driver cannot be loaded
 VIDEO PORT is not enabledData Flow path from CCDC is disabled

 Davinci AF driver cannot be loaded
 VIDEO PORT is not enabled 
 CCDC needs to be configured<6>Uniform Multi-Platform E-IDE driver
Revision:

----------------------------------------------------------------

How to rectify above problem ?

3.

When I connect my LCD display to board. If board is working it should
show a TI icon on left of the screen. Which is not seen now? 

Please advice how to configure video display.


Please advice.

Thank you,
Basharath.


From nick.thompson at ge.com  Wed Feb 17 03:32:38 2010
From: nick.thompson at ge.com (Nick Thompson)
Date: Wed, 17 Feb 2010 09:32:38 +0000
Subject: cross compilation issues on database.
In-Reply-To: <F1172CE95E42B4409E3AFBFC9D000333019B758E43@MTW02MSG01.mindtree.com>
References: <F1172CE95E42B4409E3AFBFC9D000333019B758E43@MTW02MSG01.mindtree.com>
Message-ID: <4B7BB7B6.8090705@ge.com>

On 17/02/10 05:38, Agraharam Samba Siva Reddy wrote:
> Hi,
> 
> I have tried to compile sqlite3 with the below steps but  did not get  .so files .
> 
> 
> 1.       ./configure  --prefix=/database  CC=arm_v5t_le-gcc CFLAG='-0 -g' --host=arm This step for generating the make file.
> 
> 2.       Make
> 
> 3.       Make install.
> 
> Thanks & Regards
> Siva

Perhaps you could tell us what went wrong - I assume you saw some errors?
It would be helpful to share those with the list if you want help to fix
them.

Please also tell tell us the versions of tools and the version of SQLite3
you are trying to compile.

http://catb.org/~esr/faqs/smart-questions.html

Nick.

From bjorn.forsman at gmail.com  Wed Feb 17 04:03:08 2010
From: bjorn.forsman at gmail.com (=?UTF-8?Q?Bj=C3=B8rn_Forsman?=)
Date: Wed, 17 Feb 2010 11:03:08 +0100
Subject: cross compilation issues on database.
In-Reply-To: <F1172CE95E42B4409E3AFBFC9D000333019B758E43@MTW02MSG01.mindtree.com>
References: <F1172CE95E42B4409E3AFBFC9D000333019B758E43@MTW02MSG01.mindtree.com>
Message-ID: <5f2b61002170203r7fa9b8bcg3be21ad2b0b5ba74@mail.gmail.com>

Hi,

On 17 February 2010 06:38, Agraharam Samba Siva Reddy
<Agraharam_Reddy at mindtree.com> wrote:
> Hi,
>
>
>
> I have tried to compile sqlite3 with the below steps but ?did not get? .so
> files .
>
>
>
> 1.?????? ./configure ?--prefix=/database? CC=arm_v5t_le-gcc CFLAG='-0 -g'
> --host=arm This step for generating the make file.
>
> 2.?????? Make
>
> 3.?????? Make install.

I'm not sure if this is cross-compile related. If you build natively,
do you get .so files then?
Also, look at ./configure --help, maybe there's a flag that must be
set to enable .so files?

Best regards,
Bj?rn Forsman

From Agraharam_Reddy at mindtree.com  Wed Feb 17 04:38:40 2010
From: Agraharam_Reddy at mindtree.com (Agraharam Samba Siva Reddy)
Date: Wed, 17 Feb 2010 16:08:40 +0530
Subject: cross compilation issues on database.
In-Reply-To: <4B7BB7B6.8090705@ge.com>
References: <F1172CE95E42B4409E3AFBFC9D000333019B758E43@MTW02MSG01.mindtree.com>
	<4B7BB7B6.8090705@ge.com>
Message-ID: <F1172CE95E42B4409E3AFBFC9D000333019B7A3E63@MTW02MSG01.mindtree.com>

Hi,
I have tried on the sqlite-3.6.11 version.

-----Original Message-----
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Nick Thompson
Sent: Wednesday, February 17, 2010 3:03 PM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: Re: cross compilation issues on database.

On 17/02/10 05:38, Agraharam Samba Siva Reddy wrote:
> Hi,
>
> I have tried to compile sqlite3 with the below steps but  did not get  .so files .
>
>
> 1.       ./configure  --prefix=/database  CC=arm_v5t_le-gcc CFLAG='-0 -g' --host=arm This step for generating the make file.
>
> 2.       Make
>
> 3.       Make install.
>
> Thanks & Regards
> Siva

Perhaps you could tell us what went wrong - I assume you saw some errors?
It would be helpful to share those with the list if you want help to fix
them.

Please also tell tell us the versions of tools and the version of SQLite3
you are trying to compile.

http://catb.org/~esr/faqs/smart-questions.html

Nick.
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

http://www.mindtree.com/email/disclaimer.html

From swb at i-d-2.com  Wed Feb 17 06:20:52 2010
From: swb at i-d-2.com (Stephen Berry)
Date: Wed, 17 Feb 2010 07:20:52 -0500
Subject: Does IPIPE Smoothing Halve our resolution?
In-Reply-To: <7F1B6BBBDF05C649BBBA3C853F488A6119FCAF9E17@Hawking.deepsea.com>
References: <7F1B6BBBDF05C649BBBA3C853F488A6119FCAF9E17@Hawking.deepsea.com>
Message-ID: <4B7BDF24.80209@i-d-2.com>


Paul Stuart wrote:
> Hi,
>   Looking at the smooth routine in the dvsdk, it seems that de-interlacing is accomplished by taking the first video field and then expanding it by 2x.
>
> >From a comment in Smooth.c
>     /*
>      * Configure the IPIPE such that its input looks like a buffer half the
>      * height of the input buffer, and consisting of every other line in the
>      * input buffer.  Smoothing will be done by resizing this half-height
>      * buffer to a full size frame.
>      */
>
>
> So, if I'm understanding this correctly, the routine isn't so much de-interlacing the input, as it is throwing half of it away. Am I reading that right? If so, is there a way to smooth the image using the IPIPE and preserve full resolution? 
>
>   
You understand it correctly. Converting NTSC to a progressive frame
image with out motion artifacts has been a problem for a very long time.
The simplest method is to toss away one field and horizontally double
the other. This produces a whole host of visual artifacts.

If you use the resizer (which just runs the IPIPE over the progressive
de-interlaced frame) so it doesn't resize - 1:1 mode. I think what you
will find is that the resultant image is less sharp. A lot depends on
how the coefficients are set up.

This is the kind of experiment where I would save an image or two in a
file, and run a stand alone resizer app so I can compare the two images
in a photo program side by side.

> Thanks!
> Paul
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>   

    Steve

From pan at nt.tu-darmstadt.de  Wed Feb 17 08:41:24 2010
From: pan at nt.tu-darmstadt.de (Vladimir Pantelic)
Date: Wed, 17 Feb 2010 15:41:24 +0100
Subject: Does IPIPE Smoothing Halve our resolution?
In-Reply-To: <4B7BDF24.80209@i-d-2.com>
References: <7F1B6BBBDF05C649BBBA3C853F488A6119FCAF9E17@Hawking.deepsea.com>
	<4B7BDF24.80209@i-d-2.com>
Message-ID: <4B7C0014.5040501@nt.tu-darmstadt.de>

Stephen Berry wrote:
>
> Paul Stuart wrote:
>>  Hi,
>>    Looking at the smooth routine in the dvsdk, it seems that de-interlacing is accomplished by taking the first video field and then expanding it by 2x.
>>
>>  > From a comment in Smooth.c
>>      /*
>>       * Configure the IPIPE such that its input looks like a buffer half the
>>       * height of the input buffer, and consisting of every other line in the
>>       * input buffer.  Smoothing will be done by resizing this half-height
>>       * buffer to a full size frame.
>>       */
>>
>>
>>  So, if I'm understanding this correctly, the routine isn't so much de-interlacing the input, as it is throwing half of it away. Am I reading that right? If so, is there a way to smooth the image using the IPIPE and preserve full resolution?
>>
>>
> You understand it correctly. Converting NTSC to a progressive frame
> image with out motion artifacts has been a problem for a very long time.
> The simplest method is to toss away one field and horizontally double
> the other. This produces a whole host of visual artifacts.

well, this is actually a quite good method. It is almost impossible to
deinterlace properly if you can only work on one frame at a time. All
the really good deinterlacing methods use a "temporal" component by
looking at several consecutive frames (detecting moving vs static parts
etc)

For a single frame deinterlacer, all that I have seen so far was worse than
just throwing away one field and upscaling the other.



From brian at murphy.dk  Wed Feb 17 10:54:57 2010
From: brian at murphy.dk (Brian Murphy)
Date: Wed, 17 Feb 2010 17:54:57 +0100
Subject: DM3xx: UART transmit delays
In-Reply-To: <4B7A61FB.2090300@ge.com>
References: <b41414a41002110158r2945cb3bgbacef1cd37c99688@mail.gmail.com>
	<4B795308.7050509@ge.com>
	<F39349C6FA641B4A831B7BF4EBF4D4E1418DFFBA@dlee03.ent.ti.com>
	<4B7A61FB.2090300@ge.com>
Message-ID: <b41414a41002170854u5d65d3t4b693a335ce11690@mail.gmail.com>

> My understanding of the issue is this:
>
> The UART device only generates a FIFO empty interrupt if interrupts are
> enabled and the FIFO goes from not empty to empty. If you then disable
> the interrupt and later reenable it, the interrupt is not reasserted to
> indicate that the FIFO is still empty.
>
> This seems like reasonable behaviour, but is not how a true 16550A
> device should behave. The interrupt should be reasseted if the FIFO is
> still empty and the interrupt is reenabled.
>
> The 8250 driver in the Linux kernel is written to depend upon this
> reassertion behaviour. It has tests to detect the failure of this
> behaviour and enables BUG workarounds (using a 200ms timer), if required.
>
> Brian's patch changes the driver to not depend on this behaviour and
> so doesn't need to detect its absence or invoke workarounds. It also
> avoids 200ms timer delays - which is the big bonus.
>
> I don't know what you did for your 2.6.30 backport, but I have it working
> in a 2.6.18 backport with no real changes.
>
> BTW it is not just a Davinci/OMAP problem I think...
>

Correct. You would think that TI should be able to make a 16550 compatible UART.
I have seen a few SOCs with this feature, I seem to remember a designware UART
that behaves this way too.

I agree that it wil take some work to convince the maintainers of the
8250 driver
(Alan Cox??) that these changes should be accepted. Even the "real" 16550 will
benefit from the change as an interrupt does not have to be handled
before transmission
can start.

/Brian

From brian at murphy.dk  Wed Feb 17 11:02:42 2010
From: brian at murphy.dk (Brian Murphy)
Date: Wed, 17 Feb 2010 18:02:42 +0100
Subject: DM3xx: UART transmit delays
In-Reply-To: <F39349C6FA641B4A831B7BF4EBF4D4E1418DFFBA@dlee03.ent.ti.com>
References: <b41414a41002110158r2945cb3bgbacef1cd37c99688@mail.gmail.com>
	<4B795308.7050509@ge.com>
	<F39349C6FA641B4A831B7BF4EBF4D4E1418DFFBA@dlee03.ent.ti.com>
Message-ID: <b41414a41002170902x47480f8boe44931c07427560d@mail.gmail.com>

On Mon, Feb 15, 2010 at 10:07 PM, Bansal, Prateek <pbansal at ti.com> wrote:
> Hi Brian,
>
> Thanks for sharing the patch. We tested this on 2.6.32 kernel on DM355 device and it worked fine however we are yet to get this working with 2.6.30 kernel.
>
> One of the things that we are trying to investigate is why the transmit FIFO empty interrupts are not generated. If you have more visibility into this, I would appreciate any details. Considering we see this issue across number of devices OMAP-L137, DM6446 and DM355, it points to a software issue rather than hardware one but needs to be confirmed.
>
>

I have it working with several kernels, It needed a little massaging
to work with the latest
as someone else was playing in the same place as me :).

The issue the patch fixes is a hardware issue. The UART in the TI SOC
devices does not
have the same behaviour as a 16550 uart and the linux kernel driver
requires that
behaviour to function efficiently.

The workaround in the current kernel driver is not good and hides the
problem in a very
bad way.

I will try again next week to get a discusion going on the
linux-serial list. It seems like Alan
Cox is still active despite threats to the contary so I may send
directly to him to see if that
helps.

/Brian

From david.kondrad at legrand.us  Wed Feb 17 12:32:46 2010
From: david.kondrad at legrand.us (david.kondrad at legrand.us)
Date: Wed, 17 Feb 2010 13:32:46 -0500
Subject: cross compilation issues on database
In-Reply-To: <mailman.1036.1266394406.11996.davinci-linux-open-source@linux.davincidsp.com>
Message-ID: <OFD408FF9E.7EAE855A-ON852576CD.00634ED0-852576CD.0065E0AE@grpleg.it>

Greetings:

What you need to do is make symlinks to your arm_v5t_le-* tools so that
the name of the tool fits the canonical form:
armv5tl-montavista-linuxeabi-*

So, you will now have something like this for the compiler:
armv5tl-montavista-linuxeabi-gcc

Now that you have all those symlinks, you can use the cross-compile feature
of
'configure'.

Depending on the package, you may need to create a cache file for configure
that has the platform specific options pre-set so that you don't run into
errors something like "Cross compiling - cannot run test".

The instructions for doing that are a little more involved, but can be
found
with a google search for "cross compile configure cache file". Each package
has
different requirements but most of the platform dependent variables are the
same.

Also, I would be careful when specifying a prefix, especially when
deploying to
a embedded target.

Adding the prefix sometimes also changes the 'rpath' in the library and any
apps that are linked against it will look in the hard-coded path instead of
the
proper path found by ld. If you are installing to a file system tree on a
development host box, this will really mess things up for you when you
build
your root fs.

Most configure scripts generate make files that allow you to specify a root
path to install by using DESTDIR variable. For example, if your root
filesystem
is at /home/user/rootfs, then install there by doing:

make install DESTDIR=/home/usr/rootfs

If you install that way, the /home/user/rootfs will contain all the
appropriate
directories to build the rootfs from.

So, your configure call will use --host=armv5tl-montavista-linuxeabi
parameter
and other options.

Be sure to not specify a 'CC' variable as this is already done by
configure.


Regards,
David

--
DAVID A. KONDRAD
Software Design Engineer
Home Systems Division
Legrand, North America

david.kondrad at legrand.us
http://www.legrand.us/onq

This email, and any document attached hereto, may contain
confidential and/or privileged information.  If you are not the
intended recipient (or have received this email in error) please
notify the sender immediately and destroy this email.  Any
unauthorized, direct or indirect, copying, disclosure, distribution
or other use of the material or parts thereof is strictly
forbidden.

From david.kondrad at legrand.us  Wed Feb 17 16:54:20 2010
From: david.kondrad at legrand.us (david.kondrad at legrand.us)
Date: Wed, 17 Feb 2010 17:54:20 -0500
Subject: Back porting i2c-davinci to 2.6.10?
Message-ID: <OFA3BE61CC.47DD322A-ON852576CD.007C53F6-852576CD.007DD30F@grpleg.it>


Greetings:

I've been pulling my hair out while working with the 2.6.10 version of
the davinci I2C driver on DM644x.

It's from the last TI LSP to include the 2.6.10 tree, I don't know the
specific release number.

Basically, I'm controlling an AIC33 manually through /dev/i2c/0 and I
do not have any OSS sound enabled.

For reasons I won't get into, we have our own dsp-side sound driver
which is operational, but our AIC33 sometimes act funny.

While configuring the AIC33, we should get a signal (triangle wave
generated by software) from left line out, right line out, mono
out.... sometimes this works, sometimes it doesn't.

I haven't put a scope on the I2C lines yet because I'd have to
completely dismantle our product to do so, so I can't say for sure
that the bytes actually went out, but using debug printk's in the
driver, the two code sequences for working and not working appear to
be exactly the same.

I know that many people have put a lot of work into the git I2C driver
for davinci, was this fixed by the commit that fixed lost interrupts?

Or is the old driver so bad that I'd basically have to scrap it and
back port?

So the whole point of this is how much of the kernel structure changes
from the old to the new will affect this driver? Could I get away with
stubbing out or chopping out those parts that don't exist in the old
kernel?

Unfortunately, moving to the git kernel would be an absolute
nightmare right now because we have about 2 years worth of
stuff built up with the MV pro 4 (2.6.10 base) toolchain.

Regards,
David

--
DAVID A. KONDRAD
Software Design Engineer
Home Systems Division
Legrand, North America

david.kondrad at legrand.us
http://www.legrand.us/onq

This email, and any document attached hereto, may contain
confidential and/or privileged information.  If you are not the
intended recipient (or have received this email in error) please
notify the sender immediately and destroy this email.  Any
unauthorized, direct or indirect, copying, disclosure, distribution
or other use of the material or parts thereof is strictly
forbidden.

From Jon.Povey at racelogic.co.uk  Wed Feb 17 22:07:52 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Thu, 18 Feb 2010 04:07:52 -0000
Subject: Correct way to fix __typesafe_io warnings?
Message-ID: <2992BF78ED49594EB72AD7F4F8642BBDEEFC74@RL-SBS.racelogic.local>

I am starting work on porting our drivers from MV kernel to the git
kernel, and getting a lot of warnings like:

  warning: passing argument 1 of '__typesafe_io' makes integer from
pointer without a cast

Which comes from source like:

  u32 tmpreg;
  tmpreg = inl(GPIO_DIR45);

We have our own header with lots of lines like this (inspired by drivers
in the beta DM355 SDK):

  #define GPIO_DIR45 IO_ADDRESS( DAVINCI_GPIO_BASE + 0x60 )

Now, I'm pretty sure the we shouldn't be doing this for portability and
so on, and should be getting these addresses in some
platform-independent way, but for now It Works so I don't want to fix
it.

I would however like a clue on the right way to fix these warnings and
do the kind of accesses I'm trying to do. There are many similar-looking
macros and functions available: inl(), insl(), __raw_readl() and I don't
know which I should be using, or if I should be passing around u32
"addresses" or __iomem pointers (maybe the IO_ADDRESS() should go?).
Had a look around for documentation but not found anything too useful.

Thanks,

-- 
Jon Povey
jon.povey at racelogic.co.uk

 
Racelogic is a limited company registered in England. Registered number 2743719 . 
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .
The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network

From palatis at iworldcom.com  Thu Feb 18 02:26:13 2010
From: palatis at iworldcom.com (=?UTF-8?B?IuabvuWFtuWogSAoVmljdG9yIFRzZW5nKSI=?=)
Date: Thu, 18 Feb 2010 16:26:13 +0800
Subject: Correct way to fix __typesafe_io warnings?
In-Reply-To: <2992BF78ED49594EB72AD7F4F8642BBDEEFC74@RL-SBS.racelogic.local>
References: <2992BF78ED49594EB72AD7F4F8642BBDEEFC74@RL-SBS.racelogic.local>
Message-ID: <4B7CF9A5.9030007@iworldcom.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On ??2010?02?18? 12:07, Jon Povey wrote:
> I am starting work on porting our drivers from MV kernel to the git
> kernel, and getting a lot of warnings like:
> 
>   warning: passing argument 1 of '__typesafe_io' makes integer from
> pointer without a cast
> 
> Which comes from source like:
> 
>   u32 tmpreg;
>   tmpreg = inl(GPIO_DIR45);
> 
> We have our own header with lots of lines like this (inspired by drivers
> in the beta DM355 SDK):
> 
>   #define GPIO_DIR45 IO_ADDRESS( DAVINCI_GPIO_BASE + 0x60 )
> 
> Now, I'm pretty sure the we shouldn't be doing this for portability and
> so on, and should be getting these addresses in some
> platform-independent way, but for now It Works so I don't want to fix
> it.
> 
> I would however like a clue on the right way to fix these warnings and
> do the kind of accesses I'm trying to do. There are many similar-looking
> macros and functions available: inl(), insl(), __raw_readl() and I don't
> know which I should be using, or if I should be passing around u32
> "addresses" or __iomem pointers (maybe the IO_ADDRESS() should go?).
> Had a look around for documentation but not found anything too useful.
> 
> Thanks,
> 
do a cast then.

#define GPIO_DIR45 (void *)(IO_ADDRESS( DAVINCI_GPIO_BASE + 0x60 ))

- -- 
Victor Tseng (a.k.a Palatis)
iWorldCom Co., Ltd.
Taipei World Trading Center Exhibition Hall
Room 5C28, 5F, No. 5, Hsinyi Rd., Sec. 5,
Taipei 110, Taiwan, ROC.
?????????????
??? 110 ???????? 5 ? 5 ? 5C28 ?
Tel: 886-02-8786-1579
Fax: 886-02-8786-1379
Mobile: 0938-642-978
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt8+aUACgkQSJ4mt5b7FKdD1gCghR157BC6Vdrn0sgXV5n6xm5J
KlEAn3v/HWNlvUz4XPFKgteEMDY0JfBQ
=kv+Q
-----END PGP SIGNATURE-----

From Jon.Povey at racelogic.co.uk  Thu Feb 18 03:10:02 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Thu, 18 Feb 2010 09:10:02 -0000
Subject: Correct way to fix __typesafe_io warnings?
In-Reply-To: <4B7CF9A5.9030007@iworldcom.com>
Message-ID: <2992BF78ED49594EB72AD7F4F8642BBDEEFC93@RL-SBS.racelogic.local>

"??? (Victor Tseng)" wrote:
> On ??2010?02?18? 12:07, Jon Povey wrote:
>> I am starting work on porting our drivers from MV kernel to the git
>> kernel, and getting a lot of warnings like:
>> 
>>   warning: passing argument 1 of '__typesafe_io' makes integer from
>> pointer without a cast 
>
> do a cast then.
> 
> #define GPIO_DIR45 (void *)(IO_ADDRESS( DAVINCI_GPIO_BASE + 0x60 ))

That doesn't look likely to be the "right way" to fix this..


-- 
Jon Povey
jon.povey at racelogic.co.uk

 
Racelogic is a limited company registered in England. Registered number 2743719 . 
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .
The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network

From nsekhar at ti.com  Thu Feb 18 03:27:24 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Thu, 18 Feb 2010 14:57:24 +0530
Subject: Correct way to fix __typesafe_io warnings?
In-Reply-To: <2992BF78ED49594EB72AD7F4F8642BBDEEFC74@RL-SBS.racelogic.local>
References: <2992BF78ED49594EB72AD7F4F8642BBDEEFC74@RL-SBS.racelogic.local>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E5B8A35E@dbde02.ent.ti.com>

Hi Jon,

On Thu, Feb 18, 2010 at 09:37:52, Jon Povey wrote:
> I am starting work on porting our drivers from MV kernel to the git
> kernel, and getting a lot of warnings like:
>
>   warning: passing argument 1 of '__typesafe_io' makes integer from
> pointer without a cast
>
> Which comes from source like:
>
>   u32 tmpreg;
>   tmpreg = inl(GPIO_DIR45);
>
> We have our own header with lots of lines like this (inspired by drivers
> in the beta DM355 SDK):
>
>   #define GPIO_DIR45 IO_ADDRESS( DAVINCI_GPIO_BASE + 0x60 )
>
> Now, I'm pretty sure the we shouldn't be doing this for portability and
> so on, and should be getting these addresses in some
> platform-independent way, but for now It Works so I don't want to fix
> it.

To access GPIOs you should use GPIO driver (please see
include/linux/gpio.h)

>
> I would however like a clue on the right way to fix these warnings and
> do the kind of accesses I'm trying to do. There are many similar-looking
> macros and functions available: inl(), insl(), __raw_readl() and I don't
> know which I should be using, or if I should be passing around u32
> "addresses" or __iomem pointers (maybe the IO_ADDRESS() should go?).
> Had a look around for documentation but not found anything too useful.

You are right, using IO_ADDRESS is deprecated. Kevin is
not accepting any patches which use it. The correct way
is to use ioremap() to get a virtual address and then
use __raw_{readl|writel}() to access the address. You
can find many examples of this in arch/arm/mach-davinci/*

Thanks,
Sekhar

From Jon.Povey at racelogic.co.uk  Thu Feb 18 03:58:08 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Thu, 18 Feb 2010 09:58:08 -0000
Subject: Correct way to fix __typesafe_io warnings?
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E5B8A35E@dbde02.ent.ti.com>
Message-ID: <2992BF78ED49594EB72AD7F4F8642BBDEEFCAA@RL-SBS.racelogic.local>

Nori, Sekhar wrote:
> On Thu, Feb 18, 2010 at 09:37:52, Jon Povey wrote:

> To access GPIOs you should use GPIO driver (please see
> include/linux/gpio.h)

Thanks, I had seen that.. Will investigate later. For now just trying to
hack something together that boots.

These are in-house drivers for custom hardware that will almost
certainly never get submitted for mainline.

> You are right, using IO_ADDRESS is deprecated. Kevin is
> not accepting any patches which use it. The correct way
> is to use ioremap() to get a virtual address and then
> use __raw_{readl|writel}() to access the address. You
> can find many examples of this in arch/arm/mach-davinci/*

Great, thanks!


-- 
Jon Povey
jon.povey at racelogic.co.uk

 
Racelogic is a limited company registered in England. Registered number 2743719 . 
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .
The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network

From Jon.Povey at racelogic.co.uk  Thu Feb 18 04:31:45 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Thu, 18 Feb 2010 10:31:45 -0000
Subject: Bounces from ingenient.com when sending to this list
Message-ID: <2992BF78ED49594EB72AD7F4F8642BBDEEFCBE@RL-SBS.racelogic.local>

Is anyone else getting undeliverable bounces from ingenient.com when
sending to this list?

I get am getting two "user unknown" bounces from there every time I send
to the list. Not very helpful to me, maybe to the list admin so they
could be unsubscribed..
Kind of surprised they're coming to me, but then I have forgotten what
little I knew of mail RFCs.

-- 
Jon Povey
jon.povey at racelogic.co.uk

 
Racelogic is a limited company registered in England. Registered number 2743719 . 
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .
The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network

From nick.thompson at ge.com  Thu Feb 18 04:47:31 2010
From: nick.thompson at ge.com (Nick Thompson)
Date: Thu, 18 Feb 2010 10:47:31 +0000
Subject: DM3xx: UART transmit delays
In-Reply-To: <b41414a41002170854u5d65d3t4b693a335ce11690@mail.gmail.com>
References: <b41414a41002110158r2945cb3bgbacef1cd37c99688@mail.gmail.com>	
	<4B795308.7050509@ge.com>	
	<F39349C6FA641B4A831B7BF4EBF4D4E1418DFFBA@dlee03.ent.ti.com>	
	<4B7A61FB.2090300@ge.com>
	<b41414a41002170854u5d65d3t4b693a335ce11690@mail.gmail.com>
Message-ID: <4B7D1AC3.9000701@ge.com>

On 17/02/10 16:54, Brian Murphy wrote:
> I agree that it wil take some work to convince the maintainers of the
> 8250 driver
> (Alan Cox??) that these changes should be accepted. Even the "real" 16550 will
> benefit from the change as an interrupt does not have to be handled
> before transmission
> can start.

Also there is less code to test and maintain. That's got to be good, right?

Good luck ;)

Nick.

From pan at nt.tu-darmstadt.de  Thu Feb 18 04:55:39 2010
From: pan at nt.tu-darmstadt.de (Vladimir Pantelic)
Date: Thu, 18 Feb 2010 11:55:39 +0100
Subject: Bounces from ingenient.com when sending to this list
In-Reply-To: <2992BF78ED49594EB72AD7F4F8642BBDEEFCBE@RL-SBS.racelogic.local>
References: <2992BF78ED49594EB72AD7F4F8642BBDEEFCBE@RL-SBS.racelogic.local>
Message-ID: <4B7D1CAB.8080206@nt.tu-darmstadt.de>

Jon Povey wrote:
> Is anyone else getting undeliverable bounces from ingenient.com when
> sending to this list?
> 
> I get am getting two "user unknown" bounces from there every time I send
> to the list. Not very helpful to me, maybe to the list admin so they
> could be unsubscribed..
> Kind of surprised they're coming to me, but then I have forgotten what
> little I knew of mail RFCs.

yes, telling webmaster at ingenient.com did not help, I'm all for 
unsubscribing them...


From Jon.Povey at racelogic.co.uk  Thu Feb 18 05:22:39 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Thu, 18 Feb 2010 11:22:39 -0000
Subject: Bounces from ingenient.com when sending to this list
In-Reply-To: <4B7D1CAB.8080206@nt.tu-darmstadt.de>
Message-ID: <2992BF78ED49594EB72AD7F4F8642BBDEEFCD1@RL-SBS.racelogic.local>

Vladimir Pantelic wrote:
> Jon Povey wrote:
>> Is anyone else getting undeliverable bounces from ingenient.com when
>> sending to this list? 
>> 
>> I get am getting two "user unknown" bounces from there every time I
>> send to the list. Not very helpful to me, maybe to the list admin so
>> they could be unsubscribed.. Kind of surprised they're coming to me,
>> but then I have forgotten what little I knew of mail RFCs.
> 
> yes, telling webmaster at ingenient.com did not help, I'm all for
> unsubscribing them...

OK. I have sent email to the list maintainer requesting unsub.

-- 
Jon Povey
jon.povey at racelogic.co.uk

 
Racelogic is a limited company registered in England. Registered number 2743719 . 
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .
The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network

From krunal.patil at einfochips.com  Thu Feb 18 06:17:16 2010
From: krunal.patil at einfochips.com (Krunal Patil)
Date: Thu, 18 Feb 2010 17:47:16 +0530
Subject: IPIPE memory allocation failure.
Message-ID: <4B7D2FCC.4050904@einfochips.com>

Hi,

I am working on a DM355 based system which consist of QT GUI and backend 
applications. The backend applications are responsible for MPEG 
(1024x768) / JPEG (1920/1080) capture/display and G711 audio 
capture/playback. For resized JPEG display (1920x1080 -> 768x576) I am 
using DM355 IPIPE module and successfully able to resize JPEG image 
without any corruption.

The problem is when I run the system for *a long time and hard/soft 
reboot* it the next time IPIPE memory allocation (IPIPE_REQBUF ioctl) of 
size (1344 * ((1080 * 2 + 31) & (~31))) = 2924544 fails. System has 
128MB of DDR out of which 108M are given to Linux kernel from the bootargs.

Can this issue be related with memory fragmentation? Anyone please 
suggest me some pointers?


-- 
Regards,
*Krunal Patil*


-- 
_____________________________________________________________________
Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution, copying, or other use of
this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
replying to this message and please delete it from your computer. Any
views expressed in this message are those of the individual sender
unless otherwise stated.Company has taken enough precautions to prevent
the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email.
_____________________________________________________________________
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100218/6fd1aeb2/attachment.html>

From rohan_javed at yahoo.co.uk  Thu Feb 18 07:30:31 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Thu, 18 Feb 2010 05:30:31 -0800 (PST)
Subject: DM6446:file trasfer via UART
Message-ID: <17570.96561.qm@web24108.mail.ird.yahoo.com>

Hello everyone I am using DM6446 we have made our own custom board for some reason we have not connected the ethernet port i am able to boot using the filsystem in the NAND flash.

Now i have created a program and i want to transfer or copy it to the filesystem.Anyone knows how to do it.

In our previous design we had ethernet port so we can mount on the other computer using the ethernet over nfs and copy that file into the filesystem.But now the only way is the serial port but linux is running on dat port.

Anyone knows how to transfer an executable or anyfile over serial while the linux is bootup.



Regard's
Rohan Tabish



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100218/ccbfa9f0/attachment.html>

From Jon.Povey at racelogic.co.uk  Thu Feb 18 08:05:23 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Thu, 18 Feb 2010 14:05:23 -0000
Subject: DM6446:file trasfer via UART
In-Reply-To: <17570.96561.qm@web24108.mail.ird.yahoo.com>
Message-ID: <2992BF78ED49594EB72AD7F4F8642BBDEEFCFD@RL-SBS.racelogic.local>

rohan tabish wrote:
> Anyone knows how to transfer an executable or anyfile over serial
> while the linux is bootup. 

Check out zmodem and/or kermit, this may get you started:

http://www.linux.org/docs/ldp/howto/Remote-Serial-Console-HOWTO/upload.h
tml


-- 
Jon Povey
jon.povey at racelogic.co.uk

 
Racelogic is a limited company registered in England. Registered number 2743719 . 
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .
The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network

From david.kondrad at legrand.us  Thu Feb 18 08:19:34 2010
From: david.kondrad at legrand.us (david.kondrad at legrand.us)
Date: Thu, 18 Feb 2010 09:19:34 -0500
Subject: davinci linux mailing bounces
Message-ID: <OF3CFC22E9.20812BA0-ON852576CE.004E660C-852576CE.004EB266@grpleg.it>


Jon:

Yes, I'm getting the bounces too!

There are coming from these two addresses:



ajit.clarence at ingenient.com

jlozano at ingenient.com


Regards,
David

--
DAVID A. KONDRAD
Software Design Engineer
Home Systems Division
Legrand, North America

david.kondrad at legrand.us
http://www.legrand.us/onq


This email, and any document attached hereto, may contain
confidential and/or privileged information.  If you are not the
intended recipient (or have received this email in error) please
notify the sender immediately and destroy this email.  Any
unauthorized, direct or indirect, copying, disclosure, distribution
or other use of the material or parts thereof is strictly
forbidden.

From Thomas.Koeller at baslerweb.com  Thu Feb 18 11:02:10 2010
From: Thomas.Koeller at baslerweb.com (Koeller, T.)
Date: Thu, 18 Feb 2010 18:02:10 +0100
Subject: Which linux kernel tree to use for development?
Message-ID: <C5A8FDEFF7647F4C9CB927D7DEB307730E0117FE@ahr075s.basler.corp>

Hi,

being in the early stages of porting the kernel to a new DaVinci-based platform,
I found that there are two git repositories specifically targeted at DaVinci development,
namely the one at arago-project.org/git/projects/linux-davinci.git, and another one
which is at git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git.
This raises the question which one I should use as a foundation for my work, and
how these trees are related to each other. I tried to apply git to find out about
that, and came to the conclusion that both trees are mostly independent and no
merges have recently been done between them. OTOH, active development appears to
be going on on both trees. Can anyone provide information?

tk

_______________________________

Thomas K?ller, Software Developer

Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany

Tel. +49 (0) 4102 463-390
Fax  +49 (0) 4102 463-46390

mailto:thomas.koeller at baslerweb.com
http://www.baslerweb.com

Vorstand: Dr.-Ing. Dietmar Ley (Vorsitzender) ? John P. Jennings ? Aufsichtsratsvorsitzender: Norbert Basler
Basler AG ? Amtsgericht Ahrensburg HRB 4090 ? Ust-IdNr.: DE 135 098 121 ? Steuer-Nr.: 30 292 04497 ? WEEE-Reg.-Nr. DE 83888045

_______________________________


 

From m-karicheri2 at ti.com  Thu Feb 18 11:26:36 2010
From: m-karicheri2 at ti.com (Karicheri, Muralidharan)
Date: Thu, 18 Feb 2010 11:26:36 -0600
Subject: IPIPE memory allocation failure.
In-Reply-To: <4B7D2FCC.4050904@einfochips.com>
References: <4B7D2FCC.4050904@einfochips.com>
Message-ID: <A69FA2915331DC488A831521EAE36FE40169C5CA50@dlee06.ent.ti.com>

Yes.

What you see is failure due to fragmentation. Probably use CMEM to allocate buffer and pass it to IPIPE using userptr IO instead of mmap.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-karicheri2 at ti.com

________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Krunal Patil
Sent: Thursday, February 18, 2010 7:17 AM
To: davinci-linux-open-source
Subject: IPIPE memory allocation failure.

Hi,

I am working on a DM355 based system which consist of QT GUI and backend applications. The backend applications are responsible for MPEG (1024x768) / JPEG (1920/1080) capture/display and G711 audio capture/playback. For resized JPEG display (1920x1080 -> 768x576) I am using DM355 IPIPE module and successfully able to resize JPEG image without any corruption.

The problem is when I run the system for a long time and hard/soft reboot it the next time IPIPE memory allocation (IPIPE_REQBUF ioctl) of size (1344 * ((1080 * 2 + 31) & (~31))) = 2924544 fails. System has 128MB of DDR out of which 108M are given to Linux kernel from the bootargs.

Can this issue be related with memory fragmentation? Anyone please suggest me some pointers?




--

Regards,

Krunal Patil

--
________________________________
Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email.
________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100218/bdc397ec/attachment.html>

From Robert.Chen at ingenient.com  Thu Feb 18 13:03:54 2010
From: Robert.Chen at ingenient.com (Robert Chen)
Date: Thu, 18 Feb 2010 13:03:54 -0600
Subject: davinci linux mailing bounces
Message-ID: <4DA89577C33E194ABEBC978921E8585401DE64D7@exchange.ingenient.net>


Thanks for the information.  Those 2 addresses are for people who are
no longer with ingenient (in fact, they haven't been for several
years ...).  I've sent a formal request to the list owner to please 
remove those names from the list.  Sorry for the trouble.


     -Robert Chen



From nsekhar at ti.com  Fri Feb 19 09:27:52 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Fri, 19 Feb 2010 20:57:52 +0530
Subject: Which linux kernel tree to use for development?
In-Reply-To: <C5A8FDEFF7647F4C9CB927D7DEB307730E0117FE@ahr075s.basler.corp>
References: <C5A8FDEFF7647F4C9CB927D7DEB307730E0117FE@ahr075s.basler.corp>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E5B8ACE2@dbde02.ent.ti.com>


Hello,

On Thu, Feb 18, 2010 at 22:32:10, Koeller, T. wrote:
> Hi,
>
> being in the early stages of porting the kernel to a new DaVinci-based platform,
> I found that there are two git repositories specifically targeted at DaVinci development,
> namely the one at arago-project.org/git/projects/linux-davinci.git, and another one
> which is at git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git.
> This raises the question which one I should use as a foundation for my work, and
> how these trees are related to each other. I tried to apply git to find out about
> that, and came to the conclusion that both trees are mostly independent and no
> merges have recently been done between them. OTOH, active development appears to
> be going on on both trees. Can anyone provide information?

The tree hosted on arago-project.org is contains work in progress
some of which may not been accepted (or even submitted) in mainline
yet. Once the code receives sufficient testing there, it makes its
way upstream through various subsystem tree through patch submissions
(to this list and to other subsystem lists).

The tree on git.kernel.org is maintained by Kevin Hilman who uses
it to host code accepted by him for the next kernel merge window.
He uses this tree to send pull requests to Linus. Sometimes he also
hosts patches accepted on other subsystem trees while we wait for
the trees to merge.

The tree on arago-project.org derives from that on git.kernel.org
plus some non-mainline work.

You will find more functionality on arago-project.org, but the
functionality which has not been accepted upstream may change drastically
by the time the code is accepted mainline.

The wiki page below describes the functionality status on arago-project.org
tree:

http://wiki.davincidsp.com/index.php/DaVinci_GIT_Linux_Kernel_Releases

Thanks,
Sekhar


From lamiaposta71 at gmail.com  Mon Feb 22 02:54:08 2010
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Mon, 22 Feb 2010 09:54:08 +0100
Subject: Which linux kernel tree to use for development?
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E5B8ACE2@dbde02.ent.ti.com>
References: <C5A8FDEFF7647F4C9CB927D7DEB307730E0117FE@ahr075s.basler.corp>
	<B85A65D85D7EB246BE421B3FB0FBB59301E5B8ACE2@dbde02.ent.ti.com>
Message-ID: <ade1bdc1002220054m74ea3b65s71ba51dd0aca477c@mail.gmail.com>

Hi Nori,

> The tree hosted on arago-project.org is contains work in progress
> some of which may not been accepted (or even submitted) in mainline
> yet. Once the code receives sufficient testing there, it makes its
> way upstream through various subsystem tree through patch submissions
> (to this list and to other subsystem lists).

I see the following git logs:

http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
branch master
commit 05742210d3ecf8d4d41006834723e4d85a86d8bf
Merge: a63bdb1... dee1f3a...
Author: Kevin Hilman <khilman at deeprootsystems.com>
Date:   Thu Feb 4 14:33:07 2010 -0800

and

http://arago-project.org/git/projects/linux-davinci.git
branch master
commit ac5232ccca310aaa8cae9cbca1791b69afab6c99
Author: Sneha Narnakaje <nsnehaprabha at ti.com>
Date:   Mon Jan 11 15:31:37 2010 -0500

I'm customizing a new kernel for my DaVinci board (dm365), so I was
basing it on the arago repo.
Is there a kernel roadmap about arago and khilman development?
Looking at wiki documentation I see that dm365 support lacks:
 * Audio (ALSA ASoC based) driver with internal voice codec support (DM365)
 * Facedetect driver support (DM365)

Any plan about them?
I'm looking at master branches for both trees, I'm right?

Thank you very much,
Raffaele

> The tree on git.kernel.org is maintained by Kevin Hilman who uses
> it to host code accepted by him for the next kernel merge window.
> He uses this tree to send pull requests to Linus. Sometimes he also
> hosts patches accepted on other subsystem trees while we wait for
> the trees to merge.
>
> The tree on arago-project.org derives from that on git.kernel.org
> plus some non-mainline work.
>
> You will find more functionality on arago-project.org, but the
> functionality which has not been accepted upstream may change drastically
> by the time the code is accepted mainline.
>
> The wiki page below describes the functionality status on arago-project.org
> tree:
>
> http://wiki.davincidsp.com/index.php/DaVinci_GIT_Linux_Kernel_Releases
>
> Thanks,
> Sekhar
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>



-- 
www.opensurf.it

From gasparini at imavis.com  Mon Feb 22 03:57:08 2010
From: gasparini at imavis.com (Andrea Gasparini)
Date: Mon, 22 Feb 2010 10:57:08 +0100
Subject: Which linux kernel tree to use for development?
In-Reply-To: <ade1bdc1002220054m74ea3b65s71ba51dd0aca477c@mail.gmail.com>
References: <C5A8FDEFF7647F4C9CB927D7DEB307730E0117FE@ahr075s.basler.corp>
	<B85A65D85D7EB246BE421B3FB0FBB59301E5B8ACE2@dbde02.ent.ti.com>
	<ade1bdc1002220054m74ea3b65s71ba51dd0aca477c@mail.gmail.com>
Message-ID: <201002221057.08247.gasparini@imavis.com>

Raffaele Recalcati spiffera, Monday 22 February 2010 circa:
> Any plan about them?
> I'm looking at master branches for both trees, I'm right?

About alsa and other 'common' featutres, you can look at this:
http://wiki.davincidsp.com/index.php?title=DaVinci_GIT_Linux_Kernel

About face detection, don't know. ( I'll be glad of any pointer about this, 
as well )

bye
-- 
Andrea Gasparini 
---- ImaVis S.r.l. ----
web: www.imavis.com

From caglarakyuz at gmail.com  Mon Feb 22 05:36:23 2010
From: caglarakyuz at gmail.com (Caglar Akyuz)
Date: Mon, 22 Feb 2010 13:36:23 +0200
Subject: Which linux kernel tree to use for development?
In-Reply-To: <ade1bdc1002220054m74ea3b65s71ba51dd0aca477c@mail.gmail.com>
References: <C5A8FDEFF7647F4C9CB927D7DEB307730E0117FE@ahr075s.basler.corp>
	<B85A65D85D7EB246BE421B3FB0FBB59301E5B8ACE2@dbde02.ent.ti.com>
	<ade1bdc1002220054m74ea3b65s71ba51dd0aca477c@mail.gmail.com>
Message-ID: <201002221336.23180.caglarakyuz@gmail.com>

On Monday 22 February 2010 10:54:08 am Raffaele Recalcati wrote:
> Hi Nori,

[...]

> I'm customizing a new kernel for my DaVinci board (dm365), so I was
> basing it on the arago repo.

I may be mistaken here, but Arago repo is rebased, publically. So pulling 
updates after your local changes can be a little problem.

Regards,
Caglar

> Is there a kernel roadmap about arago and khilman development?
> Looking at wiki documentation I see that dm365 support lacks:
>  * Audio (ALSA ASoC based) driver with internal voice codec support (DM365)
>  * Facedetect driver support (DM365)
> 
> Any plan about them?
> I'm looking at master branches for both trees, I'm right?
> 
> Thank you very much,
> Raffaele
> 
> > The tree on git.kernel.org is maintained by Kevin Hilman who uses
> > it to host code accepted by him for the next kernel merge window.
> > He uses this tree to send pull requests to Linus. Sometimes he also
> > hosts patches accepted on other subsystem trees while we wait for
> > the trees to merge.
> >
> > The tree on arago-project.org derives from that on git.kernel.org
> > plus some non-mainline work.
> >
> > You will find more functionality on arago-project.org, but the
> > functionality which has not been accepted upstream may change drastically
> > by the time the code is accepted mainline.
> >
> > The wiki page below describes the functionality status on
> > arago-project.org tree:
> >
> > http://wiki.davincidsp.com/index.php/DaVinci_GIT_Linux_Kernel_Releases
> >
> > Thanks,
> > Sekhar
> >
> > _______________________________________________
> > Davinci-linux-open-source mailing list
> > Davinci-linux-open-source at linux.davincidsp.com
> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 

From gasparini at imavis.com  Mon Feb 22 05:50:11 2010
From: gasparini at imavis.com (Andrea Gasparini)
Date: Mon, 22 Feb 2010 12:50:11 +0100
Subject: interpreting 'slab corruption' output.
Message-ID: <201002221250.11477.gasparini@imavis.com>

Hi,
I'm running a 2.6.18 MV kernel, I'm having some output like that:

Slab corruption: start=c061e180, len=256
000: 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00
010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
040: 2b 80 00 00 13 00 00 00 2c 80 00 00 08 00 00 00
050: 2d 80 00 00 08 00 00 00 2e 80 00 00 11 00 00 00
Prev obj: start=c061e080, len=256
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Next obj: start=c061e280, len=256
000: 20 00 00 00 08 00 00 00 20 00 00 00 08 00 00 00
010: 20 00 00 00 10 00 00 00 20 00 00 00 08 00 00 00

Has someone a pointer on how to interpret slab corruption output?
I'm guessing that first 'object' is the memory the kernel recognize as 
'corrupted'.

The obscure thing is the 'len' argument, because at 'c061e080' there's an 
object that I actually use, but isn't 256 long. It's more something like 
512bytes: the address in c061e180 *has* to be written after "prev obj"...

any clue on this?
thanks. bye!
-- 
Andrea Gasparini 
---- ImaVis S.r.l. ----
web: www.imavis.com

From lamiaposta71 at gmail.com  Mon Feb 22 08:21:42 2010
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Mon, 22 Feb 2010 15:21:42 +0100
Subject: Which linux kernel tree to use for development?
In-Reply-To: <201002221336.23180.caglarakyuz@gmail.com>
References: <C5A8FDEFF7647F4C9CB927D7DEB307730E0117FE@ahr075s.basler.corp>
	<B85A65D85D7EB246BE421B3FB0FBB59301E5B8ACE2@dbde02.ent.ti.com>
	<ade1bdc1002220054m74ea3b65s71ba51dd0aca477c@mail.gmail.com>
	<201002221336.23180.caglarakyuz@gmail.com>
Message-ID: <ade1bdc1002220621n4e4c7f98y52149b8e4590a68e@mail.gmail.com>

2010/2/22 Caglar Akyuz <caglarakyuz at gmail.com>:
> On Monday 22 February 2010 10:54:08 am Raffaele Recalcati wrote:
>> Hi Nori,
>
> [...]
>
>> I'm customizing a new kernel for my DaVinci board (dm365), so I was
>> basing it on the arago repo.
>
> I may be mistaken here, but Arago repo is rebased, publically. So pulling
> updates after your local changes can be a little problem.

Hi Caglar,
I don't have local changes, I work on a different branch.

Anyway, for a better check I did:

git clone http://arago-project.org/git/projects/linux-davinci.git
git log

commit ac5232ccca310aaa8cae9cbca1791b69afab6c99
Author: Sneha Narnakaje <nsnehaprabha at ti.com>
Date:   Mon Jan 11 15:31:37 2010 -0500

    DM365: update default configuration - disable misc input driver
for IR remote

    This patch disables the misc input driver for IR remote so that DVSDK
    demos can directly get the IR input/output from MSP430 via I2C. The misc
    input driver had to be disabled so that MSP430 I2C address is not already
    taken up by this driver.

    Signed-off-by: Sneha Narnakaje <nsnehaprabha at ti.com>

-----------

http protocol is good?
in my company I can't use git itself.

Bye,
Raffaele

From rohan_javed at yahoo.co.uk  Mon Feb 22 08:51:04 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Mon, 22 Feb 2010 06:51:04 -0800 (PST)
Subject: HOW TO TRANSFER A FILE VIA serial in LINUX
Message-ID: <54612.71456.qm@web24101.mail.ird.yahoo.com>

Hello everyone i want to know how to transfer any file via /dev/ttyS0 to flash while linux is running on ttyS0

Regard's
RT



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100222/f30c802a/attachment.html>

From nick.thompson at ge.com  Mon Feb 22 08:53:58 2010
From: nick.thompson at ge.com (Nick Thompson)
Date: Mon, 22 Feb 2010 14:53:58 +0000
Subject: HOW TO TRANSFER A FILE VIA serial in LINUX
In-Reply-To: <54612.71456.qm@web24101.mail.ird.yahoo.com>
References: <54612.71456.qm@web24101.mail.ird.yahoo.com>
Message-ID: <4B829A86.3060908@ge.com>

On 22/02/10 14:51, rohan tabish wrote:
> Hello everyone i want to know how to transfer any file via /dev/ttyS0 to flash while linux is running on ttyS0

Try Zmodem. Once installed you can use the rz (and sz) commands
and your terminals Zmodem send (or receive) file...

Nick.

From rohan_javed at yahoo.co.uk  Mon Feb 22 09:21:54 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Mon, 22 Feb 2010 07:21:54 -0800 (PST)
Subject: Loadb equailent in linux
Message-ID: <910337.89120.qm@web24101.mail.ird.yahoo.com>

Hello everyon we are using DM6446 i don't have any ethernet port in our custom board i want to know how to transfer a file using serial port once we get to the linux prompt how to add file to the file system using the prompt via serial port

Regard's
Rohan Tabish 



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100222/33d510fd/attachment.html>

From nick.thompson at ge.com  Mon Feb 22 10:05:27 2010
From: nick.thompson at ge.com (Nick Thompson)
Date: Mon, 22 Feb 2010 16:05:27 +0000
Subject: HOW TO TRANSFER A FILE VIA serial in LINUX
In-Reply-To: <915500.20758.qm@web24105.mail.ird.yahoo.com>
References: <915500.20758.qm@web24105.mail.ird.yahoo.com>
Message-ID: <4B82AB47.5000902@ge.com>

On 22/02/10 15:26, rohan tabish wrote:
> Nick thanks for your reply i have chossen busybox providing the linux utilities do you know is dere any utlity in it to transfer the file 
> 
> Regard's
> RT 

I'm not a busybox expert, but I don't think it includes zmodem tools.

May be you could try http://www.ohse.de/uwe/software/lrzsz.html

Nick.

From nick.thompson at ge.com  Mon Feb 22 10:27:52 2010
From: nick.thompson at ge.com (Nick Thompson)
Date: Mon, 22 Feb 2010 16:27:52 +0000
Subject: HOW TO TRANSFER A FILE VIA serial in LINUX
In-Reply-To: <4B82AB47.5000902@ge.com>
References: <915500.20758.qm@web24105.mail.ird.yahoo.com>
	<4B82AB47.5000902@ge.com>
Message-ID: <4B82B088.3080100@ge.com>

On 22/02/10 16:05, Nick Thompson wrote:
> On 22/02/10 15:26, rohan tabish wrote:
>> Nick thanks for your reply i have chossen busybox providing the linux utilities do you know is dere any utlity in it to transfer the file 
>>
>> Regard's
>> RT 
> 
> I'm not a busybox expert, but I don't think it includes zmodem tools.
> 
> May be you could try http://www.ohse.de/uwe/software/lrzsz.html

On my system, busybox does supply rx, which is the Xmodem equivalent
of rz. That can probably work for you if you have it.

Nick.

From nsekhar at ti.com  Mon Feb 22 11:27:18 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 22 Feb 2010 22:57:18 +0530
Subject: Which linux kernel tree to use for development?
In-Reply-To: <ade1bdc1002220054m74ea3b65s71ba51dd0aca477c@mail.gmail.com>
References: <C5A8FDEFF7647F4C9CB927D7DEB307730E0117FE@ahr075s.basler.corp>
	<B85A65D85D7EB246BE421B3FB0FBB59301E5B8ACE2@dbde02.ent.ti.com>
	<ade1bdc1002220054m74ea3b65s71ba51dd0aca477c@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E5CCAF8A@dbde02.ent.ti.com>

Hello Raffaele,

On Mon, Feb 22, 2010 at 14:24:08, Raffaele Recalcati wrote:
> Hi Nori,
>

[...]

>
> I'm customizing a new kernel for my DaVinci board (dm365), so I was
> basing it on the arago repo.
> Is there a kernel roadmap about arago and khilman development?

There was a temporary lull in last two months on the Arago kernel
because of increased focus on omap-l1. We will restart activity in
March - starting with rebasing patches to the newest kernel from
Kevin's tree.

Activity in Kevin's tree doesn't really have a roadmap (except
periodically rebasing to latest from Linus's kernel) - it depends
on community's participation in helping get stuff upstream.

> Looking at wiki documentation I see that dm365 support lacks:
>  * Audio (ALSA ASoC based) driver with internal voice codec support (DM365)

This was worked on by Miguel lately[1]. These will be pulled into
the arago tree with the next rebase.

>  * Facedetect driver support (DM365)

There is a version of driver available in MV Linux 2.6.18 based
LSP 02.10[1] (drivers/char/dm365_facedetect_hw.c). The best bet
for you currently would be to up-port this to latest kernel.

Thanks,
Sekhar

[1] http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg16622.html
[2] http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_2_10/latest/index_FDS.html




From rohan_javed at yahoo.co.uk  Mon Feb 22 11:35:19 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Mon, 22 Feb 2010 09:35:19 -0800 (PST)
Subject: HOW TO TRANSFER A FILE VIA serial in LINUX
In-Reply-To: <4B82AB47.5000902@ge.com>
Message-ID: <373135.28116.qm@web24104.mail.ird.yahoo.com>

xmodem in busybox works fine

--- On Mon, 22/2/10, Nick Thompson <nick.thompson at ge.com> wrote:

From: Nick Thompson <nick.thompson at ge.com>
Subject: Re: HOW TO TRANSFER A FILE VIA serial in LINUX
To: "rohan tabish" <rohan_javed at yahoo.co.uk>
Cc: "davinci-linux-open-source at linux.davincidsp.com" <davinci-linux-open-source at linux.davincidsp.com>
Date: Monday, 22 February, 2010, 21:05

On 22/02/10 15:26, rohan tabish wrote:
> Nick thanks for your reply i have chossen busybox providing the linux utilities do you know is dere any utlity in it to transfer the file 
> 
> Regard's
> RT 

I'm not a busybox expert, but I don't think it includes zmodem tools.

May be you could try http://www.ohse.de/uwe/software/lrzsz.html

Nick.



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100222/ab4beac9/attachment.html>

From nsekhar at ti.com  Mon Feb 22 11:37:14 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 22 Feb 2010 23:07:14 +0530
Subject: Which linux kernel tree to use for development?
In-Reply-To: <201002221336.23180.caglarakyuz@gmail.com>
References: <C5A8FDEFF7647F4C9CB927D7DEB307730E0117FE@ahr075s.basler.corp>
	<B85A65D85D7EB246BE421B3FB0FBB59301E5B8ACE2@dbde02.ent.ti.com>
	<ade1bdc1002220054m74ea3b65s71ba51dd0aca477c@mail.gmail.com>
	<201002221336.23180.caglarakyuz@gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E5CCAF96@dbde02.ent.ti.com>

On Mon, Feb 22, 2010 at 17:06:23, Caglar Akyuz wrote:
> On Monday 22 February 2010 10:54:08 am Raffaele Recalcati wrote:
> > Hi Nori,
>
> [...]
>
> > I'm customizing a new kernel for my DaVinci board (dm365), so I was
> > basing it on the arago repo.
>
> I may be mistaken here, but Arago repo is rebased, publically. So pulling
> updates after your local changes can be a little problem.

Hi Caglar,

We treat it as a 'staging' repository for patches lined up for upstream
submissions so we don't flinch when squashing patches where it makes sense
- which rewrites history.

Thanks,
Sekhar


From caglarakyuz at gmail.com  Mon Feb 22 11:50:49 2010
From: caglarakyuz at gmail.com (Caglar Akyuz)
Date: Mon, 22 Feb 2010 19:50:49 +0200
Subject: Which linux kernel tree to use for development?
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E5CCAF96@dbde02.ent.ti.com>
References: <C5A8FDEFF7647F4C9CB927D7DEB307730E0117FE@ahr075s.basler.corp>
	<201002221336.23180.caglarakyuz@gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E5CCAF96@dbde02.ent.ti.com>
Message-ID: <201002221950.49136.caglarakyuz@gmail.com>

On Monday 22 February 2010 07:37:14 pm Nori, Sekhar wrote:
> On Mon, Feb 22, 2010 at 17:06:23, Caglar Akyuz wrote:
> > On Monday 22 February 2010 10:54:08 am Raffaele Recalcati wrote:
> > > Hi Nori,
> >
> > [...]
> >
> > > I'm customizing a new kernel for my DaVinci board (dm365), so I was
> > > basing it on the arago repo.
> >
> > I may be mistaken here, but Arago repo is rebased, publically. So pulling
> > updates after your local changes can be a little problem.
> 
> Hi Caglar,
> 

Hi,

> We treat it as a 'staging' repository for patches lined up for upstream
> submissions so we don't flinch when squashing patches where it makes sense
> - which rewrites history.
> 

It was a mark rather than a critic. I'm using Arago tree for my work and I 
find it quite useful as the way it is. Your efforts are much appreciated.

Regards,
Caglar

> Thanks,
> Sekhar
> 

From nsekhar at ti.com  Mon Feb 22 22:17:34 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 23 Feb 2010 09:47:34 +0530
Subject: Which linux kernel tree to use for development?
In-Reply-To: <201002221950.49136.caglarakyuz@gmail.com>
References: <C5A8FDEFF7647F4C9CB927D7DEB307730E0117FE@ahr075s.basler.corp>
	<201002221336.23180.caglarakyuz@gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E5CCAF96@dbde02.ent.ti.com>
	<201002221950.49136.caglarakyuz@gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E5CCB0B0@dbde02.ent.ti.com>

On Mon, Feb 22, 2010 at 23:20:49, Caglar Akyuz wrote:
> On Monday 22 February 2010 07:37:14 pm Nori, Sekhar wrote:
> > On Mon, Feb 22, 2010 at 17:06:23, Caglar Akyuz wrote:
> > > On Monday 22 February 2010 10:54:08 am Raffaele Recalcati wrote:
> > > > Hi Nori,
> > >

[...]

> > >
> > > I may be mistaken here, but Arago repo is rebased, publically. So pulling
> > > updates after your local changes can be a little problem.
> >
> > Hi Caglar,
> >
>
> Hi,
>
> > We treat it as a 'staging' repository for patches lined up for upstream
> > submissions so we don't flinch when squashing patches where it makes sense
> > - which rewrites history.
> >
>
> It was a mark rather than a critic. I'm using Arago tree for my work and I
> find it quite useful as the way it is. Your efforts are much appreciated.
>

No problem. We do get this question (even internally) so
I thought I will clarify why things are the way they are.

Thanks,
Sekhar

From aspnair at gmail.com  Tue Feb 23 00:11:48 2010
From: aspnair at gmail.com (Anand Sivaram)
Date: Tue, 23 Feb 2010 11:41:48 +0530
Subject: controlloing video display brighness/contrast on dm6446
Message-ID: <d0bf7b0b1002222211u16e528aboc8a88030e293ccaf@mail.gmail.com>

Hello All,

I am using fbdev on a dm6446 to playout video.
Is there any way of controlling the brighness/contrast
of the video?  After going through vpbe backend (sprue37)
document, I could not find any way of doing it.
Is there any particular register settings for that?

Thanks and Regards

Anand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100223/c5bd316d/attachment.html>

From rafael7n at gmail.com  Tue Feb 23 05:13:48 2010
From: rafael7n at gmail.com (Rafael Setti Nogueira)
Date: Tue, 23 Feb 2010 08:13:48 -0300
Subject: Ethernet application on DM6446 - Da Vinci
Message-ID: <1c02c8191002230313w6abb68c9t72e87237ea5b2af4@mail.gmail.com>

Hello everybody,
I am very new on using Da Vinci plataform, and I am full of doubts.
I really need to quickly develop an application that uses the ethernet
peripheral to connect to an Cyclone 3 development kit from Altera. Since I
am developing on the Embedded Linux on the Da Vinci and I am also new on
linux systems I am not familiarized with Linux devices drives. I have
already developed an code to use the OSD through its device drive located on
/etc/dev/fb/0. It was quietly easy to do that, but when it comes to Ethernet
I don't have a clue on where to begin. Is there an specific device drive on
the embedded linux on Da Vinci platform where i can just just like in OSD
case and perform an ethernet packet transfer? Someone told me Linux has a
library already implemented for ethernet called socket.h, how can I use that
to build a server client connection? Does anyone has a source code on which
I can test and develop an ethernet connection ?

Thanks in advance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100223/8a5a41be/attachment.html>

From swami.iyer at ti.com  Tue Feb 23 09:49:55 2010
From: swami.iyer at ti.com (Subbrathnam, Swaminathan)
Date: Tue, 23 Feb 2010 21:19:55 +0530
Subject: need to know about usbaudio.
In-Reply-To: <d61c39561002192228g196938f0me9efab8c265f9c49@mail.gmail.com>
References: <d61c39561002190136h101f5bd4w7370f2c6a51df7c5@mail.gmail.com>
	<FCCFB4CDC6E5564B9182F639FC3560870303F501F5@dbde02.ent.ti.com>
	<d61c39561002192228g196938f0me9efab8c265f9c49@mail.gmail.com>
Message-ID: <FCCFB4CDC6E5564B9182F639FC356087030408C243@dbde02.ent.ti.com>

Pratik,
	Have you updated your kernel with the latest patches that are released?

	The increased interrupt loading in the ISO case cannot be avoided.  It is how the controller was designed to work.

Regards
swami

> -----Original Message-----
> From: Pratik Prajapati [mailto:pratik.prajapati at gmail.com]
> Sent: Saturday, February 20, 2010 11:58 AM
> To: Subbrathnam, Swaminathan
> Cc: linux-usb at vger.kernel.org
> Subject: Re: need to know about usbaudio.
> 
> Hello Swami,
> 
> Thank you for your reply.
> 
> My issue is,
> 
> I want to make best use of DMA to get better performance. (better
> performance means less CPU usage and less interrupts.) My clients
> wants better performance, as he is going to run CPU hungry application
> which will do USB BULK+ISO xfer.
> 
> With DMA, my BULK xfer takes same CPU capared to 'without DMA', but I
> get lesser intereputs 'WITH DMA'.
> With DMA, my ISO xfer takes more CPU capared to 'without DMA', and I
> see same no. of interrupts 'WITH DMA'.
> 
> So I'm getting advantage of using DMA in BULK xfer, but ISO xfer gets
> worst( as CPU usage goes very high in ISO xfer because of ksoftirqd).
> 
> For ISO xfer,Without DMA my CPU usage is total 1% to 6% (i.e. 1% to 5%
> audio player app takes + 0% to 1% ksoftirqd takes).
> For ISO xfer, With DMA my CPU usage is total 20% to 32% (i.e. 0% to 2%
> audio player app takes + 20% to 30% ksoftirqd takes).
> 
> With DMA, I see overall CPU usage go very high compared to 'without
> DMA' i.e. for ISO xfer. because of ksoftirqd.
> I think musb schdules tasklets in davinci_interrupt isr for DMA. Which
> inturn makes a lot of sort irqs and so ksoftirqd eats of a lot of
> CPU(around 20% to 30%).
> 
> with DMA, ISO xfer gets worst as ksoftirqd eats up a lot of CPU
> campared to "WITHOUT DMA"
> 
> Kindly suggest me how can I get best performace with DMA for both ISO and
> BULK?
> 
> Thank you in advance.
> 
> On Sat, Feb 20, 2010 at 12:57 AM, Subbrathnam, Swaminathan
> <swami.iyer at ti.com> wrote:
> > Pratik,
> > ? ? ? ?The increased interrupt activity during ISO transactions is
> expected.
> >
> > ? ? ? ?Can you provide information on the actual issue you are facing.
> ?Are you not able to stream/run application etc. due to the increased
> interrupts?
> >
> > Regards
> > Swami
> >
> >> -----Original Message-----
> >> From: linux-usb-owner at vger.kernel.org [mailto:linux-usb-
> >> owner at vger.kernel.org] On Behalf Of Pratik Prajapati
> >> Sent: Friday, February 19, 2010 3:06 PM
> >> To: linux-usb at vger.kernel.org
> >> Subject: need to know about usbaudio.
> >>
> >> Hello,
> >>
> >> I'm doing playback/record with usbaudio on TI musb with ALSA.
> >>
> >> My concern is, in isochronus mode (with CPPI DMA) I see a lot of
> >> interrupts?and so?ksoftirqd takes up to 30% CPU in addition to Audio
> >> application. And in bulk mode(with CPPI DMA) I see less?interrupts and
> >> also?ksoftirqd is taking around 15% CPU?in addition to the
> >> application. Is there any way by which I can get lesser?interrupts in
> >> sochronus mode (with CPPI DMA)?
> >>
> >> my linux is: 2.6.10_mvl401, with
> >> musb_hdrc: version 2.2a/db-0.4.8 [cppi-dma] [host] [debug=1]
> >> musb_hdrc: ConfigData=0x06 (UTMI-8, dyn FIFOs, SoftConn)
> >> musb_hdrc: MHDRC RTL version 1.300
> >> musb_hdrc: USB Host mode controller at c8002000 using DMA, IRQ 12
> >> musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1
> >>
> >> I have observed that whether I play 8KHZ audio or 44KHZ audio, I see
> >> iso_frame_desc (packed in urb) ramains of same length, i.e. 176 bytes.
> >> e.g.
> >> I played 8KHZ audio and found that, musb is gets total 4
> >> iso_frame_desc in each URB. size of each?iso_frame_desc is 176 bytes.
> >> I played 44KHZ audio and found that, musb is gets total 4
> >> iso_frame_desc in each URB. size of each?iso_frame_desc is 176 bytes.
> >> In each URB musb gets 4?iso_frame_desc, which is fixed by variable
> >> 'static int nrpacks' in usbaudio.c.
> >>
> >> CPPI DMA makes buffer discriptors of each iso_frame_desc, which is
> >> very small chunk.
> >>
> >> Does it make sense that usbaudio passes larger iso_frame_desc to musb
> >> ( right now I'm getting 176 bytes iso_frame_desc each time)? so that
> >> CPPI DMA will send lesser interrupts to CPU.
> >>
> >> Please let me know if more information is required from my side.
> >>
> >> --
> >> Regards,
> >> Pratik PRAJAPATI
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> >> the body of a message to majordomo at vger.kernel.org
> >> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> >
> 
> 
> 
> --
> Regards,
> Pratik PRAJAPATI

From hvaibhav at ti.com  Tue Feb 23 23:40:29 2010
From: hvaibhav at ti.com (Hiremath, Vaibhav)
Date: Wed, 24 Feb 2010 11:10:29 +0530
Subject: [PATCH 3/9] tvp514x: add YUYV format support
In-Reply-To: <55a3e0ce1002231544o36a63a07if76501bff7967b45@mail.gmail.com>
References: <hvaibhav@ti.com>
	<1262613782-20463-4-git-send-email-hvaibhav@ti.com>
	<55a3e0ce1002231544o36a63a07if76501bff7967b45@mail.gmail.com>
Message-ID: <19F8576C6E063C45BE387C64729E7394044DA99713@dbde02.ent.ti.com>


> -----Original Message-----
> From: Muralidharan Karicheri [mailto:mkaricheri at gmail.com]
> Sent: Wednesday, February 24, 2010 5:15 AM
> To: Hiremath, Vaibhav
> Cc: linux-media at vger.kernel.org; linux-omap at vger.kernel.org;
> hverkuil at xs4all.nl; davinci-linux-open-source at linux.davincidsp.com;
> Karicheri, Muralidharan
> Subject: Re: [PATCH 3/9] tvp514x: add YUYV format support
> 
> Vaibhav,
> 
> 
> On Mon, Jan 4, 2010 at 9:02 AM,  <hvaibhav at ti.com> wrote:
> > From: Vaibhav Hiremath <hvaibhav at ti.com>
> >
> >
> > Signed-off-by: Vaibhav Hiremath <hvaibhav at ti.com>
> > ---
> > ?drivers/media/video/tvp514x.c | ? ?7 +++++++
> > ?1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
> > index 4cf3593..b344b58 100644
> > --- a/drivers/media/video/tvp514x.c
> > +++ b/drivers/media/video/tvp514x.c
> > @@ -212,6 +212,13 @@ static const struct v4l2_fmtdesc tvp514x_fmt_list[] =
> {
> > ? ? ? ? .description = "8-bit UYVY 4:2:2 Format",
> > ? ? ? ? .pixelformat = V4L2_PIX_FMT_UYVY,
> > ? ? ? ?},
> > + ? ? ? {
> > + ? ? ? ?.index = 1,
> > + ? ? ? ?.type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
> > + ? ? ? ?.flags = 0,
> > + ? ? ? ?.description = "8-bit YUYV 4:2:2 Format",
> > + ? ? ? ?.pixelformat = V4L2_PIX_FMT_YUYV,
> > + ? ? ? },
> > ?};
> 
> As per data sheet I can see only CbYCrY format output from the tvp5146
> which translate to UYVY. How are you configuring tvp to output YUYV? I
> don;t see any change to the code to configure this format.
> 
[Hiremath, Vaibhav] Yes you are right, actually this is dummy format created to support YUYV.
> CCDC can switch the CbCr order and also can swap Y/C order. So if you
> are achieving
> this via ccdc configuration, there is no need to add this format to tvp5146
> IMO.
> 
[Hiremath, Vaibhav] I think it makes sense to handle this is master driver, since we are handling this in CCDC. It could possible in the future TVP5146 might get used with SoC which don't have this capability. 

Thanks,
Vaibhav

> -Murali
> 
> >
> > ?/**
> > --
> > 1.6.2.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> >
> 
> 
> 
> --
> Murali Karicheri
> mkaricheri at gmail.com

From Ben.White at vcatechnology.com  Wed Feb 24 03:28:09 2010
From: Ben.White at vcatechnology.com (Ben White)
Date: Wed, 24 Feb 2010 09:28:09 -0000
Subject: Debugging spurious reboots
Message-ID: <95FAFD227E8A2947BA96E1C807505D0412CA7C@sbs001.office.local>

Hi Folks,

 

We have a video encoder product that is based on DM6446. GIT kernel
2.6.23-davinci1 and DVSDK 1.30.01.41.

 

We have some automated test tools that repeatedly change the codecs from
H.264->MJPEG->MPEG4-> etc (these simulate user actions). This results in
the whole of CE being torn down and re-setup during each codec switch.
There's also a heap of other stuff happening on the ARM at this point.

 

Anyway, the problem is that after about 30mins - 1hour of running the
automated test, the board reboots. There are no error messages, nothing
strange, memory usage looks OK. The watchdog is disabled.

 

So my question, is how to go about debugging this. My current attack
plan is just to start disabling stuff until the problem goes away and
then gradually bring back things to isolate the problem. But, there
should surely be a quicker way?

 

Cheers,

Ben

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100224/baf6ec58/attachment.html>

From pan at nt.tu-darmstadt.de  Wed Feb 24 05:42:27 2010
From: pan at nt.tu-darmstadt.de (Vladimir Pantelic)
Date: Wed, 24 Feb 2010 12:42:27 +0100
Subject: Debugging spurious reboots
In-Reply-To: <95FAFD227E8A2947BA96E1C807505D0412CA7C@sbs001.office.local>
References: <95FAFD227E8A2947BA96E1C807505D0412CA7C@sbs001.office.local>
Message-ID: <4B8510A3.8000606@nt.tu-darmstadt.de>

Ben White wrote:
> Hi Folks,
>
> We have a video encoder product that is based on DM6446. GIT kernel
> 2.6.23-davinci1 and DVSDK 1.30.01.41.
>
> We have some automated test tools that repeatedly change the codecs from
> H.264->MJPEG->MPEG4-> etc (these simulate user actions). This results in
> the whole of CE being torn down and re-setup during each codec switch.
> There?s also a heap of other stuff happening on the ARM at this point.
>
> Anyway, the problem is that after about 30mins ? 1hour of running the
> automated test, the board reboots. There are no error messages, nothing
> strange, memory usage looks OK. The watchdog is disabled.
>
> So my question, is how to go about debugging this. My current attack
> plan is just to start disabling stuff until the problem goes away and
> then gradually bring back things to isolate the problem. But, there
> should surely be a quicker way?

- logs? (dmesg -n 8)
- limit the codecs used to a smaller subset (e.g. only H264)
- isolate arm vs dsp/CE activity



From kiran.kumar at ittiam.com  Wed Feb 24 07:21:55 2010
From: kiran.kumar at ittiam.com (Kiran Kumar A)
Date: Wed, 24 Feb 2010 18:51:55 +0530
Subject: Query on 1080i video capture on DM6467EVM using GIT kernel 3.10.00.12
Message-ID: <904DEC693BE1AB429622C6F5ABA7E0B8071BCB26@is01ex02.ittiam.com>

Hi,

I am facing some issues while capturing 1080i (video std) using git
kernel version 3.10.00.12. I am using the HD Davinci EVM from TI. 

 

TVP 7002 is used to capture 1080i video on the EVM. TVP 5147 is also
present on the EVM to capture SD video. As DM6467 can support only one
encode at any instant, only one of these devices can be enabled to
capture video. Both these devices also have the same I2C address 0x5D. A
switching logic is present on the EVM to interface one of these two
video encoders to the processor.  The switching logic is controlled by
CPLD present on the EVM. DM6467 processor configures the CPLD through
i2c accesses.

 

Earlier PSP from TI with PSP version PSP_01_30_00_082 and DVSDK version
DVSDK-1_40_02_33 supports the i2c control logic. Thus we were able to
capture the video data from either of these interfaces, configuring each
of them at run time. I found that this feature is not supported in the
GIT kernel version: 3.10.00.12. 

 

I like to know if TI made any latest release fixing this issue. 

 

Regards,

Kiran Kumar A

 

 

_________________________________________________________________________________________________________________________________________________________
Please do not print this email unless it is absolutely necessary.

This email and any files transmitted with it are confidential and may be legally privileged. 
It is intended solely for the use of the individual or entity to whom they are addressed. 
If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this e-mail is prohibited. 
If you have received this information in error, please notify the sender immediately and destroy all copies of this message and any attachments. 

Warning: Computer viruses can be transmitted via email. 
E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed or incomplete. 
The recipient should check this email and any attachments for the presence of viruses. 
Ittiam therefore does not accept any liability for damage caused by virus, errors or omissions in the content, which may arise as a result of e-mail transmission. www.ittiam.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100224/f3596840/attachment.html>

From bgr at acdstar.com  Wed Feb 24 07:46:41 2010
From: bgr at acdstar.com (Brian Rhodes)
Date: Wed, 24 Feb 2010 07:46:41 -0600
Subject: Debugging spurious reboots
In-Reply-To: <95FAFD227E8A2947BA96E1C807505D0412CA7C@sbs001.office.local>
References: <95FAFD227E8A2947BA96E1C807505D0412CA7C@sbs001.office.local>
Message-ID: <4B852DC1.30408@acdstar.com>

Ben White wrote:
>
> Hi Folks,
>
> We have a video encoder product that is based on DM6446. GIT kernel 
> 2.6.23-davinci1 and DVSDK 1.30.01.41.
>
> We have some automated test tools that repeatedly change the codecs 
> from H.264->MJPEG->MPEG4-> etc (these simulate user actions). This 
> results in the whole of CE being torn down and re-setup during each 
> codec switch. There?s also a heap of other stuff happening on the ARM 
> at this point.
>
> Anyway, the problem is that after about 30mins ? 1hour of running the 
> automated test, the board reboots. There are no error messages, 
> nothing strange, memory usage looks OK. The watchdog is disabled.
>
> So my question, is how to go about debugging this. My current attack 
> plan is just to start disabling stuff until the problem goes away and 
> then gradually bring back things to isolate the problem. But, there 
> should surely be a quicker way?
>
> Cheers,
>
> Ben
>

Might be worth investigating heat.

From raghu_ramaraj at mindtree.com  Wed Feb 24 07:53:00 2010
From: raghu_ramaraj at mindtree.com (Raghu Ramaraj)
Date: Wed, 24 Feb 2010 19:23:00 +0530
Subject: DM6467 -BT656 progressive input 
Message-ID: <DE1563FF5EF45A4794D1220EF0363CB411B96471FA@MTW02MSG02.mindtree.com>

Hi,
      I would like to get the BT656 progressive input from image sensor. Right now we are porting the TVP5147.c driver code
We need the following information reading this ...

1)       How to get the Progressive input using TVP 5147 driver? Or how to change interlace to progressive mode?

2)       How to change the buffer allocation based on the resolution (VGA,/SD/) ?



Thanks & Regards,
Raghu


________________________________
http://www.mindtree.com/email/disclaimer.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100224/e4f59a2e/attachment.html>

From m-karicheri2 at ti.com  Wed Feb 24 10:27:55 2010
From: m-karicheri2 at ti.com (Karicheri, Muralidharan)
Date: Wed, 24 Feb 2010 10:27:55 -0600
Subject: vpfe capture support on DM365 merged to v4l sub system for 2.6.34
Message-ID: <A69FA2915331DC488A831521EAE36FE4016A2D83D4@dlee06.ent.ti.com>

Hi,

My latest set of patches for vpfe capture is merged to v4l subsystem linux-next tree for merge to 2.6.34. This will allow capture from TVP5146 on DM365. 

Thanks to everyone who reviewed the code and made this possible.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-karicheri2 at ti.com


From dato at digimeq.ru  Wed Feb 24 12:29:23 2010
From: dato at digimeq.ru (David Goshadze)
Date: Wed, 24 Feb 2010 21:29:23 +0300
Subject: 2.6.32 musb_hdrc fails to load (DM6446)
Message-ID: <1284591885.20100224212923@digimeq.ru>

Hi all!

Please help with the following problem:

I successfully loaded an built 2.6.32 for our DM6446 based board.

Everything's just fine except I cannot load musb_hdrc driver.
 I got:
  modprobe musb_hdrc : version 6.0, cppi-dma, peripherial, debug=0
  FATAL: Error inserting musb_hdrc (/lib/modules/2/6/32/kernel/drivers/usb/musb/musb_hdrc.ko): No such device
  nop_usb_xceiv loaded successfully.

  use_dma=n doesn't help.
  
Spending 2 days trying various kernel configurations and googling didn't help.

With 2.6.10 (mvl) everything was fine.

I'm nearly gone mad with this.

David.




From swami.iyer at ti.com  Wed Feb 24 12:33:27 2010
From: swami.iyer at ti.com (Subbrathnam, Swaminathan)
Date: Thu, 25 Feb 2010 00:03:27 +0530
Subject: 2.6.32 musb_hdrc fails to load (DM6446)
In-Reply-To: <1284591885.20100224212923@digimeq.ru>
References: <1284591885.20100224212923@digimeq.ru>
Message-ID: <FCCFB4CDC6E5564B9182F639FC356087030408C875@dbde02.ent.ti.com>

David,
	Could you try the aarago git davinci tree?

	From the below log it seems there could be a configuration issue between the base port and the driver init.

Regards
swami

> -----Original Message-----
> From: davinci-linux-open-source-
> bounces+swami.iyer=ti.com at linux.davincidsp.com [mailto:davinci-linux-open-
> source-bounces+swami.iyer=ti.com at linux.davincidsp.com] On Behalf Of David
> Goshadze
> Sent: Wednesday, February 24, 2010 11:59 PM
> To: davinci-linux-open-source at linux.davincidsp.com
> Subject: 2.6.32 musb_hdrc fails to load (DM6446)
> 
> Hi all!
> 
> Please help with the following problem:
> 
> I successfully loaded an built 2.6.32 for our DM6446 based board.
> 
> Everything's just fine except I cannot load musb_hdrc driver.
>  I got:
>   modprobe musb_hdrc : version 6.0, cppi-dma, peripherial, debug=0
>   FATAL: Error inserting musb_hdrc
> (/lib/modules/2/6/32/kernel/drivers/usb/musb/musb_hdrc.ko): No such device
>   nop_usb_xceiv loaded successfully.
> 
>   use_dma=n doesn't help.
> 
> Spending 2 days trying various kernel configurations and googling didn't
> help.
> 
> With 2.6.10 (mvl) everything was fine.
> 
> I'm nearly gone mad with this.
> 
> David.
> 
> 
> 
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From Alex.Tarter at ultra-cis.com  Thu Feb 25 03:22:45 2010
From: Alex.Tarter at ultra-cis.com (Alex Tarter)
Date: Thu, 25 Feb 2010 09:22:45 -0000
Subject: SPI with DM6446
Message-ID: <5B30463C3CBD6E42AF0DBB4E95DB38575F0DF8@SCS-21.ultra-scs.com>

I have trying to get my dm6446 running SDK2.0 to output on the SPI bus.
I was grateful to Josh Hintze who posted a driver on this forum a few
years ago (thank god for archives!), however I can't seem to get it to
work.

 

When I send a write command to the driver it sends the SPI_CLK, SPI_D0
and SPI_EN0 pins high but doesn't change their voltage. How do I get the
clock to start cycling and data to come out?

 

The driver is practically the same as the one given in
http://linux.omap.com/pipermail/davinci-linux-open-source/2008-March/005
587.html

 

And my user code is just a simple prog:

 

int main(Int argc, String argv[]) {

  int fd_spi;

  unsigned char *input_data;

  input_data = (unsigned char *)malloc(2);

  input_data[0] = 0xAA;

  input_data[1] = 0x2C;

 

  fd_spi = open("/dev/dv_spi", O_RDWR);

  if (fd_spi < 0) {

      printf("Failed to open /dev/dv_spi (%s)\n", strerror(errno));

      return -1;

  }

  write (fd_spi, input_data, 2);

  close(fd_spi);

  return (0);

}

 

What am I doing wrong? I just want to get some fast way of clocking out
my data on an IO line. I initially tried extending
davinci_spi_platform.c (in lsp/../arch/arm/mach-davinci) and including
the module in the kernel, but I couldn't work out how to access the
functions from user space.

 

Does anyone know a simple(ish) method of getting SPI to work on my
dm6446?

 

Thanks,

 

Alex

 

Alex Tarter

Systems Engineer

Ultra Electronics

Communication & Integrated Systems

Tel: +44 (0)20 8813 4527

www.ultra-electronics.com

 

Please note that our email address has changed to firstname.lastname at ultra-cis.com. This is to reflect the change in name to Ultra Electronics Communication and Integrated Systems, a business name of Ultra Electronics Limited.
DISCLAIMER
This e-mail from Ultra Electronics Limited and any attachments to it are confidential to the intended recipient and may also be privileged.  If you have received it in error please notify the sender and delete it from your system.  If you are not the intended recipient you must not copy it or use it for any purpose nor disclose or distribute its contents to any other person.  All communications may be subject to interception or monitoring for operational and/or security purposes.  Please rely on your own virus checking as the sender cannot accept any liability for any damage arising from any bug or virus infection.

Ultra Electronics Limited is a company registered in England and Wales, registration number 2830644.  The address of its registered office is 417 Bridport Road, Greenford, Middlesex, UB6 8UA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100225/bc506b66/attachment.html>

From rohan_javed at yahoo.co.uk  Thu Feb 25 04:23:08 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Thu, 25 Feb 2010 02:23:08 -0800 (PST)
Subject: DM6446 HELP:GPIO
Message-ID: <792255.31022.qm@web24104.mail.ird.yahoo.com>

Hello everyine i want to know how to acess lets say an LED which is connected to GPIO.

any help regarding it will be useful.I have seen the gpio.h file there are MACROS defined do i just need to use those MACROS

Regard's
RT




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100225/28c5cf47/attachment.html>

From dato at digimeq.ru  Thu Feb 25 04:39:31 2010
From: dato at digimeq.ru (David Goshadze)
Date: Thu, 25 Feb 2010 13:39:31 +0300
Subject: 2.6.32 musb_hdrc fails to load (DM6446)
In-Reply-To: <FCCFB4CDC6E5564B9182F639FC356087030408C875@dbde02.ent.ti.com>
References: <1284591885.20100224212923@digimeq.ru>
	<FCCFB4CDC6E5564B9182F639FC356087030408C875@dbde02.ent.ti.com>
Message-ID: <1789496250.20100225133931@digimeq.ru>

Hello Swaminathan,

Thank you for you help.

Unfortunately arago-git brought as much as the same result:

root at dm6446-evm:/# modprobe musb_hdrc
usbcore: registered new interface driver usbfs                                                                            
usbcore: registered new interface driver hub                                                                              
usbcore: registered new device driver usb                                                                                 
musb_hdrc: version 6.0, cppi-dma, host, debug=0                                                                           
FATAL: Error inserting musb_hdrc (/lib/modules/2.6.32-rc2-davinci1/kernel/drivers/usb/musb/musb_hdrc.ko): No such device  
root at dm6446-evm:/# lsmod                                                                                                  
Module                  Size  Used by                                                                                     
usbcore               108027  0                                                                                           
nop_usb_xceiv           1606  0                                                                                           
ipv6                  228907  10                                                                                          
minix                  25382  0                                                                                           
root at dm6446-evm:/#

David.

SS> David,
SS>         Could you try the aarago git davinci tree?

SS>         From the below log it seems there could be a
SS> configuration issue between the base port and the driver init.

SS> Regards
SS> swami

>> -----Original Message-----
>> From: davinci-linux-open-source-
>> bounces+swami.iyer=ti.com at linux.davincidsp.com [mailto:davinci-linux-open-
>> source-bounces+swami.iyer=ti.com at linux.davincidsp.com] On Behalf Of David
>> Goshadze
>> Sent: Wednesday, February 24, 2010 11:59 PM
>> To: davinci-linux-open-source at linux.davincidsp.com
>> Subject: 2.6.32 musb_hdrc fails to load (DM6446)
>> 
>> Hi all!
>> 
>> Please help with the following problem:
>> 
>> I successfully loaded an built 2.6.32 for our DM6446 based board.
>> 
>> Everything's just fine except I cannot load musb_hdrc driver.
>>  I got:
>>   modprobe musb_hdrc : version 6.0, cppi-dma, peripherial, debug=0
>>   FATAL: Error inserting musb_hdrc
>> (/lib/modules/2/6/32/kernel/drivers/usb/musb/musb_hdrc.ko): No such device
>>   nop_usb_xceiv loaded successfully.
>> 
>>   use_dma=n doesn't help.
>> 
>> Spending 2 days trying various kernel configurations and googling didn't
>> help.
>> 
>> With 2.6.10 (mvl) everything was fine.
>> 
>> I'm nearly gone mad with this.
>> 
>> David.
>> 
>> 
>> 
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source at linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source



___________________________
David Goshadze,
Chief project developer,
PLC Digimeq,
5, Vozdvizhenka str.
Moscow, Russian Federation

Ph +7 495 9505231
Mob +7 916 604 56 93
Fax +7 495 9505231
dato at digimeq.ru
www.digimeq.com


From rohan_javed at yahoo.co.uk  Thu Feb 25 05:32:56 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Thu, 25 Feb 2010 03:32:56 -0800 (PST)
Subject: Enabling and using ASP interface
Message-ID: <143837.70756.qm@web24104.mail.ird.yahoo.com>

Anyone knows how to use the ASP interface on ARM

Regard's
RT



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100225/f3f394f9/attachment.html>

From Sriraja_Yagneswaran at mindtree.com  Thu Feb 25 05:43:03 2010
From: Sriraja_Yagneswaran at mindtree.com (Sriraja Yagneswaran)
Date: Thu, 25 Feb 2010 17:13:03 +0530
Subject: Compiling with link arbiter enabled on dvsdk2.0
Message-ID: <EA7C0E7A4EF62348884B24E35F046DC001AF114C6F@MTW02MSG01.mindtree.com>

Hello All,

I have a codec engine based application that has been built with tools from dvsdk 1.40 (with CE 2.10.02, dsplink 1.50).

I'm trying to migrate to dvsdk2.0 and the application does not compile citing undefined references to LAD functions. I have enabled the use of linkarbiter in the app's CE config script as follows for using multiple instances of the application to access the DSP engine.
osalGlobal.useLinkArbiter = true;
The app compiles if comment out the line enabling the use of linkArbiter, though I'm yet to check if the application runs.

Are there any path settings or configuration changes that I'm missing out? Does any library have to be recompiled?


Following is an extract of the errors that I observe:
/home/test/dvsdk_2_00_00_22/codec_engine_2_23_01/packages/ti/sdo/ce/ipc/dsplink/lib/release/ipc_dsplink_6467.av5T(Processor_dsplink.ov5T): In function `procDelete':
Processor_dsplink.c:(.text+0x524): undefined reference to `LAD_releaseDsp'
Processor_dsplink.c:(.text+0x558): undefined reference to `LAD_disconnect'
/home/test/dvsdk_2_00_00_22/codec_engine_2_23_01/packages/ti/sdo/ce/ipc/dsplink/lib/release/ipc_dsplink_6467.av5T(Processor_dsplink.ov5T): In function `daemon':
Processor_dsplink.c:(.text+0xbd4): undefined reference to `LAD_connect'
Processor_dsplink.c:(.text+0xc18): undefined reference to `LAD_startupDsp'



Thanks and Regards
Sriraja



  ________________________________
http://www.mindtree.com/email/disclaimer.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100225/189c4e10/attachment.html>

From ottavio.campana at dei.unipd.it  Thu Feb 25 07:54:55 2010
From: ottavio.campana at dei.unipd.it (Ottavio Campana)
Date: Thu, 25 Feb 2010 14:54:55 +0100
Subject: DM6446 HELP:GPIO
In-Reply-To: <792255.31022.qm@web24104.mail.ird.yahoo.com>
References: <792255.31022.qm@web24104.mail.ird.yahoo.com>
Message-ID: <4B86812F.4070106@dei.unipd.it>

Il 25/02/10 11.23, rohan tabish ha scritto:
> Hello everyine i want to know how to acess lets say an LED which is
> connected to GPIO.
>
> any help regarding it will be useful.I have seen the gpio.h file there
> are MACROS defined do i just need to use those MACROS

if on the dvevm

http://tiexpressdsp.com/index.php/LED_usage_on_DVEVM

otherwise read Documentation/gpio.txt in the kernel sources.

From ottavio.campana at dei.unipd.it  Thu Feb 25 07:58:22 2010
From: ottavio.campana at dei.unipd.it (Ottavio Campana)
Date: Thu, 25 Feb 2010 14:58:22 +0100
Subject: SPI with DM6446
In-Reply-To: <5B30463C3CBD6E42AF0DBB4E95DB38575F0DF8@SCS-21.ultra-scs.com>
References: <5B30463C3CBD6E42AF0DBB4E95DB38575F0DF8@SCS-21.ultra-scs.com>
Message-ID: <4B8681FE.3080401@dei.unipd.it>

Il 25/02/10 10.22, Alex Tarter ha scritto:
> I have trying to get my dm6446 running SDK2.0 to output on the SPI bus.
> I was grateful to Josh Hintze who posted a driver on this forum a few
> years ago (thank god for archives!), however I can?t seem to get it to work.
>
> When I send a write command to the driver it sends the SPI_CLK, SPI_D0
> and SPI_EN0 pins high but doesn?t change their voltage. How do I get the
> clock to start cycling and data to come out?

check the value of PINMUX1 (or PINMUX0, I don't perfectly remember) to 
see if the SPI controller is connected to the output pins. There's a bit 
that has to be set to 1.

Ottavio

From rafael7n at gmail.com  Thu Feb 25 11:15:47 2010
From: rafael7n at gmail.com (Rafael Setti Nogueira)
Date: Thu, 25 Feb 2010 14:15:47 -0300
Subject: DM6446 HELP:GPIO
In-Reply-To: <4B86812F.4070106@dei.unipd.it>
References: <792255.31022.qm@web24104.mail.ird.yahoo.com>
	<4B86812F.4070106@dei.unipd.it>
Message-ID: <1c02c8191002250915h6309ea25v2355f5a5aaa932b4@mail.gmail.com>

On DM6446 DVEVM those 8 eight leds aren't on GPIOs, you must set them
through i2c

2010/2/25 Ottavio Campana <ottavio.campana at dei.unipd.it>

> Il 25/02/10 11.23, rohan tabish ha scritto:
>
>  Hello everyine i want to know how to acess lets say an LED which is
>> connected to GPIO.
>>
>> any help regarding it will be useful.I have seen the gpio.h file there
>> are MACROS defined do i just need to use those MACROS
>>
>
> if on the dvevm
>
> http://tiexpressdsp.com/index.php/LED_usage_on_DVEVM
>
> otherwise read Documentation/gpio.txt in the kernel sources.
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100225/0e0a8c7f/attachment.html>

From cring at ti.com  Thu Feb 25 13:44:12 2010
From: cring at ti.com (Ring, Chris)
Date: Thu, 25 Feb 2010 13:44:12 -0600
Subject: Compiling with link arbiter enabled on dvsdk2.0
In-Reply-To: <EA7C0E7A4EF62348884B24E35F046DC001AF114C6F@MTW02MSG01.mindtree.com>
References: <EA7C0E7A4EF62348884B24E35F046DC001AF114C6F@MTW02MSG01.mindtree.com>
Message-ID: <92CDD168D1E81F4F9D3839DC45903FC675C46608@dlee03.ent.ti.com>

There's an example in $(CE_INSTALL_DIR)/examples/ti/sdo/ce/examples/apps/speech_copy_LAD that demonstrates the LAD-based config - does that example build for you?  Maybe compare differences between that example and yours?

Else, perhaps post your app .cfg script and full build output?  Setting .useLinkArbiter to 'true' is right... but maybe seeing the .cfg script would catch something overriding it - or let us try to reproduce it.

Chris

________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Sriraja Yagneswaran
Sent: Thursday, February 25, 2010 3:43 AM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: Compiling with link arbiter enabled on dvsdk2.0

Hello All,

I have a codec engine based application that has been built with tools from dvsdk 1.40 (with CE 2.10.02, dsplink 1.50).

I'm trying to migrate to dvsdk2.0 and the application does not compile citing undefined references to LAD functions. I have enabled the use of linkarbiter in the app's CE config script as follows for using multiple instances of the application to access the DSP engine.
osalGlobal.useLinkArbiter = true;
The app compiles if comment out the line enabling the use of linkArbiter, though I'm yet to check if the application runs.

Are there any path settings or configuration changes that I'm missing out? Does any library have to be recompiled?


Following is an extract of the errors that I observe:
/home/test/dvsdk_2_00_00_22/codec_engine_2_23_01/packages/ti/sdo/ce/ipc/dsplink/lib/release/ipc_dsplink_6467.av5T(Processor_dsplink.ov5T): In function `procDelete':
Processor_dsplink.c:(.text+0x524): undefined reference to `LAD_releaseDsp'
Processor_dsplink.c:(.text+0x558): undefined reference to `LAD_disconnect'
/home/test/dvsdk_2_00_00_22/codec_engine_2_23_01/packages/ti/sdo/ce/ipc/dsplink/lib/release/ipc_dsplink_6467.av5T(Processor_dsplink.ov5T): In function `daemon':
Processor_dsplink.c:(.text+0xbd4): undefined reference to `LAD_connect'
Processor_dsplink.c:(.text+0xc18): undefined reference to `LAD_startupDsp'



Thanks and Regards
Sriraja


  ________________________________
http://www.mindtree.com/email/disclaimer.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100225/ca044ea1/attachment.html>

From juha.kuikka at gmail.com  Thu Feb 25 15:07:40 2010
From: juha.kuikka at gmail.com (Juha Kuikka)
Date: Thu, 25 Feb 2010 13:07:40 -0800
Subject: Problem with the Arago GIT clone
Message-ID: <a46a26fd1002251307x4b99d0e2sf15d9da40eafe497@mail.gmail.com>

Hi,

I am trying to pull the Arago git tree to get the DaVinci PSP 03.20
version 03.20.00.08 kernel[1] and I run into a problem:

$ git clone http://arago-project.org/git/people/sekhar/linux-omapl1.git
......
.....
walk 0b5e2588d8238b03df66c4e74769fd03ad84f694
walk eb1c838fca2248ae62e5472b496ab52d3d774cc5
walk 53ff7095cce683813be075379160b8e4e6ea8b85
got 907c13113c68720125710c65584c73420eca2c3f
got 399ae858071d562707db10d22de04023f550bdc7
walk 399ae858071d562707db10d22de04023f550bdc7
got 064fdd73f8f1bf1eed129581cfce7cc076b24ff8
got 5f3a80c73f400978cbe4f7285796e69c69eb61c3
Getting pack a92ff0529e2ddbfecfb09e913d8662c30d94a5f0
?which contains 0716feb5da6460793f20c74e43935284543afae0
error: file /home/juha/git-arago/linux-omapl1/.git/objects/pack/pack-a92ff0529e2ddbfecfb09e913d8662c30d94a5f0.pack
is not a GIT packfile
fatal: packfile
/home/juha/git-arago/linux-omapl1/.git/objects/pack/pack-a92ff0529e2ddbfecfb09e913d8662c30d94a5f0.pack
cannot be accessed

The hard drive has abundant space left (19G).  Unfortunately GIT
deletes the failed clone directory so I cannot examine it manually.

Does anyone else have similar problems?

 + Juha

[1] http://wiki.davincidsp.com/index.php/DaVinci_PSP_03.20.00.08_Release_Notes

From khilman at deeprootsystems.com  Thu Feb 25 18:29:51 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 25 Feb 2010 16:29:51 -0800
Subject: [PATCH/RFC] davinci: DM365: fix duplicate default IRQ priorities
Message-ID: <1267144191-12809-1-git-send-email-khilman@deeprootsystems.com>

IRQ 29 has two possible interrupts DDRINT and RTC, but having both in
the default priority table is confusing (and triggers a warning from
sparse.)

This patch removes the lower priority DDRINT from the default priority
table leaving the RTC setting as the default.

Signed-off-by: Kevin Hilman <khilman at deeprootsystems.com>
---
 arch/arm/mach-davinci/dm365.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 27772e1..0d6ee58 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -758,7 +758,6 @@ static u8 dm365_default_priorities[DAVINCI_N_AINTC_IRQ] = {
 	[IRQ_MMCINT]			= 7,
 	[IRQ_DM365_MMCINT1]		= 7,
 	[IRQ_DM365_PWMINT3]		= 7,
-	[IRQ_DDRINT]			= 4,
 	[IRQ_AEMIFINT]			= 2,
 	[IRQ_DM365_SDIOINT1]		= 2,
 	[IRQ_TINT0_TINT12]		= 7,
-- 
1.6.6


From iso at cypress.com  Fri Feb 26 01:05:47 2010
From: iso at cypress.com (Arun Siluvery)
Date: Fri, 26 Feb 2010 12:35:47 +0530
Subject: dm365EVM: kernel build issue
Message-ID: <440F8F6A5F6F43C9B7ED8D779C98225D@india.cypress.com>

Hello All,

This question is regarding dm365EVM.

Initially I customized the kernel
mvl_5_0_0_demo_lsp_setuplinux_02_10_00_08.bin that was given with the kit
and could compile the kernel successfully.

Recently I downloaded the updated lsp from TI site
mvl_5_0_0_demo_lsp_setuplinux_02_10_00_14.bin and ran into the following
issue when compiling the kernel.

--------------------------------------
iso at iso:~/workdir/lsp/ti-davinci/linux-2.6.18_pro500$ make ARCH=arm
CROSS_COMPILE=arm_v5t_le- uImage
  CHK     include/linux/version.h
make[1]: `include/asm-arm/mach-types.h' is up to date.
  CHK     include/linux/utsrelease.h
  CHK     include/linux/compile.h
  GEN     .version
  CHK     include/linux/compile.h
  LD      .tmp_vmlinux1
`bt_sysfs_cleanup' referenced in section `.init.text' of net/built-in.o:
defined in discarded section `.exit.text' of net/built-in.o
make: *** [.tmp_vmlinux1] Error 1
--------------------------------------

Could someone please suggest me how to resolve this issue?
Thanks in advance for your help.

--
Best Regards
Arun




From nsekhar at ti.com  Fri Feb 26 02:14:20 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Fri, 26 Feb 2010 13:44:20 +0530
Subject: Problem with the Arago GIT clone
In-Reply-To: <a46a26fd1002251307x4b99d0e2sf15d9da40eafe497@mail.gmail.com>
References: <a46a26fd1002251307x4b99d0e2sf15d9da40eafe497@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E5E60959@dbde02.ent.ti.com>

On Fri, Feb 26, 2010 at 02:37:40, Juha Kuikka wrote:
> Hi,
>
> I am trying to pull the Arago git tree to get the DaVinci PSP 03.20
> version 03.20.00.08 kernel[1] and I run into a problem:
>
> $ git clone http://arago-project.org/git/people/sekhar/linux-omapl1.git

[...]

> Getting pack a92ff0529e2ddbfecfb09e913d8662c30d94a5f0
>  which contains 0716feb5da6460793f20c74e43935284543afae0
> error: file /home/juha/git-arago/linux-omapl1/.git/objects/pack/pack-a92ff0529e2ddbfecfb09e913d8662c30d94a5f0.pack
> is not a GIT packfile
> fatal: packfile
> /home/juha/git-arago/linux-omapl1/.git/objects/pack/pack-a92ff0529e2ddbfecfb09e913d8662c30d94a5f0.pack
> cannot be accessed
>
> The hard drive has abundant space left (19G).  Unfortunately GIT
> deletes the failed clone directory so I cannot examine it manually.
>
> Does anyone else have similar problems?

I just tried a http clone of the same tree and
was successful. Also verified that the pack in
question was received successfully. Can you retry?

Thanks,
Sekhar

From nsekhar at ti.com  Fri Feb 26 05:50:29 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Fri, 26 Feb 2010 17:20:29 +0530
Subject: DM6446:VLYNQ HELP
In-Reply-To: <806456.43382.qm@web24101.mail.ird.yahoo.com>
References: <806456.43382.qm@web24101.mail.ird.yahoo.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E5E60B7E@dbde02.ent.ti.com>

On Tue, Jan 19, 2010 at 16:41:19, rohan tabish wrote:
> Hello everyone i am using DM6446 and want to enable the VLYNQ interface
> Have read the
>
> sprue36.pdf VLYNQ port interface but i am unable to get the clear
> information.Also have
>
> downloaded  the CCS version of the VLYNQ code.I am able to see the clock
> but i am not able
>
> to get back what is transmitted.Anyone has enabled the VLYNQ interface
> on DM6446.

VLYNQ was tested on DM6446 EVM in one of the earlier 2.6.10 based MontaVista
kernels, but I am not aware of anyone getting this to work with recent kernels.

In the recent kernels, there is a VLYNQ driver present in drivers/vlynq/*
which caters to the same IP from TI, but has only been tested on TI's AR7
chip. The best way forward would be to start with trying to use this driver.
You can look at AR7 code for an example of how this has been used.

Thanks,
Sekhar

From iso at cypress.com  Fri Feb 26 06:46:30 2010
From: iso at cypress.com (Arun Siluvery)
Date: Fri, 26 Feb 2010 18:16:30 +0530
Subject: dm365EVM: kernel build issue
In-Reply-To: <440F8F6A5F6F43C9B7ED8D779C98225D@india.cypress.com>
References: <440F8F6A5F6F43C9B7ED8D779C98225D@india.cypress.com>
Message-ID: <830DA5AA11A0419A8618E8F7F0AB023A@india.cypress.com>

Hello All,

I am replying to my own post.

The function 'bt_sysfs_cleanup()' is related to bluetooth; I disabled
Bluetooth support in the kernel as I do not need it and the compilation is
successful. There is no issue with the new kernel now.

--
Best Regards
Arun

-----Original Message-----
From: davinci-linux-open-source-bounces at linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of
Arun Siluvery
Sent: Friday, February 26, 2010 12:36 PM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: dm365EVM: kernel build issue

Hello All,

This question is regarding dm365EVM.

Initially I customized the kernel
mvl_5_0_0_demo_lsp_setuplinux_02_10_00_08.bin that was given with the kit
and could compile the kernel successfully.

Recently I downloaded the updated lsp from TI site
mvl_5_0_0_demo_lsp_setuplinux_02_10_00_14.bin and ran into the following
issue when compiling the kernel.

--------------------------------------
iso at iso:~/workdir/lsp/ti-davinci/linux-2.6.18_pro500$ make ARCH=arm
CROSS_COMPILE=arm_v5t_le- uImage
  CHK     include/linux/version.h
make[1]: `include/asm-arm/mach-types.h' is up to date.
  CHK     include/linux/utsrelease.h
  CHK     include/linux/compile.h
  GEN     .version
  CHK     include/linux/compile.h
  LD      .tmp_vmlinux1
`bt_sysfs_cleanup' referenced in section `.init.text' of net/built-in.o:
defined in discarded section `.exit.text' of net/built-in.o
make: *** [.tmp_vmlinux1] Error 1
--------------------------------------

Could someone please suggest me how to resolve this issue?
Thanks in advance for your help.

--
Best Regards
Arun



_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


From Sriraja_Yagneswaran at mindtree.com  Fri Feb 26 07:33:14 2010
From: Sriraja_Yagneswaran at mindtree.com (Sriraja Yagneswaran)
Date: Fri, 26 Feb 2010 19:03:14 +0530
Subject: Compiling with link arbiter enabled on dvsdk2.0
In-Reply-To: <92CDD168D1E81F4F9D3839DC45903FC675C46608@dlee03.ent.ti.com>
References: <EA7C0E7A4EF62348884B24E35F046DC001AF114C6F@MTW02MSG01.mindtree.com>
	<92CDD168D1E81F4F9D3839DC45903FC675C46608@dlee03.ent.ti.com>
Message-ID: <EA7C0E7A4EF62348884B24E35F046DC001AF26B52F@MTW02MSG01.mindtree.com>

Thanks Chris,

I'm able to compile the applications now. I had to explicitly add the ladclient package to the app's .cfg script.
var ladPkg = xdc.loadPackage('ti.dsplink.utils.ladclient');

I compiled the  speech_copy_LAD and compared the loaded packages. While the script itself did not differ the folder did have a package.bld file that is apparently loading the LAD package.

I still have some ARM-side library dependencies to resolve before I can run the application. Hopefully I should be able to run it on the platform.

Regards
Sriraja

________________________________
From: Ring, Chris [mailto:cring at ti.com]
Sent: Friday, February 26, 2010 1:14 AM
To: Sriraja Yagneswaran; davinci-linux-open-source at linux.davincidsp.com
Subject: RE: Compiling with link arbiter enabled on dvsdk2.0

There's an example in $(CE_INSTALL_DIR)/examples/ti/sdo/ce/examples/apps/speech_copy_LAD that demonstrates the LAD-based config - does that example build for you?  Maybe compare differences between that example and yours?

Else, perhaps post your app .cfg script and full build output?  Setting .useLinkArbiter to 'true' is right... but maybe seeing the .cfg script would catch something overriding it - or let us try to reproduce it.

Chris

________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Sriraja Yagneswaran
Sent: Thursday, February 25, 2010 3:43 AM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: Compiling with link arbiter enabled on dvsdk2.0
Hello All,

I have a codec engine based application that has been built with tools from dvsdk 1.40 (with CE 2.10.02, dsplink 1.50).

I'm trying to migrate to dvsdk2.0 and the application does not compile citing undefined references to LAD functions. I have enabled the use of linkarbiter in the app's CE config script as follows for using multiple instances of the application to access the DSP engine.
osalGlobal.useLinkArbiter = true;
The app compiles if comment out the line enabling the use of linkArbiter, though I'm yet to check if the application runs.

Are there any path settings or configuration changes that I'm missing out? Does any library have to be recompiled?


Following is an extract of the errors that I observe:
/home/test/dvsdk_2_00_00_22/codec_engine_2_23_01/packages/ti/sdo/ce/ipc/dsplink/lib/release/ipc_dsplink_6467.av5T(Processor_dsplink.ov5T): In function `procDelete':
Processor_dsplink.c:(.text+0x524): undefined reference to `LAD_releaseDsp'
Processor_dsplink.c:(.text+0x558): undefined reference to `LAD_disconnect'
/home/test/dvsdk_2_00_00_22/codec_engine_2_23_01/packages/ti/sdo/ce/ipc/dsplink/lib/release/ipc_dsplink_6467.av5T(Processor_dsplink.ov5T): In function `daemon':
Processor_dsplink.c:(.text+0xbd4): undefined reference to `LAD_connect'
Processor_dsplink.c:(.text+0xc18): undefined reference to `LAD_startupDsp'



Thanks and Regards
Sriraja


  ________________________________
http://www.mindtree.com/email/disclaimer.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100226/903851b8/attachment.html>

From dato at digimeq.ru  Sat Feb 27 06:35:38 2010
From: dato at digimeq.ru (David Goshadze)
Date: Sat, 27 Feb 2010 15:35:38 +0300
Subject: 2.6.32 musb_hdrc fails to load (DM6446)
In-Reply-To: <FCCFB4CDC6E5564B9182F639FC356087030408C875@dbde02.ent.ti.com>
References: <1284591885.20100224212923@digimeq.ru>
	<FCCFB4CDC6E5564B9182F639FC356087030408C875@dbde02.ent.ti.com>
Message-ID: <1341891187.20100227153538@digimeq.ru>

Hi all again.

Digging into sources I discovered that setup_usb (from
arch/arm/mach-davinci/usb.c) is never called, thus platform device
register for usb_dev is also never called.

Wondering for a reason.
Please help.

David.

SS> David,
SS>         Could you try the aarago git davinci tree?

SS>         From the below log it seems there could be a
SS> configuration issue between the base port and the driver init.

SS> Regards
SS> swami

>> -----Original Message-----
>> From: davinci-linux-open-source-
>> bounces+swami.iyer=ti.com at linux.davincidsp.com [mailto:davinci-linux-open-
>> source-bounces+swami.iyer=ti.com at linux.davincidsp.com] On Behalf Of David
>> Goshadze
>> Sent: Wednesday, February 24, 2010 11:59 PM
>> To: davinci-linux-open-source at linux.davincidsp.com
>> Subject: 2.6.32 musb_hdrc fails to load (DM6446)
>> 
>> Hi all!
>> 
>> Please help with the following problem:
>> 
>> I successfully loaded an built 2.6.32 for our DM6446 based board.
>> 
>> Everything's just fine except I cannot load musb_hdrc driver.
>>  I got:
>>   modprobe musb_hdrc : version 6.0, cppi-dma, peripherial, debug=0
>>   FATAL: Error inserting musb_hdrc
>> (/lib/modules/2/6/32/kernel/drivers/usb/musb/musb_hdrc.ko): No such device
>>   nop_usb_xceiv loaded successfully.
>> 
>>   use_dma=n doesn't help.
>> 
>> Spending 2 days trying various kernel configurations and googling didn't
>> help.
>> 
>> With 2.6.10 (mvl) everything was fine.
>> 
>> I'm nearly gone mad with this.
>> 
>> David.
>> 
>> 
>> 
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source at linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source



___________________________
David Goshadze,
Chief project developer,
PLC Digimeq,
5, Vozdvizhenka str.
Moscow, Russian Federation

Ph +7 495 9505231
Mob +7 916 604 56 93
Fax +7 495 9505231
dato at digimeq.ru
www.digimeq.com


From swami.iyer at ti.com  Sat Feb 27 11:07:51 2010
From: swami.iyer at ti.com (Subbrathnam, Swaminathan)
Date: Sat, 27 Feb 2010 22:37:51 +0530
Subject: 2.6.32 musb_hdrc fails to load (DM6446)
In-Reply-To: <1341891187.20100227153538@digimeq.ru>
References: <1284591885.20100224212923@digimeq.ru>
	<FCCFB4CDC6E5564B9182F639FC356087030408C875@dbde02.ent.ti.com>,
	<1341891187.20100227153538@digimeq.ru>
Message-ID: <FCCFB4CDC6E5564B9182F639FC3560870303E7629A@dbde02.ent.ti.com>

David,

Did you compile in the I2c Expander support in the kernel.  I think you are missing this part of the config.  Can you confirm.

regards
swami

________________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of David Goshadze [dato at digimeq.ru]
Sent: Saturday, February 27, 2010 6:05 PM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: Re: 2.6.32 musb_hdrc fails to load (DM6446)

Hi all again.

Digging into sources I discovered that setup_usb (from
arch/arm/mach-davinci/usb.c) is never called, thus platform device
register for usb_dev is also never called.

Wondering for a reason.
Please help.

David.

SS> David,
SS>         Could you try the aarago git davinci tree?

SS>         From the below log it seems there could be a
SS> configuration issue between the base port and the driver init.

SS> Regards
SS> swami

>> -----Original Message-----
>> From: davinci-linux-open-source-
>> bounces+swami.iyer=ti.com at linux.davincidsp.com [mailto:davinci-linux-open-
>> source-bounces+swami.iyer=ti.com at linux.davincidsp.com] On Behalf Of David
>> Goshadze
>> Sent: Wednesday, February 24, 2010 11:59 PM
>> To: davinci-linux-open-source at linux.davincidsp.com
>> Subject: 2.6.32 musb_hdrc fails to load (DM6446)
>>
>> Hi all!
>>
>> Please help with the following problem:
>>
>> I successfully loaded an built 2.6.32 for our DM6446 based board.
>>
>> Everything's just fine except I cannot load musb_hdrc driver.
>>  I got:
>>   modprobe musb_hdrc : version 6.0, cppi-dma, peripherial, debug=0
>>   FATAL: Error inserting musb_hdrc
>> (/lib/modules/2/6/32/kernel/drivers/usb/musb/musb_hdrc.ko): No such device
>>   nop_usb_xceiv loaded successfully.
>>
>>   use_dma=n doesn't help.
>>
>> Spending 2 days trying various kernel configurations and googling didn't
>> help.
>>
>> With 2.6.10 (mvl) everything was fine.
>>
>> I'm nearly gone mad with this.
>>
>> David.
>>
>>
>>
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source at linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source



___________________________
David Goshadze,
Chief project developer,
PLC Digimeq,
5, Vozdvizhenka str.
Moscow, Russian Federation

Ph +7 495 9505231
Mob +7 916 604 56 93
Fax +7 495 9505231
dato at digimeq.ru
www.digimeq.com

_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From wolneykien at altlinux.org  Sat Feb 27 15:02:38 2010
From: wolneykien at altlinux.org (Paul Wolneykien)
Date: Sun, 28 Feb 2010 00:02:38 +0300
Subject: musb_submit_urb() blocking problem
Message-ID: <4B89886E.4000604@altlinux.org>


   Hi,

   I've got a message mentioning a deadlock resulting from the 
musb_submit_urb() call on the TMS320DM355 chip, ti-davinci 2.6.10 
kernel. Mentioned that the "deadlock" (or blocking) emerges with _some_ 
USB 1.1 gadgets only, when that gadgets are connected to the DM355 host 
and a bulk transfer to the gadget is submitted. Contrary to the expected 
asynchronous submit_urb() call behavior, the call is blocked infinitely.
   Currently I do not have an access to the TMS320DM355 device but I'm 
trying to investigate the potential roots of the problem analyzing the 
source code, chip documentation and mail lists. And I'd be very glad for 
any suggestions pointing the potentially unsafe points that exist inside 
the submit_urb call that may result in such a blocking.

   Thanks in advance.

-- 
Paul Wolneykien,
   ALT Linux Ltd.

From proclus at gnu-darwin.org  Sun Feb 28 22:15:53 2010
From: proclus at gnu-darwin.org (proclus at gnu-darwin.org)
Date: Sun, 28 Feb 2010 23:15:53 -0500 (EST)
Subject: radical mormons
Message-ID: <20100301041553.0A164D5C0C2@gnu-darwin.org>


Those of you who have been following mormonism on the web
for many years will probably recognize The Radical Mormon
publication.  This was likely the first attempt to make
a web portal for latter-day saint people, and this pioneering
effort helped to inspire many other sites to do likewise.  
Radical set itself apart as a place where devout and sincere
LDS and mormons could intelligently discuss controversial
doctrines in a positive light, at a time when the anti-mormon
forces were very powerful on the web.  The publication has been
active off and on ever since that time.  If you are not
familiar with it, you might want to have a look at it.  This
site broke new ground at the time that it was started in 1999.

http://proclus.tripod.com/radical/

For those who are already familiar with The Radical Mormon,
you might be interested to know that the editors and 
contributors have recently started work on some historical
information regarding the publication, which provides many
links to related websites.  You can have an advance look, 
and see as it evolves.  

http://proclus.tripod.com/radical/editor.html

Some of you may even like to contribute something; help us
fix broken links, contribute a news item, editorial, or
personal story.  If you were a part of the activity that
spawned The Radical Mormon, you might like to submit your
link for inclusion on our contributors page.

Regards,
proclus
http://www.gnu-darwin.org/


From yuvraj.pasi at nextbitcpu.com  Sun Feb 28 23:47:41 2010
From: yuvraj.pasi at nextbitcpu.com (Yuvraj Pasi)
Date: Mon, 1 Mar 2010 11:17:41 +0530
Subject: USB camera
Message-ID: <d448eead1002282147h4d8e9be8yf35c6a71e4f858ab@mail.gmail.com>

Hi,
I am using a usb camera with gspca driver for dm6446 based system. i have
used capture application given in v4l2 documentation
to capture images. my problem is that it is giving timeout error in select
operation. the device detection doesn't give problem & it gets registered as
/dev/video1.
Do I have to do something else to get usb webcam running because the same
application is running properly with composite input signal device
registered as
/dev/video0.

here is the dump:
open_device 6
Input Name: ov519
Input Type: 2
VIDIOC_ENUMSTD: Invalid argument
 Menu items:
Control Brightness
Control Contrast
Control Color
Control Mirror
Control Vflip
/dev/video1 has no video overlay feature
/dev/video1 has streaming feature
Width:640
Height:480
PixelFormat:JPEG
PixField:1
bytes/line=640
BufLen:118784 BufType:1
BufLen:118784 BufType:1
BufLen:118784 BufType:1
capture_init_device
The framebuffer device was opened successfully.7
640x480, 16bpp

 screensize=614400
fb_init_device
gspca: usb_submit_urb alt 4 err -28
gspca: usb_submit_urb alt 3 err -28
start_capturing
select timeout: Invalid argument


-- 
Thanks & regards
yuvraj pasi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100301/d46cc83a/attachment.html>