RE: [PATCH] rtc: make rtc-omap wakeup capable

[Nori, Sekhar]

Hello,

On Tue, Nov 24, 2009 at 18:48:40, Nori, Sekhar wrote:
> The rtc-omap driver currently hardcodes the RTC to be
> not capable of wakeup events. On the DA850/OMAP-L138
> SoC, the RTC is a wake up source from its "deep sleep"
> mode.
>
> Let platform data set the wakeup capability flag instead.
>
> Signed-off-by: Sekhar Nori 
> Signed-off-by: Kevin Hilman 

Any comments on this patch?

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: Cmem address translation when working with Codec Engine

[Erez Kinarti]

Thank you very much Rob,
I'm going to try it now.
Just one open issue is the size of the big buffer:
In the app I cannot be sure what is the buffer size that CMEM allocated
for me, I just know that the size is at least the size that I requested.
Do I have to put the size parameter in these function the exact size
allocated by CMEM, or just the size that I use is enough?
In case I must use the size allocated by CMEM, is there a way to know
what this size is?

Thanks,
Erez


-Original Message-
From: Tivy, Robert [mailto:rt...@ti.com] 
Sent: Tuesday, January 05, 2010 1:30 AM
To: Erez Kinarti; Vladimir Pantelic;
Davinci-linux-open-source@linux.davincidsp.com
Subject: RE: Cmem address translation when working with Codec Engine


There is no function available to invalidate all the Memory module
virt-phys translations.

If your app structure allows it, you can call
Memory_registerContigBuf(bigCMEMBufferVirtAddr, 258048,
CMEM_getPhys(bigCMEMBufferVirtAddr));
once, and all smaller subdivided buffers will be covered by this one
registration (or, even simpler, just call
Memory_getBufferPhysicalAddress(bigCMEMBufferVirtAddr, 258048,
NULL);
and ignore the result, which will do the CMEM_getPhys() for you and
register it).  You can then call
Memory_unregisterContigBuf(bigCMEMBufferVirtAddr, 258048) once when
you're ready to free the CMEM buffer.  FYI, if you want to double-check
me, you can call Memory_dumpKnownContigBufsList() to display (through GT
tracing) the contig buffer list (AKA, the Memory module virt-phys
translation table).

Regards,

- Rob

> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com 
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
> ] On Behalf Of Erez Kinarti
> Sent: Monday, January 04, 2010 9:15 AM
> To: Vladimir Pantelic; Davinci-linux-open-source@linux.davincidsp.com
> Subject: RE: Cmem address translation when working with Codec Engine
> 
> Thank you Vladimir,
> But we are not able to allocate and free via CodecEngine due 
> to the structure of our application and the need to call the 
> alloc not before calling CERuntimeInit().
> 
> 
> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
> ] On Behalf Of Vladimir Pantelic
> Sent: Monday, January 04, 2010 7:09 PM
> To: Davinci-linux-open-source@linux.davincidsp.com
> Subject: Re: Cmem address translation when working with Codec Engine
> 
> Erez Kinarti wrote:
> > Thanks a lot Rob.
> >
> > calling this function for each of the pointers used with 
> CodecEngine 
> > solved the problem.
> >
> > However, we need something else, some function that invalidates all
> this
> > virt->phy table and not each of the virtual pointers separately.
> >
> > Is there a way to do a full invalidate in a single call 
> without keep 
> > tracking on each of the virtual pointers?
> >
> > The reason that Memory_unregisterContigBuf it is not enough for us:
> >
> > In our system, we allocate a very big buffer from CMEM 
> (258048 bytes), 
> > but we don't call CodecEngine with a pointer to the big buffer.
> 
> You dont need to call Memory_unregisterContigBuf, just alloc 
> and free the buffers via CE and CE will know that you are 
> calling it with a smaller buffer inside a larger one that it 
> knows the translation to...
> 
> ___
> 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: codec hangs

[Vladimir Pantelic]

Albert Burbea wrote:

Hi
thanks for your help - the problem is that the JPEG codec is TI's and I
do not have access to its source code.
What could hang the message queue ?
Thanks again
Albert



Hi everybody,
I am using mv 4.01 with codec engine 2.01. I am integrating the
TI JPEG encoder 1.1.13. At the beginning it did not work,it did
not even open,  until I modified the JPEGENC.xs to return the
saram and daram scratch sizes. Before that, I modified also the
ce/JPEGENC.xdc to use an IMGENC1 VISA interface instead of the
IMGENC interface. I was able to open it and do an XDM_SETPARAMS
control, but I did not try anything more. I restored the IMGENC
interface in ce/JPEGENC.xdc, and compiled. Still worked. Then, I


well, what API is this codec using? IMGENC or IMGENC1? You have to use the
correct API of course and you say that IMGENC1 worked, so why are you trying
IMGENC?

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

RE: Cmem address translation when working with Codec Engine

[Erez Kinarti]

Hey Rob,
I see that calling the register functions require that CE is in the air
(CERuntimeInit) so it is problematic for us in the same way as doing the
CMEM allocations via CodecEngine.
So I guess I have no solution except redesigning my system such that
CERuntimeInit will be before any buffers allocation.
Do you have any other offer that can save me this effort (which is
huge)?

Thanks in advance,
Erez


-Original Message-
From: Tivy, Robert [mailto:rt...@ti.com] 
Sent: Tuesday, January 05, 2010 1:30 AM
To: Erez Kinarti; Vladimir Pantelic;
Davinci-linux-open-source@linux.davincidsp.com
Subject: RE: Cmem address translation when working with Codec Engine


There is no function available to invalidate all the Memory module
virt-phys translations.

If your app structure allows it, you can call
Memory_registerContigBuf(bigCMEMBufferVirtAddr, 258048,
CMEM_getPhys(bigCMEMBufferVirtAddr));
once, and all smaller subdivided buffers will be covered by this one
registration (or, even simpler, just call
Memory_getBufferPhysicalAddress(bigCMEMBufferVirtAddr, 258048,
NULL);
and ignore the result, which will do the CMEM_getPhys() for you and
register it).  You can then call
Memory_unregisterContigBuf(bigCMEMBufferVirtAddr, 258048) once when
you're ready to free the CMEM buffer.  FYI, if you want to double-check
me, you can call Memory_dumpKnownContigBufsList() to display (through GT
tracing) the contig buffer list (AKA, the Memory module virt-phys
translation table).

Regards,

- Rob

> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com 
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
> ] On Behalf Of Erez Kinarti
> Sent: Monday, January 04, 2010 9:15 AM
> To: Vladimir Pantelic; Davinci-linux-open-source@linux.davincidsp.com
> Subject: RE: Cmem address translation when working with Codec Engine
> 
> Thank you Vladimir,
> But we are not able to allocate and free via CodecEngine due 
> to the structure of our application and the need to call the 
> alloc not before calling CERuntimeInit().
> 
> 
> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
> ] On Behalf Of Vladimir Pantelic
> Sent: Monday, January 04, 2010 7:09 PM
> To: Davinci-linux-open-source@linux.davincidsp.com
> Subject: Re: Cmem address translation when working with Codec Engine
> 
> Erez Kinarti wrote:
> > Thanks a lot Rob.
> >
> > calling this function for each of the pointers used with 
> CodecEngine 
> > solved the problem.
> >
> > However, we need something else, some function that invalidates all
> this
> > virt->phy table and not each of the virtual pointers separately.
> >
> > Is there a way to do a full invalidate in a single call 
> without keep 
> > tracking on each of the virtual pointers?
> >
> > The reason that Memory_unregisterContigBuf it is not enough for us:
> >
> > In our system, we allocate a very big buffer from CMEM 
> (258048 bytes), 
> > but we don't call CodecEngine with a pointer to the big buffer.
> 
> You dont need to call Memory_unregisterContigBuf, just alloc 
> and free the buffers via CE and CE will know that you are 
> calling it with a smaller buffer inside a larger one that it 
> knows the translation to...
> 
> ___
> 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: Cmem address translation when working with Codec Engine

[Vladimir Pantelic]

Erez Kinarti wrote:

Hey Rob,
I see that calling the register functions require that CE is in the air
(CERuntimeInit) so it is problematic for us in the same way as doing the
CMEM allocations via CodecEngine.


as you have to call CERuntimeInit() before using any of CE, you can do the
Memory_registerContigBuf() after CERuntimeInit(), no?


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

RE: Cmem address translation when working with Codec Engine

[Erez Kinarti]

No, because in my system, the first codec that is generated is calling
CERuntimeInit (working with C++, keeping reference counter for the call
to CERuntimeInit and CERuntimeExit), while the system buffers are
allocated before that.


-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On
Behalf Of Vladimir Pantelic
Sent: Tuesday, January 05, 2010 11:15 AM
To: Davinci-linux-open-source@linux.davincidsp.com
Cc: Davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Cmem address translation when working with Codec Engine

Erez Kinarti wrote:
> Hey Rob,
> I see that calling the register functions require that CE is in the
air
> (CERuntimeInit) so it is problematic for us in the same way as doing
the
> CMEM allocations via CodecEngine.

as you have to call CERuntimeInit() before using any of CE, you can do
the
Memory_registerContigBuf() after CERuntimeInit(), no?


___
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: Cmem address translation when working with Codec Engine

[Vladimir Pantelic]

Erez Kinarti wrote:

No, because in my system, the first codec that is generated is calling
CERuntimeInit (working with C++, keeping reference counter for the call
to CERuntimeInit and CERuntimeExit), while the system buffers are
allocated before that.


well, then move that call outside of the codecs

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

RE: Cmem address translation when working with Codec Engine

[Erez Kinarti]

You are totally correct, it is just that our system is in a validation
stage where we don't want to touch anything (in order to avoid doing all
the testing cycle again), and moving the CERuntimeInit to be before the
buffers allocation will require some changes that I don't want to do in
such stage.
Of course I'll do it if I have no other choice ...



-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On
Behalf Of Vladimir Pantelic
Sent: Tuesday, January 05, 2010 11:48 AM
To: Davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Cmem address translation when working with Codec Engine

Erez Kinarti wrote:
> No, because in my system, the first codec that is generated is calling
> CERuntimeInit (working with C++, keeping reference counter for the
call
> to CERuntimeInit and CERuntimeExit), while the system buffers are
> allocated before that.

well, then move that call outside of the codecs

___
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

Image manipulation on DM355

[Jatin Pasrija]

Hi

I want to display an image using DM355 along with a text menu and some other
images on the side. What is the best way that I can manipulate size and
location of images displayed on the screen. Till now I have only managed to
display a full jpeg image using the demo code in DM355 and the frame buffer.


I am a student and have just started working on Da Vinci, hence kindly reply
accordingly.

Thanks a lot

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

RE: USB storage error

[Gopala Gottumukkala]

Which kernel version number is working for you can I know the kernel
version number and if any patches please let me know the patches also.

 

- Gopala

 

From: Gopala Gottumukkala 
Sent: Monday, January 04, 2010 9:13 AM
To: 'Subbrathnam, Swaminathan';
davinci-linux-open-source@linux.davincidsp.com
Subject: RE: USB storage error

 

Can I know the latest Davinci Git kernel version which is working for
you.  The kernel version number and where can I down load the latest
one.

 

- Gopala

 

From: Subbrathnam, Swaminathan [mailto:swami.i...@ti.com] 
Sent: Friday, January 01, 2010 8:10 AM
To: Gopala Gottumukkala; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: USB storage error

 

Gopala,

 

Could you try the latest DaVinci Git.  It works for me.

 

regards

swami



