date:20100816

IPIPE issue in DM365

2010-08-16 Thread hitesh


 Hi All,

I am facing memory leak issue in Chroma Conversion module of  DM365 IPIPE.
When I run the ioctl(resizer_fd, RSZ_RESIZE, &convert) ioctl, It 
increase my memory usage and it is gradually increasing it in
every call of of ioctl. Do you have any solution? I want to do chroma 
conversion for encode my video with H264 encoder.


My configuration for IPIPE is as below.
INPUT_WIDTH =1280
INPUT_HEIGHT =720

 rsz_ss_config.input.image_width = INPUT_WIDTH;
rsz_ss_config.input.image_height = INPUT_HEIGHT;
rsz_ss_config.input.ppln = rsz_ss_config.input.image_width + 8;
rsz_ss_config.input.lpfr = rsz_ss_config.input.image_height + 10;
rsz_ss_config.input.pix_fmt = IPIPE_UYVY;
rsz_ss_config.output1.pix_fmt = IPIPE_YUV420SP;
rsz_ss_config.output1.enable = 1;
rsz_ss_config.output1.width = INPUT_WIDTH;
rsz_ss_config.output1.height = INPUT_HEIGHT;
rsz_ss_config.output2.enable = 0;

rsz_chan_config.oper_mode = IMP_MODE_SINGLE_SHOT;
rsz_chan_config.chain = 0;


I am calling ioctl as below.

 convert.in_buff.buf_type = IMP_BUF_IN;
convert.in_buff.index = 0;
convert.in_buff.offset = buf_in[0].offset;
convert.in_buff.size = buf_in[0].size;
convert.out_buff1.buf_type = IMP_BUF_OUT1;
convert.out_buff1.index = 0;
convert.out_buff1.offset = buf_out1[0].offset;
convert.out_buff1.size = buf_out1[0].size;
if (ioctl(resizer_fd, RSZ_RESIZE, &convert) < 0) {
perror("Error in doing preview\n");
munmap(input_buffer, buf_in[0].size);
munmap(output_buffer, buf_out1[0].size);
close(resizer_fd);
fclose(inp_f);
fclose(outp_f);
exit(1);
}



Thanks
Hitesh


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

Re: IPIPE issue in DM365

2010-08-16 Thread Albert Burbea

Hi
seems strange to me that you use
convert.in_buff.index = 0;
convert.out_buff1.index = 0;
with the same index.
In the dvsdk for DaVinci (2.1 to the best of my knowledge) you should use -1
for buffers that have not been allocated by the resizer itself.
I hope this did not confuse you
Albert

On Mon, Aug 16, 2010 at 11:18 AM, hitesh wrote:

>  Hi All,
>
> I am facing memory leak issue in Chroma Conversion module of  DM365 IPIPE.
> When I run the ioctl(resizer_fd, RSZ_RESIZE, &convert) ioctl, It increase
> my memory usage and it is gradually increasing it in
> every call of of ioctl. Do you have any solution? I want to do chroma
> conversion for encode my video with H264 encoder.
>
> My configuration for IPIPE is as below.
>INPUT_WIDTH =1280
>INPUT_HEIGHT =720
>
> rsz_ss_config.input.image_width = INPUT_WIDTH;
>rsz_ss_config.input.image_height = INPUT_HEIGHT;
>rsz_ss_config.input.ppln = rsz_ss_config.input.image_width + 8;
>rsz_ss_config.input.lpfr = rsz_ss_config.input.image_height + 10;
>rsz_ss_config.input.pix_fmt = IPIPE_UYVY;
>rsz_ss_config.output1.pix_fmt = IPIPE_YUV420SP;
>rsz_ss_config.output1.enable = 1;
>rsz_ss_config.output1.width = INPUT_WIDTH;
>rsz_ss_config.output1.height = INPUT_HEIGHT;
>rsz_ss_config.output2.enable = 0;
>
>rsz_chan_config.oper_mode = IMP_MODE_SINGLE_SHOT;
>rsz_chan_config.chain = 0;
>
>
> I am calling ioctl as below.
>
>  convert.in_buff.buf_type = IMP_BUF_IN;
>convert.in_buff.index = 0;
>convert.in_buff.offset = buf_in[0].offset;
>convert.in_buff.size = buf_in[0].size;
>convert.out_buff1.buf_type = IMP_BUF_OUT1;
>convert.out_buff1.index = 0;
>convert.out_buff1.offset = buf_out1[0].offset;
>convert.out_buff1.size = buf_out1[0].size;
>if (ioctl(resizer_fd, RSZ_RESIZE, &convert) < 0) {
>perror("Error in doing preview\n");
>munmap(input_buffer, buf_in[0].size);
>munmap(output_buffer, buf_out1[0].size);
>close(resizer_fd);
>fclose(inp_f);
>fclose(outp_f);
>exit(1);
>}
>
>
>
> Thanks
> Hitesh
>
>
> ___
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>



