RE: Problem with YAFFS2 on LargePage NAND

Zhang, You could try defining YAFFS_IGNORE_TAGS_ECC in fs/yaffs2/yaffs_ecc.h and give it a shot. If this works it would mean, h/w ECC uses up the OOB spare area leaving no space for YAFFS2 to mark bad blocks hence showing 100% usage. Regards, Philby On Wed, 2009-03-18 at 12:55 -0500, Na

Re: net_rx_action Kernel Panic

I get the identical problem with DVEVM with DM6446. I have tried kernel version 2.6.27-davinci1 and 2.6.26-rc3. It always happens in net_rx_action. I have tried with davinci_evm_dm644x_defconfig as well as my own .config file. I use gcc v 4.2.4 It occurs more often under heavy network load,

Davinci, MUSB, DVEVM - driver but no devices? (solved, thanks)

Hi All, i was earlier reporting USB problems with a DVEVM "alike" board. Later, it became clear, that the board was really unalike in a component critical to the kernel. Meanwhile i got an original DVEVM, and, to set the record straight, can report, that USB 2.0 works well here, both in PIO and

Re: [RFC 4/7] ARM: DaVinci: DM646x Video: Defintions for standards supported by display

Hi Chaithrika, Just a quick note: getting these digital TV standards sorted out is the main blocking issue for the DM646x. Without this nothing can get merged. In addition, extending the V4L2 API will take time and usually takes several review cycles. So I recommend that this gets a high priori

Re: [PATCH 1/7] VPFE capture driver for DM355 and DM6446

On Wednesday 18 March 2009 22:47:51 Laurent Pinchart wrote: > Hi Murali, > > here's my (humble) review of your VPFE capture driver. Before I start, > I'd like to thank you for your work on this v4l driver and contribution > to the Linux kernel. Excellent review, Laurent! Chaithrika, please note t

Re: [PATCH] DaVinci: add support for CPPI 4.1

Hello, I 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 anyway. --- As

[PATCH] DaVinci: add support for CPPI 4.1

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 anyway. --- As DA830/OMAP-L137 code is

RE: [PATCH 2/2] ARM: DaVinci: EDMA: Enable EDMA support for dm646x

Thanks for the clarification. I've coded it (minimally, just to print the context of the error), and have found that in some configurations (certain Codecs running on the DSP), I'm getting TC errors, with an indication of a Bus Error... I'd found that in the original 2.6.10 delivered version of d

RE: Problem with YAFFS2 on LargePage NAND

Zhang, Which software codebase/release are you using here on DM6446 EVM? The default NAND configuration for DM6446 EVM is to use a small block NAND flash (with page size = 512bytes) and 1-bit HW ECC. If the driver configuration does not match with what the NAND device expects, all blocks of the

Re: [PATCH 2/2] ARM: DaVinci: EDMA: Enable EDMA support for dm646x

On Wednesday 18 March 2009, Roberts, Randy wrote: > Why is the TC error handling considered a NOP? Nobody ever coded it. > Why should handling of TC "errors" be removed? If there were actual code doing anything there, that would make sense. ___ Davin

Can not get the vpfe isr on the dm6446 with tvp5150

Hi Prabhaharan Stephen, Can you tell me the register setting about the tvp5150 with sync656enable mode. Now, i have registered the VDINT0 interrupt in the vpfe init function. But, the vpfe_isr is always not getting called. It is registering properly and not getting failed.

dm6446 tvp5150 can not get the vpfe isr

Hi Prabhaharan, Can you tell me the register setting about the tvp5150 with sync656enable mode. Now, i have registered the VDINT0 interrupt in the vpfe init function. But, the vpfe_isr is always not getting called. It is registering properly and not getting failed. I th

[PATCH 1/1] ARM: Davinci: UART: Fix bug with serial ports registration