From: davinci-linux-open-source-boun...@linux.davincidsp.com
[davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Gopala Gottumukkala [ggott...@cernium.com]
Sent: Friday, January 01, 2010 1:38 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: USB storage error

I have compiled davinci 2.6.30

I mounted the usb manually 

I ran some sample program which will open, write and delete the file
into usb drive.

While writing the file into usb drive.  It gives the following error and
the program dies.

 

Any help would be appreciated on this

 

 

usb 1-1: reset high speed USB device using musb_hdrc and address 2

usb 1-1: reset high speed USB device using musb_hdrc and address 2

usb 1-1: reset high speed USB device using musb_hdrc and address 2

sd 0:0:0:0: Device offlined - not ready after error recovery

sd 0:0:0:0: [sda] Unhandled error code

sd 0:0:0:0: [sda] Result: hostbyte=0x05 driverbyte=0x00

end_request: I/O error, dev sda, sector 41584

sd 0:0:0:0: rejecting I/O to offline device

sd 0:0:0:0: [sda] Unhandled error code

sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00

end_request: I/O error, dev sda, sector 4

sd 0:0:0:0: rejecting I/O to offline device

sd 0:0:0:0: rejecting I/O to offline device

sd 0:0:0:0: rejecting I/O to offline device

sd 0:0:0:0: rejecting I/O to offline device

sd 0:0:0:0: rejecting I/O to offline device

sd 0:0:0:0: rejecting I/O to offline device

sd 0:0:0:0: rejecting I/O to offline device

 

- Gopala

NOTICE: The information contained in this email and any document
attached hereto is intended only for the named recipient(s). It is the
property of Cernium Corporation and shall not be used, disclosed or
reproduced without the express written consent of Cernium Corporation.
If you are not the intended recipient (or the employee or agent
responsible for delivering this message in confidence to the intended
recipient(s)), you are hereby notified that you have received this
transmittal in error, and any review, dissemination, distribution or
copying of this transmittal or its attachments is strictly prohibited.
If you have received this transmittal and/or attachments in error,
please notify me immediately by reply email or telephone and immediately
delete this message and all its attachments. 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

RE: USB storage error

[Subbrathnam, Swaminathan]

Pl. refer to DaVinci Staging GIT kernel hosted at 
http://arago-project.org/git/people/?p=sneha/linux-davinci-staging.git;a=summary.


From: Gopala Gottumukkala [mailto:ggott...@cernium.com]
Sent: Tuesday, January 05, 2010 8:06 PM
To: Subbrathnam, Swaminathan; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: USB storage error

Which kernel version number is working for you can I know the kernel version 
number and if any patches please let me know the patches also.

- Gopala

From: Gopala Gottumukkala
Sent: Monday, January 04, 2010 9:13 AM
To: 'Subbrathnam, Swaminathan'; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: USB storage error

Can I know the latest Davinci Git kernel version which is working for you.  The 
kernel version number and where can I down load the latest one.

- Gopala

From: Subbrathnam, Swaminathan [mailto:swami.i...@ti.com]
Sent: Friday, January 01, 2010 8:10 AM
To: Gopala Gottumukkala; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: USB storage error

Gopala,

Could you try the latest DaVinci Git.  It works for me.

regards
swami

From: davinci-linux-open-source-boun...@linux.davincidsp.com 
[davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Gopala 
Gottumukkala [ggott...@cernium.com]
Sent: Friday, January 01, 2010 1:38 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: USB storage error
I have compiled davinci 2.6.30
I mounted the usb manually
I ran some sample program which will open, write and delete the file into usb 
drive.
While writing the file into usb drive.  It gives the following error and the 
program dies.

Any help would be appreciated on this


usb 1-1: reset high speed USB device using musb_hdrc and address 2
usb 1-1: reset high speed USB device using musb_hdrc and address 2
usb 1-1: reset high speed USB device using musb_hdrc and address 2
sd 0:0:0:0: Device offlined - not ready after error recovery
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=0x05 driverbyte=0x00
end_request: I/O error, dev sda, sector 41584
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00
end_request: I/O error, dev sda, sector 4
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device

- Gopala
NOTICE: The information contained in this email and any document attached 
hereto is intended only for the named recipient(s). It is the property of 
Cernium Corporation and shall not be used, disclosed or reproduced without the 
express written consent of Cernium Corporation. If you are not the intended 
recipient (or the employee or agent responsible for delivering this message in 
confidence to the intended recipient(s)), you are hereby notified that you have 
received this transmittal in error, and any review, dissemination, distribution 
or copying of this transmittal or its attachments is strictly prohibited. If 
you have received this transmittal and/or attachments in error, please notify 
me immediately by reply email or telephone and immediately delete this message 
and all its attachments. Thank you.
NOTICE: The information contained in this email and any document attached 
hereto is intended only for the named recipient(s). It is the property of 
Cernium Corporation and shall not be used, disclosed or reproduced without the 
express written consent of Cernium Corporation. If you are not the intended 
recipient (or the employee or agent responsible for delivering this message in 
confidence to the intended recipient(s)), you are hereby notified that you have 
received this transmittal in error, and any review, dissemination, distribution 
or copying of this transmittal or its attachments is strictly prohibited. If 
you have received this transmittal and/or attachments in error, please notify 
me immediately by reply email or telephone and immediately delete this message 
and all its attachments. 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

RE: Arago Kerenel w/ codec_engine_2_00_01 issues?

[Paul Stuart]

Thanks for the response!

I'll give the latest CMEM, LinuxUtils, et al a whirl and see what happens. The 
strange thing is that the mpeg4 decoder, jpeg encode/decode, and mp3 
encode/decode all load without complaint. It's just the mpeg4enc that fails.


I've rebuilt cmemk.ko and dm350mmap.ko against the arago kernel. Neither 
process was straight forward though because of changes between the montavista 
kernel we were using. Maybe something got botched in the process.


Turning on the trace, with CE_DEBUG=2, I get the following during mpeg4enc 
initialization:


@5,653,051us: [+0 T:0x43300490] ti.sdo.ce.video1.VIDENC1 - VIDENC1_create> 
Enter (engine=0x100670, name='mpeg4enc', params=0x432ffca8)
@5,653,350us: [+0 T:0x43300490] CV - VISA_create(0x100670, 'mpeg4enc', 
0x432ffca8, 0x2496, 'ti.sdo.ce.video1.IVIDENC1')
@5,653,569us: [+0 T:0x43300490] CV - VISA_create2(0x100670, 'mpeg4enc', 
0x432ffca8, 0x30, 0x2496, 'ti.sdo.ce.video1.IVIDENC1')
@5,654,187us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - Algorithm_create> 
Enter(fxns=0xf89c0, idma3Fxns=0xf8988, iresFxns=0x0, params=0x432ffca8, 
attrs=0x432ffac8)
@5,654,470us: [+0 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create> Enter 
(scratchId=1, fxns=0xf89c0, parentAlg=0x0, params=0x432ffca8)
@5,678,280us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create> algNumAlloc 7 
memory recs
@5,678,574us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create> algAlloc 
returned numRecs=7
@5,678,777us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create>  Memory 
requested memTab[0]: size=0x2c58, align=0x100, space=0x11, attrs=0x1
@5,678,985us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create>  Memory 
requested memTab[1]: size=0x200, align=0x100, space=0x11, attrs=0x1
@5,679,182us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create>  Memory 
requested memTab[2]: size=0x19a400, align=0x100, space=0x11, attrs=0x1
@5,679,568us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create>  Memory 
requested memTab[3]: size=0x10e0, align=0x100, space=0x11, attrs=0x1
@5,679,816us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create>  Memory 
requested memTab[4]: size=0x4, align=0x100, space=0x11, attrs=0x1
@5,680,026us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create>  Memory 
requested memTab[5]: size=0x14000, align=0x100, space=0x11, attrs=0x1
@5,680,233us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create>  Memory 
requested memTab[6]: size=0x3840, align=0x100, space=0x11, attrs=0x1
@5,680,648us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_alloc(11352) = 
0x43301000.
@5,680,909us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
CMEM_getPhys(0x43301000) = 0x8702c000.
@5,681,514us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_alloc(512) = 
0x42a02000.
@5,681,792us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
CMEM_getPhys(0x42a02000) = 0x87018000.
@5,682,401us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_alloc(1680384) = 
0x43305000.
@5,682,711us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
CMEM_getPhys(0x43305000) = 0x87e0.
@5,698,324us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_alloc(4320) = 
0x43505000.
@5,698,622us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
CMEM_getPhys(0x43505000) = 0x8702a000.
@5,699,098us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_alloc(4) = 
0x43507000.
@5,699,535us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
CMEM_getPhys(0x43507000) = 0x87019000.
@5,700,033us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_alloc(81920) = 
0x43508000.
@5,700,348us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
CMEM_getPhys(0x43508000) = 0x8704e000.
@5,701,570us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_alloc(14400) = 
0x4351c000.
@5,701,844us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
CMEM_getPhys(0x4351c000) = 0x8703.
@5,757,804us: [+7 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create> algInit call 
failed 49280
@5,765,522us: [+0 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create> Exit 
(algHandle=NULL)
@5,765,791us: [+7 T:0x43300490] ti.sdo.ce.alg.Algorithm - Algorithm_create> 
Algorithm creation FAILED; make sure that 1) alg params are 
correct/appropriate, 2) there is enough internal and external algorithm memory 
available -- check DSKT2 settings for heap assignments and scratch allocation
@5,766,031us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - Algorithm_delete> 
Enter(alg=0x1fb020)
@5,766,236us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - Algorithm_create> 
return (0x0)
@5,766,462us: [+2 T:0x43300490] CV - VISA_create> FAILED to create local codec.
@5,766,648us: [+0 T:0x43300490] CV - VISA_delete(0x1439f8)
@5,766,817us: [+5 T:0x43300490] CV - VISA_delete> deleting codec 
(localQueue=0x, remoteQueue=0x)
@5,767,009us: [+0 T:0x43300490] ti.sdo.ce.video1.VIDENC1 - VIDENC1_create> 
return (0x0)
Dvr_Titler Error: Failed to open video encode algorithm: mpeg4enc (0x0)


>From the trace, it looks like cmem is allocating the the memory requested. 
>I've tried passing in the default parameters to the algorithm, the parameters 
>used in the dvsdk encod

how do i enable full speed instead of high speed in the USB

[Gopala Gottumukkala]

I want to use Full speed instead of high speed.  What needs to be done
to work with full speed.

 

Help appreciated, 

Thanks

- Gopala

 

From: Subbrathnam, Swaminathan [mailto:swami.i...@ti.com] 
Sent: Tuesday, January 05, 2010 9:41 AM
To: Gopala Gottumukkala; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: USB storage error

 

Pl. refer to DaVinci Staging GIT kernel hosted at
http://arago-project.org/git/people/?p=sneha/linux-davinci-staging.git;a
=summary.

 



From: Gopala Gottumukkala [mailto:ggott...@cernium.com] 
Sent: Tuesday, January 05, 2010 8:06 PM
To: Subbrathnam, Swaminathan;
davinci-linux-open-source@linux.davincidsp.com
Subject: RE: USB storage error

 

Which kernel version number is working for you can I know the kernel
version number and if any patches please let me know the patches also.

 

- Gopala

 

From: Gopala Gottumukkala 
Sent: Monday, January 04, 2010 9:13 AM
To: 'Subbrathnam, Swaminathan';
davinci-linux-open-source@linux.davincidsp.com
Subject: RE: USB storage error

 

Can I know the latest Davinci Git kernel version which is working for
you.  The kernel version number and where can I down load the latest
one.

 

- Gopala

 

From: Subbrathnam, Swaminathan [mailto:swami.i...@ti.com] 
Sent: Friday, January 01, 2010 8:10 AM
To: Gopala Gottumukkala; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: USB storage error

 

Gopala,

 

Could you try the latest DaVinci Git.  It works for me.

 

regards

swami



From: davinci-linux-open-source-boun...@linux.davincidsp.com
[davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Gopala Gottumukkala [ggott...@cernium.com]
Sent: Friday, January 01, 2010 1:38 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: USB storage error

I have compiled davinci 2.6.30

I mounted the usb manually 

I ran some sample program which will open, write and delete the file
into usb drive.

While writing the file into usb drive.  It gives the following error and
the program dies.

 

Any help would be appreciated on this

 

 

usb 1-1: reset high speed USB device using musb_hdrc and address 2

usb 1-1: reset high speed USB device using musb_hdrc and address 2

usb 1-1: reset high speed USB device using musb_hdrc and address 2

sd 0:0:0:0: Device offlined - not ready after error recovery

sd 0:0:0:0: [sda] Unhandled error code

sd 0:0:0:0: [sda] Result: hostbyte=0x05 driverbyte=0x00

end_request: I/O error, dev sda, sector 41584

sd 0:0:0:0: rejecting I/O to offline device

sd 0:0:0:0: [sda] Unhandled error code

sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00

end_request: I/O error, dev sda, sector 4

sd 0:0:0:0: rejecting I/O to offline device

sd 0:0:0:0: rejecting I/O to offline device

sd 0:0:0:0: rejecting I/O to offline device

sd 0:0:0:0: rejecting I/O to offline device

sd 0:0:0:0: rejecting I/O to offline device

sd 0:0:0:0: rejecting I/O to offline device

sd 0:0:0:0: rejecting I/O to offline device

 

- Gopala

NOTICE: The information contained in this email and any document
attached hereto is intended only for the named recipient(s). It is the
property of Cernium Corporation and shall not be used, disclosed or
reproduced without the express written consent of Cernium Corporation.
If you are not the intended recipient (or the employee or agent
responsible for delivering this message in confidence to the intended
recipient(s)), you are hereby notified that you have received this
transmittal in error, and any review, dissemination, distribution or
copying of this transmittal or its attachments is strictly prohibited.
If you have received this transmittal and/or attachments in error,
please notify me immediately by reply email or telephone and immediately
delete this message and all its attachments. Thank you. 

NOTICE: The information contained in this email and any document
attached hereto is intended only for the named recipient(s). It is the
property of Cernium Corporation and shall not be used, disclosed or
reproduced without the express written consent of Cernium Corporation.
If you are not the intended recipient (or the employee or agent
responsible for delivering this message in confidence to the intended
recipient(s)), you are hereby notified that you have received this
transmittal in error, and any review, dissemination, distribution or
copying of this transmittal or its attachments is strictly prohibited.
If you have received this transmittal and/or attachments in error,
please notify me immediately by reply email or telephone and immediately
delete this message and all its attachments. 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

RE: Arago Kerenel w/ codec_engine_2_00_01 issues?

[Ring, Chris]

First, it looks like your on a DM355 or DM365 as this codec is 'local' (i.e. 
running on the same processor as your app).  That helps eliminate some 
complexity (e.g. no DSP Link, and no DSKT2... the warning msg is misleading - 
there's no DSKT2 in a DM355/365 system).

Also from the trace, I can see that the memory requested by the alg succeeds 
(the codec needs 7 distinct memory blocks, and I can see 7 successful CMEM 
alloc() calls being made).

However, during the algInit() call (where Codec Engine provides this newly 
allocated memory to the codec), the codec is returning 49280 (0xC080).  So the 
codec didn't like something it was given - either the memory (unlikely) or the 
creation params(?) - and returned this error.

Do the codec docs (or headers?) provide any details about this specific error 
code (0xC080)?  Does it fail if you pass in NULL as the create() params?

Finally, to your specific question, the error returned (mpeg4enc (0x0)) 
indicates a NULL handle, not a success code.

Chris 

> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com 
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
] On Behalf Of Paul Stuart
> Sent: Tuesday, January 05, 2010 7:26 AM
> To: Tivy, Robert; davinci-linux-open-source@linux.davincidsp.com
> Subject: RE: Arago Kerenel w/ codec_engine_2_00_01 issues?
> 
> Thanks for the response!
> 
> I'll give the latest CMEM, LinuxUtils, et al a whirl and see 
> what happens. The strange thing is that the mpeg4 decoder, 
> jpeg encode/decode, and mp3 encode/decode all load without 
> complaint. It's just the mpeg4enc that fails.
> 
> 
> I've rebuilt cmemk.ko and dm350mmap.ko against the arago 
> kernel. Neither process was straight forward though because 
> of changes between the montavista kernel we were using. Maybe 
> something got botched in the process.
> 
> 
> Turning on the trace, with CE_DEBUG=2, I get the following 
> during mpeg4enc initialization:
> 
> 
> @5,653,051us: [+0 T:0x43300490] ti.sdo.ce.video1.VIDENC1 - 
> VIDENC1_create> Enter (engine=0x100670, name='mpeg4enc', 
> params=0x432ffca8)
> @5,653,350us: [+0 T:0x43300490] CV - VISA_create(0x100670, 
> 'mpeg4enc', 0x432ffca8, 0x2496, 'ti.sdo.ce.video1.IVIDENC1')
> @5,653,569us: [+0 T:0x43300490] CV - VISA_create2(0x100670, 
> 'mpeg4enc', 0x432ffca8, 0x30, 0x2496, 'ti.sdo.ce.video1.IVIDENC1')
> @5,654,187us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - 
> Algorithm_create> Enter(fxns=0xf89c0, idma3Fxns=0xf8988, 
> iresFxns=0x0, params=0x432ffca8, attrs=0x432ffac8)
> @5,654,470us: [+0 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create> Enter (scratchId=1, fxns=0xf89c0, parentAlg=0x0, 
> params=0x432ffca8)
> @5,678,280us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create> algNumAlloc 7 memory recs
> @5,678,574us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create> algAlloc returned numRecs=7
> @5,678,777us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create>  Memory requested memTab[0]: size=0x2c58, 
> align=0x100, space=0x11, attrs=0x1
> @5,678,985us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create>  Memory requested memTab[1]: size=0x200, 
> align=0x100, space=0x11, attrs=0x1
> @5,679,182us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create>  Memory requested memTab[2]: size=0x19a400, 
> align=0x100, space=0x11, attrs=0x1
> @5,679,568us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create>  Memory requested memTab[3]: size=0x10e0, 
> align=0x100, space=0x11, attrs=0x1
> @5,679,816us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create>  Memory requested memTab[4]: size=0x4, 
> align=0x100, space=0x11, attrs=0x1
> @5,680,026us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create>  Memory requested memTab[5]: size=0x14000, 
> align=0x100, space=0x11, attrs=0x1
> @5,680,233us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create>  Memory requested memTab[6]: size=0x3840, 
> align=0x100, space=0x11, attrs=0x1
> @5,680,648us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_alloc(11352) = 0x43301000.
> @5,680,909us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_getPhys(0x43301000) = 0x8702c000.
> @5,681,514us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_alloc(512) = 0x42a02000.
> @5,681,792us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_getPhys(0x42a02000) = 0x87018000.
> @5,682,401us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_alloc(1680384) = 0x43305000.
> @5,682,711us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_getPhys(0x43305000) = 0x87e0.
> @5,698,324us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_alloc(4320) = 0x43505000.
> @5,698,622us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_getPhys(0x43505000) = 0x8702a000.
> @5,699,098us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_alloc(4) = 0x43507000.
> @5,699,535us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_getPhys(0x43507000) = 0x87019000.
> @5,700,033us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_alloc(81920) = 0x43508

Default config file when we do make menuconfig

[Gopala Gottumukkala]

Hello Gurus,

Looks to me like when I download a new kernel from the git or arago and
do make menuconfig I don't see Davinci related arch. I need to do make
arch-arm davinci_all_defconfig.  Then do the make.  Is there a way where
you can include the davinci related arch in the system arch.

- Gopala


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

[PATCH] MMC: DaVinci: Fixed typos in comments of the response registers in davinci_mmc.c

[raghav n]

[PATCH 1/1] MMC: DaVinci: Fixed typos in comments of the response
registers in davinci_mmc.c

This patch fixes the typos in the comments for the MMC response
registers. They were all /* Response Register 0 and 1 */

Signed-off-by: raghav.m...@gmail.com
---
>From 08e00d18ca5d0c20a9035c631e7fcb5f39c88cb8 Mon Sep 17 00:00:00 2001
From: raghav 

Date: Tue, 5 Jan 2010 23:57:17 +0530
Subject: [PATCH] Fixed comments for the response registers. They were
all saying Regiser 0 and 1.

---
 drivers/mmc/host/davinci_mmc.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index dd45e7c..73a6a14 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -54,9 +54,9 @@
 #define DAVINCI_MMCCMD   0x30 /* Command Register  */

 #define DAVINCI_MMCARGHL 0x34 /* Argument Register */
 #define DAVINCI_MMCRSP01 0x38 /* Response Register 0 and 1 */
-#define DAVINCI_MMCRSP23 0x3C /* Response Register 0 and 1 */

-#define DAVINCI_MMCRSP45 0x40 /* Response Register 0 and 1 */
-#define DAVINCI_MMCRSP67 0x44 /* Response Register 0 and 1 */
+#define DAVINCI_MMCRSP23 0x3C /* Response Register 2 and 3 */

+#define DAVINCI_MMCRSP45 0x40 /* Response Register 4 and 5 */
+#define DAVINCI_MMCRSP67 0x44 /* Response Register 6 and 7 */
 #define DAVINCI_MMCDRSP  0x48 /* Data Response Register*/

 #define DAVINCI_MMCETOK  0x4C
 #define DAVINCI_MMCCIDX  0x50 /* Command Index Register*/
--
1.6.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

use NAND Flash MT29F2G08ABD (Micron)

[Naresh Kansara]

Hello All,

Has anybody have used this NAND Flash with Davinci? The device
(manufacture id is 0x2C & device id is 0xAA). I can load both the
ubl_davinci_nand.bin and u-boot-594-nand.bin through CCS(Code Composer
Studio).  After I remove the JTAG connector and re-apply the power, the
RBL still seem not to find this NAND device(get BOOTME message )

Any suggestion is appreciated.

 

Regards,

 

 

Naresh Kansara

Irvine Sensors Corporation

phone: (714)-435-8928

email: nkans...@irvine-sensors.com

 

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

Re: use NAND Flash MT29F2G08ABD (Micron)

[Steve Chen]

On Tue, 2010-01-05 at 12:12 -0800, Naresh Kansara wrote:
> Hello All,
> 
> Has anybody have used this NAND Flash with Davinci? The device
> (manufacture id is 0x2C & device id is 0xAA). I can load both the
> ubl_davinci_nand.bin and u-boot-594-nand.bin through CCS(Code Composer
> Studio).  After I remove the JTAG connector and re-apply the power,
> the RBL still seem not to find this NAND device(get BOOTME message )
> 
> Any suggestion is appreciated.

I have not used this part, but I heard that Micron NANDs comes up in
power-save mode which can cause strange behaviors.

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: [PATCH] MMC: DaVinci: Fixed typos in comments of the response registers in davinci_mmc.c

[Kevin Hilman]

raghav n  writes:

> [PATCH 1/1] MMC: DaVinci: Fixed typos in comments of the response registers 
> in davinci_mmc.c

You don't need to duplicate the subject in the changelog.

> This patch fixes the typos in the comments for the MMC response registers. 
> They were all /* Response Register 0 and 1 */
>
> Signed-off-by: raghav.m...@gmail.com

Thanks, will que

> ---
> From 08e00d18ca5d0c20a9035c631e7fcb5f39c88cb8 Mon Sep 17 00:00:00 2001
> From: raghav 
>
> Date: Tue, 5 Jan 2010 23:57:17 +0530
> Subject: [PATCH] Fixed comments for the response registers. They were all 
> saying Regiser 0 and 1.

You've got duplicate headers/changelog etc. here.

I highly recommend using git-format-patch + git-send-email to send patches?

> ---
>  drivers/mmc/host/davinci_mmc.c |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)

The patch itself looks fine.  After cleaning up the changelog, I'll
queue for 2.6.33-rc fixes series.

Kevin

>
>
> diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
> index dd45e7c..73a6a14 100644
> --- a/drivers/mmc/host/davinci_mmc.c
> +++ b/drivers/mmc/host/davinci_mmc.c
> @@ -54,9 +54,9 @@
>  #define DAVINCI_MMCCMD   0x30 /* Command Register  */
>
>
>  #define DAVINCI_MMCARGHL 0x34 /* Argument Register */
>  #define DAVINCI_MMCRSP01 0x38 /* Response Register 0 and 1 */
> -#define DAVINCI_MMCRSP23 0x3C /* Response Register 0 and 1 */
>
>
> -#define DAVINCI_MMCRSP45 0x40 /* Response Register 0 and 1 */
> -#define DAVINCI_MMCRSP67 0x44 /* Response Register 0 and 1 */
> +#define DAVINCI_MMCRSP23 0x3C /* Response Register 2 and 3 */
>
>
> +#define DAVINCI_MMCRSP45 0x40 /* Response Register 4 and 5 */
> +#define DAVINCI_MMCRSP67 0x44 /* Response Register 6 and 7 */
>  #define DAVINCI_MMCDRSP  0x48 /* Data Response Register*/
>
>
>  #define DAVINCI_MMCETOK  0x4C
>  #define DAVINCI_MMCCIDX  0x50 /* Command Index Register*/
> --
> 1.6.0.4
>
>
> ___
> 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] MMC: DaVinci: Fixed typos in comments of the response registers in davinci_mmc.c

[Kevin Hilman]

Kevin Hilman wrote:

raghav n  writes:


[PATCH 1/1] MMC: DaVinci: Fixed typos in comments of the response registers in 
davinci_mmc.c


You don't need to duplicate the subject in the changelog.


This patch fixes the typos in the comments for the MMC response registers. They 
were all /* Response Register 0 and 1 */

Signed-off-by: raghav.m...@gmail.com


Thanks, will que


---
From 08e00d18ca5d0c20a9035c631e7fcb5f39c88cb8 Mon Sep 17 00:00:00 2001
From: raghav 

Date: Tue, 5 Jan 2010 23:57:17 +0530
Subject: [PATCH] Fixed comments for the response registers. They were all 
saying Regiser 0 and 1.


You've got duplicate headers/changelog etc. here.

I highly recommend using git-format-patch + git-send-email to send patches?


---
 drivers/mmc/host/davinci_mmc.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)


The patch itself looks fine.  After cleaning up the changelog, I'll
queue for 2.6.33-rc fixes series.


After trying to apply this, the patch is corrupted in other ways and 
doesn't apply cleanly.


Please fix up the patch to apply against current davinci git and resend, 
preferably using git-format-patch + git-send-email.


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 0/9] davinci: EDMA updates

[Kevin Hilman]

Sudhakar Rajashekhara  writes:

> This patch set corrects some issues with the existing EDMA
> driver and also adds support for EDMA resource (channel/slots)
> sharing between two processors (say ARM and DSP).
>
> The patch set has been tested on DM646x, OMAP-L137 and OMAP-L138
> EVM boards.

Hi Sudhakar,

This series looks good.  One minor request.  

For the last three patches, I think it would be helpful to describe in
the changelog or even better at the definition of the reserved arrays
what the channels are being reserved for.

Kevin


> Sudhakar Rajashekhara (9):
>   davinci: Correct return value of edma_alloc_channel api
>   davinci: Keep count of channel controllers on a platform
>   davinci: Fix edma_alloc_channel api for EDMA_CHANNEL_ANY case
>   davinci: build list of unused EDMA events dynamically
>   davinci: support for EDMA resource sharing
>   davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138
>   davinci: da830/omapl137: Specify reserved channels/slots
>   davinci: da850/omapl138: Specify reserved channels/slots
>   davinci: dm646x: Specify reserved EDMA channel/slots for DM646x
>
>  arch/arm/mach-davinci/devices-da8xx.c |  181 ++--
>  arch/arm/mach-davinci/dm355.c |8 --
>  arch/arm/mach-davinci/dm644x.c|   10 --
>  arch/arm/mach-davinci/dm646x.c|   28 -
>  arch/arm/mach-davinci/dma.c   |  101 ++---
>  arch/arm/mach-davinci/include/mach/edma.h |4 +-
>  6 files changed, 276 insertions(+), 56 deletions(-)
>
> ___
> 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: Arago Kerenel w/ codec_engine_2_00_01 issues?

[Tivy, Robert]

 
Chris has already responded to your other issues, so please see just one 
comment from me below.

Regards,

- Rob

> -Original Message-
> From: Paul Stuart [mailto:paul_stu...@seektech.com] 
> Sent: Tuesday, January 05, 2010 7:26 AM
> To: Tivy, Robert; davinci-linux-open-source@linux.davincidsp.com
> Subject: RE: Arago Kerenel w/ codec_engine_2_00_01 issues?
> 
> Thanks for the response!
> 
> I'll give the latest CMEM, LinuxUtils, et al a whirl and see 
> what happens. The strange thing is that the mpeg4 decoder, 
> jpeg encode/decode, and mp3 encode/decode all load without 
> complaint. It's just the mpeg4enc that fails.
> 
> 
> I've rebuilt cmemk.ko and dm350mmap.ko against the arago 
> kernel. Neither process was straight forward though because 
> of changes between the montavista kernel we were using. Maybe 
> something got botched in the process.

One of the reasons to upgrade to the latest LinuxUtils is that they've been 
ported to the recent DaVinci GIT kernel releases, although I don't know if the 
MontaVista changes have kept up-to-date with the GIT changes.

> 
> 
> Turning on the trace, with CE_DEBUG=2, I get the following 
> during mpeg4enc initialization:
> 
> 
> @5,653,051us: [+0 T:0x43300490] ti.sdo.ce.video1.VIDENC1 - 
> VIDENC1_create> Enter (engine=0x100670, name='mpeg4enc', 
> params=0x432ffca8)
> @5,653,350us: [+0 T:0x43300490] CV - VISA_create(0x100670, 
> 'mpeg4enc', 0x432ffca8, 0x2496, 'ti.sdo.ce.video1.IVIDENC1')
> @5,653,569us: [+0 T:0x43300490] CV - VISA_create2(0x100670, 
> 'mpeg4enc', 0x432ffca8, 0x30, 0x2496, 'ti.sdo.ce.video1.IVIDENC1')
> @5,654,187us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - 
> Algorithm_create> Enter(fxns=0xf89c0, idma3Fxns=0xf8988, 
> iresFxns=0x0, params=0x432ffca8, attrs=0x432ffac8)
> @5,654,470us: [+0 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create> Enter (scratchId=1, fxns=0xf89c0, parentAlg=0x0, 
> params=0x432ffca8)
> @5,678,280us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create> algNumAlloc 7 memory recs
> @5,678,574us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create> algAlloc returned numRecs=7
> @5,678,777us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create>  Memory requested memTab[0]: size=0x2c58, 
> align=0x100, space=0x11, attrs=0x1
> @5,678,985us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create>  Memory requested memTab[1]: size=0x200, 
> align=0x100, space=0x11, attrs=0x1
> @5,679,182us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create>  Memory requested memTab[2]: size=0x19a400, 
> align=0x100, space=0x11, attrs=0x1
> @5,679,568us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create>  Memory requested memTab[3]: size=0x10e0, 
> align=0x100, space=0x11, attrs=0x1
> @5,679,816us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create>  Memory requested memTab[4]: size=0x4, 
> align=0x100, space=0x11, attrs=0x1
> @5,680,026us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create>  Memory requested memTab[5]: size=0x14000, 
> align=0x100, space=0x11, attrs=0x1
> @5,680,233us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create>  Memory requested memTab[6]: size=0x3840, 
> align=0x100, space=0x11, attrs=0x1
> @5,680,648us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_alloc(11352) = 0x43301000.
> @5,680,909us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_getPhys(0x43301000) = 0x8702c000.
> @5,681,514us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_alloc(512) = 0x42a02000.
> @5,681,792us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_getPhys(0x42a02000) = 0x87018000.
> @5,682,401us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_alloc(1680384) = 0x43305000.
> @5,682,711us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_getPhys(0x43305000) = 0x87e0.
> @5,698,324us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_alloc(4320) = 0x43505000.
> @5,698,622us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_getPhys(0x43505000) = 0x8702a000.
> @5,699,098us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_alloc(4) = 0x43507000.
> @5,699,535us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_getPhys(0x43507000) = 0x87019000.
> @5,700,033us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_alloc(81920) = 0x43508000.
> @5,700,348us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_getPhys(0x43508000) = 0x8704e000.
> @5,701,570us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_alloc(14400) = 0x4351c000.
> @5,701,844us: [+4 T:0x43300490] OM - Memory_contigAlloc> 
> CMEM_getPhys(0x4351c000) = 0x8703.
> @5,757,804us: [+7 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create> algInit call failed 49280
> @5,765,522us: [+0 T:0x43300490] ti.sdo.ce.osal.alg - 
> ALG_create> Exit (algHandle=NULL)
> @5,765,791us: [+7 T:0x43300490] ti.sdo.ce.alg.Algorithm - 
> Algorithm_create> Algorithm creation FAILED; make sure that 
> 1) alg params are correct/appropriate, 2) there is enough 
> internal and external algorithm memory available -- check 
> DSKT2 settings for heap assignments and sc

RE: Cmem address translation when working with Codec Engine

[Tivy, Robert]

This sounds like an odd setup, how are you even calling the codec if not 
through CE?

Since the first codec is assuming responsibility for doing "first" things, like 
calling CERuntime_init(), can't it also call Memory_registerContigBuf()?  From 
your earlier descriptions it sounds like you might need a way to inform this 
first codec of the (big CMEM) buffer size to register, but communicating that 
info sounds easier than tracking small buffer subdivisions.

Regards,

- Rob

> -Original Message-
> From: 
> davinci-linux-open-source-bounces+rtivy=ti@linux.davincids
> p.com 
> [mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.d
> avincidsp.com] On Behalf Of Erez Kinarti
> Sent: Tuesday, January 05, 2010 1:26 AM
> To: Vladimir Pantelic; Davinci-linux-open-source@linux.davincidsp.com
> Cc: Davinci-linux-open-source@linux.davincidsp.com
> Subject: RE: Cmem address translation when working with Codec Engine
> 
> No, because in my system, the first codec that is generated 
> is calling CERuntimeInit (working with C++, keeping reference 
> counter for the call to CERuntimeInit and CERuntimeExit), 
> while the system buffers are allocated before that.
> 
> 
> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
> ] On Behalf Of Vladimir Pantelic
> Sent: Tuesday, January 05, 2010 11:15 AM
> To: Davinci-linux-open-source@linux.davincidsp.com
> Cc: Davinci-linux-open-source@linux.davincidsp.com
> Subject: Re: Cmem address translation when working with Codec Engine
> 
> Erez Kinarti wrote:
> > Hey Rob,
> > I see that calling the register functions require that CE is in the
> air
> > (CERuntimeInit) so it is problematic for us in the same way as doing
> the
> > CMEM allocations via CodecEngine.
> 
> as you have to call CERuntimeInit() before using any of CE, 
> you can do the
> Memory_registerContigBuf() after CERuntimeInit(), no?
> 
> 
> ___
> 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: [PATCH v2 3/4] i2c: davinci: Add suspend/resume support

