Ignore this!

Completely a lame mistake by me! My script that compiles the kernel runs a make clean, which applies montavista patches, hence overwrites my code!! Only discovered it after losing all my changes!

When it doubt, its something simple!

Andrew

Andrew Armstrong wrote:
Guys, Amol,

Did you ever get this working with the RTC Kernel driver? I can access
my non-evm clock fine via my own interface, but I have not managed to
get the davinci-rtc.c to talk properly with my device, which is strange
as I have just copied over working code!

Looking on my scope it seems that the I2C waveforms produced via
davinci-rtc.c I2C calls are not right at all.

This is a really strange one? Should I be looking at scrapping the
Davinci RTC code and writing a module from scratch? It seems a little
long winded but I am running out of ideas!

Regards,

Andrew


On Sat, 2007-01-20 at 22:18 -0800, Amol Lad wrote:
I'm connecting external RTC (ISl1208) to Davinci on I2C. It's slave address as 
per device spec is 0xDE. BUT in davinci the device is responding at address 0x6F

In my all other platforms the device responds at 0xDE.

I use davinci_i2c_read/davinci_i2c_write APIs ? One more point. 0x6F << 1 == 
0xDE



----- Original Message ----
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
To: davinci-linux-open-source@linux.davincidsp.com
Sent: Thursday, January 18, 2007 3:46:31 PM
Subject: Davinci-linux-open-source Digest, Vol 13, Issue 49

Send Davinci-linux-open-source mailing list submissions to
    davinci-linux-open-source@linux.davincidsp.com

To subscribe or unsubscribe via the World Wide Web, visit
    http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

or, via email, send a message with subject or body 'help' to
    [EMAIL PROTECTED]

You can reach the person managing the list at
    [EMAIL PROTECTED]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Davinci-linux-open-source digest..."


Today's Topics:

   1. Re: Can the ARM and DSP accessing the RAM simulatenously?
      (Andy Ngo)


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

Message: 1
Date: Thu, 18 Jan 2007 02:16:21 -0800 (PST)
From: Andy Ngo <[EMAIL PROTECTED]>
Subject: Re: Can the ARM and DSP accessing the RAM simulatenously?
To: "Griffis, Brad" <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
    davinci-linux-open-source@linux.davincidsp.com
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="windows-1252"

Brad / Brandon,

Thanks for your responses.  So basically, what you are saying is that in the 
current DVEVM DDR memory mapping (the one shown
below) which the codec examples are using, if no cache is being used, the 
application on the ARM (as well as any other application / system
process in the Linux kernel that runs in DDR RAM) never runs at the same time (in parallel) as the code server (DSP/BIOS) task on the DSP side, since they both access the same DDR device. Is that correct? It's almost as though it's a single processor system. So,
assuming we keep the same single DDR device memory mapping, the only way to fix 
this contention to allow both sides to run in parallel
most of the time is via using cache (assuming we get cache hits most of the 
time).  Where I can fix examples/documents on setting up
the cache for the DaVinci and how to split them between the ARM and DSP?  I 
guess for the CE server, it's specified in the *.cfg and
*.tcf files, is that correct?

Regards,
Andy


----- Original Message ----
From: "Griffis, Brad" <[EMAIL PROTECTED]>
To: Andy Ngo <[EMAIL PROTECTED]>; davinci-linux-open-source@linux.davincidsp.com
Sent: Wednesday, January 17, 2007 6:12:07 PM
Subject: RE: Can the ARM and DSP accessing the RAM simulatenously?








