-Original Message-
From: Philby John [mailto:pj...@mvista.com]
Sent: Monday, March 08, 2010 7:37 AM
To: Griffis, Brad
Cc: Nori, Sekhar; davinci-linux-open-source@linux.davincidsp.com; linux-
i...@vger.kernel.org
Subject: Re: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear
Right. I was also hoping to rid of cpu_is_xxx usage. The only other way
I could think of is to add pinmux index into i2c platform data struct.
What do you think is the best approach?
I think passing pinmux index through platform data is fair.
Thanks,
Sekhar
I recently was told of a
First, I should mention that I'm in favor of what you've been discussing, Rob
and David. I think having a mechanism in place to make more EDMA channels
available for consumption is a good thing.
I question the number of channels the codec team needs. See below.
Below is a codec DMA needs
-Original Message-
From: Vladimir Pantelic [mailto:p...@nt.tu-darmstadt.de]
Sent: Friday, August 07, 2009 1:27 AM
To: Griffis, Brad
Cc: davinci-linux-open-source
Subject: Re: Montavista Compiler License
As it turns out, there are some hooks in MV gcc to call an external app
Hi everyone,
I need to make an important clarification on this issue. My issue of gcc being
tied into FlexLM applies specifically to Montavista's Mobilinux product which
is what I ran my quick test on. Their more common product, e.g. MVPro5, does
NOT have gcc tied into FlexLM. Only
Hi all,
Maybe someone from Montavista or anyone else with experience using Montavista
tools can help answer my question.
A customer recently discovered the hard way that once your one year support
contract with Montavista expires that your compiler ceases to function. The
customer's product
-Original Message-
From: Vladimir Pantelic [mailto:p...@nt.tu-darmstadt.de]
Sent: Thursday, August 06, 2009 12:41 PM
To: Griffis, Brad
Cc: davinci-linux-open-source
Subject: Re: Montavista Compiler License
Griffis, Brad wrote:
Hi all,
Maybe someone from Montavista
at www.macrovision.com.
-Original Message-
From: Diego Dompe [mailto:diego.do...@ridgerun.com]
Sent: Thursday, August 06, 2009 1:00 PM
To: Vladimir Pantelic
Cc: Diego Dompe; Griffis, Brad; davinci-linux-open-source
Subject: Re: Montavista Compiler License
I'm not a lawyer
Core voltage stays the same across both devices. Your PLL multiplier will need
to change to get you up to 270 MHz. This will ripple down into SYSCLK2 and
SYSCLK4 which feed into the peripherals, so the peripherals would need to
accommodate for the faster clock being supplied. Hopefully the
The datasheet and ARM subsystem user guide refer the PLLs as PLL1 and PLL2. In
any case, I think you would need to:
* Execute code from internal memory
* Put the DDR into self-refresh
* Turn off / bypass DDR PLL
Brad
From:
In xdcpaths.mak set USE_CETOOLS_IF_EXISTS :=0.
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Sandeep YEDIRE
Sent: Thursday, June 11, 2009 7:31 AM
To:
? What connector
is on it? What header is on the board?
From: elbert shiang [mailto:elbertshi...@yahoo.com]
Sent: Friday, May 22, 2009 2:14 PM
To: David Brownell; davinci-linux-open-source@linux.davincidsp.com; Griffis,
Brad
Subject: RE: 14 pins JTAG cable
Brad
Yes, there will definitely be Linux support coming. I haven't heard the exact
dates, but I understand it should be soon (this year?). I hear the main
hang-up is the emulation drivers (i.e. from Spectrum Digital and Blackhawk).
-Original Message-
From:
knowledge we don't have any level-sensitive interrupts.
Brad
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Griffis, Brad
Sent: Thursday, May 14, 2009 11:48 AM
To: Kevin Hilman
Cc
On Monday 11 May 2009, Narnakaje, Snehaprabha wrote:
Kevin, Dave,
We checked this with the hardware team -
The GPIO module does't seem to have the ability to
enable/disable the direct/banked GPIO[0:9] at the GPIO
Level (it does via the SET register, but it doesn't
prevent triggering
Prasad,
The high resolution clock that DSP/BIOS uses on 64x+ architecture is called the
time-stamp counter (TSC), which is part of the 64x+ Megamodule. It's a 64-bit
counter consisting of two registers, TSCH and TSCL, that operate at CPU/1.
When you call CLK_gethtime it reads TSCL.
By
I imagine he's referring to the Device Revision Code that would be on the
silkscreen of each device shipped. When we transitioned to Silicon Rev 2.1 (a
year ago?) the device markings changed from TMS320DM6446ZWT to
TMS320DM6446AZWT. However, at least from a part numbering perspective the
You need to write your assembly to handle interrupts properly. For example,
you need to make sure that the stack pointer is double-word aligned at any time
where interrupts are enabled. That means you could not do two pushes in a
row to the stack. Rather you would need to increment the stack
To: Griffis, Brad
Cc: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: How to debug codec in CCS
Hello Brad,
Checking the Component Manager, I do have several buid toos installed, and
specifically the 'Texas instruments c6000 code generation tools' for
TMS320C64xx. Anyway, the project .pjt
When you set the breakpoint you'll either get a filled-in red circle, or just
an empty circle. If it's filled-in with red then CCS understands where
you're trying to set the breakpoint. There are file names embedded in the x64P
file along with the symbols, etc.
One thing to be careful about
What build tools have you specified for 64x in the component manager? (Help -
About - Component Manager) The error message says you don't have any
specified.
From: davinci-linux-open-source-boun...@linux.davincidsp.com
I don't know anything about gstreamer in order to help you solve your issue,
but I do know that there is another gstreamer project that is being actively
worked right now:
https://omapzoom.org/gf/project/gstreamer_ti/wiki/
Perhaps you will have better luck with it. It's running on all OMAP
This path is likely incorrect:
/home/rtalbot/dvevm_2_21/dsplink_1_60/packages
You need to do one of the following to fix it:
1) Root through the various makefiles to figure out where they define XDCPATH
and delete the extra packages they are appending to the dsplink path.
- OR -
2) Add a
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf
Of David Brownell
Sent: Tuesday, January 27, 2009 1:22 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Re:
When the peripheral driver wants transfer can continue
semantics, it should edma_pause() instead of edma_stop().
- Dave
Sorry, for some reason I had it in my mind that you were talking about pause!
So, yes, I agree with you.
___
If so, my initial reaction is to thnk that
using da830_* symbols would be the least
confusing option ... instead of omap_*.
Text in Kconfig would be able to include both
Aureus and OMAP (L1xx) descriptions.
That's beginning to sound like a consensus (I hope).
This same situation has
I suspect that until patches appear, discussion can get no
further. Plus, if it's going to be mach-omap-L1 it'd
be good to have enough detail that the OMAP team (and RMK)
can see why it should pair with plat-davinci instead of
the more obvious plat-omap.
Although it has OMAP in the
-Original Message-
From: David Brownell [mailto:davi...@pacbell.net]
Sent: Tuesday, January 20, 2009 3:50 PM
To: Griffis, Brad
Cc: Sergei Shtylyov; DaVinci
Subject: Re: omap-L1xxx (WAS: [patch 0/6] EDMA interface updates)
On Tuesday 20 January 2009, Griffis, Brad wrote:
I
The ACPY3 set of APIs is intended to allow algorithms to perform DMA transfers.
It works with the DMA Manager (DMAN) so that you don't clobber another
algorithm's transfer.
Please see this wiki entry for an overview:
http://wiki.davincidsp.com/index.php?title=DMA_Framework_Components
Brad
The more descriptive terms are active/reload. The active
set is the one that the EDMA actually uses for transferring
data. When the transfer is completed, if the active channel
specifies a link set (i.e. the reload set), then that set
will be copied over the active set.
Agreed on
David,
I'd like to make a few comments just to be sure that you understand a few
things related to items you removed.
1) EDMA3 resources. There are several different resources that are shared
among all users of EDMA3 (i.e. ARM, DSP, etc.).
A) Channels - Each channel has a hard-coded
Shared using the shadow regions in some cases. Does the
DSP software use region 1? I'd hope it does...
Generally speaking each core should use its own unique shadow region.
(Unrelated: why do people call ASP modules McBSP modules??
Just carrying forward obsolete terminology? It's
The 6.1.x codegen tools have a feature called hide/unhide. You could do
something like:
--hide=* --unhide=api_base_name_*
This will replace all the symbol names (with the exception of api_base_name_*)
with zeros.
Brad
From:
There are two pieces to this issue:
1) The transfer between memory and the DM9000. This should be no problem
as the DM9000 will show up in the EMIF address space.
2) The initiation of the transfer. You either need to manually invoke
the transfer (through the ESR) or an event can
It looks like your problems started here:
asm/arch/param.h: No such file or directory
The asm directory is normally a softlink (e.g. to arm-asm) and it gets
created during the make dm6446_defconfig step (that might not be the exact
syntax though hopefully you get what I'm saying). If you
If you're using Windows, do you have .Net Framework 2.0 installed? If you're
using Linux did you install mono?
Brad
-Original Message-
From: Neerav Patel [mailto:[EMAIL PROTECTED]
Sent: Monday, December 08, 2008 4:43 PM
To: Griffis, Brad; davinci-linux-open-source
I usually send people here:
https://www-a.ti.com/downloads/sds_support/CodeGenerationTools.htm
There are downloads for both Linux and Windows and none of them say eval.
Brad
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua Hintze
Sent:
Does this issue occur ONLY on your custom board, i.e. can you successfully
connect to the EVM using the same configuration?
From: Marta Gros Marín [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 02, 2008 9:56 PM
To: Griffis, Brad
Subject: RE: Icecrusher
Hi Brad
Which version of CCS are you using (e.g. CCS 3.3 SR11). What version of the
Blackhawk emulation drivers do you have? How did you configure cc_setup?
Brad
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marta Gros Marín
Sent: Friday,
Looks similar to this:
http://tiexpressdsp.com/wiki/index.php?title=Troubleshooting_DSPLink_configuration_issues#Problem:_PROC_start_failed_with_configuration_mismatch.2Ffailure_showing_some_modules_with_0.2C_some_with_1.2C_2_etc._and_others_with_0x
Are you not freeing up the memory
Albert,
You said the codec is located here:
/home/albertb/albertb_tests/codecs/ti/sdo/codecs/h264dec/
Therefore your path needs to include
/home/albertb/albertb_tests/codecs/
Note there are two changes:
1) Add the preceding '/' as Rob pointed out.
2) Change packages to codecs if that's indeed
What is the difference between the below products, apart from the fact
that montavista is included in two of them, and one has CCStudio and
XDS560R. Does the DVSPB have anything else that the DVEVM doesn't have?
[BG] DVSPB stands for Digital Video Software Production Bundle. The two
DVSPB
Your NACK could be due to having the wrong slave address. The 7-bit slave
address is shown many different ways. Sometimes it's shown left-aligned so
that you can OR the R/W bit into the address. Other times it's right aligned.
Also, the driver itself sometimes expects it one way or another!
http://tiexpressdsp.com/wiki/index.php?title=-mf_compiler_option
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Kumar Brajbhushan
Sent: Tuesday, September 23, 2008 12:58 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: TI CG Tool
Jeff,
That's correct that the refresh rate refers to the rate that the DDR controller
will refresh the DDR. In self-refresh mode the DDR is refreshing itself.
Brad
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Jeff Cooper
Sent: Wednesday,
Did you modify the makefile itself? This line is messed up:
make -C
/opt/mv_pro_4.0.1/montavista/pro/devkit/lsp/ti-davinci_evm-arm_v5t_le/linux-2.6.10_mvl401
M=`pwd` ARCH=arm CROSS_COMPILE=/opt/mv_pr/bin/arm_v5t_le-
\/pro/devkit/arm/v5t_le
EXTRA_CFLAGS=-DUSE_UDEV=1 -DMAX_POOLS=128
Are you returning from main? Did you setup the CLK manager to define how often
your ticks should occur? Did you define how many ticks between PRDs?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oscar Garcia Abad
Sent: Thursday, July 03, 2008
Oscar,
CCS support for OMAP35x started with CCS 3.3 SR7 (3.3.67). Currently CCS is at
SR9 (3.3.79).
There's no firm requirement to write xDAIS algorithms in CCS. However, I
imagine it will be much easier. CCS will give you much better debug capability.
Make sure you've downloaded the
Be careful with your cache operations. A WB-inv is not the catch all
operation. You can do some damage if you do it in the wrong place.
A few hints/tips:
* Make sure that only one of the processors is accessing the data at any given
time.
* Before touching a buffer for the first time the
Oscar,
Codec Engine will be adding OMAP35x support in the upcoming 2.20 release slated
for August 2008:
http://wiki.davincidsp.com/index.php?title=Codec_Engine_Roadmap
Brad
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oscar Garcia Abad
Sent:
?
From: Albert Burbea [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 11, 2008 4:22 PM
To: Griffis, Brad
Cc: Andre Gaschler; kashin Lin;
davinci-linux-open-source@linux.davincidsp.com
Subject: Re: About the cache issues of dm6446
Hi
another question - is it possible to victimize
: Thursday, June 12, 2008 12:52 AM
To: Griffis, Brad; [EMAIL PROTECTED]
Cc: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: About the cache issues of dm6446
Hi,
thanks for all of your answering.
Brad, i still has some questions:
1. in document spru862a page 26 section 2.2, it says
Albert,
This is off topic. Please post your question here in the floating point
section:
https://community.ti.com/forums/
Brad
From: Albert Burbea [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 12, 2008 12:28 PM
To: Griffis, Brad
Cc: Andre
You're both looking at documents that do not apply to the DM6446.
Please go to the DM6446 product folder for documents applicable to this
device:
http://focus.ti.com/docs/prod/folders/print/tms320dm6446.html#technicald
ocuments
Kashin, the guide you are looking at applies to 64x cache, not 64x+
C64P.rootDir needs to point to the c6000 codegen tools. The tools are
not provided as part of the DVEVM. Only licensed users of Code Composer
Studio should have these tools.
Brad
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of amdw2
Sent:
If the SPI interface has a 16-bit interface then you should do an A-sync
transfer with ACNT=2. It should be A-sync and not AB-sync because the SPI
interface is only ready to receive one element when it gives the “ready” signal
to the EDMA. If for example the SPI had a FIFO on it then you
that to PGA_R and to the
A/D for conversion. In this case you end up with a mono version of each input
though.
Brad
-Original Message-
From: Joyab Bhabharawala [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 12:06 AM
To: Griffis, Brad; davinci-linux-open-source
The cl6x executable is the front-end to TI's compiler/linker for the
64x+ DSP core. It comes with our DSP development tools, Code Composer
Studio. If you go to the Update Advisor in CCS you can download
codegen updates, including versions built for Linux host PC, which is
what you need.
Brad
Please clarify your question. Your subject mentions multi channel capture
which means multiple audio inputs. But then you ask for multiple outputs later
on. Which is it?
Open an AIC31 data sheet and find the signal names for the inputs and the
outputs and then let us know which ones you
your evaluation.
Brad
From: Albert Burbea [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 23, 2008 7:31 AM
To: Griffis, Brad
Cc: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: software updates for DM355?
Hi
another issue - I have a dm6446
Make sure none of your memory maps are overlapping:
1) Linux, declared in u-boot bootargs
2) CMEM, declared during insmod at run-time
3) DSPLINK, declared in your DSP server's tcf file provided that
you're using createFromServer() in your application config file.
Brad
David,
TOTAL : 8880 (128M)
Better double-check your math. 0x0800_ = 128MB. What you have is
actually 136MB. This explains why DSP Link will not load anything above
address 0x8800_, i.e. there's no more memory!
Brad
-Original Message-
From: [EMAIL
I had that same issue the first time I registered a board. It looked as
though the registration needed to be manually processed before you get
access. I imagine within a couple hours you'll have access. You should
get an email once access has been granted.
Brad
-Original Message-
]
Sent: Thursday, March 20, 2008 1:51 PM
To: Griffis, Brad
Cc: Andrew J. Kilpatrick;
davinci-linux-open-source@linux.davincidsp.com
Subject: Re: software updates for DM355?
I have the same problem. The davincisoftwareupdates page is non-
existent.
My registration is complete, I've received
Are you using Enge.createFromServer() in your app.cfg file?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf
Of Sam Hague (shague)
Sent: Saturday, March 15, 2008 8:50 AM
To: Kamoolkar, Mugdha; davinci-linux-open-source@linux.davincidsp.com
Subject: RE:
Short Answers:
1) 64 logical channels and 2 physical channels (TC0 and TC1).
2) The QDMA channels are also logical. The actual transfers are
handled by TC0 and TC1.
Long Answer:
There are two distinct pieces to the EDMA: the channel controller
(CC) and the transfer
, March 04, 2008 3:19 PM
To: Shawn Ho; Griffis, Brad;
davinci-linux-open-source@linux.davincidsp.com
Subject: RE: DM355 or DM6437
On DM355 (and other single processor systems, like DM6437), Codec
Engine-based codecs are always configured to be 'local', and as such the
overhead introduced by CE
The PINMUX register definitions are in the datasheet, section 3.5.4.
http://www.ti.com/lit/gpn/tms320dm6446
Note there are several errata related to RGB888 so please be sure to
read the silicon errata:
http://www.ti.com/litv/pdf/sprz241h
I've not used the RGB888 mode so I'm not sure about the
SPRU871H Chapter 9
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Will Tucker
Sent: Thursday, November 08, 2007 3:22 PM
To: Hunter, Jon; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: SV: turn on/off the DSP
Hi,
I'm
Carlos,
The DM355 will decode 720p (30fps) but NOT 1080i streams.
Brad
-Original Message-
From: Carlos Ojea [mailto:[EMAIL PROTECTED]
Sent: Monday, October 22, 2007 3:28 AM
To: Griffis, Brad
Cc: [EMAIL PROTECTED];
davinci-linux-open-source@linux.davincidsp.com
Subject: Re: HD MPEG-4 SP
Lloyd,
The DM355 is targeted for MPEG-4 and so the price of the codec is
already accounted for within the price of the device. It can ONLY do
MPEG-4 (and JPEG) and that is the reason why we just bundle it. The
DM644x on the other hand is much more flexible and so we don't
pre-package any
features of the codec yet
though I would expect it to be similar to the one you mentioned.
Brad
-Original Message-
From: Carlos Ojea [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 17, 2007 2:22 AM
To: Griffis, Brad
Cc: Linux DaVinci
Subject: Re: HD MPEG-4 SP
Thanks, Brad !
Is MPEG-4
http://www.ti.com/digitalmediasoftware
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Carlos Ojea
Sent: Tuesday, October 16, 2007 7:42 AM
To: Linux DaVinci
Subject: HD MPEG-4 SP
Where could I find TI's HD MPEG-4 SP features and price?
Many thanks,
Rakesh,
GP[29] connects to the DC_P1 connector. The DM6437 EVM Technical
Reference from Spectrum Digital states the following:
User inputs can be driven via daughter card connector DC_P1 when the on
board CBTs
are disabled by driving control TVP5146_ENABLEn signal high on DC_P1.
Are
It sounds like your issue is on the digital interface on the receive
side. You might want to try changing the clock polarity on the McBSP
for the receive side. If the McBSP is trying to read the data on the
exact same edge that the AIC23 is writing the data then you run into a
problem where
Here’s the page with all the signal processing libraries:
http://focus.ti.com/dsp/docs/dspsupporttoolssoftwareaut.tsp?sectionId=3tabId=480familyId=132toolTypeId=44
Here’s the link to the 64x+ image library:
http://focus.ti.com/docs/toolsw/folders/print/sprc264.html
Brad
Amol,
In I2C the device address is a 7-bit number. Whenever an I2C
transaction occurs the master sends the 7-bit slave address and then a
Read/Write bit. That is, the total transfer for the address ends up
being 8 bits when you count read/write. Because of that, there is some
general confusion
: Thursday, January 18, 2007 1:50 PM
To: Griffis, Brad; Azbell, Brandon;
davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Can the ARM and DSP accessing the RAM simulatenously?
Hmm..., I just received an answer from a TI expert that says that the ARM and
DSP can still access the DDR
I think the problem is that you need to escape your semicolon. That is replace
; with \; in your commands.
Brad
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Sz Lian Yu
Sent: Tuesday, December 05, 2006 7:13 PM
To: [EMAIL PROTECTED];
79 matches
Mail list logo