[Kevin Hilman]

Chaithrika U S  writes:

> Add suspend and resume callbacks to DaVinci I2C driver.
> This has been tested on DA850/OMAP-L138 EVM. The SoC specific
> suspend-to-RAM support patch series [1] is needed to test this feature.
>
> [1] http://linux.davincidsp.com/pipermail/davinci-linux-open-source/
> 2009-November/016958.html
>
> Signed-off-by: Chaithrika U S 
> ---
>  drivers/i2c/busses/i2c-davinci.c |   32 
>  1 files changed, 32 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-davinci.c 
> b/drivers/i2c/busses/i2c-davinci.c
> index 81c1049..c1c2909 100644
> --- a/drivers/i2c/busses/i2c-davinci.c
> +++ b/drivers/i2c/busses/i2c-davinci.c
> @@ -622,6 +622,36 @@ static int davinci_i2c_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> +#ifdef CONFIG_PM
> +static int davinci_i2c_suspend(struct platform_device *pdev, pm_message_t 
> state)
> +{
> + struct davinci_i2c_dev *dev = platform_get_drvdata(pdev);
> +
> + /* put I2C into reset */
> + davinci_i2c_reset_ctrl(dev, 0);
> +
> + clk_disable(dev->clk);
> +
> + return 0;
> +}
> +
> +static int davinci_i2c_resume(struct platform_device *pdev)
> +{
> + struct davinci_i2c_dev *dev = platform_get_drvdata(pdev);
> +
> + clk_enable(dev->clk);
> +
> + /* take I2C out of reset */
> + davinci_i2c_reset_ctrl(dev, 1);
> +
> + return 0;
> +}
> +
> +#else
> +#define davinci_i2c_suspend NULL
> +#define davinci_i2c_resume NULL
> +#endif
> +
>  /* work with hotplug and coldplug */
>  MODULE_ALIAS("platform:i2c_davinci");
>  
> @@ -632,6 +662,8 @@ static struct platform_driver davinci_i2c_driver = {
>   .name   = "i2c_davinci",
>   .owner  = THIS_MODULE,
>   },
> + .suspend= davinci_i2c_suspend,
> + .resume = davinci_i2c_resume,

Rather than adding these to the platform_driver, you should use dev_pm_ops.

Something like the patch below on top of your PATCH 3/4 should work.

