RE: [PATCH RFC v8] MUSB: DA8xx/OMAP-L1x glue layer

Hi, > -Original Message- > From: davinci-linux-open-source- > bounces+ajay.gupta=ti@linux.davincidsp.com [mailto:davinci-linux-open- > source-bounces+ajay.gupta=ti@linux.davincidsp.com] On Behalf Of Sergei > Shtylyov > Sent: Wednesday, May 12, 2010 11:42 PM > To: linux-...@vger.kern

RE: davinci linux kernel updata

liuyue18301 wrote: >if i want to updata the davinci linux kernel to the > higher.what should i do,i think the gcc version has to update.now,i > have download the kernle version:2.6.32 and gcc 4.3.3,what i do is > just update the gcc and linux kernel in the SEED-SDK.the flow is ok? I don't

Re: davinci linux kernel updata

git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git liuyue18301 wrote: hello everybody: if i want to updata the davinci linux kernel to the higher.what should i do,i think the gcc version has to update.now,i have download the kernle version:2.6.32 and gcc 4.3.3,what i do is

davinci linux kernel updata

hello everybody: if i want to updata the davinci linux kernel to the higher.what should i do,i think the gcc version has to update.now,i have download the kernle version:2.6.32 and gcc 4.3.3,what i do is just update the gcc and linux kernel in the SEED-SDK.the flow is ok?

Re: [PATCH v6 0/6] Davinci: initial tnetv107x patch series

Hi Kevin, [...] > Is there anything in the DaVinci-specific parts now that is preventing > a single kernel shared between DMx an tnetv? No, at least not by design :-) > I know about the ARM-generic code that has problems when both ARMv5 > and ARMv6 are enabled, but am curious about any remaining

Re: [PATCH v6 4/6] Davinci: tnetv107x initial gpio support

Hi Kevin, [...] > I know Sergei isn't used to me agreeing with him ;) but I tend to > agree with him on the increased bulk of gpio_set_value(). > > It's not simply the increased size that is an issue here. The point > of these inlines (as the comment suggests) is for low-overhead > bit-banging.

Re: [PATCH v6 3/6] Davinci: tnetv107x soc support

Hi Kevin, [...] >> +#define PINMUX(x) (4 * (x)) > > minor nit... > > Isn't this a duplicate of what is now in ? Yes, I will remove this unfortunate left over. Regards Cyril. ___ Davinci-linux-open-source mailing list Davinci-linux-open-sou

Re: [PATCH v6 1/6] Davinci: generalized debug macros

Hi Kevin, [...] >> Tony's updated version[1] for OMAP is not using 0x3ffc offset since only >> 4 bytes are used. I see that Tony's patch passes just one word through this area. The davinci code on the other hand passes both phys and virt, hence the extra word of allocation. >> Any objection to

question about using DMA for davinci SPI controller

Hi all, I am trying to fix a bug about full duplex DMA transfer for SPI controller hang on ti-omapl138 ref borad. I read the DMA setting code of davinci SPI controller. It's in drivers/spi/davinci_spi.c:davinci_spi_bufs_dma(). There is a code snippet which I don't understand. List below:

[PATCH 4/20] arch/arm/mach-davinci: Use kzalloc

From: Julia Lawall Use kzalloc rather than the combination of kmalloc and memset. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // @@ expression x,size,flags; statement S; @@ -x = kmalloc(size,flags); +x = kzalloc(size,flags); if (x == NULL) S -memset(

Re: [PATCH] DA830: fix USB 2.0 clock entry

