Troy Kisky troy.ki...@boundarydevices.com writes:
Reserve channels 0,1,12,13 and
slots 78-109 for dsp use on dm644x.
Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
I've only verified that channels 0, and 78-101 need
reserved, but reserving a little extra seems like
a good idea.
Use network device ops interface.
Tested on TI DM646x adn DM644x EVMs.
Signed-off-by: Chaithrika U S chaithr...@ti.com
---
drivers/net/davinci_emac.c | 28 +++-
1 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/net/davinci_emac.c
Existing EDMA driver does not take care of multiple EDMA channel
controller instances. An upcoming architecture from TI has 2 EDMA
channel controller instances. This patch adds support for multiple
EDMA CC instances.
With this patch, user needs to pass the EDMA channel number as
Chaithrika U S chaithr...@ti.com writes:
Fix for phy_disconnect bug
Disconnect the phy device only if there is a PHY connected.
If the phy_mask is zero, the phydev pointer is null, therefore
check the phydevice before disconnection.
Signed-off-by: Chaithrika U S chaithr...@ti.com
Thanks,
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
Jorge Luis Zapata Muga jorgeluis.zap...@gmail.com writes:
This series of patches add support for the Neuros Technologies OSD2
board (http://wiki.neurostechnology.com/index.php/OSD_2.0_HD). It is a
multimedia player/recorder based on DM6446.
Sorry for the noise about sending the patches too
Jorge Luis Zapata Muga jorgeluis.zap...@gmail.com writes:
This series of patches add support for the Neuros Technologies OSD2
board (http://wiki.neurostechnology.com/index.php/OSD_2.0_HD). It is a
multimedia player/recorder based on DM6446.
For the most part, this series looks fine.
After
Quick reactions to this version ...
Almost all of these changes flow directly from the interface
changes which I've excerpted below, which will help make this
response much shorter than the patch! That's a nice feature
of a patch being reviewed.
Still ... 40 KBytes is big. This patch *might*
On Friday 17 April 2009, Sudhakar Rajashekhara wrote:
This patch has been tested on DM644x. While testing this patch,
I found out that audio is playing fast on DM644x (even without
this patch). Need to debug this further.
Make sure you include the driver for the i2c gpio expander,
so the audio
On Fri, Apr 17, 2009 at 11:59:42AM -0500, Kevin Hilman wrote:
Mark A. Greer mgr...@mvista.com writes:
This is version 3 of what was previously called
ARM: da830 - Add support for DA830/OMAP-L137 EVM
but with the da830 patches removed and Kevin's issues
addressed.
I'll repost the
Kevin Hilman wrote:
Troy Kisky troy.ki...@boundarydevices.com writes:
Reserve channels 0,1,12,13 and
slots 78-109 for dsp use on dm644x.
Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
I've only verified that channels 0, and 78-101 need
reserved, but reserving a little extra
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
Ring, Chris wrote:
It's a bit too much info, but please review the Overview section here:
http://tiexpressdsp.com/index.php?title=Dma_overview
It attempts to describe challenges in hard-coding DMA resources on systems
with multiple cores that must cooperate. Fortunately the DMA resource
It may not have been clear, there's sort of a 2 phase resource management:
1. At build/config time where the resources are statically partitioned -
some for ARM, some for DSP - and given to their respective CPU-specific
resource managers. I think originally we simply cut the DMA resources
Ring, Chris wrote:
It may not have been clear, there's sort of a 2 phase resource management:
1. At build/config time where the resources are statically partitioned -
some for ARM, some for DSP - and given to their respective CPU-specific
resource managers. I think originally we simply
Why does this patch get your mpeg4 codec to work - b/c the codec has a
hard-coded channel 0 it needs (so your patch keeps channel 0 out of Linux's
partition)?
If so, IMHO, that change doesn't belong in the mainline tree - that's a
customer-specific integration issue. FWIW, the architecturally
16 matches
Mail list logo