Other than this, I'm OK with this series, feel free to add my signoff
and resend to linux-i2c and LKML.  linux-i2c has had very slow
response to embedded patches lately.

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: Cmem address translation when working with Codec Engine

[Tivy, Robert]

I would expect that the size that you use is good enough for the 
Memory_registerContigBuf() call.

The only way you can query the size of the buffers allocated by CMEM is to do 
so in a non-direct manner, by performing "%cat /proc/cmem" and parsing the 
ASCII output (try out that command, you'll see what I mean).

- Rob

> -Original Message-
> From: Erez Kinarti [mailto:er...@radvision.com] 
> Sent: Tuesday, January 05, 2010 12:21 AM
> To: Tivy, Robert; Vladimir Pantelic; 
> Davinci-linux-open-source@linux.davincidsp.com
> Subject: RE: Cmem address translation when working with Codec Engine
> 
> Thank you very much Rob,
> I'm going to try it now.
> Just one open issue is the size of the big buffer:
> In the app I cannot be sure what is the buffer size that CMEM 
> allocated for me, I just know that the size is at least the 
> size that I requested.
> Do I have to put the size parameter in these function the 
> exact size allocated by CMEM, or just the size that I use is enough?
> In case I must use the size allocated by CMEM, is there a way 
> to know what this size is?
> 
> Thanks,
> Erez
> 
> 
> -Original Message-
> From: Tivy, Robert [mailto:rt...@ti.com]
> Sent: Tuesday, January 05, 2010 1:30 AM
> To: Erez Kinarti; Vladimir Pantelic;
> Davinci-linux-open-source@linux.davincidsp.com
> Subject: RE: Cmem address translation when working with Codec Engine
> 
> 
> There is no function available to invalidate all the Memory module
> virt-phys translations.
> 
> If your app structure allows it, you can call
> Memory_registerContigBuf(bigCMEMBufferVirtAddr, 258048,
> CMEM_getPhys(bigCMEMBufferVirtAddr));
> once, and all smaller subdivided buffers will be covered by this one
> registration (or, even simpler, just call
> Memory_getBufferPhysicalAddress(bigCMEMBufferVirtAddr, 258048,
> NULL);
> and ignore the result, which will do the CMEM_getPhys() for you and
> register it).  You can then call
> Memory_unregisterContigBuf(bigCMEMBufferVirtAddr, 258048) once when
> you're ready to free the CMEM buffer.  FYI, if you want to 
> double-check
> me, you can call Memory_dumpKnownContigBufsList() to display 
> (through GT
> tracing) the contig buffer list (AKA, the Memory module virt-phys
> translation table).
> 
> Regards,
> 
> - Rob
> 
> > -Original Message-
> > From: davinci-linux-open-source-boun...@linux.davincidsp.com 
> > [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
> > ] On Behalf Of Erez Kinarti
> > Sent: Monday, January 04, 2010 9:15 AM
> > To: Vladimir Pantelic; 
> Davinci-linux-open-source@linux.davincidsp.com
> > Subject: RE: Cmem address translation when working with Codec Engine
> > 
> > Thank you Vladimir,
> > But we are not able to allocate and free via CodecEngine due 
> > to the structure of our application and the need to call the 
> > alloc not before calling CERuntimeInit().
> > 
> > 
> > -Original Message-
> > From: davinci-linux-open-source-boun...@linux.davincidsp.com
> > [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
> > ] On Behalf Of Vladimir Pantelic
> > Sent: Monday, January 04, 2010 7:09 PM
> > To: Davinci-linux-open-source@linux.davincidsp.com
> > Subject: Re: Cmem address translation when working with Codec Engine
> > 
> > Erez Kinarti wrote:
> > > Thanks a lot Rob.
> > >
> > > calling this function for each of the pointers used with 
> > CodecEngine 
> > > solved the problem.
> > >
> > > However, we need something else, some function that 
> invalidates all
> > this
> > > virt->phy table and not each of the virtual pointers separately.
> > >
> > > Is there a way to do a full invalidate in a single call 
> > without keep 
> > > tracking on each of the virtual pointers?
> > >
> > > The reason that Memory_unregisterContigBuf it is not 
> enough for us:
> > >
> > > In our system, we allocate a very big buffer from CMEM 
> > (258048 bytes), 
> > > but we don't call CodecEngine with a pointer to the big buffer.
> > 
> > You dont need to call Memory_unregisterContigBuf, just alloc 
> > and free the buffers via CE and CE will know that you are 
> > calling it with a smaller buffer inside a larger one that it 
> > knows the translation to...
> > 
> > ___
> > 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: [PATCH v2] davinci: add CDCE949 support on DM6467 EVM

[Kevin Hilman]

Sekhar Nori  writes:

> From: Nageswari Srinivasan 
>
> This patch adds the CDCE949 reference oscillator to
> the davinci clock list.
>
> On the DM6467T EVM, the CDCE949 is responsible for
> generating the pixel clock for display. On the DM6467
> EVM, this pixel clock was being obtained from an
> internal source. This is not possible on the DM6467T
> EVM because of the presence of a 33MHz oscillator.
>
> The TSIF module also requires the CDCE949 to generate
> the data clocks.
>
> The actual clock definitions will be added by patches
> adding support for DM6467T VPIF and TSIF. This patch
> mearly lays the foundation for that work.
>
> Signed-off-by: Nageswari Srinivasan 
> Signed-off-by: Sekhar Nori 
> ---
> Since v1, ALWAYS_ENABLED flag has been removed from cdce_clk_in

Looks good, applying to davinc git and queueing in davinci-next for
2.6.34.

Kevin

>  arch/arm/mach-davinci/Makefile   |2 +-
>  arch/arm/mach-davinci/board-dm646x-evm.c |   31 
> ++
>  2 files changed, 32 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
> index eeb9230..7e806b0 100644
> --- a/arch/arm/mach-davinci/Makefile
> +++ b/arch/arm/mach-davinci/Makefile
> @@ -26,7 +26,7 @@ obj-$(CONFIG_MACH_SFFSDR)   += board-sffsdr.o
>  obj-$(CONFIG_MACH_NEUROS_OSD2)   += board-neuros-osd2.o
>  obj-$(CONFIG_MACH_DAVINCI_DM355_EVM) += board-dm355-evm.o
>  obj-$(CONFIG_MACH_DM355_LEOPARD) += board-dm355-leopard.o
> -obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM)+= board-dm646x-evm.o
> +obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM)+= board-dm646x-evm.o cdce949.o
>  obj-$(CONFIG_MACH_DAVINCI_DM365_EVM) += board-dm365-evm.o
>  obj-$(CONFIG_MACH_DAVINCI_DA830_EVM) += board-da830-evm.o
>  obj-$(CONFIG_MACH_DAVINCI_DA850_EVM) += board-da850-evm.o
> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c 
> b/arch/arm/mach-davinci/board-dm646x-evm.c
> index 6ff3411..6c7c604 100644
> --- a/arch/arm/mach-davinci/board-dm646x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c
> @@ -40,6 +40,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "clock.h"
>  
> @@ -389,6 +391,9 @@ static struct i2c_board_info __initdata i2c_info[] =  {
>   {
>   I2C_BOARD_INFO("cpld_video", 0x3b),
>   },
> + {
> + I2C_BOARD_INFO("cdce949", 0x6c),
> + },
>  };
>  
>  static struct davinci_i2c_platform_data i2c_pdata = {
> @@ -681,9 +686,35 @@ static void __init evm_init_i2c(void)
>   evm_init_video();
>  }
>  
> +#define CDCE949_XIN_RATE 2700
> +
> +/* CDCE949 support - "lpsc" field is overridden to work as clock number */
> +static struct clk cdce_clk_in = {
> + .name   = "cdce_xin",
> + .rate   = ATOMIC_INIT(CDCE949_XIN_RATE),
> +};
> +
> +static struct davinci_clk cdce_clks[] = {
> + CLK(NULL, "xin", &cdce_clk_in),
> + CLK(NULL, NULL, NULL),
> +};
> +
> +static void __init cdce_clk_init(void)
> +{
> + struct davinci_clk *c;
> + struct clk *clk;
> +
> + for (c = cdce_clks; c->lk.clk; c++) {
> + clk = c->lk.clk;
> + clkdev_add(&c->lk);
> + clk_register(clk);
> + }
> +}
> +
>  static void __init davinci_map_io(void)
>  {
>   dm646x_init();
> + cdce_clk_init();
>  }
>  
>  static struct davinci_uart_config uart_config __initdata = {
> -- 
> 1.6.2.4
>
> ___
> 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: codec hangs

[Tivy, Robert]

The message handling on the DSP is performed by the same thread (a DSP/BIOS 
TSK) as the codec's "control()" thread.  So, once the DSP gets the CONTROL 
command for the codec, it calls the codec's control() function, and upon 
returning from that control() function sends the "reply" command that gets 
picked up by the ARM app.  If the control() function never returns, the "reply" 
message will never be received by the ARM.  It is my assumption that the 
codec's control() function is not returning for whatever reason.  You could try 
general things, such as increasing the DSP/BIOS TSK's stack size for the codec, 
but even though you don't have the TI codec's source code you could still put a 
BP on the codec's control() function and step it at the assembly level, or just 
see if it ever returns.  If it doesn't return, it could be either a codec 
problem or a general DSP/BIOS system problem (such as not enough stack for the 
codec TSK).

Regards,

- Rob


From: Albert Burbea [mailto:alber...@gmail.com]
Sent: Monday, January 04, 2010 11:55 PM
To: Tivy, Robert
Cc: davinci-linux-open-source
Subject: Re: codec hangs

Hi
thanks for your help - the problem is that the JPEG codec is TI's and I do not 
have access to its source code.
What could hang the message queue ?
Thanks again
Albert

On Tue, Jan 5, 2010 at 3:47 AM, Tivy, Robert 
mailto:rt...@ti.com>> wrote:
Nothing comes to mind from just your description.  BTW, that "really strange" 
address (0xbeffc850) seems like a Linux user stack address.

Since nothing jumps out from your top-down description, I would suggest a 
bottom-up investigation - debugging the DSP.  Seems that the codec's 
"control()" code is sending the DSP into the weeds, at least with the 
parameters passed in.  I would suggest putting a BP on the codec's "control()" 
function and stepping that function to see where the DSP goes bad.

Regards,

- Rob


From: 
davinci-linux-open-source-boun...@linux.davincidsp.com
 
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com]
 On Behalf Of Albert Burbea
Sent: Tuesday, December 29, 2009 11:22 AM
To: davinci-linux-open-source
Subject: codec hangs

Hi everybody,
I am using mv 4.01 with codec engine 2.01. I am integrating the TI JPEG encoder 
1.1.13. At the beginning it did not work,it did not even open,  until I 
modified the JPEGENC.xs to return the saram and daram scratch sizes. Before 
that, I modified also the ce/JPEGENC.xdc to use an IMGENC1 VISA interface 
instead of the IMGENC interface. I was able to open it and do an XDM_SETPARAMS 
control, but I did not try anything more. I restored the IMGENC interface in 
ce/JPEGENC.xdc, and compiled. Still worked. Then, I added a CMEM allocation for 
the output buffer, and... it hangs! Of course I removed the allocation and 
retried, but nope, I can only open it. Wen I execute the  XDM_SETPARAMS, 
everything seems fine until the VISA_call for the XDM_SETPARAMS. The pointers 
it receives seem really strange to me, one of them if beffc850 or something 
like. It only enters the call, is able to queue the call, but then waits 
forever for the message queue to return, and everyting dies.
What can be the problem? I verified several times the tcf file and the cmem 
settings and seem correct to me.
Thanks in advance
Albert

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



--
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: [PATCH v2] davinci: add CDCE949 support on DM6467 EVM

[Kevin Hilman]

On Tue, Jan 5, 2010 at 3:04 PM, Kevin Hilman
 wrote:
> Sekhar Nori  writes:
>
>> From: Nageswari Srinivasan 
>>
>> This patch adds the CDCE949 reference oscillator to
>> the davinci clock list.
>>
>> On the DM6467T EVM, the CDCE949 is responsible for
>> generating the pixel clock for display. On the DM6467
>> EVM, this pixel clock was being obtained from an
>> internal source. This is not possible on the DM6467T
>> EVM because of the presence of a 33MHz oscillator.
>>
>> The TSIF module also requires the CDCE949 to generate
>> the data clocks.
>>
>> The actual clock definitions will be added by patches
>> adding support for DM6467T VPIF and TSIF. This patch
>> mearly lays the foundation for that work.
>>
>> Signed-off-by: Nageswari Srinivasan 
>> Signed-off-by: Sekhar Nori 
>> ---
>> Since v1, ALWAYS_ENABLED flag has been removed from cdce_clk_in
>
> Looks good, applying to davinc git and queueing in davinci-next for
> 2.6.34.
>

I responded too soon.  This doesn't compile...

>
>>  arch/arm/mach-davinci/Makefile           |    2 +-
>>  arch/arm/mach-davinci/board-dm646x-evm.c |   31 
>> ++
>>  2 files changed, 32 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
>> index eeb9230..7e806b0 100644
>> --- a/arch/arm/mach-davinci/Makefile
>> +++ b/arch/arm/mach-davinci/Makefile
>> @@ -26,7 +26,7 @@ obj-$(CONFIG_MACH_SFFSDR)           += board-sffsdr.o
>>  obj-$(CONFIG_MACH_NEUROS_OSD2)               += board-neuros-osd2.o
>>  obj-$(CONFIG_MACH_DAVINCI_DM355_EVM) += board-dm355-evm.o
>>  obj-$(CONFIG_MACH_DM355_LEOPARD)     += board-dm355-leopard.o
>> -obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM)        += board-dm646x-evm.o
>> +obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM)        += board-dm646x-evm.o cdce949.o
>>  obj-$(CONFIG_MACH_DAVINCI_DM365_EVM) += board-dm365-evm.o
>>  obj-$(CONFIG_MACH_DAVINCI_DA830_EVM) += board-da830-evm.o
>>  obj-$(CONFIG_MACH_DAVINCI_DA850_EVM) += board-da850-evm.o
>> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c 
>> b/arch/arm/mach-davinci/board-dm646x-evm.c
>> index 6ff3411..6c7c604 100644
>> --- a/arch/arm/mach-davinci/board-dm646x-evm.c
>> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c
>> @@ -40,6 +40,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 

...since this file doesn't exist yet.

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: Arago Kerenel w/ codec_engine_2_00_01 issues?

[Paul Stuart]

Hi,
  Thanks for the info. I've updated to the latest cmemk.ko and dm350mmap.ko 
modules and still have the issue. Also fails if I pass NULL for the parameter 
structure instead of the defaults. 

