HI,
Can anyone tell whether DM365 supports 4:2:0 display. If yes how
is the memory layout
Regards
Shantanu Bhaduri
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On
Behalf Of [email protected]
Sent: Wednesday, June 10, 2009 3:48 AM
To: [email protected]
Subject: Davinci-linux-open-source Digest, Vol 42, Issue 53
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. [PATCH v1] Adding DaVinci DM365 EDMA Support ([email protected])
2. RE: [PATCH RFC] adding support for setting bus parameters in
sub device (Karicheri, Muralidharan)
3. RE: CMEM and mmap'd buffers in 2.6.28rc6 (Ryan Talbot)
4. Re: device driver for 800x480 LCD (Yusuf Caglar AKYUZ)
5. RE: CMEM and mmap'd buffers in 2.6.28rc6 (Tivy, Robert)
6. [PATCH] Minor Update to Kconfig ([email protected])
7. [PATCH v1] DM365 NAND Support ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Tue, 9 Jun 2009 17:15:46 -0400
From: [email protected]
Subject: [PATCH v1] Adding DaVinci DM365 EDMA Support
To: [email protected]
Message-ID: <[email protected]>
The patch adds support for EDMA in DM365
The EDMA user guide for DM365 can be found at
http://focus.ti.com/lit/ug/sprufi0/sprufi0.pdf
Signed-off-by: Sandeep Paulraj <[email protected]>
---
arch/arm/mach-davinci/dm365.c | 91
+++++++++++++++++++++++++++++++++++++++++
1 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/dm365.c
b/arch/arm/mach-davinci/dm365.c
index bf4d6da..912ab52 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -601,6 +601,87 @@ static u8
dm365_default_priorities[DAVINCI_N_AINTC_IRQ] = {
[IRQ_DM365_EMUINT] = 7,
};
+/* Four Transfer Controllers on DM365 */
+static const s8
+dm365_queue_tc_mapping[][2] = {
+ /* {event queue no, TC no} */
+ {0, 0},
+ {1, 1},
+ {2, 2},
+ {3, 3},
+ {-1, -1},
+};
+
+static const s8
+dm365_queue_priority_mapping[][2] = {
+ /* {event queue no, Priority} */
+ {0, 7},
+ {1, 7},
+ {2, 7},
+ {3, 0},
+ {-1, -1},
+};
+
+static struct edma_soc_info dm365_edma_info = {
+ .n_channel = 64,
+ .n_region = 4,
+ .n_slot = 256,
+ .n_tc = 4,
+ .n_cc = 1,
+ .queue_tc_mapping = dm365_queue_tc_mapping,
+ .queue_priority_mapping = dm365_queue_priority_mapping,
+};
+
+static struct resource edma_resources[] = {
+ {
+ .name = "edma_cc0",
+ .start = 0x01c00000,
+ .end = 0x01c00000 + SZ_64K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "edma_tc0",
+ .start = 0x01c10000,
+ .end = 0x01c10000 + SZ_1K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "edma_tc1",
+ .start = 0x01c10400,
+ .end = 0x01c10400 + SZ_1K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "edma_tc2",
+ .start = 0x01c10800,
+ .end = 0x01c10800 + SZ_1K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "edma_tc3",
+ .start = 0x01c10c00,
+ .end = 0x01c10c00 + SZ_1K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = IRQ_CCINT0,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = IRQ_CCERRINT,
+ .flags = IORESOURCE_IRQ,
+ },
+ /* not using TC*_ERR */
+};
+
+static struct platform_device dm365_edma_device = {
+ .name = "edma",
+ .id = 0,
+ .dev.platform_data = &dm365_edma_info,
+ .num_resources = ARRAY_SIZE(edma_resources),
+ .resource = edma_resources,
+};
+
static struct map_desc dm365_io_desc[] = {
{
.virtual = IO_VIRT,
@@ -698,3 +779,13 @@ void __init dm365_init(void)
{
davinci_common_init(&davinci_soc_info_dm365);
}
+
+static int __init dm365_init_devices(void)
+{
+ if (!cpu_is_davinci_dm365())
+ return 0;
+
+ platform_device_register(&dm365_edma_device);
+ return 0;
+}
+postcore_initcall(dm365_init_devices);
--
1.6.0.4
------------------------------
Message: 2
Date: Tue, 9 Jun 2009 16:20:21 -0500
From: "Karicheri, Muralidharan" <[email protected]>
Subject: RE: [PATCH RFC] adding support for setting bus parameters in
sub device
To: Hans Verkuil <[email protected]>
Cc: "[email protected]"
<[email protected]>,
Muralidharan
Karicheri <[email protected]>,
"[email protected]"
<[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-15"
email: [email protected]
>-----Original Message-----
>From: Hans Verkuil [mailto:[email protected]]
>Sent: Tuesday, June 09, 2009 5:03 PM
>To: Karicheri, Muralidharan
>Cc: [email protected]; davinci-linux-open-
>[email protected]; Muralidharan Karicheri
>Subject: Re: [PATCH RFC] adding support for setting bus parameters in
sub
>device
>
>On Tuesday 09 June 2009 22:55:53 [email protected] wrote:
>> From: Muralidharan Karicheri <[email protected]>
>>
>> re-sending with RFC in the header
>>
>> This patch adds support for setting bus parameters such as bus type
>> (BT.656, BT.1120 etc), width (example 10 bit raw image data bus)
>> and polarities (vsync, hsync, field etc) in sub device. This allows
>> bridge driver to configure the sub device for a specific set of bus
>> parameters through s_bus() function call.
>>
>> Reviewed By "Hans Verkuil".
>> Signed-off-by: Muralidharan Karicheri <[email protected]>
>> ---
>> Applies to v4l-dvb repository
>>
>> include/media/v4l2-subdev.h | 36
++++++++++++++++++++++++++++++++++++
>> 1 files changed, 36 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/media/v4l2-subdev.h
b/include/media/v4l2-subdev.h
>> index 1785608..c1cfb3b 100644
>> --- a/include/media/v4l2-subdev.h
>> +++ b/include/media/v4l2-subdev.h
>> @@ -37,6 +37,41 @@ struct v4l2_decode_vbi_line {
>> u32 type; /* VBI service type (V4L2_SLICED_*). 0
if no
>service found
>> */ };
>>
>> +/*
>> + * Some sub-devices are connected to the bridge device through a bus
>> that + * carries * the clock, vsync, hsync and data. Some interfaces
such
>> as BT.656 + * carries the sync embedded in the data where as others
have
>> separate line + * carrying the sync signals. The structure below is
used
>> by bridge driver to + * set the desired bus parameters in the sub
device
>> to work with it. + */
>> +enum v4l2_subdev_bus_type {
>> + /* BT.656 interface. Embedded sync */
>> + V4L2_SUBDEV_BUS_BT_656,
>> + /* BT.1120 interface. Embedded sync */
>> + V4L2_SUBDEV_BUS_BT_1120,
>> + /* 8 bit muxed YCbCr bus, separate sync and field signals */
>> + V4L2_SUBDEV_BUS_YCBCR_8,
>> + /* 16 bit YCbCr bus, separate sync and field signals */
>> + V4L2_SUBDEV_BUS_YCBCR_16,
>
>Hmm, what do you mean with "8 bit muxed YCbCr bus"? It's not clear to
me
>what the format of these YCBCR bus types is exactly.
>
[MK] For YCbCr16, there is separate bus to carry Y and CbCr data, where
as on YCbCr8, both gets multiplexed over same 8 bit bus (Y, Cb, Y, Cr,
Y, Cb.... The difference between V4L2_SUBDEV_BUS_BT_656 and
V4L2_SUBDEV_BUS_YCBCR_8 is that sync is embedded with data in the
former, where as there is dedicated sync lines for the latter.
>> + /* Raw Bayer image data bus , 8 - 16 bit wide, sync signals */
>> + V4L2_SUBDEV_BUS_RAW_BAYER
>> +};
>> +
>> +struct v4l2_subdev_bus {
>> + enum v4l2_subdev_bus_type type;
>> + u8 width;
>> + /* 0 - active low, 1 - active high */
>> + unsigned pol_vsync:1;
>> + /* 0 - active low, 1 - active high */
>> + unsigned pol_hsync:1;
>> + /* 0 - low to high , 1 - high to low */
>> + unsigned pol_field:1;
>> + /* 0 - sample at falling edge , 1 - sample at rising edge */
>> + unsigned pol_pclock:1;
>> + /* 0 - active low , 1 - active high */
>> + unsigned pol_data:1;
>> +};
>> +
>> /* Sub-devices are devices that are connected somehow to the main
bridge
>> device. These devices are usually audio/video
>> muxers/encoders/decoders or sensors and webcam controllers.
>> @@ -109,6 +144,7 @@ struct v4l2_subdev_core_ops {
>> int (*querymenu)(struct v4l2_subdev *sd, struct v4l2_querymenu
*qm);
>> int (*s_std)(struct v4l2_subdev *sd, v4l2_std_id norm);
>> long (*ioctl)(struct v4l2_subdev *sd, unsigned int cmd, void
*arg);
>> + int (*s_bus)(struct v4l2_subdev *sd, struct v4l2_subdev_bus
*bus);
>
>Make this 'const struct v4l2_subdev_bus *bus'.
>
Ok.
>> #ifdef CONFIG_VIDEO_ADV_DEBUG
>> int (*g_register)(struct v4l2_subdev *sd, struct
v4l2_dbg_register
>> *reg); int (*s_register)(struct v4l2_subdev *sd, struct
v4l2_dbg_register
>> *reg);
>
>Regards,
>
> Hans
>
>--
>Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
------------------------------
Message: 3
Date: Tue, 9 Jun 2009 17:29:04 -0400
From: "Ryan Talbot" <[email protected]>
Subject: RE: CMEM and mmap'd buffers in 2.6.28rc6
To: "Vladimir Pantelic" <[email protected]>,
<[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi Vladimir,
> Ryan Talbot wrote:
>
> > CMEM Error: getPhys: Failed to get physical address of
> 0x4015c000 CMEM
> > Error: getPhys: Failed to get physical address of 0x40226fff
>
> > Those addresses correspond to the virtual addresses of the first
> > capture buffer, and the second capture buffer -1,
> respectively. Those
> > were allocated via kzalloc(), which should yield physically
> contiguous
> > memory, so we don't know what the problem would be.
> > It was suggested by our codec vendor that the issue might
> be the CMEM
> > pool configuration. We find this confusing since the
> capture buffers
> > come from Linux memory, not the CMEM pools. CMEM merely does the
> > virt->phys address translation to hand to the DSP in that
> case, right?
> > Additionally, when recording from file and CMEM actually is
> in charge
> > of allocating the input buffers, things work fine.
>
> > It would seem, then,
> > that CMEM is having trouble translating an address for
> memory that it
> > didn't allocate.
>
> Yes, as seen by the above error. why don't you allocate the
> mem from CMEM?
>
Well, it was my understanding that CMEM should be able to translate any
virtual address to a physical address. These buffers are internally
allocated by the vpfe_capture driver and mmap'd to user space. This was
the way it worked in 2.6.10, anyhow. Furthermore, looking at the code
for the CMEM module, it just uses get_user() and get_phys() system calls
to do the translation, so it should not care who originally allocated
the memory.
Am I mistaken in this?
Ryan
------------------------------
Message: 4
Date: Wed, 10 Jun 2009 01:02:03 +0300
From: Yusuf Caglar AKYUZ <[email protected]>
Subject: Re: device driver for 800x480 LCD
To: elbert shiang <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
elbert shiang wrote:
> Hi, Dear All:
>
> I want to make dm355 connect to the TFT-LCD which has RGB666 signal.
>
> I have no idea where to start to build the device driver from tool
chain. Can anyone guide me which documentation I should read and what
brief procedure I should proceed to integarte the 800x480 TFT-LCD into
Linex kernel?
>
> the LCD I refer to is AM800480E3TMQW-00H from AMPIRE CO.
>
> Thanks,
> Elbert
>
>
I added some information to DaVinci wiki at [1] about LCD
interfacing to DaVinci kernels. It may give you a starting point. By
looking at the datasheet of your LCD, it must be fairly easy to
interface.
Regards,
Caglar
[1] http://wiki.davincidsp.com/index.php/LCD_RGB_640x480_VGA_Addition
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAkou29sACgkQ/nL+S5dojegkkACdG/wdt4cdcYN7OjCPVFuPQRHn
9R4AniFELEwkxzooVt6loZIo9/4vAF64
=ZaWe
-----END PGP SIGNATURE-----
------------------------------
Message: 5
Date: Tue, 9 Jun 2009 17:00:24 -0500
From: "Tivy, Robert" <[email protected]>
Subject: RE: CMEM and mmap'd buffers in 2.6.28rc6
To: Ryan Talbot <[email protected]>, Vladimir Pantelic
<[email protected]>,
"[email protected]"
<[email protected]>
Cc: "[email protected]"
<[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]
> ] On Behalf Of Ryan Talbot
> Sent: Tuesday, June 09, 2009 2:29 PM
> To: Vladimir Pantelic; [email protected]
> Cc: [email protected]
> Subject: RE: CMEM and mmap'd buffers in 2.6.28rc6
>
> Hi Vladimir,
>
> > Ryan Talbot wrote:
> >
> > > CMEM Error: getPhys: Failed to get physical address of
> > 0x4015c000 CMEM
> > > Error: getPhys: Failed to get physical address of 0x40226fff
> >
> > > Those addresses correspond to the virtual addresses of the first
> > > capture buffer, and the second capture buffer -1,
> > respectively. Those
> > > were allocated via kzalloc(), which should yield physically
> > contiguous
> > > memory, so we don't know what the problem would be.
> > > It was suggested by our codec vendor that the issue might
> > be the CMEM
> > > pool configuration. We find this confusing since the
> > capture buffers
> > > come from Linux memory, not the CMEM pools. CMEM merely does the
> > > virt->phys address translation to hand to the DSP in that
> > case, right?
> > > Additionally, when recording from file and CMEM actually is
> > in charge
> > > of allocating the input buffers, things work fine.
> >
> > > It would seem, then,
> > > that CMEM is having trouble translating an address for
> > memory that it
> > > didn't allocate.
> >
> > Yes, as seen by the above error. why don't you allocate the
> mem from
> > CMEM?
> >
>
>
> Well, it was my understanding that CMEM should be able to
> translate any virtual address to a physical address. These
> buffers are internally allocated by the vpfe_capture driver
> and mmap'd to user space. This was the way it worked in
> 2.6.10, anyhow. Furthermore, looking at the code for the
> CMEM module, it just uses get_user() and get_phys() system
> calls to do the translation, so it should not care who
> originally allocated the memory.
>
> Am I mistaken in this?
>
> Ryan
Sometime after 2.6.10 the CMEM get_phys() function stopped working for
kernel addresses. Kevin Hillman provided a new one to work with newer
kernels (unverified), but I discovered that this new one didn't
correctly translate non-direct-mapped kernel addresses, so I added code
to CMEM to save the lower/upper bounds of the CMEM blocks' kernel
addresses, and manually look for those in get_phys() before trying more
general methods of translation.
So, in short, CMEM's get_phys() doesn't handle non-direct-mapped kernel
addresses except the ones that correspond to CMEM's managed memory
block(s).
Regards,
- Rob
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> [email protected]
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
------------------------------
Message: 6
Date: Tue, 9 Jun 2009 18:16:22 -0400
From: [email protected]
Subject: [PATCH] Minor Update to Kconfig
To: [email protected]
Message-ID: <[email protected]>
Patch updates the Kconfig for the various DaVinci EVMs
This is being done based on a comment received when
DM365 patches were reviewed.
Each EVM defaults to be enabled whenever the SOC is enabled
Signed-off-by: Sandeep Paulraj <[email protected]>
---
arch/arm/mach-davinci/Kconfig | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/Kconfig
b/arch/arm/mach-davinci/Kconfig
index 7640867..c259841 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -26,7 +26,7 @@ comment "DaVinci Board Type"
config MACH_DAVINCI_EVM
bool "TI DM644x EVM"
- default y
+ default ARCH_DAVINCI_DM644x
depends on ARCH_DAVINCI_DM644x
help
Configure this option to specify the whether the board used
@@ -34,7 +34,7 @@ config MACH_DAVINCI_EVM
config MACH_SFFSDR
bool "Lyrtech SFFSDR"
- default n
+ default ARCH_DAVINCI_DM644x
depends on ARCH_DAVINCI_DM644x
help
Say Y here to select the Lyrtech Small Form Factor
@@ -42,7 +42,7 @@ config MACH_SFFSDR
config MACH_DAVINCI_DM355_EVM
bool "TI DM355 EVM"
- default n
+ default ARCH_DAVINCI_DM355
depends on ARCH_DAVINCI_DM355
help
Configure this option to specify the whether the board used
@@ -50,7 +50,7 @@ config MACH_DAVINCI_DM355_EVM
config MACH_DM355_LEOPARD
bool "DM355 Leopard board"
- default n
+ default ARCH_DAVINCI_DM355
depends on ARCH_DAVINCI_DM355
help
Configure this option to specify the whether the board used
@@ -58,7 +58,7 @@ config MACH_DM355_LEOPARD
config MACH_DAVINCI_DM6467_EVM
bool "TI DM6467 EVM"
- default n
+ default ARCH_DAVINCI_DM646x
depends on ARCH_DAVINCI_DM646x
help
Configure this option to specify the whether the board used
--
1.6.0.4
------------------------------
Message: 7
Date: Tue, 9 Jun 2009 18:18:16 -0400
From: [email protected]
Subject: [PATCH v1] DM365 NAND Support
To: [email protected]
Message-ID: <[email protected]>
This patch adds NAND support for the DM365.
The EMIF controller on the DM365 is the same as the DM355.
Signed-off-by: Sandeep Paulraj <[email protected]>
---
arch/arm/mach-davinci/board-dm365-evm.c | 84
+++++++++++++++++++++++++++++++
1 files changed, 84 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index 08c2f12..07ae930 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -19,6 +19,9 @@
#include <linux/i2c.h>
#include <linux/io.h>
#include <linux/clk.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/nand.h>
#include <asm/setup.h>
#include <asm/mach-types.h>
@@ -33,6 +36,80 @@
#include <linux/i2c.h>
#include <mach/serial.h>
#include <mach/common.h>
+#include <mach/nand.h>
+
+#define DAVINCI_ASYNC_EMIF_CONTROL_BASE 0x01d10000
+#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x02000000
+
+/* NOTE: this is geared for the standard config, with a socketed
+ * 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you
+ * swap chips with a different block size, partitioning will
+ * need to be changed. This NAND chip MT29F16G08FAA is the default
+ * NAND shipped with the Spectrum Digital DM365 EVM
+ */
+#define NAND_BLOCK_SIZE SZ_128K
+
+static struct mtd_partition davinci_nand_partitions[] = {
+ {
+ /* UBL (a few copies) plus U-Boot */
+ .name = "bootloader",
+ .offset = 0,
+ .size = 28 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE, /* force read-only */
+ }, {
+ /* U-Boot environment */
+ .name = "params",
+ .offset = MTDPART_OFS_APPEND,
+ .size = 2 * NAND_BLOCK_SIZE,
+ .mask_flags = 0,
+ }, {
+ .name = "kernel",
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_4M,
+ .mask_flags = 0,
+ }, {
+ .name = "filesystem1",
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_512M,
+ .mask_flags = 0,
+ }, {
+ .name = "filesystem2",
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ .mask_flags = 0,
+ }
+ /* two blocks with bad block table (and mirror) at the end */
+};
+
+static struct davinci_nand_pdata davinci_nand_data = {
+ .mask_chipsel = BIT(14),
+ .parts = davinci_nand_partitions,
+ .nr_parts = ARRAY_SIZE(davinci_nand_partitions),
+ .ecc_mode = NAND_ECC_HW,
+ .options = NAND_USE_FLASH_BBT,
+};
+
+static struct resource davinci_nand_resources[] = {
+ {
+ .start = DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
+ .end = DAVINCI_ASYNC_EMIF_DATA_CE0_BASE +
SZ_32M - 1,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = DAVINCI_ASYNC_EMIF_CONTROL_BASE,
+ .end = DAVINCI_ASYNC_EMIF_CONTROL_BASE +
SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device davinci_nand_device = {
+ .name = "davinci_nand",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(davinci_nand_resources),
+ .resource = davinci_nand_resources,
+ .dev = {
+ .platform_data = &davinci_nand_data,
+ },
+};
static struct davinci_i2c_platform_data i2c_pdata = {
.bus_freq = 400 /* kHz */,
@@ -44,6 +121,10 @@ static void __init evm_init_i2c(void)
davinci_init_i2c(&i2c_pdata);
}
+static struct platform_device *dm365_evm_devices[] __initdata = {
+ &davinci_nand_device,
+};
+
static struct davinci_uart_config uart_config __initdata = {
.enabled_uarts = (1 << 0),
};
@@ -55,6 +136,9 @@ static void __init dm365_evm_map_io(void)
static __init void dm365_evm_init(void)
{
+ platform_add_devices(dm365_evm_devices,
+ ARRAY_SIZE(dm365_evm_devices));
+
evm_init_i2c();
davinci_serial_init(&uart_config);
}
--
1.6.0.4
------------------------------
_______________________________________________
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 42, Issue 53
*********************************************************
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
