Re: [PATCH 16/18] ARM: da830 - Add base DA830/OMAP-L137 SoC support
On Tuesday 31 March 2009, Nori, Sekhar wrote: 2) It detects and complains about pinmux contention and there is a lot of potential contention with the da830. No less so than with OMAP, or lots of other SoCs. Contention is rarely a problem given a clearly structured framework for board init ... like being able to rely on device registration to perform the pinmux. But when contention does happen, isn't the best way of flagging that is to return -EBUSY from driver probe No, that's very late. And it presumes drivers have a way to recover from such faults ... having drivers worry about pinmux variants on the various SoCs is a *really* bad game to play, it makes for unmaintainable code. (Since each new SoC needs a bunch of driver patches...) and let userland figure out that the kernel doesn't quite have what it needs (when it can't open the device node)? I think the best way of dealing with that kind of contention is to just structure things so that it doesn't happen. :) After all, the hardware designers manage to build systems where that's not an issue. If the software doesn't have an easy way to express that, that software is clearly goofy. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Welcome to the Davinci-linux-open-source@linux.davincidsp.com mailing
Hi: this is a test!!! OK? ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 16/18] ARM: da830 - Add base DA830/OMAP-L137 SoC support
From: David Brownell [mailto:davi...@pacbell.net] Sent: Wednesday, April 01, 2009 11:37 AM On Tuesday 31 March 2009, Nori, Sekhar wrote: 2) It detects and complains about pinmux contention and there is a lot of potential contention with the da830. No less so than with OMAP, or lots of other SoCs. Contention is rarely a problem given a clearly structured framework for board init ... like being able to rely on device registration to perform the pinmux. But when contention does happen, isn't the best way of flagging that is to return -EBUSY from driver probe No, that's very late. And it presumes drivers have a way to recover from such faults ... having drivers worry about pinmux variants on the various SoCs is a *really* bad game to play, it makes for unmaintainable code. (Since each new SoC needs a bunch of driver patches...) I am not suggesting that drivers needs to deal with pinmux variations across SoCs but I think the driver does need to request the platform that all the pins required for basic operation be available. Shouldn't this be similar to irq or memory resources reserved by driver and at the same time not having to deal with variations in the actual resource across platforms? Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
SD card usage
Hi I am using sd card to store pictures and other relevant data in my system. I hoped it will copy faster, but it is not a problem. I have pretty bigger problem to umount sdcard. It has FAT file system. And it takes about 5 minutes to umount. I have tried to pull out card during umount and get realy hudege bunch of errors. Any suggestion why it takes so long. Ondrej Pindroch SoftHard Technology ltd. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 16/18] ARM: da830 - Add base DA830/OMAP-L137 SoC support
On Tuesday 31 March 2009, Nori, Sekhar wrote: I am not suggesting that drivers needs to deal with pinmux variations across SoCs but I think the driver does need to request the platform that all the pins required for basic operation be available. I'm suggesting that it's simpler if the platform just not provide devices that aren't-all-there. Shouldn't this be similar to irq or memory resources reserved by driver and at the same time not having to deal with variations in the actual resource across platforms? If you want to propose a platform-neutral interface for requesting or configuring pins, go for it. :) I think you'll have a hard time getting traction with that kind of model, however. It's not exactly an area where cross-platform portability has been an issue. Lots of systems even leave it to the bootloader, and platform capabilities vary widely. - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 16/18] ARM: da830 - Add base DA830/OMAP-L137 SoC support
From: David Brownell [mailto:davi...@pacbell.net] Sent: Wednesday, April 01, 2009 12:23 PM On Tuesday 31 March 2009, Nori, Sekhar wrote: I am not suggesting that drivers needs to deal with pinmux variations across SoCs but I think the driver does need to request the platform that all the pins required for basic operation be available. I'm suggesting that it's simpler if the platform just not provide devices that aren't-all-there. Shouldn't this be similar to irq or memory resources reserved by driver and at the same time not having to deal with variations in the actual resource across platforms? If you want to propose a platform-neutral interface for requesting or configuring pins, go for it. :) This is where such discussions usually end :) Let's see what Steve Chen comes up with. I think we at least agree that detecting contentions and splitting errors/warnings would be useful. Thanks, Sekhar I think you'll have a hard time getting traction with that kind of model, however. It's not exactly an area where cross-platform portability has been an issue. Lots of systems even leave it to the bootloader, and platform capabilities vary widely. - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 16/18] ARM: da830 - Add base DA830/OMAP-L137 SoC support
On Wednesday 01 April 2009, Nori, Sekhar wrote: I think we at least agree that detecting contentions and splitting errors/warnings would be useful. I'm still at the convince me, I'm skeptical stage there. It's literally been *years* since I've seen pin contention problems. The last time I recall seeing one ... was with an OMAP1 device, where it was a secondary contention thing. Two different pins were both routed to different chips. Each could be configured as either of two GPIOs. But it turned out that the only possible configuration for each pin was to have them use the same GPIO (since its other GPIO option was needed elsewhere, on pins with no mux options). That class of mux contention problem is a bit beyond what I'd expect any sane programming interface to address; it was really a hardware bug, which only showed up late in system integration testing (needed a board respin). There are other problems that I could believe need some cross-platform solution (maybe), and if some kind of record of pin configuration (and thus ability to detect and report that's in use) falls out, that could be fine. - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: SD card usage
Try mounting it with the sync option and seeing how long it takes to unmount then. Andrew Ondrej Pindroch wrote: Hi I am using sd card to store pictures and other relevant data in my system. I hoped it will copy faster, but it is not a problem. I have pretty bigger problem to umount sdcard. It has FAT file system. And it takes about 5 minutes to umount. I have tried to pull out card during umount and get realy hudege bunch of errors. Any suggestion why it takes so long. */ Ondrej Pindroch SoftHard Technology ltd. /* ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Use of shared buffer for VPBE
Hi, This is not possible in frame buffer driver but you can do other way, take the buffer from frame buffer driver and use it in resizer. Thanks, Brijesh Jadav From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Ondrej Pindroch Sent: Tuesday, March 31, 2009 6:44 PM To: davinci-linux-open-source Subject: Use of shared buffer for VPBE HI I have one question is it possible to use the same buffer which comes from for example resizer as input for video output, without need of copying data from one location to an other? I have seen som examples, they are copying data to an other buffer. This consumes lot of time. Ondrej Pindroch SoftHard Technology ltd. Tel: +421(2)65459327 Fax: +421(2)65459329 Mobile:+421(904)906011 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Matlab code with DM 6467
Hi, I have worked a bit on getting OpenCV up on the ARM side of the DM6446 (not using the DSP). I followed the instructions from http://danielbaggio.blogspot.com/2009/01/compiling-opencv-for-gumstix.html and got the library compiled, but during testing with the facedetect example program it failed inside an OpenCV library call. (Note that I used the CodeSourcery ARM toolchain and not the OpenEmbedded toolchain mentioned in the above link.) If you get it running I'd be happy to hear how you did it. Regards, Bjørn Forsman 2009/4/1 Abhishek Botadra abhibota...@gmail.com Thanks for the link. I used Matlab to generate C code but its giving me lot many header file conflicts when I try to compile it using GCC. Also, the C code generated is quite difficult to understand which would make debugging difficult. As per the link, the software needs to be purchased. So, it seems there is no free software available for this. I was wondering if anyone has tried porting OpenCV (computer vision library) to DM 6467. It seems that it might be helpful in writing the C code for the processor. Thanks, Abhishek On Mon, Mar 30, 2009 at 5:09 PM, C.L. Hammond lappin.hamm...@gmail.comwrote: 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 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 matlab code or I need to manually write the C code. Any links/suggestions would be a great help. Thanks, Abhishek ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- -- Lappin Hammond -- Abhishek ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/3] SPI Driver for DaVinci/DA8xx
On Monday 30 March 2009, s-paul...@ti.com wrote:
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.
Real quick comments, in the form of a patch that mostly
adds comments. :)
I've not yet dared to try running this, since it seems
to demand some extra configuration that shouldn't be
necessary (controller_data, mostly expanding spi-mode).
It'll also fail if there's a transfer active to one
device at the same time spi_setup(other_device) gets
called.
It's light on error checking in setup() and transfer().
- Dave
=
--- d26.orig/drivers/spi/Kconfig2009-04-01 02:36:29.0 -0700
+++ d26/drivers/spi/Kconfig 2009-04-01 02:31:24.0 -0700
@@ -83,7 +83,7 @@ config SPI_DAVINCI
select SPI_BITBANG
default y
help
- SPI master controller for DaVinci MibSPI modules.
+ SPI master controller for DaVinci SPI modules.
config SPI_DAVINCI_INTERRUPT
bool Set DaVinci SPI to Interrupt mode
--- d26.orig/drivers/spi/davinci_spi_master.c 2009-04-01 02:36:29.0
-0700
+++ d26/drivers/spi/davinci_spi_master.c2009-04-01 02:36:17.0
-0700
@@ -19,6 +19,9 @@
#include linux/platform_device.h
+// as noted before:shorter name here.
+// spi_davinci.c to match the driver name.
+
#include linux/spi/davinci_spi_master.h
#include linux/dma-mapping.h
#include linux/io.h
@@ -30,6 +33,7 @@ static inline void davinci_spi_rx_buf_u8
struct davinci_spi *davinci_spi)
{
u8 *rx = davinci_spi-rx;
+
*rx++ = (u8)data;
davinci_spi-rx = rx;
}
@@ -38,6 +42,7 @@ static inline void davinci_spi_rx_buf_u1
struct davinci_spi *davinci_spi)
{
u16 *rx = davinci_spi-rx;
+
*rx++ = (u16)data;
davinci_spi-rx = rx;
}
@@ -46,6 +51,7 @@ static inline u32 davinci_spi_tx_buf_u8(
{
u32 data;
const u8 *tx = davinci_spi-tx;
+
data = *tx++;
davinci_spi-tx = tx;
return data;
@@ -55,6 +61,7 @@ static inline u32 davinci_spi_tx_buf_u16
{
u32 data;
const u16 *tx = davinci_spi-tx;
+
data = *tx++;
davinci_spi-tx = tx;
return data;
@@ -74,6 +81,9 @@ static inline void clear_bits(void __iom
iowrite32(v, addr);
}
+// whoa, this looks like overkill.
+// why not just use FMT0 for CS0, FMT1 for CS1, etc?
+
static inline void set_fmt_bits(void __iomem *addr, u32 bits)
{
set_bits(addr + SPIFMT0, bits);
@@ -104,6 +114,9 @@ static void davinci_spi_chipselect(struc
pdata = davinci_spi-pdata;
if (value == BITBANG_CS_INACTIVE) {
+ // No reason not to support SPI_CS_HIGH (someday!)
+ // ... and normally you'd set just ONE chipselect
+
/* set all chip select high */
if (pdata-chip_sel != NULL) {
for (i = 0; i pdata-num_chipselect; i++) {
@@ -168,6 +181,9 @@ static int davinci_spi_setup_transfer(st
hz = spi-max_speed_hz;
if (!hz) {
hz = 200;
+ // use dev_warn()
+ // and comment why 2 MHz is used, instead
+ // of a clean failure (MUCH earlier)
pr_info([SPI] - Slave device speed not set
correctly. Trying with %dHz\n, hz);
}
@@ -176,7 +192,7 @@ static int davinci_spi_setup_transfer(st
clear_fmt_bits(davinci_spi-base, SPI_SPIFMT_CHARLEN_MASK);
set_fmt_bits(davinci_spi-base, bits_per_word 0x1f);
- prescale = ((clk_get_rate(pdata-clk_info) / hz) - 1) 0xff;
+ prescale = ((clk_get_rate(davinci_spi-clk) / hz) - 1) 0xff;
clear_fmt_bits(davinci_spi-base, 0xff00);
set_fmt_bits(davinci_spi-base, prescale 8);
@@ -196,6 +212,9 @@ static int davinci_spi_setup(struct spi_
int retval;
struct davinci_spi *davinci_spi;
+ // check bits in spi-mode ... if any are set that
+ // we don't understand, fail.
+
davinci_spi = spi_master_get_devdata(spi-master);
if (!spi-bits_per_word)
@@ -203,16 +222,25 @@ static int davinci_spi_setup(struct spi_
davinci_spi-slave[spi-chip_select].cmd_to_write = 0;
+ // NO!!!
+ // - you're trashing all FMTx bits ... but a transfer to
+ //another spi_device may now be active!!
+ // - you're ignoring chipselect, instead of forcing it
+ //to be inactive (possibly affected by SPI_CS_HIGH)
+
retval = davinci_spi_setup_transfer(spi, NULL);
return retval;
}
+#if 0
static void davinci_spi_cleanup(const struct spi_device *spi)
{
- struct davinci_spi *davinci_spi =
Re: [PATCH 2/3] DM355 SPI Support
On Monday 30 March 2009, s-paul...@ti.com wrote:
@@ -377,14 +382,21 @@ static struct davinci_clk dm355_clks[] = {
static u64 dm355_spi0_dma_mask = DMA_32BIT_MASK;
+static struct davinci_spi_platform_data dm355_spi0_pdata = {
+ .version = DAVINCI_SPI_VERSION_1,
+ .num_chipselect = 2,
+ .clk_name = spi0,
See comments in that driver. clk_get(dev, logical name -or- NULL)
suffices; don't pass clock names like this.
+};
+
static struct resource dm355_spi0_resources[] = {
- {
- .start = 0x01c66000,
- .end = 0x01c667ff,
+ [0] = {
+ .start = DM355_SPI0_BASE,
+ .end = DM355_SPI0_BASE + (SZ_4K/2) - 1,
Maybe it's just me, but I'd rather see the numbers direct from
the data sheet than add multiple new symbols, which aren't at
all obviously correct.
.flags = IORESOURCE_MEM,
},
- {
- .start = IRQ_DM355_SPINT0_1,
+ [1] = {
+ .start = IRQ_DM355_SPINT0_0,
+ .end = IRQ_DM355_SPINT0_0,
The .end isn't really needed. :)
FWIW the reason this originally used the second IRQ
for the controller was I think that it had fewer
irq mux conflicts ... SPINT1_1 is muxed with the EDMA
channel controller error IRQ on dm355, which we *do*
use today (weakly).
.flags = IORESOURCE_IRQ,
},
/* Not yet used, so not included:
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[patch 2.6.29-davinci1 git] dm6446evm CF support
From: David Brownell dbrown...@users.sourceforge.net
This provides basic support for the CF slot on the dm6446 EVM.
Insert/remove events are not (currently) supported.
On a very small sample of cards, using hdparm -tT to measure
(and correct for buffer access), throughput is about 1.5 MB/sec.
That's a third what an ATA drive gives on the same system; the
CF cards do not support DMA access modes. Root on an SD card
remains the fastest choice for non-NFS root (over 8 MB/sec).
(Unrelated: remove obsolete ref to RTC.)
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
Same as before, but the probe() call got rid of an #ifdef
arch/arm/mach-davinci/Kconfig| 11 +
arch/arm/mach-davinci/board-dm644x-evm.c | 33 ++---
2 files changed, 32 insertions(+), 12 deletions(-)
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -26,6 +26,17 @@ config MACH_DAVINCI_EVM
Configure this option to specify the whether the board used
for development is a DM644x EVM
+config MACH_DAVINCI_EVM_CF
+ bool Use CompactFlash, not IDE drive
+ depends on MACH_DAVINCI_EVM BLK_DEV_PALMCHIP_BK3710
+ help
+ Enable this if you want to use a CompactFlash card instead of
+ an IDE/ATA drive. The CF card will be used in True IDE mode.
+
+ At this writing, CF insert and remove events are not supported.
+ Insert the CF at boot time, and leave it there until you power
+ the system off.
+
config MACH_DAVINCI_DM646X_EVM
bool TI DM646x EVM
default n
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -192,11 +192,6 @@ static struct platform_device davinci_fb
.num_resources = 0,
};
-static struct platform_device rtc_dev = {
- .name = rtc_davinci_evm,
- .id = -1,
-};
-
static struct resource ide_resources[] = {
{
.start = DAVINCI_CFC_ATA_BASE,
@@ -368,6 +363,13 @@ static struct pcf857x_platform_data pcf_
/* U35 - various I/O signals used to manage USB, CF, ATA, etc */
+#ifdef CONFIG_MACH_DAVINCI_EVM_CF
+#define USE_CF 1
+#else
+#define USE_CF 0
+#endif
+#define USE_HDD(!USE_CF)
+
static int
evm_u35_setup(struct i2c_client *client, int gpio, unsigned ngpio, void *c)
{
@@ -383,9 +385,9 @@ evm_u35_setup(struct i2c_client *client,
gpio_request(gpio + 2, VLYNQ_EN);
gpio_direction_output(gpio + 2, 1);
- /* p3 = n3V3_CF_RESET (initial: stay in reset) */
+ /* p3 = n3V3_CF_RESET (initial: stay reset unless using CF) */
gpio_request(gpio + 3, nCF_RESET);
- gpio_direction_output(gpio + 3, 0);
+ gpio_direction_output(gpio + 3, USE_CF);
/* (p4 unused) */
@@ -393,13 +395,13 @@ evm_u35_setup(struct i2c_client *client,
gpio_request(gpio + 5, WLAN_RESET);
gpio_direction_output(gpio + 5, 1);
- /* p6 = nATA_SEL (initial: select) */
+ /* p6 = nATA_SEL (initial: select unless CF is used) */
gpio_request(gpio + 6, nATA_SEL);
- gpio_direction_output(gpio + 6, 0);
+ gpio_direction_output(gpio + 6, !USE_HDD);
- /* p7 = nCF_SEL (initial: deselect) */
+ /* p7 = nCF_SEL (initial: select only if CF is used) */
gpio_request(gpio + 7, nCF_SEL);
- gpio_direction_output(gpio + 7, 1);
+ gpio_direction_output(gpio + 7, !USE_CF);
/* irlml6401 switches over 1A, in under 8 msec;
* now it can be managed by nDRV_VBUS ...
@@ -488,6 +490,14 @@ static struct i2c_client *dm6446evm_msp;
static int dm6446evm_msp_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
+ if (USE_CF) {
+ static const u8 cmdbuf[4] = { 4, 6, 0, BIT(3) | BIT(0), };
+
+ /* CF slot powered up: BIT(3) set.
+* SmartMedia powered off: BIT(0) set.
+*/
+ i2c_master_send(client, cmdbuf, sizeof cmdbuf);
+ }
dm6446evm_msp = client;
return 0;
}
@@ -612,7 +622,6 @@ static void __init evm_init_i2c(void)
static struct platform_device *davinci_evm_devices[] __initdata = {
davinci_fb_device,
- rtc_dev,
};
static struct davinci_uart_config uart_config __initdata = {
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Matlab code with DM 6467
On 01-04-09 11:17, Bjørn Forsman wrote: Hi, I have worked a bit on getting OpenCV up on the ARM side of the DM6446 (not using the DSP). I followed the instructions from http://danielbaggio.blogspot.com/2009/01/compiling-opencv-for-gumstix.html and got the library compiled, but during testing with the facedetect example program it failed inside an OpenCV library call. (Note that I used the CodeSourcery ARM toolchain and not the OpenEmbedded toolchain mentioned in the above link.) If you get it running I'd be happy to hear how you did it. I you use openembedded: MACHINE=davinci-dvevm bitbake opencv The face-detect sample runs fine, albeit slowly on arm9 and cortex CPUs: http://www.flickr.com/photos/koenkooi/3039017696/ regards, Koen ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [patch 2.6.29-davinci1 git] dm6446evm CF support
David Brownell wrote: This provides basic support for the CF slot on the dm6446 EVM. Insert/remove events are not (currently) supported. On a very small sample of cards, using hdparm -tT to measure (and correct for buffer access), throughput is about 1.5 MB/sec. That's a third what an ATA drive gives on the same system; the CF cards do not support DMA access modes. Root on an SD card remains the fastest choice for non-NFS root (over 8 MB/sec). (Unrelated: remove obsolete ref to RTC.) Signed-off-by: David Brownell dbrown...@users.sourceforge.net --- a/arch/arm/mach-davinci/Kconfig +++ b/arch/arm/mach-davinci/Kconfig @@ -26,6 +26,17 @@ config MACH_DAVINCI_EVM Configure this option to specify the whether the board used for development is a DM644x EVM +config MACH_DAVINCI_EVM_CF + bool Use CompactFlash, not IDE drive + depends on MACH_DAVINCI_EVM BLK_DEV_PALMCHIP_BK3710 + help + Enable this if you want to use a CompactFlash card instead of + an IDE/ATA drive. The CF card will be used in True IDE mode. + + At this writing, CF insert and remove events are not supported. + Insert the CF at boot time, and leave it there until you power + the system off. + This instruction is already obsolete. As I've already noted, IDE core now supports warm plug via sysfs, see Documentation/ide/warm-plug-howto.txt. One can plug and unplug any time, this just won't be automatically noticed by the kernel, so one will need to notify it. MBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH resend] musb_gadget: fix STALL handling
Hello. David Brownell wrote: Could you take another whack at this, and include set_wedge()? You mean implementing set_wedge()? I thinkl this should be in another patch. OK, but in that case I'd like to see that one first, then see what issues remain. Frankly speaking, I don't see how implementing set_wedge() may influence the issues which this patch tries to deal with, namely: - abortion of requests queued while EP is halted; - starting OUT transfers despite EP is halted. I'll give this an eyeballing anyway, on the grounds that at least some parts of this are probably right already ... just, the mass storage support can't be exactly correct. Why? Is set_wedge() required now? Stricter conformance to the mass storage class spec is the reason for set_wedge(). This patch was described as aiding such conformance. Ah, OK, thanks for clarification. I'm seeing that the file-storage gadget is the only oince calling set_wedge() method. Now, it's clear there is one inherent issue in the current code: no set_wedge(). My eventual eyeballing will be because I suspect there may be other issues too. There surely are, hence the patch. See, I ran the USBCV tests last week -- not on file_storage, just standard tests, on gadget zero -- and the current code passed those just fine. So to that extent, what's needed is will be something specific to mass storage support. I'm not sure it's specific enough... - Dave WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Bottom boot Uboot
Hi all, Does anybody have a Bottom boot UBoot code; If so where can I download it. Thank you. Regards, Gopal Sukumar http://www.mindtree.com/email/disclaimer.html ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 16/18] ARM: da830 - Add base DA830/OMAP-L137 SoC support
On Wed, 2009-04-01 at 12:48 +0530, Nori, Sekhar wrote: From: David Brownell [mailto:davi...@pacbell.net] Sent: Wednesday, April 01, 2009 12:23 PM On Tuesday 31 March 2009, Nori, Sekhar wrote: I am not suggesting that drivers needs to deal with pinmux variations across SoCs but I think the driver does need to request the platform that all the pins required for basic operation be available. I'm suggesting that it's simpler if the platform just not provide devices that aren't-all-there. Shouldn't this be similar to irq or memory resources reserved by driver and at the same time not having to deal with variations in the actual resource across platforms? If you want to propose a platform-neutral interface for requesting or configuring pins, go for it. :) This is where such discussions usually end :) Let's see what Steve Chen comes up with. I think we at least agree that detecting contentions and splitting errors/warnings would be useful. I guess I should say something since this was my crazy patch :) I put in the pinmux conflict detection code in da8xx because certain interfaces can not be used at the same time. For example, NAND/NOR on UI daughter card uses the same pins as MMC/SD. If a user tries to use UI card NAND/NOR and MMC/SD at the same time, one of them is obviously not going to work. The pinmux conflict detection prints out an error and stop driver from loading. Any issues regarding conflicting pinmux becomes obvious. The user then has the option of changing kernel config/rebuild or unload/load the appropriate kernel modules to work around this issue. There could be other daughter cards for DA8xx/OMAP-L137 to further complicate pinmux dependencies. Having some type of conflict detection seem to be (at least to me) a clean way to avoid problems down the road. Pinmux conflict problem is not new. The DM644x EVM, for example, IDE and NOR can not be enabled at the same time. Regards, Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] DaVinci NAND: Add support for 4-bit ECC, up to 4K page size with 128bytes OOB and standard NAND layouton DM355
From: Sneha Narnakaje nsnehapra...@ti.com
This patch adds support for NAND on DM355, with 4-bit ECC, up to 4K page size
and 128bytes of OOB. The core MTD NAND ECC APIs have been overridden for
layout, calculate, correct, hwctl, read_page/write_page and read_oob/write_oob.
The ECC (data) size is configured as 512bytes (since the EMIF supports 4-bit HW
for every 512bytes read/write) with 10bytes of ECC and 6bytes of prepad. The
driver uses NAND_ECC_HW_SYNDROME ecc mode for DM355. We could also have used
NAND_ECC_HW ecc mode, but again had to override the read_page/write_page APIs,
since we have to read the whole OOB area and then data in 512byte chunks. If we
do need to support the old legacy layout (for backward compatibility reasons),
we have to come up another set of read_page/write_page APIs and also need to
override read_page_raw/write_page_raw APIs.
This patch is dependent on the MTD-NAND patch sent to linux-mtd and LKLM. This
patch along with MTD-NAND patch has been tested on the DM355 EVM with the
default Micron 2GB NAND device (2K page size) and Samsung 2GB NAND device (4K
page size). Following are some of the tests conducted:
1. 4-bit HW ECC: Bit errors up to 4-bits (every 512-byte chunk) were introduced
and checked for correction. MTD utilities - nandwrite and nanddump were used to
perform the tests.
2. JFFS2: Populated a reduced filesystem on mtd3/mtd4 partition and booted it
as a rootfs.
3. mtd-tests: Ran mtd_oobtest, mtd_pagetest, mtd_readtest, mtd_speedtest and
mtd_stresstest, with no errors.
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Signed-off-by: Sneha Narnakaje nsnehapra...@ti.com
---
arch/arm/mach-davinci/include/mach/nand.h |9 +
drivers/mtd/nand/davinci_nand.c | 393 -
2 files changed, 398 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/nand.h
b/arch/arm/mach-davinci/include/mach/nand.h
index ee7b7b7..7dafe9f 100644
--- a/arch/arm/mach-davinci/include/mach/nand.h
+++ b/arch/arm/mach-davinci/include/mach/nand.h
@@ -57,6 +57,15 @@
#defineMASK_ALE0x08
#defineMASK_CLE0x10
+/* Definitions for 4-bit hardware ECC */
+#define NAND_4BIT_ECC_MASK 0x03FF03FF
+#define NANDFSR_ECC_STATE_MASK 0x0F00
+#define ECC_STATE_NO_ERR 0x0
+#define ECC_STATE_TOO_MANY_ERRS0x1
+#define ECC_STATE_ERR_CORR_COMP_P 0x2
+#define ECC_STATE_ERR_CORR_COMP_N 0x3
+#define ECC_MAX_CORRECTABLE_ERRORS 0x4
+
struct davinci_nand_pdata {/* platform_data */
u32 mask_ale;
u32 mask_cle;
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index a2f78ad..9f8a2f7 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -26,6 +26,7 @@
#include linux/kernel.h
#include linux/init.h
#include linux/module.h
+#include linux/delay.h
#include linux/platform_device.h
#include linux/err.h
#include linux/clk.h
@@ -87,6 +88,8 @@ struct davinci_nand_info {
static DEFINE_SPINLOCK(davinci_nand_lock);
+static u_char davinci_ecc_buf[NAND_MAX_OOBSIZE];
+
#define to_davinci_nand(m) container_of(m, struct davinci_nand_info, mtd)
@@ -275,6 +278,378 @@ static int nand_davinci_dev_ready(struct mtd_info *mtd)
return davinci_nand_readl(info, NANDFSR_OFFSET) BIT(0);
}
+/* DaVinci specific flash bbt decriptors */
+static uint8_t nand_davinci_bbt_pattern[] = {'B', 'b', 't', '0' };
+static uint8_t nand_davinci_mirror_pattern[] = {'1', 't', 'b', 'B' };
+
+static struct nand_bbt_descr nand_davinci_bbt_main_descr = {
+ .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE
+ | NAND_BBT_2BIT | NAND_BBT_VERSION | NAND_BBT_PERCHIP,
+ .offs = 2,
+ .len = 4,
+ .veroffs = 16,
+ .maxblocks = 4,
+ .pattern = nand_davinci_bbt_pattern
+};
+
+static struct nand_bbt_descr nand_davinci_bbt_mirror_descr = {
+ .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE
+ | NAND_BBT_2BIT | NAND_BBT_VERSION | NAND_BBT_PERCHIP,
+ .offs = 2,
+ .len = 4,
+ .veroffs = 16,
+ .maxblocks = 4,
+ .pattern = nand_davinci_mirror_pattern
+};
+
+static struct nand_ecclayout nand_davinci_layout_4bit = {
+ .eccbytes = 10,
+ .eccpos = {
+ 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
+ 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
+ 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
+ 54, 55, 56, 57, 58, 59, 60, 61, 62, 63},
+ .oobfree = {
+ {0, 6}, {16, 6}, {32, 6}, {48, 6},
+ {64, 6}, {80, 6}, {96, 6}, {112, 6} }
+};
+
+static void nand_davinci_hwctl_4bit(struct mtd_info *mtd, int mode)
+{
+ struct davinci_nand_info *info = to_davinci_nand(mtd);
+ u32 nandfcr;
+
+ switch (mode) {
+ case NAND_ECC_WRITE:
+
[PATCH] MTD-NAND: Changes to read_page APIs to support NAND_ECC_HW_SYNDROME mode on TI DaVinci DM355
From: Sneha Narnakaje nsnehapra...@ti.com
The NAND controller on TI DaVinci DM355 supports NAND devices with large page
size (2K and 4K), but the HW ECC is handled for every 512byte read/write
chunks. The current HW_SYNDROME read_page/write_page APIs in the NAND core
(nand_base) use the infix OOB scheme. The core APIs overwrite NAND
manufacturer's bad block meta data, thus complicating the jobs of non-Linux
NAND programmers (end equipment manufacturering). These APIs also imply ECC
protection for the prepad bytes, causing nand raw_write operations to fail.
So the TI DaVinci NAND driver overrides these APIs for DaVinci DM355. The
read_page APIs required page to be passed for reading the whole OOB area
first and then data in chunks of 512bytes. The ECC status is checked after
reading every 512byte chunk and passing the ECC syndrome.
Since there is a change to read_page/read_page_raw API definitions, other NAND
drivers overriding these APIs have also been changed (to address compilation
problems).
This patch also changes the way oobavail is calculated using the
oobfree[].length and the way oobfree[] is used. The oobfree[] is defined as an
array of MTD_MAX_OOBFREE_ENTRIES size (8). If we initialize all 8 entries, then
the current for loop which has a chance to go beyond the array limit thus
causing incorrect oobavail value. The NAND core and other NAND drivers do not
require upto 8 oobfree entries, but the TI DaVinci NAND driver requires upto 8
oobfree entries to support upto 4K page size. The check for
MTD_MAX_OOBFREE_ENTREIES is already there in the
drivers/mtd/onenand/onenand_base.c, which is based on
drivers/mtd/nand/nand_base.c. There is also a check for ecc.steps to make the
oobfree[] backward compatible with 2K page size. The max oob size and page size
have been adjusted for the 4K+128 page size. Supporting up to 4K page with
NAND_ECC_HW_SYNDROME does not require changes to include/mtd/mtd-abi.h (breaks
user space IOCTL interface).
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Signed-off-by: Sneha Narnakaje nsnehapra...@ti.com
---
drivers/mtd/nand/atmel_nand.c|2 +-
drivers/mtd/nand/cafe_nand.c |2 +-
drivers/mtd/nand/fsl_elbc_nand.c |3 +-
drivers/mtd/nand/nand_base.c | 45 ++
drivers/mtd/nand/sh_flctl.c |2 +-
include/linux/mtd/nand.h |8 +++---
6 files changed, 35 insertions(+), 27 deletions(-)
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 47a33ce..b63eddb 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -214,7 +214,7 @@ static int atmel_nand_calculate(struct mtd_info *mtd,
* buf:buffer to store read data
*/
static int atmel_nand_read_page(struct mtd_info *mtd,
- struct nand_chip *chip, uint8_t *buf)
+ struct nand_chip *chip, uint8_t *buf, int page)
{
int eccsize = chip-ecc.size;
int eccbytes = chip-ecc.bytes;
diff --git a/drivers/mtd/nand/cafe_nand.c b/drivers/mtd/nand/cafe_nand.c
index 22a6b2e..8ea1623 100644
--- a/drivers/mtd/nand/cafe_nand.c
+++ b/drivers/mtd/nand/cafe_nand.c
@@ -381,7 +381,7 @@ static int cafe_nand_read_oob(struct mtd_info *mtd, struct
nand_chip *chip,
* we need a special oob layout and handling.
*/
static int cafe_nand_read_page(struct mtd_info *mtd, struct nand_chip *chip,
- uint8_t *buf)
+ uint8_t *buf, int page)
{
struct cafe_priv *cafe = mtd-priv;
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 1f6eb25..ddd37d2 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -739,7 +739,8 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
static int fsl_elbc_read_page(struct mtd_info *mtd,
struct nand_chip *chip,
- uint8_t *buf)
+ uint8_t *buf,
+ int page)
{
fsl_elbc_read_buf(mtd, buf, mtd-writesize);
fsl_elbc_read_buf(mtd, chip-oob_poi, mtd-oobsize);
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 599185c..d7f6650 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -750,7 +750,7 @@ static int nand_wait(struct mtd_info *mtd, struct nand_chip
*chip)
* @buf: buffer to store read data
*/
static int nand_read_page_raw(struct mtd_info *mtd, struct nand_chip *chip,
- uint8_t *buf)
+ uint8_t *buf, int page)
{
chip-read_buf(mtd, buf, mtd-writesize);
chip-read_buf(mtd, chip-oob_poi, mtd-oobsize);
@@ -764,7 +764,7 @@ static int nand_read_page_raw(struct mtd_info *mtd, struct
nand_chip *chip,
* @buf: buffer to store read data
*/
static int nand_read_page_swecc(struct mtd_info *mtd, struct nand_chip *chip,
-
[PATCH] MTD-NAND: Changes to read_page APIs to support NAND_ECC_HW_SYNDROME mode on TI DaVinci DM355
From: Sneha Narnakaje nsnehapra...@ti.com
The NAND controller on TI DaVinci DM355 supports NAND devices with large page
size (2K and 4K), but the HW ECC is handled for every 512byte read/write
chunks. The current HW_SYNDROME read_page/write_page APIs in the NAND core
(nand_base) use the infix OOB scheme. The core APIs overwrite NAND
manufacturer's bad block meta data, thus complicating the jobs of non-Linux
NAND programmers (end equipment manufacturering). These APIs also imply ECC
protection for the prepad bytes, causing nand raw_write operations to fail.
So the TI DaVinci NAND driver overrides these APIs for DaVinci DM355. The
read_page APIs required page to be passed for reading the whole OOB area
first and then data in chunks of 512bytes. The ECC status is checked after
reading every 512byte chunk and passing the ECC syndrome.
Since there is a change to read_page/read_page_raw API definitions, other NAND
drivers overriding these APIs have also been changed (to address compilation
problems).
This patch also changes the way oobavail is calculated using the
oobfree[].length and the way oobfree[] is used. The oobfree[] is defined as an
array of MTD_MAX_OOBFREE_ENTRIES size (8). If we initialize all 8 entries, then
the current for loop which has a chance to go beyond the array limit thus
causing incorrect oobavail value. The NAND core and other NAND drivers do not
require upto 8 oobfree entries, but the TI DaVinci NAND driver requires upto 8
oobfree entries to support upto 4K page size. The check for
MTD_MAX_OOBFREE_ENTREIES is already there in the
drivers/mtd/onenand/onenand_base.c, which is based on
drivers/mtd/nand/nand_base.c. There is also a check for ecc.steps to make the
oobfree[] backward compatible with 2K page size. The max oob size and page size
have been adjusted for the 4K+128 page size. Supporting up to 4K page with
NAND_ECC_HW_SYNDROME does not require changes to include/mtd/mtd-abi.h (breaks
user space IOCTL interface).
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Signed-off-by: Sneha Narnakaje nsnehapra...@ti.com
---
drivers/mtd/nand/atmel_nand.c|2 +-
drivers/mtd/nand/cafe_nand.c |2 +-
drivers/mtd/nand/fsl_elbc_nand.c |3 +-
drivers/mtd/nand/nand_base.c | 45 ++
drivers/mtd/nand/sh_flctl.c |2 +-
include/linux/mtd/nand.h |8 +++---
6 files changed, 35 insertions(+), 27 deletions(-)
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 47a33ce..b63eddb 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -214,7 +214,7 @@ static int atmel_nand_calculate(struct mtd_info *mtd,
* buf:buffer to store read data
*/
static int atmel_nand_read_page(struct mtd_info *mtd,
- struct nand_chip *chip, uint8_t *buf)
+ struct nand_chip *chip, uint8_t *buf, int page)
{
int eccsize = chip-ecc.size;
int eccbytes = chip-ecc.bytes;
diff --git a/drivers/mtd/nand/cafe_nand.c b/drivers/mtd/nand/cafe_nand.c
index 22a6b2e..8ea1623 100644
--- a/drivers/mtd/nand/cafe_nand.c
+++ b/drivers/mtd/nand/cafe_nand.c
@@ -381,7 +381,7 @@ static int cafe_nand_read_oob(struct mtd_info *mtd, struct
nand_chip *chip,
* we need a special oob layout and handling.
*/
static int cafe_nand_read_page(struct mtd_info *mtd, struct nand_chip *chip,
- uint8_t *buf)
+ uint8_t *buf, int page)
{
struct cafe_priv *cafe = mtd-priv;
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 1f6eb25..ddd37d2 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -739,7 +739,8 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
static int fsl_elbc_read_page(struct mtd_info *mtd,
struct nand_chip *chip,
- uint8_t *buf)
+ uint8_t *buf,
+ int page)
{
fsl_elbc_read_buf(mtd, buf, mtd-writesize);
fsl_elbc_read_buf(mtd, chip-oob_poi, mtd-oobsize);
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 599185c..d7f6650 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -750,7 +750,7 @@ static int nand_wait(struct mtd_info *mtd, struct nand_chip
*chip)
* @buf: buffer to store read data
*/
static int nand_read_page_raw(struct mtd_info *mtd, struct nand_chip *chip,
- uint8_t *buf)
+ uint8_t *buf, int page)
{
chip-read_buf(mtd, buf, mtd-writesize);
chip-read_buf(mtd, chip-oob_poi, mtd-oobsize);
@@ -764,7 +764,7 @@ static int nand_read_page_raw(struct mtd_info *mtd, struct
nand_chip *chip,
* @buf: buffer to store read data
*/
static int nand_read_page_swecc(struct mtd_info *mtd, struct nand_chip *chip,
-
Re: [patch 2.6.29-davinci1 git] dm6446evm CF support
On Wednesday 01 April 2009, Sergei Shtylyov wrote: +config MACH_DAVINCI_EVM_CF + bool Use CompactFlash, not IDE drive + depends on MACH_DAVINCI_EVM BLK_DEV_PALMCHIP_BK3710 + help + Enable this if you want to use a CompactFlash card instead of + an IDE/ATA drive. The CF card will be used in True IDE mode. + + At this writing, CF insert and remove events are not supported. + Insert the CF at boot time, and leave it there until you power + the system off. + This instruction is already obsolete. As I've already noted, IDE core now supports warm plug via sysfs, see Documentation/ide/warm-plug-howto.txt. One can plug and unplug any time, this just won't be automatically noticed by the kernel, so one will need to notify it. CF insert and remove events are very different from writing some sysfs files. They are handled through a pcmcia_socket abstraction ... and are completely hands-off. Socket events include card insert/removal detection, and socket operations include power on/off and reset. I don't know that true-IDE links work through those sockets, though. That said ... I tried that manual workaround; it didn't work. So: no, that instruction is far from obsolete. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [patch 2.6.29-davinci1 git] dm6446evm CF support
Hello. David Brownell wrote: +config MACH_DAVINCI_EVM_CF + bool Use CompactFlash, not IDE drive + depends on MACH_DAVINCI_EVM BLK_DEV_PALMCHIP_BK3710 + help + Enable this if you want to use a CompactFlash card instead of + an IDE/ATA drive. The CF card will be used in True IDE mode. + + At this writing, CF insert and remove events are not supported. + Insert the CF at boot time, and leave it there until you power + the system off. + This instruction is already obsolete. As I've already noted, IDE core now supports warm plug via sysfs, see Documentation/ide/warm-plug-howto.txt. One can plug and unplug any time, this just won't be automatically noticed by the kernel, so one will need to notify it. CF insert and remove events are very different from writing some sysfs files. They are handled through a pcmcia_socket abstraction ... and are completely hands-off. Socket events include card insert/removal detection, and socket operations include power on/off and reset. I don't know that true-IDE links work through those sockets, though. That said ... I tried that manual workaround; it didn't work. So: no, that instruction is far from obsolete. So, it would only work with real hard disks... sigh. Sorry for disinformation then -- I hoped warm plug could've been helpful for CF. MBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
BT.656 mode on DM6446
Hello all, I'm trying to produce BT.656 (NTSC timing) data on the output pins YOUT[7..0], but I'm not having any luck. I get headers that look somewhat like SAV and EAV, but are not consistent. Example: Instead of FF 0 0 80, I often get FF 0 80. Anyway, I haven't ever gotten any correct data. The h/w guys have PCLK front end clock running at 27MHz and VPBECLK at 54MHz. It looks like VCLK is being produced at 54MHz. Here are my register settings. If it's not listed, it's not changed from the Power-Up default value. //PCR.CLK_OFF (bit 0) Normal (0) vs Clocks-disabled (1). Set to 0 to change other registers. //VPSS_CLKCTL.VENCLKEN - (bit 3) set to '1' to enable ENC_CLK //VPSS_CLKCTL. MUXSEL - (bits 1:0) need to be set to '2', VPBECLK mode //VMOD.VDMD (bits 15:12) := 1. //VMOD.ITLCL (bit 11):= 0 //VMOD.ITLC (bit 10):= 1 //VMOD.TVTYP (bits 7:6) := 0 for NTSC, 1 for PAL. Choosing NTSC //VMOD.VMD (bit 4) := 0. use NTSC/PAL timing. //VMOD.VENC (bit 0):= 0 0 for disable or configuration, 1 for enable // Set to 1 after final configuration to start encoder. //YCCTL.CHM (bit4) := 1 ? Maybe 0? //YCCTL.YCP (bits 3:2) := 0 //YCCTL.R656 (bit-0 ) := 1 //RGBCTL.DFLTS (bits 9:8) := 0 (disable RGB function) //VIDCTL.VCLKE (bit 13) := 1 //VIDCTL.VCLKZ (bit 12) := 0 Enable VCLK driver. Needs to be changed from default setting //VIDCTL.VDMD := 0. Page 35 of SPRUE37 calls this field name out, but the field doesn't exist in listing. //I think this is actually DOMD (bits 5:4) := 0. //HSTART and VSTART still have their default values of 0 I couldn't tell from SPRUE37 if H_VALID and V_VALID needed to be set, or if they were given values when you select BT-656 mode. At the moment, I have set them with non-zero values. If I need to set them, what should their values be? //VIDWIN0ADR is set to the start of the data, at hex-8000_, which I've initialized to something obvious, 1 2 3 4 5 etc. and final step: // Enable the Video Encoder //VMOD.VENC (bit 0) :=0 for disable, 1 for enable. An extra question: If I just want to send a single frame (not interlaced), how do I stop the Vid Encoder from sending a second frame? Thanks in advance for help, JTL___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 10/18] ARM: DaVinci - Move serial platform_device into SoC-specific files
On Wed, Apr 01, 2009 at 01:13:46AM -0400, Hugo Villeneuve wrote: On Tue, 31 Mar 2009 22:04:46 -0700 Kevin Hilman khil...@deeprootsystems.com wrote: Hugo Villeneuve h...@hugovil.com writes: On Tue, 31 Mar 2009 21:31:13 -0700 Kevin Hilman khil...@deeprootsystems.com wrote: David Brownell davi...@pacbell.net writes: On Tuesday 31 March 2009, Mark A. Greer wrote: On Tue, Mar 31, 2009 at 01:43:41PM -0700, David Brownell wrote: On Tuesday 31 March 2009, Mark A. Greer wrote: The serial infrastructure is pretty limited WRT this (I have same issue on da830 evm--I only want to use uart2). Couldn't you add some kind of ignore this one flag to that infrastructure, and just have DaVinci use it? Yes and that's probably the right long-term solution. Problem is that code is used by almost everyone so who knows how long it'll take to get accepted. Accepted: should be easy with a sane patch. No existing driver would be setting that new flag. Used widely: happens over time, like always. We ran into this same problem in OMAP too. The solution we ame up with is to just power-up all UARTs and an inactivity timer disables unused UART clocks. I tried a solution to this in the 8250 driver, but the bigger problem is that the 8250 driver is orphaned. Patches to add/fix features for the 8250 driver go largely ignored on the serial list. This all seems overly complicated to me. I don't like the idea of registering a non-used serial port. I have no problem with having ttyS0 and ttyS1 if I register UART0 and UART2. Symbolic links can be used to make things more obvious like /dev/mydevice - /dev/ttyS0. Yes, it is a bit complicated, but your solution leads to complications and confusion as well. My solution is there to fix a bug. Before my patch, if you registered only UART0 and UART2, it didn't work. I prefer a little bit of confusion and to have something bug free for now. The real problem seems to be the way that the 8250 driver assigns its device numbers. If you disagree with that methodology, then fix the 8250 driver. Don't use some ugly hacks to avoid the real problem. That's what David has already suggested but that is only a solution IFF there is someone on the other end to accept that patch. As Kevin points out, there isn't ATM. Having uart2 known as uartanything but 2 is unacceptable. Enabling a uart then disabling is better than having no idea which uart is which, IMHO. Mark ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 10/18] ARM: DaVinci - Move serial platform_device into SoC-specific files
On Wednesday 01 April 2009, Mark A. Greer wrote: The real problem seems to be the way that the 8250 driver assigns its device numbers. If you disagree with that methodology, then fix the 8250 driver. Don't use some ugly hacks to avoid the real problem. That's what David has already suggested but that is only a solution IFF there is someone on the other end to accept that patch. As Kevin points out, there isn't ATM. Which means that you should highlight the fix to Andrew Morton when you submit it. Having uart2 known as uartanything but 2 is unacceptable. Agreed. Enabling a uart then disabling is better than having no idea which uart is which, IMHO. I'd really like to stamp out the meme that needing to enable then disable something is anything except a bug. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Davinci DM644x DDR2 VTP calibration bug?
Dear Friends, I have 2 questions about VTP manual calibration of DM644x devices. 1. In davinci_ubl project, in the platform.asm I found the DDR2 VTP calibration code. Some part of it is the following: ... LDR R6, DDRVTPR LDR R7, [R6] AND R7, R7, #0x1F AND R8, R7, #0x3E0 ORR R8, R7, R8 LDR R7, VTP_RECAL ORR R8, R7, R8 LDR R7, VTP_EN ORR R8, R7, R8 STR R8, [R0] ... VTP_RECAL: .word 0x0004 VTP_EN: .word 0x2000 DDRVTPR:.word 0x01C42030 ;/* DDR VPTR MMR; */ ... It seems to this code is want to execute the requirements of sprue22c.pdf, Page 31: 2.12.2 Initializing Following Device Power Up and Device RESET ... 9. Read the DDR VTP register to get the P/N channel VTP value. See Section 4.13 for details on the DDR VTP register. 10. Write the VTP information to the PCH and NCH fields in the VTPIOCR. Make sure the RECAL and EN fields remain set to 1. ... The problem is: I think, the code may contains a bug, because after AND R7, R7, #0x1F, the DDRVTPR.PCH value is dropped. I have read the values of DDR2 Memory Controller Registers which is may confirmed the bug: DDR2.DDRVTPER[0x01C4004C]=0x DDR2.DDRVTPR [0x01C42030]=0x0384 DDR2.SDRSTAT [0x2004]=0x4004 DDR2.SDBCR [0x2008]=0x00170832 DDR2.SDRCR [0x200C]=0x041F DDR2.SDTIMR [0x2010]=0x229229C9 DDR2.SDTIMR2 [0x2014]=0x0012C722 DDR2.PBBPR [0x2020]=0x00FE DDR2.IRR [0x20C0]=0x DDR2.IMR [0x20C4]=0x DDR2.IMSR[0x20C8]=0x DDR2.IMCR[0x20CC]=0x DDR2.DDRPHYCR[0x20E4]=0x50006405 DDR2.VTPIOCR [0x20F0]=0x0004 The two important registers are the DDRVTPR (=0x0384) and the VTPIOCR (=0x0004). My opinion is, the following should be met: 1.1. DDRVTPR.PCH == VTPIOCR.PCH (28!=0) 1.2. DDRVTPR.NCH == VTPIOCR.NCH (4==4) 2. The value of VTP_RECAL in the code above is equals to 0x0004. Nevertheless, the Chapter 4.12 in sprue22c.pdf describes the VTP IO Control Register (VTPIOCR). In this section specified the RECAL bit in position b15. According to this technical specification the value of VTP_RECAL constant should be the 0x8000! Has anybody have any idea about the aboves? Thanks for any help! Peter ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
problem in u-boot
Hi all I use DM6446, when i download u-boot loader into the flash using DVFlasher and serial port(UART). but It is error; Error Log: . ACK command sent. Waiting for BEGIN command... DVEVM: BEGIN BEGIN commmand received. Sending CRC table... CRC table sent. Waiting for DONE... DONE received. Sending the UART UBL file... DONE received. UART UBL file was accepted. UART UBL Transmitted successfully. DVEVM:TI UBL Version: 1.12, Flash type: NOR DVEVM:Booting PSP Boot Loader DVEVM:PSPBootMode = UART Waiting for UBL on DVEVM... UBL's BOOTPSP commmand received. Returning CMD and command... CMD value sent. SENDAPP received. Returning ACK and header for application data... ACK command sent. Waiting for BEGIN command... UBL's BEGIN commmand received. Sending the application code... Application code sent. Waiting for DONE... DONE received. All bytes of application code received... DONE received. Application S-record decoded correctly. DVEVM:NOR Initialization: DVEVM:Command Set: AMD DVEVM:Manufacturer: AMD DVEVM:Size (in bytes): 0x0100 DVEVM:Erasing the NOR Flash DVEVM:Erased through 0x0202 DVEVM:Erase Completed DVEVM:Writing the NOR Flash DVEVM:Abort ocurred. Best Regards, 肖亮星 2009-04-01 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Bottom-Boot Uboot for a Board based on DM6446 EVM.
Hi All, We are developing a board based on the DM6446 EVM. The uboot on the EVM is a Top-Boot uboot. However the NOR flash memory on the new board needs a Bottom-Boot uboot. Please let me know if any one has a Bottom-boot uboot binary/sources. Regards, Zaheer. http://www.mindtree.com/email/disclaimer.html ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