If 0xC080 refers to the M355_MPEG4E_ERROR structure as defined in the MPEG4ENC 
user guide (which I'm not it does, could be a wild assumption), then the error 
reported would be DM355_MPEG4E_INVALID_FRAMERATE, 
DM355_MPEG4E_INVALID_INTRATHRES, and an undefined bit (15). Passing in NULL or 
using the default parameters, I wouldn't expect to run into these errors. 

Could this have anything to do with the changes to the edma api between the 
montavista kernel and the latest arago distribution? Grasping at straws here...

thanks!
Paul

From: Ring, Chris [cr...@ti.com]
Sent: Tuesday, January 05, 2010 7:57 AM
To: Paul Stuart; Tivy, Robert; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: Arago Kerenel w/ codec_engine_2_00_01 issues?

First, it looks like your on a DM355 or DM365 as this codec is 'local' (i.e. 
running on the same processor as your app).  That helps eliminate some 
complexity (e.g. no DSP Link, and no DSKT2... the warning msg is misleading - 
there's no DSKT2 in a DM355/365 system).

Also from the trace, I can see that the memory requested by the alg succeeds 
(the codec needs 7 distinct memory blocks, and I can see 7 successful CMEM 
alloc() calls being made).

However, during the algInit() call (where Codec Engine provides this newly 
allocated memory to the codec), the codec is returning 49280 (0xC080).  So the 
codec didn't like something it was given - either the memory (unlikely) or the 
creation params(?) - and returned this error.

Do the codec docs (or headers?) provide any details about this specific error 
code (0xC080)?  Does it fail if you pass in NULL as the create() params?

Finally, to your specific question, the error returned (mpeg4enc (0x0)) 
indicates a NULL handle, not a success code.

Chris

> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
] On Behalf Of Paul Stuart
> Sent: Tuesday, January 05, 2010 7:26 AM
> To: Tivy, Robert; davinci-linux-open-source@linux.davincidsp.com
> Subject: RE: Arago Kerenel w/ codec_engine_2_00_01 issues?
>
> Thanks for the response!
>
> I'll give the latest CMEM, LinuxUtils, et al a whirl and see
> what happens. The strange thing is that the mpeg4 decoder,
> jpeg encode/decode, and mp3 encode/decode all load without
> complaint. It's just the mpeg4enc that fails.
>
>
> I've rebuilt cmemk.ko and dm350mmap.ko against the arago
> kernel. Neither process was straight forward though because
> of changes between the montavista kernel we were using. Maybe
> something got botched in the process.
>
>
> Turning on the trace, with CE_DEBUG=2, I get the following
> during mpeg4enc initialization:
>
>
> @5,653,051us: [+0 T:0x43300490] ti.sdo.ce.video1.VIDENC1 -
> VIDENC1_create> Enter (engine=0x100670, name='mpeg4enc',
> params=0x432ffca8)
> @5,653,350us: [+0 T:0x43300490] CV - VISA_create(0x100670,
> 'mpeg4enc', 0x432ffca8, 0x2496, 'ti.sdo.ce.video1.IVIDENC1')
> @5,653,569us: [+0 T:0x43300490] CV - VISA_create2(0x100670,
> 'mpeg4enc', 0x432ffca8, 0x30, 0x2496, 'ti.sdo.ce.video1.IVIDENC1')
> @5,654,187us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm -
> Algorithm_create> Enter(fxns=0xf89c0, idma3Fxns=0xf8988,
> iresFxns=0x0, params=0x432ffca8, attrs=0x432ffac8)
> @5,654,470us: [+0 T:0x43300490] ti.sdo.ce.osal.alg -
> ALG_create> Enter (scratchId=1, fxns=0xf89c0, parentAlg=0x0,
> params=0x432ffca8)
> @5,678,280us: [+2 T:0x43300490] ti.sdo.ce.osal.alg -
> ALG_create> algNumAlloc 7 memory recs
> @5,678,574us: [+2 T:0x43300490] ti.sdo.ce.osal.alg -
> ALG_create> algAlloc returned numRecs=7
> @5,678,777us: [+4 T:0x43300490] ti.sdo.ce.osal.alg -
> ALG_create>  Memory requested memTab[0]: size=0x2c58,
> align=0x100, space=0x11, attrs=0x1
> @5,678,985us: [+4 T:0x43300490] ti.sdo.ce.osal.alg -
> ALG_create>  Memory requested memTab[1]: size=0x200,
> align=0x100, space=0x11, attrs=0x1
> @5,679,182us: [+4 T:0x43300490] ti.sdo.ce.osal.alg -
> ALG_create>  Memory requested memTab[2]: size=0x19a400,
> align=0x100, space=0x11, attrs=0x1
> @5,679,568us: [+4 T:0x43300490] ti.sdo.ce.osal.alg -
> ALG_create>  Memory requested memTab[3]: size=0x10e0,
> align=0x100, space=0x11, attrs=0x1
> @5,679,816us: [+4 T:0x43300490] ti.sdo.ce.osal.alg -
> ALG_create>  Memory requested memTab[4]: size=0x4,
> align=0x100, space=0x11, attrs=0x1
> @5,680,026us: [+4 T:0x43300490] ti.sdo.ce.osal.alg -
> ALG_create>  Memory requested memTab[5]: size=0x14000,
> align=0x100, space=0x11, attrs=0x1
> @5,680,233us: [+4 T:0x43300490] ti.sdo.ce.osal.alg -
> ALG_create>  Memory requested memTab[6]: size=0x3840,
> align=0x100, space=0x11, attrs=0x1
> @5,680,648us: [+4 T:0x43300490] OM - Memory_contigAlloc>
> CMEM_alloc(11352) = 0x43301000.
> @5,680,909us: [+4 

Re: [PATCH v3 1/3] davinci: add power management support

[Kevin Hilman]

Sekhar Nori  writes:

> This patch adds core power management (suspend-to-RAM)
> support for DaVinci SoCs.
>
> The code depends on the the "deepsleep" feature to suspend
> the SoC and saves power by gating the input clock.
>
> The wakeup can be based on an external event as supported
> by the SoC.
>
> Assembly code (in sleep.S) is added to aid gating DDR2
> clocks. Code doing this work should not be accessing DDR2.
> The assembly code is relocated to SRAM by the code in pm.c
>
> The support has been validated on DA850/OMAP-L138 only
> though the code is (hopefully) generic enough that other
> SoCs supporting deepsleep feature simply requires SoC
> specific code to start using this driver.
>
> Note that all the device drivers don't support suspend/resume
> still and are being worked on.
>
> Signed-off-by: Sekhar Nori 

This series looks good.  Applying v3 to davinci-git and queuing for
2.6.34 in davinci-next.

Kevin

> ---
> Since v1:
> 1) suspend function has been renamed.
> 2) register access helper functions have been removed.
> 3) spinlock in davinci_pm_suspend() function has been removed.
>
>  arch/arm/mach-davinci/Makefile  |1 +
>  arch/arm/mach-davinci/include/mach/memory.h |1 +
>  arch/arm/mach-davinci/include/mach/pm.h |   54 +++
>  arch/arm/mach-davinci/pm.c  |  158 +++
>  arch/arm/mach-davinci/sleep.S   |  224 
> +++
>  5 files changed, 438 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-davinci/include/mach/pm.h
>  create mode 100644 arch/arm/mach-davinci/pm.c
>  create mode 100644 arch/arm/mach-davinci/sleep.S
>
> diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
> index eeb9230..d0fed3a 100644
> --- a/arch/arm/mach-davinci/Makefile
> +++ b/arch/arm/mach-davinci/Makefile
> @@ -34,3 +34,4 @@ obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)+= 
> board-da850-evm.o
>  # Power Management
>  obj-$(CONFIG_CPU_FREQ)   += cpufreq.o
>  obj-$(CONFIG_CPU_IDLE)   += cpuidle.o
> +obj-$(CONFIG_SUSPEND)+= pm.o sleep.o
> diff --git a/arch/arm/mach-davinci/include/mach/memory.h 
> b/arch/arm/mach-davinci/include/mach/memory.h
> index 7aeaf46..a91edfb 100644
> --- a/arch/arm/mach-davinci/include/mach/memory.h
> +++ b/arch/arm/mach-davinci/include/mach/memory.h
> @@ -33,6 +33,7 @@
>  
>  #define DDR2_SDRCR_OFFSET0xc
>  #define DDR2_SRPD_BITBIT(23)
> +#define DDR2_MCLKSTOPEN_BIT  BIT(30)
>  #define DDR2_LPMODEN_BIT BIT(31)
>  
>  /*
> diff --git a/arch/arm/mach-davinci/include/mach/pm.h 
> b/arch/arm/mach-davinci/include/mach/pm.h
> new file mode 100644
> index 000..37b19bf
> --- /dev/null
> +++ b/arch/arm/mach-davinci/include/mach/pm.h
> @@ -0,0 +1,54 @@
> +/*
> + * TI DaVinci platform support for power management.
> + *
> + * Copyright (C) 2009 Texas Instruments, Inc. http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +#ifndef _MACH_DAVINCI_PM_H
> +#define _MACH_DAVINCI_PM_H
> +
> +/*
> + * Caution: Assembly code in sleep.S makes assumtion on the order
> + * of the members of this structure.
> + */
> +struct davinci_pm_config {
> + void __iomem *ddr2_ctlr_base;
> + void __iomem *ddrpsc_reg_base;
> + int ddrpsc_num;
> + void __iomem *ddrpll_reg_base;
> + void __iomem *deepsleep_reg;
> + void __iomem *cpupll_reg_base;
> + /*
> +  * Note on SLEEPCOUNT:
> +  * The SLEEPCOUNT feature is mainly intended for cases in which
> +  * the internal oscillator is used. The internal oscillator is
> +  * fully disabled in deep sleep mode.  When you exist deep sleep
> +  * mode, the oscillator will be turned on and will generate very
> +  * small oscillations which will not be detected by the deep sleep
> +  * counter.  Eventually those oscillations will grow to an amplitude
> +  * large enough to start incrementing the deep sleep counter.
> +  * In this case recommendation from hardware engineers is that the
> +  * SLEEPCOUNT be set to 4096.  This means that 4096 valid clock cycles
> +  * must be detected before the clock is passed to the rest of the
> +  * system.
> +  * In the case that the internal oscillator is not used and the
> +  * clock is generated externally, the SLEEPCOUNT value can be very
> +  * small since the clock input is assumed to be stable before SoC
> +  * is taken out of deepsleep mode.  A value of 128 would be more than
> +  * adequate.
> + 

Re: [PATCH] davinci: clock: Check CLK_PSC flag before disabling PSC

[Kevin Hilman]

Chaithrika U S  writes:

> Some modules do not have PSC to control their clocks.
> The 'lpsc' field in the clk structure is 0 for such clocks.
>
> In the clock disable function check for CLK PSC flag before
> disabling the PSC. If this is not taken care of then it may
> so happen that module controlled by LPSC 0 is erroneously disabled.
>
> Signed-off-by: Chaithrika U S 

Looks good, Applying to master and queuing for 2.6.33-rc in
davinci-fixes branch.

Kevin


> ---
>  arch/arm/mach-davinci/clock.c |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
> index e46a643..f097f8d 100644
> --- a/arch/arm/mach-davinci/clock.c
> +++ b/arch/arm/mach-davinci/clock.c
> @@ -49,7 +49,8 @@ static void __clk_disable(struct clk *clk)
>  {
>   if (WARN_ON(atomic_read(&clk->usecount) == 0))
>   return;
> - if (atomic_dec_and_test(&clk->usecount) && !(clk->flags & CLK_PLL))
> + if (atomic_dec_and_test(&clk->usecount) && !(clk->flags & CLK_PLL)
> + && (clk->flags & CLK_PSC))
>   davinci_psc_config(psc_domain(clk), clk->gpsc, clk->lpsc, 0);
>   if (clk->parent)
>   __clk_disable(clk->parent);
> -- 
> 1.5.6
___
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 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver

[Kevin Hilman]

m-kariche...@ti.com writes:

> From: Muralidharan Karicheri 
>
> This combines the two patches sent earlier to change the clock configuration
> and converting ccdc drivers to platform drivers. This has updated comments
> against v2 of these patches. Two new clocks "master" and "slave" are defined 
> for ccdc driver
> as per comments from Kevin Hilman.
>
> This adds platform code for ccdc driver on DM355 and DM6446.
>
> Reviewed-by: Vaibhav Hiremath 
> Reviewed-by: Kevin Hilman 
>
> Signed-off-by: Muralidharan Karicheri 
> ---
> Applies to linux-davinci tree
>  arch/arm/mach-davinci/dm355.c  |   41 ---
>  arch/arm/mach-davinci/dm644x.c |   20 ++-
>  2 files changed, 48 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
> index 2244e8c..a9ea761 100644
> --- a/arch/arm/mach-davinci/dm355.c
> +++ b/arch/arm/mach-davinci/dm355.c
> @@ -378,6 +378,8 @@ static struct davinci_clk dm355_clks[] = {
>   CLK(NULL, "timer3", &timer3_clk),
>   CLK(NULL, "rto", &rto_clk),
>   CLK(NULL, "usb", &usb_clk),
> + CLK("dm355_ccdc", "master", &vpss_master_clk),
> + CLK("dm355_ccdc", "slave", &vpss_slave_clk),

I still don't understand why you have to add new entries here and
can't simply rename the existing CLK nodes using vpss_*_clk.  

Same comment for dm644x.c changes.

Kevin

>   CLK(NULL, NULL, NULL),
>  };
>  
> @@ -665,6 +667,17 @@ static struct platform_device dm355_asp1_device = {
>   .resource   = dm355_asp1_resources,
>  };
>  
> +static void dm355_ccdc_setup_pinmux(void)
> +{
> + davinci_cfg_reg(DM355_VIN_PCLK);
> + davinci_cfg_reg(DM355_VIN_CAM_WEN);
> + davinci_cfg_reg(DM355_VIN_CAM_VD);
> + davinci_cfg_reg(DM355_VIN_CAM_HD);
> + davinci_cfg_reg(DM355_VIN_YIN_EN);
> + davinci_cfg_reg(DM355_VIN_CINL_EN);
> + davinci_cfg_reg(DM355_VIN_CINH_EN);
> +}
> +
>  static struct resource dm355_vpss_resources[] = {
>   {
>   /* VPSS BL Base address */
> @@ -701,6 +714,10 @@ static struct resource vpfe_resources[] = {
>   .end= IRQ_VDINT1,
>   .flags  = IORESOURCE_IRQ,
>   },
> +};
> +
> +static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
> +static struct resource dm355_ccdc_resource[] = {
>   /* CCDC Base address */
>   {
>   .flags  = IORESOURCE_MEM,
> @@ -708,8 +725,18 @@ static struct resource vpfe_resources[] = {
>   .end= 0x01c70600 + 0x1ff,
>   },
>  };
> +static struct platform_device dm355_ccdc_dev = {
> + .name   = "dm355_ccdc",
> + .id = -1,
> + .num_resources  = ARRAY_SIZE(dm355_ccdc_resource),
> + .resource   = dm355_ccdc_resource,
> + .dev = {
> + .dma_mask   = &vpfe_capture_dma_mask,
> + .coherent_dma_mask  = DMA_BIT_MASK(32),
> + .platform_data  = dm355_ccdc_setup_pinmux,
> + },
> +};
>  
> -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
>  static struct platform_device vpfe_capture_dev = {
>   .name   = CAPTURE_DRV_NAME,
>   .id = -1,
> @@ -860,17 +887,7 @@ static int __init dm355_init_devices(void)
>   davinci_cfg_reg(DM355_INT_EDMA_CC);
>   platform_device_register(&dm355_edma_device);
>   platform_device_register(&dm355_vpss_device);
> - /*
> -  * setup Mux configuration for vpfe input and register
> -  * vpfe capture platform device
> -  */
> - davinci_cfg_reg(DM355_VIN_PCLK);
> - davinci_cfg_reg(DM355_VIN_CAM_WEN);
> - davinci_cfg_reg(DM355_VIN_CAM_VD);
> - davinci_cfg_reg(DM355_VIN_CAM_HD);
> - davinci_cfg_reg(DM355_VIN_YIN_EN);
> - davinci_cfg_reg(DM355_VIN_CINL_EN);
> - davinci_cfg_reg(DM355_VIN_CINH_EN);
> + platform_device_register(&dm355_ccdc_dev);
>   platform_device_register(&vpfe_capture_dev);
>  
>   return 0;
> diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
> index e65e29e..e5f1ee9 100644
> --- a/arch/arm/mach-davinci/dm644x.c
> +++ b/arch/arm/mach-davinci/dm644x.c
> @@ -315,6 +315,8 @@ struct davinci_clk dm644x_clks[] = {
>   CLK(NULL, "timer0", &timer0_clk),
>   CLK(NULL, "timer1", &timer1_clk),
>   CLK("watchdog", NULL, &timer2_clk),
> + CLK("dm644x_ccdc", "master", &vpss_master_clk),
> + CLK("dm644x_ccdc", "slave", &vpss_slave_clk),
>   CLK(NULL, NULL, NULL),
>  };
>  
> @@ -612,6 +614,11 @@ static struct resource vpfe_resources[] = {
>   .end= IRQ_VDINT1,
>   .flags  = IORESOURCE_IRQ,
>   },
> +};
> +
> +static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
> +static struct resource dm644x_ccdc_resource[] = {
> + /* CCDC Base address */
>   {
>   .start  = 0x01c70400,
>   .end= 0x01c70400 + 0xff,
> @@ -619,7 +626,17 @@ static struct resource vpfe_r

Re: [PATCH] DaVinci: DM365: Changing default queue for DM365.

[Kevin Hilman]

s-paul...@ti.com writes:

> From: Sandeep Paulraj 
>
> In DM365 Q0, Q1 and Q2 are used by codecs.
> LSP drivers should use Q3.
> This patch changes the default queue for DM365.
>
> Signed-off-by: Sandeep Paulraj 

Thanks.  Applying to master, queueing for 2.6.34 in davinci-next.

Kevin

> ---
>  arch/arm/mach-davinci/dm365.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index cc3bae4..62cec33 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -754,7 +754,7 @@ static struct edma_soc_info dm365_edma_info[] = {
>   .n_cc   = 1,
>   .queue_tc_mapping   = dm365_queue_tc_mapping,
>   .queue_priority_mapping = dm365_queue_priority_mapping,
> - .default_queue  = EVENTQ_2,
> + .default_queue  = EVENTQ_3,
>   },
>  };
>  
> -- 
> 1.6.0.4
>
> ___
> 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 quality with CPU frequency scaling

[Kevin Hilman]

"Chaithrika U S"  writes:

> Kevin,
>
> With the cpufreq support on DA850/OMAP-L138 SoC we are observing
> that audio does not function as expected at all sampling rates
> for various operating points. At a CPU frequency of 96MHz, audio
> works fine with a sampling frequency of 8kHz. For other sampling
> rates, there are lot of underrun/overrun errors. This is because
> of EDMA also runs at a lower speed and is not able to transfer
> data at the desired rate.
>
> To overcome the above, we can depend on the user to set the scaling
> min frequency to be the same as scaling max frequency (in this case
> 300 MHz) before starting aplay/arecord or temporarily move to 
> performance governor so that the audio quality is not affected.
>
> Do you think this is the right approach to this problem? Any other
> solutions you suggest exploring?

An alternative to relying on the user to change the CPUfreq policy is
to have the audio driver itself do that.  Based on the sample rate and
clock frequency, the audio driver should be able to determine that the
EDMA rate will not be fast enough and set a CPUfreq policy so that
lower frequencies are not attempted.  When the audio driver is done,
it can set the policy back.

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 v2] SPI DaVinci: SPI master driver for DaVinci/DA8xx

[Kevin Hilman]

s-paul...@ti.com writes:

> From: Sandeep Paulraj 
>
> This patch adds support for a SPI master driver for the
> DaVinci series of SOCs
>
> Signed-off-by: Sandeep Paulraj 
> Signed-off-by: Mark A. Greer 
> Signed-off-by: Philby John 
> Signed-off-by: Sudhakar Rajashekhara 

In case it helps move this along...

Signed-off-by: Kevin Hilman 

> ---
>  drivers/spi/Kconfig   |7 +
>  drivers/spi/Makefile  |1 +
>  drivers/spi/davinci_spi.c | 1109 
> +
>  drivers/spi/davinci_spi.h |  171 +++
>  4 files changed, 1288 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/spi/davinci_spi.c
>  create mode 100644 drivers/spi/davinci_spi.h
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 4b6f7cb..28d2fae 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -77,6 +77,13 @@ 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/DA8xx SoC's"
> + depends on SPI_MASTER && ARCH_DAVINCI
> + select SPI_BITBANG
> + help
> +   SPI master controller for DaVinci and DA8xx SPI modules.
> +
>  config SPI_BITBANG
>   tristate "Utilities for Bitbanging SPI masters"
>   help
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 21a1182..11f995d 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_SPI_TXX9)  += spi_txx9.o
>  obj-$(CONFIG_SPI_XILINX) += xilinx_spi.o
>  obj-$(CONFIG_SPI_SH_SCI) += spi_sh_sci.o
>  obj-$(CONFIG_SPI_STMP3XXX)   += spi_stmp.o
> +obj-$(CONFIG_SPI_DAVINCI)+= davinci_spi.o
>  #... add above this line ...
>  
>  # SPI protocol drivers (device/link on bus)
> diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
> new file mode 100644
> index 000..c62721a
> --- /dev/null
> +++ b/drivers/spi/davinci_spi.c
> @@ -0,0 +1,1109 @@
> +/*
> + * Copyright (C) 2009 Texas Instruments.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "davinci_spi.h"
> +
> +#define  SPI_NO_RESOURCE ((resource_size_t)-1)
> +
> +static unsigned use_dma;
> +
> +static void davinci_spi_rx_buf_u8(u32 data, struct davinci_spi *davinci_spi)
> +{
> + u8 *rx = davinci_spi->rx;
> +
> + *rx++ = (u8)data;
> + davinci_spi->rx = rx;
> +}
> +
> +static void davinci_spi_rx_buf_u16(u32 data, struct davinci_spi *davinci_spi)
> +{
> + u16 *rx = davinci_spi->rx;
> +
> + *rx++ = (u16)data;
> + davinci_spi->rx = rx;
> +}
> +
> +static u32 davinci_spi_tx_buf_u8(struct davinci_spi *davinci_spi)
> +{
> + u32 data;
> + const u8 *tx = davinci_spi->tx;
> +
> + data = *tx++;
> + davinci_spi->tx = tx;
> + return data;
> +}
> +
> +static u32 davinci_spi_tx_buf_u16(struct davinci_spi *davinci_spi)
> +{
> + u32 data;
> + const u16 *tx = davinci_spi->tx;
> +
> + data = *tx++;
> + davinci_spi->tx = tx;
> + return data;
> +}
> +
> +static inline void set_io_bits(void __iomem *addr, u32 bits)
> +{
> + u32 v = ioread32(addr);
> +
> + v |= bits;
> + iowrite32(v, addr);
> +}
> +
> +static inline void clear_io_bits(void __iomem *addr, u32 bits)
> +{
> + u32 v = ioread32(addr);
> +
> + v &= ~bits;
> + iowrite32(v, addr);
> +}
> +
> +static inline void set_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
> +{
> + set_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
> +}
> +
> +static inline void clear_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
> +{
> + clear_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
> +}
> +
> +static void davinci_spi_set_dma_req(const struct spi_device *spi, int enable)
> +{
> + struct davinci_spi *davinci_spi = spi_master_get_devdata(spi->master);
> +
> + if (enable)
> + set_io_bits(davinci_spi->base + SPIINT, SPIINT_DMA_REQ_EN);
> + else
> + clear_io_bits(davinci_spi->base + SPIINT, SPIINT_DMA_REQ_EN);
> +}
>

Re: [PATCH v2] SPI DaVinci: SPI master driver for DaVinci/DA8xx

[Kevin Hilman]

s-paul...@ti.com writes:

> From: Sandeep Paulraj 
>
> This patch adds support for a SPI master driver for the
> DaVinci series of SOCs
>
> Signed-off-by: Sandeep Paulraj 
> Signed-off-by: Mark A. Greer 
> Signed-off-by: Philby John 
> Signed-off-by: Sudhakar Rajashekhara 

Sandeep,

This needs a minor refresh against current Linus tree for the Makefile
change.

While doing the Makefile addition, it looks like the list is maintained in
alphabetical order.  Please add davinci in the right order, and feel free to
add my signoff.

Thanks,

Kevin

> ---
>  drivers/spi/Kconfig   |7 +
>  drivers/spi/Makefile  |1 +
>  drivers/spi/davinci_spi.c | 1109 
> +
>  drivers/spi/davinci_spi.h |  171 +++
>  4 files changed, 1288 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/spi/davinci_spi.c
>  create mode 100644 drivers/spi/davinci_spi.h
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 4b6f7cb..28d2fae 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -77,6 +77,13 @@ 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/DA8xx SoC's"
> + depends on SPI_MASTER && ARCH_DAVINCI
> + select SPI_BITBANG
> + help
> +   SPI master controller for DaVinci and DA8xx SPI modules.
> +
>  config SPI_BITBANG
>   tristate "Utilities for Bitbanging SPI masters"
>   help
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 21a1182..11f995d 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_SPI_TXX9)  += spi_txx9.o
>  obj-$(CONFIG_SPI_XILINX) += xilinx_spi.o
>  obj-$(CONFIG_SPI_SH_SCI) += spi_sh_sci.o
>  obj-$(CONFIG_SPI_STMP3XXX)   += spi_stmp.o
> +obj-$(CONFIG_SPI_DAVINCI)+= davinci_spi.o
>  #... add above this line ...
>  
>  # SPI protocol drivers (device/link on bus)
> diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
> new file mode 100644
> index 000..c62721a
> --- /dev/null
> +++ b/drivers/spi/davinci_spi.c
> @@ -0,0 +1,1109 @@
> +/*
> + * Copyright (C) 2009 Texas Instruments.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "davinci_spi.h"
> +
> +#define  SPI_NO_RESOURCE ((resource_size_t)-1)
> +
> +static unsigned use_dma;
> +
> +static void davinci_spi_rx_buf_u8(u32 data, struct davinci_spi *davinci_spi)
> +{
> + u8 *rx = davinci_spi->rx;
> +
> + *rx++ = (u8)data;
> + davinci_spi->rx = rx;
> +}
> +
> +static void davinci_spi_rx_buf_u16(u32 data, struct davinci_spi *davinci_spi)
> +{
> + u16 *rx = davinci_spi->rx;
> +
> + *rx++ = (u16)data;
> + davinci_spi->rx = rx;
> +}
> +
> +static u32 davinci_spi_tx_buf_u8(struct davinci_spi *davinci_spi)
> +{
> + u32 data;
> + const u8 *tx = davinci_spi->tx;
> +
> + data = *tx++;
> + davinci_spi->tx = tx;
> + return data;
> +}
> +
> +static u32 davinci_spi_tx_buf_u16(struct davinci_spi *davinci_spi)
> +{
> + u32 data;
> + const u16 *tx = davinci_spi->tx;
> +
> + data = *tx++;
> + davinci_spi->tx = tx;
> + return data;
> +}
> +
> +static inline void set_io_bits(void __iomem *addr, u32 bits)
> +{
> + u32 v = ioread32(addr);
> +
> + v |= bits;
> + iowrite32(v, addr);
> +}
> +
> +static inline void clear_io_bits(void __iomem *addr, u32 bits)
> +{
> + u32 v = ioread32(addr);
> +
> + v &= ~bits;
> + iowrite32(v, addr);
> +}
> +
> +static inline void set_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
> +{
> + set_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
> +}
> +
> +static inline void clear_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
> +{
> + clear_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
> +}
> +
> +static void davinci_spi_set_dma_req(const struct spi_device *spi, int enable)
> +{
> + struct davinci_spi *davinci_spi = spi_master_get_devdata(spi

Re: [PATCH 2/2] davinci: MMC: updates to suspend/resume implementation

[Kevin Hilman]

Janakiram Sistla  writes:

> On 12/17/09, Chaithrika U S  wrote:
>> Improve the suspend and resume callbacks in DaVinci MMC
>> host controller driver.
>
> [Ram] I came cross in the mailing some days back that "direct"
> .suspend and .resume calls will stop being supported.Is This
> true??This patch does require a migration then again.

Yes, this patch (or an additional patch) will have to update the
MMC driver to use dev_pm_ops.

See this commit in Linus' tree where I converted the smc91x driver.
Something like this will nee dto be done for this driver as well.

Kevin

commit 9f950f72e57fe4bf9b16ace67e4cc5ffcee79d00
Author: Kevin Hilman 
Date:   Tue Nov 24 12:57:47 2009 +

NET: smc91x: convert to dev_pm_ops

Convert smc91x driver from legacy PM hooks over to using dev_pm_ops.

Tested on OMAP3 platform.

Signed-off-by: Kevin Hilman 
Acked-by: Nicolas Pitre 
Signed-off-by: David S. Miller 

>> Tested on DA850/OMAP-L138 EVM. This testing requires patches
>> which add suspend-to-RAM support to DA850/OMAP-L138 SoC[1].
>>
>> [1]http://linux.davincidsp.com/pipermail/davinci-linux-open-source/
>> 2009-September/016118.html
>>
>> Signed-off-by: Chaithrika U S 
>> ---
>> Applies to Linus' kernel tree.
>>
>>  drivers/mmc/host/davinci_mmc.c |   31 +--
>>  1 files changed, 29 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
>> index 25645bf..7d05cc1 100644
>> --- a/drivers/mmc/host/davinci_mmc.c
>> +++ b/drivers/mmc/host/davinci_mmc.c
>> @@ -170,6 +170,7 @@ struct mmc_davinci_host {
>>  #define DAVINCI_MMC_DATADIR_READ   1
>>  #define DAVINCI_MMC_DATADIR_WRITE  2
>>unsigned char data_dir;
>> +   unsigned char suspended;
>>
>>/* buffer is used during PIO of one scatterlist segment, and
>> * is updated along with buffer_bytes_left.  bytes_left applies
>> @@ -1300,15 +1301,41 @@ static int __exit davinci_mmcsd_remove(struct 
>> platform_device *pdev)
>>  static int davinci_mmcsd_suspend(struct platform_device *pdev, pm_message_t 
>> msg)
>>  {
>>struct mmc_davinci_host *host = platform_get_drvdata(pdev);
>> +   int ret;
>>
>> -   return mmc_suspend_host(host->mmc, msg);
>> +   mmc_host_enable(host->mmc);
>> +   ret = mmc_suspend_host(host->mmc, msg);
>> +   if (!ret) {
>> +   writel(0, host->base + DAVINCI_MMCIM);
>> +   mmc_davinci_reset_ctrl(host, 1);
>> +   mmc_host_disable(host->mmc);
>> +   clk_disable(host->clk);
>> +   host->suspended = 1;
>> +   } else {
>> +   host->suspended = 0;
>> +   mmc_host_disable(host->mmc);
>> +   }
>> +
>> +   return ret;
>>  }
>>
>>  static int davinci_mmcsd_resume(struct platform_device *pdev)
>>  {
>>struct mmc_davinci_host *host = platform_get_drvdata(pdev);
>> +   int ret;
>>
>> -   return mmc_resume_host(host->mmc);
>> +   if (!host->suspended)
>> +   return 0;
>> +
>> +   clk_enable(host->clk);
>> +   mmc_host_enable(host->mmc);
>> +
>> +   mmc_davinci_reset_ctrl(host, 0);
>> +   ret = mmc_resume_host(host->mmc);
>> +   if (!ret)
>> +   host->suspended = 0;
>> +
>> +   return ret;
>>  }
>>  #else
>>  #define davinci_mmcsd_suspend  NULL
>> --
>> 1.5.6
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
___
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] davinci: MMC: Add a function to control reset state of the controller

[Kevin Hilman]

Chaithrika U S  writes:

> Add a helper function which will aid in changing the reset
> status of the controller.
>
> Signed-off-by: Chaithrika U S 

Signed-off-by: Kevin Hilman 


> ---
> Applies to Linus' kernel tree.
>
>  drivers/mmc/host/davinci_mmc.c |   37 -
>  1 files changed, 16 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
> index dd45e7c..25645bf 100644
> --- a/drivers/mmc/host/davinci_mmc.c
> +++ b/drivers/mmc/host/davinci_mmc.c
> @@ -884,19 +884,26 @@ static void mmc_davinci_cmd_done(struct 
> mmc_davinci_host *host,
>   }
>  }
>  
> -static void
> -davinci_abort_data(struct mmc_davinci_host *host, struct mmc_data *data)
> +static inline void mmc_davinci_reset_ctrl(struct mmc_davinci_host *host,
> + int val)
>  {
>   u32 temp;
>  
> - /* reset command and data state machines */
>   temp = readl(host->base + DAVINCI_MMCCTL);
> - writel(temp | MMCCTL_CMDRST | MMCCTL_DATRST,
> - host->base + DAVINCI_MMCCTL);
> + if (val)/* reset */
> + temp |= MMCCTL_CMDRST | MMCCTL_DATRST;
> + else/* enable */
> + temp &= ~(MMCCTL_CMDRST | MMCCTL_DATRST);
>  
> - temp &= ~(MMCCTL_CMDRST | MMCCTL_DATRST);
> - udelay(10);
>   writel(temp, host->base + DAVINCI_MMCCTL);
> + udelay(10);
> +}
> +
> +static void
> +davinci_abort_data(struct mmc_davinci_host *host, struct mmc_data *data)
> +{
> + mmc_davinci_reset_ctrl(host, 1);
> + mmc_davinci_reset_ctrl(host, 0);
>  }
>  
>  static irqreturn_t mmc_davinci_irq(int irq, void *dev_id)
> @@ -1100,15 +1107,8 @@ static inline void 
> mmc_davinci_cpufreq_deregister(struct mmc_davinci_host *host)
>  #endif
>  static void __init init_mmcsd_host(struct mmc_davinci_host *host)
>  {
> - /* DAT line portion is diabled and in reset state */
> - writel(readl(host->base + DAVINCI_MMCCTL) | MMCCTL_DATRST,
> - host->base + DAVINCI_MMCCTL);
> -
> - /* CMD line portion is diabled and in reset state */
> - writel(readl(host->base + DAVINCI_MMCCTL) | MMCCTL_CMDRST,
> - host->base + DAVINCI_MMCCTL);
>  
> - udelay(10);
> + mmc_davinci_reset_ctrl(host, 1);
>  
>   writel(0, host->base + DAVINCI_MMCCLK);
>   writel(MMCCLK_CLKEN, host->base + DAVINCI_MMCCLK);
> @@ -1116,12 +1116,7 @@ static void __init init_mmcsd_host(struct 
> mmc_davinci_host *host)
>   writel(0x1FFF, host->base + DAVINCI_MMCTOR);
>   writel(0x, host->base + DAVINCI_MMCTOD);
>  
> - writel(readl(host->base + DAVINCI_MMCCTL) & ~MMCCTL_DATRST,
> - host->base + DAVINCI_MMCCTL);
> - writel(readl(host->base + DAVINCI_MMCCTL) & ~MMCCTL_CMDRST,
> - host->base + DAVINCI_MMCCTL);
> -
> - udelay(10);
> + mmc_davinci_reset_ctrl(host, 0);
>  }
>  
>  static int __init davinci_mmcsd_probe(struct platform_device *pdev)
> -- 
> 1.5.6
___
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: MMC: Adding support for 8bit MMC cards