-- 
Albert Burbea
Harishonim 8
Ramat Gan 52502, Israel
Tel/Fax + 972-3-7526016
Mobile: +972-52-3541842
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: IPIPE issue in DM365

2010-08-16 Thread hitesh


 Thanks  Albert for your prompt response..

If my application want to allocate memory  and I want to pass that 
memory to IPIPE module then

what should be the parameter?
Do you have any sample application that only doing chroma conversion 
from 422 to 420 without resizing of width and height?

My application getting kernel panic as below.




Read from file done
hResizerHandle 0x2f6c0,srcOffset 0x8ba3e000,destOffset 0x8b87c000
Again in Hell1
Again in Hell22
Unable to handle kernel NULL pointer dereference at virtual address 
Resize operationpgd = c41f
 completed succe[] *pgd=8770f031ssfully.Write to, *pte= 
file done

cou, *ppte=nt 13
file read

Read from fileInternal error: Oops: 817 [#1]
Modules linked in: dm365mmap edmak irqk cmemk
CPU: 0
PC is at nfs_update_request+0x194/0x36c
LR is at radix_tree_node_alloc+0x24/0x5c
pc : []lr : []Not tainted
sp : c41dbc70  ip : c057c960  fp : c41dbcb4
r10: c40f8a10  r9 : c40f8918  r8 : 
r7 : c40f89f0  r6 : c44863a0  r5 : ffef  r4 : 
r3 : ffef  r2 : 0001  r1 : c33e7ee8  r0 : ffef
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 5317F
Table: 841F  DAC: 0015
Process resizer_test (pid: 830, stack limit = 0xc41da258)
Stack: (0xc41dbc70 to 0xc41dc000)

-Hitesh



On 08/16/2010 03:47 PM, Albert Burbea wrote:

Hi
seems strange to me that you use
convert.in_buff.index = 0;
convert.out_buff1.index = 0;
with the same index.
In the dvsdk for DaVinci (2.1 to the best of my knowledge) you should 
use -1 for buffers that have not been allocated by the resizer itself.

I hope this did not confuse you
Albert

On Mon, Aug 16, 2010 at 11:18 AM, hitesh > wrote:


 Hi All,

I am facing memory leak issue in Chroma Conversion module of
 DM365 IPIPE.
When I run the ioctl(resizer_fd, RSZ_RESIZE, &convert) ioctl, It
increase my memory usage and it is gradually increasing it in
every call of of ioctl. Do you have any solution? I want to do
chroma conversion for encode my video with H264 encoder.

My configuration for IPIPE is as below.
   INPUT_WIDTH =1280
   INPUT_HEIGHT =720

rsz_ss_config.input.image_width = INPUT_WIDTH;
   rsz_ss_config.input.image_height = INPUT_HEIGHT;
   rsz_ss_config.input.ppln = rsz_ss_config.input.image_width + 8;
   rsz_ss_config.input.lpfr = rsz_ss_config.input.image_height
+ 10;
   rsz_ss_config.input.pix_fmt = IPIPE_UYVY;
   rsz_ss_config.output1.pix_fmt = IPIPE_YUV420SP;
   rsz_ss_config.output1.enable = 1;
   rsz_ss_config.output1.width = INPUT_WIDTH;
   rsz_ss_config.output1.height = INPUT_HEIGHT;
   rsz_ss_config.output2.enable = 0;

   rsz_chan_config.oper_mode = IMP_MODE_SINGLE_SHOT;
   rsz_chan_config.chain = 0;


I am calling ioctl as below.

 convert.in_buff.buf_type = IMP_BUF_IN;
   convert.in_buff.index = 0;
   convert.in_buff.offset = buf_in[0].offset;
   convert.in_buff.size = buf_in[0].size;
   convert.out_buff1.buf_type = IMP_BUF_OUT1;
   convert.out_buff1.index = 0;
   convert.out_buff1.offset = buf_out1[0].offset;
   convert.out_buff1.size = buf_out1[0].size;
   if (ioctl(resizer_fd, RSZ_RESIZE, &convert) < 0) {
   perror("Error in doing preview\n");
   munmap(input_buffer, buf_in[0].size);
   munmap(output_buffer, buf_out1[0].size);
   close(resizer_fd);
   fclose(inp_f);
   fclose(outp_f);
   exit(1);
   }



Thanks
Hitesh


___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com

http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source




--
Albert Burbea
Harishonim 8
Ramat Gan 52502, Israel
Tel/Fax + 972-3-7526016
Mobile: +972-52-3541842


*Email Scanned for Virus & Dangerous Content by :* 
*www.CleanMailGateway.com*




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

C implementation of DaVinci 4-bit NAND ECC?

2010-08-16 Thread Jon Povey

Just on the off-chance I'm reinventing the wheel, are there any C 
implementations of the DaVinci 4-bit NAND ECC algorithm out there?

I am aware of the C# implementation in the TI flash_utils, looking through it 
there is more Scary Maths than I anticipated. Planning to reverse-engineer and 
rewrite it in C, hardcoded for 512 bytes + 4-bit sizing, unless there is a 
better idea (no, I don't want to use Mono, and it needs to build with GCC.)

For context, this is to run on the DM355 so I can calculate ECC in software and 
write NAND flash in raw mode with different OOB layouts.

--
Jon Povey
jon.po...@racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 
.
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, 
MK18 1TB .

The information contained in this electronic mail transmission is intended by 
Racelogic Ltd for the use of the named individual or entity to which it is 
directed and may contain information that is confidential or privileged. If you 
have received this electronic mail transmission in error, please delete it from 
your system without copying or forwarding it, and notify the sender of the 
error by reply email so that the sender's address records can be corrected. The 
views expressed by the sender of this communication do not necessarily 
represent those of Racelogic Ltd. Please note that Racelogic reserves the right 
to monitor e-mail communications passing through its network


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

Re: C implementation of DaVinci 4-bit NAND ECC?

2010-08-16 Thread Christophe Aeschlimann


On 16.08.2010 13:43, Jon Povey wrote:

Just on the off-chance I'm reinventing the wheel, are there any C 
implementations of the DaVinci 4-bit NAND ECC algorithm out there?

I am aware of the C# implementation in the TI flash_utils, looking through it 
there is more Scary Maths than I anticipated. Planning to reverse-engineer and 
rewrite it in C, hardcoded for 512 bytes + 4-bit sizing, unless there is a 
better idea (no, I don't want to use Mono, and it needs to build with GCC.)

For context, this is to run on the DM355 so I can calculate ECC in software and 
write NAND flash in raw mode with different OOB layouts.


I think it's been implemented as a part of the OpenOCD project.

Have a look : http://developer.berlios.de/projects/openocd/

Regards,


--
Christophe Aeschlimann

Embedded Software Engineer

Advanced Communications Networks S.A.

Rue du Puits-Godet 8a
2000 Neuchâtel, Switzerland

Tél. +41 32 724 74 31

c.aeschlim...@acn-group.ch



--
Jon Povey
jon.po...@racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 
.
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, 
MK18 1TB .

The information contained in this electronic mail transmission is intended by 
Racelogic Ltd for the use of the named individual or entity to which it is 
directed and may contain information that is confidential or privileged. If you 
have received this electronic mail transmission in error, please delete it from 
your system without copying or forwarding it, and notify the sender of the 
error by reply email so that the sender's address records can be corrected. The 
views expressed by the sender of this communication do not necessarily 
represent those of Racelogic Ltd. Please note that Racelogic reserves the right 
to monitor e-mail communications passing through its network


___
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: C implementation of DaVinci 4-bit NAND ECC?

2010-08-16 Thread David Brownell

> I think it's been implemented as a part of the
> OpenOCD project.

Not unless someone snuck in a LOT of code when I
wasn't looking.  The original DaVinci NAND support
used the hardware ECC logic for 1-bit and 4-bit ECC.

- 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: C implementation of DaVinci 4-bit NAND ECC?

2010-08-16 Thread Christophe Aeschlimann


On 16.08.2010 14:41, David Brownell wrote:

I think it's been implemented as a part of the
OpenOCD project.


Not unless someone snuck in a LOT of code when I
wasn't looking.  The original DaVinci NAND support
used the hardware ECC logic for 1-bit and 4-bit ECC.

- Dave


Yeap you're right sorry.

Regards,

--
Christophe Aeschlimann

Embedded Software Engineer

Advanced Communications Networks S.A.

Rue du Puits-Godet 8a
2000 Neuchâtel, Switzerland

Tél. +41 32 724 74 31

c.aeschlim...@acn-group.ch
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: IPIPE issue in DM365

2010-08-16 Thread Albert Burbea

Hi
i  do not have any sample like this. But it is trange you are getting kernle
panic
Are the offsets initialized? It could be that, because u used 0 (zero) as
your buffer index, the resizer did something, but now it is receiving stale
pointers.
Albert

On Mon, Aug 16, 2010 at 2:17 PM, hitesh  wrote:

> Thanks  Albert for your prompt response..
>
> If my application want to allocate memory  and I want to pass that memory
> to IPIPE module then
> what should be the parameter?
> Do you have any sample application that only doing chroma conversion from
> 422 to 420 without resizing of width and height?
> My application getting kernel panic as below.
>
>
>
>
> Read from file done
> hResizerHandle 0x2f6c0,srcOffset 0x8ba3e000,destOffset 0x8b87c000
> Again in Hell1
> Again in Hell22
> Unable to handle kernel NULL pointer dereference at virtual address
> 
> Resize operationpgd = c41f
>  completed succe[] *pgd=8770f031ssfully.Write to, *pte=
> file done
> cou, *ppte=nt 13
> file read
>
> Read from fileInternal error: Oops: 817 [#1]
> Modules linked in: dm365mmap edmak irqk cmemk
> CPU: 0
> PC is at nfs_update_request+0x194/0x36c
> LR is at radix_tree_node_alloc+0x24/0x5c
> pc : []lr : []Not tainted
> sp : c41dbc70  ip : c057c960  fp : c41dbcb4
> r10: c40f8a10  r9 : c40f8918  r8 : 
> r7 : c40f89f0  r6 : c44863a0  r5 : ffef  r4 : 
> r3 : ffef  r2 : 0001  r1 : c33e7ee8  r0 : ffef
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
> Control: 5317F
> Table: 841F  DAC: 0015
> Process resizer_test (pid: 830, stack limit = 0xc41da258)
> Stack: (0xc41dbc70 to 0xc41dc000)
>
> -Hitesh
>
>
>
> On 08/16/2010 03:47 PM, Albert Burbea wrote:
>
>  Hi
> seems strange to me that you use
> convert.in_buff.index = 0;
> convert.out_buff1.index = 0;
> with the same index.
> In the dvsdk for DaVinci (2.1 to the best of my knowledge) you should use
> -1 for buffers that have not been allocated by the resizer itself.
> I hope this did not confuse you
> Albert
>
> On Mon, Aug 16, 2010 at 11:18 AM, hitesh wrote:
>
>>  Hi All,
>>
>> I am facing memory leak issue in Chroma Conversion module of  DM365 IPIPE.
>> When I run the ioctl(resizer_fd, RSZ_RESIZE, &convert) ioctl, It increase
>> my memory usage and it is gradually increasing it in
>> every call of of ioctl. Do you have any solution? I want to do chroma
>> conversion for encode my video with H264 encoder.
>>
>> My configuration for IPIPE is as below.
>>INPUT_WIDTH =1280
>>INPUT_HEIGHT =720
>>
>> rsz_ss_config.input.image_width = INPUT_WIDTH;
>>rsz_ss_config.input.image_height = INPUT_HEIGHT;
>>rsz_ss_config.input.ppln = rsz_ss_config.input.image_width + 8;
>>rsz_ss_config.input.lpfr = rsz_ss_config.input.image_height + 10;
>>rsz_ss_config.input.pix_fmt = IPIPE_UYVY;
>>rsz_ss_config.output1.pix_fmt = IPIPE_YUV420SP;
>>rsz_ss_config.output1.enable = 1;
>>rsz_ss_config.output1.width = INPUT_WIDTH;
>>rsz_ss_config.output1.height = INPUT_HEIGHT;
>>rsz_ss_config.output2.enable = 0;
>>
>>rsz_chan_config.oper_mode = IMP_MODE_SINGLE_SHOT;
>>rsz_chan_config.chain = 0;
>>
>>
>> I am calling ioctl as below.
>>
>>  convert.in_buff.buf_type = IMP_BUF_IN;
>>convert.in_buff.index = 0;
>>convert.in_buff.offset = buf_in[0].offset;
>>convert.in_buff.size = buf_in[0].size;
>>convert.out_buff1.buf_type = IMP_BUF_OUT1;
>>convert.out_buff1.index = 0;
>>convert.out_buff1.offset = buf_out1[0].offset;
>>convert.out_buff1.size = buf_out1[0].size;
>>if (ioctl(resizer_fd, RSZ_RESIZE, &convert) < 0) {
>>perror("Error in doing preview\n");
>>munmap(input_buffer, buf_in[0].size);
>>munmap(output_buffer, buf_out1[0].size);
>>close(resizer_fd);
>>fclose(inp_f);
>>fclose(outp_f);
>>exit(1);
>>}
>>
>>
>>
>> Thanks
>> Hitesh
>>
>>
>> ___
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source@linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>>
>
>
>
> --
> Albert Burbea
> Harishonim 8
> Ramat Gan 52502, Israel
> Tel/Fax + 972-3-7526016
> Mobile: +972-52-3541842
>
>
>   *Email Scanned for Virus & Dangerous Content by :* *
> www.CleanMailGateway.com *
>
>
>


-- 
Albert Burbea
Harishonim 8
Ramat Gan 52502, Israel
Tel/Fax + 972-3-7526016
Mobile: +972-52-3541842
___
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/4] Add support for second MMCSD controller for DA-850

2010-08-16 Thread Juha.Kuikka

This small patch series adds the second MMCSD controller as a platform
device as well as the required resource definitions.

Tested on a custom board with a WiFi peripheral.

Sorry for the formatting in advance. Outlook is not very git-friendly.

Juha Kuikka (4):
  DA850: Add LPSC id for MMCSD1
  DA8xx: Add MMCSD1 base and device registration function
  DA850: Split MMCSD clock into two to support both MMCSD peripherals
  DA8xx: Add MMCSD1 resources, platform device and convenience
registration function

 arch/arm/mach-davinci/da850.c  |   14 --
 arch/arm/mach-davinci/devices-da8xx.c  |   36

 arch/arm/mach-davinci/include/mach/da8xx.h |2 +
 arch/arm/mach-davinci/include/mach/psc.h   |1 +
 4 files changed, 50 insertions(+), 3 deletions(-)
 mode change 100644 => 100755 arch/arm/mach-davinci/devices-da8xx.c
 mode change 100644 => 100755 arch/arm/mach-davinci/include/mach/da8xx.h

Juha Kuikka
Senior Software Engineer, Mobile Device Solutions




Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

___
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/4] DA850: Split MMCSD clock into two to support both MMCSD peripherals

2010-08-16 Thread Juha.Kuikka

Signed-off-by: Juha Kuikka 

diff --git a/arch/arm/mach-davinci/da850.c
b/arch/arm/mach-davinci/da850.c
index 68ed58a..36407e2 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -323,12 +323,19 @@ static struct clk lcdc_clk = {
.gpsc   = 1,
 };

-static struct clk mmcsd_clk = {
-   .name   = "mmcsd",
+static struct clk mmcsd0_clk = {
+   .name   = "mmcsd0",
.parent = &pll0_sysclk2,
.lpsc   = DA8XX_LPSC0_MMC_SD,
 };

+static struct clk mmcsd1_clk = {
+   .name   = "mmcsd1",
+   .parent = &pll0_sysclk2,
+   .lpsc   = DA8XX_LPSC1_MMC_SD1,
+   .gpsc   = 1,
+};
+
 static struct clk aemif_clk = {
.name   = "aemif",
.parent = &pll0_sysclk3,
@@ -375,7 +382,8 @@ static struct clk_lookup da850_clks[] = {
CLK("davinci_emac.1",   NULL,   &emac_clk),
CLK("davinci-mcasp.0",  NULL,   &mcasp_clk),
CLK("da8xx_lcdc.0", NULL,   &lcdc_clk),
-   CLK("davinci_mmc.0",NULL,   &mmcsd_clk),
+   CLK("davinci_mmc.0",NULL,   &mmcsd0_clk),
+   CLK("davinci_mmc.1",NULL,   &mmcsd1_clk),
CLK(NULL,   "aemif",&aemif_clk),
CLK(NULL,   NULL,   NULL),
 };
--
1.6.0.1

Juha Kuikka
Senior Software Engineer, Mobile Device Solutions




Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

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

[PATCH 2/4] DA8xx: Add MMCSD1 base and device registration function

2010-08-16 Thread Juha.Kuikka

Signed-off-by: Juha Kuikka 

diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h
b/arch/arm/mach-davinci/include/mach/da8xx.h
old mode 100644
new mode 100755
index 3c07059..fefa03d
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -58,6 +58,7 @@ extern void __iomem *da8xx_syscfg1_base;
 #define DA8XX_LCD_CNTRL_BASE   0x01e13000
 #define DA8XX_PLL1_BASE0x01e1a000
 #define DA8XX_MMCSD0_BASE  0x01c4
+#define DA8XX_MMCSD1_BASE  0x01e1b000
 #define DA8XX_AEMIF_CS2_BASE   0x6000
 #define DA8XX_AEMIF_CS3_BASE   0x6200
 #define DA8XX_AEMIF_CTL_BASE   0x6800
@@ -76,6 +77,7 @@ int da8xx_register_usb11(struct da8xx_ohci_root_hub
*pdata);
 int da8xx_register_emac(void);
 int da8xx_register_lcdc(struct da8xx_lcdc_platform_data *pdata);
 int da8xx_register_mmcsd0(struct davinci_mmc_config *config);
+int da8xx_register_mmcsd1(struct davinci_mmc_config *config);
 void __init da8xx_register_mcasp(int id, struct snd_platform_data
*pdata);
 int da8xx_register_rtc(void);
 int da850_register_cpufreq(void);
--
1.6.0.1

Juha Kuikka
Senior Software Engineer, Mobile Device Solutions




Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

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

[PATCH 1/4] DA850: Add LPSC id for MMCSD1

2010-08-16 Thread Juha.Kuikka

Signed-off-by: Juha Kuikka 

diff --git a/arch/arm/mach-davinci/include/mach/psc.h
b/arch/arm/mach-davinci/include/mach/psc.h
index 983da6e..05118e7 100644
--- a/arch/arm/mach-davinci/include/mach/psc.h
+++ b/arch/arm/mach-davinci/include/mach/psc.h
@@ -172,6 +172,7 @@
 #define DA8XX_LPSC1_UART2  13
 #define DA8XX_LPSC1_LCDC   16
 #define DA8XX_LPSC1_PWM17
+#define DA8XX_LPSC1_MMC_SD118
 #define DA8XX_LPSC1_ECAP   20
 #define DA830_LPSC1_EQEP   21
 #define DA850_LPSC1_TPTC2  21
--
1.6.0.1

Juha Kuikka
Senior Software Engineer, Mobile Device Solutions




Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

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

[PATCH 4/4] DA8xx: Add MMCSD1 resources, platform device and convenience registration function

2010-08-16 Thread Juha.Kuikka

Signed-off-by: Juha Kuikka 

diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
old mode 100644
new mode 100755
index 52bc7b1..9e1a8be
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -566,6 +566,42 @@ int __init da8xx_register_mmcsd0(struct
davinci_mmc_config *config)
return platform_device_register(&da8xx_mmcsd0_device);
 }

+static struct resource da8xx_mmcsd1_resources[] = {
+   {   /* registers */
+   .start  = DA8XX_MMCSD1_BASE,
+   .end= DA8XX_MMCSD1_BASE + SZ_4K - 1,
+   .flags  = IORESOURCE_MEM,
+   },
+   {   /* interrupt */
+   .start  = IRQ_DA850_MMCSDINT0_1,
+   .end= IRQ_DA850_MMCSDINT0_1,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {   /* DMA RX */
+   .start  = EDMA_CTLR_CHAN(1, 28),
+   .end= EDMA_CTLR_CHAN(1, 28),
+   .flags  = IORESOURCE_DMA,
+   },
+   {   /* DMA TX */
+   .start  = EDMA_CTLR_CHAN(1, 29),
+   .end= EDMA_CTLR_CHAN(1, 29),
+   .flags  = IORESOURCE_DMA,
+   },
+};
+
+static struct platform_device da8xx_mmcsd1_device = {
+   .name   = "davinci_mmc",
+   .id = 1,
+   .num_resources  = ARRAY_SIZE(da8xx_mmcsd1_resources),
+   .resource   = da8xx_mmcsd1_resources,
+};
+
+int __init da8xx_register_mmcsd1(struct davinci_mmc_config *config)
+{
+   da8xx_mmcsd1_device.dev.platform_data = config;
+   return platform_device_register(&da8xx_mmcsd1_device);
+}
+
 static struct resource da8xx_rtc_resources[] = {
{
.start  = DA8XX_RTC_BASE,
--
1.6.0.1

Juha Kuikka
Senior Software Engineer, Mobile Device Solutions





Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

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

dm365 h264dec buf usage problem

2010-08-16 Thread johnny

problem of h264dec:

the version of h264dec is 2.0.0.5.

in source code vdec2.c in dmai:

Int Vdec2_process(Vdec2_Handle hVd, Buffer_Handle hInBuf,
  Buffer_Handle hDstBuf)
{
VIDDEC2_InArgs  inArgs;
VIDDEC2_OutArgs outArgs;
XDM1_BufDescinBufDesc;
XDM_BufDesc outBufDesc;
XDAS_Int32  outBufSizeArray[XDM_MAX_IO_BUFFERS];
XDAS_Int8  *outBufPtrArray[XDM_MAX_IO_BUFFERS];
XDAS_Int32  status;
Int bufIdx;
BufferGfx_Dimensionsdim;
XDAS_Int8  *inPtr, *dstPtr;
Int ret = Dmai_EOK;
UInt32  offset;
UInt32  bpp;
assert(hVd);
assert(hInBuf);
assert(hDstBuf);
assert(Buffer_getUserPtr(hInBuf));
assert(Buffer_getUserPtr(hDstBuf));
assert(Buffer_getNumBytesUsed(hInBuf));
assert(Buffer_getSize(hDstBuf));
assert(Buffer_getType(hDstBuf) == Buffer_Type_GRAPHICS);
bpp = ColorSpace_getBpp(BufferGfx_getColorSpace(hDstBuf));

BufferGfx_getDimensions(hDstBuf, &dim);
offset = (dim.y * dim.lineLength) + (dim.x * (bpp >> 3));
assert(offset < Buffer_getSize(hDstBuf));
inPtr  = Buffer_getUserPtr(hInBuf);
dstPtr = Buffer_getUserPtr(hDstBuf) + offset;
if (BufferGfx_getColorSpace(hDstBuf) == ColorSpace_YUV420PSEMI) {
outBufPtrArray[0]   = dstPtr;
outBufSizeArray[0]  = hVd->minOutBufSize[0];
outBufPtrArray[1]   = dstPtr + Buffer_getSize(hDstBuf) * 2 / 3;
outBufSizeArray[1]  = hVd->minOutBufSize[1];
}
else if (BufferGfx_getColorSpace(hDstBuf) == ColorSpace_UYVY) {
outBufPtrArray[0]   = dstPtr;
outBufSizeArray[0]  = hVd->minOutBufSize[0];
}
else {
Dmai_err0("Unsupported color format of destination buffer\n");
return Dmai_EINVAL;
}
outBufDesc.numBufs  = hVd->minNumOutBufs;
outBufDesc.bufSizes = outBufSizeArray;
outBufDesc.bufs = outBufPtrArray;
/* One buffer with encoded data */
inBufDesc.numBufs   = 1;
inBufDesc.descs[0].buf  = inPtr;
inBufDesc.descs[0].bufSize  = Buffer_getNumBytesUsed(hInBuf);
inArgs.size = sizeof(VIDDEC2_InArgs);
inArgs.numBytes = Buffer_getNumBytesUsed(hInBuf);
inArgs.inputID  = GETID(Buffer_getId(hDstBuf));
outArgs.size= sizeof(VIDDEC2_OutArgs);
/* Decode video buffer */
status = VIDDEC2_process(hVd->hDecode, &inBufDesc, &outBufDesc, &inArgs,
 &outArgs);
Buffer_setNumBytesUsed(hInBuf, outArgs.bytesConsumed);
Dmai_dbg4("VIDDEC2_process() ret %d inId %d inUse %d consumed %d\n",
  status, Buffer_getId(hDstBuf), outArgs.outBufsInUseFlag,
  outArgs.bytesConsumed);
if (status != VIDDEC2_EOK) {
if (XDM_ISFATALERROR(outArgs.decodedBufs.extendedError)) {
Dmai_err2("VIDDEC2_process() failed with error (%d ext: 0x%x)\n",
  (Int)status, (Uns) outArgs.decodedBufs.extendedError);
return Dmai_EFAIL;
}
else {
Dmai_dbg1("VIDDEC2_process() non-fatal error 0x%x\n",
  (Uns) outArgs.decodedBufs.extendedError);
ret = Dmai_EBITERROR;
}
}
/* Prepare buffers for display */
for (bufIdx = 0;
 bufIdx < IVIDDEC2_MAX_IO_BUFFERS && outArgs.outputID[bufIdx] > 0;
 bufIdx++) {
hVd->hDisplayBufs[bufIdx] =
BufTab_getBuf(hVd->hOutBufTab, GETIDX(outArgs.outputID[bufIdx]));
dim.width = outArgs.displayBufs[bufIdx].frameWidth;
dim.height = outArgs.displayBufs[bufIdx].frameHeight;
dim.lineLength = outArgs.displayBufs[bufIdx].framePitch;
/* Is there an offset to where we are supposed to start displaying? */
offset = outArgs.displayBufs[bufIdx].bufDesc[0].buf -
 Buffer_getUserPtr(hVd->hDisplayBufs[bufIdx]);
dim.y = offset / dim.lineLength;
dim.x = offset - ((dim.y * dim.lineLength) >> (bpp >> 4));
#ifdef Dmai_Device_dm365
if (BufferGfx_getColorSpace(hDstBuf) == ColorSpace_YUV420PSEMI) {

BufferGfx_DimensionscbcrDim;
Int8   *pSrc, *pDst;

offset = dim.y * dim.lineLength / 2 + (dim.x * (bpp >> 3)); 
pSrc   = (Int8 *) outArgs.displayBufs[bufIdx].bufDesc[1].buf;
pDst   = Buffer_getUserPtr(hVd->hDisplayBufs[bufIdx]) + offset 
 + (Buffer_getSize(hVd->hDisplayBufs[bufIdx]) * 2 / 3);

if(pSrc != pDst) {
/* Move the CbCr plane to its right place */
printf("Move the CbCr plane to its right place\n");
cbcrDim = dim;
cbcrDim.height = cbcrDim.height / 2;
_Framecopy_accel_move(hVd->hFc, &cbcrDim, pSrc, pDst);

RE: [PATCH 0/4] Add support for second MMCSD controller for DA-850

2010-08-16 Thread Nori, Sekhar

Hi Juha,

On Tue, Aug 17, 2010 at 01:35:09, juha.kui...@elektrobit.com wrote:
> This small patch series adds the second MMCSD controller as a platform
> device as well as the required resource definitions.

Thanks! I remember some EDMA changes were discussed on the list for MMCSD1
support. Are those resolved upstream?

>
> Tested on a custom board with a WiFi peripheral.
>
> Sorry for the formatting in advance. Outlook is not very git-friendly.

No need to use outlook to send patches. Use git-send-email.

Regards,
Sekhar

___
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/4] DA850: Add LPSC id for MMCSD1

2010-08-16 Thread Nori, Sekhar

On Tue, Aug 17, 2010 at 01:36:29, juha.kui...@elektrobit.com wrote:
> Signed-off-by: Juha Kuikka 
>
> diff --git a/arch/arm/mach-davinci/include/mach/psc.h
> b/arch/arm/mach-davinci/include/mach/psc.h
> index 983da6e..05118e7 100644
> --- a/arch/arm/mach-davinci/include/mach/psc.h
> +++ b/arch/arm/mach-davinci/include/mach/psc.h
> @@ -172,6 +172,7 @@
>  #define DA8XX_LPSC1_UART2  13
>  #define DA8XX_LPSC1_LCDC   16
>  #define DA8XX_LPSC1_PWM17
> +#define DA8XX_LPSC1_MMC_SD118

Since MMC/SD1 is present only on DA850 and not on
DA830, this define should rather be DA850_LPSC1_MMC_SD1
to be consistent with what is being done for other
such modules.

Thanks,
Sekhar

___
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 2/4] DA8xx: Add MMCSD1 base and device registration function

2010-08-16 Thread Nori, Sekhar

On Tue, Aug 17, 2010 at 01:36:34, juha.kui...@elektrobit.com wrote:
> Signed-off-by: Juha Kuikka 
>
> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h
> b/arch/arm/mach-davinci/include/mach/da8xx.h
> old mode 100644
> new mode 100755
> index 3c07059..fefa03d
> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
> @@ -58,6 +58,7 @@ extern void __iomem *da8xx_syscfg1_base;
>  #define DA8XX_LCD_CNTRL_BASE   0x01e13000
>  #define DA8XX_PLL1_BASE0x01e1a000
>  #define DA8XX_MMCSD0_BASE  0x01c4
> +#define DA8XX_MMCSD1_BASE  0x01e1b000

Since this define is only going to be used in
devices-da8xx.c, it should be kept in that file
itself. MMC/SD0 is not following this and probably
needs fixing. Also, similar to the LPSC comment,
the define should be DA850_MMCSD1_BASE.

>  #define DA8XX_AEMIF_CS2_BASE   0x6000
>  #define DA8XX_AEMIF_CS3_BASE   0x6200
>  #define DA8XX_AEMIF_CTL_BASE   0x6800
> @@ -76,6 +77,7 @@ int da8xx_register_usb11(struct da8xx_ohci_root_hub
> *pdata);
>  int da8xx_register_emac(void);
>  int da8xx_register_lcdc(struct da8xx_lcdc_platform_data *pdata);
>  int da8xx_register_mmcsd0(struct davinci_mmc_config *config);
> +int da8xx_register_mmcsd1(struct davinci_mmc_config *config);

This should be part of patch 4/4

Thanks,
Sekhar

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

IPIPE issue in DM365

Re: IPIPE issue in DM365

Re: IPIPE issue in DM365

C implementation of DaVinci 4-bit NAND ECC?

Re: C implementation of DaVinci 4-bit NAND ECC?

Re: C implementation of DaVinci 4-bit NAND ECC?

Re: C implementation of DaVinci 4-bit NAND ECC?

Re: IPIPE issue in DM365

[PATCH 0/4] Add support for second MMCSD controller for DA-850

[PATCH 3/4] DA850: Split MMCSD clock into two to support both MMCSD peripherals

[PATCH 2/4] DA8xx: Add MMCSD1 base and device registration function

[PATCH 1/4] DA850: Add LPSC id for MMCSD1

[PATCH 4/4] DA8xx: Add MMCSD1 resources, platform device and convenience registration function

dm365 h264dec buf usage problem

RE: [PATCH 0/4] Add support for second MMCSD controller for DA-850

RE: [PATCH 1/4] DA850: Add LPSC id for MMCSD1

RE: [PATCH 2/4] DA8xx: Add MMCSD1 base and device registration function

17 matches

Site Navigation

Mail list logo

Footer information