Unable to change cache size in codec engine.
Hello ,
I am trying to build an application to encode video in mpeg4 format
and also integrate the scale example from the codec engine in the
encode combo server. During the integration fro performance reasons I
want to increase the L2 cache size from 64k to 128k. My processor is
tms320dm6446.
On building the codec_server I get the error:
Error: Can't set cache to size: 128k
Following is the encode.tcf file:
/*
* Setup platform-specific memory map, CLK rate, etc.
*/
var mem_ext = [
{
comment:"DDRALGHEAP: memory for dynamic algmem allocation",
name: "DDRALGHEAP",
base: 0x8B80,
len:0x0420,// 66MB
space: "code/data"
},
{
comment:"L1DSRAM: memory for dynamic algmem allocation",
name: "L1DSRAM",
base: 0x11F04000, //
len:0x1, // 64k
space: "data"
},
{
comment:"CACHE_L2",
name: "CACHE_L2",
base: 0x1180, //
len:0x20, // 128k
space: "data"
},
{
comment:"H264ENCSEC1",
name: "H264ENCSEC1",
base: 0x8FA0,
len:0x4140,
space: "code/data"
},
{
comment:"H264ENCSEC2",
name: "H264ENCSEC2",
base: 0x8FA04140,
len:0x5080,
space: "code/data"
},
{
comment:"H264ENCSEC3",
name: "H264ENCSEC3",
base: 0x8FA09220,
len:0x6000,
space: "code/data"
},
{
comment:"H264ENCSEC4",
name: "H264ENCSEC4",
base: 0x8FA1,
len:0x5000,
space: "code/data"
},
{
comment:"H264ENCSEC5",
name: "H264ENCSEC5",
base: 0x8FA15000,
len:0x3000,
space: "code/data"
},
{
comment:"H264ENCSEC6",
name: "H264ENCSEC6",
base: 0x8FA18000,
len:0x4040,
space: "code/data"
},
{
comment:"H264ENCSEC7",
name: "H264ENCSEC7",
base: 0x8FA28000,
len:0x5400,
space: "code/data"
},
{
comment:"H264ENCSEC8",
name: "H264ENCSEC8",
base: 0x8FA2D400,
len:0x2c00,
space: "code/data"
},
{
comment:"MPEG4ENCSEC1",
name: "MPEG4ENCSEC1",
base: 0x8FA4,
len:0x0001,
space: "code/data"
},
{
comment:"MPEG4ENCSEC2",
name: "MPEG4ENCSEC2",
base: 0x8FA5,
len:0x8000,
space: "code/data"
},
{
comment:"MPEG4ENCSEC3",
name: "MPEG4ENCSEC3",
base: 0x8FA58000,
len:0x8000,
space: "code/data"
},
{
comment:"MPEG4ENCSEC4",
name: "MPEG4ENCSEC4",
base: 0x8FA6,
len:0x8000,
space: "code/data"
},
{
comment:"MPEG4ENCSEC5",
name: "MPEG4ENCSEC5",
base: 0x8FA68000,
len:0x8000,
space: "code/data"
},
{
comment:"MPEG4ENCSEC6",
name: "MPEG4ENCSEC6",
base: 0x8FA7,
len:0x8000,
space: "code/data"
},
{
comment:"MPEG4ENCSEC7",
name: "MPEG4ENCSEC7",
base: 0x8FA78000,
len:0x0001,
space: "code/data"
},
{
comment:"DDR: memory for code and data",
name: "DDR",
base: 0x8FB0,
len:0x0030,
space: "code/data"
},
{
comment:"DSPLINK: memory for DSPLINK code and data",
name: "DSPLINKMEM",
base: 0x8FE0, // 254MB
len:0x0010, // 1MB
space: "code/data"
},
{
comment:"RESET_VECTOR: memory for the reset vector table",
name: "RESET_VECTOR",
base: 0x8FF0,
len:0x0080,
space: "code/data"
},
];
/* Specify the L2 memory setting */
var device_regs = {
l2Mode: "128k"
};
var params = {
clockRate: 594,
catalogName: "ti.catalog.c6000",
deviceName: "DM6446",
regs: device_regs,
mem: mem_ext
};
/*
* Customize generic platform with parameters specified above.
*/
utils.loadPlatform("ti.platforms.generic", params);
/* ===
* Enable heaps and tasks
* ===
*/
bios.enableMemoryHeaps(prog);
bios.enableTskManager(prog);
/* ===
* Create heaps in memory segments that are to have heap
* ===
*/
bios.DDR.createHeap = true;
bios.DDR.heapSize = 0x1; // 256K
bios.DDRALGHEAP.createHeap = true;
bios.DDRALGHEAP.heapSize = bios.DDRALGHEAP.len;
/*
* Enable heaps in the L1DSRAM (internal L1 cache ram, fixed size)
* and define the label for heap usage.
*/
bios.L1DSRAM.createHeap = true;
bios.L1DS
Re: Unable to change cache size in codec engine.
Hello,
I remember 64x+ L2 cache size is 64K (maximum).
Regards
Jayakrishnan
--- Original Message ---
Sender : bhushan
Date : May 21, 2009 16:19 (GMT+09:00)
Title : Unable to change cache size in codec engine.
Hello ,
I am trying to build an application to encode video in mpeg4 format
and also integrate the scale example from the codec engine in the
encode combo server. During the integration fro performance reasons I
want to increase the L2 cache size from 64k to 128k. My processor is
tms320dm6446.
On building the codec_server I get the error:
Error: Can't set cache to size: 128k
Following is the encode.tcf file:
/*
* Setup platform-specific memory map, CLK rate, etc.
*/
var mem_ext = [
{
comment:"DDRALGHEAP: memory for dynamic algmem allocation",
name: "DDRALGHEAP",
base: 0x8B80,
len:0x0420,// 66MB
space: "code/data"
},
{
comment:"L1DSRAM: memory for dynamic algmem allocation",
name: "L1DSRAM",
base: 0x11F04000, //
len:0x1, // 64k
space: "data"
},
{
comment:"CACHE_L2",
name: "CACHE_L2",
base: 0x1180, //
len:0x20, // 128k
space: "data"
},
{
comment:"H264ENCSEC1",
name: "H264ENCSEC1",
base: 0x8FA0,
len:0x4140,
space: "code/data"
},
{
comment:"H264ENCSEC2",
name: "H264ENCSEC2",
base: 0x8FA04140,
len:0x5080,
space: "code/data"
},
{
comment:"H264ENCSEC3",
name: "H264ENCSEC3",
base: 0x8FA09220,
len:0x6000,
space: "code/data"
},
{
comment:"H264ENCSEC4",
name: "H264ENCSEC4",
base: 0x8FA1,
len:0x5000,
space: "code/data"
},
{
comment:"H264ENCSEC5",
name: "H264ENCSEC5",
base: 0x8FA15000,
len:0x3000,
space: "code/data"
},
{
comment:"H264ENCSEC6",
name: "H264ENCSEC6",
base: 0x8FA18000,
len:0x4040,
space: "code/data"
},
{
comment:"H264ENCSEC7",
name: "H264ENCSEC7",
base: 0x8FA28000,
len:0x5400,
space: "code/data"
},
{
comment:"H264ENCSEC8",
name: "H264ENCSEC8",
base: 0x8FA2D400,
len:0x2c00,
space: "code/data"
},
{
comment:"MPEG4ENCSEC1",
name: "MPEG4ENCSEC1",
base: 0x8FA4,
len:0x0001,
space: "code/data"
},
{
comment:"MPEG4ENCSEC2",
name: "MPEG4ENCSEC2",
base: 0x8FA5,
len:0x8000,
space: "code/data"
},
{
comment:"MPEG4ENCSEC3",
name: "MPEG4ENCSEC3",
base: 0x8FA58000,
len:0x8000,
space: "code/data"
},
{
comment:"MPEG4ENCSEC4",
name: "MPEG4ENCSEC4",
base: 0x8FA6,
len:0x8000,
space: "code/data"
},
{
comment:"MPEG4ENCSEC5",
name: "MPEG4ENCSEC5",
base: 0x8FA68000,
len:0x8000,
space: "code/data"
},
{
comment:"MPEG4ENCSEC6",
name: "MPEG4ENCSEC6",
base: 0x8FA7,
len:0x8000,
space: "code/data"
},
{
comment:"MPEG4ENCSEC7",
name: "MPEG4ENCSEC7",
base: 0x8FA78000,
len:0x0001,
space: "code/data"
},
{
comment:"DDR: memory for code and data",
name: "DDR",
base: 0x8FB0,
len:0x0030,
space: "code/data"
},
{
comment:"DSPLINK: memory for DSPLINK code and data",
name: "DSPLINKMEM",
base: 0x8FE0, // 254MB
len:0x0010, // 1MB
space: "code/data"
},
{
comment:"RESET_VECTOR: memory for the reset vector table",
name: "RESET_VECTOR",
base: 0x8FF0,
len:0x0080,
space: "code/data"
},
];
/* Specify the L2 memory setting */
var device_regs = {
l2Mode: "128k"
};
var params = {
clockRate: 594,
catalogName: "ti.catalog.c6000",
deviceName: "DM6446",
regs: device_regs,
mem: mem_ext
};
/*
* Customize generic platform with parameters specified above.
*/
utils.loadPlatform("ti.platforms.generic", params);
/* ===
* Enable heaps and tasks
* ===
*/
bios.enableMemoryHeaps(prog);
bios.enableTskManager(prog);
/* ===
* Create heaps in memory segments that are to have heap
* ===
*/
bios.DDR.createHeap = true;
bios.DDR.heapSize = 0x1; // 256K
bios.DDRALGHEAP.crea
Re: Unable to change cache size in codec engine.
Hello,
As per my understanding DM6446 L2 memory includes 64 KB of RAM. The Unified
memory controller allows you to configure part or all of the L2 RAM as
normal RAM or as cache. You can configure cache sizes of 0 KB, 4 KB, 8 KB,
16 KB, 32 KB, or 64 KB
of the 64 KB of RAM. But you cant exceed 64KB size.
Thanks,
Sneha Sheth
On Thu, May 21, 2009 at 1:30 PM, Jaya krishnan wrote:
> Hello,
> I remember 64x+ L2 cache size is 64K (maximum).
> Regards
> Jayakrishnan
>
>
>
>
> --- Original Message ---
> Sender : bhushan
> Date : May 21, 2009 16:19 (GMT+09:00)
> Title : Unable to change cache size in codec engine.
>
> Hello ,
> I am trying to build an application to encode video in mpeg4 format
> and also integrate the scale example from the codec engine in the
> encode combo server. During the integration fro performance reasons I
> want to increase the L2 cache size from 64k to 128k. My processor is
> tms320dm6446.
> On building the codec_server I get the error:
> Error: Can't set cache to size: 128k
> Following is the encode.tcf file:
> /*
> * Setup platform-specific memory map, CLK rate, etc.
> */
> var mem_ext = [
> {
>comment:"DDRALGHEAP: memory for dynamic algmem allocation",
>name: "DDRALGHEAP",
>base: 0x8B80,
>len:0x0420,// 66MB
>space: "code/data"
> },
> {
>comment:"L1DSRAM: memory for dynamic algmem allocation",
>name: "L1DSRAM",
>base: 0x11F04000, //
>len:0x1, // 64k
>space: "data"
> },
> {
>comment:"CACHE_L2",
>name: "CACHE_L2",
>base: 0x1180, //
>len:0x20, // 128k
>space: "data"
> },
> {
>comment:"H264ENCSEC1",
>name: "H264ENCSEC1",
>base: 0x8FA0,
>len:0x4140,
>space: "code/data"
> },
> {
>comment:"H264ENCSEC2",
>name: "H264ENCSEC2",
>base: 0x8FA04140,
>len:0x5080,
>space: "code/data"
> },
> {
>comment:"H264ENCSEC3",
>name: "H264ENCSEC3",
>base: 0x8FA09220,
>len:0x6000,
>space: "code/data"
> },
> {
>comment:"H264ENCSEC4",
>name: "H264ENCSEC4",
>base: 0x8FA1,
>len:0x5000,
>space: "code/data"
> },
> {
>comment:"H264ENCSEC5",
>name: "H264ENCSEC5",
>base: 0x8FA15000,
>len:0x3000,
>space: "code/data"
> },
> {
>comment:"H264ENCSEC6",
>name: "H264ENCSEC6",
>base: 0x8FA18000,
>len:0x4040,
>space: "code/data"
> },
> {
>comment:"H264ENCSEC7",
>name: "H264ENCSEC7",
>base: 0x8FA28000,
>len:0x5400,
>space: "code/data"
> },
> {
>comment:"H264ENCSEC8",
>name: "H264ENCSEC8",
>base: 0x8FA2D400,
>len:0x2c00,
>space: "code/data"
> },
> {
>comment:"MPEG4ENCSEC1",
>name: "MPEG4ENCSEC1",
>base: 0x8FA4,
>len:0x0001,
>space: "code/data"
> },
> {
>comment:"MPEG4ENCSEC2",
>name: "MPEG4ENCSEC2",
>base: 0x8FA5,
>len:0x8000,
>space: "code/data"
> },
> {
>comment:"MPEG4ENCSEC3",
>name: "MPEG4ENCSEC3",
>base: 0x8FA58000,
>len:0x8000,
>space: "code/data"
> },
> {
>comment:"MPEG4ENCSEC4",
>name: "MPEG4ENCSEC4",
>base: 0x8FA6,
>len:0x8000,
>space: "code/data"
> },
> {
>comment:"MPEG4ENCSEC5",
>name: "MPEG4ENCSEC5",
>base: 0x8FA68000,
>len:0x8000,
>space: "code/data"
> },
> {
>comment:"MPEG4ENCSEC6",
>name: "MPEG4ENCSEC6",
>base: 0x8FA7,
>len:0x8000,
>space: "code/data"
> },
> {
>comment:"MPEG4ENCSEC7",
>name: "MPEG4ENCSEC7",
>base: 0x8FA78000,
>len:0x0001,
>space: "code/data"
> },
>
> {
>
>comment:"DDR: memory for code and data",
>name: "DDR",
>base: 0x8FB0,
>len:0x0030,
>space: "code/data"
> },
>
>
> {
>comment:"DSPLINK: memory for DSPLINK code and data",
>name: "DSPLINKMEM",
>base: 0x8FE0, // 254MB
>len:0x0010, // 1MB
>space: "code/data"
> },
> {
>comment:"RESET_VECTOR: memory for the reset vector table",
>name: "RESET_VECTOR",
>base: 0x8FF0,
>len:0x0080,
>space: "code/data"
> },
> ];
>
> /* Specify the L2 memory setting */
> var device_regs = {
>l2Mode: "128k"
> };
>
> var params = {
>clockRate: 594,
>catalogName: "ti.catalog.c6000",
>deviceName: "DM6446",
>regs: device_regs,
>mem: mem_ext
> };
>
> /*
> * Customize generic platform with pa
Re: Unable to change cache size in codec engine.
I am referring doc spru871j.pdf. In the section Level 2 memory and
cache it is mentioned that the L2 cache size can be configured for
32KB, 64KB, 128KB and 256KB. I presume the L2_CACHE is same as this.
If there is any other doc whcih specifies that the cache size
configured is limited to 64KB please refer the same to me.
regards,
Bhushan
On Thu, May 21, 2009 at 1:30 PM, Jaya krishnan
wrote:
> Hello,
> I remember 64x+ L2 cache size is 64K (maximum).
> Regards
> Jayakrishnan
>
>
>
>
> --- Original Message ---
> Sender : bhushan
> Date : May 21, 2009 16:19 (GMT+09:00)
> Title : Unable to change cache size in codec engine.
>
> Hello ,
> I am trying to build an application to encode video in mpeg4 format
> and also integrate the scale example from the codec engine in the
> encode combo server. During the integration fro performance reasons I
> want to increase the L2 cache size from 64k to 128k. My processor is
> tms320dm6446.
> On building the codec_server I get the error:
> Error: Can't set cache to size: 128k
> Following is the encode.tcf file:
> /*
> * Setup platform-specific memory map, CLK rate, etc.
> */
> var mem_ext = [
> {
> comment: "DDRALGHEAP: memory for dynamic algmem allocation",
> name: "DDRALGHEAP",
> base: 0x8B80,
> len: 0x0420,// 66MB
> space: "code/data"
> },
> {
> comment: "L1DSRAM: memory for dynamic algmem allocation",
> name: "L1DSRAM",
> base: 0x11F04000, //
> len: 0x1, // 64k
> space: "data"
> },
> {
> comment: "CACHE_L2",
> name: "CACHE_L2",
> base: 0x1180, //
> len: 0x20, // 128k
> space: "data"
> },
> {
> comment: "H264ENCSEC1",
> name: "H264ENCSEC1",
> base: 0x8FA0,
> len: 0x4140,
> space: "code/data"
> },
> {
> comment: "H264ENCSEC2",
> name: "H264ENCSEC2",
> base: 0x8FA04140,
> len: 0x5080,
> space: "code/data"
> },
> {
> comment: "H264ENCSEC3",
> name: "H264ENCSEC3",
> base: 0x8FA09220,
> len: 0x6000,
> space: "code/data"
> },
> {
> comment: "H264ENCSEC4",
> name: "H264ENCSEC4",
> base: 0x8FA1,
> len: 0x5000,
> space: "code/data"
> },
> {
> comment: "H264ENCSEC5",
> name: "H264ENCSEC5",
> base: 0x8FA15000,
> len: 0x3000,
> space: "code/data"
> },
> {
> comment: "H264ENCSEC6",
> name: "H264ENCSEC6",
> base: 0x8FA18000,
> len: 0x4040,
> space: "code/data"
> },
> {
> comment: "H264ENCSEC7",
> name: "H264ENCSEC7",
> base: 0x8FA28000,
> len: 0x5400,
> space: "code/data"
> },
> {
> comment: "H264ENCSEC8",
> name: "H264ENCSEC8",
> base: 0x8FA2D400,
> len: 0x2c00,
> space: "code/data"
> },
> {
> comment: "MPEG4ENCSEC1",
> name: "MPEG4ENCSEC1",
> base: 0x8FA4,
> len: 0x0001,
> space: "code/data"
> },
> {
> comment: "MPEG4ENCSEC2",
> name: "MPEG4ENCSEC2",
> base: 0x8FA5,
> len: 0x8000,
> space: "code/data"
> },
> {
> comment: "MPEG4ENCSEC3",
> name: "MPEG4ENCSEC3",
> base: 0x8FA58000,
> len: 0x8000,
> space: "code/data"
> },
> {
> comment: "MPEG4ENCSEC4",
> name: "MPEG4ENCSEC4",
> base: 0x8FA6,
> len: 0x8000,
> space: "code/data"
> },
> {
> comment: "MPEG4ENCSEC5",
> name: "MPEG4ENCSEC5",
> base: 0x8FA68000,
> len: 0x8000,
> space: "code/data"
> },
> {
> comment: "MPEG4ENCSEC6",
> name: "MPEG4ENCSEC6",
> base: 0x8FA7,
> len: 0x8000,
> space: "code/data"
> },
> {
> comment: "MPEG4ENCSEC7",
> name: "MPEG4ENCSEC7",
> base: 0x8FA78000,
> len: 0x0001,
> space: "code/data"
> },
>
> {
>
> comment: "DDR: memory for code and data",
> name: "DDR",
> base: 0x8FB0,
> len: 0x0030,
> space: "code/data"
> },
>
>
> {
> comment: "DSPLINK: memory for DSPLINK code and data",
> name: "DSPLINKMEM",
> base: 0x8FE0, // 254MB
> len: 0x0010, // 1MB
> space: "code/data"
> },
> {
> comment: "RESET_VECTOR: memory for the reset vector table",
> name: "RESET_VECTOR",
> base: 0x8FF0,
> len: 0x0080,
> space: "code/data"
> },
> ];
>
> /* Specify the L2 memory setting */
> var device_regs = {
> l2Mode: "128k"
> };
>
> var params = {
> clockRate: 594,
> catalogName: "ti.catalog.c6000",
> deviceName: "DM6446",
> regs: device_regs,
> mem: mem_ext
> };
>
> /*
> * Customize generic
Re: Unable to change cache size in codec engine.
Refer to tms320dm6446.pdf /p14 (datasheet of TMS320DM6446) DSP has only
64KB
The DSP Subsystem includes the following features:
· C64x+ DSP CPU
· 32KB L1 Program (L1P)/Cache (up to 32KB)
· 80KB L1 Data (L1D)/Cache (up to 32KB)
· 64KB Unified Mapped RAM/Cache (L2)
· Little endian
Best regards
Ondrej Pindroch
-Original Message-
From: bhushan
To: jaya.krish...@samsung.com
Cc: "davinci-linux-open-source@linux.davincidsp.com"
Date: Thu, 21 May 2009 14:23:18 +0530
Subject: Re: Unable to change cache size in codec engine.
I am referring doc spru871j.pdf. In the section Level 2 memory and
cache it is mentioned that the L2 cache size can be configured for
32KB, 64KB, 128KB and 256KB. I presume the L2_CACHE is same as this.
If there is any other doc whcih specifies that the cache size
configured is limited to 64KB please refer the same to me.
regards,
Bhushan
On Thu, May 21, 2009 at 1:30 PM, Jaya krishnan
wrote:
> Hello,
> I remember 64x+ L2 cache size is 64K (maximum).
> Regards
> Jayakrishnan
>
>
>
>
> --- Original Message ---
> Sender : bhushan
> Date : May 21, 2009 16:19 (GMT+09:00)
> Title : Unable to change cache size in codec engine.
>
> Hello ,
> I am trying to build an application to encode video in mpeg4 format
> and also integrate the scale example from the codec engine in the
> encode combo server. During the integration fro performance reasons I
> want to increase the L2 cache size from 64k to 128k. My processor is
> tms320dm6446.
> On building the codec_server I get the error:
> Error: Can't set cache to size: 128k
> Following is the encode.tcf file:
> /*
> * Setup platform-specific memory map, CLK rate, etc.
> */
> var mem_ext = [
> {
>comment:"DDRALGHEAP: memory for dynamic algmem allocation",
>name: "DDRALGHEAP",
>base: 0x8B80,
>len:0x0420,// 66MB
>space: "code/data"
> },
> {
>comment:"L1DSRAM: memory for dynamic algmem allocation",
>name: "L1DSRAM",
>base: 0x11F04000, //
>len:0x1, // 64k
>space: "data"
> },
> {
>comment:"CACHE_L2",
>name: "CACHE_L2",
>base: 0x1180, //
>len:0x20, // 128k
>space: "data"
> },
> {
>comment:"H264ENCSEC1",
>name: "H264ENCSEC1",
>base: 0x8FA0,
>len:0x4140,
>space: "code/data"
> },
> {
>comment:"H264ENCSEC2",
>name: "H264ENCSEC2",
>base: 0x8FA04140,
>len:0x5080,
>space: "code/data"
> },
> {
>comment:"H264ENCSEC3",
>name: "H264ENCSEC3",
>base: 0x8FA09220,
>len:0x6000,
>space: "code/data"
> },
> {
>comment:"H264ENCSEC4",
>name: "H264ENCSEC4",
>base: 0x8FA1,
>len:0x5000,
>space: "code/data"
> },
> {
>comment:"H264ENCSEC5",
>name: "H264ENCSEC5",
>base: 0x8FA15000,
>len:0x3000,
>space: "code/data"
> },
> {
>comment:"H264ENCSEC6",
>name: "H264ENCSEC6",
>base: 0x8FA18000,
>len:0x4040,
>space: "code/data"
> },
> {
>comment:"H264ENCSEC7",
>name: "H264ENCSEC7",
>base: 0x8FA28000,
>len:0x5400,
>space: "code/data"
> },
> {
>comment:"H264ENCSEC8",
>name: "H264ENCSEC8",
>base: 0x8FA2D400,
>len:0x2c00,
>space: "code/data"
> },
> {
>comment:"MPEG4ENCSEC1",
>name: "MPEG4ENCSEC1",
>base: 0x8FA4,
>len:0x0001,
>space: "code/data"
> },
> {
>comment:"MPEG4ENCSEC2",
>name: "MPEG4ENCSEC2",
>base: 0x8FA5,
>len:0x8000,
>space: "code/data"
> },
> {
>comment:"MPEG4ENCSEC3",
>name: "MPEG4ENCSEC3",
>base: 0x8FA58000,
>len:0x8000,
>space: "code/data"
> },
> {
>comment:"MPEG4ENCSEC4",
>name: "MPEG4ENCSEC4",
>base: 0x8FA6,
>len:0x8000,
>space: "code/data"
> },
> {
>comment:"MPEG4ENCSEC5",
>name: "MPEG4ENCSEC5",
>base: 0x8FA68000,
>len:0x8000,
>space: "code/data"
> },
> {
>comment:"MPEG4ENCSEC6",
>name: "MPEG4ENCSEC6",
>base: 0x8FA7,
>len:0x8000,
>space: "code/data"
> },
> {
>comment:"MPEG4ENCSEC7",
>name: "MPEG4ENCSEC7",
>base: 0x8FA78000,
>len:0x0001,
>space: "code/data"
> },
>
> {
>
>comment:"DDR: memory for code and data",
>name: "DDR",
>base: 0x8FB0,
>len:0x0030,
>
Re: Unable to change cache size in codec engine.
thanks
On Thu, May 21, 2009 at 2:39 PM, Ondrej Pindroch wrote:
> Refer to tms320dm6446.pdf /p14 (datasheet of TMS320DM6446) DSP has only
> 64KB
>
> The DSP Subsystem includes the following features:
> · C64x+ DSP CPU
> · 32KB L1 Program (L1P)/Cache (up to 32KB)
> · 80KB L1 Data (L1D)/Cache (up to 32KB)
> · 64KB Unified Mapped RAM/Cache (L2)
> · Little endian
> Best regards
>
> Ondrej Pindroch
>
>
> -Original Message-
> From: bhushan
> To: jaya.krish...@samsung.com
> Cc: "davinci-linux-open-source@linux.davincidsp.com"
>
> Date: Thu, 21 May 2009 14:23:18 +0530
> Subject: Re: Unable to change cache size in codec engine.
>
> I am referring doc spru871j.pdf. In the section Level 2 memory and
> cache it is mentioned that the L2 cache size can be configured for
> 32KB, 64KB, 128KB and 256KB. I presume the L2_CACHE is same as this.
> If there is any other doc whcih specifies that the cache size
> configured is limited to 64KB please refer the same to me.
>
> regards,
> Bhushan
>
> On Thu, May 21, 2009 at 1:30 PM, Jaya krishnan
> wrote:
>> Hello,
>> I remember 64x+ L2 cache size is 64K (maximum).
>> Regards
>> Jayakrishnan
>>
>>
>>
>>
>> --- Original Message ---
>> Sender : bhushan
>> Date : May 21, 2009 16:19 (GMT+09:00)
>> Title : Unable to change cache size in codec engine.
>>
>> Hello ,
>> I am trying to build an application to encode video in mpeg4 format
>> and also integrate the scale example from the codec engine in the
>> encode combo server. During the integration fro performance reasons I
>> want to increase the L2 cache size from 64k to 128k. My processor is
>> tms320dm6446.
>> On building the codec_server I get the error:
>> Error: Can't set cache to size: 128k
>> Following is the encode.tcf file:
>> /*
>> * Setup platform-specific memory map, CLK rate, etc.
>> */
>> var mem_ext = [
>> {
>> comment: "DDRALGHEAP: memory for dynamic algmem allocation",
>> name: "DDRALGHEAP",
>> base: 0x8B80,
>> len: 0x0420,// 66MB
>> space: "code/data"
>> },
>> {
>> comment: "L1DSRAM: memory for dynamic algmem allocation",
>> name: "L1DSRAM",
>> base: 0x11F04000, //
>> len: 0x1, // 64k
>> space: "data"
>> },
>> {
>> comment: "CACHE_L2",
>> name: "CACHE_L2",
>> base: 0x1180, //
>> len: 0x20, // 128k
>> space: "data"
>> },
>> {
>> comment: "H264ENCSEC1",
>> name: "H264ENCSEC1",
>> base: 0x8FA0,
>> len: 0x4140,
>> space: "code/data"
>> },
>> {
>> comment: "H264ENCSEC2",
>> name: "H264ENCSEC2",
>> base: 0x8FA04140,
>> len: 0x5080,
>> space: "code/data"
>> },
>> {
>> comment: "H264ENCSEC3",
>> name: "H264ENCSEC3",
>> base: 0x8FA09220,
>> len: 0x6000,
>> space: "code/data"
>> },
>> {
>> comment: "H264ENCSEC4",
>> name: "H264ENCSEC4",
>> base: 0x8FA1,
>> len: 0x5000,
>> space: "code/data"
>> },
>> {
>> comment: "H264ENCSEC5",
>> name: "H264ENCSEC5",
>> base: 0x8FA15000,
>> len: 0x3000,
>> space: "code/data"
>> },
>> {
>> comment: "H264ENCSEC6",
>> name: "H264ENCSEC6",
>> base: 0x8FA18000,
>> len: 0x4040,
>> space: "code/data"
>> },
>> {
>> comment: "H264ENCSEC7",
>> name: "H264ENCSEC7",
>> base: 0x8FA28000,
>> len: 0x5400,
>> space: "code/data"
>> },
>> {
>> comment: "H264ENCSEC8",
>> name: "H264ENCSEC8",
>> base: 0x8FA2D400,
>> len: 0x2c00,
>> space: "code/data"
>> },
>> {
>> comment: "MPEG4ENCSEC1",
>> name: "MPEG4ENCSEC1",
>> base: 0x8FA4,
>> len: 0x0001,
>> space: "code/data"
>> },
>> {
>> comment: "MPEG4ENCSEC2",
>> name: "MPEG4ENCSEC2",
>> base: 0x8FA5,
>> len: 0x8000,
>> space: "code/data"
>> },
>> {
>> comment: "MPEG4ENCSEC3",
>> name: "MPEG4ENCSEC3",
>> base: 0x8FA58000,
>> len: 0x8000,
>> space: "code/data"
>> },
>> {
>> comment: "MPEG4ENCSEC4",
>> name: "MPEG4ENCSEC4",
>> base: 0x8FA6,
>> len: 0x8000,
>> space: "code/data"
>> },
>> {
>> comment: "MPEG4ENCSEC5",
>> name: "MPEG4ENCSEC5",
>> base: 0x8FA68000,
>> len: 0x8000,
>> space: "code/data"
>> },
>> {
>> comment: "MPEG4ENCSEC6",
>> name: "MPEG4ENCSEC6",
>> base: 0x8FA7,
>> len: 0x8000,
>> space: "code/data"
>> },
>> {
>> comment: "MPEG4ENCSEC7",
>> name: "MPEG4ENCSEC7",
>> base: 0x8FA78000,
>> len: 0x0001,
>> space: "code/data"
>> },
>>
>> {
>>
>> comment: "DDR: memory for
about mpeg4 SP on DM355!!!!!!!!
All, Could anyone show me how to convert video clips with other encoder formats to be playable by dm355 mpeg4 sp decoder using open source tool (ffmpeg or others)? I need not ArcSoft MediaConverter(I need a free tool). Thanks very much. BR, Jeff ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: SD root filsystem support on OMAP-L137 EVM
From: Erik Svensson Sent: Tuesday, May 19, 2009 3:09 PM > > Hello, > > Sorry for the confusion. I am able to boot using SPI and SD with the > MV-kernel and I am content with that. But I wanted to see what > linux-davinci had to offer. For SPI, you would have to take Sandeep's DM355 SPI patches (posted 5/17) and then port for OMAP-L137. The SPI flash is supported by the MTD m25p80.c driver. SD should be more straightforward. davinci_mmc.c should be ready for OMAP-L137 support. You will need register the appropriate platform device structure and take also take care of pinmux. Patches for supporting these should flow in once the basic DA830/OMAP- L137 support is pushed. Thanks, Sekhar > Even if I was able to boot from NFS this > would soon be insufficient, I will need to be able to boot linux > without external support. I was wondering if this currently is > possible? It is also interesting to know if this is on the way or if > would be hard to accomplish. > I have no prior experience developing on the linux kernel but >5 years > of Win32 C++ and experienced hardware developer. > > Best regards, > Erik Svensson > > On Mon, May 18, 2009 at 7:36 PM, Tobias Knutsson > wrote: > > Hi Erik > > > > I have used an NFS rootfs on the OMAPL137 with the MV- kernel and it > worked > > just fine. Some things to try out: > > > > - Sure you have nfs+nfs on root enabled? > > > > - Can you mount the NFS share from some other machine? > > > > - How does your /etc/exports entry look? It the bitmask wrong? > Permissions? > > > > Hälsningar / Regards > > Tobias Knutsson > > > > On 18 maj 2009, at 14.50, Erik Svensson > wrote: > > > >> Hello, > >> > >> As Tobias tried in Friday I'm also trying to boot linux-davinci on > the > >> OMAP-L137 EVM board. With the advice in his thread I seem to be > able > >> to come a bit longer in the boot process. I haven't been able to > set > >> up NFS boot and therefore boot from SPI with file system on SD. > This > >> doesn't seem to work tho so I'm wondering if this is not yet > supported > >> in linux-davinci? > >> > >> I'm using linux-davinci master commit > >> 6d5f14ebd3e9401f17b215fab8038138462dfd43 (ASoC: Correct the > resource > >> structure assignment) with following patches > >> > >> - [PATCH] ARM: Add writethrough dcache support for ARM926EJS > processor > >> - [PATCH] ARM: Davinci - Put WDT platform_device in soc_info > structure > >> - [PATCH 1/2 v5] ARM: da830 - Add base DA830/OMAP-L137 SoC support > >> - [PATCH 2/2 v5] ARM: da830 - Add support for DA830/OMAP-L137 EVM > >> > >> Best regards, > >> Erik Svensson > >> > >> ___ > >> Davinci-linux-open-source mailing list > >> Davinci-linux-open-source@linux.davincidsp.com > >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- > source > > > > ___ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Audio on DM355 EVM
Dave, Thank you for the suggestion. Troy's patch works fine on DM355 EVM. Regards, Chaithrika > -Original Message- > From: David Brownell [mailto:davi...@pacbell.net] > Sent: Thursday, May 21, 2009 12:27 PM > To: davinci-linux-open-source@linux.davincidsp.com > Cc: chaithrika > Subject: Re: Audio on DM355 EVM > > On Wednesday 20 May 2009, chaithrika wrote: > > All, > > > > We are observing overrun and underrun messages when arecord and aplay > > utilities are used. This has been observed with the latest kernel > > after a merge with the 2.6.30-rc2. Has anybody observed this? > > It's a well-discussed issue. Did you try with the patch that > Troy sent yesterday? "ASoc use iram to buffer sound". > > > > With 'arecord -f cd /dev/null' too these overrun messages are > observed. > > > > Also, record for 8kHz sampling rate is not working (kernel hangs). > > > > Audio is working fine with the 2.6.29-davinci1 version (commit > > 0b9273a39e5e25532c88a00369306a229ec98c8f). > > > > Also, during audio playback the audio can be heard either on the left > or > > right side (only on 1 side at a time). This issue though is not > > related to the above overrun/underrun issue. > > > > > > Regards, > > Chaithrika > > > > > > ___ > > Davinci-linux-open-source mailing list > > Davinci-linux-open-source@linux.davincidsp.com > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- > source > > > > > ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] RFC: ARM: DaVinci: ASoc use iram to buffer sound
Troy,
I tried this patch on DM355 EVM. It works fine.
Thanks,
Chaithrika
> -Original Message-
> From: davinci-linux-open-source-
> bounces+chaithrika=ti@linux.davincidsp.com [mailto:davinci-linux-
> open-source-bounces+chaithrika=ti@linux.davincidsp.com] On Behalf
> Of Troy Kisky
> Sent: Wednesday, May 20, 2009 5:18 AM
> To: davinci-linux-open-source@linux.davincidsp.com
> Subject: [PATCH] RFC: ARM: DaVinci: ASoc use iram to buffer sound
>
> Use the sram(iram) to avoid underrun on audio.
> I will clean this up after someone says it
> works for them.
>
> Signed-off-by: Troy Kisky
> ---
> include/sound/soc-dai.h |2 +
> sound/soc/davinci/davinci-i2s.c | 336 -
> sound/soc/davinci/davinci-pcm.c | 516 ++-
>
> sound/soc/davinci/davinci-pcm.h |3 +-
> 4 files changed, 618 insertions(+), 239 deletions(-)
>
> diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
> index 1367647..fe9bfa3 100644
> --- a/include/sound/soc-dai.h
> +++ b/include/sound/soc-dai.h
> @@ -137,6 +137,7 @@ int snd_soc_dai_digital_mute(struct snd_soc_dai
> *dai, int mute);
> * This structure covers the clocking, formating and ALSA operations
> for each
> * interface a
> */
> +/* ASoC DAI ops */
> struct snd_soc_dai_ops {
> /*
>* DAI clocking configuration, all optional.
> @@ -162,6 +163,7 @@ struct snd_soc_dai_ops {
>* Called by soc-core to minimise any pops.
>*/
> int (*digital_mute)(struct snd_soc_dai *dai, int mute);
> + int (*inform_channel_order)(struct snd_soc_dai *dai, int
> right_first);
>
> /*
>* ALSA PCM audio operations - all optional.
> diff --git a/sound/soc/davinci/davinci-i2s.c
> b/sound/soc/davinci/davinci-i2s.c
> index b1ea52f..725a019 100644
> --- a/sound/soc/davinci/davinci-i2s.c
> +++ b/sound/soc/davinci/davinci-i2s.c
> @@ -63,6 +63,7 @@
> #define DAVINCI_MCBSP_RCR_RWDLEN1(v) ((v) << 5)
> #define DAVINCI_MCBSP_RCR_RFRLEN1(v) ((v) << 8)
> #define DAVINCI_MCBSP_RCR_RDATDLY(v) ((v) << 16)
> +#define DAVINCI_MCBSP_RCR_RFIG (1 << 18)
> #define DAVINCI_MCBSP_RCR_RWDLEN2(v) ((v) << 21)
>
> #define DAVINCI_MCBSP_XCR_XWDLEN1(v) ((v) << 5)
> @@ -85,14 +86,6 @@
> #define DAVINCI_MCBSP_PCR_FSRM (1 << 10)
> #define DAVINCI_MCBSP_PCR_FSXM (1 << 11)
>
> -#define MOD_REG_BIT(val, mask, set) do { \
> - if (set) { \
> - val |= mask; \
> - } else { \
> - val &= ~mask; \
> - } \
> -} while (0)
> -
> enum {
> DAVINCI_MCBSP_WORD_8 = 0,
> DAVINCI_MCBSP_WORD_12,
> @@ -112,8 +105,13 @@ static struct davinci_pcm_dma_params
> davinci_i2s_pcm_in = {
>
> struct davinci_mcbsp_dev {
> void __iomem*base;
> +#define MOD_DSP_A0
> +#define MOD_DSP_B1
> + int mode;
> + u32 pcr;
> struct clk *clk;
> struct davinci_pcm_dma_params *dma_params[2];
> + struct snd_soc_dai *codec_dai;
> };
>
> static inline void davinci_mcbsp_write_reg(struct davinci_mcbsp_dev
> *dev,
> @@ -127,96 +125,100 @@ static inline u32 davinci_mcbsp_read_reg(struct
> davinci_mcbsp_dev *dev, int reg)
> return __raw_readl(dev->base + reg);
> }
>
> -static void davinci_mcbsp_start(struct snd_pcm_substream *substream)
> +static void toggle_clock(struct davinci_mcbsp_dev *dev, int playback)
> +{
> + u32 m = playback ? DAVINCI_MCBSP_PCR_CLKXP :
> DAVINCI_MCBSP_PCR_CLKRP;
> + /* The clock needs to toggle to complete reset.
> + * So, fake it by toggling the clk polarity.
> + */
> + davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_PCR_REG, dev->pcr ^
> m);
> + davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_PCR_REG, dev->pcr);
> +}
> +
> +static void davinci_mcbsp_start(struct davinci_mcbsp_dev *dev,
> + struct snd_pcm_substream *substream)
> {
> struct snd_soc_pcm_runtime *rtd = substream->private_data;
> - struct davinci_mcbsp_dev *dev = rtd->dai->cpu_dai->private_data;
> struct snd_soc_device *socdev = rtd->socdev;
> struct snd_soc_platform *platform = socdev->card->platform;
> - u32 w;
> - int ret;
> -
> - /* Start the sample generator and enable transmitter/receiver */
> - w = davinci_mcbsp_read_reg(dev, DAVINCI_MCBSP_SPCR_REG);
> - MOD_REG_BIT(w, DAVINCI_MCBSP_SPCR_GRST, 1);
> - davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SPCR_REG, w);
> + int playback = (substream->stream == SNDRV_PCM_STREAM_PLAYBACK);
> + u32 spcr;
> + u32 mask = playback ? DAVINCI_MCBSP_SPCR_XRST :
> DAVINCI_MCBSP_SPCR_RRST;
> + spcr = davinci_mcbsp_read_reg(dev, DAVINCI_MCBSP_SPCR_REG);
> + if (spcr & mask) {
> + /* start off disabled */
> + davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SPCR_REG,
> + spcr & ~mask);
> + toggle_clock(dev, playback);
> +
RE: [PATCH v2] net-next-2.6: TI DaVinci EMAC driver
David, > -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Tuesday, May 19, 2009 3:50 AM > To: chaithr...@ti.com > Cc: net...@vger.kernel.org; davinci-linux-open- > sou...@linux.davincidsp.com; nsek...@ti.com; anantg...@ti.com; > khil...@deeprootsystems.com > Subject: Re: [PATCH v2] net-next-2.6: TI DaVinci EMAC driver > > From: Chaithrika U S > Date: Mon, 18 May 2009 07:34:32 -0400 > > > Add support for TI DaVinci EMAC driver. > > > > TI DaVinci Ethernet Media Access Controller module is based upon > > TI CPPI 3.0 DMA engine and supports 10/100 Mbps on all and Gigabit > modes on > > some TI devices. It supports MII/RMII and has up to 8Kbytes of > internal > > descriptor memory. This driver has been working on several TI devices > including > > DM644x, DM646x and DA830 platforms. The specs of this device are > available at: > > http://www.ti.com/litv/pdf/sprue24a > > > > Signed-off-by: Anant Gole > > Signed-off-by: Kevin Hilman > > Signed-off-by: Chaithrika U S > > Applied, thanks. > Thanks. > BTW, DECLARE_MAC_BUF(), print_mac() et al. is deprecated, you can > simply use the printf format specifier "%pM" to print MAC addresses > directly. OK. Will submit a patch for this. Regards, Chaithrika ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v4 1/3] ARM: DaVinci: Internal restructuring of EDMA driver
Define a structure to store EDMA channel controller based information.
Use platform_device.id to find out the instance being configured in
probe function.
Signed-off-by: Sudhakar Rajashekhara
---
arch/arm/mach-davinci/dm355.c |5 +-
arch/arm/mach-davinci/dm644x.c|5 +-
arch/arm/mach-davinci/dma.c | 99 +++--
arch/arm/mach-davinci/include/mach/edma.h |1 +
4 files changed, 73 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index bccc5a8..984a237 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -563,12 +563,13 @@ static struct edma_soc_info dm355_edma_info = {
.n_region = 4,
.n_slot = 128,
.n_tc = 2,
+ .n_cc = 1,
.noevent= dma_chan_dm355_no_event,
};
static struct resource edma_resources[] = {
{
- .name = "edma_cc",
+ .name = "edma_cc0",
.start = 0x01c0,
.end= 0x01c0 + SZ_64K - 1,
.flags = IORESOURCE_MEM,
@@ -598,7 +599,7 @@ static struct resource edma_resources[] = {
static struct platform_device dm355_edma_device = {
.name = "edma",
- .id = -1,
+ .id = 0,
.dev.platform_data = &dm355_edma_info,
.num_resources = ARRAY_SIZE(edma_resources),
.resource = edma_resources,
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 45abac4..7f44a77 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -489,12 +489,13 @@ static struct edma_soc_info dm644x_edma_info = {
.n_region = 4,
.n_slot = 128,
.n_tc = 2,
+ .n_cc = 1,
.noevent= dma_chan_dm644x_no_event,
};
static struct resource edma_resources[] = {
{
- .name = "edma_cc",
+ .name = "edma_cc0",
.start = 0x01c0,
.end= 0x01c0 + SZ_64K - 1,
.flags = IORESOURCE_MEM,
@@ -524,7 +525,7 @@ static struct resource edma_resources[] = {
static struct platform_device dm644x_edma_device = {
.name = "edma",
- .id = -1,
+ .id = 0,
.dev.platform_data = &dm644x_edma_info,
.num_resources = ARRAY_SIZE(edma_resources),
.resource = edma_resources,
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 1f58631..53f6c9b 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -107,11 +107,12 @@
#define EDMA_MAX_DMACH 64
#define EDMA_MAX_PARAMENTRY 512
#define EDMA_MAX_EVQUE2/* FIXME too small */
+#define EDMA_MAX_CC 2
/*/
-static __iomem void *edmacc_regs_base;
+static __iomem void *edmacc_regs_base[EDMA_MAX_CC];
static inline unsigned int edma_read(int offset)
{
@@ -207,24 +208,39 @@ static inline void edma_parm_or(int offset, int param_no,
unsigned or)
/*/
/* actual number of DMA channels and slots on this silicon */
-static unsigned num_channels;
-static unsigned num_slots;
+struct edma {
+ /* how many dma resources of each type */
+ unsignednum_channels;
+ unsignednum_region;
+ unsignednum_slots;
+ unsignednum_tc;
+ unsignednum_cc;
+
+ /* list of channels with no even trigger; terminated by "-1" */
+ const s8*noevent;
+
+ /* The edma_inuse bit for each PaRAM slot is clear unless the
+* channel is in use ... by ARM or DSP, for QDMA, or whatever.
+*/
+ DECLARE_BITMAP(edma_inuse, EDMA_MAX_PARAMENTRY);
-static struct dma_interrupt_data {
- void (*callback)(unsigned channel, unsigned short ch_status, void
*data);
- void *data;
-} intr_data[EDMA_MAX_DMACH];
+ /* The edma_noevent bit for each channel is clear unless
+* it doesn't trigger DMA events on this platform. It uses a
+* bit of SOC-specific initialization code.
+*/
+ DECLARE_BITMAP(edma_noevent, EDMA_MAX_DMACH);
-/* The edma_inuse bit for each PaRAM slot is clear unless the
- * channel is in use ... by ARM or DSP, for QDMA, or whatever.
- */
-static DECLARE_BITMAP(edma_inuse, EDMA_MAX_PARAMENTRY);
+ unsignedirq_res_start;
+ unsignedirq_res_end;
-/* The edma_noevent bit for each channel is clear unless
- * it doesn't trigger DMA events on this platform. It uses a
- * bit of SOC-specific initialization code.
- */
-static DECLARE_
[PATCH v4 0/3] ARM: DaVinci: Add support for multiple EDMA CC instances
Existing EDMA driver does not take care of multiple EDMA channel controller instances. An upcoming architecture from TI has 2 EDMA channel controller instances. This series adds support for multiple EDMA CC instances. With this patch, user needs to pass the EDMA channel number as EDMA_CTLR_CHAN(ctlr, chan), through IORESOURCE_DMA resources. The edma_alloc_channel api returns the channel number in LSB and controller number in MSB. This return value is accepted by the other EDMA apis. Drivers using EDMA have to pass controller number as an argument along with slot number required. The macros EDMA_CHAN_SLOT and EDMA_CTLR will extract the channel/slot number and the controller number from the value returned by edma_alloc_channel. This series has been tested on DM644x. Thanks to David Brownell(davi...@pacbell.net) for all the review comments. -Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v4 3/3] ARM: DaVinci: Modifications to EDMA driver
Modify the EDMA driver based on the interface changes done by the first
two patches of this series.
Signed-off-by: Sudhakar Rajashekhara
---
arch/arm/mach-davinci/dma.c | 507 ---
1 files changed, 333 insertions(+), 174 deletions(-)
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index fdfd59d..056e21e 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -114,95 +114,105 @@
static __iomem void *edmacc_regs_base[EDMA_MAX_CC];
-static inline unsigned int edma_read(int offset)
+static inline unsigned int edma_read(unsigned ctlr, int offset)
{
- return (unsigned int)__raw_readl(edmacc_regs_base + offset);
+ return (unsigned int)__raw_readl(edmacc_regs_base[ctlr] + offset);
}
-static inline void edma_write(int offset, int val)
+static inline void edma_write(unsigned ctlr, int offset, int val)
{
- __raw_writel(val, edmacc_regs_base + offset);
+ __raw_writel(val, edmacc_regs_base[ctlr] + offset);
}
-static inline void edma_modify(int offset, unsigned and, unsigned or)
+static inline void edma_modify(unsigned ctlr, int offset, unsigned and,
+ unsigned or)
{
- unsigned val = edma_read(offset);
+ unsigned val = edma_read(ctlr, offset);
val &= and;
val |= or;
- edma_write(offset, val);
+ edma_write(ctlr, offset, val);
}
-static inline void edma_and(int offset, unsigned and)
+static inline void edma_and(unsigned ctlr, int offset, unsigned and)
{
- unsigned val = edma_read(offset);
+ unsigned val = edma_read(ctlr, offset);
val &= and;
- edma_write(offset, val);
+ edma_write(ctlr, offset, val);
}
-static inline void edma_or(int offset, unsigned or)
+static inline void edma_or(unsigned ctlr, int offset, unsigned or)
{
- unsigned val = edma_read(offset);
+ unsigned val = edma_read(ctlr, offset);
val |= or;
- edma_write(offset, val);
+ edma_write(ctlr, offset, val);
}
-static inline unsigned int edma_read_array(int offset, int i)
+static inline unsigned int edma_read_array(unsigned ctlr, int offset, int i)
{
- return edma_read(offset + (i << 2));
+ return edma_read(ctlr, offset + (i << 2));
}
-static inline void edma_write_array(int offset, int i, unsigned val)
+static inline void edma_write_array(unsigned ctlr, int offset, int i,
+ unsigned val)
{
- edma_write(offset + (i << 2), val);
+ edma_write(ctlr, offset + (i << 2), val);
}
-static inline void edma_modify_array(int offset, int i,
+static inline void edma_modify_array(unsigned ctlr, int offset, int i,
unsigned and, unsigned or)
{
- edma_modify(offset + (i << 2), and, or);
+ edma_modify(ctlr, offset + (i << 2), and, or);
}
-static inline void edma_or_array(int offset, int i, unsigned or)
+static inline void edma_or_array(unsigned ctlr, int offset, int i, unsigned or)
{
- edma_or(offset + (i << 2), or);
+ edma_or(ctlr, offset + (i << 2), or);
}
-static inline void edma_or_array2(int offset, int i, int j, unsigned or)
+static inline void edma_or_array2(unsigned ctlr, int offset, int i, int j,
+ unsigned or)
{
- edma_or(offset + ((i*2 + j) << 2), or);
+ edma_or(ctlr, offset + ((i*2 + j) << 2), or);
}
-static inline void edma_write_array2(int offset, int i, int j, unsigned val)
+static inline void edma_write_array2(unsigned ctlr, int offset, int i, int j,
+ unsigned val)
{
- edma_write(offset + ((i*2 + j) << 2), val);
+ edma_write(ctlr, offset + ((i*2 + j) << 2), val);
}
-static inline unsigned int edma_shadow0_read(int offset)
+static inline unsigned int edma_shadow0_read(unsigned ctlr, int offset)
{
- return edma_read(EDMA_SHADOW0 + offset);
+ return edma_read(ctlr, EDMA_SHADOW0 + offset);
}
-static inline unsigned int edma_shadow0_read_array(int offset, int i)
+static inline unsigned int edma_shadow0_read_array(unsigned ctlr, int offset,
+ int i)
{
- return edma_read(EDMA_SHADOW0 + offset + (i << 2));
+ return edma_read(ctlr, EDMA_SHADOW0 + offset + (i << 2));
}
-static inline void edma_shadow0_write(int offset, unsigned val)
+static inline void edma_shadow0_write(unsigned ctlr, int offset, unsigned val)
{
- edma_write(EDMA_SHADOW0 + offset, val);
+ edma_write(ctlr, EDMA_SHADOW0 + offset, val);
}
-static inline void edma_shadow0_write_array(int offset, int i, unsigned val)
+static inline void edma_shadow0_write_array(unsigned ctlr, int offset, int i,
+ unsigned val)
{
- edma_write(EDMA_SHADOW0 + offset + (i << 2), val);
+ edma_write(ctlr, EDMA_SHADOW0 + offset + (i << 2), val);
}
-static inline unsigned int edma_parm_read(int offset, int param_no)
+static inline unsigned int edma_parm_read(unsigned ctlr, int offset,
+ int param_no)
{
- return edma_read(EDMA_PARM + offset + (param
[PATCH v4 2/3] ARM: DaVinci: Interface changes visible to EDMA clients
Introduce macros to build IDs from controller and channel number, and to
extract them. Modify the edma_alloc_slot function to take an extra argument
for the controller.
Also, modify the MMC and ASoC drivers to reflect the above changes.
Signed-off-by: Sudhakar Rajashekhara
---
arch/arm/mach-davinci/devices.c |8
arch/arm/mach-davinci/dma.c | 25 +++--
arch/arm/mach-davinci/include/mach/edma.h |6 +-
drivers/mmc/host/davinci_mmc.c| 10 +-
sound/soc/davinci/davinci-evm.c |8
sound/soc/davinci/davinci-pcm.c |6 +++---
6 files changed, 36 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 5b21faf..0968722 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -90,10 +90,10 @@ static struct resource mmcsd0_resources[] = {
},
/* DMA channels: RX, then TX */
{
- .start = DAVINCI_DMA_MMCRXEVT,
+ .start = EDMA_CTLR_CHAN(0, DAVINCI_DMA_MMCRXEVT),
.flags = IORESOURCE_DMA,
}, {
- .start = DAVINCI_DMA_MMCTXEVT,
+ .start = EDMA_CTLR_CHAN(0, DAVINCI_DMA_MMCTXEVT),
.flags = IORESOURCE_DMA,
},
};
@@ -127,10 +127,10 @@ static struct resource mmcsd1_resources[] = {
},
/* DMA channels: RX, then TX */
{
- .start = 30,/* rx */
+ .start = EDMA_CTLR_CHAN(0, 30), /* rx */
.flags = IORESOURCE_DMA,
}, {
- .start = 31,/* tx */
+ .start = EDMA_CTLR_CHAN(0, 31), /* tx */
.flags = IORESOURCE_DMA,
},
};
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 53f6c9b..fdfd59d 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -573,28 +573,33 @@ EXPORT_SYMBOL(edma_free_channel);
*
* Returns the number of the slot, else negative errno.
*/
-int edma_alloc_slot(int slot)
+int edma_alloc_slot(unsigned ctlr, int slot)
{
+ if (slot >= 0)
+ slot = EDMA_CHAN(slot);
+
if (slot < 0) {
- slot = num_channels;
+ slot = edma_info[ctlr]->num_channels;
for (;;) {
- slot = find_next_zero_bit(edma_inuse,
- num_slots, slot);
- if (slot == num_slots)
+ slot = find_next_zero_bit(edma_info[ctlr]->edma_inuse,
+ edma_info[ctlr]->num_slots, slot);
+ if (slot == edma_info[ctlr]->num_slots)
return -ENOMEM;
- if (!test_and_set_bit(slot, edma_inuse))
+ if (!test_and_set_bit(slot,
+ edma_info[ctlr]->edma_inuse))
break;
}
- } else if (slot < num_channels || slot >= num_slots) {
+ } else if (slot < edma_info[ctlr]->num_channels ||
+ slot >= edma_info[ctlr]->num_slots) {
return -EINVAL;
- } else if (test_and_set_bit(slot, edma_inuse)) {
+ } else if (test_and_set_bit(slot, edma_info[ctlr]->edma_inuse)) {
return -EBUSY;
}
- memcpy_toio(edmacc_regs_base + PARM_OFFSET(slot),
+ memcpy_toio(edmacc_regs_base[ctlr] + PARM_OFFSET(slot),
&dummy_paramset, PARM_SIZE);
- return slot;
+ return EDMA_CTLR_CHAN(ctlr, slot);
}
EXPORT_SYMBOL(edma_alloc_slot);
diff --git a/arch/arm/mach-davinci/include/mach/edma.h
b/arch/arm/mach-davinci/include/mach/edma.h
index 517ae36..aaeeb96 100644
--- a/arch/arm/mach-davinci/include/mach/edma.h
+++ b/arch/arm/mach-davinci/include/mach/edma.h
@@ -171,6 +171,10 @@ enum sync_dimension {
ABSYNC = 1
};
+#define EDMA_CTLR_CHAN(ctlr, chan) (((ctlr) << 16) | (chan))
+#define EDMA_CTLR(i) ((i) >> 16)
+#define EDMA_CHAN_SLOT(i) ((i) & 0x)
+
#define EDMA_CHANNEL_ANY -1 /* for edma_alloc_channel() */
#define EDMA_SLOT_ANY -1 /* for edma_alloc_slot() */
@@ -181,7 +185,7 @@ int edma_alloc_channel(int channel,
void edma_free_channel(unsigned channel);
/* alloc/free parameter RAM slots */
-int edma_alloc_slot(int slot);
+int edma_alloc_slot(unsigned ctlr, int slot);
void edma_free_slot(unsigned slot);
/* calls that operate on part of a parameter RAM slot */
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 9b23802..5babb1f 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -178,7 +178,7 @@ struct mmc_davinci_host {
u32 buffer_bytes_left;
u32 bytes_left;
- u8 rxdma, txdma;
+ u32 rxdma, txdma;
How to improve image latency
Hi I have an aplication which is useing CCDC PREVIEWER and V4L2 for output. There is one buffer between CCDC and PREVIEWER (exactly 3 buffers) and for output it is used buffer from V4L2. For now I have latency 160 - 200ms. I have made some mistakes and loosing frames (hudge bunche of errors). Than I have had latency less than 100ms. I have alredy measured time needed for capture and proccessing. It was 5-7ms. >From capture to get frame buffer from V4L2 it take almost 40ms (25fps for PAL) Have you any idea where I get this 120ms of additional latency. Frame rate of sensor is almost 60fps Thanks Ondrej Pindroch SoftHard Technology ltd. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] RFC: ARM: DaVinci: ASoc use iram to buffer sound
Troy,
I tried this patch on DM644x EVM and following are my observations:
1. Playback works fine.
2. Record has some issues. Recorded stream has Loud volume on
the right side, and on the left, volume is very low.
3. Loopback (arecord -f cd | aplay -f cd) has some issues.
Audio is bit noisy here. I think if arecord issues are fixed,
this may go away.
On DM355, though arecord and aplay work fine independently. But
once loopback is run, arecord records data only on one side.
Loopback is noisy with intermittent overrun/underrun messages both
on DM355 and DM644x EVMs.
Regards, Sudhakar
> -Original Message-
> From: davinci-linux-open-source-
> bounces+sudhakar.raj=ti@linux.davincidsp.com [mailto:davinci-linux-
> open-source-bounces+sudhakar.raj=ti@linux.davincidsp.com] On Behalf
> Of Troy Kisky
> Sent: Wednesday, May 20, 2009 5:18 AM
> To: davinci-linux-open-source@linux.davincidsp.com
> Subject: [PATCH] RFC: ARM: DaVinci: ASoc use iram to buffer sound
>
> Use the sram(iram) to avoid underrun on audio.
> I will clean this up after someone says it
> works for them.
>
> Signed-off-by: Troy Kisky
> ---
> include/sound/soc-dai.h |2 +
> sound/soc/davinci/davinci-i2s.c | 336 -
> sound/soc/davinci/davinci-pcm.c | 516 ++-
>
> sound/soc/davinci/davinci-pcm.h |3 +-
> 4 files changed, 618 insertions(+), 239 deletions(-)
>
> diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
> index 1367647..fe9bfa3 100644
> --- a/include/sound/soc-dai.h
> +++ b/include/sound/soc-dai.h
> @@ -137,6 +137,7 @@ int snd_soc_dai_digital_mute(struct snd_soc_dai
> *dai, int mute);
> * This structure covers the clocking, formating and ALSA operations
> for each
> * interface a
> */
> +/* ASoC DAI ops */
> struct snd_soc_dai_ops {
> /*
>* DAI clocking configuration, all optional.
> @@ -162,6 +163,7 @@ struct snd_soc_dai_ops {
>* Called by soc-core to minimise any pops.
>*/
> int (*digital_mute)(struct snd_soc_dai *dai, int mute);
> + int (*inform_channel_order)(struct snd_soc_dai *dai, int
> right_first);
>
> /*
>* ALSA PCM audio operations - all optional.
> diff --git a/sound/soc/davinci/davinci-i2s.c
> b/sound/soc/davinci/davinci-i2s.c
> index b1ea52f..725a019 100644
> --- a/sound/soc/davinci/davinci-i2s.c
> +++ b/sound/soc/davinci/davinci-i2s.c
> @@ -63,6 +63,7 @@
> #define DAVINCI_MCBSP_RCR_RWDLEN1(v) ((v) << 5)
> #define DAVINCI_MCBSP_RCR_RFRLEN1(v) ((v) << 8)
> #define DAVINCI_MCBSP_RCR_RDATDLY(v) ((v) << 16)
> +#define DAVINCI_MCBSP_RCR_RFIG (1 << 18)
> #define DAVINCI_MCBSP_RCR_RWDLEN2(v) ((v) << 21)
>
> #define DAVINCI_MCBSP_XCR_XWDLEN1(v) ((v) << 5)
> @@ -85,14 +86,6 @@
> #define DAVINCI_MCBSP_PCR_FSRM (1 << 10)
> #define DAVINCI_MCBSP_PCR_FSXM (1 << 11)
>
> -#define MOD_REG_BIT(val, mask, set) do { \
> - if (set) { \
> - val |= mask; \
> - } else { \
> - val &= ~mask; \
> - } \
> -} while (0)
> -
> enum {
> DAVINCI_MCBSP_WORD_8 = 0,
> DAVINCI_MCBSP_WORD_12,
> @@ -112,8 +105,13 @@ static struct davinci_pcm_dma_params
> davinci_i2s_pcm_in = {
>
> struct davinci_mcbsp_dev {
> void __iomem*base;
> +#define MOD_DSP_A0
> +#define MOD_DSP_B1
> + int mode;
> + u32 pcr;
> struct clk *clk;
> struct davinci_pcm_dma_params *dma_params[2];
> + struct snd_soc_dai *codec_dai;
> };
>
> static inline void davinci_mcbsp_write_reg(struct davinci_mcbsp_dev
> *dev,
> @@ -127,96 +125,100 @@ static inline u32 davinci_mcbsp_read_reg(struct
> davinci_mcbsp_dev *dev, int reg)
> return __raw_readl(dev->base + reg);
> }
>
> -static void davinci_mcbsp_start(struct snd_pcm_substream *substream)
> +static void toggle_clock(struct davinci_mcbsp_dev *dev, int playback)
> +{
> + u32 m = playback ? DAVINCI_MCBSP_PCR_CLKXP :
> DAVINCI_MCBSP_PCR_CLKRP;
> + /* The clock needs to toggle to complete reset.
> + * So, fake it by toggling the clk polarity.
> + */
> + davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_PCR_REG, dev->pcr ^ m);
> + davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_PCR_REG, dev->pcr);
> +}
> +
> +static void davinci_mcbsp_start(struct davinci_mcbsp_dev *dev,
> + struct snd_pcm_substream *substream)
> {
> struct snd_soc_pcm_runtime *rtd = substream->private_data;
> - struct davinci_mcbsp_dev *dev = rtd->dai->cpu_dai->private_data;
> struct snd_soc_device *socdev = rtd->socdev;
> struct snd_soc_platform *platform = socdev->card->platform;
> - u32 w;
> - int ret;
> -
> - /* Start the sample generator and enable transmitter/receiver */
> - w = davinci_mcbsp_read_reg(dev, DAVINCI_MCBSP_SPCR_REG);
> - MOD_REG_BIT(w, DAVINCI_MCBSP_SPCR_GRST, 1);
> - davinci_mcbsp_wri
RE: Danvinci watchdog + Intel flash problem
Hi Kevin, in general you are right, but in this case is the execution of the bootloader to fail and there's no way to address the problem after reboot. I think there's a problem in the logic implemented in the cfi flash driver: some driver operations don't leave the chip in read array mode and this, according to my point of view, causes the malfunction. If a clean reboot procedure is executed, a reboot notifier routine is executed that puts the chip in the right state In case of watchdog reboot the chip performs a maximum reset without executing any software cleanup procedure and a subsequent boot fails due to impossibility to execute the bootloader from the flash (flash in an inconsistent state). In fact, walking into the driver's code I've seen that: * when the kernel loads the flash driver several operations are performed (chip probe, geometry detection, etc.), most of them put the chip in ready array mode after completion. * when the NOR Flash partitions are given to the driver it configures the partitions to be write protected or unprotected, this operation doesn't seem to leave the chip in read array mode when completed. * if later a read is issued on the device, the chip is correctly configured in read array mode In my case I was using the NOR flash to host the bootloader and the kernel while root file system stays on NFS so there was no read operation after partition configuration so: * when a clean reboot was issued on the board everything went fine, the reboot notifier of the driver is called, the chip is configured in read array mode and reboot is successful * when the watchdog expires the chip remains in the last state asserted during boot (FL_STATUS) so reset is successful but bootloader load fails because chip is not readable. I just changed the following lines in the cfi_cmdset_0001.c to go always to the ready state when an operation is completed (put_chip function): diff -r1.1.1.1 cfi_cmdset_0001.c 853d852 < case FL_READY: 855a855,858 > case FL_READY: > /* let's be safe: go back to ready state */ > map_write(map, CMD(0xff), adr); > chip->state = FL_READY; I've not made exhaustive tests to check that everything works fine with this change, anyway this fix seems to be ok in all the scenarios I have in my environment (kernel/root file system update performed by means of ftp/flashcp commands executed in a shell script). Alberto -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: martedì 19 maggio 2009 17.05 "Alberto Navatta" writes: > We?re trying to use the Davinci (dm6446) hardware watchdog in a > custom board configured to boot from flash (u-boot 1.1.3 on an Intel > PC28F128P30). > > We have seen that during soft reboot (e.g. reboot ?f command issued > from the shell) the function ?cfi_intelext_reset? is called before > machine reboot is triggered by means of the davinci watchdog > (davinci_watchdog_reset function call), and this works fine. > > Instead, if we configure the watchdog to reboot the board on timer > expire (e.g. configuring and triggering watchdog timer with the > davinci_wdt device), the board seems to perform the maximum reset as > expected but it never restarts. > > My understanding of this behavior is that the cfi_intelext_reset > function performs a reset of the intel flash device so that the > flash is found in the right state (array mode, to be used during > boot), so, in the first case after the watchdog triggered reset the > flash is readable by the CPU and boot process is performed > successfully, while in the second one I suppose the flash chip is in > an undetermined state and, after the reset, the boot process fails. > > Does anyone know a reasonable way to override this problem and to > have a clean hardware watchdog triggered reset/reboot of the board? > > I mean we can have a timer based soft watchdog (e.g. softdog) that > calls the flash reset function (cfi?) before to trigger the machine > reset, but this requires some kind of software processing still > available on the board (interrupt handlers, etc.): our environment > is very critical and we cannot rely on any software portion to take > care of software/kernel error conditions, we need to do it in > hardware (possibly without adding an external hardware watchdog to > the board). This sounds to me like a u-boot problem. The bootloader should make sure the flash is in a usable state before booting. The point of a watchdog is to be able to do a hard reset in case things go wrong. In these situations, you may not be able to do any additional function calls etc. and just need to hard reset. It's the job of the bootloader to be able to reboot in this situation. Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: How to improve image latency
Hi, What is the display frame rate? Thanks, Brijesh Jadav From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Ondrej Pindroch Sent: Thursday, May 21, 2009 5:48 PM To: davinci-linux-open-source Subject: How to improve image latency Hi I have an aplication which is useing CCDC PREVIEWER and V4L2 for output. There is one buffer between CCDC and PREVIEWER (exactly 3 buffers) and for output it is used buffer from V4L2. For now I have latency 160 - 200ms. I have made some mistakes and loosing frames (hudge bunche of errors). Than I have had latency less than 100ms. I have alredy measured time needed for capture and proccessing. It was 5-7ms. >From capture to get frame buffer from V4L2 it take almost 40ms (25fps for PAL) Have you any idea where I get this 120ms of additional latency. Frame rate of sensor is almost 60fps Thanks Ondrej Pindroch SoftHard Technology ltd. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: How to improve image latency
Display frame rate is 25fps it is PAL output. Ondrej Pindroch SoftHard Technology ltd. -Original Message- From: "Jadav, Brijesh R" To: Ondrej Pindroch , davinci-linux-open-source Date: Thu, 21 May 2009 19:05:53 +0530 Subject: RE: How to improve image latency Hi, What is the display frame rate? Thanks, Brijesh Jadav From:davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf OfOndrej Pindroch Sent: Thursday, May 21, 2009 5:48 PM To: davinci-linux-open-source Subject: How to improve image latency Hi I have an aplication which is useing CCDC PREVIEWER and V4L2 for output. There is one buffer between CCDC and PREVIEWER (exactly 3 buffers) and for output it is used buffer from V4L2. For now I have latency 160 - 200ms. I have made some mistakes and loosing frames (hudge bunche of errors). Than I have had latency less than 100ms. I have alredy measured time needed for capture and proccessing. It was 5-7ms. >From capture to get frame buffer from V4L2 it take almost 40ms (25fps for PAL) Have you any idea where I get this 120ms of additional latency. Frame rate of sensor is almost 60fps Thanks Ondrej Pindroch SoftHard Technology ltd. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 0/4] ARM: DaVinci: DM646x Video: DM646x display driver
On Thursday 21 May 2009 08:12:57 chaithrika wrote: > Hi All, > > Do you have any review comments on this patch set? Reviewed-by: Hans Verkuil I'm happy with these patches! There is one thing that can be improved, though. It is really an enhancement and does not prevent this from being merged. Currently the isr routine refuses to switch to the next frame if the dma queue is empty. However, I see no reason for this: it should always go to that frame regardless and keep that until new frames are queued. I've made this change in the (very old) driver I use at work, but this should become standard behavior. Regards, Hans > > Regards, > Chaithrika > > > -Original Message- > > From: Chaithrika U S [mailto:chaithr...@ti.com] > > Sent: Friday, May 08, 2009 6:55 PM > > To: linux-me...@vger.kernel.org > > Cc: davinci-linux-open-source@linux.davincidsp.com; Manjunath Hadli; > > Brijesh Jadav; Chaithrika U S > > Subject: [PATCH v3 0/4] ARM: DaVinci: DM646x Video: DM646x display > > driver > > > > Display driver for TI DM646x EVM > > > > Signed-off-by: Manjunath Hadli > > Signed-off-by: Brijesh Jadav > > Signed-off-by: Chaithrika U S > > > > These patches add the display driver support for TI DM646x EVM. > > This patch set has been tested for basic display functionality for > > Composite and Component outputs. > > > > This patch set consists of the updates based on the review comments by > > Hans Verkuil. > > > > Patch 1: Display device platform and board setup > > Patch 2: VPIF driver > > Patch 3: DM646x display driver > > Patch 4: Makefile and config files modifications for Display > > > > Some of the features like the HBI/VBI support are not yet implemented. > > Also there are some known issues in the code implementation like > > fine tuning to be done to TRY_FMT ioctl.The USERPTR usage has not been > > tested extensively. > > > > -Chaithrika > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hans Verkuil - video4linux developer - sponsored by TANDBERG ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2] net-next-2.6: TI DaVinci EMAC driver
David Miller writes: > From: Chaithrika U S > Date: Mon, 18 May 2009 07:34:32 -0400 > >> Add support for TI DaVinci EMAC driver. >> >> TI DaVinci Ethernet Media Access Controller module is based upon >> TI CPPI 3.0 DMA engine and supports 10/100 Mbps on all and Gigabit modes on >> some TI devices. It supports MII/RMII and has up to 8Kbytes of internal >> descriptor memory. This driver has been working on several TI devices >> including >> DM644x, DM646x and DA830 platforms. The specs of this device are available >> at: >> http://www.ti.com/litv/pdf/sprue24a >> >> Signed-off-by: Anant Gole >> Signed-off-by: Kevin Hilman >> Signed-off-by: Chaithrika U S > > Applied, thanks. > Chaithrika, Nice work! Thanks for taking this driver all the way upstream. It will now be in 2.6.31. Hopefully, my platform updates will be accepted for the .31 merge window as well. Thanks! Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
14 pins JTAG cable
Dear All: Can you help me to find the JTAG solution? my questions is followed. 1. which vendor and how can I get the 14 pins JTAG cable other than TI? 2. Can I download the Linux based CCStudio? 3. Can the CCStudia run well on Fedora 10? 4. which documentation address this issue? Thanks, J.J.___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] RFC: ARM: DaVinci: ASoc use iram to buffer sound
Rajashekhara, Sudhakar wrote: > Troy, > > I tried this patch on DM644x EVM and following are my observations: > > 1. Playback works fine. > 2. Record has some issues. Recorded stream has Loud volume on > the right side, and on the left, volume is very low. > 3. Loopback (arecord -f cd | aplay -f cd) has some issues. > Audio is bit noisy here. I think if arecord issues are fixed, > this may go away. > > On DM355, though arecord and aplay work fine independently. But > once loopback is run, arecord records data only on one side. > Loopback is noisy with intermittent overrun/underrun messages both > on DM355 and DM644x EVMs. > Thanks for testing... Can you post the overrun/underrun messages. Which codec does the DM355 use. Is it AIC33 like DM6446 EVM? Thanks Troy ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] RFC: ARM: DaVinci: ASoc use iram to buffer sound
chaithrika wrote: > Troy, > > I tried this patch on DM355 EVM. It works fine. > > Thanks, > Chaithrika > Thanks. Are you seeing the same issues as Sudhakar? Message repeated below. _ Troy, I tried this patch on DM644x EVM and following are my observations: 1. Playback works fine. 2. Record has some issues. Recorded stream has Loud volume on the right side, and on the left, volume is very low. 3. Loopback (arecord -f cd | aplay -f cd) has some issues. Audio is bit noisy here. I think if arecord issues are fixed, this may go away. On DM355, though arecord and aplay work fine independently. But once loopback is run, arecord records data only on one side. Loopback is noisy with intermittent overrun/underrun messages both on DM355 and DM644x EVMs. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: 14 pins JTAG cable
On Thu, 2009-05-21 at 11:09 -0700, elbert shiang wrote: > Dear All: > > Can you help me to find the JTAG solution? > my questions is followed. > > 1. which vendor and how can I get the 14 pins JTAG cable other than > TI? > 2. Can I download the Linux based CCStudio? > 3. Can the CCStudia run well on Fedora 10? > 4. which documentation address this issue? > > Thanks, > J.J. > You can probably get the JTAG cable somewhere at Spectrum Digital's web site at http://www.spectrumdigital.com/ Here is a link to an EVAL copy. I'm not sure how recent it is. Anyway, if you are buying stuff from Spectrum, I'm sure you can get a copy from them (or TI). http://support.spectrumdigital.com/ccs33/Release-30328/setupCCSPlatinum_v30328.zip CCS Studio only runs on Windows. Regards, Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: 14 pins JTAG cable
On Thursday 21 May 2009, Steve Chen wrote: > CCS Studio only runs on Windows. Although ... CCS4 is using Eclipse, and surely one of the main reasons to do that is to (eventually) get rid of that annoying restriction? ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 0/3] davinci: add SRAM allocator
Provide a generic SRAM allocator using genalloc, and vaguely modeled after what AVR32 uses. This is the last of the davinci updates for the 2.6.31 merge window and applies on top of the previous 3 series: - [PATCH 0/2] davinci GPIO fixes for next merge window - [PATCH 00/11] davinci: more SoCs and platform updates - [PATCH 00/16] davinci: generalize common SoC infrastructure Upon review/acceptance, I'll merge all of them into a single branch for pulling. David Brownell (3): davinci: remove remnants of IRAM allocator davinci: soc-specific SRAM setup davinci: add SRAM allocator arch/arm/Kconfig|1 + arch/arm/mach-davinci/Makefile |2 +- arch/arm/mach-davinci/dm355.c |9 +++ arch/arm/mach-davinci/dm644x.c |9 +++ arch/arm/mach-davinci/dm646x.c |9 +++ arch/arm/mach-davinci/include/mach/common.h |6 ++ arch/arm/mach-davinci/include/mach/edma.h |4 -- arch/arm/mach-davinci/include/mach/memory.h |1 - arch/arm/mach-davinci/include/mach/sram.h | 27 ++ arch/arm/mach-davinci/sram.c| 74 +++ 10 files changed, 136 insertions(+), 6 deletions(-) create mode 100644 arch/arm/mach-davinci/include/mach/sram.h create mode 100644 arch/arm/mach-davinci/sram.c ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 3/3] davinci: add SRAM allocator
From: David Brownell
Provide a generic SRAM allocator using genalloc, and vaguely
modeled after what AVR32 uses. This builds on top of the
static CPU mapping set up in the previous patch, and returns
DMA mappings as requested (if possible).
Compared to its OMAP cousin, there's no current support for
(currently non-existent) DaVinci power management code running
in SRAM; and this has ways to deallocate, instead of being
allocate-only.
The initial user of this should probably be the audio code,
because EDMA from DDR is subject to various dropouts on at
least DM355 and DM6446 chips.
Signed-off-by: David Brownell
Signed-off-by: Kevin Hilman
---
arch/arm/Kconfig |1 +
arch/arm/mach-davinci/Makefile|2 +-
arch/arm/mach-davinci/include/mach/sram.h | 27 ++
arch/arm/mach-davinci/sram.c | 74 +
4 files changed, 103 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-davinci/include/mach/sram.h
create mode 100644 arch/arm/mach-davinci/sram.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e60ec54..ffa8427 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -586,6 +586,7 @@ config ARCH_DAVINCI
select ZONE_DMA
select HAVE_IDE
select COMMON_CLKDEV
+ select GENERIC_ALLOCATOR
help
Support for TI's DaVinci platform.
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 5b62d8a..059ab78 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -5,7 +5,7 @@
# Common objects
obj-y := time.o clock.o serial.o io.o psc.o \
- gpio.o devices.o dma.o usb.o common.o
+ gpio.o devices.o dma.o usb.o common.o sram.o
obj-$(CONFIG_DAVINCI_MUX) += mux.o
diff --git a/arch/arm/mach-davinci/include/mach/sram.h
b/arch/arm/mach-davinci/include/mach/sram.h
new file mode 100644
index 000..111f7cc
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/sram.h
@@ -0,0 +1,27 @@
+/*
+ * mach/sram.h - DaVinci simple SRAM allocator
+ *
+ * Copyright (C) 2009 David Brownell
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __MACH_SRAM_H
+#define __MACH_SRAM_H
+
+/* ARBITRARY: SRAM allocations are multiples of this 2^N size */
+#define SRAM_GRANULARITY 512
+
+/*
+ * SRAM allocations return a CPU virtual address, or NULL on error.
+ * If a DMA address is requested and the SRAM supports DMA, its
+ * mapped address is also returned.
+ *
+ * Errors include SRAM memory not being available, and requesting
+ * DMA mapped SRAM on systems which don't allow that.
+ */
+extern void *sram_alloc(size_t len, dma_addr_t *dma);
+extern void sram_free(void *addr, size_t len);
+
+#endif /* __MACH_SRAM_H */
diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
new file mode 100644
index 000..0309e72
--- /dev/null
+++ b/arch/arm/mach-davinci/sram.c
@@ -0,0 +1,74 @@
+/*
+ * mach-davinci/sram.c - DaVinci simple SRAM allocator
+ *
+ * Copyright (C) 2009 David Brownell
+ *
+ * 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.
+ */
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+
+static struct gen_pool *sram_pool;
+
+void *sram_alloc(size_t len, dma_addr_t *dma)
+{
+ unsigned long vaddr;
+ dma_addr_t dma_base = davinci_get_soc_info()->sram_dma;
+
+ if (dma)
+ *dma = 0;
+ if (!sram_pool || (dma && !dma_base))
+ return NULL;
+
+ vaddr = gen_pool_alloc(sram_pool, len);
+ if (!vaddr)
+ return NULL;
+
+ if (dma)
+ *dma = dma_base + (vaddr - SRAM_VIRT);
+ return (void *)vaddr;
+
+}
+EXPORT_SYMBOL(sram_alloc);
+
+void sram_free(void *addr, size_t len)
+{
+ gen_pool_free(sram_pool, (unsigned long) addr, len);
+}
+EXPORT_SYMBOL(sram_free);
+
+
+/*
+ * REVISIT This supports CPU and DMA access to/from SRAM, but it
+ * doesn't (yet?) support some other notable uses of SRAM: as TCM
+ * for data and/or instructions; and holding code needed to enter
+ * and exit suspend states (while DRAM can't be used).
+ */
+static int __init sram_init(void)
+{
+ unsigned len = davinci_get_soc_info()->sram_len;
+ int status = 0;
+
+ if (len) {
+ len = min(len, SRAM_SIZE);
+ sram_pool = gen_pool_create(ilog2(SRAM_GRANULARITY), -1);
+ if (!sram_pool)
+ status = -ENOMEM;
+ }
+ if (sram_pool)
+ status = gen_pool_add(sram_pool, SRAM_VIRT, len, -1);
+
[PATCH 2/3] davinci: soc-specific SRAM setup
From: David Brownell
Package on-chip SRAM. It's always accessible from the ARM, so
set up a standardized virtual address mapping into a 128 KiB
area that's reserved for platform use.
In some cases (dm6467) the physical addresses used for EDMA are
not the same as the ones used by the ARM ... so record that info
separately in the SOC data, for chips (unlike the OMAP-L137)
where SRAM may be used with EDMA.
Other blocks of SRAM, such as the ETB buffer or DSP L1/L2 RAM,
may be unused/available on some system. They are ignored here.
Signed-off-by: David Brownell
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/dm355.c |9 +
arch/arm/mach-davinci/dm644x.c |9 +
arch/arm/mach-davinci/dm646x.c |9 +
arch/arm/mach-davinci/include/mach/common.h |6 ++
4 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 602eca0..efc7b5a 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -613,6 +613,13 @@ static struct map_desc dm355_io_desc[] = {
.length = IO_SIZE,
.type = MT_DEVICE
},
+ {
+ .virtual= SRAM_VIRT,
+ .pfn= __phys_to_pfn(0x0001),
+ .length = SZ_32K,
+ /* MT_MEMORY_NONCACHED requires supersection alignment */
+ .type = MT_DEVICE,
+ },
};
/* Contents of JTAG ID register used to identify exact cpu type */
@@ -702,6 +709,8 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
.gpio_num = 104,
.gpio_irq = IRQ_DM355_GPIOBNK0,
.serial_dev = &dm355_serial_device,
+ .sram_dma = 0x0001,
+ .sram_len = SZ_32K,
};
void __init dm355_init(void)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index ee71e6a..b3d1447 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -539,6 +539,13 @@ static struct map_desc dm644x_io_desc[] = {
.length = IO_SIZE,
.type = MT_DEVICE
},
+ {
+ .virtual= SRAM_VIRT,
+ .pfn= __phys_to_pfn(0x8000),
+ .length = SZ_16K,
+ /* MT_MEMORY_NONCACHED requires supersection alignment */
+ .type = MT_DEVICE,
+ },
};
/* Contents of JTAG ID register used to identify exact cpu type */
@@ -629,6 +636,8 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
.gpio_irq = IRQ_GPIOBNK0,
.serial_dev = &dm644x_serial_device,
.emac_pdata = &dm644x_emac_pdata,
+ .sram_dma = 0x8000,
+ .sram_len = SZ_16K,
};
void __init dm644x_init(void)
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 3d8996b..6b65d1b 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -518,6 +518,13 @@ static struct map_desc dm646x_io_desc[] = {
.length = IO_SIZE,
.type = MT_DEVICE
},
+ {
+ .virtual= SRAM_VIRT,
+ .pfn= __phys_to_pfn(0x0001),
+ .length = SZ_32K,
+ /* MT_MEMORY_NONCACHED requires supersection alignment */
+ .type = MT_DEVICE,
+ },
};
/* Contents of JTAG ID register used to identify exact cpu type */
@@ -608,6 +615,8 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
.gpio_irq = IRQ_DM646X_GPIOBNK0,
.serial_dev = &dm646x_serial_device,
.emac_pdata = &dm646x_emac_pdata,
+ .sram_dma = 0x1001,
+ .sram_len = SZ_32K,
};
void __init dm646x_init(void)
diff --git a/arch/arm/mach-davinci/include/mach/common.h
b/arch/arm/mach-davinci/include/mach/common.h
index 0a237a8..352f365 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -66,9 +66,15 @@ struct davinci_soc_info {
unsignedgpio_irq;
struct platform_device *serial_dev;
struct emac_platform_data *emac_pdata;
+ dma_addr_t sram_dma;
+ unsignedsram_len;
};
extern struct davinci_soc_info *davinci_get_soc_info(void);
extern void davinci_common_init(struct davinci_soc_info *soc_info);
+/* standard place to map on-chip SRAMs; they *may* support DMA */
+#define SRAM_VIRT 0xfffe
+#define SRAM_SIZE SZ_128K
+
#endif /* __ARCH_ARM_MACH_DAVINCI_COMMON_H */
--
1.6.2.2
___
[PATCH 1/3] davinci: remove remnants of IRAM allocator
From: David Brownell
Remove remnants of dm6446-specific SRAM allocator, as preparation for
a more generic replacement.
Signed-off-by: David Brownell
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/include/mach/edma.h |4
arch/arm/mach-davinci/include/mach/memory.h |1 -
2 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/edma.h
b/arch/arm/mach-davinci/include/mach/edma.h
index f6fc539..24a3792 100644
--- a/arch/arm/mach-davinci/include/mach/edma.h
+++ b/arch/arm/mach-davinci/include/mach/edma.h
@@ -208,10 +208,6 @@ void edma_clear_event(unsigned channel);
void edma_pause(unsigned channel);
void edma_resume(unsigned channel);
-/* UNRELATED TO DMA */
-int davinci_alloc_iram(unsigned size);
-void davinci_free_iram(unsigned addr, unsigned size);
-
/* platform_data for EDMA driver */
struct edma_soc_info {
diff --git a/arch/arm/mach-davinci/include/mach/memory.h
b/arch/arm/mach-davinci/include/mach/memory.h
index 86c25c7..c712c7c 100644
--- a/arch/arm/mach-davinci/include/mach/memory.h
+++ b/arch/arm/mach-davinci/include/mach/memory.h
@@ -21,7 +21,6 @@
* Definitions
**/
#define DAVINCI_DDR_BASE0x8000
-#define DAVINCI_IRAM_BASE 0x8000 /* ARM Internal RAM */
#define PHYS_OFFSET DAVINCI_DDR_BASE
--
1.6.2.2
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] DaVinci SPI Driver
s-paul...@ti.com writes: > The patch adds support for DaVinci SPI driver. > It was tested on the DM355 using the at25 EEPROM driver. > > Signed-off-by: Sandeep Paulraj [...] > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > index 83a185d..565967b 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -77,6 +77,23 @@ config SPI_AU1550 > This driver can also be built as a module. If so, the module > will be called au1550_spi. > > +config SPI_DAVINCI > + tristate "SPI controller driver for DaVinci SoC" > + depends on SPI_MASTER && ARCH_DAVINCI > + select SPI_BITBANG > + default y > + help > + SPI master controller for DaVinci SPI modules. Currently, > + SPI is only officially supported for DM646x, DM355, DM365 and DA8xx. > + > +config SPI_INTERRUPT > + bool "Set DaVinci SPI to Interrupt mode" > + depends on SPI_DAVINCI > + default n > + help > +Select this option to set DaVinci SPI to Interrupt mode, deselect > +to put in polling mode (default) > + I don't we need yet another Kconfig option for this. Especially because the driver implements it as a run-time option, this Kconfig option appears to be specific to board code. Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/2] ARM: DaVinci: DM646x PCIHOST: Core files modifications for PCI PINMUX and I/O
Hemant Pedanekar writes: > The changes mainly target two areas: 1) Provide clock structure, setting up > PCI > PINMUX and perform board specific fix-ups for PCI Host core to begin > configuration/enumeraion and 2) Provide PCI IO access through in/outx() and > ioread/iowritex(). > > The arm-kernel configuration is updated to support PCI Bus for DM646x builds. > > In addition, I/O mapping macros are moved inside hardware.h to avoid the need > for inclusion of io.h in assembly files which results in assembler errors for > PCI I/O functions, as well as serial.h, which results in unresolved symbols > for > PCI I/O functions (in uncompress code). > > Signed-off-by: Hemant Pedanekar > --- > arch/arm/Kconfig |2 +- > arch/arm/mach-davinci/Kconfig|1 + > arch/arm/mach-davinci/Makefile |6 + > arch/arm/mach-davinci/board-dm646x-evm.c | 82 > arch/arm/mach-davinci/dm646x.c | 22 ++- > arch/arm/mach-davinci/include/mach/dm646x.h | 33 +++- > arch/arm/mach-davinci/include/mach/entry-macro.S |2 +- > arch/arm/mach-davinci/include/mach/hardware.h| 21 ++ > arch/arm/mach-davinci/include/mach/io.h | 237 > -- > arch/arm/mach-davinci/include/mach/mux.h | 10 +- > arch/arm/mach-davinci/include/mach/serial.h |2 +- > arch/arm/mach-davinci/include/mach/vmalloc.h |2 +- > 12 files changed, 390 insertions(+), 30 deletions(-) > Just some general comments without digging too much into the PCI specific parts... You're doing lots of things in this patch, it should be split break it up into smaller pieces with better descriptions. You could break out some cleanup/fixup patches, and the clock/mux defines into separate patches, the PCI accessor functions etc. etc. The header rework should be a separate patch with a clearer description of the problem. If the problem is with incluing from assembly files, then there's probably a better way to do this like using #ifdef __ASSEMBLER__. Also, is PCI going to be specific to the dm646x forever? Something tells me no. Some of the PCI stuff you put into dm646x.h should probably be in a more generic header like or something. > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index bf935b0..3324c02 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -776,7 +776,7 @@ config ISA_DMA_API > bool > > config PCI > - bool "PCI support" if ARCH_INTEGRATOR_AP || ARCH_VERSATILE_PB || > ARCH_IXP4XX || ARCH_KS8695 || MACH_ARMCORE > + bool "PCI support" if ARCH_INTEGRATOR_AP || ARCH_VERSATILE_PB || > ARCH_IXP4XX || ARCH_KS8695 || MACH_ARMCORE || ARCH_DAVINCI_DM646x > help > Find out whether you have a PCI motherboard. PCI is the name of a > bus system, i.e. the way the CPU talks to the other stuff inside > diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig > index c460615..2ce0ffd 100644 > --- a/arch/arm/mach-davinci/Kconfig > +++ b/arch/arm/mach-davinci/Kconfig > @@ -17,6 +17,7 @@ config ARCH_DAVINCI_DM644x > config ARCH_DAVINCI_DM646x > bool "DaVinci 646x based system" > select AINTC > + select DAVINCI_MUX if PCI > > config ARCH_DAVINCI_DM355 > bool "DaVinci 355 based system" > diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile > old mode 100644 > new mode 100755 > index 6da7b63..7323c83 > --- a/arch/arm/mach-davinci/Makefile > +++ b/arch/arm/mach-davinci/Makefile > @@ -9,12 +9,18 @@ obj-y := time.o clock.o serial.o io.o > psc.o \ > sram.o > > obj-$(CONFIG_DAVINCI_MUX)+= mux.o > +obj-$(CONFIG_PCI)+= pci-generic.o You add files to the Makefile which are not added in this patch. This will break bisecting. > # Chip specific > obj-$(CONFIG_ARCH_DAVINCI_DM644x) += dm644x.o > obj-$(CONFIG_ARCH_DAVINCI_DM646x) += dm646x.o > obj-$(CONFIG_ARCH_DAVINCI_DM355)+= dm355.o > > +# PCI - Chip specific > +ifeq ($(CONFIG_PCI), y) > +obj-$(CONFIG_ARCH_DAVINCI_DM646x)+= pci-dm6467.o > +endif > + Ditto. [...] Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 3/3] davinci: add SRAM allocator
Just a quick "can we talk through this patch a bit" note... I _think_ there are existing codecs on some DaVinci platforms (e.g. DM365) that are already using this SRAM memory. The current [easy] solution to their use case was to keep this memory out of the kernel, and simply give it to CMEM to manage (via its insmod params) and the codecs indirectly allocate from CMEM. If you're unfamiliar with CMEM, there is an overview here: http://tiexpressdsp.com/index.php?title=CMEM_Overview I'm not the expert, I only want to encourage further discussion! But I'm a little concerned about a resource collision if this SRAM allocator gets pushed, and more than one client thinks they own that resource. Chris > -Original Message- > From: davinci-linux-open-source-boun...@linux.davincidsp.com > [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com > ] On Behalf Of Kevin Hilman > Sent: Thursday, May 21, 2009 2:47 PM > To: linux-arm-ker...@lists.arm.linux.org.uk > Cc: davinci-linux-open-source@linux.davincidsp.com; David Brownell > Subject: [PATCH 3/3] davinci: add SRAM allocator > > From: David Brownell > > Provide a generic SRAM allocator using genalloc, and vaguely > modeled after what AVR32 uses. This builds on top of the > static CPU mapping set up in the previous patch, and returns > DMA mappings as requested (if possible). > > Compared to its OMAP cousin, there's no current support for > (currently non-existent) DaVinci power management code running > in SRAM; and this has ways to deallocate, instead of being > allocate-only. > > The initial user of this should probably be the audio code, > because EDMA from DDR is subject to various dropouts on at > least DM355 and DM6446 chips. > > Signed-off-by: David Brownell > Signed-off-by: Kevin Hilman > --- > arch/arm/Kconfig |1 + > arch/arm/mach-davinci/Makefile|2 +- > arch/arm/mach-davinci/include/mach/sram.h | 27 ++ > arch/arm/mach-davinci/sram.c | 74 > + > 4 files changed, 103 insertions(+), 1 deletions(-) > create mode 100644 arch/arm/mach-davinci/include/mach/sram.h > create mode 100644 arch/arm/mach-davinci/sram.c > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index e60ec54..ffa8427 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -586,6 +586,7 @@ config ARCH_DAVINCI > select ZONE_DMA > select HAVE_IDE > select COMMON_CLKDEV > + select GENERIC_ALLOCATOR > help > Support for TI's DaVinci platform. > > diff --git a/arch/arm/mach-davinci/Makefile > b/arch/arm/mach-davinci/Makefile > index 5b62d8a..059ab78 100644 > --- a/arch/arm/mach-davinci/Makefile > +++ b/arch/arm/mach-davinci/Makefile > @@ -5,7 +5,7 @@ > > # Common objects > obj-y:= time.o clock.o serial.o io.o psc.o \ > -gpio.o devices.o dma.o usb.o common.o > +gpio.o devices.o dma.o usb.o common.o sram.o > > obj-$(CONFIG_DAVINCI_MUX)+= mux.o > > diff --git a/arch/arm/mach-davinci/include/mach/sram.h > b/arch/arm/mach-davinci/include/mach/sram.h > new file mode 100644 > index 000..111f7cc > --- /dev/null > +++ b/arch/arm/mach-davinci/include/mach/sram.h > @@ -0,0 +1,27 @@ > +/* > + * mach/sram.h - DaVinci simple SRAM allocator > + * > + * Copyright (C) 2009 David Brownell > + * > + * This program is free software; you can redistribute it > and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > +#ifndef __MACH_SRAM_H > +#define __MACH_SRAM_H > + > +/* ARBITRARY: SRAM allocations are multiples of this 2^N size */ > +#define SRAM_GRANULARITY 512 > + > +/* > + * SRAM allocations return a CPU virtual address, or NULL on error. > + * If a DMA address is requested and the SRAM supports DMA, its > + * mapped address is also returned. > + * > + * Errors include SRAM memory not being available, and requesting > + * DMA mapped SRAM on systems which don't allow that. > + */ > +extern void *sram_alloc(size_t len, dma_addr_t *dma); > +extern void sram_free(void *addr, size_t len); > + > +#endif /* __MACH_SRAM_H */ > diff --git a/arch/arm/mach-davinci/sram.c > b/arch/arm/mach-davinci/sram.c > new file mode 100644 > index 000..0309e72 > --- /dev/null > +++ b/arch/arm/mach-davinci/sram.c > @@ -0,0 +1,74 @@ > +/* > + * mach-davinci/sram.c - DaVinci simple SRAM allocator > + * > + * Copyright (C) 2009 David Brownell > + * > + * 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. > + */ > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > + > +static struct gen_pool *sram_pool; > + > +v
Re: [PATCH 3/3] davinci: add SRAM allocator
On Thursday 21 May 2009, Ring, Chris wrote: > I _think_ there are existing codecs on some DaVinci > platforms (e.g. DM365) that are already using this > SRAM memory. The current [easy] solution to their use > case was to keep this memory out of the kernel, and > simply give it to CMEM to manage (via its insmod > params) and the codecs indirectly allocate from CMEM. If you can find out the answer, that'd be good. If that's a real issue, it'll be trivial to add a "reserve this memory" call ... but nobody had brought up that issue in any previous incarnation of this code, which is why it's not there. IMO that could wait for DM365 support though. A somewhat similar use: maybe you're using a JTAG debugger like OpenOCD, and don't want to have to back up the data all the time. So you might want to just reserve some of it for those purposes. - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] RFC: ARM: DaVinci: ASoc use iram to buffer sound
> -Original Message- > From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] > Sent: Friday, May 22, 2009 12:15 AM > To: chaithrika > Cc: davinci-linux-open-source@linux.davincidsp.com; Rajashekhara, > Sudhakar > Subject: Re: [PATCH] RFC: ARM: DaVinci: ASoc use iram to buffer sound > > chaithrika wrote: > > Troy, > > > > I tried this patch on DM355 EVM. It works fine. > > > > Thanks, > > Chaithrika > > > > Thanks. Are you seeing the same issues as Sudhakar? Yes, I also observed the same issue with loopback. After loopback, arecord is not functioning properly. > > Message repeated below. > _ > Troy, > > I tried this patch on DM644x EVM and following are my observations: > > 1. Playback works fine. > 2. Record has some issues. Recorded stream has Loud volume on > the right side, and on the left, volume is very low. > 3. Loopback (arecord -f cd | aplay -f cd) has some issues. > Audio is bit noisy here. I think if arecord issues are fixed, > this may go away. > > On DM355, though arecord and aplay work fine independently. But > once loopback is run, arecord records data only on one side. > Loopback is noisy with intermittent overrun/underrun messages both > on DM355 and DM644x EVMs. > > Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v3 0/4] ARM: DaVinci: DM646x Video: DM646x display driver
Hans, > -Original Message- > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > Sent: Thursday, May 21, 2009 7:45 PM > To: chaithrika > Cc: linux-me...@vger.kernel.org; davinci-linux-open- > sou...@linux.davincidsp.com; 'Manjunath Hadli'; 'Brijesh Jadav' > Subject: Re: [PATCH v3 0/4] ARM: DaVinci: DM646x Video: DM646x display > driver > > On Thursday 21 May 2009 08:12:57 chaithrika wrote: > > Hi All, > > > > Do you have any review comments on this patch set? > > Reviewed-by: Hans Verkuil > > I'm happy with these patches! > Thanks! > There is one thing that can be improved, though. It is really an > enhancement > and does not prevent this from being merged. > > Currently the isr routine refuses to switch to the next frame if the > dma > queue is empty. However, I see no reason for this: it should always go > to > that frame regardless and keep that until new frames are queued. I've > made > this change in the (very old) driver I use at work, but this should > become > standard behavior. > OK. I will look into this. Thanks, Chaithrika > Regards, > > Hans > > > > > Regards, > > Chaithrika > > > > > -Original Message- > > > From: Chaithrika U S [mailto:chaithr...@ti.com] > > > Sent: Friday, May 08, 2009 6:55 PM > > > To: linux-me...@vger.kernel.org > > > Cc: davinci-linux-open-source@linux.davincidsp.com; Manjunath > Hadli; > > > Brijesh Jadav; Chaithrika U S > > > Subject: [PATCH v3 0/4] ARM: DaVinci: DM646x Video: DM646x display > > > driver > > > > > > Display driver for TI DM646x EVM > > > > > > Signed-off-by: Manjunath Hadli > > > Signed-off-by: Brijesh Jadav > > > Signed-off-by: Chaithrika U S > > > > > > These patches add the display driver support for TI DM646x EVM. > > > This patch set has been tested for basic display functionality for > > > Composite and Component outputs. > > > > > > This patch set consists of the updates based on the review comments > by > > > Hans Verkuil. > > > > > > Patch 1: Display device platform and board setup > > > Patch 2: VPIF driver > > > Patch 3: DM646x display driver > > > Patch 4: Makefile and config files modifications for Display > > > > > > Some of the features like the HBI/VBI support are not yet > implemented. > > > Also there are some known issues in the code implementation like > > > fine tuning to be done to TRY_FMT ioctl.The USERPTR usage has not > been > > > tested extensively. > > > > > > -Chaithrika > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux- > media" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > Hans Verkuil - video4linux developer - sponsored by TANDBERG ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] RFC: ARM: DaVinci: ASoc use iram to buffer sound
> > Rajashekhara, Sudhakar wrote: > > Troy, > > > > I tried this patch on DM644x EVM and following are my observations: > > > > 1. Playback works fine. > > 2. Record has some issues. Recorded stream has Loud volume on > > the right side, and on the left, volume is very low. > > 3. Loopback (arecord -f cd | aplay -f cd) has some issues. > > Audio is bit noisy here. I think if arecord issues are fixed, > > this may go away. > > > > On DM355, though arecord and aplay work fine independently. But > > once loopback is run, arecord records data only on one side. > > Loopback is noisy with intermittent overrun/underrun messages both > > on DM355 and DM644x EVMs. > > > > Thanks for testing... Can you post the overrun/underrun messages. # arecord -f cd | aplay -f cd Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo underrun!!! (at least 0.372 ms long) underrun!!! (at least 0.146 ms long) underrun!!! (at least 0.147 ms long) underrun!!! (at least 0.153 ms long) underrun!!! (at least 0.153 ms long) underrun!!! (at least 0.159 ms long) underrun!!! (at least 0.149 ms long) underrun!!! (at least 0.153 ms long) underrun!!! (at least 0.153 ms long) underrun!!! (at least 0.236 ms long) underrun!!! (at least 0.147 ms long) underrun!!! (at least 0.180 ms long) underrun!!! (at least 0.159 ms long) underrun!!! (at least 0.154 ms long) underrun!!! (at least 0.154 ms long) underrun!!! (at least 0.149 ms long) underrun!!! (at least 0.145 ms long) underrun!!! (at least 0.149 ms long) underrun!!! (at least 0.176 ms long) Aborted by signal Interrupt... Aborted by signal Interrupt... # After I stop it, if I re-run the same command as above, I am not getting these messages. > > Which codec does the DM355 use. Is it AIC33 like DM6446 EVM? > Yes, DM355 is using AIC33. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] RFC: ARM: DaVinci: ASoc use iram to buffer sound
Rajashekhara, Sudhakar wrote: >> Rajashekhara, Sudhakar wrote: >>> Troy, >>> >>> I tried this patch on DM644x EVM and following are my observations: >>> >>> 1. Playback works fine. >>> 2. Record has some issues. Recorded stream has Loud volume on >>> the right side, and on the left, volume is very low. >>> 3. Loopback (arecord -f cd | aplay -f cd) has some issues. >>> Audio is bit noisy here. I think if arecord issues are fixed, >>> this may go away. >>> >>> On DM355, though arecord and aplay work fine independently. But >>> once loopback is run, arecord records data only on one side. >>> Loopback is noisy with intermittent overrun/underrun messages both >>> on DM355 and DM644x EVMs. >>> >> Thanks for testing... Can you post the overrun/underrun messages. > > # arecord -f cd | aplay -f cd > Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo > Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo > underrun!!! (at least 0.372 ms long) > underrun!!! (at least 0.146 ms long) > underrun!!! (at least 0.147 ms long) > underrun!!! (at least 0.153 ms long) > underrun!!! (at least 0.153 ms long) > underrun!!! (at least 0.159 ms long) > underrun!!! (at least 0.149 ms long) > underrun!!! (at least 0.153 ms long) > underrun!!! (at least 0.153 ms long) > underrun!!! (at least 0.236 ms long) > underrun!!! (at least 0.147 ms long) > underrun!!! (at least 0.180 ms long) > underrun!!! (at least 0.159 ms long) > underrun!!! (at least 0.154 ms long) > underrun!!! (at least 0.154 ms long) > underrun!!! (at least 0.149 ms long) > underrun!!! (at least 0.145 ms long) > underrun!!! (at least 0.149 ms long) > underrun!!! (at least 0.176 ms long) > Aborted by signal Interrupt... > Aborted by signal Interrupt... > # > > After I stop it, if I re-run the same command as above, I am not > getting these messages. > >> Which codec does the DM355 use. Is it AIC33 like DM6446 EVM? >> > > Yes, DM355 is using AIC33. > > Regards, Sudhakar > > > Hmm do you know if the aic33 is initialized at 44100, or is alsa arecord converting the input from 48000 to 44100 and then aplay converting the opposite direction. Troy ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Danvinci watchdog + Intel flash problem
From: Alberto Navatta Sent: Thursday, May 21, 2009 6:42 PM > > Hi Kevin, > > in general you are right, but in this case is the execution of the > bootloader to fail and there's no way to address the problem after > reboot. > > I think there's a problem in the logic implemented in the cfi flash > driver: > some driver operations don't leave the chip in read array mode and > this, > according to my point of view, causes the malfunction. Alberto, as Onkar suggested, looks like this problem should have been fixed in board design. Are you facing this on DM644x EVM? Looking at the schematics here: http://c6000.spectrumdigital.com/davincievm/revf/files/DaVinciEVM_Schematic.pdf, the RST# of NOR flash is connected to RESETn of the DM644x. Watchdog reset should drive the RESETn low, which should put the NOR flash in read array mode. So, irrespective of what state the NOR flash was in at the time of watchdog reset, it should be in read array mode by the time ROM bootloader gets to reading it. Thanks, Sekhar > > If a clean reboot procedure is executed, a reboot notifier routine is > executed that puts the chip in the right state > In case of watchdog reboot the chip performs a maximum reset without > executing any software cleanup procedure and a subsequent boot fails > due to > impossibility to execute the bootloader from the flash (flash in an > inconsistent state). > > In fact, walking into the driver's code I've seen that: > * when the kernel loads the flash driver several operations are > performed > (chip probe, geometry detection, etc.), most of them put the chip in > ready > array mode after completion. > * when the NOR Flash partitions are given to the driver it configures > the > partitions to be write protected or unprotected, this operation > doesn't seem > to leave the chip in read array mode when completed. > * if later a read is issued on the device, the chip is correctly > configured > in read array mode > > In my case I was using the NOR flash to host the bootloader and the > kernel > while root file system stays on NFS so there was no read operation > after > partition configuration so: > * when a clean reboot was issued on the board everything went fine, > the > reboot notifier of the driver is called, the chip is configured in > read > array mode and reboot is successful > * when the watchdog expires the chip remains in the last state > asserted > during boot (FL_STATUS) so reset is successful but bootloader load > fails > because chip is not readable. > > I just changed the following lines in the cfi_cmdset_0001.c to go > always to > the ready state when an operation is completed (put_chip function): > diff -r1.1.1.1 cfi_cmdset_0001.c > 853d852 > < case FL_READY: > 855a855,858 > > case FL_READY: > > /* let's be safe: go back to ready state */ > > map_write(map, CMD(0xff), adr); > > chip->state = FL_READY; > > I've not made exhaustive tests to check that everything works fine > with this > change, anyway this fix seems to be ok in all the scenarios I have in > my > environment (kernel/root file system update performed by means of > ftp/flashcp commands executed in a shell script). > > Alberto > > -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: martedì 19 maggio 2009 17.05 > > "Alberto Navatta" writes: > > > We?re trying to use the Davinci (dm6446) hardware watchdog in a > > custom board configured to boot from flash (u-boot 1.1.3 on an Intel > > PC28F128P30). > > > > We have seen that during soft reboot (e.g. reboot ?f command issued > > from the shell) the function ?cfi_intelext_reset? is called before > > machine reboot is triggered by means of the davinci watchdog > > (davinci_watchdog_reset function call), and this works fine. > > > > Instead, if we configure the watchdog to reboot the board on timer > > expire (e.g. configuring and triggering watchdog timer with the > > davinci_wdt device), the board seems to perform the maximum reset as > > expected but it never restarts. > > > > My understanding of this behavior is that the cfi_intelext_reset > > function performs a reset of the intel flash device so that the > > flash is found in the right state (array mode, to be used during > > boot), so, in the first case after the watchdog triggered reset the > > flash is readable by the CPU and boot process is performed > > successfully, while in the second one I suppose the flash chip is in > > an undetermined state and, after the reset, the boot process fails. > > > > Does anyone know a reasonable way to override this problem and to > > have a clean hardware watchdog triggered reset/reboot of the board? > > > > I mean we can have a timer based soft watchdog (e.g. softdog) that > > calls the flash reset function (cfi?) before to trigger the machine > > reset, but this requires some kind of software processing still > > available on the board (interrupt handlers, etc.): our environment > > is very critical