[Kevin Hilman]

Sergei Shtylyov  writes:

> Hello.
>
> Vipin Bhandari wrote:
>
>   [Re-replying to all, as I only replied to Vipin the first time.]
>
>> This patch adds the support for 8bit MMC cards. The controller
>> data width is configurable depending on the wires setting in the
>> platform data structure.
>>
>> MMC 8bit is tested on OMAPL137 and MMC 4bit is tested on OMAPL138 EVM.
>>
>> Signed-off-by: Vipin Bhandari 
>>   
>
>   This has been done by MV in the internal tree but as you code is
> significantly differenet from that one, I'm not asking you about the
> missing MV signoffs...
>
>> diff --git a/drivers/mmc/host/davinci_mmc.c
>> b/drivers/mmc/host/davinci_mmc.c
>> index dd45e7c..3bd0ba2 100644
>> --- a/drivers/mmc/host/davinci_mmc.c
>> +++ b/drivers/mmc/host/davinci_mmc.c
>> @@ -73,6 +73,7 @@
>>  /* DAVINCI_MMCCTL definitions */
>>  #define MMCCTL_DATRST (1 << 0)
>>  #define MMCCTL_CMDRST (1 << 1)
>> +#define MMCCTL_WIDTH_8_BIT(1 << 8)
>>  #define MMCCTL_WIDTH_4_BIT(1 << 2)
>>  #define MMCCTL_DATEG_DISABLED (0 << 6)
>>  #define MMCCTL_DATEG_RISING   (1 << 6)
>> @@ -791,22 +792,42 @@ static void calculate_clk_divider(struct
>> mmc_host *mmc, struct mmc_ios *ios)
>>   static void mmc_davinci_set_ios(struct mmc_host *mmc, struct
>> mmc_ios *ios)
>>  {
>> -unsigned int mmc_pclk = 0;
>>  struct mmc_davinci_host *host = mmc_priv(mmc);
>>  -mmc_pclk = host->mmc_input_clk;
>>  dev_dbg(mmc_dev(host->mmc),
>>  "clock %dHz busmode %d powermode %d Vdd %04x\n",
>>  ios->clock, ios->bus_mode, ios->power_mode,
>>  ios->vdd);
>> -if (ios->bus_width == MMC_BUS_WIDTH_4) {
>> -dev_dbg(mmc_dev(host->mmc), "Enabling 4 bit mode\n");
>> -writel(readl(host->base + DAVINCI_MMCCTL) | MMCCTL_WIDTH_4_BIT,
>> -host->base + DAVINCI_MMCCTL);
>> -} else {
>> -dev_dbg(mmc_dev(host->mmc), "Disabling 4 bit mode\n");
>> -writel(readl(host->base + DAVINCI_MMCCTL) & ~MMCCTL_WIDTH_4_BIT,
>> +
>> +switch (ios->bus_width) {
>> +case MMC_BUS_WIDTH_8:
>> +dev_dbg(mmc_dev(host->mmc), "Enabling 8 bit mode\n");
>> +writel((readl(host->base + DAVINCI_MMCCTL) &
>> +~MMCCTL_WIDTH_4_BIT) | MMCCTL_WIDTH_8_BIT,
>>  host->base + DAVINCI_MMCCTL);
>> +break;
>> +case MMC_BUS_WIDTH_4:
>> +dev_dbg(mmc_dev(host->mmc), "Enabling 4 bit mode\n");
>> +if (host->version == MMC_CTLR_VERSION_2)
>> +writel((readl(host->base + DAVINCI_MMCCTL) &
>> +~MMCCTL_WIDTH_8_BIT) | MMCCTL_WIDTH_4_BIT,
>> +host->base + DAVINCI_MMCCTL);
>> +else
>> +writel(readl(host->base + DAVINCI_MMCCTL) |
>> +MMCCTL_WIDTH_4_BIT,
>> +host->base + DAVINCI_MMCCTL);
>>   
>
>   I don't think it makes sense to check for host->version just to not
> clear the bit which is reserved for original DaVinci. There's nothing
> criminal in clearing a reserved bit, so I'm suggesting that you remove
> the check.

There's nothing criminal... yet... until some new version of the
controller uses that bit for something else.  I think it's always best
to not touch reserved bits unless there is a good, well tested, reason
not to, such as performance etc.

Kevin


>> +break;
>> +case MMC_BUS_WIDTH_1:
>> +dev_dbg(mmc_dev(host->mmc), "Enabling 1 bit mode\n");
>> +if (host->version == MMC_CTLR_VERSION_2)
>> +writel(readl(host->base + DAVINCI_MMCCTL) &
>> +~(MMCCTL_WIDTH_8_BIT | MMCCTL_WIDTH_4_BIT),
>> +host->base + DAVINCI_MMCCTL);
>> +else
>> +writel(readl(host->base + DAVINCI_MMCCTL) &
>> +~MMCCTL_WIDTH_4_BIT,
>> +host->base + DAVINCI_MMCCTL);
>>   
>
>   Same comment here...
>
>> +break;
>>   
>
>   It'll result less code if you read/write the register only once -- 
> before/after the *switch* statement respectively.
>
>>  }
>>   calculate_clk_divider(mmc, ios);
>> @@ -1189,10 +1210,14 @@ static int __init davinci_mmcsd_probe(struct
>> platform_device *pdev)
>>   /* REVISIT:  someday, support IRQ-driven card detection.  */
>>  mmc->caps |= MMC_CAP_NEEDS_POLL;
>> +mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
>>   
>
>Does this flag have to do with the bus width at all? :-/
>
> WBR, Sergei
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
___
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 1/2] Input: Add device_enable handler to DaVinci Keyscan platform data

[Kevin Hilman]

Kevin Hilman  writes:

> Dmitry Torokhov  writes:
>
>> On Mon, Dec 07, 2009 at 04:24:59PM -0800, Kevin Hilman wrote:
>>>  writes:
>>> 
>>> > From: Miguel Aguilar 
>>> >
>>> > Add a function pointer in the platform data of the DaVinci Keyscan driver
>>> > called device_enabled, in order to perform board specific actions when
>>> > the device is initialized, like setup the PINMUX configuration.
>>> >
>>> > Signed-off-by: Miguel Aguilar 
>>> 
>>> Signed-off-by: Kevin Hilman 
>>> 
>>> Dmitry,
>>> 
>>> Will you be queueing this driver (and this patch) for 2.6.34?  I
>>> thought you had accepted the original driver, but I don't see it in
>>> the master or next branch of your input tree at:
>>> 
>>>   git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
>>
>> The driver is there, commit bc09dcadc1a3da87d58aa70ebc8e9441205be75c on
>> 'next' branch (I don't really use master branch).  It was committed back
>> in October, probably that's why you don't see it?
>>
>> As far as the patch goes - I got an impression from email sent by
>> Steve that there are ways to do automatic PINMUX detection and thus
>> this patch was not needed.  Is this ture?
>
> The method Steve was referring to was done for MontaVista
> internal/product kernels but was rejected for upstream (by me) because
> of the way it was implemented (by tying mux settings to clock
> settings.)
>
>> If not I am stull unsure what happens if you unload the driver. How
>> do you restore the old configuration so that the device you took
>> over from can start working again? Maybe pinmux should be controlled
>> via sysfs attribute (in board code) so that user can switch on-fly
>> between the devices?
>
> The way we currently handle MUXing in davinci, you don't need to do
> anything after the driver unloads.  Any other user of these pins will
> mux them as needed.
>
> If really necessary, we could do an equivalent 'device_disable' hook
> but there would be empty as it wouldn't be needed.
>
> So, speaking as maintainer of the DaVinci support, I'm in favor of this
> approach from Miguel.

Dmitry,

Unless there are further objectsions, could you please queue this
patch for 2.6.34 with my signoff?

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

Re: [PATCH v1] i2c: Davinci i2c bus recovery procedure to come out of time out conditions

[Kevin Hilman]

Philby John  writes:

>>From 062cfba8b86ccd932eaa498980e703295d86a6cb Mon Sep 17 00:00:00 2001
> From: Philby John 
> Date: Mon, 23 Nov 2009 18:08:33 +0530
> Subject: [PATCH] Davinci i2c bus recovery procedure to come out of time out 
> conditions
>
> Get out of i2c time out condition by following the
> bus recovery procedure outlined in the i2c protocol v3 spec.
> The kernel must be robust enough to gracefully recover
> from i2c bus failure without having to reset the machine.
> This is done by first NACKing the slave, pulsing the SCL
> line 9 times and then sending the stop command.
>
> This patch has been tested on a DM6446 and DM355

How are you testing this?  this should also be tested on da8xx by someone.

> Signed-off-by: Philby John 
>
> ---
>  drivers/i2c/busses/i2c-davinci.c |   54 +
>  1 files changed, 48 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-davinci.c 
> b/drivers/i2c/busses/i2c-davinci.c
> index 67d88cc..6b4a550 100644
> --- a/drivers/i2c/busses/i2c-davinci.c
> +++ b/drivers/i2c/busses/i2c-davinci.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -43,6 +44,7 @@
>  /* - global defines --- */
>  
>  #define DAVINCI_I2C_TIMEOUT  (1*HZ)
> +#define DAVINCI_I2C_MAX_TRIES2
>  #define I2C_DAVINCI_INTR_ALL(DAVINCI_I2C_IMR_AAS | \
>DAVINCI_I2C_IMR_SCD | \
>DAVINCI_I2C_IMR_ARDY | \
> @@ -134,6 +136,38 @@ static inline u16 davinci_i2c_read_reg(struct 
> davinci_i2c_dev *i2c_dev, int reg)
>   return __raw_readw(i2c_dev->base + reg);
>  }
>  
> +/* Generate a pulse on the i2c clock pin. */
> +static void pulse_i2c_clock(void)
> +{
> + gpio_set_value(14, 0);
> + udelay(20);
> + gpio_set_value(14, 1);
> + udelay(20);
> +}
> +
> +/* This routine does i2c bus recovery as specified in the
> + * i2c protocol Rev. 03 section 3.16 titled "Bus clear"
> + */
> +static void i2c_recover_bus(struct davinci_i2c_dev *dev)
> +{
> + u16 i;
> + u32 flag = 0;
> +
> + dev_err(dev->dev, "initiating i2c bus recovery\n");

This looks like a debug leftover.  I doubt you want this since
you're calling this function on every xfer.

> + /* Send NACK to the slave */
> + flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
> + flag |=  DAVINCI_I2C_MDR_NACK;
> + /* write the data into mode register */
> + davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
> + /* Send high and low on the SCL line */
> + for (i = 0; i < 9; i++)
> + pulse_i2c_clock();
> + /* Send STOP */
> + flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
> + MOD_REG_BIT(flag, DAVINCI_I2C_MDR_STP, 1);

This patch will need some updates as this macro is now gone.

Kevin

> + davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
> +}
> +
>  /*
>   * This functions configures I2C and brings I2C out of reset.
>   * This function is called during I2C init function. This function
> @@ -221,19 +255,26 @@ static int i2c_davinci_wait_bus_not_busy(struct 
> davinci_i2c_dev *dev,
>char allow_sleep)
>  {
>   unsigned long timeout;
> + static u16 to_cnt = 0;
>  
>   timeout = jiffies + dev->adapter.timeout;
>   while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG)
> -& DAVINCI_I2C_STR_BB) {
> - if (time_after(jiffies, timeout)) {
> - dev_warn(dev->dev,
> -  "timeout waiting for bus ready\n");
> - return -ETIMEDOUT;
> + & DAVINCI_I2C_STR_BB) {
> + if (to_cnt <= DAVINCI_I2C_MAX_TRIES) {
> + if (time_after(jiffies, timeout)) {
> + dev_warn(dev->dev,
> + "timeout waiting for bus ready\n");
> + to_cnt++;
> + return -ETIMEDOUT;
> + } else {
> + to_cnt = 0;
> + i2c_recover_bus(dev);
> + i2c_davinci_init(dev);
> + }
>   }
>   if (allow_sleep)
>   schedule_timeout(1);
>   }
> -
>   return 0;
>  }
>  
> @@ -310,6 +351,7 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct 
> i2c_msg *msg, int stop)
> dev->adapter.timeout);
>   if (r == 0) {
>   dev_err(dev->dev, "controller timed out\n");
> + i2c_recover_bus(dev);
>   i2c_davinci_init(dev);
>   dev->buf_len = 0;
>   return -ETIMEDOUT;
> -- 
> 1.6.3.3.MVISTA
>
>
>
>
> ___
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
>

Re: [PATCH v2] SPI DaVinci: SPI master driver for DaVinci/DA8xx

[Kevin Hilman]

Grant Likely  writes:

> On Tue, Jan 5, 2010 at 4:46 PM, Kevin Hilman
>  wrote:
>> s-paul...@ti.com writes:
>>
>>> From: Sandeep Paulraj 
>>>
>>> This patch adds support for a SPI master driver for the
>>> DaVinci series of SOCs
>>>
>>> Signed-off-by: Sandeep Paulraj 
>>> Signed-off-by: Mark A. Greer 
>>> Signed-off-by: Philby John 
>>> Signed-off-by: Sudhakar Rajashekhara 
>>
>> Sandeep,
>>
>> This needs a minor refresh against current Linus tree for the Makefile
>> change.
>>
>> While doing the Makefile addition, it looks like the list is maintained in
>> alphabetical order.  Please add davinci in the right order, and feel free to
>> add my signoff.
>
> Signed-of-by lines are only for patches that actually pass through
> your hands (ie. you add it yourself when you pick it up and pass it).
> It is not appropriate to add a s-o-b line for someone else.
> "Acked-by" or "Reviewed-by" should be used instead.

Understood.  This driver has passed through my hands (and in front of
my eyes) in various forms many times in its development, so I figured
an s-o-b was appropriate.

That being said, for this particular version, and ack is probably more
appropriate.

Sandeep, after you refresh, please add

Acked-by: Kevin Hilman 

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

[PATCH] Fixed comments for the response registers. They were all saying Regiser 0 and 1.

[raghav]

---
 drivers/mmc/host/davinci_mmc.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index dd45e7c..73a6a14 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -54,9 +54,9 @@
 #define DAVINCI_MMCCMD   0x30 /* Command Register  */
 #define DAVINCI_MMCARGHL 0x34 /* Argument Register */
 #define DAVINCI_MMCRSP01 0x38 /* Response Register 0 and 1 */
-#define DAVINCI_MMCRSP23 0x3C /* Response Register 0 and 1 */
-#define DAVINCI_MMCRSP45 0x40 /* Response Register 0 and 1 */
-#define DAVINCI_MMCRSP67 0x44 /* Response Register 0 and 1 */
+#define DAVINCI_MMCRSP23 0x3C /* Response Register 2 and 3 */
+#define DAVINCI_MMCRSP45 0x40 /* Response Register 4 and 5 */
+#define DAVINCI_MMCRSP67 0x44 /* Response Register 6 and 7 */
 #define DAVINCI_MMCDRSP  0x48 /* Data Response Register*/
 #define DAVINCI_MMCETOK  0x4C
 #define DAVINCI_MMCCIDX  0x50 /* Command Index Register*/
-- 
1.6.0.4

___
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] MMC: DaVinci: Fixed typos in comments of the response registers in davinci_mmc.c

[raghav n]

Hi Kevin,
I have tried sending the patch again using git send-email. Hope it should be
in a good shape now. Thank you for the patience and the suggestions.
-raghav

On Wed, Jan 6, 2010 at 3:59 AM, Kevin Hilman wrote:

> Kevin Hilman wrote:
>
>> raghav n  writes:
>>
>>  [PATCH 1/1] MMC: DaVinci: Fixed typos in comments of the response
>>> registers in davinci_mmc.c
>>>
>>
>> You don't need to duplicate the subject in the changelog.
>>
>>  This patch fixes the typos in the comments for the MMC response
>>> registers. They were all /* Response Register 0 and 1 */
>>>
>>> Signed-off-by: raghav.m...@gmail.com
>>>
>>
>> Thanks, will que
>>
>>  ---
>>> From 08e00d18ca5d0c20a9035c631e7fcb5f39c88cb8 Mon Sep 17 00:00:00 2001
>>> From: raghav 
>>>
>>> Date: Tue, 5 Jan 2010 23:57:17 +0530
>>> Subject: [PATCH] Fixed comments for the response registers. They were all
>>> saying Regiser 0 and 1.
>>>
>>
>> You've got duplicate headers/changelog etc. here.
>>
>> I highly recommend using git-format-patch + git-send-email to send
>> patches?
>>
>>  ---
>>>  drivers/mmc/host/davinci_mmc.c |6 +++---
>>>  1 files changed, 3 insertions(+), 3 deletions(-)
>>>
>>
>> The patch itself looks fine.  After cleaning up the changelog, I'll
>> queue for 2.6.33-rc fixes series.
>>
>
> After trying to apply this, the patch is corrupted in other ways and
> doesn't apply cleanly.
>
> Please fix up the patch to apply against current davinci git and resend,
> preferably using git-format-patch + git-send-email.
>
> 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 do i enable full speed instead of high speed in the USB

[Subbrathnam, Swaminathan]

High Speed is backward compatible with Full Speed mode.  So just connect any 
full speed device when acting as host or connect to a full speed port when 
acting as device and you should be able to work in full speed.

regards
swami

From: davinci-linux-open-source-boun...@linux.davincidsp.com 
[davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Gopala 
Gottumukkala [ggott...@cernium.com]
Sent: Tuesday, January 05, 2010 9:04 PM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: how do i enable full speed instead of high speed in the USB

I want to use Full speed instead of high speed.  What needs to be done to work 
with full speed.

Help appreciated,
Thanks
- Gopala

From: Subbrathnam, Swaminathan [mailto:swami.i...@ti.com]
Sent: Tuesday, January 05, 2010 9:41 AM
To: Gopala Gottumukkala; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: USB storage error

Pl. refer to DaVinci Staging GIT kernel hosted at 
http://arago-project.org/git/people/?p=sneha/linux-davinci-staging.git;a=summary.


From: Gopala Gottumukkala [mailto:ggott...@cernium.com]
Sent: Tuesday, January 05, 2010 8:06 PM
To: Subbrathnam, Swaminathan; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: USB storage error

Which kernel version number is working for you can I know the kernel version 
number and if any patches please let me know the patches also.

- Gopala

From: Gopala Gottumukkala
Sent: Monday, January 04, 2010 9:13 AM
To: 'Subbrathnam, Swaminathan'; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: USB storage error

Can I know the latest Davinci Git kernel version which is working for you.  The 
kernel version number and where can I down load the latest one.

- Gopala

From: Subbrathnam, Swaminathan [mailto:swami.i...@ti.com]
Sent: Friday, January 01, 2010 8:10 AM
To: Gopala Gottumukkala; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: USB storage error

Gopala,

Could you try the latest DaVinci Git.  It works for me.

regards
swami

From: davinci-linux-open-source-boun...@linux.davincidsp.com 
[davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Gopala 
Gottumukkala [ggott...@cernium.com]
Sent: Friday, January 01, 2010 1:38 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: USB storage error
I have compiled davinci 2.6.30
I mounted the usb manually
I ran some sample program which will open, write and delete the file into usb 
drive.
While writing the file into usb drive.  It gives the following error and the 
program dies.

Any help would be appreciated on this


usb 1-1: reset high speed USB device using musb_hdrc and address 2
usb 1-1: reset high speed USB device using musb_hdrc and address 2
usb 1-1: reset high speed USB device using musb_hdrc and address 2
sd 0:0:0:0: Device offlined - not ready after error recovery
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=0x05 driverbyte=0x00
end_request: I/O error, dev sda, sector 41584
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00
end_request: I/O error, dev sda, sector 4
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device

- Gopala
NOTICE: The information contained in this email and any document attached 
hereto is intended only for the named recipient(s). It is the property of 
Cernium Corporation and shall not be used, disclosed or reproduced without the 
express written consent of Cernium Corporation. If you are not the intended 
recipient (or the employee or agent responsible for delivering this message in 
confidence to the intended recipient(s)), you are hereby notified that you have 
received this transmittal in error, and any review, dissemination, distribution 
or copying of this transmittal or its attachments is strictly prohibited. If 
you have received this transmittal and/or attachments in error, please notify 
me immediately by reply email or telephone and immediately delete this message 
and all its attachments. Thank you.
NOTICE: The information contained in this email and any document attached 
hereto is intended only for the named recipient(s). It is the property of 
Cernium Corporation and shall not be used, disclosed or reproduced without the 
express written consent of Cernium Corporation. If you are not the intended 
recipient (or the employee or agent responsible for delivering this message in 
confidence to the intended recipient(s)), you are hereby notified that you have 
received this transmittal in error, and any review, dissemination, distribution 
or copying of this transmittal or its attachm

RE: [PATCH 2/2] davinci: MMC: updates to suspend/resume implementation

[Chaithrika U S]

On Wed, Jan 06, 2010 at 05:23:53, Kevin Hilman wrote:
> Janakiram Sistla  writes:
> 
> > On 12/17/09, Chaithrika U S  wrote:
> >> Improve the suspend and resume callbacks in DaVinci MMC
> >> host controller driver.
> >
> > [Ram] I came cross in the mailing some days back that "direct"
> > .suspend and .resume calls will stop being supported.Is This
> > true??This patch does require a migration then again.
> 
> Yes, this patch (or an additional patch) will have to update the
> MMC driver to use dev_pm_ops.
> 
> See this commit in Linus' tree where I converted the smc91x driver.
> Something like this will nee dto be done for this driver as well.

OK. I will submit an updated version of this patch soon.

Regards, 
Chaithrika

> 
> Kevin
> 
> commit 9f950f72e57fe4bf9b16ace67e4cc5ffcee79d00
> Author: Kevin Hilman 
> Date:   Tue Nov 24 12:57:47 2009 +
> 
> NET: smc91x: convert to dev_pm_ops
> 
> Convert smc91x driver from legacy PM hooks over to using dev_pm_ops.
> 
> Tested on OMAP3 platform.
> 
> Signed-off-by: Kevin Hilman 
> Acked-by: Nicolas Pitre 
> Signed-off-by: David S. Miller 
> 
> >> Tested on DA850/OMAP-L138 EVM. This testing requires patches
> >> which add suspend-to-RAM support to DA850/OMAP-L138 SoC[1].
> >>
> >> [1]http://linux.davincidsp.com/pipermail/davinci-linux-open-source/
> >> 2009-September/016118.html
> >>
> >> Signed-off-by: Chaithrika U S 
> >> ---
> >> Applies to Linus' kernel tree.
> >>
> >>  drivers/mmc/host/davinci_mmc.c |   31 +--
> >>  1 files changed, 29 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/mmc/host/davinci_mmc.c 
> >> b/drivers/mmc/host/davinci_mmc.c
> >> index 25645bf..7d05cc1 100644
> >> --- a/drivers/mmc/host/davinci_mmc.c
> >> +++ b/drivers/mmc/host/davinci_mmc.c
> >> @@ -170,6 +170,7 @@ struct mmc_davinci_host {
> >>  #define DAVINCI_MMC_DATADIR_READ   1
> >>  #define DAVINCI_MMC_DATADIR_WRITE  2
> >>unsigned char data_dir;
> >> +   unsigned char suspended;
> >>
> >>/* buffer is used during PIO of one scatterlist segment, and
> >> * is updated along with buffer_bytes_left.  bytes_left applies
> >> @@ -1300,15 +1301,41 @@ static int __exit davinci_mmcsd_remove(struct 
> >> platform_device *pdev)
> >>  static int davinci_mmcsd_suspend(struct platform_device *pdev, 
> >> pm_message_t msg)
> >>  {
> >>struct mmc_davinci_host *host = platform_get_drvdata(pdev);
> >> +   int ret;
> >>
> >> -   return mmc_suspend_host(host->mmc, msg);
> >> +   mmc_host_enable(host->mmc);
> >> +   ret = mmc_suspend_host(host->mmc, msg);
> >> +   if (!ret) {
> >> +   writel(0, host->base + DAVINCI_MMCIM);
> >> +   mmc_davinci_reset_ctrl(host, 1);
> >> +   mmc_host_disable(host->mmc);
> >> +   clk_disable(host->clk);
> >> +   host->suspended = 1;
> >> +   } else {
> >> +   host->suspended = 0;
> >> +   mmc_host_disable(host->mmc);
> >> +   }
> >> +
> >> +   return ret;
> >>  }
> >>
> >>  static int davinci_mmcsd_resume(struct platform_device *pdev)
> >>  {
> >>struct mmc_davinci_host *host = platform_get_drvdata(pdev);
> >> +   int ret;
> >>
> >> -   return mmc_resume_host(host->mmc);
> >> +   if (!host->suspended)
> >> +   return 0;
> >> +
> >> +   clk_enable(host->clk);
> >> +   mmc_host_enable(host->mmc);
> >> +
> >> +   mmc_davinci_reset_ctrl(host, 0);
> >> +   ret = mmc_resume_host(host->mmc);
> >> +   if (!ret)
> >> +   host->suspended = 0;
> >> +
> >> +   return ret;
> >>  }
> >>  #else
> >>  #define davinci_mmcsd_suspend  NULL
> >> --
> >> 1.5.6
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >> the body of a message to majord...@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> Please read the FAQ at  http://www.tux.org/lkml/
> >>
> 


___
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 3/4] i2c: davinci: Add suspend/resume support

[Chaithrika U S]

On Wed, Jan 06, 2010 at 04:26:44, Kevin Hilman wrote:
> Chaithrika U S  writes:
> 
> > Add suspend and resume callbacks to DaVinci I2C driver.
> > This has been tested on DA850/OMAP-L138 EVM. The SoC specific
> > suspend-to-RAM support patch series [1] is needed to test this feature.
> >
> > [1] http://linux.davincidsp.com/pipermail/davinci-linux-open-source/
> > 2009-November/016958.html
> >
> > Signed-off-by: Chaithrika U S 
> > ---
> >  drivers/i2c/busses/i2c-davinci.c |   32 
> >  1 files changed, 32 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-davinci.c 
> > b/drivers/i2c/busses/i2c-davinci.c
> > index 81c1049..c1c2909 100644
> > --- a/drivers/i2c/busses/i2c-davinci.c
> > +++ b/drivers/i2c/busses/i2c-davinci.c
> > @@ -622,6 +622,36 @@ static int davinci_i2c_remove(struct platform_device 
> > *pdev)
> > return 0;
> >  }
> >  
> > +#ifdef CONFIG_PM
> > +static int davinci_i2c_suspend(struct platform_device *pdev, pm_message_t 
> > state)
> > +{
> > +   struct davinci_i2c_dev *dev = platform_get_drvdata(pdev);
> > +
> > +   /* put I2C into reset */
> > +   davinci_i2c_reset_ctrl(dev, 0);
> > +
> > +   clk_disable(dev->clk);
> > +
> > +   return 0;
> > +}
> > +
> > +static int davinci_i2c_resume(struct platform_device *pdev)
> > +{
> > +   struct davinci_i2c_dev *dev = platform_get_drvdata(pdev);
> > +
> > +   clk_enable(dev->clk);
> > +
> > +   /* take I2C out of reset */
> > +   davinci_i2c_reset_ctrl(dev, 1);
> > +
> > +   return 0;
> > +}
> > +
> > +#else
> > +#define davinci_i2c_suspend NULL
> > +#define davinci_i2c_resume NULL
> > +#endif
> > +
> >  /* work with hotplug and coldplug */
> >  MODULE_ALIAS("platform:i2c_davinci");
> >  
> > @@ -632,6 +662,8 @@ static struct platform_driver davinci_i2c_driver = {
> > .name   = "i2c_davinci",
> > .owner  = THIS_MODULE,
> > },
> > +   .suspend= davinci_i2c_suspend,
> > +   .resume = davinci_i2c_resume,
> 
> Rather than adding these to the platform_driver, you should use dev_pm_ops.
> 
> Something like the patch below on top of your PATCH 3/4 should work.
> 
> Other than this, I'm OK with this series, feel free to add my signoff
> and resend to linux-i2c and LKML.  linux-i2c has had very slow
> response to embedded patches lately.
> 
> Kevin
> 

OK. I will post updated patches soon.

Thanks & 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

RE: Cmem address translation when working with Codec Engine

[Erez Kinarti]

This is not an odd setup. The buffers are allocated in other place by
memory manager, and for decoupling the codec should not be aware of
that, it just need to be called with pointers to in/out buffers.
Believe me that we have good enough reason not to do the alloc and
release from the codec. In addition, the codec is not aware at all to
the big buffer, just to the pointers inside it.

In bottom line, I understand that I have to take CERuntimeInit/Exit out
of the codecs in some way and there is no other way supplied by TI to
cope with this problem (like unregister all the virtual addresses in one
call without a specific pointer). Am I correct?

Thanks,
Erez

-Original Message-
From: Tivy, Robert [mailto:rt...@ti.com] 
Sent: Wednesday, January 06, 2010 12:52 AM
To: Erez Kinarti; Vladimir Pantelic;
Davinci-linux-open-source@linux.davincidsp.com
Cc: Davinci-linux-open-source@linux.davincidsp.com
Subject: RE: Cmem address translation when working with Codec Engine


This sounds like an odd setup, how are you even calling the codec if not
through CE?

Since the first codec is assuming responsibility for doing "first"
things, like calling CERuntime_init(), can't it also call
Memory_registerContigBuf()?  From your earlier descriptions it sounds
like you might need a way to inform this first codec of the (big CMEM)
buffer size to register, but communicating that info sounds easier than
tracking small buffer subdivisions.

Regards,

- Rob

> -Original Message-
> From: 
> davinci-linux-open-source-bounces+rtivy=ti@linux.davincids
> p.com 
> [mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.d
> avincidsp.com] On Behalf Of Erez Kinarti
> Sent: Tuesday, January 05, 2010 1:26 AM
> To: Vladimir Pantelic; Davinci-linux-open-source@linux.davincidsp.com
> Cc: Davinci-linux-open-source@linux.davincidsp.com
> Subject: RE: Cmem address translation when working with Codec Engine
> 
> No, because in my system, the first codec that is generated 
> is calling CERuntimeInit (working with C++, keeping reference 
> counter for the call to CERuntimeInit and CERuntimeExit), 
> while the system buffers are allocated before that.
> 
> 
> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
> ] On Behalf Of Vladimir Pantelic
> Sent: Tuesday, January 05, 2010 11:15 AM
> To: Davinci-linux-open-source@linux.davincidsp.com
> Cc: Davinci-linux-open-source@linux.davincidsp.com
> Subject: Re: Cmem address translation when working with Codec Engine
> 
> Erez Kinarti wrote:
> > Hey Rob,
> > I see that calling the register functions require that CE is in the
> air
> > (CERuntimeInit) so it is problematic for us in the same way as doing
> the
> > CMEM allocations via CodecEngine.
> 
> as you have to call CERuntimeInit() before using any of CE, 
> you can do the
> Memory_registerContigBuf() after CERuntimeInit(), no?
> 
> 
> ___
> 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