<!--
 _filtered {font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
 _filtered {font-family:"Trebuchet MS";
panose-1:2 11 6 3 2 2 2 2 2 4;}
/* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
    {margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
    {color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
    {color:purple;
text-decoration:underline;}
p
    {
margin-right:0in;

margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";}
span.EmailStyle18
    {
font-family:Arial;
color:navy;}
span.EmailStyle19
    {
font-family:Arial;
color:navy;}
 _filtered {
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
    {}
-->






Andy,
Perhaps the following info will help you
in deciding whether to add a second RAM device.
Keep in mind that both the ARM and DSP have
cache.  The cache greatly reduces the number of DDR2 accesses which also
reduces the number of conflicts.  Also, the switched central resource has
software configurable priorities for the masters such that you can control who 
you
want to have access to the DDR2 in the case of a conflict.  This is further
documented in “Table 3-12. DM6446 Default Bus Master Priorities” in
the data sheet.
Brad









From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Azbell, Brandon

Sent: Wednesday, January 17, 2007
7:54 PM

To: Andy Ngo;
davinci-linux-open-source@linux.davincidsp.com

Subject: RE: Can the ARM and DSP
accessing the RAM simulatenously?



Andy,
The DM6446 has exactly 2 memory interface busses on it. One interfaces to
DD2 memories and the other is the EMIFA, which can support Asynchronous SRAM
and Flash.
These 2 memory interfaces are completely
independent of each other.  At any given moment in time, one and only one
transaction, or access, can/will occur on each bus.  The master/initiator
of that access for each memory interface can be one of many different masters
inside the device, including the ARM, DSP, EDMA, VPSS, EMAC, USB, etc. Due to the Switched Central Resource internal bus architecture, multiple
masters can access different targets simultaneously, as long as they are not
conflicting for the same resource.  If they do conflict, then yes, one of
them will be stalled.
You really need to make an assessment as to why having a different memory,
connected to the EMIFA which the DSP would use, is necessary.  What is the
motivation?  Is the motivation based on something you have measured using
the DVEVM, or is it perception?
Based on the scenario that you illustrated below:
“Since this DDR RAM is
physically being shared by both the ARM and DSP, does this mean only one
can access the RAM at a time?  For
example, if the DSP is accessing RAM, does
that mean the ARM is put on hold if it trying to use RAM at that time?  If
this is the case, then
the ARM and DSP cannot operate
simultaneously and there is a performance issue?  I’m asking because
my hardware engineer believes that is
the case since both the ARM and DSP are
using the same bus to access the same DDR RAM chip so only one of
them can access the RAM at a given
time, regardless of the actual location
within the 256 MB space.”
If both the ARM and DSP are accessing DDR2 memory (for instance) at the same
time, one of them will be stalled.  You can not physically have 2 accesses
occurring at the same time on the same bus.  Look at it this way, if both
the ARM and DSP were writing a value to DDR2, what would you expect to see on
the 32-bit data bus in a given clock cycle: data from the ARM, or data from the
DSP?


Regards, Brandon Azbell Texas Instruments Senior, Group Technical Staff System Applications [EMAIL PROTECTED] email 847.517.4536 voice 847.517.4576 fax 630.561.9593 mobile












From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andy Ngo

Sent: Wednesday, January 17, 2007
6:56 PM

To:
davinci-linux-open-source@linux.davincidsp.com

Subject: Can the ARM and DSP
accessing the RAM simulatenously?





I have question that I wanted to
ask.  The DVEVM board has 256 MB DDR RAM available to the ARM and
DSP; according to the document
that comes with codec examples, this RAM
is partitioned as follows:



· 0x80000000 ..
0x87800000 (0-120MB;     size 120MB): Linux, booted with
MEM=120M
· 0x87800000 ..
0x88000000 (120-128MB;   size   8MB): CMEM -- shared buffers between
Arm, DSP
· 0x88000000 ..
0x8FA00000 (128-250MB;   size 122MB): DDRALGHEAP (*)-- DSP segment used
exclusively for algorithm heaps
· 0x8FA00000 ..
0x8FE00000 (250-254MB;   size   4MB): DDR (*)-- DSP segment
for code, stack, static data, and system dynamic data
· 0x8FE00000 ..
0x8FF00000 (254-255MB;   size   1MB): DSPLINKMEM (*) memory
for DSPLINK
· 0x8FF00000 ..
0x8FF00080 (255MB-255MB; size  128B): CTRLRESET (*) memory for reset
vectors)
· 0x8FF00080 .. 0x8FFFFFFF (255MB-256MB; size 1MB): waste
Since this DDR RAM is
physically being shared by both the ARM and DSP, does this mean only one
can access the RAM at a time?  For
example, if the DSP is accessing RAM, does
that mean the ARM is put on hold if it trying to use RAM at that time?  If
this is the case, then
the ARM and DSP cannot operate simultaneously
and there is a performance issue?  I’m asking because my hardware engineer
believes that is
the case since both the ARM and DSP are
using the same bus to access the same DDR RAM chip so only one of
them can access the RAM at a given
time, regardless of the actual location
within the 256 MB space.  This is most likely not the case but I need to
know why so I can convince my
hardware engineer.  I want him to put
a similar 256 MB chip on our custom board, but he insists on putting a 128MB
for the ARM and a dedicated
tiny 512 Kb for the DSP (which I told him
is not enough for CE server I'm trying to run on the DSP).
I appreciate your response.  Thanks.



Regards,
Andy














-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://linux.omap.com/pipermail/davinci-linux-open-source/attachments/20070118/5646b2e5/attachment.htm

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

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


End of Davinci-linux-open-source Digest, Vol 13, Issue 49
*********************************************************





____________________________________________________________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367
_______________________________________________
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

Reply via email to