Hello.
David Brownell wrote:
From: David Brownell dbrown...@users.sourceforge.net
This provides basic support for the CF slot on the dm6446 EVM.
Oops, I was going to submit that months ago, and still haven't. :-
Insert/remove events are not (currently) supported.
IDE now has
David Brownell wrote:
+u32 davinci_timer_irqs[NUM_TIMERS] = {
Isn't wanting NUM_TIMERS itself a problem? Why not just
pass the size of the timer address array, and then just
know that the IRQ array is twice as big?
Or better still, have a structure like:
struct timer64 {
u32
Hi Mugdha,
I recompiled the dspbios link with all configuration options selected, still
the result is the same. I have confirmed that CHNL component is getting
added into build.
I also compiled the complete DVSDK on configuring the dspbios link.
I am now looking into the decode demo. Can you
On Thursday 26 March 2009 14:22:20 Chaithrika U S wrote:
Video Port Interface driver
Add VPIF driver for DM646x. This code be used by the display and
capture drivers.
Signed-off-by: Chaithrika U S chaithr...@ti.com
---
Applies to v4l-dvb repository
drivers/media/video/davinci/vpif.c
Hi
Can anybody send me how can I get data from histogram.
Second one question is what is in buffer which I read out form AEW or AF?
And which count I should request in read function.
I tried to realize dependecies on settings, but have no success.
Best regards
Ondrej Pindroch
SoftHard
On Sun, Mar 29, 2009 at 11:57:57AM +0200, Koen Kooi wrote:
Could you update board-dm355-leopard.c as well please?
Yes. I didn't notice the leopard until I'd already submitted.
Mark
--
___
Davinci-linux-open-source mailing list
On Thu, Mar 26, 2009 at 07:33:21PM -0700, Mark A. Greer wrote:
Clear any set bits in the 'NEXT' field of the MDCTL register in the
Power and Sleep Controller (PSC) before setting any new bits.
This also allows some minor cleanup by removing some no longer
needed lines of code.
On Monday 30 March 2009, Sergei Shtylyov wrote:
That's a third what an ATA drive gives on the same system; the
CF cards do not support DMA access modes.
Those CF cards probably don't even support PIO3/4 because using DMA ATA
drive's speed whould've been order of magnitude better than
On Sat, Mar 28, 2009 at 08:54:01PM -0700, David Brownell wrote:
On Saturday 28 March 2009, Mark A. Greer wrote:
+u32 davinci_timer_irqs[NUM_TIMERS] = {
Isn't wanting NUM_TIMERS itself a problem? Why not just
pass the size of the timer address array, and then just
know that the IRQ array
On Mon, Mar 30, 2009 at 03:38:41PM +0400, Sergei Shtylyov wrote:
David Brownell wrote:
+u32 davinci_timer_irqs[NUM_TIMERS] = {
Isn't wanting NUM_TIMERS itself a problem? Why not just
pass the size of the timer address array, and then just
know that the IRQ array is twice as big?
Or
David Brownell wrote:
That's a third what an ATA drive gives on the same system; the
CF cards do not support DMA access modes.
Those CF cards probably don't even support PIO3/4 because using DMA ATA
drive's speed whould've been order of magnitude better than 4.5 MB/sec (which
should
On Monday 30 March 2009, Sergei Shtylyov wrote:
Russing 'hdrparm -t /dev/hda' gives me about up
to 30 MB/s on DM6467 --that's not 45 but not 4.5 either.
And on dm6446evm, matching $SUBJECT ... ?
___
Davinci-linux-open-source mailing list
On Sat, Mar 28, 2009 at 11:33:58PM -0400, Hugo Villeneuve wrote:
On Sat, 28 Mar 2009 19:05:13 -0700
Mark A. Greer mgr...@mvista.com wrote:
From: Mark A. Greer mgr...@mvista.com
Currently, there is one set of platform_device and platform_data
structures for all DaVinci SoCs. The
On Sat, Mar 28, 2009 at 09:08:19PM -0700, David Brownell wrote:
On Saturday 28 March 2009, Mark A. Greer wrote:
*info)
static int __init davinci_init(void)
{
- return platform_device_register(serial_device);
+ return
On Sat, Mar 28, 2009 at 09:20:46PM -0700, David Brownell wrote:
On Saturday 28 March 2009, Mark A. Greer wrote:
When enabled, the clocksource remains a continuous
32-bit counter but the clock event will no longer
support periodic interrupts. Instead only oneshot
timers will be supported
On Sat, Mar 28, 2009 at 09:30:19PM -0700, David Brownell wrote:
On Saturday 28 March 2009, Mark A. Greer wrote:
-/* dm355 only */
+/* dm355 da830 only */
#define PINMUX20x08
#define PINMUX30x0c
#define PINMUX4
On Sat, Mar 28, 2009 at 09:24:17PM -0700, David Brownell wrote:
On Saturday 28 March 2009, Mark A. Greer wrote:
+ * Device specific mux setup
+ *
+ * soc description mux mode mode mux dbg
+ * reg offset mask mode
Cosmetic nitpickery:
On Sat, Mar 28, 2009 at 08:42:26PM -0700, David Brownell wrote:
On Saturday 28 March 2009, Mark A. Greer wrote:
+/* SoC specific init support */
+struct davinci_soc_info {
+ struct map_desc *io_desc;
+ unsigned long io_desc_num;
+};
How
On Monday 30 March 2009, Mark A. Greer wrote:
How about adding the physical address of the SRAM (as exposed
to EDMA and ARM), and its size? ...
This seems like a good idea but I'd like to leave it out of this
series of patches.
OK.
We can add things to davinci_soc_info at our
On Mon, Mar 30, 2009 at 10:35:01AM -0700, David Brownell wrote:
On Monday 30 March 2009, Mark A. Greer wrote:
How about adding the physical address of the SRAM (as exposed
to EDMA and ARM), and its size? ...
This seems like a good idea but I'd like to leave it out of this
series
On Sat, Mar 28, 2009 at 06:38:59PM -0700, Mark A. Greer wrote:
The da830 boots (initramfs) but the emac isn't working. It may be a
FYI, Sekhar found the emac issue:
Hi Mark,
You need to set version as well as rmii_en. I could get EMAC working on top
of your patches with the following
Mark A. Greer mgr...@mvista.com writes:
On Thu, Mar 26, 2009 at 07:33:21PM -0700, Mark A. Greer wrote:
Clear any set bits in the 'NEXT' field of the MDCTL register in the
Power and Sleep Controller (PSC) before setting any new bits.
This also allows some minor cleanup by removing some no
David Brownell davi...@pacbell.net writes:
On Saturday 28 March 2009, Mark A. Greer wrote:
This series of patches adds support for the da830 SoC and da830_evm
platform. To do that, a bunch of assumptions had to be removed from
the code and passed in via a global struct that hold the
David Brownell wrote:
Russing 'hdrparm -t /dev/hda' gives me about up
to 30 MB/s on DM6467 --that's not 45 but not 4.5 either.
And on dm6446evm, matching $SUBJECT ... ?
*Slightly* less. However, it's not with a recent kernel. With a 2.6.29-rc
kernel, I din't have my HDD recognized at
On Mon, 30 Mar 2009 10:14:28 -0700
Mark A. Greer mgr...@mvista.com wrote:
On Sat, Mar 28, 2009 at 11:33:58PM -0400, Hugo Villeneuve wrote:
On Sat, 28 Mar 2009 19:05:13 -0700
Mark A. Greer mgr...@mvista.com wrote:
From: Mark A. Greer mgr...@mvista.com
Currently, there is one set
Hello.
Pedanekar, Hemant wrote:
Add support for Texas Instuments Communication Port Programming Interface 4.1
(CPPI 4.1) used on OMAP-L137/DA830.
At this moment, only the DMA controller and queue manager are supported.
Support for the buffer manager is lacking but this chip doesn't have it
Mark A. Greer mgr...@mvista.com writes:
Clear any set bits in the 'NEXT' field of the MDCTL register in the
Power and Sleep Controller (PSC) before setting any new bits.
This also allows some minor cleanup by removing some no longer
needed lines of code.
Signed-off-by: Mark A. Greer
On Mon, Mar 30, 2009 at 02:32:52PM -0500, Hugo Villeneuve wrote:
On Mon, 30 Mar 2009 10:14:28 -0700
Mark A. Greer mgr...@mvista.com wrote:
On Sat, Mar 28, 2009 at 11:33:58PM -0400, Hugo Villeneuve wrote:
On Sat, 28 Mar 2009 19:05:13 -0700
Mark A. Greer mgr...@mvista.com wrote:
On Monday 30 March 2009, Sergei Shtylyov wrote:
Russing 'hdrparm -t /dev/hda' gives me about up
to 30 MB/s on DM6467 --that's not 45 but not 4.5 either.
And on dm6446evm, matching $SUBJECT ... ?
*Slightly* less.
Curious. As I said: moving a drive from a laptop to
a dm6446evm gave
Mark A. Greer mgr...@mvista.com writes:
From: Mark A. Greer mgr...@mvista.com
The Davinci cpu_is_davinci_*() macros use the SoC part number
and variant retrieved from the JTAG ID register to determine the
type of cpu that the kernel is running on. Currently, the code to
read the JTAG ID
Mark A. Greer mgr...@mvista.com writes:
From: Mark A. Greer mgr...@mvista.com
The watchdog code currently hardcodes the base address
of the timer its using. To support new SoCs, make it
support timers at any address. Use davinci_soc_info
to do this.
Signed-off-by: Mark A. Greer
On Mon, Mar 30, 2009 at 12:38:21PM -0700, Kevin Hilman wrote:
Can you move the use of IO_ADDRESS() here and put the physical address
in the soc_info struct?
This will allow ease of migration away from IO_ADDRESS() in the future.
Sure.
Other than that, looks ok.
OK, thanks.
Mark
--
The SPI on DM355 EVM and DM6467 EVM is conencted only to
AT25 EEPROM. This patch adds support for the EEPROM client driver.
The EEPROM is accessed using the MTD interface
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Signed-off-by: Steve Chen sc...@mvista.com
---
drivers/mtd/devices/Makefile
Patch adds support for SPI in DM355. The ATMEL EEPROM that is connected to
SPI on the DM355 EVM is accessed using the MTD interface.
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
---
arch/arm/mach-davinci/board-dm355-evm.c | 51 +++
arch/arm/mach-davinci/dm355.c
This patch adds support for SPI driver for DaVinci and DA8xx.
The SPI module on DM355,DM365 and DM6467 is a little different
from that on DA8xx. So we use two different flags, 'DAVINCI_SPI_VERSION_1'
and 'DAVINCI_SPI_VERSION_2' in the driver.
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
---
On Monday 30 March 2009, s-paul...@ti.com wrote:
The SPI on DM355 EVM and DM6467 EVM is conencted only to
AT25 EEPROM. This patch adds support for the EEPROM client driver.
The EEPROM is accessed using the MTD interface
I'm trying to understand why this shouldn't use
the existing EEPROM
Hi,
I have a large piece of Matlab code for video processing which I need to
implement on DM6467. I suppose I need to convert the Matlab code to C/C++ in
order for ARM GCC compilers to compile it. I was wondering if there is any
tool provided by TI which can get me the equivalent C code for my
Mark A. Greer mgr...@mvista.com writes:
From: Mark A. Greer mgr...@mvista.com
Several of davinci platforms have their mac address
at the same location in the same type of i2c eeprom
so factor out the code to extract that mac address.
Also factor out the code that fixes up a bogus mac
assuming it is ANSI-C, i have seen colleagues use matlab plugins ( or matlab
itself ) to generate C code for their algorithms.
a google search shows this article referencing such a plugin
http://www.dspdesignline.com/howto/204802244
2009/3/30 Abhishek Botadra abhibota...@gmail.com
Hi,
I
Mark A. Greer mgr...@mvista.com writes:
On Sat, Mar 28, 2009 at 09:20:46PM -0700, David Brownell wrote:
On Saturday 28 March 2009, Mark A. Greer wrote:
When enabled, the clocksource remains a continuous
32-bit counter but the clock event will no longer
support periodic interrupts.
s-paul...@ti.com writes:
The SPI on DM355 EVM and DM6467 EVM is conencted only to
AT25 EEPROM. This patch adds support for the EEPROM client driver.
The EEPROM is accessed using the MTD interface
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Signed-off-by: Steve Chen sc...@mvista.com
On Mon, Mar 30, 2009 at 05:07:52PM -0700, Kevin Hilman wrote:
Mark A. Greer mgr...@mvista.com writes:
From: Mark A. Greer mgr...@mvista.com
Several of davinci platforms have their mac address
at the same location in the same type of i2c eeprom
so factor out the code to extract that
dear all:
I want to use picture in picture function for two video displaying,I can
display a video stream in device /dev/fb/3 which i referenced the demos the
dvsdk supported,but when i use the device /dev/fb/1 to display another video
stream, i cann't see the picture,why?
The vpbe pdf tell me
the bootargs i used just as:
setenv bootargs 'mem=116M console=ttyS0,115200n8 root=/dev/ram0 rw
initrd=0x8200,4M ip=off
video=davincifb:vid0=720x576x16,2500K:vid1=720x576x16,2500K@:osd0=800x600x16,2025K
:osd1=720x576x16,1650K davinci_enc_mngr.ch0_output=COMPONENT1
deal all:
My boatrd is Davinci dm6446, the LSP is 01-20-00-014, when i insmod the
usbserial.ko for 3 3G/HSDPA modem ,i succeed to pppd to the 3G network, but
when i try to ping ip address 203.208.39.99 which is Google's a static ip, i
get errors below:
generic ttyUSB5:
Mark A. Greer mgr...@mvista.com writes:
On Mon, Mar 30, 2009 at 05:07:52PM -0700, Kevin Hilman wrote:
Mark A. Greer mgr...@mvista.com writes:
From: Mark A. Greer mgr...@mvista.com
Several of davinci platforms have their mac address
at the same location in the same type of i2c eeprom
Can you provide the lsusb -v output with the device connected to your EVM?
Also ensure that you have updated your kernel with the latest patches.
regards
swami
From: davinci-linux-open-source-boun...@linux.davincidsp.com
Mark A. Greer mgr...@mvista.com writes:
[...]
diff --git a/arch/arm/mach-davinci/clock.h b/arch/arm/mach-davinci/clock.h
index 91c24e6..9d09105 100644
--- a/arch/arm/mach-davinci/clock.h
+++ b/arch/arm/mach-davinci/clock.h
@@ -66,6 +66,7 @@ struct clk {
u8
On Monday 30 March 2009, Kevin Hilman wrote:
What I didn't like was the at24 stuff in the new common code.
However, as I think about it, once I move to the new memory_accessor
series (which I will push shortly) the common code only has the
memory_accessor struct, not the at24_iface struct so
Mark A. Greer mgr...@mvista.com writes:
[...]
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -435,6 +435,7 @@ void __init dm355_init_spi0(unsigned chipselect_mask,
* soc description mux mode mode muxdbg
* reg
Mark A. Greer mgr...@mvista.com writes:
From: Mark A. Greer mgr...@mvista.com
Since most of the emac platform_data is really SoC specific
and not board specific, move it to the SoC-specific files.
Put a pointer to the platform_data in davinci_soc_info
so the board-specific code can set some
On Monday 30 March 2009, Kevin Hilman wrote:
Mark A. Greer mgr...@mvista.com writes:
On Sat, Mar 28, 2009 at 09:20:46PM -0700, David Brownell wrote:
On Saturday 28 March 2009, Mark A. Greer wrote:
When enabled, the clocksource remains a continuous
32-bit counter but the clock event
On Mon, Mar 30, 2009 at 08:35:58PM -0700, Kevin Hilman wrote:
Mark A. Greer mgr...@mvista.com writes:
[...]
diff --git a/arch/arm/mach-davinci/clock.h b/arch/arm/mach-davinci/clock.h
index 91c24e6..9d09105 100644
--- a/arch/arm/mach-davinci/clock.h
+++ b/arch/arm/mach-davinci/clock.h
On Mon, Mar 30, 2009 at 09:02:11PM -0700, Kevin Hilman wrote:
Mark A. Greer mgr...@mvista.com writes:
diff --git a/arch/arm/mach-davinci/include/mach/common.h
b/arch/arm/mach-davinci/include/mach/common.h
index 7cb3e39..7d072e2 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
Mark A. Greer mgr...@mvista.com writes:
From: Mark A. Greer mgr...@mvista.com
The da830/omap l137 is a new SoC from TI that is similar
to the davinci line. Since its so similar to davinci,
put the support for the da830 in the same directory as
the davinci code.
There are differences,
Kevin Hilman khil...@deeprootsystems.com writes:
Mark A. Greer mgr...@mvista.com writes:
[...]
2) Different uart addresses. This is only an issue
for the assembly 'addruart' macro when CONFIG_DEBUG_LL
is enabled. Since the code in that macro is called
so early (e.g., by _error_p
On Mon, Mar 30, 2009 at 08:55:32PM -0700, David Brownell wrote:
On Monday 30 March 2009, Kevin Hilman wrote:
What I didn't like was the at24 stuff in the new common code.
However, as I think about it, once I move to the new memory_accessor
series (which I will push shortly) the common code
Mark A. Greer mgr...@mvista.com writes:
From: Mark A. Greer mgr...@mvista.com
Add support for the DA830/OMAP-L137 Evaluation Module (EVM
from TI. The EVM has User Interface (UI) and Audio cards
that can be connected that contain various devices.
Support for those devices and ones on the
Mark A. Greer mgr...@mvista.com writes:
From: Mark A. Greer mgr...@mvista.com
On the da830, the jtag id register used to determine
the cpu type is in the config register space. The
registers in that space can be protected from I/O.
To unlock that space, two kick registers need to
be
Mark A. Greer mgr...@mvista.com writes:
This series of patches adds support for the da830 SoC and da830_evm
platform. To do that, a bunch of assumptions had to be removed from
the code and passed in via a global struct that hold the necessary
information.
Mark,
Thanks for this series.
David Brownell davi...@pacbell.net writes:
On Monday 30 March 2009, Kevin Hilman wrote:
Mark A. Greer mgr...@mvista.com writes:
On Sat, Mar 28, 2009 at 09:20:46PM -0700, David Brownell wrote:
On Saturday 28 March 2009, Mark A. Greer wrote:
When enabled, the clocksource remains a
Mark A. Greer mgr...@mvista.com writes:
On Mon, Mar 30, 2009 at 08:55:32PM -0700, David Brownell wrote:
On Monday 30 March 2009, Kevin Hilman wrote:
What I didn't like was the at24 stuff in the new common code.
However, as I think about it, once I move to the new memory_accessor
series
From: Kevin Hilman
Sent: Tuesday, March 31, 2009 10:51 AM
Mark A. Greer mgr...@mvista.com writes:
From: Mark A. Greer mgr...@mvista.com
The da830 currently has an issue with writeback data
cache so CONFIG_CPU_DCACHE_WRITETHROUGH is forced on
when CONFIG_ARCH_DAVINCI_DA830 is enabled.
63 matches
Mail list logo
