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: [email protected] > 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 > [email protected] > > 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], > [email protected] > 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]>; > [email protected] > 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; > [email protected] > > 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: > [email protected] > > 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 > [email protected] > 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 > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