This bug occurs when the davinci serial code tries to register UART(X) when UART(X-1) or UART(X-2) is not enabled in the structure uart_config of the board setup code: This works: .enabled_uarts = (1 << 0) This works: .enabled_uarts = (1 << 0) | (1 << 1) This works: .enabled_uarts = (1 << 0) | (1

RE: [PATCH 2/2] ARM: DaVinci: EDMA: Enable EDMA support for dm646x

Why is the TC error handling considered a NOP? Why should handling of TC "errors" be removed? Do they not indicate a REAL error? Granted, it may only be information, and not actionable... So, is the recommendation to just NOT enable the notification of this type of exception? Thanks, Ran

Davinci DM355 - USB bulk end point issue

Hello All, I am trying to develop a customized USB gadget driver. I am emulating streaming using bulk endpoint. . I am using gadget/zero.c as a base. Source is pumping data in higher rate than the rate of consumption. How to increase the rate (frame rate) of consumption in usb gadget? Is it

Davinci DM355 - USB driver

Hello All, I am trying to develop a customized USB gadget driver. I am using gadget/zero.c as a base. I want to have one of the endpoint as isochronous endpoint. I modified one of the endpoint descriptor as, static struct usb_endpoint_descriptor fs_source_desc = { .bLengt

RE: [alsa-devel] [PATCH 0/9] ARM: DaVinci: ASoC: Adds Audio support for TI DM646X

Mark, Thanks for the review. I will re-submit the series by taking care of your comments. > -Original Message- > From: naresh [mailto:x0090...@ti.com] > Sent: Wednesday, March 18, 2009 5:50 PM > To: 'nar...@ti.com' > Subject: > > On Mon, Mar 16, 2009 at 08:00:54AM -0400, Naresh Me

[PATCH 1/1] DaVinci: MMC: Updated MMC/SD controller driver for DaVinci family.

From: Purshotam Kumar This patch adds support for MMC/SD controller driver for DaVinci family SoC. This patch will work for SoC like DM6446 and DM355. SoC like DM365 and DA830 also has same controller with small variations and could supported/added easily by using this version of patch. It means

RE: [alsa-devel] [PATCH 9/9] ARM: DaVinci: ASoC: Adds build support for DM646X audio driver

> On Mon, Mar 16, 2009 at 08:06:27AM -0400, Naresh Medisetty wrote: > > > +config SND_SOC_CODEC_STUBS > > +tristate > > + > > You need to add this to SND_SOC_ALL_CODECS. I will add this to SND_SOC_ALL_CODECS ___ Davinci-linux-open-source mail

RE: [alsa-devel] [PATCH 7/9] ARM: DaVinci: ASoC: Adds ALSA SoC DIT/DIR driver support for DM646X

>> On Mon, Mar 16, 2009 at 08:05:48AM -0400, Naresh Medisetty wrote: > > > --- /dev/null > > +++ b/sound/soc/codecs/codec_stubs.c > > @@ -0,0 +1,63 @@ > > +/* > > + * ALSA SoC DaVinci DIT/DIR driver > > + * > > + * TI DaVinci audio controller can operate in DIT/DIR (SPDI/F) > where > > + * no c

RE: [alsa-devel] [PATCH 6/9] ARM: DaVinci: ASoC: Adds McASP clock support for TI DM646X processor

> On Mon, Mar 16, 2009 at 08:05:25AM -0400, Naresh Medisetty wrote: > > > + CLK("soc-audio.0", NULL, &mcasp0_clk), > > + CLK("soc-audio.1", NULL, &mcasp1_clk), > > Assuming this is a shorthand for defining two platform devices for two > ASoC cards I'd suggest that you instead move towards r

Re: New ramdisk.gz

Yes, but the kernel compilation didn´t affect the ramdisk.gz neither generate a new one. So it´s necessary do it in the kernel and create a new file. I can use a 32MB ramdisk, just changing the parameter bs to 32M. Worked pretty fine now. The first sequence it´s wrong. The second way runs without

RE: [alsa-devel] [PATCH 3/9] ARM: DaVinci: ASoC: Adds header file for McASP Audio Layer for TI DM646X processor

> -Original Message- > From: naresh [mailto:x0090...@ti.com] > Sent: Wednesday, March 18, 2009 5:05 PM > To: 'naresh' > Subject: > > On Mon, Mar 16, 2009 at 08:03:22AM -0400, Naresh Medisetty wrote: > > > +/* > > + * DAVINCI_MCASP_PWREMUMGT_REG - Power Down and Emulation Management > > + *

RE: [alsa-devel] [PATCH 1/9] ARM: DaVinci: ASoC: Adds ASoC driver support for TI DM646X EVM platform

I will re-work on this and re-submit the patch. Regards Naresh From: Mark Brown [broo...@sirena.org.uk] Sent: Monday, March 16, 2009 8:27 PM To: Medisetty, Naresh Cc: davinci-linux-open-source@linux.davincidsp.com; alsa-de...@alsa-project.org Subject: Re: [

RE: [PATCH 2/2] ARM: DaVinci: EDMA: Enable EDMA support for dm646x

> -Original Message- > From: naresh [mailto:x0090...@ti.com] > Sent: Wednesday, March 18, 2009 4:59 PM > To: 'nar...@ti.com' > Subject: > > On Sunday 15 March 2009, nar...@ti.com wrote: > > @@ -167,6 +175,8 @@ enum fifo_width { > > enum dma_event_q { > > EVEN

RE: [PATCH 1/2] ARM: DaVinci: EDMA: Move queue to tc mapping to dm.c

Dave, Thanks for the review. I will re-work on this and submit a patch Regards Naresh From: davinci-linux-open-source-boun...@linux.davincidsp.com [davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of David Brownell [davi...@pacbell.net] S

RE: [PATCH 2/2] ARM: DaVinci: EDMA: Enable EDMA support for dm646x

Dave, Thanks for the review. > On Sunday 15 March 2009, nar...@ti.com wrote: > > @@ -427,6 +441,20 @@ static irqreturn_t dma_tc1err_handler(int irq, > void *data) > > return IRQ_HANDLED; > > } > > > > +/* dm646x specific */ > > +static irqreturn_t dma_tc2err_ha

RE: Changing the memory map

Disregard... must have been user error or sleep deprivation... modifying the .tcf file does indeed change the .cmd file, as advertised. Sorry folks. Ryan From: Ryan Talbot Sent: Tuesday, March 17, 2009 4:51 PM To: davinci-linux-open-so