Hello. I wrote: DA8xx OHCI driver fails to load due to failing clk_get() call for the USB 2.0 clock. Arrange matching USB 2.0 clock by the clock name instead of the device. (Adding another CLK() entry for "ohci.0" device won't do -- in the future I'll also have to enable USB 2.0 clock to configu

[PATCH] DA830: fix USB 2.0 clock entry

DA8xx OHCI driver fails to load due to failing clk_get() call for the USB 2.0 clock. Arrange matching USB 2.0 clock by the clock name instead of the device. (Adding another CLK() entry for "ohci.0" device won't do -- in the future I'll also have to enable USB 2.0 clock to configure CPPI 4.1 module,

Re: [PATCH RFC v8] MUSB: DA8xx/OMAP-L1x glue layer

Sergei Shtylyov wrote: Texas Instruments DA8xx/OMAP-L1x glue layer for the MUSBMHRDC driver. Signed-off-by: Sergei Shtylyov Signed-off-by: Yadviga Grigorieva --- The patch is against the recent Linus' tree. Felipe, I forgot to both CC you and drop RFC from the subject. Please queue/ack t

Re: [PATCH 0/3] More PINMUX definitions

thomas.koel...@baslerweb.com writes: > From: Thomas Koeller > > Patch series is against Kevin's tree this time. They > introduce new PINMUX settings that are required to support > the board I am working on. > > Thomas Koeller (3): > DM365: Added PINMUX definitions for GPIO30..32 > DM365: Make

Re: [PATCH v6 0/6] Davinci: initial tnetv107x patch series

Cyril Chemparathy writes: > This patch series adds support for TNETV107X - a Texas Instruments SOC that > shares a number of common features with the Davinci architecture. > > This version includes minor fixes over the v5 series posted earlier Hi Cyril, I had some minor comments on a couple of

Re: [PATCH v6 4/6] Davinci: tnetv107x initial gpio support

Cyril Chemparathy writes: > This patch adds support for the tnetv107x gpio controller. > > Key differences between davinci and tnetv107x controllers: > - register map - davinci's controller is organized into banks of 32 gpios, >tnetv107x has a single space with arrays of registers for in, ou

Re: [PATCH v6 3/6] Davinci: tnetv107x soc support

Cyril Chemparathy writes: > TNETV107X is a Texas Instruments SOC that shares a number of common features > with the Davinci architecture. Some of the key differences between > traditional Davincis and this new SOC are as follow: > > 1. The SOCs clock architecture includes a new spread-spectrum P

Re: [PATCH v6 1/6] Davinci: generalized debug macros

Kevin Hilman writes: > Cyril Chemparathy writes: > >> This patch adopts a debug uart selection similar to the OMAP model. During >> the boot process, the uncompress code determines the physical and virtual >> base >> addresses of the board-specific debug uart. These addresses are then passed

Re: [PATCH v2 1/2] davinci: edma: use BIT() wherever possible

Sekhar Nori writes: > This patch replaces occurences of (1 << x) with > BIT(x) as it makes for much better reading. > > Signed-off-by: Sekhar Nori Looks good, applying both patches and queuing for 2.6.35 in davinci-next. Kevin ___ Davinci-linux-open-

Re: live555

Date: Thu, 13 May 2010 20:13:51 +0800 From: "huangsw" I have succeeded to cross compile live555 (version is 2010-04-09),and i run it on my dm6446 ,and i stored a mp3 file on the same dir, on my pc ,i filed to open the mp3 using Realplayer and VLC p;ayer, can you give me some advice? I

Re: [PATCH v6 1/6] Davinci: generalized debug macros

Cyril Chemparathy writes: > This patch adopts a debug uart selection similar to the OMAP model. During > the boot process, the uncompress code determines the physical and virtual base > addresses of the board-specific debug uart. These addresses are then passed > on to the in-kernel debug macro

Re: [PATCH v3 0/8] pre-tnetv107x ioremap series

Cyril Chemparathy writes: > With this patch, various davinci modules (gpio, timer, psc, etc.) now use > ioremap() instead of having virtual addresses passed in via davinci_soc_info. > Based on this cleanup, davinci_ioremap() has been modified to search through > the iotable instead of mapping bas

Re: [PATCH 06/34] RTC: DaVinci RTC driver

Russell King - ARM Linux writes: > This should also go to the RTC people. Forgot the Cc here, but this has already been discussed ack'd by RTC folks and agreed that it should merge via my tree. Kevin > On Thu, May 06, 2010 at 04:23:57PM -0700, Kevin Hilman wrote: >> From: Miguel Aguilar >> >

Why failed to open mp3 which stored my live555MediaServer?

I have succeeded to cross compile live555 (version is 2010-04-09),and i run it on my dm6446 ,and i stored a mp3 file on the same dir, on my pc ,i filed to open the mp3 using Realplayer and VLC p;ayer, can you give me some advice? 2010-05-13 huangsw __

Re: [PATCH 07/34] rtc: omap: let device wakeup capability be configured from chip init logic

-> rtc people On Thu, May 06, 2010 at 04:23:58PM -0700, Kevin Hilman wrote: > From: Sekhar Nori > > The rtc-omap driver currently hardcodes the RTC wakeup capability > to be "not capable". While this seems to be true for existing OMAP1 > boards which are not wired for this, the DA850/OMAP-L138 S

Re: [PATCH 06/34] RTC: DaVinci RTC driver

This should also go to the RTC people. On Thu, May 06, 2010 at 04:23:57PM -0700, Kevin Hilman wrote: > From: Miguel Aguilar > > This driver features: > > * Alarm support. > * Periodic interrupt by using a timer include into the RTC module. > * The update interrupt is not supported by this RTC m

RE: The DM355 AEW is very sensitive to YELLOW color?

Please ignore my last email... Just realized that you have already posted it on E2E forum :( Sorry for unnecessary emails. Regards, Anshuman From: Saxena, Anshuman Sent: Thursday, May 13, 2010 1:44 PM To: 'Han Jun-peng'; Davinci-linux-open-source@linux.davincidsp

RE: The DM355 AEW is very sensitive to YELLOW color?

Hi, Can you please post this query on TI E2E forum (http://e2e.ti.com) in Davinci Video Processors section? I have anyways forwarded your question to our team and we will reply on the forum itself, so that other users can also benefit from this reply at a later point of time

The DM355 AEW is very sensitive to YELLOW color?

Hi,all I use the APPRO IPNC as my development platform. The IPNC provides two 2A function:the appro 2A and the TI 2A. I find if I use the TI 2A, the video is very sensitive to YELLOW color,that means if I place a piece of yellow paper before the sensor, the whole video view will become very blue, a

davinci gpio driver

hello everybody: recently i want to take GPIO1 as interrupt source in my driver,the work flow as follow: 1 set GPIO1 as input mode 2 set the trigger mode 3 request_irq(gpio_to_irq(GPIO1),void *)hander,SA_INTERRUPT,xx,xx); 4 do the work in the interrupt process. i