From Gopal_Sukumar at mindtree.com  Thu Apr  1 00:37:08 2010
From: Gopal_Sukumar at mindtree.com (Gopal Sukumar)
Date: Thu, 1 Apr 2010 12:07:08 +0530
Subject: JVM on DaVinci
In-Reply-To: <30776573.210741270042725028.JavaMail.root@email>
References: <30776573.210741270042725028.JavaMail.root@email>
Message-ID: <4BB43F14.6050302@mindtree.com>

Thank you Mark.
Even I was wondering if this was apt.

Regards,
Gopal Sukumar.

Mark Deneen wrote:
> SpiderMonkey is JavaScript, similar in name only to Java.
>
> Best Regards,
> Mark Deneen
> Saucon Technologies
>
> Best Regards,
> Mark Deneen
> Saucon Technologies
>
> ----- "Arie Muijnck" <amuijnck at optelecom-nkf.com> wrote:
>
>   
>> SpiderMonkey works fine.
>>
>> Kind regards,
>> Arie de Muijnck
>>
>>
>>
>> From: davinci-linux-open-source-bounces at linux.davincidsp.com
>> [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On
>> Behalf Of Gopal Sukumar
>> Sent: Wednesday, March 31, 2010 09:17
>> To: DaVinciMailingList
>> Subject: JVM on DaVinci
>>
>>
>>
>> Dear all,
>>
>> Can we run JVM on DaVinci platforms? I would like to develop code in
>> Java to run on DaVinci. Is this possible?
>>
>> Thanks in advance.
>>
>> Regards
>> Gopal Sukumar.
>>
>>
>>
>> http://www.mindtree.com/email/disclaimer.html
>>
>> This message contains confidential information and is intended only
>> for the individual named. If you are not the named addressee you
>> should not disseminate, distribute or copy this e-mail. Please notify
>> the sender immediately by e-mail if you have received this e-mail by
>> mistake and delete this e-mail from your system. E-mail transmission
>> cannot be guaranteed to be secure or error-free as information could
>> be intercepted, corrupted, lost, destroyed, arrive late or incomplete,
>> or contain viruses. The sender therefore does not accept liability for
>> any errors or omissions in the contents of this message, which arise
>> as a result of e-mail transmission. If verification is required please
>> request a hard-copy version.
>>
>> Please consider the environment before printing this email message
>>     
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100401/327f6390/attachment.html>

From Jon.Povey at racelogic.co.uk  Thu Apr  1 00:47:40 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Thu, 1 Apr 2010 07:47:40 +0100
Subject: [PATCH v2] DA8XX/OMAP-L1XX: FB: Implement double buffering
In-Reply-To: <20100331203256.852450d3.akpm@linux-foundation.org>
Message-ID: <70E876B0EA86DD4BAF101844BC814DFE0FDD0EFE@Cloud.RL.local>

Andrew Morton wrote:
> On Wed, 31 Mar 2010 20:43:29 -0500 "Ambrose, Martin" <martin at ti.com>
> wrote:

>>> If the calling process has signal_pending() (say, someone hit ^C)
>>> then wait_event_interruptible_timeout() will fall straight through
>>> with -ERESTARTSYS.  Will this cause the driver to malfunction at
>>> all?
>>
>> I don't think so since the driver doesn't make use of this
>> information in any way. This is just status to the caller that the
>> current frame has finished DMA'ing out of the framebuffer.
>>
>> Could you maybe propose a scenario/use case where you think it is
>> problematic? I could then either reason why it should be OK or
>> I'll create a test harness and see how the driver can/should be
>> modified.
>
> Gee, I dunno - I don't understand the driver to that level.  If you're
> OK with this wait being interrupted by a signal and the driver handles
> it OK then fine, that's a feature.
>
> To test it I suppose you should give your test app a signal handler
> and blast kills at it from another process.

Jumping in..

This should not cause a problem for the driver; its purpose is to tell userland that it can write to the buffer without corrupting graphics (as presumably it is double-buffering and the other buffer is now being DMA'd from by the hardware).

At worst, if the userland software doesn't handle this correctly it may draw one bad frame of graphics. Although if it's had a ctrl-C it probably has bigger things to worry about.

If the app wants to handle signals it needs to consider such things.. I would not expect the driver to do anything other than what this patch does.

--
Jon Povey
jon.povey at racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network



From Priya_Raghavendra at mindtree.com  Thu Apr  1 02:49:04 2010
From: Priya_Raghavendra at mindtree.com (Priya Raghavendra)
Date: Thu, 1 Apr 2010 14:19:04 +0530
Subject: Unable the detect SD card after kernel boot up on DM6467 
Message-ID: <1B3CA99331DE5E47BB89385002F8D1EF110A45ADC5@MTW02MSG02.mindtree.com>

Hi,

I am working on a custom board which has TI Davinci DM6467 Processor running Linux 2.6.10 as the host processor to which we have a USB2640 hub controller connected on the USB bus. This hub controller has a built in SD card controller. So basically this hub supports two USB devices and one SD card.
The problem I am facing right now is that if the SD card is connected during kernel boot up, the SD card gets detected and also enumerated. After this I am able to mount the SD card.
But in case I plug in the SD card after kernel boot up, the SD card does not get detected when I insert it.
The USB devices like USB pen drive or mouse connected to the USB ports are detected when they are hot plugged.

So how do I enable hot plugging for the SD card? Basically how do I enumerate the SD card once the kernel is up and the SD card is hot plugged?

Thanks,
bkrpri

________________________________
http://www.mindtree.com/email/disclaimer.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100401/48c29888/attachment-0001.html>

From gasparini at imavis.com  Thu Apr  1 02:54:58 2010
From: gasparini at imavis.com (Andrea Gasparini)
Date: Thu, 1 Apr 2010 10:54:58 +0200
Subject: JVM on DaVinci
In-Reply-To: <q2uc35f83941003311039va95b2064o6afc8dfe7d75978b@mail.gmail.com>
References: <4BB2F6DD.70406@mindtree.com>
	<q2uc35f83941003311039va95b2064o6afc8dfe7d75978b@mail.gmail.com>
Message-ID: <201004011054.59116.gasparini@imavis.com>

Ben Gardiner spiffera, alle Wednesday 31 March 2010 circa:
> On Wed, Mar 31, 2010 at 3:16 AM, Gopal Sukumar
> 
> <Gopal_Sukumar at mindtree.com> wrote:
> > Dear all,
> > 
> > Can we run JVM on DaVinci platforms? I would like to develop code in
> > Java to run on DaVinci. Is this possible?
> 
> You definitely can. GCJ comes to mind. Oracle/Sun's Java SE for
> embedded is an option
> http://java.sun.com/javase/downloads/embedded.jsp.  I think that
> openjdk is also a possibility but I haven't used it personally.

just for curiosity: does a JVM that supports Jazelle extensions exist?
given that Davinci processors has them, why can't we use it? :P

bye!
-- 
Andrea Gasparini 
---- ImaVis S.r.l. ----
web: www.imavis.com

From tarkandogu at gmail.com  Thu Apr  1 03:00:09 2010
From: tarkandogu at gmail.com (Tarkan DOGU)
Date: Thu, 1 Apr 2010 12:00:09 +0300
Subject: 6446 Master Volume Control
Message-ID: <w2ybb0fe03d1004010200o297e0fd5l800fdf33fc7d77fe@mail.gmail.com>

 I am trying to control master volume on 6446. But during the  IOCTL
   phase I am getting error -1. My Linux version is OE(Open Embedded -
   Angstrom)
   Do u have any idea?
   Thanks inadvance...
   B.R
   Tarkan
           int DeviceSound,vol=0;
           if ((DeviceSound = open("/dev/pcmC0D0c", O_RDWR)) == -1)
           {
                   printf("Failed to open /dev/pcmC0D0c\n");
                   return -1;
           }
           if (ioctl(DeviceSound, SOUND_MIXER_WRITE_VOLUME, &vol) == -1)
           {
                   printf("Failed to set DeviceSound for vol.\n");
                   close(DeviceSound);
                   return -1;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100401/f5839fc9/attachment.html>

From Gopal_Sukumar at mindtree.com  Thu Apr  1 03:28:54 2010
From: Gopal_Sukumar at mindtree.com (Gopal Sukumar)
Date: Thu, 1 Apr 2010 14:58:54 +0530
Subject: JVM on DaVinci
In-Reply-To: <201004011054.59116.gasparini@imavis.com>
References: <4BB2F6DD.70406@mindtree.com>
	<q2uc35f83941003311039va95b2064o6afc8dfe7d75978b@mail.gmail.com>
	<201004011054.59116.gasparini@imavis.com>
Message-ID: <4BB46756.5020607@mindtree.com>

This was the first thing I asked when my Technology Head inquired about 'JVM on DaVinci. :)

Andrea Gasparini wrote:

Ben Gardiner spiffera, alle Wednesday 31 March 2010 circa:


On Wed, Mar 31, 2010 at 3:16 AM, Gopal Sukumar

<Gopal_Sukumar at mindtree.com><mailto:Gopal_Sukumar at mindtree.com> wrote:


Dear all,

Can we run JVM on DaVinci platforms? I would like to develop code in
Java to run on DaVinci. Is this possible?


You definitely can. GCJ comes to mind. Oracle/Sun's Java SE for
embedded is an option
http://java.sun.com/javase/downloads/embedded.jsp.  I think that
openjdk is also a possibility but I haven't used it personally.



just for curiosity: does a JVM that supports Jazelle extensions exist?
given that Davinci processors has them, why can't we use it? :P

bye!


________________________________
http://www.mindtree.com/email/disclaimer.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100401/dd1e5b8b/attachment.html>

From pratik.joshi at einfochips.com  Thu Apr  1 04:43:28 2010
From: pratik.joshi at einfochips.com (Pratik Joshi)
Date: Thu, 1 Apr 2010 16:13:28 +0530
Subject: Query -USB hub with multiple block devices connected
Message-ID: <006201cad188$2c8a9ec0$859fdc40$@joshi@einfochips.com>

Hi All,

 

I am getting following error while I run Wireless USB device and a mass
storage device together. This error is displayed on console continuously and
I have to reboot the DVEVM.

++++++++++++++++++++++++++++++++++

SCSI error : <0 0 0 0> return code = 0x70000

 

end_request: I/O error, dev sda, sector 4404236

-------------------------------------------------------------

Regards,

Pratik Joshi

Embedded Engineer

eInfochips Ltd, Ahmedabad, India

+91-079-26563705 - ext - 303

www.einfochips.com

 

From: Pratik Joshi [mailto:pratik.joshi at einfochips.com] 
Sent: Tuesday, March 30, 2010 6:26 PM
To: 'davinci-linux-open-source at linux.davincidsp.com'
Subject: Query -USB hub with multiple block devices connected

 

Hi All,

 

We are seeing following problem:

 

Setup:

We have connected a USB hub to DVEVM. We have connected two bulk devices
mass storage and USB wireless device. We are continuously receiving data on
USB wireless device (using iperf utility) and at the same time continuously
writing to mass storage device. We do fsync () after writing data using
write command to ensure data is actually written to mass storage device.

 

Problem statement:

In above setup we see SCSI errors and I/O errors. Also we have observed "usb
1-1.1: usb_sg_cancel, unlink --> 0" message sometimes. What is the
significance of this message? Has anyone tested USB driver in such a driver?


 

Regards,

Pratik Joshi

Embedded Engineer

eInfochips Ltd, Ahmedabad, India

+91-079-26563705 - ext - 303

www.einfochips.com


-- 
_____________________________________________________________________
Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution, copying, or other use of
this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
replying to this message and please delete it from your computer. Any
views expressed in this message are those of the individual sender
unless otherwise stated.Company has taken enough precautions to prevent
the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email.
_____________________________________________________________________
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100401/93918d27/attachment.html>

From scerveau at awox.com  Thu Apr  1 06:30:28 2010
From: scerveau at awox.com (Stephane Cerveau)
Date: Thu, 1 Apr 2010 14:30:28 +0200
Subject: Query -USB hub with multiple block devices connected
References: <006201cad188$2c8a9ec0$859fdc40$@joshi@einfochips.com>
Message-ID: <46423D9081D5254CAFCEFF0CBC2CC9BA021BFFB8@jakarta.awox.com>

Hi all,

 

I experienced the same bug and I succeed to workaround the bug by adding
a delay into musb_ep_program but this is working only with the RT73 USB
Wireless device.

 

I experienced bug with other Wireless device.

Joshi, you can I think the verbose level in the musb driver. May be it
can help you to diagnose the bug with more accuracy... 

Any comment or help will be welcome. 

 

Stephane

From: Pratik Joshi [mailto:pratik.joshi at einfochips.com] 
Sent: jeudi 1 avril 2010 12:43
To: davinci-linux-open-source at linux.davincidsp.com
Subject: RE: Query -USB hub with multiple block devices connected

 

Hi All,

 

I am getting following error while I run Wireless USB device and a mass
storage device together. This error is displayed on console continuously
and I have to reboot the DVEVM.

++++++++++++++++++++++++++++++++++

SCSI error : <0 0 0 0> return code = 0x70000

 

end_request: I/O error, dev sda, sector 4404236

-------------------------------------------------------------

Regards,

Pratik Joshi

Embedded Engineer

eInfochips Ltd, Ahmedabad, India

+91-079-26563705 - ext - 303

www.einfochips.com

 

From: Pratik Joshi [mailto:pratik.joshi at einfochips.com] 
Sent: Tuesday, March 30, 2010 6:26 PM
To: 'davinci-linux-open-source at linux.davincidsp.com'
Subject: Query -USB hub with multiple block devices connected

 

Hi All,

 

We are seeing following problem:

 

Setup:

We have connected a USB hub to DVEVM. We have connected two bulk devices
mass storage and USB wireless device. We are continuously receiving data
on USB wireless device (using iperf utility) and at the same time
continuously writing to mass storage device. We do fsync () after
writing data using write command to ensure data is actually written to
mass storage device.

 

Problem statement:

In above setup we see SCSI errors and I/O errors. Also we have observed
"usb 1-1.1: usb_sg_cancel, unlink --> 0" message sometimes. What is the
significance of this message? Has anyone tested USB driver in such a
driver? 

 

Regards,

Pratik Joshi

Embedded Engineer

eInfochips Ltd, Ahmedabad, India

+91-079-26563705 - ext - 303

www.einfochips.com


-- 

  _____  

Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution, copying, or other use of
this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
replying to this message and please delete it from your computer. Any
views expressed in this message are those of the individual sender
unless otherwise stated.Company has taken enough precautions to prevent
the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email. 

  _____  




__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4991 (20100401) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100401/4efbb403/attachment-0001.html>

From mchehab at redhat.com  Thu Apr  1 10:20:39 2010
From: mchehab at redhat.com (Mauro Carvalho Chehab)
Date: Thu, 01 Apr 2010 13:20:39 -0300
Subject: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash
	on 	DM365
In-Reply-To: <55a3e0ce1003270613k1d565204qfe51a5f746439701@mail.gmail.com>
References: <1268846327-7255-1-git-send-email-m-karicheri2@ti.com>	
	<A69FA2915331DC488A831521EAE36FE4016A6EC7D3@dlee06.ent.ti.com>	
	<4BAA6CF8.4060006@redhat.com>
	<55a3e0ce1003270613k1d565204qfe51a5f746439701@mail.gmail.com>
Message-ID: <4BB4C7D7.2000304@redhat.com>

Muralidharan Karicheri wrote:
> Mauro,
> 
> When I had last replied to your email, I didn't check if the patch is
> actually applied to your v4l_for_linux branch of fixes.git tree. But
> Today I checked and I can't find the patch merged to this tree as you
> had mentioned..
> 
> So if you haven't merged it for some reason, please merge my updated patch
> available at https://patchwork.kernel.org/patch/86731/
> 

I had merged, but, as I haven't pushed on linuxtv, I decided to rebase my local
tree. Patch applied.

-- 

Cheers,
Mauro

From m-karicheri2 at ti.com  Thu Apr  1 10:29:38 2010
From: m-karicheri2 at ti.com (Karicheri, Muralidharan)
Date: Thu, 1 Apr 2010 11:29:38 -0500
Subject: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash
	on 	DM365
In-Reply-To: <4BB4C7D7.2000304@redhat.com>
References: <1268846327-7255-1-git-send-email-m-karicheri2@ti.com>
	<A69FA2915331DC488A831521EAE36FE4016A6EC7D3@dlee06.ent.ti.com>
	<4BAA6CF8.4060006@redhat.com>
	<55a3e0ce1003270613k1d565204qfe51a5f746439701@mail.gmail.com>
	<4BB4C7D7.2000304@redhat.com>
Message-ID: <A69FA2915331DC488A831521EAE36FE4016A92CBB2@dlee06.ent.ti.com>

Mauro,

Thanks a lot for your support.

Do you plan to merge my pull request for 2.6.35 anytime soon?

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-karicheri2 at ti.com

>-----Original Message-----
>From: Mauro Carvalho Chehab [mailto:mchehab at redhat.com]
>Sent: Thursday, April 01, 2010 12:21 PM
>To: Muralidharan Karicheri
>Cc: Karicheri, Muralidharan; linux-media at vger.kernel.org;
>hverkuil at xs4all.nl; davinci-linux-open-source at linux.davincidsp.com
>Subject: Re: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash
>on DM365
>
>Muralidharan Karicheri wrote:
>> Mauro,
>>
>> When I had last replied to your email, I didn't check if the patch is
>> actually applied to your v4l_for_linux branch of fixes.git tree. But
>> Today I checked and I can't find the patch merged to this tree as you
>> had mentioned..
>>
>> So if you haven't merged it for some reason, please merge my updated
>patch
>> available at https://patchwork.kernel.org/patch/86731/
>>
>
>I had merged, but, as I haven't pushed on linuxtv, I decided to rebase my
>local
>tree. Patch applied.
>
>--
>
>Cheers,
>Mauro

From lamiaposta71 at gmail.com  Thu Apr  1 10:31:16 2010
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Thu, 1 Apr 2010 18:31:16 +0200
Subject: dm365 - voice codec
Message-ID: <j2tade1bdc1004010931v440aa4fdz97de74bbb8c7ca25@mail.gmail.com>

It seems that in git kernel this peripheral is not yet supported.
I search everywere:

./arch/arm/mach-davinci/dm365.c:        CLK("davinci_voicecodec",
NULL, &voicecodec_clk),
./arch/arm/mach-davinci/dm365.c:        .name           = "davinci_voicecodec",

This means that davinci_voicecodec is not really configured.
Anybody can please confirm this point and tell me the development roadmap?

Thx,
Raffaele

From mchehab at redhat.com  Thu Apr  1 10:35:33 2010
From: mchehab at redhat.com (Mauro Carvalho Chehab)
Date: Thu, 01 Apr 2010 13:35:33 -0300
Subject: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash
	on 	DM365
In-Reply-To: <A69FA2915331DC488A831521EAE36FE4016A92CBB2@dlee06.ent.ti.com>
References: <1268846327-7255-1-git-send-email-m-karicheri2@ti.com>	
	<A69FA2915331DC488A831521EAE36FE4016A6EC7D3@dlee06.ent.ti.com>	
	<4BAA6CF8.4060006@redhat.com>
	<55a3e0ce1003270613k1d565204qfe51a5f746439701@mail.gmail.com>
	<4BB4C7D7.2000304@redhat.com>
	<A69FA2915331DC488A831521EAE36FE4016A92CBB2@dlee06.ent.ti.com>
Message-ID: <4BB4CB55.8060503@redhat.com>

Karicheri, Muralidharan wrote:
> Mauro,
> 
> Thanks a lot for your support.
> 
> Do you plan to merge my pull request for 2.6.35 anytime soon?

It were already merged locally. I'm running a compilation of the
tree with the merged patches. If all compile ok, your pull request
(and others) will be at linuxtv server soon.

-- 

Cheers,
Mauro

From richard.salvetat at arbos-dsp.com  Thu Apr  1 10:48:48 2010
From: richard.salvetat at arbos-dsp.com (Richard SALVETAT)
Date: Thu, 1 Apr 2010 18:48:48 +0200
Subject: cancel my inscription
Message-ID: <20100401164847.66AA38000367@mwinf2f24.orange.fr>

Please stop my incripstion on the mail list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100401/04251b84/attachment.html>

From m-karicheri2 at ti.com  Thu Apr  1 12:08:54 2010
From: m-karicheri2 at ti.com (Karicheri, Muralidharan)
Date: Thu, 1 Apr 2010 13:08:54 -0500
Subject: isif - debugging on dm365
In-Reply-To: <j2qade1bdc1003310748t5b57539cs4c868911e7d464e5@mail.gmail.com>
References: <ade1bdc1003300750r111aeda4iaeab54f770a86331@mail.gmail.com>
	<A69FA2915331DC488A831521EAE36FE4016A8B3D35@dlee06.ent.ti.com>
	<ade1bdc1003300915q6a557cc8n9ac9684c439cad42@mail.gmail.com>
	<A69FA2915331DC488A831521EAE36FE4016A8B3DD2@dlee06.ent.ti.com>
	<j2qade1bdc1003310748t5b57539cs4c868911e7d464e5@mail.gmail.com>
Message-ID: <A69FA2915331DC488A831521EAE36FE4016A92CC50@dlee06.ent.ti.com>

Raffaele,

 [MK] 0 means the interrupt happens right at VD pulse. 1 means after one line. You might want to check the signals received from ADV to input of VPFE to see if adv is doing what it is configured to do.

My colleague has found how to make the vpfe_isr interrupt working with adv7180.
He has made this change in isif.c inside isif_config_ycbcr:

-               ccdcfg = ccdcfg | ISIF_DATA_PACK8 | ISIF_YCINSWP_YCBCR;
+               ccdcfg = ccdcfg | ISIF_DATA_PACK8 ;
[MK] What you are doing is essentially swapping the Y and C input lines. Probably on your board, you are connecting the input differently than on the DM365 evm. Please confirm if this is the only change that got it working.
He verified that tvp514x was really working using 10bit port.
If he disabled pinmux on Y0 and Y1 interrupts aren't generated.
But in isif_config_ycbcr function the kernel enters in
                case VPFE_BT656:
because it lacks a call for setting isif_cfg.if_type.
I think the problem is that the YCINSWP setting on your board. In 8 bit mode, this decides whether input signals are connected to Y input or C input. In TVP5146 on DM365, it is connected to C input, where as on your board it is connected to Y input. So we need to add this as a configurable variable in the board setup file, read it and set in isif.c. Please send a patch to the list. For example define a variable y_c_swap and set it to 0 in your board. On DM365 evm board file you can set it to 1 so that it works fine for tvp5146 and adv7180. In isif.c you can read this variable and update the YCINSWP bit in CCDCFG. Are you planning to send a patch for this?
Murali






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100401/887ee9a8/attachment.html>

From m-karicheri2 at ti.com  Thu Apr  1 12:12:13 2010
From: m-karicheri2 at ti.com (Karicheri, Muralidharan)
Date: Thu, 1 Apr 2010 13:12:13 -0500
Subject: isif - debugging on dm365
In-Reply-To: <A69FA2915331DC488A831521EAE36FE4016A92CC50@dlee06.ent.ti.com>
References: <ade1bdc1003300750r111aeda4iaeab54f770a86331@mail.gmail.com>
	<A69FA2915331DC488A831521EAE36FE4016A8B3D35@dlee06.ent.ti.com>
	<ade1bdc1003300915q6a557cc8n9ac9684c439cad42@mail.gmail.com>
	<A69FA2915331DC488A831521EAE36FE4016A8B3DD2@dlee06.ent.ti.com>
	<j2qade1bdc1003310748t5b57539cs4c868911e7d464e5@mail.gmail.com>
	<A69FA2915331DC488A831521EAE36FE4016A92CC50@dlee06.ent.ti.com>
Message-ID: <A69FA2915331DC488A831521EAE36FE4016A92CC5A@dlee06.ent.ti.com>

Some typo corrected....


Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-karicheri2 at ti.com

________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Karicheri, Muralidharan
Sent: Thursday, April 01, 2010 2:09 PM
To: Raffaele Recalcati
Cc: davinci-linux-open-source
Subject: RE: isif - debugging on dm365

Raffaele,

 [MK] 0 means the interrupt happens right at VD pulse. 1 means after one line. You might want to check the signals received from ADV to input of VPFE to see if adv is doing what it is configured to do.

My colleague has found how to make the vpfe_isr interrupt working with adv7180.
He has made this change in isif.c inside isif_config_ycbcr:

-               ccdcfg = ccdcfg | ISIF_DATA_PACK8 | ISIF_YCINSWP_YCBCR;
+               ccdcfg = ccdcfg | ISIF_DATA_PACK8 ;
[MK] What you are doing is essentially swapping the Y and C input lines. Probably on your board, you are connecting the input differently than on the DM365 evm. Please confirm if this is the only change that got it working.
He verified that tvp514x was really working using 10bit port.
If he disabled pinmux on Y0 and Y1 interrupts aren't generated.
But in isif_config_ycbcr function the kernel enters in
                case VPFE_BT656:
because it lacks a call for setting isif_cfg.if_type.
I think the problem is in the YCINSWP setting on your board. In 8 bit mode, this decides whether input signals are connected to Y input or C input as per data sheet. In TVP5146 on DM365 evm, it is connected to C input and hence we set that bit, where as on your board it is connected to Y input. So we need to add this as a configurable variable in the board setup file, read it and set in isif.c. Please send a patch to the list. For example define a variable y_c_swap and set it to 0 in your board. On DM365 evm board file you can set it to 1 so that it works fine for both tvp5146 and adv7180. In isif.c you can read this variable and update the YCINSWP bit in CCDCFG.
Murali




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100401/73468e26/attachment.html>

From lamiaposta71 at gmail.com  Fri Apr  2 00:38:04 2010
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Fri, 2 Apr 2010 08:38:04 +0200
Subject: isif - debugging on dm365
In-Reply-To: <A69FA2915331DC488A831521EAE36FE4016A92CC50@dlee06.ent.ti.com>
References: <ade1bdc1003300750r111aeda4iaeab54f770a86331@mail.gmail.com>
	<A69FA2915331DC488A831521EAE36FE4016A8B3D35@dlee06.ent.ti.com>
	<ade1bdc1003300915q6a557cc8n9ac9684c439cad42@mail.gmail.com>
	<A69FA2915331DC488A831521EAE36FE4016A8B3DD2@dlee06.ent.ti.com>
	<j2qade1bdc1003310748t5b57539cs4c868911e7d464e5@mail.gmail.com>
	<A69FA2915331DC488A831521EAE36FE4016A92CC50@dlee06.ent.ti.com>
Message-ID: <r2nade1bdc1004012338yb12139b8k697d9831df81de33@mail.gmail.com>

I ll send a patch tuesday. Today i am on holyday

2010/4/1, Karicheri, Muralidharan <m-karicheri2 at ti.com>:
> Raffaele,
>
>  [MK] 0 means the interrupt happens right at VD pulse. 1 means after one
> line. You might want to check the signals received from ADV to input of VPFE
> to see if adv is doing what it is configured to do.
>
> My colleague has found how to make the vpfe_isr interrupt working with
> adv7180.
> He has made this change in isif.c inside isif_config_ycbcr:
>
> -               ccdcfg = ccdcfg | ISIF_DATA_PACK8 | ISIF_YCINSWP_YCBCR;
> +               ccdcfg = ccdcfg | ISIF_DATA_PACK8 ;
> [MK] What you are doing is essentially swapping the Y and C input lines.
> Probably on your board, you are connecting the input differently than on the
> DM365 evm. Please confirm if this is the only change that got it working.
> He verified that tvp514x was really working using 10bit port.
> If he disabled pinmux on Y0 and Y1 interrupts aren't generated.
> But in isif_config_ycbcr function the kernel enters in
>                 case VPFE_BT656:
> because it lacks a call for setting isif_cfg.if_type.
> I think the problem is that the YCINSWP setting on your board. In 8 bit
> mode, this decides whether input signals are connected to Y input or C
> input. In TVP5146 on DM365, it is connected to C input, where as on your
> board it is connected to Y input. So we need to add this as a configurable
> variable in the board setup file, read it and set in isif.c. Please send a
> patch to the list. For example define a variable y_c_swap and set it to 0 in
> your board. On DM365 evm board file you can set it to 1 so that it works
> fine for tvp5146 and adv7180. In isif.c you can read this variable and
> update the YCINSWP bit in CCDCFG. Are you planning to send a patch for this?
> Murali
>
>
>
>
>
>
>


-- 
www.opensurf.it

From a.auer at zydacron.com  Fri Apr  2 02:58:15 2010
From: a.auer at zydacron.com (Andreas Auer)
Date: Fri, 02 Apr 2010 10:58:15 +0200
Subject: DM6446 and DSA (Distributed Switch Architecture)
In-Reply-To: <i2nfca5cfb21003310708s83569139p51c56915e1c6c728@mail.gmail.com>
References: <houuji$a30$1@dough.gmane.org>
	<i2nfca5cfb21003310708s83569139p51c56915e1c6c728@mail.gmail.com>
Message-ID: <hp4bl8$i6f$1@dough.gmane.org>

Steve Chen schrieb:
> On Wed, Mar 31, 2010 at 2:44 AM, Andreas Auer <a.auer at zydacron.com> wrote:
>> Hello,
>>
>> I'm using a customized board similar to the EVM with a DM6446 cpu. The main
>> difference is that I'm using a Micrel KSZ8893M ethernet switch. The ethernet
>> switch has an I2C config interface and the standard mdio interface.
>> Therefore, I'm using the DSA driver subsystem and wrote a small chip driver
>> (I took the KSZ8893 driver for the Blackfin processor as reference).
>> Now, my problem is that the ethernet mac of the Davinci cpu is initialized
>> (probed) later then the DSA driver. And therefore the DSA driver cannot find
>> a valid netdevice.
>> Does anyone know how to change the initialization order of the devices??
>> Changing the order of the register_device_driver function calls has
>> basically no influence on the init sequence.
>>
>> Thanks,
>> Andreas
> 
> Hello,
> 
> I encounter the same issue with DA830/OMAP-l137 EVM.  Instead of
> probing PHY to get speed and duplexity, the driver just set the speed
> and duplexity based on platform data.  May want to take a look at the
> OMAP-l137.

Thanks for your answer. I got another solution. The davinci_emac driver 
calls the init function very late because of
       late_initcall(davinci_emac_init);

I changed this line:
       module_init(davinci_emac_init);

Now, it is working!

Cheers,
Andreas


From albertbu at gmail.com  Fri Apr  2 08:12:26 2010
From: albertbu at gmail.com (Albert Burbea)
Date: Fri, 2 Apr 2010 16:12:26 +0200
Subject: video port for omap
Message-ID: <k2sb0389af41004020712q320f093eme1bac89a50723103@mail.gmail.com>

hi guys
can somebody pls explain me how to configure the mistral board kernel (arago
kernel) to use a specific video sensor
(non standard one)
10x in advance
-- 
Albert Burbea
Mobile: +972-52-3541842
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100402/87136546/attachment.html>

From todd.fischer at ridgerun.com  Fri Apr  2 15:33:44 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Fri, 02 Apr 2010 15:33:44 -0600
Subject: [PATCH 0/4]-V2 TPS6507x MFD driver
In-Reply-To: <1269634292-29686-1-git-send-email-todd.fischer@ridgerun.com>
References: <1269634292-29686-1-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <1270244024.20290.8603.camel@sax-lx>

This is the second posting of the TPS6507x driver set.  I have
incorporated Mark Brown's feedback and retested.  Patches 3 and
5 have been combined so there are only 4 patches in the series now.

The TPS6507x family of Texas Instruments power management ICs (pmic) are
multi-function chips that include voltage regulation and touch screen
controller capabilities.  This patch set adds a TPS6507x multi-function
device driver and change the TPS6507x regulator driver to use the
TPS6507x MFD driver instead of interacting with the chip directly.  The
changes are needed before a touch screen driver can be added.

The patch set applies cleanly to the MFD repository:
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git  If the
MFD and voltage regulator maintainer would prefer I post patches for a
different repository, please let me know.

The TPS6507x touch screen input driver will be posted to
linux-input at vger.kernel.org list.


From todd.fischer at ridgerun.com  Fri Apr  2 15:37:29 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Fri,  2 Apr 2010 15:37:29 -0600
Subject: [PATCH 0/4]-V2 TPS6507x MFD driver
Message-ID: <1270244253-4234-1-git-send-email-todd.fischer@ridgerun.com>


This is the second posting of the TPS6507x driver set.  I have
incorporated Mark Brown's feedback and retested.  Patches 3 and
5 have been combined so there are only 4 patches in the series now.

The TPS6507x family of Texas Instruments power management ICs (pmic) are
multi-function chips that include voltage regulation and touch screen
controller capabilities.  This patch set adds a TPS6507x multi-function
device driver and change the TPS6507x regulator driver to use the
TPS6507x MFD driver instead of interacting with the chip directly.  The
changes are needed before a touch screen driver can be added.

The patch set applies cleanly to the MFD repository:
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git  If the
MFD and voltage regulator maintainer would prefer I post patches for a
different repository, please let me know.

The TPS6507x touch screen input driver will be posted to
linux-input at vger.kernel.org list.

From todd.fischer at ridgerun.com  Fri Apr  2 15:37:30 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Fri,  2 Apr 2010 15:37:30 -0600
Subject: [PATCH 1/4]-V2 Move TPS6507x register definition to header file.
In-Reply-To: <1270244253-4234-1-git-send-email-todd.fischer@ridgerun.com>
References: <1270244253-4234-1-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <1270244253-4234-2-git-send-email-todd.fischer@ridgerun.com>

Other sub-drivers for the TPS6507x chip will need to use register 
definition so move it out of the source file and into a header file.

Signed-off-by: Todd Fischer <todd.fischer at ridgerun.com>
---
 drivers/regulator/tps6507x-regulator.c |   60 +--------------
 include/linux/mfd/tps6507x.h           |  134 ++++++++++++++++++++++++++++++++
 2 files changed, 135 insertions(+), 59 deletions(-)
 create mode 100644 include/linux/mfd/tps6507x.h

diff --git a/drivers/regulator/tps6507x-regulator.c b/drivers/regulator/tps6507x-regulator.c
index c2a9539..91172e3 100644
--- a/drivers/regulator/tps6507x-regulator.c
+++ b/drivers/regulator/tps6507x-regulator.c
@@ -24,65 +24,7 @@
 #include <linux/regulator/machine.h>
 #include <linux/i2c.h>
 #include <linux/delay.h>
-
-/* Register definitions */
-#define	TPS6507X_REG_PPATH1				0X01
-#define	TPS6507X_REG_INT				0X02
-#define	TPS6507X_REG_CHGCONFIG0				0X03
-#define	TPS6507X_REG_CHGCONFIG1				0X04
-#define	TPS6507X_REG_CHGCONFIG2				0X05
-#define	TPS6507X_REG_CHGCONFIG3				0X06
-#define	TPS6507X_REG_REG_ADCONFIG			0X07
-#define	TPS6507X_REG_TSCMODE				0X08
-#define	TPS6507X_REG_ADRESULT_1				0X09
-#define	TPS6507X_REG_ADRESULT_2				0X0A
-#define	TPS6507X_REG_PGOOD				0X0B
-#define	TPS6507X_REG_PGOODMASK				0X0C
-#define	TPS6507X_REG_CON_CTRL1				0X0D
-#define	TPS6507X_REG_CON_CTRL2				0X0E
-#define	TPS6507X_REG_CON_CTRL3				0X0F
-#define	TPS6507X_REG_DEFDCDC1				0X10
-#define	TPS6507X_REG_DEFDCDC2_LOW			0X11
-#define	TPS6507X_REG_DEFDCDC2_HIGH			0X12
-#define	TPS6507X_REG_DEFDCDC3_LOW			0X13
-#define	TPS6507X_REG_DEFDCDC3_HIGH			0X14
-#define	TPS6507X_REG_DEFSLEW				0X15
-#define	TPS6507X_REG_LDO_CTRL1				0X16
-#define	TPS6507X_REG_DEFLDO2				0X17
-#define	TPS6507X_REG_WLED_CTRL1				0X18
-#define	TPS6507X_REG_WLED_CTRL2				0X19
-
-/* CON_CTRL1 bitfields */
-#define	TPS6507X_CON_CTRL1_DCDC1_ENABLE		BIT(4)
-#define	TPS6507X_CON_CTRL1_DCDC2_ENABLE		BIT(3)
-#define	TPS6507X_CON_CTRL1_DCDC3_ENABLE		BIT(2)
-#define	TPS6507X_CON_CTRL1_LDO1_ENABLE		BIT(1)
-#define	TPS6507X_CON_CTRL1_LDO2_ENABLE		BIT(0)
-
-/* DEFDCDC1 bitfields */
-#define TPS6507X_DEFDCDC1_DCDC1_EXT_ADJ_EN	BIT(7)
-#define TPS6507X_DEFDCDC1_DCDC1_MASK		0X3F
-
-/* DEFDCDC2_LOW bitfields */
-#define TPS6507X_DEFDCDC2_LOW_DCDC2_MASK	0X3F
-
-/* DEFDCDC2_HIGH bitfields */
-#define TPS6507X_DEFDCDC2_HIGH_DCDC2_MASK	0X3F
-
-/* DEFDCDC3_LOW bitfields */
-#define TPS6507X_DEFDCDC3_LOW_DCDC3_MASK	0X3F
-
-/* DEFDCDC3_HIGH bitfields */
-#define TPS6507X_DEFDCDC3_HIGH_DCDC3_MASK	0X3F
-
-/* TPS6507X_REG_LDO_CTRL1 bitfields */
-#define TPS6507X_REG_LDO_CTRL1_LDO1_MASK	0X0F
-
-/* TPS6507X_REG_DEFLDO2 bitfields */
-#define TPS6507X_REG_DEFLDO2_LDO2_MASK		0X3F
-
-/* VDCDC MASK */
-#define TPS6507X_DEFDCDCX_DCDC_MASK		0X3F
+#include <linux/mfd/tps6507x.h>
 
 /* DCDC's */
 #define TPS6507X_DCDC_1				0
diff --git a/include/linux/mfd/tps6507x.h b/include/linux/mfd/tps6507x.h
new file mode 100644
index 0000000..155bee1
--- /dev/null
+++ b/include/linux/mfd/tps6507x.h
@@ -0,0 +1,134 @@
+/* linux/mfd/tps6507x.h
+ *
+ * Functions to access TPS65070 power management chip.
+ *
+ * Copyright (c) 2009 RidgeRun (todd.fischer at ridgerun.com)
+ *
+ *
+ *  For licencing details see kernel-base/COPYING
+ */
+
+#ifndef __LINUX_MFD_TPS6507X_H
+#define __LINUX_MFD_TPS6507X_H
+
+/*
+ * ----------------------------------------------------------------------------
+ * Registers, all 8 bits
+ * ----------------------------------------------------------------------------
+ */
+
+
+/* Register definitions */
+#define	TPS6507X_REG_PPATH1			0X01
+#define	TPS6507X_CHG_USB			BIT(7)
+#define	TPS6507X_CHG_AC				BIT(6)
+#define	TPS6507X_CHG_USB_PW_ENABLE		BIT(5)
+#define	TPS6507X_CHG_AC_PW_ENABLE		BIT(4)
+#define	TPS6507X_CHG_AC_CURRENT			BIT(2)
+#define	TPS6507X_CHG_USB_CURRENT		BIT(0)
+
+#define	TPS6507X_REG_INT			0X02
+#define	TPS6507X_REG_MASK_AC_USB		BIT(7)
+#define	TPS6507X_REG_MASK_TSC			BIT(6)
+#define	TPS6507X_REG_MASK_PB_IN			BIT(5)
+#define	TPS6507X_REG_TSC_INT			BIT(3)
+#define	TPS6507X_REG_PB_IN_INT			BIT(2)
+#define	TPS6507X_REG_AC_USB_APPLIED		BIT(1)
+#define	TPS6507X_REG_AC_USB_REMOVED		BIT(0)
+
+#define	TPS6507X_REG_CHGCONFIG0			0X03
+
+#define	TPS6507X_REG_CHGCONFIG1			0X04
+#define	TPS6507X_CON_CTRL1_DCDC1_ENABLE		BIT(4)
+#define	TPS6507X_CON_CTRL1_DCDC2_ENABLE		BIT(3)
+#define	TPS6507X_CON_CTRL1_DCDC3_ENABLE		BIT(2)
+#define	TPS6507X_CON_CTRL1_LDO1_ENABLE		BIT(1)
+#define	TPS6507X_CON_CTRL1_LDO2_ENABLE		BIT(0)
+
+#define	TPS6507X_REG_CHGCONFIG2			0X05
+
+#define	TPS6507X_REG_CHGCONFIG3			0X06
+
+#define	TPS6507X_REG_ADCONFIG			0X07
+#define	TPS6507X_ADCONFIG_AD_ENABLE		BIT(7)
+#define	TPS6507X_ADCONFIG_START_CONVERSION	BIT(6)
+#define	TPS6507X_ADCONFIG_CONVERSION_DONE	BIT(5)
+#define	TPS6507X_ADCONFIG_VREF_ENABLE		BIT(4)
+#define	TPS6507X_ADCONFIG_INPUT_AD_IN1		0
+#define	TPS6507X_ADCONFIG_INPUT_AD_IN2		1
+#define	TPS6507X_ADCONFIG_INPUT_AD_IN3		2
+#define	TPS6507X_ADCONFIG_INPUT_AD_IN4		3
+#define	TPS6507X_ADCONFIG_INPUT_TS_PIN		4
+#define	TPS6507X_ADCONFIG_INPUT_BAT_CURRENT	5
+#define	TPS6507X_ADCONFIG_INPUT_AC_VOLTAGE	6
+#define	TPS6507X_ADCONFIG_INPUT_SYS_VOLTAGE	7
+#define	TPS6507X_ADCONFIG_INPUT_CHARGER_VOLTAGE 8
+#define	TPS6507X_ADCONFIG_INPUT_BAT_VOLTAGE	9
+#define	TPS6507X_ADCONFIG_INPUT_THRESHOLD_VOLTAGE 10
+#define	TPS6507X_ADCONFIG_INPUT_ISET1_VOLTAGE	11
+#define	TPS6507X_ADCONFIG_INPUT_ISET2_VOLTAGE	12
+#define	TPS6507X_ADCONFIG_INPUT_REAL_TSC	14
+#define	TPS6507X_ADCONFIG_INPUT_TSC		15
+
+#define	TPS6507X_REG_TSCMODE			0X08
+#define	TPS6507X_TSCMODE_X_POSITION		0
+#define	TPS6507X_TSCMODE_Y_POSITION		1
+#define	TPS6507X_TSCMODE_PRESSURE		2
+#define	TPS6507X_TSCMODE_X_PLATE		3
+#define	TPS6507X_TSCMODE_Y_PLATE		4
+#define	TPS6507X_TSCMODE_STANDBY		5
+#define	TPS6507X_TSCMODE_ADC_INPUT		6
+#define	TPS6507X_TSCMODE_DISABLE		7
+
+#define	TPS6507X_REG_ADRESULT_1			0X09
+
+#define	TPS6507X_REG_ADRESULT_2			0X0A
+#define	TPS6507X_REG_ADRESULT_2_MASK		(BIT(1) | BIT(0))
+
+#define	TPS6507X_REG_PGOOD			0X0B
+
+#define	TPS6507X_REG_PGOODMASK			0X0C
+
+#define	TPS6507X_REG_CON_CTRL1			0X0D
+#define	TPS6507X_CON_CTRL1_DCDC1_ENABLE		BIT(4)
+#define	TPS6507X_CON_CTRL1_DCDC2_ENABLE		BIT(3)
+#define	TPS6507X_CON_CTRL1_DCDC3_ENABLE		BIT(2)
+#define	TPS6507X_CON_CTRL1_LDO1_ENABLE		BIT(1)
+#define	TPS6507X_CON_CTRL1_LDO2_ENABLE		BIT(0)
+
+#define	TPS6507X_REG_CON_CTRL2			0X0E
+
+#define	TPS6507X_REG_CON_CTRL3			0X0F
+
+#define	TPS6507X_REG_DEFDCDC1			0X10
+#define TPS6507X_DEFDCDC1_DCDC1_EXT_ADJ_EN	BIT(7)
+#define TPS6507X_DEFDCDC1_DCDC1_MASK		0X3F
+
+#define	TPS6507X_REG_DEFDCDC2_LOW		0X11
+#define TPS6507X_DEFDCDC2_LOW_DCDC2_MASK	0X3F
+
+#define	TPS6507X_REG_DEFDCDC2_HIGH		0X12
+#define TPS6507X_DEFDCDC2_HIGH_DCDC2_MASK	0X3F
+
+#define	TPS6507X_REG_DEFDCDC3_LOW		0X13
+#define TPS6507X_DEFDCDC3_LOW_DCDC3_MASK	0X3F
+
+#define	TPS6507X_REG_DEFDCDC3_HIGH		0X14
+#define TPS6507X_DEFDCDC3_HIGH_DCDC3_MASK	0X3F
+
+#define	TPS6507X_REG_DEFSLEW			0X15
+
+#define	TPS6507X_REG_LDO_CTRL1			0X16
+#define TPS6507X_REG_LDO_CTRL1_LDO1_MASK	0X0F
+
+#define	TPS6507X_REG_DEFLDO2			0X17
+#define TPS6507X_REG_DEFLDO2_LDO2_MASK		0X3F
+
+#define	TPS6507X_REG_WLED_CTRL1			0X18
+
+#define	TPS6507X_REG_WLED_CTRL2			0X19
+
+/* VDCDC MASK */
+#define TPS6507X_DEFDCDCX_DCDC_MASK		0X3F
+
+#endif /*  __LINUX_MFD_TPS6507X_H */
-- 
1.6.0.4


From todd.fischer at ridgerun.com  Fri Apr  2 15:37:31 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Fri,  2 Apr 2010 15:37:31 -0600
Subject: [PATCH 2/4]-V2 Make room for other tps6507x drivers to have board
	specific initialization data.
In-Reply-To: <1270244253-4234-2-git-send-email-todd.fischer@ridgerun.com>
References: <1270244253-4234-1-git-send-email-todd.fischer@ridgerun.com>
	<1270244253-4234-2-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <1270244253-4234-3-git-send-email-todd.fischer@ridgerun.com>

Add mfd structure which refrences sub-driver initialization data. For example,
for a giving hardware implementation, the voltage regulator sub-driver
initialization data provides the mapping betten a voltage regulator and what
the output voltage is being used for.

Signed-off-by: Todd Fischer <todd.fischer at ridgerun.com>
---
 arch/arm/mach-davinci/board-da850-evm.c |    7 ++++++-
 drivers/regulator/tps6507x-regulator.c  |   14 ++++++++++++--
 include/linux/mfd/tps6507x.h            |   11 +++++++++++
 3 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 411284d..d059924 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -17,6 +17,7 @@
 #include <linux/i2c.h>
 #include <linux/i2c/at24.h>
 #include <linux/i2c/pca953x.h>
+#include <linux/mfd/tps6507x.h>
 #include <linux/gpio.h>
 #include <linux/platform_device.h>
 #include <linux/mtd/mtd.h>
@@ -533,10 +534,14 @@ struct regulator_init_data tps65070_regulator_data[] = {
 	},
 };
 
+static struct tps6507x_board tps_board = {
+	.tps6507x_pmic_init_data = &tps65070_regulator_data[0],
+};
+
 static struct i2c_board_info __initdata da850evm_tps65070_info[] = {
 	{
 		I2C_BOARD_INFO("tps6507x", 0x48),
-		.platform_data = &tps65070_regulator_data[0],
+		.platform_data = &tps_board,
 	},
 };
 
diff --git a/drivers/regulator/tps6507x-regulator.c b/drivers/regulator/tps6507x-regulator.c
index 91172e3..becf652 100644
--- a/drivers/regulator/tps6507x-regulator.c
+++ b/drivers/regulator/tps6507x-regulator.c
@@ -488,6 +488,7 @@ static int __devinit tps_6507x_probe(struct i2c_client *client,
 	struct regulator_init_data *init_data;
 	struct regulator_dev *rdev;
 	struct tps_pmic *tps;
+	struct tps6507x_board *tps_board;
 	int i;
 	int error;
 
@@ -496,12 +497,21 @@ static int __devinit tps_6507x_probe(struct i2c_client *client,
 		return -EIO;
 
 	/**
+	 * tps_board points to pmic related constants
+	 * coming from the board-evm file.
+	 */
+
+	tps_board = dev_get_platdata(&client->dev);
+	if (!tps_board)
+		return -EINVAL;
+
+	/**
 	 * init_data points to array of regulator_init structures
 	 * coming from the board-evm file.
 	 */
-	init_data = client->dev.platform_data;
+	init_data = tps_board->tps6507x_pmic_init_data;
 	if (!init_data)
-		return -EIO;
+		return -EINVAL;
 
 	tps = kzalloc(sizeof(*tps), GFP_KERNEL);
 	if (!tps)
diff --git a/include/linux/mfd/tps6507x.h b/include/linux/mfd/tps6507x.h
index 155bee1..fd73af5 100644
--- a/include/linux/mfd/tps6507x.h
+++ b/include/linux/mfd/tps6507x.h
@@ -131,4 +131,15 @@
 /* VDCDC MASK */
 #define TPS6507X_DEFDCDCX_DCDC_MASK		0X3F
 
+/**
+ * struct tps6507x_board - packages regulator and touchscreen init data
+ * @tps6507x_regulator_data: regulator initialization values
+ *
+ * Board data may be used to initialize regulator and touchscreen.
+ */
+
+struct tps6507x_board {
+	struct regulator_init_data *tps6507x_pmic_init_data;
+};
+
 #endif /*  __LINUX_MFD_TPS6507X_H */
-- 
1.6.0.4


From todd.fischer at ridgerun.com  Fri Apr  2 15:37:32 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Fri,  2 Apr 2010 15:37:32 -0600
Subject: [PATCH 3/4]-V2 Cleaned up name space so each MFD sub-driver uses a
	different name space.
In-Reply-To: <1270244253-4234-3-git-send-email-todd.fischer@ridgerun.com>
References: <1270244253-4234-1-git-send-email-todd.fischer@ridgerun.com>
	<1270244253-4234-2-git-send-email-todd.fischer@ridgerun.com>
	<1270244253-4234-3-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <1270244253-4234-4-git-send-email-todd.fischer@ridgerun.com>

Move from using tps or tsp6507x to tps6057x_pmic in a consistent manner.

Signed-off-by: Todd Fischer <todd.fischer at ridgerun.com>
---
 drivers/regulator/tps6507x-regulator.c |  172 ++++++++++++++++----------------
 1 files changed, 87 insertions(+), 85 deletions(-)

diff --git a/drivers/regulator/tps6507x-regulator.c b/drivers/regulator/tps6507x-regulator.c
index becf652..86f2e05 100644
--- a/drivers/regulator/tps6507x-regulator.c
+++ b/drivers/regulator/tps6507x-regulator.c
@@ -103,7 +103,7 @@ struct tps_info {
 	const u16 *table;
 };
 
-struct tps_pmic {
+struct tps6507x_pmic {
 	struct regulator_desc desc[TPS6507X_NUM_REGULATOR];
 	struct i2c_client *client;
 	struct regulator_dev *rdev[TPS6507X_NUM_REGULATOR];
@@ -111,23 +111,23 @@ struct tps_pmic {
 	struct mutex io_lock;
 };
 
-static inline int tps_6507x_read(struct tps_pmic *tps, u8 reg)
+static inline int tps6507x_pmic_read(struct tps6507x_pmic *tps, u8 reg)
 {
 	return i2c_smbus_read_byte_data(tps->client, reg);
 }
 
-static inline int tps_6507x_write(struct tps_pmic *tps, u8 reg, u8 val)
+static inline int tps6507x_pmic_write(struct tps6507x_pmic *tps, u8 reg, u8 val)
 {
 	return i2c_smbus_write_byte_data(tps->client, reg, val);
 }
 
-static int tps_6507x_set_bits(struct tps_pmic *tps, u8 reg, u8 mask)
+static int tps6507x_pmic_set_bits(struct tps6507x_pmic *tps, u8 reg, u8 mask)
 {
 	int err, data;
 
 	mutex_lock(&tps->io_lock);
 
-	data = tps_6507x_read(tps, reg);
+	data = tps6507x_pmic_read(tps, reg);
 	if (data < 0) {
 		dev_err(&tps->client->dev, "Read from reg 0x%x failed\n", reg);
 		err = data;
@@ -135,7 +135,7 @@ static int tps_6507x_set_bits(struct tps_pmic *tps, u8 reg, u8 mask)
 	}
 
 	data |= mask;
-	err = tps_6507x_write(tps, reg, data);
+	err = tps6507x_pmic_write(tps, reg, data);
 	if (err)
 		dev_err(&tps->client->dev, "Write for reg 0x%x failed\n", reg);
 
@@ -144,13 +144,13 @@ out:
 	return err;
 }
 
-static int tps_6507x_clear_bits(struct tps_pmic *tps, u8 reg, u8 mask)
+static int tps6507x_pmic_clear_bits(struct tps6507x_pmic *tps, u8 reg, u8 mask)
 {
 	int err, data;
 
 	mutex_lock(&tps->io_lock);
 
-	data = tps_6507x_read(tps, reg);
+	data = tps6507x_pmic_read(tps, reg);
 	if (data < 0) {
 		dev_err(&tps->client->dev, "Read from reg 0x%x failed\n", reg);
 		err = data;
@@ -158,7 +158,7 @@ static int tps_6507x_clear_bits(struct tps_pmic *tps, u8 reg, u8 mask)
 	}
 
 	data &= ~mask;
-	err = tps_6507x_write(tps, reg, data);
+	err = tps6507x_pmic_write(tps, reg, data);
 	if (err)
 		dev_err(&tps->client->dev, "Write for reg 0x%x failed\n", reg);
 
@@ -167,13 +167,13 @@ out:
 	return err;
 }
 
-static int tps_6507x_reg_read(struct tps_pmic *tps, u8 reg)
+static int tps6507x_pmic_reg_read(struct tps6507x_pmic *tps, u8 reg)
 {
 	int data;
 
 	mutex_lock(&tps->io_lock);
 
-	data = tps_6507x_read(tps, reg);
+	data = tps6507x_pmic_read(tps, reg);
 	if (data < 0)
 		dev_err(&tps->client->dev, "Read from reg 0x%x failed\n", reg);
 
@@ -181,13 +181,13 @@ static int tps_6507x_reg_read(struct tps_pmic *tps, u8 reg)
 	return data;
 }
 
-static int tps_6507x_reg_write(struct tps_pmic *tps, u8 reg, u8 val)
+static int tps6507x_pmic_reg_write(struct tps6507x_pmic *tps, u8 reg, u8 val)
 {
 	int err;
 
 	mutex_lock(&tps->io_lock);
 
-	err = tps_6507x_write(tps, reg, val);
+	err = tps6507x_pmic_write(tps, reg, val);
 	if (err < 0)
 		dev_err(&tps->client->dev, "Write for reg 0x%x failed\n", reg);
 
@@ -195,9 +195,9 @@ static int tps_6507x_reg_write(struct tps_pmic *tps, u8 reg, u8 val)
 	return err;
 }
 
-static int tps6507x_dcdc_is_enabled(struct regulator_dev *dev)
+static int tps6507x_pmic_dcdc_is_enabled(struct regulator_dev *dev)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int data, dcdc = rdev_get_id(dev);
 	u8 shift;
 
@@ -205,7 +205,7 @@ static int tps6507x_dcdc_is_enabled(struct regulator_dev *dev)
 		return -EINVAL;
 
 	shift = TPS6507X_MAX_REG_ID - dcdc;
-	data = tps_6507x_reg_read(tps, TPS6507X_REG_CON_CTRL1);
+	data = tps6507x_pmic_reg_read(tps, TPS6507X_REG_CON_CTRL1);
 
 	if (data < 0)
 		return data;
@@ -213,9 +213,9 @@ static int tps6507x_dcdc_is_enabled(struct regulator_dev *dev)
 		return (data & 1<<shift) ? 1 : 0;
 }
 
-static int tps6507x_ldo_is_enabled(struct regulator_dev *dev)
+static int tps6507x_pmic_ldo_is_enabled(struct regulator_dev *dev)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int data, ldo = rdev_get_id(dev);
 	u8 shift;
 
@@ -223,7 +223,7 @@ static int tps6507x_ldo_is_enabled(struct regulator_dev *dev)
 		return -EINVAL;
 
 	shift = TPS6507X_MAX_REG_ID - ldo;
-	data = tps_6507x_reg_read(tps, TPS6507X_REG_CON_CTRL1);
+	data = tps6507x_pmic_reg_read(tps, TPS6507X_REG_CON_CTRL1);
 
 	if (data < 0)
 		return data;
@@ -231,9 +231,9 @@ static int tps6507x_ldo_is_enabled(struct regulator_dev *dev)
 		return (data & 1<<shift) ? 1 : 0;
 }
 
-static int tps6507x_dcdc_enable(struct regulator_dev *dev)
+static int tps6507x_pmic_dcdc_enable(struct regulator_dev *dev)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int dcdc = rdev_get_id(dev);
 	u8 shift;
 
@@ -241,12 +241,12 @@ static int tps6507x_dcdc_enable(struct regulator_dev *dev)
 		return -EINVAL;
 
 	shift = TPS6507X_MAX_REG_ID - dcdc;
-	return tps_6507x_set_bits(tps, TPS6507X_REG_CON_CTRL1, 1 << shift);
+	return tps6507x_pmic_set_bits(tps, TPS6507X_REG_CON_CTRL1, 1 << shift);
 }
 
-static int tps6507x_dcdc_disable(struct regulator_dev *dev)
+static int tps6507x_pmic_dcdc_disable(struct regulator_dev *dev)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int dcdc = rdev_get_id(dev);
 	u8 shift;
 
@@ -254,12 +254,13 @@ static int tps6507x_dcdc_disable(struct regulator_dev *dev)
 		return -EINVAL;
 
 	shift = TPS6507X_MAX_REG_ID - dcdc;
-	return tps_6507x_clear_bits(tps, TPS6507X_REG_CON_CTRL1, 1 << shift);
+	return tps6507x_pmic_clear_bits(tps, TPS6507X_REG_CON_CTRL1,
+					1 << shift);
 }
 
-static int tps6507x_ldo_enable(struct regulator_dev *dev)
+static int tps6507x_pmic_ldo_enable(struct regulator_dev *dev)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int ldo = rdev_get_id(dev);
 	u8 shift;
 
@@ -267,12 +268,12 @@ static int tps6507x_ldo_enable(struct regulator_dev *dev)
 		return -EINVAL;
 
 	shift = TPS6507X_MAX_REG_ID - ldo;
-	return tps_6507x_set_bits(tps, TPS6507X_REG_CON_CTRL1, 1 << shift);
+	return tps6507x_pmic_set_bits(tps, TPS6507X_REG_CON_CTRL1, 1 << shift);
 }
 
-static int tps6507x_ldo_disable(struct regulator_dev *dev)
+static int tps6507x_pmic_ldo_disable(struct regulator_dev *dev)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int ldo = rdev_get_id(dev);
 	u8 shift;
 
@@ -280,12 +281,13 @@ static int tps6507x_ldo_disable(struct regulator_dev *dev)
 		return -EINVAL;
 
 	shift = TPS6507X_MAX_REG_ID - ldo;
-	return tps_6507x_clear_bits(tps, TPS6507X_REG_CON_CTRL1, 1 << shift);
+	return tps6507x_pmic_clear_bits(tps, TPS6507X_REG_CON_CTRL1,
+					1 << shift);
 }
 
-static int tps6507x_dcdc_get_voltage(struct regulator_dev *dev)
+static int tps6507x_pmic_dcdc_get_voltage(struct regulator_dev *dev)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int data, dcdc = rdev_get_id(dev);
 	u8 reg;
 
@@ -303,7 +305,7 @@ static int tps6507x_dcdc_get_voltage(struct regulator_dev *dev)
 		return -EINVAL;
 	}
 
-	data = tps_6507x_reg_read(tps, reg);
+	data = tps6507x_pmic_reg_read(tps, reg);
 	if (data < 0)
 		return data;
 
@@ -311,10 +313,10 @@ static int tps6507x_dcdc_get_voltage(struct regulator_dev *dev)
 	return tps->info[dcdc]->table[data] * 1000;
 }
 
-static int tps6507x_dcdc_set_voltage(struct regulator_dev *dev,
+static int tps6507x_pmic_dcdc_set_voltage(struct regulator_dev *dev,
 				int min_uV, int max_uV)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int data, vsel, dcdc = rdev_get_id(dev);
 	u8 reg;
 
@@ -352,19 +354,19 @@ static int tps6507x_dcdc_set_voltage(struct regulator_dev *dev,
 	if (vsel == tps->info[dcdc]->table_len)
 		return -EINVAL;
 
-	data = tps_6507x_reg_read(tps, reg);
+	data = tps6507x_pmic_reg_read(tps, reg);
 	if (data < 0)
 		return data;
 
 	data &= ~TPS6507X_DEFDCDCX_DCDC_MASK;
 	data |= vsel;
 
-	return tps_6507x_reg_write(tps, reg, data);
+	return tps6507x_pmic_reg_write(tps, reg, data);
 }
 
-static int tps6507x_ldo_get_voltage(struct regulator_dev *dev)
+static int tps6507x_pmic_ldo_get_voltage(struct regulator_dev *dev)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int data, ldo = rdev_get_id(dev);
 	u8 reg, mask;
 
@@ -378,7 +380,7 @@ static int tps6507x_ldo_get_voltage(struct regulator_dev *dev)
 				TPS6507X_REG_DEFLDO2_LDO2_MASK);
 	}
 
-	data = tps_6507x_reg_read(tps, reg);
+	data = tps6507x_pmic_reg_read(tps, reg);
 	if (data < 0)
 		return data;
 
@@ -386,10 +388,10 @@ static int tps6507x_ldo_get_voltage(struct regulator_dev *dev)
 	return tps->info[ldo]->table[data] * 1000;
 }
 
-static int tps6507x_ldo_set_voltage(struct regulator_dev *dev,
+static int tps6507x_pmic_ldo_set_voltage(struct regulator_dev *dev,
 				int min_uV, int max_uV)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int data, vsel, ldo = rdev_get_id(dev);
 	u8 reg, mask;
 
@@ -420,20 +422,20 @@ static int tps6507x_ldo_set_voltage(struct regulator_dev *dev,
 	if (vsel == tps->info[ldo]->table_len)
 		return -EINVAL;
 
-	data = tps_6507x_reg_read(tps, reg);
+	data = tps6507x_pmic_reg_read(tps, reg);
 	if (data < 0)
 		return data;
 
 	data &= ~mask;
 	data |= vsel;
 
-	return tps_6507x_reg_write(tps, reg, data);
+	return tps6507x_pmic_reg_write(tps, reg, data);
 }
 
-static int tps6507x_dcdc_list_voltage(struct regulator_dev *dev,
+static int tps6507x_pmic_dcdc_list_voltage(struct regulator_dev *dev,
 					unsigned selector)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int dcdc = rdev_get_id(dev);
 
 	if (dcdc < TPS6507X_DCDC_1 || dcdc > TPS6507X_DCDC_3)
@@ -445,10 +447,10 @@ static int tps6507x_dcdc_list_voltage(struct regulator_dev *dev,
 		return tps->info[dcdc]->table[selector] * 1000;
 }
 
-static int tps6507x_ldo_list_voltage(struct regulator_dev *dev,
+static int tps6507x_pmic_ldo_list_voltage(struct regulator_dev *dev,
 					unsigned selector)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int ldo = rdev_get_id(dev);
 
 	if (ldo < TPS6507X_LDO_1 || ldo > TPS6507X_LDO_2)
@@ -461,33 +463,33 @@ static int tps6507x_ldo_list_voltage(struct regulator_dev *dev,
 }
 
 /* Operations permitted on VDCDCx */
-static struct regulator_ops tps6507x_dcdc_ops = {
-	.is_enabled = tps6507x_dcdc_is_enabled,
-	.enable = tps6507x_dcdc_enable,
-	.disable = tps6507x_dcdc_disable,
-	.get_voltage = tps6507x_dcdc_get_voltage,
-	.set_voltage = tps6507x_dcdc_set_voltage,
-	.list_voltage = tps6507x_dcdc_list_voltage,
+static struct regulator_ops tps6507x_pmic_dcdc_ops = {
+	.is_enabled = tps6507x_pmic_dcdc_is_enabled,
+	.enable = tps6507x_pmic_dcdc_enable,
+	.disable = tps6507x_pmic_dcdc_disable,
+	.get_voltage = tps6507x_pmic_dcdc_get_voltage,
+	.set_voltage = tps6507x_pmic_dcdc_set_voltage,
+	.list_voltage = tps6507x_pmic_dcdc_list_voltage,
 };
 
 /* Operations permitted on LDOx */
-static struct regulator_ops tps6507x_ldo_ops = {
-	.is_enabled = tps6507x_ldo_is_enabled,
-	.enable = tps6507x_ldo_enable,
-	.disable = tps6507x_ldo_disable,
-	.get_voltage = tps6507x_ldo_get_voltage,
-	.set_voltage = tps6507x_ldo_set_voltage,
-	.list_voltage = tps6507x_ldo_list_voltage,
+static struct regulator_ops tps6507x_pmic_ldo_ops = {
+	.is_enabled = tps6507x_pmic_ldo_is_enabled,
+	.enable = tps6507x_pmic_ldo_enable,
+	.disable = tps6507x_pmic_ldo_disable,
+	.get_voltage = tps6507x_pmic_ldo_get_voltage,
+	.set_voltage = tps6507x_pmic_ldo_set_voltage,
+	.list_voltage = tps6507x_pmic_ldo_list_voltage,
 };
 
-static int __devinit tps_6507x_probe(struct i2c_client *client,
+static int __devinit tps6507x_pmic_probe(struct i2c_client *client,
 				     const struct i2c_device_id *id)
 {
 	static int desc_id;
 	const struct tps_info *info = (void *)id->driver_data;
 	struct regulator_init_data *init_data;
 	struct regulator_dev *rdev;
-	struct tps_pmic *tps;
+	struct tps6507x_pmic *tps;
 	struct tps6507x_board *tps_board;
 	int i;
 	int error;
@@ -529,7 +531,7 @@ static int __devinit tps_6507x_probe(struct i2c_client *client,
 		tps->desc[i].id = desc_id++;
 		tps->desc[i].n_voltages = num_voltages[i];
 		tps->desc[i].ops = (i > TPS6507X_DCDC_3 ?
-				&tps6507x_ldo_ops : &tps6507x_dcdc_ops);
+		&tps6507x_pmic_ldo_ops : &tps6507x_pmic_dcdc_ops);
 		tps->desc[i].type = REGULATOR_VOLTAGE;
 		tps->desc[i].owner = THIS_MODULE;
 
@@ -559,14 +561,14 @@ fail:
 }
 
 /**
- * tps_6507x_remove - TPS6507x driver i2c remove handler
+ * tps6507x_remove - TPS6507x driver i2c remove handler
  * @client: i2c driver client device structure
  *
  * Unregister TPS driver as an i2c client device driver
  */
-static int __devexit tps_6507x_remove(struct i2c_client *client)
+static int __devexit tps6507x_pmic_remove(struct i2c_client *client)
 {
-	struct tps_pmic *tps = i2c_get_clientdata(client);
+	struct tps6507x_pmic *tps = i2c_get_clientdata(client);
 	int i;
 
 	/* clear the client data in i2c */
@@ -580,7 +582,7 @@ static int __devexit tps_6507x_remove(struct i2c_client *client)
 	return 0;
 }
 
-static const struct tps_info tps6507x_regs[] = {
+static const struct tps_info tps6507x_pmic_regs[] = {
 	{
 		.name = "VDCDC1",
 		.min_uV = 725000,
@@ -618,44 +620,44 @@ static const struct tps_info tps6507x_regs[] = {
 	},
 };
 
-static const struct i2c_device_id tps_6507x_id[] = {
+static const struct i2c_device_id tps6507x_pmic_id[] = {
 	{.name = "tps6507x",
-	.driver_data = (unsigned long) tps6507x_regs,},
+	.driver_data = (unsigned long) tps6507x_pmic_regs,},
 	{ },
 };
-MODULE_DEVICE_TABLE(i2c, tps_6507x_id);
+MODULE_DEVICE_TABLE(i2c, tps6507x_pmic_id);
 
-static struct i2c_driver tps_6507x_i2c_driver = {
+static struct i2c_driver tps6507x_i2c_driver = {
 	.driver = {
 		.name = "tps6507x",
 		.owner = THIS_MODULE,
 	},
-	.probe = tps_6507x_probe,
-	.remove = __devexit_p(tps_6507x_remove),
-	.id_table = tps_6507x_id,
+	.probe = tps6507x_pmic_probe,
+	.remove = __devexit_p(tps6507x_pmic_remove),
+	.id_table = tps6507x_pmic_id,
 };
 
 /**
- * tps_6507x_init
+ * tps6507x_pmic_init
  *
  * Module init function
  */
-static int __init tps_6507x_init(void)
+static int __init tps6507x_pmic_init(void)
 {
-	return i2c_add_driver(&tps_6507x_i2c_driver);
+	return i2c_add_driver(&tps6507x_i2c_driver);
 }
-subsys_initcall(tps_6507x_init);
+subsys_initcall(tps6507x_pmic_init);
 
 /**
- * tps_6507x_cleanup
+ * tps6507x_pmic_cleanup
  *
  * Module exit function
  */
-static void __exit tps_6507x_cleanup(void)
+static void __exit tps6507x_pmic_cleanup(void)
 {
-	i2c_del_driver(&tps_6507x_i2c_driver);
+	i2c_del_driver(&tps6507x_i2c_driver);
 }
-module_exit(tps_6507x_cleanup);
+module_exit(tps6507x_pmic_cleanup);
 
 MODULE_AUTHOR("Texas Instruments");
 MODULE_DESCRIPTION("TPS6507x voltage regulator driver");
-- 
1.6.0.4


From todd.fischer at ridgerun.com  Fri Apr  2 15:37:33 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Fri,  2 Apr 2010 15:37:33 -0600
Subject: [PATCH 4/4]-V2 Add MFD driver for TPS6507x family of multi-function
	chips and move TPS6507x regulator driver from being stand-alone
	to using the MFD driver.
In-Reply-To: <1270244253-4234-4-git-send-email-todd.fischer@ridgerun.com>
References: <1270244253-4234-1-git-send-email-todd.fischer@ridgerun.com>
	<1270244253-4234-2-git-send-email-todd.fischer@ridgerun.com>
	<1270244253-4234-3-git-send-email-todd.fischer@ridgerun.com>
	<1270244253-4234-4-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <1270244253-4234-5-git-send-email-todd.fischer@ridgerun.com>

Add MFD driver for TPS6507x family of multi-function chips.  Move TPS6507x 
regulator driver from being stand-alone driver to using the MFD TPS6507x driver.

Signed-off-by: Todd Fischer <todd.fischer at ridgerun.com>
---
 drivers/mfd/Kconfig                    |   12 +++
 drivers/mfd/Makefile                   |    3 +-
 drivers/mfd/tps6507x.c                 |  145 ++++++++++++++++++++++++++++++
 drivers/regulator/tps6507x-regulator.c |  153 +++++++++++++++----------------
 include/linux/mfd/tps6507x.h           |   22 +++++
 5 files changed, 255 insertions(+), 80 deletions(-)
 create mode 100644 drivers/mfd/tps6507x.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2a5a0b7..1e301ad 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -111,6 +111,18 @@ config TPS65010
 	  This driver can also be built as a module.  If so, the module
 	  will be called tps65010.
 
+config TPS6507X
+	tristate "TPS6507x Power Management / Touch Screen chips"
+	select MFD_CORE
+	depends on I2C
+	help
+	  If you say yes here you get support for the TPS6507x series of
+	  Power Management / Touch Screen chips.  These include voltage
+	  regulators, lithium ion/polymer battery charging, touch screen
+	  and other features that are often used in portable devices.
+	  This driver can also be built as a module.  If so, the module
+	  will be called tps6507x.
+
 config MENELAUS
 	bool "Texas Instruments TWL92330/Menelaus PM chip"
 	depends on I2C=y && ARCH_OMAP2
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 22715ad..2bebc95 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_MFD_WM8350_I2C)	+= wm8350-i2c.o
 obj-$(CONFIG_MFD_WM8994)	+= wm8994-core.o
 
 obj-$(CONFIG_TPS65010)		+= tps65010.o
+obj-$(CONFIG_TPS6507X)		+= tps6507x.o
 obj-$(CONFIG_MENELAUS)		+= menelaus.o
 
 obj-$(CONFIG_TWL4030_CORE)	+= twl-core.o twl4030-irq.o twl6030-irq.o
@@ -62,4 +63,4 @@ obj-$(CONFIG_AB3100_OTP)	+= ab3100-otp.o
 obj-$(CONFIG_AB4500_CORE)	+= ab4500-core.o
 obj-$(CONFIG_MFD_TIMBERDALE)    += timberdale.o
 obj-$(CONFIG_PMIC_ADP5520)	+= adp5520.o
-obj-$(CONFIG_LPC_SCH)		+= lpc_sch.o
\ No newline at end of file
+obj-$(CONFIG_LPC_SCH)		+= lpc_sch.o
diff --git a/drivers/mfd/tps6507x.c b/drivers/mfd/tps6507x.c
new file mode 100644
index 0000000..edda9ff
--- /dev/null
+++ b/drivers/mfd/tps6507x.c
@@ -0,0 +1,145 @@
+/*
+ * tps6507x.c  --  TPS6507x chip family multi-function driver
+ *
+ *  Copyright (c) 2010 RidgeRun (todd.fischer at ridgerun.com)
+ *
+ * Author: Todd Fischer
+ *         todd.fischer at ridgerun.com
+ *
+ * Credits:
+ *
+ *    Using code from wm831x-*.c, Wolfson Microelectronics PLC.
+ *
+ * For licencing details see kernel-base/COPYING
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/init.h>
+#include <linux/i2c.h>
+#include <linux/mfd/core.h>
+#include <linux/mfd/tps6507x.h>
+
+static struct mfd_cell tps6507x_devs[] = {
+	{
+		.name = "tps6507x-pmic",
+	},
+};
+
+
+static int tps6507x_i2c_read_device(struct tps6507x_dev *tps6507x, char reg,
+				  int bytes, void *dest)
+{
+	struct i2c_client *i2c = tps6507x->i2c_client;
+	int ret;
+
+	ret = i2c_master_send(i2c, &reg, 1);
+	if (ret < 0)
+		return ret;
+
+	ret = i2c_master_recv(i2c, dest, bytes);
+	if (ret < 0)
+		return ret;
+	if (ret != bytes)
+		return -EIO;
+	return 0;
+}
+
+static int tps6507x_i2c_write_device(struct tps6507x_dev *tps6507x, char reg,
+				   int bytes, void *src)
+{
+	struct i2c_client *i2c = tps6507x->i2c_client;
+	/* we add 1 byte for device register */
+	u8 msg[(TPS6507X_MAX_REGISTER << 1) + 1];
+	int ret;
+
+	if (bytes > ((TPS6507X_MAX_REGISTER << 1) + 1))
+		return -EINVAL;
+
+	msg[0] = reg;
+	memcpy(&msg[1], src, bytes);
+
+	ret = i2c_master_send(i2c, msg, bytes + 1);
+	if (ret < 0)
+		return ret;
+	if (ret != bytes + 1)
+		return -EIO;
+	return 0;
+}
+
+static int tps6507x_i2c_probe(struct i2c_client *i2c,
+			    const struct i2c_device_id *id)
+{
+	struct tps6507x_dev *tps6507x;
+	int ret = 0;
+
+	tps6507x = kzalloc(sizeof(struct tps6507x_dev), GFP_KERNEL);
+	if (tps6507x == NULL) {
+		kfree(i2c);
+		return -ENOMEM;
+	}
+
+	i2c_set_clientdata(i2c, tps6507x);
+	tps6507x->dev = &i2c->dev;
+	tps6507x->i2c_client = i2c;
+	tps6507x->read_dev = tps6507x_i2c_read_device;
+	tps6507x->write_dev = tps6507x_i2c_write_device;
+
+	ret = mfd_add_devices(tps6507x->dev, -1,
+			      tps6507x_devs, ARRAY_SIZE(tps6507x_devs),
+			      NULL, 0);
+
+	if (ret < 0)
+		goto err;
+
+	return ret;
+
+err:
+	mfd_remove_devices(tps6507x->dev);
+	kfree(tps6507x);
+	return ret;
+}
+
+static int tps6507x_i2c_remove(struct i2c_client *i2c)
+{
+	struct tps6507x_dev *tps6507x = i2c_get_clientdata(i2c);
+
+	mfd_remove_devices(tps6507x->dev);
+	kfree(tps6507x);
+
+	return 0;
+}
+
+static const struct i2c_device_id tps6507x_i2c_id[] = {
+       { "tps6507x", 0 },
+       { }
+};
+MODULE_DEVICE_TABLE(i2c, tps6507x_i2c_id);
+
+
+static struct i2c_driver tps6507x_i2c_driver = {
+	.driver = {
+		   .name = "tps6507x",
+		   .owner = THIS_MODULE,
+	},
+	.probe = tps6507x_i2c_probe,
+	.remove = tps6507x_i2c_remove,
+	.id_table = tps6507x_i2c_id,
+};
+
+static int __init tps6507x_i2c_init(void)
+{
+	return i2c_add_driver(&tps6507x_i2c_driver);
+}
+/* init early so consumer devices can complete system boot */
+subsys_initcall(tps6507x_i2c_init);
+
+static void __exit tps6507x_i2c_exit(void)
+{
+	i2c_del_driver(&tps6507x_i2c_driver);
+}
+module_exit(tps6507x_i2c_exit);
+
+MODULE_DESCRIPTION("TPS6507x chip family multi-function driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/regulator/tps6507x-regulator.c b/drivers/regulator/tps6507x-regulator.c
index 86f2e05..e4d7d2f 100644
--- a/drivers/regulator/tps6507x-regulator.c
+++ b/drivers/regulator/tps6507x-regulator.c
@@ -22,7 +22,6 @@
 #include <linux/platform_device.h>
 #include <linux/regulator/driver.h>
 #include <linux/regulator/machine.h>
-#include <linux/i2c.h>
 #include <linux/delay.h>
 #include <linux/mfd/tps6507x.h>
 
@@ -103,22 +102,67 @@ struct tps_info {
 	const u16 *table;
 };
 
+static const struct tps_info tps6507x_pmic_regs[] = {
+	{
+		.name = "VDCDC1",
+		.min_uV = 725000,
+		.max_uV = 3300000,
+		.table_len = ARRAY_SIZE(VDCDCx_VSEL_table),
+		.table = VDCDCx_VSEL_table,
+	},
+	{
+		.name = "VDCDC2",
+		.min_uV = 725000,
+		.max_uV = 3300000,
+		.table_len = ARRAY_SIZE(VDCDCx_VSEL_table),
+		.table = VDCDCx_VSEL_table,
+	},
+	{
+		.name = "VDCDC3",
+		.min_uV = 725000,
+		.max_uV = 3300000,
+		.table_len = ARRAY_SIZE(VDCDCx_VSEL_table),
+		.table = VDCDCx_VSEL_table,
+	},
+	{
+		.name = "LDO1",
+		.min_uV = 1000000,
+		.max_uV = 3300000,
+		.table_len = ARRAY_SIZE(LDO1_VSEL_table),
+		.table = LDO1_VSEL_table,
+	},
+	{
+		.name = "LDO2",
+		.min_uV = 725000,
+		.max_uV = 3300000,
+		.table_len = ARRAY_SIZE(LDO2_VSEL_table),
+		.table = LDO2_VSEL_table,
+	},
+};
+
 struct tps6507x_pmic {
 	struct regulator_desc desc[TPS6507X_NUM_REGULATOR];
-	struct i2c_client *client;
+	struct tps6507x_dev *mfd;
 	struct regulator_dev *rdev[TPS6507X_NUM_REGULATOR];
 	const struct tps_info *info[TPS6507X_NUM_REGULATOR];
 	struct mutex io_lock;
 };
-
 static inline int tps6507x_pmic_read(struct tps6507x_pmic *tps, u8 reg)
 {
-	return i2c_smbus_read_byte_data(tps->client, reg);
+	u8 val;
+	int err;
+
+	err = tps->mfd->read_dev(tps->mfd, reg, 1, &val);
+
+	if (err)
+		return err;
+
+	return val;
 }
 
 static inline int tps6507x_pmic_write(struct tps6507x_pmic *tps, u8 reg, u8 val)
 {
-	return i2c_smbus_write_byte_data(tps->client, reg, val);
+	return tps->mfd->write_dev(tps->mfd, reg, 1, &val);
 }
 
 static int tps6507x_pmic_set_bits(struct tps6507x_pmic *tps, u8 reg, u8 mask)
@@ -129,7 +173,7 @@ static int tps6507x_pmic_set_bits(struct tps6507x_pmic *tps, u8 reg, u8 mask)
 
 	data = tps6507x_pmic_read(tps, reg);
 	if (data < 0) {
-		dev_err(&tps->client->dev, "Read from reg 0x%x failed\n", reg);
+		dev_err(tps->mfd->dev, "Read from reg 0x%x failed\n", reg);
 		err = data;
 		goto out;
 	}
@@ -137,7 +181,7 @@ static int tps6507x_pmic_set_bits(struct tps6507x_pmic *tps, u8 reg, u8 mask)
 	data |= mask;
 	err = tps6507x_pmic_write(tps, reg, data);
 	if (err)
-		dev_err(&tps->client->dev, "Write for reg 0x%x failed\n", reg);
+		dev_err(tps->mfd->dev, "Write for reg 0x%x failed\n", reg);
 
 out:
 	mutex_unlock(&tps->io_lock);
@@ -152,7 +196,7 @@ static int tps6507x_pmic_clear_bits(struct tps6507x_pmic *tps, u8 reg, u8 mask)
 
 	data = tps6507x_pmic_read(tps, reg);
 	if (data < 0) {
-		dev_err(&tps->client->dev, "Read from reg 0x%x failed\n", reg);
+		dev_err(tps->mfd->dev, "Read from reg 0x%x failed\n", reg);
 		err = data;
 		goto out;
 	}
@@ -160,7 +204,7 @@ static int tps6507x_pmic_clear_bits(struct tps6507x_pmic *tps, u8 reg, u8 mask)
 	data &= ~mask;
 	err = tps6507x_pmic_write(tps, reg, data);
 	if (err)
-		dev_err(&tps->client->dev, "Write for reg 0x%x failed\n", reg);
+		dev_err(tps->mfd->dev, "Write for reg 0x%x failed\n", reg);
 
 out:
 	mutex_unlock(&tps->io_lock);
@@ -175,7 +219,7 @@ static int tps6507x_pmic_reg_read(struct tps6507x_pmic *tps, u8 reg)
 
 	data = tps6507x_pmic_read(tps, reg);
 	if (data < 0)
-		dev_err(&tps->client->dev, "Read from reg 0x%x failed\n", reg);
+		dev_err(tps->mfd->dev, "Read from reg 0x%x failed\n", reg);
 
 	mutex_unlock(&tps->io_lock);
 	return data;
@@ -189,7 +233,7 @@ static int tps6507x_pmic_reg_write(struct tps6507x_pmic *tps, u8 reg, u8 val)
 
 	err = tps6507x_pmic_write(tps, reg, val);
 	if (err < 0)
-		dev_err(&tps->client->dev, "Write for reg 0x%x failed\n", reg);
+		dev_err(tps->mfd->dev, "Write for reg 0x%x failed\n", reg);
 
 	mutex_unlock(&tps->io_lock);
 	return err;
@@ -482,11 +526,12 @@ static struct regulator_ops tps6507x_pmic_ldo_ops = {
 	.list_voltage = tps6507x_pmic_ldo_list_voltage,
 };
 
-static int __devinit tps6507x_pmic_probe(struct i2c_client *client,
-				     const struct i2c_device_id *id)
+static __devinit
+int tps6507x_pmic_probe(struct platform_device *pdev)
 {
+	struct tps6507x_dev *tps6507x_dev = dev_get_drvdata(pdev->dev.parent);
 	static int desc_id;
-	const struct tps_info *info = (void *)id->driver_data;
+	const struct tps_info *info = &tps6507x_pmic_regs[0];
 	struct regulator_init_data *init_data;
 	struct regulator_dev *rdev;
 	struct tps6507x_pmic *tps;
@@ -494,16 +539,12 @@ static int __devinit tps6507x_pmic_probe(struct i2c_client *client,
 	int i;
 	int error;
 
-	if (!i2c_check_functionality(client->adapter,
-				I2C_FUNC_SMBUS_BYTE_DATA))
-		return -EIO;
-
 	/**
 	 * tps_board points to pmic related constants
 	 * coming from the board-evm file.
 	 */
 
-	tps_board = dev_get_platdata(&client->dev);
+	tps_board = dev_get_platdata(tps6507x_dev->dev);
 	if (!tps_board)
 		return -EINVAL;
 
@@ -522,7 +563,7 @@ static int __devinit tps6507x_pmic_probe(struct i2c_client *client,
 	mutex_init(&tps->io_lock);
 
 	/* common for all regulators */
-	tps->client = client;
+	tps->mfd = tps6507x_dev;
 
 	for (i = 0; i < TPS6507X_NUM_REGULATOR; i++, info++, init_data++) {
 		/* Register the regulators */
@@ -536,10 +577,11 @@ static int __devinit tps6507x_pmic_probe(struct i2c_client *client,
 		tps->desc[i].owner = THIS_MODULE;
 
 		rdev = regulator_register(&tps->desc[i],
-					&client->dev, init_data, tps);
+					tps6507x_dev->dev, init_data, tps);
 		if (IS_ERR(rdev)) {
-			dev_err(&client->dev, "failed to register %s\n",
-				id->name);
+			dev_err(tps6507x_dev->dev,
+				"failed to register %s regulator\n",
+				pdev->name);
 			error = PTR_ERR(rdev);
 			goto fail;
 		}
@@ -548,7 +590,7 @@ static int __devinit tps6507x_pmic_probe(struct i2c_client *client,
 		tps->rdev[i] = rdev;
 	}
 
-	i2c_set_clientdata(client, tps);
+	tps6507x_dev->pmic = tps;
 
 	return 0;
 
@@ -566,14 +608,12 @@ fail:
  *
  * Unregister TPS driver as an i2c client device driver
  */
-static int __devexit tps6507x_pmic_remove(struct i2c_client *client)
+static int __devexit tps6507x_pmic_remove(struct platform_device *pdev)
 {
-	struct tps6507x_pmic *tps = i2c_get_clientdata(client);
+	struct tps6507x_dev *tps6507x_dev = platform_get_drvdata(pdev);
+	struct tps6507x_pmic *tps = tps6507x_dev->pmic;
 	int i;
 
-	/* clear the client data in i2c */
-	i2c_set_clientdata(client, NULL);
-
 	for (i = 0; i < TPS6507X_NUM_REGULATOR; i++)
 		regulator_unregister(tps->rdev[i]);
 
@@ -582,59 +622,13 @@ static int __devexit tps6507x_pmic_remove(struct i2c_client *client)
 	return 0;
 }
 
-static const struct tps_info tps6507x_pmic_regs[] = {
-	{
-		.name = "VDCDC1",
-		.min_uV = 725000,
-		.max_uV = 3300000,
-		.table_len = ARRAY_SIZE(VDCDCx_VSEL_table),
-		.table = VDCDCx_VSEL_table,
-	},
-	{
-		.name = "VDCDC2",
-		.min_uV = 725000,
-		.max_uV = 3300000,
-		.table_len = ARRAY_SIZE(VDCDCx_VSEL_table),
-		.table = VDCDCx_VSEL_table,
-	},
-	{
-		.name = "VDCDC3",
-		.min_uV = 725000,
-		.max_uV = 3300000,
-		.table_len = ARRAY_SIZE(VDCDCx_VSEL_table),
-		.table = VDCDCx_VSEL_table,
-	},
-	{
-		.name = "LDO1",
-		.min_uV = 1000000,
-		.max_uV = 3300000,
-		.table_len = ARRAY_SIZE(LDO1_VSEL_table),
-		.table = LDO1_VSEL_table,
-	},
-	{
-		.name = "LDO2",
-		.min_uV = 725000,
-		.max_uV = 3300000,
-		.table_len = ARRAY_SIZE(LDO2_VSEL_table),
-		.table = LDO2_VSEL_table,
-	},
-};
-
-static const struct i2c_device_id tps6507x_pmic_id[] = {
-	{.name = "tps6507x",
-	.driver_data = (unsigned long) tps6507x_pmic_regs,},
-	{ },
-};
-MODULE_DEVICE_TABLE(i2c, tps6507x_pmic_id);
-
-static struct i2c_driver tps6507x_i2c_driver = {
+static struct platform_driver tps6507x_pmic_driver = {
 	.driver = {
-		.name = "tps6507x",
+		.name = "tps6507x-pmic",
 		.owner = THIS_MODULE,
 	},
 	.probe = tps6507x_pmic_probe,
 	.remove = __devexit_p(tps6507x_pmic_remove),
-	.id_table = tps6507x_pmic_id,
 };
 
 /**
@@ -644,7 +638,7 @@ static struct i2c_driver tps6507x_i2c_driver = {
  */
 static int __init tps6507x_pmic_init(void)
 {
-	return i2c_add_driver(&tps6507x_i2c_driver);
+	return platform_driver_register(&tps6507x_pmic_driver);
 }
 subsys_initcall(tps6507x_pmic_init);
 
@@ -655,10 +649,11 @@ subsys_initcall(tps6507x_pmic_init);
  */
 static void __exit tps6507x_pmic_cleanup(void)
 {
-	i2c_del_driver(&tps6507x_i2c_driver);
+	platform_driver_unregister(&tps6507x_pmic_driver);
 }
 module_exit(tps6507x_pmic_cleanup);
 
 MODULE_AUTHOR("Texas Instruments");
 MODULE_DESCRIPTION("TPS6507x voltage regulator driver");
 MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:tps6507x-pmic");
diff --git a/include/linux/mfd/tps6507x.h b/include/linux/mfd/tps6507x.h
index fd73af5..9543cb7 100644
--- a/include/linux/mfd/tps6507x.h
+++ b/include/linux/mfd/tps6507x.h
@@ -131,6 +131,8 @@
 /* VDCDC MASK */
 #define TPS6507X_DEFDCDCX_DCDC_MASK		0X3F
 
+#define TPS6507X_MAX_REGISTER			0X19
+
 /**
  * struct tps6507x_board - packages regulator and touchscreen init data
  * @tps6507x_regulator_data: regulator initialization values
@@ -142,4 +144,24 @@ struct tps6507x_board {
 	struct regulator_init_data *tps6507x_pmic_init_data;
 };
 
+/**
+ * struct tps6507x_dev - tps6507x sub-driver chip access routines
+ * @read_dev() - I2C register read function
+ * @write_dev() - I2C register write function
+ *
+ * Device data may be used to access the TPS6507x chip
+ */
+
+struct tps6507x_dev {
+	struct device *dev;
+	struct i2c_client *i2c_client;
+	int (*read_dev)(struct tps6507x_dev *tps6507x, char reg, int size,
+			void *dest);
+	int (*write_dev)(struct tps6507x_dev *tps6507x, char reg, int size,
+			 void *src);
+
+	/* Client devices */
+	struct tps6507x_pmic *pmic;
+};
+
 #endif /*  __LINUX_MFD_TPS6507X_H */
-- 
1.6.0.4


From todd.fischer at ridgerun.com  Sat Apr  3 17:16:40 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Sat,  3 Apr 2010 17:16:40 -0600
Subject: [PATCH] Add touch screen input driver for TPS6507x family of
	multi-function chips.
Message-ID: <1270336600-1664-1-git-send-email-todd.fischer@ridgerun.com>

The TPS6507x family of Texas Instruments power management ICs (pmic)
are multi-function chips that include voltage regulation and touch
screen controller capabilities.  This patch adds a touch screen
input driver for the TPS6507x pmic.  There was an existing regulator
driver.  Before the touch screen driver could be added, a multi-function
device (MFD) driver was needed and the regulator driver modified to
use the MDF driver.  Patches for these changes have been posted and
reviewed.  The TPS6507x touch screen driver applies cleanly to the
MFD GIT repo after the above referenced patches are applied.  If I
should use a different approach for the touch screen driver, please
let me know.

Signed-off-by: Todd Fischer <todd.fischer at ridgerun.com>
---
 arch/arm/mach-davinci/board-da850-evm.c |   12 +
 drivers/input/touchscreen/Kconfig       |   13 +
 drivers/input/touchscreen/Makefile      |    1 +
 drivers/input/touchscreen/tps6507x-ts.c |  400 +++++++++++++++++++++++++++++++
 drivers/mfd/tps6507x.c                  |    3 +
 include/linux/input/tps6507x-ts.h       |   24 ++
 include/linux/mfd/tps6507x.h            |    2 +
 7 files changed, 455 insertions(+), 0 deletions(-)
 create mode 100644 drivers/input/touchscreen/tps6507x-ts.c
 create mode 100644 include/linux/input/tps6507x-ts.h

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index d059924..b3cbb32 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -25,6 +25,8 @@
 #include <linux/mtd/partitions.h>
 #include <linux/mtd/physmap.h>
 #include <linux/regulator/machine.h>
+#include <linux/mfd/tps6507x.h>
+#include <linux/input/tps6507x-ts.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -534,8 +536,18 @@ struct regulator_init_data tps65070_regulator_data[] = {
 	},
 };
 
+static struct touchscreen_init_data tps6507x_touchscreen_data = {
+	.poll_period =  30,	/* ms between touch samples */
+	.min_pressure = 0x30,	/* minimum pressure to trigger touch */
+	.vref = 0,		/* turn off vref when not using A/D */
+	.vendor = 0,		/* /sys/class/input/input?/id/vendor */
+	.product = 65070,	/* /sys/class/input/input?/id/product */
+	.version = 0x100,	/* /sys/class/input/input?/id/version */
+};
+
 static struct tps6507x_board tps_board = {
 	.tps6507x_pmic_init_data = &tps65070_regulator_data[0],
+	.tps6507x_ts_init_data = &tps6507x_touchscreen_data,
 };
 
 static struct i2c_board_info __initdata da850evm_tps65070_info[] = {
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 8a8fa4d..6166aa8 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -594,4 +594,17 @@ config TOUCHSCREEN_PCAP
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called pcap_ts.
+
+config TOUCHSCREEN_TPS6507X
+	tristate "TPS6507x based touchscreens"
+	depends on I2C
+	help
+	  Say Y here if you have a TPS6507x based touchscreen
+	  controller.
+
+	  If unsure, say N.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called tps6507x_ts.
+
 endif
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index 7fef7d5..cfa83d0 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -46,3 +46,4 @@ obj-$(CONFIG_TOUCHSCREEN_WM97XX_ATMEL)	+= atmel-wm97xx.o
 obj-$(CONFIG_TOUCHSCREEN_WM97XX_MAINSTONE)	+= mainstone-wm97xx.o
 obj-$(CONFIG_TOUCHSCREEN_WM97XX_ZYLONITE)	+= zylonite-wm97xx.o
 obj-$(CONFIG_TOUCHSCREEN_W90X900)	+= w90p910_ts.o
+obj-$(CONFIG_TOUCHSCREEN_TPS6507X)	+= tps6507x-ts.o
diff --git a/drivers/input/touchscreen/tps6507x-ts.c b/drivers/input/touchscreen/tps6507x-ts.c
new file mode 100644
index 0000000..5de80a1
--- /dev/null
+++ b/drivers/input/touchscreen/tps6507x-ts.c
@@ -0,0 +1,400 @@
+/*
+ * drivers/input/touchscreen/tps6507x_ts.c
+ *
+ * Touchscreen driver for the tps6507x chip.
+ *
+ * Copyright (c) 2009 RidgeRun (todd.fischer at ridgerun.com)
+ *
+ * Credits:
+ *
+ *    Using code from tsc2007, MtekVision Co., Ltd.
+ *
+ * For licencing details see kernel-base/COPYING
+ *
+ * TPS65070, TPS65073, TPS650731, and TPS650732 support
+ * 10 bit touch screen interface.
+ */
+
+#include <linux/module.h>
+#include <linux/workqueue.h>
+#include <linux/slab.h>
+#include <linux/input.h>
+#include <linux/platform_device.h>
+#include <linux/mfd/tps6507x.h>
+#include <linux/input/tps6507x-ts.h>
+#include <linux/delay.h>
+
+#define TSC_DEFAULT_POLL_PERIOD 30 /* ms */
+#define TPS_DEFAULT_MIN_PRESSURE 0x30
+#define MAX_10BIT ((1 << 10) - 1)
+
+#define	TPS6507X_ADCONFIG_CONVERT_TS (TPS6507X_ADCONFIG_AD_ENABLE | \
+					 TPS6507X_ADCONFIG_START_CONVERSION | \
+					 TPS6507X_ADCONFIG_INPUT_REAL_TSC)
+#define	TPS6507X_ADCONFIG_POWER_DOWN_TS (TPS6507X_ADCONFIG_INPUT_REAL_TSC)
+
+struct ts_event {
+	u16	x;
+	u16	y;
+	u16	pressure;
+};
+
+struct tps6507x_ts {
+	struct input_dev	*input_dev;
+	struct device		*dev;
+	char			phys[32];
+	struct workqueue_struct *wq;
+	struct delayed_work	work;
+	unsigned		polling;	/* polling is active */
+	struct ts_event		tc;
+	struct tps6507x_dev	*mfd;
+	u16			model;
+	unsigned		pendown;
+	int			irq;
+	void			(*clear_penirq)(void);
+	unsigned long		poll_period;	/* ms */
+	u16			min_pressure;
+	int			vref;		/* non-zero to leave vref on */
+};
+
+static int tps6507x_read_u8(struct tps6507x_ts *tsc, u8 reg, u8 *data)
+{
+	int err;
+
+	err = tsc->mfd->read_dev(tsc->mfd, reg, 1, data);
+
+	if (err)
+		return err;
+
+	return 0;
+}
+
+static int tps6507x_write_u8(struct tps6507x_ts *tsc, u8 reg, u8 data)
+{
+	return tsc->mfd->write_dev(tsc->mfd, reg, 1, &data);
+}
+
+static s32 tps6507x_adc_conversion(struct tps6507x_ts *tsc,
+				   u8 tsc_mode, u16 *value)
+{
+	s32 ret;
+	u8 adc_status;
+	u8 result;
+
+	/* Route input signal to A/D converter */
+
+	ret = tps6507x_write_u8(tsc, TPS6507X_REG_TSCMODE, tsc_mode);
+	if (ret) {
+		dev_err(tsc->dev, "TSC mode read failed\n");
+		goto err;
+	}
+
+	/* Start A/D conversion */
+
+	ret = tps6507x_write_u8(tsc, TPS6507X_REG_ADCONFIG,
+				TPS6507X_ADCONFIG_CONVERT_TS);
+	if (ret) {
+		dev_err(tsc->dev, "ADC config write failed\n");
+		return ret;
+	}
+
+	do {
+		ret = tps6507x_read_u8(tsc, TPS6507X_REG_ADCONFIG,
+				       &adc_status);
+		if (ret) {
+			dev_err(tsc->dev, "ADC config read failed\n");
+			goto err;
+		}
+	} while (adc_status & TPS6507X_ADCONFIG_START_CONVERSION);
+
+	ret = tps6507x_read_u8(tsc, TPS6507X_REG_ADRESULT_2, &result);
+	if (ret) {
+		dev_err(tsc->dev, "ADC result 2 read failed\n");
+		goto err;
+	}
+
+	*value = (result & TPS6507X_REG_ADRESULT_2_MASK) << 8;
+
+	ret = tps6507x_read_u8(tsc, TPS6507X_REG_ADRESULT_1, &result);
+	if (ret) {
+		dev_err(tsc->dev, "ADC result 1 read failed\n");
+		goto err;
+	}
+
+	*value |= result;
+
+	dev_dbg(tsc->dev, "TSC channel %d = 0x%X\n", tsc_mode, *value);
+
+err:
+	return ret;
+}
+
+/* Need to call tps6507x_adc_standby() after using A/D converter for the
+ * touch screen interrupt to work properly.
+ */
+
+static s32 tps6507x_adc_standby(struct tps6507x_ts *tsc)
+{
+	s32 ret;
+	s32 loops = 0;
+	u8 val;
+
+	ret = tps6507x_write_u8(tsc,  TPS6507X_REG_ADCONFIG,
+				TPS6507X_ADCONFIG_INPUT_TSC);
+	if (ret)
+		return ret;
+
+	ret = tps6507x_write_u8(tsc, TPS6507X_REG_TSCMODE,
+				TPS6507X_TSCMODE_STANDBY);
+	if (ret)
+		return ret;
+
+	ret = tps6507x_read_u8(tsc, TPS6507X_REG_INT, &val);
+	if (ret)
+		return ret;
+
+	while (val & TPS6507X_REG_TSC_INT) {
+		mdelay(10);
+		ret = tps6507x_read_u8(tsc, TPS6507X_REG_INT, &val);
+		if (ret)
+			return ret;
+		loops++;
+	}
+
+	return ret;
+}
+
+static void tps6507x_ts_handler(struct work_struct *work)
+{
+	struct tps6507x_ts *tsc =  container_of(work,
+				struct tps6507x_ts, work.work);
+	struct input_dev *input_dev = tsc->input_dev;
+	int pendown;
+	int schd;
+	int poll = 0;
+	s32 ret;
+
+	ret =  tps6507x_adc_conversion(tsc, TPS6507X_TSCMODE_PRESSURE,
+				       &tsc->tc.pressure);
+	if (ret)
+		goto done;
+
+	pendown = tsc->tc.pressure > tsc->min_pressure;
+
+	if (unlikely(!pendown && tsc->pendown)) {
+		dev_dbg(tsc->dev, "UP\n");
+		input_report_key(input_dev, BTN_TOUCH, 0);
+		input_report_abs(input_dev, ABS_PRESSURE, 0);
+		input_sync(input_dev);
+		tsc->pendown = 0;
+	}
+
+	if (pendown) {
+
+		if (!tsc->pendown) {
+			dev_dbg(tsc->dev, "DOWN\n");
+			input_report_key(input_dev, BTN_TOUCH, 1);
+		} else
+			dev_dbg(tsc->dev, "still down\n");
+
+		ret =  tps6507x_adc_conversion(tsc, TPS6507X_TSCMODE_X_POSITION,
+					       &tsc->tc.x);
+		if (ret)
+			goto done;
+
+		ret =  tps6507x_adc_conversion(tsc, TPS6507X_TSCMODE_Y_POSITION,
+					       &tsc->tc.y);
+		if (ret)
+			goto done;
+
+		input_report_abs(input_dev, ABS_X, tsc->tc.x);
+		input_report_abs(input_dev, ABS_Y, tsc->tc.y);
+		input_report_abs(input_dev, ABS_PRESSURE, tsc->tc.pressure);
+		input_sync(input_dev);
+		tsc->pendown = 1;
+		poll = 1;
+	}
+
+done:
+	/* always poll if not using interrupts */
+	poll = 1;
+
+	if (poll) {
+		schd = queue_delayed_work(tsc->wq, &tsc->work,
+					  tsc->poll_period * HZ / 1000);
+		if (schd)
+			tsc->polling = 1;
+		else {
+			tsc->polling = 0;
+			dev_err(tsc->dev, "re-schedule failed");
+		}
+	} else
+		tsc->polling = 0;
+
+	ret = tps6507x_adc_standby(tsc);
+}
+
+static int tps6507x_ts_probe(struct platform_device *pdev)
+{
+	int error;
+	struct tps6507x_ts *tsc;
+	struct tps6507x_dev *tps6507x_dev = dev_get_drvdata(pdev->dev.parent);
+	struct touchscreen_init_data *init_data;
+	struct input_dev *input_dev;
+	struct tps6507x_board *tps_board;
+	int schd;
+
+	/**
+	 * tps_board points to pmic related constants
+	 * coming from the board-evm file.
+	 */
+
+	tps_board = (struct tps6507x_board *)tps6507x_dev->dev->platform_data;
+
+	if (!tps_board) {
+		dev_err(tps6507x_dev->dev,
+			"Could not find tps6507x platform data\n");
+		return -EIO;
+	}
+
+	/**
+	 * init_data points to array of regulator_init structures
+	 * coming from the board-evm file.
+	 */
+
+	init_data = tps_board->tps6507x_ts_init_data;
+
+	tsc = kzalloc(sizeof(struct tps6507x_ts), GFP_KERNEL);
+	if (!tsc) {
+		dev_err(tps6507x_dev->dev, "failed to allocate driver data\n");
+		error = -ENOMEM;
+		goto err0;
+	}
+
+	tps6507x_dev->ts = tsc;
+	tsc->mfd = tps6507x_dev;
+	tsc->dev = tps6507x_dev->dev;
+	input_dev = input_allocate_device();
+	if (!input_dev) {
+		dev_err(tsc->dev, "Failed to allocate input device.\n");
+		error = -ENOMEM;
+		goto err1;
+	}
+
+	input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
+	input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
+
+	input_set_abs_params(input_dev, ABS_X, 0, MAX_10BIT, 0, 0);
+	input_set_abs_params(input_dev, ABS_Y, 0, MAX_10BIT, 0, 0);
+	input_set_abs_params(input_dev, ABS_PRESSURE, 0, MAX_10BIT, 0, 0);
+
+	input_dev->name = "TPS6507x Touchscreen";
+	input_dev->id.bustype = BUS_I2C;
+	input_dev->dev.parent = tsc->dev;
+
+	snprintf(tsc->phys, sizeof(tsc->phys),
+		 "%s/input0", dev_name(tsc->dev));
+	input_dev->phys = tsc->phys;
+
+	dev_dbg(tsc->dev, "device: %s\n", input_dev->phys);
+
+	input_set_drvdata(input_dev, tsc);
+
+	tsc->input_dev = input_dev;
+
+	INIT_DELAYED_WORK(&tsc->work, tps6507x_ts_handler);
+	tsc->wq = create_workqueue("TPS6507x Touchscreen");
+
+	if (init_data) {
+		tsc->poll_period = init_data->poll_period;
+		tsc->vref = init_data->vref;
+		tsc->min_pressure = init_data->min_pressure;
+		input_dev->id.vendor = init_data->vendor;
+		input_dev->id.product = init_data->product;
+		input_dev->id.version = init_data->version;
+	} else {
+		tsc->poll_period = TSC_DEFAULT_POLL_PERIOD;
+		tsc->min_pressure = TPS_DEFAULT_MIN_PRESSURE;
+	}
+
+	error = tps6507x_adc_standby(tsc);
+	if (error)
+		goto err2;
+
+	error = input_register_device(input_dev);
+	if (error)
+		goto err2;
+
+	schd = queue_delayed_work(tsc->wq, &tsc->work,
+				  tsc->poll_period * HZ / 1000);
+
+	if (schd)
+		tsc->polling = 1;
+	else {
+		tsc->polling = 0;
+		dev_err(tsc->dev, "schedule failed");
+		goto err2;
+	 }
+
+	return 0;
+
+err2:
+	cancel_delayed_work(&tsc->work);
+	flush_workqueue(tsc->wq);
+	destroy_workqueue(tsc->wq);
+	tsc->wq = 0;
+	input_free_device(input_dev);
+err1:
+	kfree(tsc);
+	tps6507x_dev->ts = NULL;
+err0:
+	return error;
+}
+
+static int __devexit tps6507x_ts_remove(struct platform_device *pdev)
+{
+	struct tps6507x_dev *tps6507x_dev = platform_get_drvdata(pdev);
+	struct tps6507x_ts *tsc = tps6507x_dev->ts;
+	struct input_dev *input_dev = tsc->input_dev;
+
+	if (!tsc)
+		return 0;
+
+	cancel_delayed_work(&tsc->work);
+	flush_workqueue(tsc->wq);
+	destroy_workqueue(tsc->wq);
+	tsc->wq = 0;
+
+	input_free_device(input_dev);
+
+	tps6507x_dev->ts = NULL;
+	kfree(tsc);
+
+	return 0;
+}
+
+static struct platform_driver tps6507x_ts_driver = {
+	.driver = {
+		.name = "tps6507x-ts",
+		.owner = THIS_MODULE,
+	},
+	.probe = tps6507x_ts_probe,
+	.remove = __devexit_p(tps6507x_ts_remove),
+};
+
+static int __init tps6507x_ts_init(void)
+{
+	return platform_driver_register(&tps6507x_ts_driver);
+}
+module_init(tps6507x_ts_init);
+
+static void __exit tps6507x_ts_exit(void)
+{
+	platform_driver_unregister(&tps6507x_ts_driver);
+}
+module_exit(tps6507x_ts_exit);
+
+MODULE_AUTHOR("Todd Fischer <todd.fischer at ridgerun.com>");
+MODULE_DESCRIPTION("TPS6507x - TouchScreen driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:tps6507x-tsc");
diff --git a/drivers/mfd/tps6507x.c b/drivers/mfd/tps6507x.c
index edda9ff..d05c52d 100644
--- a/drivers/mfd/tps6507x.c
+++ b/drivers/mfd/tps6507x.c
@@ -25,6 +25,9 @@ static struct mfd_cell tps6507x_devs[] = {
 	{
 		.name = "tps6507x-pmic",
 	},
+	{
+		.name = "tps6507x-ts",
+	},
 };
 
 
diff --git a/include/linux/input/tps6507x-ts.h b/include/linux/input/tps6507x-ts.h
new file mode 100644
index 0000000..ab14403
--- /dev/null
+++ b/include/linux/input/tps6507x-ts.h
@@ -0,0 +1,24 @@
+/* linux/i2c/tps6507x-ts.h
+ *
+ * Functions to access TPS65070 touch screen chip.
+ *
+ * Copyright (c) 2009 RidgeRun (todd.fischer at ridgerun.com)
+ *
+ *
+ *  For licencing details see kernel-base/COPYING
+ */
+
+#ifndef __LINUX_I2C_TPS6507X_TS_H
+#define __LINUX_I2C_TPS6507X_TS_H
+
+/* Board specific touch screen initial values */
+struct touchscreen_init_data {
+	int	poll_period;	/* ms */
+	int	vref;		/* non-zero to leave vref on */
+	__u16	min_pressure;	/* min reading to be treated as a touch */
+	__u16	vendor;
+	__u16	product;
+	__u16	version;
+};
+
+#endif /*  __LINUX_I2C_TPS6507X_TS_H */
diff --git a/include/linux/mfd/tps6507x.h b/include/linux/mfd/tps6507x.h
index 9543cb7..c923e48 100644
--- a/include/linux/mfd/tps6507x.h
+++ b/include/linux/mfd/tps6507x.h
@@ -142,6 +142,7 @@
 
 struct tps6507x_board {
 	struct regulator_init_data *tps6507x_pmic_init_data;
+	struct touchscreen_init_data *tps6507x_ts_init_data;
 };
 
 /**
@@ -162,6 +163,7 @@ struct tps6507x_dev {
 
 	/* Client devices */
 	struct tps6507x_pmic *pmic;
+	struct tps6507x_ts *ts;
 };
 
 #endif /*  __LINUX_MFD_TPS6507X_H */
-- 
1.6.0.4


From martin at ti.com  Sun Apr  4 11:49:49 2010
From: martin at ti.com (Ambrose, Martin)
Date: Sun, 4 Apr 2010 11:49:49 -0500
Subject: [PATCH v2] DA8XX/OMAP-L1XX: FB: Implement double buffering
In-Reply-To: <A24693684029E5489D1D202277BE8944546D96C1@dlee02.ent.ti.com>
References: <1269868554-17045-1-git-send-email-martin@ti.com>
	<A24693684029E5489D1D202277BE89445316FAB1@dlee02.ent.ti.com>
	<20100330133621.e897cdb5.akpm@linux-foundation.org>
	<A24693684029E5489D1D202277BE8944546D96C1@dlee02.ent.ti.com>
Message-ID: <A24693684029E5489D1D202277BE894454789F00@dlee02.ent.ti.com>

On Wed, Mar 31, 2010 at 20:43:29, Ambrose, Martin wrote:

> Andrew,
> 
> Thanks for the feedback.
> 
> > > +/*
> > > + * Function to wait for vertical sync which for this LCD peripheral
> > > + * translates into waiting for the current raster frame to complete.
> > > + */
> > > +static int fb_wait_for_vsync(struct fb_info *info)
> > > +{
> > > +       struct da8xx_fb_par *par = info->par;
> > > +       wait_queue_t wq;
> > > +       int ret;
> > > +
> > > +       init_waitqueue_entry(&wq, current);
> > 
> > DECLARE_WAITQUEUE() would be more conventional.
> 
> I'll update -- cloned this from some older code I think.

After looking at this further this variable wasn't even used so
I will trim this in upcoming v3 patch.

Regards, 
Martin

From martin at ti.com  Sun Apr  4 11:51:16 2010
From: martin at ti.com (Ambrose, Martin)
Date: Sun, 4 Apr 2010 11:51:16 -0500
Subject: [PATCH v2] DA8XX/OMAP-L1XX: FB: Implement double buffering
In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE0FDD0EFE@Cloud.RL.local>
References: <20100331203256.852450d3.akpm@linux-foundation.org>
	<70E876B0EA86DD4BAF101844BC814DFE0FDD0EFE@Cloud.RL.local>
Message-ID: <A24693684029E5489D1D202277BE894454789F01@dlee02.ent.ti.com>

On Thu, Apr 01, 2010 at 01:47:40, Jon Povey wrote:

> Andrew Morton wrote:
> > On Wed, 31 Mar 2010 20:43:29 -0500 "Ambrose, Martin" <martin at ti.com>
> > wrote:
> 
> >>> If the calling process has signal_pending() (say, someone hit ^C)
> >>> then wait_event_interruptible_timeout() will fall straight through
> >>> with -ERESTARTSYS.  Will this cause the driver to malfunction at
> >>> all?
> >>
> >> I don't think so since the driver doesn't make use of this
> >> information in any way. This is just status to the caller that the
> >> current frame has finished DMA'ing out of the framebuffer.
> >>
> >> Could you maybe propose a scenario/use case where you think it is
> >> problematic? I could then either reason why it should be OK or
> >> I'll create a test harness and see how the driver can/should be
> >> modified.
> >
> > Gee, I dunno - I don't understand the driver to that level.  If you're
> > OK with this wait being interrupted by a signal and the driver handles
> > it OK then fine, that's a feature.
> >
> > To test it I suppose you should give your test app a signal handler
> > and blast kills at it from another process.
> 
> Jumping in..
> 
> This should not cause a problem for the driver; its purpose is to tell userland that it can
> write to the buffer without corrupting graphics (as presumably it is double-buffering and
> the other buffer is now being DMA'd from by the hardware).
> 
> At worst, if the userland software doesn't handle this correctly it may draw one bad frame of graphics. Although if it's had a ctrl-C it probably has bigger things to worry about.
> 
> If the app wants to handle signals it needs to consider such things.. I would not expect the driver to do anything other than what this patch does.

Thanks Jon. I agree. 

If no further objections I'll leave this as is.

Regards, 
Martin

From nsekhar at ti.com  Mon Apr  5 01:18:20 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 5 Apr 2010 11:48:20 +0530
Subject: [PATCH v2 09/16] Davinci: tnetv107x SOC specific header
In-Reply-To: <1269553439-14886-10-git-send-email-cyril@ti.com>
References: <1269553439-14886-1-git-send-email-cyril@ti.com>
	<1269553439-14886-2-git-send-email-cyril@ti.com>
	<1269553439-14886-3-git-send-email-cyril@ti.com>
	<1269553439-14886-4-git-send-email-cyril@ti.com>
	<1269553439-14886-5-git-send-email-cyril@ti.com>
	<1269553439-14886-6-git-send-email-cyril@ti.com>
	<1269553439-14886-7-git-send-email-cyril@ti.com>
	<1269553439-14886-8-git-send-email-cyril@ti.com>
	<1269553439-14886-9-git-send-email-cyril@ti.com>
	<1269553439-14886-10-git-send-email-cyril@ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E66990F8@dbde02.ent.ti.com>

On Fri, Mar 26, 2010 at 03:13:52, Chemparathy, Cyril wrote:
> Added on-chip peripheral base addresses so tnetv107x SOC header.
>

There should be no need to define the full
list of base addresses in one place because
the are typically needed only at only one place
(near the resource definition).

Just add the define where needed and use it.

Thanks,
Sekhar


From nsekhar at ti.com  Mon Apr  5 01:27:52 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 5 Apr 2010 11:57:52 +0530
Subject: [PATCH v2 11/16] Davinci: tnetv107x edma definitions
In-Reply-To: <1269553439-14886-12-git-send-email-cyril@ti.com>
References: <1269553439-14886-1-git-send-email-cyril@ti.com>
	<1269553439-14886-2-git-send-email-cyril@ti.com>
	<1269553439-14886-3-git-send-email-cyril@ti.com>
	<1269553439-14886-4-git-send-email-cyril@ti.com>
	<1269553439-14886-5-git-send-email-cyril@ti.com>
	<1269553439-14886-6-git-send-email-cyril@ti.com>
	<1269553439-14886-7-git-send-email-cyril@ti.com>
	<1269553439-14886-8-git-send-email-cyril@ti.com>
	<1269553439-14886-9-git-send-email-cyril@ti.com>
	<1269553439-14886-10-git-send-email-cyril@ti.com>
	<1269553439-14886-11-git-send-email-cyril@ti.com>
	<1269553439-14886-12-git-send-email-cyril@ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E669910F@dbde02.ent.ti.com>


Hi Cyril,

On Fri, Mar 26, 2010 at 03:13:54, Chemparathy, Cyril wrote:
> Added edma definitions for the tnetv107x soc.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> ---
>  arch/arm/mach-davinci/include/mach/edma.h |   53 +++++++++++++++++++++++++++++
>  1 files changed, 53 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/include/mach/edma.h b/arch/arm/mach-davinci/include/mach/edma.h
> index ced3092..e9d9fd2 100644
> --- a/arch/arm/mach-davinci/include/mach/edma.h
> +++ b/arch/arm/mach-davinci/include/mach/edma.h
> @@ -187,6 +187,59 @@ enum DA830_edma_ch {
>       DA830_DMACH_UART2_TX
>  };
>
> +/* TNETV107X specific EDMA3 information */
> +#define EDMA_TNETV107X_NUM_DMACH     64
> +#define EDMA_TNETV107X_NUM_TCC               64
> +#define EDMA_TNETV107X_NUM_PARAMENTRY        128
> +#define EDMA_TNETV107X_NUM_EVQUE     2
> +#define EDMA_TNETV107X_NUM_TC                2
> +#define EDMA_TNETV107X_CHMAP_EXIST   0
> +#define EDMA_TNETV107X_NUM_REGIONS   4
> +#define TNETV107X_DMACH2EVENT_MAP0   0x3C0CE000u
> +#define TNETV107X_DMACH2EVENT_MAP1   0x000FFFFFu
> +
> +/* TNETV107X specific EDMA3 Events Information */
> +enum tnetv107x_edma_ch {
> +     TNETV107X_DMACH_AES_DMAREQIN            = 3,
> +     TNETV107X_DMACH_AES_DMAREQOUT           = 4,
> +     TNETV107X_DMACH_DES_DMAREQIN            = 5,
> +     TNETV107X_DMACH_DES_DMAREQOUT           = 6,
> +     TNETV107X_DMACH_SHA                     = 7,
> +     TNETV107X_DMACH_IMCOP_IMX               = 8,
> +     TNETV107X_DMACH_IMCOP_VLCD              = 9,
> +     TNETV107X_DMACH_IMCOP_SQR_ARM           = 10,
> +     TNETV107X_DMACH_IMCOP_SQR_DSP           = 11,
> +     TNETV107X_DMACH_PKA                     = 13,
> +     TNETV107X_DMACH_MDIO                    = 14,
> +     TNETV107X_DMACH_SSP                     = 15,
> +     TNETV107X_DMACH_UART1_RX                = 18,
> +     TNETV107X_DMACH_UART1_TX                = 19,
> +     TNETV107X_DMACH_SDIO0_RX                = 26,
> +     TNETV107X_DMACH_SDIO0_TX                = 27,
> +     TNETV107X_DMACH_SDIO1_RX                = 28,
> +     TNETV107X_DMACH_SDIO1_TX                = 29,
> +     TNETV107X_DMACH_GPIO00                  = 32,
> +     TNETV107X_DMACH_GPIO01                  = 33,
> +     TNETV107X_DMACH_GPIO02                  = 34,
> +     TNETV107X_DMACH_GPIO03                  = 35,
> +     TNETV107X_DMACH_EXT0                    = 44,
> +     TNETV107X_DMACH_EXT1                    = 45,
> +     TNETV107X_DMACH_GPIO12                  = 46,
> +     TNETV107X_DMACH_GPIO13                  = 47,
> +     TNETV107X_DMACH_TIMER00                 = 48,
> +     TNETV107X_DMACH_TIMER01                 = 49,
> +     TNETV107X_DMACH_TIMER10                 = 50,
> +     TNETV107X_DMACH_TIMER11                 = 51,
> +     TNETV107X_DMACH_TDM0_RXDMA              = 52,
> +     TNETV107X_DMACH_TDM0_RXMCSP             = 53,
> +     TNETV107X_DMACH_TDM0_TXDMA              = 54,
> +     TNETV107X_DMACH_TDM0_TXMCSP             = 55,
> +     TNETV107X_DMACH_TDM1_RXDMA              = 56,
> +     TNETV107X_DMACH_TDM1_RXMCSP             = 57,
> +     TNETV107X_DMACH_TDM1_TXDMA              = 58,
> +     TNETV107X_DMACH_TDM1_TXMCSP             = 59,
> +};

If I am not forgetting, even DMA channel assignments
are needed only where the IO resources are defined.
So, no need for a definition in a header file.

Readability will be improved if these are defined
where actually used.

I know this is coming from existing defines of this
sort in edma.h, but, I don't think that's ideal.

Thanks,
Sekhar

From nsekhar at ti.com  Mon Apr  5 04:14:59 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 5 Apr 2010 14:44:59 +0530
Subject: [PATCH v2 14/16] Davinci: tnetv107x gpio implementation
In-Reply-To: <1269553439-14886-15-git-send-email-cyril@ti.com>
References: <1269553439-14886-1-git-send-email-cyril@ti.com>
	<1269553439-14886-2-git-send-email-cyril@ti.com>
	<1269553439-14886-3-git-send-email-cyril@ti.com>
	<1269553439-14886-4-git-send-email-cyril@ti.com>
	<1269553439-14886-5-git-send-email-cyril@ti.com>
	<1269553439-14886-6-git-send-email-cyril@ti.com>
	<1269553439-14886-7-git-send-email-cyril@ti.com>
	<1269553439-14886-8-git-send-email-cyril@ti.com>
	<1269553439-14886-9-git-send-email-cyril@ti.com>
	<1269553439-14886-10-git-send-email-cyril@ti.com>
	<1269553439-14886-11-git-send-email-cyril@ti.com>
	<1269553439-14886-12-git-send-email-cyril@ti.com>
	<1269553439-14886-13-git-send-email-cyril@ti.com>
	<1269553439-14886-14-git-send-email-cyril@ti.com>
	<1269553439-14886-15-git-send-email-cyril@ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E6699276@dbde02.ent.ti.com>

Hi Cyril,

On Fri, Mar 26, 2010 at 03:13:57, Chemparathy, Cyril wrote:
> Support for tnetv107x gpio controller.  Note that this controller does not use
> the gpio related definitions from davinci_soc_info.

... because this code is used only on one chip right now? How about
when more devices of the same family are added?

>
> Further, this patch modifies davinci's inlined gpio functions to range check
> against davinci_soc_info contents instead of DAVINCI_N_GPIO.  This way,
> tnetv107x systems can define davinci_soc_info.gpio_num to 0 and bypass the
> inline routines.

Why? Tnetv107x would benefit from inline GPIO functions as well.
So, why not define separate inline functions for that chip?

>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> ---
>  arch/arm/mach-davinci/Makefile                 |    1 +
>  arch/arm/mach-davinci/gpio-tnetv107x.c         |  155 ++++++++++++++++++++++++
>  arch/arm/mach-davinci/include/mach/gpio.h      |    6 +-
>  arch/arm/mach-davinci/include/mach/tnetv107x.h |    4 +
>  4 files changed, 163 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm/mach-davinci/gpio-tnetv107x.c
>
> diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
> index 6aac880..0284a4c 100644
> --- a/arch/arm/mach-davinci/Makefile
> +++ b/arch/arm/mach-davinci/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_ARCH_DAVINCI_DM646x)       += dm646x.o devices.o
>  obj-$(CONFIG_ARCH_DAVINCI_DM365)     += dm365.o devices.o
>  obj-$(CONFIG_ARCH_DAVINCI_DA830)        += da830.o devices-da8xx.o
>  obj-$(CONFIG_ARCH_DAVINCI_DA850)        += da850.o devices-da8xx.o
> +obj-$(CONFIG_ARCH_DAVINCI_TNETV107X)    += gpio-tnetv107x.o

Err, you are building in support for both DaVinci and
tnetv107x gpios. I thought the DaVinci GPIO code is not
applicable for this chip.

>
>  obj-$(CONFIG_AINTC)                  += irq.o
>  obj-$(CONFIG_CP_INTC)                        += cp_intc.o
> diff --git a/arch/arm/mach-davinci/gpio-tnetv107x.c b/arch/arm/mach-davinci/gpio-tnetv107x.c
> new file mode 100644
> index 0000000..d868b46
> --- /dev/null
> +++ b/arch/arm/mach-davinci/gpio-tnetv107x.c
> @@ -0,0 +1,155 @@
> +/*
> + * TI TNETV107X GPIO Support
> + *
> + * Author: Cyril Chemparathy <cyril at ti.com>
> + *
> + * 2009 (c) Texas Instruments, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This program
> + * is licensed "as is" without any warranty of any kind, whether express
> + * or implied.
> + */
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/gpio.h>
> +
> +#include <mach/common.h>
> +#include <mach/tnetv107x.h>
> +
> +struct tnetv107x_gpio_regs {
> +     u32     idver;
> +     u32     data_in[3];
> +     u32     data_out[3];
> +     u32     direction[3];
> +     u32     enable[3];
> +};
> +
> +struct tnetv107x_gpio_controller {
> +     struct tnetv107x_gpio_regs __iomem *regs;
> +     struct gpio_chip        chip;
> +};
> +
> +static struct tnetv107x_gpio_controller tnetv107x_gpio_controller;
> +
> +#define gpio_reg_index(gpio) ((gpio) >> 5)
> +#define gpio_reg_bit(gpio)   BIT((gpio) & 0x1f)
> +
> +#define gpio_reg_rmw(reg, mask, val) \
> +     __raw_writel((__raw_readl(reg) & ~(mask)) | (val), (reg))
> +
> +#define gpio_reg_set_bit(reg, gpio)  \
> +     gpio_reg_rmw((reg) + gpio_reg_index(gpio), 0, gpio_reg_bit(gpio))
> +
> +#define gpio_reg_clear_bit(reg, gpio)        \
> +     gpio_reg_rmw((reg) + gpio_reg_index(gpio), gpio_reg_bit(gpio), 0)
> +
> +#define gpio_reg_get_bit(reg, gpio)  \
> +     (__raw_readl((reg) + gpio_reg_index(gpio)) & gpio_reg_bit(gpio))
> +
> +#define chip_to_gpio(chip)           \
> +     container_of(chip, struct tnetv107x_gpio_controller, chip)
> +
> +static int tnetv107x_gpio_request(struct gpio_chip *chip, unsigned gpio)
> +{
> +     struct tnetv107x_gpio_controller *ctlr = chip_to_gpio(chip);
> +     unsigned long flags;
> +
> +     local_irq_save(flags);

Should use spin_lock() for protection.

> +
> +     gpio_reg_set_bit(&ctlr->regs->enable, gpio);
> +
> +     local_irq_restore(flags);
> +
> +     return 0;
> +}
> +

[...]

> +void __init tnetv107x_gpio_init(void)
> +{
> +     struct tnetv107x_gpio_controller *ctlr = &tnetv107x_gpio_controller;
> +
> +     ctlr->regs = ioremap(TNETV107X_GPIO_BASE, PAGE_SIZE);
> +
> +     ctlr->chip.label                = "TNETV107X";
> +     ctlr->chip.request              = tnetv107x_gpio_request;
> +     ctlr->chip.free                 = tnetv107x_gpio_free;
> +     ctlr->chip.direction_input      = tnetv107x_gpio_dir_in;
> +     ctlr->chip.get                  = tnetv107x_gpio_get;
> +     ctlr->chip.direction_output     = tnetv107x_gpio_dir_out;
> +     ctlr->chip.set                  = tnetv107x_gpio_set;
> +     ctlr->chip.base                 = 0;
> +     ctlr->chip.ngpio                = TNETV107X_N_GPIOS;
> +     ctlr->chip.can_sleep            = 0;
> +
> +     gpiochip_add(&ctlr->chip);
> +}

Why make it a global? Why not an initcall like the regular
DaVinci gpio driver does?

Thanks,
Sekhar


From nsekhar at ti.com  Mon Apr  5 04:24:42 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 5 Apr 2010 14:54:42 +0530
Subject: [PATCH v2 13/16] Davinci: simplified debug macros
In-Reply-To: <1269553439-14886-14-git-send-email-cyril@ti.com>
References: <1269553439-14886-1-git-send-email-cyril@ti.com>
	<1269553439-14886-2-git-send-email-cyril@ti.com>
	<1269553439-14886-3-git-send-email-cyril@ti.com>
	<1269553439-14886-4-git-send-email-cyril@ti.com>
	<1269553439-14886-5-git-send-email-cyril@ti.com>
	<1269553439-14886-6-git-send-email-cyril@ti.com>
	<1269553439-14886-7-git-send-email-cyril@ti.com>
	<1269553439-14886-8-git-send-email-cyril@ti.com>
	<1269553439-14886-9-git-send-email-cyril@ti.com>
	<1269553439-14886-10-git-send-email-cyril@ti.com>
	<1269553439-14886-11-git-send-email-cyril@ti.com>
	<1269553439-14886-12-git-send-email-cyril@ti.com>
	<1269553439-14886-13-git-send-email-cyril@ti.com>
	<1269553439-14886-14-git-send-email-cyril@ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E6699294@dbde02.ent.ti.com>


Hi Cyril,

On Fri, Mar 26, 2010 at 03:13:56, Chemparathy, Cyril wrote:
> Simplified UART base address calculation for low-level debug macros.  This
> makes it much easier to add in support for other SOCs.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> ---
>  arch/arm/mach-davinci/include/mach/debug-macro.S |   28 +++++++++++++--------
>  arch/arm/mach-davinci/include/mach/hardware.h    |    4 ++-
>  arch/arm/mach-davinci/include/mach/serial.h      |    2 +
>  3 files changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/include/mach/debug-macro.S b/arch/arm/mach-davinci/include/mach/debug-macro.S
> index 3cd93a8..b8b47a4 100644
> --- a/arch/arm/mach-davinci/include/mach/debug-macro.S
> +++ b/arch/arm/mach-davinci/include/mach/debug-macro.S
> @@ -17,22 +17,28 @@
>   */
>
>  #include <linux/serial_reg.h>
> +#include <mach/serial.h>
> +
> +#if defined(CONFIG_ARCH_DAVINCI_DMx)
> +#define UART_PHYS    DAVINCI_UART0_BASE
> +#define UART_VIRT    IO_ADDRESS(UART_PHYS)
> +#endif
> +
> +#if defined(CONFIG_ARCH_DAVINCI_DA8XX)
> +#ifdef UART_PHYS
> +#error "CONFIG_DEBUG_LL is incompatible with multiple archs"
> +#endif
> +#define UART_PHYS    DA8XX_UART2_BASE
> +#define UART_VIRT    IO_ADDRESS(UART_PHYS)
> +#endif
> +
>  #define UART_SHIFT   2
>
>               .macro addruart, rx, tmp
>               mrc     p15, 0, \rx, c1, c0
>               tst     \rx, #1                 @ MMU enabled?
> -             moveq   \rx, #0x01000000        @ physical base address
> -             movne   \rx, #0xfe000000        @ virtual base
> -#if defined(CONFIG_ARCH_DAVINCI_DA8XX) && defined(CONFIG_ARCH_DAVINCI_DMx)
> -#error Cannot enable DaVinci and DA8XX platforms concurrently
> -#elif defined(CONFIG_MACH_DAVINCI_DA830_EVM) || \
> -     defined(CONFIG_MACH_DAVINCI_DA850_EVM)
> -             orr     \rx, \rx, #0x00d00000   @ physical base address
> -             orr     \rx, \rx, #0x0000d000   @ of UART 2
> -#else
> -             orr     \rx, \rx, #0x00c20000   @ UART 0
> -#endif
> +             ldreq   \rx, =UART_PHYS
> +             ldrne   \rx, =UART_VIRT


As Sergei pointed out, this is making the debug
UART dependent on the architecture which would be
an incorrect thing to do.

IMHO, a better simplification would be to let the debug
UART number on a board be defined by Kconfig entry for that
board and the code here could compute the UART base using
that number.

Thanks,
Sekhar


From nsekhar at ti.com  Mon Apr  5 05:56:54 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 5 Apr 2010 16:26:54 +0530
Subject: [PATCH v2 16/16] Davinci: initial tnetv107x evm board support
In-Reply-To: <1269553439-14886-17-git-send-email-cyril@ti.com>
References: <1269553439-14886-1-git-send-email-cyril@ti.com>
	<1269553439-14886-2-git-send-email-cyril@ti.com>
	<1269553439-14886-3-git-send-email-cyril@ti.com>
	<1269553439-14886-4-git-send-email-cyril@ti.com>
	<1269553439-14886-5-git-send-email-cyril@ti.com>
	<1269553439-14886-6-git-send-email-cyril@ti.com>
	<1269553439-14886-7-git-send-email-cyril@ti.com>
	<1269553439-14886-8-git-send-email-cyril@ti.com>
	<1269553439-14886-9-git-send-email-cyril@ti.com>
	<1269553439-14886-10-git-send-email-cyril@ti.com>
	<1269553439-14886-11-git-send-email-cyril@ti.com>
	<1269553439-14886-12-git-send-email-cyril@ti.com>
	<1269553439-14886-13-git-send-email-cyril@ti.com>
	<1269553439-14886-14-git-send-email-cyril@ti.com>
	<1269553439-14886-15-git-send-email-cyril@ti.com>
	<1269553439-14886-16-git-send-email-cyril@ti.com>
	<1269553439-14886-17-git-send-email-cyril@ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E6699394@dbde02.ent.ti.com>

On Fri, Mar 26, 2010 at 03:13:59, Chemparathy, Cyril wrote:
> Added support for tnetv107x evaluation module.

Its odd to see the EVM being added before SoC...

>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> ---

[...]

>
>  endchoice
>
> +config MACH_TNETV107X
> +     bool "TI TNETV107X Reference Platform"
> +     default ARCH_DAVINCI_TNETV107X
> +     depends on ARCH_DAVINCI_TNETV107X

... because of symbols like these which are being used before
being defined cause git-bisect to break (although this particular
case would be quite harmless).

> +     help
> +       Say Y here to select the TI TNETV107X Evaluation Module.
> +
>  config DAVINCI_MUX
>       bool "DAVINCI multiplexing support"
>       depends on ARCH_DAVINCI
> diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
> index 62c5116..eab4c0f 100644
> --- a/arch/arm/mach-davinci/Makefile
> +++ b/arch/arm/mach-davinci/Makefile
> @@ -32,6 +32,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM)       += board-dm646x-evm.o cdce949.o
>  obj-$(CONFIG_MACH_DAVINCI_DM365_EVM) += board-dm365-evm.o
>  obj-$(CONFIG_MACH_DAVINCI_DA830_EVM) += board-da830-evm.o
>  obj-$(CONFIG_MACH_DAVINCI_DA850_EVM) += board-da850-evm.o
> +obj-$(CONFIG_MACH_TNETV107X)         += board-tnetv107x-evm.o
>
>  # Power Management
>  obj-$(CONFIG_CPU_FREQ)                       += cpufreq.o
> diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c b/arch/arm/mach-davinci/board-tnetv107x-evm.c
> new file mode 100644
> index 0000000..a6bf49c
> --- /dev/null
> +++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c

[...]

> +static __init void tnetv107x_evm_board_init(void)
> +{
> +     int status;
> +
> +     davinci_cfg_reg_list(tnetv107x_sdio1_pins);
> +     davinci_cfg_reg_list(tnetv107x_uart1_pins);
> +     davinci_cfg_reg_list(tnetv107x_gpio_pins);
> +
> +     tnetv107x_gpio_init();
> +     tnetv107x_edma_init();
> +     tnetv107x_serial_init(tnetv107x_serial_pdata);
> +
> +     status = gpio_request(TNETV107X_EVM_MMC_WP_GPIO, "MMC WP\n");
> +     if (status < 0) {
> +             printk(KERN_ERR "cannot open mmcsd write protect gpio %d\n",
> +                             TNETV107X_EVM_MMC_WP_GPIO);
> +             tnetv107x_evm_mmc_config.get_ro = NULL;
> +     } else
> +             gpio_direction_input(TNETV107X_EVM_MMC_WP_GPIO);

Use braces on else here..

> +
> +     status = gpio_request(TNETV107X_EVM_MMC_CD_GPIO, "MMC CD\n");
> +     if (status < 0) {
> +             printk(KERN_ERR "cannot open mmcsd card detect gpio %d\n",
> +                             TNETV107X_EVM_MMC_CD_GPIO);
> +             tnetv107x_evm_mmc_config.get_cd = NULL;
> +     } else
> +             gpio_direction_input(TNETV107X_EVM_MMC_CD_GPIO);

... and here.

> +
> +     platform_add_devices(tnetv107x_evm_devices,
> +                             ARRAY_SIZE(tnetv107x_evm_devices));

No need to mux the CD and WP pins as GPIO pins?

Thanks,
Sekhar


From nsekhar at ti.com  Mon Apr  5 06:24:47 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 5 Apr 2010 16:54:47 +0530
Subject: DM6446 and DSA (Distributed Switch Architecture)
In-Reply-To: <hp4bl8$i6f$1@dough.gmane.org>
References: <houuji$a30$1@dough.gmane.org>
	<i2nfca5cfb21003310708s83569139p51c56915e1c6c728@mail.gmail.com>
	<hp4bl8$i6f$1@dough.gmane.org>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E6699410@dbde02.ent.ti.com>


Hi Andreas,

On Fri, Apr 02, 2010 at 14:28:15, Andreas Auer wrote:
> Steve Chen schrieb:
> > On Wed, Mar 31, 2010 at 2:44 AM, Andreas Auer <a.auer at zydacron.com> wrote:
> >> Hello,
> >>
> >> I'm using a customized board similar to the EVM with a DM6446 cpu. The main
> >> difference is that I'm using a Micrel KSZ8893M ethernet switch. The ethernet
> >> switch has an I2C config interface and the standard mdio interface.
> >> Therefore, I'm using the DSA driver subsystem and wrote a small chip driver
> >> (I took the KSZ8893 driver for the Blackfin processor as reference).
> >> Now, my problem is that the ethernet mac of the Davinci cpu is initialized
> >> (probed) later then the DSA driver. And therefore the DSA driver cannot find
> >> a valid netdevice.
> >> Does anyone know how to change the initialization order of the devices??
> >> Changing the order of the register_device_driver function calls has
> >> basically no influence on the init sequence.
> >>
> >> Thanks,
> >> Andreas
> >
> > Hello,
> >
> > I encounter the same issue with DA830/OMAP-l137 EVM.  Instead of
> > probing PHY to get speed and duplexity, the driver just set the speed
> > and duplexity based on platform data.  May want to take a look at the
> > OMAP-l137.
>
> Thanks for your answer. I got another solution. The davinci_emac driver
> calls the init function very late because of
>        late_initcall(davinci_emac_init);
>
> I changed this line:
>        module_init(davinci_emac_init);

This change was made so EMAC can get initialized after
the SPI subsystem (so mac address could be fetched from
SPI flash). Seems like there are one too many initialization
order dependencies around EMAC driver.

Is it possible to get your DSA driver to be a late_initcall too?
Within the same initcall level the order is determined by the order
In which the makefile lists the .o file.

Thanks,
Sekhar


From nsekhar at ti.com  Mon Apr  5 06:35:39 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 5 Apr 2010 17:05:39 +0530
Subject: [PATCH v2 16/16] Davinci: initial tnetv107x evm board support
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E6699394@dbde02.ent.ti.com>
References: <1269553439-14886-1-git-send-email-cyril@ti.com>
	<1269553439-14886-2-git-send-email-cyril@ti.com>
	<1269553439-14886-3-git-send-email-cyril@ti.com>
	<1269553439-14886-4-git-send-email-cyril@ti.com>
	<1269553439-14886-5-git-send-email-cyril@ti.com>
	<1269553439-14886-6-git-send-email-cyril@ti.com>
	<1269553439-14886-7-git-send-email-cyril@ti.com>
	<1269553439-14886-8-git-send-email-cyril@ti.com>
	<1269553439-14886-9-git-send-email-cyril@ti.com>
	<1269553439-14886-10-git-send-email-cyril@ti.com>
	<1269553439-14886-11-git-send-email-cyril@ti.com>
	<1269553439-14886-12-git-send-email-cyril@ti.com>
	<1269553439-14886-13-git-send-email-cyril@ti.com>
	<1269553439-14886-14-git-send-email-cyril@ti.com>
	<1269553439-14886-15-git-send-email-cyril@ti.com>
	<1269553439-14886-16-git-send-email-cyril@ti.com>
	<1269553439-14886-17-git-send-email-cyril@ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E6699394@dbde02.ent.ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E6699423@dbde02.ent.ti.com>

On Mon, Apr 05, 2010 at 16:26:54, Nori, Sekhar wrote:
> On Fri, Mar 26, 2010 at 03:13:59, Chemparathy, Cyril wrote:
> > Added support for tnetv107x evaluation module.
>
> Its odd to see the EVM being added before SoC...
>
> >
> > Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> > ---
>
> [...]
>
> >
> >  endchoice
> >
> > +config MACH_TNETV107X
> > +     bool "TI TNETV107X Reference Platform"
> > +     default ARCH_DAVINCI_TNETV107X
> > +     depends on ARCH_DAVINCI_TNETV107X
>
> ... because of symbols like these which are being used before
> being defined cause git-bisect to break (although this particular
> case would be quite harmless).

Argh, please ignore this comment. Obviously I was seeing double.

Thanks,
Sekhar


From uniquepiya at gmail.com  Mon Apr  5 06:36:10 2010
From: uniquepiya at gmail.com (priyanka patny)
Date: Mon, 5 Apr 2010 04:36:10 -0700
Subject: Davinci-linux-open-source Digest, Vol 52, Issue 9
In-Reply-To: <mailman.1671.1270466691.11996.davinci-linux-open-source@linux.davincidsp.com>
References: <mailman.1671.1270466691.11996.davinci-linux-open-source@linux.davincidsp.com>
Message-ID: <q2w6dd47d831004050436l18842260h70073c3be07db2b4@mail.gmail.com>

how can i use opencv on davinci processor can anybody tell me please

On 4/5/10, davinci-linux-open-source-request at linux.davincidsp.com <
davinci-linux-open-source-request at linux.davincidsp.com> wrote:
>
> Send Davinci-linux-open-source mailing list submissions to
>        davinci-linux-open-source at linux.davincidsp.com
>
> 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
>        davinci-linux-open-source-request at linux.davincidsp.com
>
> You can reach the person managing the list at
>        davinci-linux-open-source-owner at linux.davincidsp.com
>
> 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. RE: [PATCH v2 09/16] Davinci: tnetv107x SOC specific header
>      (Nori, Sekhar)
>   2. RE: [PATCH v2 11/16] Davinci: tnetv107x edma definitions
>      (Nori, Sekhar)
>   3. RE: [PATCH v2 14/16] Davinci: tnetv107x gpio implementation
>      (Nori, Sekhar)
>   4. RE: [PATCH v2 13/16] Davinci: simplified debug macros
>      (Nori, Sekhar)
>   5. RE: [PATCH v2 16/16] Davinci: initial tnetv107x evm board
>      support (Nori, Sekhar)
>   6. RE: DM6446 and DSA (Distributed Switch Architecture)
>      (Nori, Sekhar)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 5 Apr 2010 11:48:20 +0530
> From: "Nori, Sekhar" <nsekhar at ti.com>
> To: "Chemparathy, Cyril" <cyril at ti.com>
> Cc: "davinci-linux-open-source at linux.davincidsp.com"
>        <davinci-linux-open-source at linux.davincidsp.com>,
>        "sshtylyov at mvista.com" <sshtylyov at mvista.com>
> Subject: RE: [PATCH v2 09/16] Davinci: tnetv107x SOC specific header
> Message-ID:
>        <B85A65D85D7EB246BE421B3FB0FBB59301E66990F8 at dbde02.ent.ti.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Fri, Mar 26, 2010 at 03:13:52, Chemparathy, Cyril wrote:
> > Added on-chip peripheral base addresses so tnetv107x SOC header.
> >
>
> There should be no need to define the full
> list of base addresses in one place because
> the are typically needed only at only one place
> (near the resource definition).
>
> Just add the define where needed and use it.
>
> Thanks,
> Sekhar
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 5 Apr 2010 11:57:52 +0530
> From: "Nori, Sekhar" <nsekhar at ti.com>
> To: "Chemparathy, Cyril" <cyril at ti.com>
> Cc: "davinci-linux-open-source at linux.davincidsp.com"
>        <davinci-linux-open-source at linux.davincidsp.com>,
>        "sshtylyov at mvista.com" <sshtylyov at mvista.com>
> Subject: RE: [PATCH v2 11/16] Davinci: tnetv107x edma definitions
> Message-ID:
>        <B85A65D85D7EB246BE421B3FB0FBB59301E669910F at dbde02.ent.ti.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Hi Cyril,
>
> On Fri, Mar 26, 2010 at 03:13:54, Chemparathy, Cyril wrote:
> > Added edma definitions for the tnetv107x soc.
> >
> > Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> > ---
> >  arch/arm/mach-davinci/include/mach/edma.h |   53
> +++++++++++++++++++++++++++++
> >  1 files changed, 53 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-davinci/include/mach/edma.h
> b/arch/arm/mach-davinci/include/mach/edma.h
> > index ced3092..e9d9fd2 100644
> > --- a/arch/arm/mach-davinci/include/mach/edma.h
> > +++ b/arch/arm/mach-davinci/include/mach/edma.h
> > @@ -187,6 +187,59 @@ enum DA830_edma_ch {
> >       DA830_DMACH_UART2_TX
> >  };
> >
> > +/* TNETV107X specific EDMA3 information */
> > +#define EDMA_TNETV107X_NUM_DMACH     64
> > +#define EDMA_TNETV107X_NUM_TCC               64
> > +#define EDMA_TNETV107X_NUM_PARAMENTRY        128
> > +#define EDMA_TNETV107X_NUM_EVQUE     2
> > +#define EDMA_TNETV107X_NUM_TC                2
> > +#define EDMA_TNETV107X_CHMAP_EXIST   0
> > +#define EDMA_TNETV107X_NUM_REGIONS   4
> > +#define TNETV107X_DMACH2EVENT_MAP0   0x3C0CE000u
> > +#define TNETV107X_DMACH2EVENT_MAP1   0x000FFFFFu
> > +
> > +/* TNETV107X specific EDMA3 Events Information */
> > +enum tnetv107x_edma_ch {
> > +     TNETV107X_DMACH_AES_DMAREQIN            = 3,
> > +     TNETV107X_DMACH_AES_DMAREQOUT           = 4,
> > +     TNETV107X_DMACH_DES_DMAREQIN            = 5,
> > +     TNETV107X_DMACH_DES_DMAREQOUT           = 6,
> > +     TNETV107X_DMACH_SHA                     = 7,
> > +     TNETV107X_DMACH_IMCOP_IMX               = 8,
> > +     TNETV107X_DMACH_IMCOP_VLCD              = 9,
> > +     TNETV107X_DMACH_IMCOP_SQR_ARM           = 10,
> > +     TNETV107X_DMACH_IMCOP_SQR_DSP           = 11,
> > +     TNETV107X_DMACH_PKA                     = 13,
> > +     TNETV107X_DMACH_MDIO                    = 14,
> > +     TNETV107X_DMACH_SSP                     = 15,
> > +     TNETV107X_DMACH_UART1_RX                = 18,
> > +     TNETV107X_DMACH_UART1_TX                = 19,
> > +     TNETV107X_DMACH_SDIO0_RX                = 26,
> > +     TNETV107X_DMACH_SDIO0_TX                = 27,
> > +     TNETV107X_DMACH_SDIO1_RX                = 28,
> > +     TNETV107X_DMACH_SDIO1_TX                = 29,
> > +     TNETV107X_DMACH_GPIO00                  = 32,
> > +     TNETV107X_DMACH_GPIO01                  = 33,
> > +     TNETV107X_DMACH_GPIO02                  = 34,
> > +     TNETV107X_DMACH_GPIO03                  = 35,
> > +     TNETV107X_DMACH_EXT0                    = 44,
> > +     TNETV107X_DMACH_EXT1                    = 45,
> > +     TNETV107X_DMACH_GPIO12                  = 46,
> > +     TNETV107X_DMACH_GPIO13                  = 47,
> > +     TNETV107X_DMACH_TIMER00                 = 48,
> > +     TNETV107X_DMACH_TIMER01                 = 49,
> > +     TNETV107X_DMACH_TIMER10                 = 50,
> > +     TNETV107X_DMACH_TIMER11                 = 51,
> > +     TNETV107X_DMACH_TDM0_RXDMA              = 52,
> > +     TNETV107X_DMACH_TDM0_RXMCSP             = 53,
> > +     TNETV107X_DMACH_TDM0_TXDMA              = 54,
> > +     TNETV107X_DMACH_TDM0_TXMCSP             = 55,
> > +     TNETV107X_DMACH_TDM1_RXDMA              = 56,
> > +     TNETV107X_DMACH_TDM1_RXMCSP             = 57,
> > +     TNETV107X_DMACH_TDM1_TXDMA              = 58,
> > +     TNETV107X_DMACH_TDM1_TXMCSP             = 59,
> > +};
>
> If I am not forgetting, even DMA channel assignments
> are needed only where the IO resources are defined.
> So, no need for a definition in a header file.
>
> Readability will be improved if these are defined
> where actually used.
>
> I know this is coming from existing defines of this
> sort in edma.h, but, I don't think that's ideal.
>
> Thanks,
> Sekhar
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 5 Apr 2010 14:44:59 +0530
> From: "Nori, Sekhar" <nsekhar at ti.com>
> To: "Chemparathy, Cyril" <cyril at ti.com>
> Cc: "davinci-linux-open-source at linux.davincidsp.com"
>        <davinci-linux-open-source at linux.davincidsp.com>,
>        "sshtylyov at mvista.com" <sshtylyov at mvista.com>
> Subject: RE: [PATCH v2 14/16] Davinci: tnetv107x gpio implementation
> Message-ID:
>        <B85A65D85D7EB246BE421B3FB0FBB59301E6699276 at dbde02.ent.ti.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Cyril,
>
> On Fri, Mar 26, 2010 at 03:13:57, Chemparathy, Cyril wrote:
> > Support for tnetv107x gpio controller.  Note that this controller does
> not use
> > the gpio related definitions from davinci_soc_info.
>
> ... because this code is used only on one chip right now? How about
> when more devices of the same family are added?
>
> >
> > Further, this patch modifies davinci's inlined gpio functions to range
> check
> > against davinci_soc_info contents instead of DAVINCI_N_GPIO.  This way,
> > tnetv107x systems can define davinci_soc_info.gpio_num to 0 and bypass
> the
> > inline routines.
>
> Why? Tnetv107x would benefit from inline GPIO functions as well.
> So, why not define separate inline functions for that chip?
>
> >
> > Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> > ---
> >  arch/arm/mach-davinci/Makefile                 |    1 +
> >  arch/arm/mach-davinci/gpio-tnetv107x.c         |  155
> ++++++++++++++++++++++++
> >  arch/arm/mach-davinci/include/mach/gpio.h      |    6 +-
> >  arch/arm/mach-davinci/include/mach/tnetv107x.h |    4 +
> >  4 files changed, 163 insertions(+), 3 deletions(-)
> >  create mode 100644 arch/arm/mach-davinci/gpio-tnetv107x.c
> >
> > diff --git a/arch/arm/mach-davinci/Makefile
> b/arch/arm/mach-davinci/Makefile
> > index 6aac880..0284a4c 100644
> > --- a/arch/arm/mach-davinci/Makefile
> > +++ b/arch/arm/mach-davinci/Makefile
> > @@ -16,6 +16,7 @@ obj-$(CONFIG_ARCH_DAVINCI_DM646x)       += dm646x.o
> devices.o
> >  obj-$(CONFIG_ARCH_DAVINCI_DM365)     += dm365.o devices.o
> >  obj-$(CONFIG_ARCH_DAVINCI_DA830)        += da830.o devices-da8xx.o
> >  obj-$(CONFIG_ARCH_DAVINCI_DA850)        += da850.o devices-da8xx.o
> > +obj-$(CONFIG_ARCH_DAVINCI_TNETV107X)    += gpio-tnetv107x.o
>
> Err, you are building in support for both DaVinci and
> tnetv107x gpios. I thought the DaVinci GPIO code is not
> applicable for this chip.
>
> >
> >  obj-$(CONFIG_AINTC)                  += irq.o
> >  obj-$(CONFIG_CP_INTC)                        += cp_intc.o
> > diff --git a/arch/arm/mach-davinci/gpio-tnetv107x.c
> b/arch/arm/mach-davinci/gpio-tnetv107x.c
> > new file mode 100644
> > index 0000000..d868b46
> > --- /dev/null
> > +++ b/arch/arm/mach-davinci/gpio-tnetv107x.c
> > @@ -0,0 +1,155 @@
> > +/*
> > + * TI TNETV107X GPIO Support
> > + *
> > + * Author: Cyril Chemparathy <cyril at ti.com>
> > + *
> > + * 2009 (c) Texas Instruments, Inc. This file is licensed under
> > + * the terms of the GNU General Public License version 2. This program
> > + * is licensed "as is" without any warranty of any kind, whether express
> > + * or implied.
> > + */
> > +#include <linux/kernel.h>
> > +#include <linux/init.h>
> > +#include <linux/gpio.h>
> > +
> > +#include <mach/common.h>
> > +#include <mach/tnetv107x.h>
> > +
> > +struct tnetv107x_gpio_regs {
> > +     u32     idver;
> > +     u32     data_in[3];
> > +     u32     data_out[3];
> > +     u32     direction[3];
> > +     u32     enable[3];
> > +};
> > +
> > +struct tnetv107x_gpio_controller {
> > +     struct tnetv107x_gpio_regs __iomem *regs;
> > +     struct gpio_chip        chip;
> > +};
> > +
> > +static struct tnetv107x_gpio_controller tnetv107x_gpio_controller;
> > +
> > +#define gpio_reg_index(gpio) ((gpio) >> 5)
> > +#define gpio_reg_bit(gpio)   BIT((gpio) & 0x1f)
> > +
> > +#define gpio_reg_rmw(reg, mask, val) \
> > +     __raw_writel((__raw_readl(reg) & ~(mask)) | (val), (reg))
> > +
> > +#define gpio_reg_set_bit(reg, gpio)  \
> > +     gpio_reg_rmw((reg) + gpio_reg_index(gpio), 0, gpio_reg_bit(gpio))
> > +
> > +#define gpio_reg_clear_bit(reg, gpio)        \
> > +     gpio_reg_rmw((reg) + gpio_reg_index(gpio), gpio_reg_bit(gpio), 0)
> > +
> > +#define gpio_reg_get_bit(reg, gpio)  \
> > +     (__raw_readl((reg) + gpio_reg_index(gpio)) & gpio_reg_bit(gpio))
> > +
> > +#define chip_to_gpio(chip)           \
> > +     container_of(chip, struct tnetv107x_gpio_controller, chip)
> > +
> > +static int tnetv107x_gpio_request(struct gpio_chip *chip, unsigned gpio)
> > +{
> > +     struct tnetv107x_gpio_controller *ctlr = chip_to_gpio(chip);
> > +     unsigned long flags;
> > +
> > +     local_irq_save(flags);
>
> Should use spin_lock() for protection.
>
> > +
> > +     gpio_reg_set_bit(&ctlr->regs->enable, gpio);
> > +
> > +     local_irq_restore(flags);
> > +
> > +     return 0;
> > +}
> > +
>
> [...]
>
> > +void __init tnetv107x_gpio_init(void)
> > +{
> > +     struct tnetv107x_gpio_controller *ctlr =
> &tnetv107x_gpio_controller;
> > +
> > +     ctlr->regs = ioremap(TNETV107X_GPIO_BASE, PAGE_SIZE);
> > +
> > +     ctlr->chip.label                = "TNETV107X";
> > +     ctlr->chip.request              = tnetv107x_gpio_request;
> > +     ctlr->chip.free                 = tnetv107x_gpio_free;
> > +     ctlr->chip.direction_input      = tnetv107x_gpio_dir_in;
> > +     ctlr->chip.get                  = tnetv107x_gpio_get;
> > +     ctlr->chip.direction_output     = tnetv107x_gpio_dir_out;
> > +     ctlr->chip.set                  = tnetv107x_gpio_set;
> > +     ctlr->chip.base                 = 0;
> > +     ctlr->chip.ngpio                = TNETV107X_N_GPIOS;
> > +     ctlr->chip.can_sleep            = 0;
> > +
> > +     gpiochip_add(&ctlr->chip);
> > +}
>
> Why make it a global? Why not an initcall like the regular
> DaVinci gpio driver does?
>
> Thanks,
> Sekhar
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 5 Apr 2010 14:54:42 +0530
> From: "Nori, Sekhar" <nsekhar at ti.com>
> To: "Chemparathy, Cyril" <cyril at ti.com>
> Cc: "davinci-linux-open-source at linux.davincidsp.com"
>        <davinci-linux-open-source at linux.davincidsp.com>,
>        "sshtylyov at mvista.com" <sshtylyov at mvista.com>
> Subject: RE: [PATCH v2 13/16] Davinci: simplified debug macros
> Message-ID:
>        <B85A65D85D7EB246BE421B3FB0FBB59301E6699294 at dbde02.ent.ti.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Hi Cyril,
>
> On Fri, Mar 26, 2010 at 03:13:56, Chemparathy, Cyril wrote:
> > Simplified UART base address calculation for low-level debug
> macros.  This
> > makes it much easier to add in support for other SOCs.
> >
> > Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> > ---
> >  arch/arm/mach-davinci/include/mach/debug-macro.S |   28
> +++++++++++++--------
> >  arch/arm/mach-davinci/include/mach/hardware.h    |    4 ++-
> >  arch/arm/mach-davinci/include/mach/serial.h      |    2 +
> >  3 files changed, 22 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/arm/mach-davinci/include/mach/debug-macro.S
> b/arch/arm/mach-davinci/include/mach/debug-macro.S
> > index 3cd93a8..b8b47a4 100644
> > --- a/arch/arm/mach-davinci/include/mach/debug-macro.S
> > +++ b/arch/arm/mach-davinci/include/mach/debug-macro.S
> > @@ -17,22 +17,28 @@
> >   */
> >
> >  #include <linux/serial_reg.h>
> > +#include <mach/serial.h>
> > +
> > +#if defined(CONFIG_ARCH_DAVINCI_DMx)
> > +#define UART_PHYS    DAVINCI_UART0_BASE
> > +#define UART_VIRT    IO_ADDRESS(UART_PHYS)
> > +#endif
> > +
> > +#if defined(CONFIG_ARCH_DAVINCI_DA8XX)
> > +#ifdef UART_PHYS
> > +#error "CONFIG_DEBUG_LL is incompatible with multiple archs"
> > +#endif
> > +#define UART_PHYS    DA8XX_UART2_BASE
> > +#define UART_VIRT    IO_ADDRESS(UART_PHYS)
> > +#endif
> > +
> >  #define UART_SHIFT   2
> >
> >               .macro addruart, rx, tmp
> >               mrc     p15, 0, \rx, c1, c0
> >               tst     \rx, #1                 @ MMU enabled?
> > -             moveq   \rx, #0x01000000        @ physical base address
> > -             movne   \rx, #0xfe000000        @ virtual base
> > -#if defined(CONFIG_ARCH_DAVINCI_DA8XX) &&
> defined(CONFIG_ARCH_DAVINCI_DMx)
> > -#error Cannot enable DaVinci and DA8XX platforms concurrently
> > -#elif defined(CONFIG_MACH_DAVINCI_DA830_EVM) || \
> > -     defined(CONFIG_MACH_DAVINCI_DA850_EVM)
> > -             orr     \rx, \rx, #0x00d00000   @ physical base address
> > -             orr     \rx, \rx, #0x0000d000   @ of UART 2
> > -#else
> > -             orr     \rx, \rx, #0x00c20000   @ UART 0
> > -#endif
> > +             ldreq   \rx, =UART_PHYS
> > +             ldrne   \rx, =UART_VIRT
>
>
> As Sergei pointed out, this is making the debug
> UART dependent on the architecture which would be
> an incorrect thing to do.
>
> IMHO, a better simplification would be to let the debug
> UART number on a board be defined by Kconfig entry for that
> board and the code here could compute the UART base using
> that number.
>
> Thanks,
> Sekhar
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 5 Apr 2010 16:26:54 +0530
> From: "Nori, Sekhar" <nsekhar at ti.com>
> To: "Chemparathy, Cyril" <cyril at ti.com>
> Cc: "davinci-linux-open-source at linux.davincidsp.com"
>        <davinci-linux-open-source at linux.davincidsp.com>,
>        "sshtylyov at mvista.com" <sshtylyov at mvista.com>
> Subject: RE: [PATCH v2 16/16] Davinci: initial tnetv107x evm board
>        support
> Message-ID:
>        <B85A65D85D7EB246BE421B3FB0FBB59301E6699394 at dbde02.ent.ti.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Fri, Mar 26, 2010 at 03:13:59, Chemparathy, Cyril wrote:
> > Added support for tnetv107x evaluation module.
>
> Its odd to see the EVM being added before SoC...
>
> >
> > Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> > ---
>
> [...]
>
> >
> >  endchoice
> >
> > +config MACH_TNETV107X
> > +     bool "TI TNETV107X Reference Platform"
> > +     default ARCH_DAVINCI_TNETV107X
> > +     depends on ARCH_DAVINCI_TNETV107X
>
> ... because of symbols like these which are being used before
> being defined cause git-bisect to break (although this particular
> case would be quite harmless).
>
> > +     help
> > +       Say Y here to select the TI TNETV107X Evaluation Module.
> > +
> >  config DAVINCI_MUX
> >       bool "DAVINCI multiplexing support"
> >       depends on ARCH_DAVINCI
> > diff --git a/arch/arm/mach-davinci/Makefile
> b/arch/arm/mach-davinci/Makefile
> > index 62c5116..eab4c0f 100644
> > --- a/arch/arm/mach-davinci/Makefile
> > +++ b/arch/arm/mach-davinci/Makefile
> > @@ -32,6 +32,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM)       +=
> board-dm646x-evm.o cdce949.o
> >  obj-$(CONFIG_MACH_DAVINCI_DM365_EVM) += board-dm365-evm.o
> >  obj-$(CONFIG_MACH_DAVINCI_DA830_EVM) += board-da830-evm.o
> >  obj-$(CONFIG_MACH_DAVINCI_DA850_EVM) += board-da850-evm.o
> > +obj-$(CONFIG_MACH_TNETV107X)         += board-tnetv107x-evm.o
> >
> >  # Power Management
> >  obj-$(CONFIG_CPU_FREQ)                       += cpufreq.o
> > diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c
> b/arch/arm/mach-davinci/board-tnetv107x-evm.c
> > new file mode 100644
> > index 0000000..a6bf49c
> > --- /dev/null
> > +++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
>
> [...]
>
> > +static __init void tnetv107x_evm_board_init(void)
> > +{
> > +     int status;
> > +
> > +     davinci_cfg_reg_list(tnetv107x_sdio1_pins);
> > +     davinci_cfg_reg_list(tnetv107x_uart1_pins);
> > +     davinci_cfg_reg_list(tnetv107x_gpio_pins);
> > +
> > +     tnetv107x_gpio_init();
> > +     tnetv107x_edma_init();
> > +     tnetv107x_serial_init(tnetv107x_serial_pdata);
> > +
> > +     status = gpio_request(TNETV107X_EVM_MMC_WP_GPIO, "MMC WP\n");
> > +     if (status < 0) {
> > +             printk(KERN_ERR "cannot open mmcsd write protect gpio
> %d\n",
> > +                             TNETV107X_EVM_MMC_WP_GPIO);
> > +             tnetv107x_evm_mmc_config.get_ro = NULL;
> > +     } else
> > +             gpio_direction_input(TNETV107X_EVM_MMC_WP_GPIO);
>
> Use braces on else here..
>
> > +
> > +     status = gpio_request(TNETV107X_EVM_MMC_CD_GPIO, "MMC CD\n");
> > +     if (status < 0) {
> > +             printk(KERN_ERR "cannot open mmcsd card detect gpio %d\n",
> > +                             TNETV107X_EVM_MMC_CD_GPIO);
> > +             tnetv107x_evm_mmc_config.get_cd = NULL;
> > +     } else
> > +             gpio_direction_input(TNETV107X_EVM_MMC_CD_GPIO);
>
> ... and here.
>
> > +
> > +     platform_add_devices(tnetv107x_evm_devices,
> > +                             ARRAY_SIZE(tnetv107x_evm_devices));
>
> No need to mux the CD and WP pins as GPIO pins?
>
> Thanks,
> Sekhar
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 5 Apr 2010 16:54:47 +0530
> From: "Nori, Sekhar" <nsekhar at ti.com>
> To: Andreas Auer <a.auer at zydacron.com>
> Cc: "davinci-linux-open-source at linux.davincidsp.com"
>        <davinci-linux-open-source at linux.davincidsp.com>
> Subject: RE: DM6446 and DSA (Distributed Switch Architecture)
> Message-ID:
>        <B85A65D85D7EB246BE421B3FB0FBB59301E6699410 at dbde02.ent.ti.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
> Hi Andreas,
>
> On Fri, Apr 02, 2010 at 14:28:15, Andreas Auer wrote:
> > Steve Chen schrieb:
> > > On Wed, Mar 31, 2010 at 2:44 AM, Andreas Auer <a.auer at zydacron.com>
> wrote:
> > >> Hello,
> > >>
> > >> I'm using a customized board similar to the EVM with a DM6446 cpu. The
> main
> > >> difference is that I'm using a Micrel KSZ8893M ethernet switch. The
> ethernet
> > >> switch has an I2C config interface and the standard mdio interface.
> > >> Therefore, I'm using the DSA driver subsystem and wrote a small chip
> driver
> > >> (I took the KSZ8893 driver for the Blackfin processor as reference).
> > >> Now, my problem is that the ethernet mac of the Davinci cpu is
> initialized
> > >> (probed) later then the DSA driver. And therefore the DSA driver
> cannot find
> > >> a valid netdevice.
> > >> Does anyone know how to change the initialization order of the
> devices??
> > >> Changing the order of the register_device_driver function calls has
> > >> basically no influence on the init sequence.
> > >>
> > >> Thanks,
> > >> Andreas
> > >
> > > Hello,
> > >
> > > I encounter the same issue with DA830/OMAP-l137 EVM.  Instead of
> > > probing PHY to get speed and duplexity, the driver just set the speed
> > > and duplexity based on platform data.  May want to take a look at the
> > > OMAP-l137.
> >
> > Thanks for your answer. I got another solution. The davinci_emac driver
> > calls the init function very late because of
> >        late_initcall(davinci_emac_init);
> >
> > I changed this line:
> >        module_init(davinci_emac_init);
>
> This change was made so EMAC can get initialized after
> the SPI subsystem (so mac address could be fetched from
> SPI flash). Seems like there are one too many initialization
> order dependencies around EMAC driver.
>
> Is it possible to get your DSA driver to be a late_initcall too?
> Within the same initcall level the order is determined by the order
> In which the makefile lists the .o file.
>
> Thanks,
> Sekhar
>
>
>
> ------------------------------
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>
> End of Davinci-linux-open-source Digest, Vol 52, Issue 9
> ********************************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100405/1c77cd5b/attachment-0001.html>

From broonie at opensource.wolfsonmicro.com  Mon Apr  5 08:46:57 2010
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 5 Apr 2010 14:46:57 +0100
Subject: [PATCH 1/4]-V2 Move TPS6507x register definition to header file.
In-Reply-To: <1270244253-4234-2-git-send-email-todd.fischer@ridgerun.com>
References: <1270244253-4234-1-git-send-email-todd.fischer@ridgerun.com>
	<1270244253-4234-2-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <20100405134657.GF6580@rakim.wolfsonmicro.main>

On Fri, Apr 02, 2010 at 03:37:30PM -0600, Todd Fischer wrote:
> Other sub-drivers for the TPS6507x chip will need to use register 
> definition so move it out of the source file and into a header file.
> 
> Signed-off-by: Todd Fischer <todd.fischer at ridgerun.com>

Acked-by: Mark Brown <broonie at opensource.wolfsonmicro.com>

From broonie at opensource.wolfsonmicro.com  Mon Apr  5 08:48:31 2010
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 5 Apr 2010 14:48:31 +0100
Subject: [PATCH 2/4]-V2 Make room for other tps6507x drivers to have
	board specific initialization data.
In-Reply-To: <1270244253-4234-3-git-send-email-todd.fischer@ridgerun.com>
References: <1270244253-4234-1-git-send-email-todd.fischer@ridgerun.com>
	<1270244253-4234-2-git-send-email-todd.fischer@ridgerun.com>
	<1270244253-4234-3-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <20100405134831.GG6580@rakim.wolfsonmicro.main>

On Fri, Apr 02, 2010 at 03:37:31PM -0600, Todd Fischer wrote:
> Add mfd structure which refrences sub-driver initialization data. For example,
> for a giving hardware implementation, the voltage regulator sub-driver
> initialization data provides the mapping betten a voltage regulator and what
> the output voltage is being used for.
> 
> Signed-off-by: Todd Fischer <todd.fischer at ridgerun.com>

Acked-by: Mark Brown <broonie at opensource.wolfsonmicro.com>

From broonie at opensource.wolfsonmicro.com  Mon Apr  5 08:49:13 2010
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 5 Apr 2010 14:49:13 +0100
Subject: [PATCH 3/4]-V2 Cleaned up name space so each MFD sub-driver
	uses a different name space.
In-Reply-To: <1270244253-4234-4-git-send-email-todd.fischer@ridgerun.com>
References: <1270244253-4234-1-git-send-email-todd.fischer@ridgerun.com>
	<1270244253-4234-2-git-send-email-todd.fischer@ridgerun.com>
	<1270244253-4234-3-git-send-email-todd.fischer@ridgerun.com>
	<1270244253-4234-4-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <20100405134913.GH6580@rakim.wolfsonmicro.main>

On Fri, Apr 02, 2010 at 03:37:32PM -0600, Todd Fischer wrote:
> Move from using tps or tsp6507x to tps6057x_pmic in a consistent manner.
> 
> Signed-off-by: Todd Fischer <todd.fischer at ridgerun.com>

Acked-by: Mark Brown <broonie at opensource.wolfsonicro.com>

From broonie at opensource.wolfsonmicro.com  Mon Apr  5 08:56:58 2010
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 5 Apr 2010 14:56:58 +0100
Subject: [PATCH 4/4]-V2 Add MFD driver for TPS6507x family of
	multi-function chips and move TPS6507x regulator driver from being
	stand-alone to using the MFD driver.
In-Reply-To: <1270244253-4234-5-git-send-email-todd.fischer@ridgerun.com>
References: <1270244253-4234-1-git-send-email-todd.fischer@ridgerun.com>
	<1270244253-4234-2-git-send-email-todd.fischer@ridgerun.com>
	<1270244253-4234-3-git-send-email-todd.fischer@ridgerun.com>
	<1270244253-4234-4-git-send-email-todd.fischer@ridgerun.com>
	<1270244253-4234-5-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <20100405135657.GI6580@rakim.wolfsonmicro.main>

On Fri, Apr 02, 2010 at 03:37:33PM -0600, Todd Fischer wrote:
> Add MFD driver for TPS6507x family of multi-function chips.  Move TPS6507x 
> regulator driver from being stand-alone driver to using the MFD TPS6507x driver.
> 
> Signed-off-by: Todd Fischer <todd.fischer at ridgerun.com>

One issue...

> +static int tps6507x_i2c_read_device(struct tps6507x_dev *tps6507x, char reg,
> +				  int bytes, void *dest)
> +{
> +	struct i2c_client *i2c = tps6507x->i2c_client;
> +	int ret;
> +
> +	ret = i2c_master_send(i2c, &reg, 1);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = i2c_master_recv(i2c, dest, bytes);
> +	if (ret < 0)
> +		return ret;
> +	if (ret != bytes)
> +		return -EIO;
> +	return 0;
> +}

Your register I/O functions don't have anything protecting them against
concurrent access.  This isn't really an issue for the writes by
themselves since they do a single transaction on the I2C bus so the I2C
layer concurrency protection ought to be enough but for reads you need
to send the register address first then read back the data, opening up
an issue.  A simple mutex in the read and write functions ought to cover
this.

From khilman at deeprootsystems.com  Mon Apr  5 16:06:44 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 05 Apr 2010 14:06:44 -0700
Subject: [PATCH 1/4] Davinci: Allow SOCs based on other ARM CPUs
In-Reply-To: <1269039457-27750-1-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Fri\, 19 Mar 2010 18\:57\:34 -0400")
References: <1269039457-27750-1-git-send-email-cyril@ti.com>
Message-ID: <87mxxhvcbf.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> Preliminary modification prior to adding support for TNETV107X based on
> ARM1176.  This change allows for CPUs other than ARM926T to be used for Davinci
> derivative SoCs.  Existing devices (DA8x and DMx) operate unchanged.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> ---

Thanks, this series looks good.  Applying all 4 to davinci git,
and queueing for 2.6.35 in davinci-next.

Kevin

>  arch/arm/Kconfig              |    1 -
>  arch/arm/mach-davinci/Kconfig |    2 ++
>  2 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 3b18128..2553c75 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -702,7 +702,6 @@ config ARCH_U300
>  
>  config ARCH_DAVINCI
>  	bool "TI DaVinci"
> -	select CPU_ARM926T
>  	select GENERIC_TIME
>  	select GENERIC_CLOCKEVENTS
>  	select GENERIC_GPIO
> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> index 0ebe185..0316e20 100644
> --- a/arch/arm/mach-davinci/Kconfig
> +++ b/arch/arm/mach-davinci/Kconfig
> @@ -7,6 +7,7 @@ config CP_INTC
>  	bool
>  
>  config ARCH_DAVINCI_DMx
> +	select CPU_ARM926T
>  	bool
>  
>  menu "TI DaVinci Implementations"
> @@ -41,6 +42,7 @@ config ARCH_DAVINCI_DA850
>  	select ARCH_HAS_CPUFREQ
>  
>  config ARCH_DAVINCI_DA8XX
> +	select CPU_ARM926T
>  	bool
>  
>  config ARCH_DAVINCI_DM365
> -- 
> 1.6.3.3
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From khilman at deeprootsystems.com  Mon Apr  5 16:54:06 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 05 Apr 2010 14:54:06 -0700
Subject: [PATCH v2 14/16] Davinci: tnetv107x gpio implementation
In-Reply-To: <1269553439-14886-15-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Thu\, 25 Mar 2010 17\:43\:57 -0400")
References: <1269553439-14886-1-git-send-email-cyril@ti.com>
	<1269553439-14886-2-git-send-email-cyril@ti.com>
	<1269553439-14886-3-git-send-email-cyril@ti.com>
	<1269553439-14886-4-git-send-email-cyril@ti.com>
	<1269553439-14886-5-git-send-email-cyril@ti.com>
	<1269553439-14886-6-git-send-email-cyril@ti.com>
	<1269553439-14886-7-git-send-email-cyril@ti.com>
	<1269553439-14886-8-git-send-email-cyril@ti.com>
	<1269553439-14886-9-git-send-email-cyril@ti.com>
	<1269553439-14886-10-git-send-email-cyril@ti.com>
	<1269553439-14886-11-git-send-email-cyril@ti.com>
	<1269553439-14886-12-git-send-email-cyril@ti.com>
	<1269553439-14886-13-git-send-email-cyril@ti.com>
	<1269553439-14886-14-git-send-email-cyril@ti.com>
	<1269553439-14886-15-git-send-email-cyril@ti.com>
Message-ID: <871vetva4h.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> Support for tnetv107x gpio controller.  Note that this controller does not use
> the gpio related definitions from davinci_soc_info.
>
> Further, this patch modifies davinci's inlined gpio functions to range check
> against davinci_soc_info contents instead of DAVINCI_N_GPIO.  This way,
> tnetv107x systems can define davinci_soc_info.gpio_num to 0 and bypass the
> inline routines.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> ---
>  arch/arm/mach-davinci/Makefile                 |    1 +
>  arch/arm/mach-davinci/gpio-tnetv107x.c         |  155 ++++++++++++++++++++++++
>  arch/arm/mach-davinci/include/mach/gpio.h      |    6 +-
>  arch/arm/mach-davinci/include/mach/tnetv107x.h |    4 +
>  4 files changed, 163 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm/mach-davinci/gpio-tnetv107x.c

I'm not crazy about this approach.

Both the existing functions and the new functions all do basically the same thing:
- read base + offset
- set/clear bit(s) based on GPIO#
- write base + offset

I think a cleaner solution to this would be to clean the existing GPIO
layer of direct knowledge of register layout.  Instead, convert the
gpio_controller struct into struct that holds register offsets from a
base.  This array of offsets is what needs to be different between
davinci and tnetv107x.

Also, Re: locking.  You shouldn't need to globally disable interrupts
here.  What I'm guessing you need is a mutex.

Kevin

From martin at ti.com  Mon Apr  5 16:52:31 2010
From: martin at ti.com (Ambrose, Martin)
Date: Mon, 5 Apr 2010 16:52:31 -0500
Subject: [PATCH v3 0/1] DA8XX/OMAP-L1XX: FB: Implement double buffering
In-Reply-To: <1270504278-15088-1-git-send-email-martin@ti.com>
References: <1270504278-15088-1-git-send-email-martin@ti.com>
Message-ID: <A24693684029E5489D1D202277BE89445316FACB@dlee02.ent.ti.com>

Changes from v2 patch set:
        . Fixed register clear sequence in isr to avoid spurious interrupt.
        . Removed unused wait queue variable in wait_for_vsync().
        . Moved initialization of vsync_wait prior to register_framebuffer.

From martin at ti.com  Mon Apr  5 16:54:59 2010
From: martin at ti.com (Ambrose, Martin)
Date: Mon, 5 Apr 2010 16:54:59 -0500
Subject: [PATCH v3 1/1] DA8XX/OMAP-L1XX: FB: Implement double buffering
In-Reply-To: <1270504278-15088-2-git-send-email-martin@ti.com>
References: <1270504278-15088-1-git-send-email-martin@ti.com>,
	<1270504278-15088-2-git-send-email-martin@ti.com>
Message-ID: <A24693684029E5489D1D202277BE89445316FACC@dlee02.ent.ti.com>

This work includes the following:
 . Implement handler for FBIO_WAITFORVSYNC ioctl.

 . Allocate the data and palette buffers separately.
   A consequence of this is that the palette and data loading is now
   done in different phases. And that the LCD must be disabled
   temporarily after the palette is loaded but this will only happen
   once after init and each time the palette is changed. I think this
   is OK.

 . Allocate two (ping and pong) framebuffers from memory.

 . Add pan_display handler which toggles the LCDC DMA registers between
   the ping and pong buffers.

Signed-off-by: Martin Ambrose <martin at ti.com>
---
 drivers/video/da8xx-fb.c |  301 +++++++++++++++++++++++++++++++++++----------
 include/video/da8xx-fb.h |    1 +
 2 files changed, 235 insertions(+), 67 deletions(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 8d244ba..cad7d45 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -36,7 +36,9 @@
 #define DRIVER_NAME "da8xx_lcdc"

 /* LCD Status Register */
+#define LCD_END_OF_FRAME1              BIT(9)
 #define LCD_END_OF_FRAME0              BIT(8)
+#define LCD_PL_LOAD_DONE               BIT(6)
 #define LCD_FIFO_UNDERFLOW             BIT(5)
 #define LCD_SYNC_LOST                  BIT(2)

@@ -58,11 +60,13 @@
 #define LCD_PALETTE_LOAD_MODE(x)       ((x) << 20)
 #define PALETTE_AND_DATA               0x00
 #define PALETTE_ONLY                   0x01
+#define DATA_ONLY                      0x02

 #define LCD_MONO_8BIT_MODE             BIT(9)
 #define LCD_RASTER_ORDER               BIT(8)
 #define LCD_TFT_MODE                   BIT(7)
 #define LCD_UNDERFLOW_INT_ENA          BIT(6)
+#define LCD_PL_ENABLE                  BIT(4)
 #define LCD_MONOCHROME_MODE            BIT(1)
 #define LCD_RASTER_ENABLE              BIT(0)
 #define LCD_TFT_ALT_ENABLE             BIT(23)
@@ -87,6 +91,10 @@
 #define  LCD_DMA_CTRL_REG                      0x40
 #define  LCD_DMA_FRM_BUF_BASE_ADDR_0_REG       0x44
 #define  LCD_DMA_FRM_BUF_CEILING_ADDR_0_REG    0x48
+#define  LCD_DMA_FRM_BUF_BASE_ADDR_1_REG       0x4C
+#define  LCD_DMA_FRM_BUF_CEILING_ADDR_1_REG    0x50
+
+#define LCD_NUM_BUFFERS        2

 #define WSI_TIMEOUT    50
 #define PALETTE_SIZE   256
@@ -111,13 +119,20 @@ static inline void lcdc_write(unsigned int val, unsigned int addr)
 struct da8xx_fb_par {
        resource_size_t p_palette_base;
        unsigned char *v_palette_base;
+       dma_addr_t              vram_phys;
+       unsigned long           vram_size;
+       void                    *vram_virt;
+       unsigned int            dma_start;
+       unsigned int            dma_end;
        struct clk *lcdc_clk;
        int irq;
        unsigned short pseudo_palette[16];
-       unsigned int databuf_sz;
        unsigned int palette_sz;
        unsigned int pxl_clk;
        int blank;
+       wait_queue_head_t       vsync_wait;
+       int                     vsync_flag;
+       int                     vsync_timeout;
 #ifdef CONFIG_CPU_FREQ
        struct notifier_block   freq_transition;
 #endif
@@ -148,9 +163,9 @@ static struct fb_fix_screeninfo da8xx_fb_fix __devinitdata = {
        .type = FB_TYPE_PACKED_PIXELS,
        .type_aux = 0,
        .visual = FB_VISUAL_PSEUDOCOLOR,
-       .xpanstep = 1,
+       .xpanstep = 0,
        .ypanstep = 1,
-       .ywrapstep = 1,
+       .ywrapstep = 0,
        .accel = FB_ACCEL_NONE
 };

@@ -221,22 +236,48 @@ static inline void lcd_disable_raster(void)

 static void lcd_blit(int load_mode, struct da8xx_fb_par *par)
 {
-       u32 tmp = par->p_palette_base + par->databuf_sz - 4;
-       u32 reg;
+       u32 start;
+       u32 end;
+       u32 reg_ras;
+       u32 reg_dma;
+
+       /* init reg to clear PLM (loading mode) fields */
+       reg_ras = lcdc_read(LCD_RASTER_CTRL_REG);
+       reg_ras &= ~(3 << 20);
+
+       reg_dma  = lcdc_read(LCD_DMA_CTRL_REG);
+
+       if (load_mode == LOAD_DATA) {
+               start    = par->dma_start;
+               end      = par->dma_end;
+
+               reg_ras |= LCD_PALETTE_LOAD_MODE(DATA_ONLY);
+               reg_dma |= LCD_END_OF_FRAME_INT_ENA;
+               reg_dma |= LCD_DUAL_FRAME_BUFFER_ENABLE;
+
+               lcdc_write(start, LCD_DMA_FRM_BUF_BASE_ADDR_0_REG);
+               lcdc_write(end, LCD_DMA_FRM_BUF_CEILING_ADDR_0_REG);
+               lcdc_write(start, LCD_DMA_FRM_BUF_BASE_ADDR_1_REG);
+               lcdc_write(end, LCD_DMA_FRM_BUF_CEILING_ADDR_1_REG);
+       } else if (load_mode == LOAD_PALETTE) {
+               start    = par->p_palette_base;
+               end      = start + par->palette_sz - 1;
+
+               reg_ras |= LCD_PALETTE_LOAD_MODE(PALETTE_ONLY);
+               reg_ras |= LCD_PL_ENABLE;
+
+               lcdc_write(start, LCD_DMA_FRM_BUF_BASE_ADDR_0_REG);
+               lcdc_write(end, LCD_DMA_FRM_BUF_CEILING_ADDR_0_REG);
+       }

-       /* Update the databuf in the hw. */
-       lcdc_write(par->p_palette_base, LCD_DMA_FRM_BUF_BASE_ADDR_0_REG);
-       lcdc_write(tmp, LCD_DMA_FRM_BUF_CEILING_ADDR_0_REG);
+       lcdc_write(reg_dma, LCD_DMA_CTRL_REG);
+       lcdc_write(reg_ras, LCD_RASTER_CTRL_REG);

-       /* Start the DMA. */
-       reg = lcdc_read(LCD_RASTER_CTRL_REG);
-       reg &= ~(3 << 20);
-       if (load_mode == LOAD_DATA)
-               reg |= LCD_PALETTE_LOAD_MODE(PALETTE_AND_DATA);
-       else if (load_mode == LOAD_PALETTE)
-               reg |= LCD_PALETTE_LOAD_MODE(PALETTE_ONLY);
-
-       lcdc_write(reg, LCD_RASTER_CTRL_REG);
+       /*
+        * The Raster enable bit must be set after all other control fields are
+        * set.
+        */
+       lcd_enable_raster();
 }

 /* Configure the Burst Size of DMA */
@@ -368,12 +409,8 @@ static int lcd_cfg_display(const struct lcd_ctrl_config *cfg)
 static int lcd_cfg_frame_buffer(struct da8xx_fb_par *par, u32 width, u32 height,
                u32 bpp, u32 raster_order)
 {
-       u32 bpl, reg;
+       u32 reg;

-       /* Disable Dual Frame Buffer. */
-       reg = lcdc_read(LCD_DMA_CTRL_REG);
-       lcdc_write(reg & ~LCD_DUAL_FRAME_BUFFER_ENABLE,
-                                               LCD_DMA_CTRL_REG);
        /* Set the Panel Width */
        /* Pixels per line = (PPL + 1)*16 */
        /*0x3F in bits 4..9 gives max horisontal resolution = 1024 pixels*/
@@ -410,9 +447,6 @@ static int lcd_cfg_frame_buffer(struct da8xx_fb_par *par, u32 width, u32 height,
                return -EINVAL;
        }

-       bpl = width * bpp / 8;
-       par->databuf_sz = height * bpl + par->palette_sz;
-
        return 0;
 }

@@ -421,8 +455,9 @@ static int fb_setcolreg(unsigned regno, unsigned red, unsigned green,
                              struct fb_info *info)
 {
        struct da8xx_fb_par *par = info->par;
-       unsigned short *palette = (unsigned short *)par->v_palette_base;
+       unsigned short *palette = (unsigned short *) par->v_palette_base;
        u_short pal;
+       int update_hw = 0;

        if (regno > 255)
                return 1;
@@ -439,8 +474,10 @@ static int fb_setcolreg(unsigned regno, unsigned red, unsigned green,
                pal |= (green & 0x00f0);
                pal |= (blue & 0x000f);

-               palette[regno] = pal;
-
+               if (palette[regno] != pal) {
+                       update_hw = 1;
+                       palette[regno] = pal;
+               }
        } else if ((info->var.bits_per_pixel == 16) && regno < 16) {
                red >>= (16 - info->var.red.length);
                red <<= info->var.red.offset;
@@ -453,9 +490,16 @@ static int fb_setcolreg(unsigned regno, unsigned red, unsigned green,

                par->pseudo_palette[regno] = red | green | blue;

-               palette[0] = 0x4000;
+               if (palette[0] != 0x4000) {
+                       update_hw = 1;
+                       palette[0] = 0x4000;
+               }
        }

+       /* Update the palette in the h/w as needed. */
+       if (update_hw)
+               lcd_blit(LOAD_PALETTE, par);
+
        return 0;
 }

@@ -541,15 +585,54 @@ static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,

 static irqreturn_t lcdc_irq_handler(int irq, void *arg)
 {
+       struct da8xx_fb_par *par = arg;
        u32 stat = lcdc_read(LCD_STAT_REG);
+       u32 reg_ras;

        if ((stat & LCD_SYNC_LOST) && (stat & LCD_FIFO_UNDERFLOW)) {
                lcd_disable_raster();
                lcdc_write(stat, LCD_STAT_REG);
                lcd_enable_raster();
-       } else
+       } else if (stat & LCD_PL_LOAD_DONE) {
+               /*
+                * Must disable raster before changing state of any control bit.
+                * And also must be disabled before clearing the PL loading
+                * interrupt via the following write to the status register. If
+                * this is done after then one gets multiple PL done interrupts.
+                */
+               lcd_disable_raster();
+
                lcdc_write(stat, LCD_STAT_REG);

+               /* Disable PL completion inerrupt */
+               reg_ras  = lcdc_read(LCD_RASTER_CTRL_REG);
+               reg_ras &= ~LCD_PL_ENABLE;
+               lcdc_write(reg_ras, LCD_RASTER_CTRL_REG);
+
+               /* Setup and start data loading mode */
+               lcd_blit(LOAD_DATA, par);
+       } else {
+               lcdc_write(stat, LCD_STAT_REG);
+
+               if (stat & LCD_END_OF_FRAME0) {
+                       lcdc_write(par->dma_start,
+                                  LCD_DMA_FRM_BUF_BASE_ADDR_0_REG);
+                       lcdc_write(par->dma_end,
+                                  LCD_DMA_FRM_BUF_CEILING_ADDR_0_REG);
+                       par->vsync_flag = 1;
+                       wake_up_interruptible(&par->vsync_wait);
+               }
+
+               if (stat & LCD_END_OF_FRAME1) {
+                       lcdc_write(par->dma_start,
+                                  LCD_DMA_FRM_BUF_BASE_ADDR_1_REG);
+                       lcdc_write(par->dma_end,
+                                  LCD_DMA_FRM_BUF_CEILING_ADDR_1_REG);
+                       par->vsync_flag = 1;
+                       wake_up_interruptible(&par->vsync_wait);
+               }
+       }
+
        return IRQ_HANDLED;
 }

@@ -654,9 +737,10 @@ static int __devexit fb_remove(struct platform_device *dev)

                unregister_framebuffer(info);
                fb_dealloc_cmap(&info->cmap);
-               dma_free_coherent(NULL, par->databuf_sz + PAGE_SIZE,
-                                       info->screen_base - PAGE_SIZE,
-                                       info->fix.smem_start);
+               dma_free_coherent(NULL, PALETTE_SIZE, par->v_palette_base,
+                                 par->p_palette_base);
+               dma_free_coherent(NULL, par->vram_size, par->vram_virt,
+                                 par->vram_phys);
                free_irq(par->irq, par);
                clk_disable(par->lcdc_clk);
                clk_put(par->lcdc_clk);
@@ -668,6 +752,39 @@ static int __devexit fb_remove(struct platform_device *dev)
        return 0;
 }

+/*
+ * Function to wait for vertical sync which for this LCD peripheral
+ * translates into waiting for the current raster frame to complete.
+ */
+static int fb_wait_for_vsync(struct fb_info *info)
+{
+       struct da8xx_fb_par *par = info->par;
+       int ret;
+
+       /*
+        * Set flag to 0 and wait for isr to set to 1. It would seem there is a
+        * race condition here where the ISR could have occured just before or
+        * just after this set. But since we are just coarsely waiting for
+        * a frame to complete then that's OK. i.e. if the frame completed
+        * just before this code executed then we have to wait another full
+        * frame time but there is no way to avoid such a situation. On the
+        * other hand if the frame completed just after then we don't need
+        * to wait long at all. Either way we are guaranteed to return to the
+        * user immediately after a frame completion which is all that is
+        * required.
+        */
+       par->vsync_flag = 0;
+       ret = wait_event_interruptible_timeout(par->vsync_wait,
+                                              par->vsync_flag != 0,
+                                              par->vsync_timeout);
+       if (ret < 0)
+               return ret;
+       if (ret == 0)
+               return -ETIMEDOUT;
+
+       return 0;
+}
+
 static int fb_ioctl(struct fb_info *info, unsigned int cmd,
                          unsigned long arg)
 {
@@ -697,6 +814,8 @@ static int fb_ioctl(struct fb_info *info, unsigned int cmd,
                                        sync_arg.pulse_width,
                                        sync_arg.front_porch);
                break;
+       case FBIO_WAITFORVSYNC:
+               return fb_wait_for_vsync(info);
        default:
                return -EINVAL;
        }
@@ -732,10 +851,47 @@ static int cfb_blank(int blank, struct fb_info *info)
        return ret;
 }

+/*
+ * Set new x,y offsets in the virtual display for the visible area and switch
+ * to the new mode.
+ */
+static int da8xx_pan_display(struct fb_var_screeninfo *var,
+                            struct fb_info *fbi)
+{
+       int ret = 0;
+       struct fb_var_screeninfo new_var;
+       struct da8xx_fb_par         *par = fbi->par;
+       struct fb_fix_screeninfo    *fix = &fbi->fix;
+       unsigned int end;
+       unsigned int start;
+
+       if (var->xoffset != fbi->var.xoffset ||
+                       var->yoffset != fbi->var.yoffset) {
+               memcpy(&new_var, &fbi->var, sizeof(new_var));
+               new_var.xoffset = var->xoffset;
+               new_var.yoffset = var->yoffset;
+               if (fb_check_var(&new_var, fbi))
+                       ret = -EINVAL;
+               else {
+                       memcpy(&fbi->var, &new_var, sizeof(new_var));
+
+                       start   = fix->smem_start +
+                               new_var.yoffset * fix->line_length +
+                               new_var.xoffset * var->bits_per_pixel / 8;
+                       end     = start + var->yres * fix->line_length - 1;
+                       par->dma_start  = start;
+                       par->dma_end    = end;
+               }
+       }
+
+       return ret;
+}
+
 static struct fb_ops da8xx_fb_ops = {
        .owner = THIS_MODULE,
        .fb_check_var = fb_check_var,
        .fb_setcolreg = fb_setcolreg,
+       .fb_pan_display = da8xx_pan_display,
        .fb_ioctl = fb_ioctl,
        .fb_fillrect = cfb_fillrect,
        .fb_copyarea = cfb_copyarea,
@@ -829,40 +985,53 @@ static int __init fb_probe(struct platform_device *device)
        }

        /* allocate frame buffer */
-       da8xx_fb_info->screen_base = dma_alloc_coherent(NULL,
-                                       par->databuf_sz + PAGE_SIZE,
-                                       (resource_size_t *)
-                                       &da8xx_fb_info->fix.smem_start,
-                                       GFP_KERNEL | GFP_DMA);
-
-       if (!da8xx_fb_info->screen_base) {
+       par->vram_size = lcdc_info->width * lcdc_info->height * lcd_cfg->bpp;
+       par->vram_size = PAGE_ALIGN(par->vram_size/8);
+       par->vram_size = par->vram_size * LCD_NUM_BUFFERS;
+
+       par->vram_virt = dma_alloc_coherent(NULL,
+                                           par->vram_size,
+                                           (resource_size_t *) &par->vram_phys,
+                                           GFP_KERNEL | GFP_DMA);
+       if (!par->vram_virt) {
                dev_err(&device->dev,
                        "GLCD: kmalloc for frame buffer failed\n");
                ret = -EINVAL;
                goto err_release_fb;
        }

-       /* move palette base pointer by (PAGE_SIZE - palette_sz) bytes */
-       par->v_palette_base = da8xx_fb_info->screen_base +
-                               (PAGE_SIZE - par->palette_sz);
-       par->p_palette_base = da8xx_fb_info->fix.smem_start +
-                               (PAGE_SIZE - par->palette_sz);
-
-       /* the rest of the frame buffer is pixel data */
-       da8xx_fb_info->screen_base = par->v_palette_base + par->palette_sz;
-       da8xx_fb_fix.smem_start = par->p_palette_base + par->palette_sz;
-       da8xx_fb_fix.smem_len = par->databuf_sz - par->palette_sz;
-       da8xx_fb_fix.line_length = (lcdc_info->width * lcd_cfg->bpp) / 8;
+       da8xx_fb_info->screen_base = (char __iomem *) par->vram_virt;
+       da8xx_fb_fix.smem_start    = par->vram_phys;
+       da8xx_fb_fix.smem_len      = par->vram_size;
+       da8xx_fb_fix.line_length   = (lcdc_info->width * lcd_cfg->bpp) / 8;
+
+       par->dma_start = par->vram_phys;
+       par->dma_end   = par->dma_start + lcdc_info->height *
+               da8xx_fb_fix.line_length - 1;
+
+       /* allocate palette buffer */
+       par->v_palette_base = dma_alloc_coherent(NULL,
+                                              PALETTE_SIZE,
+                                              (resource_size_t *)
+                                              &par->p_palette_base,
+                                              GFP_KERNEL | GFP_DMA);
+       if (!par->v_palette_base) {
+               dev_err(&device->dev,
+                       "GLCD: kmalloc for palette buffer failed\n");
+               ret = -EINVAL;
+               goto err_release_fb_mem;
+       }
+       memset(par->v_palette_base, 0, PALETTE_SIZE);

        par->irq = platform_get_irq(device, 0);
        if (par->irq < 0) {
                ret = -ENOENT;
-               goto err_release_fb_mem;
+               goto err_release_pl_mem;
        }

        ret = request_irq(par->irq, lcdc_irq_handler, 0, DRIVER_NAME, par);
        if (ret)
-               goto err_release_fb_mem;
+               goto err_release_pl_mem;

        /* Initialize par */
        da8xx_fb_info->var.bits_per_pixel = lcd_cfg->bpp;
@@ -870,8 +1039,8 @@ static int __init fb_probe(struct platform_device *device)
        da8xx_fb_var.xres = lcdc_info->width;
        da8xx_fb_var.xres_virtual = lcdc_info->width;

-       da8xx_fb_var.yres = lcdc_info->height;
-       da8xx_fb_var.yres_virtual = lcdc_info->height;
+       da8xx_fb_var.yres         = lcdc_info->height;
+       da8xx_fb_var.yres_virtual = lcdc_info->height * LCD_NUM_BUFFERS;

        da8xx_fb_var.grayscale =
            lcd_cfg->p_disp_panel->panel_shade == MONOCHROME ? 1 : 0;
@@ -892,18 +1061,18 @@ static int __init fb_probe(struct platform_device *device)
        ret = fb_alloc_cmap(&da8xx_fb_info->cmap, PALETTE_SIZE, 0);
        if (ret)
                goto err_free_irq;
-
-       /* First palette_sz byte of the frame buffer is the palette */
        da8xx_fb_info->cmap.len = par->palette_sz;

-       /* Flush the buffer to the screen. */
-       lcd_blit(LOAD_DATA, par);
-
        /* initialize var_screeninfo */
        da8xx_fb_var.activate = FB_ACTIVATE_FORCE;
        fb_set_var(da8xx_fb_info, &da8xx_fb_var);

        dev_set_drvdata(&device->dev, da8xx_fb_info);
+
+       /* initialize the vsync wait queue */
+       init_waitqueue_head(&par->vsync_wait);
+       par->vsync_timeout = HZ / 5;
+
        /* Register the Frame Buffer  */
        if (register_framebuffer(da8xx_fb_info) < 0) {
                dev_err(&device->dev,
@@ -919,10 +1088,6 @@ static int __init fb_probe(struct platform_device *device)
                goto err_cpu_freq;
        }
 #endif
-
-       /* enable raster engine */
-       lcd_enable_raster();
-
        return 0;

 #ifdef CONFIG_CPU_FREQ
@@ -936,10 +1101,12 @@ err_dealloc_cmap:
 err_free_irq:
        free_irq(par->irq, par);

+err_release_pl_mem:
+       dma_free_coherent(NULL, PALETTE_SIZE, par->v_palette_base,
+                         par->p_palette_base);
+
 err_release_fb_mem:
-       dma_free_coherent(NULL, par->databuf_sz + PAGE_SIZE,
-                               da8xx_fb_info->screen_base - PAGE_SIZE,
-                               da8xx_fb_info->fix.smem_start);
+       dma_free_coherent(NULL, par->vram_size, par->vram_virt, par->vram_phys);

 err_release_fb:
        framebuffer_release(da8xx_fb_info);
diff --git a/include/video/da8xx-fb.h b/include/video/da8xx-fb.h
index 89d43b3..6316cda 100644
--- a/include/video/da8xx-fb.h
+++ b/include/video/da8xx-fb.h
@@ -99,6 +99,7 @@ struct lcd_sync_arg {
 #define FBIPUT_COLOR           _IOW('F', 6, int)
 #define FBIPUT_HSYNC           _IOW('F', 9, int)
 #define FBIPUT_VSYNC           _IOW('F', 10, int)
+#define FBIO_WAITFORVSYNC      _IOW('F', 0x20, u_int32_t)

 #endif  /* ifndef DA8XX_FB_H */

--
1.6.6.1


From khilman at deeprootsystems.com  Mon Apr  5 17:06:10 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 05 Apr 2010 15:06:10 -0700
Subject: [PATCH 13/14] Davinci: simplified debug macros
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E64F6A88@dbde02.ent.ti.com>
	(Sekhar Nori's message of "Thu\, 25 Mar 2010 21\:58\:04 +0530")
References: <1269476345-16111-1-git-send-email-cyril@ti.com>
	<1269476345-16111-2-git-send-email-cyril@ti.com>
	<1269476345-16111-3-git-send-email-cyril@ti.com>
	<1269476345-16111-4-git-send-email-cyril@ti.com>
	<1269476345-16111-5-git-send-email-cyril@ti.com>
	<1269476345-16111-6-git-send-email-cyril@ti.com>
	<1269476345-16111-7-git-send-email-cyril@ti.com>
	<1269476345-16111-8-git-send-email-cyril@ti.com>
	<1269476345-16111-9-git-send-email-cyril@ti.com>
	<1269476345-16111-10-git-send-email-cyril@ti.com>
	<1269476345-16111-11-git-send-email-cyril@ti.com>
	<1269476345-16111-12-git-send-email-cyril@ti.com>
	<1269476345-16111-13-git-send-email-cyril@ti.com>
	<1269476345-16111-14-git-send-email-cyril@ti.com>
	<4BAB408A.7040706@mvista.com>
	<8FFAA0BFC4E5374B8F85F65FE1F2BFA58B937985@dlee02.ent.ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E64F6A88@dbde02.ent.ti.com>
Message-ID: <87pr2dtuzx.fsf@deeprootsystems.com>

"Nori, Sekhar" <nsekhar at ti.com> writes:

> On Thu, Mar 25, 2010 at 20:39:02, Chemparathy, Cyril wrote:
>> Sergei,
>>
>> [...]
>> > > > +#if defined(CONFIG_ARCH_DAVINCI_DMx)
>> > > > +#define UART_PHYS      DAVINCI_UART0_BASE
>> > > > +#define UART_VIRT      IO_ADDRESS(UART_PHYS)
>> > > > +#endif
>> > >
>> > >    These UART addressed are machine-, not arch-specific.
>> >
>> > Thanks.  Will change in v2.
>>
>> On second thoughts, if we were to make these definitions machine specific, it would explode into excruciating verbosity:
>>
>> #if     defined(CONFIG_MACH_DAVINCI_EVM)        || \
>>         defined(CONFIG_MACH_SFFSDR)             || \
>>         defined(CONFIG_MACH_NEUROS_OSD2)        || \
>>         defined(CONFIG_MACH_DAVINCI_DM355_EVM)  || \
>>         defined(CONFIG_MACH_DM355_LEOPARD)      || \
>>         defined(CONFIG_MACH_DAVINCI_DM6467_EVM) || \
>>         defined(CONFIG_MACH_DAVINCI_DM6467TEVM) || \
>>         defined(CONFIG_MACH_DAVINCI_DM365_EVM)
>>
>> Is that the preferred approach?  Would we be better off leaving UART selection arch-specific for now and making it machine-specific as and when a new board deviates from the norm on that arch?
>>
>
> How about trying to do some runtime detection of the enabled
> UART by checking the enabled status in PWREMU_MGMT register of
> each UART starting from UART0. You would probably also need a
> fall-back option that can be chosen by boards on which this is
> guaranteed not to work (they can provide the debug UART# in kernel
> configuration).
>
> I quickly checked DM644x and OMAP-L138 documentation and both
> of these have the register implemented and have the UART reset
> by default.
>
> OMAP2/3 seems to manage this by writing a pattern to the UART SCR
> registers, but unfortunately none of the DaVinci bootloaders
> support this.

Actually, we don't need bootloader support for this.

On OMAP, we do this in the uncompress code.  See:
arch/arm/plat-omap/include/plat/uncompress.h, and in this commit[1] for details.

Rather than continuing to hack the current hack, I'd like to see
something similar on DaVinci.  This will also remove one more barrier
to multiple-SoC support.

Also, we don't necessarily have to use the UART1 scratchpad register.
All we need is some temporary, writable register that is available on
all supported SoCs.  Any suggestions?

Kevin


[1] 
commit 0c8219f0302d0d27fda52c790d38406801e547ec
Author: Tony Lindgren <tony at atomide.com>
Date:   Mon Feb 15 08:49:01 2010 -0800

    omap: Make uncompress code and DEBUG_LL code generic
    
    Define arch_decomp_setup() the same way as some other
    architectures do. Use arch_id to configure the debug uart
    based on the machine_is by storing it into the uart
    scratchpad register for DEBUG_LL code to use.
    
    Signed-off-by: Tony Lindgren <tony at atomide.com>


From khilman at deeprootsystems.com  Mon Apr  5 17:07:24 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 05 Apr 2010 15:07:24 -0700
Subject: [PATCH v2 09/16] Davinci: tnetv107x SOC specific header
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E66990F8@dbde02.ent.ti.com>
	(Sekhar Nori's message of "Mon\, 5 Apr 2010 11\:48\:20 +0530")
References: <1269553439-14886-1-git-send-email-cyril@ti.com>
	<1269553439-14886-2-git-send-email-cyril@ti.com>
	<1269553439-14886-3-git-send-email-cyril@ti.com>
	<1269553439-14886-4-git-send-email-cyril@ti.com>
	<1269553439-14886-5-git-send-email-cyril@ti.com>
	<1269553439-14886-6-git-send-email-cyril@ti.com>
	<1269553439-14886-7-git-send-email-cyril@ti.com>
	<1269553439-14886-8-git-send-email-cyril@ti.com>
	<1269553439-14886-9-git-send-email-cyril@ti.com>
	<1269553439-14886-10-git-send-email-cyril@ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E66990F8@dbde02.ent.ti.com>
Message-ID: <87k4sltuxv.fsf@deeprootsystems.com>

"Nori, Sekhar" <nsekhar at ti.com> writes:

> On Fri, Mar 26, 2010 at 03:13:52, Chemparathy, Cyril wrote:
>> Added on-chip peripheral base addresses so tnetv107x SOC header.
>>
>
> There should be no need to define the full
> list of base addresses in one place because
> the are typically needed only at only one place
> (near the resource definition).
>
> Just add the define where needed and use it.

Agreed.

These should only ever be used when defining a platform_device or in
the low-level core code.

Kevin

From khilman at deeprootsystems.com  Mon Apr  5 17:12:21 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 05 Apr 2010 15:12:21 -0700
Subject: [PATCH] Add touch screen input driver for TPS6507x family of
	multi-function chips.
In-Reply-To: <1270336600-1664-1-git-send-email-todd.fischer@ridgerun.com>
	(Todd Fischer's message of "Sat\, 3 Apr 2010 17\:16\:40 -0600")
References: <1270336600-1664-1-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <87eiittupm.fsf@deeprootsystems.com>

Todd Fischer <todd.fischer at ridgerun.com> writes:

> The TPS6507x family of Texas Instruments power management ICs (pmic)
> are multi-function chips that include voltage regulation and touch
> screen controller capabilities.  This patch adds a touch screen
> input driver for the TPS6507x pmic.  There was an existing regulator
> driver.  Before the touch screen driver could be added, a multi-function
> device (MFD) driver was needed and the regulator driver modified to
> use the MDF driver.  Patches for these changes have been posted and
> reviewed.  The TPS6507x touch screen driver applies cleanly to the
> MFD GIT repo after the above referenced patches are applied.  If I
> should use a different approach for the touch screen driver, please
> let me know.
>
> Signed-off-by: Todd Fischer <todd.fischer at ridgerun.com>
> ---
>  arch/arm/mach-davinci/board-da850-evm.c |   12 +

Could you separate out the da850 board support from the driver please?

To avoid convlicts with other arch code, I will merge the board
support via davinci git after the driver is merged via the appropriate
subsystem tree.

Kevin

>  drivers/input/touchscreen/Kconfig       |   13 +
>  drivers/input/touchscreen/Makefile      |    1 +
>  drivers/input/touchscreen/tps6507x-ts.c |  400 +++++++++++++++++++++++++++++++
>  drivers/mfd/tps6507x.c                  |    3 +
>  include/linux/input/tps6507x-ts.h       |   24 ++
>  include/linux/mfd/tps6507x.h            |    2 +
>  7 files changed, 455 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/input/touchscreen/tps6507x-ts.c
>  create mode 100644 include/linux/input/tps6507x-ts.h
>
> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index d059924..b3cbb32 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -25,6 +25,8 @@
>  #include <linux/mtd/partitions.h>
>  #include <linux/mtd/physmap.h>
>  #include <linux/regulator/machine.h>
> +#include <linux/mfd/tps6507x.h>
> +#include <linux/input/tps6507x-ts.h>
>  
>  #include <asm/mach-types.h>
>  #include <asm/mach/arch.h>
> @@ -534,8 +536,18 @@ struct regulator_init_data tps65070_regulator_data[] = {
>  	},
>  };
>  
> +static struct touchscreen_init_data tps6507x_touchscreen_data = {
> +	.poll_period =  30,	/* ms between touch samples */
> +	.min_pressure = 0x30,	/* minimum pressure to trigger touch */
> +	.vref = 0,		/* turn off vref when not using A/D */
> +	.vendor = 0,		/* /sys/class/input/input?/id/vendor */
> +	.product = 65070,	/* /sys/class/input/input?/id/product */
> +	.version = 0x100,	/* /sys/class/input/input?/id/version */
> +};
> +
>  static struct tps6507x_board tps_board = {
>  	.tps6507x_pmic_init_data = &tps65070_regulator_data[0],
> +	.tps6507x_ts_init_data = &tps6507x_touchscreen_data,
>  };
>  
>  static struct i2c_board_info __initdata da850evm_tps65070_info[] = {
> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> index 8a8fa4d..6166aa8 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -594,4 +594,17 @@ config TOUCHSCREEN_PCAP
>  
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called pcap_ts.
> +
> +config TOUCHSCREEN_TPS6507X
> +	tristate "TPS6507x based touchscreens"
> +	depends on I2C
> +	help
> +	  Say Y here if you have a TPS6507x based touchscreen
> +	  controller.
> +
> +	  If unsure, say N.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called tps6507x_ts.
> +
>  endif
> diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
> index 7fef7d5..cfa83d0 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -46,3 +46,4 @@ obj-$(CONFIG_TOUCHSCREEN_WM97XX_ATMEL)	+= atmel-wm97xx.o
>  obj-$(CONFIG_TOUCHSCREEN_WM97XX_MAINSTONE)	+= mainstone-wm97xx.o
>  obj-$(CONFIG_TOUCHSCREEN_WM97XX_ZYLONITE)	+= zylonite-wm97xx.o
>  obj-$(CONFIG_TOUCHSCREEN_W90X900)	+= w90p910_ts.o
> +obj-$(CONFIG_TOUCHSCREEN_TPS6507X)	+= tps6507x-ts.o
> diff --git a/drivers/input/touchscreen/tps6507x-ts.c b/drivers/input/touchscreen/tps6507x-ts.c
> new file mode 100644
> index 0000000..5de80a1
> --- /dev/null
> +++ b/drivers/input/touchscreen/tps6507x-ts.c
> @@ -0,0 +1,400 @@
> +/*
> + * drivers/input/touchscreen/tps6507x_ts.c
> + *
> + * Touchscreen driver for the tps6507x chip.
> + *
> + * Copyright (c) 2009 RidgeRun (todd.fischer at ridgerun.com)
> + *
> + * Credits:
> + *
> + *    Using code from tsc2007, MtekVision Co., Ltd.
> + *
> + * For licencing details see kernel-base/COPYING
> + *
> + * TPS65070, TPS65073, TPS650731, and TPS650732 support
> + * 10 bit touch screen interface.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/workqueue.h>
> +#include <linux/slab.h>
> +#include <linux/input.h>
> +#include <linux/platform_device.h>
> +#include <linux/mfd/tps6507x.h>
> +#include <linux/input/tps6507x-ts.h>
> +#include <linux/delay.h>
> +
> +#define TSC_DEFAULT_POLL_PERIOD 30 /* ms */
> +#define TPS_DEFAULT_MIN_PRESSURE 0x30
> +#define MAX_10BIT ((1 << 10) - 1)
> +
> +#define	TPS6507X_ADCONFIG_CONVERT_TS (TPS6507X_ADCONFIG_AD_ENABLE | \
> +					 TPS6507X_ADCONFIG_START_CONVERSION | \
> +					 TPS6507X_ADCONFIG_INPUT_REAL_TSC)
> +#define	TPS6507X_ADCONFIG_POWER_DOWN_TS (TPS6507X_ADCONFIG_INPUT_REAL_TSC)
> +
> +struct ts_event {
> +	u16	x;
> +	u16	y;
> +	u16	pressure;
> +};
> +
> +struct tps6507x_ts {
> +	struct input_dev	*input_dev;
> +	struct device		*dev;
> +	char			phys[32];
> +	struct workqueue_struct *wq;
> +	struct delayed_work	work;
> +	unsigned		polling;	/* polling is active */
> +	struct ts_event		tc;
> +	struct tps6507x_dev	*mfd;
> +	u16			model;
> +	unsigned		pendown;
> +	int			irq;
> +	void			(*clear_penirq)(void);
> +	unsigned long		poll_period;	/* ms */
> +	u16			min_pressure;
> +	int			vref;		/* non-zero to leave vref on */
> +};
> +
> +static int tps6507x_read_u8(struct tps6507x_ts *tsc, u8 reg, u8 *data)
> +{
> +	int err;
> +
> +	err = tsc->mfd->read_dev(tsc->mfd, reg, 1, data);
> +
> +	if (err)
> +		return err;
> +
> +	return 0;
> +}
> +
> +static int tps6507x_write_u8(struct tps6507x_ts *tsc, u8 reg, u8 data)
> +{
> +	return tsc->mfd->write_dev(tsc->mfd, reg, 1, &data);
> +}
> +
> +static s32 tps6507x_adc_conversion(struct tps6507x_ts *tsc,
> +				   u8 tsc_mode, u16 *value)
> +{
> +	s32 ret;
> +	u8 adc_status;
> +	u8 result;
> +
> +	/* Route input signal to A/D converter */
> +
> +	ret = tps6507x_write_u8(tsc, TPS6507X_REG_TSCMODE, tsc_mode);
> +	if (ret) {
> +		dev_err(tsc->dev, "TSC mode read failed\n");
> +		goto err;
> +	}
> +
> +	/* Start A/D conversion */
> +
> +	ret = tps6507x_write_u8(tsc, TPS6507X_REG_ADCONFIG,
> +				TPS6507X_ADCONFIG_CONVERT_TS);
> +	if (ret) {
> +		dev_err(tsc->dev, "ADC config write failed\n");
> +		return ret;
> +	}
> +
> +	do {
> +		ret = tps6507x_read_u8(tsc, TPS6507X_REG_ADCONFIG,
> +				       &adc_status);
> +		if (ret) {
> +			dev_err(tsc->dev, "ADC config read failed\n");
> +			goto err;
> +		}
> +	} while (adc_status & TPS6507X_ADCONFIG_START_CONVERSION);
> +
> +	ret = tps6507x_read_u8(tsc, TPS6507X_REG_ADRESULT_2, &result);
> +	if (ret) {
> +		dev_err(tsc->dev, "ADC result 2 read failed\n");
> +		goto err;
> +	}
> +
> +	*value = (result & TPS6507X_REG_ADRESULT_2_MASK) << 8;
> +
> +	ret = tps6507x_read_u8(tsc, TPS6507X_REG_ADRESULT_1, &result);
> +	if (ret) {
> +		dev_err(tsc->dev, "ADC result 1 read failed\n");
> +		goto err;
> +	}
> +
> +	*value |= result;
> +
> +	dev_dbg(tsc->dev, "TSC channel %d = 0x%X\n", tsc_mode, *value);
> +
> +err:
> +	return ret;
> +}
> +
> +/* Need to call tps6507x_adc_standby() after using A/D converter for the
> + * touch screen interrupt to work properly.
> + */
> +
> +static s32 tps6507x_adc_standby(struct tps6507x_ts *tsc)
> +{
> +	s32 ret;
> +	s32 loops = 0;
> +	u8 val;
> +
> +	ret = tps6507x_write_u8(tsc,  TPS6507X_REG_ADCONFIG,
> +				TPS6507X_ADCONFIG_INPUT_TSC);
> +	if (ret)
> +		return ret;
> +
> +	ret = tps6507x_write_u8(tsc, TPS6507X_REG_TSCMODE,
> +				TPS6507X_TSCMODE_STANDBY);
> +	if (ret)
> +		return ret;
> +
> +	ret = tps6507x_read_u8(tsc, TPS6507X_REG_INT, &val);
> +	if (ret)
> +		return ret;
> +
> +	while (val & TPS6507X_REG_TSC_INT) {
> +		mdelay(10);
> +		ret = tps6507x_read_u8(tsc, TPS6507X_REG_INT, &val);
> +		if (ret)
> +			return ret;
> +		loops++;
> +	}
> +
> +	return ret;
> +}
> +
> +static void tps6507x_ts_handler(struct work_struct *work)
> +{
> +	struct tps6507x_ts *tsc =  container_of(work,
> +				struct tps6507x_ts, work.work);
> +	struct input_dev *input_dev = tsc->input_dev;
> +	int pendown;
> +	int schd;
> +	int poll = 0;
> +	s32 ret;
> +
> +	ret =  tps6507x_adc_conversion(tsc, TPS6507X_TSCMODE_PRESSURE,
> +				       &tsc->tc.pressure);
> +	if (ret)
> +		goto done;
> +
> +	pendown = tsc->tc.pressure > tsc->min_pressure;
> +
> +	if (unlikely(!pendown && tsc->pendown)) {
> +		dev_dbg(tsc->dev, "UP\n");
> +		input_report_key(input_dev, BTN_TOUCH, 0);
> +		input_report_abs(input_dev, ABS_PRESSURE, 0);
> +		input_sync(input_dev);
> +		tsc->pendown = 0;
> +	}
> +
> +	if (pendown) {
> +
> +		if (!tsc->pendown) {
> +			dev_dbg(tsc->dev, "DOWN\n");
> +			input_report_key(input_dev, BTN_TOUCH, 1);
> +		} else
> +			dev_dbg(tsc->dev, "still down\n");
> +
> +		ret =  tps6507x_adc_conversion(tsc, TPS6507X_TSCMODE_X_POSITION,
> +					       &tsc->tc.x);
> +		if (ret)
> +			goto done;
> +
> +		ret =  tps6507x_adc_conversion(tsc, TPS6507X_TSCMODE_Y_POSITION,
> +					       &tsc->tc.y);
> +		if (ret)
> +			goto done;
> +
> +		input_report_abs(input_dev, ABS_X, tsc->tc.x);
> +		input_report_abs(input_dev, ABS_Y, tsc->tc.y);
> +		input_report_abs(input_dev, ABS_PRESSURE, tsc->tc.pressure);
> +		input_sync(input_dev);
> +		tsc->pendown = 1;
> +		poll = 1;
> +	}
> +
> +done:
> +	/* always poll if not using interrupts */
> +	poll = 1;
> +
> +	if (poll) {
> +		schd = queue_delayed_work(tsc->wq, &tsc->work,
> +					  tsc->poll_period * HZ / 1000);
> +		if (schd)
> +			tsc->polling = 1;
> +		else {
> +			tsc->polling = 0;
> +			dev_err(tsc->dev, "re-schedule failed");
> +		}
> +	} else
> +		tsc->polling = 0;
> +
> +	ret = tps6507x_adc_standby(tsc);
> +}
> +
> +static int tps6507x_ts_probe(struct platform_device *pdev)
> +{
> +	int error;
> +	struct tps6507x_ts *tsc;
> +	struct tps6507x_dev *tps6507x_dev = dev_get_drvdata(pdev->dev.parent);
> +	struct touchscreen_init_data *init_data;
> +	struct input_dev *input_dev;
> +	struct tps6507x_board *tps_board;
> +	int schd;
> +
> +	/**
> +	 * tps_board points to pmic related constants
> +	 * coming from the board-evm file.
> +	 */
> +
> +	tps_board = (struct tps6507x_board *)tps6507x_dev->dev->platform_data;
> +
> +	if (!tps_board) {
> +		dev_err(tps6507x_dev->dev,
> +			"Could not find tps6507x platform data\n");
> +		return -EIO;
> +	}
> +
> +	/**
> +	 * init_data points to array of regulator_init structures
> +	 * coming from the board-evm file.
> +	 */
> +
> +	init_data = tps_board->tps6507x_ts_init_data;
> +
> +	tsc = kzalloc(sizeof(struct tps6507x_ts), GFP_KERNEL);
> +	if (!tsc) {
> +		dev_err(tps6507x_dev->dev, "failed to allocate driver data\n");
> +		error = -ENOMEM;
> +		goto err0;
> +	}
> +
> +	tps6507x_dev->ts = tsc;
> +	tsc->mfd = tps6507x_dev;
> +	tsc->dev = tps6507x_dev->dev;
> +	input_dev = input_allocate_device();
> +	if (!input_dev) {
> +		dev_err(tsc->dev, "Failed to allocate input device.\n");
> +		error = -ENOMEM;
> +		goto err1;
> +	}
> +
> +	input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
> +	input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
> +
> +	input_set_abs_params(input_dev, ABS_X, 0, MAX_10BIT, 0, 0);
> +	input_set_abs_params(input_dev, ABS_Y, 0, MAX_10BIT, 0, 0);
> +	input_set_abs_params(input_dev, ABS_PRESSURE, 0, MAX_10BIT, 0, 0);
> +
> +	input_dev->name = "TPS6507x Touchscreen";
> +	input_dev->id.bustype = BUS_I2C;
> +	input_dev->dev.parent = tsc->dev;
> +
> +	snprintf(tsc->phys, sizeof(tsc->phys),
> +		 "%s/input0", dev_name(tsc->dev));
> +	input_dev->phys = tsc->phys;
> +
> +	dev_dbg(tsc->dev, "device: %s\n", input_dev->phys);
> +
> +	input_set_drvdata(input_dev, tsc);
> +
> +	tsc->input_dev = input_dev;
> +
> +	INIT_DELAYED_WORK(&tsc->work, tps6507x_ts_handler);
> +	tsc->wq = create_workqueue("TPS6507x Touchscreen");
> +
> +	if (init_data) {
> +		tsc->poll_period = init_data->poll_period;
> +		tsc->vref = init_data->vref;
> +		tsc->min_pressure = init_data->min_pressure;
> +		input_dev->id.vendor = init_data->vendor;
> +		input_dev->id.product = init_data->product;
> +		input_dev->id.version = init_data->version;
> +	} else {
> +		tsc->poll_period = TSC_DEFAULT_POLL_PERIOD;
> +		tsc->min_pressure = TPS_DEFAULT_MIN_PRESSURE;
> +	}
> +
> +	error = tps6507x_adc_standby(tsc);
> +	if (error)
> +		goto err2;
> +
> +	error = input_register_device(input_dev);
> +	if (error)
> +		goto err2;
> +
> +	schd = queue_delayed_work(tsc->wq, &tsc->work,
> +				  tsc->poll_period * HZ / 1000);
> +
> +	if (schd)
> +		tsc->polling = 1;
> +	else {
> +		tsc->polling = 0;
> +		dev_err(tsc->dev, "schedule failed");
> +		goto err2;
> +	 }
> +
> +	return 0;
> +
> +err2:
> +	cancel_delayed_work(&tsc->work);
> +	flush_workqueue(tsc->wq);
> +	destroy_workqueue(tsc->wq);
> +	tsc->wq = 0;
> +	input_free_device(input_dev);
> +err1:
> +	kfree(tsc);
> +	tps6507x_dev->ts = NULL;
> +err0:
> +	return error;
> +}
> +
> +static int __devexit tps6507x_ts_remove(struct platform_device *pdev)
> +{
> +	struct tps6507x_dev *tps6507x_dev = platform_get_drvdata(pdev);
> +	struct tps6507x_ts *tsc = tps6507x_dev->ts;
> +	struct input_dev *input_dev = tsc->input_dev;
> +
> +	if (!tsc)
> +		return 0;
> +
> +	cancel_delayed_work(&tsc->work);
> +	flush_workqueue(tsc->wq);
> +	destroy_workqueue(tsc->wq);
> +	tsc->wq = 0;
> +
> +	input_free_device(input_dev);
> +
> +	tps6507x_dev->ts = NULL;
> +	kfree(tsc);
> +
> +	return 0;
> +}
> +
> +static struct platform_driver tps6507x_ts_driver = {
> +	.driver = {
> +		.name = "tps6507x-ts",
> +		.owner = THIS_MODULE,
> +	},
> +	.probe = tps6507x_ts_probe,
> +	.remove = __devexit_p(tps6507x_ts_remove),
> +};
> +
> +static int __init tps6507x_ts_init(void)
> +{
> +	return platform_driver_register(&tps6507x_ts_driver);
> +}
> +module_init(tps6507x_ts_init);
> +
> +static void __exit tps6507x_ts_exit(void)
> +{
> +	platform_driver_unregister(&tps6507x_ts_driver);
> +}
> +module_exit(tps6507x_ts_exit);
> +
> +MODULE_AUTHOR("Todd Fischer <todd.fischer at ridgerun.com>");
> +MODULE_DESCRIPTION("TPS6507x - TouchScreen driver");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:tps6507x-tsc");
> diff --git a/drivers/mfd/tps6507x.c b/drivers/mfd/tps6507x.c
> index edda9ff..d05c52d 100644
> --- a/drivers/mfd/tps6507x.c
> +++ b/drivers/mfd/tps6507x.c
> @@ -25,6 +25,9 @@ static struct mfd_cell tps6507x_devs[] = {
>  	{
>  		.name = "tps6507x-pmic",
>  	},
> +	{
> +		.name = "tps6507x-ts",
> +	},
>  };
>  
>  
> diff --git a/include/linux/input/tps6507x-ts.h b/include/linux/input/tps6507x-ts.h
> new file mode 100644
> index 0000000..ab14403
> --- /dev/null
> +++ b/include/linux/input/tps6507x-ts.h
> @@ -0,0 +1,24 @@
> +/* linux/i2c/tps6507x-ts.h
> + *
> + * Functions to access TPS65070 touch screen chip.
> + *
> + * Copyright (c) 2009 RidgeRun (todd.fischer at ridgerun.com)
> + *
> + *
> + *  For licencing details see kernel-base/COPYING
> + */
> +
> +#ifndef __LINUX_I2C_TPS6507X_TS_H
> +#define __LINUX_I2C_TPS6507X_TS_H
> +
> +/* Board specific touch screen initial values */
> +struct touchscreen_init_data {
> +	int	poll_period;	/* ms */
> +	int	vref;		/* non-zero to leave vref on */
> +	__u16	min_pressure;	/* min reading to be treated as a touch */
> +	__u16	vendor;
> +	__u16	product;
> +	__u16	version;
> +};
> +
> +#endif /*  __LINUX_I2C_TPS6507X_TS_H */
> diff --git a/include/linux/mfd/tps6507x.h b/include/linux/mfd/tps6507x.h
> index 9543cb7..c923e48 100644
> --- a/include/linux/mfd/tps6507x.h
> +++ b/include/linux/mfd/tps6507x.h
> @@ -142,6 +142,7 @@
>  
>  struct tps6507x_board {
>  	struct regulator_init_data *tps6507x_pmic_init_data;
> +	struct touchscreen_init_data *tps6507x_ts_init_data;
>  };
>  
>  /**
> @@ -162,6 +163,7 @@ struct tps6507x_dev {
>  
>  	/* Client devices */
>  	struct tps6507x_pmic *pmic;
> +	struct tps6507x_ts *ts;
>  };
>  
>  #endif /*  __LINUX_MFD_TPS6507X_H */
> -- 
> 1.6.0.4
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From khilman at deeprootsystems.com  Mon Apr  5 17:35:38 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 05 Apr 2010 15:35:38 -0700
Subject: [PATCH v3 1/1] DA8XX/OMAP-L1XX: FB: Implement double buffering
In-Reply-To: <A24693684029E5489D1D202277BE89445316FACC@dlee02.ent.ti.com>
	(Martin Ambrose's message of "Mon\, 5 Apr 2010 16\:54\:59 -0500")
References: <1270504278-15088-1-git-send-email-martin@ti.com>
	<1270504278-15088-2-git-send-email-martin@ti.com>
	<A24693684029E5489D1D202277BE89445316FACC@dlee02.ent.ti.com>
Message-ID: <8739z9ttmt.fsf@deeprootsystems.com>

"Ambrose, Martin" <martin at ti.com> writes:

> This work includes the following:
>  . Implement handler for FBIO_WAITFORVSYNC ioctl.
>
>  . Allocate the data and palette buffers separately.
>    A consequence of this is that the palette and data loading is now
>    done in different phases. And that the LCD must be disabled
>    temporarily after the palette is loaded but this will only happen
>    once after init and each time the palette is changed. I think this
>    is OK.
>
>  . Allocate two (ping and pong) framebuffers from memory.
>
>  . Add pan_display handler which toggles the LCDC DMA registers between
>    the ping and pong buffers.
>
> Signed-off-by: Martin Ambrose <martin at ti.com>

Your mailer (probably outlook) is converting all tabs to spaces
resulting in a patch that wont apply.

I recommend using git-format-patch + git-send-email directly to your
SMTP server to avoid outlook mangling.

Kevin

From khilman at deeprootsystems.com  Mon Apr  5 17:39:39 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 05 Apr 2010 15:39:39 -0700
Subject: [PATCH] <mach/da8xx.h>: #include <linux/platform_device.h>
In-Reply-To: <201003261756.58925.sshtylyov@ru.mvista.com> (Sergei Shtylyov's
	message of "Fri\, 26 Mar 2010 17\:56\:58 +0300")
References: <201003261756.58925.sshtylyov@ru.mvista.com>
Message-ID: <87wrwlsevo.fsf@deeprootsystems.com>

Sergei Shtylyov <sshtylyov at ru.mvista.com> writes:

> This hushes the following warning:
>
> arch/arm/mach-davinci/include/mach/da8xx.h:104: warning: ?struct platform_device?
> declared inside parameter list
> arch/arm/mach-davinci/include/mach/da8xx.h:104: warning: its scope is only this
> definition or declaration, which is probably not what you want
>
> Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>
>
> ---
> The patch is against the recent DaVinci tree.

Thanks, applying and queuing for 2.6.34-rc in davinci-fixes branch.

Kevin

>  arch/arm/mach-davinci/include/mach/da8xx.h |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> Index: linux-davinci/arch/arm/mach-davinci/include/mach/da8xx.h
> ===================================================================
> --- linux-davinci.orig/arch/arm/mach-davinci/include/mach/da8xx.h
> +++ linux-davinci/arch/arm/mach-davinci/include/mach/da8xx.h
> @@ -3,7 +3,7 @@
>   *
>   * Author: Mark A. Greer <mgreer at mvista.com>
>   *
> - * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
> + * 2007, 2009-2010 (c) MontaVista Software, Inc. This file is licensed under
>   * the terms of the GNU General Public License version 2. This program
>   * is licensed "as is" without any warranty of any kind, whether express
>   * or implied.
> @@ -13,7 +13,9 @@
>  
>  #include <video/da8xx-fb.h>
>  
> +#include <linux/platform_device.h>
>  #include <linux/davinci_emac.h>
> +
>  #include <mach/serial.h>
>  #include <mach/edma.h>
>  #include <mach/i2c.h>

From todd.fischer at ridgerun.com  Mon Apr  5 18:53:11 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Mon,  5 Apr 2010 17:53:11 -0600
Subject: [PATCH 0/2]-V2 Add touch screen input driver for TPS6507x family of
	multi-function chips.
Message-ID: <1270511593-4785-1-git-send-email-todd.fischer@ridgerun.com>


This is the second posting of the TPS6507x touch screen driver. I have
incorporated Kevin Hilman's request to split the board specific changes
into a separate patch.

The TPS6507x family of Texas Instruments power management ICs (pmic)
are multi-function chips that include voltage regulation and touch
screen controller capabilities.  This patch adds a touch screen
input driver for the TPS6507x pmic.  There was an existing regulator
driver.  Before the touch screen driver can be added, a multi-function
device (MFD) driver was needed and the regulator driver modified to
use the MDF driver.  Patches for these changes have been posted and
reviewed.  The TPS6507x touch screen driver applies cleanly to the
MFD GIT repo after the above referenced patches are applied.  If I
should use a different approach, please let me know.

The TPS6507x pmic supports interrupting on touch detection.
Unfortuntaly, the hardware used for driver development didn't have
the interrupt signal properly connected.  When TPS6507x pmic interrupt
capable hardware is in hand, another patch will be posted adding
interrupt support.

From todd.fischer at ridgerun.com  Mon Apr  5 18:53:13 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Mon,  5 Apr 2010 17:53:13 -0600
Subject: [PATCH 2/2] TPS6507x touch screen driver board specific
	initialization values.
In-Reply-To: <1270511593-4785-2-git-send-email-todd.fischer@ridgerun.com>
References: <1270511593-4785-1-git-send-email-todd.fischer@ridgerun.com>
	<1270511593-4785-2-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <1270511593-4785-3-git-send-email-todd.fischer@ridgerun.com>

The touch screen controller in the TPS6507x chip needs values that are 
dependent on the characteristics of the touch screen hardware being used
in the board design.  In addition, the board provides version information
that is exposed via the kernel input sub-system.

Signed-off-by: Todd Fischer <todd.fischer at ridgerun.com>
---
 arch/arm/mach-davinci/board-da850-evm.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index d059924..b3cbb32 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -25,6 +25,8 @@
 #include <linux/mtd/partitions.h>
 #include <linux/mtd/physmap.h>
 #include <linux/regulator/machine.h>
+#include <linux/mfd/tps6507x.h>
+#include <linux/input/tps6507x-ts.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -534,8 +536,18 @@ struct regulator_init_data tps65070_regulator_data[] = {
 	},
 };
 
+static struct touchscreen_init_data tps6507x_touchscreen_data = {
+	.poll_period =  30,	/* ms between touch samples */
+	.min_pressure = 0x30,	/* minimum pressure to trigger touch */
+	.vref = 0,		/* turn off vref when not using A/D */
+	.vendor = 0,		/* /sys/class/input/input?/id/vendor */
+	.product = 65070,	/* /sys/class/input/input?/id/product */
+	.version = 0x100,	/* /sys/class/input/input?/id/version */
+};
+
 static struct tps6507x_board tps_board = {
 	.tps6507x_pmic_init_data = &tps65070_regulator_data[0],
+	.tps6507x_ts_init_data = &tps6507x_touchscreen_data,
 };
 
 static struct i2c_board_info __initdata da850evm_tps65070_info[] = {
-- 
1.6.0.4


From todd.fischer at ridgerun.com  Mon Apr  5 18:53:12 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Mon,  5 Apr 2010 17:53:12 -0600
Subject: [PATCH 1/2] Touch screen input driver for TPS6507x family of
	multi-function chips.
In-Reply-To: <1270511593-4785-1-git-send-email-todd.fischer@ridgerun.com>
References: <1270511593-4785-1-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <1270511593-4785-2-git-send-email-todd.fischer@ridgerun.com>

Add touch screen input driver for TPS6507x family of multi-function
chips.  Uses the TPS6507x MFD driver.  No interrupt support due to
testing limitations of current hardware.

Signed-off-by: Todd Fischer <todd.fischer at ridgerun.com>
---
 drivers/input/touchscreen/Kconfig       |   13 +
 drivers/input/touchscreen/Makefile      |    1 +
 drivers/input/touchscreen/tps6507x-ts.c |  400 +++++++++++++++++++++++++++++++
 drivers/mfd/tps6507x.c                  |    3 +
 include/linux/input/tps6507x-ts.h       |   24 ++
 include/linux/mfd/tps6507x.h            |    2 +
 6 files changed, 443 insertions(+), 0 deletions(-)
 create mode 100644 drivers/input/touchscreen/tps6507x-ts.c
 create mode 100644 include/linux/input/tps6507x-ts.h

diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 8a8fa4d..6166aa8 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -594,4 +594,17 @@ config TOUCHSCREEN_PCAP
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called pcap_ts.
+
+config TOUCHSCREEN_TPS6507X
+	tristate "TPS6507x based touchscreens"
+	depends on I2C
+	help
+	  Say Y here if you have a TPS6507x based touchscreen
+	  controller.
+
+	  If unsure, say N.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called tps6507x_ts.
+
 endif
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index 7fef7d5..cfa83d0 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -46,3 +46,4 @@ obj-$(CONFIG_TOUCHSCREEN_WM97XX_ATMEL)	+= atmel-wm97xx.o
 obj-$(CONFIG_TOUCHSCREEN_WM97XX_MAINSTONE)	+= mainstone-wm97xx.o
 obj-$(CONFIG_TOUCHSCREEN_WM97XX_ZYLONITE)	+= zylonite-wm97xx.o
 obj-$(CONFIG_TOUCHSCREEN_W90X900)	+= w90p910_ts.o
+obj-$(CONFIG_TOUCHSCREEN_TPS6507X)	+= tps6507x-ts.o
diff --git a/drivers/input/touchscreen/tps6507x-ts.c b/drivers/input/touchscreen/tps6507x-ts.c
new file mode 100644
index 0000000..5de80a1
--- /dev/null
+++ b/drivers/input/touchscreen/tps6507x-ts.c
@@ -0,0 +1,400 @@
+/*
+ * drivers/input/touchscreen/tps6507x_ts.c
+ *
+ * Touchscreen driver for the tps6507x chip.
+ *
+ * Copyright (c) 2009 RidgeRun (todd.fischer at ridgerun.com)
+ *
+ * Credits:
+ *
+ *    Using code from tsc2007, MtekVision Co., Ltd.
+ *
+ * For licencing details see kernel-base/COPYING
+ *
+ * TPS65070, TPS65073, TPS650731, and TPS650732 support
+ * 10 bit touch screen interface.
+ */
+
+#include <linux/module.h>
+#include <linux/workqueue.h>
+#include <linux/slab.h>
+#include <linux/input.h>
+#include <linux/platform_device.h>
+#include <linux/mfd/tps6507x.h>
+#include <linux/input/tps6507x-ts.h>
+#include <linux/delay.h>
+
+#define TSC_DEFAULT_POLL_PERIOD 30 /* ms */
+#define TPS_DEFAULT_MIN_PRESSURE 0x30
+#define MAX_10BIT ((1 << 10) - 1)
+
+#define	TPS6507X_ADCONFIG_CONVERT_TS (TPS6507X_ADCONFIG_AD_ENABLE | \
+					 TPS6507X_ADCONFIG_START_CONVERSION | \
+					 TPS6507X_ADCONFIG_INPUT_REAL_TSC)
+#define	TPS6507X_ADCONFIG_POWER_DOWN_TS (TPS6507X_ADCONFIG_INPUT_REAL_TSC)
+
+struct ts_event {
+	u16	x;
+	u16	y;
+	u16	pressure;
+};
+
+struct tps6507x_ts {
+	struct input_dev	*input_dev;
+	struct device		*dev;
+	char			phys[32];
+	struct workqueue_struct *wq;
+	struct delayed_work	work;
+	unsigned		polling;	/* polling is active */
+	struct ts_event		tc;
+	struct tps6507x_dev	*mfd;
+	u16			model;
+	unsigned		pendown;
+	int			irq;
+	void			(*clear_penirq)(void);
+	unsigned long		poll_period;	/* ms */
+	u16			min_pressure;
+	int			vref;		/* non-zero to leave vref on */
+};
+
+static int tps6507x_read_u8(struct tps6507x_ts *tsc, u8 reg, u8 *data)
+{
+	int err;
+
+	err = tsc->mfd->read_dev(tsc->mfd, reg, 1, data);
+
+	if (err)
+		return err;
+
+	return 0;
+}
+
+static int tps6507x_write_u8(struct tps6507x_ts *tsc, u8 reg, u8 data)
+{
+	return tsc->mfd->write_dev(tsc->mfd, reg, 1, &data);
+}
+
+static s32 tps6507x_adc_conversion(struct tps6507x_ts *tsc,
+				   u8 tsc_mode, u16 *value)
+{
+	s32 ret;
+	u8 adc_status;
+	u8 result;
+
+	/* Route input signal to A/D converter */
+
+	ret = tps6507x_write_u8(tsc, TPS6507X_REG_TSCMODE, tsc_mode);
+	if (ret) {
+		dev_err(tsc->dev, "TSC mode read failed\n");
+		goto err;
+	}
+
+	/* Start A/D conversion */
+
+	ret = tps6507x_write_u8(tsc, TPS6507X_REG_ADCONFIG,
+				TPS6507X_ADCONFIG_CONVERT_TS);
+	if (ret) {
+		dev_err(tsc->dev, "ADC config write failed\n");
+		return ret;
+	}
+
+	do {
+		ret = tps6507x_read_u8(tsc, TPS6507X_REG_ADCONFIG,
+				       &adc_status);
+		if (ret) {
+			dev_err(tsc->dev, "ADC config read failed\n");
+			goto err;
+		}
+	} while (adc_status & TPS6507X_ADCONFIG_START_CONVERSION);
+
+	ret = tps6507x_read_u8(tsc, TPS6507X_REG_ADRESULT_2, &result);
+	if (ret) {
+		dev_err(tsc->dev, "ADC result 2 read failed\n");
+		goto err;
+	}
+
+	*value = (result & TPS6507X_REG_ADRESULT_2_MASK) << 8;
+
+	ret = tps6507x_read_u8(tsc, TPS6507X_REG_ADRESULT_1, &result);
+	if (ret) {
+		dev_err(tsc->dev, "ADC result 1 read failed\n");
+		goto err;
+	}
+
+	*value |= result;
+
+	dev_dbg(tsc->dev, "TSC channel %d = 0x%X\n", tsc_mode, *value);
+
+err:
+	return ret;
+}
+
+/* Need to call tps6507x_adc_standby() after using A/D converter for the
+ * touch screen interrupt to work properly.
+ */
+
+static s32 tps6507x_adc_standby(struct tps6507x_ts *tsc)
+{
+	s32 ret;
+	s32 loops = 0;
+	u8 val;
+
+	ret = tps6507x_write_u8(tsc,  TPS6507X_REG_ADCONFIG,
+				TPS6507X_ADCONFIG_INPUT_TSC);
+	if (ret)
+		return ret;
+
+	ret = tps6507x_write_u8(tsc, TPS6507X_REG_TSCMODE,
+				TPS6507X_TSCMODE_STANDBY);
+	if (ret)
+		return ret;
+
+	ret = tps6507x_read_u8(tsc, TPS6507X_REG_INT, &val);
+	if (ret)
+		return ret;
+
+	while (val & TPS6507X_REG_TSC_INT) {
+		mdelay(10);
+		ret = tps6507x_read_u8(tsc, TPS6507X_REG_INT, &val);
+		if (ret)
+			return ret;
+		loops++;
+	}
+
+	return ret;
+}
+
+static void tps6507x_ts_handler(struct work_struct *work)
+{
+	struct tps6507x_ts *tsc =  container_of(work,
+				struct tps6507x_ts, work.work);
+	struct input_dev *input_dev = tsc->input_dev;
+	int pendown;
+	int schd;
+	int poll = 0;
+	s32 ret;
+
+	ret =  tps6507x_adc_conversion(tsc, TPS6507X_TSCMODE_PRESSURE,
+				       &tsc->tc.pressure);
+	if (ret)
+		goto done;
+
+	pendown = tsc->tc.pressure > tsc->min_pressure;
+
+	if (unlikely(!pendown && tsc->pendown)) {
+		dev_dbg(tsc->dev, "UP\n");
+		input_report_key(input_dev, BTN_TOUCH, 0);
+		input_report_abs(input_dev, ABS_PRESSURE, 0);
+		input_sync(input_dev);
+		tsc->pendown = 0;
+	}
+
+	if (pendown) {
+
+		if (!tsc->pendown) {
+			dev_dbg(tsc->dev, "DOWN\n");
+			input_report_key(input_dev, BTN_TOUCH, 1);
+		} else
+			dev_dbg(tsc->dev, "still down\n");
+
+		ret =  tps6507x_adc_conversion(tsc, TPS6507X_TSCMODE_X_POSITION,
+					       &tsc->tc.x);
+		if (ret)
+			goto done;
+
+		ret =  tps6507x_adc_conversion(tsc, TPS6507X_TSCMODE_Y_POSITION,
+					       &tsc->tc.y);
+		if (ret)
+			goto done;
+
+		input_report_abs(input_dev, ABS_X, tsc->tc.x);
+		input_report_abs(input_dev, ABS_Y, tsc->tc.y);
+		input_report_abs(input_dev, ABS_PRESSURE, tsc->tc.pressure);
+		input_sync(input_dev);
+		tsc->pendown = 1;
+		poll = 1;
+	}
+
+done:
+	/* always poll if not using interrupts */
+	poll = 1;
+
+	if (poll) {
+		schd = queue_delayed_work(tsc->wq, &tsc->work,
+					  tsc->poll_period * HZ / 1000);
+		if (schd)
+			tsc->polling = 1;
+		else {
+			tsc->polling = 0;
+			dev_err(tsc->dev, "re-schedule failed");
+		}
+	} else
+		tsc->polling = 0;
+
+	ret = tps6507x_adc_standby(tsc);
+}
+
+static int tps6507x_ts_probe(struct platform_device *pdev)
+{
+	int error;
+	struct tps6507x_ts *tsc;
+	struct tps6507x_dev *tps6507x_dev = dev_get_drvdata(pdev->dev.parent);
+	struct touchscreen_init_data *init_data;
+	struct input_dev *input_dev;
+	struct tps6507x_board *tps_board;
+	int schd;
+
+	/**
+	 * tps_board points to pmic related constants
+	 * coming from the board-evm file.
+	 */
+
+	tps_board = (struct tps6507x_board *)tps6507x_dev->dev->platform_data;
+
+	if (!tps_board) {
+		dev_err(tps6507x_dev->dev,
+			"Could not find tps6507x platform data\n");
+		return -EIO;
+	}
+
+	/**
+	 * init_data points to array of regulator_init structures
+	 * coming from the board-evm file.
+	 */
+
+	init_data = tps_board->tps6507x_ts_init_data;
+
+	tsc = kzalloc(sizeof(struct tps6507x_ts), GFP_KERNEL);
+	if (!tsc) {
+		dev_err(tps6507x_dev->dev, "failed to allocate driver data\n");
+		error = -ENOMEM;
+		goto err0;
+	}
+
+	tps6507x_dev->ts = tsc;
+	tsc->mfd = tps6507x_dev;
+	tsc->dev = tps6507x_dev->dev;
+	input_dev = input_allocate_device();
+	if (!input_dev) {
+		dev_err(tsc->dev, "Failed to allocate input device.\n");
+		error = -ENOMEM;
+		goto err1;
+	}
+
+	input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
+	input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
+
+	input_set_abs_params(input_dev, ABS_X, 0, MAX_10BIT, 0, 0);
+	input_set_abs_params(input_dev, ABS_Y, 0, MAX_10BIT, 0, 0);
+	input_set_abs_params(input_dev, ABS_PRESSURE, 0, MAX_10BIT, 0, 0);
+
+	input_dev->name = "TPS6507x Touchscreen";
+	input_dev->id.bustype = BUS_I2C;
+	input_dev->dev.parent = tsc->dev;
+
+	snprintf(tsc->phys, sizeof(tsc->phys),
+		 "%s/input0", dev_name(tsc->dev));
+	input_dev->phys = tsc->phys;
+
+	dev_dbg(tsc->dev, "device: %s\n", input_dev->phys);
+
+	input_set_drvdata(input_dev, tsc);
+
+	tsc->input_dev = input_dev;
+
+	INIT_DELAYED_WORK(&tsc->work, tps6507x_ts_handler);
+	tsc->wq = create_workqueue("TPS6507x Touchscreen");
+
+	if (init_data) {
+		tsc->poll_period = init_data->poll_period;
+		tsc->vref = init_data->vref;
+		tsc->min_pressure = init_data->min_pressure;
+		input_dev->id.vendor = init_data->vendor;
+		input_dev->id.product = init_data->product;
+		input_dev->id.version = init_data->version;
+	} else {
+		tsc->poll_period = TSC_DEFAULT_POLL_PERIOD;
+		tsc->min_pressure = TPS_DEFAULT_MIN_PRESSURE;
+	}
+
+	error = tps6507x_adc_standby(tsc);
+	if (error)
+		goto err2;
+
+	error = input_register_device(input_dev);
+	if (error)
+		goto err2;
+
+	schd = queue_delayed_work(tsc->wq, &tsc->work,
+				  tsc->poll_period * HZ / 1000);
+
+	if (schd)
+		tsc->polling = 1;
+	else {
+		tsc->polling = 0;
+		dev_err(tsc->dev, "schedule failed");
+		goto err2;
+	 }
+
+	return 0;
+
+err2:
+	cancel_delayed_work(&tsc->work);
+	flush_workqueue(tsc->wq);
+	destroy_workqueue(tsc->wq);
+	tsc->wq = 0;
+	input_free_device(input_dev);
+err1:
+	kfree(tsc);
+	tps6507x_dev->ts = NULL;
+err0:
+	return error;
+}
+
+static int __devexit tps6507x_ts_remove(struct platform_device *pdev)
+{
+	struct tps6507x_dev *tps6507x_dev = platform_get_drvdata(pdev);
+	struct tps6507x_ts *tsc = tps6507x_dev->ts;
+	struct input_dev *input_dev = tsc->input_dev;
+
+	if (!tsc)
+		return 0;
+
+	cancel_delayed_work(&tsc->work);
+	flush_workqueue(tsc->wq);
+	destroy_workqueue(tsc->wq);
+	tsc->wq = 0;
+
+	input_free_device(input_dev);
+
+	tps6507x_dev->ts = NULL;
+	kfree(tsc);
+
+	return 0;
+}
+
+static struct platform_driver tps6507x_ts_driver = {
+	.driver = {
+		.name = "tps6507x-ts",
+		.owner = THIS_MODULE,
+	},
+	.probe = tps6507x_ts_probe,
+	.remove = __devexit_p(tps6507x_ts_remove),
+};
+
+static int __init tps6507x_ts_init(void)
+{
+	return platform_driver_register(&tps6507x_ts_driver);
+}
+module_init(tps6507x_ts_init);
+
+static void __exit tps6507x_ts_exit(void)
+{
+	platform_driver_unregister(&tps6507x_ts_driver);
+}
+module_exit(tps6507x_ts_exit);
+
+MODULE_AUTHOR("Todd Fischer <todd.fischer at ridgerun.com>");
+MODULE_DESCRIPTION("TPS6507x - TouchScreen driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:tps6507x-tsc");
diff --git a/drivers/mfd/tps6507x.c b/drivers/mfd/tps6507x.c
index edda9ff..d05c52d 100644
--- a/drivers/mfd/tps6507x.c
+++ b/drivers/mfd/tps6507x.c
@@ -25,6 +25,9 @@ static struct mfd_cell tps6507x_devs[] = {
 	{
 		.name = "tps6507x-pmic",
 	},
+	{
+		.name = "tps6507x-ts",
+	},
 };
 
 
diff --git a/include/linux/input/tps6507x-ts.h b/include/linux/input/tps6507x-ts.h
new file mode 100644
index 0000000..ab14403
--- /dev/null
+++ b/include/linux/input/tps6507x-ts.h
@@ -0,0 +1,24 @@
+/* linux/i2c/tps6507x-ts.h
+ *
+ * Functions to access TPS65070 touch screen chip.
+ *
+ * Copyright (c) 2009 RidgeRun (todd.fischer at ridgerun.com)
+ *
+ *
+ *  For licencing details see kernel-base/COPYING
+ */
+
+#ifndef __LINUX_I2C_TPS6507X_TS_H
+#define __LINUX_I2C_TPS6507X_TS_H
+
+/* Board specific touch screen initial values */
+struct touchscreen_init_data {
+	int	poll_period;	/* ms */
+	int	vref;		/* non-zero to leave vref on */
+	__u16	min_pressure;	/* min reading to be treated as a touch */
+	__u16	vendor;
+	__u16	product;
+	__u16	version;
+};
+
+#endif /*  __LINUX_I2C_TPS6507X_TS_H */
diff --git a/include/linux/mfd/tps6507x.h b/include/linux/mfd/tps6507x.h
index 9543cb7..c923e48 100644
--- a/include/linux/mfd/tps6507x.h
+++ b/include/linux/mfd/tps6507x.h
@@ -142,6 +142,7 @@
 
 struct tps6507x_board {
 	struct regulator_init_data *tps6507x_pmic_init_data;
+	struct touchscreen_init_data *tps6507x_ts_init_data;
 };
 
 /**
@@ -162,6 +163,7 @@ struct tps6507x_dev {
 
 	/* Client devices */
 	struct tps6507x_pmic *pmic;
+	struct tps6507x_ts *ts;
 };
 
 #endif /*  __LINUX_MFD_TPS6507X_H */
-- 
1.6.0.4


From khilman at deeprootsystems.com  Mon Apr  5 18:56:58 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 05 Apr 2010 16:56:58 -0700
Subject: [PATCH 00/14] Davinci: tnetv107x SOC patch series
In-Reply-To: <1269476345-16111-1-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Wed\, 24 Mar 2010 20\:18\:51 -0400")
References: <1269476345-16111-1-git-send-email-cyril@ti.com>
Message-ID: <87zl1hqwqd.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> Hi,
>
> This patch series adds support for TNETV107X - a Texas Instruments SOC that
> shares a number of common features with the Davinci architecture.
>
> Some of the patches included in this series were posted earlier, but have also
> been included here.

I'm planning to merge patches 1-8 and 10 to davinci git.
The others have had some issues raised that need to be discussed and/or addressed.

Kevin


> The key differences between traditional Davincis and this new SOC are:
>
> 1. The SOCs clock architecture includes a new spread-spectrum PLL.  Some
> elements of the clock architecture are reused from Davinci (e.g. LPSC), but
> the PLL related code is overridden using existing interfaces in "struct clk".
>
> 2. The MMR layout on this SOC is substantially different from Davinci.
> Consequently, the fixed I/O map is a whole lot more convoluted (more so than
> DA8xx).  The net impact here is that IO_ADDRESS() will not work on this SoC,
> and therefore all mappings have to be through ioremap().
>
> 3. The Davinci reset mechanism (via Timer64 watchdog) will not work on this
> SoC.  This difference has not been addressed here (dummy davinci_wdt_device),
> but a more "extensible" reset mechanism will need to be established
> eventually.
>
> 4. The GPIO controller on this device is different.  Currently, this patch
> leaves the traditional Davinci GPIO numbers (0..DAVINCI_N_GPIO) unused so that
> the inline GPIO implementation can remain unmodified.  TNETV107X GPIOs are
> exposed as higher numbered GPIOs, and are currently accessible only through
> a non-inline version.
>
>
> Despite all efforts, I could not retain a unified build across davinci and
> tnetv107x devices. The code included in this patch series does not impose
> such a limitation in itself, but the underlying ARM code fails to build when
> both 926 and 1176 Kconfig options are set.
>
>
> - Cyril.

From khilman at deeprootsystems.com  Mon Apr  5 18:59:20 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 05 Apr 2010 16:59:20 -0700
Subject: [PATCH 00/14] Davinci: tnetv107x SOC patch series
References: <1269476345-16111-1-git-send-email-cyril@ti.com>
Message-ID: <87sk79qwmf.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> Hi,
>
> This patch series adds support for TNETV107X - a Texas Instruments SOC that
> shares a number of common features with the Davinci architecture.
>
> Some of the patches included in this series were posted earlier, but have also
> been included here.

I'm planning to merge patches 1-8 and 10 to davinci git.
The others have had some issues raised that need to be discussed and/or addressed.

Kevin


> The key differences between traditional Davincis and this new SOC are:
>
> 1. The SOCs clock architecture includes a new spread-spectrum PLL.  Some
> elements of the clock architecture are reused from Davinci (e.g. LPSC), but
> the PLL related code is overridden using existing interfaces in "struct clk".
>
> 2. The MMR layout on this SOC is substantially different from Davinci.
> Consequently, the fixed I/O map is a whole lot more convoluted (more so than
> DA8xx).  The net impact here is that IO_ADDRESS() will not work on this SoC,
> and therefore all mappings have to be through ioremap().
>
> 3. The Davinci reset mechanism (via Timer64 watchdog) will not work on this
> SoC.  This difference has not been addressed here (dummy davinci_wdt_device),
> but a more "extensible" reset mechanism will need to be established
> eventually.
>
> 4. The GPIO controller on this device is different.  Currently, this patch
> leaves the traditional Davinci GPIO numbers (0..DAVINCI_N_GPIO) unused so that
> the inline GPIO implementation can remain unmodified.  TNETV107X GPIOs are
> exposed as higher numbered GPIOs, and are currently accessible only through
> a non-inline version.
>
>
> Despite all efforts, I could not retain a unified build across davinci and
> tnetv107x devices. The code included in this patch series does not impose
> such a limitation in itself, but the underlying ARM code fails to build when
> both 926 and 1176 Kconfig options are set.
>
>
> - Cyril.

From todd.fischer at ridgerun.com  Mon Apr  5 21:23:57 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Mon,  5 Apr 2010 20:23:57 -0600
Subject: [PATCH 2/4]-V3 Make room for other tps6507x drivers to have board
	specific initialization data.
In-Reply-To: <1270520639-20516-2-git-send-email-todd.fischer@ridgerun.com>
References: <1270520639-20516-1-git-send-email-todd.fischer@ridgerun.com>
	<1270520639-20516-2-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <1270520639-20516-3-git-send-email-todd.fischer@ridgerun.com>

Add mfd structure which refrences sub-driver initialization data. For example,
for a giving hardware implementation, the voltage regulator sub-driver
initialization data provides the mapping betten a voltage regulator and what
the output voltage is being used for.

Signed-off-by: Todd Fischer <todd.fischer at ridgerun.com>
---
 arch/arm/mach-davinci/board-da850-evm.c |    7 ++++++-
 drivers/regulator/tps6507x-regulator.c  |   14 ++++++++++++--
 include/linux/mfd/tps6507x.h            |   11 +++++++++++
 3 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 411284d..d059924 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -17,6 +17,7 @@
 #include <linux/i2c.h>
 #include <linux/i2c/at24.h>
 #include <linux/i2c/pca953x.h>
+#include <linux/mfd/tps6507x.h>
 #include <linux/gpio.h>
 #include <linux/platform_device.h>
 #include <linux/mtd/mtd.h>
@@ -533,10 +534,14 @@ struct regulator_init_data tps65070_regulator_data[] = {
 	},
 };
 
+static struct tps6507x_board tps_board = {
+	.tps6507x_pmic_init_data = &tps65070_regulator_data[0],
+};
+
 static struct i2c_board_info __initdata da850evm_tps65070_info[] = {
 	{
 		I2C_BOARD_INFO("tps6507x", 0x48),
-		.platform_data = &tps65070_regulator_data[0],
+		.platform_data = &tps_board,
 	},
 };
 
diff --git a/drivers/regulator/tps6507x-regulator.c b/drivers/regulator/tps6507x-regulator.c
index 91172e3..becf652 100644
--- a/drivers/regulator/tps6507x-regulator.c
+++ b/drivers/regulator/tps6507x-regulator.c
@@ -488,6 +488,7 @@ static int __devinit tps_6507x_probe(struct i2c_client *client,
 	struct regulator_init_data *init_data;
 	struct regulator_dev *rdev;
 	struct tps_pmic *tps;
+	struct tps6507x_board *tps_board;
 	int i;
 	int error;
 
@@ -496,12 +497,21 @@ static int __devinit tps_6507x_probe(struct i2c_client *client,
 		return -EIO;
 
 	/**
+	 * tps_board points to pmic related constants
+	 * coming from the board-evm file.
+	 */
+
+	tps_board = dev_get_platdata(&client->dev);
+	if (!tps_board)
+		return -EINVAL;
+
+	/**
 	 * init_data points to array of regulator_init structures
 	 * coming from the board-evm file.
 	 */
-	init_data = client->dev.platform_data;
+	init_data = tps_board->tps6507x_pmic_init_data;
 	if (!init_data)
-		return -EIO;
+		return -EINVAL;
 
 	tps = kzalloc(sizeof(*tps), GFP_KERNEL);
 	if (!tps)
diff --git a/include/linux/mfd/tps6507x.h b/include/linux/mfd/tps6507x.h
index 155bee1..fd73af5 100644
--- a/include/linux/mfd/tps6507x.h
+++ b/include/linux/mfd/tps6507x.h
@@ -131,4 +131,15 @@
 /* VDCDC MASK */
 #define TPS6507X_DEFDCDCX_DCDC_MASK		0X3F
 
+/**
+ * struct tps6507x_board - packages regulator and touchscreen init data
+ * @tps6507x_regulator_data: regulator initialization values
+ *
+ * Board data may be used to initialize regulator and touchscreen.
+ */
+
+struct tps6507x_board {
+	struct regulator_init_data *tps6507x_pmic_init_data;
+};
+
 #endif /*  __LINUX_MFD_TPS6507X_H */
-- 
1.6.0.4


From todd.fischer at ridgerun.com  Mon Apr  5 21:23:55 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Mon,  5 Apr 2010 20:23:55 -0600
Subject: [PATCH 0/4]-V3 TPS6507x MFD driver
Message-ID: <1270520639-20516-1-git-send-email-todd.fischer@ridgerun.com>


This is the third posting of the TPS6507x driver set.  I have
resolved the concurrent access issue identified by Mark Brown.
Instead of using a mutex, I used the i2c_transfer() as done in
the similar routine in the wm8400-core.c file.

The TPS6507x family of Texas Instruments power management ICs (pmic) are
multi-function chips that include voltage regulation and touch screen
controller capabilities.  This patch set adds a TPS6507x multi-function
device driver and change the TPS6507x regulator driver to use the
TPS6507x MFD driver instead of interacting with the chip directly.  The
changes are needed before a touch screen driver can be added.

The patch set applies cleanly to the MFD repository:
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git  If the
MFD and voltage regulator maintainer would prefer I post patches for a
different repository, please let me know.

From todd.fischer at ridgerun.com  Mon Apr  5 21:23:56 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Mon,  5 Apr 2010 20:23:56 -0600
Subject: [PATCH 1/4]-V3 Move TPS6507x register definition to header file.
In-Reply-To: <1270520639-20516-1-git-send-email-todd.fischer@ridgerun.com>
References: <1270520639-20516-1-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <1270520639-20516-2-git-send-email-todd.fischer@ridgerun.com>

Other sub-drivers for the TPS6507x chip will need to use register 
definition so move it out of the source file and into a header file.

Signed-off-by: Todd Fischer <todd.fischer at ridgerun.com>
---
 drivers/regulator/tps6507x-regulator.c |   60 +--------------
 include/linux/mfd/tps6507x.h           |  134 ++++++++++++++++++++++++++++++++
 2 files changed, 135 insertions(+), 59 deletions(-)
 create mode 100644 include/linux/mfd/tps6507x.h

diff --git a/drivers/regulator/tps6507x-regulator.c b/drivers/regulator/tps6507x-regulator.c
index c2a9539..91172e3 100644
--- a/drivers/regulator/tps6507x-regulator.c
+++ b/drivers/regulator/tps6507x-regulator.c
@@ -24,65 +24,7 @@
 #include <linux/regulator/machine.h>
 #include <linux/i2c.h>
 #include <linux/delay.h>
-
-/* Register definitions */
-#define	TPS6507X_REG_PPATH1				0X01
-#define	TPS6507X_REG_INT				0X02
-#define	TPS6507X_REG_CHGCONFIG0				0X03
-#define	TPS6507X_REG_CHGCONFIG1				0X04
-#define	TPS6507X_REG_CHGCONFIG2				0X05
-#define	TPS6507X_REG_CHGCONFIG3				0X06
-#define	TPS6507X_REG_REG_ADCONFIG			0X07
-#define	TPS6507X_REG_TSCMODE				0X08
-#define	TPS6507X_REG_ADRESULT_1				0X09
-#define	TPS6507X_REG_ADRESULT_2				0X0A
-#define	TPS6507X_REG_PGOOD				0X0B
-#define	TPS6507X_REG_PGOODMASK				0X0C
-#define	TPS6507X_REG_CON_CTRL1				0X0D
-#define	TPS6507X_REG_CON_CTRL2				0X0E
-#define	TPS6507X_REG_CON_CTRL3				0X0F
-#define	TPS6507X_REG_DEFDCDC1				0X10
-#define	TPS6507X_REG_DEFDCDC2_LOW			0X11
-#define	TPS6507X_REG_DEFDCDC2_HIGH			0X12
-#define	TPS6507X_REG_DEFDCDC3_LOW			0X13
-#define	TPS6507X_REG_DEFDCDC3_HIGH			0X14
-#define	TPS6507X_REG_DEFSLEW				0X15
-#define	TPS6507X_REG_LDO_CTRL1				0X16
-#define	TPS6507X_REG_DEFLDO2				0X17
-#define	TPS6507X_REG_WLED_CTRL1				0X18
-#define	TPS6507X_REG_WLED_CTRL2				0X19
-
-/* CON_CTRL1 bitfields */
-#define	TPS6507X_CON_CTRL1_DCDC1_ENABLE		BIT(4)
-#define	TPS6507X_CON_CTRL1_DCDC2_ENABLE		BIT(3)
-#define	TPS6507X_CON_CTRL1_DCDC3_ENABLE		BIT(2)
-#define	TPS6507X_CON_CTRL1_LDO1_ENABLE		BIT(1)
-#define	TPS6507X_CON_CTRL1_LDO2_ENABLE		BIT(0)
-
-/* DEFDCDC1 bitfields */
-#define TPS6507X_DEFDCDC1_DCDC1_EXT_ADJ_EN	BIT(7)
-#define TPS6507X_DEFDCDC1_DCDC1_MASK		0X3F
-
-/* DEFDCDC2_LOW bitfields */
-#define TPS6507X_DEFDCDC2_LOW_DCDC2_MASK	0X3F
-
-/* DEFDCDC2_HIGH bitfields */
-#define TPS6507X_DEFDCDC2_HIGH_DCDC2_MASK	0X3F
-
-/* DEFDCDC3_LOW bitfields */
-#define TPS6507X_DEFDCDC3_LOW_DCDC3_MASK	0X3F
-
-/* DEFDCDC3_HIGH bitfields */
-#define TPS6507X_DEFDCDC3_HIGH_DCDC3_MASK	0X3F
-
-/* TPS6507X_REG_LDO_CTRL1 bitfields */
-#define TPS6507X_REG_LDO_CTRL1_LDO1_MASK	0X0F
-
-/* TPS6507X_REG_DEFLDO2 bitfields */
-#define TPS6507X_REG_DEFLDO2_LDO2_MASK		0X3F
-
-/* VDCDC MASK */
-#define TPS6507X_DEFDCDCX_DCDC_MASK		0X3F
+#include <linux/mfd/tps6507x.h>
 
 /* DCDC's */
 #define TPS6507X_DCDC_1				0
diff --git a/include/linux/mfd/tps6507x.h b/include/linux/mfd/tps6507x.h
new file mode 100644
index 0000000..155bee1
--- /dev/null
+++ b/include/linux/mfd/tps6507x.h
@@ -0,0 +1,134 @@
+/* linux/mfd/tps6507x.h
+ *
+ * Functions to access TPS65070 power management chip.
+ *
+ * Copyright (c) 2009 RidgeRun (todd.fischer at ridgerun.com)
+ *
+ *
+ *  For licencing details see kernel-base/COPYING
+ */
+
+#ifndef __LINUX_MFD_TPS6507X_H
+#define __LINUX_MFD_TPS6507X_H
+
+/*
+ * ----------------------------------------------------------------------------
+ * Registers, all 8 bits
+ * ----------------------------------------------------------------------------
+ */
+
+
+/* Register definitions */
+#define	TPS6507X_REG_PPATH1			0X01
+#define	TPS6507X_CHG_USB			BIT(7)
+#define	TPS6507X_CHG_AC				BIT(6)
+#define	TPS6507X_CHG_USB_PW_ENABLE		BIT(5)
+#define	TPS6507X_CHG_AC_PW_ENABLE		BIT(4)
+#define	TPS6507X_CHG_AC_CURRENT			BIT(2)
+#define	TPS6507X_CHG_USB_CURRENT		BIT(0)
+
+#define	TPS6507X_REG_INT			0X02
+#define	TPS6507X_REG_MASK_AC_USB		BIT(7)
+#define	TPS6507X_REG_MASK_TSC			BIT(6)
+#define	TPS6507X_REG_MASK_PB_IN			BIT(5)
+#define	TPS6507X_REG_TSC_INT			BIT(3)
+#define	TPS6507X_REG_PB_IN_INT			BIT(2)
+#define	TPS6507X_REG_AC_USB_APPLIED		BIT(1)
+#define	TPS6507X_REG_AC_USB_REMOVED		BIT(0)
+
+#define	TPS6507X_REG_CHGCONFIG0			0X03
+
+#define	TPS6507X_REG_CHGCONFIG1			0X04
+#define	TPS6507X_CON_CTRL1_DCDC1_ENABLE		BIT(4)
+#define	TPS6507X_CON_CTRL1_DCDC2_ENABLE		BIT(3)
+#define	TPS6507X_CON_CTRL1_DCDC3_ENABLE		BIT(2)
+#define	TPS6507X_CON_CTRL1_LDO1_ENABLE		BIT(1)
+#define	TPS6507X_CON_CTRL1_LDO2_ENABLE		BIT(0)
+
+#define	TPS6507X_REG_CHGCONFIG2			0X05
+
+#define	TPS6507X_REG_CHGCONFIG3			0X06
+
+#define	TPS6507X_REG_ADCONFIG			0X07
+#define	TPS6507X_ADCONFIG_AD_ENABLE		BIT(7)
+#define	TPS6507X_ADCONFIG_START_CONVERSION	BIT(6)
+#define	TPS6507X_ADCONFIG_CONVERSION_DONE	BIT(5)
+#define	TPS6507X_ADCONFIG_VREF_ENABLE		BIT(4)
+#define	TPS6507X_ADCONFIG_INPUT_AD_IN1		0
+#define	TPS6507X_ADCONFIG_INPUT_AD_IN2		1
+#define	TPS6507X_ADCONFIG_INPUT_AD_IN3		2
+#define	TPS6507X_ADCONFIG_INPUT_AD_IN4		3
+#define	TPS6507X_ADCONFIG_INPUT_TS_PIN		4
+#define	TPS6507X_ADCONFIG_INPUT_BAT_CURRENT	5
+#define	TPS6507X_ADCONFIG_INPUT_AC_VOLTAGE	6
+#define	TPS6507X_ADCONFIG_INPUT_SYS_VOLTAGE	7
+#define	TPS6507X_ADCONFIG_INPUT_CHARGER_VOLTAGE 8
+#define	TPS6507X_ADCONFIG_INPUT_BAT_VOLTAGE	9
+#define	TPS6507X_ADCONFIG_INPUT_THRESHOLD_VOLTAGE 10
+#define	TPS6507X_ADCONFIG_INPUT_ISET1_VOLTAGE	11
+#define	TPS6507X_ADCONFIG_INPUT_ISET2_VOLTAGE	12
+#define	TPS6507X_ADCONFIG_INPUT_REAL_TSC	14
+#define	TPS6507X_ADCONFIG_INPUT_TSC		15
+
+#define	TPS6507X_REG_TSCMODE			0X08
+#define	TPS6507X_TSCMODE_X_POSITION		0
+#define	TPS6507X_TSCMODE_Y_POSITION		1
+#define	TPS6507X_TSCMODE_PRESSURE		2
+#define	TPS6507X_TSCMODE_X_PLATE		3
+#define	TPS6507X_TSCMODE_Y_PLATE		4
+#define	TPS6507X_TSCMODE_STANDBY		5
+#define	TPS6507X_TSCMODE_ADC_INPUT		6
+#define	TPS6507X_TSCMODE_DISABLE		7
+
+#define	TPS6507X_REG_ADRESULT_1			0X09
+
+#define	TPS6507X_REG_ADRESULT_2			0X0A
+#define	TPS6507X_REG_ADRESULT_2_MASK		(BIT(1) | BIT(0))
+
+#define	TPS6507X_REG_PGOOD			0X0B
+
+#define	TPS6507X_REG_PGOODMASK			0X0C
+
+#define	TPS6507X_REG_CON_CTRL1			0X0D
+#define	TPS6507X_CON_CTRL1_DCDC1_ENABLE		BIT(4)
+#define	TPS6507X_CON_CTRL1_DCDC2_ENABLE		BIT(3)
+#define	TPS6507X_CON_CTRL1_DCDC3_ENABLE		BIT(2)
+#define	TPS6507X_CON_CTRL1_LDO1_ENABLE		BIT(1)
+#define	TPS6507X_CON_CTRL1_LDO2_ENABLE		BIT(0)
+
+#define	TPS6507X_REG_CON_CTRL2			0X0E
+
+#define	TPS6507X_REG_CON_CTRL3			0X0F
+
+#define	TPS6507X_REG_DEFDCDC1			0X10
+#define TPS6507X_DEFDCDC1_DCDC1_EXT_ADJ_EN	BIT(7)
+#define TPS6507X_DEFDCDC1_DCDC1_MASK		0X3F
+
+#define	TPS6507X_REG_DEFDCDC2_LOW		0X11
+#define TPS6507X_DEFDCDC2_LOW_DCDC2_MASK	0X3F
+
+#define	TPS6507X_REG_DEFDCDC2_HIGH		0X12
+#define TPS6507X_DEFDCDC2_HIGH_DCDC2_MASK	0X3F
+
+#define	TPS6507X_REG_DEFDCDC3_LOW		0X13
+#define TPS6507X_DEFDCDC3_LOW_DCDC3_MASK	0X3F
+
+#define	TPS6507X_REG_DEFDCDC3_HIGH		0X14
+#define TPS6507X_DEFDCDC3_HIGH_DCDC3_MASK	0X3F
+
+#define	TPS6507X_REG_DEFSLEW			0X15
+
+#define	TPS6507X_REG_LDO_CTRL1			0X16
+#define TPS6507X_REG_LDO_CTRL1_LDO1_MASK	0X0F
+
+#define	TPS6507X_REG_DEFLDO2			0X17
+#define TPS6507X_REG_DEFLDO2_LDO2_MASK		0X3F
+
+#define	TPS6507X_REG_WLED_CTRL1			0X18
+
+#define	TPS6507X_REG_WLED_CTRL2			0X19
+
+/* VDCDC MASK */
+#define TPS6507X_DEFDCDCX_DCDC_MASK		0X3F
+
+#endif /*  __LINUX_MFD_TPS6507X_H */
-- 
1.6.0.4


From todd.fischer at ridgerun.com  Mon Apr  5 21:23:58 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Mon,  5 Apr 2010 20:23:58 -0600
Subject: [PATCH 3/4]-V3 Cleaned up name space so each MFD sub-driver uses a
	different name space.
In-Reply-To: <1270520639-20516-3-git-send-email-todd.fischer@ridgerun.com>
References: <1270520639-20516-1-git-send-email-todd.fischer@ridgerun.com>
	<1270520639-20516-2-git-send-email-todd.fischer@ridgerun.com>
	<1270520639-20516-3-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <1270520639-20516-4-git-send-email-todd.fischer@ridgerun.com>

Move from using tps or tsp6507x to tps6057x_pmic in a consistent manner.

Signed-off-by: Todd Fischer <todd.fischer at ridgerun.com>
---
 drivers/regulator/tps6507x-regulator.c |  172 ++++++++++++++++----------------
 1 files changed, 87 insertions(+), 85 deletions(-)

diff --git a/drivers/regulator/tps6507x-regulator.c b/drivers/regulator/tps6507x-regulator.c
index becf652..86f2e05 100644
--- a/drivers/regulator/tps6507x-regulator.c
+++ b/drivers/regulator/tps6507x-regulator.c
@@ -103,7 +103,7 @@ struct tps_info {
 	const u16 *table;
 };
 
-struct tps_pmic {
+struct tps6507x_pmic {
 	struct regulator_desc desc[TPS6507X_NUM_REGULATOR];
 	struct i2c_client *client;
 	struct regulator_dev *rdev[TPS6507X_NUM_REGULATOR];
@@ -111,23 +111,23 @@ struct tps_pmic {
 	struct mutex io_lock;
 };
 
-static inline int tps_6507x_read(struct tps_pmic *tps, u8 reg)
+static inline int tps6507x_pmic_read(struct tps6507x_pmic *tps, u8 reg)
 {
 	return i2c_smbus_read_byte_data(tps->client, reg);
 }
 
-static inline int tps_6507x_write(struct tps_pmic *tps, u8 reg, u8 val)
+static inline int tps6507x_pmic_write(struct tps6507x_pmic *tps, u8 reg, u8 val)
 {
 	return i2c_smbus_write_byte_data(tps->client, reg, val);
 }
 
-static int tps_6507x_set_bits(struct tps_pmic *tps, u8 reg, u8 mask)
+static int tps6507x_pmic_set_bits(struct tps6507x_pmic *tps, u8 reg, u8 mask)
 {
 	int err, data;
 
 	mutex_lock(&tps->io_lock);
 
-	data = tps_6507x_read(tps, reg);
+	data = tps6507x_pmic_read(tps, reg);
 	if (data < 0) {
 		dev_err(&tps->client->dev, "Read from reg 0x%x failed\n", reg);
 		err = data;
@@ -135,7 +135,7 @@ static int tps_6507x_set_bits(struct tps_pmic *tps, u8 reg, u8 mask)
 	}
 
 	data |= mask;
-	err = tps_6507x_write(tps, reg, data);
+	err = tps6507x_pmic_write(tps, reg, data);
 	if (err)
 		dev_err(&tps->client->dev, "Write for reg 0x%x failed\n", reg);
 
@@ -144,13 +144,13 @@ out:
 	return err;
 }
 
-static int tps_6507x_clear_bits(struct tps_pmic *tps, u8 reg, u8 mask)
+static int tps6507x_pmic_clear_bits(struct tps6507x_pmic *tps, u8 reg, u8 mask)
 {
 	int err, data;
 
 	mutex_lock(&tps->io_lock);
 
-	data = tps_6507x_read(tps, reg);
+	data = tps6507x_pmic_read(tps, reg);
 	if (data < 0) {
 		dev_err(&tps->client->dev, "Read from reg 0x%x failed\n", reg);
 		err = data;
@@ -158,7 +158,7 @@ static int tps_6507x_clear_bits(struct tps_pmic *tps, u8 reg, u8 mask)
 	}
 
 	data &= ~mask;
-	err = tps_6507x_write(tps, reg, data);
+	err = tps6507x_pmic_write(tps, reg, data);
 	if (err)
 		dev_err(&tps->client->dev, "Write for reg 0x%x failed\n", reg);
 
@@ -167,13 +167,13 @@ out:
 	return err;
 }
 
-static int tps_6507x_reg_read(struct tps_pmic *tps, u8 reg)
+static int tps6507x_pmic_reg_read(struct tps6507x_pmic *tps, u8 reg)
 {
 	int data;
 
 	mutex_lock(&tps->io_lock);
 
-	data = tps_6507x_read(tps, reg);
+	data = tps6507x_pmic_read(tps, reg);
 	if (data < 0)
 		dev_err(&tps->client->dev, "Read from reg 0x%x failed\n", reg);
 
@@ -181,13 +181,13 @@ static int tps_6507x_reg_read(struct tps_pmic *tps, u8 reg)
 	return data;
 }
 
-static int tps_6507x_reg_write(struct tps_pmic *tps, u8 reg, u8 val)
+static int tps6507x_pmic_reg_write(struct tps6507x_pmic *tps, u8 reg, u8 val)
 {
 	int err;
 
 	mutex_lock(&tps->io_lock);
 
-	err = tps_6507x_write(tps, reg, val);
+	err = tps6507x_pmic_write(tps, reg, val);
 	if (err < 0)
 		dev_err(&tps->client->dev, "Write for reg 0x%x failed\n", reg);
 
@@ -195,9 +195,9 @@ static int tps_6507x_reg_write(struct tps_pmic *tps, u8 reg, u8 val)
 	return err;
 }
 
-static int tps6507x_dcdc_is_enabled(struct regulator_dev *dev)
+static int tps6507x_pmic_dcdc_is_enabled(struct regulator_dev *dev)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int data, dcdc = rdev_get_id(dev);
 	u8 shift;
 
@@ -205,7 +205,7 @@ static int tps6507x_dcdc_is_enabled(struct regulator_dev *dev)
 		return -EINVAL;
 
 	shift = TPS6507X_MAX_REG_ID - dcdc;
-	data = tps_6507x_reg_read(tps, TPS6507X_REG_CON_CTRL1);
+	data = tps6507x_pmic_reg_read(tps, TPS6507X_REG_CON_CTRL1);
 
 	if (data < 0)
 		return data;
@@ -213,9 +213,9 @@ static int tps6507x_dcdc_is_enabled(struct regulator_dev *dev)
 		return (data & 1<<shift) ? 1 : 0;
 }
 
-static int tps6507x_ldo_is_enabled(struct regulator_dev *dev)
+static int tps6507x_pmic_ldo_is_enabled(struct regulator_dev *dev)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int data, ldo = rdev_get_id(dev);
 	u8 shift;
 
@@ -223,7 +223,7 @@ static int tps6507x_ldo_is_enabled(struct regulator_dev *dev)
 		return -EINVAL;
 
 	shift = TPS6507X_MAX_REG_ID - ldo;
-	data = tps_6507x_reg_read(tps, TPS6507X_REG_CON_CTRL1);
+	data = tps6507x_pmic_reg_read(tps, TPS6507X_REG_CON_CTRL1);
 
 	if (data < 0)
 		return data;
@@ -231,9 +231,9 @@ static int tps6507x_ldo_is_enabled(struct regulator_dev *dev)
 		return (data & 1<<shift) ? 1 : 0;
 }
 
-static int tps6507x_dcdc_enable(struct regulator_dev *dev)
+static int tps6507x_pmic_dcdc_enable(struct regulator_dev *dev)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int dcdc = rdev_get_id(dev);
 	u8 shift;
 
@@ -241,12 +241,12 @@ static int tps6507x_dcdc_enable(struct regulator_dev *dev)
 		return -EINVAL;
 
 	shift = TPS6507X_MAX_REG_ID - dcdc;
-	return tps_6507x_set_bits(tps, TPS6507X_REG_CON_CTRL1, 1 << shift);
+	return tps6507x_pmic_set_bits(tps, TPS6507X_REG_CON_CTRL1, 1 << shift);
 }
 
-static int tps6507x_dcdc_disable(struct regulator_dev *dev)
+static int tps6507x_pmic_dcdc_disable(struct regulator_dev *dev)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int dcdc = rdev_get_id(dev);
 	u8 shift;
 
@@ -254,12 +254,13 @@ static int tps6507x_dcdc_disable(struct regulator_dev *dev)
 		return -EINVAL;
 
 	shift = TPS6507X_MAX_REG_ID - dcdc;
-	return tps_6507x_clear_bits(tps, TPS6507X_REG_CON_CTRL1, 1 << shift);
+	return tps6507x_pmic_clear_bits(tps, TPS6507X_REG_CON_CTRL1,
+					1 << shift);
 }
 
-static int tps6507x_ldo_enable(struct regulator_dev *dev)
+static int tps6507x_pmic_ldo_enable(struct regulator_dev *dev)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int ldo = rdev_get_id(dev);
 	u8 shift;
 
@@ -267,12 +268,12 @@ static int tps6507x_ldo_enable(struct regulator_dev *dev)
 		return -EINVAL;
 
 	shift = TPS6507X_MAX_REG_ID - ldo;
-	return tps_6507x_set_bits(tps, TPS6507X_REG_CON_CTRL1, 1 << shift);
+	return tps6507x_pmic_set_bits(tps, TPS6507X_REG_CON_CTRL1, 1 << shift);
 }
 
-static int tps6507x_ldo_disable(struct regulator_dev *dev)
+static int tps6507x_pmic_ldo_disable(struct regulator_dev *dev)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int ldo = rdev_get_id(dev);
 	u8 shift;
 
@@ -280,12 +281,13 @@ static int tps6507x_ldo_disable(struct regulator_dev *dev)
 		return -EINVAL;
 
 	shift = TPS6507X_MAX_REG_ID - ldo;
-	return tps_6507x_clear_bits(tps, TPS6507X_REG_CON_CTRL1, 1 << shift);
+	return tps6507x_pmic_clear_bits(tps, TPS6507X_REG_CON_CTRL1,
+					1 << shift);
 }
 
-static int tps6507x_dcdc_get_voltage(struct regulator_dev *dev)
+static int tps6507x_pmic_dcdc_get_voltage(struct regulator_dev *dev)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int data, dcdc = rdev_get_id(dev);
 	u8 reg;
 
@@ -303,7 +305,7 @@ static int tps6507x_dcdc_get_voltage(struct regulator_dev *dev)
 		return -EINVAL;
 	}
 
-	data = tps_6507x_reg_read(tps, reg);
+	data = tps6507x_pmic_reg_read(tps, reg);
 	if (data < 0)
 		return data;
 
@@ -311,10 +313,10 @@ static int tps6507x_dcdc_get_voltage(struct regulator_dev *dev)
 	return tps->info[dcdc]->table[data] * 1000;
 }
 
-static int tps6507x_dcdc_set_voltage(struct regulator_dev *dev,
+static int tps6507x_pmic_dcdc_set_voltage(struct regulator_dev *dev,
 				int min_uV, int max_uV)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int data, vsel, dcdc = rdev_get_id(dev);
 	u8 reg;
 
@@ -352,19 +354,19 @@ static int tps6507x_dcdc_set_voltage(struct regulator_dev *dev,
 	if (vsel == tps->info[dcdc]->table_len)
 		return -EINVAL;
 
-	data = tps_6507x_reg_read(tps, reg);
+	data = tps6507x_pmic_reg_read(tps, reg);
 	if (data < 0)
 		return data;
 
 	data &= ~TPS6507X_DEFDCDCX_DCDC_MASK;
 	data |= vsel;
 
-	return tps_6507x_reg_write(tps, reg, data);
+	return tps6507x_pmic_reg_write(tps, reg, data);
 }
 
-static int tps6507x_ldo_get_voltage(struct regulator_dev *dev)
+static int tps6507x_pmic_ldo_get_voltage(struct regulator_dev *dev)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int data, ldo = rdev_get_id(dev);
 	u8 reg, mask;
 
@@ -378,7 +380,7 @@ static int tps6507x_ldo_get_voltage(struct regulator_dev *dev)
 				TPS6507X_REG_DEFLDO2_LDO2_MASK);
 	}
 
-	data = tps_6507x_reg_read(tps, reg);
+	data = tps6507x_pmic_reg_read(tps, reg);
 	if (data < 0)
 		return data;
 
@@ -386,10 +388,10 @@ static int tps6507x_ldo_get_voltage(struct regulator_dev *dev)
 	return tps->info[ldo]->table[data] * 1000;
 }
 
-static int tps6507x_ldo_set_voltage(struct regulator_dev *dev,
+static int tps6507x_pmic_ldo_set_voltage(struct regulator_dev *dev,
 				int min_uV, int max_uV)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int data, vsel, ldo = rdev_get_id(dev);
 	u8 reg, mask;
 
@@ -420,20 +422,20 @@ static int tps6507x_ldo_set_voltage(struct regulator_dev *dev,
 	if (vsel == tps->info[ldo]->table_len)
 		return -EINVAL;
 
-	data = tps_6507x_reg_read(tps, reg);
+	data = tps6507x_pmic_reg_read(tps, reg);
 	if (data < 0)
 		return data;
 
 	data &= ~mask;
 	data |= vsel;
 
-	return tps_6507x_reg_write(tps, reg, data);
+	return tps6507x_pmic_reg_write(tps, reg, data);
 }
 
-static int tps6507x_dcdc_list_voltage(struct regulator_dev *dev,
+static int tps6507x_pmic_dcdc_list_voltage(struct regulator_dev *dev,
 					unsigned selector)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int dcdc = rdev_get_id(dev);
 
 	if (dcdc < TPS6507X_DCDC_1 || dcdc > TPS6507X_DCDC_3)
@@ -445,10 +447,10 @@ static int tps6507x_dcdc_list_voltage(struct regulator_dev *dev,
 		return tps->info[dcdc]->table[selector] * 1000;
 }
 
-static int tps6507x_ldo_list_voltage(struct regulator_dev *dev,
+static int tps6507x_pmic_ldo_list_voltage(struct regulator_dev *dev,
 					unsigned selector)
 {
-	struct tps_pmic *tps = rdev_get_drvdata(dev);
+	struct tps6507x_pmic *tps = rdev_get_drvdata(dev);
 	int ldo = rdev_get_id(dev);
 
 	if (ldo < TPS6507X_LDO_1 || ldo > TPS6507X_LDO_2)
@@ -461,33 +463,33 @@ static int tps6507x_ldo_list_voltage(struct regulator_dev *dev,
 }
 
 /* Operations permitted on VDCDCx */
-static struct regulator_ops tps6507x_dcdc_ops = {
-	.is_enabled = tps6507x_dcdc_is_enabled,
-	.enable = tps6507x_dcdc_enable,
-	.disable = tps6507x_dcdc_disable,
-	.get_voltage = tps6507x_dcdc_get_voltage,
-	.set_voltage = tps6507x_dcdc_set_voltage,
-	.list_voltage = tps6507x_dcdc_list_voltage,
+static struct regulator_ops tps6507x_pmic_dcdc_ops = {
+	.is_enabled = tps6507x_pmic_dcdc_is_enabled,
+	.enable = tps6507x_pmic_dcdc_enable,
+	.disable = tps6507x_pmic_dcdc_disable,
+	.get_voltage = tps6507x_pmic_dcdc_get_voltage,
+	.set_voltage = tps6507x_pmic_dcdc_set_voltage,
+	.list_voltage = tps6507x_pmic_dcdc_list_voltage,
 };
 
 /* Operations permitted on LDOx */
-static struct regulator_ops tps6507x_ldo_ops = {
-	.is_enabled = tps6507x_ldo_is_enabled,
-	.enable = tps6507x_ldo_enable,
-	.disable = tps6507x_ldo_disable,
-	.get_voltage = tps6507x_ldo_get_voltage,
-	.set_voltage = tps6507x_ldo_set_voltage,
-	.list_voltage = tps6507x_ldo_list_voltage,
+static struct regulator_ops tps6507x_pmic_ldo_ops = {
+	.is_enabled = tps6507x_pmic_ldo_is_enabled,
+	.enable = tps6507x_pmic_ldo_enable,
+	.disable = tps6507x_pmic_ldo_disable,
+	.get_voltage = tps6507x_pmic_ldo_get_voltage,
+	.set_voltage = tps6507x_pmic_ldo_set_voltage,
+	.list_voltage = tps6507x_pmic_ldo_list_voltage,
 };
 
-static int __devinit tps_6507x_probe(struct i2c_client *client,
+static int __devinit tps6507x_pmic_probe(struct i2c_client *client,
 				     const struct i2c_device_id *id)
 {
 	static int desc_id;
 	const struct tps_info *info = (void *)id->driver_data;
 	struct regulator_init_data *init_data;
 	struct regulator_dev *rdev;
-	struct tps_pmic *tps;
+	struct tps6507x_pmic *tps;
 	struct tps6507x_board *tps_board;
 	int i;
 	int error;
@@ -529,7 +531,7 @@ static int __devinit tps_6507x_probe(struct i2c_client *client,
 		tps->desc[i].id = desc_id++;
 		tps->desc[i].n_voltages = num_voltages[i];
 		tps->desc[i].ops = (i > TPS6507X_DCDC_3 ?
-				&tps6507x_ldo_ops : &tps6507x_dcdc_ops);
+		&tps6507x_pmic_ldo_ops : &tps6507x_pmic_dcdc_ops);
 		tps->desc[i].type = REGULATOR_VOLTAGE;
 		tps->desc[i].owner = THIS_MODULE;
 
@@ -559,14 +561,14 @@ fail:
 }
 
 /**
- * tps_6507x_remove - TPS6507x driver i2c remove handler
+ * tps6507x_remove - TPS6507x driver i2c remove handler
  * @client: i2c driver client device structure
  *
  * Unregister TPS driver as an i2c client device driver
  */
-static int __devexit tps_6507x_remove(struct i2c_client *client)
+static int __devexit tps6507x_pmic_remove(struct i2c_client *client)
 {
-	struct tps_pmic *tps = i2c_get_clientdata(client);
+	struct tps6507x_pmic *tps = i2c_get_clientdata(client);
 	int i;
 
 	/* clear the client data in i2c */
@@ -580,7 +582,7 @@ static int __devexit tps_6507x_remove(struct i2c_client *client)
 	return 0;
 }
 
-static const struct tps_info tps6507x_regs[] = {
+static const struct tps_info tps6507x_pmic_regs[] = {
 	{
 		.name = "VDCDC1",
 		.min_uV = 725000,
@@ -618,44 +620,44 @@ static const struct tps_info tps6507x_regs[] = {
 	},
 };
 
-static const struct i2c_device_id tps_6507x_id[] = {
+static const struct i2c_device_id tps6507x_pmic_id[] = {
 	{.name = "tps6507x",
-	.driver_data = (unsigned long) tps6507x_regs,},
+	.driver_data = (unsigned long) tps6507x_pmic_regs,},
 	{ },
 };
-MODULE_DEVICE_TABLE(i2c, tps_6507x_id);
+MODULE_DEVICE_TABLE(i2c, tps6507x_pmic_id);
 
-static struct i2c_driver tps_6507x_i2c_driver = {
+static struct i2c_driver tps6507x_i2c_driver = {
 	.driver = {
 		.name = "tps6507x",
 		.owner = THIS_MODULE,
 	},
-	.probe = tps_6507x_probe,
-	.remove = __devexit_p(tps_6507x_remove),
-	.id_table = tps_6507x_id,
+	.probe = tps6507x_pmic_probe,
+	.remove = __devexit_p(tps6507x_pmic_remove),
+	.id_table = tps6507x_pmic_id,
 };
 
 /**
- * tps_6507x_init
+ * tps6507x_pmic_init
  *
  * Module init function
  */
-static int __init tps_6507x_init(void)
+static int __init tps6507x_pmic_init(void)
 {
-	return i2c_add_driver(&tps_6507x_i2c_driver);
+	return i2c_add_driver(&tps6507x_i2c_driver);
 }
-subsys_initcall(tps_6507x_init);
+subsys_initcall(tps6507x_pmic_init);
 
 /**
- * tps_6507x_cleanup
+ * tps6507x_pmic_cleanup
  *
  * Module exit function
  */
-static void __exit tps_6507x_cleanup(void)
+static void __exit tps6507x_pmic_cleanup(void)
 {
-	i2c_del_driver(&tps_6507x_i2c_driver);
+	i2c_del_driver(&tps6507x_i2c_driver);
 }
-module_exit(tps_6507x_cleanup);
+module_exit(tps6507x_pmic_cleanup);
 
 MODULE_AUTHOR("Texas Instruments");
 MODULE_DESCRIPTION("TPS6507x voltage regulator driver");
-- 
1.6.0.4


From todd.fischer at ridgerun.com  Mon Apr  5 21:23:59 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Mon,  5 Apr 2010 20:23:59 -0600
Subject: [PATCH 4/4]-V3 Add MFD driver for TPS6507x family of multi-function
	chips and move TPS6507x regulator driver from being stand-alone
	to using the MFD driver.
In-Reply-To: <1270520639-20516-4-git-send-email-todd.fischer@ridgerun.com>
References: <1270520639-20516-1-git-send-email-todd.fischer@ridgerun.com>
	<1270520639-20516-2-git-send-email-todd.fischer@ridgerun.com>
	<1270520639-20516-3-git-send-email-todd.fischer@ridgerun.com>
	<1270520639-20516-4-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <1270520639-20516-5-git-send-email-todd.fischer@ridgerun.com>

Add MFD driver for TPS6507x family of multi-function chips.  Move TPS6507x 
regulator driver from being stand-alone driver to using the MFD TPS6507x driver.

Signed-off-by: Todd Fischer <todd.fischer at ridgerun.com>
---
 drivers/mfd/Kconfig                    |   12 +++
 drivers/mfd/Makefile                   |    3 +-
 drivers/mfd/tps6507x.c                 |  155 ++++++++++++++++++++++++++++++++
 drivers/regulator/tps6507x-regulator.c |  153 +++++++++++++++----------------
 include/linux/mfd/tps6507x.h           |   22 +++++
 5 files changed, 265 insertions(+), 80 deletions(-)
 create mode 100644 drivers/mfd/tps6507x.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2a5a0b7..1e301ad 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -111,6 +111,18 @@ config TPS65010
 	  This driver can also be built as a module.  If so, the module
 	  will be called tps65010.
 
+config TPS6507X
+	tristate "TPS6507x Power Management / Touch Screen chips"
+	select MFD_CORE
+	depends on I2C
+	help
+	  If you say yes here you get support for the TPS6507x series of
+	  Power Management / Touch Screen chips.  These include voltage
+	  regulators, lithium ion/polymer battery charging, touch screen
+	  and other features that are often used in portable devices.
+	  This driver can also be built as a module.  If so, the module
+	  will be called tps6507x.
+
 config MENELAUS
 	bool "Texas Instruments TWL92330/Menelaus PM chip"
 	depends on I2C=y && ARCH_OMAP2
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 22715ad..2bebc95 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_MFD_WM8350_I2C)	+= wm8350-i2c.o
 obj-$(CONFIG_MFD_WM8994)	+= wm8994-core.o
 
 obj-$(CONFIG_TPS65010)		+= tps65010.o
+obj-$(CONFIG_TPS6507X)		+= tps6507x.o
 obj-$(CONFIG_MENELAUS)		+= menelaus.o
 
 obj-$(CONFIG_TWL4030_CORE)	+= twl-core.o twl4030-irq.o twl6030-irq.o
@@ -62,4 +63,4 @@ obj-$(CONFIG_AB3100_OTP)	+= ab3100-otp.o
 obj-$(CONFIG_AB4500_CORE)	+= ab4500-core.o
 obj-$(CONFIG_MFD_TIMBERDALE)    += timberdale.o
 obj-$(CONFIG_PMIC_ADP5520)	+= adp5520.o
-obj-$(CONFIG_LPC_SCH)		+= lpc_sch.o
\ No newline at end of file
+obj-$(CONFIG_LPC_SCH)		+= lpc_sch.o
diff --git a/drivers/mfd/tps6507x.c b/drivers/mfd/tps6507x.c
new file mode 100644
index 0000000..5bca398
--- /dev/null
+++ b/drivers/mfd/tps6507x.c
@@ -0,0 +1,155 @@
+/*
+ * tps6507x.c  --  TPS6507x chip family multi-function driver
+ *
+ *  Copyright (c) 2010 RidgeRun (todd.fischer at ridgerun.com)
+ *
+ * Author: Todd Fischer
+ *         todd.fischer at ridgerun.com
+ *
+ * Credits:
+ *
+ *    Using code from wm831x-*.c, wm8400-core, Wolfson Microelectronics PLC.
+ *
+ * For licencing details see kernel-base/COPYING
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/init.h>
+#include <linux/i2c.h>
+#include <linux/mfd/core.h>
+#include <linux/mfd/tps6507x.h>
+
+static struct mfd_cell tps6507x_devs[] = {
+	{
+		.name = "tps6507x-pmic",
+	},
+};
+
+
+static int tps6507x_i2c_read_device(struct tps6507x_dev *tps6507x, char reg,
+				  int bytes, void *dest)
+{
+	struct i2c_client *i2c = tps6507x->i2c_client;
+	struct i2c_msg xfer[2];
+	int ret;
+
+	/* Write register */
+	xfer[0].addr = i2c->addr;
+	xfer[0].flags = 0;
+	xfer[0].len = 1;
+	xfer[0].buf = &reg;
+
+	/* Read data */
+	xfer[1].addr = i2c->addr;
+	xfer[1].flags = I2C_M_RD;
+	xfer[1].len = bytes;
+	xfer[1].buf = dest;
+
+	ret = i2c_transfer(i2c->adapter, xfer, 2);
+	if (ret == 2)
+		ret = 0;
+	else if (ret >= 0)
+		ret = -EIO;
+
+	return ret;
+}
+
+static int tps6507x_i2c_write_device(struct tps6507x_dev *tps6507x, char reg,
+				   int bytes, void *src)
+{
+	struct i2c_client *i2c = tps6507x->i2c_client;
+	/* we add 1 byte for device register */
+	u8 msg[TPS6507X_MAX_REGISTER + 1];
+	int ret;
+
+	if (bytes > (TPS6507X_MAX_REGISTER + 1))
+		return -EINVAL;
+
+	msg[0] = reg;
+	memcpy(&msg[1], src, bytes);
+
+	ret = i2c_master_send(i2c, msg, bytes + 1);
+	if (ret < 0)
+		return ret;
+	if (ret != bytes + 1)
+		return -EIO;
+	return 0;
+}
+
+static int tps6507x_i2c_probe(struct i2c_client *i2c,
+			    const struct i2c_device_id *id)
+{
+	struct tps6507x_dev *tps6507x;
+	int ret = 0;
+
+	tps6507x = kzalloc(sizeof(struct tps6507x_dev), GFP_KERNEL);
+	if (tps6507x == NULL) {
+		kfree(i2c);
+		return -ENOMEM;
+	}
+
+	i2c_set_clientdata(i2c, tps6507x);
+	tps6507x->dev = &i2c->dev;
+	tps6507x->i2c_client = i2c;
+	tps6507x->read_dev = tps6507x_i2c_read_device;
+	tps6507x->write_dev = tps6507x_i2c_write_device;
+
+	ret = mfd_add_devices(tps6507x->dev, -1,
+			      tps6507x_devs, ARRAY_SIZE(tps6507x_devs),
+			      NULL, 0);
+
+	if (ret < 0)
+		goto err;
+
+	return ret;
+
+err:
+	mfd_remove_devices(tps6507x->dev);
+	kfree(tps6507x);
+	return ret;
+}
+
+static int tps6507x_i2c_remove(struct i2c_client *i2c)
+{
+	struct tps6507x_dev *tps6507x = i2c_get_clientdata(i2c);
+
+	mfd_remove_devices(tps6507x->dev);
+	kfree(tps6507x);
+
+	return 0;
+}
+
+static const struct i2c_device_id tps6507x_i2c_id[] = {
+       { "tps6507x", 0 },
+       { }
+};
+MODULE_DEVICE_TABLE(i2c, tps6507x_i2c_id);
+
+
+static struct i2c_driver tps6507x_i2c_driver = {
+	.driver = {
+		   .name = "tps6507x",
+		   .owner = THIS_MODULE,
+	},
+	.probe = tps6507x_i2c_probe,
+	.remove = tps6507x_i2c_remove,
+	.id_table = tps6507x_i2c_id,
+};
+
+static int __init tps6507x_i2c_init(void)
+{
+	return i2c_add_driver(&tps6507x_i2c_driver);
+}
+/* init early so consumer devices can complete system boot */
+subsys_initcall(tps6507x_i2c_init);
+
+static void __exit tps6507x_i2c_exit(void)
+{
+	i2c_del_driver(&tps6507x_i2c_driver);
+}
+module_exit(tps6507x_i2c_exit);
+
+MODULE_DESCRIPTION("TPS6507x chip family multi-function driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/regulator/tps6507x-regulator.c b/drivers/regulator/tps6507x-regulator.c
index 86f2e05..e4d7d2f 100644
--- a/drivers/regulator/tps6507x-regulator.c
+++ b/drivers/regulator/tps6507x-regulator.c
@@ -22,7 +22,6 @@
 #include <linux/platform_device.h>
 #include <linux/regulator/driver.h>
 #include <linux/regulator/machine.h>
-#include <linux/i2c.h>
 #include <linux/delay.h>
 #include <linux/mfd/tps6507x.h>
 
@@ -103,22 +102,67 @@ struct tps_info {
 	const u16 *table;
 };
 
+static const struct tps_info tps6507x_pmic_regs[] = {
+	{
+		.name = "VDCDC1",
+		.min_uV = 725000,
+		.max_uV = 3300000,
+		.table_len = ARRAY_SIZE(VDCDCx_VSEL_table),
+		.table = VDCDCx_VSEL_table,
+	},
+	{
+		.name = "VDCDC2",
+		.min_uV = 725000,
+		.max_uV = 3300000,
+		.table_len = ARRAY_SIZE(VDCDCx_VSEL_table),
+		.table = VDCDCx_VSEL_table,
+	},
+	{
+		.name = "VDCDC3",
+		.min_uV = 725000,
+		.max_uV = 3300000,
+		.table_len = ARRAY_SIZE(VDCDCx_VSEL_table),
+		.table = VDCDCx_VSEL_table,
+	},
+	{
+		.name = "LDO1",
+		.min_uV = 1000000,
+		.max_uV = 3300000,
+		.table_len = ARRAY_SIZE(LDO1_VSEL_table),
+		.table = LDO1_VSEL_table,
+	},
+	{
+		.name = "LDO2",
+		.min_uV = 725000,
+		.max_uV = 3300000,
+		.table_len = ARRAY_SIZE(LDO2_VSEL_table),
+		.table = LDO2_VSEL_table,
+	},
+};
+
 struct tps6507x_pmic {
 	struct regulator_desc desc[TPS6507X_NUM_REGULATOR];
-	struct i2c_client *client;
+	struct tps6507x_dev *mfd;
 	struct regulator_dev *rdev[TPS6507X_NUM_REGULATOR];
 	const struct tps_info *info[TPS6507X_NUM_REGULATOR];
 	struct mutex io_lock;
 };
-
 static inline int tps6507x_pmic_read(struct tps6507x_pmic *tps, u8 reg)
 {
-	return i2c_smbus_read_byte_data(tps->client, reg);
+	u8 val;
+	int err;
+
+	err = tps->mfd->read_dev(tps->mfd, reg, 1, &val);
+
+	if (err)
+		return err;
+
+	return val;
 }
 
 static inline int tps6507x_pmic_write(struct tps6507x_pmic *tps, u8 reg, u8 val)
 {
-	return i2c_smbus_write_byte_data(tps->client, reg, val);
+	return tps->mfd->write_dev(tps->mfd, reg, 1, &val);
 }
 
 static int tps6507x_pmic_set_bits(struct tps6507x_pmic *tps, u8 reg, u8 mask)
@@ -129,7 +173,7 @@ static int tps6507x_pmic_set_bits(struct tps6507x_pmic *tps, u8 reg, u8 mask)
 
 	data = tps6507x_pmic_read(tps, reg);
 	if (data < 0) {
-		dev_err(&tps->client->dev, "Read from reg 0x%x failed\n", reg);
+		dev_err(tps->mfd->dev, "Read from reg 0x%x failed\n", reg);
 		err = data;
 		goto out;
 	}
@@ -137,7 +181,7 @@ static int tps6507x_pmic_set_bits(struct tps6507x_pmic *tps, u8 reg, u8 mask)
 	data |= mask;
 	err = tps6507x_pmic_write(tps, reg, data);
 	if (err)
-		dev_err(&tps->client->dev, "Write for reg 0x%x failed\n", reg);
+		dev_err(tps->mfd->dev, "Write for reg 0x%x failed\n", reg);
 
 out:
 	mutex_unlock(&tps->io_lock);
@@ -152,7 +196,7 @@ static int tps6507x_pmic_clear_bits(struct tps6507x_pmic *tps, u8 reg, u8 mask)
 
 	data = tps6507x_pmic_read(tps, reg);
 	if (data < 0) {
-		dev_err(&tps->client->dev, "Read from reg 0x%x failed\n", reg);
+		dev_err(tps->mfd->dev, "Read from reg 0x%x failed\n", reg);
 		err = data;
 		goto out;
 	}
@@ -160,7 +204,7 @@ static int tps6507x_pmic_clear_bits(struct tps6507x_pmic *tps, u8 reg, u8 mask)
 	data &= ~mask;
 	err = tps6507x_pmic_write(tps, reg, data);
 	if (err)
-		dev_err(&tps->client->dev, "Write for reg 0x%x failed\n", reg);
+		dev_err(tps->mfd->dev, "Write for reg 0x%x failed\n", reg);
 
 out:
 	mutex_unlock(&tps->io_lock);
@@ -175,7 +219,7 @@ static int tps6507x_pmic_reg_read(struct tps6507x_pmic *tps, u8 reg)
 
 	data = tps6507x_pmic_read(tps, reg);
 	if (data < 0)
-		dev_err(&tps->client->dev, "Read from reg 0x%x failed\n", reg);
+		dev_err(tps->mfd->dev, "Read from reg 0x%x failed\n", reg);
 
 	mutex_unlock(&tps->io_lock);
 	return data;
@@ -189,7 +233,7 @@ static int tps6507x_pmic_reg_write(struct tps6507x_pmic *tps, u8 reg, u8 val)
 
 	err = tps6507x_pmic_write(tps, reg, val);
 	if (err < 0)
-		dev_err(&tps->client->dev, "Write for reg 0x%x failed\n", reg);
+		dev_err(tps->mfd->dev, "Write for reg 0x%x failed\n", reg);
 
 	mutex_unlock(&tps->io_lock);
 	return err;
@@ -482,11 +526,12 @@ static struct regulator_ops tps6507x_pmic_ldo_ops = {
 	.list_voltage = tps6507x_pmic_ldo_list_voltage,
 };
 
-static int __devinit tps6507x_pmic_probe(struct i2c_client *client,
-				     const struct i2c_device_id *id)
+static __devinit
+int tps6507x_pmic_probe(struct platform_device *pdev)
 {
+	struct tps6507x_dev *tps6507x_dev = dev_get_drvdata(pdev->dev.parent);
 	static int desc_id;
-	const struct tps_info *info = (void *)id->driver_data;
+	const struct tps_info *info = &tps6507x_pmic_regs[0];
 	struct regulator_init_data *init_data;
 	struct regulator_dev *rdev;
 	struct tps6507x_pmic *tps;
@@ -494,16 +539,12 @@ static int __devinit tps6507x_pmic_probe(struct i2c_client *client,
 	int i;
 	int error;
 
-	if (!i2c_check_functionality(client->adapter,
-				I2C_FUNC_SMBUS_BYTE_DATA))
-		return -EIO;
-
 	/**
 	 * tps_board points to pmic related constants
 	 * coming from the board-evm file.
 	 */
 
-	tps_board = dev_get_platdata(&client->dev);
+	tps_board = dev_get_platdata(tps6507x_dev->dev);
 	if (!tps_board)
 		return -EINVAL;
 
@@ -522,7 +563,7 @@ static int __devinit tps6507x_pmic_probe(struct i2c_client *client,
 	mutex_init(&tps->io_lock);
 
 	/* common for all regulators */
-	tps->client = client;
+	tps->mfd = tps6507x_dev;
 
 	for (i = 0; i < TPS6507X_NUM_REGULATOR; i++, info++, init_data++) {
 		/* Register the regulators */
@@ -536,10 +577,11 @@ static int __devinit tps6507x_pmic_probe(struct i2c_client *client,
 		tps->desc[i].owner = THIS_MODULE;
 
 		rdev = regulator_register(&tps->desc[i],
-					&client->dev, init_data, tps);
+					tps6507x_dev->dev, init_data, tps);
 		if (IS_ERR(rdev)) {
-			dev_err(&client->dev, "failed to register %s\n",
-				id->name);
+			dev_err(tps6507x_dev->dev,
+				"failed to register %s regulator\n",
+				pdev->name);
 			error = PTR_ERR(rdev);
 			goto fail;
 		}
@@ -548,7 +590,7 @@ static int __devinit tps6507x_pmic_probe(struct i2c_client *client,
 		tps->rdev[i] = rdev;
 	}
 
-	i2c_set_clientdata(client, tps);
+	tps6507x_dev->pmic = tps;
 
 	return 0;
 
@@ -566,14 +608,12 @@ fail:
  *
  * Unregister TPS driver as an i2c client device driver
  */
-static int __devexit tps6507x_pmic_remove(struct i2c_client *client)
+static int __devexit tps6507x_pmic_remove(struct platform_device *pdev)
 {
-	struct tps6507x_pmic *tps = i2c_get_clientdata(client);
+	struct tps6507x_dev *tps6507x_dev = platform_get_drvdata(pdev);
+	struct tps6507x_pmic *tps = tps6507x_dev->pmic;
 	int i;
 
-	/* clear the client data in i2c */
-	i2c_set_clientdata(client, NULL);
-
 	for (i = 0; i < TPS6507X_NUM_REGULATOR; i++)
 		regulator_unregister(tps->rdev[i]);
 
@@ -582,59 +622,13 @@ static int __devexit tps6507x_pmic_remove(struct i2c_client *client)
 	return 0;
 }
 
-static const struct tps_info tps6507x_pmic_regs[] = {
-	{
-		.name = "VDCDC1",
-		.min_uV = 725000,
-		.max_uV = 3300000,
-		.table_len = ARRAY_SIZE(VDCDCx_VSEL_table),
-		.table = VDCDCx_VSEL_table,
-	},
-	{
-		.name = "VDCDC2",
-		.min_uV = 725000,
-		.max_uV = 3300000,
-		.table_len = ARRAY_SIZE(VDCDCx_VSEL_table),
-		.table = VDCDCx_VSEL_table,
-	},
-	{
-		.name = "VDCDC3",
-		.min_uV = 725000,
-		.max_uV = 3300000,
-		.table_len = ARRAY_SIZE(VDCDCx_VSEL_table),
-		.table = VDCDCx_VSEL_table,
-	},
-	{
-		.name = "LDO1",
-		.min_uV = 1000000,
-		.max_uV = 3300000,
-		.table_len = ARRAY_SIZE(LDO1_VSEL_table),
-		.table = LDO1_VSEL_table,
-	},
-	{
-		.name = "LDO2",
-		.min_uV = 725000,
-		.max_uV = 3300000,
-		.table_len = ARRAY_SIZE(LDO2_VSEL_table),
-		.table = LDO2_VSEL_table,
-	},
-};
-
-static const struct i2c_device_id tps6507x_pmic_id[] = {
-	{.name = "tps6507x",
-	.driver_data = (unsigned long) tps6507x_pmic_regs,},
-	{ },
-};
-MODULE_DEVICE_TABLE(i2c, tps6507x_pmic_id);
-
-static struct i2c_driver tps6507x_i2c_driver = {
+static struct platform_driver tps6507x_pmic_driver = {
 	.driver = {
-		.name = "tps6507x",
+		.name = "tps6507x-pmic",
 		.owner = THIS_MODULE,
 	},
 	.probe = tps6507x_pmic_probe,
 	.remove = __devexit_p(tps6507x_pmic_remove),
-	.id_table = tps6507x_pmic_id,
 };
 
 /**
@@ -644,7 +638,7 @@ static struct i2c_driver tps6507x_i2c_driver = {
  */
 static int __init tps6507x_pmic_init(void)
 {
-	return i2c_add_driver(&tps6507x_i2c_driver);
+	return platform_driver_register(&tps6507x_pmic_driver);
 }
 subsys_initcall(tps6507x_pmic_init);
 
@@ -655,10 +649,11 @@ subsys_initcall(tps6507x_pmic_init);
  */
 static void __exit tps6507x_pmic_cleanup(void)
 {
-	i2c_del_driver(&tps6507x_i2c_driver);
+	platform_driver_unregister(&tps6507x_pmic_driver);
 }
 module_exit(tps6507x_pmic_cleanup);
 
 MODULE_AUTHOR("Texas Instruments");
 MODULE_DESCRIPTION("TPS6507x voltage regulator driver");
 MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:tps6507x-pmic");
diff --git a/include/linux/mfd/tps6507x.h b/include/linux/mfd/tps6507x.h
index fd73af5..9543cb7 100644
--- a/include/linux/mfd/tps6507x.h
+++ b/include/linux/mfd/tps6507x.h
@@ -131,6 +131,8 @@
 /* VDCDC MASK */
 #define TPS6507X_DEFDCDCX_DCDC_MASK		0X3F
 
+#define TPS6507X_MAX_REGISTER			0X19
+
 /**
  * struct tps6507x_board - packages regulator and touchscreen init data
  * @tps6507x_regulator_data: regulator initialization values
@@ -142,4 +144,24 @@ struct tps6507x_board {
 	struct regulator_init_data *tps6507x_pmic_init_data;
 };
 
+/**
+ * struct tps6507x_dev - tps6507x sub-driver chip access routines
+ * @read_dev() - I2C register read function
+ * @write_dev() - I2C register write function
+ *
+ * Device data may be used to access the TPS6507x chip
+ */
+
+struct tps6507x_dev {
+	struct device *dev;
+	struct i2c_client *i2c_client;
+	int (*read_dev)(struct tps6507x_dev *tps6507x, char reg, int size,
+			void *dest);
+	int (*write_dev)(struct tps6507x_dev *tps6507x, char reg, int size,
+			 void *src);
+
+	/* Client devices */
+	struct tps6507x_pmic *pmic;
+};
+
 #endif /*  __LINUX_MFD_TPS6507X_H */
-- 
1.6.0.4


From nsekhar at ti.com  Tue Apr  6 00:42:43 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 6 Apr 2010 11:12:43 +0530
Subject: [PATCH v2 15/16] Davinci: initial tnetv107x support
In-Reply-To: <1269553439-14886-16-git-send-email-cyril@ti.com>
References: <1269553439-14886-1-git-send-email-cyril@ti.com>
	<1269553439-14886-2-git-send-email-cyril@ti.com>
	<1269553439-14886-3-git-send-email-cyril@ti.com>
	<1269553439-14886-4-git-send-email-cyril@ti.com>
	<1269553439-14886-5-git-send-email-cyril@ti.com>
	<1269553439-14886-6-git-send-email-cyril@ti.com>
	<1269553439-14886-7-git-send-email-cyril@ti.com>
	<1269553439-14886-8-git-send-email-cyril@ti.com>
	<1269553439-14886-9-git-send-email-cyril@ti.com>
	<1269553439-14886-10-git-send-email-cyril@ti.com>
	<1269553439-14886-11-git-send-email-cyril@ti.com>
	<1269553439-14886-12-git-send-email-cyril@ti.com>
	<1269553439-14886-13-git-send-email-cyril@ti.com>
	<1269553439-14886-14-git-send-email-cyril@ti.com>
	<1269553439-14886-15-git-send-email-cyril@ti.com>
	<1269553439-14886-16-git-send-email-cyril@ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E669976F@dbde02.ent.ti.com>


Hi Cyril,

On Fri, Mar 26, 2010 at 03:13:58, Chemparathy, Cyril wrote:
> 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 PLL.  Some
> elements of the clock architecture are reused from Davinci (e.g. LPSC), but
> the PLL related code is overridden using existing interfaces in "struct clk".
>
> 2. The MMR layout on this SOC is substantially different from Davinci.
> Consequently, the fixed I/O map is a whole lot more convoluted (more so than
> DA8xx).  The net impact here is that IO_ADDRESS() will not work on this SoC,
> and therefore all mappings have to be through ioremap().
>
> 3. The Davinci reset mechanism (via Timer64 watchdog) will not work on this
> SoC.  This difference has not been addressed here (dummy davinci_wdt_device),
> but a more "extensible" reset mechanism will need to be established
> eventually.

It will be nice to point out which of the existing platforms
were tested to be working after this series was applied
(with some indication of the type of testing done).

>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> ---

[...]

> +
> +static struct resource wdt_resources[] = {
> +     {
> +             .start  = TNETV107X_TIMER1_BASE,
> +             .end    = TNETV107X_TIMER1_BASE + SZ_4K - 1,
> +             .flags  = IORESOURCE_MEM,
> +     },
> +};
> +
> +struct platform_device davinci_wdt_device = {
> +     .name           = "watchdog",
> +     .id             = -1,
> +     .num_resources  = ARRAY_SIZE(wdt_resources),
> +     .resource       = wdt_resources,
> +};

IMO, a better way to overcome the 'no watchdog timer'
limitation would be to make the watchdog reset code
not use the wdt platform data directly, but instead
'search' for watchdog device using bus_for_each_dev()
iterator on platform bus.

In your case, the watchdog device wouldn't be found
and the reset function should exist gracefully.

[...]

> +
> +void __init tnetv107x_edma_init(void)
> +{
> +     platform_device_register(&edma_device);
> +}
> +
> +void __init tnetv107x_serial_init(struct plat_serial8250_port* ports)
> +{
> +     int i;
> +     char name[16];
> +     struct clk *uart_clk;
> +
> +     for (i = 0; ports[i].flags; i++) {
> +             sprintf(name, "uart%d", i);
> +             uart_clk = clk_get(NULL, name);
> +             if (IS_ERR(uart_clk))
> +                     printk(KERN_ERR "%s:%d: failed to get UART%d clock\n",
> +                                     __func__, __LINE__, i);
> +             else {
> +                     clk_enable(uart_clk);
> +                     ports[i].uartclk = clk_get_rate(uart_clk);
> +             }
> +     }
> +}

An explanation on why davinci_serial_init() is no good for
this SoC would be good.

[...]

> diff --git a/arch/arm/mach-davinci/tnetv107x.c b/arch/arm/mach-davinci/tnetv107x.c
> new file mode 100644
> index 0000000..30ff23b
> --- /dev/null
> +++ b/arch/arm/mach-davinci/tnetv107x.c
> @@ -0,0 +1,1222 @@
> +/*
> + * TI TNETV107X chip specific setup
> + *
> + * Author: Cyril Chemparathy <cyril at ti.com>
> + *
> + * 2009 (c) Texas Instruments, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This program
> + * is licensed "as is" without any warranty of any kind, whether express
> + * or implied.
> + */
> +
> +/*
> + * TNETV107X clock control implementation doesn't (at this point) reuse
> + * much of Davinci's generic implementation. This is because of the
> + * SSPLL nastiness that is present on this part.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +
> +#include <asm/mach/map.h>
> +
> +#include <mach/common.h>
> +#include <mach/time.h>
> +#include <mach/cputype.h>
> +#include <mach/psc.h>
> +#include <mach/cp_intc.h>
> +#include <mach/irqs.h>
> +#include <mach/hardware.h>
> +#include <mach/tnetv107x.h>
> +
> +#include "clock.h"
> +#include "mux.h"
> +
> +/* Reference clock frequencies */
> +#define OSC_FREQ_ONCHIP              (24000 * 1000)
> +#define OSC_FREQ_OFFCHIP_SYS (25000 * 1000)
> +#define OSC_FREQ_OFFCHIP_ETH (25000 * 1000)
> +#define OSC_FREQ_OFFCHIP_TDM (19200 * 1000)
> +
> +/* PLL Types */
> +enum pll_type {
> +     SYS_PLL,
> +     TDM_PLL,
> +     ETH_PLL,
> +     N_PLLS
> +};
> +
> +/* Clock Control Registers */
> +struct clk_ctrl_regs {
> +     u32     pll_bypass;
> +     u32     _reserved0;
> +     u32     gem_lrst;
> +     u32     _reserved1;
> +     u32     pll_unlock_stat;
> +     u32     sys_unlock;
> +     u32     eth_unlock;
> +     u32     tdm_unlock;
> +};
> +
> +/* SSPLL Registers */
> +struct sspll_regs {
> +     u32     modes;
> +     u32     post_div;
> +     u32     pre_div;
> +     u32     mult_factor;
> +     u32     divider_range;
> +     u32     bw_divider;
> +     u32     spr_amount;
> +     u32     spr_rate_div;
> +     u32     diag;
> +};
> +
> +static struct clk_ctrl_regs __iomem *clk_ctrl_regs;
> +
> +static struct sspll_regs __iomem *sspll_regs[N_PLLS];
> +static int sspll_regs_base[N_PLLS] = { 0x40, 0x80, 0xc0 };
> +
> +/* PLL Control Registers (same as in Davinci) */
> +static void __iomem *pllctl_regs[N_PLLS];
> +static int pllctl_regs_base[N_PLLS] = { 0x600, 0x200, 0x400 };
> +
> +/* PLL bypass bit shifts in clk_ctrl_regs->pll_bypass register */
> +static u32 bypass_mask[N_PLLS] = { BIT(0), BIT(2), BIT(1) };
> +
> +/* different PLLs have different limits on the divider max */
> +static u32 div_mask[] = {0x01ff, 0x00ff, 0x00ff};
> +
> +/* offchip (external) reference clock frequencies */
> +static u32 pll_ext_freq[] = {
> +     OSC_FREQ_OFFCHIP_SYS,
> +     OSC_FREQ_OFFCHIP_TDM,
> +     OSC_FREQ_OFFCHIP_ETH
> +};
> +
> +/* PSC control registers */
> +static void __iomem *psc_regs[1];
> +
> +/* Host map for interrupt controller */
> +static u32 intc_host_map[] = { 0x01010000, 0x01010101, -1 };
> +
> +static unsigned long clk_sspll_recalc(struct clk *clk);
> +static unsigned long clk_div_recalc(struct clk *clk);
> +static unsigned long clk_null_recalc(struct clk *clk);
> +
> +static struct pll_data pll_sys_data = { .num = SYS_PLL };
> +static struct pll_data pll_eth_data = { .num = ETH_PLL };
> +static struct pll_data pll_tdm_data = { .num = TDM_PLL };
> +

[...]

> +
> +
> +/* LPSC Gated Clocks */
> +static struct clk clk_arm = {
> +     .name           = "clk_arm",

[...]

> +
> +static struct clk clk_ddr2_vctl_rst = {
> +     .name           = "clk_ddr2_vctl_rst",

No need of the 'clk_' prefix for all the LPSC
clock names.

[...]

> +
> +/*
> + * TNETV107X platforms do not use the static mappings from Davinci
> + * IO_PHYS/IO_VIRT. This SOC's interesting MMRs are at different addresses,
> + * and changing IO_PHYS would break away from existing Davinci SOCs.

So why not redefine the IO_PHYS for this SoC? I believe you are not able
to build a single image for TNETV107x and DaVinci anyway.

That should also avoid the EDMA issue you highlight below.

> + *
> + * The primary impact of the current model is that IO_ADDRESS() is not to be
> + * used to map registers on TNETV107X. With the exception of early boot code
> + * in tnetv107x_init() (where fixed maps are necessary), all other pieces of
> + * code absolutely _must_ use ioremap().
> + *
> + * 1.        The first section in here is specifically for edma, even through the
> + *   edma driver code properly ioremap()s its register space.  This is
> + *   because the edma MMRs on tnetv107x unfortunately fall within the
> + *   davinci IO_PHYS - (IO_PHYS + IO_SIZE) range, and therefore the edma
> + *   driver's ioremap() gets subverted by davinci_ioremap(). Yikes!
> + *
> + * 2.        The second chunk is for INTC - no major issues here.  If the cp_intc
> + *   code were to someday ioremap() internally, we could very well get rid
> + *   of this map.
> + *
> + * 3.        The third chunk maps in register areas that need to be populated into
> + *   davinci_soc_info.  Note that alignment restrictions come into play if
> + *   low-level debug is enabled (see note in <mach/tnetv107x.h>).
> + */
> +static struct map_desc tnetv107x_io_desc[] = {
> +     {       /* EDMA */
> +             .virtual        = IO_VIRT,
> +             .pfn            = __phys_to_pfn(IO_PHYS),
> +             .length         = SZ_128K,
> +             .type           = MT_DEVICE
> +     },
> +     {       /* INTC */
> +             .virtual        = IO_VIRT + SZ_128K,
> +             .pfn            = __phys_to_pfn(TNETV107X_INTC_BASE),
> +             .length         = SZ_16K,
> +             .type           = MT_DEVICE
> +     },
> +     {       /* Most of the rest */
> +             .virtual        = TNETV107X_IO_VIRT,
> +             .pfn            = __phys_to_pfn(TNETV107X_IO_BASE),
> +             .length         = IO_SIZE - SZ_1M,
> +             .type           = MT_DEVICE
> +     },
> +};
> +

[...]

> +
> +static void __iomem *fixed_ioremap(unsigned long p, size_t size)
> +{
> +     struct map_desc *map = tnetv107x_soc_info.io_desc;
> +     int i;
> +
> +     for (i = 0; i < tnetv107x_soc_info.io_desc_num; i++) {
> +             unsigned long iophys = __pfn_to_phys(map[i].pfn);
> +             unsigned long iosize = map[i].length;
> +
> +             if (p >= iophys && (p + size) <= (iophys + iosize))
> +                     return IOMEM(map[i].virtual + p - iophys);
> +     }
> +
> +     panic("attempt to map invalid physical range %lx-%lx\n",
> +                     p, p + size);
> +}

This sounds like something that should be useful on
all DaVinci SoCs. Why not make davinci_ioremap to do
exactly this?

> +
> +void __init tnetv107x_init(void)
> +{
> +     void __iomem *tmp;
> +     int i;
> +
> +     /*
> +      * Figure out virtual addresses for necessary peripherals, but do not
> +      * access any of these here. iotable_init() needs to happen for the
> +      * mappings to actually get setup
> +      */
> +     clk_ctrl_regs = tmp =
> +             fixed_ioremap(TNETV107X_CLOCK_CONTROL_BASE, SZ_4K);
> +
> +     for (i = 0; i < N_PLLS; i++) {
> +             sspll_regs[i] = tmp + sspll_regs_base[i];
> +             pllctl_regs[i] = tmp + pllctl_regs_base[i];
> +     }
> +
> +     psc_regs[0] = fixed_ioremap(TNETV107X_PSC_BASE, SZ_4K);
> +
> +     tmp = fixed_ioremap(TNETV107X_CHIP_CFG_BASE, SZ_4K);
> +     tnetv107x_soc_info.jtag_id_base = tmp + 0x018;
> +     tnetv107x_soc_info.pinmux_base  = tmp + 0x150;
> +
> +     tnetv107x_soc_info.intc_base =
> +             fixed_ioremap(TNETV107X_INTC_BASE, SZ_16K);
> +
> +     tnetv107x_timer_instance[0].base =
> +             fixed_ioremap(TNETV107X_TIMER0_BASE, 0x100);
> +
> +     tnetv107x_timer_instance[1].base =
> +             fixed_ioremap(TNETV107X_TIMER1_BASE, 0x100);

All the fixed_ioremap stuff should disappear
if you can implement the comment above.

> +
> +     davinci_common_init(&tnetv107x_soc_info);
> +}
> +

[...]

> +
> +static unsigned long clk_sspll_recalc(struct clk *clk)
> +{
> +     int             pll;
> +     unsigned long   mult = 0, prediv = 1, postdiv = 1;
> +     unsigned long   ref = OSC_FREQ_ONCHIP, ret;
> +     u32             tmp;
> +
> +     if (WARN_ON(!clk->pll_data))
> +             return clk->rate;
> +
> +     pll = clk->pll_data->num;
> +
> +     tmp = __raw_readl(&clk_ctrl_regs->pll_bypass);
> +     if (!(tmp & bypass_mask[pll])) {
> +             mult    = __raw_readl(&sspll_regs[pll]->mult_factor);
> +             prediv  = __raw_readl(&sspll_regs[pll]->pre_div) + 1;
> +             postdiv = __raw_readl(&sspll_regs[pll]->post_div) + 1;
> +     }
> +
> +     tmp = __raw_readl(pllctl_regs[pll] + PLLCTL);
> +     if (tmp & PLLCTL_CLKMODE)
> +             ref = pll_ext_freq[pll];
> +
> +     clk->pll_data->input_rate = ref;
> +
> +     tmp = __raw_readl(pllctl_regs[pll] + PLLCTL);
> +     if (!(tmp & PLLCTL_PLLEN))
> +             return ref;
> +
> +     ret = ref;
> +     if (mult)
> +             ret += ((unsigned long long)ref * mult) / 256;
> +
> +     ret /= (prediv * postdiv);
> +
> +     return ret;
> +}

How about moving this to clock.c and using a flag in clk
structure to determine whether to use clk_pllclk_recalc()
or clk_sspll_recalc()?

> +
> +static unsigned long clk_div_recalc(struct clk *clk)
> +{
> +     struct pll_data *pll;
> +     unsigned long rate = clk->rate;
> +     unsigned long div;
> +
> +     if (WARN_ON(!clk->parent))
> +             return rate;
> +
> +     rate = clk->parent->rate;
> +
> +     /* Otherwise, the parent must be a PLL */
> +     if (WARN_ON(!clk->parent->pll_data))
> +             return rate;
> +
> +     pll = clk->parent->pll_data;
> +
> +     if (!clk->div_reg)
> +             return rate;
> +
> +     div = __raw_readl(pllctl_regs[pll->num] + clk->div_reg);
> +     if (div & PLLDIV_EN) {
> +             div &= div_mask[pll->num];
> +             rate /= (div + 1);
> +     }
> +
> +     return rate;
> +}

Is the div_mask the only reason you could not use clock.c:clk_sysclk_recalc()
here? How about making the mask a part of PLL data and using PLLDIV_RATIO_MASK
if no mask is initialized (zero)?

> +
> +static unsigned long clk_null_recalc(struct clk *clk)
> +{
> +     BUG_ON(!clk->parent);
> +     return clk->parent->rate;
> +}

There is already a function in clock.c which does exactly this
(clk_leafclk_recalc).

Thanks,
Sekhar


From liuyue18301 at 163.com  Tue Apr  6 02:12:10 2010
From: liuyue18301 at 163.com (liuyue18301)
Date: Tue, 6 Apr 2010 15:12:10 +0800 (CST)
Subject: confused in dsplink
Message-ID: <d260cf.a124.127d1f64850.Coremail.liuyue18301@163.com>




hello everybody:
     recently i am studing the DSP/BIOS Link i encouter some problems.please help me!
     fist, i can run the demos of code_engine and also can run the demos of dsplink  separtely but can i integrate demos of code_engine and dsplink into the code_engine when i try encouter some .h header file is confilict
    second,in the demos of the codec_engine,i think the demo must call the dsplink,but i can not approve this in the code.who can explain it
    thirdly,i want to caputer the image data and send the data to the romate dsp by dsplink,in my arm application code how can it call the dsplink?
    thank you very much
    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100406/aefd4e11/attachment.html>

From nyhetsbrev at dokumera.anp.se  Tue Apr  6 01:33:18 2010
From: nyhetsbrev at dokumera.anp.se (DokuMera Nyhetsbrev)
Date: Tue, 06 Apr 2010 08:33:18 +0200
Subject: Skattekonsekvenser
Message-ID: <1256583705.2784@dokumera.anp.se>


Om du har problem med att l?sa detta e-postmeddelande, klicka h?r (http://www.anp.se/newsletter/621716/44405D4074454B5C447043475843) f?r en webb-version.

V?rt nyhetsbrev skickas automatiskt till v?ra kunder och intressenter. Vill du inte ha detta nyhetsbrev fram?ver, klicka h?r f?r att avprenumerera (http://www.anp.se/oa/621716/44405D4074454B5C447043475843).

Nyhetsbrev 14/2010Detta nyhetsbrev ?r skickat till: davinci-linux-open-source at linux.davincidsp.com

(http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se&from=173902333&prefix=dm) (http://www.anp.se/taf/621716/44405D4074454B5C447043475843)  (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_newsletters.asp&from=173902333&prefix=dm)  (http://www.anp.se/newsletter.asp?sqid=621716&sid=44405D4074454B5C447043475843&print=true)

Skattekonsekvenser

Det finns fem huvudsakliga s?tt f?r en aktie?gare att ta ut vinstmedel p?:
L?n
Pension
Utdelning
Kapitalvinst
R?nta
I dagsl?get betalar alltf?r m?nga ?gare till f?mansf?retag h?gre skatt ?n vad skattereglerna ger m?jlighet till. DokuMeras skattemallar hj?lper aktie?garen optimera sina vinstuttag. Genom att k?nna till regelverket f?r uttag av vinstmedel kan du minska det totala skatteuttaget med tiotals procentenheter.


Veckans dokument

Checklista vinstuttag f?mansf?retag >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/checklista_vinstuttag_famansforetag_2644_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Skattekonsekvenser vinstuttag f?mansf?retag 2010>> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/skattekonsekvenser_vinstuttag_famansforetag_2645_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Veckans expert

Stefan Hellstrand
Partner Skatteavdelningen
Grant Thornton (http://www.grantthornton.se/Om-oss/Korta-fakta/)
Telefon: 08- 563 070 48

Grant Thornton ?r Sveriges ledande revisions- och konsultbyr? f?r ?garledda f?retag. V?r expert Stefan Hellstrand har under 19 ?rs tid arbetat med skatte- r?dgivning och hj?lper dig med t.ex. 3:12-reglerna, omstruktureringar, skatte- processer och planerings?tg?rder.


Boken f?r dig som vill lyckas!

Best?ll boken h?r! (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/mind_your_own_business_4246_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)I Mind Your Own Business avsl?jar 50 av landets fr?msta entrepren?rer och ledare hur de har lyckats.

Med kvalitetss?krade framg?ngstips fr?n Sveriges mest framg?ngsrika m?nniskor tar Mind Your Own Business dig och ditt f?retag till n?sta niv?. 

L?s framg?ngstipsen fr?n 50 av landets fr?msta entrepren?rer och ledare: - Sven Hagstr?mer - Bert Karlsson - Kajsa Bergqvist - Mats Gabrielsson - Richard B?ge - Alexandra Charles - Laila Bagge - Kjell A Nordstr?m - Ulf Karlsson - Anders Andersson - Anna Skipper - Ayad Al Saffar och m?nga fler.


(http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/foretagspaketet_1321_dc.html&from=173902333&prefix=dm) (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_atq_ppdviewer.asp&from=173902333&prefix=dm) (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/styckvisa_dokumentmallar_1330_dc.html&from=173902333&prefix=dm)

 (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_contactusmessage.asp&from=173902333&prefix=dm)

F?r en kostnadsfri exklusiv presentation av hur DokuMera kan spara tiotusentals kronor ?t just mitt f?retag.
Givetvis ?r du varmt v?lkommen att ringa oss p? 08-664 04 50.

Inneh?llet i nyhetsbrev ska inte tolkas som ett ?tagande fr?n DokuMeras sida. Informationen s?nds ut i befintligt skick, utan garantier och digitala signaturer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100406/656bafa8/attachment-0001.html>

From swami.iyer at ti.com  Tue Apr  6 02:33:54 2010
From: swami.iyer at ti.com (Subbrathnam, Swaminathan)
Date: Tue, 6 Apr 2010 13:03:54 +0530
Subject: Unable the detect SD card after kernel boot up on DM6467 
In-Reply-To: <1B3CA99331DE5E47BB89385002F8D1EF110A45ADC5@MTW02MSG02.mindtree.com>
References: <1B3CA99331DE5E47BB89385002F8D1EF110A45ADC5@MTW02MSG02.mindtree.com>
Message-ID: <FCCFB4CDC6E5564B9182F639FC35608703049B6A21@dbde02.ent.ti.com>

Priya,
            I believe the SD card reader should have a status indication mechanism that needs to be used for card detection purposes.  If it is a proprietary implementation then you would have to write a driver on Linux to interface with the mechanism or get the related code from the vendor.

Regards
swami

________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Priya Raghavendra
Sent: Thursday, April 01, 2010 2:19 PM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: Unable the detect SD card after kernel boot up on DM6467

Hi,

I am working on a custom board which has TI Davinci DM6467 Processor running Linux 2.6.10 as the host processor to which we have a USB2640 hub controller connected on the USB bus. This hub controller has a built in SD card controller. So basically this hub supports two USB devices and one SD card.
The problem I am facing right now is that if the SD card is connected during kernel boot up, the SD card gets detected and also enumerated. After this I am able to mount the SD card.
But in case I plug in the SD card after kernel boot up, the SD card does not get detected when I insert it.
The USB devices like USB pen drive or mouse connected to the USB ports are detected when they are hot plugged.

So how do I enable hot plugging for the SD card? Basically how do I enumerate the SD card once the kernel is up and the SD card is hot plugged?

Thanks,
bkrpri

________________________________
http://www.mindtree.com/email/disclaimer.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100406/c346ffa7/attachment.html>

From broonie at opensource.wolfsonmicro.com  Tue Apr  6 05:51:33 2010
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Tue, 6 Apr 2010 11:51:33 +0100
Subject: [PATCH 0/4]-V3 TPS6507x MFD driver
In-Reply-To: <1270520639-20516-1-git-send-email-todd.fischer@ridgerun.com>
References: <1270520639-20516-1-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <20100406105132.GC2688@rakim.wolfsonmicro.main>

On Mon, Apr 05, 2010 at 08:23:55PM -0600, Todd Fischer wrote:

> This is the third posting of the TPS6507x driver set.  I have
> resolved the concurrent access issue identified by Mark Brown.
> Instead of using a mutex, I used the i2c_transfer() as done in
> the similar routine in the wm8400-core.c file.

All

Acked-by: Mark Brown <broonie at opensource.wolfsonmicro.com>

When reposting a patch series that has previously been reviewed it's
useful to record any acks and similar that were given for patches that
have been reposted unmodified - this makes life easier for reviewers
since it saves having to re-review previously posted patches.

From lrg at slimlogic.co.uk  Tue Apr  6 06:05:59 2010
From: lrg at slimlogic.co.uk (Liam Girdwood)
Date: Tue, 06 Apr 2010 12:05:59 +0100
Subject: [PATCH 0/4]-V3 TPS6507x MFD driver
In-Reply-To: <20100406105132.GC2688@rakim.wolfsonmicro.main>
References: <1270520639-20516-1-git-send-email-todd.fischer@ridgerun.com>
	<20100406105132.GC2688@rakim.wolfsonmicro.main>
Message-ID: <1270551959.3229.22.camel@odin>

Hi Samuel,

Please feel free to upstream via MFD.

On Tue, 2010-04-06 at 11:51 +0100, Mark Brown wrote:
> On Mon, Apr 05, 2010 at 08:23:55PM -0600, Todd Fischer wrote:
> 
> > This is the third posting of the TPS6507x driver set.  I have
> > resolved the concurrent access issue identified by Mark Brown.
> > Instead of using a mutex, I used the i2c_transfer() as done in
> > the similar routine in the wm8400-core.c file.
> 
> All
> 
> Acked-by: Mark Brown <broonie at opensource.wolfsonmicro.com>

Signed-off-by: Liam Girdwood <lrg at slimlogic.co.uk>

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk


From kieranbingham at gmail.com  Tue Apr  6 07:20:19 2010
From: kieranbingham at gmail.com (Kieran Bingham)
Date: Tue, 06 Apr 2010 13:20:19 +0100
Subject: ARM CCNT Register : Cycle Count Register
Message-ID: <4BBB2703.7030005@gmail.com>

Is it possible to read / access the cycle count register in userspace?  
(I'm on a DM365)

I attempted to read the register with the following code - but the 
application dies with an invalid instruction.

Regards

--
Kieran Bingham


<<< Code Segment cpu-cycles.c >>>

static inline void 
ccnt_start(void)                                                                                                                     

{                                                                                                                                                       

    __asm__ volatile ("mcr p15, 0, %0, c9, c12, 1" :: 
"r"(1<<31));                                                                                      


}

static inline void ccnt_stop(void)
{                                
    __asm__ volatile ("mcr p15, 0, %0, c9, c12, 2" :: "r"(1<<31));

}

static inline unsigned ccnt_read(void)
{                                    
    unsigned cc;                     
    __asm__ volatile ("mrc p15, 0, %0, c9, c13, 0" : "=r"(cc));
    return cc;                                                

}

static inline void ccnt_init(void)
{
    ccnt_stop();
    __asm__ volatile ("mcr p15, 0, %0, c9, c12, 0" :: "r"(5));

}

static inline void enable_user_pmon(void)
{
        __asm__ volatile ("mov     r0, #1");
        __asm__ volatile ("mcr     p15, 0, r0, c9, c14, 0");
}

#include <stdio.h>
#include <stdlib.h>

void main(void)
{
        int start;
        int stop;

        enable_user_pmon();

        ccnt_init();

        start = ccnt_read();

        ccnt_start();

        usleep(1000);

        stop = ccnt_read();

        printf("CCNT Ran for %d cycles\n", stop - start);
}


From sameo at linux.intel.com  Fri Apr  2 07:35:10 2010
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Fri, 2 Apr 2010 15:35:10 +0200
Subject: [PATCH 0/5] TPS6507x MFD driver
In-Reply-To: <1269634292-29686-1-git-send-email-todd.fischer@ridgerun.com>
References: <1269634292-29686-1-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <20100402133508.GG8010@sortiz.org>

Hi Todd,

On Fri, Mar 26, 2010 at 02:11:27PM -0600, Todd Fischer wrote:
> 
> The TPS6507x family of Texas Instruments power management ICs (pmic) 
> are multi-function chips that include voltage regulation and touch 
> screen controller capabilities.  This patch set adds a TPS6507x 
> multi-function device driver and change the TPS6507x regulator driver 
> to use the TPS6507x MFD driver instead of interacting with the chip 
> directly.  The changes are needed before a touch screen driver can be 
> added.
> 
> The patch set applies cleanly to the MFD repository: 
> git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git  
> If the MFD and voltage regulator maintainer would prefer I post 
> patches for a different repository, please let me know.
Mark's review is fairly complete. Please address his concerns, and I'll merge
this patchset.

Cheers,
Samuel.


> The TPS6507x touch screen input driver will be posted to 
> linux-input at vger.kernel.org list.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

From gaspa at yattaweb.it  Thu Apr  1 03:08:31 2010
From: gaspa at yattaweb.it (Andrea Gasparini)
Date: Thu, 1 Apr 2010 11:08:31 +0200
Subject: JVM on DaVinci
In-Reply-To: <201004011054.59116.gasparini@imavis.com>
References: <4BB2F6DD.70406@mindtree.com>
	<q2uc35f83941003311039va95b2064o6afc8dfe7d75978b@mail.gmail.com>
	<201004011054.59116.gasparini@imavis.com>
Message-ID: <201004011108.31365.gaspa@yattaweb.it>

Andrea Gasparini spiffera, alle Thursday 01 April 2010 circa:
> just for curiosity: does a JVM that supports Jazelle extensions exist?
> given that Davinci processors has them, why can't we use it? :P

Found a pointer: 
http://linux.omap.com/pipermail/davinci-linux-open-source/2008-
May/006770.html

bye
-- 
-gaspa-
-----------------------------------------------
-------- https://launchpad.net/~gaspa ---------
----- HomePage: http://gaspa.yattaweb.it ------
-Il lunedi'dell'arrampicatore: www.lunedi.org -

From yaopingtiankong at 163.com  Sat Apr  3 07:10:17 2010
From: yaopingtiankong at 163.com (yaopingtiankong)
Date: Sat, 3 Apr 2010 21:10:17 +0800 (CST)
Subject: uart1 help
Message-ID: <1f42eab.4235.127c3cb11a5.Coremail.yaopingtiankong@163.com>

Dear sir,According to your help in uart1.txt?I recompile the kernel,and I do find /dev/tts/1,command ls -l /dev/tts/1 display right,but when i run the app_485,only display "device opened ",and then wait there? why?
please give me help,thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100403/673d5bc0/attachment.html>

From cyril at ti.com  Tue Apr  6 11:33:14 2010
From: cyril at ti.com (Chemparathy, Cyril)
Date: Tue, 6 Apr 2010 11:33:14 -0500
Subject: [PATCH 13/14] Davinci: simplified debug macros
In-Reply-To: <87pr2dtuzx.fsf@deeprootsystems.com>
References: <1269476345-16111-1-git-send-email-cyril@ti.com>
	<1269476345-16111-2-git-send-email-cyril@ti.com>
	<1269476345-16111-3-git-send-email-cyril@ti.com>
	<1269476345-16111-4-git-send-email-cyril@ti.com>
	<1269476345-16111-5-git-send-email-cyril@ti.com>
	<1269476345-16111-6-git-send-email-cyril@ti.com>
	<1269476345-16111-7-git-send-email-cyril@ti.com>
	<1269476345-16111-8-git-send-email-cyril@ti.com>
	<1269476345-16111-9-git-send-email-cyril@ti.com>
	<1269476345-16111-10-git-send-email-cyril@ti.com>
	<1269476345-16111-11-git-send-email-cyril@ti.com>
	<1269476345-16111-12-git-send-email-cyril@ti.com>
	<1269476345-16111-13-git-send-email-cyril@ti.com>
	<1269476345-16111-14-git-send-email-cyril@ti.com>
	<4BAB408A.7040706@mvista.com>
	<8FFAA0BFC4E5374B8F85F65FE1F2BFA58B937985@dlee02.ent.ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E64F6A88@dbde02.ent.ti.com>
	<87pr2dtuzx.fsf@deeprootsystems.com>
Message-ID: <8FFAA0BFC4E5374B8F85F65FE1F2BFA58BC87B0C@dlee02.ent.ti.com>

Kevin,

> On OMAP, we do this in the uncompress code.  See:
> arch/arm/plat-omap/include/plat/uncompress.h, and in this commit[1] for details.
> 
> Rather than continuing to hack the current hack, I'd like to see
> something similar on DaVinci.  This will also remove one more barrier
> to multiple-SoC support.
> 
> Also, we don't necessarily have to use the UART1 scratchpad register.
> All we need is some temporary, writable register that is available on
> all supported SoCs.  Any suggestions?

AFAICS, the UART1 scratchpad is being used as a temporary storage for communication between the decompressor and the debug-macros.  If so, the only requirement on this should be that this "register" have the same address across all davinci derivatives.

EDMA is the only module that meets this criterion, since it is consistently present @ 0x01c00000 across all socs (so far).

Regards
Cyril.

From cyril at ti.com  Tue Apr  6 11:33:14 2010
From: cyril at ti.com (Chemparathy, Cyril)
Date: Tue, 6 Apr 2010 11:33:14 -0500
Subject: [PATCH v2 14/16] Davinci: tnetv107x gpio implementation
In-Reply-To: <871vetva4h.fsf@deeprootsystems.com>
References: <1269553439-14886-1-git-send-email-cyril@ti.com>
	<1269553439-14886-2-git-send-email-cyril@ti.com>
	<1269553439-14886-3-git-send-email-cyril@ti.com>
	<1269553439-14886-4-git-send-email-cyril@ti.com>
	<1269553439-14886-5-git-send-email-cyril@ti.com>
	<1269553439-14886-6-git-send-email-cyril@ti.com>
	<1269553439-14886-7-git-send-email-cyril@ti.com>
	<1269553439-14886-8-git-send-email-cyril@ti.com>
	<1269553439-14886-9-git-send-email-cyril@ti.com>
	<1269553439-14886-10-git-send-email-cyril@ti.com>
	<1269553439-14886-11-git-send-email-cyril@ti.com>
	<1269553439-14886-12-git-send-email-cyril@ti.com>
	<1269553439-14886-13-git-send-email-cyril@ti.com>
	<1269553439-14886-14-git-send-email-cyril@ti.com>
	<1269553439-14886-15-git-send-email-cyril@ti.com>
	<871vetva4h.fsf@deeprootsystems.com>
Message-ID: <8FFAA0BFC4E5374B8F85F65FE1F2BFA58BC87B0E@dlee02.ent.ti.com>

Hi,

> I'm not crazy about this approach.
> 
> Both the existing functions and the new functions all do basically the same thing:
> - read base + offset
> - set/clear bit(s) based on GPIO#
> - write base + offset
> 
> I think a cleaner solution to this would be to clean the existing GPIO
> layer of direct knowledge of register layout.  Instead, convert the
> gpio_controller struct into struct that holds register offsets from a
> base.  This array of offsets is what needs to be different between
> davinci and tnetv107x.

Agreed. I'll work on this a bit and propose a more generic implementation.

> Also, Re: locking.  You shouldn't need to globally disable interrupts
> here.  What I'm guessing you need is a mutex.

My intent was to keep the gpios non-sleeping (gpio_can_sleep() == 0) so that they remain usable in interrupt handlers.  Since mutexes might_sleep(), we can't really use them to serialize register read-modify-write.  I think that the read-modify-write itself shouldn't take more than a few cycles, and therefore disabling interrupts for the duration should be ok.

Regards
Cyril.

From cyril at ti.com  Tue Apr  6 11:33:14 2010
From: cyril at ti.com (Chemparathy, Cyril)
Date: Tue, 6 Apr 2010 11:33:14 -0500
Subject: [PATCH v2 09/16] Davinci: tnetv107x SOC specific header
In-Reply-To: <87k4sltuxv.fsf@deeprootsystems.com>
References: <1269553439-14886-1-git-send-email-cyril@ti.com>
	<1269553439-14886-2-git-send-email-cyril@ti.com>
	<1269553439-14886-3-git-send-email-cyril@ti.com>
	<1269553439-14886-4-git-send-email-cyril@ti.com>
	<1269553439-14886-5-git-send-email-cyril@ti.com>
	<1269553439-14886-6-git-send-email-cyril@ti.com>
	<1269553439-14886-7-git-send-email-cyril@ti.com>
	<1269553439-14886-8-git-send-email-cyril@ti.com>
	<1269553439-14886-9-git-send-email-cyril@ti.com>
	<1269553439-14886-10-git-send-email-cyril@ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E66990F8@dbde02.ent.ti.com>
	<87k4sltuxv.fsf@deeprootsystems.com>
Message-ID: <8FFAA0BFC4E5374B8F85F65FE1F2BFA58BC87B0D@dlee02.ent.ti.com>

Hi,

> >> Added on-chip peripheral base addresses so tnetv107x SOC header.
> >
> > There should be no need to define the full
> > list of base addresses in one place because
> > the are typically needed only at only one place
> > (near the resource definition).
> >
> > Just add the define where needed and use it.
> 
> Agreed.
> 
> These should only ever be used when defining a platform_device or in
> the low-level core code.

Ok. Please comment on the following approach:

1. Move arch/arm/mach-davinci/include/mach/<soc>.h to arch/arm/mach-davinci/:
By doing so, these low-level definitions are restricted to mach-davinci code, and will not be accessible via "#include <mach/xxx>" from elsewhere in the kernel code.

2. Consolidate all soc-specific stuff into this <soc.h>:
This includes edma definitions, irq numbers, module base addresses, mux pins, psc indices, and whatever else comes in down the road.


Regards
Cyril.

From khilman at deeprootsystems.com  Tue Apr  6 12:13:25 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Tue, 06 Apr 2010 10:13:25 -0700
Subject: [PATCH 13/14] Davinci: simplified debug macros
In-Reply-To: <8FFAA0BFC4E5374B8F85F65FE1F2BFA58BC87B0C@dlee02.ent.ti.com>
	(Cyril Chemparathy's message of "Tue\,
	6 Apr 2010 11\:33\:14 -0500")
References: <1269476345-16111-1-git-send-email-cyril@ti.com>
	<1269476345-16111-2-git-send-email-cyril@ti.com>
	<1269476345-16111-3-git-send-email-cyril@ti.com>
	<1269476345-16111-4-git-send-email-cyril@ti.com>
	<1269476345-16111-5-git-send-email-cyril@ti.com>
	<1269476345-16111-6-git-send-email-cyril@ti.com>
	<1269476345-16111-7-git-send-email-cyril@ti.com>
	<1269476345-16111-8-git-send-email-cyril@ti.com>
	<1269476345-16111-9-git-send-email-cyril@ti.com>
	<1269476345-16111-10-git-send-email-cyril@ti.com>
	<1269476345-16111-11-git-send-email-cyril@ti.com>
	<1269476345-16111-12-git-send-email-cyril@ti.com>
	<1269476345-16111-13-git-send-email-cyril@ti.com>
	<1269476345-16111-14-git-send-email-cyril@ti.com>
	<4BAB408A.7040706@mvista.com>
	<8FFAA0BFC4E5374B8F85F65FE1F2BFA58B937985@dlee02.ent.ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E64F6A88@dbde02.ent.ti.com>
	<87pr2dtuzx.fsf@deeprootsystems.com>
	<8FFAA0BFC4E5374B8F85F65FE1F2BFA58BC87B0C@dlee02.ent.ti.com>
Message-ID: <874ojoqzbe.fsf@deeprootsystems.com>

"Chemparathy, Cyril" <cyril at ti.com> writes:

> Kevin,
>
>> On OMAP, we do this in the uncompress code.  See:
>> arch/arm/plat-omap/include/plat/uncompress.h, and in this commit[1] for details.
>> 
>> Rather than continuing to hack the current hack, I'd like to see
>> something similar on DaVinci.  This will also remove one more barrier
>> to multiple-SoC support.
>> 
>> Also, we don't necessarily have to use the UART1 scratchpad register.
>> All we need is some temporary, writable register that is available on
>> all supported SoCs.  Any suggestions?
>
> AFAICS, the UART1 scratchpad is being used as a temporary storage
> for communication between the decompressor and the debug-macros.  

Correct.

> If so, the only requirement on this should be that this "register"
> have the same address across all davinci derivatives.
>
> EDMA is the only module that meets this criterion, since it is
> consistently present @ 0x01c00000 across all socs (so far).

That seems like a reasonable option since we can assume that EDMA is
disabled during early uncompress/boot.

Maybe the channel src or dest regs?

Kevin



From cyril at ti.com  Tue Apr  6 12:21:45 2010
From: cyril at ti.com (Chemparathy, Cyril)
Date: Tue, 6 Apr 2010 12:21:45 -0500
Subject: [PATCH 13/14] Davinci: simplified debug macros
In-Reply-To: <874ojoqzbe.fsf@deeprootsystems.com>
References: <1269476345-16111-1-git-send-email-cyril@ti.com>
	<1269476345-16111-2-git-send-email-cyril@ti.com>
	<1269476345-16111-3-git-send-email-cyril@ti.com>
	<1269476345-16111-4-git-send-email-cyril@ti.com>
	<1269476345-16111-5-git-send-email-cyril@ti.com>
	<1269476345-16111-6-git-send-email-cyril@ti.com>
	<1269476345-16111-7-git-send-email-cyril@ti.com>
	<1269476345-16111-8-git-send-email-cyril@ti.com>
	<1269476345-16111-9-git-send-email-cyril@ti.com>
	<1269476345-16111-10-git-send-email-cyril@ti.com>
	<1269476345-16111-11-git-send-email-cyril@ti.com>
	<1269476345-16111-12-git-send-email-cyril@ti.com>
	<1269476345-16111-13-git-send-email-cyril@ti.com>
	<1269476345-16111-14-git-send-email-cyril@ti.com>
	<4BAB408A.7040706@mvista.com>
	<8FFAA0BFC4E5374B8F85F65FE1F2BFA58B937985@dlee02.ent.ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E64F6A88@dbde02.ent.ti.com>
	<87pr2dtuzx.fsf@deeprootsystems.com>
	<8FFAA0BFC4E5374B8F85F65FE1F2BFA58BC87B0C@dlee02.ent.ti.com>
	<874ojoqzbe.fsf@deeprootsystems.com>
Message-ID: <8FFAA0BFC4E5374B8F85F65FE1F2BFA58BC1DF35@dlee02.ent.ti.com>

Hi Kevin,

> > If so, the only requirement on this should be that this "register"
> > have the same address across all davinci derivatives.
> >
> > EDMA is the only module that meets this criterion, since it is
> > consistently present @ 0x01c00000 across all socs (so far).
> 
> That seems like a reasonable option since we can assume that EDMA is
> disabled during early uncompress/boot.
> 
> Maybe the channel src or dest regs?

The only problem is that EDMA CC will need to be brought out of reset either in the uncompress init code or in the bootloader.

Wouldn't it be cleaner to use a few words of memory between the boot params and zreladdr?  For example, 16 bytes @0x80007ff0 can be used to pass in uart phys, virt, and shift.  This should work cleanly across socs, and is less dependent on MMR layout should some future architecture change things.

Regards
Cyril.

From khilman at deeprootsystems.com  Tue Apr  6 12:55:09 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Tue, 06 Apr 2010 10:55:09 -0700
Subject: [PATCH v2 14/16] Davinci: tnetv107x gpio implementation
In-Reply-To: <8FFAA0BFC4E5374B8F85F65FE1F2BFA58BC87B0E@dlee02.ent.ti.com>
	(Cyril Chemparathy's message of "Tue\,
	6 Apr 2010 11\:33\:14 -0500")
References: <1269553439-14886-1-git-send-email-cyril@ti.com>
	<1269553439-14886-2-git-send-email-cyril@ti.com>
	<1269553439-14886-3-git-send-email-cyril@ti.com>
	<1269553439-14886-4-git-send-email-cyril@ti.com>
	<1269553439-14886-5-git-send-email-cyril@ti.com>
	<1269553439-14886-6-git-send-email-cyril@ti.com>
	<1269553439-14886-7-git-send-email-cyril@ti.com>
	<1269553439-14886-8-git-send-email-cyril@ti.com>
	<1269553439-14886-9-git-send-email-cyril@ti.com>
	<1269553439-14886-10-git-send-email-cyril@ti.com>
	<1269553439-14886-11-git-send-email-cyril@ti.com>
	<1269553439-14886-12-git-send-email-cyril@ti.com>
	<1269553439-14886-13-git-send-email-cyril@ti.com>
	<1269553439-14886-14-git-send-email-cyril@ti.com>
	<1269553439-14886-15-git-send-email-cyril@ti.com>
	<871vetva4h.fsf@deeprootsystems.com>
	<8FFAA0BFC4E5374B8F85F65FE1F2BFA58BC87B0E@dlee02.ent.ti.com>
Message-ID: <87r5mspite.fsf@deeprootsystems.com>

"Chemparathy, Cyril" <cyril at ti.com> writes:

> Hi,
>
>> I'm not crazy about this approach.
>> 
>> Both the existing functions and the new functions all do basically the same thing:
>> - read base + offset
>> - set/clear bit(s) based on GPIO#
>> - write base + offset
>> 
>> I think a cleaner solution to this would be to clean the existing GPIO
>> layer of direct knowledge of register layout.  Instead, convert the
>> gpio_controller struct into struct that holds register offsets from a
>> base.  This array of offsets is what needs to be different between
>> davinci and tnetv107x.
>
> Agreed. I'll work on this a bit and propose a more generic implementation.
>
>> Also, Re: locking.  You shouldn't need to globally disable interrupts
>> here.  What I'm guessing you need is a mutex.
>
> My intent was to keep the gpios non-sleeping (gpio_can_sleep() == 0)
> so that they remain usable in interrupt handlers.

Then you should be using spin_lock_irq* instead of a global IRQ
disable.

Locks should always be as fine grained as possible.

Even better would be to make the spinlock bank specific so only
concurrent accesses to the same bank would need to be serialized.

Kevin

> Since mutexes might_sleep(), we can't really use them to serialize
> register read-modify-write.  I think that the read-modify-write
> itself shouldn't take more than a few cycles, and therefore
> disabling interrupts for the duration should be ok.



From khilman at deeprootsystems.com  Tue Apr  6 13:28:43 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Tue, 06 Apr 2010 11:28:43 -0700
Subject: [PATCH 13/14] Davinci: simplified debug macros
In-Reply-To: <8FFAA0BFC4E5374B8F85F65FE1F2BFA58BC1DF35@dlee02.ent.ti.com>
	(Cyril Chemparathy's message of "Tue\,
	6 Apr 2010 12\:21\:45 -0500")
References: <1269476345-16111-1-git-send-email-cyril@ti.com>
	<1269476345-16111-2-git-send-email-cyril@ti.com>
	<1269476345-16111-3-git-send-email-cyril@ti.com>
	<1269476345-16111-4-git-send-email-cyril@ti.com>
	<1269476345-16111-5-git-send-email-cyril@ti.com>
	<1269476345-16111-6-git-send-email-cyril@ti.com>
	<1269476345-16111-7-git-send-email-cyril@ti.com>
	<1269476345-16111-8-git-send-email-cyril@ti.com>
	<1269476345-16111-9-git-send-email-cyril@ti.com>
	<1269476345-16111-10-git-send-email-cyril@ti.com>
	<1269476345-16111-11-git-send-email-cyril@ti.com>
	<1269476345-16111-12-git-send-email-cyril@ti.com>
	<1269476345-16111-13-git-send-email-cyril@ti.com>
	<1269476345-16111-14-git-send-email-cyril@ti.com>
	<4BAB408A.7040706@mvista.com>
	<8FFAA0BFC4E5374B8F85F65FE1F2BFA58B937985@dlee02.ent.ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E64F6A88@dbde02.ent.ti.com>
	<87pr2dtuzx.fsf@deeprootsystems.com>
	<8FFAA0BFC4E5374B8F85F65FE1F2BFA58BC87B0C@dlee02.ent.ti.com>
	<874ojoqzbe.fsf@deeprootsystems.com>
	<8FFAA0BFC4E5374B8F85F65FE1F2BFA58BC1DF35@dlee02.ent.ti.com>
Message-ID: <87fx38ph9g.fsf@deeprootsystems.com>

"Chemparathy, Cyril" <cyril at ti.com> writes:

> Hi Kevin,
>
>> > If so, the only requirement on this should be that this "register"
>> > have the same address across all davinci derivatives.
>> >
>> > EDMA is the only module that meets this criterion, since it is
>> > consistently present @ 0x01c00000 across all socs (so far).
>> 
>> That seems like a reasonable option since we can assume that EDMA is
>> disabled during early uncompress/boot.
>> 
>> Maybe the channel src or dest regs?
>
> The only problem is that EDMA CC will need to be brought out of
> reset either in the uncompress init code or in the bootloader.

Good point, that would be a bit clumsy to do in an SoC independent way
in the uncompress code.

> Wouldn't it be cleaner to use a few words of memory between the boot
> params and zreladdr?  For example, 16 bytes @0x80007ff0 can be used
> to pass in uart phys, virt, and shift.  This should work cleanly
> across socs, and is less dependent on MMR layout should some future
> architecture change things.

That's worth a try.

Just make sure you copy the values out after first read since that
first page will be unmapped early in boot.  The OMAP debug-macros.S
does this as an example.

Kevin


From liuyue18301 at 163.com  Tue Apr  6 20:55:52 2010
From: liuyue18301 at 163.com (liuyue18301)
Date: Wed, 7 Apr 2010 09:55:52 +0800 (CST)
Subject: how Codec_engine call the dsplink
Message-ID: <1405096.1a8c.127d5fb0f66.Coremail.liuyue18301@163.com>

hello everybody:
      well in the video_copy demos of the codec_engine i think i call the api of dsplink to implement the communication between arm and dsp. but i can't find out that in the code 
      who can help me it confused me so long time. what is the relationship codec_engine and dsplink and the relationship of calling 
      thank you very much.

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100407/22b52f85/attachment.html>

From sameo at linux.intel.com  Wed Apr  7 03:43:06 2010
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Wed, 7 Apr 2010 10:43:06 +0200
Subject: [PATCH 0/4]-V3 TPS6507x MFD driver
In-Reply-To: <1270520639-20516-1-git-send-email-todd.fischer@ridgerun.com>
References: <1270520639-20516-1-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <20100407084305.GA2962@sortiz.org>

Hi Todd,

On Mon, Apr 05, 2010 at 08:23:55PM -0600, Todd Fischer wrote:
> 
> This is the third posting of the TPS6507x driver set.  I have
> resolved the concurrent access issue identified by Mark Brown.
> Instead of using a mutex, I used the i2c_transfer() as done in
> the similar routine in the wm8400-core.c file.
> 
> The TPS6507x family of Texas Instruments power management ICs (pmic) are
> multi-function chips that include voltage regulation and touch screen
> controller capabilities.  This patch set adds a TPS6507x multi-function
> device driver and change the TPS6507x regulator driver to use the
> TPS6507x MFD driver instead of interacting with the chip directly.  The
> changes are needed before a touch screen driver can be added.
> 
> The patch set applies cleanly to the MFD repository:
> git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git  If the
> MFD and voltage regulator maintainer would prefer I post patches for a
> different repository, please let me know.
All 4 patches applied to my for-next branch.
Some nit picking advices for your future patches:
- Include the Signed-off-by and Acked-by you collect along the review cycles.
- Have shorter patch subject, they typically are less than 80 chars.
- Describe the changes when moving from patchset vN to patchset vN+1. Also we
prefer "[PATCH vN]" to "[PATCH]-vN", it makes our life easier when applying
your patches.

Thanks a lot for your work.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

From sameo at linux.intel.com  Wed Apr  7 03:46:45 2010
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Wed, 7 Apr 2010 10:46:45 +0200
Subject: [PATCH 0/2]-V2 Add touch screen input driver for TPS6507x
	family of multi-function chips.
In-Reply-To: <1270511593-4785-1-git-send-email-todd.fischer@ridgerun.com>
References: <1270511593-4785-1-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <20100407084644.GB2962@sortiz.org>

Hi Todd, hi Kevin,

On Mon, Apr 05, 2010 at 05:53:11PM -0600, Todd Fischer wrote:
> 
> This is the second posting of the TPS6507x touch screen driver. I have
> incorporated Kevin Hilman's request to split the board specific changes
> into a separate patch.
> 
> The TPS6507x family of Texas Instruments power management ICs (pmic)
> are multi-function chips that include voltage regulation and touch
> screen controller capabilities.  This patch adds a touch screen
> input driver for the TPS6507x pmic.  There was an existing regulator
> driver.  Before the touch screen driver can be added, a multi-function
> device (MFD) driver was needed and the regulator driver modified to
> use the MDF driver.  Patches for these changes have been posted and
> reviewed.  The TPS6507x touch screen driver applies cleanly to the
> MFD GIT repo after the above referenced patches are applied.  If I
> should use a different approach, please let me know.
> 
> The TPS6507x pmic supports interrupting on touch detection.
> Unfortuntaly, the hardware used for driver development didn't have
> the interrupt signal properly connected.  When TPS6507x pmic interrupt
> capable hardware is in hand, another patch will be posted adding
> interrupt support.
I've applied patch #1 of this patchset. Kevin, would you please take patch #2?

Cheers,
Samuel.


-- 
Intel Open Source Technology Centre
http://oss.intel.com/

From lamiaposta71 at gmail.com  Wed Apr  7 04:38:52 2010
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Wed, 7 Apr 2010 11:38:52 +0200
Subject: isif - debugging on dm365
In-Reply-To: <r2nade1bdc1004012338yb12139b8k697d9831df81de33@mail.gmail.com>
References: <ade1bdc1003300750r111aeda4iaeab54f770a86331@mail.gmail.com>
	<A69FA2915331DC488A831521EAE36FE4016A8B3D35@dlee06.ent.ti.com>
	<ade1bdc1003300915q6a557cc8n9ac9684c439cad42@mail.gmail.com>
	<A69FA2915331DC488A831521EAE36FE4016A8B3DD2@dlee06.ent.ti.com>
	<j2qade1bdc1003310748t5b57539cs4c868911e7d464e5@mail.gmail.com>
	<A69FA2915331DC488A831521EAE36FE4016A92CC50@dlee06.ent.ti.com>
	<r2nade1bdc1004012338yb12139b8k697d9831df81de33@mail.gmail.com>
Message-ID: <v2vade1bdc1004070238if288b7abx7b762d3d9d79ab91@mail.gmail.com>

I was adding isif_cfg.y_c_swap variable, but it need a modification inside
arch/arm/mach-davinci/dm365.c that I think is not the right direction.
I mean, the "isif" platform data is not board related, but it is cpu
related.
I'd like to use  isif_set_hw_if_params, but I'm not sure that it is really
used.
I have to get a device (actually not available) to check if this function is
called.
work in progress ...

2010/4/2 Raffaele Recalcati <lamiaposta71 at gmail.com>

> I ll send a patch tuesday. Today i am on holyday
>
> 2010/4/1, Karicheri, Muralidharan <m-karicheri2 at ti.com>:
> > Raffaele,
> >
> >  [MK] 0 means the interrupt happens right at VD pulse. 1 means after one
> > line. You might want to check the signals received from ADV to input of
> VPFE
> > to see if adv is doing what it is configured to do.
> >
> > My colleague has found how to make the vpfe_isr interrupt working with
> > adv7180.
> > He has made this change in isif.c inside isif_config_ycbcr:
> >
> > -               ccdcfg = ccdcfg | ISIF_DATA_PACK8 | ISIF_YCINSWP_YCBCR;
> > +               ccdcfg = ccdcfg | ISIF_DATA_PACK8 ;
> > [MK] What you are doing is essentially swapping the Y and C input lines.
> > Probably on your board, you are connecting the input differently than on
> the
> > DM365 evm. Please confirm if this is the only change that got it working.
> > He verified that tvp514x was really working using 10bit port.
> > If he disabled pinmux on Y0 and Y1 interrupts aren't generated.
> > But in isif_config_ycbcr function the kernel enters in
> >                 case VPFE_BT656:
> > because it lacks a call for setting isif_cfg.if_type.
> > I think the problem is that the YCINSWP setting on your board. In 8 bit
> > mode, this decides whether input signals are connected to Y input or C
> > input. In TVP5146 on DM365, it is connected to C input, where as on your
> > board it is connected to Y input. So we need to add this as a
> configurable
> > variable in the board setup file, read it and set in isif.c. Please send
> a
> > patch to the list. For example define a variable y_c_swap and set it to 0
> in
> > your board. On DM365 evm board file you can set it to 1 so that it works
> > fine for tvp5146 and adv7180. In isif.c you can read this variable and
> > update the YCINSWP bit in CCDCFG. Are you planning to send a patch for
> this?
> > Murali
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> www.opensurf.it
>



-- 
www.opensurf.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100407/c0c41cbc/attachment.html>

From sales at sgfpcb.com  Tue Apr  6 19:43:36 2010
From: sales at sgfpcb.com (sales at sgfpcb.com)
Date: Wed, 7 Apr 2010 08:43:36 +0800
Subject: =?UTF-8?Q?Onward_into_2010._Best_wishes_from_?=
	=?UTF-8?Q?ChinaPCBOne?=
Message-ID: <00B9D9D565914E7F9027154CDD68D697@Aafuzqo>

I'm going to deviate from my typical "marketing tip" style and speak candidly. It's possible this email won't necessarily apply to you, but still hope you can take a few minutes to understand about our products and services, maybe able to help your business.

My company is a professional PCB Manufacturer in ShenZhen of China, specialize in Quick Turn PCB prototypes,Small and Medium-volume PCB Product. We excel at Aluminum base PCB(AL PCB),Rigid-flex PCB,High Density pcb(HDI PCB),Impedance Control PCB,High Temperature PCB(High TG PCBs),Heavy Copper PCB,and other Advanced Circuits.

Now, if you think of our products and services are not for you, just click your mouse to delete it. Thank you for your valuable time!

Thank you very much to continue to learn more about our products and services!

Let me introduce to you more about our products:

Layers -------------------------- 2-48 Layers

Material ------------------------ FR4,High Tg,Teflon,Rogers,Arlon,Taconic,Nelco,Al-base 

Board thickness ----------------- 0.2 --? 8.0mm

Copper Thickness ---------------- 0.5 OZ --- 19 OZ

Mini line width/space ----------- 3mil/3mil

Mini finished Hole Size --------- 6mil(0.15mm)

Surface treatment --------------- HASL, Lead Free HASL,Immersion Gold,Flash Gold,Immersion Tin/Silver,Gold finger,OSP,Carbon Ink,Peelabe mask

Delivery time ------------------- 24H for prototype,4-8days for mass production

Products Application ------------ Communication,Military Avionics,Power Supplier,Industrial Controller,Automobile,LCD,LCD and so on
 
For Full details please visit our website: http://www.chinapcbone.com 

Thank you for you valuable time!

With best Regards,

Michelle Law
____________________________________________________________

Sales Manager:Michelle Law

ChinaPCBOne--Professional PCB Manufacturer--Shenzhen China

Internet: http://www.ChinaPCBOne.com

E-Mail: sales at ChinaPCBOne.com

Phone: +86 (755) 27370200

Fax: +86 (755) 27395968

Mobile:+86-13612807580

Skype call:michelle.law.

MSN:sales at chinapcbone.com
____________________________________________________________

The information contained in this e-mail may be confidential information, and may also be the subject of professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the e-mail.

From shuishoujin at yahoo.com.cn  Wed Apr  7 09:16:39 2010
From: shuishoujin at yahoo.com.cn (zhijin wang)
Date: Wed, 7 Apr 2010 22:16:39 +0800 (CST)
Subject: can LSP - 02.10.00.14 be use for DM6467
Message-ID: <335216.51195.qm@web15101.mail.cnb.yahoo.com>

hi guys,
?
i'm working on DM6467, using mvtools 5.0 and dvsdk 2.00.00.02.
?
there is some issue for the kernel, from ti website ,the kernel should be lsp-02.00.00.140.? but this verson kernel seems that there is some issue on network communication. so i tried
LSP-02.10.00.14, it works on Dm6467, but from the release note, it support DM365, not including DM6467. so i wonder if it is ok working with dvsdk 2.00.00.02 for DM6467.
?
anyone knows? many thanks.
?
Forrest.


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100407/6ad4c6ad/attachment.html>

From schen at mvista.com  Wed Apr  7 09:33:23 2010
From: schen at mvista.com (Steve Chen)
Date: Wed, 7 Apr 2010 09:33:23 -0500
Subject: can LSP - 02.10.00.14 be use for DM6467
In-Reply-To: <335216.51195.qm@web15101.mail.cnb.yahoo.com>
References: <335216.51195.qm@web15101.mail.cnb.yahoo.com>
Message-ID: <n2zfca5cfb21004070733w831041c4g6a070771364b210d@mail.gmail.com>

On Wed, Apr 7, 2010 at 9:16 AM, zhijin wang <shuishoujin at yahoo.com.cn>wrote:

> hi guys,
>
> i'm working on DM6467, using mvtools 5.0 and dvsdk 2.00.00.02.
>
> there is some issue for the kernel, from ti website ,the kernel should be
> lsp-02.00.00.140.  but this verson kernel seems that there is some issue on
> network communication. so i tried
> LSP-02.10.00.14, it works on Dm6467, but from the release note, it support
> DM365, not including DM6467. so i wonder if it is ok working with dvsdk
> 2.00.00.02 for DM6467.
>
> anyone knows? many thanks.
>
> Forrest.
>
>
The best thing is to avoid using the DM365 for DM6467.  The reason is that
later DM6467 patches may not apply cleanly. Just wondering, what type of
network communication issue did you see?

Regards,

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100407/2664aea7/attachment.html>

From cyril at ti.com  Wed Apr  7 09:35:30 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed,  7 Apr 2010 10:35:30 -0400
Subject: [PATCH] Davinci: generalized debug macros
Message-ID: <1270650930-21329-1-git-send-email-cyril@ti.com>

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 macros through a small chunk of memory placed just
below the page tables (@0x80003ff8).

This code was tested on tnetv107x (with addition board and arch specific code
not included here), under both pre-mmu and post-mmu scenarios.  Sandeep also
tested this (earlyprintk, post-mmu) on the dm365 evm.

Also, the OMAP2 debug-macro implementation incorrectly loads omap_uart_phys
using its virtual address in the mmu-disabled case.  I suspect that if those
macros ever get invoked via __error_p/__error_a (arch/arm/kernel/head.S), bad
things are likely to happen.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/include/mach/debug-macro.S |   51 +++++++++++---
 arch/arm/mach-davinci/include/mach/serial.h      |   13 ++++
 arch/arm/mach-davinci/include/mach/uncompress.h  |   80 ++++++++++++++++------
 3 files changed, 112 insertions(+), 32 deletions(-)

diff --git a/arch/arm/mach-davinci/include/mach/debug-macro.S b/arch/arm/mach-davinci/include/mach/debug-macro.S
index 3cd93a8..ac0fa02 100644
--- a/arch/arm/mach-davinci/include/mach/debug-macro.S
+++ b/arch/arm/mach-davinci/include/mach/debug-macro.S
@@ -17,22 +17,51 @@
  */
 
 #include <linux/serial_reg.h>
+
+#include <asm/memory.h>
+
+#include <mach/serial.h>
+
 #define UART_SHIFT	2
 
+		.pushsection .data
+davinci_uart_phys:	.word	0
+davinci_uart_virt:	.word	0
+		.popsection
+
 		.macro addruart, rx, tmp
+
+		/* Use davinci_uart_phys/virt if already configured */
+10:		mrc	p15, 0, \rx, c1, c0
+		tst	\rx, #1			@ MMU enabled?
+		ldreq	\rx, =__virt_to_phys(davinci_uart_phys)
+		ldrne	\rx, =davinci_uart_virt
+		ldr	\rx, [\rx]
+		cmp	\rx, #0			@ is port configured?
+		bne	99f			@ already configured
+
+		/* Copy uart phys address from decompressor uart info */
 		mrc	p15, 0, \rx, c1, c0
 		tst	\rx, #1			@ MMU enabled?
-		moveq	\rx, #0x01000000	@ physical base address
-		movne	\rx, #0xfe000000	@ virtual base
-#if defined(CONFIG_ARCH_DAVINCI_DA8XX) && defined(CONFIG_ARCH_DAVINCI_DMx)
-#error Cannot enable DaVinci and DA8XX platforms concurrently
-#elif defined(CONFIG_MACH_DAVINCI_DA830_EVM) || \
-	defined(CONFIG_MACH_DAVINCI_DA850_EVM)
-		orr	\rx, \rx, #0x00d00000	@ physical base address
-		orr	\rx, \rx, #0x0000d000	@ of UART 2
-#else
-		orr	\rx, \rx, #0x00c20000   @ UART 0
-#endif
+		ldreq	\tmp, =__virt_to_phys(davinci_uart_phys)
+		ldrne	\tmp, =davinci_uart_phys
+		ldreq	\rx, =DAVINCI_UART_INFO
+		ldrne	\rx, =__phys_to_virt(DAVINCI_UART_INFO)
+		ldr	\rx, [\rx, #0]
+		str	\rx, [\tmp]
+
+		/* Copy uart virt address from decompressor uart info */
+		mrc	p15, 0, \rx, c1, c0
+		tst	\rx, #1			@ MMU enabled?
+		ldreq	\tmp, =__virt_to_phys(davinci_uart_virt)
+		ldrne	\tmp, =davinci_uart_virt
+		ldreq	\rx, =DAVINCI_UART_INFO
+		ldrne	\rx, =__phys_to_virt(DAVINCI_UART_INFO)
+		ldr	\rx, [\rx, #4]
+		str	\rx, [\tmp]
+
+		b	10b
+99:
 		.endm
 
 		.macro	senduart,rd,rx
diff --git a/arch/arm/mach-davinci/include/mach/serial.h b/arch/arm/mach-davinci/include/mach/serial.h
index a584697..8829dde 100644
--- a/arch/arm/mach-davinci/include/mach/serial.h
+++ b/arch/arm/mach-davinci/include/mach/serial.h
@@ -11,8 +11,19 @@
 #ifndef __ASM_ARCH_SERIAL_H
 #define __ASM_ARCH_SERIAL_H
 
+#include <asm/memory.h>
+
 #include <mach/hardware.h>
 
+/*
+ * Stolen area that contains debug uart physical and virtual addresses.  These
+ * addresses are filled in by the uncompress.h code, and are used by the debug
+ * macros in debug-macro.S.
+ *
+ * This area sits just below the page tables (see arch/arm/kernel/head.S).
+ */
+#define DAVINCI_UART_INFO	(PHYS_OFFSET + 0x3ff8)
+
 #define DAVINCI_MAX_NR_UARTS	3
 #define DAVINCI_UART0_BASE	(IO_PHYS + 0x20000)
 #define DAVINCI_UART1_BASE	(IO_PHYS + 0x20400)
@@ -27,11 +38,13 @@
 #define UART_DM646X_SCR			0x10
 #define UART_DM646X_SCR_TX_WATERMARK	0x08
 
+#ifndef __ASSEMBLY__
 struct davinci_uart_config {
 	/* Bit field of UARTs present; bit 0 --> UART1 */
 	unsigned int enabled_uarts;
 };
 
 extern int davinci_serial_init(struct davinci_uart_config *);
+#endif
 
 #endif /* __ASM_ARCH_SERIAL_H */
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
index 33796b4..20c23a3 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -1,8 +1,17 @@
 /*
  * Serial port stubs for kernel decompress status messages
  *
- *  Author:     Anant Gole
- * (C) Copyright (C) 2006, Texas Instruments, Inc
+ * Initially based on:
+ * arch/arm/plat-omap/include/mach/uncompress.h
+ *
+ * Original copyrights follow.
+ *
+ * Copyright (C) 2000 RidgeRun, Inc.
+ * Author: Greg Lonnon <glonnon at ridgerun.com>
+ *
+ * Rewritten by:
+ * Author: <source at mvista.com>
+ * 2004 (c) MontaVista Software, Inc.
  *
  * This file is licensed under the terms of the GNU General Public License
  * version 2. This program is licensed "as is" without any warranty of any
@@ -11,30 +20,17 @@
 
 #include <linux/types.h>
 #include <linux/serial_reg.h>
-#include <mach/serial.h>
 
 #include <asm/mach-types.h>
 
-extern unsigned int __machine_arch_type;
+#include <mach/serial.h>
 
 static u32 *uart;
-
-static u32 *get_uart_base(void)
-{
-	if (__machine_arch_type == MACH_TYPE_DAVINCI_DA830_EVM ||
-		__machine_arch_type == MACH_TYPE_DAVINCI_DA850_EVM)
-		return (u32 *)DA8XX_UART2_BASE;
-	else
-		return (u32 *)DAVINCI_UART0_BASE;
-}
+static u32 *uart_info = (u32 *)(DAVINCI_UART_INFO);
 
 /* PORT_16C550A, in polled non-fifo mode */
-
 static void putc(char c)
 {
-	if (!uart)
-		uart = get_uart_base();
-
 	while (!(uart[UART_LSR] & UART_LSR_THRE))
 		barrier();
 	uart[UART_TX] = c;
@@ -42,12 +38,54 @@ static void putc(char c)
 
 static inline void flush(void)
 {
-	if (!uart)
-		uart = get_uart_base();
-
 	while (!(uart[UART_LSR] & UART_LSR_THRE))
 		barrier();
 }
 
-#define arch_decomp_setup()
+static inline void set_uart_info(u32 phys, void * __iomem virt)
+{
+	uart = (u32 *)phys;
+	uart_info[0] = phys;
+	uart_info[1] = (u32)virt;
+}
+
+#define _DEBUG_LL_ENTRY(machine, phys, virt)			\
+	if (machine_is_##machine()) {				\
+		set_uart_info(phys, virt);			\
+		break;						\
+	}
+
+#define DEBUG_LL_DAVINCI(machine, port)				\
+	_DEBUG_LL_ENTRY(machine, DAVINCI_UART##port##_BASE,	\
+			IO_ADDRESS(DAVINCI_UART##port##_BASE))
+
+#define DEBUG_LL_DA8XX(machine, port)				\
+	_DEBUG_LL_ENTRY(machine, DA8XX_UART##port##_BASE,	\
+			IO_ADDRESS(DA8XX_UART##port##_BASE))
+
+static inline void __arch_decomp_setup(unsigned long arch_id)
+{
+	/*
+	 * Initialize the port based on the machine ID from the bootloader.
+	 * Note that we're using macros here instead of switch statement
+	 * as machine_is functions are optimized out for the boards that
+	 * are not selected.
+	 */
+	do {
+		/* Davinci boards */
+		DEBUG_LL_DAVINCI(davinci_evm,		0);
+		DEBUG_LL_DAVINCI(sffsdr,		0);
+		DEBUG_LL_DAVINCI(neuros_osd2,		0);
+		DEBUG_LL_DAVINCI(davinci_dm355_evm,	0);
+		DEBUG_LL_DAVINCI(dm355_leopard,		0);
+		DEBUG_LL_DAVINCI(davinci_dm6467_evm,	0);
+		DEBUG_LL_DAVINCI(davinci_dm365_evm,	0);
+
+		/* DA8xx boards */
+		DEBUG_LL_DA8XX(davinci_da830_evm,	2);
+		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
+	} while (0);
+}
+
+#define arch_decomp_setup()	__arch_decomp_setup(arch_id)
 #define arch_decomp_wdog()
-- 
1.6.3.3


From jp.francois at cynove.com  Wed Apr  7 09:40:55 2010
From: jp.francois at cynove.com (=?ISO-8859-1?Q?Jean-Philippe_Fran=E7ois?=)
Date: Wed, 07 Apr 2010 16:40:55 +0200
Subject: isif - debugging on dm365
In-Reply-To: <v2vade1bdc1004070238if288b7abx7b762d3d9d79ab91@mail.gmail.com>
References: <ade1bdc1003300750r111aeda4iaeab54f770a86331@mail.gmail.com>	<A69FA2915331DC488A831521EAE36FE4016A8B3D35@dlee06.ent.ti.com>	<ade1bdc1003300915q6a557cc8n9ac9684c439cad42@mail.gmail.com>	<A69FA2915331DC488A831521EAE36FE4016A8B3DD2@dlee06.ent.ti.com>	<j2qade1bdc1003310748t5b57539cs4c868911e7d464e5@mail.gmail.com>	<A69FA2915331DC488A831521EAE36FE4016A92CC50@dlee06.ent.ti.com>	<r2nade1bdc1004012338yb12139b8k697d9831df81de33@mail.gmail.com>
	<v2vade1bdc1004070238if288b7abx7b762d3d9d79ab91@mail.gmail.com>
Message-ID: <4BBC9977.8080902@cynove.com>

Raffaele Recalcati a ?crit :
> I was adding isif_cfg.y_c_swap variable, but it need a modification 
> inside arch/arm/mach-davinci/dm365.c that I think is not the right 
> direction.
> I mean, the "isif" platform data is not board related, but it is cpu 
> related.

sensor or decoder connection to the isif is definitely board related.

the ccdc_if_params field of the vpfe_subdev_info struct is used by
the ccdc code in the ccdc_set_hw_if_params function.

Here is a patch that implement an ycswap field.
It is set in the board file, and used in the ccdc driver.
It does only include the dm365 ccdc, but it can be extended.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: yc_swap.patch
Type: text/x-diff
Size: 3132 bytes
Desc: not available
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100407/83942f29/attachment.bin>

From khilman at deeprootsystems.com  Wed Apr  7 11:10:06 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Wed, 07 Apr 2010 09:10:06 -0700
Subject: [PATCH 0/2]-V2 Add touch screen input driver for TPS6507x family
	of multi-function chips.
In-Reply-To: <20100407084644.GB2962@sortiz.org> (Samuel Ortiz's message of
	"Wed\, 7 Apr 2010 10\:46\:45 +0200")
References: <1270511593-4785-1-git-send-email-todd.fischer@ridgerun.com>
	<20100407084644.GB2962@sortiz.org>
Message-ID: <874ojnfdlt.fsf@deeprootsystems.com>

Samuel Ortiz <sameo at linux.intel.com> writes:

> Hi Todd, hi Kevin,
>
> On Mon, Apr 05, 2010 at 05:53:11PM -0600, Todd Fischer wrote:
>> 
>> This is the second posting of the TPS6507x touch screen driver. I have
>> incorporated Kevin Hilman's request to split the board specific changes
>> into a separate patch.
>> 
>> The TPS6507x family of Texas Instruments power management ICs (pmic)
>> are multi-function chips that include voltage regulation and touch
>> screen controller capabilities.  This patch adds a touch screen
>> input driver for the TPS6507x pmic.  There was an existing regulator
>> driver.  Before the touch screen driver can be added, a multi-function
>> device (MFD) driver was needed and the regulator driver modified to
>> use the MDF driver.  Patches for these changes have been posted and
>> reviewed.  The TPS6507x touch screen driver applies cleanly to the
>> MFD GIT repo after the above referenced patches are applied.  If I
>> should use a different approach, please let me know.
>> 
>> The TPS6507x pmic supports interrupting on touch detection.
>> Unfortuntaly, the hardware used for driver development didn't have
>> the interrupt signal properly connected.  When TPS6507x pmic interrupt
>> capable hardware is in hand, another patch will be posted adding
>> interrupt support.
>
> I've applied patch #1 of this patchset. Kevin, would you please take patch #2?

Thanks.  Yes, patch #2 will be queued for linux-next and 2.6.35.

Kevin


From khilman at deeprootsystems.com  Wed Apr  7 11:24:24 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Wed, 07 Apr 2010 09:24:24 -0700
Subject: [PATCH 0/2]-V2 Add touch screen input driver for TPS6507x family
	of multi-function chips.
In-Reply-To: <874ojnfdlt.fsf@deeprootsystems.com> (Kevin Hilman's message of
	"Wed\, 07 Apr 2010 09\:10\:06 -0700")
References: <1270511593-4785-1-git-send-email-todd.fischer@ridgerun.com>
	<20100407084644.GB2962@sortiz.org>
	<874ojnfdlt.fsf@deeprootsystems.com>
Message-ID: <87ljczdydj.fsf@deeprootsystems.com>

Kevin Hilman <khilman at deeprootsystems.com> writes:

> Samuel Ortiz <sameo at linux.intel.com> writes:
>
>> Hi Todd, hi Kevin,
>>
>> On Mon, Apr 05, 2010 at 05:53:11PM -0600, Todd Fischer wrote:
>>> 
>>> This is the second posting of the TPS6507x touch screen driver. I have
>>> incorporated Kevin Hilman's request to split the board specific changes
>>> into a separate patch.

[...]

>>
>> I've applied patch #1 of this patchset. Kevin, would you please take patch #2?
>
> Thanks.  Yes, patch #2 will be queued for linux-next and 2.6.35.

After trying to apply this, I ran into some snags

The other series '[PATCH 0/4]-V3 TPS6507x MFD driver' also had some
board file changes mixed in that I did not catch, and patch #2 of this
series depends on those.

So either we split those out and merge them via my tree, or you can
just merge patch #2 of this series via your tree as well.

I'm OK with either option, but just merging patch #2 of this series
via your tree seems like the least amount of hassle at this time.

If you merge via your tree, please add:

Signed-off-by: Kevin Hilman <khilman at deeprootsystems.com>

Kevin

From jlarsen45 at hotmail.com  Wed Apr  7 12:01:49 2010
From: jlarsen45 at hotmail.com (Jeremy Larsen)
Date: Wed, 7 Apr 2010 17:01:49 +0000
Subject: DM365 H.264 Encoder size change problem
Message-ID: <COL121-W32793F160F6E16CE8AD159A3170@phx.gbl>


I am having a problem anytime I change the height and width setting of the H.264 encoder on the DM365.  I have tried sending XDM_RESET control message to the encoder to try and reset it before I change to the new size.  I have even deleted and recreated the encoder with VIDENC1_delete and VIDENC1_create calls before starting the new size and the produced bitstream is still not correct.  The syntax is correct but the decoded image is not.  I can independently encode either size setting (after a board reboot) correctly, but when I try to switch size the problem occurs.  I am using dvsdk_3_10_00_03.  Can anyone offer any advice?

 

Jeremy
 		 	   		  
_________________________________________________________________
The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail.
http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100407/f601da9a/attachment.html>

From khilman at deeprootsystems.com  Wed Apr  7 12:02:01 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Wed, 07 Apr 2010 10:02:01 -0700
Subject: [PATCH v2 09/16] Davinci: tnetv107x SOC specific header
In-Reply-To: <8FFAA0BFC4E5374B8F85F65FE1F2BFA58BC87B0D@dlee02.ent.ti.com>
	(Cyril Chemparathy's message of "Tue\,
	6 Apr 2010 11\:33\:14 -0500")
References: <1269553439-14886-1-git-send-email-cyril@ti.com>
	<1269553439-14886-2-git-send-email-cyril@ti.com>
	<1269553439-14886-3-git-send-email-cyril@ti.com>
	<1269553439-14886-4-git-send-email-cyril@ti.com>
	<1269553439-14886-5-git-send-email-cyril@ti.com>
	<1269553439-14886-6-git-send-email-cyril@ti.com>
	<1269553439-14886-7-git-send-email-cyril@ti.com>
	<1269553439-14886-8-git-send-email-cyril@ti.com>
	<1269553439-14886-9-git-send-email-cyril@ti.com>
	<1269553439-14886-10-git-send-email-cyril@ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E66990F8@dbde02.ent.ti.com>
	<87k4sltuxv.fsf@deeprootsystems.com>
	<8FFAA0BFC4E5374B8F85F65FE1F2BFA58BC87B0D@dlee02.ent.ti.com>
Message-ID: <87d3ybdwmu.fsf@deeprootsystems.com>

"Chemparathy, Cyril" <cyril at ti.com> writes:

> Hi,
>
>> >> Added on-chip peripheral base addresses so tnetv107x SOC header.
>> >
>> > There should be no need to define the full
>> > list of base addresses in one place because
>> > the are typically needed only at only one place
>> > (near the resource definition).
>> >
>> > Just add the define where needed and use it.
>> 
>> Agreed.
>> 
>> These should only ever be used when defining a platform_device or in
>> the low-level core code.
>
> Ok. Please comment on the following approach:
>
> 1. Move arch/arm/mach-davinci/include/mach/<soc>.h to arch/arm/mach-davinci/:
> By doing so, these low-level definitions are restricted to mach-davinci code, and will not be accessible via "#include <mach/xxx>" from elsewhere in the kernel code.

No, the header location is fine.  The point is that most of the base
addresses there do not need to be there.  

If you compare how its done for the other platforms, only the minimal
set of base addresses are defined there.  The others are
defined directly in the places where the platform_devices are defined.

Kevin


From rtivy at ti.com  Wed Apr  7 12:38:36 2010
From: rtivy at ti.com (Tivy, Robert)
Date: Wed, 7 Apr 2010 12:38:36 -0500
Subject: how Codec_engine call the dsplink
In-Reply-To: <1405096.1a8c.127d5fb0f66.Coremail.liuyue18301@163.com>
References: <1405096.1a8c.127d5fb0f66.Coremail.liuyue18301@163.com>
Message-ID: <6B8224E84039B140AA662F0BB03616430129D86F91@dlee04.ent.ti.com>



________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of liuyue18301
Sent: Tuesday, April 06, 2010 6:56 PM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: how Codec_engine call the dsplink

hello everybody:
      well in the video_copy demos of the codec_engine i think i call the api of dsplink to implement the communication between arm and dsp. but i can't find out that in the code
      who can help me it confused me so long time. what is the relationship codec_engine and dsplink and the relationship of calling
      thank you very much.




DSPLink is used internally by Codec Engine.  You do not call any DSPLink APIs, which is the whole point of Codec Engine, to insulate the user from the details of the implementation.  You just call Codec Engine APIs, as the video_copy demo does, or any of the Codec Engine example apps.

DSPLink is used by Codec Engine when there is a remote server configured into the system, so you need to configure a remote server but you don't need to configure the use of DSPLink, since Codec Engine does that for you.  If you're just doing a "local" codec then you won't specify a server and DSPLink is not needed in this case.

- Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100407/2c949f2c/attachment.html>

From cring at ti.com  Wed Apr  7 13:41:54 2010
From: cring at ti.com (Ring, Chris)
Date: Wed, 7 Apr 2010 13:41:54 -0500
Subject: how Codec_engine call the dsplink
In-Reply-To: <6B8224E84039B140AA662F0BB03616430129D86F91@dlee04.ent.ti.com>
References: <1405096.1a8c.127d5fb0f66.Coremail.liuyue18301@163.com>
	<6B8224E84039B140AA662F0BB03616430129D86F91@dlee04.ent.ti.com>
Message-ID: <92CDD168D1E81F4F9D3839DC45903FC676A4E99F@dlee03.ent.ti.com>

Rob's right, the Link details are intentionally hidden under Codec Engine.  But it's often useful to know what's going on underneath.

There are more details about CE and DSP Link interaction during DSP start/stop in section 2's "Opening an Engine" and "Closing an Engine" here:
http://tiexpressdsp.com/index.php/Codec_Engine_Application_Developers_Guide

-------------------------

I couldn't find an article that describes the internal MSGQ usage under the VISA APIs, but you can get a good feel for what's going on under by studying the trace output when setting CE_DEBUG=3 (http://tiexpressdsp.com/index.php/CE_DEBUG).

Here's a [very trimmed] excerpt of trace from a single VIDENC_process() call with CE_DEBUG=3 set.  The ARM-side is in red, the DSP side is in green, and I've underlined the lines where Codec Engine internally calls MSGQ_alloc()/put()/get()/free() on the ARM side, as well as MSGQ_get()/put() on the DSP side:

@1,454,227us: [+0 T:0x4001f000 S:0x03874944] ti.sdo.ce.video.VIDENC - VIDENC_process> Enter (handle=0x44c90, inBufs=0x3874a74, outBufs=0x3874a68, inArgs=0x443c8, outArgs=0x443e0)
@1,454,428us: [+5 T:0x4001f000 S:0x038748dc] CV - VISA_allocMsg> Allocating message for messageId=0x00026700
@1,458,639us: [+0 T:0x4001f000 S:0x038748e4] CV - VISA_call(visa=0x44c90, msg=0x41169c80): messageId=0x00026700, command=0x0
@1,458,807us: [+0 T:0x4001f000 S:0x038748ac] OC - Comm_put> Enter(queue=0x2, msg=0x41169c80)
@1,459,039us: [+0 T:0x4001f000 S:0x038748ac] OC - Comm_put> return (0)
@1,459,221us: [+0 T:0x4001f000 S:0x038748a4] OC - Comm_get> Enter(queue=0x10001, msg=0x387495c, timeout=-1)
@1,507,703us: [+0 T:0x4001f000 S:0x038748a4] OC - Comm_get> MSGQ_get() status=0x8000, return (0)
[DSP] @0,511,501tk: [+5 T:0x8b9fb21c S:0x8b9fd1e4] CN - NODE> 0x8fa82398(xavsc_ateme#0) call(algHandle=0x8fa82450, msg=0x8fe06c80); messageId=0x00026700
[DSP] @0,512,933tk: [+0 T:0x8b9fb21c S:0x8b9fd14c] ti.sdo.ce.video.VIDENC - VIDENC_process> Enter (handle=0x8fa82450, inBufs=0x8b9fd1ec, outBufs=0x8b9fd1f8, inArgs=0x8fe06db8, outArgs=0x8fe06dc8)
[DSP] @0,513,035tk: [+5 T:0x8b9fb21c S:0x8b9fd12c] CV - VISA_enter(visa=0x8fa82450): algHandle = 0x8fa82480
[DSP] @0,513,095tk: [+0 T:0x8b9fb21c S:0x8b9fd10c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(alg=0x8fa82480)
[DSP] @0,513,157tk: [+0 T:0x8b9fb21c S:0x8b9fd10c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Exit
[DSP] @0,622,199tk: [+5 T:0x8b9fb21c S:0x8b9fd12c] CV - VISA_exit(visa=0x8fa82450): algHandle = 0x8fa82480
[DSP] @0,622,282tk: [+0 T:0x8b9fb21c S:0x8b9fd10c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter(alg=0x8fa82480)
[DSP] @0,622,371tk: [+0 T:0x8b9fb21c S:0x8b9fd10c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Exit
[DSP] @0,622,424tk: [+0 T:0x8b9fb21c S:0x8b9fd14c] ti.sdo.ce.video.VIDENC - VIDENC_process> Exit (handle=0x8fa82450, retVal=0x0)
[DSP] @0,623,888tk: [+5 T:0x8b9fb21c S:0x8b9fd1e4] CN - NODE> returned from call(algHandle=0x8fa82450, msg=0x8fe06c80); messageId=0x00026700
@1,518,966us: [+0 T:0x4001f000 S:0x038748e4] CV - VISA_call Completed: messageId=0x00026700, command=0x0, return(status=0)
@1,522,687us: [+5 T:0x4001f000 S:0x038748bc] CV - VISA_freeMsg(0x44c90, 0x41169c80): Freeing message with messageId=0x00026700
@1,522,855us: [+0 T:0x4001f000 S:0x03874944] ti.sdo.ce.video.VIDENC - VIDENC_process> Exit (handle=0x44c90, retVal=0x0)

Chris

________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Tivy, Robert
Sent: Wednesday, April 07, 2010 10:39 AM
To: liuyue18301; davinci-linux-open-source at linux.davincidsp.com
Subject: RE: how Codec_engine call the dsplink



________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of liuyue18301
Sent: Tuesday, April 06, 2010 6:56 PM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: how Codec_engine call the dsplink

hello everybody:
      well in the video_copy demos of the codec_engine i think i call the api of dsplink to implement the communication between arm and dsp. but i can't find out that in the code
      who can help me it confused me so long time. what is the relationship codec_engine and dsplink and the relationship of calling
      thank you very much.




DSPLink is used internally by Codec Engine.  You do not call any DSPLink APIs, which is the whole point of Codec Engine, to insulate the user from the details of the implementation.  You just call Codec Engine APIs, as the video_copy demo does, or any of the Codec Engine example apps.

DSPLink is used by Codec Engine when there is a remote server configured into the system, so you need to configure a remote server but you don't need to configure the use of DSPLink, since Codec Engine does that for you.  If you're just doing a "local" codec then you won't specify a server and DSPLink is not needed in this case.

- Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100407/c1625b3b/attachment-0001.html>

From martin at ti.com  Wed Apr  7 16:05:13 2010
From: martin at ti.com (Ambrose, Martin)
Date: Wed, 7 Apr 2010 16:05:13 -0500
Subject: [PATCH v3 1/1] DA8XX/OMAP-L1XX: FB: Implement double buffering
In-Reply-To: <8739z9ttmt.fsf@deeprootsystems.com>
References: <1270504278-15088-1-git-send-email-martin@ti.com>
	<1270504278-15088-2-git-send-email-martin@ti.com>
	<A24693684029E5489D1D202277BE89445316FACC@dlee02.ent.ti.com>
	<8739z9ttmt.fsf@deeprootsystems.com>
Message-ID: <A24693684029E5489D1D202277BE8944549254AE@dlee02.ent.ti.com>

On Mon, Apr 05, 2010 at 17:35:38, Kevin Hilman wrote:

> "Ambrose, Martin" <martin at ti.com> writes:
> 
> > This work includes the following:
> >  . Implement handler for FBIO_WAITFORVSYNC ioctl.
> >
> >  . Allocate the data and palette buffers separately.
> >    A consequence of this is that the palette and data loading is now
> >    done in different phases. And that the LCD must be disabled
> >    temporarily after the palette is loaded but this will only happen
> >    once after init and each time the palette is changed. I think this
> >    is OK.
> >
> >  . Allocate two (ping and pong) framebuffers from memory.
> >
> >  . Add pan_display handler which toggles the LCDC DMA registers between
> >    the ping and pong buffers.
> >
> > Signed-off-by: Martin Ambrose <martin at ti.com>
> 
> Your mailer (probably outlook) is converting all tabs to spaces
> resulting in a patch that wont apply.
> 
> I recommend using git-format-patch + git-send-email directly to your
> SMTP server to avoid outlook mangling.

Sorry about this but I'm floundering. The problem I'm having is that my git-send-email
is being rejected by several of the recipients on this thread (notably linux-fbdev).
The reason is that their servers perform sender verification which is fair and understandable.
See my first attempt at sending the patch which made it to davinci-linux-open-source but
not fbdev. My attempt at a solution was to first send it to my corporate account, which doesn't
verify the address, then forward from Outlook. But this is non-functional as you pointed out.

I am not an email expert by any means and don't know how to test different options without
spamming the mailing lists with test emails. The root cause, I think, is that even though
I am using git-send-email with the .gitconfig pointing to our corporate mail server the resultant
header (or maybe ID) is not passing the verification step on the receiving end. 

I have tried from both within cygwin and linux running under VMWare. Next step will be
to try and send from a real linux machine on the corporate network but I'm doubting this
will resolve the problem. And/or see if I can script Outlook to not convert whitespace --
this I can test without annoying others.

Regards, 
Martin

From khilman at deeprootsystems.com  Wed Apr  7 16:16:37 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Wed, 07 Apr 2010 14:16:37 -0700
Subject: [PATCH v3 1/1] DA8XX/OMAP-L1XX: FB: Implement double buffering
In-Reply-To: <A24693684029E5489D1D202277BE8944549254AE@dlee02.ent.ti.com>
	(Martin Ambrose's message of "Wed\, 7 Apr 2010 16\:05\:13 -0500")
References: <1270504278-15088-1-git-send-email-martin@ti.com>
	<1270504278-15088-2-git-send-email-martin@ti.com>
	<A24693684029E5489D1D202277BE89445316FACC@dlee02.ent.ti.com>
	<8739z9ttmt.fsf@deeprootsystems.com>
	<A24693684029E5489D1D202277BE8944549254AE@dlee02.ent.ti.com>
Message-ID: <876343arpm.fsf@deeprootsystems.com>

"Ambrose, Martin" <martin at ti.com> writes:

> On Mon, Apr 05, 2010 at 17:35:38, Kevin Hilman wrote:
>
>> "Ambrose, Martin" <martin at ti.com> writes:
>> 
>> > This work includes the following:
>> >  . Implement handler for FBIO_WAITFORVSYNC ioctl.
>> >
>> >  . Allocate the data and palette buffers separately.
>> >    A consequence of this is that the palette and data loading is now
>> >    done in different phases. And that the LCD must be disabled
>> >    temporarily after the palette is loaded but this will only happen
>> >    once after init and each time the palette is changed. I think this
>> >    is OK.
>> >
>> >  . Allocate two (ping and pong) framebuffers from memory.
>> >
>> >  . Add pan_display handler which toggles the LCDC DMA registers between
>> >    the ping and pong buffers.
>> >
>> > Signed-off-by: Martin Ambrose <martin at ti.com>
>> 
>> Your mailer (probably outlook) is converting all tabs to spaces
>> resulting in a patch that wont apply.
>> 
>> I recommend using git-format-patch + git-send-email directly to your
>> SMTP server to avoid outlook mangling.
>
> Sorry about this but I'm floundering. The problem I'm having is that my git-send-email
> is being rejected by several of the recipients on this thread (notably linux-fbdev).
> The reason is that their servers perform sender verification which is fair and understandable.
> See my first attempt at sending the patch which made it to davinci-linux-open-source but
> not fbdev. My attempt at a solution was to first send it to my corporate account, which doesn't
> verify the address, then forward from Outlook. But this is non-functional as you pointed out.
>
> I am not an email expert by any means and don't know how to test different options without
> spamming the mailing lists with test emails. The root cause, I think, is that even though
> I am using git-send-email with the .gitconfig pointing to our corporate mail server the resultant
> header (or maybe ID) is not passing the verification step on the receiving end. 
>
> I have tried from both within cygwin and linux running under VMWare. Next step will be
> to try and send from a real linux machine on the corporate network but I'm doubting this
> will resolve the problem. And/or see if I can script Outlook to not convert whitespace --
> this I can test without annoying others.

Not sure what is going wrong, but I know that there are many folks
inside TI who are using git-send-email successfully.  Maybe ask
around.

Alternatively, you could use a gmail account as well.  See this
GitTips page where it describes how to send using gmail:

   https://git.wiki.kernel.org/index.php/GitTips#Mail

Kevin


From mans at mansr.com  Wed Apr  7 18:36:09 2010
From: mans at mansr.com (=?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=)
Date: Thu, 08 Apr 2010 00:36:09 +0100
Subject: ARM CCNT Register : Cycle Count Register
References: <4BBB2703.7030005@gmail.com>
Message-ID: <yw1x1vequ97a.fsf@unicorn.mansr.com>

Kieran Bingham <kieranbingham at gmail.com>
writes:

> Is it possible to read / access the cycle count register in userspace?

The counters are accessible to userspace only if enabled in the
kernel.  Here's a patch to do that:
http://git.mansr.com/?p=linux-omap;a=commitdiff;h=5170038

-- 
M?ns Rullg?rd
mans at mansr.com


From marcelkatz at gmail.com  Thu Apr  8 03:30:49 2010
From: marcelkatz at gmail.com (Marcel Katz)
Date: Thu, 8 Apr 2010 10:30:49 +0200
Subject: 6446 VPBE slave mode
Message-ID: <y2z2147c2791004080130xb56b3b4bq3089d638fdd62e05@mail.gmail.com>

Hi

There is somebody using the 6446 VPBE digital output in slave mode?

I am trying to do it without success.

Regards
Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100408/a1fc1f8f/attachment.html>

From kieranbingham at gmail.com  Thu Apr  8 04:08:50 2010
From: kieranbingham at gmail.com (Kieran Bingham)
Date: Thu, 08 Apr 2010 10:08:50 +0100
Subject: ARM CCNT Register : Cycle Count Register
In-Reply-To: <yw1x1vequ97a.fsf@unicorn.mansr.com>
References: <4BBB2703.7030005@gmail.com> <yw1x1vequ97a.fsf@unicorn.mansr.com>
Message-ID: <4BBD9D22.8020003@gmail.com>

M?ns Rullg?rd wrote:
> Kieran Bingham <kieranbingham at gmail.com>
> writes:
>
>   
>> Is it possible to read / access the cycle count register in userspace?
>>     
>
> The counters are accessible to userspace only if enabled in the
> kernel.  Here's a patch to do that:
> http://git.mansr.com/?p=linux-omap;a=commitdiff;h=5170038
>
>   
Aha - the missing link ...

That patch states it depends on CPU_V7 will this work on ARM9? - I'm on 
a DM365 processor

I added

<http://git.mansr.com/?p=linux-omap;a=blob;f=arch/arm/mm/proc-v7.S;h=fec926a18ad2975571755d74aa2b5a57e486843b;hb=5170038#l275>        
mov     r0, #1
<http://git.mansr.com/?p=linux-omap;a=blob;f=arch/arm/mm/proc-v7.S;h=fec926a18ad2975571755d74aa2b5a57e486843b;hb=5170038#l276>        
mcr     p15, 0, r0, c9, c14, 0

to the __arm926_setup: within arch/arm/mm/proc-arm926.S but the kernel 
fails to boot past init. I presume it causes an illegal instruction and 
spins...

--
Regards
Kieran

From premkumar.j at ti.com  Thu Apr  8 04:17:19 2010
From: premkumar.j at ti.com (JayaKumar, PremKumar)
Date: Thu, 8 Apr 2010 14:47:19 +0530
Subject: DM365 H.264 Encoder size change problem
In-Reply-To: <COL121-W32793F160F6E16CE8AD159A3170@phx.gbl>
References: <COL121-W32793F160F6E16CE8AD159A3170@phx.gbl>
Message-ID: <EAF47CD23C76F840A9E7FCE10091EFAB02C4D0F57C@dbde02.ent.ti.com>

Jeremy,

This scenario works with the DVTB application present in the DVSDK 3.10 installation. We could sequentially encode two YUV 420SP streams of size 1920x1088 and 1280x720 using two codec instances.
However we have kept the maxWidth to 1920 and maxHeight to 1088 for both instances.

Can you try closing the Codec Engine and open it once again before creating the second instance? You might get some clue.

If possible you can try running the DVTB as well.

Regards,
Prem

________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Jeremy Larsen
Sent: Wednesday, April 07, 2010 10:32 PM
To: davinci-linux-open-source
Subject: DM365 H.264 Encoder size change problem

I am having a problem anytime I change the height and width setting of the H.264 encoder on the DM365.  I have tried sending XDM_RESET control message to the encoder to try and reset it before I change to the new size.  I have even deleted and recreated the encoder with VIDENC1_delete and VIDENC1_create calls before starting the new size and the produced bitstream is still not correct.  The syntax is correct but the decoded image is not.  I can independently encode either size setting (after a board reboot) correctly, but when I try to switch size the problem occurs.  I am using dvsdk_3_10_00_03.  Can anyone offer any advice?

Jeremy
________________________________
The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. Get busy.<http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100408/2733255f/attachment-0001.html>

From sameo at linux.intel.com  Thu Apr  8 04:32:49 2010
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Thu, 8 Apr 2010 11:32:49 +0200
Subject: [PATCH 0/2]-V2 Add touch screen input driver for TPS6507x
	family of multi-function chips.
In-Reply-To: <87ljczdydj.fsf@deeprootsystems.com>
References: <1270511593-4785-1-git-send-email-todd.fischer@ridgerun.com>
	<20100407084644.GB2962@sortiz.org>
	<874ojnfdlt.fsf@deeprootsystems.com>
	<87ljczdydj.fsf@deeprootsystems.com>
Message-ID: <20100408093248.GA3075@sortiz.org>

Hi Kevin,

On Wed, Apr 07, 2010 at 09:24:24AM -0700, Kevin Hilman wrote:
> Kevin Hilman <khilman at deeprootsystems.com> writes:
> 
> > Samuel Ortiz <sameo at linux.intel.com> writes:
> >
> >> Hi Todd, hi Kevin,
> >>
> >> On Mon, Apr 05, 2010 at 05:53:11PM -0600, Todd Fischer wrote:
> >>> 
> >>> This is the second posting of the TPS6507x touch screen driver. I have
> >>> incorporated Kevin Hilman's request to split the board specific changes
> >>> into a separate patch.
> 
> [...]
> 
> >>
> >> I've applied patch #1 of this patchset. Kevin, would you please take patch #2?
> >
> > Thanks.  Yes, patch #2 will be queued for linux-next and 2.6.35.
> 
> After trying to apply this, I ran into some snags
> 
> The other series '[PATCH 0/4]-V3 TPS6507x MFD driver' also had some
> board file changes mixed in that I did not catch, and patch #2 of this
> series depends on those.
> 
> So either we split those out and merge them via my tree, or you can
> just merge patch #2 of this series via your tree as well.
> 
> I'm OK with either option, but just merging patch #2 of this series
> via your tree seems like the least amount of hassle at this time.
Definitely. I'm taking this patch, thanks a lot.

Cheers,
Samuel.


> If you merge via your tree, please add:
> 
> Signed-off-by: Kevin Hilman <khilman at deeprootsystems.com>
> 
> Kevin

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

From scerveau at awox.com  Thu Apr  8 05:08:39 2010
From: scerveau at awox.com (Stephane Cerveau)
Date: Thu, 8 Apr 2010 12:08:39 +0200
Subject: WIreless and Mass storage USB problem.
References: <006201cad188$2c8a9ec0$859fdc40$@joshi@einfochips.com> 
Message-ID: <46423D9081D5254CAFCEFF0CBC2CC9BA021C027F@jakarta.awox.com>

Hi all,

 

I still have issues using the USB DMA mode driver with a mass storage and a WIFI USB dongle in the mean while. Indeed I have untimely disconnected MS device when I try to download a file with WIFI key and store it on the mass storage device.

Sometimes it's due to TX_CSR_ERROR and sometimes due to RXCSR_STALL... Does anyone experience this problem ? Can anybody help me with this problem ? I'm working on it for several weeks and I do not understand the root cause of this consequence.

This problem is very easy to reproduce but it's untimely.......It seems to be a race condition but I don't understand where it happens ...

 

Best regards.  

 

 

St?phane Cerveau.

 

 

From: Stephane Cerveau 
Sent: jeudi 1 avril 2010 14:30
To: 'Pratik Joshi'; davinci-linux-open-source at linux.davincidsp.com
Subject: RE: Query -USB hub with multiple block devices connected

 

Hi all,

 

I experienced the same bug and I succeed to workaround the bug by adding a delay into musb_ep_program but this is working only with the RT73 USB Wireless device.

 

I experienced bug with other Wireless device.

Joshi, you can I think the verbose level in the musb driver. May be it can help you to diagnose the bug with more accuracy... 

Any comment or help will be welcome. 

 

Stephane

From: Pratik Joshi [mailto:pratik.joshi at einfochips.com] 
Sent: jeudi 1 avril 2010 12:43
To: davinci-linux-open-source at linux.davincidsp.com
Subject: RE: Query -USB hub with multiple block devices connected

 

Hi All,

 

I am getting following error while I run Wireless USB device and a mass storage device together. This error is displayed on console continuously and I have to reboot the DVEVM.

++++++++++++++++++++++++++++++++++

SCSI error : <0 0 0 0> return code = 0x70000

 

end_request: I/O error, dev sda, sector 4404236

-------------------------------------------------------------

Regards,

Pratik Joshi

Embedded Engineer

eInfochips Ltd, Ahmedabad, India

+91-079-26563705 - ext - 303

www.einfochips.com

 

From: Pratik Joshi [mailto:pratik.joshi at einfochips.com] 
Sent: Tuesday, March 30, 2010 6:26 PM
To: 'davinci-linux-open-source at linux.davincidsp.com'
Subject: Query -USB hub with multiple block devices connected

 

Hi All,

 

We are seeing following problem:

 

Setup:

We have connected a USB hub to DVEVM. We have connected two bulk devices mass storage and USB wireless device. We are continuously receiving data on USB wireless device (using iperf utility) and at the same time continuously writing to mass storage device. We do fsync () after writing data using write command to ensure data is actually written to mass storage device.

 

Problem statement:

In above setup we see SCSI errors and I/O errors. Also we have observed "usb 1-1.1: usb_sg_cancel, unlink --> 0" message sometimes. What is the significance of this message? Has anyone tested USB driver in such a driver? 

 

Regards,

Pratik Joshi

Embedded Engineer

eInfochips Ltd, Ahmedabad, India

+91-079-26563705 - ext - 303

www.einfochips.com


-- 

  _____  

Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. 

  _____  




__________ Information from ESET NOD32 Antivirus, version of virus signature database 4991 (20100401) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4991 (20100401) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


__________ Information from ESET NOD32 Antivirus, version of virus signature database 5003 (20100406) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


__________ Information from ESET NOD32 Antivirus, version of virus signature database 5009 (20100408) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100408/81d22184/attachment.html>

From cyril at ti.com  Thu Apr  8 09:06:29 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 08 Apr 2010 10:06:29 -0400
Subject: [Fwd: RE: [PATCH v2 15/16] Davinci: initial tnetv107x support]
Message-ID: <1270735589.19066.34.camel@gtrgwdeb>

Hi Sekhar,

Thanks for the detailed review.

[...]
> It will be nice to point out which of the existing platforms
> were tested to be working after this series was applied 
> (with some indication of the type of testing done).

Will do in the next rev.

[...]
> > +struct platform_device davinci_wdt_device = {
> > +	.name		= "watchdog",
> > +	.id		= -1,
> > +	.num_resources	= ARRAY_SIZE(wdt_resources),
> > +	.resource	= wdt_resources,
> > +};
> 
> IMO, a better way to overcome the 'no watchdog timer'
> limitation would be to make the watchdog reset code
> not use the wdt platform data directly, but instead
> 'search' for watchdog device using bus_for_each_dev()
> iterator on platform bus.
> 
> In your case, the watchdog device wouldn't be found
> and the reset function should exist gracefully.

Agreed.  In addition to the platform_device search, I will also need to
put in an override-able reset hook for tnetv107x watchdog reset to plug
in into.

[...]
> > +void __init tnetv107x_serial_init(struct plat_serial8250_port* ports)
> > +{
> > +	int i;
> > +	char name[16];
> > +	struct clk *uart_clk;
> > +
> > +	for (i = 0; ports[i].flags; i++) {
> > +		sprintf(name, "uart%d", i);
> > +		uart_clk = clk_get(NULL, name);
> > +		if (IS_ERR(uart_clk))
> > +			printk(KERN_ERR "%s:%d: failed to get UART%d clock\n",
> > +					__func__, __LINE__, i);
> > +		else {
> > +			clk_enable(uart_clk);
> > +			ports[i].uartclk = clk_get_rate(uart_clk);
> > +		}
> > +	}
> > +}
> 
> An explanation on why davinci_serial_init() is no good for
> this SoC would be good.

Will include comments.  There are a couple of problems that prevent
davinci_serial_init() from being reused as is.

First, that function uses IO_ADDRESS() - a scheme that will not work (as
it stands) on tnetv107x.

Second, davinci_serial_init() goes around modifying PWREMU - a register
that doesnt exist on tnetv107x.

[...]
> No need of the 'clk_' prefix for all the LPSC
> clock names.

Ok.  Will modify.

[...]
> > + * TNETV107X platforms do not use the static mappings from Davinci
> > + * IO_PHYS/IO_VIRT. This SOC's interesting MMRs are at different addresses,
> > + * and changing IO_PHYS would break away from existing Davinci SOCs.
> 
> So why not redefine the IO_PHYS for this SoC? I believe you are not able
> to build a single image for TNETV107x and DaVinci anyway.
> 
> That should also avoid the EDMA issue you highlight below.

Although tnetv107x and davinci currently cannot be built into a single
image, I wanted to keep that breakage to a minimum.  At some point in
the future, if the underlying ARM arch code supports combined v6+v5, we
wouldn't need to go around fixing things all over the place.

[...]
> > +static void __iomem *fixed_ioremap(unsigned long p, size_t size)
> > +{
> > +	struct map_desc *map = tnetv107x_soc_info.io_desc;
> > +	int i;
> > +
> > +	for (i = 0; i < tnetv107x_soc_info.io_desc_num; i++) {
> > +		unsigned long iophys = __pfn_to_phys(map[i].pfn);
> > +		unsigned long iosize = map[i].length;
> > +
> > +		if (p >= iophys && (p + size) <= (iophys + iosize))
> > +			return IOMEM(map[i].virtual + p - iophys);
> > +	}
> > +
> > +	panic("attempt to map invalid physical range %lx-%lx\n",
> > +			p, p + size);
> > +}
> 
> This sounds like something that should be useful on
> all DaVinci SoCs. Why not make davinci_ioremap to do
> exactly this?

Good point. davinci_ioremap() can do this based on the iotable info it
pulls out of davinci_soc_info.  The only hitch here is that da8xx seems
to ioremap() before davinci_common_init().  Let me propose a patch for
this (separately) and take it from there.

[...]
> > +static unsigned long clk_sspll_recalc(struct clk *clk)
> > +{
> > +	int		pll;
> > +	unsigned long	mult = 0, prediv = 1, postdiv = 1;
> > +	unsigned long	ref = OSC_FREQ_ONCHIP, ret;
> > +	u32		tmp;
> > +
> > +	if (WARN_ON(!clk->pll_data))
> > +		return clk->rate;
> > +
> > +	pll = clk->pll_data->num;
> > +
> > +	tmp = __raw_readl(&clk_ctrl_regs->pll_bypass);
> > +	if (!(tmp & bypass_mask[pll])) {
> > +		mult	= __raw_readl(&sspll_regs[pll]->mult_factor);
> > +		prediv	= __raw_readl(&sspll_regs[pll]->pre_div) + 1;
> > +		postdiv	= __raw_readl(&sspll_regs[pll]->post_div) + 1;
> > +	}
> > +
> > +	tmp = __raw_readl(pllctl_regs[pll] + PLLCTL);
> > +	if (tmp & PLLCTL_CLKMODE)
> > +		ref = pll_ext_freq[pll];
> > +
> > +	clk->pll_data->input_rate = ref;
> > +
> > +	tmp = __raw_readl(pllctl_regs[pll] + PLLCTL);
> > +	if (!(tmp & PLLCTL_PLLEN))
> > +		return ref;
> > +
> > +	ret = ref;
> > +	if (mult)
> > +		ret += ((unsigned long long)ref * mult) / 256;
> > +
> > +	ret /= (prediv * postdiv);
> > +
> > +	return ret;
> > +}
> 
> How about moving this to clock.c and using a flag in clk
> structure to determine whether to use clk_pllclk_recalc()
> or clk_sspll_recalc()?

For now, it seems the sspll wrapper is specific to tnetv107x.  That
said, I would rather keep this code private to tnetv107x (for now) and
promote to clock.c if/when other socs with ssplls turn up.

[...]
> > +static unsigned long clk_div_recalc(struct clk *clk)
> > +{
> > +	struct pll_data *pll;
> > +	unsigned long rate = clk->rate;
> > +	unsigned long div;
> > +
> > +	if (WARN_ON(!clk->parent))
> > +		return rate;
> > +
> > +	rate = clk->parent->rate;
> > +
> > +	/* Otherwise, the parent must be a PLL */
> > +	if (WARN_ON(!clk->parent->pll_data))
> > +		return rate;
> > +
> > +	pll = clk->parent->pll_data;
> > +
> > +	if (!clk->div_reg)
> > +		return rate;
> > +
> > +	div = __raw_readl(pllctl_regs[pll->num] + clk->div_reg);
> > +	if (div & PLLDIV_EN) {
> > +		div &= div_mask[pll->num];
> > +		rate /= (div + 1);
> > +	}
> > +
> > +	return rate;
> > +}
> 
> Is the div_mask the only reason you could not use clock.c:clk_sysclk_recalc()
> here? How about making the mask a part of PLL data and using PLLDIV_RATIO_MASK
> if no mask is initialized (zero)?

Agreed.  Will do so.

> > +static unsigned long clk_null_recalc(struct clk *clk)
> > +{
> > +	BUG_ON(!clk->parent);
> > +	return clk->parent->rate;
> > +}
> 
> There is already a function in clock.c which does exactly this
> (clk_leafclk_recalc).

Agreed.  Will reuse.

Thanks
- Cyril.


From kieranbingham at gmail.com  Thu Apr  8 09:23:23 2010
From: kieranbingham at gmail.com (Kieran Bingham)
Date: Thu, 08 Apr 2010 15:23:23 +0100
Subject: Kernel Modules and Latest Kernel from Arago
Message-ID: <4BBDE6DB.6070605@gmail.com>

Hi Guys

I'm working to bring our application from the 2.6.18 environment to the 
2.6.32 kernel for the DM365.

Our application runs using the mcvip-encoder code base - and av_capture 
framework from the DVRRDK.

Contained in here are some kernel modules that seem to need either a 
complete re-write - or the framework should perhaps be re-implemented to 
use the kernel framework differently.

In particular - it is the CSL and DRV modules
CSL seems to be titled Chip Support Library and wraps up interfaces to 
all the capture/resize hardware
DRV contains code to map DMA and I2C hardware.

Is anyone here working on the AV_Capture / mcvip framework code bases?
Has anyone got this framework running on the latest DVSDK3.10 code base?

Regards
Kieran Bingham

From idriss.ghodhbane at gmail.com  Thu Apr  8 09:34:14 2010
From: idriss.ghodhbane at gmail.com (Idriss Ghodhbane)
Date: Thu, 8 Apr 2010 16:34:14 +0200
Subject: DM355 CPU overload+alaw+gstreamer
Message-ID: <x2t90d17c5d1004080734i1878be4fg96717b20aec33e6f@mail.gmail.com>

 Hi everybody,

I am using the DM355 evm and I am working on streaming audio between two
DM355.

I have integrated the Alaw codec in the gstreamer because I haven't any TI
audio codec included in my evm DM355.

Despite the Alaw codec doesn't do compression or decompression, the CPU is
overloaded, about 98% when I launched the audio encoding or decoding

via the gstreamer's pipelines.

Can you help me solving this problem ?

Thanks in advance

-- 
IDRISS GHODHBANE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100408/3e33cafa/attachment.html>

From thomas.koeller at baslerweb.com  Thu Apr  8 10:01:53 2010
From: thomas.koeller at baslerweb.com (thomas.koeller at baslerweb.com)
Date: Thu,  8 Apr 2010 17:01:53 +0200
Subject: [PATCH 0/4] Improve modularity
Message-ID: <1270738918-30050-1-git-send-email-thomas.koeller@baslerweb.com>

From: Thomas Koeller <thomas.koeller at baslerweb.com>

While writing code to suport a new DaVinci-based board design, I
noticed several shortcomings of the existing code that this patch
series tries to address.


Thomas Koeller (4):
  DM365: Make all SPI units SPI0..SPI4 available
  DM365: Allow use of GPIO64_57
  DaVinci SPI: Fix SPI clock prescale factor computation
  DM365: Add platform resource management

 arch/arm/mach-davinci/board-dm365-evm.c           |   37 ++-
 arch/arm/mach-davinci/board_dm365_evm_resources.h |   17 +
 arch/arm/mach-davinci/dm365.c                     |  554 ++++++++++++++++++---
 arch/arm/mach-davinci/dma.c                       |    8 -
 arch/arm/mach-davinci/include/mach/dm365.h        |   24 +-
 arch/arm/mach-davinci/include/mach/mux.h          |    1 +
 drivers/i2c/busses/i2c-davinci.c                  |    9 +-
 drivers/mmc/host/davinci_mmc.c                    |    4 +-
 drivers/spi/davinci_spi.c                         |   28 +-
 9 files changed, 560 insertions(+), 122 deletions(-)
 create mode 100644 arch/arm/mach-davinci/board_dm365_evm_resources.h


From thomas.koeller at baslerweb.com  Thu Apr  8 10:01:54 2010
From: thomas.koeller at baslerweb.com (thomas.koeller at baslerweb.com)
Date: Thu,  8 Apr 2010 17:01:54 +0200
Subject: [PATCH 0/4] Improve modularity
In-Reply-To: <1270738918-30050-1-git-send-email-thomas.koeller@baslerweb.com>
References: <1270738918-30050-1-git-send-email-thomas.koeller@baslerweb.com>
Message-ID: <1270738918-30050-2-git-send-email-thomas.koeller@baslerweb.com>

From: Thomas Koeller <thomas.koeller at baslerweb.com>

While writing code to suport a new DaVinci-based board design, I
noticed several shortcomings of the existing code, that this patch
series tries to address.


Thomas Koeller (4):
  DM365: Make all SPI units SPI0..SPI4 available
  DM365: Allow use of GPIO64_57
  DaVinci SPI: Fix SPI clock prescale factor computation
  DM365: Add platform resource management

 arch/arm/mach-davinci/board-dm365-evm.c           |   37 ++-
 arch/arm/mach-davinci/board_dm365_evm_resources.h |   17 +
 arch/arm/mach-davinci/dm365.c                     |  554 ++++++++++++++++++---
 arch/arm/mach-davinci/dma.c                       |    8 -
 arch/arm/mach-davinci/include/mach/dm365.h        |   24 +-
 arch/arm/mach-davinci/include/mach/mux.h          |    1 +
 drivers/i2c/busses/i2c-davinci.c                  |    9 +-
 drivers/mmc/host/davinci_mmc.c                    |    4 +-
 drivers/spi/davinci_spi.c                         |   28 +-
 9 files changed, 560 insertions(+), 122 deletions(-)
 create mode 100644 arch/arm/mach-davinci/board_dm365_evm_resources.h


From thomas.koeller at baslerweb.com  Thu Apr  8 10:01:55 2010
From: thomas.koeller at baslerweb.com (thomas.koeller at baslerweb.com)
Date: Thu,  8 Apr 2010 17:01:55 +0200
Subject: [PATCH 1/4] DM365: Make all SPI units SPI0..SPI4 available
In-Reply-To: <1270738918-30050-1-git-send-email-thomas.koeller@baslerweb.com>
References: <1270738918-30050-1-git-send-email-thomas.koeller@baslerweb.com>
Message-ID: <1270738918-30050-3-git-send-email-thomas.koeller@baslerweb.com>

From: Thomas Koeller <thomas.koeller at baslerweb.com>

Change the SPI setup code to allow use of all SPI units. Also,
move some resource assignments (DMA channels, interrupts)
to the board code, where they belong. These really should not
be hard-coded in dm365.c.

Signed-off-by: Thomas Koeller <thomas.koeller at baslerweb.com>
---
 arch/arm/mach-davinci/board-dm365-evm.c           |   37 +++-
 arch/arm/mach-davinci/board_dm365_evm_resources.h |   17 ++
 arch/arm/mach-davinci/dm365.c                     |  278 +++++++++++++++++----
 arch/arm/mach-davinci/include/mach/dm365.h        |   16 +-
 4 files changed, 293 insertions(+), 55 deletions(-)
 create mode 100644 arch/arm/mach-davinci/board_dm365_evm_resources.h

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index ab3b0e2..6797d3e 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -49,6 +49,8 @@
 #include <media/tvp7002.h>
 #include <media/davinci/videohd.h>
 
+#include "board_dm365_evm_resources.h"
+
 
 
 /* have_imager() - Check if we have support for imager interface */
@@ -832,16 +834,39 @@ static struct spi_eeprom at25640 = {
 	.flags		= EE_ADDR2,
 };
 
-static struct spi_board_info dm365_evm_spi_info[] __initconst = {
-	{
+static const struct spi_board_info
+	dm365_evm_spi_info_at25 __initconst = {
 		.modalias	= "at25",
 		.platform_data	= &at25640,
 		.max_speed_hz	= 20 * 1000 * 1000,	/* at 3v3 */
 		.bus_num	= 0,
 		.chip_select	= 0,
 		.mode		= SPI_MODE_0,
-	},
-};
+	};
+
+static struct dm365_spi_unit_desc
+	dm365_evm_spi_udesc_at25 = {
+		.spi_hwunit	= 0,
+		.chipsel	= BIT(0),
+		.irq		= IRQ_SPI0,
+		.dma_tx_chan	= DMA_CHAN_SPI0_TX,
+		.dma_rx_chan	= DMA_CHAN_SPI0_RX,
+		.dma_evtq	= DMA_EVQ_SPI0,
+		.pdata		= {
+			.version 	= SPI_VERSION_1,
+			.num_chipselect = 2,
+			.clk_internal	= 1,
+			.cs_hold	= 1,
+			.intr_level	= 0,
+			.poll_mode	= 1,	/* 0 -> interrupt mode 1-> polling mode */
+			.use_dma	= 1,	/* when 1, value in poll_mode is ignored */
+			.c2tdelay	= 0,
+			.t2cdelay	= 0
+		}
+	};
+
+
+
 
 static __init void dm365_evm_init(void)
 {
@@ -861,8 +886,8 @@ static __init void dm365_evm_init(void)
 	dm365_init_rtc();
 	dm365_init_ks(&dm365evm_ks_data);
 
-	dm365_init_spi0(BIT(0), dm365_evm_spi_info,
-			ARRAY_SIZE(dm365_evm_spi_info));
+	dm365_init_spi(&dm365_evm_spi_udesc_at25, 1, &dm365_evm_spi_info_at25);
+	return;
 }
 
 static __init void dm365_evm_irq_init(void)
diff --git a/arch/arm/mach-davinci/board_dm365_evm_resources.h b/arch/arm/mach-davinci/board_dm365_evm_resources.h
new file mode 100644
index 0000000..d9cfc6b
--- /dev/null
+++ b/arch/arm/mach-davinci/board_dm365_evm_resources.h
@@ -0,0 +1,17 @@
+#ifndef _DAVINCI_EVM_RESOURCES_H
+#define _DAVINCI_EVM_RESOURCES_H
+
+#include <mach/irqs.h>
+#include <mach/edma.h>
+
+/* IRQs */
+#define IRQ_SPI0		IRQ_DM365_SPIINT0_0
+
+/* DMA channels */
+#define DMA_CHAN_SPI0_TX	16
+#define DMA_CHAN_SPI0_RX	17
+
+/* DMA event queues */
+#define DMA_EVQ_SPI0		EVENTQ_3
+
+#endif /* _DAVINCI_EVM_RESOURCES_H */
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index ed6c9c7..023d708 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -616,72 +616,256 @@ EVT_CFG(DM365,	EVT3_ASP_RX,         1,     1,    0,     false)
 #endif
 };
 
-static u64 dm365_spi0_dma_mask = DMA_BIT_MASK(32);
+static u64 dm365_spi_dma_mask = DMA_BIT_MASK(32);
 
-static struct davinci_spi_platform_data dm365_spi0_pdata = {
-	.version 	= SPI_VERSION_1,
-	.num_chipselect = 2,
-	.clk_internal	= 1,
-	.cs_hold	= 1,
-	.intr_level	= 0,
-	.poll_mode	= 1,	/* 0 -> interrupt mode 1-> polling mode */
-	.use_dma	= 1,	/* when 1, value in poll_mode is ignored */
-	.c2tdelay	= 0,
-	.t2cdelay	= 0,
+enum dm365_spi_resource_index {
+	spirsrc_iomem,
+	spirsrc_irq,
+	spirsrc_rxdma,
+	spirsrc_txdma,
+	spirsrc_evqdma
 };
 
-static struct resource dm365_spi0_resources[] = {
+
+static struct resource dm365_spi_resources[spirsrc_evqdma + 1][5] = {
 	{
-		.start = 0x01c66000,
-		.end   = 0x01c667ff,
-		.flags = IORESOURCE_MEM,
+		[spirsrc_iomem] = {
+			.start	= 0x01c66000,
+			.end	= 0x01c667ff,
+			.flags	= IORESOURCE_MEM,
+		},
+		[spirsrc_irq] = {
+			.flags	= IORESOURCE_IRQ,
+		},
+		[spirsrc_rxdma] = {
+			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
+		},
+		[spirsrc_txdma] = {
+			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
+		},
+		[spirsrc_evqdma] = {
+			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
+		}
 	},
 	{
-		.start = IRQ_DM365_SPIINT0_0,
-		.flags = IORESOURCE_IRQ,
+		[spirsrc_iomem] = {
+			.start	= 0x01c66800,
+			.end	= 0x01c66fff,
+			.flags	= IORESOURCE_MEM,
+		},
+		[spirsrc_irq] = {
+			.flags	= IORESOURCE_IRQ,
+		},
+		[spirsrc_rxdma] = {
+			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
+		},
+		[spirsrc_txdma] = {
+			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
+		},
+		[spirsrc_evqdma] = {
+			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
+		}
 	},
 	{
-		.start = 17,
-		.flags = IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
+		[spirsrc_iomem] = {
+			.start	= 0x01c67800,
+			.end	= 0x01c67fff,
+			.flags	= IORESOURCE_MEM,
+		},
+		[spirsrc_irq] = {
+			.flags	= IORESOURCE_IRQ,
+		},
+		[spirsrc_rxdma] = {
+			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
+		},
+		[spirsrc_txdma] = {
+			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
+		},
+		[spirsrc_evqdma] = {
+			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
+		}
 	},
 	{
-		.start = 16,
-		.flags = IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
+		[spirsrc_iomem] = {
+			.start	= 0x01c68000,
+			.end	= 0x01c687ff,
+			.flags	= IORESOURCE_MEM,
+		},
+		[spirsrc_irq] = {
+			.flags	= IORESOURCE_IRQ,
+		},
+		[spirsrc_rxdma] = {
+			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
+		},
+		[spirsrc_txdma] = {
+			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
+		},
+		[spirsrc_evqdma] = {
+			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
+		}
 	},
 	{
-		.start = EVENTQ_3,
-		.flags = IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
+		[spirsrc_iomem] = {
+			.start	= 0x01c23000,
+			.end	= 0x01c237ff,
+			.flags	= IORESOURCE_MEM,
+		},
+		[spirsrc_irq] = {
+			.flags	= IORESOURCE_IRQ,
+		},
+		[spirsrc_rxdma] = {
+			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
+		},
+		[spirsrc_txdma] = {
+			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
+		},
+		[spirsrc_evqdma] = {
+			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
+		}
+	}
+};
+
+static struct platform_device dm365_spi_device[] = {
+	{
+		.name = "spi_davinci",
+		.id = 0,
+		.dev = {
+			.dma_mask = &dm365_spi_dma_mask,
+			.coherent_dma_mask = DMA_BIT_MASK(32),
+		},
+		.num_resources = ARRAY_SIZE(dm365_spi_resources[0]),
+		.resource = dm365_spi_resources[0]
 	},
-};
-
-static struct platform_device dm365_spi0_device = {
-	.name = "spi_davinci",
-	.id = 0,
-	.dev = {
-		.dma_mask = &dm365_spi0_dma_mask,
-		.coherent_dma_mask = DMA_BIT_MASK(32),
-		.platform_data = &dm365_spi0_pdata,
+	{
+		.name = "spi_davinci",
+		.id = 1,
+		.dev = {
+			.dma_mask = &dm365_spi_dma_mask,
+			.coherent_dma_mask = DMA_BIT_MASK(32),
+		},
+		.num_resources = ARRAY_SIZE(dm365_spi_resources[1]),
+		.resource = dm365_spi_resources[1]
+	},
+	{
+		.name = "spi_davinci",
+		.id = 2,
+		.dev = {
+			.dma_mask = &dm365_spi_dma_mask,
+			.coherent_dma_mask = DMA_BIT_MASK(32),
+		},
+		.num_resources = ARRAY_SIZE(dm365_spi_resources[2]),
+		.resource = dm365_spi_resources[2]
+	},
+	{
+		.name = "spi_davinci",
+		.id = 3,
+		.dev = {
+			.dma_mask = &dm365_spi_dma_mask,
+			.coherent_dma_mask = DMA_BIT_MASK(32),
+		},
+		.num_resources = ARRAY_SIZE(dm365_spi_resources[3]),
+		.resource = dm365_spi_resources[3]
 	},
-	.num_resources = ARRAY_SIZE(dm365_spi0_resources),
-	.resource = dm365_spi0_resources,
+	{
+		.name = "spi_davinci",
+		.id = 4,
+		.dev = {
+			.dma_mask = &dm365_spi_dma_mask,
+			.coherent_dma_mask = DMA_BIT_MASK(32),
+		},
+		.num_resources = ARRAY_SIZE(dm365_spi_resources[4]),
+		.resource = dm365_spi_resources[4]
+	}
+};
+
+struct dm365_spi_pins {
+	int	sclk;
+	int	sdi;
+	int	sdo;
+	int	sdena0;
+	int	sdena1;
+};
+
+static const struct dm365_spi_pins dm365_spi_pinmap[] __initconst = {
+	{
+		.sclk	= DM365_SPI0_SCLK,
+		.sdi	= DM365_SPI0_SDI,
+		.sdo	= DM365_SPI0_SDO,
+		.sdena0	= DM365_SPI0_SDENA0,
+		.sdena1	= DM365_SPI0_SDENA1
+	},
+	{
+		.sclk	= DM365_SPI1_SCLK,
+		.sdi	= DM365_SPI1_SDI,
+		.sdo	= DM365_SPI1_SDO,
+		.sdena0	= DM365_SPI1_SDENA0,
+		.sdena1	= DM365_SPI1_SDENA1
+	},
+	{
+		.sclk	= DM365_SPI2_SCLK,
+		.sdi	= DM365_SPI2_SDI,
+		.sdo	= DM365_SPI2_SDO,
+		.sdena0	= DM365_SPI2_SDENA0,
+		.sdena1	= DM365_SPI2_SDENA1
+	},
+	{
+		.sclk	= DM365_SPI3_SCLK,
+		.sdi	= DM365_SPI3_SDI,
+		.sdo	= DM365_SPI3_SDO,
+		.sdena0	= DM365_SPI3_SDENA0,
+		.sdena1	= DM365_SPI3_SDENA1
+	},
+	{
+		.sclk	= DM365_SPI4_SCLK,
+		.sdi	= DM365_SPI4_SDI,
+		.sdo	= DM365_SPI4_SDO,
+		.sdena0	= DM365_SPI4_SDENA0,
+		.sdena1	= DM365_SPI4_SDENA1
+	}
 };
 
-void __init dm365_init_spi0(unsigned chipselect_mask,
-		struct spi_board_info *info, unsigned len)
+void __init dm365_init_spi(struct dm365_spi_unit_desc *unit,
+			unsigned int ninfo,
+			const struct spi_board_info *info)
 {
-	davinci_cfg_reg(DM365_SPI0_SCLK);
-	davinci_cfg_reg(DM365_SPI0_SDI);
-	davinci_cfg_reg(DM365_SPI0_SDO);
+	int err;
+	const unsigned int hwunit = unit->spi_hwunit;
+	const struct dm365_spi_pins * const pins = &dm365_spi_pinmap[hwunit];
+	struct platform_device * const pdev = &dm365_spi_device[hwunit];
+	struct davinci_spi_platform_data * const pdata = &unit->pdata;
 
-	/* not all slaves will be wired up */
-	if (chipselect_mask & BIT(0))
-		davinci_cfg_reg(DM365_SPI0_SDENA0);
-	if (chipselect_mask & BIT(1))
-		davinci_cfg_reg(DM365_SPI0_SDENA1);
-
-	spi_register_board_info(info, len);
+	davinci_cfg_reg(pins->sclk);
+	davinci_cfg_reg(pins->sdi);
+	davinci_cfg_reg(pins->sdo);
 
-	platform_device_register(&dm365_spi0_device);
+	/* not all slaves will be wired up */
+	if (unit->chipsel & BIT(0))
+		davinci_cfg_reg(pins->sdena0);
+	if (unit->chipsel & BIT(1))
+		davinci_cfg_reg(pins->sdena1);
+
+	pdev->dev.platform_data = pdata;
+
+	pdev->resource[spirsrc_irq].start =
+	pdev->resource[spirsrc_irq].end = unit->irq;
+	pdev->resource[spirsrc_rxdma].start =
+	pdev->resource[spirsrc_rxdma].end = unit->dma_rx_chan;
+	pdev->resource[spirsrc_txdma].start =
+	pdev->resource[spirsrc_txdma].end = unit->dma_tx_chan;
+	pdev->resource[spirsrc_evqdma].start =
+	pdev->resource[spirsrc_evqdma].end = unit->dma_evtq;
+
+	pr_debug("Creating SPI%u: irq = %u, dma_rx = %u, dma_tx = %u, "
+		"dma_evq = %u",
+		hwunit, unit->irq, unit->dma_rx_chan, unit->dma_tx_chan,
+		unit->dma_evtq);
+
+	err = platform_device_register(pdev);
+	if (unlikely(err))
+		pr_err("Failed to create platform device for SPI%u - error %d",
+			hwunit, err);
+
+	spi_register_board_info(info, ninfo);
 }
 
 
diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h
index 44b0cc6..3d2a823 100644
--- a/arch/arm/mach-davinci/include/mach/dm365.h
+++ b/arch/arm/mach-davinci/include/mach/dm365.h
@@ -19,6 +19,7 @@
 #include <mach/emac.h>
 #include <mach/asp.h>
 #include <mach/keyscan.h>
+#include <mach/spi.h>
 
 #define DM365_EMAC_BASE			(0x01D07000)
 #define DM365_EMAC_CNTRL_OFFSET		(0x0000)
@@ -38,8 +39,19 @@ void __init dm365_init_rtc(void);
 void __init dm365_init_ks(struct davinci_ks_platform_data *pdata);
 void dm365_set_vpfe_config(struct vpfe_config *cfg);
 
+struct dm365_spi_unit_desc {
+	unsigned int				spi_hwunit;
+	unsigned int				chipsel;
+	unsigned int				irq;
+	unsigned int				dma_tx_chan;
+	unsigned int				dma_rx_chan;
+	unsigned int				dma_evtq;
+	struct davinci_spi_platform_data	pdata;
+};
+
 struct spi_board_info;
-void dm365_init_spi0(unsigned chipselect_mask,
-		struct spi_board_info *info, unsigned len);
+void dm365_init_spi(struct dm365_spi_unit_desc *unit,
+		unsigned int ninfo,
+		const struct spi_board_info *info);
 
 #endif /* __ASM_ARCH_DM365_H */
-- 
1.7.0.3


From thomas.koeller at baslerweb.com  Thu Apr  8 10:01:56 2010
From: thomas.koeller at baslerweb.com (thomas.koeller at baslerweb.com)
Date: Thu,  8 Apr 2010 17:01:56 +0200
Subject: [PATCH 2/4] DM365: Allow use of GPIO64_57
In-Reply-To: <1270738918-30050-1-git-send-email-thomas.koeller@baslerweb.com>
References: <1270738918-30050-1-git-send-email-thomas.koeller@baslerweb.com>
Message-ID: <1270738918-30050-4-git-send-email-thomas.koeller@baslerweb.com>

From: Thomas Koeller <thomas.koeller at baslerweb.com>

Extended the MUX configuration to allow use of GPIO
terminals 64..57.

Signed-off-by: Thomas Koeller <thomas.koeller at baslerweb.com>
---
 arch/arm/mach-davinci/dm365.c            |    1 +
 arch/arm/mach-davinci/include/mach/mux.h |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 023d708..0813dce 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -580,6 +580,7 @@ MUX_CFG(DM365,	SPI4_SDENA1,	4,   16,    3,    2,	 false)
 MUX_CFG(DM365,	GPIO20,		3,   21,    3,    0,	 false)
 MUX_CFG(DM365,	GPIO33,		4,   12,    3,	  0,	 false)
 MUX_CFG(DM365,	GPIO40,		4,   26,    3,	  0,	 false)
+MUX_CFG(DM365,	GPIO64_57,	2,   6,     1,	  0,	 false)
 
 MUX_CFG(DM365,	VOUT_FIELD,	1,   18,    3,	  1,	 false)
 MUX_CFG(DM365,	VOUT_FIELD_G81,	1,   18,    3,	  0,	 false)
diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h
index 05e35fa..d6c6921 100644
--- a/arch/arm/mach-davinci/include/mach/mux.h
+++ b/arch/arm/mach-davinci/include/mach/mux.h
@@ -295,6 +295,7 @@ enum davinci_dm365_index {
 	DM365_GPIO20,
 	DM365_GPIO33,
 	DM365_GPIO40,
+	DM365_GPIO64_57,
 
 	/* Video */
 	DM365_VOUT_FIELD,
-- 
1.7.0.3


From thomas.koeller at baslerweb.com  Thu Apr  8 10:01:57 2010
From: thomas.koeller at baslerweb.com (thomas.koeller at baslerweb.com)
Date: Thu,  8 Apr 2010 17:01:57 +0200
Subject: [PATCH 3/4] DaVinci SPI: Fix SPI clock prescale factor computation
In-Reply-To: <1270738918-30050-1-git-send-email-thomas.koeller@baslerweb.com>
References: <1270738918-30050-1-git-send-email-thomas.koeller@baslerweb.com>
Message-ID: <1270738918-30050-5-git-send-email-thomas.koeller@baslerweb.com>

From: Thomas Koeller <thomas.koeller at baslerweb.com>

Computation of the clock prescaler value returned bogus results if
the requested SPI clock was impossible to set. It now sets either
the maximum or minimum clock frequency, as appropriate.

Signed-off-by: Thomas Koeller <thomas.koeller at baslerweb.com>
---
 drivers/spi/davinci_spi.c |   12 +++++++++---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 956f617..02e1a76 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -153,7 +153,7 @@ static int davinci_spi_setup_transfer(struct spi_device *spi,
 	struct davinci_spi *davinci_spi;
 	struct davinci_spi_platform_data *pdata;
 	u8 bits_per_word = 0;
-	u32 hz = 0, prescale;
+	u32 hz = 0, prescale = 0, clkspeed;
 
 	davinci_spi = spi_master_get_devdata(spi->master);
 	pdata = davinci_spi->pdata;
@@ -190,10 +190,16 @@ static int davinci_spi_setup_transfer(struct spi_device *spi,
 	set_fmt_bits(davinci_spi->base, bits_per_word & 0x1f,
 			spi->chip_select);
 
-	prescale = ((clk_get_rate(davinci_spi->clk) / hz) - 1) & 0xff;
+	clkspeed = clk_get_rate(davinci_spi->clk);
+	if (hz > clkspeed / 2)
+		prescale = 1 << 8;
+	if (hz < clkspeed / 256)
+		prescale = 255 << 8;
+	if (!prescale)
+		prescale = ((clkspeed / hz - 1) << 8) & 0x0000ff00;
 
 	clear_fmt_bits(davinci_spi->base, 0x0000ff00, spi->chip_select);
-	set_fmt_bits(davinci_spi->base, prescale << 8, spi->chip_select);
+	set_fmt_bits(davinci_spi->base, prescale, spi->chip_select);
 
 	return 0;
 }
-- 
1.7.0.3


From thomas.koeller at baslerweb.com  Thu Apr  8 10:01:58 2010
From: thomas.koeller at baslerweb.com (thomas.koeller at baslerweb.com)
Date: Thu,  8 Apr 2010 17:01:58 +0200
Subject: [PATCH 4/4] DM365: Add platform resource management
In-Reply-To: <1270738918-30050-1-git-send-email-thomas.koeller@baslerweb.com>
References: <1270738918-30050-1-git-send-email-thomas.koeller@baslerweb.com>
Message-ID: <1270738918-30050-6-git-send-email-thomas.koeller@baslerweb.com>

From: Thomas Koeller <thomas.koeller at baslerweb.com>

Keeping track of resource assignments greatly simplifies
the task of writing board support code. Many drivers for
DaVinci peripherals were using resources that had never
been allocated, with the notable exception of memory
resources.

Non-conflicting resource assignment is a responsibility
of the bus the devices are on, in this case, the platform bus.

The resource management scheme implemented by this patch is not
perfect. The SoC code really has no business managing resources,
it should only provide them to the platform (board support) code.
The board support is the only place where information about the
intended use of the various hardware resources is available.

Signed-off-by: Thomas Koeller <thomas.koeller at baslerweb.com>
---
 arch/arm/mach-davinci/dm365.c              |  287 ++++++++++++++++++++++++----
 arch/arm/mach-davinci/dma.c                |    8 -
 arch/arm/mach-davinci/include/mach/dm365.h |    8 +
 drivers/i2c/busses/i2c-davinci.c           |    9 +-
 drivers/mmc/host/davinci_mmc.c             |    4 +-
 drivers/spi/davinci_spi.c                  |   16 +--
 6 files changed, 262 insertions(+), 70 deletions(-)

diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 0813dce..33be53e 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -617,6 +617,74 @@ EVT_CFG(DM365,	EVT3_ASP_RX,         1,     1,    0,     false)
 #endif
 };
 
+/* root resource for configuration register space */
+struct resource resource_cfg_root = {
+	.name	= "DM365 peripherals",
+	.start	= 0x01c00000,
+	.end	= 0x01ffffff,
+	.flags	= IORESOURCE_MEM
+};
+EXPORT_SYMBOL(resource_cfg_root);
+
+/* root resource for DMA channels */
+struct resource resource_dma_root = {
+	.name	= "DM365 DMA",
+	.start	= 0,
+	.end	= 63,
+	.flags	= IORESOURCE_DMA
+};
+EXPORT_SYMBOL(resource_dma_root);
+
+/* root resource for DMA event queues */
+struct resource resource_evq_root = {
+	.name	= "DM365 EVQ",
+	.start	= 0,
+	.end	= 3,
+	.flags	= IORESOURCE_DMA
+};
+EXPORT_SYMBOL(resource_evq_root);
+
+/* root resource for IRQ numbers */
+struct resource resource_irq_root = {
+	.name	= "DM365 IRQ",
+	.start	= 0,
+	.end	= 63,
+	.flags	= IORESOURCE_IRQ
+};
+EXPORT_SYMBOL(resource_irq_root);
+
+/* Allocate resources for platform device */
+static int alloc_platform_resources(const struct platform_device *dev)
+{
+	int n;
+
+	for (n = 0; n < dev->num_resources; ++n) {
+		int res;
+		struct resource *rsrc = &dev->resource[n];
+
+		res = request_resource(rsrc->parent, rsrc);
+		if (likely(!res))
+			continue;
+
+		/* bail out */
+		pr_warning("Resource allocation failed for '%s'\n", rsrc->name);
+		while (--n >= 0) {
+			struct resource *parent;
+
+			/* preserve the parent pointer */
+			rsrc = &dev->resource[n];
+			parent = rsrc->parent;
+			release_resource(rsrc);
+			rsrc->parent = parent;
+		}
+
+		return res;
+	}
+
+	return 0;
+}
+
+
 static u64 dm365_spi_dma_mask = DMA_BIT_MASK(32);
 
 enum dm365_spi_resource_index {
@@ -627,100 +695,158 @@ enum dm365_spi_resource_index {
 	spirsrc_evqdma
 };
 
+static const char
+	spi0_name[] = "SPI0",
+	spi1_name[] = "SPI1",
+	spi2_name[] = "SPI2",
+	spi3_name[] = "SPI3",
+	spi4_name[] = "SPI4";
 
-static struct resource dm365_spi_resources[spirsrc_evqdma + 1][5] = {
-	{
+
+static struct resource
+dm365_spi_resources[spirsrc_evqdma + 1][5] = {
+	[0] = {
 		[spirsrc_iomem] = {
+			.name	= spi0_name,
+			.parent	= &resource_cfg_root,
 			.start	= 0x01c66000,
 			.end	= 0x01c667ff,
 			.flags	= IORESOURCE_MEM,
 		},
 		[spirsrc_irq] = {
+			.name	= spi0_name,
+			.parent	= &resource_irq_root,
 			.flags	= IORESOURCE_IRQ,
 		},
 		[spirsrc_rxdma] = {
+			.name	= spi0_name,
+			.parent	= &resource_dma_root,
 			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
 		},
 		[spirsrc_txdma] = {
+			.name	= spi0_name,
+			.parent	= &resource_dma_root,
 			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
 		},
 		[spirsrc_evqdma] = {
+			.name	= spi0_name,
+			.parent	= &resource_evq_root,
 			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
 		}
 	},
-	{
+	[1] = {
 		[spirsrc_iomem] = {
+			.name	= spi1_name,
+			.parent	= &resource_cfg_root,
 			.start	= 0x01c66800,
 			.end	= 0x01c66fff,
 			.flags	= IORESOURCE_MEM,
 		},
 		[spirsrc_irq] = {
+			.name	= spi1_name,
+			.parent	= &resource_irq_root,
 			.flags	= IORESOURCE_IRQ,
 		},
 		[spirsrc_rxdma] = {
+			.name	= spi1_name,
+			.parent	= &resource_dma_root,
 			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
 		},
 		[spirsrc_txdma] = {
+			.name	= spi1_name,
+			.parent	= &resource_dma_root,
 			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
 		},
 		[spirsrc_evqdma] = {
+			.name	= spi1_name,
+			.parent	= &resource_evq_root,
 			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
 		}
 	},
-	{
+	[2] = {
 		[spirsrc_iomem] = {
+			.name	= spi2_name,
+			.parent	= &resource_cfg_root,
 			.start	= 0x01c67800,
 			.end	= 0x01c67fff,
 			.flags	= IORESOURCE_MEM,
 		},
 		[spirsrc_irq] = {
+			.name	= spi2_name,
+			.parent	= &resource_irq_root,
 			.flags	= IORESOURCE_IRQ,
 		},
 		[spirsrc_rxdma] = {
+			.name	= spi2_name,
+			.parent	= &resource_dma_root,
 			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
 		},
 		[spirsrc_txdma] = {
+			.name	= spi2_name,
+			.parent	= &resource_dma_root,
 			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
 		},
 		[spirsrc_evqdma] = {
+			.name	= spi2_name,
+			.parent	= &resource_evq_root,
 			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
 		}
 	},
-	{
+	[3] = {
 		[spirsrc_iomem] = {
+			.name	= spi3_name,
+			.parent	= &resource_cfg_root,
 			.start	= 0x01c68000,
 			.end	= 0x01c687ff,
 			.flags	= IORESOURCE_MEM,
 		},
 		[spirsrc_irq] = {
+			.name	= spi3_name,
+			.parent	= &resource_irq_root,
 			.flags	= IORESOURCE_IRQ,
 		},
 		[spirsrc_rxdma] = {
+			.name	= spi3_name,
+			.parent	= &resource_dma_root,
 			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
 		},
 		[spirsrc_txdma] = {
+			.name	= spi3_name,
+			.parent	= &resource_dma_root,
 			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
 		},
 		[spirsrc_evqdma] = {
+			.name	= spi3_name,
+			.parent	= &resource_evq_root,
 			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
 		}
 	},
-	{
+	[4] = {
 		[spirsrc_iomem] = {
+			.name	= spi4_name,
+			.parent	= &resource_cfg_root,
 			.start	= 0x01c23000,
 			.end	= 0x01c237ff,
 			.flags	= IORESOURCE_MEM,
 		},
 		[spirsrc_irq] = {
+			.name	= spi4_name,
+			.parent	= &resource_irq_root,
 			.flags	= IORESOURCE_IRQ,
 		},
 		[spirsrc_rxdma] = {
+			.name	= spi4_name,
+			.parent	= &resource_dma_root,
 			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
 		},
 		[spirsrc_txdma] = {
+			.name	= spi4_name,
+			.parent	= &resource_dma_root,
 			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
 		},
 		[spirsrc_evqdma] = {
+			.name	= spi4_name,
+			.parent	= &resource_evq_root,
 			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
 		}
 	}
@@ -856,6 +982,11 @@ void __init dm365_init_spi(struct dm365_spi_unit_desc *unit,
 	pdev->resource[spirsrc_evqdma].start =
 	pdev->resource[spirsrc_evqdma].end = unit->dma_evtq;
 
+	if (alloc_platform_resources(pdev)) {
+		pr_err("Resource allocation failed for SPI%u\n", hwunit);
+		return;
+	};
+
 	pr_debug("Creating SPI%u: irq = %u, dma_rx = %u, dma_tx = %u, "
 		"dma_evq = %u",
 		hwunit, unit->irq, unit->dma_rx_chan, unit->dma_tx_chan,
@@ -874,6 +1005,8 @@ void __init dm365_init_spi(struct dm365_spi_unit_desc *unit,
 static u64 dm365_ipipeif_dma_mask = DMA_BIT_MASK(32);
 static struct resource dm365_ipipeif_resources[] = {
 	{
+		.name		= "IPIPEIF",
+		.parent		= &resource_cfg_root,
 		.start          = 0x01C71200,
 		.end            = 0x01C71200 + 0x60,
 		.flags          = IORESOURCE_MEM,
@@ -901,11 +1034,13 @@ static struct davinci_osd_platform_data dm365_osd_pdata = {
 
 static struct resource dm365_osd_resources[] = {
 	{
+		.parent		= &resource_irq_root,
 		.start          = IRQ_VENCINT,
 		.end            = IRQ_VENCINT,
 		.flags          = IORESOURCE_IRQ,
 	},
 	{
+		.parent		= &resource_cfg_root,
 		.start          = DM365_OSD_REG_BASE,
 		.end            = DM365_OSD_REG_BASE + OSD_REG_SIZE,
 		.flags          = IORESOURCE_MEM,
@@ -931,9 +1066,12 @@ static struct davinci_venc_platform_data dm365_venc_pdata = {
 	.soc = DM36x,
 };
 
+static const char venc_name[] = "davinci_venc";
 
 static struct resource dm365_venc_resources[] = {
 	{
+		.name		= venc_name,
+		.parent		= &resource_cfg_root,
 		.start          = DM365_VENC_REG_BASE,
 		.end            = DM365_VENC_REG_BASE + 0x180,
 		.flags          = IORESOURCE_MEM,
@@ -941,7 +1079,7 @@ static struct resource dm365_venc_resources[] = {
 };
 
 static struct platform_device dm365_venc_dev = {
-	.name		= "davinci_venc",
+	.name		= venc_name,
 	.id		= -1,
 	.num_resources	= ARRAY_SIZE(dm365_venc_resources),
 	.resource	= dm365_venc_resources,
@@ -961,28 +1099,40 @@ static struct emac_platform_data dm365_emac_pdata = {
 	.version		= EMAC_VERSION_2,
 };
 
+static const char emac_name[] = "davinci_emac";
+
 static struct resource dm365_emac_resources[] = {
 	{
+		.name	= emac_name,
+		.parent	= &resource_cfg_root,
 		.start	= DM365_EMAC_BASE,
 		.end	= DM365_EMAC_BASE + 0x47ff,
 		.flags	= IORESOURCE_MEM,
 	},
 	{
+		.name	= emac_name,
+		.parent	= &resource_irq_root,
 		.start	= IRQ_DM365_EMAC_RXTHRESH,
 		.end	= IRQ_DM365_EMAC_RXTHRESH,
 		.flags	= IORESOURCE_IRQ,
 	},
 	{
+		.name	= emac_name,
+		.parent	= &resource_irq_root,
 		.start	= IRQ_DM365_EMAC_RXPULSE,
 		.end	= IRQ_DM365_EMAC_RXPULSE,
 		.flags	= IORESOURCE_IRQ,
 	},
 	{
+		.name	= emac_name,
+		.parent	= &resource_irq_root,
 		.start	= IRQ_DM365_EMAC_TXPULSE,
 		.end	= IRQ_DM365_EMAC_TXPULSE,
 		.flags	= IORESOURCE_IRQ,
 	},
 	{
+		.name	= emac_name,
+		.parent	= &resource_irq_root,
 		.start	= IRQ_DM365_EMAC_MISCPULSE,
 		.end	= IRQ_DM365_EMAC_MISCPULSE,
 		.flags	= IORESOURCE_IRQ,
@@ -990,7 +1140,7 @@ static struct resource dm365_emac_resources[] = {
 };
 
 static struct platform_device dm365_emac_device = {
-	.name		= "davinci_emac",
+	.name		= emac_name,
 	.id		= 1,
 	.dev = {
 		.platform_data	= &dm365_emac_pdata,
@@ -1104,42 +1254,51 @@ static struct edma_soc_info dm365_edma_info[] = {
 static struct resource edma_resources[] = {
 	{
 		.name	= "edma_cc0",
+		.parent	= &resource_cfg_root,
 		.start	= 0x01c00000,
 		.end	= 0x01c00000 + SZ_64K - 1,
 		.flags	= IORESOURCE_MEM,
 	},
 	{
 		.name	= "edma_tc0",
+		.parent	= &resource_cfg_root,
 		.start	= 0x01c10000,
 		.end	= 0x01c10000 + SZ_1K - 1,
 		.flags	= IORESOURCE_MEM,
 	},
 	{
 		.name	= "edma_tc1",
+		.parent	= &resource_cfg_root,
 		.start	= 0x01c10400,
 		.end	= 0x01c10400 + SZ_1K - 1,
 		.flags	= IORESOURCE_MEM,
 	},
 	{
 		.name	= "edma_tc2",
+		.parent	= &resource_cfg_root,
 		.start	= 0x01c10800,
 		.end	= 0x01c10800 + SZ_1K - 1,
 		.flags	= IORESOURCE_MEM,
 	},
 	{
 		.name	= "edma_tc3",
+		.parent	= &resource_cfg_root,
 		.start	= 0x01c10c00,
 		.end	= 0x01c10c00 + SZ_1K - 1,
 		.flags	= IORESOURCE_MEM,
 	},
 	{
 		.name	= "edma0",
+		.parent	= &resource_irq_root,
 		.start	= IRQ_CCINT0,
+		.end	= IRQ_CCINT0,
 		.flags	= IORESOURCE_IRQ,
 	},
 	{
 		.name	= "edma0_err",
+		.parent	= &resource_irq_root,
 		.start	= IRQ_CCERRINT,
+		.end	= IRQ_CCERRINT,
 		.flags	= IORESOURCE_IRQ,
 	},
 	/* not using TC*_ERR */
@@ -1153,18 +1312,26 @@ static struct platform_device dm365_edma_device = {
 	.resource		= edma_resources,
 };
 
+static const char asp_name[] = "davinci-asp";
+
 static struct resource dm365_asp_resources[] = {
 	{
+		.name	= asp_name,
+		.parent	= &resource_cfg_root,
 		.start	= DAVINCI_DM365_ASP0_BASE,
 		.end	= DAVINCI_DM365_ASP0_BASE + SZ_8K - 1,
 		.flags	= IORESOURCE_MEM,
 	},
 	{
+		.name	= asp_name,
+		.parent	= &resource_dma_root,
 		.start	= DAVINCI_DMA_ASP0_TX,
 		.end	= DAVINCI_DMA_ASP0_TX,
 		.flags	= IORESOURCE_DMA,
 	},
 	{
+		.name	= asp_name,
+		.parent	= &resource_dma_root,
 		.start	= DAVINCI_DMA_ASP0_RX,
 		.end	= DAVINCI_DMA_ASP0_RX,
 		.flags	= IORESOURCE_DMA,
@@ -1172,26 +1339,33 @@ static struct resource dm365_asp_resources[] = {
 };
 
 static struct platform_device dm365_asp_device = {
-	.name		= "davinci-asp",
+	.name		= asp_name,
 	.id		= 0,
 	.num_resources	= ARRAY_SIZE(dm365_asp_resources),
 	.resource	= dm365_asp_resources,
 };
 
+static const char rtc_name[] = "rtc_davinci";
+
 static struct resource dm365_rtc_resources[] = {
 	{
-		.start = DM365_RTC_BASE,
-		.end = DM365_RTC_BASE + SZ_1K - 1,
-		.flags = IORESOURCE_MEM,
+		.name	= rtc_name,
+		.parent	= &resource_cfg_root,
+		.start	= DM365_RTC_BASE,
+		.end	= DM365_RTC_BASE + SZ_1K - 1,
+		.flags	= IORESOURCE_MEM,
 	},
 	{
-		.start = IRQ_DM365_RTCINT,
-		.flags = IORESOURCE_IRQ,
+		.name = rtc_name,
+		.parent	= &resource_irq_root,
+		.start	= IRQ_DM365_RTCINT,
+		.end	= IRQ_DM365_RTCINT,
+		.flags	= IORESOURCE_IRQ,
 	},
 };
 
 static struct platform_device dm365_rtc_device = {
-	.name = "rtc_davinci",
+	.name = rtc_name,
 	.id = 0,
 	.num_resources = ARRAY_SIZE(dm365_rtc_resources),
 	.resource = dm365_rtc_resources,
@@ -1213,23 +1387,29 @@ static struct map_desc dm365_io_desc[] = {
 	},
 };
 
+static const char ks_name[] = "davinci_keyscan";
+
 static struct resource dm365_ks_resources[] = {
 	{
 		/* registers */
-		.start = DM365_KEYSCAN_BASE,
-		.end = DM365_KEYSCAN_BASE + SZ_1K - 1,
-		.flags = IORESOURCE_MEM,
+		.name	= ks_name,
+		.parent	= &resource_cfg_root,
+		.start	= DM365_KEYSCAN_BASE,
+		.end	= DM365_KEYSCAN_BASE + SZ_1K - 1,
+		.flags	= IORESOURCE_MEM,
 	},
 	{
 		/* interrupt */
-		.start = IRQ_DM365_KEYINT,
-		.end = IRQ_DM365_KEYINT,
-		.flags = IORESOURCE_IRQ,
+		.start	= IRQ_DM365_KEYINT,
+		.parent	= &resource_irq_root,
+		.start	= IRQ_DM365_KEYINT,
+		.end	= IRQ_DM365_KEYINT,
+		.flags	= IORESOURCE_IRQ,
 	},
 };
 
 static struct platform_device dm365_ks_device = {
-	.name		= "davinci_keyscan",
+	.name		= ks_name,
 	.id		= 0,
 	.num_resources	= ARRAY_SIZE(dm365_ks_resources),
 	.resource	= dm365_ks_resources,
@@ -1257,7 +1437,7 @@ static void __iomem *dm365_psc_bases[] = {
 	IO_ADDRESS(DAVINCI_PWR_SLEEP_CNTRL_BASE),
 };
 
-struct davinci_timer_info dm365_timer_info = {
+static struct davinci_timer_info dm365_timer_info = {
 	.timers		= davinci_timer_instance,
 	.clockevent_id	= T0_BOT,
 	.clocksource_id	= T0_TOP,
@@ -1331,7 +1511,8 @@ void __init dm365_init_asp(struct snd_platform_data *pdata)
 	davinci_cfg_reg(DM365_EVT2_ASP_TX);
 	davinci_cfg_reg(DM365_EVT3_ASP_RX);
 	dm365_asp_device.dev.platform_data = pdata;
-	platform_device_register(&dm365_asp_device);
+	if (!alloc_platform_resources(&dm365_asp_device))
+		platform_device_register(&dm365_asp_device);
 }
 
 void __init dm365_init_ks(struct davinci_ks_platform_data *pdata)
@@ -1343,7 +1524,8 @@ void __init dm365_init_ks(struct davinci_ks_platform_data *pdata)
 void __init dm365_init_rtc(void)
 {
 	davinci_cfg_reg(DM365_INT_PRTCSS);
-	platform_device_register(&dm365_rtc_device);
+	if (!alloc_platform_resources(&dm365_rtc_device))
+		platform_device_register(&dm365_rtc_device);
 }
 
 void __init dm365_init(void)
@@ -1351,17 +1533,21 @@ void __init dm365_init(void)
 	davinci_common_init(&davinci_soc_info_dm365);
 }
 
+static const char vpss_name[] = "vpss";
+
 static struct resource dm365_vpss_resources[] = {
 	{
 		/* VPSS ISP5 Base address */
-		.name           = "vpss",
+		.name           = vpss_name,
+		.parent		= &resource_cfg_root,
 		.start          = 0x01c70000,
 		.end            = 0x01c70000 + 0xff,
 		.flags          = IORESOURCE_MEM,
 	},
 	{
 		/* VPSS CLK Base address */
-		.name           = "vpss",
+		.name           = vpss_name,
+		.parent		= &resource_cfg_root,
 		.start          = 0x01c70200,
 		.end            = 0x01c70200 + 0xff,
 		.flags          = IORESOURCE_MEM,
@@ -1369,20 +1555,26 @@ static struct resource dm365_vpss_resources[] = {
 };
 
 static struct platform_device dm365_vpss_device = {
-       .name                   = "vpss",
+       .name                   = vpss_name,
        .id                     = -1,
        .dev.platform_data      = "dm365_vpss",
        .num_resources          = ARRAY_SIZE(dm365_vpss_resources),
        .resource               = dm365_vpss_resources,
 };
 
+static const char cptr_name[] = CAPTURE_DRV_NAME;
+
 static struct resource vpfe_resources[] = {
 	{
+		.name		= cptr_name,
+		.parent		= &resource_irq_root,
 		.start          = IRQ_VDINT0,
 		.end            = IRQ_VDINT0,
 		.flags          = IORESOURCE_IRQ,
 	},
 	{
+		.name		= cptr_name,
+		.parent		= &resource_irq_root,
 		.start          = IRQ_VDINT1,
 		.end            = IRQ_VDINT1,
 		.flags          = IORESOURCE_IRQ,
@@ -1391,7 +1583,7 @@ static struct resource vpfe_resources[] = {
 
 static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
 static struct platform_device vpfe_capture_dev = {
-	.name           = CAPTURE_DRV_NAME,
+	.name           = cptr_name,
 	.id             = -1,
 	.num_resources  = ARRAY_SIZE(vpfe_resources),
 	.resource       = vpfe_resources,
@@ -1401,28 +1593,36 @@ static struct platform_device vpfe_capture_dev = {
 	},
 };
 
+static const char isif_name[] = "dm365_isif";
+
 static struct resource isif_resource[] = {
 	/* ISIF Base address */
 	{
+		.name		= isif_name,
+		.parent		= &resource_cfg_root,
 		.start          = 0x01c71000,
 		.end            = 0x01c71000 + 0x1ff,
 		.flags          = IORESOURCE_MEM,
 	},
 	/* ISIF Linearization table 0 */
 	{
+		.name		= isif_name,
+		.parent		= &resource_cfg_root,
 		.start          = 0x1C7C000,
 		.end            = 0x1C7C000 + 0x2ff,
 		.flags          = IORESOURCE_MEM,
 	},
 	/* ISIF Linearization table 1 */
 	{
+		.name		= isif_name,
+		.parent		= &resource_cfg_root,
 		.start          = 0x1C7C400,
 		.end            = 0x1C7C400 + 0x2ff,
 		.flags          = IORESOURCE_MEM,
 	},
 };
 static struct platform_device dm365_isif_dev = {
-	.name           = "dm365_isif",
+	.name           = isif_name,
 	.id             = -1,
 	.num_resources  = ARRAY_SIZE(isif_resource),
 	.resource       = isif_resource,
@@ -1437,24 +1637,35 @@ static int __init dm365_init_devices(void)
 	if (!cpu_is_davinci_dm365())
 		return 0;
 
+	if (request_resource(&iomem_resource, &resource_cfg_root))
+		BUG();
+
 	davinci_cfg_reg(DM365_INT_EDMA_CC);
-	platform_device_register(&dm365_edma_device);
-	platform_device_register(&dm365_emac_device);
+	if (!alloc_platform_resources(&dm365_edma_device))
+		platform_device_register(&dm365_edma_device);
+	if (!alloc_platform_resources(&dm365_emac_device))
+		platform_device_register(&dm365_emac_device);
 
 	/*
 	* setup Mux configuration for vpfe input and register
 	* vpfe capture platform device
 	*/
-	platform_device_register(&dm365_vpss_device);
-	platform_device_register(&dm365_ipipeif_dev);
-	platform_device_register(&dm365_isif_dev);
-	platform_device_register(&vpfe_capture_dev);
+	if (!alloc_platform_resources(&dm365_vpss_device))
+		platform_device_register(&dm365_vpss_device);
+	if (!alloc_platform_resources(&dm365_ipipeif_dev))
+		platform_device_register(&dm365_ipipeif_dev);
+	if (!alloc_platform_resources(&dm365_isif_dev))
+		platform_device_register(&dm365_isif_dev);
+	if (!alloc_platform_resources(&vpfe_capture_dev))
+		platform_device_register(&vpfe_capture_dev);
 
 	/* Register OSD device */
-	platform_device_register(&dm365_osd_dev);
+	if (!alloc_platform_resources(&dm365_osd_dev))
+		platform_device_register(&dm365_osd_dev);
 
 	/* Register VENC device */
-	platform_device_register(&dm365_venc_dev);
+	if (!alloc_platform_resources(&dm365_venc_dev))
+		platform_device_register(&dm365_venc_dev);
 
 	return 0;
 }
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 5cd48fa..8abc707 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -1430,14 +1430,6 @@ static int __init edma_probe(struct platform_device *pdev)
 			found = 1;
 
 		len[j] = resource_size(r[j]);
-
-		r[j] = request_mem_region(r[j]->start, len[j],
-			dev_name(&pdev->dev));
-		if (!r[j]) {
-			status = -EBUSY;
-			goto fail1;
-		}
-
 		edmacc_regs_base[j] = ioremap(r[j]->start, len[j]);
 		if (!edmacc_regs_base[j]) {
 			status = -EBUSY;
diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h
index 3d2a823..2cd1134 100644
--- a/arch/arm/mach-davinci/include/mach/dm365.h
+++ b/arch/arm/mach-davinci/include/mach/dm365.h
@@ -14,6 +14,7 @@
 #define __ASM_ARCH_DM665_H
 
 #include <linux/platform_device.h>
+#include <linux/ioport.h>
 #include <mach/hardware.h>
 #include <media/davinci/vpfe_capture.h>
 #include <mach/emac.h>
@@ -33,6 +34,13 @@
 /* Base of key scan register bank */
 #define DM365_KEYSCAN_BASE		(0x01C69400)
 
+/* Root resources */
+extern struct resource
+	resource_cfg_root,
+	resource_dma_root,
+	resource_irq_root,
+	resource_evq_root;
+
 void __init dm365_init(void);
 void __init dm365_init_asp(struct snd_platform_data *pdata);
 void __init dm365_init_rtc(void);
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 67d88cc..4327ad9 100755
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -520,7 +520,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
 {
 	struct davinci_i2c_dev *dev;
 	struct i2c_adapter *adap;
-	struct resource *mem, *irq, *ioarea;
+	struct resource *mem, *irq;
 	int r;
 
 	/* NOTE: driver uses the static register mapping */
@@ -536,13 +536,6 @@ static int davinci_i2c_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
-	ioarea = request_mem_region(mem->start, resource_size(mem),
-				    pdev->name);
-	if (!ioarea) {
-		dev_err(&pdev->dev, "I2C region already claimed\n");
-		return -EBUSY;
-	}
-
 	dev = kzalloc(sizeof(struct davinci_i2c_dev), GFP_KERNEL);
 	if (!dev) {
 		r = -ENOMEM;
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 1bf0587..cf69c2e 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -1183,9 +1183,7 @@ static int __init davinci_mmcsd_probe(struct platform_device *pdev)
 
 	ret = -EBUSY;
 	mem_size = resource_size(r);
-	mem = request_mem_region(r->start, mem_size, pdev->name);
-	if (!mem)
-		goto out;
+	mem = r;
 
 	ret = -ENOMEM;
 	mmc = mmc_alloc_host(sizeof(struct mmc_davinci_host), &pdev->dev);
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 02e1a76..a5211d8 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -874,7 +874,7 @@ static irqreturn_t davinci_spi_irq(s32 irq, void *context_data)
 	return ret;
 }
 
-resource_size_t davinci_spi_get_dma_by_flag(struct platform_device *dev,
+static resource_size_t davinci_spi_get_dma_by_flag(struct platform_device *dev,
 		unsigned long flag)
 {
 	struct resource *r;
@@ -907,7 +907,7 @@ static int davinci_spi_probe(struct platform_device *pdev)
 	struct spi_master *master;
 	struct davinci_spi *davinci_spi;
 	struct davinci_spi_platform_data *pdata;
-	struct resource *r, *mem;
+	struct resource *r;
 	resource_size_t dma_rx_chan = DAVINCI_SPI_NO_RESOURCE;
 	resource_size_t	dma_tx_chan = DAVINCI_SPI_NO_RESOURCE;
 	resource_size_t	dma_eventq = DAVINCI_SPI_NO_RESOURCE;
@@ -942,19 +942,11 @@ static int davinci_spi_probe(struct platform_device *pdev)
 	davinci_spi->pbase = r->start;
 	davinci_spi->region_size = resource_size(r);
 	davinci_spi->pdata = pdata;
-
-	mem = request_mem_region(r->start, davinci_spi->region_size,
-					pdev->name);
-	if (mem == NULL) {
-		ret = -EBUSY;
-		goto free_master;
-	}
-
 	davinci_spi->base = (struct davinci_spi_reg __iomem *)
 			ioremap(r->start, davinci_spi->region_size);
 	if (davinci_spi->base == NULL) {
 		ret = -ENOMEM;
-		goto release_region;
+		goto free_master;
 	}
 
 	davinci_spi->irq = platform_get_irq(pdev, 0);
@@ -1094,8 +1086,6 @@ err1:
 	free_irq(davinci_spi->irq, davinci_spi);
 unmap_io:
 	iounmap(davinci_spi->base);
-release_region:
-	release_mem_region(davinci_spi->pbase, davinci_spi->region_size);
 free_master:
 	kfree(master);
 err:
-- 
1.7.0.3


From pan at nt.tu-darmstadt.de  Thu Apr  8 10:14:10 2010
From: pan at nt.tu-darmstadt.de (Vladimir Pantelic)
Date: Thu, 08 Apr 2010 17:14:10 +0200
Subject: DM355 CPU overload+alaw+gstreamer
In-Reply-To: <x2t90d17c5d1004080734i1878be4fg96717b20aec33e6f@mail.gmail.com>
References: <x2t90d17c5d1004080734i1878be4fg96717b20aec33e6f@mail.gmail.com>
Message-ID: <4BBDF2C2.1020202@nt.tu-darmstadt.de>

Idriss Ghodhbane wrote:
>   Hi everybody,
>
> I am using the DM355 evm and I am working on streaming audio between two
> DM355.
>
> I have integrated the Alaw codec in the gstreamer because I haven't any
> TI audio codec included in my evm DM355.
>
> Despite the Alaw codec doesn't do compression or decompression, the CPU
> is overloaded, about 98% when I launched the audio encoding or decoding
>
> via the gstreamer's pipelines.
>
> Can you help me solving this problem ?

what does oprofile tell you about where all that CPU is spent?


From idriss.ghodhbane at gmail.com  Thu Apr  8 12:18:39 2010
From: idriss.ghodhbane at gmail.com (Idriss Ghodhbane)
Date: Thu, 8 Apr 2010 19:18:39 +0200
Subject: Davinci-linux-open-source Digest, Vol 52, Issue 28
In-Reply-To: <mailman.1.1270746000.2437.davinci-linux-open-source@linux.davincidsp.com>
References: <mailman.1.1270746000.2437.davinci-linux-open-source@linux.davincidsp.com>
Message-ID: <o2j90d17c5d1004081018w557c888qc4cf00d4b4b1e6c2@mail.gmail.com>

Hi Vladimir,

Thanks for your reply.
I used the command  "top" to discover the CPU overload.
Concerning Oprofile, I don't know how to use it on my DM355 EVM.
I will be grateful if you tell me more details.
Thanks in advance.

Regards

2010/4/8 <davinci-linux-open-source-request at linux.davincidsp.com>

> Send Davinci-linux-open-source mailing list submissions to
>        davinci-linux-open-source at linux.davincidsp.com
>
> 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
>        davinci-linux-open-source-request at linux.davincidsp.com
>
> You can reach the person managing the list at
>        davinci-linux-open-source-owner at linux.davincidsp.com
>
> 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. Re: DM355 CPU overload+alaw+gstreamer (Vladimir Pantelic)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 08 Apr 2010 17:14:10 +0200
> From: Vladimir Pantelic <pan at nt.tu-darmstadt.de>
> To: davinci-linux-open-source at linux.davincidsp.com
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Subject: Re: DM355 CPU overload+alaw+gstreamer
> Message-ID: <4BBDF2C2.1020202 at nt.tu-darmstadt.de>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Idriss Ghodhbane wrote:
> >   Hi everybody,
> >
> > I am using the DM355 evm and I am working on streaming audio between two
> > DM355.
> >
> > I have integrated the Alaw codec in the gstreamer because I haven't any
> > TI audio codec included in my evm DM355.
> >
> > Despite the Alaw codec doesn't do compression or decompression, the CPU
> > is overloaded, about 98% when I launched the audio encoding or decoding
> >
> > via the gstreamer's pipelines.
> >
> > Can you help me solving this problem ?
>
> what does oprofile tell you about where all that CPU is spent?
>
>
>
> ------------------------------
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>
> End of Davinci-linux-open-source Digest, Vol 52, Issue 28
> *********************************************************
>



-- 
IDRISS GHODHBANE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100408/d9ac8d4e/attachment.html>

From albertbu at gmail.com  Fri Apr  9 04:16:55 2010
From: albertbu at gmail.com (Albert Burbea)
Date: Fri, 9 Apr 2010 11:16:55 +0200
Subject: DM355 CPU overload+alaw+gstreamer
In-Reply-To: <4BBDF2C2.1020202@nt.tu-darmstadt.de>
References: <x2t90d17c5d1004080734i1878be4fg96717b20aec33e6f@mail.gmail.com>
	<4BBDF2C2.1020202@nt.tu-darmstadt.de>
Message-ID: <q2zb0389af41004090216l953a9e34g10a6ca14063778a6@mail.gmail.com>

Hi
how do you use oprofile?
Albert

On Thu, Apr 8, 2010 at 5:14 PM, Vladimir Pantelic <pan at nt.tu-darmstadt.de>wrote:

>  Idriss Ghodhbane wrote:
>
>>  Hi everybody,
>>
>> I am using the DM355 evm and I am working on streaming audio between two
>> DM355.
>>
>> I have integrated the Alaw codec in the gstreamer because I haven't any
>> TI audio codec included in my evm DM355.
>>
>> Despite the Alaw codec doesn't do compression or decompression, the CPU
>> is overloaded, about 98% when I launched the audio encoding or decoding
>>
>> via the gstreamer's pipelines.
>>
>> Can you help me solving this problem ?
>>
>
>  what does oprofile tell you about where all that CPU is spent?
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>



-- 
Albert Burbea
Harishonim 8
Ramat Gan 52502, Israel
Tel/Fax + 972-3-7526016
Mobile: +972-52-3541842
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100409/b0c72743/attachment.html>

From pratik.joshi at einfochips.com  Fri Apr  9 08:00:31 2010
From: pratik.joshi at einfochips.com (Pratik Joshi)
Date: Fri, 9 Apr 2010 18:30:31 +0530
Subject: USB mass storage not detected in 2.6.32 kernel
Message-ID: <004501cad7e4$a4dbe430$ee93ac90$@joshi@einfochips.com>

Hi All,

 

I am migrating from 2.6.10 kernel to 2.6.32 kernel for DM6446 platform. I
took a kernel from www.kernel.org version 2.6.32.11. 

 

Problem statement:

 

I have configured USB in new kernel for mass storage and I have also enabled
scsi module. To my knowledge I have done all configuration in kernel to
enabled USB mass storage. But somehow it seems USB driver is not included in
the kernel image. On issuing "lsusb" command on the prompt yields nothing.
Can anyone throw a light on issue that I am facing?

 

Regards,

Pratik Joshi

 


-- 
_____________________________________________________________________
Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution, copying, or other use of
this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
replying to this message and please delete it from your computer. Any
views expressed in this message are those of the individual sender
unless otherwise stated.Company has taken enough precautions to prevent
the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email.
_____________________________________________________________________
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100409/b7c715d5/attachment.html>

From viral at allaboutif.com  Fri Apr  9 08:13:48 2010
From: viral at allaboutif.com (Viral Sachde)
Date: Fri, 9 Apr 2010 18:43:48 +0530
Subject: USB mass storage not detected in 2.6.32 kernel
In-Reply-To: <8278439946330628762@unknownmsgid>
References: <8278439946330628762@unknownmsgid>
Message-ID: <x2wb002f1321004090613j65f85bccuc0104dd23fdc3996@mail.gmail.com>

On Fri, Apr 9, 2010 at 6:30 PM, Pratik Joshi
<pratik.joshi at einfochips.com> wrote:
> Hi All,
> I am migrating from 2.6.10 kernel to 2.6.32 kernel for DM6446 platform. I
> took a kernel from www.kernel.org version 2.6.32.11.
> Problem statement:
> I have configured USB in new kernel for mass storage and I have also enabled
> scsi module. To my knowledge I have done all configuration in kernel to
> enabled USB mass storage. But somehow it seems USB driver is not included in
> the kernel image. On issuing ?lsusb? command on the prompt yields nothing.
> Can anyone throw a light on issue that I am facing?
> Regards,
> Pratik Joshi

I assume your file system is mounting procfs & usbfs. If not mount them.
Can you check /proc/bus/usb/ directory and file "devices" inside it.
Send devices file here to start with.

Regards, Viral

From cyril at ti.com  Fri Apr  9 11:52:44 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri,  9 Apr 2010 12:52:44 -0400
Subject: [PATCH] Davinci: iotable based ioremap() interception
Message-ID: <1270831964-22661-1-git-send-email-cyril@ti.com>

This patch allows for a more flexible ioremap() interception.  The mechanism
works by translating physical addresses based on soc-specific iotable
contents (davinci_soc_info.io_desc), once davinci_soc_info is populated by
davinci_common_init().

This change has been tested on dm365 and dm355 by Sandeep.  With additional
changes (not included here), this was also tested on tnetv107x.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/da830.c           |    7 +++++-
 arch/arm/mach-davinci/da850.c           |    9 ++++++-
 arch/arm/mach-davinci/include/mach/io.h |    4 +++
 arch/arm/mach-davinci/io.c              |   33 +++++++++++++++++++++++++++---
 4 files changed, 46 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 122e61a..168f277 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1206,9 +1206,14 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
 	.emac_pdata		= &da8xx_emac_pdata,
 };
 
+#define da830_early_ioremap(p, s)				\
+	__davinci_ioremap(p, s,					\
+			davinci_soc_info_da830.io_desc,		\
+			davinci_soc_info_da830.io_desc_num)
+
 void __init da830_init(void)
 {
-	da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
+	da8xx_syscfg0_base = da830_early_ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
 	if (WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module"))
 		return;
 
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index d0fd756..27eb32e 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1093,15 +1093,20 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.sram_len		= SZ_8K,
 };
 
+#define da850_early_ioremap(p, s)				\
+	__davinci_ioremap(p, s,					\
+			davinci_soc_info_da850.io_desc,		\
+			davinci_soc_info_da850.io_desc_num)
+
 void __init da850_init(void)
 {
 	unsigned int v;
 
-	da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
+	da8xx_syscfg0_base = da850_early_ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
 	if (WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module"))
 		return;
 
-	da8xx_syscfg1_base = ioremap(DA8XX_SYSCFG1_BASE, SZ_4K);
+	da8xx_syscfg1_base = da850_early_ioremap(DA8XX_SYSCFG1_BASE, SZ_4K);
 	if (WARN(!da8xx_syscfg1_base, "Unable to map syscfg1 module"))
 		return;
 
diff --git a/arch/arm/mach-davinci/include/mach/io.h b/arch/arm/mach-davinci/include/mach/io.h
index 62b0a90..4aa301c 100644
--- a/arch/arm/mach-davinci/include/mach/io.h
+++ b/arch/arm/mach-davinci/include/mach/io.h
@@ -25,6 +25,10 @@
 #define __arch_ioremap(p, s, t)	davinci_ioremap(p, s, t)
 #define __arch_iounmap(v)	davinci_iounmap(v)
 
+struct map_desc;
+
+void __iomem *__davinci_ioremap(unsigned long p, size_t size,
+		struct map_desc *io_desc, int io_desc_num);
 void __iomem *davinci_ioremap(unsigned long phys, size_t size,
 			      unsigned int type);
 void davinci_iounmap(volatile void __iomem *addr);
diff --git a/arch/arm/mach-davinci/io.c b/arch/arm/mach-davinci/io.c
index a1c0b6b..3a62f14 100644
--- a/arch/arm/mach-davinci/io.c
+++ b/arch/arm/mach-davinci/io.c
@@ -12,17 +12,42 @@
 #include <linux/io.h>
 
 #include <asm/tlb.h>
+#include <asm/mach/map.h>
 
-#define BETWEEN(p, st, sz)	((p) >= (st) && (p) < ((st) + (sz)))
-#define XLATE(p, pst, vst)	((void __iomem *)((p) - (pst) + (vst)))
+#include <mach/common.h>
+
+/*
+ * Remap io addresses based on a soc-specific io-descriptor table. This is
+ * useful in early arch init code before davinci_common_init().  After
+ * davinci_common_init(), regular ioremap() calls should be used.
+ */
+void __iomem *__davinci_ioremap(unsigned long p, size_t size,
+		struct map_desc *io_desc, int io_desc_num)
+{
+	int i;
+
+	for (i = 0; i < io_desc_num; i++, io_desc++) {
+		unsigned long iophys = __pfn_to_phys(io_desc->pfn);
+		unsigned long iosize = io_desc->length;
+
+		if (p >= iophys && (p + size) <= (iophys + iosize))
+			return __io(io_desc->virtual + p - iophys);
+	}
+
+	return NULL;
+}
 
 /*
  * Intercept ioremap() requests for addresses in our fixed mapping regions.
  */
 void __iomem *davinci_ioremap(unsigned long p, size_t size, unsigned int type)
 {
-	if (BETWEEN(p, IO_PHYS, IO_SIZE))
-		return XLATE(p, IO_PHYS, IO_VIRT);
+	void __iomem *ret;
+
+	ret = __davinci_ioremap(p, size, davinci_soc_info.io_desc,
+			davinci_soc_info.io_desc_num);
+	if (ret)
+		return ret;
 
 	return __arm_ioremap_caller(p, size, type, __builtin_return_address(0));
 }
-- 
1.6.3.3


From pan at nt.tu-darmstadt.de  Fri Apr  9 13:54:23 2010
From: pan at nt.tu-darmstadt.de (Vladimir Pantelic)
Date: Fri, 09 Apr 2010 20:54:23 +0200
Subject: DM355 CPU overload+alaw+gstreamer
In-Reply-To: <q2zb0389af41004090216l953a9e34g10a6ca14063778a6@mail.gmail.com>
References: <x2t90d17c5d1004080734i1878be4fg96717b20aec33e6f@mail.gmail.com>	
	<4BBDF2C2.1020202@nt.tu-darmstadt.de>
	<q2zb0389af41004090216l953a9e34g10a6ca14063778a6@mail.gmail.com>
Message-ID: <4BBF77DF.4000101@nt.tu-darmstadt.de>

Albert Burbea wrote:
> Hi
> how do you use oprofile?

what does google say?

> Albert
> 
> On Thu, Apr 8, 2010 at 5:14 PM, Vladimir Pantelic
> <pan at nt.tu-darmstadt.de <mailto:pan at nt.tu-darmstadt.de>> wrote:
> 
>     Idriss Ghodhbane wrote:
> 
>          Hi everybody,
> 
>         I am using the DM355 evm and I am working on streaming audio
>         between two
>         DM355.
> 
>         I have integrated the Alaw codec in the gstreamer because I
>         haven't any
>         TI audio codec included in my evm DM355.
> 
>         Despite the Alaw codec doesn't do compression or decompression,
>         the CPU
>         is overloaded, about 98% when I launched the audio encoding or
>         decoding
> 
>         via the gstreamer's pipelines.
> 
>         Can you help me solving this problem ?
> 
> 
>     what does oprofile tell you about where all that CPU is spent?
> 
>     _______________________________________________
>     Davinci-linux-open-source mailing list
>     Davinci-linux-open-source at linux.davincidsp.com
>     <mailto:Davinci-linux-open-source at linux.davincidsp.com>
>     http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 
> 
> 
> 
> -- 
> Albert Burbea
> Harishonim 8
> Ramat Gan 52502, Israel
> Tel/Fax + 972-3-7526016
> Mobile: +972-52-3541842


From cyril at ti.com  Fri Apr  9 16:56:37 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 09 Apr 2010 17:56:37 -0400
Subject: [PATCH v2 15/16] Davinci: initial tnetv107x support
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E669976F@dbde02.ent.ti.com>
References: <1269553439-14886-1-git-send-email-cyril@ti.com>
	<1269553439-14886-2-git-send-email-cyril@ti.com>
	<1269553439-14886-3-git-send-email-cyril@ti.com>
	<1269553439-14886-4-git-send-email-cyril@ti.com>
	<1269553439-14886-5-git-send-email-cyril@ti.com>
	<1269553439-14886-6-git-send-email-cyril@ti.com>
	<1269553439-14886-7-git-send-email-cyril@ti.com>
	<1269553439-14886-8-git-send-email-cyril@ti.com>
	<1269553439-14886-9-git-send-email-cyril@ti.com>
	<1269553439-14886-10-git-send-email-cyril@ti.com>
	<1269553439-14886-11-git-send-email-cyril@ti.com>
	<1269553439-14886-12-git-send-email-cyril@ti.com>
	<1269553439-14886-13-git-send-email-cyril@ti.com>
	<1269553439-14886-14-git-send-email-cyril@ti.com>
	<1269553439-14886-15-git-send-email-cyril@ti.com>
	<1269553439-14886-16-git-send-email-cyril@ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E669976F@dbde02.ent.ti.com>
Message-ID: <4BBFA295.5010007@ti.com>

Sekhar,

> > +struct platform_device davinci_wdt_device = {
> > +	.name		= "watchdog",
> > +	.id		= -1,
> > +	.num_resources	= ARRAY_SIZE(wdt_resources),
> > +	.resource	= wdt_resources,
> > +};
> 
> IMO, a better way to overcome the 'no watchdog timer'
> limitation would be to make the watchdog reset code
> not use the wdt platform data directly, but instead
> 'search' for watchdog device using bus_for_each_dev()
> iterator on platform bus.
> 
> In your case, the watchdog device wouldn't be found
> and the reset function should exist gracefully.

I realize that I agreed to your viewpoint earlier, but I see a problem 
with this approach.  If an arch_reset() were to somehow get triggered in 
early boot (e.g. via panic()), the watchdog device may not have been 
registered yet.

Any thoughts on how to approach this situation?

Regards
Cyril.

From michael.williamson at criticallink.com  Sun Apr 11 09:55:49 2010
From: michael.williamson at criticallink.com (Mike Williamson)
Date: Sun, 11 Apr 2010 10:55:49 -0400
Subject: SPI Support for DA850 (OMAPL-138).
Message-ID: <p2p763e54b1004110755u701c9e5ek3c9cc29320c733c5@mail.gmail.com>

Hi,

I've been working with Kevin's tree and have been having some problems
with the SPI interface for the DA850 (OMAP-L138), SPI version 2.

I am getting a lot of failures in the davinci_spi_check_error routine
that I'm not sure are real errors.? I was googling around and found
this thread:

http://linux.omap.com/pipermail/davinci-linux-open-source/2009-July/015025.html

The thread raises the same issue that I have found in that the routine
is declaring an error if the status of the SPI engine is claiming that
the Tx buffer is empty (SPIFLG_TX_INTR_MASK) and there is also a check
on a bit  (SPIFLG_BUF_INIT_ACTIVE_MASK, bit 24) that is undocumented
in the SPI user guide.  I found that I had to turn off both of these
checks in order for the SPI to work with our device in polled mode
with no DMAs.    The device is an m25p64 EEPROM, same configuration as
on the 850 / OMAPL138 evm.

Can anyone confirm if the spi implementation in Kevin's tree is
working for VERSION_2 SPI devices (850 specifically), and what SPI
configuration you're using?

I am also wondering if the SPI patches from Brian Niebuhr have died on
the wire (http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-March/018077.html).
 It seemed like he had identified several issues with the driver and
had taken a crack at sorting them out.

-Mike




--
Michael Williamson
315-425-4045x230
www.criticallink.com

From martin at ti.com  Sun Apr 11 12:34:14 2010
From: martin at ti.com (martin at ti.com)
Date: Sun, 11 Apr 2010 12:34:14 -0500
Subject: [Resubmit: PATCH v3 0/1] DA8XX/OMAP-L1XX: FB: Implement double
	buffering
Message-ID: <1271007255-3401-1-git-send-email-martin@ti.com>

From: Martin Ambrose <martin at ti.com>

Changes from v2 patch set:
        . Fixed register clear sequence in isr to avoid spurious interrupt.
        . Removed unused wait queue variable in wait_for_vsync().
        . Moved initialization of vsync_wait prior to register_framebuffer.
  

 drivers/video/da8xx-fb.c |  301 +++++++++++++++++++++++++++++++++++----------
 include/video/da8xx-fb.h |    1 +
 2 files changed, 235 insertions(+), 67 deletions(-)


From martin at ti.com  Sun Apr 11 12:34:15 2010
From: martin at ti.com (martin at ti.com)
Date: Sun, 11 Apr 2010 12:34:15 -0500
Subject: [Resubmit: PATCH v3 1/1] DA8XX/OMAP-L1XX: FB: Implement double
	buffering
In-Reply-To: <1271007255-3401-1-git-send-email-martin@ti.com>
References: <1271007255-3401-1-git-send-email-martin@ti.com>
Message-ID: <1271007255-3401-2-git-send-email-martin@ti.com>

From: Martin Ambrose <martin at ti.com>

 This work includes the following:
 . Implement handler for FBIO_WAITFORVSYNC ioctl.

 . Allocate the data and palette buffers separately.
   A consequence of this is that the palette and data loading is now
   done in different phases. And that the LCD must be disabled
   temporarily after the palette is loaded but this will only happen
   once after init and each time the palette is changed. I think this
   is OK.

 . Allocate two (ping and pong) framebuffers from memory.

 . Add pan_display handler which toggles the LCDC DMA registers between
   the ping and pong buffers.

Signed-off-by: Martin Ambrose <martin at ti.com>
---
 drivers/video/da8xx-fb.c |  301 +++++++++++++++++++++++++++++++++++----------
 include/video/da8xx-fb.h |    1 +
 2 files changed, 235 insertions(+), 67 deletions(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 8d244ba..cad7d45 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -36,7 +36,9 @@
 #define DRIVER_NAME "da8xx_lcdc"
 
 /* LCD Status Register */
+#define LCD_END_OF_FRAME1		BIT(9)
 #define LCD_END_OF_FRAME0		BIT(8)
+#define LCD_PL_LOAD_DONE		BIT(6)
 #define LCD_FIFO_UNDERFLOW		BIT(5)
 #define LCD_SYNC_LOST			BIT(2)
 
@@ -58,11 +60,13 @@
 #define LCD_PALETTE_LOAD_MODE(x)	((x) << 20)
 #define PALETTE_AND_DATA		0x00
 #define PALETTE_ONLY			0x01
+#define DATA_ONLY			0x02
 
 #define LCD_MONO_8BIT_MODE		BIT(9)
 #define LCD_RASTER_ORDER		BIT(8)
 #define LCD_TFT_MODE			BIT(7)
 #define LCD_UNDERFLOW_INT_ENA		BIT(6)
+#define LCD_PL_ENABLE			BIT(4)
 #define LCD_MONOCHROME_MODE		BIT(1)
 #define LCD_RASTER_ENABLE		BIT(0)
 #define LCD_TFT_ALT_ENABLE		BIT(23)
@@ -87,6 +91,10 @@
 #define  LCD_DMA_CTRL_REG			0x40
 #define  LCD_DMA_FRM_BUF_BASE_ADDR_0_REG	0x44
 #define  LCD_DMA_FRM_BUF_CEILING_ADDR_0_REG	0x48
+#define  LCD_DMA_FRM_BUF_BASE_ADDR_1_REG	0x4C
+#define  LCD_DMA_FRM_BUF_CEILING_ADDR_1_REG	0x50
+
+#define LCD_NUM_BUFFERS	2
 
 #define WSI_TIMEOUT	50
 #define PALETTE_SIZE	256
@@ -111,13 +119,20 @@ static inline void lcdc_write(unsigned int val, unsigned int addr)
 struct da8xx_fb_par {
 	resource_size_t p_palette_base;
 	unsigned char *v_palette_base;
+	dma_addr_t		vram_phys;
+	unsigned long		vram_size;
+	void			*vram_virt;
+	unsigned int		dma_start;
+	unsigned int		dma_end;
 	struct clk *lcdc_clk;
 	int irq;
 	unsigned short pseudo_palette[16];
-	unsigned int databuf_sz;
 	unsigned int palette_sz;
 	unsigned int pxl_clk;
 	int blank;
+	wait_queue_head_t	vsync_wait;
+	int			vsync_flag;
+	int			vsync_timeout;
 #ifdef CONFIG_CPU_FREQ
 	struct notifier_block	freq_transition;
 #endif
@@ -148,9 +163,9 @@ static struct fb_fix_screeninfo da8xx_fb_fix __devinitdata = {
 	.type = FB_TYPE_PACKED_PIXELS,
 	.type_aux = 0,
 	.visual = FB_VISUAL_PSEUDOCOLOR,
-	.xpanstep = 1,
+	.xpanstep = 0,
 	.ypanstep = 1,
-	.ywrapstep = 1,
+	.ywrapstep = 0,
 	.accel = FB_ACCEL_NONE
 };
 
@@ -221,22 +236,48 @@ static inline void lcd_disable_raster(void)
 
 static void lcd_blit(int load_mode, struct da8xx_fb_par *par)
 {
-	u32 tmp = par->p_palette_base + par->databuf_sz - 4;
-	u32 reg;
+	u32 start;
+	u32 end;
+	u32 reg_ras;
+	u32 reg_dma;
+
+	/* init reg to clear PLM (loading mode) fields */
+	reg_ras = lcdc_read(LCD_RASTER_CTRL_REG);
+	reg_ras &= ~(3 << 20);
+
+	reg_dma  = lcdc_read(LCD_DMA_CTRL_REG);
+
+	if (load_mode == LOAD_DATA) {
+		start    = par->dma_start;
+		end      = par->dma_end;
+
+		reg_ras |= LCD_PALETTE_LOAD_MODE(DATA_ONLY);
+		reg_dma |= LCD_END_OF_FRAME_INT_ENA;
+		reg_dma |= LCD_DUAL_FRAME_BUFFER_ENABLE;
+
+		lcdc_write(start, LCD_DMA_FRM_BUF_BASE_ADDR_0_REG);
+		lcdc_write(end, LCD_DMA_FRM_BUF_CEILING_ADDR_0_REG);
+		lcdc_write(start, LCD_DMA_FRM_BUF_BASE_ADDR_1_REG);
+		lcdc_write(end, LCD_DMA_FRM_BUF_CEILING_ADDR_1_REG);
+	} else if (load_mode == LOAD_PALETTE) {
+		start    = par->p_palette_base;
+		end      = start + par->palette_sz - 1;
+
+		reg_ras |= LCD_PALETTE_LOAD_MODE(PALETTE_ONLY);
+		reg_ras |= LCD_PL_ENABLE;
+
+		lcdc_write(start, LCD_DMA_FRM_BUF_BASE_ADDR_0_REG);
+		lcdc_write(end, LCD_DMA_FRM_BUF_CEILING_ADDR_0_REG);
+	}
 
-	/* Update the databuf in the hw. */
-	lcdc_write(par->p_palette_base, LCD_DMA_FRM_BUF_BASE_ADDR_0_REG);
-	lcdc_write(tmp, LCD_DMA_FRM_BUF_CEILING_ADDR_0_REG);
+	lcdc_write(reg_dma, LCD_DMA_CTRL_REG);
+	lcdc_write(reg_ras, LCD_RASTER_CTRL_REG);
 
-	/* Start the DMA. */
-	reg = lcdc_read(LCD_RASTER_CTRL_REG);
-	reg &= ~(3 << 20);
-	if (load_mode == LOAD_DATA)
-		reg |= LCD_PALETTE_LOAD_MODE(PALETTE_AND_DATA);
-	else if (load_mode == LOAD_PALETTE)
-		reg |= LCD_PALETTE_LOAD_MODE(PALETTE_ONLY);
-
-	lcdc_write(reg, LCD_RASTER_CTRL_REG);
+	/*
+	 * The Raster enable bit must be set after all other control fields are
+	 * set.
+	 */
+	lcd_enable_raster();
 }
 
 /* Configure the Burst Size of DMA */
@@ -368,12 +409,8 @@ static int lcd_cfg_display(const struct lcd_ctrl_config *cfg)
 static int lcd_cfg_frame_buffer(struct da8xx_fb_par *par, u32 width, u32 height,
 		u32 bpp, u32 raster_order)
 {
-	u32 bpl, reg;
+	u32 reg;
 
-	/* Disable Dual Frame Buffer. */
-	reg = lcdc_read(LCD_DMA_CTRL_REG);
-	lcdc_write(reg & ~LCD_DUAL_FRAME_BUFFER_ENABLE,
-						LCD_DMA_CTRL_REG);
 	/* Set the Panel Width */
 	/* Pixels per line = (PPL + 1)*16 */
 	/*0x3F in bits 4..9 gives max horisontal resolution = 1024 pixels*/
@@ -410,9 +447,6 @@ static int lcd_cfg_frame_buffer(struct da8xx_fb_par *par, u32 width, u32 height,
 		return -EINVAL;
 	}
 
-	bpl = width * bpp / 8;
-	par->databuf_sz = height * bpl + par->palette_sz;
-
 	return 0;
 }
 
@@ -421,8 +455,9 @@ static int fb_setcolreg(unsigned regno, unsigned red, unsigned green,
 			      struct fb_info *info)
 {
 	struct da8xx_fb_par *par = info->par;
-	unsigned short *palette = (unsigned short *)par->v_palette_base;
+	unsigned short *palette = (unsigned short *) par->v_palette_base;
 	u_short pal;
+	int update_hw = 0;
 
 	if (regno > 255)
 		return 1;
@@ -439,8 +474,10 @@ static int fb_setcolreg(unsigned regno, unsigned red, unsigned green,
 		pal |= (green & 0x00f0);
 		pal |= (blue & 0x000f);
 
-		palette[regno] = pal;
-
+		if (palette[regno] != pal) {
+			update_hw = 1;
+			palette[regno] = pal;
+		}
 	} else if ((info->var.bits_per_pixel == 16) && regno < 16) {
 		red >>= (16 - info->var.red.length);
 		red <<= info->var.red.offset;
@@ -453,9 +490,16 @@ static int fb_setcolreg(unsigned regno, unsigned red, unsigned green,
 
 		par->pseudo_palette[regno] = red | green | blue;
 
-		palette[0] = 0x4000;
+		if (palette[0] != 0x4000) {
+			update_hw = 1;
+			palette[0] = 0x4000;
+		}
 	}
 
+	/* Update the palette in the h/w as needed. */
+	if (update_hw)
+		lcd_blit(LOAD_PALETTE, par);
+
 	return 0;
 }
 
@@ -541,15 +585,54 @@ static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
 
 static irqreturn_t lcdc_irq_handler(int irq, void *arg)
 {
+	struct da8xx_fb_par *par = arg;
 	u32 stat = lcdc_read(LCD_STAT_REG);
+	u32 reg_ras;
 
 	if ((stat & LCD_SYNC_LOST) && (stat & LCD_FIFO_UNDERFLOW)) {
 		lcd_disable_raster();
 		lcdc_write(stat, LCD_STAT_REG);
 		lcd_enable_raster();
-	} else
+	} else if (stat & LCD_PL_LOAD_DONE) {
+		/*
+		 * Must disable raster before changing state of any control bit.
+		 * And also must be disabled before clearing the PL loading
+		 * interrupt via the following write to the status register. If
+		 * this is done after then one gets multiple PL done interrupts.
+		 */
+		lcd_disable_raster();
+
 		lcdc_write(stat, LCD_STAT_REG);
 
+		/* Disable PL completion inerrupt */
+		reg_ras  = lcdc_read(LCD_RASTER_CTRL_REG);
+		reg_ras &= ~LCD_PL_ENABLE;
+		lcdc_write(reg_ras, LCD_RASTER_CTRL_REG);
+
+		/* Setup and start data loading mode */
+		lcd_blit(LOAD_DATA, par);
+	} else {
+		lcdc_write(stat, LCD_STAT_REG);
+
+		if (stat & LCD_END_OF_FRAME0) {
+			lcdc_write(par->dma_start,
+				   LCD_DMA_FRM_BUF_BASE_ADDR_0_REG);
+			lcdc_write(par->dma_end,
+				   LCD_DMA_FRM_BUF_CEILING_ADDR_0_REG);
+			par->vsync_flag = 1;
+			wake_up_interruptible(&par->vsync_wait);
+		}
+
+		if (stat & LCD_END_OF_FRAME1) {
+			lcdc_write(par->dma_start,
+				   LCD_DMA_FRM_BUF_BASE_ADDR_1_REG);
+			lcdc_write(par->dma_end,
+				   LCD_DMA_FRM_BUF_CEILING_ADDR_1_REG);
+			par->vsync_flag = 1;
+			wake_up_interruptible(&par->vsync_wait);
+		}
+	}
+
 	return IRQ_HANDLED;
 }
 
@@ -654,9 +737,10 @@ static int __devexit fb_remove(struct platform_device *dev)
 
 		unregister_framebuffer(info);
 		fb_dealloc_cmap(&info->cmap);
-		dma_free_coherent(NULL, par->databuf_sz + PAGE_SIZE,
-					info->screen_base - PAGE_SIZE,
-					info->fix.smem_start);
+		dma_free_coherent(NULL, PALETTE_SIZE, par->v_palette_base,
+				  par->p_palette_base);
+		dma_free_coherent(NULL, par->vram_size, par->vram_virt,
+				  par->vram_phys);
 		free_irq(par->irq, par);
 		clk_disable(par->lcdc_clk);
 		clk_put(par->lcdc_clk);
@@ -668,6 +752,39 @@ static int __devexit fb_remove(struct platform_device *dev)
 	return 0;
 }
 
+/*
+ * Function to wait for vertical sync which for this LCD peripheral
+ * translates into waiting for the current raster frame to complete.
+ */
+static int fb_wait_for_vsync(struct fb_info *info)
+{
+	struct da8xx_fb_par *par = info->par;
+	int ret;
+
+	/*
+	 * Set flag to 0 and wait for isr to set to 1. It would seem there is a
+	 * race condition here where the ISR could have occured just before or
+	 * just after this set. But since we are just coarsely waiting for
+	 * a frame to complete then that's OK. i.e. if the frame completed
+	 * just before this code executed then we have to wait another full
+	 * frame time but there is no way to avoid such a situation. On the
+	 * other hand if the frame completed just after then we don't need
+	 * to wait long at all. Either way we are guaranteed to return to the
+	 * user immediately after a frame completion which is all that is
+	 * required.
+	 */
+	par->vsync_flag = 0;
+	ret = wait_event_interruptible_timeout(par->vsync_wait,
+					       par->vsync_flag != 0,
+					       par->vsync_timeout);
+	if (ret < 0)
+		return ret;
+	if (ret == 0)
+		return -ETIMEDOUT;
+
+	return 0;
+}
+
 static int fb_ioctl(struct fb_info *info, unsigned int cmd,
 			  unsigned long arg)
 {
@@ -697,6 +814,8 @@ static int fb_ioctl(struct fb_info *info, unsigned int cmd,
 					sync_arg.pulse_width,
 					sync_arg.front_porch);
 		break;
+	case FBIO_WAITFORVSYNC:
+		return fb_wait_for_vsync(info);
 	default:
 		return -EINVAL;
 	}
@@ -732,10 +851,47 @@ static int cfb_blank(int blank, struct fb_info *info)
 	return ret;
 }
 
+/*
+ * Set new x,y offsets in the virtual display for the visible area and switch
+ * to the new mode.
+ */
+static int da8xx_pan_display(struct fb_var_screeninfo *var,
+			     struct fb_info *fbi)
+{
+	int ret = 0;
+	struct fb_var_screeninfo new_var;
+	struct da8xx_fb_par         *par = fbi->par;
+	struct fb_fix_screeninfo    *fix = &fbi->fix;
+	unsigned int end;
+	unsigned int start;
+
+	if (var->xoffset != fbi->var.xoffset ||
+			var->yoffset != fbi->var.yoffset) {
+		memcpy(&new_var, &fbi->var, sizeof(new_var));
+		new_var.xoffset = var->xoffset;
+		new_var.yoffset = var->yoffset;
+		if (fb_check_var(&new_var, fbi))
+			ret = -EINVAL;
+		else {
+			memcpy(&fbi->var, &new_var, sizeof(new_var));
+
+			start	= fix->smem_start +
+				new_var.yoffset * fix->line_length +
+				new_var.xoffset * var->bits_per_pixel / 8;
+			end	= start + var->yres * fix->line_length - 1;
+			par->dma_start	= start;
+			par->dma_end	= end;
+		}
+	}
+
+	return ret;
+}
+
 static struct fb_ops da8xx_fb_ops = {
 	.owner = THIS_MODULE,
 	.fb_check_var = fb_check_var,
 	.fb_setcolreg = fb_setcolreg,
+	.fb_pan_display = da8xx_pan_display,
 	.fb_ioctl = fb_ioctl,
 	.fb_fillrect = cfb_fillrect,
 	.fb_copyarea = cfb_copyarea,
@@ -829,40 +985,53 @@ static int __init fb_probe(struct platform_device *device)
 	}
 
 	/* allocate frame buffer */
-	da8xx_fb_info->screen_base = dma_alloc_coherent(NULL,
-					par->databuf_sz + PAGE_SIZE,
-					(resource_size_t *)
-					&da8xx_fb_info->fix.smem_start,
-					GFP_KERNEL | GFP_DMA);
-
-	if (!da8xx_fb_info->screen_base) {
+	par->vram_size = lcdc_info->width * lcdc_info->height * lcd_cfg->bpp;
+	par->vram_size = PAGE_ALIGN(par->vram_size/8);
+	par->vram_size = par->vram_size * LCD_NUM_BUFFERS;
+
+	par->vram_virt = dma_alloc_coherent(NULL,
+					    par->vram_size,
+					    (resource_size_t *) &par->vram_phys,
+					    GFP_KERNEL | GFP_DMA);
+	if (!par->vram_virt) {
 		dev_err(&device->dev,
 			"GLCD: kmalloc for frame buffer failed\n");
 		ret = -EINVAL;
 		goto err_release_fb;
 	}
 
-	/* move palette base pointer by (PAGE_SIZE - palette_sz) bytes */
-	par->v_palette_base = da8xx_fb_info->screen_base +
-				(PAGE_SIZE - par->palette_sz);
-	par->p_palette_base = da8xx_fb_info->fix.smem_start +
-				(PAGE_SIZE - par->palette_sz);
-
-	/* the rest of the frame buffer is pixel data */
-	da8xx_fb_info->screen_base = par->v_palette_base + par->palette_sz;
-	da8xx_fb_fix.smem_start = par->p_palette_base + par->palette_sz;
-	da8xx_fb_fix.smem_len = par->databuf_sz - par->palette_sz;
-	da8xx_fb_fix.line_length = (lcdc_info->width * lcd_cfg->bpp) / 8;
+	da8xx_fb_info->screen_base = (char __iomem *) par->vram_virt;
+	da8xx_fb_fix.smem_start    = par->vram_phys;
+	da8xx_fb_fix.smem_len      = par->vram_size;
+	da8xx_fb_fix.line_length   = (lcdc_info->width * lcd_cfg->bpp) / 8;
+
+	par->dma_start = par->vram_phys;
+	par->dma_end   = par->dma_start + lcdc_info->height *
+		da8xx_fb_fix.line_length - 1;
+
+	/* allocate palette buffer */
+	par->v_palette_base = dma_alloc_coherent(NULL,
+					       PALETTE_SIZE,
+					       (resource_size_t *)
+					       &par->p_palette_base,
+					       GFP_KERNEL | GFP_DMA);
+	if (!par->v_palette_base) {
+		dev_err(&device->dev,
+			"GLCD: kmalloc for palette buffer failed\n");
+		ret = -EINVAL;
+		goto err_release_fb_mem;
+	}
+	memset(par->v_palette_base, 0, PALETTE_SIZE);
 
 	par->irq = platform_get_irq(device, 0);
 	if (par->irq < 0) {
 		ret = -ENOENT;
-		goto err_release_fb_mem;
+		goto err_release_pl_mem;
 	}
 
 	ret = request_irq(par->irq, lcdc_irq_handler, 0, DRIVER_NAME, par);
 	if (ret)
-		goto err_release_fb_mem;
+		goto err_release_pl_mem;
 
 	/* Initialize par */
 	da8xx_fb_info->var.bits_per_pixel = lcd_cfg->bpp;
@@ -870,8 +1039,8 @@ static int __init fb_probe(struct platform_device *device)
 	da8xx_fb_var.xres = lcdc_info->width;
 	da8xx_fb_var.xres_virtual = lcdc_info->width;
 
-	da8xx_fb_var.yres = lcdc_info->height;
-	da8xx_fb_var.yres_virtual = lcdc_info->height;
+	da8xx_fb_var.yres         = lcdc_info->height;
+	da8xx_fb_var.yres_virtual = lcdc_info->height * LCD_NUM_BUFFERS;
 
 	da8xx_fb_var.grayscale =
 	    lcd_cfg->p_disp_panel->panel_shade == MONOCHROME ? 1 : 0;
@@ -892,18 +1061,18 @@ static int __init fb_probe(struct platform_device *device)
 	ret = fb_alloc_cmap(&da8xx_fb_info->cmap, PALETTE_SIZE, 0);
 	if (ret)
 		goto err_free_irq;
-
-	/* First palette_sz byte of the frame buffer is the palette */
 	da8xx_fb_info->cmap.len = par->palette_sz;
 
-	/* Flush the buffer to the screen. */
-	lcd_blit(LOAD_DATA, par);
-
 	/* initialize var_screeninfo */
 	da8xx_fb_var.activate = FB_ACTIVATE_FORCE;
 	fb_set_var(da8xx_fb_info, &da8xx_fb_var);
 
 	dev_set_drvdata(&device->dev, da8xx_fb_info);
+
+	/* initialize the vsync wait queue */
+	init_waitqueue_head(&par->vsync_wait);
+	par->vsync_timeout = HZ / 5;
+
 	/* Register the Frame Buffer  */
 	if (register_framebuffer(da8xx_fb_info) < 0) {
 		dev_err(&device->dev,
@@ -919,10 +1088,6 @@ static int __init fb_probe(struct platform_device *device)
 		goto err_cpu_freq;
 	}
 #endif
-
-	/* enable raster engine */
-	lcd_enable_raster();
-
 	return 0;
 
 #ifdef CONFIG_CPU_FREQ
@@ -936,10 +1101,12 @@ err_dealloc_cmap:
 err_free_irq:
 	free_irq(par->irq, par);
 
+err_release_pl_mem:
+	dma_free_coherent(NULL, PALETTE_SIZE, par->v_palette_base,
+			  par->p_palette_base);
+
 err_release_fb_mem:
-	dma_free_coherent(NULL, par->databuf_sz + PAGE_SIZE,
-				da8xx_fb_info->screen_base - PAGE_SIZE,
-				da8xx_fb_info->fix.smem_start);
+	dma_free_coherent(NULL, par->vram_size, par->vram_virt, par->vram_phys);
 
 err_release_fb:
 	framebuffer_release(da8xx_fb_info);
diff --git a/include/video/da8xx-fb.h b/include/video/da8xx-fb.h
index 89d43b3..6316cda 100644
--- a/include/video/da8xx-fb.h
+++ b/include/video/da8xx-fb.h
@@ -99,6 +99,7 @@ struct lcd_sync_arg {
 #define FBIPUT_COLOR		_IOW('F', 6, int)
 #define FBIPUT_HSYNC		_IOW('F', 9, int)
 #define FBIPUT_VSYNC		_IOW('F', 10, int)
+#define FBIO_WAITFORVSYNC	_IOW('F', 0x20, u_int32_t)
 
 #endif  /* ifndef DA8XX_FB_H */
 
-- 
1.6.6.1


From lamiaposta71 at gmail.com  Mon Apr 12 03:46:11 2010
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Mon, 12 Apr 2010 10:46:11 +0200
Subject: isif - debugging on dm365
In-Reply-To: <4BBC9977.8080902@cynove.com>
References: <ade1bdc1003300750r111aeda4iaeab54f770a86331@mail.gmail.com>
	<A69FA2915331DC488A831521EAE36FE4016A8B3D35@dlee06.ent.ti.com>
	<ade1bdc1003300915q6a557cc8n9ac9684c439cad42@mail.gmail.com>
	<A69FA2915331DC488A831521EAE36FE4016A8B3DD2@dlee06.ent.ti.com>
	<j2qade1bdc1003310748t5b57539cs4c868911e7d464e5@mail.gmail.com>
	<A69FA2915331DC488A831521EAE36FE4016A92CC50@dlee06.ent.ti.com>
	<r2nade1bdc1004012338yb12139b8k697d9831df81de33@mail.gmail.com>
	<v2vade1bdc1004070238if288b7abx7b762d3d9d79ab91@mail.gmail.com>
	<4BBC9977.8080902@cynove.com>
Message-ID: <h2kade1bdc1004120146ged3ea83vd1d6ba6386af4f2e@mail.gmail.com>

Hi Jean-Philippe,

I finally create my patch against f5cef8f45739db4c0c1c346296922cac274c87eb
in attachment, but the problem is that isif_set_hw_if_params is not called
by gstreamer.

If I set in drivers/media/video/davinci/isif.c (and not in
drivers/media/video/davinci/dm365_ccdc.c as I don't have it !!)
   'ycswap=YCIN_NOT_SWP'
it works !!

The board file has no effect on my gstreamer command:
   gst-launch v4l2src ! video/x-raw-yuv ! filesink location=video_new3.raw
see below for my complete logs.

Here you are the board declaration:
static struct vpfe_subdev_info vpfe_sub_devs[] = {
        {
                .name = "adv7180",
                .grp_id = 0,
                .num_inputs = ARRAY_SIZE(adv7180_inputs),
                .inputs = adv7180_inputs,
                .routes = adv7180_routes,
                .can_route = 1,
                .ccdc_if_params = {
                        .if_type = VPFE_BT656,
                        .hdpol = VPFE_PINPOL_POSITIVE,
                        .vdpol = VPFE_PINPOL_POSITIVE,
                        .ycswap = YCIN_NOT_SWP,
                },
                .board_info = {
                        I2C_BOARD_INFO("adv7180", 0x20),
                        .platform_data = &adv7180_pdata,
                },
        },
};

The patch is very similar to yours, I change only the name of defines
because they seem more clear to me.

The complete log (setting ycswap=YCIN_SWP inside isif.c file in order to try
to get the correct parameter from my board file) follows:
(isif_set_hw_if_params is not called)

root at dm365-evm:~# gst-launch v4l2src ! video/x-raw-yuv ! filesink
location=video
_new3.raw
Setting pipeline to PAUSED ...
vpfe-capture vpfe-capture: vpfe_open
vpfe-capture vpfe-capture: vpfe_querycap
vpfe-capture vpfe-capture: vpfe_enum_input
vpfe-capture vpfe-capture: vpfe_enum_input
vpfe-capture vpfe-capture: input information not found for the subdev
vpfe-capture vpfe-capture: vpfe_g_std
vpfe-capture vpfe-capture: vpfe_g_input
vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap
vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap
vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap
vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap
vpfe-capture vpfe-capture: width = 1, height = 1, bpp = 2
vpfe-capture vpfe-capture: adjusted width = 16, height = 2, bpp = 2,
bytesperline = 32, sizeimage = 64
vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap
vpfe-capture vpfe-capture: width = 32768, height = 32768, bpp = 2
vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2,
bytesperline = 1440, sizeimage = 691200
vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap
vpfe-capture vpfe-capture: width = 1, height = 1, bpp = 2
vpfe-capture vpfe-capture: adjusted width = 16, height = 2, bpp = 2,
bytesperline = 32, sizeimage = 64
vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap
vpfe-capture vpfe-capture: width = 32768, height = 32768, bpp = 2
vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2,
bytesperline = 1440, sizeimage = 691200
vpfe-capture vpfe-capture: vpfe_g_fmt_vid_cap
vpfe-capture vpfe-capture: vpfe_s_fmt_vid_cap
vpfe-capture vpfe-capture: width = 720, height = 480, bpp = 2
vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2,
bytesperline = 1440, sizeimage = 691200
vpfe-capture vpfe-capture: vpfe_g_std
vpfe-capture vpfe-capture: vpfe_reqbufs
vpfe-capture vpfe-capture: vpfe_buffer_setup
vpfe-capture vpfe-capture: count=3, size=1147200
vpfe-capture vpfe-capture: vpfe_querybuf
vpfe-capture vpfe-capture: vpfe_mmap
vpfe-capture vpfe-capture: vpfe_querybuf
vpfe-capture vpfe-capture: vpfe_mmap
vpfe-capture vpfe-capture: vpfe_querybuf
vpfe-capture vpfe-capture: vpfe_mmap
vpfe-capture vpfe-capture: vpfe_qbuf
vpfe-capture vpfe-capture: vpfe_buffer_prepare
vpfe-capture vpfe-capture: vpfe_qbuf
vpfe-capture vpfe-capture: vpfe_buffer_prepare
vpfe-capture vpfe-capture: vpfe_qbuf
vpfe-capture vpfe-capture: vpfe_buffer_prepare
vpfe-capture vpfe-capture: vpfe_streamon
vpfe-capture vpfe-capture: vpfe_buffer_queue
vpfe-capture vpfe-capture: vpfe_buffer_queue
vpfe-capture vpfe-capture: vpfe_buffer_queue
vpfe-capture vpfe-capture: vpfe_calculate_offsets
isif_config_ycbcr - if_type = 0
isif_config_ycbcr - ycswap = 1
isif_config_ycbcr -924
isif_config_ycbcr -927
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
vpfe-capture vpfe-capture: vpfe_poll
New clock: GstSystemClock




2010/4/7 Jean-Philippe Fran?ois <jp.francois at cynove.com>

> Raffaele Recalcati a ?crit :
>
>  I was adding isif_cfg.y_c_swap variable, but it need a modification inside
>> arch/arm/mach-davinci/dm365.c that I think is not the right direction.
>> I mean, the "isif" platform data is not board related, but it is cpu
>> related.
>>
>
> sensor or decoder connection to the isif is definitely board related.
>
> the ccdc_if_params field of the vpfe_subdev_info struct is used by
> the ccdc code in the ccdc_set_hw_if_params function.
>
> Here is a patch that implement an ycswap field.
> It is set in the board file, and used in the ccdc driver.
> It does only include the dm365 ccdc, but it can be extended.
>
>
>
>


-- 
www.opensurf.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100412/ae5218b6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: video-in-ycswap.patch.gz
Type: application/x-gzip
Size: 1067 bytes
Desc: not available
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100412/ae5218b6/attachment-0001.gz>

From jp.francois at cynove.com  Mon Apr 12 04:43:55 2010
From: jp.francois at cynove.com (=?ISO-8859-1?Q?Jean-Philippe_Fran=E7ois?=)
Date: Mon, 12 Apr 2010 11:43:55 +0200
Subject: isif - debugging on dm365
In-Reply-To: <h2kade1bdc1004120146ged3ea83vd1d6ba6386af4f2e@mail.gmail.com>
References: <ade1bdc1003300750r111aeda4iaeab54f770a86331@mail.gmail.com>	
	<A69FA2915331DC488A831521EAE36FE4016A8B3D35@dlee06.ent.ti.com>	
	<ade1bdc1003300915q6a557cc8n9ac9684c439cad42@mail.gmail.com>	
	<A69FA2915331DC488A831521EAE36FE4016A8B3DD2@dlee06.ent.ti.com>	
	<j2qade1bdc1003310748t5b57539cs4c868911e7d464e5@mail.gmail.com>	
	<A69FA2915331DC488A831521EAE36FE4016A92CC50@dlee06.ent.ti.com>	
	<r2nade1bdc1004012338yb12139b8k697d9831df81de33@mail.gmail.com>	
	<v2vade1bdc1004070238if288b7abx7b762d3d9d79ab91@mail.gmail.com>	
	<4BBC9977.8080902@cynove.com>
	<h2kade1bdc1004120146ged3ea83vd1d6ba6386af4f2e@mail.gmail.com>
Message-ID: <4BC2EB5B.4030706@cynove.com>

I suppose it does not work, because isif_set_hw_if params is only called
if the user applications is doing a VIDIOC_S_INPUT.

based on your log, it seems gstreamer does not do that.

I don't know if the driver or the application should be corrected.
May be there is a command switch to gstreamer that allows to specify an input ?
Raffaele Recalcati a ?crit :
> Hi Jean-Philippe,
> 
> I finally create my patch against 
> f5cef8f45739db4c0c1c346296922cac274c87eb in attachment, but the problem 
> is that isif_set_hw_if_params is not called by gstreamer.
> 
> If I set in drivers/media/video/davinci/isif.c (and not in 
> drivers/media/video/davinci/dm365_ccdc.c as I don't have it !!)  
>    'ycswap=YCIN_NOT_SWP'  
> it works !!
> 
> The board file has no effect on my gstreamer command:
>    gst-launch v4l2src ! video/x-raw-yuv ! filesink location=video_new3.raw
> see below for my complete logs.
> 
> Here you are the board declaration:
> static struct vpfe_subdev_info vpfe_sub_devs[] = {
>         {
>                 .name = "adv7180",
>                 .grp_id = 0,
>                 .num_inputs = ARRAY_SIZE(adv7180_inputs),
>                 .inputs = adv7180_inputs,
>                 .routes = adv7180_routes,
>                 .can_route = 1,
>                 .ccdc_if_params = {
>                         .if_type = VPFE_BT656,
>                         .hdpol = VPFE_PINPOL_POSITIVE,
>                         .vdpol = VPFE_PINPOL_POSITIVE,
>                         .ycswap = YCIN_NOT_SWP,
>                 },
>                 .board_info = {
>                         I2C_BOARD_INFO("adv7180", 0x20),
>                         .platform_data = &adv7180_pdata,
>                 },
>         },
> };
> 
> The patch is very similar to yours, I change only the name of defines 
> because they seem more clear to me.
> 
> The complete log (setting ycswap=YCIN_SWP inside isif.c file in order to 
> try to get the correct parameter from my board file) follows:
> (isif_set_hw_if_params is not called)
> 
> root at dm365-evm:~# gst-launch v4l2src ! video/x-raw-yuv ! filesink 
> location=video
> _new3.raw
> Setting pipeline to PAUSED ...
> vpfe-capture vpfe-capture: vpfe_open
> vpfe-capture vpfe-capture: vpfe_querycap
> vpfe-capture vpfe-capture: vpfe_enum_input
> vpfe-capture vpfe-capture: vpfe_enum_input
> vpfe-capture vpfe-capture: input information not found for the subdev
> vpfe-capture vpfe-capture: vpfe_g_std
> vpfe-capture vpfe-capture: vpfe_g_input
> vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap
> vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap
> vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap
> vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap
> vpfe-capture vpfe-capture: width = 1, height = 1, bpp = 2
> vpfe-capture vpfe-capture: adjusted width = 16, height = 2, bpp = 2, 
> bytesperline = 32, sizeimage = 64
> vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap
> vpfe-capture vpfe-capture: width = 32768, height = 32768, bpp = 2
> vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2, 
> bytesperline = 1440, sizeimage = 691200
> vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap
> vpfe-capture vpfe-capture: width = 1, height = 1, bpp = 2
> vpfe-capture vpfe-capture: adjusted width = 16, height = 2, bpp = 2, 
> bytesperline = 32, sizeimage = 64
> vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap
> vpfe-capture vpfe-capture: width = 32768, height = 32768, bpp = 2
> vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2, 
> bytesperline = 1440, sizeimage = 691200
> vpfe-capture vpfe-capture: vpfe_g_fmt_vid_cap
> vpfe-capture vpfe-capture: vpfe_s_fmt_vid_cap
> vpfe-capture vpfe-capture: width = 720, height = 480, bpp = 2
> vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2, 
> bytesperline = 1440, sizeimage = 691200
> vpfe-capture vpfe-capture: vpfe_g_std
> vpfe-capture vpfe-capture: vpfe_reqbufs
> vpfe-capture vpfe-capture: vpfe_buffer_setup
> vpfe-capture vpfe-capture: count=3, size=1147200
> vpfe-capture vpfe-capture: vpfe_querybuf
> vpfe-capture vpfe-capture: vpfe_mmap
> vpfe-capture vpfe-capture: vpfe_querybuf
> vpfe-capture vpfe-capture: vpfe_mmap
> vpfe-capture vpfe-capture: vpfe_querybuf
> vpfe-capture vpfe-capture: vpfe_mmap
> vpfe-capture vpfe-capture: vpfe_qbuf
> vpfe-capture vpfe-capture: vpfe_buffer_prepare
> vpfe-capture vpfe-capture: vpfe_qbuf
> vpfe-capture vpfe-capture: vpfe_buffer_prepare
> vpfe-capture vpfe-capture: vpfe_qbuf
> vpfe-capture vpfe-capture: vpfe_buffer_prepare
> vpfe-capture vpfe-capture: vpfe_streamon
> vpfe-capture vpfe-capture: vpfe_buffer_queue
> vpfe-capture vpfe-capture: vpfe_buffer_queue
> vpfe-capture vpfe-capture: vpfe_buffer_queue
> vpfe-capture vpfe-capture: vpfe_calculate_offsets
> isif_config_ycbcr - if_type = 0
> isif_config_ycbcr - ycswap = 1
> isif_config_ycbcr -924
> isif_config_ycbcr -927
> Pipeline is live and does not need PREROLL ...
> Setting pipeline to PLAYING ...
> vpfe-capture vpfe-capture: vpfe_poll
> New clock: GstSystemClock
> 
> 
> 
> 
> 2010/4/7 Jean-Philippe Fran?ois <jp.francois at cynove.com 
> <mailto:jp.francois at cynove.com>>
> 
>     Raffaele Recalcati a ?crit :
> 
>         I was adding isif_cfg.y_c_swap variable, but it need a
>         modification inside arch/arm/mach-davinci/dm365.c that I think
>         is not the right direction.
>         I mean, the "isif" platform data is not board related, but it is
>         cpu related.
> 
> 
>     sensor or decoder connection to the isif is definitely board related.
> 
>     the ccdc_if_params field of the vpfe_subdev_info struct is used by
>     the ccdc code in the ccdc_set_hw_if_params function.
> 
>     Here is a patch that implement an ycswap field.
>     It is set in the board file, and used in the ccdc driver.
>     It does only include the dm365 ccdc, but it can be extended.
> 
> 
> 
> 
> 
> 
> -- 
> www.opensurf.it <http://www.opensurf.it>


From lamiaposta71 at gmail.com  Mon Apr 12 07:36:01 2010
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Mon, 12 Apr 2010 14:36:01 +0200
Subject: dm365 - voice codec
In-Reply-To: <j2tade1bdc1004010931v440aa4fdz97de74bbb8c7ca25@mail.gmail.com>
References: <j2tade1bdc1004010931v440aa4fdz97de74bbb8c7ca25@mail.gmail.com>
Message-ID: <u2nade1bdc1004120536w79762aa5t675b016e6b0a3248@mail.gmail.com>

Hello everybody.
If I'm not wrong it doesn't yet exist the voice codec for dm365.
Is there any roadmap to support this peripheral?
Thank in advance.


2010/4/1 Raffaele Recalcati <lamiaposta71 at gmail.com>

> It seems that in git kernel this peripheral is not yet supported.
> I search everywere:
>
> ./arch/arm/mach-davinci/dm365.c:        CLK("davinci_voicecodec",
> NULL, &voicecodec_clk),
> ./arch/arm/mach-davinci/dm365.c:        .name           =
> "davinci_voicecodec",
>
> This means that davinci_voicecodec is not really configured.
> Anybody can please confirm this point and tell me the development roadmap?
>
> Thx,
> Raffaele
>



-- 
www.opensurf.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100412/394e685c/attachment.html>

From BNiebuhr at efjohnson.com  Mon Apr 12 08:42:37 2010
From: BNiebuhr at efjohnson.com (Brian Niebuhr)
Date: Mon, 12 Apr 2010 08:42:37 -0500
Subject: SPI Support for DA850 (OMAPL-138).
In-Reply-To: <p2p763e54b1004110755u701c9e5ek3c9cc29320c733c5@mail.gmail.com>
References: <p2p763e54b1004110755u701c9e5ek3c9cc29320c733c5@mail.gmail.com>
Message-ID: <A117B9F753B6EB4580D381ED91D0FED0017D2E10@transmail01.transcrypt.local>

Mike - 

I do plan on resubmitting the driver as a replacement driver (remove the old and add the updated version) as suggested by TI.  I am just trying to get some other work finished up first.  If you want to try the version I submitted, the patch was actually against the arago kernel.  You can try patching that version and pulling it into your kernel to see if that fixes your issues. Hopefully I'll get around to resubmitting the driver for consideration some time this week.

Brian

> -----Original Message-----
> From: davinci-linux-open-source-bounces at linux.davincidsp.com 
> [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com
> ] On Behalf Of Mike Williamson
> Sent: Sunday, April 11, 2010 9:56 AM
> To: davinci-linux-open-source at linux.davincidsp.com
> Subject: SPI Support for DA850 (OMAPL-138).
> 
> Hi,
> 
> I've been working with Kevin's tree and have been having some problems
> with the SPI interface for the DA850 (OMAP-L138), SPI version 2.
> 
> I am getting a lot of failures in the davinci_spi_check_error routine
> that I'm not sure are real errors.? I was googling around and found
> this thread:
> 
> http://linux.omap.com/pipermail/davinci-linux-open-source/2009
> -July/015025.html
> 
> The thread raises the same issue that I have found in that the routine
> is declaring an error if the status of the SPI engine is claiming that
> the Tx buffer is empty (SPIFLG_TX_INTR_MASK) and there is also a check
> on a bit  (SPIFLG_BUF_INIT_ACTIVE_MASK, bit 24) that is undocumented
> in the SPI user guide.  I found that I had to turn off both of these
> checks in order for the SPI to work with our device in polled mode
> with no DMAs.    The device is an m25p64 EEPROM, same configuration as
> on the 850 / OMAPL138 evm.
> 
> Can anyone confirm if the spi implementation in Kevin's tree is
> working for VERSION_2 SPI devices (850 specifically), and what SPI
> configuration you're using?
> 
> I am also wondering if the SPI patches from Brian Niebuhr have died on
> the wire 
> (http://linux.davincidsp.com/pipermail/davinci-linux-open-sour
> ce/2010-March/018077.html).
>  It seemed like he had identified several issues with the driver and
> had taken a crack at sorting them out.
> 
> -Mike
> 
> 
> 
> 
> --
> Michael Williamson
> 315-425-4045x230
> www.criticallink.com
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 
> 


From cyril at ti.com  Mon Apr 12 10:01:58 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Mon, 12 Apr 2010 11:01:58 -0400
Subject: [PATCH v2 14/16] Davinci: tnetv107x gpio implementation
In-Reply-To: <871vetva4h.fsf@deeprootsystems.com>
References: <1269553439-14886-1-git-send-email-cyril@ti.com>	<1269553439-14886-2-git-send-email-cyril@ti.com>	<1269553439-14886-3-git-send-email-cyril@ti.com>	<1269553439-14886-4-git-send-email-cyril@ti.com>	<1269553439-14886-5-git-send-email-cyril@ti.com>	<1269553439-14886-6-git-send-email-cyril@ti.com>	<1269553439-14886-7-git-send-email-cyril@ti.com>	<1269553439-14886-8-git-send-email-cyril@ti.com>	<1269553439-14886-9-git-send-email-cyril@ti.com>	<1269553439-14886-10-git-send-email-cyril@ti.com>	<1269553439-14886-11-git-send-email-cyril@ti.com>	<1269553439-14886-12-git-send-email-cyril@ti.com>	<1269553439-14886-13-git-send-email-cyril@ti.com>	<1269553439-14886-14-git-send-email-cyril@ti.com>	<1269553439-14886-15-git-send-email-cyril@ti.com>
	<871vetva4h.fsf@deeprootsystems.com>
Message-ID: <4BC335E6.40309@ti.com>

Hi Kevin,

> Both the existing functions and the new functions all do basically the same thing:
> - read base + offset
> - set/clear bit(s) based on GPIO#
> - write base + offset

Davinci doesn't really do a read-modify-write.  Instead, it sets bits 
into set_data/clr_data registers to indirectly manipulate out_data 
contents.  On the other hand, the tnetv107x controller follows a 
read-modify-write as you've outlined.

This poses a bit of a problem is structuring a common table containing 
register offsets and bitmasks.  Is there a problem with writing to the 
out_data register instead of set/clr_data?

Regards
Cyril.

From todd.fischer at ridgerun.com  Mon Apr 12 10:42:02 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Mon, 12 Apr 2010 09:42:02 -0600
Subject: dm365 - voice codec
In-Reply-To: <u2nade1bdc1004120536w79762aa5t675b016e6b0a3248@mail.gmail.com>
References: <j2tade1bdc1004010931v440aa4fdz97de74bbb8c7ca25@mail.gmail.com>
	<u2nade1bdc1004120536w79762aa5t675b016e6b0a3248@mail.gmail.com>
Message-ID: <1271086922.4697.4126.camel@sax-lx>

Hi Raffaele,

Miguel posted a patch to add voice codec to alsa-devel at alsa-project.org
on March 9th.

For DM365, you can either use external or built-in voice codec, but not
both in a general way at the same time.  There is also some limitations
in ALSA that make exposing both in a general way not possible (I don't
recall the details).

If you just want to use the built-in voice codec and not an external AIC
chip, Miguel's patches should meet your needs.

Todd


On Mon, 2010-04-12 at 14:36 +0200, Raffaele Recalcati wrote:

> Hello everybody.
> If I'm not wrong it doesn't yet exist the voice codec for dm365.
> Is there any roadmap to support this peripheral?
> Thank in advance.
> 
> 
> 
> 2010/4/1 Raffaele Recalcati <lamiaposta71 at gmail.com>
> 
>         It seems that in git kernel this peripheral is not yet
>         supported.
>         I search everywere:
>         
>         ./arch/arm/mach-davinci/dm365.c:
>          CLK("davinci_voicecodec",
>         NULL, &voicecodec_clk),
>         ./arch/arm/mach-davinci/dm365.c:        .name           =
>         "davinci_voicecodec",
>         
>         This means that davinci_voicecodec is not really configured.
>         Anybody can please confirm this point and tell me the
>         development roadmap?
>         
>         Thx,
>         Raffaele
> 
> 
> 
> 
> -- 
> www.opensurf.it
> 
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100412/8b6b10aa/attachment-0001.html>

From cyril at ti.com  Mon Apr 12 16:15:25 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Mon, 12 Apr 2010 17:15:25 -0400
Subject: [PATCH 0/8] davinci common code changes for tnetv107x
Message-ID: <1271106933-13911-1-git-send-email-cyril@ti.com>

This patch series contains a bundle of common code changes that are needed as
a precursor to adding tnetv107x soc support.

Some of these patches were sent out separately earlier, but have also been
included here.

This patch series has been boot-up tested on dm365, thanks to Sandeep.

Cyril Chemparathy (8):
  Davinci: iotable based ioremap() interception
  Davinci: generalized debug macros
  Davinci: configurable pll divider mask
  Davinci: gpio - minor cleanup
  Davinci: gpio - struct renames
  Davinci: gpio - register layout invariant inlines
  Davinci: gpio - controller type support
  Davinci: gpio - fine grained locking

 arch/arm/mach-davinci/clock.c                    |    9 +-
 arch/arm/mach-davinci/clock.h                    |    1 +
 arch/arm/mach-davinci/da830.c                    |    8 +-
 arch/arm/mach-davinci/da850.c                    |   10 ++-
 arch/arm/mach-davinci/dm355.c                    |    1 +
 arch/arm/mach-davinci/dm365.c                    |    1 +
 arch/arm/mach-davinci/dm644x.c                   |    1 +
 arch/arm/mach-davinci/dm646x.c                   |    1 +
 arch/arm/mach-davinci/gpio.c                     |  133 ++++++++++++++--------
 arch/arm/mach-davinci/include/mach/common.h      |    5 +
 arch/arm/mach-davinci/include/mach/debug-macro.S |   51 +++++++--
 arch/arm/mach-davinci/include/mach/gpio.h        |   72 ++++++-------
 arch/arm/mach-davinci/include/mach/io.h          |    4 +
 arch/arm/mach-davinci/include/mach/serial.h      |   13 ++
 arch/arm/mach-davinci/include/mach/uncompress.h  |   80 ++++++++++----
 arch/arm/mach-davinci/io.c                       |   33 +++++-
 16 files changed, 293 insertions(+), 130 deletions(-)


From cyril at ti.com  Mon Apr 12 16:15:27 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Mon, 12 Apr 2010 17:15:27 -0400
Subject: [PATCH 2/8] Davinci: generalized debug macros
In-Reply-To: <1271106933-13911-2-git-send-email-cyril@ti.com>
References: <1271106933-13911-1-git-send-email-cyril@ti.com>
	<1271106933-13911-2-git-send-email-cyril@ti.com>
Message-ID: <1271106933-13911-3-git-send-email-cyril@ti.com>

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 macros through a small chunk of memory placed just
below the page tables (@0x80003ff8).

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/include/mach/debug-macro.S |   51 +++++++++++---
 arch/arm/mach-davinci/include/mach/serial.h      |   13 ++++
 arch/arm/mach-davinci/include/mach/uncompress.h  |   80 ++++++++++++++++------
 3 files changed, 112 insertions(+), 32 deletions(-)

diff --git a/arch/arm/mach-davinci/include/mach/debug-macro.S b/arch/arm/mach-davinci/include/mach/debug-macro.S
index 3cd93a8..ac0fa02 100644
--- a/arch/arm/mach-davinci/include/mach/debug-macro.S
+++ b/arch/arm/mach-davinci/include/mach/debug-macro.S
@@ -17,22 +17,51 @@
  */
 
 #include <linux/serial_reg.h>
+
+#include <asm/memory.h>
+
+#include <mach/serial.h>
+
 #define UART_SHIFT	2
 
+		.pushsection .data
+davinci_uart_phys:	.word	0
+davinci_uart_virt:	.word	0
+		.popsection
+
 		.macro addruart, rx, tmp
+
+		/* Use davinci_uart_phys/virt if already configured */
+10:		mrc	p15, 0, \rx, c1, c0
+		tst	\rx, #1			@ MMU enabled?
+		ldreq	\rx, =__virt_to_phys(davinci_uart_phys)
+		ldrne	\rx, =davinci_uart_virt
+		ldr	\rx, [\rx]
+		cmp	\rx, #0			@ is port configured?
+		bne	99f			@ already configured
+
+		/* Copy uart phys address from decompressor uart info */
 		mrc	p15, 0, \rx, c1, c0
 		tst	\rx, #1			@ MMU enabled?
-		moveq	\rx, #0x01000000	@ physical base address
-		movne	\rx, #0xfe000000	@ virtual base
-#if defined(CONFIG_ARCH_DAVINCI_DA8XX) && defined(CONFIG_ARCH_DAVINCI_DMx)
-#error Cannot enable DaVinci and DA8XX platforms concurrently
-#elif defined(CONFIG_MACH_DAVINCI_DA830_EVM) || \
-	defined(CONFIG_MACH_DAVINCI_DA850_EVM)
-		orr	\rx, \rx, #0x00d00000	@ physical base address
-		orr	\rx, \rx, #0x0000d000	@ of UART 2
-#else
-		orr	\rx, \rx, #0x00c20000   @ UART 0
-#endif
+		ldreq	\tmp, =__virt_to_phys(davinci_uart_phys)
+		ldrne	\tmp, =davinci_uart_phys
+		ldreq	\rx, =DAVINCI_UART_INFO
+		ldrne	\rx, =__phys_to_virt(DAVINCI_UART_INFO)
+		ldr	\rx, [\rx, #0]
+		str	\rx, [\tmp]
+
+		/* Copy uart virt address from decompressor uart info */
+		mrc	p15, 0, \rx, c1, c0
+		tst	\rx, #1			@ MMU enabled?
+		ldreq	\tmp, =__virt_to_phys(davinci_uart_virt)
+		ldrne	\tmp, =davinci_uart_virt
+		ldreq	\rx, =DAVINCI_UART_INFO
+		ldrne	\rx, =__phys_to_virt(DAVINCI_UART_INFO)
+		ldr	\rx, [\rx, #4]
+		str	\rx, [\tmp]
+
+		b	10b
+99:
 		.endm
 
 		.macro	senduart,rd,rx
diff --git a/arch/arm/mach-davinci/include/mach/serial.h b/arch/arm/mach-davinci/include/mach/serial.h
index a584697..8829dde 100644
--- a/arch/arm/mach-davinci/include/mach/serial.h
+++ b/arch/arm/mach-davinci/include/mach/serial.h
@@ -11,8 +11,19 @@
 #ifndef __ASM_ARCH_SERIAL_H
 #define __ASM_ARCH_SERIAL_H
 
+#include <asm/memory.h>
+
 #include <mach/hardware.h>
 
+/*
+ * Stolen area that contains debug uart physical and virtual addresses.  These
+ * addresses are filled in by the uncompress.h code, and are used by the debug
+ * macros in debug-macro.S.
+ *
+ * This area sits just below the page tables (see arch/arm/kernel/head.S).
+ */
+#define DAVINCI_UART_INFO	(PHYS_OFFSET + 0x3ff8)
+
 #define DAVINCI_MAX_NR_UARTS	3
 #define DAVINCI_UART0_BASE	(IO_PHYS + 0x20000)
 #define DAVINCI_UART1_BASE	(IO_PHYS + 0x20400)
@@ -27,11 +38,13 @@
 #define UART_DM646X_SCR			0x10
 #define UART_DM646X_SCR_TX_WATERMARK	0x08
 
+#ifndef __ASSEMBLY__
 struct davinci_uart_config {
 	/* Bit field of UARTs present; bit 0 --> UART1 */
 	unsigned int enabled_uarts;
 };
 
 extern int davinci_serial_init(struct davinci_uart_config *);
+#endif
 
 #endif /* __ASM_ARCH_SERIAL_H */
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
index 33796b4..20c23a3 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -1,8 +1,17 @@
 /*
  * Serial port stubs for kernel decompress status messages
  *
- *  Author:     Anant Gole
- * (C) Copyright (C) 2006, Texas Instruments, Inc
+ * Initially based on:
+ * arch/arm/plat-omap/include/mach/uncompress.h
+ *
+ * Original copyrights follow.
+ *
+ * Copyright (C) 2000 RidgeRun, Inc.
+ * Author: Greg Lonnon <glonnon at ridgerun.com>
+ *
+ * Rewritten by:
+ * Author: <source at mvista.com>
+ * 2004 (c) MontaVista Software, Inc.
  *
  * This file is licensed under the terms of the GNU General Public License
  * version 2. This program is licensed "as is" without any warranty of any
@@ -11,30 +20,17 @@
 
 #include <linux/types.h>
 #include <linux/serial_reg.h>
-#include <mach/serial.h>
 
 #include <asm/mach-types.h>
 
-extern unsigned int __machine_arch_type;
+#include <mach/serial.h>
 
 static u32 *uart;
-
-static u32 *get_uart_base(void)
-{
-	if (__machine_arch_type == MACH_TYPE_DAVINCI_DA830_EVM ||
-		__machine_arch_type == MACH_TYPE_DAVINCI_DA850_EVM)
-		return (u32 *)DA8XX_UART2_BASE;
-	else
-		return (u32 *)DAVINCI_UART0_BASE;
-}
+static u32 *uart_info = (u32 *)(DAVINCI_UART_INFO);
 
 /* PORT_16C550A, in polled non-fifo mode */
-
 static void putc(char c)
 {
-	if (!uart)
-		uart = get_uart_base();
-
 	while (!(uart[UART_LSR] & UART_LSR_THRE))
 		barrier();
 	uart[UART_TX] = c;
@@ -42,12 +38,54 @@ static void putc(char c)
 
 static inline void flush(void)
 {
-	if (!uart)
-		uart = get_uart_base();
-
 	while (!(uart[UART_LSR] & UART_LSR_THRE))
 		barrier();
 }
 
-#define arch_decomp_setup()
+static inline void set_uart_info(u32 phys, void * __iomem virt)
+{
+	uart = (u32 *)phys;
+	uart_info[0] = phys;
+	uart_info[1] = (u32)virt;
+}
+
+#define _DEBUG_LL_ENTRY(machine, phys, virt)			\
+	if (machine_is_##machine()) {				\
+		set_uart_info(phys, virt);			\
+		break;						\
+	}
+
+#define DEBUG_LL_DAVINCI(machine, port)				\
+	_DEBUG_LL_ENTRY(machine, DAVINCI_UART##port##_BASE,	\
+			IO_ADDRESS(DAVINCI_UART##port##_BASE))
+
+#define DEBUG_LL_DA8XX(machine, port)				\
+	_DEBUG_LL_ENTRY(machine, DA8XX_UART##port##_BASE,	\
+			IO_ADDRESS(DA8XX_UART##port##_BASE))
+
+static inline void __arch_decomp_setup(unsigned long arch_id)
+{
+	/*
+	 * Initialize the port based on the machine ID from the bootloader.
+	 * Note that we're using macros here instead of switch statement
+	 * as machine_is functions are optimized out for the boards that
+	 * are not selected.
+	 */
+	do {
+		/* Davinci boards */
+		DEBUG_LL_DAVINCI(davinci_evm,		0);
+		DEBUG_LL_DAVINCI(sffsdr,		0);
+		DEBUG_LL_DAVINCI(neuros_osd2,		0);
+		DEBUG_LL_DAVINCI(davinci_dm355_evm,	0);
+		DEBUG_LL_DAVINCI(dm355_leopard,		0);
+		DEBUG_LL_DAVINCI(davinci_dm6467_evm,	0);
+		DEBUG_LL_DAVINCI(davinci_dm365_evm,	0);
+
+		/* DA8xx boards */
+		DEBUG_LL_DA8XX(davinci_da830_evm,	2);
+		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
+	} while (0);
+}
+
+#define arch_decomp_setup()	__arch_decomp_setup(arch_id)
 #define arch_decomp_wdog()
-- 
1.6.3.3


From cyril at ti.com  Mon Apr 12 16:15:28 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Mon, 12 Apr 2010 17:15:28 -0400
Subject: [PATCH 3/8] Davinci: configurable pll divider mask
In-Reply-To: <1271106933-13911-3-git-send-email-cyril@ti.com>
References: <1271106933-13911-1-git-send-email-cyril@ti.com>
	<1271106933-13911-2-git-send-email-cyril@ti.com>
	<1271106933-13911-3-git-send-email-cyril@ti.com>
Message-ID: <1271106933-13911-4-git-send-email-cyril@ti.com>

This patch allows socs to override the divider ratio mask by setting an
optional field (div_ratio_mask) in the pll_data structure.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/clock.c |    9 ++++++---
 arch/arm/mach-davinci/clock.h |    1 +
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
index 5de60ae..828f434 100644
--- a/arch/arm/mach-davinci/clock.c
+++ b/arch/arm/mach-davinci/clock.c
@@ -279,7 +279,7 @@ static unsigned long clk_sysclk_recalc(struct clk *clk)
 
 	v = __raw_readl(pll->base + clk->div_reg);
 	if (v & PLLDIV_EN) {
-		plldiv = (v & PLLDIV_RATIO_MASK) + 1;
+		plldiv = (v & pll->div_ratio_mask) + 1;
 		if (plldiv)
 			rate /= plldiv;
 	}
@@ -319,7 +319,7 @@ static unsigned long clk_pllclk_recalc(struct clk *clk)
 	if (pll->flags & PLL_HAS_PREDIV) {
 		prediv = __raw_readl(pll->base + PREDIV);
 		if (prediv & PLLDIV_EN)
-			prediv = (prediv & PLLDIV_RATIO_MASK) + 1;
+			prediv = (prediv & pll->div_ratio_mask) + 1;
 		else
 			prediv = 1;
 	}
@@ -331,7 +331,7 @@ static unsigned long clk_pllclk_recalc(struct clk *clk)
 	if (pll->flags & PLL_HAS_POSTDIV) {
 		postdiv = __raw_readl(pll->base + POSTDIV);
 		if (postdiv & PLLDIV_EN)
-			postdiv = (postdiv & PLLDIV_RATIO_MASK) + 1;
+			postdiv = (postdiv & pll->div_ratio_mask) + 1;
 		else
 			postdiv = 1;
 	}
@@ -464,6 +464,9 @@ int __init davinci_clk_init(struct clk_lookup *clocks)
 		if (clk->lpsc)
 			clk->flags |= CLK_PSC;
 
+		if (clk->pll_data && !clk->pll_data->div_ratio_mask)
+			clk->pll_data->div_ratio_mask = PLLDIV_RATIO_MASK;
+
 		clk_register(clk);
 		num_clocks++;
 
diff --git a/arch/arm/mach-davinci/clock.h b/arch/arm/mach-davinci/clock.h
index 53a0f7b..ce26015 100644
--- a/arch/arm/mach-davinci/clock.h
+++ b/arch/arm/mach-davinci/clock.h
@@ -76,6 +76,7 @@ struct pll_data {
 	u32 num;
 	u32 flags;
 	u32 input_rate;
+	u32 div_ratio_mask;
 };
 #define PLL_HAS_PREDIV          0x01
 #define PLL_HAS_POSTDIV         0x02
-- 
1.6.3.3


From cyril at ti.com  Mon Apr 12 16:15:26 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Mon, 12 Apr 2010 17:15:26 -0400
Subject: [PATCH 1/8] Davinci: iotable based ioremap() interception
In-Reply-To: <1271106933-13911-1-git-send-email-cyril@ti.com>
References: <1271106933-13911-1-git-send-email-cyril@ti.com>
Message-ID: <1271106933-13911-2-git-send-email-cyril@ti.com>

This patch allows for a more flexible ioremap() interception.  The mechanism
works by translating physical addresses based on soc-specific iotable
contents (davinci_soc_info.io_desc), once davinci_soc_info is populated by
davinci_common_init().

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/da830.c           |    7 +++++-
 arch/arm/mach-davinci/da850.c           |    9 ++++++-
 arch/arm/mach-davinci/include/mach/io.h |    4 +++
 arch/arm/mach-davinci/io.c              |   33 +++++++++++++++++++++++++++---
 4 files changed, 46 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 122e61a..168f277 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1206,9 +1206,14 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
 	.emac_pdata		= &da8xx_emac_pdata,
 };
 
+#define da830_early_ioremap(p, s)				\
+	__davinci_ioremap(p, s,					\
+			davinci_soc_info_da830.io_desc,		\
+			davinci_soc_info_da830.io_desc_num)
+
 void __init da830_init(void)
 {
-	da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
+	da8xx_syscfg0_base = da830_early_ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
 	if (WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module"))
 		return;
 
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index d0fd756..27eb32e 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1093,15 +1093,20 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.sram_len		= SZ_8K,
 };
 
+#define da850_early_ioremap(p, s)				\
+	__davinci_ioremap(p, s,					\
+			davinci_soc_info_da850.io_desc,		\
+			davinci_soc_info_da850.io_desc_num)
+
 void __init da850_init(void)
 {
 	unsigned int v;
 
-	da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
+	da8xx_syscfg0_base = da850_early_ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
 	if (WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module"))
 		return;
 
-	da8xx_syscfg1_base = ioremap(DA8XX_SYSCFG1_BASE, SZ_4K);
+	da8xx_syscfg1_base = da850_early_ioremap(DA8XX_SYSCFG1_BASE, SZ_4K);
 	if (WARN(!da8xx_syscfg1_base, "Unable to map syscfg1 module"))
 		return;
 
diff --git a/arch/arm/mach-davinci/include/mach/io.h b/arch/arm/mach-davinci/include/mach/io.h
index 62b0a90..4aa301c 100644
--- a/arch/arm/mach-davinci/include/mach/io.h
+++ b/arch/arm/mach-davinci/include/mach/io.h
@@ -25,6 +25,10 @@
 #define __arch_ioremap(p, s, t)	davinci_ioremap(p, s, t)
 #define __arch_iounmap(v)	davinci_iounmap(v)
 
+struct map_desc;
+
+void __iomem *__davinci_ioremap(unsigned long p, size_t size,
+		struct map_desc *io_desc, int io_desc_num);
 void __iomem *davinci_ioremap(unsigned long phys, size_t size,
 			      unsigned int type);
 void davinci_iounmap(volatile void __iomem *addr);
diff --git a/arch/arm/mach-davinci/io.c b/arch/arm/mach-davinci/io.c
index a1c0b6b..3a62f14 100644
--- a/arch/arm/mach-davinci/io.c
+++ b/arch/arm/mach-davinci/io.c
@@ -12,17 +12,42 @@
 #include <linux/io.h>
 
 #include <asm/tlb.h>
+#include <asm/mach/map.h>
 
-#define BETWEEN(p, st, sz)	((p) >= (st) && (p) < ((st) + (sz)))
-#define XLATE(p, pst, vst)	((void __iomem *)((p) - (pst) + (vst)))
+#include <mach/common.h>
+
+/*
+ * Remap io addresses based on a soc-specific io-descriptor table. This is
+ * useful in early arch init code before davinci_common_init().  After
+ * davinci_common_init(), regular ioremap() calls should be used.
+ */
+void __iomem *__davinci_ioremap(unsigned long p, size_t size,
+		struct map_desc *io_desc, int io_desc_num)
+{
+	int i;
+
+	for (i = 0; i < io_desc_num; i++, io_desc++) {
+		unsigned long iophys = __pfn_to_phys(io_desc->pfn);
+		unsigned long iosize = io_desc->length;
+
+		if (p >= iophys && (p + size) <= (iophys + iosize))
+			return __io(io_desc->virtual + p - iophys);
+	}
+
+	return NULL;
+}
 
 /*
  * Intercept ioremap() requests for addresses in our fixed mapping regions.
  */
 void __iomem *davinci_ioremap(unsigned long p, size_t size, unsigned int type)
 {
-	if (BETWEEN(p, IO_PHYS, IO_SIZE))
-		return XLATE(p, IO_PHYS, IO_VIRT);
+	void __iomem *ret;
+
+	ret = __davinci_ioremap(p, size, davinci_soc_info.io_desc,
+			davinci_soc_info.io_desc_num);
+	if (ret)
+		return ret;
 
 	return __arm_ioremap_caller(p, size, type, __builtin_return_address(0));
 }
-- 
1.6.3.3


From cyril at ti.com  Mon Apr 12 16:15:29 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Mon, 12 Apr 2010 17:15:29 -0400
Subject: [PATCH 4/8] Davinci: gpio - minor cleanup
In-Reply-To: <1271106933-13911-4-git-send-email-cyril@ti.com>
References: <1271106933-13911-1-git-send-email-cyril@ti.com>
	<1271106933-13911-2-git-send-email-cyril@ti.com>
	<1271106933-13911-3-git-send-email-cyril@ti.com>
	<1271106933-13911-4-git-send-email-cyril@ti.com>
Message-ID: <1271106933-13911-5-git-send-email-cyril@ti.com>

macroized repeated container_of()s to improve readability.
unified direction in/out functions.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/gpio.c |   47 +++++++++++++++++++++--------------------
 1 files changed, 24 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index 5476ad1..bb55f41 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -28,6 +28,9 @@ struct davinci_gpio {
 	int			irq_base;
 };
 
+#define chip2controller(chip)	\
+	container_of(chip, struct davinci_gpio, chip)
+
 static struct davinci_gpio chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
 
 /* create a non-inlined version */
@@ -54,21 +57,36 @@ static int __init davinci_gpio_irq_setup(void);
  * needed, and enable the GPIO clock.
  */
 
-static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
+static inline int __davinci_direction(struct gpio_chip *chip,
+			unsigned offset, bool out)
 {
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+	struct davinci_gpio *d = chip2controller(chip);
 	struct gpio_controller __iomem *g = d->regs;
 	u32 temp;
 
 	spin_lock(&gpio_lock);
 	temp = __raw_readl(&g->dir);
-	temp |= (1 << offset);
+	if (out)
+		temp &= ~(1 << offset);
+	else
+		temp |= (1 << offset);
 	__raw_writel(temp, &g->dir);
 	spin_unlock(&gpio_lock);
 
 	return 0;
 }
 
+static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
+{
+	return __davinci_direction(chip, offset, false);
+}
+
+static int
+davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
+{
+	return __davinci_direction(chip, offset, true);
+}
+
 /*
  * Read the pin's value (works even if it's set up as output);
  * returns zero/nonzero.
@@ -78,36 +96,19 @@ static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
  */
 static int davinci_gpio_get(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+	struct davinci_gpio *d = chip2controller(chip);
 	struct gpio_controller __iomem *g = d->regs;
 
 	return (1 << offset) & __raw_readl(&g->in_data);
 }
 
-static int
-davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
-{
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
-	struct gpio_controller __iomem *g = d->regs;
-	u32 temp;
-	u32 mask = 1 << offset;
-
-	spin_lock(&gpio_lock);
-	temp = __raw_readl(&g->dir);
-	temp &= ~mask;
-	__raw_writel(mask, value ? &g->set_data : &g->clr_data);
-	__raw_writel(temp, &g->dir);
-	spin_unlock(&gpio_lock);
-	return 0;
-}
-
 /*
  * Assuming the pin is muxed as a gpio output, set its output value.
  */
 static void
 davinci_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
 {
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+	struct davinci_gpio *d = chip2controller(chip);
 	struct gpio_controller __iomem *g = d->regs;
 
 	__raw_writel((1 << offset), value ? &g->set_data : &g->clr_data);
@@ -262,7 +263,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
 
 static int gpio_to_irq_banked(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+	struct davinci_gpio *d = chip2controller(chip);
 
 	if (d->irq_base >= 0)
 		return d->irq_base + offset;
-- 
1.6.3.3


From cyril at ti.com  Mon Apr 12 16:15:32 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Mon, 12 Apr 2010 17:15:32 -0400
Subject: [PATCH 7/8] Davinci: gpio - controller type support
In-Reply-To: <1271106933-13911-7-git-send-email-cyril@ti.com>
References: <1271106933-13911-1-git-send-email-cyril@ti.com>
	<1271106933-13911-2-git-send-email-cyril@ti.com>
	<1271106933-13911-3-git-send-email-cyril@ti.com>
	<1271106933-13911-4-git-send-email-cyril@ti.com>
	<1271106933-13911-5-git-send-email-cyril@ti.com>
	<1271106933-13911-6-git-send-email-cyril@ti.com>
	<1271106933-13911-7-git-send-email-cyril@ti.com>
Message-ID: <1271106933-13911-8-git-send-email-cyril@ti.com>

This patch allows for gpio controllers that deviate from those found on
traditional davinci socs.  davinci_soc_info has an added field to indicate the
soc-specific gpio controller type.  The gpio initialization code then bails
out of necessary.

More elements (tnetv107x) to be added later into enum davinci_gpio_type.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/da830.c               |    1 +
 arch/arm/mach-davinci/da850.c               |    1 +
 arch/arm/mach-davinci/dm355.c               |    1 +
 arch/arm/mach-davinci/dm365.c               |    1 +
 arch/arm/mach-davinci/dm644x.c              |    1 +
 arch/arm/mach-davinci/dm646x.c              |    1 +
 arch/arm/mach-davinci/gpio.c                |    3 +++
 arch/arm/mach-davinci/include/mach/common.h |    1 +
 arch/arm/mach-davinci/include/mach/gpio.h   |    4 ++++
 9 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 168f277..c4b30c4 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1199,6 +1199,7 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
 	.intc_irq_prios		= da830_default_priorities,
 	.intc_irq_num		= DA830_N_CP_INTC_IRQ,
 	.timer_info		= &da830_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DA8XX_GPIO_BASE),
 	.gpio_num		= 128,
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 27eb32e..2aa9748 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1084,6 +1084,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.intc_irq_prios		= da850_default_priorities,
 	.intc_irq_num		= DA850_N_CP_INTC_IRQ,
 	.timer_info		= &da850_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DA8XX_GPIO_BASE),
 	.gpio_num		= 144,
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 5efce70..f9a54ff 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -859,6 +859,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.intc_irq_prios		= dm355_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm355_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM355_GPIOBNK0,
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 871be5a..d81c440 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1063,6 +1063,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.intc_irq_prios		= dm365_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm365_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM365_GPIO0,
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 23cbe9d..4af349e 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -748,6 +748,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.intc_irq_prios 	= dm644x_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm644x_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
 	.gpio_num		= 71,
 	.gpio_irq		= IRQ_GPIOBNK0,
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index b67b997..899859c 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -858,6 +858,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.intc_irq_prios		= dm646x_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm646x_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
 	.gpio_num		= 43, /* Only 33 usable */
 	.gpio_irq		= IRQ_DM646X_GPIOBNK0,
diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index 082a098..3a78897 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -143,6 +143,9 @@ static int __init davinci_gpio_setup(void)
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
 	struct davinci_gpio_regs *regs;
 
+	if (soc_info->gpio_type != GPIO_TYPE_DAVINCI)
+		return 0;
+
 	/*
 	 * The gpio banks conceptually expose a segmented bitmap,
 	 * and "ngpio" is one more than the largest zero-based
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index c85c795..174619b 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -56,6 +56,7 @@ struct davinci_soc_info {
 	u8				*intc_irq_prios;
 	unsigned long			intc_irq_num;
 	struct davinci_timer_info	*timer_info;
+	int				gpio_type;
 	void __iomem			*gpio_base;
 	unsigned			gpio_num;
 	unsigned			gpio_irq;
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index a8ca4ce..33962c3 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -21,6 +21,10 @@
 
 #define DAVINCI_GPIO_BASE 0x01C67000
 
+enum davinci_gpio_type {
+	GPIO_TYPE_DAVINCI = 0,
+};
+
 /*
  * basic gpio routines
  *
-- 
1.6.3.3


From cyril at ti.com  Mon Apr 12 16:15:33 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Mon, 12 Apr 2010 17:15:33 -0400
Subject: [PATCH 8/8] Davinci: gpio - fine grained locking
In-Reply-To: <1271106933-13911-8-git-send-email-cyril@ti.com>
References: <1271106933-13911-1-git-send-email-cyril@ti.com>
	<1271106933-13911-2-git-send-email-cyril@ti.com>
	<1271106933-13911-3-git-send-email-cyril@ti.com>
	<1271106933-13911-4-git-send-email-cyril@ti.com>
	<1271106933-13911-5-git-send-email-cyril@ti.com>
	<1271106933-13911-6-git-send-email-cyril@ti.com>
	<1271106933-13911-7-git-send-email-cyril@ti.com>
	<1271106933-13911-8-git-send-email-cyril@ti.com>
Message-ID: <1271106933-13911-9-git-send-email-cyril@ti.com>

This patch eliminates the global gpio_lock, and implements a per-controller
lock instead.  This also switches to irqsave/irqrestore locks in case gpios
are manipulated in isr.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/gpio.c              |    9 +++++----
 arch/arm/mach-davinci/include/mach/gpio.h |    3 +++
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index 3a78897..1486c63 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -33,8 +33,6 @@ struct davinci_gpio_regs {
 	u32	intstat;
 };
 
-static DEFINE_SPINLOCK(gpio_lock);
-
 #define chip2controller(chip)	\
 	container_of(chip, struct davinci_gpio_controller, chip)
 
@@ -84,16 +82,17 @@ static inline int __davinci_direction(struct gpio_chip *chip,
 {
 	struct davinci_gpio_controller *d = chip2controller(chip);
 	struct davinci_gpio_regs __iomem *g = d->regs;
+	unsigned long flags;
 	u32 temp;
 
-	spin_lock(&gpio_lock);
+	spin_lock_irqsave(&d->lock, flags);
 	temp = __raw_readl(&g->dir);
 	if (out)
 		temp &= ~(1 << offset);
 	else
 		temp |= (1 << offset);
 	__raw_writel(temp, &g->dir);
-	spin_unlock(&gpio_lock);
+	spin_unlock_irqrestore(&d->lock, flags);
 
 	return 0;
 }
@@ -173,6 +172,8 @@ static int __init davinci_gpio_setup(void)
 		if (chips[i].chip.ngpio > 32)
 			chips[i].chip.ngpio = 32;
 
+		spin_lock_init(&chips[i].lock);
+
 		regs = gpio2regs(base);
 		chips[i].regs = regs;
 		chips[i].set_data = &regs->set_data;
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index 33962c3..2384cd1 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -14,6 +14,8 @@
 #define	__DAVINCI_GPIO_H
 
 #include <linux/io.h>
+#include <linux/spinlock.h>
+
 #include <asm-generic/gpio.h>
 
 #include <mach/irqs.h>
@@ -51,6 +53,7 @@ enum davinci_gpio_type {
 
 struct davinci_gpio_controller {
 	struct davinci_gpio_regs __iomem *regs;
+	spinlock_t		lock;
 	struct gpio_chip	chip;
 	int			irq_base;
 	void __iomem		*set_data;
-- 
1.6.3.3


From cyril at ti.com  Mon Apr 12 16:15:30 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Mon, 12 Apr 2010 17:15:30 -0400
Subject: [PATCH 5/8] Davinci: gpio - struct renames
In-Reply-To: <1271106933-13911-5-git-send-email-cyril@ti.com>
References: <1271106933-13911-1-git-send-email-cyril@ti.com>
	<1271106933-13911-2-git-send-email-cyril@ti.com>
	<1271106933-13911-3-git-send-email-cyril@ti.com>
	<1271106933-13911-4-git-send-email-cyril@ti.com>
	<1271106933-13911-5-git-send-email-cyril@ti.com>
Message-ID: <1271106933-13911-6-git-send-email-cyril@ti.com>

Renamed gpio structures to something more sensible:
	struct gpio_controller 	--> struct davinci_gpio_regs
	struct davinci_gpio	--> struct davinci_gpio_controller

This change also moves davinci_gpio_controller definition to gpio.h.
Eventually, the gpio registers structure will be moved to gpio.c and no longer
a common cross-soc definition.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/gpio.c              |   44 ++++++++++++----------------
 arch/arm/mach-davinci/include/mach/gpio.h |   14 ++++++--
 2 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index bb55f41..58a6fd5 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -22,28 +22,22 @@
 
 static DEFINE_SPINLOCK(gpio_lock);
 
-struct davinci_gpio {
-	struct gpio_chip	chip;
-	struct gpio_controller	__iomem *regs;
-	int			irq_base;
-};
-
 #define chip2controller(chip)	\
-	container_of(chip, struct davinci_gpio, chip)
+	container_of(chip, struct davinci_gpio_controller, chip)
 
-static struct davinci_gpio chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
+static struct davinci_gpio_controller chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
 
 /* create a non-inlined version */
-static struct gpio_controller __iomem __init *gpio2controller(unsigned gpio)
+static struct davinci_gpio_regs __iomem __init *gpio2controller(unsigned gpio)
 {
 	return __gpio_to_controller(gpio);
 }
 
-static inline struct gpio_controller __iomem *irq2controller(int irq)
+static inline struct davinci_gpio_regs __iomem *irq2controller(int irq)
 {
-	struct gpio_controller __iomem *g;
+	struct davinci_gpio_regs __iomem *g;
 
-	g = (__force struct gpio_controller __iomem *)get_irq_chip_data(irq);
+	g = (__force struct davinci_gpio_regs __iomem *)get_irq_chip_data(irq);
 
 	return g;
 }
@@ -60,8 +54,8 @@ static int __init davinci_gpio_irq_setup(void);
 static inline int __davinci_direction(struct gpio_chip *chip,
 			unsigned offset, bool out)
 {
-	struct davinci_gpio *d = chip2controller(chip);
-	struct gpio_controller __iomem *g = d->regs;
+	struct davinci_gpio_controller *d = chip2controller(chip);
+	struct davinci_gpio_regs __iomem *g = d->regs;
 	u32 temp;
 
 	spin_lock(&gpio_lock);
@@ -96,8 +90,8 @@ davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
  */
 static int davinci_gpio_get(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = chip2controller(chip);
-	struct gpio_controller __iomem *g = d->regs;
+	struct davinci_gpio_controller *d = chip2controller(chip);
+	struct davinci_gpio_regs __iomem *g = d->regs;
 
 	return (1 << offset) & __raw_readl(&g->in_data);
 }
@@ -108,8 +102,8 @@ static int davinci_gpio_get(struct gpio_chip *chip, unsigned offset)
 static void
 davinci_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
 {
-	struct davinci_gpio *d = chip2controller(chip);
-	struct gpio_controller __iomem *g = d->regs;
+	struct davinci_gpio_controller *d = chip2controller(chip);
+	struct davinci_gpio_regs __iomem *g = d->regs;
 
 	__raw_writel((1 << offset), value ? &g->set_data : &g->clr_data);
 }
@@ -171,7 +165,7 @@ pure_initcall(davinci_gpio_setup);
 
 static void gpio_irq_disable(unsigned irq)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2controller(irq);
 	u32 mask = (u32) get_irq_data(irq);
 
 	__raw_writel(mask, &g->clr_falling);
@@ -180,7 +174,7 @@ static void gpio_irq_disable(unsigned irq)
 
 static void gpio_irq_enable(unsigned irq)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2controller(irq);
 	u32 mask = (u32) get_irq_data(irq);
 	unsigned status = irq_desc[irq].status;
 
@@ -196,7 +190,7 @@ static void gpio_irq_enable(unsigned irq)
 
 static int gpio_irq_type(unsigned irq, unsigned trigger)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2controller(irq);
 	u32 mask = (u32) get_irq_data(irq);
 
 	if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
@@ -225,7 +219,7 @@ static struct irq_chip gpio_irqchip = {
 static void
 gpio_irq_handler(unsigned irq, struct irq_desc *desc)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2controller(irq);
 	u32 mask = 0xffff;
 
 	/* we only care about one bank */
@@ -263,7 +257,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
 
 static int gpio_to_irq_banked(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = chip2controller(chip);
+	struct davinci_gpio_controller *d = chip2controller(chip);
 
 	if (d->irq_base >= 0)
 		return d->irq_base + offset;
@@ -286,7 +280,7 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset)
 
 static int gpio_irq_type_unbanked(unsigned irq, unsigned trigger)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2controller(irq);
 	u32 mask = (u32) get_irq_data(irq);
 
 	if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
@@ -315,7 +309,7 @@ static int __init davinci_gpio_irq_setup(void)
 	u32		binten = 0;
 	unsigned	ngpio, bank_irq;
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
-	struct gpio_controller	__iomem *g;
+	struct davinci_gpio_regs	__iomem *g;
 
 	ngpio = soc_info->gpio_num;
 
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index 0099e6e..bdab001 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -45,7 +45,7 @@
 /* Convert GPIO signal to GPIO pin number */
 #define GPIO_TO_PIN(bank, gpio)	(16 * (bank) + (gpio))
 
-struct gpio_controller {
+struct davinci_gpio_regs {
 	u32	dir;
 	u32	out_data;
 	u32	set_data;
@@ -58,6 +58,12 @@ struct gpio_controller {
 	u32	intstat;
 };
 
+struct davinci_gpio_controller {
+	struct davinci_gpio_regs __iomem *regs;
+	struct gpio_chip	chip;
+	int			irq_base;
+};
+
 /* The __gpio_to_controller() and __gpio_mask() functions inline to constants
  * with constant parameters; or in outlined code they execute at runtime.
  *
@@ -67,7 +73,7 @@ struct gpio_controller {
  *
  * These are NOT part of the cross-platform GPIO interface
  */
-static inline struct gpio_controller __iomem *
+static inline struct davinci_gpio_regs __iomem *
 __gpio_to_controller(unsigned gpio)
 {
 	void __iomem *ptr;
@@ -102,7 +108,7 @@ static inline u32 __gpio_mask(unsigned gpio)
 static inline void gpio_set_value(unsigned gpio, int value)
 {
 	if (__builtin_constant_p(value) && gpio < DAVINCI_N_GPIO) {
-		struct gpio_controller	__iomem *g;
+		struct davinci_gpio_regs	__iomem *g;
 		u32			mask;
 
 		g = __gpio_to_controller(gpio);
@@ -128,7 +134,7 @@ static inline void gpio_set_value(unsigned gpio, int value)
  */
 static inline int gpio_get_value(unsigned gpio)
 {
-	struct gpio_controller	__iomem *g;
+	struct davinci_gpio_regs	__iomem *g;
 
 	if (!__builtin_constant_p(gpio) || gpio >= DAVINCI_N_GPIO)
 		return __gpio_get_value(gpio);
-- 
1.6.3.3


From cyril at ti.com  Mon Apr 12 16:15:31 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Mon, 12 Apr 2010 17:15:31 -0400
Subject: [PATCH 6/8] Davinci: gpio - register layout invariant inlines
In-Reply-To: <1271106933-13911-6-git-send-email-cyril@ti.com>
References: <1271106933-13911-1-git-send-email-cyril@ti.com>
	<1271106933-13911-2-git-send-email-cyril@ti.com>
	<1271106933-13911-3-git-send-email-cyril@ti.com>
	<1271106933-13911-4-git-send-email-cyril@ti.com>
	<1271106933-13911-5-git-send-email-cyril@ti.com>
	<1271106933-13911-6-git-send-email-cyril@ti.com>
Message-ID: <1271106933-13911-7-git-send-email-cyril@ti.com>

This patch renders the inlined gpio accessors in gpio.h independent of the
underlying controller's register layout.  This is done by including three new
fields in davinci_gpio_controller to hold the addresses of the set, clear, and
in data registers.

Other changes:

1. davinci_gpio_regs structure definition moved to gpio.c.  This structure is
no longer common across all davinci socs (davinci_gpio_controller is).

2. controller base address calculation code (gpio2controller()) moved to
gpio.c as this was no longer necessary for the inline implementation.

3. modified inline range checks to use davinci_soc_info.gpio_num instead of
DAVINCI_N_GPIO.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/gpio.c                |   46 +++++++++++++++++--
 arch/arm/mach-davinci/include/mach/common.h |    4 ++
 arch/arm/mach-davinci/include/mach/gpio.h   |   63 +++++++++-----------------
 3 files changed, 67 insertions(+), 46 deletions(-)

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index 58a6fd5..082a098 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -20,6 +20,19 @@
 
 #include <asm/mach/irq.h>
 
+struct davinci_gpio_regs {
+	u32	dir;
+	u32	out_data;
+	u32	set_data;
+	u32	clr_data;
+	u32	in_data;
+	u32	set_rising;
+	u32	clr_rising;
+	u32	set_falling;
+	u32	clr_falling;
+	u32	intstat;
+};
+
 static DEFINE_SPINLOCK(gpio_lock);
 
 #define chip2controller(chip)	\
@@ -28,9 +41,24 @@ static DEFINE_SPINLOCK(gpio_lock);
 static struct davinci_gpio_controller chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
 
 /* create a non-inlined version */
-static struct davinci_gpio_regs __iomem __init *gpio2controller(unsigned gpio)
+static struct davinci_gpio_regs __iomem __init *gpio2regs(unsigned gpio)
 {
-	return __gpio_to_controller(gpio);
+	void __iomem *ptr;
+	void __iomem *base = davinci_soc_info.gpio_base;
+
+	if (gpio < 32 * 1)
+		ptr = base + 0x10;
+	else if (gpio < 32 * 2)
+		ptr = base + 0x38;
+	else if (gpio < 32 * 3)
+		ptr = base + 0x60;
+	else if (gpio < 32 * 4)
+		ptr = base + 0x88;
+	else if (gpio < 32 * 5)
+		ptr = base + 0xb0;
+	else
+		ptr = NULL;
+	return ptr;
 }
 
 static inline struct davinci_gpio_regs __iomem *irq2controller(int irq)
@@ -113,6 +141,7 @@ static int __init davinci_gpio_setup(void)
 	int i, base;
 	unsigned ngpio;
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
+	struct davinci_gpio_regs *regs;
 
 	/*
 	 * The gpio banks conceptually expose a segmented bitmap,
@@ -141,11 +170,18 @@ static int __init davinci_gpio_setup(void)
 		if (chips[i].chip.ngpio > 32)
 			chips[i].chip.ngpio = 32;
 
-		chips[i].regs = gpio2controller(base);
+		regs = gpio2regs(base);
+		chips[i].regs = regs;
+		chips[i].set_data = &regs->set_data;
+		chips[i].clr_data = &regs->clr_data;
+		chips[i].in_data = &regs->in_data;
 
 		gpiochip_add(&chips[i].chip);
 	}
 
+	soc_info->gpio_ctlrs = chips;
+	soc_info->gpio_ctlrs_num = DIV_ROUND_UP(ngpio, 32);
+
 	davinci_gpio_irq_setup();
 	return 0;
 }
@@ -358,7 +394,7 @@ static int __init davinci_gpio_irq_setup(void)
 		gpio_irqchip_unbanked.set_type = gpio_irq_type_unbanked;
 
 		/* default trigger: both edges */
-		g = gpio2controller(0);
+		g = gpio2regs(0);
 		__raw_writel(~0, &g->set_falling);
 		__raw_writel(~0, &g->set_rising);
 
@@ -383,7 +419,7 @@ static int __init davinci_gpio_irq_setup(void)
 		unsigned		i;
 
 		/* disabled by default, enabled only as needed */
-		g = gpio2controller(gpio);
+		g = gpio2regs(gpio);
 		__raw_writel(~0, &g->clr_falling);
 		__raw_writel(~0, &g->clr_rising);
 
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 50a955f..c85c795 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -34,6 +34,8 @@ struct davinci_timer_info {
 	unsigned int			clocksource_id;
 };
 
+struct davinci_gpio_controller;
+
 /* SoC specific init support */
 struct davinci_soc_info {
 	struct map_desc			*io_desc;
@@ -58,6 +60,8 @@ struct davinci_soc_info {
 	unsigned			gpio_num;
 	unsigned			gpio_irq;
 	unsigned			gpio_unbanked;
+	struct davinci_gpio_controller	*gpio_ctlrs;
+	int				gpio_ctlrs_num;
 	struct platform_device		*serial_dev;
 	struct emac_platform_data	*emac_pdata;
 	dma_addr_t			sram_dma;
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index bdab001..a8ca4ce 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -45,23 +45,13 @@
 /* Convert GPIO signal to GPIO pin number */
 #define GPIO_TO_PIN(bank, gpio)	(16 * (bank) + (gpio))
 
-struct davinci_gpio_regs {
-	u32	dir;
-	u32	out_data;
-	u32	set_data;
-	u32	clr_data;
-	u32	in_data;
-	u32	set_rising;
-	u32	clr_rising;
-	u32	set_falling;
-	u32	clr_falling;
-	u32	intstat;
-};
-
 struct davinci_gpio_controller {
 	struct davinci_gpio_regs __iomem *regs;
 	struct gpio_chip	chip;
 	int			irq_base;
+	void __iomem		*set_data;
+	void __iomem		*clr_data;
+	void __iomem		*in_data;
 };
 
 /* The __gpio_to_controller() and __gpio_mask() functions inline to constants
@@ -73,25 +63,16 @@ struct davinci_gpio_controller {
  *
  * These are NOT part of the cross-platform GPIO interface
  */
-static inline struct davinci_gpio_regs __iomem *
+static inline struct davinci_gpio_controller *
 __gpio_to_controller(unsigned gpio)
 {
-	void __iomem *ptr;
-	void __iomem *base = davinci_soc_info.gpio_base;
-
-	if (gpio < 32 * 1)
-		ptr = base + 0x10;
-	else if (gpio < 32 * 2)
-		ptr = base + 0x38;
-	else if (gpio < 32 * 3)
-		ptr = base + 0x60;
-	else if (gpio < 32 * 4)
-		ptr = base + 0x88;
-	else if (gpio < 32 * 5)
-		ptr = base + 0xb0;
-	else
-		ptr = NULL;
-	return ptr;
+	struct davinci_gpio_controller *ctlrs = davinci_soc_info.gpio_ctlrs;
+	int index = gpio / 32;
+
+	if (!ctlrs || index >= davinci_soc_info.gpio_ctlrs_num)
+		return NULL;
+
+	return ctlrs + index;
 }
 
 static inline u32 __gpio_mask(unsigned gpio)
@@ -107,16 +88,16 @@ static inline u32 __gpio_mask(unsigned gpio)
  */
 static inline void gpio_set_value(unsigned gpio, int value)
 {
-	if (__builtin_constant_p(value) && gpio < DAVINCI_N_GPIO) {
-		struct davinci_gpio_regs	__iomem *g;
-		u32			mask;
+	if (__builtin_constant_p(value) && gpio < davinci_soc_info.gpio_num) {
+		struct davinci_gpio_controller *ctlr;
+		u32				mask;
 
-		g = __gpio_to_controller(gpio);
+		ctlr = __gpio_to_controller(gpio);
 		mask = __gpio_mask(gpio);
 		if (value)
-			__raw_writel(mask, &g->set_data);
+			__raw_writel(mask, ctlr->set_data);
 		else
-			__raw_writel(mask, &g->clr_data);
+			__raw_writel(mask, ctlr->clr_data);
 		return;
 	}
 
@@ -134,18 +115,18 @@ static inline void gpio_set_value(unsigned gpio, int value)
  */
 static inline int gpio_get_value(unsigned gpio)
 {
-	struct davinci_gpio_regs	__iomem *g;
+	struct davinci_gpio_controller *ctlr;
 
-	if (!__builtin_constant_p(gpio) || gpio >= DAVINCI_N_GPIO)
+	if (!__builtin_constant_p(gpio) || gpio >= davinci_soc_info.gpio_num)
 		return __gpio_get_value(gpio);
 
-	g = __gpio_to_controller(gpio);
-	return __gpio_mask(gpio) & __raw_readl(&g->in_data);
+	ctlr = __gpio_to_controller(gpio);
+	return __gpio_mask(gpio) & __raw_readl(ctlr->in_data);
 }
 
 static inline int gpio_cansleep(unsigned gpio)
 {
-	if (__builtin_constant_p(gpio) && gpio < DAVINCI_N_GPIO)
+	if (__builtin_constant_p(gpio) && gpio < davinci_soc_info.gpio_num)
 		return 0;
 	else
 		return __gpio_cansleep(gpio);
-- 
1.6.3.3


From drogers at echo360.com  Mon Apr 12 17:39:11 2010
From: drogers at echo360.com (Doug Rogers)
Date: Mon, 12 Apr 2010 18:39:11 -0400
Subject: Removing excessive printing of NAND bad eraseblocks in nand/nand_bbt.c
Message-ID: <524D5246B64CA84EAB367B8147F0C7B70165EB4A@echoms01.echo360.local>

Howdy,

 

I don't know if this is the proper place for this, so please direct me
elsewhere if it is not.

 

I get a LOT of NAND bad eraseblocks when booting my dm6467t DVEVM. I've
never dealt with NAND ROM before so I was surprised by how many bad
eraseblocks are generated. I've seen elsewhere that this is to be
expected. So I'm curious - does it need to be so excessively printed if
it is relatively normal?

 

I've made a patch to drivers/mtd/nand/nand_bbt.c to remove printing of
each individual block. Instead, a warning message is generated that
displays the number of blocks and the location of the first bad
eraseblock.

 

Do you think this is something worth doing permanently?

 

Doug

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100412/80e46c92/attachment-0001.html>

From Jon.Povey at racelogic.co.uk  Tue Apr 13 01:35:11 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Tue, 13 Apr 2010 07:35:11 +0100
Subject: DM355 RBL updates for ECC layout?
Message-ID: <70E876B0EA86DD4BAF101844BC814DFE0FDD1A13@Cloud.RL.local>

Can anyone point me at more information about a DM355 RBL change to NAND ECC layout handling? This email from David Brownell on the u-boot mailing list

http://www.mail-archive.com/u-boot at lists.denx.de/msg21042.html

mentions a discussion here and hints at an RBL change, but I can't see anything obvious in the archives.

As far as I know DM355 RBL can only handle "infix" ECC layout on 2KB page NAND, i.e. clobbering manufacturer bad block markers.

Just want to check that:

- DM355 RBL can't handle the "new"/"correct" layout (ECC together at end of page)

- We're not going to buy another batch of DM355s and suddenly find a new RBL which expects a different ECC layout. If so I better start planning now..

Thanks,

--
Jon Povey
jon.povey at racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network



From nyhetsbrev at dokumera.anp.se  Tue Apr 13 02:17:20 2010
From: nyhetsbrev at dokumera.anp.se (DokuMera Nyhetsbrev)
Date: Tue, 13 Apr 2010 09:17:20 +0200
Subject: =?iso-8859-1?B?RHUgbeVzdGUgam9iYmEgcOUgc2VtZXN0ZXJuIQ==?=
Message-ID: <C3AAA1019C3F48FCBD4B3C3A4AB53603@dokumera.anp.se>

Om du har problem med att l?sa detta e-postmeddelande, klicka h?r (http://www.anp.se/newsletterweb/636409/44405D4074454B5C447043475843) f?r en webb-version.



V?rt nyhetsbrev skickas automatiskt till v?ra kunder och intressenter. Vill du inte ha detta nyhetsbrev fram?ver, klicka h?r f?r att avprenumerera (http://www.anp.se/oa/636409/44405D4074454B5C447043475843).




Nyhetsbrev 15/2010Detta nyhetsbrev ?r skickat till: davinci-linux-open-source at linux.davincidsp.com


 (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se&from=173902333&prefix=dm) (http://www.anp.se/taf/636409/44405D4074454B5C447043475843)  (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_newsletters.asp&from=173902333&prefix=dm)  (http://www.anp.se/newsletter.asp?sqid=636409&sid=44405D4074454B5C447043475843&print=true)


"Du m?ste jobba, annars f?rlorar vi en best?llning!"

Hur gick det med semesterplaneringen f?rra ?ret? F?rlorade ni aff?rer och kunder p? grund av personalbrist? Var det ett tidskr?vande pussel f?r att medarbetarna skulle f? semester n?r de ville? 

G?r semesterplaneringen smidigare och snabbare i ?r genom att anv?nda DokuMeras mallar f?r bland annat Semesterpolicy och Semesterplanering. D? f?r du ordning p? personalplaneringen och hj?lp med att f?lja lagar och regler. Dessutom f?r du mer tid ?ver till aff?rerna. 

Du kan ocks? skaffa v?rt f?retagspaket. H?r finns mallar, checklistor, policys, expertsvar och mycket mer som underl?ttar, och juridiskt s?kerst?ller, arbetet i ditt f?retag. 

Kontakta oss s? ber?ttar vi mer! Ring: 08 - 664 04 50, mejla: info at dokumera.se, eller bes?k oss p? www.dokumera.se. Det g?r ocks? bra att meddela oss, s? ringer vi upp.



Veckans dokument

Semesterpolicy >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/semesterpolicy_4293_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Semesterplanering >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/semesterplanering_2006_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Anst?llningsavtal vikariat 2010 >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/aa04_anstallningsavtal_vikariat_373_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Ledighetsans?kan >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/ledighetsansokan_496_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)


DokuMeras bok

F?rsta Dokumenthj?lpen ?r byggd p? DokuMeras dokumentmallar och beskriver de 100 viktigaste dokumenten ditt f?retag beh?ver. Alla dokument presenteras l?ttf?rst?eligt med begripliga texter, smarta tips och illustrerande exempel.

Best?ll h?r! (http://www.dokumera.se/forsta_dokumenthjalpen_4245_dd.html)



 (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/foretagspaketet_1321_dc.html&from=173902333&prefix=dm) (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_atq_ppdviewer.asp&from=173902333&prefix=dm) (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/styckvisa_dokumentmallar_1330_dc.html&from=173902333&prefix=dm)

 (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_contactusmessage.asp&from=173902333&prefix=dm)

F?r en kostnadsfri exklusiv presentation av hur DokuMera kan spara tiotusentals kronor ?t just mitt f?retag.
Givetvis ?r du varmt v?lkommen att ringa oss p? 08-664 04 50.

Inneh?llet i nyhetsbrev ska inte tolkas som ett ?tagande fr?n DokuMeras sida. Informationen s?nds ut i befintligt skick, utan garantier och digitala signaturer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100413/4070b3b2/attachment-0001.html>

From a.auer at zydacron.com  Tue Apr 13 03:27:12 2010
From: a.auer at zydacron.com (Andreas Auer)
Date: Tue, 13 Apr 2010 10:27:12 +0200
Subject: UVC webcam problem
Message-ID: <hq19vt$paf$1@dough.gmane.org>

Hi,

I'm trying to get a UVC webcam working with the latest khilman kernel 
(2.6.34) on a Davinci EVM like board with DM6446 processor.

I'm able to request the buffers and queue them without errors. But if I 
switch on the streaming the UVC driver tells me:
   "uvcvideo: USB isochronous frame lost (-18)."

Some time ago, I tried the 2.6.32 kernel from the arago project and 
webcam capturing was working out of the box but WLAN was not working. 
(so, I switched to the khilman kernel).

Maybe, someone can help me with the uvc webcam problem!!!

Thanks,
Andreas


From mrechberger at gmail.com  Tue Apr 13 03:53:47 2010
From: mrechberger at gmail.com (Markus Rechberger)
Date: Tue, 13 Apr 2010 10:53:47 +0200
Subject: UVC webcam problem
In-Reply-To: <hq19vt$paf$1@dough.gmane.org>
References: <hq19vt$paf$1@dough.gmane.org>
Message-ID: <s2hd9def9db1004130153pfb9b6f98v1ada2efffa2e233c@mail.gmail.com>

On Tue, Apr 13, 2010 at 10:27 AM, Andreas Auer <a.auer at zydacron.com> wrote:
> Hi,
>
> I'm trying to get a UVC webcam working with the latest khilman kernel
> (2.6.34) on a Davinci EVM like board with DM6446 processor.
>
> I'm able to request the buffers and queue them without errors. But if I
> switch on the streaming the UVC driver tells me:
> ?"uvcvideo: USB isochronous frame lost (-18)."
>
> Some time ago, I tried the 2.6.32 kernel from the arago project and webcam
> capturing was working out of the box but WLAN was not working. (so, I
> switched to the khilman kernel).
>
> Maybe, someone can help me with the uvc webcam problem!!!
>

with our tests the DM6446 only supported up to around 4.5 mbyte of
isochronous data...
Raw Analog TV 720x576x25 requires around 170 mbit, I guess webcams are
near to that level there's no chance to get such a thing work.
Maybe MJPEG or MPEG based devices can work with it.

Markus

From swami.iyer at ti.com  Tue Apr 13 04:00:18 2010
From: swami.iyer at ti.com (Subbrathnam, Swaminathan)
Date: Tue, 13 Apr 2010 14:30:18 +0530
Subject: UVC webcam problem
In-Reply-To: <s2hd9def9db1004130153pfb9b6f98v1ada2efffa2e233c@mail.gmail.com>
References: <hq19vt$paf$1@dough.gmane.org>
	<s2hd9def9db1004130153pfb9b6f98v1ada2efffa2e233c@mail.gmail.com>
Message-ID: <FCCFB4CDC6E5564B9182F639FC3560870304B3DF2E@dbde02.ent.ti.com>



> -----Original Message-----
> From: davinci-linux-open-source-bounces at linux.davincidsp.com
> [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf
> Of Markus Rechberger
> Sent: Tuesday, April 13, 2010 2:24 PM
> To: Andreas Auer
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Subject: Re: UVC webcam problem
> 
> On Tue, Apr 13, 2010 at 10:27 AM, Andreas Auer <a.auer at zydacron.com>
> wrote:
> > Hi,
> >
> > I'm trying to get a UVC webcam working with the latest khilman kernel
> > (2.6.34) on a Davinci EVM like board with DM6446 processor.
> >
> > I'm able to request the buffers and queue them without errors. But if I
> > switch on the streaming the UVC driver tells me:
> > ?"uvcvideo: USB isochronous frame lost (-18)."
> >
> > Some time ago, I tried the 2.6.32 kernel from the arago project and
> webcam
> > capturing was working out of the box but WLAN was not working. (so, I
> > switched to the khilman kernel).
> >
> > Maybe, someone can help me with the uvc webcam problem!!!
> >
> 
> with our tests the DM6446 only supported up to around 4.5 mbyte of
> isochronous data...

DM644x USB supports only normal ISO mode hence the max ISO bandwidth achievable is limited to ~64Mbps.

> Raw Analog TV 720x576x25 requires around 170 mbit, I guess webcams are
> near to that level there's no chance to get such a thing work.
> Maybe MJPEG or MPEG based devices can work with it.


One could use BULK mode if higher throughput is needed but not may webcams support such a transport.

> 
> Markus
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From a.auer at zydacron.com  Tue Apr 13 04:01:47 2010
From: a.auer at zydacron.com (Andreas Auer)
Date: Tue, 13 Apr 2010 11:01:47 +0200
Subject: UVC webcam problem
In-Reply-To: <s2hd9def9db1004130153pfb9b6f98v1ada2efffa2e233c@mail.gmail.com>
References: <hq19vt$paf$1@dough.gmane.org>
	<s2hd9def9db1004130153pfb9b6f98v1ada2efffa2e233c@mail.gmail.com>
Message-ID: <4BC432FB.5000502@zydacron.com>

Markus Rechberger schrieb:
> On Tue, Apr 13, 2010 at 10:27 AM, Andreas Auer <a.auer at zydacron.com> wrote:
>> Hi,
>>
>> I'm trying to get a UVC webcam working with the latest khilman kernel
>> (2.6.34) on a Davinci EVM like board with DM6446 processor.
>>
>> I'm able to request the buffers and queue them without errors. But if I
>> switch on the streaming the UVC driver tells me:
>>  "uvcvideo: USB isochronous frame lost (-18)."
>>
>> Some time ago, I tried the 2.6.32 kernel from the arago project and webcam
>> capturing was working out of the box but WLAN was not working. (so, I
>> switched to the khilman kernel).
>>
>> Maybe, someone can help me with the uvc webcam problem!!!
>>
> 
> with our tests the DM6446 only supported up to around 4.5 mbyte of
> isochronous data...
> Raw Analog TV 720x576x25 requires around 170 mbit, I guess webcams are
> near to that level there's no chance to get such a thing work.
> Maybe MJPEG or MPEG based devices can work with it.

Thanks for your reply. I have a Logitech QuickCam Communicate Deluxe 
with MJPEG format. And this webcam is working with the 2.6.32 kernel 
from the arago project. So, I think this cam should be working.

Does anyone know what's the above "status code" -18 means??

Thanks,
Andreas

From swami.iyer at ti.com  Tue Apr 13 04:08:18 2010
From: swami.iyer at ti.com (Subbrathnam, Swaminathan)
Date: Tue, 13 Apr 2010 14:38:18 +0530
Subject: UVC webcam problem
In-Reply-To: <4BC432FB.5000502@zydacron.com>
References: <hq19vt$paf$1@dough.gmane.org>
	<s2hd9def9db1004130153pfb9b6f98v1ada2efffa2e233c@mail.gmail.com>
	<4BC432FB.5000502@zydacron.com>
Message-ID: <FCCFB4CDC6E5564B9182F639FC3560870304B3DF40@dbde02.ent.ti.com>

Andreas,

Pl. ensure that the FIFO is configured correctly.  Probably this error could mean you need a 1024 byte fifo space and it is not available.  If so increase the fifo space in musb_core.c file.

Regards
Swami

> -----Original Message-----
> From: davinci-linux-open-source-
> bounces+swami.iyer=ti.com at linux.davincidsp.com [mailto:davinci-linux-open-
> source-bounces+swami.iyer=ti.com at linux.davincidsp.com] On Behalf Of
> Andreas Auer
> Sent: Tuesday, April 13, 2010 2:32 PM
> To: Markus Rechberger
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Subject: Re: UVC webcam problem
> 
> Markus Rechberger schrieb:
> > On Tue, Apr 13, 2010 at 10:27 AM, Andreas Auer <a.auer at zydacron.com>
> wrote:
> >> Hi,
> >>
> >> I'm trying to get a UVC webcam working with the latest khilman kernel
> >> (2.6.34) on a Davinci EVM like board with DM6446 processor.
> >>
> >> I'm able to request the buffers and queue them without errors. But if I
> >> switch on the streaming the UVC driver tells me:
> >>  "uvcvideo: USB isochronous frame lost (-18)."
> >>
> >> Some time ago, I tried the 2.6.32 kernel from the arago project and
> webcam
> >> capturing was working out of the box but WLAN was not working. (so, I
> >> switched to the khilman kernel).
> >>
> >> Maybe, someone can help me with the uvc webcam problem!!!
> >>
> >
> > with our tests the DM6446 only supported up to around 4.5 mbyte of
> > isochronous data...
> > Raw Analog TV 720x576x25 requires around 170 mbit, I guess webcams are
> > near to that level there's no chance to get such a thing work.
> > Maybe MJPEG or MPEG based devices can work with it.
> 
> Thanks for your reply. I have a Logitech QuickCam Communicate Deluxe
> with MJPEG format. And this webcam is working with the 2.6.32 kernel
> from the arago project. So, I think this cam should be working.
> 
> Does anyone know what's the above "status code" -18 means??
> 
> Thanks,
> Andreas
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From mrechberger at gmail.com  Tue Apr 13 04:08:50 2010
From: mrechberger at gmail.com (Markus Rechberger)
Date: Tue, 13 Apr 2010 11:08:50 +0200
Subject: UVC webcam problem
In-Reply-To: <FCCFB4CDC6E5564B9182F639FC3560870304B3DF2E@dbde02.ent.ti.com>
References: <hq19vt$paf$1@dough.gmane.org>
	<s2hd9def9db1004130153pfb9b6f98v1ada2efffa2e233c@mail.gmail.com>
	<FCCFB4CDC6E5564B9182F639FC3560870304B3DF2E@dbde02.ent.ti.com>
Message-ID: <q2id9def9db1004130208z9cf06adbvd4176f5df7f8ba66@mail.gmail.com>

On Tue, Apr 13, 2010 at 11:00 AM, Subbrathnam, Swaminathan
<swami.iyer at ti.com> wrote:
>
>
>> -----Original Message-----
>> From: davinci-linux-open-source-bounces at linux.davincidsp.com
>> [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf
>> Of Markus Rechberger
>> Sent: Tuesday, April 13, 2010 2:24 PM
>> To: Andreas Auer
>> Cc: davinci-linux-open-source at linux.davincidsp.com
>> Subject: Re: UVC webcam problem
>>
>> On Tue, Apr 13, 2010 at 10:27 AM, Andreas Auer <a.auer at zydacron.com>
>> wrote:
>> > Hi,
>> >
>> > I'm trying to get a UVC webcam working with the latest khilman kernel
>> > (2.6.34) on a Davinci EVM like board with DM6446 processor.
>> >
>> > I'm able to request the buffers and queue them without errors. But if I
>> > switch on the streaming the UVC driver tells me:
>> > ?"uvcvideo: USB isochronous frame lost (-18)."
>> >
>> > Some time ago, I tried the 2.6.32 kernel from the arago project and
>> webcam
>> > capturing was working out of the box but WLAN was not working. (so, I
>> > switched to the khilman kernel).
>> >
>> > Maybe, someone can help me with the uvc webcam problem!!!
>> >
>>
>> with our tests the DM6446 only supported up to around 4.5 mbyte of
>> isochronous data...
>
> DM644x USB supports only normal ISO mode hence the max ISO bandwidth achievable is limited to ~64Mbps.
>
not even reliable, we have USB DVB-C/T/ATSC/ISDB-T devices which
support exactly 60 MBit, the transfer mode is switchable between
ISOC and BULK, we finally managed to get those devices work by
enabling hardware PID filtering.
45mbit already caused some issues with it, HDTV (720p) usually
requeris around 15 mbit (one channel) which works
well with our devices. Isochronous used to hang up for no reason (the
usb host controller/driver was(is?) quite unstable as well
with isochronous and higher data rates)
However Bulk works fine with around 4.5 mbyte/sec

Markus
>> Raw Analog TV 720x576x25 requires around 170 mbit, I guess webcams are
>> near to that level there's no chance to get such a thing work.
>> Maybe MJPEG or MPEG based devices can work with it.
>
>
> One could use BULK mode if higher throughput is needed but not may webcams support such a transport.
>
>>
>> Markus
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source at linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>

From swami.iyer at ti.com  Tue Apr 13 04:15:03 2010
From: swami.iyer at ti.com (Subbrathnam, Swaminathan)
Date: Tue, 13 Apr 2010 14:45:03 +0530
Subject: UVC webcam problem
In-Reply-To: <q2id9def9db1004130208z9cf06adbvd4176f5df7f8ba66@mail.gmail.com>
References: <hq19vt$paf$1@dough.gmane.org>
	<s2hd9def9db1004130153pfb9b6f98v1ada2efffa2e233c@mail.gmail.com>
	<FCCFB4CDC6E5564B9182F639FC3560870304B3DF2E@dbde02.ent.ti.com>
	<q2id9def9db1004130208z9cf06adbvd4176f5df7f8ba66@mail.gmail.com>
Message-ID: <FCCFB4CDC6E5564B9182F639FC3560870304B3DF55@dbde02.ent.ti.com>



> -----Original Message-----
> From: Markus Rechberger [mailto:mrechberger at gmail.com]
> Sent: Tuesday, April 13, 2010 2:39 PM
> To: Subbrathnam, Swaminathan
> Cc: Andreas Auer; davinci-linux-open-source at linux.davincidsp.com
> Subject: Re: UVC webcam problem
> 
> On Tue, Apr 13, 2010 at 11:00 AM, Subbrathnam, Swaminathan
> <swami.iyer at ti.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: davinci-linux-open-source-bounces at linux.davincidsp.com
> >> [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On
> Behalf
> >> Of Markus Rechberger
> >> Sent: Tuesday, April 13, 2010 2:24 PM
> >> To: Andreas Auer
> >> Cc: davinci-linux-open-source at linux.davincidsp.com
> >> Subject: Re: UVC webcam problem
> >>
> >> On Tue, Apr 13, 2010 at 10:27 AM, Andreas Auer <a.auer at zydacron.com>
> >> wrote:
> >> > Hi,
> >> >
> >> > I'm trying to get a UVC webcam working with the latest khilman kernel
> >> > (2.6.34) on a Davinci EVM like board with DM6446 processor.
> >> >
> >> > I'm able to request the buffers and queue them without errors. But if
> I
> >> > switch on the streaming the UVC driver tells me:
> >> > ?"uvcvideo: USB isochronous frame lost (-18)."
> >> >
> >> > Some time ago, I tried the 2.6.32 kernel from the arago project and
> >> webcam
> >> > capturing was working out of the box but WLAN was not working. (so, I
> >> > switched to the khilman kernel).
> >> >
> >> > Maybe, someone can help me with the uvc webcam problem!!!
> >> >
> >>
> >> with our tests the DM6446 only supported up to around 4.5 mbyte of
> >> isochronous data...
> >
> > DM644x USB supports only normal ISO mode hence the max ISO bandwidth
> achievable is limited to ~64Mbps.
> >
> not even reliable, we have USB DVB-C/T/ATSC/ISDB-T devices which
> support exactly 60 MBit, the transfer mode is switchable between
> ISOC and BULK, we finally managed to get those devices work by
> enabling hardware PID filtering.
> 45mbit already caused some issues with it, HDTV (720p) usually
> requeris around 15 mbit (one channel) which works
> well with our devices. Isochronous used to hang up for no reason (the
> usb host controller/driver was(is?) quite unstable as well
> with isochronous and higher data rates)
> However Bulk works fine with around 4.5 mbyte/sec

I have personally verified the exact use case you have mentioned and seen it working just fine (with Haupaugue 1950 device as I remember).  ISO functions as spec'ed and so does Bulk.  4.5MBps is too low pl. refer to DM644x release data sheets and you can see much higher numbers for throughput in the USB MSC contexts.

The problem could have been with the older drivers and I do acknowledge that there were instability issues with them.

> 
> Markus
> >> Raw Analog TV 720x576x25 requires around 170 mbit, I guess webcams are
> >> near to that level there's no chance to get such a thing work.
> >> Maybe MJPEG or MPEG based devices can work with it.
> >
> >
> > One could use BULK mode if higher throughput is needed but not may
> webcams support such a transport.
> >
> >>
> >> Markus
> >> _______________________________________________
> >> Davinci-linux-open-source mailing list
> >> Davinci-linux-open-source at linux.davincidsp.com
> >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> >

From mrechberger at gmail.com  Tue Apr 13 04:50:37 2010
From: mrechberger at gmail.com (Markus Rechberger)
Date: Tue, 13 Apr 2010 11:50:37 +0200
Subject: UVC webcam problem
In-Reply-To: <FCCFB4CDC6E5564B9182F639FC3560870304B3DF55@dbde02.ent.ti.com>
References: <hq19vt$paf$1@dough.gmane.org>
	<s2hd9def9db1004130153pfb9b6f98v1ada2efffa2e233c@mail.gmail.com>
	<FCCFB4CDC6E5564B9182F639FC3560870304B3DF2E@dbde02.ent.ti.com>
	<q2id9def9db1004130208z9cf06adbvd4176f5df7f8ba66@mail.gmail.com>
	<FCCFB4CDC6E5564B9182F639FC3560870304B3DF55@dbde02.ent.ti.com>
Message-ID: <t2nd9def9db1004130250h420bb68ck5d752e6a2d7fea94@mail.gmail.com>

On Tue, Apr 13, 2010 at 11:15 AM, Subbrathnam, Swaminathan
<swami.iyer at ti.com> wrote:
>
>
>> -----Original Message-----
>> From: Markus Rechberger [mailto:mrechberger at gmail.com]
>> Sent: Tuesday, April 13, 2010 2:39 PM
>> To: Subbrathnam, Swaminathan
>> Cc: Andreas Auer; davinci-linux-open-source at linux.davincidsp.com
>> Subject: Re: UVC webcam problem
>>
>> On Tue, Apr 13, 2010 at 11:00 AM, Subbrathnam, Swaminathan
>> <swami.iyer at ti.com> wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: davinci-linux-open-source-bounces at linux.davincidsp.com
>> >> [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On
>> Behalf
>> >> Of Markus Rechberger
>> >> Sent: Tuesday, April 13, 2010 2:24 PM
>> >> To: Andreas Auer
>> >> Cc: davinci-linux-open-source at linux.davincidsp.com
>> >> Subject: Re: UVC webcam problem
>> >>
>> >> On Tue, Apr 13, 2010 at 10:27 AM, Andreas Auer <a.auer at zydacron.com>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > I'm trying to get a UVC webcam working with the latest khilman kernel
>> >> > (2.6.34) on a Davinci EVM like board with DM6446 processor.
>> >> >
>> >> > I'm able to request the buffers and queue them without errors. But if
>> I
>> >> > switch on the streaming the UVC driver tells me:
>> >> > ?"uvcvideo: USB isochronous frame lost (-18)."
>> >> >
>> >> > Some time ago, I tried the 2.6.32 kernel from the arago project and
>> >> webcam
>> >> > capturing was working out of the box but WLAN was not working. (so, I
>> >> > switched to the khilman kernel).
>> >> >
>> >> > Maybe, someone can help me with the uvc webcam problem!!!
>> >> >
>> >>
>> >> with our tests the DM6446 only supported up to around 4.5 mbyte of
>> >> isochronous data...
>> >
>> > DM644x USB supports only normal ISO mode hence the max ISO bandwidth
>> achievable is limited to ~64Mbps.
>> >
>> not even reliable, we have USB DVB-C/T/ATSC/ISDB-T devices which
>> support exactly 60 MBit, the transfer mode is switchable between
>> ISOC and BULK, we finally managed to get those devices work by
>> enabling hardware PID filtering.
>> 45mbit already caused some issues with it, HDTV (720p) usually
>> requeris around 15 mbit (one channel) which works
>> well with our devices. Isochronous used to hang up for no reason (the
>> usb host controller/driver was(is?) quite unstable as well
>> with isochronous and higher data rates)
>> However Bulk works fine with around 4.5 mbyte/sec
>
> I have personally verified the exact use case you have mentioned and seen it working just fine (with Haupaugue 1950 device as I remember). ?ISO functions as spec'ed and so does Bulk. ?4.5MBps is too low pl. refer to DM644x release data sheets and you can see much higher numbers for throughput in the USB MSC contexts.
>

> The problem could have been with the older drivers and I do acknowledge that there were instability issues with them.
>

the problem we had with 45mbit was USB BUS resets and occasional
hangups when the transfer stopped (although we were also using 2.6.18
back then). Maybe things improved... a customer got a patch from TI
back then the reset recovered but it still caused glitches in the
stream. Maybe things improved a little bit further in the meantime
(last time we tested it was exactly 1 year ago).
DVB-C gains a much higher bandwidth than ATSC or DVB-T devices
(clearQAM might be near but I'm not sure).

Just in case as a reference:
http://support.sundtek.com/index.php/topic,4.0.html (DVB-T/DVB-C)
http://support.sundtek.com/index.php/topic,87.0.html (ATSC/Qam)

Markus

From mrechberger at gmail.com  Tue Apr 13 04:54:05 2010
From: mrechberger at gmail.com (Markus Rechberger)
Date: Tue, 13 Apr 2010 11:54:05 +0200
Subject: UVC webcam problem
In-Reply-To: <4BC432FB.5000502@zydacron.com>
References: <hq19vt$paf$1@dough.gmane.org>
	<s2hd9def9db1004130153pfb9b6f98v1ada2efffa2e233c@mail.gmail.com>
	<4BC432FB.5000502@zydacron.com>
Message-ID: <g2xd9def9db1004130254zb7feb782yc9d41d5f328d27b1@mail.gmail.com>

On Tue, Apr 13, 2010 at 11:01 AM, Andreas Auer <a.auer at zydacron.com> wrote:
> Markus Rechberger schrieb:
>>
>> On Tue, Apr 13, 2010 at 10:27 AM, Andreas Auer <a.auer at zydacron.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to get a UVC webcam working with the latest khilman kernel
>>> (2.6.34) on a Davinci EVM like board with DM6446 processor.
>>>
>>> I'm able to request the buffers and queue them without errors. But if I
>>> switch on the streaming the UVC driver tells me:
>>> ?"uvcvideo: USB isochronous frame lost (-18)."
>>>
>>> Some time ago, I tried the 2.6.32 kernel from the arago project and
>>> webcam
>>> capturing was working out of the box but WLAN was not working. (so, I
>>> switched to the khilman kernel).
>>>
>>> Maybe, someone can help me with the uvc webcam problem!!!
>>>
>>
>> with our tests the DM6446 only supported up to around 4.5 mbyte of
>> isochronous data...
>> Raw Analog TV 720x576x25 requires around 170 mbit, I guess webcams are
>> near to that level there's no chance to get such a thing work.
>> Maybe MJPEG or MPEG based devices can work with it.
>
> Thanks for your reply. I have a Logitech QuickCam Communicate Deluxe with
> MJPEG format. And this webcam is working with the 2.6.32 kernel from the
> arago project. So, I think this cam should be working.
>
> Does anyone know what's the above "status code" -18 means??
>

that something with the usb controller/driver (not the cam driver) is broken.
On the other side you also need to find an accelerated solution to
decode MJPEG ... (the ARM part of the dm6446 will not help you in that
case).
You might better look for an MPEG capable USB camera (although I don't
know which of them are supported with Linux)

Markus

From sshtylyov at mvista.com  Tue Apr 13 06:27:32 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Tue, 13 Apr 2010 15:27:32 +0400
Subject: [PATCH 4/8] Davinci: gpio - minor cleanup
In-Reply-To: <1271106933-13911-5-git-send-email-cyril@ti.com>
References: <1271106933-13911-1-git-send-email-cyril@ti.com>
	<1271106933-13911-2-git-send-email-cyril@ti.com>
	<1271106933-13911-3-git-send-email-cyril@ti.com>
	<1271106933-13911-4-git-send-email-cyril@ti.com>
	<1271106933-13911-5-git-send-email-cyril@ti.com>
Message-ID: <4BC45524.70805@mvista.com>

Hello.

Cyril Chemparathy wrote:

> macroized repeated container_of()s to improve readability.
> unified direction in/out functions.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
> ---
>  arch/arm/mach-davinci/gpio.c |   47 +++++++++++++++++++++--------------------
>  1 files changed, 24 insertions(+), 23 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
> index 5476ad1..bb55f41 100644
> --- a/arch/arm/mach-davinci/gpio.c
> +++ b/arch/arm/mach-davinci/gpio.c
>   
[...]
> @@ -54,21 +57,36 @@ static int __init davinci_gpio_irq_setup(void);
>   * needed, and enable the GPIO clock.
>   */
>  
> -static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
> +static inline int __davinci_direction(struct gpio_chip *chip,
> +			unsigned offset, bool out)
>  {
> -	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
> +	struct davinci_gpio *d = chip2controller(chip);
>  	struct gpio_controller __iomem *g = d->regs;
>  	u32 temp;
>  
>  	spin_lock(&gpio_lock);
>  	temp = __raw_readl(&g->dir);
> -	temp |= (1 << offset);
> +	if (out)
> +		temp &= ~(1 << offset);
> +	else
> +		temp |= (1 << offset);
>  	__raw_writel(temp, &g->dir);
>  	spin_unlock(&gpio_lock);
>  
>  	return 0;
>  }
>  
> +static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
> +{
> +	return __davinci_direction(chip, offset, false);
> +}
> +
> +static int
> +davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
> +{
> +	return __davinci_direction(chip, offset, true);
>   

   No, this ignores 'value'. The function should also program GPIO to 
the value specified.

> @@ -78,36 +96,19 @@ static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
>   */
>  static int davinci_gpio_get(struct gpio_chip *chip, unsigned offset)
>  {
> -	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
> +	struct davinci_gpio *d = chip2controller(chip);
>  	struct gpio_controller __iomem *g = d->regs;
>  
>  	return (1 << offset) & __raw_readl(&g->in_data);
>  }
>  
> -static int
> -davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
> -{
> -	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
> -	struct gpio_controller __iomem *g = d->regs;
> -	u32 temp;
> -	u32 mask = 1 << offset;
> -
> -	spin_lock(&gpio_lock);
> -	temp = __raw_readl(&g->dir);
> -	temp &= ~mask;
> -	__raw_writel(mask, value ? &g->set_data : &g->clr_data);
>   

    Here's what you've forgotten...

> -	__raw_writel(temp, &g->dir);
> -	spin_unlock(&gpio_lock);
> -	return 0;
> -}
> -

WBR, Sergei


From a.auer at zydacron.com  Tue Apr 13 07:01:46 2010
From: a.auer at zydacron.com (Andreas Auer)
Date: Tue, 13 Apr 2010 14:01:46 +0200
Subject: UVC webcam problem
In-Reply-To: <FCCFB4CDC6E5564B9182F639FC3560870304B3DF40@dbde02.ent.ti.com>
References: <hq19vt$paf$1@dough.gmane.org>	<s2hd9def9db1004130153pfb9b6f98v1ada2efffa2e233c@mail.gmail.com>	<4BC432FB.5000502@zydacron.com>
	<FCCFB4CDC6E5564B9182F639FC3560870304B3DF40@dbde02.ent.ti.com>
Message-ID: <hq1mi6$6up$1@dough.gmane.org>

Right now, I tried to use the USB driver (the musb folder) from the 
arago kernel. With this driver I can capture the video from the webcam. 
So, something important must be different!

BUT, as I already mentioned I had a problem with "USB WLAN sticks" when 
I use the arago kernel. And this is also the case if I use the USB 
driver from the arago 2.6.32 kernel with the khilman 2.6.34 kernel.

But I need to use USB WLAN devices together with USB webcams. Maybe 
someone could help me to get this running!

One thing a forgot to mention about the used hardware is that I have a 
USB hub IC (ISP1521) between my USB devices and the USB host interface 
of the Davinci processor. Maybe this hub chip makes also some problems.

Thanks for your help so far,
Andreas

PS: I also tried to adjust the FIFO buffers but this was not the solution.

PPS: Maye, I should write a new post for the WLAN problem!?


Subbrathnam, Swaminathan schrieb:
> Andreas,
> 
> Pl. ensure that the FIFO is configured correctly.  Probably this error could mean you need a 1024 byte fifo space and it is not available.  If so increase the fifo space in musb_core.c file.
> 
> Regards
> Swami
> 
>> -----Original Message-----
>> From: davinci-linux-open-source-
>> bounces+swami.iyer=ti.com at linux.davincidsp.com [mailto:davinci-linux-open-
>> source-bounces+swami.iyer=ti.com at linux.davincidsp.com] On Behalf Of
>> Andreas Auer
>> Sent: Tuesday, April 13, 2010 2:32 PM
>> To: Markus Rechberger
>> Cc: davinci-linux-open-source at linux.davincidsp.com
>> Subject: Re: UVC webcam problem
>>
>> Markus Rechberger schrieb:
>>> On Tue, Apr 13, 2010 at 10:27 AM, Andreas Auer <a.auer at zydacron.com>
>> wrote:
>>>> Hi,
>>>>
>>>> I'm trying to get a UVC webcam working with the latest khilman kernel
>>>> (2.6.34) on a Davinci EVM like board with DM6446 processor.
>>>>
>>>> I'm able to request the buffers and queue them without errors. But if I
>>>> switch on the streaming the UVC driver tells me:
>>>>  "uvcvideo: USB isochronous frame lost (-18)."
>>>>
>>>> Some time ago, I tried the 2.6.32 kernel from the arago project and
>> webcam
>>>> capturing was working out of the box but WLAN was not working. (so, I
>>>> switched to the khilman kernel).
>>>>
>>>> Maybe, someone can help me with the uvc webcam problem!!!
>>>>
>>> with our tests the DM6446 only supported up to around 4.5 mbyte of
>>> isochronous data...
>>> Raw Analog TV 720x576x25 requires around 170 mbit, I guess webcams are
>>> near to that level there's no chance to get such a thing work.
>>> Maybe MJPEG or MPEG based devices can work with it.
>> Thanks for your reply. I have a Logitech QuickCam Communicate Deluxe
>> with MJPEG format. And this webcam is working with the 2.6.32 kernel
>> from the arago project. So, I think this cam should be working.
>>
>> Does anyone know what's the above "status code" -18 means??
>>
>> Thanks,
>> Andreas
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source at linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


From scerveau at awox.com  Tue Apr 13 07:22:17 2010
From: scerveau at awox.com (Stephane Cerveau)
Date: Tue, 13 Apr 2010 14:22:17 +0200
Subject: UVC webcam problem
References: <hq19vt$paf$1@dough.gmane.org>	<s2hd9def9db1004130153pfb9b6f98v1ada2efffa2e233c@mail.gmail.com>	<4BC432FB.5000502@zydacron.com><FCCFB4CDC6E5564B9182F639FC3560870304B3DF40@dbde02.ent.ti.com>
	<hq1mi6$6up$1@dough.gmane.org>
Message-ID: <46423D9081D5254CAFCEFF0CBC2CC9BA021C044F@jakarta.awox.com>

Hi,

I also encounter a WIFI USB issue. What sort of issue are you
encountering ? 
On my side, I download a large file from WIFI to a MSC device and after
a while, the MSC is disconnected... Indeed I encounter a STALL or a
ERROR in either TXCSR or RXCSR...
I'm still digging to understand what exactly happen.
When I download from WIFI and put the result into /dev/null and read the
MSC in the mean while, I do not encounter any problem. It seems that the
problem comes from TX/RX multiplexing with different timing  or buffer
size... 


Best regards

Stephane

-----Original Message-----
From: Andreas Auer [mailto:a.auer at zydacron.com] 
Sent: mardi 13 avril 2010 14:02
To: davinci-linux-open-source at linux.davincidsp.com
Subject: Re: UVC webcam problem

Right now, I tried to use the USB driver (the musb folder) from the 
arago kernel. With this driver I can capture the video from the webcam. 
So, something important must be different!

BUT, as I already mentioned I had a problem with "USB WLAN sticks" when 
I use the arago kernel. And this is also the case if I use the USB 
driver from the arago 2.6.32 kernel with the khilman 2.6.34 kernel.

But I need to use USB WLAN devices together with USB webcams. Maybe 
someone could help me to get this running!

One thing a forgot to mentionabout the used hardware is that I have a 
USB hub IC (ISP1521) between my USB devices and the USB host interface 
of the Davinci processor. Maybe this hub chip makes also some problems.

Thanks for your help so far,
Andreas

PS: I also tried to adjust the FIFO buffers but this was not the
solution.

PPS: Maye, I should write a new post for the WLAN problem!?


Subbrathnam, Swaminathan schrieb:
> Andreas,
> 
> Pl. ensure that the FIFO is configured correctly.  Probably this error
could mean you need a 1024 byte fifo space and it is not available.  If
so increase the fifo space in musb_core.c file.
> 
> Regards
> Swami
> 
>> -----Original Message-----
>> From: davinci-linux-open-source-
>> bounces+swami.iyer=ti.com at linux.davincidsp.com
[mailto:davinci-linux-open-
>> source-bounces+swami.iyer=ti.com at linux.davincidsp.com] On Behalf Of
>> Andreas Auer
>> Sent: Tuesday, April 13, 2010 2:32 PM
>> To: Markus Rechberger
>> Cc: davinci-linux-open-source at linux.davincidsp.com
>> Subject: Re: UVC webcam problem
>>
>> Markus Rechberger schrieb:
>>> On Tue, Apr 13, 2010 at 10:27 AM, Andreas Auer <a.auer at zydacron.com>
>> wrote:
>>>> Hi,
>>>>
>>>> I'm trying to get a UVC webcam working with the latest khilman
kernel
>>>> (2.6.34) on a Davinci EVM like board with DM6446 processor.
>>>>
>>>> I'm able to request the buffers and queue them without errors. But
if I
>>>> switch on the streaming the UVC driver tells me:
>>>>  "uvcvideo: USB isochronous frame lost (-18)."
>>>>
>>>> Some time ago, I tried the 2.6.32 kernel from the arago project and
>> webcam
>>>> capturing was working out of the box but WLAN was not working. (so,
I
>>>> switched to the khilman kernel).
>>>>
>>>> Maybe, someone can help me with the uvc webcam problem!!!
>>>>
>>> with our tests the DM6446 only supported up to around 4.5 mbyte of
>>> isochronous data...
>>> Raw Analog TV 720x576x25 requires around 170 mbit, I guess webcams
are
>>> near to that level there's no chance to get such a thing work.
>>> Maybe MJPEG or MPEG based devices can work with it.
>> Thanks for your reply. I have a Logitech QuickCam Communicate Deluxe
>> with MJPEG format. And this webcam is working with the 2.6.32 kernel
>> from the arago project. So, I think this cam should be working.
>>
>> Does anyone know what's the above "status code" -18 means??
>>
>> Thanks,
>> Andreas
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source at linux.davincidsp.com
>>
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
 

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 5024 (20100413) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 
 

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 5024 (20100413) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 

From a.auer at zydacron.com  Tue Apr 13 07:28:28 2010
From: a.auer at zydacron.com (Andreas Auer)
Date: Tue, 13 Apr 2010 14:28:28 +0200
Subject: UVC webcam problem
In-Reply-To: <46423D9081D5254CAFCEFF0CBC2CC9BA021C044F@jakarta.awox.com>
References: <hq19vt$paf$1@dough.gmane.org>	<s2hd9def9db1004130153pfb9b6f98v1ada2efffa2e233c@mail.gmail.com>	<4BC432FB.5000502@zydacron.com><FCCFB4CDC6E5564B9182F639FC3560870304B3DF40@dbde02.ent.ti.com>
	<hq1mi6$6up$1@dough.gmane.org>
	<46423D9081D5254CAFCEFF0CBC2CC9BA021C044F@jakarta.awox.com>
Message-ID: <4BC4636C.8090800@zydacron.com>

My problem is that the I can connect to an access point with WIFI but 
after requesting an IP address from the DHCP server I get disconnected.
I get also disconnected if I use a static IP and try to download a file 
or do something else. Afterwards, wpa_supplicant is not able to find an 
access point.

I get the message from syslog (logread):
"No probe response from AP 00:22:3f:7e:31:f2 after 500ms, disconnecting."

Best regards,
Andreas

Stephane Cerveau schrieb:
> Hi,
> 
> I also encounter a WIFI USB issue. What sort of issue are you
> encountering ? 
> On my side, I download a large file from WIFI to a MSC device and after
> a while, the MSC is disconnected... Indeed I encounter a STALL or a
> ERROR in either TXCSR or RXCSR...
> I'm still digging to understand what exactly happen.
> When I download from WIFI and put the result into /dev/null and read the
> MSC in the mean while, I do not encounter any problem. It seems that the
> problem comes from TX/RX multiplexing with different timing  or buffer
> size... 
> 
> 
> Best regards
> 
> Stephane
> 
> -----Original Message-----
> From: Andreas Auer [mailto:a.auer at zydacron.com] 
> Sent: mardi 13 avril 2010 14:02
> To: davinci-linux-open-source at linux.davincidsp.com
> Subject: Re: UVC webcam problem
> 
> Right now, I tried to use the USB driver (the musb folder) from the 
> arago kernel. With this driver I can capture the video from the webcam. 
> So, something important must be different!
> 
> BUT, as I already mentioned I had a problem with "USB WLAN sticks" when 
> I use the arago kernel. And this is also the case if I use the USB 
> driver from the arago 2.6.32 kernel with the khilman 2.6.34 kernel.
> 
> But I need to use USB WLAN devices together with USB webcams. Maybe 
> someone could help me to get this running!
> 
> One thing a forgot to mentionabout the used hardware is that I have a 
> USB hub IC (ISP1521) between my USB devices and the USB host interface 
> of the Davinci processor. Maybe this hub chip makes also some problems.
> 
> Thanks for your help so far,
> Andreas
> 
> PS: I also tried to adjust the FIFO buffers but this was not the
> solution.
> 
> PPS: Maye, I should write a new post for the WLAN problem!?
> 
> 
> Subbrathnam, Swaminathan schrieb:
>> Andreas,
>>
>> Pl. ensure that the FIFO is configured correctly.  Probably this error
> could mean you need a 1024 byte fifo space and it is not available.  If
> so increase the fifo space in musb_core.c file.
>> Regards
>> Swami
>>
>>> -----Original Message-----
>>> From: davinci-linux-open-source-
>>> bounces+swami.iyer=ti.com at linux.davincidsp.com
> [mailto:davinci-linux-open-
>>> source-bounces+swami.iyer=ti.com at linux.davincidsp.com] On Behalf Of
>>> Andreas Auer
>>> Sent: Tuesday, April 13, 2010 2:32 PM
>>> To: Markus Rechberger
>>> Cc: davinci-linux-open-source at linux.davincidsp.com
>>> Subject: Re: UVC webcam problem
>>>
>>> Markus Rechberger schrieb:
>>>> On Tue, Apr 13, 2010 at 10:27 AM, Andreas Auer <a.auer at zydacron.com>
>>> wrote:
>>>>> Hi,
>>>>>
>>>>> I'm trying to get a UVC webcam working with the latest khilman
> kernel
>>>>> (2.6.34) on a Davinci EVM like board with DM6446 processor.
>>>>>
>>>>> I'm able to request the buffers and queue them without errors. But
> if I
>>>>> switch on the streaming the UVC driver tells me:
>>>>>  "uvcvideo: USB isochronous frame lost (-18)."
>>>>>
>>>>> Some time ago, I tried the 2.6.32 kernel from the arago project and
>>> webcam
>>>>> capturing was working out of the box but WLAN was not working. (so,
> I
>>>>> switched to the khilman kernel).
>>>>>
>>>>> Maybe, someone can help me with the uvc webcam problem!!!
>>>>>
>>>> with our tests the DM6446 only supported up to around 4.5 mbyte of
>>>> isochronous data...
>>>> Raw Analog TV 720x576x25 requires around 170 mbit, I guess webcams
> are
>>>> near to that level there's no chance to get such a thing work.
>>>> Maybe MJPEG or MPEG based devices can work with it.
>>> Thanks for your reply. I have a Logitech QuickCam Communicate Deluxe
>>> with MJPEG format. And this webcam is working with the 2.6.32 kernel
>>> from the arago project. So, I think this cam should be working.
>>>
>>> Does anyone know what's the above "status code" -18 means??
>>>
>>> Thanks,
>>> Andreas
>>> _______________________________________________
>>> Davinci-linux-open-source mailing list
>>> Davinci-linux-open-source at linux.davincidsp.com
>>>
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>  
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 5024 (20100413) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
>  
>  
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 5024 (20100413) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
>  
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________


-- 
DI Andreas Auer
Embedded Software Developer
a.auer at zydacron.com

ZYDACRON Austria GmbH
St.-Peter-Guertel 4, 8042 Graz, AUSTRIA http://www.zydacron.com
_____________________________________________________________________
CEO: Mag. Georg Weber
Regional Court: Graz
Commercial Register: 286334f
This communication, including any attachments, may contain
confidential information of ZYDACRON, its subsidiaries or
representatives, and is intended solely for the use of the individual
or entity to which it is addressed. Any unauthorized review, use,
disclosure or distribution is prohibited.
If you believe this message was sent to you in error, please
immediately notify the sender by reply email and delete this message
without disclosing it. Thank you.
_____________________________________________________________________


From scerveau at awox.com  Tue Apr 13 07:38:52 2010
From: scerveau at awox.com (Stephane Cerveau)
Date: Tue, 13 Apr 2010 14:38:52 +0200
Subject: UVC webcam problem
References: <hq19vt$paf$1@dough.gmane.org>	<s2hd9def9db1004130153pfb9b6f98v1ada2efffa2e233c@mail.gmail.com>	<4BC432FB.5000502@zydacron.com><FCCFB4CDC6E5564B9182F639FC3560870304B3DF40@dbde02.ent.ti.com>
	<hq1mi6$6up$1@dough.gmane.org>
	<46423D9081D5254CAFCEFF0CBC2CC9BA021C044F@jakarta.awox.com>
	<4BC4636C.8090800@zydacron.com>
Message-ID: <46423D9081D5254CAFCEFF0CBC2CC9BA021C0454@jakarta.awox.com>

What sort of wifi dongle are you using ?

-----Original Message-----
From: Andreas Auer [mailto:a.auer at zydacron.com] 
Sent: mardi 13 avril 2010 14:28
To: Stephane Cerveau
Cc: davinci-linux-open-source at linux.davincidsp.com
Subject: Re: UVC webcam problem

My problem is that the I can connect to an access point with WIFI but 
after requesting an IP address from the DHCP server I get disconnected.
I get also disconnected if I use a static IP and try to download a file 
or do something else. Afterwards, wpa_supplicant is not able to find an 
access point.

I get the message from syslog (logread):
"No probe response from AP 00:22:3f:7e:31:f2 after 500ms,
disconnecting."

Best regards,
Andreas

Stephane Cerveau schrieb:
> Hi,
> 
> I also encounter a WIFI USB issue. What sort of issue are you
> encountering ? 
> On my side, I download a large file from WIFI to a MSC device and
after
> a while, the MSC is disconnected... Indeed I encounter a STALL or a
> ERROR in either TXCSR or RXCSR...
> I'm still digging to understand what exactly happen.
> When I download from WIFI and put the result into /dev/null and read
the
> MSC in the mean while, I do not encounter any problem. It seems that
the
> problem comes from TX/RX multiplexing with different timing  or buffer
> size... 
> 
> 
> Best regards
> 
> Stephane
> 
> -----Original Message-----
> From: Andreas Auer [mailto:a.auer at zydacron.com] 
> Sent: mardi 13 avril 2010 14:02
> To: davinci-linux-open-source at linux.davincidsp.com
> Subject: Re: UVC webcam problem
> 
> Right now, I tried to use the USB driver (the musb folder) from the 
> arago kernel. With this driver I can capture the video from the
webcam. 
> So, something important must be different!
> 
> BUT, as I already mentioned I had a problem with "USB WLAN sticks"
when 
> I use the arago kernel. And this is also the case if I use the USB 
> driver from the arago 2.6.32 kernel with the khilman 2.6.34 kernel.
> 
> But I need to use USB WLAN devices together with USB webcams. Maybe 
> someone could help me to get this running!
> 
> One thing a forgot to mentionabout the used hardware is that I have a 
> USB hub IC (ISP1521) between my USB devices and the USB host interface

> of the Davinci processor. Maybe this hub chip makes also some
problems.
> 
> Thanks for your help so far,
> Andreas
> 
> PS: I also tried to adjust the FIFO buffers but this was not the
> solution.
> 
> PPS: Maye, I should write a new post for the WLAN problem!?
> 
> 
> Subbrathnam, Swaminathan schrieb:
>> Andreas,
>>
>> Pl. ensure that the FIFO is configured correctly.  Probably this
error
> could mean you need a 1024 byte fifo space and it is not available.
If
> so increase the fifo space in musb_core.c file.
>> Regards
>> Swami
>>
>>> -----Original Message-----
>>> From: davinci-linux-open-source-
>>> bounces+swami.iyer=ti.com at linux.davincidsp.com
> [mailto:davinci-linux-open-
>>> source-bounces+swami.iyer=ti.com at linux.davincidsp.com] On Behalf Of
>>> Andreas Auer
>>> Sent: Tuesday, April 13, 2010 2:32 PM
>>> To: Markus Rechberger
>>> Cc: davinci-linux-open-source at linux.davincidsp.com
>>> Subject: Re: UVC webcam problem
>>>
>>> Markus Rechberger schrieb:
>>>> On Tue, Apr 13, 2010 at 10:27 AM, Andreas Auer
<a.auer at zydacron.com>
>>> wrote:
>>>>> Hi,
>>>>>
>>>>> I'm trying to get a UVC webcam working with the latest khilman
> kernel
>>>>> (2.6.34) on a Davinci EVM like board with DM6446 processor.
>>>>>
>>>>> I'm able to request the buffers and queue them without errors. But
> if I
>>>>> switch on the streaming the UVC driver tells me:
>>>>>  "uvcvideo: USB isochronous frame lost (-18)."
>>>>>
>>>>> Some time ago, I tried the 2.6.32 kernel from the arago project
and
>>> webcam
>>>>> capturing was working out of the box but WLAN was not working.
(so,
> I
>>>>> switched to the khilman kernel).
>>>>>
>>>>> Maybe, someone can help me with the uvc webcam problem!!!
>>>>>
>>>> with our tests the DM6446 only supported up to around 4.5 mbyte of
>>>> isochronous data...
>>>> Raw Analog TV 720x576x25 requires around 170 mbit, I guess webcams
> are
>>>> near to that level there's no chance to get such a thing work.
>>>> Maybe MJPEG or MPEG based devices can work with it.
>>> Thanks for your reply. I have a Logitech QuickCam Communicate Deluxe
>>> with MJPEG format. And this webcam is working with the 2.6.32 kernel
>>> from the arago project. So, I think this cam should be working.
>>>
>>> Does anyone know what's the above "status code" -18 means??
>>>
>>> Thanks,
>>> Andreas
>>> _______________________________________________
>>> Davinci-linux-open-source mailing list
>>> Davinci-linux-open-source at linux.davincidsp.com
>>>
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>  
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 5024 (20100413) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
>  
>  
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 5024 (20100413) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
>  
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________


-- 
DI Andreas Auer
Embedded Software Developer
a.auer at zydacron.com

ZYDACRON Austria GmbH
St.-Peter-Guertel 4, 8042 Graz, AUSTRIA http://www.zydacron.com
_____________________________________________________________________
CEO: Mag. Georg Weber
Regional Court: Graz
Commercial Register: 286334f
This communication, including any attachments, may contain
confidential information of ZYDACRON, its subsidiaries or
representatives, and is intended solely for the use of the individual
or entity to which it is addressed. Any unauthorized review, use,
disclosure or distribution is prohibited.
If you believe this message was sent to you in error, please
immediately notify the sender by reply email and delete this message
without disclosing it. Thank you.
_____________________________________________________________________

 

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 5024 (20100413) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 
 

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 5024 (20100413) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 

From Etienne.Eccles at vcatechnology.com  Tue Apr 13 07:39:03 2010
From: Etienne.Eccles at vcatechnology.com (Etienne Eccles)
Date: Tue, 13 Apr 2010 13:39:03 +0100
Subject: Codec engine lockup
Message-ID: <95FAFD227E8A2947BA96E1C807505D0412CD5F@sbs001.office.local>

 

H

 

 

I am getting the following debug output . using CE_DEBUG=3 when creating
and using a custom VIDENC codec:

 

 

 

root at nvc1346:/opt/davinci# CE_DEBUG=3 ./stabd -d -p a

root at nvc1346:/opt/davinci# @0,196,096us: [+4 T:0x00004000 S:0xbec8cbbc]
OG - Global_init> This program w

as built with the following packages:

@0,197,108us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
gnu.targets.rts470MV (/home/vcastab/svn/ud

p/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/gnu/targets/rts470MV
/) [1,0,0,0,1203621000516]

@0,197,334us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
dsplink.gpp (/home/vcastab/svn/udp/linux/d

vsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/dsplink/gpp/
) [3,0,0]

@0,197,516us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.xdais.dm (/home/vcastab/svn/udp/linux/d

vsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/dm/
) [1,0,4,1210262746529]

@0,197,948us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.xdais
(/home/vcastab/svn/udp/linux/dvsd

k/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/)
[1,2,1,1210262742149]

@0,198,149us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.utils.trace (/home/vcastab/svn/udp/

linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sd
o/utils/trace/) [1,0,0,122094336

6422]

@0,198,331us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.utils.xdm (/home/vcastab/svn/udp

/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ut
ils/xdm/) [1,0,1,1220951322616]

@0,198,510us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.fc.dman3 (/home/vcastab/svn/udp/lin

ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/f
c/dman3/) [1,0,3,1220943053023]

@0,198,682us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.fc.acpy3 (/home/vcastab/svn/udp/lin

ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/f
c/acpy3/) [1,0,2,1220943014135]

@0,198,852us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.linuxutils.cmem (/home/vcastab/svn/

udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/t
i/sdo/linuxutils/cmem/) [2,0,1,1

204929560755]

@0,199,030us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.catalog.c470 (/home/vcastab/svn/udp/lin

ux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/catalog/c470/)
[1,0,1,0,1203561761475]

@0,199,200us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.platforms.evmDM6446 (/home/vcastab/svn/

udp/linux/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/platforms/evmD
M6446/) [1,0,0,1,1192229600615]

@0,199,369us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.osal (/home/vcastab/svn/udp/linu

x/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/osal/)
[2,0,2,1220951127739]

@0,199,539us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.ipc (/home/vcastab/svn/udp/linux

/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/)
[2,0,1,1220951085787]

@0,199,704us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.alg (/home/vcastab/svn/udp/linux

/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/alg/)
[1,0,1,1220950781938]

@0,199,875us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.osal.linux (/home/vcastab/svn/ud

p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/o
sal/linux/) [2,0,1,1220951140072

]

@0,200,049us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.ipc.dsplink (/home/vcastab/svn/u

dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/
ipc/dsplink/) [2,0,1,12209510968

18]

@0,200,219us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce
(/home/vcastab/svn/udp/linux/dvs

dk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/)
[1,0,6,1220950771473]

@0,200,386us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.video (/home/vcastab/svn/udp/lin

ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/video/
) [1,0,3,1220951334122]

@0,200,559us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
codecs.vca_stab (/home/vcastab/svn/vt/davi

nci/trunk/ce1/codecs/vca_stab/) []

@0,200,718us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.bioslog (/home/vcastab/svn/udp/l

inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/bios
log/) [1,0,1,1220950800329]

@0,587,586us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.utils.trace (/home/vcastab/svn/u

dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/
utils/trace/) [1,0,1,12209513170

87]

@0,587,929us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
apps.stab_client (/home/vcastab/svn/vt/dav

inci/trunk/ce1/apps/stab_client/) []

@0,588,146us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter
(fxn=0x20028)

@0,588,352us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter
(fxn=0x1f4c0)

@0,588,676us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
Enter(0x18)

@0,589,026us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return
(0x5e138)

@0,589,716us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit> enter
(fxn=0x1dda8)

@0,590,050us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
Enter(0x18)

@0,590,269us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return
(0x5e188)

@0,590,492us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit> enter
(fxn=0x1b9f4)

@0,590,839us: [+0 T:0x00004000 S:0xbec8cbbc] OG - Global_atexit> enter
(fxn=0x1eb44)

@0,593,794us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem -
Sem_create> count: 0

@0,594,023us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc>
Enter(0x14)

@0,594,212us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> return
(0x5e208)

@0,594,470us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem -
Leaving Sem_create> sem[0x5e208]

@0,594,698us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem -
Sem_create> count: 0

@0,594,859us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc>
Enter(0x14)

@0,595,056us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> return
(0x5e220)

@0,595,220us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem -
Leaving Sem_create> sem[0x5e220]

@0,595,378us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc>
Enter(0x18)

@0,595,544us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> return
(0x5e238)

@0,595,707us: [+0 T:0x00004000 S:0xbec8cb8c] OT - Thread_create> Enter
(fxn=0x1ab34, attrs=0x0)

@0,595,869us: [+0 T:0x00004000 S:0xbec8cb74] OM - Memory_alloc>
Enter(0x64)

@0,596,064us: [+0 T:0x00004000 S:0xbec8cb74] OM - Memory_alloc> return
(0x5e258)

@0,598,964us: [+1 T:0x00004002 S:0xbe5ffa74] OP - daemon> thread
created.

@0,599,205us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d> Enter
(proc=0xbe5ffaec)

@0,599,387us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem -
Entered Sem_pend> sem[0x5e208] timeout

[0xffffffff]

@0,599,998us: [+0 T:0x00004000 S:0xbec8cb8c] OT - Thread_create> Exit
(task=0x5e258)

@0,600,235us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter
(fxn=0x1a6f4)

@0,600,501us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter
(fxn=0x1c7e8)

@0,600,791us: [+0 T:0x00004000 S:0xbec8cbac] ti.sdo.ce.alg - ALG_init>
Enter

@0,600,984us: [+0 T:0x00004000 S:0xbec8cb9c] OG - Global_atexit> enter
(fxn=0x209f0)

@0,601,171us: [+0 T:0x00004000 S:0xbec8cbcc] ti.sdo.ce.alg - ALG_init>
Exit

@0,601,339us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter
(fxn=0x20490)

@0,601,541us: [+0 T:0x00004000 S:0xbec8cb9c] OM - Memory_alloc>
Enter(0x18)

@0,601,767us: [+0 T:0x00004000 S:0xbec8cb9c] OM - Memory_alloc> return
(0x60418)

@0,601,955us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter
(fxn=0x1eca8)

@0,602,262us: [+6 T:0x00004000 S:0xbec8cbc4] CE - Engine_init> CE
debugging on (CE_DEBUG=3; allowed CE_D

EBUG levels: 1=min, 2=good, 3=max)

@0,602,481us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit> enter
(fxn=0x17734)

@0,602,667us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
Enter(0x18)

@0,602,852us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return
(0x60458)

@0,603,024us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
Enter(0x18)

@0,603,247us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return
(0x60478)

@0,603,423us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
Enter(0x18)

@0,603,600us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return
(0x60498)

@0,944,735us: [+0 T:0x00004000 S:0xbec8cbc4] CS - Server_init()

@0,944,957us: [+0 T:0x00004000 S:0xbec8cbc4] CS - Server_init>
Global_useLinkArbiter = 0

@0,945,138us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter
(fxn=0x16284)

@0,945,529us: [+0 T:0x00004000 S:0xbec8cbd4] OG - Global_atexit> enter
(fxn=0x14148)

@0,945,950us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
Enter(size=884736, align=-1, cache

d=FALSE, heap=FALSE)

@0,946,486us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_alloc(884736) = 0x403ee000.

@0,946,744us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_getPhys(0x403ee000) = 0x8ff25

000.

@0,946,938us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
Enter(virtAddr=0x403ee000, size=

884736, physAddr=0x8ff25000)

@0,947,127us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
creating new contigBuf object

@0,947,319us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

@0,947,514us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return
(0x60518)

@0,947,842us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
returning: cb->phys=0x8ff25000,

cb->size=884736, cb->virt=0x403ee000

@0,948,044us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
return (0x403ee000)

@0,948,270us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
Enter(size=884736, align=-1, cache

d=FALSE, heap=FALSE)

@0,948,643us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_alloc(884736) = 0x404c9000.

@0,948,931us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_getPhys(0x404c9000) = 0x8cac7

000.

@0,949,123us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
Enter(virtAddr=0x404c9000, size=

884736, physAddr=0x8cac7000)

@0,949,305us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
creating new contigBuf object

@0,949,467us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

@0,949,651us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return
(0x60530)

@0,949,823us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
returning: cb->phys=0x8cac7000,

cb->size=884736, cb->virt=0x404c9000

@0,950,004us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
return (0x404c9000)

@0,950,206us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
Enter(size=884736, align=-1, cache

d=FALSE, heap=FALSE)

@0,950,595us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_alloc(884736) = 0x405c9000.

@0,950,841us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_getPhys(0x405c9000) = 0x8c9c7

000.

@0,951,032us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
Enter(virtAddr=0x405c9000, size=

884736, physAddr=0x8c9c7000)

@0,951,219us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
creating new contigBuf object

@0,951,380us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

@0,951,592us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return
(0x60548)

@0,951,775us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
returning: cb->phys=0x8c9c7000,

cb->size=884736, cb->virt=0x405c9000

@0,951,959us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
return (0x405c9000)

@0,952,125us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
Enter(size=884736, align=-1, cache

d=FALSE, heap=FALSE)

@0,952,475us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_alloc(884736) = 0x406c9000.

@0,952,718us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_getPhys(0x406c9000) = 0x8c879

000.

@0,952,911us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
Enter(virtAddr=0x406c9000, size=

884736, physAddr=0x8c879000)

@0,953,145us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
creating new contigBuf object

@0,953,310us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

@0,953,490us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return
(0x60560)

@1,294,466us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
returning: cb->phys=0x8c879000,

cb->size=884736, cb->virt=0x406c9000

@1,294,700us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
return (0x406c9000)

@1,294,877us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
Enter(size=884736, align=-1, cache

d=FALSE, heap=FALSE)

@1,295,385us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_alloc(884736) = 0x407c9000.

@1,295,626us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_getPhys(0x407c9000) = 0x8fc94

000.

@1,295,850us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
Enter(virtAddr=0x407c9000, size=

884736, physAddr=0x8fc94000)

@1,296,040us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
creating new contigBuf object

@1,296,206us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

@1,296,387us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return
(0x60578)

@1,296,557us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
returning: cb->phys=0x8fc94000,

cb->size=884736, cb->virt=0x407c9000

@1,296,739us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
return (0x407c9000)

@1,296,908us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
Enter(size=884736, align=-1, cache

d=FALSE, heap=FALSE)

@1,297,589us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_alloc(884736) = 0x40a5a000.

@1,298,146us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_getPhys(0x40a5a000) = 0x8f8de

000.

@1,298,345us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
Enter(virtAddr=0x40a5a000, size=

884736, physAddr=0x8f8de000)

@1,298,538us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
creating new contigBuf object

@1,298,750us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

@1,298,934us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return
(0x60590)

@1,299,106us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
returning: cb->phys=0x8f8de000,

cb->size=884736, cb->virt=0x40a5a000

@1,299,290us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
return (0x40a5a000)

@1,309,917us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - Engine_open>
Enter('vca_engine', 0x0, 0xbe3ffa84)

@1,310,205us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc>
Enter(0x2c)

@1,310,419us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc> return
(0x605a8)

@1,310,604us: [+0 T:0x00008003 S:0xbe3ff9e4] CE -
rserverOpen('./server_release.x64P'), count = 0

@1,310,785us: [+0 T:0x00008003 S:0xbe3ff9ac] OP - Processor_create>
Enter(imageName='./server_release.x6

4P', linkCfg='(null)', attrs=0xbe3ffa30)

@1,312,833us: [+0 T:0x00008003 S:0xbe3ff994] OM - Memory_alloc>
Enter(0x24)

@1,313,100us: [+0 T:0x00008003 S:0xbe3ff994] OM - Memory_alloc> return
(0x605d8)

@1,313,292us: [+0 T:0x00008003 S:0xbe3ff98c] OP - doCmd> Enter (cmdId=1,
proc=0x605d8)

@1,313,470us: [+0 T:0x00008003 S:0xbe3ff97c] ti.sdo.ce.osal.Sem -
Entered Sem_post> sem[0x5e208]

@1,313,801us: [+0 T:0x00008003 S:0xbe3ff98c] ti.sdo.ce.osal.Sem -
Leaving Sem_post> sem[0x5e208]

@1,314,019us: [+0 T:0x00008003 S:0xbe3ff96c] ti.sdo.ce.osal.Sem -
Entered Sem_pend> sem[0x5e220] timeout

[0xffffffff]

@1,314,506us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem -
Leaving Sem_pend> sem[0x5e208] status[

0]

@1,314,978us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d> Exit
(result=1)

@1,315,460us: [+0 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Enter(proc=0x605d8)

@1,315,900us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Initializing DSP PROC...

@1,316,335us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Using DspLink config data for entr

y #0 [server './server_release.x64P']

@1,316,786us: [+0 T:0x00004002 S:0xbe5ffa5c] OM - Memory_alloc>
Enter(0xe0)

@1,317,458us: [+0 T:0x00004002 S:0xbe5ffa5c] OM - Memory_alloc> return
(0x60600)

@1,318,325us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Adding DSP segment #0 to Link conf

iguration: name='DDR', startAddress=0x88200000, sizeInBytes=0x400000,
shared=1

@1,660,152us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Adding DSP segment #1 to Link conf

iguration: name='DSPLINKMEM', startAddress=0x88100000,
sizeInBytes=0x100000, shared=1

@1,660,412us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Adding DSP segment #2 to Link conf

iguration: name='RESET_VECTOR', startAddress=0x88000000,
sizeInBytes=0x80, shared=0

@1,660,650us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Adding DSP segment #3 to Link conf

iguration: name='DDRALGHEAP', startAddress=0x88800000,
sizeInBytes=0x1c00000, shared=0

@1,660,856us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
DOPOWERCONTROL was=0; now=0

SET WIDTH to 720 HEIGHT to 576

@1,685,617us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Attaching to DSP PROC...

@1,698,711us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Opening MSGQ pool...

@1,699,722us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Loading ./server_release.x64P on D

SP (1 args)...

@1,892,865us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Starting DSP PROC...

@1,916,709us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Opening remote transport...

@1,917,511us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
return (1)

@1,918,475us: [+0 T:0x00004002 S:0xbe5ffa64] ti.sdo.ce.osal.Sem -
Entered Sem_post> sem[0x5e220]

@1,918,948us: [+0 T:0x00008003 S:0xbe3ff96c] ti.sdo.ce.osal.Sem -
Leaving Sem_pend> sem[0x5e220] status[

0]

@1,919,260us: [+0 T:0x00008003 S:0xbe3ff98c] OP - doCmd> Exit (result=1)

@1,919,438us: [+0 T:0x00008003 S:0xbe3ff9ac] OP - Processor_create>
return (0x605d8)

@1,919,611us: [+0 T:0x00008003 S:0xbe3ff9e4] CE -
rserverOpen('./server_release.x64P'): 0x5701c done.

@1,919,799us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc>
Enter(0x1e)

@1,919,990us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc> return
(0x61fd0)

@1,920,188us: [+0 T:0x00008003 S:0xbe3ff9bc] OC - Comm_create>
Enter(queueName='vca_engine_0', queue=0x6

05b8, attrs=0x0)

@1,920,370us: [+0 T:0x00008003 S:0xbe3ff9a4] OM - Memory_alloc>
Enter(0x4)

@1,920,579us: [+0 T:0x00008003 S:0xbe3ff9a4] OM - Memory_alloc> return
(0x61ff8)

@1,921,144us: [+0 T:0x00008003 S:0xbe3ff9bc] OC - Comm_create> return
(0x61ff8)

@1,921,384us: [+0 T:0x00008003 S:0xbe3ff9bc] OM - Memory_free>
Enter(0x61fd0, 0x1e)

@1,921,582us: [+0 T:0x00008003 S:0xbe3ff9bc] OM - Memory_free> return
(0x1)

@1,921,758us: [+0 T:0x00008003 S:0xbe3ff9c4] OC - Comm_alloc>
Enter(poolId=0x0, msg=0x605c4, size=576)

@1,921,990us: [+0 T:0x00008003 S:0xbe3ff9c4] OC - Comm_alloc>
msg=0x413dbc80, returning (0)

@1,922,187us: [+0 T:0x00008003 S:0xbe3ff9a4] OC - Comm_locate>
Enter(queueName='rmsq', queue=0x605b4)

@1,931,192us: [+0 T:0x00008003 S:0xbe3ff9a4] OC - Comm_locate> return
(0)

@1,931,465us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - checkServer(0x605a8)

@1,931,739us: [+0 T:0x00008003 S:0xbe3ff9b4] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@1,932,050us: [+0 T:0x00008003 S:0xbe3ff9b4] OC - Comm_put> return (0)

@1,932,339us: [+0 T:0x00008003 S:0xbe3ff9ac] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ffa28, timeout

=-1)

@1,932,567us: [+0 T:0x00008003 S:0xbe3ff9ac] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@1,932,768us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - rmsInit> RMS
initialized(0x605a8); CE_DEBUG on, settin

g DSP trace mask to *+01234567,GT_prefix=12345,GT_time=3

@1,932,966us: [+0 T:0x00008003 S:0xbe3ff9b4] CE - Engine_setTrace>
Enter(engine=0x605a8, mask='*+0123456

7,GT_prefix=12345,GT_time=3')

@1,933,180us: [+1 T:0x00008003 S:0xbe3ff9b4] CE - Engine_setTrace>
Requesting DSP set trace ...

@1,933,348us: [+0 T:0x00008003 S:0xbe3ff984] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@1,933,635us: [+0 T:0x00008003 S:0xbe3ff984] OC - Comm_put> return (0)

@1,933,821us: [+0 T:0x00008003 S:0xbe3ff97c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff9ec, timeout

=-1)

@1,934,437us: [+0 T:0x00004002 S:0xbe5ffa74] ti.sdo.ce.osal.Sem -
Leaving Sem_post> sem[0x5e220]

@1,934,692us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d> Enter
(proc=0xbe5ffaec)

@1,934,920us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem -
Entered Sem_pend> sem[0x5e208] timeout

[0xffffffff]

@1,937,498us: [+0 T:0x00008003 S:0xbe3ff97c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@1,937,904us: [+0 T:0x00008003 S:0xbe3ff9b4] CE - Engine_setTrace>
return(0)

@1,938,126us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@1,938,384us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put> return (0)

@1,938,673us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff9d0, timeout

=-1)

@1,938,903us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

[DSP] @0x00000208:[T:0x00000000] ZZ - main> Welcome to loopback server's
main().

[DSP] @0x0000086c:[T:0x8880415c] LS - server()

[DSP] @0x0000088d:[T:0x8880415c] OM - Memory_alloc> Enter(size=0x24)

[DSP] @0x000008b8:[T:0x8880415c] OM - Memory_alloc> return (0x882ab060)

[DSP] @0x000008e6:[T:0x8880415c] LS - server: serverMsgQueue =
0x00000001

[DSP] @0x0000090f:[T:0x8880415c] LS - server: waiting for cmd

[DSP] @0x00008cc2:[T:0x8880006c] CR - processRmsCmd(0x88105ca8, 4056):
cmd = 6

[DSP] @0x00009b1c:[T:0x8880006c] CR - processRmsCmd(0x88105ca8, 4056):
cmd = 8

[DSP] @0x00009b50:[T:0x8880006c] CR - setting trace mask to
*+01234567,GT_prefix=12345,GT_time=3

[DSP] @0,039,852tk: [+0 T:0x8880006c S:0x88803fdc] OG -
Global_setSpecialTrace> enter(mask='*+01234567,G

T_prefix=12345,GT_time=3')

[DSP] @0,039,938tk: [+4 T:0x8880006c S:0x88803fdc] OG -
Global_setSpecialTrace> This program was built w

ith the following packages:

[DSP] @0,040,015tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.targets.rts6000 (/home/vcastab/sv

n/udp/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/targets/rts60
00/) [1,0,0,0,1203621186754]

[DSP] @0,040,139tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.fc.dman3 (/home/vcastab/svn/u

dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti
/sdo/fc/dman3/) [1,0,3,122094305

3023]

[DSP] @0,040,255tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.rtdx (/home/vcastab/svn/udp/linux

/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/rtdx/)
[2,0,0,1,1194024051755]

[DSP] @0,040,356tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.psl (/home/vcastab/svn/udp/linux/

dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/psl/) [5,0,0,0,0]

[DSP] @0,040,451tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.bios (/home/vcastab/svn/udp/linux

/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/bios/)
[5,2,4,9,1193960176642]

[DSP] @0,040,552tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.fc.dskt2 (/home/vcastab/svn/u

dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti
/sdo/fc/dskt2/) [1,0,4,122094309

5081]

[DSP] @0,040,668tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.xdais.dm (/home/vcastab/svn/udp/l

inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xda
is/dm/) [1,0,4,1210262746529]

[DSP] @0,040,781tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.xdais (/home/vcastab/svn/udp/linu

x/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/
) [1,2,1,1210262742149]

[DSP] @0,040,890tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.node (/home/vcastab/svn/ud

p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/n
ode/) [1,0,0,1220951122176]

[DSP] @0,041,001tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.ipc.dsplink.dsp (/home/vca

stab/svn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/
ti/sdo/ce/ipc/dsplink/dsp/) [2,0

,1,1220951102696]

[DSP] @0,041,122tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.utils.trace (/home/vcastab/sv

n/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages
/ti/sdo/utils/trace/) [1,0,0,122

0943366422]

[DSP] @0,041,242tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.utils.xdm (/home/vcastab/s

vn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo
/ce/utils/xdm/) [1,0,1,122095132

2616]

[DSP] @0,041,357tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.fc.acpy3 (/home/vcastab/svn/u

dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti
/sdo/fc/acpy3/) [1,0,2,122094301

4135]

[DSP] @0,041,473tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
dsplink.dsp (/home/vcastab/svn/udp/l

inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/dsplin
k/dsp/) [1,3,0]

[DSP] @0,041,578tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.bios.utils (/home/vcastab/svn/udp

/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/b
ios/utils/) [2,0,1,0,11918918306

09]

[DSP] @0,041,693tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.catalog.c6000 (/home/vcastab/svn/

udp/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/catalog/c6000/)
[1,0,0,0,1203561781695]

[DSP] @0,041,802t at 2,297,823us: [+0 T:0x00008003 S:0xbe3ff944] OC -
Comm_put> Enter(queue=0x0, msg=0x413d

bc80)

@2,298,120us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put> return (0)

@2,298,417us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff9d0, timeout

=-1)

@2,298,649us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

k: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.platforms.evmDM6446 (/home/vcastab/svn/udp/linux/d

vsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/platforms/evmDM6446/)
[1,0,0,1,1192229600615]

[DSP] @0,041,919tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.osal (/home/vcastab/svn/ud

p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/o
sal/) [2,0,2,1220951127739]

[DSP] @0,042,030tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.ipc (/home/vcastab/svn/udp

/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ip
c/) [2,0,1,1220951085787]

[DSP] @0,042,139tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.alg (/home/vcastab/svn/udp

/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/al
g/) [1,0,1,1220950781938]

[DSP] @0,042,249tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.osal.bios (/home/vcastab/s

vn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo
/ce/osal/bios/) [2,0,1,122095113

3740]

[DSP] @0,042,365tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.ipc.bios (/home/vcastab/sv

n/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/
ce/ipc/bios/) [2,0,1,12209510910

97]

[DSP] @0,042,487tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce (/home/vcastab/svn/udp/lin

ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/)
[1,0,6,1220950771473]

[DSP] @0,042,593tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.bioslog (/home/vcastab/svn

/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/c
e/bioslog/) [1,0,1,1220950800329

]

[DSP] @0,042,706tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.video (/home/vcastab/svn/u

dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/
video/) [1,0,3,1220951334122]

[DSP] @0,042,818tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
codecs.vca_stab (/home/vcastab/svn/v

t/davinci/trunk/ce1/codecs/vca_stab/) []

[DSP] @0,042,901tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
servers.vca_stab_server (/home/vcast

ab/svn/vt/davinci/trunk/ce1/servers/vca_stab_server/) []

[DSP] @0,042,992tk: [+0 T:0x8880006c S:0x88803fdc] OG -
Global_setSpecialTrace> return

[DSP] @0,050,728tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

[DSP] @0,050,799tk: [+0 T:0x8880006c S:0x88804024] CR - remote time =
0x0, trace buffer size = 4032

[DSP] @0,885,481tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

[DSP] @0,885,547tk: [+0 T:0x8880006c S:0x88804024] CR - remote time =
0x0, trace buffer size = 4032

@2,650,231us: [+0 T:0x00008003 S:0xbe3ff974] CE - Engine_fwriteTrace>
returning count [6828]

@2,650,445us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - Engine_open>
return(394664)

@2,650,660us: [+0 T:0x00008003 S:0xbe3ffa34] ti.sdo.ce.video.VIDENC -
VIDENC_create> Enter (engine=0x605

a8, name='vca_stab', params=0xbe3ffa88)

@2,650,896us: [+0 T:0x00008003 S:0xbe3ffa04] CV - VISA_create(0x605a8,
'vca_stab', 0xbe3ffa88, 0x828, 't

i.sdo.ce.video.IVIDENC')

@2,651,104us: [+0 T:0x00008003 S:0xbe3ff92c] CV - VISA_create2(0x605a8,
'vca_stab', 0xbe3ffa88, 0x2c, 0x

828, 'ti.sdo.ce.video.IVIDENC')

@2,651,363us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc>
Enter(0x30)

@2,651,589us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc> return
(0x62058)

@2,651,782us: [+0 T:0x00008003 S:0xbe3ff8bc] CE -
Engine_createNode(0x605a8, 'vca_stab', 828, 0xbe3ffa88

, 0x2c, 0xbe3ffa30)

@2,651,980us: [+0 T:0x00008003 S:0xbe3ff8a4] OM - Memory_alloc>
Enter(0x20)

@2,652,163us: [+0 T:0x00008003 S:0xbe3ff8a4] OM - Memory_alloc> return
(0x61fd0)

@2,652,361us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_create>
Enter(queueName='gppfromnode_1', queue=0x

61fd8, attrs=0x0)

@2,652,545us: [+0 T:0x00008003 S:0xbe3ff87c] OM - Memory_alloc>
Enter(0x4)

@2,652,730us: [+0 T:0x00008003 S:0xbe3ff87c] OM - Memory_alloc> return
(0x62090)

@2,993,385us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_create> return
(0x62090)

@2,993,649us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@2,993,987us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put> return (0)

@2,994,199us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff914, timeout

=-1)

@3,010,127us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@3,010,439us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@3,010,710us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put> return (0)

@3,010,993us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff914, timeout

=-1)

@3,011,253us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@3,011,492us: [+4 T:0x00008003 S:0xbe3ff8bc] CE - Engine_createNode>
created node(stdIn=0x2, stdOut=0x10

001, msgq=0x62090, algName='vca_stab', rmsNode=0x882ab088,
algHandle=0x882ab168)

@3,011,735us: [+0 T:0x00008003 S:0xbe3ff81c] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@3,011,981us: [+0 T:0x00008003 S:0xbe3ff81c] OC - Comm_put> return (0)

@3,012,254us: [+0 T:0x00008003 S:0xbe3ff814] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff8a8, timeout

=-1)

@3,012,488us: [+0 T:0x00008003 S:0xbe3ff814] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

[DSP] @2,500,228tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 0

[DSP] @2,500,305tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc>
Enter(size=0x18)

[DSP] @2,500,365tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc>
return (0x882ab088)

[DSP] @2,500,425tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc>
Enter(size=0xb)

[DSP] @2,500,480tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc>
return (0x882ab0a0)

[DSP] @2,500,549tk: [+0 T:0x8880006c S:0x88803edc] OM - Memory_alloc>
Enter(size=0x20)

[DSP] @2,500,605tk: [+0 T:0x8880006c S:0x88803edc] OM - Memory_alloc>
return (0x882ab0b0)

[DSP] @2,500,665tk: [+0 T:0x8880006c S:0x88803eac] OM - Memory_alloc>
Enter(size=0x24)

[DSP] @2,500,722tk: [+0 T:0x8880006c S:0x88803eac] OM - Memory_alloc>
return (0x882ab0d0)

[DSP] @2,500,806tk: [+0 T:0x8880006c S:0x88803ec4]
ti.sdo.ce.video.VIDENC - VIDENC_create> Enter (engine

=0x0, name='vca_stab', params=0x88105cc0)

[DSP] @2,500,902tk: [+0 T:0x8880006c S:0x88803e8c] CV - VISA_create(0x0,
'vca_stab', 0x88105cc0, 0x828,

'ti.sdo.ce.video.IVIDENC')

[DSP] @2,500,988tk: [+0 T:0x8880006c S:0x88803d7c] CV -
VISA_create2(0x0, 'vca_stab', 0x88105cc0, 0x2c,

0x828, 'ti.sdo.ce.video.IVIDENC')

[DSP] @2,501,089tk: [+0 T:0x8880006c S:0x88803d14] CE - Engine_open>
Enter('local', 0x88803d6c, 0x33c)

[DSP] @2,501,158tk: [+0 T:0x8880006c S:0x88803cf4] OM - Memory_alloc>
Enter(size=0x2c)

[DSP] @2,501,216tk: [+0 T:0x8880006c S:0x88803cf4] OM - Memory_alloc>
return (0x882ab138)

[DSP] @2,501,287tk: [+0 T:0x8880006c S:0x88803d14] CE - Engine_open>
return(-2010468040)

[DSP] @2,501,362tk: [+0 T:0x8880006c S:0x88803d5c] OM - Memory_alloc>
Enter(size=0x30)

[DSP] @2,501,418tk: [+0 T:0x8880006c S:0x88803d5c] OM - Memory_alloc>
return (0x882ab168)

[DSP] @2,501,484tk: [+0 T:0x8880006c S:0x88803d34]
ti.sdo.ce.alg.Algorithm - Algorithm_create> Enter(fxn

s=0x88266574, idma3Fxns=0x882665a0, params=0x88105cc0, attrs=0x88803e80)

[DSP] @2,501,595tk: [+0 T:0x8880006c S:0x88803d14] OM - Memory_alloc>
Enter(size=0x10)

[DSP] @2,501,652tk: [+0 T:0x8880006c S:0x88803d14] OM - Memory_alloc>
return (0x882ab198)

[DSP] @2,519,578tk: [+0 T:0x8880006c S:0x88803c34] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

Bytes=1008)

[DSP] @2,519,697tk: [+0 T:0x8880006c S:0x88803c34] OM -
Memory_cacheWbInv> return

[DSP] @2,535,121tk: [+0 T:0x8880006c S:0x88803c0c] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

Bytes=32)

[DSP] @2,535,236tk: [+0 T:0x8880006c S:0x88803c0c] OM -
Memory_cacheWbInv> return

[DSP] @2,535,480tk: [+0 T:0x8880006c S:0x88803bc4] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

Bytes=32)

[DSP] @2,535,566tk: [+0 T:0x8880006c S:0x88803bc4] OM -
Memory_cacheWbInv> return

[DSP] @2,535,835tk: [+0 T:0x8880006c S:0x88803b9c] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

Bytes=32)

[DSP] @2,535,925tk: [+0 T:0x8880006c S:0x88803b9c] OM -
Memory_cacheWbInv> return

[DSP] @2,536,688tk: [+0 T:0x8880006c S:0x88803cb4] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

Bytes=1008)

[DSP] @2,536,793tk: [+0 T:0x8880006c S:0x88803cb4] OM -
Memory_cacheWbInv> return

[DSP] @2,536,915tk: [+0 T:0x8880006c S:0x88803d34]
ti.sdo.ce.alg.Algorithm - Algorithm_create> return (0

x882ab198)

[DSP] @2,536,997tk: [+0 T:0x8880006c S:0x88803ec4]
ti.sdo.ce.video.VIDENC - VIDENC_create> return (0x882

ab168)

[DSP] @2,537,080tk: [+4 T:0x8880006c S:0x88803e84] OT - Thread_create >
name: "vca_stab#0", pri:  -1, st

ack size:  16384, stack seg: 0

[DSP] @2,539,051tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 1

[DSP] @2,541,980tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

[DSP] @2,542,048tk: [+0 T:0x8880006c S:0x88804024] CR - remote time =
0x0, trace buffer size = 4032

@3,369,765us: [+0 T:0x00008003 S:0xbe3ff84c] CE - Engine_fwriteTrace>
returning count [3758]

@3,369,981us: [+2 T:0x00008003 S:0xbe3ff8bc] CE - Engine_createNode>
Returning 0x61fd0

@3,370,160us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc>
Enter(0x4)

@3,370,349us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc> return
(0x620a0)

@3,370,528us: [+0 T:0x00008003 S:0xbe3ff90c] OC - Comm_alloc>
Enter(poolId=0x0, msg=0x620a0, size=828)

@3,370,760us: [+0 T:0x00008003 S:0xbe3ff90c] OC - Comm_alloc>
msg=0x413dcc80, returning (0)

@3,370,981us: [+5 T:0x00008003 S:0xbe3ff92c] CV - VISA_create> remote
codec created (name='vca_stab', lo

calQueueID=0x10001, remoteQueueID=0x0002)

@3,371,235us: [+0 T:0x00008003 S:0xbe3ffa34] ti.sdo.ce.video.VIDENC -
VIDENC_create> return (0x62058)

@3,374,722us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC -
VIDENC_control> Enter (handle=0x62

058, id=257, params=0x5abe8, status=0xbe3ffa28

@3,375,009us: [+5 T:0x00008003 S:0xbe3ff844] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

0006

@3,375,208us: [+0 T:0x00008003 S:0xbe3ff824] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

0020006, command=0x1

@3,375,431us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

@3,375,692us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put> return (0)

@3,375,884us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3ff884, timeout

=-1)

@3,376,737us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@3,377,056us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@3,377,322us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put> return (0)

@3,377,720us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff800, timeout

=-1)

@3,378,173us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

[DSP] @3,385,962tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
0x882ab0b0(vca_stab#0) call(algHandle=0x88

2ab168, msg=0x88106c80); messageId=0x00020006

[DSP] @3,386,079tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

e=0x882ab168, id=257, params=0x88106cb4, status=0x88106d00

[DSP] @3,386,192tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

198

[DSP] @3,386,267tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

andle=0x882ab198)

[DSP] @3,386,383tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

[DSP] @3,386,881tk: [+0 T:0x8892e644 S:0x889324c4] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

Bytes=32)

[DSP] @3,386,997tk: [+0 T:0x8892e644 S:0x889324c4] OM -
Memory_cacheWbInv> return

[DSP] @3,387,126tk: [+0 T:0x8892e644 S:0x889324b4] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

Bytes=32)

[DSP] @3,387,203tk: [+0 T:0x8892e644 S:0x889324b4] OM -
Memory_cacheWbInv> return

[DSP] @3,387,442tk: [+0 T:0x8892e644 S:0x8893248c] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

Bytes=32)

[DSP] @3,387,538tk: [+0 T:0x8892e644 S:0x8893248c] OM -
Memory_cacheWbInv> return

[DSP] @3,387,604tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

98

[DSP] @3,387,679tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

(handle=0x882ab198)

[DSP] @3,387,760tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

n

[DSP] @3,387,834tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

=0x882ab168, retVal=0x0)

[DSP] @3,387,919tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned
from call(algHandle=0x882ab168, m

sg=0x88106c80); messageId=0x00020006

[DSP] @3,389,753tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

[DSP] @3,389,829tk: [+0 T:0x8880006c S:0x88804024] CR - remote time =
0x0, trace buffer size = 4032

@3,727,875us: [+0 T:0x00008003 S:0xbe3ff7a4] CE - Engine_fwriteTrace>
returning count [2039]

@3,728,094us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call Completed:
messageId=0x00020006, command=0x1

, return(status=0)

@3,728,332us: [+5 T:0x00008003 S:0xbe3ff834] CV - VISA_freeMsg(0x62058,
0x413dcc80): Freeing message wit

h messageId=0x00020006

@3,728,530us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC -
VIDENC_control> Exit (handle=0x620

58, retVal=0x0)

@3,728,715us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC -
VIDENC_control> Enter (handle=0x62

058, id=259, params=0x5abe8, status=0xbe3ff930

@3,728,916us: [+5 T:0x00008003 S:0xbe3ff844] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

0007

@3,729,097us: [+0 T:0x00008003 S:0xbe3ff824] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

0020007, command=0x1

@3,729,285us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

@3,729,551us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put> return (0)

@3,729,751us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3ff884, timeout

=-1)

@3,730,056us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@3,730,282us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@3,730,528us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put> return (0)

@3,730,802us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff800, timeout

=-1)

@3,731,055us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

[DSP] @4,206,979tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
0x882ab0b0(vca_stab#0) call(algHandle=0x88

2ab168, msg=0x88106c80); messageId=0x00020007

[DSP] @4,207,083tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

e=0x882ab168, id=259, params=0x88106cb4, status=0x88106d00

[DSP] @4,207,189tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

198

[DSP] @4,207,262tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

andle=0x882ab198)

[DSP] @4,207,346tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

[DSP] @4,207,420tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

98

[DSP] @4,207,494tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

(handle=0x882ab198)

[DSP] @4,207,571tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

n

[DSP] @4,207,636tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

=0x882ab168, retVal=0x0)

[DSP] @4,207,714tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned
from call(algHandle=0x882ab168, m

sg=0x88106c80); messageId=0x00020007

[DSP] @4,209,298tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

[DSP] @4,209,366tk: [+0 T:0x8880006c S:0x88804024] CR - remote time =
0x0, trace buffer size = 4032

@4,078,103us: [+0 T:0x00008003 S:0xbe3ff7a4] CE - Engine_fwriteTrace>
returning count [1451]

@4,078,339us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call Completed:
messageId=0x00020007, command=0x1

, return(status=0)

@4,078,546us: [+5 T:0x00008003 S:0xbe3ff834] CV - VISA_freeMsg(0x62058,
0x413dcc80): Freeing message wit

h messageId=0x00020007

@4,078,742us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC -
VIDENC_control> Exit (handle=0x620

58, retVal=0x0)

SVN Version: 3093:3110

STAB Version: 01.06.08

@4,079,044us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc>
Enter(size=28, align=-1, cached=FA

LSE, heap=FALSE)

@4,079,389us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc>
CMEM_alloc(28) = 0x4144b000.

@4,079,680us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc>
CMEM_getPhys(0x4144b000) = 0x8c9ba

000.

@4,079,883us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf>
Enter(virtAddr=0x4144b000, size=

28, physAddr=0x8c9ba000)

@4,080,074us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf>
creating new contigBuf object

@4,080,242us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc>
Enter(0x10)

@4,080,453us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc> return
(0x60fb0)

@4,080,628us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf>
returning: cb->phys=0x8c9ba000,

cb->size=28, cb->virt=0x4144b000

@4,080,810us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc>
return (0x4144b000)

@4,081,014us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc>
Enter(size=32, align=-1, cached=FA

LSE, heap=FALSE)

@4,081,323us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc>
CMEM_alloc(32) = 0x41458000.

@4,081,570us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc>
CMEM_getPhys(0x41458000) = 0x8c9ad

000.

@4,081,763us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf>
Enter(virtAddr=0x41458000, size=

32, physAddr=0x8c9ad000)

@4,081,953us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf>
creating new contigBuf object

@4,082,119us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc>
Enter(0x10)

@4,082,348us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc> return
(0x620b0)

@4,082,535us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf>
returning: cb->phys=0x8c9ad000,

cb->size=32, cb->virt=0x41458000

@4,082,729us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc>
return (0x41458000)

MAC: 00:13:23:04:13:46 USN: 970041346

@4,349,545us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC -
VIDENC_control> Enter (handle=0x62

058, id=41216, params=0xbe3fedb8, status=0xbe3fed28

@4,349,833us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

0008

@4,350,045us: [+0 T:0x00008003 S:0xbe3fe9c4] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

0020008, command=0x1

@4,350,250us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

@4,350,512us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> return (0)

@4,350,710us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3fea24, timeout

=-1)

@4,351,302us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@4,351,574us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@4,351,839us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> return (0)

@4,352,129us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3fe9a0, timeout

=-1)

@4,352,373us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

[DSP] @5,647,854tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
0x882ab0b0(vca_stab#0) call(algHandle=0x88

2ab168, msg=0x88106c80); messageId=0x00020008

[DSP] @5,647,953tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

e=0x882ab168, id=41216, params=0x88106cb4, status=0x88106cfc

[DSP] @5,648,057tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

198

[DSP] @5,648,128tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

andle=0x882ab198)

[DSP] @5,648,202tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

[DSP] @5,648,776tk: [+0 T:0x8892e644 S:0x88932504] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

Bytes=1008)

[DSP] @5,648,876tk: [+0 T:0x8892e644 S:0x88932504] OM -
Memory_cacheWbInv> return

[DSP] @5,648,930tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

98

[DSP] @5,649,005tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

(handle=0x882ab198)

[DSP] @5,649,084tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

n

[DSP] @5,649,150tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

=0x882ab168, retVal=0x0)

[DSP] @5,649,235tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned
from call(algHandle=0x882ab168, m

sg=0x88106c80); messageId=0x00020008

[DSP] @5,650,934tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

[DSP] @5,651,005tk: [+0 T:0x8880006c S:0x88804024] CR - remote time =
0x0, trace buffer size = 4032

@4,359,446us: [+0 T:0x00008003 S:0xbe3fe944] CE - Engine_fwriteTrace>
returning count [1651]

@4,359,654us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call Completed:
messageId=0x00020008, command=0x1

, return(status=0)

@4,359,857us: [+5 T:0x00008003 S:0xbe3fe9d4] CV - VISA_freeMsg(0x62058,
0x413dcc80): Freeing message wit

h messageId=0x00020008

@4,360,055us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC -
VIDENC_control> Exit (handle=0x620

58, retVal=0x0)

@4,360,248us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC -
VIDENC_control> Enter (handle=0x62

058, id=41217, params=0xbe3fec28, status=0xbe3fed28

@4,360,484us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

0009

@4,360,680us: [+0 T:0x00008003 S:0xbe3fe9c4] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

0020009, command=0x1

@4,360,873us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

@4,361,117us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> return (0)

@4,361,309us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3fea24, timeout

=-1)

@4,366,972us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@4,367,246us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@4,787,772us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> return (0)

@4,788,103us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3fe9a0, timeout

=-1)

@4,788,354us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

[DSP] @5,672,464tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
0x882ab0b0(vca_stab#0) call(algHandle=0x88

2ab168, msg=0x88106c80); messageId=0x00020009

[DSP] @5,672,568tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

e=0x882ab168, id=41217, params=0x88106cb4, status=0x88106db0

[DSP] @5,672,674tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

198

[DSP] @5,672,747tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

andle=0x882ab198)

[DSP] @5,672,827tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

[DSP] @5,685,069tk: [+0 T:0x8892e644 S:0x88932494] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

Bytes=1008)

[DSP] @5,685,193tk: [+0 T:0x8892e644 S:0x88932494] OM -
Memory_cacheWbInv> return

[DSP] @5,685,259tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

98

[DSP] @5,685,335tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

(handle=0x882ab198)

[DSP] @5,685,417tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

n

[DSP] @5,685,488tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

=0x882ab168, retVal=0x0)

[DSP] @5,685,621tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned
from call(algHandle=0x882ab168, m

sg=0x88106c80); messageId=0x00020009

[DSP] @6,662,444tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

[DSP] @6,662,522tk: [+0 T:0x8880006c S:0x88804024] CR - remote time =
0x0, trace buffer size = 4032

@4,795,428us: [+0 T:0x00008003 S:0xbe3fe944] CE - Engine_fwriteTrace>
returning count [1651]

@4,795,640us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call Completed:
messageId=0x00020009, command=0x1

, return(status=0)

@4,795,851us: [+5 T:0x00008003 S:0xbe3fe9d4] CV - VISA_freeMsg(0x62058,
0x413dcc80): Freeing message wit

h messageId=0x00020009

@4,796,075us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC -
VIDENC_control> Exit (handle=0x620

58, retVal=0x0)

@4,796,289us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC -
VIDENC_control> Enter (handle=0x62

058, id=41218, params=0xbe3fec28, status=0xbe3feac0

@4,796,501us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

000a

@4,796,692us: [+0 T:0x00008003 S:0xbe3fe9c4] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

002000a, command=0x1

@4,796,891us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

@4,797,345us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> return (0)

@4,797,723us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3fea24, timeout

=-1)

@4,798,173us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@4,798,433us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@4,798,694us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> return (0)

@4,799,015us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3fe9a0, timeout

=-1)

@4,799,256us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

[DSP] @6,684,637tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
0x882ab0b0(vca_stab#0) call(algHandle=0x88

2ab168, msg=0x88106c80); messageId=0x0002000a

[DSP] @6,684,743tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

e=0x882ab168, id=41218, params=0x88106cb4, status=0x88106db0

[DSP] @6,684,853tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

198

[DSP] @6,684,927tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

andle=0x882ab198)

[DSP] @6,685,011tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

[DSP] @6,685,660tk: [+0 T:0x8892e644 S:0x88932504] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

Bytes=1008)

[DSP] @6,685,789tk: [+0 T:0x8892e644 S:0x88932504] OM -
Memory_cacheWbInv> return

[DSP] @6,685,848tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

98

[DSP] @6,685,921tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

(handle=0x882ab198)

[DSP] @6,686,001tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

n

[DSP] @6,686,067tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

=0x882ab168, retVal=0x0)

[DSP] @6,686,152tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned
from call(algHandle=0x882ab168, m

sg=0x88106c80); messageId=0x0002000a

[DSP] @6,687,790tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

[DSP] @6,687,860tk: [+0 T:0x8880006c S:0x88804024] CR - remote time =
0x0, trace buffer size = 4032

@5,146,922us: [+0 T:0x00008003 S:0xbe3fe944] CE - Engine_fwriteTrace>
returning count [1651]

@5,147,356us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call Completed:
messageId=0x0002000a, command=0x1

, return(status=0)

@5,147,728us: [+5 T:0x00008003 S:0xbe3fe9d4] CV - VISA_freeMsg(0x62058,
0x413dcc80): Freeing message wit

h messageId=0x0002000a

@5,147,971us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC -
VIDENC_control> Exit (handle=0x620

58, retVal=0x0)

@5,174,837us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC -
VIDENC_process> Enter (handle=0x62

058, inBufs=0xbe3ffac0, outBufs=0xbe3ffab0, inArgs=0xbe3ff8fc,
outArgs=0xbe3ffa10)

@5,175,123us: [+5 T:0x00008003 S:0xbe3ff7fc] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

000b

@5,175,328us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x404c

9000, size=884736)

@5,175,514us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x404c9000,

 size=884736)

@5,175,692us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> found in cb(Sc=0x404c9000,

 Ec=0x405a1000, Ss=0x404c9000, Es=0x405a1000, PSc=0x8cac7000)

@5,175,934us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> returning physAddr=0x8cac7

000

@5,176,105us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> return (0x8cac7000)

@5,176,280us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4145

8000, size=32)

@5,176,450us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x41458000,

 size=32)

@5,176,621us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> found in cb(Sc=0x41458000,

 Ec=0x41458020, Ss=0x41458000, Es=0x41458020, PSc=0x8c9ad000)

@5,176,811us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> returning physAddr=0x8c9ad

000

@5,176,980us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> return (0x8c9ad000)

@5,177,150us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x407c

9000, size=884736)

@5,177,369us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x407c9000,

 size=884736)

@5,177,545us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> found in cb(Sc=0x407c9000,

 Ec=0x408a1000, Ss=0x407c9000, Es=0x408a1000, PSc=0x8fc94000)

@5,177,918us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> returning physAddr=0x8fc94

000

@5,178,105us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> return (0x8fc94000)

@5,178,281us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4144

b000, size=28)

@5,178,460us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x4144b000,

 size=28)

@5,178,664us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> found in cb(Sc=0x4144b000,

 Ec=0x4144b01c, Ss=0x4144b000, Es=0x4144b01c, PSc=0x8c9ba000)

@5,520,076us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> returning physAddr=0x8c9ba

000

@5,520,313us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> return (0x8c9ba000)

@5,520,501us: [+0 T:0x00008003 S:0xbe3ff80c] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

002000b, command=0x0

@5,520,695us: [+0 T:0x00008003 S:0xbe3ff7dc] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

@5,520,929us: [+0 T:0x00008003 S:0xbe3ff7dc] OC - Comm_put> return (0)

@5,521,114us: [+0 T:0x00008003 S:0xbe3ff7d4] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3ff87c, timeout

=-1)

 

 

After this it locks up and never returns control to the ARM after the
VIDENC_process() call.

 

It looks like its locking up inside the Codec Engine after returning
from the DSP side process call.

 

Can anyone shed some light on whats going wrong?

 

 

Regards,

Etienne Eccles

 

VCA Technology

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100413/4f62c55a/attachment-0001.html>

From cyril at ti.com  Tue Apr 13 09:10:35 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Tue, 13 Apr 2010 10:10:35 -0400
Subject: [PATCH 4/8] Davinci: gpio - minor cleanup
In-Reply-To: <4BC45524.70805@mvista.com>
References: <1271106933-13911-1-git-send-email-cyril@ti.com>
	<1271106933-13911-2-git-send-email-cyril@ti.com>
	<1271106933-13911-3-git-send-email-cyril@ti.com>
	<1271106933-13911-4-git-send-email-cyril@ti.com>
	<1271106933-13911-5-git-send-email-cyril@ti.com>
	<4BC45524.70805@mvista.com>
Message-ID: <4BC47B5B.4070001@ti.com>

Hi Sergei,

Sergei Shtylyov wrote:
[...]
>> +static int
>> +davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
>> +{
>> +	return __davinci_direction(chip, offset, true);
> 
>    No, this ignores 'value'. The function should also program GPIO to 
> the value specified.

Good catch, Sergei. Thanks.

Regards
Cyril.

From cring at ti.com  Tue Apr 13 12:56:45 2010
From: cring at ti.com (Ring, Chris)
Date: Tue, 13 Apr 2010 12:56:45 -0500
Subject: Codec engine lockup
In-Reply-To: <95FAFD227E8A2947BA96E1C807505D0412CD5F@sbs001.office.local>
References: <95FAFD227E8A2947BA96E1C807505D0412CD5F@sbs001.office.local>
Message-ID: <92CDD168D1E81F4F9D3839DC45903FC676C07D7E@dlee03.ent.ti.com>

The last line is an ARM-side Comm_get() call (implemented with MSGQ_get()) - which blocks until the DSP finishes it's job and sends an 'I'm done' reply message.  Basically, you've sent a request to VIDENC_process() a frame which never returns.  The DSP is hanging/crashing/waiting and never returning "I'm done" to the ARM.

Can you connect to CCS and see what's happening on the DSP side?  Since this is your codec, maybe set breakpoints in your process() method and see if it ever gets called.

http://wiki.davincidsp.com/index.php/Debugging_the_DSP_side_of_a_CE_application_using_CCS

Chris

________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Etienne Eccles
Sent: Tuesday, April 13, 2010 5:39 AM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: Codec engine lockup


H


I am getting the following debug output . using CE_DEBUG=3 when creating and using a custom VIDENC codec:



root at nvc1346:/opt/davinci# CE_DEBUG=3 ./stabd -d -p a
root at nvc1346:/opt/davinci# @0,196,096us: [+4 T:0x00004000 S:0xbec8cbbc] OG - Global_init> This program w
as built with the following packages:
@0,197,108us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package gnu.targets.rts470MV (/home/vcastab/svn/ud
p/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/gnu/targets/rts470MV/) [1,0,0,0,1203621000516]
@0,197,334us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package dsplink.gpp (/home/vcastab/svn/udp/linux/d
vsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/dsplink/gpp/) [3,0,0]
@0,197,516us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.xdais.dm (/home/vcastab/svn/udp/linux/d
vsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/dm/) [1,0,4,1210262746529]
@0,197,948us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.xdais (/home/vcastab/svn/udp/linux/dvsd
k/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/) [1,2,1,1210262742149]
@0,198,149us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.utils.trace (/home/vcastab/svn/udp/
linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/utils/trace/) [1,0,0,122094336
6422]
@0,198,331us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.utils.xdm (/home/vcastab/svn/udp
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/utils/xdm/) [1,0,1,1220951322616]
@0,198,510us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.fc.dman3 (/home/vcastab/svn/udp/lin
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/fc/dman3/) [1,0,3,1220943053023]
@0,198,682us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.fc.acpy3 (/home/vcastab/svn/udp/lin
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/fc/acpy3/) [1,0,2,1220943014135]
@0,198,852us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.linuxutils.cmem (/home/vcastab/svn/
udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/linuxutils/cmem/) [2,0,1,1
204929560755]
@0,199,030us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.catalog.c470 (/home/vcastab/svn/udp/lin
ux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/catalog/c470/) [1,0,1,0,1203561761475]
@0,199,200us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.platforms.evmDM6446 (/home/vcastab/svn/
udp/linux/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/platforms/evmDM6446/) [1,0,0,1,1192229600615]
@0,199,369us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.osal (/home/vcastab/svn/udp/linu
x/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/osal/) [2,0,2,1220951127739]
@0,199,539us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.ipc (/home/vcastab/svn/udp/linux
/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/) [2,0,1,1220951085787]
@0,199,704us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.alg (/home/vcastab/svn/udp/linux
/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/alg/) [1,0,1,1220950781938]
@0,199,875us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.osal.linux (/home/vcastab/svn/ud
p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/osal/linux/) [2,0,1,1220951140072
]
@0,200,049us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.ipc.dsplink (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/dsplink/) [2,0,1,12209510968
18]
@0,200,219us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce (/home/vcastab/svn/udp/linux/dvs
dk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/) [1,0,6,1220950771473]
@0,200,386us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.video (/home/vcastab/svn/udp/lin
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/video/) [1,0,3,1220951334122]
@0,200,559us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package codecs.vca_stab (/home/vcastab/svn/vt/davi
nci/trunk/ce1/codecs/vca_stab/) []
@0,200,718us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.bioslog (/home/vcastab/svn/udp/l
inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/bioslog/) [1,0,1,1220950800329]
@0,587,586us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.utils.trace (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/utils/trace/) [1,0,1,12209513170
87]
@0,587,929us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package apps.stab_client (/home/vcastab/svn/vt/dav
inci/trunk/ce1/apps/stab_client/) []
@0,588,146us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x20028)
@0,588,352us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x1f4c0)
@0,588,676us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> Enter(0x18)
@0,589,026us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return (0x5e138)
@0,589,716us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit> enter (fxn=0x1dda8)
@0,590,050us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> Enter(0x18)
@0,590,269us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return (0x5e188)
@0,590,492us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit> enter (fxn=0x1b9f4)
@0,590,839us: [+0 T:0x00004000 S:0xbec8cbbc] OG - Global_atexit> enter (fxn=0x1eb44)
@0,593,794us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem - Sem_create> count: 0
@0,594,023us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> Enter(0x14)
@0,594,212us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> return (0x5e208)
@0,594,470us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x5e208]
@0,594,698us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem - Sem_create> count: 0
@0,594,859us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> Enter(0x14)
@0,595,056us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> return (0x5e220)
@0,595,220us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x5e220]
@0,595,378us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> Enter(0x18)
@0,595,544us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> return (0x5e238)
@0,595,707us: [+0 T:0x00004000 S:0xbec8cb8c] OT - Thread_create> Enter (fxn=0x1ab34, attrs=0x0)
@0,595,869us: [+0 T:0x00004000 S:0xbec8cb74] OM - Memory_alloc> Enter(0x64)
@0,596,064us: [+0 T:0x00004000 S:0xbec8cb74] OM - Memory_alloc> return (0x5e258)
@0,598,964us: [+1 T:0x00004002 S:0xbe5ffa74] OP - daemon> thread created.
@0,599,205us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d> Enter (proc=0xbe5ffaec)
@0,599,387us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem - Entered Sem_pend> sem[0x5e208] timeout
[0xffffffff]
@0,599,998us: [+0 T:0x00004000 S:0xbec8cb8c] OT - Thread_create> Exit (task=0x5e258)
@0,600,235us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x1a6f4)
@0,600,501us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x1c7e8)
@0,600,791us: [+0 T:0x00004000 S:0xbec8cbac] ti.sdo.ce.alg - ALG_init> Enter
@0,600,984us: [+0 T:0x00004000 S:0xbec8cb9c] OG - Global_atexit> enter (fxn=0x209f0)
@0,601,171us: [+0 T:0x00004000 S:0xbec8cbcc] ti.sdo.ce.alg - ALG_init> Exit
@0,601,339us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x20490)
@0,601,541us: [+0 T:0x00004000 S:0xbec8cb9c] OM - Memory_alloc> Enter(0x18)
@0,601,767us: [+0 T:0x00004000 S:0xbec8cb9c] OM - Memory_alloc> return (0x60418)
@0,601,955us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x1eca8)
@0,602,262us: [+6 T:0x00004000 S:0xbec8cbc4] CE - Engine_init> CE debugging on (CE_DEBUG=3; allowed CE_D
EBUG levels: 1=min, 2=good, 3=max)
@0,602,481us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit> enter (fxn=0x17734)
@0,602,667us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> Enter(0x18)
@0,602,852us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return (0x60458)
@0,603,024us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> Enter(0x18)
@0,603,247us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return (0x60478)
@0,603,423us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> Enter(0x18)
@0,603,600us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return (0x60498)
@0,944,735us: [+0 T:0x00004000 S:0xbec8cbc4] CS - Server_init()
@0,944,957us: [+0 T:0x00004000 S:0xbec8cbc4] CS - Server_init> Global_useLinkArbiter = 0
@0,945,138us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x16284)
@0,945,529us: [+0 T:0x00004000 S:0xbec8cbd4] OG - Global_atexit> enter (fxn=0x14148)
@0,945,950us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@0,946,486us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x403ee000.
@0,946,744us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x403ee000) = 0x8ff25
000.
@0,946,938us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x403ee000, size=
884736, physAddr=0x8ff25000)
@0,947,127us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@0,947,319us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@0,947,514us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60518)
@0,947,842us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8ff25000,
cb->size=884736, cb->virt=0x403ee000
@0,948,044us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x403ee000)
@0,948,270us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@0,948,643us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x404c9000.
@0,948,931us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x404c9000) = 0x8cac7
000.
@0,949,123us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x404c9000, size=
884736, physAddr=0x8cac7000)
@0,949,305us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@0,949,467us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@0,949,651us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60530)
@0,949,823us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8cac7000,
cb->size=884736, cb->virt=0x404c9000
@0,950,004us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x404c9000)
@0,950,206us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@0,950,595us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x405c9000.
@0,950,841us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x405c9000) = 0x8c9c7
000.
@0,951,032us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x405c9000, size=
884736, physAddr=0x8c9c7000)
@0,951,219us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@0,951,380us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@0,951,592us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60548)
@0,951,775us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8c9c7000,
cb->size=884736, cb->virt=0x405c9000
@0,951,959us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x405c9000)
@0,952,125us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@0,952,475us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x406c9000.
@0,952,718us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x406c9000) = 0x8c879
000.
@0,952,911us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x406c9000, size=
884736, physAddr=0x8c879000)
@0,953,145us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@0,953,310us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@0,953,490us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60560)
@1,294,466us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8c879000,
cb->size=884736, cb->virt=0x406c9000
@1,294,700us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x406c9000)
@1,294,877us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@1,295,385us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x407c9000.
@1,295,626us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x407c9000) = 0x8fc94
000.
@1,295,850us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x407c9000, size=
884736, physAddr=0x8fc94000)
@1,296,040us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@1,296,206us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@1,296,387us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60578)
@1,296,557us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8fc94000,
cb->size=884736, cb->virt=0x407c9000
@1,296,739us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x407c9000)
@1,296,908us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@1,297,589us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x40a5a000.
@1,298,146us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x40a5a000) = 0x8f8de
000.
@1,298,345us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x40a5a000, size=
884736, physAddr=0x8f8de000)
@1,298,538us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@1,298,750us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@1,298,934us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60590)
@1,299,106us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8f8de000,
cb->size=884736, cb->virt=0x40a5a000
@1,299,290us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x40a5a000)
@1,309,917us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - Engine_open> Enter('vca_engine', 0x0, 0xbe3ffa84)
@1,310,205us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc> Enter(0x2c)
@1,310,419us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc> return (0x605a8)
@1,310,604us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - rserverOpen('./server_release.x64P'), count = 0
@1,310,785us: [+0 T:0x00008003 S:0xbe3ff9ac] OP - Processor_create> Enter(imageName='./server_release.x6
4P', linkCfg='(null)', attrs=0xbe3ffa30)
@1,312,833us: [+0 T:0x00008003 S:0xbe3ff994] OM - Memory_alloc> Enter(0x24)
@1,313,100us: [+0 T:0x00008003 S:0xbe3ff994] OM - Memory_alloc> return (0x605d8)
@1,313,292us: [+0 T:0x00008003 S:0xbe3ff98c] OP - doCmd> Enter (cmdId=1, proc=0x605d8)
@1,313,470us: [+0 T:0x00008003 S:0xbe3ff97c] ti.sdo.ce.osal.Sem - Entered Sem_post> sem[0x5e208]
@1,313,801us: [+0 T:0x00008003 S:0xbe3ff98c] ti.sdo.ce.osal.Sem - Leaving Sem_post> sem[0x5e208]
@1,314,019us: [+0 T:0x00008003 S:0xbe3ff96c] ti.sdo.ce.osal.Sem - Entered Sem_pend> sem[0x5e220] timeout
[0xffffffff]
@1,314,506us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem - Leaving Sem_pend> sem[0x5e208] status[
0]
@1,314,978us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d> Exit (result=1)
@1,315,460us: [+0 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Enter(proc=0x605d8)
@1,315,900us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Initializing DSP PROC...
@1,316,335us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Using DspLink config data for entr
y #0 [server './server_release.x64P']
@1,316,786us: [+0 T:0x00004002 S:0xbe5ffa5c] OM - Memory_alloc> Enter(0xe0)
@1,317,458us: [+0 T:0x00004002 S:0xbe5ffa5c] OM - Memory_alloc> return (0x60600)
@1,318,325us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Adding DSP segment #0 to Link conf
iguration: name='DDR', startAddress=0x88200000, sizeInBytes=0x400000, shared=1
@1,660,152us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Adding DSP segment #1 to Link conf
iguration: name='DSPLINKMEM', startAddress=0x88100000, sizeInBytes=0x100000, shared=1
@1,660,412us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Adding DSP segment #2 to Link conf
iguration: name='RESET_VECTOR', startAddress=0x88000000, sizeInBytes=0x80, shared=0
@1,660,650us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Adding DSP segment #3 to Link conf
iguration: name='DDRALGHEAP', startAddress=0x88800000, sizeInBytes=0x1c00000, shared=0
@1,660,856us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> DOPOWERCONTROL was=0; now=0
SET WIDTH to 720 HEIGHT to 576
@1,685,617us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Attaching to DSP PROC...
@1,698,711us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Opening MSGQ pool...
@1,699,722us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Loading ./server_release.x64P on D
SP (1 args)...
@1,892,865us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Starting DSP PROC...
@1,916,709us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Opening remote transport...
@1,917,511us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> return (1)
@1,918,475us: [+0 T:0x00004002 S:0xbe5ffa64] ti.sdo.ce.osal.Sem - Entered Sem_post> sem[0x5e220]
@1,918,948us: [+0 T:0x00008003 S:0xbe3ff96c] ti.sdo.ce.osal.Sem - Leaving Sem_pend> sem[0x5e220] status[
0]
@1,919,260us: [+0 T:0x00008003 S:0xbe3ff98c] OP - doCmd> Exit (result=1)
@1,919,438us: [+0 T:0x00008003 S:0xbe3ff9ac] OP - Processor_create> return (0x605d8)
@1,919,611us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - rserverOpen('./server_release.x64P'): 0x5701c done.
@1,919,799us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc> Enter(0x1e)
@1,919,990us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc> return (0x61fd0)
@1,920,188us: [+0 T:0x00008003 S:0xbe3ff9bc] OC - Comm_create> Enter(queueName='vca_engine_0', queue=0x6
05b8, attrs=0x0)
@1,920,370us: [+0 T:0x00008003 S:0xbe3ff9a4] OM - Memory_alloc> Enter(0x4)
@1,920,579us: [+0 T:0x00008003 S:0xbe3ff9a4] OM - Memory_alloc> return (0x61ff8)
@1,921,144us: [+0 T:0x00008003 S:0xbe3ff9bc] OC - Comm_create> return (0x61ff8)
@1,921,384us: [+0 T:0x00008003 S:0xbe3ff9bc] OM - Memory_free> Enter(0x61fd0, 0x1e)
@1,921,582us: [+0 T:0x00008003 S:0xbe3ff9bc] OM - Memory_free> return (0x1)
@1,921,758us: [+0 T:0x00008003 S:0xbe3ff9c4] OC - Comm_alloc> Enter(poolId=0x0, msg=0x605c4, size=576)
@1,921,990us: [+0 T:0x00008003 S:0xbe3ff9c4] OC - Comm_alloc> msg=0x413dbc80, returning (0)
@1,922,187us: [+0 T:0x00008003 S:0xbe3ff9a4] OC - Comm_locate> Enter(queueName='rmsq', queue=0x605b4)
@1,931,192us: [+0 T:0x00008003 S:0xbe3ff9a4] OC - Comm_locate> return (0)
@1,931,465us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - checkServer(0x605a8)
@1,931,739us: [+0 T:0x00008003 S:0xbe3ff9b4] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@1,932,050us: [+0 T:0x00008003 S:0xbe3ff9b4] OC - Comm_put> return (0)
@1,932,339us: [+0 T:0x00008003 S:0xbe3ff9ac] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ffa28, timeout
=-1)
@1,932,567us: [+0 T:0x00008003 S:0xbe3ff9ac] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@1,932,768us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - rmsInit> RMS initialized(0x605a8); CE_DEBUG on, settin
g DSP trace mask to *+01234567,GT_prefix=12345,GT_time=3
@1,932,966us: [+0 T:0x00008003 S:0xbe3ff9b4] CE - Engine_setTrace> Enter(engine=0x605a8, mask='*+0123456
7,GT_prefix=12345,GT_time=3')
@1,933,180us: [+1 T:0x00008003 S:0xbe3ff9b4] CE - Engine_setTrace> Requesting DSP set trace ...
@1,933,348us: [+0 T:0x00008003 S:0xbe3ff984] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@1,933,635us: [+0 T:0x00008003 S:0xbe3ff984] OC - Comm_put> return (0)
@1,933,821us: [+0 T:0x00008003 S:0xbe3ff97c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff9ec, timeout
=-1)
@1,934,437us: [+0 T:0x00004002 S:0xbe5ffa74] ti.sdo.ce.osal.Sem - Leaving Sem_post> sem[0x5e220]
@1,934,692us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d> Enter (proc=0xbe5ffaec)
@1,934,920us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem - Entered Sem_pend> sem[0x5e208] timeout
[0xffffffff]
@1,937,498us: [+0 T:0x00008003 S:0xbe3ff97c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@1,937,904us: [+0 T:0x00008003 S:0xbe3ff9b4] CE - Engine_setTrace> return(0)
@1,938,126us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@1,938,384us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put> return (0)
@1,938,673us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff9d0, timeout
=-1)
@1,938,903us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @0x00000208:[T:0x00000000] ZZ - main> Welcome to loopback server's main().
[DSP] @0x0000086c:[T:0x8880415c] LS - server()
[DSP] @0x0000088d:[T:0x8880415c] OM - Memory_alloc> Enter(size=0x24)
[DSP] @0x000008b8:[T:0x8880415c] OM - Memory_alloc> return (0x882ab060)
[DSP] @0x000008e6:[T:0x8880415c] LS - server: serverMsgQueue = 0x00000001
[DSP] @0x0000090f:[T:0x8880415c] LS - server: waiting for cmd
[DSP] @0x00008cc2:[T:0x8880006c] CR - processRmsCmd(0x88105ca8, 4056): cmd = 6
[DSP] @0x00009b1c:[T:0x8880006c] CR - processRmsCmd(0x88105ca8, 4056): cmd = 8
[DSP] @0x00009b50:[T:0x8880006c] CR - setting trace mask to *+01234567,GT_prefix=12345,GT_time=3
[DSP] @0,039,852tk: [+0 T:0x8880006c S:0x88803fdc] OG - Global_setSpecialTrace> enter(mask='*+01234567,G
T_prefix=12345,GT_time=3')
[DSP] @0,039,938tk: [+4 T:0x8880006c S:0x88803fdc] OG - Global_setSpecialTrace> This program was built w
ith the following packages:
[DSP] @0,040,015tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.targets.rts6000 (/home/vcastab/sv
n/udp/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/targets/rts6000/) [1,0,0,0,1203621186754]
[DSP] @0,040,139tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.fc.dman3 (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/fc/dman3/) [1,0,3,122094305
3023]
[DSP] @0,040,255tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.rtdx (/home/vcastab/svn/udp/linux
/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/rtdx/) [2,0,0,1,1194024051755]
[DSP] @0,040,356tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.psl (/home/vcastab/svn/udp/linux/
dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/psl/) [5,0,0,0,0]
[DSP] @0,040,451tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.bios (/home/vcastab/svn/udp/linux
/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/bios/) [5,2,4,9,1193960176642]
[DSP] @0,040,552tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.fc.dskt2 (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/fc/dskt2/) [1,0,4,122094309
5081]
[DSP] @0,040,668tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.xdais.dm (/home/vcastab/svn/udp/l
inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/dm/) [1,0,4,1210262746529]
[DSP] @0,040,781tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.xdais (/home/vcastab/svn/udp/linu
x/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/) [1,2,1,1210262742149]
[DSP] @0,040,890tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.node (/home/vcastab/svn/ud
p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/node/) [1,0,0,1220951122176]
[DSP] @0,041,001tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.ipc.dsplink.dsp (/home/vca
stab/svn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/dsplink/dsp/) [2,0
,1,1220951102696]
[DSP] @0,041,122tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.utils.trace (/home/vcastab/sv
n/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/utils/trace/) [1,0,0,122
0943366422]
[DSP] @0,041,242tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.utils.xdm (/home/vcastab/s
vn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/utils/xdm/) [1,0,1,122095132
2616]
[DSP] @0,041,357tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.fc.acpy3 (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/fc/acpy3/) [1,0,2,122094301
4135]
[DSP] @0,041,473tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package dsplink.dsp (/home/vcastab/svn/udp/l
inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/dsplink/dsp/) [1,3,0]
[DSP] @0,041,578tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.bios.utils (/home/vcastab/svn/udp
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/bios/utils/) [2,0,1,0,11918918306
09]
[DSP] @0,041,693tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.catalog.c6000 (/home/vcastab/svn/
udp/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/catalog/c6000/) [1,0,0,0,1203561781695]
[DSP] @0,041,802t at 2,297,823us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put> Enter(queue=0x0, msg=0x413d
bc80)
@2,298,120us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put> return (0)
@2,298,417us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff9d0, timeout
=-1)
@2,298,649us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
k: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.platforms.evmDM6446 (/home/vcastab/svn/udp/linux/d
vsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/platforms/evmDM6446/) [1,0,0,1,1192229600615]
[DSP] @0,041,919tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.osal (/home/vcastab/svn/ud
p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/osal/) [2,0,2,1220951127739]
[DSP] @0,042,030tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.ipc (/home/vcastab/svn/udp
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/) [2,0,1,1220951085787]
[DSP] @0,042,139tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.alg (/home/vcastab/svn/udp
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/alg/) [1,0,1,1220950781938]
[DSP] @0,042,249tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.osal.bios (/home/vcastab/s
vn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/osal/bios/) [2,0,1,122095113
3740]
[DSP] @0,042,365tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.ipc.bios (/home/vcastab/sv
n/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/bios/) [2,0,1,12209510910
97]
[DSP] @0,042,487tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce (/home/vcastab/svn/udp/lin
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/) [1,0,6,1220950771473]
[DSP] @0,042,593tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.bioslog (/home/vcastab/svn
/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/bioslog/) [1,0,1,1220950800329
]
[DSP] @0,042,706tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.video (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/video/) [1,0,3,1220951334122]
[DSP] @0,042,818tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package codecs.vca_stab (/home/vcastab/svn/v
t/davinci/trunk/ce1/codecs/vca_stab/) []
[DSP] @0,042,901tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package servers.vca_stab_server (/home/vcast
ab/svn/vt/davinci/trunk/ce1/servers/vca_stab_server/) []
[DSP] @0,042,992tk: [+0 T:0x8880006c S:0x88803fdc] OG - Global_setSpecialTrace> return
[DSP] @0,050,728tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @0,050,799tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
[DSP] @0,885,481tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @0,885,547tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@2,650,231us: [+0 T:0x00008003 S:0xbe3ff974] CE - Engine_fwriteTrace> returning count [6828]
@2,650,445us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - Engine_open> return(394664)
@2,650,660us: [+0 T:0x00008003 S:0xbe3ffa34] ti.sdo.ce.video.VIDENC - VIDENC_create> Enter (engine=0x605
a8, name='vca_stab', params=0xbe3ffa88)
@2,650,896us: [+0 T:0x00008003 S:0xbe3ffa04] CV - VISA_create(0x605a8, 'vca_stab', 0xbe3ffa88, 0x828, 't
i.sdo.ce.video.IVIDENC')
@2,651,104us: [+0 T:0x00008003 S:0xbe3ff92c] CV - VISA_create2(0x605a8, 'vca_stab', 0xbe3ffa88, 0x2c, 0x
828, 'ti.sdo.ce.video.IVIDENC')
@2,651,363us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc> Enter(0x30)
@2,651,589us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc> return (0x62058)
@2,651,782us: [+0 T:0x00008003 S:0xbe3ff8bc] CE - Engine_createNode(0x605a8, 'vca_stab', 828, 0xbe3ffa88
, 0x2c, 0xbe3ffa30)
@2,651,980us: [+0 T:0x00008003 S:0xbe3ff8a4] OM - Memory_alloc> Enter(0x20)
@2,652,163us: [+0 T:0x00008003 S:0xbe3ff8a4] OM - Memory_alloc> return (0x61fd0)
@2,652,361us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_create> Enter(queueName='gppfromnode_1', queue=0x
61fd8, attrs=0x0)
@2,652,545us: [+0 T:0x00008003 S:0xbe3ff87c] OM - Memory_alloc> Enter(0x4)
@2,652,730us: [+0 T:0x00008003 S:0xbe3ff87c] OM - Memory_alloc> return (0x62090)
@2,993,385us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_create> return (0x62090)
@2,993,649us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@2,993,987us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put> return (0)
@2,994,199us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff914, timeout
=-1)
@3,010,127us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@3,010,439us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@3,010,710us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put> return (0)
@3,010,993us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff914, timeout
=-1)
@3,011,253us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@3,011,492us: [+4 T:0x00008003 S:0xbe3ff8bc] CE - Engine_createNode> created node(stdIn=0x2, stdOut=0x10
001, msgq=0x62090, algName='vca_stab', rmsNode=0x882ab088, algHandle=0x882ab168)
@3,011,735us: [+0 T:0x00008003 S:0xbe3ff81c] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@3,011,981us: [+0 T:0x00008003 S:0xbe3ff81c] OC - Comm_put> return (0)
@3,012,254us: [+0 T:0x00008003 S:0xbe3ff814] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff8a8, timeout
=-1)
@3,012,488us: [+0 T:0x00008003 S:0xbe3ff814] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @2,500,228tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 0
[DSP] @2,500,305tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc> Enter(size=0x18)
[DSP] @2,500,365tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc> return (0x882ab088)
[DSP] @2,500,425tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc> Enter(size=0xb)
[DSP] @2,500,480tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc> return (0x882ab0a0)
[DSP] @2,500,549tk: [+0 T:0x8880006c S:0x88803edc] OM - Memory_alloc> Enter(size=0x20)
[DSP] @2,500,605tk: [+0 T:0x8880006c S:0x88803edc] OM - Memory_alloc> return (0x882ab0b0)
[DSP] @2,500,665tk: [+0 T:0x8880006c S:0x88803eac] OM - Memory_alloc> Enter(size=0x24)
[DSP] @2,500,722tk: [+0 T:0x8880006c S:0x88803eac] OM - Memory_alloc> return (0x882ab0d0)
[DSP] @2,500,806tk: [+0 T:0x8880006c S:0x88803ec4] ti.sdo.ce.video.VIDENC - VIDENC_create> Enter (engine
=0x0, name='vca_stab', params=0x88105cc0)
[DSP] @2,500,902tk: [+0 T:0x8880006c S:0x88803e8c] CV - VISA_create(0x0, 'vca_stab', 0x88105cc0, 0x828,
'ti.sdo.ce.video.IVIDENC')
[DSP] @2,500,988tk: [+0 T:0x8880006c S:0x88803d7c] CV - VISA_create2(0x0, 'vca_stab', 0x88105cc0, 0x2c,
0x828, 'ti.sdo.ce.video.IVIDENC')
[DSP] @2,501,089tk: [+0 T:0x8880006c S:0x88803d14] CE - Engine_open> Enter('local', 0x88803d6c, 0x33c)
[DSP] @2,501,158tk: [+0 T:0x8880006c S:0x88803cf4] OM - Memory_alloc> Enter(size=0x2c)
[DSP] @2,501,216tk: [+0 T:0x8880006c S:0x88803cf4] OM - Memory_alloc> return (0x882ab138)
[DSP] @2,501,287tk: [+0 T:0x8880006c S:0x88803d14] CE - Engine_open> return(-2010468040)
[DSP] @2,501,362tk: [+0 T:0x8880006c S:0x88803d5c] OM - Memory_alloc> Enter(size=0x30)
[DSP] @2,501,418tk: [+0 T:0x8880006c S:0x88803d5c] OM - Memory_alloc> return (0x882ab168)
[DSP] @2,501,484tk: [+0 T:0x8880006c S:0x88803d34] ti.sdo.ce.alg.Algorithm - Algorithm_create> Enter(fxn
s=0x88266574, idma3Fxns=0x882665a0, params=0x88105cc0, attrs=0x88803e80)
[DSP] @2,501,595tk: [+0 T:0x8880006c S:0x88803d14] OM - Memory_alloc> Enter(size=0x10)
[DSP] @2,501,652tk: [+0 T:0x8880006c S:0x88803d14] OM - Memory_alloc> return (0x882ab198)
[DSP] @2,519,578tk: [+0 T:0x8880006c S:0x88803c34] OM - Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn
Bytes=1008)
[DSP] @2,519,697tk: [+0 T:0x8880006c S:0x88803c34] OM - Memory_cacheWbInv> return
[DSP] @2,535,121tk: [+0 T:0x8880006c S:0x88803c0c] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @2,535,236tk: [+0 T:0x8880006c S:0x88803c0c] OM - Memory_cacheWbInv> return
[DSP] @2,535,480tk: [+0 T:0x8880006c S:0x88803bc4] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @2,535,566tk: [+0 T:0x8880006c S:0x88803bc4] OM - Memory_cacheWbInv> return
[DSP] @2,535,835tk: [+0 T:0x8880006c S:0x88803b9c] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @2,535,925tk: [+0 T:0x8880006c S:0x88803b9c] OM - Memory_cacheWbInv> return
[DSP] @2,536,688tk: [+0 T:0x8880006c S:0x88803cb4] OM - Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn
Bytes=1008)
[DSP] @2,536,793tk: [+0 T:0x8880006c S:0x88803cb4] OM - Memory_cacheWbInv> return
[DSP] @2,536,915tk: [+0 T:0x8880006c S:0x88803d34] ti.sdo.ce.alg.Algorithm - Algorithm_create> return (0
x882ab198)
[DSP] @2,536,997tk: [+0 T:0x8880006c S:0x88803ec4] ti.sdo.ce.video.VIDENC - VIDENC_create> return (0x882
ab168)
[DSP] @2,537,080tk: [+4 T:0x8880006c S:0x88803e84] OT - Thread_create > name: "vca_stab#0", pri:  -1, st
ack size:  16384, stack seg: 0
[DSP] @2,539,051tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 1
[DSP] @2,541,980tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @2,542,048tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@3,369,765us: [+0 T:0x00008003 S:0xbe3ff84c] CE - Engine_fwriteTrace> returning count [3758]
@3,369,981us: [+2 T:0x00008003 S:0xbe3ff8bc] CE - Engine_createNode> Returning 0x61fd0
@3,370,160us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc> Enter(0x4)
@3,370,349us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc> return (0x620a0)
@3,370,528us: [+0 T:0x00008003 S:0xbe3ff90c] OC - Comm_alloc> Enter(poolId=0x0, msg=0x620a0, size=828)
@3,370,760us: [+0 T:0x00008003 S:0xbe3ff90c] OC - Comm_alloc> msg=0x413dcc80, returning (0)
@3,370,981us: [+5 T:0x00008003 S:0xbe3ff92c] CV - VISA_create> remote codec created (name='vca_stab', lo
calQueueID=0x10001, remoteQueueID=0x0002)
@3,371,235us: [+0 T:0x00008003 S:0xbe3ffa34] ti.sdo.ce.video.VIDENC - VIDENC_create> return (0x62058)
@3,374,722us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62
058, id=257, params=0x5abe8, status=0xbe3ffa28
@3,375,009us: [+5 T:0x00008003 S:0xbe3ff844] CV - VISA_allocMsg> Allocating message for messageId=0x0002
0006
@3,375,208us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
0020006, command=0x1
@3,375,431us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@3,375,692us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put> return (0)
@3,375,884us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3ff884, timeout
=-1)
@3,376,737us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@3,377,056us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@3,377,322us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put> return (0)
@3,377,720us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff800, timeout
=-1)
@3,378,173us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @3,385,962tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88
2ab168, msg=0x88106c80); messageId=0x00020006
[DSP] @3,386,079tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl
e=0x882ab168, id=257, params=0x88106cb4, status=0x88106d00
[DSP] @3,386,192tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_enter(visa=0x882ab168): algHandle = 0x882ab
198
[DSP] @3,386,267tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h
andle=0x882ab198)
[DSP] @3,386,383tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> return
[DSP] @3,386,881tk: [+0 T:0x8892e644 S:0x889324c4] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @3,386,997tk: [+0 T:0x8892e644 S:0x889324c4] OM - Memory_cacheWbInv> return
[DSP] @3,387,126tk: [+0 T:0x8892e644 S:0x889324b4] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @3,387,203tk: [+0 T:0x8892e644 S:0x889324b4] OM - Memory_cacheWbInv> return
[DSP] @3,387,442tk: [+0 T:0x8892e644 S:0x8893248c] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @3,387,538tk: [+0 T:0x8892e644 S:0x8893248c] OM - Memory_cacheWbInv> return
[DSP] @3,387,604tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_exit(visa=0x882ab168): algHandle = 0x882ab1
98
[DSP] @3,387,679tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter
(handle=0x882ab198)
[DSP] @3,387,760tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur
n
[DSP] @3,387,834tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle
=0x882ab168, retVal=0x0)
[DSP] @3,387,919tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned from call(algHandle=0x882ab168, m
sg=0x88106c80); messageId=0x00020006
[DSP] @3,389,753tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @3,389,829tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@3,727,875us: [+0 T:0x00008003 S:0xbe3ff7a4] CE - Engine_fwriteTrace> returning count [2039]
@3,728,094us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call Completed: messageId=0x00020006, command=0x1
, return(status=0)
@3,728,332us: [+5 T:0x00008003 S:0xbe3ff834] CV - VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit
h messageId=0x00020006
@3,728,530us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620
58, retVal=0x0)
@3,728,715us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62
058, id=259, params=0x5abe8, status=0xbe3ff930
@3,728,916us: [+5 T:0x00008003 S:0xbe3ff844] CV - VISA_allocMsg> Allocating message for messageId=0x0002
0007
@3,729,097us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
0020007, command=0x1
@3,729,285us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@3,729,551us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put> return (0)
@3,729,751us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3ff884, timeout
=-1)
@3,730,056us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@3,730,282us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@3,730,528us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put> return (0)
@3,730,802us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff800, timeout
=-1)
@3,731,055us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @4,206,979tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88
2ab168, msg=0x88106c80); messageId=0x00020007
[DSP] @4,207,083tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl
e=0x882ab168, id=259, params=0x88106cb4, status=0x88106d00
[DSP] @4,207,189tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_enter(visa=0x882ab168): algHandle = 0x882ab
198
[DSP] @4,207,262tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h
andle=0x882ab198)
[DSP] @4,207,346tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> return
[DSP] @4,207,420tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_exit(visa=0x882ab168): algHandle = 0x882ab1
98
[DSP] @4,207,494tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter
(handle=0x882ab198)
[DSP] @4,207,571tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur
n
[DSP] @4,207,636tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle
=0x882ab168, retVal=0x0)
[DSP] @4,207,714tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned from call(algHandle=0x882ab168, m
sg=0x88106c80); messageId=0x00020007
[DSP] @4,209,298tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @4,209,366tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@4,078,103us: [+0 T:0x00008003 S:0xbe3ff7a4] CE - Engine_fwriteTrace> returning count [1451]
@4,078,339us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call Completed: messageId=0x00020007, command=0x1
, return(status=0)
@4,078,546us: [+5 T:0x00008003 S:0xbe3ff834] CV - VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit
h messageId=0x00020007
@4,078,742us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620
58, retVal=0x0)
SVN Version: 3093:3110
STAB Version: 01.06.08
@4,079,044us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> Enter(size=28, align=-1, cached=FA
LSE, heap=FALSE)
@4,079,389us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> CMEM_alloc(28) = 0x4144b000.
@4,079,680us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> CMEM_getPhys(0x4144b000) = 0x8c9ba
000.
@4,079,883us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> Enter(virtAddr=0x4144b000, size=
28, physAddr=0x8c9ba000)
@4,080,074us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> creating new contigBuf object
@4,080,242us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc> Enter(0x10)
@4,080,453us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc> return (0x60fb0)
@4,080,628us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> returning: cb->phys=0x8c9ba000,
cb->size=28, cb->virt=0x4144b000
@4,080,810us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> return (0x4144b000)
@4,081,014us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> Enter(size=32, align=-1, cached=FA
LSE, heap=FALSE)
@4,081,323us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> CMEM_alloc(32) = 0x41458000.
@4,081,570us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> CMEM_getPhys(0x41458000) = 0x8c9ad
000.
@4,081,763us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> Enter(virtAddr=0x41458000, size=
32, physAddr=0x8c9ad000)
@4,081,953us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> creating new contigBuf object
@4,082,119us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc> Enter(0x10)
@4,082,348us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc> return (0x620b0)
@4,082,535us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> returning: cb->phys=0x8c9ad000,
cb->size=32, cb->virt=0x41458000
@4,082,729us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> return (0x41458000)
MAC: 00:13:23:04:13:46 USN: 970041346
@4,349,545us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62
058, id=41216, params=0xbe3fedb8, status=0xbe3fed28
@4,349,833us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg> Allocating message for messageId=0x0002
0008
@4,350,045us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
0020008, command=0x1
@4,350,250us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@4,350,512us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> return (0)
@4,350,710us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3fea24, timeout
=-1)
@4,351,302us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@4,351,574us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@4,351,839us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> return (0)
@4,352,129us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3fe9a0, timeout
=-1)
@4,352,373us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @5,647,854tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88
2ab168, msg=0x88106c80); messageId=0x00020008
[DSP] @5,647,953tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl
e=0x882ab168, id=41216, params=0x88106cb4, status=0x88106cfc
[DSP] @5,648,057tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_enter(visa=0x882ab168): algHandle = 0x882ab
198
[DSP] @5,648,128tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h
andle=0x882ab198)
[DSP] @5,648,202tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> return
[DSP] @5,648,776tk: [+0 T:0x8892e644 S:0x88932504] OM - Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn
Bytes=1008)
[DSP] @5,648,876tk: [+0 T:0x8892e644 S:0x88932504] OM - Memory_cacheWbInv> return
[DSP] @5,648,930tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_exit(visa=0x882ab168): algHandle = 0x882ab1
98
[DSP] @5,649,005tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter
(handle=0x882ab198)
[DSP] @5,649,084tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur
n
[DSP] @5,649,150tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle
=0x882ab168, retVal=0x0)
[DSP] @5,649,235tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned from call(algHandle=0x882ab168, m
sg=0x88106c80); messageId=0x00020008
[DSP] @5,650,934tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @5,651,005tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@4,359,446us: [+0 T:0x00008003 S:0xbe3fe944] CE - Engine_fwriteTrace> returning count [1651]
@4,359,654us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call Completed: messageId=0x00020008, command=0x1
, return(status=0)
@4,359,857us: [+5 T:0x00008003 S:0xbe3fe9d4] CV - VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit
h messageId=0x00020008
@4,360,055us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620
58, retVal=0x0)
@4,360,248us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62
058, id=41217, params=0xbe3fec28, status=0xbe3fed28
@4,360,484us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg> Allocating message for messageId=0x0002
0009
@4,360,680us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
0020009, command=0x1
@4,360,873us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@4,361,117us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> return (0)
@4,361,309us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3fea24, timeout
=-1)
@4,366,972us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@4,367,246us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@4,787,772us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> return (0)
@4,788,103us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3fe9a0, timeout
=-1)
@4,788,354us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @5,672,464tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88
2ab168, msg=0x88106c80); messageId=0x00020009
[DSP] @5,672,568tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl
e=0x882ab168, id=41217, params=0x88106cb4, status=0x88106db0
[DSP] @5,672,674tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_enter(visa=0x882ab168): algHandle = 0x882ab
198
[DSP] @5,672,747tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h
andle=0x882ab198)
[DSP] @5,672,827tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> return
[DSP] @5,685,069tk: [+0 T:0x8892e644 S:0x88932494] OM - Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn
Bytes=1008)
[DSP] @5,685,193tk: [+0 T:0x8892e644 S:0x88932494] OM - Memory_cacheWbInv> return
[DSP] @5,685,259tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_exit(visa=0x882ab168): algHandle = 0x882ab1
98
[DSP] @5,685,335tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter
(handle=0x882ab198)
[DSP] @5,685,417tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur
n
[DSP] @5,685,488tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle
=0x882ab168, retVal=0x0)
[DSP] @5,685,621tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned from call(algHandle=0x882ab168, m
sg=0x88106c80); messageId=0x00020009
[DSP] @6,662,444tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @6,662,522tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@4,795,428us: [+0 T:0x00008003 S:0xbe3fe944] CE - Engine_fwriteTrace> returning count [1651]
@4,795,640us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call Completed: messageId=0x00020009, command=0x1
, return(status=0)
@4,795,851us: [+5 T:0x00008003 S:0xbe3fe9d4] CV - VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit
h messageId=0x00020009
@4,796,075us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620
58, retVal=0x0)
@4,796,289us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62
058, id=41218, params=0xbe3fec28, status=0xbe3feac0
@4,796,501us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg> Allocating message for messageId=0x0002
000a
@4,796,692us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
002000a, command=0x1
@4,796,891us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@4,797,345us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> return (0)
@4,797,723us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3fea24, timeout
=-1)
@4,798,173us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@4,798,433us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@4,798,694us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> return (0)
@4,799,015us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3fe9a0, timeout
=-1)
@4,799,256us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @6,684,637tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88
2ab168, msg=0x88106c80); messageId=0x0002000a
[DSP] @6,684,743tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl
e=0x882ab168, id=41218, params=0x88106cb4, status=0x88106db0
[DSP] @6,684,853tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_enter(visa=0x882ab168): algHandle = 0x882ab
198
[DSP] @6,684,927tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h
andle=0x882ab198)
[DSP] @6,685,011tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> return
[DSP] @6,685,660tk: [+0 T:0x8892e644 S:0x88932504] OM - Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn
Bytes=1008)
[DSP] @6,685,789tk: [+0 T:0x8892e644 S:0x88932504] OM - Memory_cacheWbInv> return
[DSP] @6,685,848tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_exit(visa=0x882ab168): algHandle = 0x882ab1
98
[DSP] @6,685,921tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter
(handle=0x882ab198)
[DSP] @6,686,001tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur
n
[DSP] @6,686,067tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle
=0x882ab168, retVal=0x0)
[DSP] @6,686,152tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned from call(algHandle=0x882ab168, m
sg=0x88106c80); messageId=0x0002000a
[DSP] @6,687,790tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @6,687,860tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@5,146,922us: [+0 T:0x00008003 S:0xbe3fe944] CE - Engine_fwriteTrace> returning count [1651]
@5,147,356us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call Completed: messageId=0x0002000a, command=0x1
, return(status=0)
@5,147,728us: [+5 T:0x00008003 S:0xbe3fe9d4] CV - VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit
h messageId=0x0002000a
@5,147,971us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620
58, retVal=0x0)
@5,174,837us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC - VIDENC_process> Enter (handle=0x62
058, inBufs=0xbe3ffac0, outBufs=0xbe3ffab0, inArgs=0xbe3ff8fc, outArgs=0xbe3ffa10)
@5,175,123us: [+5 T:0x00008003 S:0xbe3ff7fc] CV - VISA_allocMsg> Allocating message for messageId=0x0002
000b
@5,175,328us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x404c
9000, size=884736)
@5,175,514us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x404c9000,
 size=884736)
@5,175,692us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> found in cb(Sc=0x404c9000,
 Ec=0x405a1000, Ss=0x404c9000, Es=0x405a1000, PSc=0x8cac7000)
@5,175,934us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> returning physAddr=0x8cac7
000
@5,176,105us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> return (0x8cac7000)
@5,176,280us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4145
8000, size=32)
@5,176,450us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x41458000,
 size=32)
@5,176,621us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> found in cb(Sc=0x41458000,
 Ec=0x41458020, Ss=0x41458000, Es=0x41458020, PSc=0x8c9ad000)
@5,176,811us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> returning physAddr=0x8c9ad
000
@5,176,980us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> return (0x8c9ad000)
@5,177,150us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x407c
9000, size=884736)
@5,177,369us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x407c9000,
 size=884736)
@5,177,545us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> found in cb(Sc=0x407c9000,
 Ec=0x408a1000, Ss=0x407c9000, Es=0x408a1000, PSc=0x8fc94000)
@5,177,918us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> returning physAddr=0x8fc94
000
@5,178,105us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> return (0x8fc94000)
@5,178,281us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4144
b000, size=28)
@5,178,460us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x4144b000,
 size=28)
@5,178,664us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> found in cb(Sc=0x4144b000,
 Ec=0x4144b01c, Ss=0x4144b000, Es=0x4144b01c, PSc=0x8c9ba000)
@5,520,076us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> returning physAddr=0x8c9ba
000
@5,520,313us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> return (0x8c9ba000)
@5,520,501us: [+0 T:0x00008003 S:0xbe3ff80c] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
002000b, command=0x0
@5,520,695us: [+0 T:0x00008003 S:0xbe3ff7dc] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@5,520,929us: [+0 T:0x00008003 S:0xbe3ff7dc] OC - Comm_put> return (0)
@5,521,114us: [+0 T:0x00008003 S:0xbe3ff7d4] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3ff87c, timeout
=-1)


After this it locks up and never returns control to the ARM after the VIDENC_process() call.

It looks like its locking up inside the Codec Engine after returning from the DSP side process call.

Can anyone shed some light on whats going wrong?


Regards,
Etienne Eccles

VCA Technology

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100413/af9efce3/attachment-0001.html>

From suhas.jain at mavensystems.com  Tue Apr 13 12:59:52 2010
From: suhas.jain at mavensystems.com (Suhas Jain)
Date: Tue, 13 Apr 2010 23:29:52 +0530
Subject: UVC webcam problem
In-Reply-To: <46423D9081D5254CAFCEFF0CBC2CC9BA021C0454@jakarta.awox.com>
References: <hq19vt$paf$1@dough.gmane.org>	<s2hd9def9db1004130153pfb9b6f98v1ada2efffa2e233c@mail.gmail.com>	<4BC432FB.5000502@zydacron.com><FCCFB4CDC6E5564B9182F639FC3560870304B3DF40@dbde02.ent.ti.com>	<hq1mi6$6up$1@dough.gmane.org>	<46423D9081D5254CAFCEFF0CBC2CC9BA021C044F@jakarta.awox.com>	<4BC4636C.8090800@zydacron.com>
	<46423D9081D5254CAFCEFF0CBC2CC9BA021C0454@jakarta.awox.com>
Message-ID: <005d01cadb33$1e9840b0$5bc8c210$@jain@mavensystems.com>

Even I am facing a similar problem. I am using 2.6.32-rc2 kernel from Arago
project. I am using Libertas WIFI driver over SDIO interface. My device gets
associated to Access point but does not get an IP with DHCP. Rx. Packet
count increases but there are not packets being transmitted. 

I don't know if this is relevant to this discussion but still thought some
relevance to the problem Andreas is facing. 


-----Original Message-----
From:
davinci-linux-open-source-bounces+suhas.jain=mavensystems.com at linux.davincid
sp.com
[mailto:davinci-linux-open-source-bounces+suhas.jain=mavensystems.com at linux.
davincidsp.com] On Behalf Of Stephane Cerveau
Sent: 13 April 2010 18:09
To: Andreas Auer
Cc: davinci-linux-open-source at linux.davincidsp.com
Subject: RE: UVC webcam problem

What sort of wifi dongle are you using ?

-----Original Message-----
From: Andreas Auer [mailto:a.auer at zydacron.com] 
Sent: mardi 13 avril 2010 14:28
To: Stephane Cerveau
Cc: davinci-linux-open-source at linux.davincidsp.com
Subject: Re: UVC webcam problem

My problem is that the I can connect to an access point with WIFI but 
after requesting an IP address from the DHCP server I get disconnected.
I get also disconnected if I use a static IP and try to download a file 
or do something else. Afterwards, wpa_supplicant is not able to find an 
access point.

I get the message from syslog (logread):
"No probe response from AP 00:22:3f:7e:31:f2 after 500ms,
disconnecting."

Best regards,
Andreas

Stephane Cerveau schrieb:
> Hi,
> 
> I also encounter a WIFI USB issue. What sort of issue are you
> encountering ? 
> On my side, I download a large file from WIFI to a MSC device and
after
> a while, the MSC is disconnected... Indeed I encounter a STALL or a
> ERROR in either TXCSR or RXCSR...
> I'm still digging to understand what exactly happen.
> When I download from WIFI and put the result into /dev/null and read
the
> MSC in the mean while, I do not encounter any problem. It seems that
the
> problem comes from TX/RX multiplexing with different timing  or buffer
> size... 
> 
> 
> Best regards
> 
> Stephane
> 
> -----Original Message-----
> From: Andreas Auer [mailto:a.auer at zydacron.com] 
> Sent: mardi 13 avril 2010 14:02
> To: davinci-linux-open-source at linux.davincidsp.com
> Subject: Re: UVC webcam problem
> 
> Right now, I tried to use the USB driver (the musb folder) from the 
> arago kernel. With this driver I can capture the video from the
webcam. 
> So, something important must be different!
> 
> BUT, as I already mentioned I had a problem with "USB WLAN sticks"
when 
> I use the arago kernel. And this is also the case if I use the USB 
> driver from the arago 2.6.32 kernel with the khilman 2.6.34 kernel.
> 
> But I need to use USB WLAN devices together with USB webcams. Maybe 
> someone could help me to get this running!
> 
> One thing a forgot to mentionabout the used hardware is that I have a 
> USB hub IC (ISP1521) between my USB devices and the USB host interface

> of the Davinci processor. Maybe this hub chip makes also some
problems.
> 
> Thanks for your help so far,
> Andreas
> 
> PS: I also tried to adjust the FIFO buffers but this was not the
> solution.
> 
> PPS: Maye, I should write a new post for the WLAN problem!?
> 
> 
> Subbrathnam, Swaminathan schrieb:
>> Andreas,
>>
>> Pl. ensure that the FIFO is configured correctly.  Probably this
error
> could mean you need a 1024 byte fifo space and it is not available.
If
> so increase the fifo space in musb_core.c file.
>> Regards
>> Swami
>>
>>> -----Original Message-----
>>> From: davinci-linux-open-source-
>>> bounces+swami.iyer=ti.com at linux.davincidsp.com
> [mailto:davinci-linux-open-
>>> source-bounces+swami.iyer=ti.com at linux.davincidsp.com] On Behalf Of
>>> Andreas Auer
>>> Sent: Tuesday, April 13, 2010 2:32 PM
>>> To: Markus Rechberger
>>> Cc: davinci-linux-open-source at linux.davincidsp.com
>>> Subject: Re: UVC webcam problem
>>>
>>> Markus Rechberger schrieb:
>>>> On Tue, Apr 13, 2010 at 10:27 AM, Andreas Auer
<a.auer at zydacron.com>
>>> wrote:
>>>>> Hi,
>>>>>
>>>>> I'm trying to get a UVC webcam working with the latest khilman
> kernel
>>>>> (2.6.34) on a Davinci EVM like board with DM6446 processor.
>>>>>
>>>>> I'm able to request the buffers and queue them without errors. But
> if I
>>>>> switch on the streaming the UVC driver tells me:
>>>>>  "uvcvideo: USB isochronous frame lost (-18)."
>>>>>
>>>>> Some time ago, I tried the 2.6.32 kernel from the arago project
and
>>> webcam
>>>>> capturing was working out of the box but WLAN was not working.
(so,
> I
>>>>> switched to the khilman kernel).
>>>>>
>>>>> Maybe, someone can help me with the uvc webcam problem!!!
>>>>>
>>>> with our tests the DM6446 only supported up to around 4.5 mbyte of
>>>> isochronous data...
>>>> Raw Analog TV 720x576x25 requires around 170 mbit, I guess webcams
> are
>>>> near to that level there's no chance to get such a thing work.
>>>> Maybe MJPEG or MPEG based devices can work with it.
>>> Thanks for your reply. I have a Logitech QuickCam Communicate Deluxe
>>> with MJPEG format. And this webcam is working with the 2.6.32 kernel
>>> from the arago project. So, I think this cam should be working.
>>>
>>> Does anyone know what's the above "status code" -18 means??
>>>
>>> Thanks,
>>> Andreas
>>> _______________________________________________
>>> Davinci-linux-open-source mailing list
>>> Davinci-linux-open-source at linux.davincidsp.com
>>>
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>  
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 5024 (20100413) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
>  
>  
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 5024 (20100413) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
>  
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________


-- 
DI Andreas Auer
Embedded Software Developer
a.auer at zydacron.com

ZYDACRON Austria GmbH
St.-Peter-Guertel 4, 8042 Graz, AUSTRIA http://www.zydacron.com
_____________________________________________________________________
CEO: Mag. Georg Weber
Regional Court: Graz
Commercial Register: 286334f
This communication, including any attachments, may contain
confidential information of ZYDACRON, its subsidiaries or
representatives, and is intended solely for the use of the individual
or entity to which it is addressed. Any unauthorized review, use,
disclosure or distribution is prohibited.
If you believe this message was sent to you in error, please
immediately notify the sender by reply email and delete this message
without disclosing it. Thank you.
_____________________________________________________________________

 

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 5024 (20100413) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 
 

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 5024 (20100413) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


From ernie_zoe_bert at yahoo.com  Wed Apr 14 01:37:49 2010
From: ernie_zoe_bert at yahoo.com (Ernie Bert)
Date: Tue, 13 Apr 2010 23:37:49 -0700 (PDT)
Subject: SPI Support for DA850 (OMAPL-138).
In-Reply-To: <A117B9F753B6EB4580D381ED91D0FED0017D2E10@transmail01.transcrypt.local>
References: <p2p763e54b1004110755u701c9e5ek3c9cc29320c733c5@mail.gmail.com>
	<A117B9F753B6EB4580D381ED91D0FED0017D2E10@transmail01.transcrypt.local>
Message-ID: <119195.43947.qm@web113903.mail.gq1.yahoo.com>

Mike - I've applied Brian's patch to Kevin's tree (2.6.34-rc1 I think).
I attached the patch, in case you'll find it usefull. It also contains some code?I needed for testing on the DM355, you can ignore that.

Ernie.




________________________________
From: Brian Niebuhr <BNiebuhr at efjohnson.com>
To: Mike Williamson <michael.williamson at criticallink.com>; davinci-linux-open-source at linux.davincidsp.com
Sent: Mon, April 12, 2010 4:42:37 PM
Subject: RE: SPI Support for DA850 (OMAPL-138).

Mike - 

I do plan on resubmitting the driver as a replacement driver (remove the old and add the updated version) as suggested by TI.? I am just trying to get some other work finished up first.? If you want to try the version I submitted, the patch was actually against the arago kernel.? You can try patching that version and pulling it into your kernel to see if that fixes your issues. Hopefully I'll get around to resubmitting the driver for consideration some time this week.

Brian

> -----Original Message-----
> From: davinci-linux-open-source-bounces at linux.davincidsp.com 
> [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com
> ] On Behalf Of Mike Williamson
> Sent: Sunday, April 11, 2010 9:56 AM
> To: davinci-linux-open-source at linux.davincidsp.com
> Subject: SPI Support for DA850 (OMAPL-138).
> 
> Hi,
> 
> I've been working with Kevin's tree and have been having some problems
> with the SPI interface for the DA850 (OMAP-L138), SPI version 2.
> 
> I am getting a lot of failures in the davinci_spi_check_error routine
> that I'm not sure are real errors.? I was googling around and found
> this thread:
> 
> http://linux.omap.com/pipermail/davinci-linux-open-source/2009
> -July/015025.html
> 
> The thread raises the same issue that I have found in that the routine
> is declaring an error if the status of the SPI engine is claiming that
> the Tx buffer is empty (SPIFLG_TX_INTR_MASK) and there is also a check
> on a bit? (SPIFLG_BUF_INIT_ACTIVE_MASK, bit 24) that is undocumented
> in the SPI user guide.? I found that I had to turn off both of these
> checks in order for the SPI to work with our device in polled mode
> with no DMAs.? ? The device is an m25p64 EEPROM, same configuration as
> on the 850 / OMAPL138 evm.
> 
> Can anyone confirm if the spi implementation in Kevin's tree is
> working for VERSION_2 SPI devices (850 specifically), and what SPI
> configuration you're using?
> 
> I am also wondering if the SPI patches from Brian Niebuhr have died on
> the wire 
> (http://linux.davincidsp.com/pipermail/davinci-linux-open-sour
> ce/2010-March/018077.html).
>? It seemed like he had identified several issues with the driver and
> had taken a crack at sorting them out.
> 
> -Mike
> 
> 
> 
> 
> --
> Michael Williamson
> 315-425-4045x230
> www.criticallink.com
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 
> 

_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100413/21276b31/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spi_fixes_add_spi1.patch
Type: application/octet-stream
Size: 55381 bytes
Desc: not available
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100413/21276b31/attachment-0001.obj>

From Etienne.Eccles at vcatechnology.com  Wed Apr 14 03:59:20 2010
From: Etienne.Eccles at vcatechnology.com (Etienne Eccles)
Date: Wed, 14 Apr 2010 09:59:20 +0100
Subject: Codec engine lockup
In-Reply-To: <92CDD168D1E81F4F9D3839DC45903FC676C07D7E@dlee03.ent.ti.com>
References: <95FAFD227E8A2947BA96E1C807505D0412CD5F@sbs001.office.local>
	<92CDD168D1E81F4F9D3839DC45903FC676C07D7E@dlee03.ent.ti.com>
Message-ID: <95FAFD227E8A2947BA96E1C807505D0412CD67@sbs001.office.local>

Hi Chris

 

Thanks for the reply. 

I have actually done what you suggested, and I can see that the DSP side
process call completes successfully and returns. I have even gone so far
as to remove the entire body of DSP side process function and
immediately return with IALG_EOK.  That's why I suspected it must be
locking up in the codec engine after completing the DSP side process.

 

This lock up  problem is also not repeatable. It only occurs on about
20% of hardware examples and under certain booting conditions 

 

Etienne  

 

From: Ring, Chris [mailto:cring at ti.com] 
Sent: 13 April 2010 18:57
To: Etienne Eccles; davinci-linux-open-source at linux.davincidsp.com
Subject: RE: Codec engine lockup

 

The last line is an ARM-side Comm_get() call (implemented with
MSGQ_get()) - which blocks until the DSP finishes it's job and sends an
'I'm done' reply message.  Basically, you've sent a request to
VIDENC_process() a frame which never returns.  The DSP is
hanging/crashing/waiting and never returning "I'm done" to the ARM.

 

Can you connect to CCS and see what's happening on the DSP side?  Since
this is your codec, maybe set breakpoints in your process() method and
see if it ever gets called.

 

http://wiki.davincidsp.com/index.php/Debugging_the_DSP_side_of_a_CE_appl
ication_using_CCS

 

Chris

	 

	
________________________________


	From: davinci-linux-open-source-bounces at linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On
Behalf Of Etienne Eccles
	Sent: Tuesday, April 13, 2010 5:39 AM
	To: davinci-linux-open-source at linux.davincidsp.com
	Subject: Codec engine lockup

	 

	H

	 

	 

	I am getting the following debug output . using CE_DEBUG=3 when
creating and using a custom VIDENC codec:

	 

	 

	 

	root at nvc1346:/opt/davinci# CE_DEBUG=3 ./stabd -d -p a

	root at nvc1346:/opt/davinci# @0,196,096us: [+4 T:0x00004000
S:0xbec8cbbc] OG - Global_init> This program w

	as built with the following packages:

	@0,197,108us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
gnu.targets.rts470MV (/home/vcastab/svn/ud

	
p/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/gnu/targets/rts470MV
/) [1,0,0,0,1203621000516]

	@0,197,334us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
dsplink.gpp (/home/vcastab/svn/udp/linux/d

	
vsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/dsplink/gpp/
) [3,0,0]

	@0,197,516us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.xdais.dm (/home/vcastab/svn/udp/linux/d

	
vsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/dm/
) [1,0,4,1210262746529]

	@0,197,948us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.xdais (/home/vcastab/svn/udp/linux/dvsd

	
k/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/)
[1,2,1,1210262742149]

	@0,198,149us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.utils.trace (/home/vcastab/svn/udp/

	
linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sd
o/utils/trace/) [1,0,0,122094336

	6422]

	@0,198,331us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.utils.xdm (/home/vcastab/svn/udp

	
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ut
ils/xdm/) [1,0,1,1220951322616]

	@0,198,510us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.fc.dman3 (/home/vcastab/svn/udp/lin

	
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/f
c/dman3/) [1,0,3,1220943053023]

	@0,198,682us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.fc.acpy3 (/home/vcastab/svn/udp/lin

	
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/f
c/acpy3/) [1,0,2,1220943014135]

	@0,198,852us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.linuxutils.cmem (/home/vcastab/svn/

	
udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/t
i/sdo/linuxutils/cmem/) [2,0,1,1

	204929560755]

	@0,199,030us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.catalog.c470 (/home/vcastab/svn/udp/lin

	ux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/catalog/c470/)
[1,0,1,0,1203561761475]

	@0,199,200us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.platforms.evmDM6446 (/home/vcastab/svn/

	
udp/linux/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/platforms/evmD
M6446/) [1,0,0,1,1192229600615]

	@0,199,369us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.osal (/home/vcastab/svn/udp/linu

	
x/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/osal/)
[2,0,2,1220951127739]

	@0,199,539us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.ipc (/home/vcastab/svn/udp/linux

	
/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/)
[2,0,1,1220951085787]

	@0,199,704us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.alg (/home/vcastab/svn/udp/linux

	
/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/alg/)
[1,0,1,1220950781938]

	@0,199,875us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.osal.linux (/home/vcastab/svn/ud

	
p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/o
sal/linux/) [2,0,1,1220951140072

	]

	@0,200,049us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.ipc.dsplink (/home/vcastab/svn/u

	
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/
ipc/dsplink/) [2,0,1,12209510968

	18]

	@0,200,219us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce (/home/vcastab/svn/udp/linux/dvs

	dk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/)
[1,0,6,1220950771473]

	@0,200,386us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.video (/home/vcastab/svn/udp/lin

	
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/video/
) [1,0,3,1220951334122]

	@0,200,559us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
codecs.vca_stab (/home/vcastab/svn/vt/davi

	nci/trunk/ce1/codecs/vca_stab/) []

	@0,200,718us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.bioslog (/home/vcastab/svn/udp/l

	
inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/bios
log/) [1,0,1,1220950800329]

	@0,587,586us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.utils.trace (/home/vcastab/svn/u

	
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/
utils/trace/) [1,0,1,12209513170

	87]

	@0,587,929us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
apps.stab_client (/home/vcastab/svn/vt/dav

	inci/trunk/ce1/apps/stab_client/) []

	@0,588,146us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit>
enter (fxn=0x20028)

	@0,588,352us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit>
enter (fxn=0x1f4c0)

	@0,588,676us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
Enter(0x18)

	@0,589,026us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
return (0x5e138)

	@0,589,716us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit>
enter (fxn=0x1dda8)

	@0,590,050us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
Enter(0x18)

	@0,590,269us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
return (0x5e188)

	@0,590,492us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit>
enter (fxn=0x1b9f4)

	@0,590,839us: [+0 T:0x00004000 S:0xbec8cbbc] OG - Global_atexit>
enter (fxn=0x1eb44)

	@0,593,794us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem
- Sem_create> count: 0

	@0,594,023us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc>
Enter(0x14)

	@0,594,212us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc>
return (0x5e208)

	@0,594,470us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem
- Leaving Sem_create> sem[0x5e208]

	@0,594,698us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem
- Sem_create> count: 0

	@0,594,859us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc>
Enter(0x14)

	@0,595,056us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc>
return (0x5e220)

	@0,595,220us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem
- Leaving Sem_create> sem[0x5e220]

	@0,595,378us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc>
Enter(0x18)

	@0,595,544us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc>
return (0x5e238)

	@0,595,707us: [+0 T:0x00004000 S:0xbec8cb8c] OT - Thread_create>
Enter (fxn=0x1ab34, attrs=0x0)

	@0,595,869us: [+0 T:0x00004000 S:0xbec8cb74] OM - Memory_alloc>
Enter(0x64)

	@0,596,064us: [+0 T:0x00004000 S:0xbec8cb74] OM - Memory_alloc>
return (0x5e258)

	@0,598,964us: [+1 T:0x00004002 S:0xbe5ffa74] OP - daemon> thread
created.

	@0,599,205us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d>
Enter (proc=0xbe5ffaec)

	@0,599,387us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem
- Entered Sem_pend> sem[0x5e208] timeout

	[0xffffffff]

	@0,599,998us: [+0 T:0x00004000 S:0xbec8cb8c] OT - Thread_create>
Exit (task=0x5e258)

	@0,600,235us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit>
enter (fxn=0x1a6f4)

	@0,600,501us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit>
enter (fxn=0x1c7e8)

	@0,600,791us: [+0 T:0x00004000 S:0xbec8cbac] ti.sdo.ce.alg -
ALG_init> Enter

	@0,600,984us: [+0 T:0x00004000 S:0xbec8cb9c] OG - Global_atexit>
enter (fxn=0x209f0)

	@0,601,171us: [+0 T:0x00004000 S:0xbec8cbcc] ti.sdo.ce.alg -
ALG_init> Exit

	@0,601,339us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit>
enter (fxn=0x20490)

	@0,601,541us: [+0 T:0x00004000 S:0xbec8cb9c] OM - Memory_alloc>
Enter(0x18)

	@0,601,767us: [+0 T:0x00004000 S:0xbec8cb9c] OM - Memory_alloc>
return (0x60418)

	@0,601,955us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit>
enter (fxn=0x1eca8)

	@0,602,262us: [+6 T:0x00004000 S:0xbec8cbc4] CE - Engine_init>
CE debugging on (CE_DEBUG=3; allowed CE_D

	EBUG levels: 1=min, 2=good, 3=max)

	@0,602,481us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit>
enter (fxn=0x17734)

	@0,602,667us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
Enter(0x18)

	@0,602,852us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
return (0x60458)

	@0,603,024us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
Enter(0x18)

	@0,603,247us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
return (0x60478)

	@0,603,423us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
Enter(0x18)

	@0,603,600us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
return (0x60498)

	@0,944,735us: [+0 T:0x00004000 S:0xbec8cbc4] CS - Server_init()

	@0,944,957us: [+0 T:0x00004000 S:0xbec8cbc4] CS - Server_init>
Global_useLinkArbiter = 0

	@0,945,138us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit>
enter (fxn=0x16284)

	@0,945,529us: [+0 T:0x00004000 S:0xbec8cbd4] OG - Global_atexit>
enter (fxn=0x14148)

	@0,945,950us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> Enter(size=884736, align=-1, cache

	d=FALSE, heap=FALSE)

	@0,946,486us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_alloc(884736) = 0x403ee000.

	@0,946,744us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_getPhys(0x403ee000) = 0x8ff25

	000.

	@0,946,938us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> Enter(virtAddr=0x403ee000, size=

	884736, physAddr=0x8ff25000)

	@0,947,127us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> creating new contigBuf object

	@0,947,319us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

	@0,947,514us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
return (0x60518)

	@0,947,842us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> returning: cb->phys=0x8ff25000,

	cb->size=884736, cb->virt=0x403ee000

	@0,948,044us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> return (0x403ee000)

	@0,948,270us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> Enter(size=884736, align=-1, cache

	d=FALSE, heap=FALSE)

	@0,948,643us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_alloc(884736) = 0x404c9000.

	@0,948,931us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_getPhys(0x404c9000) = 0x8cac7

	000.

	@0,949,123us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> Enter(virtAddr=0x404c9000, size=

	884736, physAddr=0x8cac7000)

	@0,949,305us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> creating new contigBuf object

	@0,949,467us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

	@0,949,651us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
return (0x60530)

	@0,949,823us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> returning: cb->phys=0x8cac7000,

	cb->size=884736, cb->virt=0x404c9000

	@0,950,004us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> return (0x404c9000)

	@0,950,206us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> Enter(size=884736, align=-1, cache

	d=FALSE, heap=FALSE)

	@0,950,595us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_alloc(884736) = 0x405c9000.

	@0,950,841us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_getPhys(0x405c9000) = 0x8c9c7

	000.

	@0,951,032us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> Enter(virtAddr=0x405c9000, size=

	884736, physAddr=0x8c9c7000)

	@0,951,219us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> creating new contigBuf object

	@0,951,380us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

	@0,951,592us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
return (0x60548)

	@0,951,775us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> returning: cb->phys=0x8c9c7000,

	cb->size=884736, cb->virt=0x405c9000

	@0,951,959us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> return (0x405c9000)

	@0,952,125us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> Enter(size=884736, align=-1, cache

	d=FALSE, heap=FALSE)

	@0,952,475us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_alloc(884736) = 0x406c9000.

	@0,952,718us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_getPhys(0x406c9000) = 0x8c879

	000.

	@0,952,911us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> Enter(virtAddr=0x406c9000, size=

	884736, physAddr=0x8c879000)

	@0,953,145us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> creating new contigBuf object

	@0,953,310us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

	@0,953,490us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
return (0x60560)

	@1,294,466us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> returning: cb->phys=0x8c879000,

	cb->size=884736, cb->virt=0x406c9000

	@1,294,700us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> return (0x406c9000)

	@1,294,877us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> Enter(size=884736, align=-1, cache

	d=FALSE, heap=FALSE)

	@1,295,385us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_alloc(884736) = 0x407c9000.

	@1,295,626us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_getPhys(0x407c9000) = 0x8fc94

	000.

	@1,295,850us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> Enter(virtAddr=0x407c9000, size=

	884736, physAddr=0x8fc94000)

	@1,296,040us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> creating new contigBuf object

	@1,296,206us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

	@1,296,387us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
return (0x60578)

	@1,296,557us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> returning: cb->phys=0x8fc94000,

	cb->size=884736, cb->virt=0x407c9000

	@1,296,739us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> return (0x407c9000)

	@1,296,908us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> Enter(size=884736, align=-1, cache

	d=FALSE, heap=FALSE)

	@1,297,589us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_alloc(884736) = 0x40a5a000.

	@1,298,146us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_getPhys(0x40a5a000) = 0x8f8de

	000.

	@1,298,345us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> Enter(virtAddr=0x40a5a000, size=

	884736, physAddr=0x8f8de000)

	@1,298,538us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> creating new contigBuf object

	@1,298,750us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

	@1,298,934us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
return (0x60590)

	@1,299,106us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> returning: cb->phys=0x8f8de000,

	cb->size=884736, cb->virt=0x40a5a000

	@1,299,290us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> return (0x40a5a000)

	@1,309,917us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - Engine_open>
Enter('vca_engine', 0x0, 0xbe3ffa84)

	@1,310,205us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc>
Enter(0x2c)

	@1,310,419us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc>
return (0x605a8)

	@1,310,604us: [+0 T:0x00008003 S:0xbe3ff9e4] CE -
rserverOpen('./server_release.x64P'), count = 0

	@1,310,785us: [+0 T:0x00008003 S:0xbe3ff9ac] OP -
Processor_create> Enter(imageName='./server_release.x6

	4P', linkCfg='(null)', attrs=0xbe3ffa30)

	@1,312,833us: [+0 T:0x00008003 S:0xbe3ff994] OM - Memory_alloc>
Enter(0x24)

	@1,313,100us: [+0 T:0x00008003 S:0xbe3ff994] OM - Memory_alloc>
return (0x605d8)

	@1,313,292us: [+0 T:0x00008003 S:0xbe3ff98c] OP - doCmd> Enter
(cmdId=1, proc=0x605d8)

	@1,313,470us: [+0 T:0x00008003 S:0xbe3ff97c] ti.sdo.ce.osal.Sem
- Entered Sem_post> sem[0x5e208]

	@1,313,801us: [+0 T:0x00008003 S:0xbe3ff98c] ti.sdo.ce.osal.Sem
- Leaving Sem_post> sem[0x5e208]

	@1,314,019us: [+0 T:0x00008003 S:0xbe3ff96c] ti.sdo.ce.osal.Sem
- Entered Sem_pend> sem[0x5e220] timeout

	[0xffffffff]

	@1,314,506us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem
- Leaving Sem_pend> sem[0x5e208] status[

	0]

	@1,314,978us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d> Exit
(result=1)

	@1,315,460us: [+0 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Enter(proc=0x605d8)

	@1,315,900us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Initializing DSP PROC...

	@1,316,335us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Using DspLink config data for entr

	y #0 [server './server_release.x64P']

	@1,316,786us: [+0 T:0x00004002 S:0xbe5ffa5c] OM - Memory_alloc>
Enter(0xe0)

	@1,317,458us: [+0 T:0x00004002 S:0xbe5ffa5c] OM - Memory_alloc>
return (0x60600)

	@1,318,325us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Adding DSP segment #0 to Link conf

	iguration: name='DDR', startAddress=0x88200000,
sizeInBytes=0x400000, shared=1

	@1,660,152us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Adding DSP segment #1 to Link conf

	iguration: name='DSPLINKMEM', startAddress=0x88100000,
sizeInBytes=0x100000, shared=1

	@1,660,412us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Adding DSP segment #2 to Link conf

	iguration: name='RESET_VECTOR', startAddress=0x88000000,
sizeInBytes=0x80, shared=0

	@1,660,650us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Adding DSP segment #3 to Link conf

	iguration: name='DDRALGHEAP', startAddress=0x88800000,
sizeInBytes=0x1c00000, shared=0

	@1,660,856us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> DOPOWERCONTROL was=0; now=0

	SET WIDTH to 720 HEIGHT to 576

	@1,685,617us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Attaching to DSP PROC...

	@1,698,711us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Opening MSGQ pool...

	@1,699,722us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Loading ./server_release.x64P on D

	SP (1 args)...

	@1,892,865us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Starting DSP PROC...

	@1,916,709us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Opening remote transport...

	@1,917,511us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> return (1)

	@1,918,475us: [+0 T:0x00004002 S:0xbe5ffa64] ti.sdo.ce.osal.Sem
- Entered Sem_post> sem[0x5e220]

	@1,918,948us: [+0 T:0x00008003 S:0xbe3ff96c] ti.sdo.ce.osal.Sem
- Leaving Sem_pend> sem[0x5e220] status[

	0]

	@1,919,260us: [+0 T:0x00008003 S:0xbe3ff98c] OP - doCmd> Exit
(result=1)

	@1,919,438us: [+0 T:0x00008003 S:0xbe3ff9ac] OP -
Processor_create> return (0x605d8)

	@1,919,611us: [+0 T:0x00008003 S:0xbe3ff9e4] CE -
rserverOpen('./server_release.x64P'): 0x5701c done.

	@1,919,799us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc>
Enter(0x1e)

	@1,919,990us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc>
return (0x61fd0)

	@1,920,188us: [+0 T:0x00008003 S:0xbe3ff9bc] OC - Comm_create>
Enter(queueName='vca_engine_0', queue=0x6

	05b8, attrs=0x0)

	@1,920,370us: [+0 T:0x00008003 S:0xbe3ff9a4] OM - Memory_alloc>
Enter(0x4)

	@1,920,579us: [+0 T:0x00008003 S:0xbe3ff9a4] OM - Memory_alloc>
return (0x61ff8)

	@1,921,144us: [+0 T:0x00008003 S:0xbe3ff9bc] OC - Comm_create>
return (0x61ff8)

	@1,921,384us: [+0 T:0x00008003 S:0xbe3ff9bc] OM - Memory_free>
Enter(0x61fd0, 0x1e)

	@1,921,582us: [+0 T:0x00008003 S:0xbe3ff9bc] OM - Memory_free>
return (0x1)

	@1,921,758us: [+0 T:0x00008003 S:0xbe3ff9c4] OC - Comm_alloc>
Enter(poolId=0x0, msg=0x605c4, size=576)

	@1,921,990us: [+0 T:0x00008003 S:0xbe3ff9c4] OC - Comm_alloc>
msg=0x413dbc80, returning (0)

	@1,922,187us: [+0 T:0x00008003 S:0xbe3ff9a4] OC - Comm_locate>
Enter(queueName='rmsq', queue=0x605b4)

	@1,931,192us: [+0 T:0x00008003 S:0xbe3ff9a4] OC - Comm_locate>
return (0)

	@1,931,465us: [+0 T:0x00008003 S:0xbe3ff9e4] CE -
checkServer(0x605a8)

	@1,931,739us: [+0 T:0x00008003 S:0xbe3ff9b4] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

	@1,932,050us: [+0 T:0x00008003 S:0xbe3ff9b4] OC - Comm_put>
return (0)

	@1,932,339us: [+0 T:0x00008003 S:0xbe3ff9ac] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ffa28, timeout

	=-1)

	@1,932,567us: [+0 T:0x00008003 S:0xbe3ff9ac] OC - Comm_get>
MSGQ_Get() status=0x8000, return (0)

	@1,932,768us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - rmsInit> RMS
initialized(0x605a8); CE_DEBUG on, settin

	g DSP trace mask to *+01234567,GT_prefix=12345,GT_time=3

	@1,932,966us: [+0 T:0x00008003 S:0xbe3ff9b4] CE -
Engine_setTrace> Enter(engine=0x605a8, mask='*+0123456

	7,GT_prefix=12345,GT_time=3')

	@1,933,180us: [+1 T:0x00008003 S:0xbe3ff9b4] CE -
Engine_setTrace> Requesting DSP set trace ...

	@1,933,348us: [+0 T:0x00008003 S:0xbe3ff984] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

	@1,933,635us: [+0 T:0x00008003 S:0xbe3ff984] OC - Comm_put>
return (0)

	@1,933,821us: [+0 T:0x00008003 S:0xbe3ff97c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff9ec, timeout

	=-1)

	@1,934,437us: [+0 T:0x00004002 S:0xbe5ffa74] ti.sdo.ce.osal.Sem
- Leaving Sem_post> sem[0x5e220]

	@1,934,692us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d>
Enter (proc=0xbe5ffaec)

	@1,934,920us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem
- Entered Sem_pend> sem[0x5e208] timeout

	[0xffffffff]

	@1,937,498us: [+0 T:0x00008003 S:0xbe3ff97c] OC - Comm_get>
MSGQ_Get() status=0x8000, return (0)

	@1,937,904us: [+0 T:0x00008003 S:0xbe3ff9b4] CE -
Engine_setTrace> return(0)

	@1,938,126us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

	@1,938,384us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put>
return (0)

	@1,938,673us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff9d0, timeout

	=-1)

	@1,938,903us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get>
MSGQ_Get() status=0x8000, return (0)

	[DSP] @0x00000208:[T:0x00000000] ZZ - main> Welcome to loopback
server's main().

	[DSP] @0x0000086c:[T:0x8880415c] LS - server()

	[DSP] @0x0000088d:[T:0x8880415c] OM - Memory_alloc>
Enter(size=0x24)

	[DSP] @0x000008b8:[T:0x8880415c] OM - Memory_alloc> return
(0x882ab060)

	[DSP] @0x000008e6:[T:0x8880415c] LS - server: serverMsgQueue =
0x00000001

	[DSP] @0x0000090f:[T:0x8880415c] LS - server: waiting for cmd

	[DSP] @0x00008cc2:[T:0x8880006c] CR - processRmsCmd(0x88105ca8,
4056): cmd = 6

	[DSP] @0x00009b1c:[T:0x8880006c] CR - processRmsCmd(0x88105ca8,
4056): cmd = 8

	[DSP] @0x00009b50:[T:0x8880006c] CR - setting trace mask to
*+01234567,GT_prefix=12345,GT_time=3

	[DSP] @0,039,852tk: [+0 T:0x8880006c S:0x88803fdc] OG -
Global_setSpecialTrace> enter(mask='*+01234567,G

	T_prefix=12345,GT_time=3')

	[DSP] @0,039,938tk: [+4 T:0x8880006c S:0x88803fdc] OG -
Global_setSpecialTrace> This program was built w

	ith the following packages:

	[DSP] @0,040,015tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.targets.rts6000 (/home/vcastab/sv

	
n/udp/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/targets/rts60
00/) [1,0,0,0,1203621186754]

	[DSP] @0,040,139tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.fc.dman3 (/home/vcastab/svn/u

	
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti
/sdo/fc/dman3/) [1,0,3,122094305

	3023]

	[DSP] @0,040,255tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.rtdx (/home/vcastab/svn/udp/linux

	/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/rtdx/)
[2,0,0,1,1194024051755]

	[DSP] @0,040,356tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.psl (/home/vcastab/svn/udp/linux/

	dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/psl/)
[5,0,0,0,0]

	[DSP] @0,040,451tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.bios (/home/vcastab/svn/udp/linux

	/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/bios/)
[5,2,4,9,1193960176642]

	[DSP] @0,040,552tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.fc.dskt2 (/home/vcastab/svn/u

	
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti
/sdo/fc/dskt2/) [1,0,4,122094309

	5081]

	[DSP] @0,040,668tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.xdais.dm (/home/vcastab/svn/udp/l

	
inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xda
is/dm/) [1,0,4,1210262746529]

	[DSP] @0,040,781tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.xdais (/home/vcastab/svn/udp/linu

	
x/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/
) [1,2,1,1210262742149]

	[DSP] @0,040,890tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.node (/home/vcastab/svn/ud

	
p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/n
ode/) [1,0,0,1220951122176]

	[DSP] @0,041,001tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.ipc.dsplink.dsp (/home/vca

	
stab/svn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/
ti/sdo/ce/ipc/dsplink/dsp/) [2,0

	,1,1220951102696]

	[DSP] @0,041,122tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.utils.trace (/home/vcastab/sv

	
n/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages
/ti/sdo/utils/trace/) [1,0,0,122

	0943366422]

	[DSP] @0,041,242tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.utils.xdm (/home/vcastab/s

	
vn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo
/ce/utils/xdm/) [1,0,1,122095132

	2616]

	[DSP] @0,041,357tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.fc.acpy3 (/home/vcastab/svn/u

	
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti
/sdo/fc/acpy3/) [1,0,2,122094301

	4135]

	[DSP] @0,041,473tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package dsplink.dsp (/home/vcastab/svn/udp/l

	
inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/dsplin
k/dsp/) [1,3,0]

	[DSP] @0,041,578tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.bios.utils (/home/vcastab/svn/udp

	
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/b
ios/utils/) [2,0,1,0,11918918306

	09]

	[DSP] @0,041,693tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.catalog.c6000 (/home/vcastab/svn/

	
udp/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/catalog/c6000/)
[1,0,0,0,1203561781695]

	[DSP] @0,041,802t at 2,297,823us: [+0 T:0x00008003 S:0xbe3ff944] OC
- Comm_put> Enter(queue=0x0, msg=0x413d

	bc80)

	@2,298,120us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put>
return (0)

	@2,298,417us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff9d0, timeout

	=-1)

	@2,298,649us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get>
MSGQ_Get() status=0x8000, return (0)

	k: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.platforms.evmDM6446 (/home/vcastab/svn/udp/linux/d

	
vsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/platforms/evmDM6446/)
[1,0,0,1,1192229600615]

	[DSP] @0,041,919tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.osal (/home/vcastab/svn/ud

	
p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/o
sal/) [2,0,2,1220951127739]

	[DSP] @0,042,030tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.ipc (/home/vcastab/svn/udp

	
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ip
c/) [2,0,1,1220951085787]

	[DSP] @0,042,139tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.alg (/home/vcastab/svn/udp

	
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/al
g/) [1,0,1,1220950781938]

	[DSP] @0,042,249tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.osal.bios (/home/vcastab/s

	
vn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo
/ce/osal/bios/) [2,0,1,122095113

	3740]

	[DSP] @0,042,365tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.ipc.bios (/home/vcastab/sv

	
n/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/
ce/ipc/bios/) [2,0,1,12209510910

	97]

	[DSP] @0,042,487tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce (/home/vcastab/svn/udp/lin

	
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/)
[1,0,6,1220950771473]

	[DSP] @0,042,593tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.bioslog (/home/vcastab/svn

	
/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/c
e/bioslog/) [1,0,1,1220950800329

	]

	[DSP] @0,042,706tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.video (/home/vcastab/svn/u

	
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/
video/) [1,0,3,1220951334122]

	[DSP] @0,042,818tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package codecs.vca_stab (/home/vcastab/svn/v

	t/davinci/trunk/ce1/codecs/vca_stab/) []

	[DSP] @0,042,901tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package servers.vca_stab_server (/home/vcast

	ab/svn/vt/davinci/trunk/ce1/servers/vca_stab_server/) []

	[DSP] @0,042,992tk: [+0 T:0x8880006c S:0x88803fdc] OG -
Global_setSpecialTrace> return

	[DSP] @0,050,728tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

	[DSP] @0,050,799tk: [+0 T:0x8880006c S:0x88804024] CR - remote
time = 0x0, trace buffer size = 4032

	[DSP] @0,885,481tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

	[DSP] @0,885,547tk: [+0 T:0x8880006c S:0x88804024] CR - remote
time = 0x0, trace buffer size = 4032

	@2,650,231us: [+0 T:0x00008003 S:0xbe3ff974] CE -
Engine_fwriteTrace> returning count [6828]

	@2,650,445us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - Engine_open>
return(394664)

	@2,650,660us: [+0 T:0x00008003 S:0xbe3ffa34]
ti.sdo.ce.video.VIDENC - VIDENC_create> Enter (engine=0x605

	a8, name='vca_stab', params=0xbe3ffa88)

	@2,650,896us: [+0 T:0x00008003 S:0xbe3ffa04] CV -
VISA_create(0x605a8, 'vca_stab', 0xbe3ffa88, 0x828, 't

	i.sdo.ce.video.IVIDENC')

	@2,651,104us: [+0 T:0x00008003 S:0xbe3ff92c] CV -
VISA_create2(0x605a8, 'vca_stab', 0xbe3ffa88, 0x2c, 0x

	828, 'ti.sdo.ce.video.IVIDENC')

	@2,651,363us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc>
Enter(0x30)

	@2,651,589us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc>
return (0x62058)

	@2,651,782us: [+0 T:0x00008003 S:0xbe3ff8bc] CE -
Engine_createNode(0x605a8, 'vca_stab', 828, 0xbe3ffa88

	, 0x2c, 0xbe3ffa30)

	@2,651,980us: [+0 T:0x00008003 S:0xbe3ff8a4] OM - Memory_alloc>
Enter(0x20)

	@2,652,163us: [+0 T:0x00008003 S:0xbe3ff8a4] OM - Memory_alloc>
return (0x61fd0)

	@2,652,361us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_create>
Enter(queueName='gppfromnode_1', queue=0x

	61fd8, attrs=0x0)

	@2,652,545us: [+0 T:0x00008003 S:0xbe3ff87c] OM - Memory_alloc>
Enter(0x4)

	@2,652,730us: [+0 T:0x00008003 S:0xbe3ff87c] OM - Memory_alloc>
return (0x62090)

	@2,993,385us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_create>
return (0x62090)

	@2,993,649us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

	@2,993,987us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put>
return (0)

	@2,994,199us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff914, timeout

	=-1)

	@3,010,127us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get>
MSGQ_Get() status=0x8000, return (0)

	@3,010,439us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

	@3,010,710us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put>
return (0)

	@3,010,993us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff914, timeout

	=-1)

	@3,011,253us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get>
MSGQ_Get() status=0x8000, return (0)

	@3,011,492us: [+4 T:0x00008003 S:0xbe3ff8bc] CE -
Engine_createNode> created node(stdIn=0x2, stdOut=0x10

	001, msgq=0x62090, algName='vca_stab', rmsNode=0x882ab088,
algHandle=0x882ab168)

	@3,011,735us: [+0 T:0x00008003 S:0xbe3ff81c] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

	@3,011,981us: [+0 T:0x00008003 S:0xbe3ff81c] OC - Comm_put>
return (0)

	@3,012,254us: [+0 T:0x00008003 S:0xbe3ff814] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff8a8, timeout

	=-1)

	@3,012,488us: [+0 T:0x00008003 S:0xbe3ff814] OC - Comm_get>
MSGQ_Get() status=0x8000, return (0)

	[DSP] @2,500,228tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 0

	[DSP] @2,500,305tk: [+0 T:0x8880006c S:0x88803f14] OM -
Memory_alloc> Enter(size=0x18)

	[DSP] @2,500,365tk: [+0 T:0x8880006c S:0x88803f14] OM -
Memory_alloc> return (0x882ab088)

	[DSP] @2,500,425tk: [+0 T:0x8880006c S:0x88803f14] OM -
Memory_alloc> Enter(size=0xb)

	[DSP] @2,500,480tk: [+0 T:0x8880006c S:0x88803f14] OM -
Memory_alloc> return (0x882ab0a0)

	[DSP] @2,500,549tk: [+0 T:0x8880006c S:0x88803edc] OM -
Memory_alloc> Enter(size=0x20)

	[DSP] @2,500,605tk: [+0 T:0x8880006c S:0x88803edc] OM -
Memory_alloc> return (0x882ab0b0)

	[DSP] @2,500,665tk: [+0 T:0x8880006c S:0x88803eac] OM -
Memory_alloc> Enter(size=0x24)

	[DSP] @2,500,722tk: [+0 T:0x8880006c S:0x88803eac] OM -
Memory_alloc> return (0x882ab0d0)

	[DSP] @2,500,806tk: [+0 T:0x8880006c S:0x88803ec4]
ti.sdo.ce.video.VIDENC - VIDENC_create> Enter (engine

	=0x0, name='vca_stab', params=0x88105cc0)

	[DSP] @2,500,902tk: [+0 T:0x8880006c S:0x88803e8c] CV -
VISA_create(0x0, 'vca_stab', 0x88105cc0, 0x828,

	'ti.sdo.ce.video.IVIDENC')

	[DSP] @2,500,988tk: [+0 T:0x8880006c S:0x88803d7c] CV -
VISA_create2(0x0, 'vca_stab', 0x88105cc0, 0x2c,

	0x828, 'ti.sdo.ce.video.IVIDENC')

	[DSP] @2,501,089tk: [+0 T:0x8880006c S:0x88803d14] CE -
Engine_open> Enter('local', 0x88803d6c, 0x33c)

	[DSP] @2,501,158tk: [+0 T:0x8880006c S:0x88803cf4] OM -
Memory_alloc> Enter(size=0x2c)

	[DSP] @2,501,216tk: [+0 T:0x8880006c S:0x88803cf4] OM -
Memory_alloc> return (0x882ab138)

	[DSP] @2,501,287tk: [+0 T:0x8880006c S:0x88803d14] CE -
Engine_open> return(-2010468040)

	[DSP] @2,501,362tk: [+0 T:0x8880006c S:0x88803d5c] OM -
Memory_alloc> Enter(size=0x30)

	[DSP] @2,501,418tk: [+0 T:0x8880006c S:0x88803d5c] OM -
Memory_alloc> return (0x882ab168)

	[DSP] @2,501,484tk: [+0 T:0x8880006c S:0x88803d34]
ti.sdo.ce.alg.Algorithm - Algorithm_create> Enter(fxn

	s=0x88266574, idma3Fxns=0x882665a0, params=0x88105cc0,
attrs=0x88803e80)

	[DSP] @2,501,595tk: [+0 T:0x8880006c S:0x88803d14] OM -
Memory_alloc> Enter(size=0x10)

	[DSP] @2,501,652tk: [+0 T:0x8880006c S:0x88803d14] OM -
Memory_alloc> return (0x882ab198)

	[DSP] @2,519,578tk: [+0 T:0x8880006c S:0x88803c34] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

	Bytes=1008)

	[DSP] @2,519,697tk: [+0 T:0x8880006c S:0x88803c34] OM -
Memory_cacheWbInv> return

	[DSP] @2,535,121tk: [+0 T:0x8880006c S:0x88803c0c] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

	Bytes=32)

	[DSP] @2,535,236tk: [+0 T:0x8880006c S:0x88803c0c] OM -
Memory_cacheWbInv> return

	[DSP] @2,535,480tk: [+0 T:0x8880006c S:0x88803bc4] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

	Bytes=32)

	[DSP] @2,535,566tk: [+0 T:0x8880006c S:0x88803bc4] OM -
Memory_cacheWbInv> return

	[DSP] @2,535,835tk: [+0 T:0x8880006c S:0x88803b9c] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

	Bytes=32)

	[DSP] @2,535,925tk: [+0 T:0x8880006c S:0x88803b9c] OM -
Memory_cacheWbInv> return

	[DSP] @2,536,688tk: [+0 T:0x8880006c S:0x88803cb4] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

	Bytes=1008)

	[DSP] @2,536,793tk: [+0 T:0x8880006c S:0x88803cb4] OM -
Memory_cacheWbInv> return

	[DSP] @2,536,915tk: [+0 T:0x8880006c S:0x88803d34]
ti.sdo.ce.alg.Algorithm - Algorithm_create> return (0

	x882ab198)

	[DSP] @2,536,997tk: [+0 T:0x8880006c S:0x88803ec4]
ti.sdo.ce.video.VIDENC - VIDENC_create> return (0x882

	ab168)

	[DSP] @2,537,080tk: [+4 T:0x8880006c S:0x88803e84] OT -
Thread_create > name: "vca_stab#0", pri:  -1, st

	ack size:  16384, stack seg: 0

	[DSP] @2,539,051tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 1

	[DSP] @2,541,980tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

	[DSP] @2,542,048tk: [+0 T:0x8880006c S:0x88804024] CR - remote
time = 0x0, trace buffer size = 4032

	@3,369,765us: [+0 T:0x00008003 S:0xbe3ff84c] CE -
Engine_fwriteTrace> returning count [3758]

	@3,369,981us: [+2 T:0x00008003 S:0xbe3ff8bc] CE -
Engine_createNode> Returning 0x61fd0

	@3,370,160us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc>
Enter(0x4)

	@3,370,349us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc>
return (0x620a0)

	@3,370,528us: [+0 T:0x00008003 S:0xbe3ff90c] OC - Comm_alloc>
Enter(poolId=0x0, msg=0x620a0, size=828)

	@3,370,760us: [+0 T:0x00008003 S:0xbe3ff90c] OC - Comm_alloc>
msg=0x413dcc80, returning (0)

	@3,370,981us: [+5 T:0x00008003 S:0xbe3ff92c] CV - VISA_create>
remote codec created (name='vca_stab', lo

	calQueueID=0x10001, remoteQueueID=0x0002)

	@3,371,235us: [+0 T:0x00008003 S:0xbe3ffa34]
ti.sdo.ce.video.VIDENC - VIDENC_create> return (0x62058)

	@3,374,722us: [+0 T:0x00008003 S:0xbe3ff874]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62

	058, id=257, params=0x5abe8, status=0xbe3ffa28

	@3,375,009us: [+5 T:0x00008003 S:0xbe3ff844] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

	0006

	@3,375,208us: [+0 T:0x00008003 S:0xbe3ff824] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

	0020006, command=0x1

	@3,375,431us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

	@3,375,692us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put>
return (0)

	@3,375,884us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3ff884, timeout

	=-1)

	@3,376,737us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get>
MSGQ_Get() status=0x8000, return (0)

	@3,377,056us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

	@3,377,322us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put>
return (0)

	@3,377,720us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff800, timeout

	=-1)

	@3,378,173us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get>
MSGQ_Get() status=0x8000, return (0)

	[DSP] @3,385,962tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
0x882ab0b0(vca_stab#0) call(algHandle=0x88

	2ab168, msg=0x88106c80); messageId=0x00020006

	[DSP] @3,386,079tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

	e=0x882ab168, id=257, params=0x88106cb4, status=0x88106d00

	[DSP] @3,386,192tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

	198

	[DSP] @3,386,267tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

	andle=0x882ab198)

	[DSP] @3,386,383tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

	[DSP] @3,386,881tk: [+0 T:0x8892e644 S:0x889324c4] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

	Bytes=32)

	[DSP] @3,386,997tk: [+0 T:0x8892e644 S:0x889324c4] OM -
Memory_cacheWbInv> return

	[DSP] @3,387,126tk: [+0 T:0x8892e644 S:0x889324b4] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

	Bytes=32)

	[DSP] @3,387,203tk: [+0 T:0x8892e644 S:0x889324b4] OM -
Memory_cacheWbInv> return

	[DSP] @3,387,442tk: [+0 T:0x8892e644 S:0x8893248c] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

	Bytes=32)

	[DSP] @3,387,538tk: [+0 T:0x8892e644 S:0x8893248c] OM -
Memory_cacheWbInv> return

	[DSP] @3,387,604tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

	98

	[DSP] @3,387,679tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

	(handle=0x882ab198)

	[DSP] @3,387,760tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

	n

	[DSP] @3,387,834tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

	=0x882ab168, retVal=0x0)

	[DSP] @3,387,919tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
returned from call(algHandle=0x882ab168, m

	sg=0x88106c80); messageId=0x00020006

	[DSP] @3,389,753tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

	[DSP] @3,389,829tk: [+0 T:0x8880006c S:0x88804024] CR - remote
time = 0x0, trace buffer size = 4032

	@3,727,875us: [+0 T:0x00008003 S:0xbe3ff7a4] CE -
Engine_fwriteTrace> returning count [2039]

	@3,728,094us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call
Completed: messageId=0x00020006, command=0x1

	, return(status=0)

	@3,728,332us: [+5 T:0x00008003 S:0xbe3ff834] CV -
VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit

	h messageId=0x00020006

	@3,728,530us: [+0 T:0x00008003 S:0xbe3ff874]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620

	58, retVal=0x0)

	@3,728,715us: [+0 T:0x00008003 S:0xbe3ff874]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62

	058, id=259, params=0x5abe8, status=0xbe3ff930

	@3,728,916us: [+5 T:0x00008003 S:0xbe3ff844] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

	0007

	@3,729,097us: [+0 T:0x00008003 S:0xbe3ff824] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

	0020007, command=0x1

	@3,729,285us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

	@3,729,551us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put>
return (0)

	@3,729,751us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3ff884, timeout

	=-1)

	@3,730,056us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get>
MSGQ_Get() status=0x8000, return (0)

	@3,730,282us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

	@3,730,528us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put>
return (0)

	@3,730,802us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff800, timeout

	=-1)

	@3,731,055us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get>
MSGQ_Get() status=0x8000, return (0)

	[DSP] @4,206,979tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
0x882ab0b0(vca_stab#0) call(algHandle=0x88

	2ab168, msg=0x88106c80); messageId=0x00020007

	[DSP] @4,207,083tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

	e=0x882ab168, id=259, params=0x88106cb4, status=0x88106d00

	[DSP] @4,207,189tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

	198

	[DSP] @4,207,262tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

	andle=0x882ab198)

	[DSP] @4,207,346tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

	[DSP] @4,207,420tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

	98

	[DSP] @4,207,494tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

	(handle=0x882ab198)

	[DSP] @4,207,571tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

	n

	[DSP] @4,207,636tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

	=0x882ab168, retVal=0x0)

	[DSP] @4,207,714tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
returned from call(algHandle=0x882ab168, m

	sg=0x88106c80); messageId=0x00020007

	[DSP] @4,209,298tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

	[DSP] @4,209,366tk: [+0 T:0x8880006c S:0x88804024] CR - remote
time = 0x0, trace buffer size = 4032

	@4,078,103us: [+0 T:0x00008003 S:0xbe3ff7a4] CE -
Engine_fwriteTrace> returning count [1451]

	@4,078,339us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call
Completed: messageId=0x00020007, command=0x1

	, return(status=0)

	@4,078,546us: [+5 T:0x00008003 S:0xbe3ff834] CV -
VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit

	h messageId=0x00020007

	@4,078,742us: [+0 T:0x00008003 S:0xbe3ff874]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620

	58, retVal=0x0)

	SVN Version: 3093:3110

	STAB Version: 01.06.08

	@4,079,044us: [+0 T:0x00008003 S:0xbe3ffa64] OM -
Memory_contigAlloc> Enter(size=28, align=-1, cached=FA

	LSE, heap=FALSE)

	@4,079,389us: [+4 T:0x00008003 S:0xbe3ffa64] OM -
Memory_contigAlloc> CMEM_alloc(28) = 0x4144b000.

	@4,079,680us: [+4 T:0x00008003 S:0xbe3ffa64] OM -
Memory_contigAlloc> CMEM_getPhys(0x4144b000) = 0x8c9ba

	000.

	@4,079,883us: [+1 T:0x00008003 S:0xbe3ffa0c] OM -
Memory__addContigBuf> Enter(virtAddr=0x4144b000, size=

	28, physAddr=0x8c9ba000)

	@4,080,074us: [+1 T:0x00008003 S:0xbe3ffa0c] OM -
Memory__addContigBuf> creating new contigBuf object

	@4,080,242us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc>
Enter(0x10)

	@4,080,453us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc>
return (0x60fb0)

	@4,080,628us: [+1 T:0x00008003 S:0xbe3ffa0c] OM -
Memory__addContigBuf> returning: cb->phys=0x8c9ba000,

	cb->size=28, cb->virt=0x4144b000

	@4,080,810us: [+0 T:0x00008003 S:0xbe3ffa64] OM -
Memory_contigAlloc> return (0x4144b000)

	@4,081,014us: [+0 T:0x00008003 S:0xbe3ffa64] OM -
Memory_contigAlloc> Enter(size=32, align=-1, cached=FA

	LSE, heap=FALSE)

	@4,081,323us: [+4 T:0x00008003 S:0xbe3ffa64] OM -
Memory_contigAlloc> CMEM_alloc(32) = 0x41458000.

	@4,081,570us: [+4 T:0x00008003 S:0xbe3ffa64] OM -
Memory_contigAlloc> CMEM_getPhys(0x41458000) = 0x8c9ad

	000.

	@4,081,763us: [+1 T:0x00008003 S:0xbe3ffa0c] OM -
Memory__addContigBuf> Enter(virtAddr=0x41458000, size=

	32, physAddr=0x8c9ad000)

	@4,081,953us: [+1 T:0x00008003 S:0xbe3ffa0c] OM -
Memory__addContigBuf> creating new contigBuf object

	@4,082,119us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc>
Enter(0x10)

	@4,082,348us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc>
return (0x620b0)

	@4,082,535us: [+1 T:0x00008003 S:0xbe3ffa0c] OM -
Memory__addContigBuf> returning: cb->phys=0x8c9ad000,

	cb->size=32, cb->virt=0x41458000

	@4,082,729us: [+0 T:0x00008003 S:0xbe3ffa64] OM -
Memory_contigAlloc> return (0x41458000)

	MAC: 00:13:23:04:13:46 USN: 970041346

	@4,349,545us: [+0 T:0x00008003 S:0xbe3fea14]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62

	058, id=41216, params=0xbe3fedb8, status=0xbe3fed28

	@4,349,833us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

	0008

	@4,350,045us: [+0 T:0x00008003 S:0xbe3fe9c4] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

	0020008, command=0x1

	@4,350,250us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

	@4,350,512us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put>
return (0)

	@4,350,710us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3fea24, timeout

	=-1)

	@4,351,302us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get>
MSGQ_Get() status=0x8000, return (0)

	@4,351,574us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

	@4,351,839us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put>
return (0)

	@4,352,129us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3fe9a0, timeout

	=-1)

	@4,352,373us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get>
MSGQ_Get() status=0x8000, return (0)

	[DSP] @5,647,854tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
0x882ab0b0(vca_stab#0) call(algHandle=0x88

	2ab168, msg=0x88106c80); messageId=0x00020008

	[DSP] @5,647,953tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

	e=0x882ab168, id=41216, params=0x88106cb4, status=0x88106cfc

	[DSP] @5,648,057tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

	198

	[DSP] @5,648,128tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

	andle=0x882ab198)

	[DSP] @5,648,202tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

	[DSP] @5,648,776tk: [+0 T:0x8892e644 S:0x88932504] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

	Bytes=1008)

	[DSP] @5,648,876tk: [+0 T:0x8892e644 S:0x88932504] OM -
Memory_cacheWbInv> return

	[DSP] @5,648,930tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

	98

	[DSP] @5,649,005tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

	(handle=0x882ab198)

	[DSP] @5,649,084tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

	n

	[DSP] @5,649,150tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

	=0x882ab168, retVal=0x0)

	[DSP] @5,649,235tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
returned from call(algHandle=0x882ab168, m

	sg=0x88106c80); messageId=0x00020008

	[DSP] @5,650,934tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

	[DSP] @5,651,005tk: [+0 T:0x8880006c S:0x88804024] CR - remote
time = 0x0, trace buffer size = 4032

	@4,359,446us: [+0 T:0x00008003 S:0xbe3fe944] CE -
Engine_fwriteTrace> returning count [1651]

	@4,359,654us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call
Completed: messageId=0x00020008, command=0x1

	, return(status=0)

	@4,359,857us: [+5 T:0x00008003 S:0xbe3fe9d4] CV -
VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit

	h messageId=0x00020008

	@4,360,055us: [+0 T:0x00008003 S:0xbe3fea14]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620

	58, retVal=0x0)

	@4,360,248us: [+0 T:0x00008003 S:0xbe3fea14]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62

	058, id=41217, params=0xbe3fec28, status=0xbe3fed28

	@4,360,484us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

	0009

	@4,360,680us: [+0 T:0x00008003 S:0xbe3fe9c4] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

	0020009, command=0x1

	@4,360,873us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

	@4,361,117us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put>
return (0)

	@4,361,309us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3fea24, timeout

	=-1)

	@4,366,972us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get>
MSGQ_Get() status=0x8000, return (0)

	@4,367,246us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

	@4,787,772us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put>
return (0)

	@4,788,103us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3fe9a0, timeout

	=-1)

	@4,788,354us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get>
MSGQ_Get() status=0x8000, return (0)

	[DSP] @5,672,464tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
0x882ab0b0(vca_stab#0) call(algHandle=0x88

	2ab168, msg=0x88106c80); messageId=0x00020009

	[DSP] @5,672,568tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

	e=0x882ab168, id=41217, params=0x88106cb4, status=0x88106db0

	[DSP] @5,672,674tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

	198

	[DSP] @5,672,747tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

	andle=0x882ab198)

	[DSP] @5,672,827tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

	[DSP] @5,685,069tk: [+0 T:0x8892e644 S:0x88932494] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

	Bytes=1008)

	[DSP] @5,685,193tk: [+0 T:0x8892e644 S:0x88932494] OM -
Memory_cacheWbInv> return

	[DSP] @5,685,259tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

	98

	[DSP] @5,685,335tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

	(handle=0x882ab198)

	[DSP] @5,685,417tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

	n

	[DSP] @5,685,488tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

	=0x882ab168, retVal=0x0)

	[DSP] @5,685,621tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
returned from call(algHandle=0x882ab168, m

	sg=0x88106c80); messageId=0x00020009

	[DSP] @6,662,444tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

	[DSP] @6,662,522tk: [+0 T:0x8880006c S:0x88804024] CR - remote
time = 0x0, trace buffer size = 4032

	@4,795,428us: [+0 T:0x00008003 S:0xbe3fe944] CE -
Engine_fwriteTrace> returning count [1651]

	@4,795,640us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call
Completed: messageId=0x00020009, command=0x1

	, return(status=0)

	@4,795,851us: [+5 T:0x00008003 S:0xbe3fe9d4] CV -
VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit

	h messageId=0x00020009

	@4,796,075us: [+0 T:0x00008003 S:0xbe3fea14]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620

	58, retVal=0x0)

	@4,796,289us: [+0 T:0x00008003 S:0xbe3fea14]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62

	058, id=41218, params=0xbe3fec28, status=0xbe3feac0

	@4,796,501us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

	000a

	@4,796,692us: [+0 T:0x00008003 S:0xbe3fe9c4] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

	002000a, command=0x1

	@4,796,891us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

	@4,797,345us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put>
return (0)

	@4,797,723us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3fea24, timeout

	=-1)

	@4,798,173us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get>
MSGQ_Get() status=0x8000, return (0)

	@4,798,433us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

	@4,798,694us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put>
return (0)

	@4,799,015us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3fe9a0, timeout

	=-1)

	@4,799,256us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get>
MSGQ_Get() status=0x8000, return (0)

	[DSP] @6,684,637tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
0x882ab0b0(vca_stab#0) call(algHandle=0x88

	2ab168, msg=0x88106c80); messageId=0x0002000a

	[DSP] @6,684,743tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

	e=0x882ab168, id=41218, params=0x88106cb4, status=0x88106db0

	[DSP] @6,684,853tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

	198

	[DSP] @6,684,927tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

	andle=0x882ab198)

	[DSP] @6,685,011tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

	[DSP] @6,685,660tk: [+0 T:0x8892e644 S:0x88932504] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

	Bytes=1008)

	[DSP] @6,685,789tk: [+0 T:0x8892e644 S:0x88932504] OM -
Memory_cacheWbInv> return

	[DSP] @6,685,848tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

	98

	[DSP] @6,685,921tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

	(handle=0x882ab198)

	[DSP] @6,686,001tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

	n

	[DSP] @6,686,067tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

	=0x882ab168, retVal=0x0)

	[DSP] @6,686,152tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
returned from call(algHandle=0x882ab168, m

	sg=0x88106c80); messageId=0x0002000a

	[DSP] @6,687,790tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

	[DSP] @6,687,860tk: [+0 T:0x8880006c S:0x88804024] CR - remote
time = 0x0, trace buffer size = 4032

	@5,146,922us: [+0 T:0x00008003 S:0xbe3fe944] CE -
Engine_fwriteTrace> returning count [1651]

	@5,147,356us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call
Completed: messageId=0x0002000a, command=0x1

	, return(status=0)

	@5,147,728us: [+5 T:0x00008003 S:0xbe3fe9d4] CV -
VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit

	h messageId=0x0002000a

	@5,147,971us: [+0 T:0x00008003 S:0xbe3fea14]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620

	58, retVal=0x0)

	@5,174,837us: [+0 T:0x00008003 S:0xbe3ff874]
ti.sdo.ce.video.VIDENC - VIDENC_process> Enter (handle=0x62

	058, inBufs=0xbe3ffac0, outBufs=0xbe3ffab0, inArgs=0xbe3ff8fc,
outArgs=0xbe3ffa10)

	@5,175,123us: [+5 T:0x00008003 S:0xbe3ff7fc] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

	000b

	@5,175,328us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x404c

	9000, size=884736)

	@5,175,514us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x404c9000,

	 size=884736)

	@5,175,692us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> found in cb(Sc=0x404c9000,

	 Ec=0x405a1000, Ss=0x404c9000, Es=0x405a1000, PSc=0x8cac7000)

	@5,175,934us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> returning physAddr=0x8cac7

	000

	@5,176,105us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> return (0x8cac7000)

	@5,176,280us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4145

	8000, size=32)

	@5,176,450us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x41458000,

	 size=32)

	@5,176,621us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> found in cb(Sc=0x41458000,

	 Ec=0x41458020, Ss=0x41458000, Es=0x41458020, PSc=0x8c9ad000)

	@5,176,811us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> returning physAddr=0x8c9ad

	000

	@5,176,980us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> return (0x8c9ad000)

	@5,177,150us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x407c

	9000, size=884736)

	@5,177,369us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x407c9000,

	 size=884736)

	@5,177,545us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> found in cb(Sc=0x407c9000,

	 Ec=0x408a1000, Ss=0x407c9000, Es=0x408a1000, PSc=0x8fc94000)

	@5,177,918us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> returning physAddr=0x8fc94

	000

	@5,178,105us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> return (0x8fc94000)

	@5,178,281us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4144

	b000, size=28)

	@5,178,460us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x4144b000,

	 size=28)

	@5,178,664us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> found in cb(Sc=0x4144b000,

	 Ec=0x4144b01c, Ss=0x4144b000, Es=0x4144b01c, PSc=0x8c9ba000)

	@5,520,076us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> returning physAddr=0x8c9ba

	000

	@5,520,313us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> return (0x8c9ba000)

	@5,520,501us: [+0 T:0x00008003 S:0xbe3ff80c] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

	002000b, command=0x0

	@5,520,695us: [+0 T:0x00008003 S:0xbe3ff7dc] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

	@5,520,929us: [+0 T:0x00008003 S:0xbe3ff7dc] OC - Comm_put>
return (0)

	@5,521,114us: [+0 T:0x00008003 S:0xbe3ff7d4] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3ff87c, timeout

	=-1)

	 

	 

	After this it locks up and never returns control to the ARM
after the VIDENC_process() call.

	 

	It looks like its locking up inside the Codec Engine after
returning from the DSP side process call.

	 

	Can anyone shed some light on whats going wrong?

	 

	 

	Regards,

	Etienne Eccles

	 

	VCA Technology

	 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100414/9dfff955/attachment-0001.html>

From huangsw at temobi.com  Wed Apr 14 04:09:25 2010
From: huangsw at temobi.com (huangsw)
Date: Wed, 14 Apr 2010 17:09:25 +0800
Subject: Have you encountered the problem below?
Message-ID: <201004141709241092702@temobi.com>

Hi all, i  have updated my LSP from 01.20   to  REL_LSP_02_00_00_140, the system can run on my board.

But when i want to test network's performance,  i run iperf tools ,the board runs in server mode, and my pc is in client mode,

before run iperf ,pc can succeed to ping my board which run the LSP_02_00_00_140 kernel, but within  about  10 seconds my pc can not ping board again.



But ,when board runs the old LSP(01.20  ),board is ok, the network's performance is good.



Thanks for any advices!



2010-04-14 



huangsw 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100414/b302db4e/attachment.html>

From liuyue18301 at 163.com  Wed Apr 14 04:17:09 2010
From: liuyue18301 at 163.com (liuyue18301)
Date: Wed, 14 Apr 2010 17:17:09 +0800 (CST)
Subject: VIDDEC_process() ->VIDDECCOPY_TI_process()
Message-ID: <66bdce5e.1af69.127fb9b95cf.Coremail.liuyue18301@163.com>

hello everybody:
     int the Algorithm damon
     i think the implement of the video decode Algorithm by calling function interface VIDDEC_process and i believe the implement of VIDDEC_process() is in use of calling VIDDECCOPY_TI_process() but in the application code, i can not find out the calling relationship between VIDDEC_process() and VIDDECCOPY_TI_process() ,how can i do for confirm it 
    thank you very much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100414/4426fca9/attachment.html>

From maskachoska at yahoo.com  Wed Apr 14 07:58:07 2010
From: maskachoska at yahoo.com (AdarshSharma)
Date: Wed, 14 Apr 2010 05:58:07 -0700 (PDT)
Subject: DM6443 board - bebricking
Message-ID: <342677.72431.qm@web63607.mail.re1.yahoo.com>

Hi,

I have a board with TI DM6443, 128 mb NOR flash and 1GB ram. i tried to update u-boot on this using on board u-boot, something went wrong and now board is dead now(nothing on serial console). So i hooked up jtag lines Printer port Jtag adapter and tried to update flash using openocd using DVEVM DM6446 config. ARM Cpu and NOR flash detected fine and i was also able to update u-boot-1.2.0-davinci-nor.bin from PSP_01_20_00_014 in the begining address of flash. BUT on restartig the board nothing is coming up on the serial console. 

Is there something missing in the procedure i am following? Is there something else can be done?

Thanks and regards,
Adarsh




      

From a.auer at zydacron.com  Wed Apr 14 07:57:54 2010
From: a.auer at zydacron.com (Andreas Auer)
Date: Wed, 14 Apr 2010 14:57:54 +0200
Subject: USB subsystem (hardware EP, ...)
Message-ID: <hq4e7c$ghu$1@dough.gmane.org>

Hi,

previously, I was posting about the UVC problem but the problem is 
definitely in the USB driver.

Thus, I'm looking at the USB driver. There are a few questions about how 
the driver behaves.

* First of all, is there a direct mapping between connected USB devices 
and hardware endpoints?? So, if a device (e.g. mouse) offers an IN 
interrupt endpoint is the used hardware endpoint on the Davinci CPU 
(DM6446) reserved only for this device or can I share the used hardware 
  endpoint with several other USB devices (like keyboards).

* If the hardware endpoints are directly associated with the devices is 
this the case for all kind of device endpoints (bulk, iso, interrupt)??

Thanks,
Andreas


From Etienne.Eccles at vcatechnology.com  Tue Apr 13 06:21:32 2010
From: Etienne.Eccles at vcatechnology.com (Etienne Eccles)
Date: Tue, 13 Apr 2010 12:21:32 +0100
Subject: Codec engine lockup
Message-ID: <95FAFD227E8A2947BA96E1C807505D0412CD5A@sbs001.office.local>

Hi

 

I am getting the following debug output . using CE_DEBUG=3 when creating
and using a custom VIDENC codec:

 

 

 

root at nvc1346:/opt/davinci# CE_DEBUG=3 ./stabd -d -p a

root at nvc1346:/opt/davinci# @0,196,096us: [+4 T:0x00004000 S:0xbec8cbbc]
OG - Global_init> This program w

as built with the following packages:

@0,197,108us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
gnu.targets.rts470MV (/home/vcastab/svn/ud

p/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/gnu/targets/rts470MV
/) [1,0,0,0,1203621000516]

@0,197,334us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
dsplink.gpp (/home/vcastab/svn/udp/linux/d

vsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/dsplink/gpp/
) [3,0,0]

@0,197,516us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.xdais.dm (/home/vcastab/svn/udp/linux/d

vsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/dm/
) [1,0,4,1210262746529]

@0,197,948us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.xdais
(/home/vcastab/svn/udp/linux/dvsd

k/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/)
[1,2,1,1210262742149]

@0,198,149us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.utils.trace (/home/vcastab/svn/udp/

linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sd
o/utils/trace/) [1,0,0,122094336

6422]

@0,198,331us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.utils.xdm (/home/vcastab/svn/udp

/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ut
ils/xdm/) [1,0,1,1220951322616]

@0,198,510us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.fc.dman3 (/home/vcastab/svn/udp/lin

ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/f
c/dman3/) [1,0,3,1220943053023]

@0,198,682us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.fc.acpy3 (/home/vcastab/svn/udp/lin

ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/f
c/acpy3/) [1,0,2,1220943014135]

@0,198,852us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.linuxutils.cmem (/home/vcastab/svn/

udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/t
i/sdo/linuxutils/cmem/) [2,0,1,1

204929560755]

@0,199,030us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.catalog.c470 (/home/vcastab/svn/udp/lin

ux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/catalog/c470/)
[1,0,1,0,1203561761475]

@0,199,200us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.platforms.evmDM6446 (/home/vcastab/svn/

udp/linux/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/platforms/evmD
M6446/) [1,0,0,1,1192229600615]

@0,199,369us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.osal (/home/vcastab/svn/udp/linu

x/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/osal/)
[2,0,2,1220951127739]

@0,199,539us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.ipc (/home/vcastab/svn/udp/linux

/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/)
[2,0,1,1220951085787]

@0,199,704us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.alg (/home/vcastab/svn/udp/linux

/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/alg/)
[1,0,1,1220950781938]

@0,199,875us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.osal.linux (/home/vcastab/svn/ud

p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/o
sal/linux/) [2,0,1,1220951140072

]

@0,200,049us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.ipc.dsplink (/home/vcastab/svn/u

dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/
ipc/dsplink/) [2,0,1,12209510968

18]

@0,200,219us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce
(/home/vcastab/svn/udp/linux/dvs

dk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/)
[1,0,6,1220950771473]

@0,200,386us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.video (/home/vcastab/svn/udp/lin

ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/video/
) [1,0,3,1220951334122]

@0,200,559us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
codecs.vca_stab (/home/vcastab/svn/vt/davi

nci/trunk/ce1/codecs/vca_stab/) []

@0,200,718us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.bioslog (/home/vcastab/svn/udp/l

inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/bios
log/) [1,0,1,1220950800329]

@0,587,586us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
ti.sdo.ce.utils.trace (/home/vcastab/svn/u

dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/
utils/trace/) [1,0,1,12209513170

87]

@0,587,929us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package
apps.stab_client (/home/vcastab/svn/vt/dav

inci/trunk/ce1/apps/stab_client/) []

@0,588,146us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter
(fxn=0x20028)

@0,588,352us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter
(fxn=0x1f4c0)

@0,588,676us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
Enter(0x18)

@0,589,026us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return
(0x5e138)

@0,589,716us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit> enter
(fxn=0x1dda8)

@0,590,050us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
Enter(0x18)

@0,590,269us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return
(0x5e188)

@0,590,492us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit> enter
(fxn=0x1b9f4)

@0,590,839us: [+0 T:0x00004000 S:0xbec8cbbc] OG - Global_atexit> enter
(fxn=0x1eb44)

@0,593,794us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem -
Sem_create> count: 0

@0,594,023us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc>
Enter(0x14)

@0,594,212us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> return
(0x5e208)

@0,594,470us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem -
Leaving Sem_create> sem[0x5e208]

@0,594,698us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem -
Sem_create> count: 0

@0,594,859us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc>
Enter(0x14)

@0,595,056us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> return
(0x5e220)

@0,595,220us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem -
Leaving Sem_create> sem[0x5e220]

@0,595,378us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc>
Enter(0x18)

@0,595,544us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> return
(0x5e238)

@0,595,707us: [+0 T:0x00004000 S:0xbec8cb8c] OT - Thread_create> Enter
(fxn=0x1ab34, attrs=0x0)

@0,595,869us: [+0 T:0x00004000 S:0xbec8cb74] OM - Memory_alloc>
Enter(0x64)

@0,596,064us: [+0 T:0x00004000 S:0xbec8cb74] OM - Memory_alloc> return
(0x5e258)

@0,598,964us: [+1 T:0x00004002 S:0xbe5ffa74] OP - daemon> thread
created.

@0,599,205us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d> Enter
(proc=0xbe5ffaec)

@0,599,387us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem -
Entered Sem_pend> sem[0x5e208] timeout

[0xffffffff]

@0,599,998us: [+0 T:0x00004000 S:0xbec8cb8c] OT - Thread_create> Exit
(task=0x5e258)

@0,600,235us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter
(fxn=0x1a6f4)

@0,600,501us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter
(fxn=0x1c7e8)

@0,600,791us: [+0 T:0x00004000 S:0xbec8cbac] ti.sdo.ce.alg - ALG_init>
Enter

@0,600,984us: [+0 T:0x00004000 S:0xbec8cb9c] OG - Global_atexit> enter
(fxn=0x209f0)

@0,601,171us: [+0 T:0x00004000 S:0xbec8cbcc] ti.sdo.ce.alg - ALG_init>
Exit

@0,601,339us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter
(fxn=0x20490)

@0,601,541us: [+0 T:0x00004000 S:0xbec8cb9c] OM - Memory_alloc>
Enter(0x18)

@0,601,767us: [+0 T:0x00004000 S:0xbec8cb9c] OM - Memory_alloc> return
(0x60418)

@0,601,955us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter
(fxn=0x1eca8)

@0,602,262us: [+6 T:0x00004000 S:0xbec8cbc4] CE - Engine_init> CE
debugging on (CE_DEBUG=3; allowed CE_D

EBUG levels: 1=min, 2=good, 3=max)

@0,602,481us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit> enter
(fxn=0x17734)

@0,602,667us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
Enter(0x18)

@0,602,852us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return
(0x60458)

@0,603,024us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
Enter(0x18)

@0,603,247us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return
(0x60478)

@0,603,423us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc>
Enter(0x18)

@0,603,600us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return
(0x60498)

@0,944,735us: [+0 T:0x00004000 S:0xbec8cbc4] CS - Server_init()

@0,944,957us: [+0 T:0x00004000 S:0xbec8cbc4] CS - Server_init>
Global_useLinkArbiter = 0

@0,945,138us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter
(fxn=0x16284)

@0,945,529us: [+0 T:0x00004000 S:0xbec8cbd4] OG - Global_atexit> enter
(fxn=0x14148)

@0,945,950us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
Enter(size=884736, align=-1, cache

d=FALSE, heap=FALSE)

@0,946,486us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_alloc(884736) = 0x403ee000.

@0,946,744us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_getPhys(0x403ee000) = 0x8ff25

000.

@0,946,938us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
Enter(virtAddr=0x403ee000, size=

884736, physAddr=0x8ff25000)

@0,947,127us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
creating new contigBuf object

@0,947,319us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

@0,947,514us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return
(0x60518)

@0,947,842us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
returning: cb->phys=0x8ff25000,

cb->size=884736, cb->virt=0x403ee000

@0,948,044us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
return (0x403ee000)

@0,948,270us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
Enter(size=884736, align=-1, cache

d=FALSE, heap=FALSE)

@0,948,643us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_alloc(884736) = 0x404c9000.

@0,948,931us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_getPhys(0x404c9000) = 0x8cac7

000.

@0,949,123us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
Enter(virtAddr=0x404c9000, size=

884736, physAddr=0x8cac7000)

@0,949,305us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
creating new contigBuf object

@0,949,467us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

@0,949,651us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return
(0x60530)

@0,949,823us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
returning: cb->phys=0x8cac7000,

cb->size=884736, cb->virt=0x404c9000

@0,950,004us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
return (0x404c9000)

@0,950,206us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
Enter(size=884736, align=-1, cache

d=FALSE, heap=FALSE)

@0,950,595us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_alloc(884736) = 0x405c9000.

@0,950,841us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_getPhys(0x405c9000) = 0x8c9c7

000.

@0,951,032us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
Enter(virtAddr=0x405c9000, size=

884736, physAddr=0x8c9c7000)

@0,951,219us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
creating new contigBuf object

@0,951,380us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

@0,951,592us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return
(0x60548)

@0,951,775us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
returning: cb->phys=0x8c9c7000,

cb->size=884736, cb->virt=0x405c9000

@0,951,959us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
return (0x405c9000)

@0,952,125us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
Enter(size=884736, align=-1, cache

d=FALSE, heap=FALSE)

@0,952,475us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_alloc(884736) = 0x406c9000.

@0,952,718us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_getPhys(0x406c9000) = 0x8c879

000.

@0,952,911us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
Enter(virtAddr=0x406c9000, size=

884736, physAddr=0x8c879000)

@0,953,145us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
creating new contigBuf object

@0,953,310us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

@0,953,490us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return
(0x60560)

@1,294,466us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
returning: cb->phys=0x8c879000,

cb->size=884736, cb->virt=0x406c9000

@1,294,700us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
return (0x406c9000)

@1,294,877us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
Enter(size=884736, align=-1, cache

d=FALSE, heap=FALSE)

@1,295,385us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_alloc(884736) = 0x407c9000.

@1,295,626us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_getPhys(0x407c9000) = 0x8fc94

000.

@1,295,850us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
Enter(virtAddr=0x407c9000, size=

884736, physAddr=0x8fc94000)

@1,296,040us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
creating new contigBuf object

@1,296,206us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

@1,296,387us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return
(0x60578)

@1,296,557us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
returning: cb->phys=0x8fc94000,

cb->size=884736, cb->virt=0x407c9000

@1,296,739us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
return (0x407c9000)

@1,296,908us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
Enter(size=884736, align=-1, cache

d=FALSE, heap=FALSE)

@1,297,589us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_alloc(884736) = 0x40a5a000.

@1,298,146us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
CMEM_getPhys(0x40a5a000) = 0x8f8de

000.

@1,298,345us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
Enter(virtAddr=0x40a5a000, size=

884736, physAddr=0x8f8de000)

@1,298,538us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
creating new contigBuf object

@1,298,750us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc>
Enter(0x10)

@1,298,934us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return
(0x60590)

@1,299,106us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf>
returning: cb->phys=0x8f8de000,

cb->size=884736, cb->virt=0x40a5a000

@1,299,290us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc>
return (0x40a5a000)

@1,309,917us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - Engine_open>
Enter('vca_engine', 0x0, 0xbe3ffa84)

@1,310,205us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc>
Enter(0x2c)

@1,310,419us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc> return
(0x605a8)

@1,310,604us: [+0 T:0x00008003 S:0xbe3ff9e4] CE -
rserverOpen('./server_release.x64P'), count = 0

@1,310,785us: [+0 T:0x00008003 S:0xbe3ff9ac] OP - Processor_create>
Enter(imageName='./server_release.x6

4P', linkCfg='(null)', attrs=0xbe3ffa30)

@1,312,833us: [+0 T:0x00008003 S:0xbe3ff994] OM - Memory_alloc>
Enter(0x24)

@1,313,100us: [+0 T:0x00008003 S:0xbe3ff994] OM - Memory_alloc> return
(0x605d8)

@1,313,292us: [+0 T:0x00008003 S:0xbe3ff98c] OP - doCmd> Enter (cmdId=1,
proc=0x605d8)

@1,313,470us: [+0 T:0x00008003 S:0xbe3ff97c] ti.sdo.ce.osal.Sem -
Entered Sem_post> sem[0x5e208]

@1,313,801us: [+0 T:0x00008003 S:0xbe3ff98c] ti.sdo.ce.osal.Sem -
Leaving Sem_post> sem[0x5e208]

@1,314,019us: [+0 T:0x00008003 S:0xbe3ff96c] ti.sdo.ce.osal.Sem -
Entered Sem_pend> sem[0x5e220] timeout

[0xffffffff]

@1,314,506us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem -
Leaving Sem_pend> sem[0x5e208] status[

0]

@1,314,978us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d> Exit
(result=1)

@1,315,460us: [+0 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Enter(proc=0x605d8)

@1,315,900us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Initializing DSP PROC...

@1,316,335us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Using DspLink config data for entr

y #0 [server './server_release.x64P']

@1,316,786us: [+0 T:0x00004002 S:0xbe5ffa5c] OM - Memory_alloc>
Enter(0xe0)

@1,317,458us: [+0 T:0x00004002 S:0xbe5ffa5c] OM - Memory_alloc> return
(0x60600)

@1,318,325us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Adding DSP segment #0 to Link conf

iguration: name='DDR', startAddress=0x88200000, sizeInBytes=0x400000,
shared=1

@1,660,152us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Adding DSP segment #1 to Link conf

iguration: name='DSPLINKMEM', startAddress=0x88100000,
sizeInBytes=0x100000, shared=1

@1,660,412us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Adding DSP segment #2 to Link conf

iguration: name='RESET_VECTOR', startAddress=0x88000000,
sizeInBytes=0x80, shared=0

@1,660,650us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Adding DSP segment #3 to Link conf

iguration: name='DDRALGHEAP', startAddress=0x88800000,
sizeInBytes=0x1c00000, shared=0

@1,660,856us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
DOPOWERCONTROL was=0; now=0

SET WIDTH to 720 HEIGHT to 576

@1,685,617us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Attaching to DSP PROC...

@1,698,711us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Opening MSGQ pool...

@1,699,722us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Loading ./server_release.x64P on D

SP (1 args)...

@1,892,865us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Starting DSP PROC...

@1,916,709us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
Opening remote transport...

@1,917,511us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d>
return (1)

@1,918,475us: [+0 T:0x00004002 S:0xbe5ffa64] ti.sdo.ce.osal.Sem -
Entered Sem_post> sem[0x5e220]

@1,918,948us: [+0 T:0x00008003 S:0xbe3ff96c] ti.sdo.ce.osal.Sem -
Leaving Sem_pend> sem[0x5e220] status[

0]

@1,919,260us: [+0 T:0x00008003 S:0xbe3ff98c] OP - doCmd> Exit (result=1)

@1,919,438us: [+0 T:0x00008003 S:0xbe3ff9ac] OP - Processor_create>
return (0x605d8)

@1,919,611us: [+0 T:0x00008003 S:0xbe3ff9e4] CE -
rserverOpen('./server_release.x64P'): 0x5701c done.

@1,919,799us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc>
Enter(0x1e)

@1,919,990us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc> return
(0x61fd0)

@1,920,188us: [+0 T:0x00008003 S:0xbe3ff9bc] OC - Comm_create>
Enter(queueName='vca_engine_0', queue=0x6

05b8, attrs=0x0)

@1,920,370us: [+0 T:0x00008003 S:0xbe3ff9a4] OM - Memory_alloc>
Enter(0x4)

@1,920,579us: [+0 T:0x00008003 S:0xbe3ff9a4] OM - Memory_alloc> return
(0x61ff8)

@1,921,144us: [+0 T:0x00008003 S:0xbe3ff9bc] OC - Comm_create> return
(0x61ff8)

@1,921,384us: [+0 T:0x00008003 S:0xbe3ff9bc] OM - Memory_free>
Enter(0x61fd0, 0x1e)

@1,921,582us: [+0 T:0x00008003 S:0xbe3ff9bc] OM - Memory_free> return
(0x1)

@1,921,758us: [+0 T:0x00008003 S:0xbe3ff9c4] OC - Comm_alloc>
Enter(poolId=0x0, msg=0x605c4, size=576)

@1,921,990us: [+0 T:0x00008003 S:0xbe3ff9c4] OC - Comm_alloc>
msg=0x413dbc80, returning (0)

@1,922,187us: [+0 T:0x00008003 S:0xbe3ff9a4] OC - Comm_locate>
Enter(queueName='rmsq', queue=0x605b4)

@1,931,192us: [+0 T:0x00008003 S:0xbe3ff9a4] OC - Comm_locate> return
(0)

@1,931,465us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - checkServer(0x605a8)

@1,931,739us: [+0 T:0x00008003 S:0xbe3ff9b4] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@1,932,050us: [+0 T:0x00008003 S:0xbe3ff9b4] OC - Comm_put> return (0)

@1,932,339us: [+0 T:0x00008003 S:0xbe3ff9ac] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ffa28, timeout

=-1)

@1,932,567us: [+0 T:0x00008003 S:0xbe3ff9ac] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@1,932,768us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - rmsInit> RMS
initialized(0x605a8); CE_DEBUG on, settin

g DSP trace mask to *+01234567,GT_prefix=12345,GT_time=3

@1,932,966us: [+0 T:0x00008003 S:0xbe3ff9b4] CE - Engine_setTrace>
Enter(engine=0x605a8, mask='*+0123456

7,GT_prefix=12345,GT_time=3')

@1,933,180us: [+1 T:0x00008003 S:0xbe3ff9b4] CE - Engine_setTrace>
Requesting DSP set trace ...

@1,933,348us: [+0 T:0x00008003 S:0xbe3ff984] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@1,933,635us: [+0 T:0x00008003 S:0xbe3ff984] OC - Comm_put> return (0)

@1,933,821us: [+0 T:0x00008003 S:0xbe3ff97c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff9ec, timeout

=-1)

@1,934,437us: [+0 T:0x00004002 S:0xbe5ffa74] ti.sdo.ce.osal.Sem -
Leaving Sem_post> sem[0x5e220]

@1,934,692us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d> Enter
(proc=0xbe5ffaec)

@1,934,920us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem -
Entered Sem_pend> sem[0x5e208] timeout

[0xffffffff]

@1,937,498us: [+0 T:0x00008003 S:0xbe3ff97c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@1,937,904us: [+0 T:0x00008003 S:0xbe3ff9b4] CE - Engine_setTrace>
return(0)

@1,938,126us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@1,938,384us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put> return (0)

@1,938,673us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff9d0, timeout

=-1)

@1,938,903us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

[DSP] @0x00000208:[T:0x00000000] ZZ - main> Welcome to loopback server's
main().

[DSP] @0x0000086c:[T:0x8880415c] LS - server()

[DSP] @0x0000088d:[T:0x8880415c] OM - Memory_alloc> Enter(size=0x24)

[DSP] @0x000008b8:[T:0x8880415c] OM - Memory_alloc> return (0x882ab060)

[DSP] @0x000008e6:[T:0x8880415c] LS - server: serverMsgQueue =
0x00000001

[DSP] @0x0000090f:[T:0x8880415c] LS - server: waiting for cmd

[DSP] @0x00008cc2:[T:0x8880006c] CR - processRmsCmd(0x88105ca8, 4056):
cmd = 6

[DSP] @0x00009b1c:[T:0x8880006c] CR - processRmsCmd(0x88105ca8, 4056):
cmd = 8

[DSP] @0x00009b50:[T:0x8880006c] CR - setting trace mask to
*+01234567,GT_prefix=12345,GT_time=3

[DSP] @0,039,852tk: [+0 T:0x8880006c S:0x88803fdc] OG -
Global_setSpecialTrace> enter(mask='*+01234567,G

T_prefix=12345,GT_time=3')

[DSP] @0,039,938tk: [+4 T:0x8880006c S:0x88803fdc] OG -
Global_setSpecialTrace> This program was built w

ith the following packages:

[DSP] @0,040,015tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.targets.rts6000 (/home/vcastab/sv

n/udp/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/targets/rts60
00/) [1,0,0,0,1203621186754]

[DSP] @0,040,139tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.fc.dman3 (/home/vcastab/svn/u

dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti
/sdo/fc/dman3/) [1,0,3,122094305

3023]

[DSP] @0,040,255tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.rtdx (/home/vcastab/svn/udp/linux

/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/rtdx/)
[2,0,0,1,1194024051755]

[DSP] @0,040,356tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.psl (/home/vcastab/svn/udp/linux/

dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/psl/) [5,0,0,0,0]

[DSP] @0,040,451tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.bios (/home/vcastab/svn/udp/linux

/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/bios/)
[5,2,4,9,1193960176642]

[DSP] @0,040,552tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.fc.dskt2 (/home/vcastab/svn/u

dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti
/sdo/fc/dskt2/) [1,0,4,122094309

5081]

[DSP] @0,040,668tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.xdais.dm (/home/vcastab/svn/udp/l

inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xda
is/dm/) [1,0,4,1210262746529]

[DSP] @0,040,781tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.xdais (/home/vcastab/svn/udp/linu

x/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/
) [1,2,1,1210262742149]

[DSP] @0,040,890tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.node (/home/vcastab/svn/ud

p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/n
ode/) [1,0,0,1220951122176]

[DSP] @0,041,001tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.ipc.dsplink.dsp (/home/vca

stab/svn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/
ti/sdo/ce/ipc/dsplink/dsp/) [2,0

,1,1220951102696]

[DSP] @0,041,122tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.utils.trace (/home/vcastab/sv

n/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages
/ti/sdo/utils/trace/) [1,0,0,122

0943366422]

[DSP] @0,041,242tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.utils.xdm (/home/vcastab/s

vn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo
/ce/utils/xdm/) [1,0,1,122095132

2616]

[DSP] @0,041,357tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.fc.acpy3 (/home/vcastab/svn/u

dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti
/sdo/fc/acpy3/) [1,0,2,122094301

4135]

[DSP] @0,041,473tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
dsplink.dsp (/home/vcastab/svn/udp/l

inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/dsplin
k/dsp/) [1,3,0]

[DSP] @0,041,578tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.bios.utils (/home/vcastab/svn/udp

/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/b
ios/utils/) [2,0,1,0,11918918306

09]

[DSP] @0,041,693tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.catalog.c6000 (/home/vcastab/svn/

udp/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/catalog/c6000/)
[1,0,0,0,1203561781695]

[DSP] @0,041,802t at 2,297,823us: [+0 T:0x00008003 S:0xbe3ff944] OC -
Comm_put> Enter(queue=0x0, msg=0x413d

bc80)

@2,298,120us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put> return (0)

@2,298,417us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff9d0, timeout

=-1)

@2,298,649us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

k: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.platforms.evmDM6446 (/home/vcastab/svn/udp/linux/d

vsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/platforms/evmDM6446/)
[1,0,0,1,1192229600615]

[DSP] @0,041,919tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.osal (/home/vcastab/svn/ud

p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/o
sal/) [2,0,2,1220951127739]

[DSP] @0,042,030tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.ipc (/home/vcastab/svn/udp

/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ip
c/) [2,0,1,1220951085787]

[DSP] @0,042,139tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.alg (/home/vcastab/svn/udp

/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/al
g/) [1,0,1,1220950781938]

[DSP] @0,042,249tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.osal.bios (/home/vcastab/s

vn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo
/ce/osal/bios/) [2,0,1,122095113

3740]

[DSP] @0,042,365tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.ipc.bios (/home/vcastab/sv

n/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/
ce/ipc/bios/) [2,0,1,12209510910

97]

[DSP] @0,042,487tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce (/home/vcastab/svn/udp/lin

ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/)
[1,0,6,1220950771473]

[DSP] @0,042,593tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.bioslog (/home/vcastab/svn

/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/c
e/bioslog/) [1,0,1,1220950800329

]

[DSP] @0,042,706tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.sdo.ce.video (/home/vcastab/svn/u

dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/
video/) [1,0,3,1220951334122]

[DSP] @0,042,818tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
codecs.vca_stab (/home/vcastab/svn/v

t/davinci/trunk/ce1/codecs/vca_stab/) []

[DSP] @0,042,901tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package
servers.vca_stab_server (/home/vcast

ab/svn/vt/davinci/trunk/ce1/servers/vca_stab_server/) []

[DSP] @0,042,992tk: [+0 T:0x8880006c S:0x88803fdc] OG -
Global_setSpecialTrace> return

[DSP] @0,050,728tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

[DSP] @0,050,799tk: [+0 T:0x8880006c S:0x88804024] CR - remote time =
0x0, trace buffer size = 4032

[DSP] @0,885,481tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

[DSP] @0,885,547tk: [+0 T:0x8880006c S:0x88804024] CR - remote time =
0x0, trace buffer size = 4032

@2,650,231us: [+0 T:0x00008003 S:0xbe3ff974] CE - Engine_fwriteTrace>
returning count [6828]

@2,650,445us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - Engine_open>
return(394664)

@2,650,660us: [+0 T:0x00008003 S:0xbe3ffa34] ti.sdo.ce.video.VIDENC -
VIDENC_create> Enter (engine=0x605

a8, name='vca_stab', params=0xbe3ffa88)

@2,650,896us: [+0 T:0x00008003 S:0xbe3ffa04] CV - VISA_create(0x605a8,
'vca_stab', 0xbe3ffa88, 0x828, 't

i.sdo.ce.video.IVIDENC')

@2,651,104us: [+0 T:0x00008003 S:0xbe3ff92c] CV - VISA_create2(0x605a8,
'vca_stab', 0xbe3ffa88, 0x2c, 0x

828, 'ti.sdo.ce.video.IVIDENC')

@2,651,363us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc>
Enter(0x30)

@2,651,589us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc> return
(0x62058)

@2,651,782us: [+0 T:0x00008003 S:0xbe3ff8bc] CE -
Engine_createNode(0x605a8, 'vca_stab', 828, 0xbe3ffa88

, 0x2c, 0xbe3ffa30)

@2,651,980us: [+0 T:0x00008003 S:0xbe3ff8a4] OM - Memory_alloc>
Enter(0x20)

@2,652,163us: [+0 T:0x00008003 S:0xbe3ff8a4] OM - Memory_alloc> return
(0x61fd0)

@2,652,361us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_create>
Enter(queueName='gppfromnode_1', queue=0x

61fd8, attrs=0x0)

@2,652,545us: [+0 T:0x00008003 S:0xbe3ff87c] OM - Memory_alloc>
Enter(0x4)

@2,652,730us: [+0 T:0x00008003 S:0xbe3ff87c] OM - Memory_alloc> return
(0x62090)

@2,993,385us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_create> return
(0x62090)

@2,993,649us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@2,993,987us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put> return (0)

@2,994,199us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff914, timeout

=-1)

@3,010,127us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@3,010,439us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@3,010,710us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put> return (0)

@3,010,993us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff914, timeout

=-1)

@3,011,253us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@3,011,492us: [+4 T:0x00008003 S:0xbe3ff8bc] CE - Engine_createNode>
created node(stdIn=0x2, stdOut=0x10

001, msgq=0x62090, algName='vca_stab', rmsNode=0x882ab088,
algHandle=0x882ab168)

@3,011,735us: [+0 T:0x00008003 S:0xbe3ff81c] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@3,011,981us: [+0 T:0x00008003 S:0xbe3ff81c] OC - Comm_put> return (0)

@3,012,254us: [+0 T:0x00008003 S:0xbe3ff814] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff8a8, timeout

=-1)

@3,012,488us: [+0 T:0x00008003 S:0xbe3ff814] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

[DSP] @2,500,228tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 0

[DSP] @2,500,305tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc>
Enter(size=0x18)

[DSP] @2,500,365tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc>
return (0x882ab088)

[DSP] @2,500,425tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc>
Enter(size=0xb)

[DSP] @2,500,480tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc>
return (0x882ab0a0)

[DSP] @2,500,549tk: [+0 T:0x8880006c S:0x88803edc] OM - Memory_alloc>
Enter(size=0x20)

[DSP] @2,500,605tk: [+0 T:0x8880006c S:0x88803edc] OM - Memory_alloc>
return (0x882ab0b0)

[DSP] @2,500,665tk: [+0 T:0x8880006c S:0x88803eac] OM - Memory_alloc>
Enter(size=0x24)

[DSP] @2,500,722tk: [+0 T:0x8880006c S:0x88803eac] OM - Memory_alloc>
return (0x882ab0d0)

[DSP] @2,500,806tk: [+0 T:0x8880006c S:0x88803ec4]
ti.sdo.ce.video.VIDENC - VIDENC_create> Enter (engine

=0x0, name='vca_stab', params=0x88105cc0)

[DSP] @2,500,902tk: [+0 T:0x8880006c S:0x88803e8c] CV - VISA_create(0x0,
'vca_stab', 0x88105cc0, 0x828,

'ti.sdo.ce.video.IVIDENC')

[DSP] @2,500,988tk: [+0 T:0x8880006c S:0x88803d7c] CV -
VISA_create2(0x0, 'vca_stab', 0x88105cc0, 0x2c,

0x828, 'ti.sdo.ce.video.IVIDENC')

[DSP] @2,501,089tk: [+0 T:0x8880006c S:0x88803d14] CE - Engine_open>
Enter('local', 0x88803d6c, 0x33c)

[DSP] @2,501,158tk: [+0 T:0x8880006c S:0x88803cf4] OM - Memory_alloc>
Enter(size=0x2c)

[DSP] @2,501,216tk: [+0 T:0x8880006c S:0x88803cf4] OM - Memory_alloc>
return (0x882ab138)

[DSP] @2,501,287tk: [+0 T:0x8880006c S:0x88803d14] CE - Engine_open>
return(-2010468040)

[DSP] @2,501,362tk: [+0 T:0x8880006c S:0x88803d5c] OM - Memory_alloc>
Enter(size=0x30)

[DSP] @2,501,418tk: [+0 T:0x8880006c S:0x88803d5c] OM - Memory_alloc>
return (0x882ab168)

[DSP] @2,501,484tk: [+0 T:0x8880006c S:0x88803d34]
ti.sdo.ce.alg.Algorithm - Algorithm_create> Enter(fxn

s=0x88266574, idma3Fxns=0x882665a0, params=0x88105cc0, attrs=0x88803e80)

[DSP] @2,501,595tk: [+0 T:0x8880006c S:0x88803d14] OM - Memory_alloc>
Enter(size=0x10)

[DSP] @2,501,652tk: [+0 T:0x8880006c S:0x88803d14] OM - Memory_alloc>
return (0x882ab198)

[DSP] @2,519,578tk: [+0 T:0x8880006c S:0x88803c34] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

Bytes=1008)

[DSP] @2,519,697tk: [+0 T:0x8880006c S:0x88803c34] OM -
Memory_cacheWbInv> return

[DSP] @2,535,121tk: [+0 T:0x8880006c S:0x88803c0c] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

Bytes=32)

[DSP] @2,535,236tk: [+0 T:0x8880006c S:0x88803c0c] OM -
Memory_cacheWbInv> return

[DSP] @2,535,480tk: [+0 T:0x8880006c S:0x88803bc4] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

Bytes=32)

[DSP] @2,535,566tk: [+0 T:0x8880006c S:0x88803bc4] OM -
Memory_cacheWbInv> return

[DSP] @2,535,835tk: [+0 T:0x8880006c S:0x88803b9c] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

Bytes=32)

[DSP] @2,535,925tk: [+0 T:0x8880006c S:0x88803b9c] OM -
Memory_cacheWbInv> return

[DSP] @2,536,688tk: [+0 T:0x8880006c S:0x88803cb4] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

Bytes=1008)

[DSP] @2,536,793tk: [+0 T:0x8880006c S:0x88803cb4] OM -
Memory_cacheWbInv> return

[DSP] @2,536,915tk: [+0 T:0x8880006c S:0x88803d34]
ti.sdo.ce.alg.Algorithm - Algorithm_create> return (0

x882ab198)

[DSP] @2,536,997tk: [+0 T:0x8880006c S:0x88803ec4]
ti.sdo.ce.video.VIDENC - VIDENC_create> return (0x882

ab168)

[DSP] @2,537,080tk: [+4 T:0x8880006c S:0x88803e84] OT - Thread_create >
name: "vca_stab#0", pri:  -1, st

ack size:  16384, stack seg: 0

[DSP] @2,539,051tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 1

[DSP] @2,541,980tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

[DSP] @2,542,048tk: [+0 T:0x8880006c S:0x88804024] CR - remote time =
0x0, trace buffer size = 4032

@3,369,765us: [+0 T:0x00008003 S:0xbe3ff84c] CE - Engine_fwriteTrace>
returning count [3758]

@3,369,981us: [+2 T:0x00008003 S:0xbe3ff8bc] CE - Engine_createNode>
Returning 0x61fd0

@3,370,160us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc>
Enter(0x4)

@3,370,349us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc> return
(0x620a0)

@3,370,528us: [+0 T:0x00008003 S:0xbe3ff90c] OC - Comm_alloc>
Enter(poolId=0x0, msg=0x620a0, size=828)

@3,370,760us: [+0 T:0x00008003 S:0xbe3ff90c] OC - Comm_alloc>
msg=0x413dcc80, returning (0)

@3,370,981us: [+5 T:0x00008003 S:0xbe3ff92c] CV - VISA_create> remote
codec created (name='vca_stab', lo

calQueueID=0x10001, remoteQueueID=0x0002)

@3,371,235us: [+0 T:0x00008003 S:0xbe3ffa34] ti.sdo.ce.video.VIDENC -
VIDENC_create> return (0x62058)

@3,374,722us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC -
VIDENC_control> Enter (handle=0x62

058, id=257, params=0x5abe8, status=0xbe3ffa28

@3,375,009us: [+5 T:0x00008003 S:0xbe3ff844] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

0006

@3,375,208us: [+0 T:0x00008003 S:0xbe3ff824] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

0020006, command=0x1

@3,375,431us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

@3,375,692us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put> return (0)

@3,375,884us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3ff884, timeout

=-1)

@3,376,737us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@3,377,056us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@3,377,322us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put> return (0)

@3,377,720us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff800, timeout

=-1)

@3,378,173us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

[DSP] @3,385,962tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
0x882ab0b0(vca_stab#0) call(algHandle=0x88

2ab168, msg=0x88106c80); messageId=0x00020006

[DSP] @3,386,079tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

e=0x882ab168, id=257, params=0x88106cb4, status=0x88106d00

[DSP] @3,386,192tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

198

[DSP] @3,386,267tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

andle=0x882ab198)

[DSP] @3,386,383tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

[DSP] @3,386,881tk: [+0 T:0x8892e644 S:0x889324c4] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

Bytes=32)

[DSP] @3,386,997tk: [+0 T:0x8892e644 S:0x889324c4] OM -
Memory_cacheWbInv> return

[DSP] @3,387,126tk: [+0 T:0x8892e644 S:0x889324b4] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

Bytes=32)

[DSP] @3,387,203tk: [+0 T:0x8892e644 S:0x889324b4] OM -
Memory_cacheWbInv> return

[DSP] @3,387,442tk: [+0 T:0x8892e644 S:0x8893248c] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

Bytes=32)

[DSP] @3,387,538tk: [+0 T:0x8892e644 S:0x8893248c] OM -
Memory_cacheWbInv> return

[DSP] @3,387,604tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

98

[DSP] @3,387,679tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

(handle=0x882ab198)

[DSP] @3,387,760tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

n

[DSP] @3,387,834tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

=0x882ab168, retVal=0x0)

[DSP] @3,387,919tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned
from call(algHandle=0x882ab168, m

sg=0x88106c80); messageId=0x00020006

[DSP] @3,389,753tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

[DSP] @3,389,829tk: [+0 T:0x8880006c S:0x88804024] CR - remote time =
0x0, trace buffer size = 4032

@3,727,875us: [+0 T:0x00008003 S:0xbe3ff7a4] CE - Engine_fwriteTrace>
returning count [2039]

@3,728,094us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call Completed:
messageId=0x00020006, command=0x1

, return(status=0)

@3,728,332us: [+5 T:0x00008003 S:0xbe3ff834] CV - VISA_freeMsg(0x62058,
0x413dcc80): Freeing message wit

h messageId=0x00020006

@3,728,530us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC -
VIDENC_control> Exit (handle=0x620

58, retVal=0x0)

@3,728,715us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC -
VIDENC_control> Enter (handle=0x62

058, id=259, params=0x5abe8, status=0xbe3ff930

@3,728,916us: [+5 T:0x00008003 S:0xbe3ff844] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

0007

@3,729,097us: [+0 T:0x00008003 S:0xbe3ff824] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

0020007, command=0x1

@3,729,285us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

@3,729,551us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put> return (0)

@3,729,751us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3ff884, timeout

=-1)

@3,730,056us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@3,730,282us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@3,730,528us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put> return (0)

@3,730,802us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3ff800, timeout

=-1)

@3,731,055us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

[DSP] @4,206,979tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
0x882ab0b0(vca_stab#0) call(algHandle=0x88

2ab168, msg=0x88106c80); messageId=0x00020007

[DSP] @4,207,083tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

e=0x882ab168, id=259, params=0x88106cb4, status=0x88106d00

[DSP] @4,207,189tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

198

[DSP] @4,207,262tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

andle=0x882ab198)

[DSP] @4,207,346tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

[DSP] @4,207,420tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

98

[DSP] @4,207,494tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

(handle=0x882ab198)

[DSP] @4,207,571tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

n

[DSP] @4,207,636tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

=0x882ab168, retVal=0x0)

[DSP] @4,207,714tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned
from call(algHandle=0x882ab168, m

sg=0x88106c80); messageId=0x00020007

[DSP] @4,209,298tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

[DSP] @4,209,366tk: [+0 T:0x8880006c S:0x88804024] CR - remote time =
0x0, trace buffer size = 4032

@4,078,103us: [+0 T:0x00008003 S:0xbe3ff7a4] CE - Engine_fwriteTrace>
returning count [1451]

@4,078,339us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call Completed:
messageId=0x00020007, command=0x1

, return(status=0)

@4,078,546us: [+5 T:0x00008003 S:0xbe3ff834] CV - VISA_freeMsg(0x62058,
0x413dcc80): Freeing message wit

h messageId=0x00020007

@4,078,742us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC -
VIDENC_control> Exit (handle=0x620

58, retVal=0x0)

SVN Version: 3093:3110

STAB Version: 01.06.08

@4,079,044us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc>
Enter(size=28, align=-1, cached=FA

LSE, heap=FALSE)

@4,079,389us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc>
CMEM_alloc(28) = 0x4144b000.

@4,079,680us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc>
CMEM_getPhys(0x4144b000) = 0x8c9ba

000.

@4,079,883us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf>
Enter(virtAddr=0x4144b000, size=

28, physAddr=0x8c9ba000)

@4,080,074us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf>
creating new contigBuf object

@4,080,242us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc>
Enter(0x10)

@4,080,453us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc> return
(0x60fb0)

@4,080,628us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf>
returning: cb->phys=0x8c9ba000,

cb->size=28, cb->virt=0x4144b000

@4,080,810us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc>
return (0x4144b000)

@4,081,014us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc>
Enter(size=32, align=-1, cached=FA

LSE, heap=FALSE)

@4,081,323us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc>
CMEM_alloc(32) = 0x41458000.

@4,081,570us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc>
CMEM_getPhys(0x41458000) = 0x8c9ad

000.

@4,081,763us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf>
Enter(virtAddr=0x41458000, size=

32, physAddr=0x8c9ad000)

@4,081,953us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf>
creating new contigBuf object

@4,082,119us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc>
Enter(0x10)

@4,082,348us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc> return
(0x620b0)

@4,082,535us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf>
returning: cb->phys=0x8c9ad000,

cb->size=32, cb->virt=0x41458000

@4,082,729us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc>
return (0x41458000)

MAC: 00:13:23:04:13:46 USN: 970041346

@4,349,545us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC -
VIDENC_control> Enter (handle=0x62

058, id=41216, params=0xbe3fedb8, status=0xbe3fed28

@4,349,833us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

0008

@4,350,045us: [+0 T:0x00008003 S:0xbe3fe9c4] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

0020008, command=0x1

@4,350,250us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

@4,350,512us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> return (0)

@4,350,710us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3fea24, timeout

=-1)

@4,351,302us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@4,351,574us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@4,351,839us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> return (0)

@4,352,129us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3fe9a0, timeout

=-1)

@4,352,373us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

[DSP] @5,647,854tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
0x882ab0b0(vca_stab#0) call(algHandle=0x88

2ab168, msg=0x88106c80); messageId=0x00020008

[DSP] @5,647,953tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

e=0x882ab168, id=41216, params=0x88106cb4, status=0x88106cfc

[DSP] @5,648,057tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

198

[DSP] @5,648,128tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

andle=0x882ab198)

[DSP] @5,648,202tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

[DSP] @5,648,776tk: [+0 T:0x8892e644 S:0x88932504] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

Bytes=1008)

[DSP] @5,648,876tk: [+0 T:0x8892e644 S:0x88932504] OM -
Memory_cacheWbInv> return

[DSP] @5,648,930tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

98

[DSP] @5,649,005tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

(handle=0x882ab198)

[DSP] @5,649,084tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

n

[DSP] @5,649,150tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

=0x882ab168, retVal=0x0)

[DSP] @5,649,235tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned
from call(algHandle=0x882ab168, m

sg=0x88106c80); messageId=0x00020008

[DSP] @5,650,934tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

[DSP] @5,651,005tk: [+0 T:0x8880006c S:0x88804024] CR - remote time =
0x0, trace buffer size = 4032

@4,359,446us: [+0 T:0x00008003 S:0xbe3fe944] CE - Engine_fwriteTrace>
returning count [1651]

@4,359,654us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call Completed:
messageId=0x00020008, command=0x1

, return(status=0)

@4,359,857us: [+5 T:0x00008003 S:0xbe3fe9d4] CV - VISA_freeMsg(0x62058,
0x413dcc80): Freeing message wit

h messageId=0x00020008

@4,360,055us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC -
VIDENC_control> Exit (handle=0x620

58, retVal=0x0)

@4,360,248us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC -
VIDENC_control> Enter (handle=0x62

058, id=41217, params=0xbe3fec28, status=0xbe3fed28

@4,360,484us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

0009

@4,360,680us: [+0 T:0x00008003 S:0xbe3fe9c4] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

0020009, command=0x1

@4,360,873us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

@4,361,117us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> return (0)

@4,361,309us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3fea24, timeout

=-1)

@4,366,972us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@4,367,246us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@4,787,772us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> return (0)

@4,788,103us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3fe9a0, timeout

=-1)

@4,788,354us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

[DSP] @5,672,464tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
0x882ab0b0(vca_stab#0) call(algHandle=0x88

2ab168, msg=0x88106c80); messageId=0x00020009

[DSP] @5,672,568tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

e=0x882ab168, id=41217, params=0x88106cb4, status=0x88106db0

[DSP] @5,672,674tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

198

[DSP] @5,672,747tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

andle=0x882ab198)

[DSP] @5,672,827tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

[DSP] @5,685,069tk: [+0 T:0x8892e644 S:0x88932494] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

Bytes=1008)

[DSP] @5,685,193tk: [+0 T:0x8892e644 S:0x88932494] OM -
Memory_cacheWbInv> return

[DSP] @5,685,259tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

98

[DSP] @5,685,335tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

(handle=0x882ab198)

[DSP] @5,685,417tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

n

[DSP] @5,685,488tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

=0x882ab168, retVal=0x0)

[DSP] @5,685,621tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned
from call(algHandle=0x882ab168, m

sg=0x88106c80); messageId=0x00020009

[DSP] @6,662,444tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

[DSP] @6,662,522tk: [+0 T:0x8880006c S:0x88804024] CR - remote time =
0x0, trace buffer size = 4032

@4,795,428us: [+0 T:0x00008003 S:0xbe3fe944] CE - Engine_fwriteTrace>
returning count [1651]

@4,795,640us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call Completed:
messageId=0x00020009, command=0x1

, return(status=0)

@4,795,851us: [+5 T:0x00008003 S:0xbe3fe9d4] CV - VISA_freeMsg(0x62058,
0x413dcc80): Freeing message wit

h messageId=0x00020009

@4,796,075us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC -
VIDENC_control> Exit (handle=0x620

58, retVal=0x0)

@4,796,289us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC -
VIDENC_control> Enter (handle=0x62

058, id=41218, params=0xbe3fec28, status=0xbe3feac0

@4,796,501us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

000a

@4,796,692us: [+0 T:0x00008003 S:0xbe3fe9c4] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

002000a, command=0x1

@4,796,891us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

@4,797,345us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> return (0)

@4,797,723us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3fea24, timeout

=-1)

@4,798,173us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

@4,798,433us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put>
Enter(queue=0x0, msg=0x413dbc80)

@4,798,694us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> return (0)

@4,799,015us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get>
Enter(queue=0x10000, msg=0xbe3fe9a0, timeout

=-1)

@4,799,256us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> MSGQ_Get()
status=0x8000, return (0)

[DSP] @6,684,637tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE>
0x882ab0b0(vca_stab#0) call(algHandle=0x88

2ab168, msg=0x88106c80); messageId=0x0002000a

[DSP] @6,684,743tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

e=0x882ab168, id=41218, params=0x88106cb4, status=0x88106db0

[DSP] @6,684,853tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

198

[DSP] @6,684,927tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

andle=0x882ab198)

[DSP] @6,685,011tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

[DSP] @6,685,660tk: [+0 T:0x8892e644 S:0x88932504] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

Bytes=1008)

[DSP] @6,685,789tk: [+0 T:0x8892e644 S:0x88932504] OM -
Memory_cacheWbInv> return

[DSP] @6,685,848tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

98

[DSP] @6,685,921tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

(handle=0x882ab198)

[DSP] @6,686,001tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

n

[DSP] @6,686,067tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

=0x882ab168, retVal=0x0)

[DSP] @6,686,152tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned
from call(algHandle=0x882ab168, m

sg=0x88106c80); messageId=0x0002000a

[DSP] @6,687,790tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

[DSP] @6,687,860tk: [+0 T:0x8880006c S:0x88804024] CR - remote time =
0x0, trace buffer size = 4032

@5,146,922us: [+0 T:0x00008003 S:0xbe3fe944] CE - Engine_fwriteTrace>
returning count [1651]

@5,147,356us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call Completed:
messageId=0x0002000a, command=0x1

, return(status=0)

@5,147,728us: [+5 T:0x00008003 S:0xbe3fe9d4] CV - VISA_freeMsg(0x62058,
0x413dcc80): Freeing message wit

h messageId=0x0002000a

@5,147,971us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC -
VIDENC_control> Exit (handle=0x620

58, retVal=0x0)

@5,174,837us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC -
VIDENC_process> Enter (handle=0x62

058, inBufs=0xbe3ffac0, outBufs=0xbe3ffab0, inArgs=0xbe3ff8fc,
outArgs=0xbe3ffa10)

@5,175,123us: [+5 T:0x00008003 S:0xbe3ff7fc] CV - VISA_allocMsg>
Allocating message for messageId=0x0002

000b

@5,175,328us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x404c

9000, size=884736)

@5,175,514us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x404c9000,

 size=884736)

@5,175,692us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> found in cb(Sc=0x404c9000,

 Ec=0x405a1000, Ss=0x404c9000, Es=0x405a1000, PSc=0x8cac7000)

@5,175,934us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> returning physAddr=0x8cac7

000

@5,176,105us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> return (0x8cac7000)

@5,176,280us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4145

8000, size=32)

@5,176,450us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x41458000,

 size=32)

@5,176,621us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> found in cb(Sc=0x41458000,

 Ec=0x41458020, Ss=0x41458000, Es=0x41458020, PSc=0x8c9ad000)

@5,176,811us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> returning physAddr=0x8c9ad

000

@5,176,980us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> return (0x8c9ad000)

@5,177,150us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x407c

9000, size=884736)

@5,177,369us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x407c9000,

 size=884736)

@5,177,545us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> found in cb(Sc=0x407c9000,

 Ec=0x408a1000, Ss=0x407c9000, Es=0x408a1000, PSc=0x8fc94000)

@5,177,918us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> returning physAddr=0x8fc94

000

@5,178,105us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> return (0x8fc94000)

@5,178,281us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4144

b000, size=28)

@5,178,460us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x4144b000,

 size=28)

@5,178,664us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> found in cb(Sc=0x4144b000,

 Ec=0x4144b01c, Ss=0x4144b000, Es=0x4144b01c, PSc=0x8c9ba000)

@5,520,076us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> returning physAddr=0x8c9ba

000

@5,520,313us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> return (0x8c9ba000)

@5,520,501us: [+0 T:0x00008003 S:0xbe3ff80c] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

002000b, command=0x0

@5,520,695us: [+0 T:0x00008003 S:0xbe3ff7dc] OC - Comm_put>
Enter(queue=0x2, msg=0x413dcc80)

@5,520,929us: [+0 T:0x00008003 S:0xbe3ff7dc] OC - Comm_put> return (0)

@5,521,114us: [+0 T:0x00008003 S:0xbe3ff7d4] OC - Comm_get>
Enter(queue=0x10001, msg=0xbe3ff87c, timeout

=-1)

 

 

After this it locks up and never returns control to the ARM after the
VIDENC_process() call.

 

It looks like its locking up inside the Codec Engine after returning
from the DSP side process call.

 

Can anyone shed some light on whats going wrong?

 

 

Regards,

Etienne Eccles

 

VCA Technology

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100413/112ec7a5/attachment-0001.html>

From cring at ti.com  Wed Apr 14 11:32:29 2010
From: cring at ti.com (Ring, Chris)
Date: Wed, 14 Apr 2010 11:32:29 -0500
Subject: Codec engine lockup
In-Reply-To: <95FAFD227E8A2947BA96E1C807505D0412CD67@sbs001.office.local>
References: <95FAFD227E8A2947BA96E1C807505D0412CD5F@sbs001.office.local>
	<92CDD168D1E81F4F9D3839DC45903FC676C07D7E@dlee03.ent.ti.com>
	<95FAFD227E8A2947BA96E1C807505D0412CD67@sbs001.office.local>
Message-ID: <92CDD168D1E81F4F9D3839DC45903FC676C834C2@dlee03.ent.ti.com>

After your process() fxn, the call flow returns into the VIDENC skeleton.  (You can find the sources in packages/ti/sdo/ce/video/videnc_skel.c)

There's basically some cache calls (your outbuf and outArgs->reconBufs buffer descriptors are correct, right?), and the skeleton's call() method returns.  After that, CE will send the "I'm done" reply msg to the ARM.  This reply will unblock the ARM side (which is what we're _not_ seeing).

Another thing to try is to link in the CE debug libs (when building your Server) which will let you step through the DSP-side CE code after your process() call returns.  How to link in debug libs unfortunately changes a little from release to release - I think in CE 2.10.02, you would set the following line in your Server's package.bld build script:

   Pkg.attrs.profile = "debug";

You can sanity check that you're linking in the debug libs as you'll see output during build like:

    will link with ti.sdo.ce.video:lib/debug/video.a64P
Chris

________________________________
From: Etienne Eccles [mailto:Etienne.Eccles at vcatechnology.com]
Sent: Wednesday, April 14, 2010 1:59 AM
To: Ring, Chris; davinci-linux-open-source at linux.davincidsp.com
Subject: RE: Codec engine lockup

Hi Chris

Thanks for the reply.
I have actually done what you suggested, and I can see that the DSP side process call completes successfully and returns. I have even gone so far as to remove the entire body of DSP side process function and immediately return with IALG_EOK.  That's why I suspected it must be locking up in the codec engine after completing the DSP side process.

This lock up  problem is also not repeatable. It only occurs on about 20% of hardware examples and under certain booting conditions

Etienne

From: Ring, Chris [mailto:cring at ti.com]
Sent: 13 April 2010 18:57
To: Etienne Eccles; davinci-linux-open-source at linux.davincidsp.com
Subject: RE: Codec engine lockup

The last line is an ARM-side Comm_get() call (implemented with MSGQ_get()) - which blocks until the DSP finishes it's job and sends an 'I'm done' reply message.  Basically, you've sent a request to VIDENC_process() a frame which never returns.  The DSP is hanging/crashing/waiting and never returning "I'm done" to the ARM.

Can you connect to CCS and see what's happening on the DSP side?  Since this is your codec, maybe set breakpoints in your process() method and see if it ever gets called.

http://wiki.davincidsp.com/index.php/Debugging_the_DSP_side_of_a_CE_application_using_CCS

Chris

________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Etienne Eccles
Sent: Tuesday, April 13, 2010 5:39 AM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: Codec engine lockup

H


I am getting the following debug output . using CE_DEBUG=3 when creating and using a custom VIDENC codec:



root at nvc1346:/opt/davinci# CE_DEBUG=3 ./stabd -d -p a
root at nvc1346:/opt/davinci# @0,196,096us: [+4 T:0x00004000 S:0xbec8cbbc] OG - Global_init> This program w
as built with the following packages:
@0,197,108us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package gnu.targets.rts470MV (/home/vcastab/svn/ud
p/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/gnu/targets/rts470MV/) [1,0,0,0,1203621000516]
@0,197,334us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package dsplink.gpp (/home/vcastab/svn/udp/linux/d
vsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/dsplink/gpp/) [3,0,0]
@0,197,516us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.xdais.dm (/home/vcastab/svn/udp/linux/d
vsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/dm/) [1,0,4,1210262746529]
@0,197,948us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.xdais (/home/vcastab/svn/udp/linux/dvsd
k/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/) [1,2,1,1210262742149]
@0,198,149us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.utils.trace (/home/vcastab/svn/udp/
linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/utils/trace/) [1,0,0,122094336
6422]
@0,198,331us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.utils.xdm (/home/vcastab/svn/udp
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/utils/xdm/) [1,0,1,1220951322616]
@0,198,510us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.fc.dman3 (/home/vcastab/svn/udp/lin
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/fc/dman3/) [1,0,3,1220943053023]
@0,198,682us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.fc.acpy3 (/home/vcastab/svn/udp/lin
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/fc/acpy3/) [1,0,2,1220943014135]
@0,198,852us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.linuxutils.cmem (/home/vcastab/svn/
udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/linuxutils/cmem/) [2,0,1,1
204929560755]
@0,199,030us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.catalog.c470 (/home/vcastab/svn/udp/lin
ux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/catalog/c470/) [1,0,1,0,1203561761475]
@0,199,200us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.platforms.evmDM6446 (/home/vcastab/svn/
udp/linux/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/platforms/evmDM6446/) [1,0,0,1,1192229600615]
@0,199,369us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.osal (/home/vcastab/svn/udp/linu
x/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/osal/) [2,0,2,1220951127739]
@0,199,539us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.ipc (/home/vcastab/svn/udp/linux
/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/) [2,0,1,1220951085787]
@0,199,704us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.alg (/home/vcastab/svn/udp/linux
/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/alg/) [1,0,1,1220950781938]
@0,199,875us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.osal.linux (/home/vcastab/svn/ud
p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/osal/linux/) [2,0,1,1220951140072
]
@0,200,049us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.ipc.dsplink (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/dsplink/) [2,0,1,12209510968
18]
@0,200,219us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce (/home/vcastab/svn/udp/linux/dvs
dk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/) [1,0,6,1220950771473]
@0,200,386us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.video (/home/vcastab/svn/udp/lin
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/video/) [1,0,3,1220951334122]
@0,200,559us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package codecs.vca_stab (/home/vcastab/svn/vt/davi
nci/trunk/ce1/codecs/vca_stab/) []
@0,200,718us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.bioslog (/home/vcastab/svn/udp/l
inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/bioslog/) [1,0,1,1220950800329]
@0,587,586us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.utils.trace (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/utils/trace/) [1,0,1,12209513170
87]
@0,587,929us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package apps.stab_client (/home/vcastab/svn/vt/dav
inci/trunk/ce1/apps/stab_client/) []
@0,588,146us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x20028)
@0,588,352us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x1f4c0)
@0,588,676us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> Enter(0x18)
@0,589,026us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return (0x5e138)
@0,589,716us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit> enter (fxn=0x1dda8)
@0,590,050us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> Enter(0x18)
@0,590,269us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return (0x5e188)
@0,590,492us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit> enter (fxn=0x1b9f4)
@0,590,839us: [+0 T:0x00004000 S:0xbec8cbbc] OG - Global_atexit> enter (fxn=0x1eb44)
@0,593,794us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem - Sem_create> count: 0
@0,594,023us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> Enter(0x14)
@0,594,212us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> return (0x5e208)
@0,594,470us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x5e208]
@0,594,698us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem - Sem_create> count: 0
@0,594,859us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> Enter(0x14)
@0,595,056us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> return (0x5e220)
@0,595,220us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x5e220]
@0,595,378us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> Enter(0x18)
@0,595,544us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> return (0x5e238)
@0,595,707us: [+0 T:0x00004000 S:0xbec8cb8c] OT - Thread_create> Enter (fxn=0x1ab34, attrs=0x0)
@0,595,869us: [+0 T:0x00004000 S:0xbec8cb74] OM - Memory_alloc> Enter(0x64)
@0,596,064us: [+0 T:0x00004000 S:0xbec8cb74] OM - Memory_alloc> return (0x5e258)
@0,598,964us: [+1 T:0x00004002 S:0xbe5ffa74] OP - daemon> thread created.
@0,599,205us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d> Enter (proc=0xbe5ffaec)
@0,599,387us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem - Entered Sem_pend> sem[0x5e208] timeout
[0xffffffff]
@0,599,998us: [+0 T:0x00004000 S:0xbec8cb8c] OT - Thread_create> Exit (task=0x5e258)
@0,600,235us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x1a6f4)
@0,600,501us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x1c7e8)
@0,600,791us: [+0 T:0x00004000 S:0xbec8cbac] ti.sdo.ce.alg - ALG_init> Enter
@0,600,984us: [+0 T:0x00004000 S:0xbec8cb9c] OG - Global_atexit> enter (fxn=0x209f0)
@0,601,171us: [+0 T:0x00004000 S:0xbec8cbcc] ti.sdo.ce.alg - ALG_init> Exit
@0,601,339us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x20490)
@0,601,541us: [+0 T:0x00004000 S:0xbec8cb9c] OM - Memory_alloc> Enter(0x18)
@0,601,767us: [+0 T:0x00004000 S:0xbec8cb9c] OM - Memory_alloc> return (0x60418)
@0,601,955us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x1eca8)
@0,602,262us: [+6 T:0x00004000 S:0xbec8cbc4] CE - Engine_init> CE debugging on (CE_DEBUG=3; allowed CE_D
EBUG levels: 1=min, 2=good, 3=max)
@0,602,481us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit> enter (fxn=0x17734)
@0,602,667us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> Enter(0x18)
@0,602,852us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return (0x60458)
@0,603,024us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> Enter(0x18)
@0,603,247us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return (0x60478)
@0,603,423us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> Enter(0x18)
@0,603,600us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return (0x60498)
@0,944,735us: [+0 T:0x00004000 S:0xbec8cbc4] CS - Server_init()
@0,944,957us: [+0 T:0x00004000 S:0xbec8cbc4] CS - Server_init> Global_useLinkArbiter = 0
@0,945,138us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x16284)
@0,945,529us: [+0 T:0x00004000 S:0xbec8cbd4] OG - Global_atexit> enter (fxn=0x14148)
@0,945,950us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@0,946,486us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x403ee000.
@0,946,744us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x403ee000) = 0x8ff25
000.
@0,946,938us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x403ee000, size=
884736, physAddr=0x8ff25000)
@0,947,127us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@0,947,319us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@0,947,514us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60518)
@0,947,842us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8ff25000,
cb->size=884736, cb->virt=0x403ee000
@0,948,044us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x403ee000)
@0,948,270us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@0,948,643us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x404c9000.
@0,948,931us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x404c9000) = 0x8cac7
000.
@0,949,123us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x404c9000, size=
884736, physAddr=0x8cac7000)
@0,949,305us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@0,949,467us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@0,949,651us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60530)
@0,949,823us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8cac7000,
cb->size=884736, cb->virt=0x404c9000
@0,950,004us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x404c9000)
@0,950,206us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@0,950,595us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x405c9000.
@0,950,841us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x405c9000) = 0x8c9c7
000.
@0,951,032us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x405c9000, size=
884736, physAddr=0x8c9c7000)
@0,951,219us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@0,951,380us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@0,951,592us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60548)
@0,951,775us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8c9c7000,
cb->size=884736, cb->virt=0x405c9000
@0,951,959us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x405c9000)
@0,952,125us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@0,952,475us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x406c9000.
@0,952,718us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x406c9000) = 0x8c879
000.
@0,952,911us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x406c9000, size=
884736, physAddr=0x8c879000)
@0,953,145us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@0,953,310us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@0,953,490us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60560)
@1,294,466us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8c879000,
cb->size=884736, cb->virt=0x406c9000
@1,294,700us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x406c9000)
@1,294,877us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@1,295,385us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x407c9000.
@1,295,626us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x407c9000) = 0x8fc94
000.
@1,295,850us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x407c9000, size=
884736, physAddr=0x8fc94000)
@1,296,040us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@1,296,206us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@1,296,387us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60578)
@1,296,557us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8fc94000,
cb->size=884736, cb->virt=0x407c9000
@1,296,739us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x407c9000)
@1,296,908us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@1,297,589us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x40a5a000.
@1,298,146us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x40a5a000) = 0x8f8de
000.
@1,298,345us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x40a5a000, size=
884736, physAddr=0x8f8de000)
@1,298,538us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@1,298,750us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@1,298,934us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60590)
@1,299,106us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8f8de000,
cb->size=884736, cb->virt=0x40a5a000
@1,299,290us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x40a5a000)
@1,309,917us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - Engine_open> Enter('vca_engine', 0x0, 0xbe3ffa84)
@1,310,205us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc> Enter(0x2c)
@1,310,419us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc> return (0x605a8)
@1,310,604us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - rserverOpen('./server_release.x64P'), count = 0
@1,310,785us: [+0 T:0x00008003 S:0xbe3ff9ac] OP - Processor_create> Enter(imageName='./server_release.x6
4P', linkCfg='(null)', attrs=0xbe3ffa30)
@1,312,833us: [+0 T:0x00008003 S:0xbe3ff994] OM - Memory_alloc> Enter(0x24)
@1,313,100us: [+0 T:0x00008003 S:0xbe3ff994] OM - Memory_alloc> return (0x605d8)
@1,313,292us: [+0 T:0x00008003 S:0xbe3ff98c] OP - doCmd> Enter (cmdId=1, proc=0x605d8)
@1,313,470us: [+0 T:0x00008003 S:0xbe3ff97c] ti.sdo.ce.osal.Sem - Entered Sem_post> sem[0x5e208]
@1,313,801us: [+0 T:0x00008003 S:0xbe3ff98c] ti.sdo.ce.osal.Sem - Leaving Sem_post> sem[0x5e208]
@1,314,019us: [+0 T:0x00008003 S:0xbe3ff96c] ti.sdo.ce.osal.Sem - Entered Sem_pend> sem[0x5e220] timeout
[0xffffffff]
@1,314,506us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem - Leaving Sem_pend> sem[0x5e208] status[
0]
@1,314,978us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d> Exit (result=1)
@1,315,460us: [+0 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Enter(proc=0x605d8)
@1,315,900us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Initializing DSP PROC...
@1,316,335us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Using DspLink config data for entr
y #0 [server './server_release.x64P']
@1,316,786us: [+0 T:0x00004002 S:0xbe5ffa5c] OM - Memory_alloc> Enter(0xe0)
@1,317,458us: [+0 T:0x00004002 S:0xbe5ffa5c] OM - Memory_alloc> return (0x60600)
@1,318,325us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Adding DSP segment #0 to Link conf
iguration: name='DDR', startAddress=0x88200000, sizeInBytes=0x400000, shared=1
@1,660,152us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Adding DSP segment #1 to Link conf
iguration: name='DSPLINKMEM', startAddress=0x88100000, sizeInBytes=0x100000, shared=1
@1,660,412us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Adding DSP segment #2 to Link conf
iguration: name='RESET_VECTOR', startAddress=0x88000000, sizeInBytes=0x80, shared=0
@1,660,650us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Adding DSP segment #3 to Link conf
iguration: name='DDRALGHEAP', startAddress=0x88800000, sizeInBytes=0x1c00000, shared=0
@1,660,856us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> DOPOWERCONTROL was=0; now=0
SET WIDTH to 720 HEIGHT to 576
@1,685,617us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Attaching to DSP PROC...
@1,698,711us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Opening MSGQ pool...
@1,699,722us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Loading ./server_release.x64P on D
SP (1 args)...
@1,892,865us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Starting DSP PROC...
@1,916,709us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Opening remote transport...
@1,917,511us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> return (1)
@1,918,475us: [+0 T:0x00004002 S:0xbe5ffa64] ti.sdo.ce.osal.Sem - Entered Sem_post> sem[0x5e220]
@1,918,948us: [+0 T:0x00008003 S:0xbe3ff96c] ti.sdo.ce.osal.Sem - Leaving Sem_pend> sem[0x5e220] status[
0]
@1,919,260us: [+0 T:0x00008003 S:0xbe3ff98c] OP - doCmd> Exit (result=1)
@1,919,438us: [+0 T:0x00008003 S:0xbe3ff9ac] OP - Processor_create> return (0x605d8)
@1,919,611us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - rserverOpen('./server_release.x64P'): 0x5701c done.
@1,919,799us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc> Enter(0x1e)
@1,919,990us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc> return (0x61fd0)
@1,920,188us: [+0 T:0x00008003 S:0xbe3ff9bc] OC - Comm_create> Enter(queueName='vca_engine_0', queue=0x6
05b8, attrs=0x0)
@1,920,370us: [+0 T:0x00008003 S:0xbe3ff9a4] OM - Memory_alloc> Enter(0x4)
@1,920,579us: [+0 T:0x00008003 S:0xbe3ff9a4] OM - Memory_alloc> return (0x61ff8)
@1,921,144us: [+0 T:0x00008003 S:0xbe3ff9bc] OC - Comm_create> return (0x61ff8)
@1,921,384us: [+0 T:0x00008003 S:0xbe3ff9bc] OM - Memory_free> Enter(0x61fd0, 0x1e)
@1,921,582us: [+0 T:0x00008003 S:0xbe3ff9bc] OM - Memory_free> return (0x1)
@1,921,758us: [+0 T:0x00008003 S:0xbe3ff9c4] OC - Comm_alloc> Enter(poolId=0x0, msg=0x605c4, size=576)
@1,921,990us: [+0 T:0x00008003 S:0xbe3ff9c4] OC - Comm_alloc> msg=0x413dbc80, returning (0)
@1,922,187us: [+0 T:0x00008003 S:0xbe3ff9a4] OC - Comm_locate> Enter(queueName='rmsq', queue=0x605b4)
@1,931,192us: [+0 T:0x00008003 S:0xbe3ff9a4] OC - Comm_locate> return (0)
@1,931,465us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - checkServer(0x605a8)
@1,931,739us: [+0 T:0x00008003 S:0xbe3ff9b4] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@1,932,050us: [+0 T:0x00008003 S:0xbe3ff9b4] OC - Comm_put> return (0)
@1,932,339us: [+0 T:0x00008003 S:0xbe3ff9ac] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ffa28, timeout
=-1)
@1,932,567us: [+0 T:0x00008003 S:0xbe3ff9ac] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@1,932,768us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - rmsInit> RMS initialized(0x605a8); CE_DEBUG on, settin
g DSP trace mask to *+01234567,GT_prefix=12345,GT_time=3
@1,932,966us: [+0 T:0x00008003 S:0xbe3ff9b4] CE - Engine_setTrace> Enter(engine=0x605a8, mask='*+0123456
7,GT_prefix=12345,GT_time=3')
@1,933,180us: [+1 T:0x00008003 S:0xbe3ff9b4] CE - Engine_setTrace> Requesting DSP set trace ...
@1,933,348us: [+0 T:0x00008003 S:0xbe3ff984] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@1,933,635us: [+0 T:0x00008003 S:0xbe3ff984] OC - Comm_put> return (0)
@1,933,821us: [+0 T:0x00008003 S:0xbe3ff97c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff9ec, timeout
=-1)
@1,934,437us: [+0 T:0x00004002 S:0xbe5ffa74] ti.sdo.ce.osal.Sem - Leaving Sem_post> sem[0x5e220]
@1,934,692us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d> Enter (proc=0xbe5ffaec)
@1,934,920us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem - Entered Sem_pend> sem[0x5e208] timeout
[0xffffffff]
@1,937,498us: [+0 T:0x00008003 S:0xbe3ff97c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@1,937,904us: [+0 T:0x00008003 S:0xbe3ff9b4] CE - Engine_setTrace> return(0)
@1,938,126us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@1,938,384us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put> return (0)
@1,938,673us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff9d0, timeout
=-1)
@1,938,903us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @0x00000208:[T:0x00000000] ZZ - main> Welcome to loopback server's main().
[DSP] @0x0000086c:[T:0x8880415c] LS - server()
[DSP] @0x0000088d:[T:0x8880415c] OM - Memory_alloc> Enter(size=0x24)
[DSP] @0x000008b8:[T:0x8880415c] OM - Memory_alloc> return (0x882ab060)
[DSP] @0x000008e6:[T:0x8880415c] LS - server: serverMsgQueue = 0x00000001
[DSP] @0x0000090f:[T:0x8880415c] LS - server: waiting for cmd
[DSP] @0x00008cc2:[T:0x8880006c] CR - processRmsCmd(0x88105ca8, 4056): cmd = 6
[DSP] @0x00009b1c:[T:0x8880006c] CR - processRmsCmd(0x88105ca8, 4056): cmd = 8
[DSP] @0x00009b50:[T:0x8880006c] CR - setting trace mask to *+01234567,GT_prefix=12345,GT_time=3
[DSP] @0,039,852tk: [+0 T:0x8880006c S:0x88803fdc] OG - Global_setSpecialTrace> enter(mask='*+01234567,G
T_prefix=12345,GT_time=3')
[DSP] @0,039,938tk: [+4 T:0x8880006c S:0x88803fdc] OG - Global_setSpecialTrace> This program was built w
ith the following packages:
[DSP] @0,040,015tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.targets.rts6000 (/home/vcastab/sv
n/udp/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/targets/rts6000/) [1,0,0,0,1203621186754]
[DSP] @0,040,139tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.fc.dman3 (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/fc/dman3/) [1,0,3,122094305
3023]
[DSP] @0,040,255tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.rtdx (/home/vcastab/svn/udp/linux
/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/rtdx/) [2,0,0,1,1194024051755]
[DSP] @0,040,356tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.psl (/home/vcastab/svn/udp/linux/
dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/psl/) [5,0,0,0,0]
[DSP] @0,040,451tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.bios (/home/vcastab/svn/udp/linux
/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/bios/) [5,2,4,9,1193960176642]
[DSP] @0,040,552tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.fc.dskt2 (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/fc/dskt2/) [1,0,4,122094309
5081]
[DSP] @0,040,668tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.xdais.dm (/home/vcastab/svn/udp/l
inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/dm/) [1,0,4,1210262746529]
[DSP] @0,040,781tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.xdais (/home/vcastab/svn/udp/linu
x/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/) [1,2,1,1210262742149]
[DSP] @0,040,890tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.node (/home/vcastab/svn/ud
p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/node/) [1,0,0,1220951122176]
[DSP] @0,041,001tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.ipc.dsplink.dsp (/home/vca
stab/svn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/dsplink/dsp/) [2,0
,1,1220951102696]
[DSP] @0,041,122tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.utils.trace (/home/vcastab/sv
n/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/utils/trace/) [1,0,0,122
0943366422]
[DSP] @0,041,242tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.utils.xdm (/home/vcastab/s
vn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/utils/xdm/) [1,0,1,122095132
2616]
[DSP] @0,041,357tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.fc.acpy3 (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/fc/acpy3/) [1,0,2,122094301
4135]
[DSP] @0,041,473tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package dsplink.dsp (/home/vcastab/svn/udp/l
inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/dsplink/dsp/) [1,3,0]
[DSP] @0,041,578tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.bios.utils (/home/vcastab/svn/udp
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/bios/utils/) [2,0,1,0,11918918306
09]
[DSP] @0,041,693tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.catalog.c6000 (/home/vcastab/svn/
udp/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/catalog/c6000/) [1,0,0,0,1203561781695]
[DSP] @0,041,802t at 2,297,823us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put> Enter(queue=0x0, msg=0x413d
bc80)
@2,298,120us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put> return (0)
@2,298,417us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff9d0, timeout
=-1)
@2,298,649us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
k: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.platforms.evmDM6446 (/home/vcastab/svn/udp/linux/d
vsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/platforms/evmDM6446/) [1,0,0,1,1192229600615]
[DSP] @0,041,919tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.osal (/home/vcastab/svn/ud
p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/osal/) [2,0,2,1220951127739]
[DSP] @0,042,030tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.ipc (/home/vcastab/svn/udp
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/) [2,0,1,1220951085787]
[DSP] @0,042,139tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.alg (/home/vcastab/svn/udp
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/alg/) [1,0,1,1220950781938]
[DSP] @0,042,249tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.osal.bios (/home/vcastab/s
vn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/osal/bios/) [2,0,1,122095113
3740]
[DSP] @0,042,365tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.ipc.bios (/home/vcastab/sv
n/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/bios/) [2,0,1,12209510910
97]
[DSP] @0,042,487tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce (/home/vcastab/svn/udp/lin
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/) [1,0,6,1220950771473]
[DSP] @0,042,593tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.bioslog (/home/vcastab/svn
/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/bioslog/) [1,0,1,1220950800329
]
[DSP] @0,042,706tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.video (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/video/) [1,0,3,1220951334122]
[DSP] @0,042,818tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package codecs.vca_stab (/home/vcastab/svn/v
t/davinci/trunk/ce1/codecs/vca_stab/) []
[DSP] @0,042,901tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package servers.vca_stab_server (/home/vcast
ab/svn/vt/davinci/trunk/ce1/servers/vca_stab_server/) []
[DSP] @0,042,992tk: [+0 T:0x8880006c S:0x88803fdc] OG - Global_setSpecialTrace> return
[DSP] @0,050,728tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @0,050,799tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
[DSP] @0,885,481tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @0,885,547tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@2,650,231us: [+0 T:0x00008003 S:0xbe3ff974] CE - Engine_fwriteTrace> returning count [6828]
@2,650,445us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - Engine_open> return(394664)
@2,650,660us: [+0 T:0x00008003 S:0xbe3ffa34] ti.sdo.ce.video.VIDENC - VIDENC_create> Enter (engine=0x605
a8, name='vca_stab', params=0xbe3ffa88)
@2,650,896us: [+0 T:0x00008003 S:0xbe3ffa04] CV - VISA_create(0x605a8, 'vca_stab', 0xbe3ffa88, 0x828, 't
i.sdo.ce.video.IVIDENC')
@2,651,104us: [+0 T:0x00008003 S:0xbe3ff92c] CV - VISA_create2(0x605a8, 'vca_stab', 0xbe3ffa88, 0x2c, 0x
828, 'ti.sdo.ce.video.IVIDENC')
@2,651,363us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc> Enter(0x30)
@2,651,589us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc> return (0x62058)
@2,651,782us: [+0 T:0x00008003 S:0xbe3ff8bc] CE - Engine_createNode(0x605a8, 'vca_stab', 828, 0xbe3ffa88
, 0x2c, 0xbe3ffa30)
@2,651,980us: [+0 T:0x00008003 S:0xbe3ff8a4] OM - Memory_alloc> Enter(0x20)
@2,652,163us: [+0 T:0x00008003 S:0xbe3ff8a4] OM - Memory_alloc> return (0x61fd0)
@2,652,361us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_create> Enter(queueName='gppfromnode_1', queue=0x
61fd8, attrs=0x0)
@2,652,545us: [+0 T:0x00008003 S:0xbe3ff87c] OM - Memory_alloc> Enter(0x4)
@2,652,730us: [+0 T:0x00008003 S:0xbe3ff87c] OM - Memory_alloc> return (0x62090)
@2,993,385us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_create> return (0x62090)
@2,993,649us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@2,993,987us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put> return (0)
@2,994,199us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff914, timeout
=-1)
@3,010,127us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@3,010,439us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@3,010,710us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put> return (0)
@3,010,993us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff914, timeout
=-1)
@3,011,253us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@3,011,492us: [+4 T:0x00008003 S:0xbe3ff8bc] CE - Engine_createNode> created node(stdIn=0x2, stdOut=0x10
001, msgq=0x62090, algName='vca_stab', rmsNode=0x882ab088, algHandle=0x882ab168)
@3,011,735us: [+0 T:0x00008003 S:0xbe3ff81c] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@3,011,981us: [+0 T:0x00008003 S:0xbe3ff81c] OC - Comm_put> return (0)
@3,012,254us: [+0 T:0x00008003 S:0xbe3ff814] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff8a8, timeout
=-1)
@3,012,488us: [+0 T:0x00008003 S:0xbe3ff814] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @2,500,228tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 0
[DSP] @2,500,305tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc> Enter(size=0x18)
[DSP] @2,500,365tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc> return (0x882ab088)
[DSP] @2,500,425tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc> Enter(size=0xb)
[DSP] @2,500,480tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc> return (0x882ab0a0)
[DSP] @2,500,549tk: [+0 T:0x8880006c S:0x88803edc] OM - Memory_alloc> Enter(size=0x20)
[DSP] @2,500,605tk: [+0 T:0x8880006c S:0x88803edc] OM - Memory_alloc> return (0x882ab0b0)
[DSP] @2,500,665tk: [+0 T:0x8880006c S:0x88803eac] OM - Memory_alloc> Enter(size=0x24)
[DSP] @2,500,722tk: [+0 T:0x8880006c S:0x88803eac] OM - Memory_alloc> return (0x882ab0d0)
[DSP] @2,500,806tk: [+0 T:0x8880006c S:0x88803ec4] ti.sdo.ce.video.VIDENC - VIDENC_create> Enter (engine
=0x0, name='vca_stab', params=0x88105cc0)
[DSP] @2,500,902tk: [+0 T:0x8880006c S:0x88803e8c] CV - VISA_create(0x0, 'vca_stab', 0x88105cc0, 0x828,
'ti.sdo.ce.video.IVIDENC')
[DSP] @2,500,988tk: [+0 T:0x8880006c S:0x88803d7c] CV - VISA_create2(0x0, 'vca_stab', 0x88105cc0, 0x2c,
0x828, 'ti.sdo.ce.video.IVIDENC')
[DSP] @2,501,089tk: [+0 T:0x8880006c S:0x88803d14] CE - Engine_open> Enter('local', 0x88803d6c, 0x33c)
[DSP] @2,501,158tk: [+0 T:0x8880006c S:0x88803cf4] OM - Memory_alloc> Enter(size=0x2c)
[DSP] @2,501,216tk: [+0 T:0x8880006c S:0x88803cf4] OM - Memory_alloc> return (0x882ab138)
[DSP] @2,501,287tk: [+0 T:0x8880006c S:0x88803d14] CE - Engine_open> return(-2010468040)
[DSP] @2,501,362tk: [+0 T:0x8880006c S:0x88803d5c] OM - Memory_alloc> Enter(size=0x30)
[DSP] @2,501,418tk: [+0 T:0x8880006c S:0x88803d5c] OM - Memory_alloc> return (0x882ab168)
[DSP] @2,501,484tk: [+0 T:0x8880006c S:0x88803d34] ti.sdo.ce.alg.Algorithm - Algorithm_create> Enter(fxn
s=0x88266574, idma3Fxns=0x882665a0, params=0x88105cc0, attrs=0x88803e80)
[DSP] @2,501,595tk: [+0 T:0x8880006c S:0x88803d14] OM - Memory_alloc> Enter(size=0x10)
[DSP] @2,501,652tk: [+0 T:0x8880006c S:0x88803d14] OM - Memory_alloc> return (0x882ab198)
[DSP] @2,519,578tk: [+0 T:0x8880006c S:0x88803c34] OM - Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn
Bytes=1008)
[DSP] @2,519,697tk: [+0 T:0x8880006c S:0x88803c34] OM - Memory_cacheWbInv> return
[DSP] @2,535,121tk: [+0 T:0x8880006c S:0x88803c0c] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @2,535,236tk: [+0 T:0x8880006c S:0x88803c0c] OM - Memory_cacheWbInv> return
[DSP] @2,535,480tk: [+0 T:0x8880006c S:0x88803bc4] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @2,535,566tk: [+0 T:0x8880006c S:0x88803bc4] OM - Memory_cacheWbInv> return
[DSP] @2,535,835tk: [+0 T:0x8880006c S:0x88803b9c] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @2,535,925tk: [+0 T:0x8880006c S:0x88803b9c] OM - Memory_cacheWbInv> return
[DSP] @2,536,688tk: [+0 T:0x8880006c S:0x88803cb4] OM - Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn
Bytes=1008)
[DSP] @2,536,793tk: [+0 T:0x8880006c S:0x88803cb4] OM - Memory_cacheWbInv> return
[DSP] @2,536,915tk: [+0 T:0x8880006c S:0x88803d34] ti.sdo.ce.alg.Algorithm - Algorithm_create> return (0
x882ab198)
[DSP] @2,536,997tk: [+0 T:0x8880006c S:0x88803ec4] ti.sdo.ce.video.VIDENC - VIDENC_create> return (0x882
ab168)
[DSP] @2,537,080tk: [+4 T:0x8880006c S:0x88803e84] OT - Thread_create > name: "vca_stab#0", pri:  -1, st
ack size:  16384, stack seg: 0
[DSP] @2,539,051tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 1
[DSP] @2,541,980tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @2,542,048tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@3,369,765us: [+0 T:0x00008003 S:0xbe3ff84c] CE - Engine_fwriteTrace> returning count [3758]
@3,369,981us: [+2 T:0x00008003 S:0xbe3ff8bc] CE - Engine_createNode> Returning 0x61fd0
@3,370,160us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc> Enter(0x4)
@3,370,349us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc> return (0x620a0)
@3,370,528us: [+0 T:0x00008003 S:0xbe3ff90c] OC - Comm_alloc> Enter(poolId=0x0, msg=0x620a0, size=828)
@3,370,760us: [+0 T:0x00008003 S:0xbe3ff90c] OC - Comm_alloc> msg=0x413dcc80, returning (0)
@3,370,981us: [+5 T:0x00008003 S:0xbe3ff92c] CV - VISA_create> remote codec created (name='vca_stab', lo
calQueueID=0x10001, remoteQueueID=0x0002)
@3,371,235us: [+0 T:0x00008003 S:0xbe3ffa34] ti.sdo.ce.video.VIDENC - VIDENC_create> return (0x62058)
@3,374,722us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62
058, id=257, params=0x5abe8, status=0xbe3ffa28
@3,375,009us: [+5 T:0x00008003 S:0xbe3ff844] CV - VISA_allocMsg> Allocating message for messageId=0x0002
0006
@3,375,208us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
0020006, command=0x1
@3,375,431us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@3,375,692us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put> return (0)
@3,375,884us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3ff884, timeout
=-1)
@3,376,737us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@3,377,056us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@3,377,322us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put> return (0)
@3,377,720us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff800, timeout
=-1)
@3,378,173us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @3,385,962tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88
2ab168, msg=0x88106c80); messageId=0x00020006
[DSP] @3,386,079tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl
e=0x882ab168, id=257, params=0x88106cb4, status=0x88106d00
[DSP] @3,386,192tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_enter(visa=0x882ab168): algHandle = 0x882ab
198
[DSP] @3,386,267tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h
andle=0x882ab198)
[DSP] @3,386,383tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> return
[DSP] @3,386,881tk: [+0 T:0x8892e644 S:0x889324c4] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @3,386,997tk: [+0 T:0x8892e644 S:0x889324c4] OM - Memory_cacheWbInv> return
[DSP] @3,387,126tk: [+0 T:0x8892e644 S:0x889324b4] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @3,387,203tk: [+0 T:0x8892e644 S:0x889324b4] OM - Memory_cacheWbInv> return
[DSP] @3,387,442tk: [+0 T:0x8892e644 S:0x8893248c] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @3,387,538tk: [+0 T:0x8892e644 S:0x8893248c] OM - Memory_cacheWbInv> return
[DSP] @3,387,604tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_exit(visa=0x882ab168): algHandle = 0x882ab1
98
[DSP] @3,387,679tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter
(handle=0x882ab198)
[DSP] @3,387,760tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur
n
[DSP] @3,387,834tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle
=0x882ab168, retVal=0x0)
[DSP] @3,387,919tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned from call(algHandle=0x882ab168, m
sg=0x88106c80); messageId=0x00020006
[DSP] @3,389,753tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @3,389,829tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@3,727,875us: [+0 T:0x00008003 S:0xbe3ff7a4] CE - Engine_fwriteTrace> returning count [2039]
@3,728,094us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call Completed: messageId=0x00020006, command=0x1
, return(status=0)
@3,728,332us: [+5 T:0x00008003 S:0xbe3ff834] CV - VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit
h messageId=0x00020006
@3,728,530us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620
58, retVal=0x0)
@3,728,715us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62
058, id=259, params=0x5abe8, status=0xbe3ff930
@3,728,916us: [+5 T:0x00008003 S:0xbe3ff844] CV - VISA_allocMsg> Allocating message for messageId=0x0002
0007
@3,729,097us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
0020007, command=0x1
@3,729,285us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@3,729,551us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put> return (0)
@3,729,751us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3ff884, timeout
=-1)
@3,730,056us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@3,730,282us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@3,730,528us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put> return (0)
@3,730,802us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff800, timeout
=-1)
@3,731,055us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @4,206,979tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88
2ab168, msg=0x88106c80); messageId=0x00020007
[DSP] @4,207,083tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl
e=0x882ab168, id=259, params=0x88106cb4, status=0x88106d00
[DSP] @4,207,189tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_enter(visa=0x882ab168): algHandle = 0x882ab
198
[DSP] @4,207,262tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h
andle=0x882ab198)
[DSP] @4,207,346tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> return
[DSP] @4,207,420tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_exit(visa=0x882ab168): algHandle = 0x882ab1
98
[DSP] @4,207,494tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter
(handle=0x882ab198)
[DSP] @4,207,571tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur
n
[DSP] @4,207,636tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle
=0x882ab168, retVal=0x0)
[DSP] @4,207,714tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned from call(algHandle=0x882ab168, m
sg=0x88106c80); messageId=0x00020007
[DSP] @4,209,298tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @4,209,366tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@4,078,103us: [+0 T:0x00008003 S:0xbe3ff7a4] CE - Engine_fwriteTrace> returning count [1451]
@4,078,339us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call Completed: messageId=0x00020007, command=0x1
, return(status=0)
@4,078,546us: [+5 T:0x00008003 S:0xbe3ff834] CV - VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit
h messageId=0x00020007
@4,078,742us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620
58, retVal=0x0)
SVN Version: 3093:3110
STAB Version: 01.06.08
@4,079,044us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> Enter(size=28, align=-1, cached=FA
LSE, heap=FALSE)
@4,079,389us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> CMEM_alloc(28) = 0x4144b000.
@4,079,680us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> CMEM_getPhys(0x4144b000) = 0x8c9ba
000.
@4,079,883us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> Enter(virtAddr=0x4144b000, size=
28, physAddr=0x8c9ba000)
@4,080,074us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> creating new contigBuf object
@4,080,242us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc> Enter(0x10)
@4,080,453us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc> return (0x60fb0)
@4,080,628us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> returning: cb->phys=0x8c9ba000,
cb->size=28, cb->virt=0x4144b000
@4,080,810us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> return (0x4144b000)
@4,081,014us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> Enter(size=32, align=-1, cached=FA
LSE, heap=FALSE)
@4,081,323us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> CMEM_alloc(32) = 0x41458000.
@4,081,570us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> CMEM_getPhys(0x41458000) = 0x8c9ad
000.
@4,081,763us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> Enter(virtAddr=0x41458000, size=
32, physAddr=0x8c9ad000)
@4,081,953us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> creating new contigBuf object
@4,082,119us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc> Enter(0x10)
@4,082,348us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc> return (0x620b0)
@4,082,535us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> returning: cb->phys=0x8c9ad000,
cb->size=32, cb->virt=0x41458000
@4,082,729us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> return (0x41458000)
MAC: 00:13:23:04:13:46 USN: 970041346
@4,349,545us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62
058, id=41216, params=0xbe3fedb8, status=0xbe3fed28
@4,349,833us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg> Allocating message for messageId=0x0002
0008
@4,350,045us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
0020008, command=0x1
@4,350,250us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@4,350,512us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> return (0)
@4,350,710us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3fea24, timeout
=-1)
@4,351,302us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@4,351,574us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@4,351,839us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> return (0)
@4,352,129us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3fe9a0, timeout
=-1)
@4,352,373us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @5,647,854tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88
2ab168, msg=0x88106c80); messageId=0x00020008
[DSP] @5,647,953tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl
e=0x882ab168, id=41216, params=0x88106cb4, status=0x88106cfc
[DSP] @5,648,057tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_enter(visa=0x882ab168): algHandle = 0x882ab
198
[DSP] @5,648,128tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h
andle=0x882ab198)
[DSP] @5,648,202tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> return
[DSP] @5,648,776tk: [+0 T:0x8892e644 S:0x88932504] OM - Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn
Bytes=1008)
[DSP] @5,648,876tk: [+0 T:0x8892e644 S:0x88932504] OM - Memory_cacheWbInv> return
[DSP] @5,648,930tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_exit(visa=0x882ab168): algHandle = 0x882ab1
98
[DSP] @5,649,005tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter
(handle=0x882ab198)
[DSP] @5,649,084tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur
n
[DSP] @5,649,150tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle
=0x882ab168, retVal=0x0)
[DSP] @5,649,235tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned from call(algHandle=0x882ab168, m
sg=0x88106c80); messageId=0x00020008
[DSP] @5,650,934tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @5,651,005tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@4,359,446us: [+0 T:0x00008003 S:0xbe3fe944] CE - Engine_fwriteTrace> returning count [1651]
@4,359,654us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call Completed: messageId=0x00020008, command=0x1
, return(status=0)
@4,359,857us: [+5 T:0x00008003 S:0xbe3fe9d4] CV - VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit
h messageId=0x00020008
@4,360,055us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620
58, retVal=0x0)
@4,360,248us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62
058, id=41217, params=0xbe3fec28, status=0xbe3fed28
@4,360,484us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg> Allocating message for messageId=0x0002
0009
@4,360,680us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
0020009, command=0x1
@4,360,873us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@4,361,117us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> return (0)
@4,361,309us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3fea24, timeout
=-1)
@4,366,972us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@4,367,246us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@4,787,772us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> return (0)
@4,788,103us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3fe9a0, timeout
=-1)
@4,788,354us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @5,672,464tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88
2ab168, msg=0x88106c80); messageId=0x00020009
[DSP] @5,672,568tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl
e=0x882ab168, id=41217, params=0x88106cb4, status=0x88106db0
[DSP] @5,672,674tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_enter(visa=0x882ab168): algHandle = 0x882ab
198
[DSP] @5,672,747tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h
andle=0x882ab198)
[DSP] @5,672,827tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> return
[DSP] @5,685,069tk: [+0 T:0x8892e644 S:0x88932494] OM - Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn
Bytes=1008)
[DSP] @5,685,193tk: [+0 T:0x8892e644 S:0x88932494] OM - Memory_cacheWbInv> return
[DSP] @5,685,259tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_exit(visa=0x882ab168): algHandle = 0x882ab1
98
[DSP] @5,685,335tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter
(handle=0x882ab198)
[DSP] @5,685,417tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur
n
[DSP] @5,685,488tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle
=0x882ab168, retVal=0x0)
[DSP] @5,685,621tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned from call(algHandle=0x882ab168, m
sg=0x88106c80); messageId=0x00020009
[DSP] @6,662,444tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @6,662,522tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@4,795,428us: [+0 T:0x00008003 S:0xbe3fe944] CE - Engine_fwriteTrace> returning count [1651]
@4,795,640us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call Completed: messageId=0x00020009, command=0x1
, return(status=0)
@4,795,851us: [+5 T:0x00008003 S:0xbe3fe9d4] CV - VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit
h messageId=0x00020009
@4,796,075us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620
58, retVal=0x0)
@4,796,289us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62
058, id=41218, params=0xbe3fec28, status=0xbe3feac0
@4,796,501us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg> Allocating message for messageId=0x0002
000a
@4,796,692us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
002000a, command=0x1
@4,796,891us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@4,797,345us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> return (0)
@4,797,723us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3fea24, timeout
=-1)
@4,798,173us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@4,798,433us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@4,798,694us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> return (0)
@4,799,015us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3fe9a0, timeout
=-1)
@4,799,256us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @6,684,637tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88
2ab168, msg=0x88106c80); messageId=0x0002000a
[DSP] @6,684,743tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl
e=0x882ab168, id=41218, params=0x88106cb4, status=0x88106db0
[DSP] @6,684,853tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_enter(visa=0x882ab168): algHandle = 0x882ab
198
[DSP] @6,684,927tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h
andle=0x882ab198)
[DSP] @6,685,011tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> return
[DSP] @6,685,660tk: [+0 T:0x8892e644 S:0x88932504] OM - Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn
Bytes=1008)
[DSP] @6,685,789tk: [+0 T:0x8892e644 S:0x88932504] OM - Memory_cacheWbInv> return
[DSP] @6,685,848tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_exit(visa=0x882ab168): algHandle = 0x882ab1
98
[DSP] @6,685,921tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter
(handle=0x882ab198)
[DSP] @6,686,001tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur
n
[DSP] @6,686,067tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle
=0x882ab168, retVal=0x0)
[DSP] @6,686,152tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned from call(algHandle=0x882ab168, m
sg=0x88106c80); messageId=0x0002000a
[DSP] @6,687,790tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @6,687,860tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@5,146,922us: [+0 T:0x00008003 S:0xbe3fe944] CE - Engine_fwriteTrace> returning count [1651]
@5,147,356us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call Completed: messageId=0x0002000a, command=0x1
, return(status=0)
@5,147,728us: [+5 T:0x00008003 S:0xbe3fe9d4] CV - VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit
h messageId=0x0002000a
@5,147,971us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620
58, retVal=0x0)
@5,174,837us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC - VIDENC_process> Enter (handle=0x62
058, inBufs=0xbe3ffac0, outBufs=0xbe3ffab0, inArgs=0xbe3ff8fc, outArgs=0xbe3ffa10)
@5,175,123us: [+5 T:0x00008003 S:0xbe3ff7fc] CV - VISA_allocMsg> Allocating message for messageId=0x0002
000b
@5,175,328us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x404c
9000, size=884736)
@5,175,514us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x404c9000,
 size=884736)
@5,175,692us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> found in cb(Sc=0x404c9000,
 Ec=0x405a1000, Ss=0x404c9000, Es=0x405a1000, PSc=0x8cac7000)
@5,175,934us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> returning physAddr=0x8cac7
000
@5,176,105us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> return (0x8cac7000)
@5,176,280us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4145
8000, size=32)
@5,176,450us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x41458000,
 size=32)
@5,176,621us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> found in cb(Sc=0x41458000,
 Ec=0x41458020, Ss=0x41458000, Es=0x41458020, PSc=0x8c9ad000)
@5,176,811us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> returning physAddr=0x8c9ad
000
@5,176,980us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> return (0x8c9ad000)
@5,177,150us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x407c
9000, size=884736)
@5,177,369us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x407c9000,
 size=884736)
@5,177,545us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> found in cb(Sc=0x407c9000,
 Ec=0x408a1000, Ss=0x407c9000, Es=0x408a1000, PSc=0x8fc94000)
@5,177,918us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> returning physAddr=0x8fc94
000
@5,178,105us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> return (0x8fc94000)
@5,178,281us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4144
b000, size=28)
@5,178,460us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x4144b000,
 size=28)
@5,178,664us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> found in cb(Sc=0x4144b000,
 Ec=0x4144b01c, Ss=0x4144b000, Es=0x4144b01c, PSc=0x8c9ba000)
@5,520,076us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> returning physAddr=0x8c9ba
000
@5,520,313us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> return (0x8c9ba000)
@5,520,501us: [+0 T:0x00008003 S:0xbe3ff80c] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
002000b, command=0x0
@5,520,695us: [+0 T:0x00008003 S:0xbe3ff7dc] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@5,520,929us: [+0 T:0x00008003 S:0xbe3ff7dc] OC - Comm_put> return (0)
@5,521,114us: [+0 T:0x00008003 S:0xbe3ff7d4] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3ff87c, timeout
=-1)


After this it locks up and never returns control to the ARM after the VIDENC_process() call.

It looks like its locking up inside the Codec Engine after returning from the DSP side process call.

Can anyone shed some light on whats going wrong?


Regards,
Etienne Eccles

VCA Technology

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100414/6afdc313/attachment-0001.html>

From cyril at ti.com  Wed Apr 14 13:44:47 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 14:44:47 -0400
Subject: [PATCH v3 01/16] Davinci: iotable based ioremap() interception
In-Reply-To: <1271270702-28307-1-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
Message-ID: <1271270702-28307-2-git-send-email-cyril@ti.com>

This patch allows for a more flexible ioremap() interception.  The mechanism
works by translating physical addresses based on soc-specific iotable
contents (davinci_soc_info.io_desc), once davinci_soc_info is populated by
davinci_common_init().

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/da830.c           |    7 +++++-
 arch/arm/mach-davinci/da850.c           |    9 ++++++-
 arch/arm/mach-davinci/include/mach/io.h |    4 +++
 arch/arm/mach-davinci/io.c              |   33 +++++++++++++++++++++++++++---
 4 files changed, 46 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 122e61a..168f277 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1206,9 +1206,14 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
 	.emac_pdata		= &da8xx_emac_pdata,
 };
 
+#define da830_early_ioremap(p, s)				\
+	__davinci_ioremap(p, s,					\
+			davinci_soc_info_da830.io_desc,		\
+			davinci_soc_info_da830.io_desc_num)
+
 void __init da830_init(void)
 {
-	da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
+	da8xx_syscfg0_base = da830_early_ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
 	if (WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module"))
 		return;
 
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index d0fd756..27eb32e 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1093,15 +1093,20 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.sram_len		= SZ_8K,
 };
 
+#define da850_early_ioremap(p, s)				\
+	__davinci_ioremap(p, s,					\
+			davinci_soc_info_da850.io_desc,		\
+			davinci_soc_info_da850.io_desc_num)
+
 void __init da850_init(void)
 {
 	unsigned int v;
 
-	da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
+	da8xx_syscfg0_base = da850_early_ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
 	if (WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module"))
 		return;
 
-	da8xx_syscfg1_base = ioremap(DA8XX_SYSCFG1_BASE, SZ_4K);
+	da8xx_syscfg1_base = da850_early_ioremap(DA8XX_SYSCFG1_BASE, SZ_4K);
 	if (WARN(!da8xx_syscfg1_base, "Unable to map syscfg1 module"))
 		return;
 
diff --git a/arch/arm/mach-davinci/include/mach/io.h b/arch/arm/mach-davinci/include/mach/io.h
index 62b0a90..4aa301c 100644
--- a/arch/arm/mach-davinci/include/mach/io.h
+++ b/arch/arm/mach-davinci/include/mach/io.h
@@ -25,6 +25,10 @@
 #define __arch_ioremap(p, s, t)	davinci_ioremap(p, s, t)
 #define __arch_iounmap(v)	davinci_iounmap(v)
 
+struct map_desc;
+
+void __iomem *__davinci_ioremap(unsigned long p, size_t size,
+		struct map_desc *io_desc, int io_desc_num);
 void __iomem *davinci_ioremap(unsigned long phys, size_t size,
 			      unsigned int type);
 void davinci_iounmap(volatile void __iomem *addr);
diff --git a/arch/arm/mach-davinci/io.c b/arch/arm/mach-davinci/io.c
index a1c0b6b..3a62f14 100644
--- a/arch/arm/mach-davinci/io.c
+++ b/arch/arm/mach-davinci/io.c
@@ -12,17 +12,42 @@
 #include <linux/io.h>
 
 #include <asm/tlb.h>
+#include <asm/mach/map.h>
 
-#define BETWEEN(p, st, sz)	((p) >= (st) && (p) < ((st) + (sz)))
-#define XLATE(p, pst, vst)	((void __iomem *)((p) - (pst) + (vst)))
+#include <mach/common.h>
+
+/*
+ * Remap io addresses based on a soc-specific io-descriptor table. This is
+ * useful in early arch init code before davinci_common_init().  After
+ * davinci_common_init(), regular ioremap() calls should be used.
+ */
+void __iomem *__davinci_ioremap(unsigned long p, size_t size,
+		struct map_desc *io_desc, int io_desc_num)
+{
+	int i;
+
+	for (i = 0; i < io_desc_num; i++, io_desc++) {
+		unsigned long iophys = __pfn_to_phys(io_desc->pfn);
+		unsigned long iosize = io_desc->length;
+
+		if (p >= iophys && (p + size) <= (iophys + iosize))
+			return __io(io_desc->virtual + p - iophys);
+	}
+
+	return NULL;
+}
 
 /*
  * Intercept ioremap() requests for addresses in our fixed mapping regions.
  */
 void __iomem *davinci_ioremap(unsigned long p, size_t size, unsigned int type)
 {
-	if (BETWEEN(p, IO_PHYS, IO_SIZE))
-		return XLATE(p, IO_PHYS, IO_VIRT);
+	void __iomem *ret;
+
+	ret = __davinci_ioremap(p, size, davinci_soc_info.io_desc,
+			davinci_soc_info.io_desc_num);
+	if (ret)
+		return ret;
 
 	return __arm_ioremap_caller(p, size, type, __builtin_return_address(0));
 }
-- 
1.6.3.3


From cyril at ti.com  Wed Apr 14 13:44:46 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 14:44:46 -0400
Subject: [PATCH v3 00/16] Davinci: initial tnetv107x patch series
Message-ID: <1271270702-28307-1-git-send-email-cyril@ti.com>

Hi,

This patch series adds support for TNETV107X - a Texas Instruments SOC that
shares a number of common features with the Davinci architecture.

Changes in this patch series (against v2):

1. Migrates to iotable based remapping across architectures
2. Implemented a debug macro scheme similar to that on OMAP platform
3. Eliminated tnetv107x specific clock recalc code where possible
4. GPIO implementation restructured to allow for controller differences
5. Moved definitions of base addresses, edma channels etc.

Some of these patches were posted separately earlier in an attempt to get some
early feedback.  This series contains updated versions of those patches as
well.

These changes were tested on tnetv107x evm and on dm365 evm (thanks to Sandeep
Paulraj).

- Cyril.

Cyril Chemparathy (16):
  Davinci: iotable based ioremap() interception
  Davinci: generalized debug macros
  Davinci: configurable pll divider mask
  Davinci: cpu class macros
  Davinci: watchdog reset separation across socs
  Davinci: gpio - minor cleanup
  Davinci: gpio - struct renames
  Davinci: gpio - register layout invariant inlines
  Davinci: gpio - controller type support
  Davinci: gpio - fine grained locking
  Davinci: tnetv107x decompresser uart definitions
  Davinci: tnetv107x soc specific header
  Davinci: tnetv107x initial support
  Davinci: tnetv107x watchdog reset support
  Davinci: tnetv107x initial gpio support
  Davinci: tnetv107x evm board initial support

 arch/arm/mach-davinci/Kconfig                    |   12 +
 arch/arm/mach-davinci/Makefile                   |    3 +
 arch/arm/mach-davinci/board-tnetv107x-evm.c      |  281 +++++
 arch/arm/mach-davinci/clock.c                    |    9 +-
 arch/arm/mach-davinci/clock.h                    |    3 +-
 arch/arm/mach-davinci/da830.c                    |    9 +-
 arch/arm/mach-davinci/da850.c                    |   11 +-
 arch/arm/mach-davinci/devices-da8xx.c            |    4 +-
 arch/arm/mach-davinci/devices-tnetv107x.c        |  149 +++
 arch/arm/mach-davinci/dm355.c                    |    1 +
 arch/arm/mach-davinci/dm365.c                    |    1 +
 arch/arm/mach-davinci/dm644x.c                   |    1 +
 arch/arm/mach-davinci/dm646x.c                   |    1 +
 arch/arm/mach-davinci/gpio-tnetv107x.c           |  201 ++++
 arch/arm/mach-davinci/gpio.c                     |  106 ++-
 arch/arm/mach-davinci/include/mach/common.h      |    5 +
 arch/arm/mach-davinci/include/mach/cputype.h     |   13 +
 arch/arm/mach-davinci/include/mach/debug-macro.S |   51 +-
 arch/arm/mach-davinci/include/mach/gpio.h        |   73 +-
 arch/arm/mach-davinci/include/mach/io.h          |    4 +
 arch/arm/mach-davinci/include/mach/serial.h      |   21 +
 arch/arm/mach-davinci/include/mach/system.h      |   19 +-
 arch/arm/mach-davinci/include/mach/tnetv107x.h   |   67 ++
 arch/arm/mach-davinci/include/mach/uncompress.h  |   87 ++-
 arch/arm/mach-davinci/io.c                       |   33 +-
 arch/arm/mach-davinci/time.c                     |    3 +-
 arch/arm/mach-davinci/tnetv107x.c                | 1282 ++++++++++++++++++++++
 27 files changed, 2327 insertions(+), 123 deletions(-)
 create mode 100644 arch/arm/mach-davinci/board-tnetv107x-evm.c
 create mode 100644 arch/arm/mach-davinci/devices-tnetv107x.c
 create mode 100644 arch/arm/mach-davinci/gpio-tnetv107x.c
 create mode 100644 arch/arm/mach-davinci/include/mach/tnetv107x.h
 create mode 100644 arch/arm/mach-davinci/tnetv107x.c


From cyril at ti.com  Wed Apr 14 13:44:50 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 14:44:50 -0400
Subject: [PATCH v3 04/16] Davinci: cpu class macros
In-Reply-To: <1271270702-28307-4-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
Message-ID: <1271270702-28307-5-git-send-email-cyril@ti.com>

This patches adds cpu class macros that can be used to differentiate between
DMx, da8xx, and tnetv107x socs.

These macros are available for use only after the JTAG ID looking is done by
davinci_common_init().  If we need this earlier in the boot process, we may
have to rely on machine_is_* macros to determine the cpu class.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/include/mach/cputype.h |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/include/mach/cputype.h b/arch/arm/mach-davinci/include/mach/cputype.h
index cea6b89..0bc6996 100644
--- a/arch/arm/mach-davinci/include/mach/cputype.h
+++ b/arch/arm/mach-davinci/include/mach/cputype.h
@@ -91,4 +91,17 @@ IS_DAVINCI_CPU(tnetv107x, DAVINCI_CPU_ID_TNETV107X)
 #define cpu_is_davinci_tnetv107x() 0
 #endif
 
+#define cpu_class_is_dmx()		\
+	(cpu_is_davinci_dm644x() ||	\
+	 cpu_is_davinci_dm646x() ||	\
+	 cpu_is_davinci_dm355()  ||	\
+	 cpu_is_davinci_dm365())
+
+#define cpu_class_is_da8xx()		\
+	(cpu_is_davinci_da830()	||	\
+	 cpu_is_davinci_da850())
+
+#define cpu_class_is_tnetv107x()	\
+	(cpu_is_davinci_tnetv107x())
+
 #endif
-- 
1.6.3.3


From cyril at ti.com  Wed Apr 14 13:44:48 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 14:44:48 -0400
Subject: [PATCH v3 02/16] Davinci: generalized debug macros
In-Reply-To: <1271270702-28307-2-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
Message-ID: <1271270702-28307-3-git-send-email-cyril@ti.com>

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 macros through a small chunk of memory placed just
below the page tables (@0x80003ff8).

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/include/mach/debug-macro.S |   51 +++++++++++---
 arch/arm/mach-davinci/include/mach/serial.h      |   13 ++++
 arch/arm/mach-davinci/include/mach/uncompress.h  |   80 ++++++++++++++++------
 3 files changed, 112 insertions(+), 32 deletions(-)

diff --git a/arch/arm/mach-davinci/include/mach/debug-macro.S b/arch/arm/mach-davinci/include/mach/debug-macro.S
index 3cd93a8..ac0fa02 100644
--- a/arch/arm/mach-davinci/include/mach/debug-macro.S
+++ b/arch/arm/mach-davinci/include/mach/debug-macro.S
@@ -17,22 +17,51 @@
  */
 
 #include <linux/serial_reg.h>
+
+#include <asm/memory.h>
+
+#include <mach/serial.h>
+
 #define UART_SHIFT	2
 
+		.pushsection .data
+davinci_uart_phys:	.word	0
+davinci_uart_virt:	.word	0
+		.popsection
+
 		.macro addruart, rx, tmp
+
+		/* Use davinci_uart_phys/virt if already configured */
+10:		mrc	p15, 0, \rx, c1, c0
+		tst	\rx, #1			@ MMU enabled?
+		ldreq	\rx, =__virt_to_phys(davinci_uart_phys)
+		ldrne	\rx, =davinci_uart_virt
+		ldr	\rx, [\rx]
+		cmp	\rx, #0			@ is port configured?
+		bne	99f			@ already configured
+
+		/* Copy uart phys address from decompressor uart info */
 		mrc	p15, 0, \rx, c1, c0
 		tst	\rx, #1			@ MMU enabled?
-		moveq	\rx, #0x01000000	@ physical base address
-		movne	\rx, #0xfe000000	@ virtual base
-#if defined(CONFIG_ARCH_DAVINCI_DA8XX) && defined(CONFIG_ARCH_DAVINCI_DMx)
-#error Cannot enable DaVinci and DA8XX platforms concurrently
-#elif defined(CONFIG_MACH_DAVINCI_DA830_EVM) || \
-	defined(CONFIG_MACH_DAVINCI_DA850_EVM)
-		orr	\rx, \rx, #0x00d00000	@ physical base address
-		orr	\rx, \rx, #0x0000d000	@ of UART 2
-#else
-		orr	\rx, \rx, #0x00c20000   @ UART 0
-#endif
+		ldreq	\tmp, =__virt_to_phys(davinci_uart_phys)
+		ldrne	\tmp, =davinci_uart_phys
+		ldreq	\rx, =DAVINCI_UART_INFO
+		ldrne	\rx, =__phys_to_virt(DAVINCI_UART_INFO)
+		ldr	\rx, [\rx, #0]
+		str	\rx, [\tmp]
+
+		/* Copy uart virt address from decompressor uart info */
+		mrc	p15, 0, \rx, c1, c0
+		tst	\rx, #1			@ MMU enabled?
+		ldreq	\tmp, =__virt_to_phys(davinci_uart_virt)
+		ldrne	\tmp, =davinci_uart_virt
+		ldreq	\rx, =DAVINCI_UART_INFO
+		ldrne	\rx, =__phys_to_virt(DAVINCI_UART_INFO)
+		ldr	\rx, [\rx, #4]
+		str	\rx, [\tmp]
+
+		b	10b
+99:
 		.endm
 
 		.macro	senduart,rd,rx
diff --git a/arch/arm/mach-davinci/include/mach/serial.h b/arch/arm/mach-davinci/include/mach/serial.h
index a584697..8829dde 100644
--- a/arch/arm/mach-davinci/include/mach/serial.h
+++ b/arch/arm/mach-davinci/include/mach/serial.h
@@ -11,8 +11,19 @@
 #ifndef __ASM_ARCH_SERIAL_H
 #define __ASM_ARCH_SERIAL_H
 
+#include <asm/memory.h>
+
 #include <mach/hardware.h>
 
+/*
+ * Stolen area that contains debug uart physical and virtual addresses.  These
+ * addresses are filled in by the uncompress.h code, and are used by the debug
+ * macros in debug-macro.S.
+ *
+ * This area sits just below the page tables (see arch/arm/kernel/head.S).
+ */
+#define DAVINCI_UART_INFO	(PHYS_OFFSET + 0x3ff8)
+
 #define DAVINCI_MAX_NR_UARTS	3
 #define DAVINCI_UART0_BASE	(IO_PHYS + 0x20000)
 #define DAVINCI_UART1_BASE	(IO_PHYS + 0x20400)
@@ -27,11 +38,13 @@
 #define UART_DM646X_SCR			0x10
 #define UART_DM646X_SCR_TX_WATERMARK	0x08
 
+#ifndef __ASSEMBLY__
 struct davinci_uart_config {
 	/* Bit field of UARTs present; bit 0 --> UART1 */
 	unsigned int enabled_uarts;
 };
 
 extern int davinci_serial_init(struct davinci_uart_config *);
+#endif
 
 #endif /* __ASM_ARCH_SERIAL_H */
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
index 33796b4..20c23a3 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -1,8 +1,17 @@
 /*
  * Serial port stubs for kernel decompress status messages
  *
- *  Author:     Anant Gole
- * (C) Copyright (C) 2006, Texas Instruments, Inc
+ * Initially based on:
+ * arch/arm/plat-omap/include/mach/uncompress.h
+ *
+ * Original copyrights follow.
+ *
+ * Copyright (C) 2000 RidgeRun, Inc.
+ * Author: Greg Lonnon <glonnon at ridgerun.com>
+ *
+ * Rewritten by:
+ * Author: <source at mvista.com>
+ * 2004 (c) MontaVista Software, Inc.
  *
  * This file is licensed under the terms of the GNU General Public License
  * version 2. This program is licensed "as is" without any warranty of any
@@ -11,30 +20,17 @@
 
 #include <linux/types.h>
 #include <linux/serial_reg.h>
-#include <mach/serial.h>
 
 #include <asm/mach-types.h>
 
-extern unsigned int __machine_arch_type;
+#include <mach/serial.h>
 
 static u32 *uart;
-
-static u32 *get_uart_base(void)
-{
-	if (__machine_arch_type == MACH_TYPE_DAVINCI_DA830_EVM ||
-		__machine_arch_type == MACH_TYPE_DAVINCI_DA850_EVM)
-		return (u32 *)DA8XX_UART2_BASE;
-	else
-		return (u32 *)DAVINCI_UART0_BASE;
-}
+static u32 *uart_info = (u32 *)(DAVINCI_UART_INFO);
 
 /* PORT_16C550A, in polled non-fifo mode */
-
 static void putc(char c)
 {
-	if (!uart)
-		uart = get_uart_base();
-
 	while (!(uart[UART_LSR] & UART_LSR_THRE))
 		barrier();
 	uart[UART_TX] = c;
@@ -42,12 +38,54 @@ static void putc(char c)
 
 static inline void flush(void)
 {
-	if (!uart)
-		uart = get_uart_base();
-
 	while (!(uart[UART_LSR] & UART_LSR_THRE))
 		barrier();
 }
 
-#define arch_decomp_setup()
+static inline void set_uart_info(u32 phys, void * __iomem virt)
+{
+	uart = (u32 *)phys;
+	uart_info[0] = phys;
+	uart_info[1] = (u32)virt;
+}
+
+#define _DEBUG_LL_ENTRY(machine, phys, virt)			\
+	if (machine_is_##machine()) {				\
+		set_uart_info(phys, virt);			\
+		break;						\
+	}
+
+#define DEBUG_LL_DAVINCI(machine, port)				\
+	_DEBUG_LL_ENTRY(machine, DAVINCI_UART##port##_BASE,	\
+			IO_ADDRESS(DAVINCI_UART##port##_BASE))
+
+#define DEBUG_LL_DA8XX(machine, port)				\
+	_DEBUG_LL_ENTRY(machine, DA8XX_UART##port##_BASE,	\
+			IO_ADDRESS(DA8XX_UART##port##_BASE))
+
+static inline void __arch_decomp_setup(unsigned long arch_id)
+{
+	/*
+	 * Initialize the port based on the machine ID from the bootloader.
+	 * Note that we're using macros here instead of switch statement
+	 * as machine_is functions are optimized out for the boards that
+	 * are not selected.
+	 */
+	do {
+		/* Davinci boards */
+		DEBUG_LL_DAVINCI(davinci_evm,		0);
+		DEBUG_LL_DAVINCI(sffsdr,		0);
+		DEBUG_LL_DAVINCI(neuros_osd2,		0);
+		DEBUG_LL_DAVINCI(davinci_dm355_evm,	0);
+		DEBUG_LL_DAVINCI(dm355_leopard,		0);
+		DEBUG_LL_DAVINCI(davinci_dm6467_evm,	0);
+		DEBUG_LL_DAVINCI(davinci_dm365_evm,	0);
+
+		/* DA8xx boards */
+		DEBUG_LL_DA8XX(davinci_da830_evm,	2);
+		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
+	} while (0);
+}
+
+#define arch_decomp_setup()	__arch_decomp_setup(arch_id)
 #define arch_decomp_wdog()
-- 
1.6.3.3


From cyril at ti.com  Wed Apr 14 13:44:52 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 14:44:52 -0400
Subject: [PATCH v3 06/16] Davinci: gpio - minor cleanup
In-Reply-To: <1271270702-28307-6-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
Message-ID: <1271270702-28307-7-git-send-email-cyril@ti.com>

macroized repeated container_of()s to improve readability.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
v3: Reverted back on direction_in/out unification

 arch/arm/mach-davinci/gpio.c |   13 ++++++++-----
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index 5476ad1..5a045e6 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -28,6 +28,9 @@ struct davinci_gpio {
 	int			irq_base;
 };
 
+#define chip2controller(chip)	\
+	container_of(chip, struct davinci_gpio, chip)
+
 static struct davinci_gpio chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
 
 /* create a non-inlined version */
@@ -56,7 +59,7 @@ static int __init davinci_gpio_irq_setup(void);
 
 static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+	struct davinci_gpio *d = chip2controller(chip);
 	struct gpio_controller __iomem *g = d->regs;
 	u32 temp;
 
@@ -78,7 +81,7 @@ static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
  */
 static int davinci_gpio_get(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+	struct davinci_gpio *d = chip2controller(chip);
 	struct gpio_controller __iomem *g = d->regs;
 
 	return (1 << offset) & __raw_readl(&g->in_data);
@@ -87,7 +90,7 @@ static int davinci_gpio_get(struct gpio_chip *chip, unsigned offset)
 static int
 davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
 {
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+	struct davinci_gpio *d = chip2controller(chip);
 	struct gpio_controller __iomem *g = d->regs;
 	u32 temp;
 	u32 mask = 1 << offset;
@@ -107,7 +110,7 @@ davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
 static void
 davinci_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
 {
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+	struct davinci_gpio *d = chip2controller(chip);
 	struct gpio_controller __iomem *g = d->regs;
 
 	__raw_writel((1 << offset), value ? &g->set_data : &g->clr_data);
@@ -262,7 +265,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
 
 static int gpio_to_irq_banked(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+	struct davinci_gpio *d = chip2controller(chip);
 
 	if (d->irq_base >= 0)
 		return d->irq_base + offset;
-- 
1.6.3.3


From cyril at ti.com  Wed Apr 14 13:44:51 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 14:44:51 -0400
Subject: [PATCH v3 05/16] Davinci: watchdog reset separation across socs
In-Reply-To: <1271270702-28307-5-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
Message-ID: <1271270702-28307-6-git-send-email-cyril@ti.com>

The earlier watchdog reset mechanism had a couple of limitations.  First, it
embedded a reference to "davinci_wdt_device" inside common code.  This
forced all derived platforms (da8xx and tnetv107x) to define such a device.
This also would have caused problems in including multiple socs in a single
build due to symbol redefinition.

With this patch, davinci_watchdog_reset() now takes the platform device as an
argument.  arch_reset() then uses the cpu_class_ macros and passes in an
appropriate soc-dependent device to davinci_watchdog_reset().

This way, as long as the compiler optimizer is active (tested with O2 and Os),
irrelevant arch_reset code gets auto-magically stripped out along with hanging
references to unknown symbols.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/clock.h               |    2 --
 arch/arm/mach-davinci/devices-da8xx.c       |    4 ++--
 arch/arm/mach-davinci/include/mach/system.h |   14 ++++++++++++--
 arch/arm/mach-davinci/time.c                |    3 +--
 4 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-davinci/clock.h b/arch/arm/mach-davinci/clock.h
index ce26015..448a0a9 100644
--- a/arch/arm/mach-davinci/clock.h
+++ b/arch/arm/mach-davinci/clock.h
@@ -119,8 +119,6 @@ int davinci_clk_init(struct clk_lookup *clocks);
 int davinci_set_pllrate(struct pll_data *pll, unsigned int prediv,
 				unsigned int mult, unsigned int postdiv);
 
-extern struct platform_device davinci_wdt_device;
-
 #endif
 
 #endif
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index 0a96791..67a6fbc 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -326,7 +326,7 @@ static struct resource da8xx_watchdog_resources[] = {
 	},
 };
 
-struct platform_device davinci_wdt_device = {
+struct platform_device da8xx_wdt_device = {
 	.name		= "watchdog",
 	.id		= -1,
 	.num_resources	= ARRAY_SIZE(da8xx_watchdog_resources),
@@ -335,7 +335,7 @@ struct platform_device davinci_wdt_device = {
 
 int __init da8xx_register_watchdog(void)
 {
-	return platform_device_register(&davinci_wdt_device);
+	return platform_device_register(&da8xx_wdt_device);
 }
 
 static struct resource da8xx_emac_resources[] = {
diff --git a/arch/arm/mach-davinci/include/mach/system.h b/arch/arm/mach-davinci/include/mach/system.h
index 5a7d758..90be3f6 100644
--- a/arch/arm/mach-davinci/include/mach/system.h
+++ b/arch/arm/mach-davinci/include/mach/system.h
@@ -11,7 +11,13 @@
 #ifndef __ASM_ARCH_SYSTEM_H
 #define __ASM_ARCH_SYSTEM_H
 
-extern void davinci_watchdog_reset(void);
+#include <linux/platform_device.h>
+#include <mach/cputype.h>
+
+extern struct platform_device davinci_wdt_device;
+extern struct platform_device da8xx_wdt_device;
+
+extern void davinci_watchdog_reset(struct platform_device *);
 
 static inline void arch_idle(void)
 {
@@ -20,7 +26,11 @@ static inline void arch_idle(void)
 
 static inline void arch_reset(char mode, const char *cmd)
 {
-	davinci_watchdog_reset();
+	if (cpu_class_is_dmx())
+		davinci_watchdog_reset(&davinci_wdt_device);
+
+	if (cpu_class_is_da8xx())
+		davinci_watchdog_reset(&da8xx_wdt_device);
 }
 
 #endif /* __ASM_ARCH_SYSTEM_H */
diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index b21f763..6a762be 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c
@@ -399,10 +399,9 @@ struct sys_timer davinci_timer = {
 
 
 /* reset board using watchdog timer */
-void davinci_watchdog_reset(void)
+void davinci_watchdog_reset(struct platform_device *pdev)
 {
 	u32 tgcr, wdtcr;
-	struct platform_device *pdev = &davinci_wdt_device;
 	void __iomem *base = IO_ADDRESS(pdev->resource[0].start);
 	struct clk *wd_clk;
 
-- 
1.6.3.3


From cyril at ti.com  Wed Apr 14 13:44:49 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 14:44:49 -0400
Subject: [PATCH v3 03/16] Davinci: configurable pll divider mask
In-Reply-To: <1271270702-28307-3-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
Message-ID: <1271270702-28307-4-git-send-email-cyril@ti.com>

This patch allows socs to override the divider ratio mask by setting an
optional field (div_ratio_mask) in the pll_data structure.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
v3: moved div_ratio_mask setup to before clk->recalc()

 arch/arm/mach-davinci/clock.c |    9 ++++++---
 arch/arm/mach-davinci/clock.h |    1 +
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
index 5de60ae..868cb76 100644
--- a/arch/arm/mach-davinci/clock.c
+++ b/arch/arm/mach-davinci/clock.c
@@ -279,7 +279,7 @@ static unsigned long clk_sysclk_recalc(struct clk *clk)
 
 	v = __raw_readl(pll->base + clk->div_reg);
 	if (v & PLLDIV_EN) {
-		plldiv = (v & PLLDIV_RATIO_MASK) + 1;
+		plldiv = (v & pll->div_ratio_mask) + 1;
 		if (plldiv)
 			rate /= plldiv;
 	}
@@ -319,7 +319,7 @@ static unsigned long clk_pllclk_recalc(struct clk *clk)
 	if (pll->flags & PLL_HAS_PREDIV) {
 		prediv = __raw_readl(pll->base + PREDIV);
 		if (prediv & PLLDIV_EN)
-			prediv = (prediv & PLLDIV_RATIO_MASK) + 1;
+			prediv = (prediv & pll->div_ratio_mask) + 1;
 		else
 			prediv = 1;
 	}
@@ -331,7 +331,7 @@ static unsigned long clk_pllclk_recalc(struct clk *clk)
 	if (pll->flags & PLL_HAS_POSTDIV) {
 		postdiv = __raw_readl(pll->base + POSTDIV);
 		if (postdiv & PLLDIV_EN)
-			postdiv = (postdiv & PLLDIV_RATIO_MASK) + 1;
+			postdiv = (postdiv & pll->div_ratio_mask) + 1;
 		else
 			postdiv = 1;
 	}
@@ -458,6 +458,9 @@ int __init davinci_clk_init(struct clk_lookup *clocks)
 				clk->recalc = clk_leafclk_recalc;
 		}
 
+		if (clk->pll_data && !clk->pll_data->div_ratio_mask)
+			clk->pll_data->div_ratio_mask = PLLDIV_RATIO_MASK;
+
 		if (clk->recalc)
 			clk->rate = clk->recalc(clk);
 
diff --git a/arch/arm/mach-davinci/clock.h b/arch/arm/mach-davinci/clock.h
index 53a0f7b..ce26015 100644
--- a/arch/arm/mach-davinci/clock.h
+++ b/arch/arm/mach-davinci/clock.h
@@ -76,6 +76,7 @@ struct pll_data {
 	u32 num;
 	u32 flags;
 	u32 input_rate;
+	u32 div_ratio_mask;
 };
 #define PLL_HAS_PREDIV          0x01
 #define PLL_HAS_POSTDIV         0x02
-- 
1.6.3.3


From cyril at ti.com  Wed Apr 14 13:44:54 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 14:44:54 -0400
Subject: [PATCH v3 08/16] Davinci: gpio - register layout invariant inlines
In-Reply-To: <1271270702-28307-8-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
Message-ID: <1271270702-28307-9-git-send-email-cyril@ti.com>

This patch renders the inlined gpio accessors in gpio.h independent of the
underlying controller's register layout.  This is done by including three new
fields in davinci_gpio_controller to hold the addresses of the set, clear, and
in data registers.

Other changes:

1. davinci_gpio_regs structure definition moved to gpio.c.  This structure is
no longer common across all davinci socs (davinci_gpio_controller is).

2. controller base address calculation code (gpio2controller()) moved to
gpio.c as this was no longer necessary for the inline implementation.

3. modified inline range checks to use davinci_soc_info.gpio_num instead of
DAVINCI_N_GPIO.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
v3: reverted back on direction_in/out unification
v3: changed gpio controller's registers field type to void, reflecting the
    fact that different underlying gpio controllers can have different
    register layouts

 arch/arm/mach-davinci/gpio.c                |   46 +++++++++++++++++--
 arch/arm/mach-davinci/include/mach/common.h |    4 ++
 arch/arm/mach-davinci/include/mach/gpio.h   |   65 +++++++++-----------------
 3 files changed, 68 insertions(+), 47 deletions(-)

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index 6c470a7..e15dbc8 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -20,6 +20,19 @@
 
 #include <asm/mach/irq.h>
 
+struct davinci_gpio_regs {
+	u32	dir;
+	u32	out_data;
+	u32	set_data;
+	u32	clr_data;
+	u32	in_data;
+	u32	set_rising;
+	u32	clr_rising;
+	u32	set_falling;
+	u32	clr_falling;
+	u32	intstat;
+};
+
 static DEFINE_SPINLOCK(gpio_lock);
 
 #define chip2controller(chip)	\
@@ -28,9 +41,24 @@ static DEFINE_SPINLOCK(gpio_lock);
 static struct davinci_gpio_controller chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
 
 /* create a non-inlined version */
-static struct davinci_gpio_regs __iomem __init *gpio2controller(unsigned gpio)
+static struct davinci_gpio_regs __iomem __init *gpio2regs(unsigned gpio)
 {
-	return __gpio_to_controller(gpio);
+	void __iomem *ptr;
+	void __iomem *base = davinci_soc_info.gpio_base;
+
+	if (gpio < 32 * 1)
+		ptr = base + 0x10;
+	else if (gpio < 32 * 2)
+		ptr = base + 0x38;
+	else if (gpio < 32 * 3)
+		ptr = base + 0x60;
+	else if (gpio < 32 * 4)
+		ptr = base + 0x88;
+	else if (gpio < 32 * 5)
+		ptr = base + 0xb0;
+	else
+		ptr = NULL;
+	return ptr;
 }
 
 static inline struct davinci_gpio_regs __iomem *irq2controller(int irq)
@@ -115,6 +143,7 @@ static int __init davinci_gpio_setup(void)
 	int i, base;
 	unsigned ngpio;
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
+	struct davinci_gpio_regs *regs;
 
 	/*
 	 * The gpio banks conceptually expose a segmented bitmap,
@@ -143,11 +172,18 @@ static int __init davinci_gpio_setup(void)
 		if (chips[i].chip.ngpio > 32)
 			chips[i].chip.ngpio = 32;
 
-		chips[i].regs = gpio2controller(base);
+		regs = gpio2regs(base);
+		chips[i].regs = regs;
+		chips[i].set_data = &regs->set_data;
+		chips[i].clr_data = &regs->clr_data;
+		chips[i].in_data = &regs->in_data;
 
 		gpiochip_add(&chips[i].chip);
 	}
 
+	soc_info->gpio_ctlrs = chips;
+	soc_info->gpio_ctlrs_num = DIV_ROUND_UP(ngpio, 32);
+
 	davinci_gpio_irq_setup();
 	return 0;
 }
@@ -360,7 +396,7 @@ static int __init davinci_gpio_irq_setup(void)
 		gpio_irqchip_unbanked.set_type = gpio_irq_type_unbanked;
 
 		/* default trigger: both edges */
-		g = gpio2controller(0);
+		g = gpio2regs(0);
 		__raw_writel(~0, &g->set_falling);
 		__raw_writel(~0, &g->set_rising);
 
@@ -385,7 +421,7 @@ static int __init davinci_gpio_irq_setup(void)
 		unsigned		i;
 
 		/* disabled by default, enabled only as needed */
-		g = gpio2controller(gpio);
+		g = gpio2regs(gpio);
 		__raw_writel(~0, &g->clr_falling);
 		__raw_writel(~0, &g->clr_rising);
 
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 50a955f..c85c795 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -34,6 +34,8 @@ struct davinci_timer_info {
 	unsigned int			clocksource_id;
 };
 
+struct davinci_gpio_controller;
+
 /* SoC specific init support */
 struct davinci_soc_info {
 	struct map_desc			*io_desc;
@@ -58,6 +60,8 @@ struct davinci_soc_info {
 	unsigned			gpio_num;
 	unsigned			gpio_irq;
 	unsigned			gpio_unbanked;
+	struct davinci_gpio_controller	*gpio_ctlrs;
+	int				gpio_ctlrs_num;
 	struct platform_device		*serial_dev;
 	struct emac_platform_data	*emac_pdata;
 	dma_addr_t			sram_dma;
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index bdab001..82591d0 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -45,23 +45,13 @@
 /* Convert GPIO signal to GPIO pin number */
 #define GPIO_TO_PIN(bank, gpio)	(16 * (bank) + (gpio))
 
-struct davinci_gpio_regs {
-	u32	dir;
-	u32	out_data;
-	u32	set_data;
-	u32	clr_data;
-	u32	in_data;
-	u32	set_rising;
-	u32	clr_rising;
-	u32	set_falling;
-	u32	clr_falling;
-	u32	intstat;
-};
-
 struct davinci_gpio_controller {
-	struct davinci_gpio_regs __iomem *regs;
 	struct gpio_chip	chip;
 	int			irq_base;
+	void __iomem		*regs;
+	void __iomem		*set_data;
+	void __iomem		*clr_data;
+	void __iomem		*in_data;
 };
 
 /* The __gpio_to_controller() and __gpio_mask() functions inline to constants
@@ -73,25 +63,16 @@ struct davinci_gpio_controller {
  *
  * These are NOT part of the cross-platform GPIO interface
  */
-static inline struct davinci_gpio_regs __iomem *
+static inline struct davinci_gpio_controller *
 __gpio_to_controller(unsigned gpio)
 {
-	void __iomem *ptr;
-	void __iomem *base = davinci_soc_info.gpio_base;
-
-	if (gpio < 32 * 1)
-		ptr = base + 0x10;
-	else if (gpio < 32 * 2)
-		ptr = base + 0x38;
-	else if (gpio < 32 * 3)
-		ptr = base + 0x60;
-	else if (gpio < 32 * 4)
-		ptr = base + 0x88;
-	else if (gpio < 32 * 5)
-		ptr = base + 0xb0;
-	else
-		ptr = NULL;
-	return ptr;
+	struct davinci_gpio_controller *ctlrs = davinci_soc_info.gpio_ctlrs;
+	int index = gpio / 32;
+
+	if (!ctlrs || index >= davinci_soc_info.gpio_ctlrs_num)
+		return NULL;
+
+	return ctlrs + index;
 }
 
 static inline u32 __gpio_mask(unsigned gpio)
@@ -107,16 +88,16 @@ static inline u32 __gpio_mask(unsigned gpio)
  */
 static inline void gpio_set_value(unsigned gpio, int value)
 {
-	if (__builtin_constant_p(value) && gpio < DAVINCI_N_GPIO) {
-		struct davinci_gpio_regs	__iomem *g;
-		u32			mask;
+	if (__builtin_constant_p(value) && gpio < davinci_soc_info.gpio_num) {
+		struct davinci_gpio_controller *ctlr;
+		u32				mask;
 
-		g = __gpio_to_controller(gpio);
+		ctlr = __gpio_to_controller(gpio);
 		mask = __gpio_mask(gpio);
 		if (value)
-			__raw_writel(mask, &g->set_data);
+			__raw_writel(mask, ctlr->set_data);
 		else
-			__raw_writel(mask, &g->clr_data);
+			__raw_writel(mask, ctlr->clr_data);
 		return;
 	}
 
@@ -134,18 +115,18 @@ static inline void gpio_set_value(unsigned gpio, int value)
  */
 static inline int gpio_get_value(unsigned gpio)
 {
-	struct davinci_gpio_regs	__iomem *g;
+	struct davinci_gpio_controller *ctlr;
 
-	if (!__builtin_constant_p(gpio) || gpio >= DAVINCI_N_GPIO)
+	if (!__builtin_constant_p(gpio) || gpio >= davinci_soc_info.gpio_num)
 		return __gpio_get_value(gpio);
 
-	g = __gpio_to_controller(gpio);
-	return __gpio_mask(gpio) & __raw_readl(&g->in_data);
+	ctlr = __gpio_to_controller(gpio);
+	return __gpio_mask(gpio) & __raw_readl(ctlr->in_data);
 }
 
 static inline int gpio_cansleep(unsigned gpio)
 {
-	if (__builtin_constant_p(gpio) && gpio < DAVINCI_N_GPIO)
+	if (__builtin_constant_p(gpio) && gpio < davinci_soc_info.gpio_num)
 		return 0;
 	else
 		return __gpio_cansleep(gpio);
-- 
1.6.3.3


From cyril at ti.com  Wed Apr 14 13:44:53 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 14:44:53 -0400
Subject: [PATCH v3 07/16] Davinci: gpio - struct renames
In-Reply-To: <1271270702-28307-7-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
Message-ID: <1271270702-28307-8-git-send-email-cyril@ti.com>

Renamed gpio structures to something more sensible:
	struct gpio_controller 	--> struct davinci_gpio_regs
	struct davinci_gpio	--> struct davinci_gpio_controller

This change also moves davinci_gpio_controller definition to gpio.h.
Eventually, the gpio registers structure will be moved to gpio.c and no longer
a common cross-soc definition.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
v3: reverted back on direction_in/out unification

 arch/arm/mach-davinci/gpio.c              |   48 ++++++++++++----------------
 arch/arm/mach-davinci/include/mach/gpio.h |   14 ++++++--
 2 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index 5a045e6..6c470a7 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -22,28 +22,22 @@
 
 static DEFINE_SPINLOCK(gpio_lock);
 
-struct davinci_gpio {
-	struct gpio_chip	chip;
-	struct gpio_controller	__iomem *regs;
-	int			irq_base;
-};
-
 #define chip2controller(chip)	\
-	container_of(chip, struct davinci_gpio, chip)
+	container_of(chip, struct davinci_gpio_controller, chip)
 
-static struct davinci_gpio chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
+static struct davinci_gpio_controller chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
 
 /* create a non-inlined version */
-static struct gpio_controller __iomem __init *gpio2controller(unsigned gpio)
+static struct davinci_gpio_regs __iomem __init *gpio2controller(unsigned gpio)
 {
 	return __gpio_to_controller(gpio);
 }
 
-static inline struct gpio_controller __iomem *irq2controller(int irq)
+static inline struct davinci_gpio_regs __iomem *irq2controller(int irq)
 {
-	struct gpio_controller __iomem *g;
+	struct davinci_gpio_regs __iomem *g;
 
-	g = (__force struct gpio_controller __iomem *)get_irq_chip_data(irq);
+	g = (__force struct davinci_gpio_regs __iomem *)get_irq_chip_data(irq);
 
 	return g;
 }
@@ -59,8 +53,8 @@ static int __init davinci_gpio_irq_setup(void);
 
 static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = chip2controller(chip);
-	struct gpio_controller __iomem *g = d->regs;
+	struct davinci_gpio_controller *d = chip2controller(chip);
+	struct davinci_gpio_regs __iomem *g = d->regs;
 	u32 temp;
 
 	spin_lock(&gpio_lock);
@@ -81,8 +75,8 @@ static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
  */
 static int davinci_gpio_get(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = chip2controller(chip);
-	struct gpio_controller __iomem *g = d->regs;
+	struct davinci_gpio_controller *d = chip2controller(chip);
+	struct davinci_gpio_regs __iomem *g = d->regs;
 
 	return (1 << offset) & __raw_readl(&g->in_data);
 }
@@ -90,8 +84,8 @@ static int davinci_gpio_get(struct gpio_chip *chip, unsigned offset)
 static int
 davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
 {
-	struct davinci_gpio *d = chip2controller(chip);
-	struct gpio_controller __iomem *g = d->regs;
+	struct davinci_gpio_controller *d = chip2controller(chip);
+	struct davinci_gpio_regs __iomem *g = d->regs;
 	u32 temp;
 	u32 mask = 1 << offset;
 
@@ -110,8 +104,8 @@ davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
 static void
 davinci_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
 {
-	struct davinci_gpio *d = chip2controller(chip);
-	struct gpio_controller __iomem *g = d->regs;
+	struct davinci_gpio_controller *d = chip2controller(chip);
+	struct davinci_gpio_regs __iomem *g = d->regs;
 
 	__raw_writel((1 << offset), value ? &g->set_data : &g->clr_data);
 }
@@ -173,7 +167,7 @@ pure_initcall(davinci_gpio_setup);
 
 static void gpio_irq_disable(unsigned irq)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2controller(irq);
 	u32 mask = (u32) get_irq_data(irq);
 
 	__raw_writel(mask, &g->clr_falling);
@@ -182,7 +176,7 @@ static void gpio_irq_disable(unsigned irq)
 
 static void gpio_irq_enable(unsigned irq)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2controller(irq);
 	u32 mask = (u32) get_irq_data(irq);
 	unsigned status = irq_desc[irq].status;
 
@@ -198,7 +192,7 @@ static void gpio_irq_enable(unsigned irq)
 
 static int gpio_irq_type(unsigned irq, unsigned trigger)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2controller(irq);
 	u32 mask = (u32) get_irq_data(irq);
 
 	if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
@@ -227,7 +221,7 @@ static struct irq_chip gpio_irqchip = {
 static void
 gpio_irq_handler(unsigned irq, struct irq_desc *desc)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2controller(irq);
 	u32 mask = 0xffff;
 
 	/* we only care about one bank */
@@ -265,7 +259,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
 
 static int gpio_to_irq_banked(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = chip2controller(chip);
+	struct davinci_gpio_controller *d = chip2controller(chip);
 
 	if (d->irq_base >= 0)
 		return d->irq_base + offset;
@@ -288,7 +282,7 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset)
 
 static int gpio_irq_type_unbanked(unsigned irq, unsigned trigger)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2controller(irq);
 	u32 mask = (u32) get_irq_data(irq);
 
 	if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
@@ -317,7 +311,7 @@ static int __init davinci_gpio_irq_setup(void)
 	u32		binten = 0;
 	unsigned	ngpio, bank_irq;
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
-	struct gpio_controller	__iomem *g;
+	struct davinci_gpio_regs	__iomem *g;
 
 	ngpio = soc_info->gpio_num;
 
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index 0099e6e..bdab001 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -45,7 +45,7 @@
 /* Convert GPIO signal to GPIO pin number */
 #define GPIO_TO_PIN(bank, gpio)	(16 * (bank) + (gpio))
 
-struct gpio_controller {
+struct davinci_gpio_regs {
 	u32	dir;
 	u32	out_data;
 	u32	set_data;
@@ -58,6 +58,12 @@ struct gpio_controller {
 	u32	intstat;
 };
 
+struct davinci_gpio_controller {
+	struct davinci_gpio_regs __iomem *regs;
+	struct gpio_chip	chip;
+	int			irq_base;
+};
+
 /* The __gpio_to_controller() and __gpio_mask() functions inline to constants
  * with constant parameters; or in outlined code they execute at runtime.
  *
@@ -67,7 +73,7 @@ struct gpio_controller {
  *
  * These are NOT part of the cross-platform GPIO interface
  */
-static inline struct gpio_controller __iomem *
+static inline struct davinci_gpio_regs __iomem *
 __gpio_to_controller(unsigned gpio)
 {
 	void __iomem *ptr;
@@ -102,7 +108,7 @@ static inline u32 __gpio_mask(unsigned gpio)
 static inline void gpio_set_value(unsigned gpio, int value)
 {
 	if (__builtin_constant_p(value) && gpio < DAVINCI_N_GPIO) {
-		struct gpio_controller	__iomem *g;
+		struct davinci_gpio_regs	__iomem *g;
 		u32			mask;
 
 		g = __gpio_to_controller(gpio);
@@ -128,7 +134,7 @@ static inline void gpio_set_value(unsigned gpio, int value)
  */
 static inline int gpio_get_value(unsigned gpio)
 {
-	struct gpio_controller	__iomem *g;
+	struct davinci_gpio_regs	__iomem *g;
 
 	if (!__builtin_constant_p(gpio) || gpio >= DAVINCI_N_GPIO)
 		return __gpio_get_value(gpio);
-- 
1.6.3.3


From cyril at ti.com  Wed Apr 14 13:45:00 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 14:45:00 -0400
Subject: [PATCH v3 14/16] Davinci: tnetv107x watchdog reset support
In-Reply-To: <1271270702-28307-14-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
	<1271270702-28307-9-git-send-email-cyril@ti.com>
	<1271270702-28307-10-git-send-email-cyril@ti.com>
	<1271270702-28307-11-git-send-email-cyril@ti.com>
	<1271270702-28307-12-git-send-email-cyril@ti.com>
	<1271270702-28307-13-git-send-email-cyril@ti.com>
	<1271270702-28307-14-git-send-email-cyril@ti.com>
Message-ID: <1271270702-28307-15-git-send-email-cyril@ti.com>

This patch adds support for tnetv107x cpu reset using the soc's watchdog
timer.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 arch/arm/mach-davinci/devices-tnetv107x.c      |   21 +++++
 arch/arm/mach-davinci/include/mach/system.h    |    5 +
 arch/arm/mach-davinci/include/mach/tnetv107x.h |    1 +
 arch/arm/mach-davinci/tnetv107x.c              |  107 ++++++++++++++++++++++++
 4 files changed, 134 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-tnetv107x.c b/arch/arm/mach-davinci/devices-tnetv107x.c
index ab54c91..43cd2ea 100644
--- a/arch/arm/mach-davinci/devices-tnetv107x.c
+++ b/arch/arm/mach-davinci/devices-tnetv107x.c
@@ -26,6 +26,7 @@
 #define TNETV107X_TPCC_BASE			0x01c00000
 #define TNETV107X_TPTC0_BASE			0x01c10000
 #define TNETV107X_TPTC1_BASE			0x01c10400
+#define TNETV107X_WDOG_BASE			0x08086700
 
 /* TNETV107X specific EDMA3 information */
 #define EDMA_TNETV107X_NUM_DMACH	64
@@ -103,11 +104,31 @@ static struct platform_device edma_device = {
 	.dev.platform_data = edma_info,
 };
 
+static struct resource wdt_resources[] = {
+	{
+		.start	= TNETV107X_WDOG_BASE,
+		.end	= TNETV107X_WDOG_BASE + SZ_4K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+struct platform_device tnetv107x_wdt_device = {
+	.name		= "watchdog",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(wdt_resources),
+	.resource	= wdt_resources,
+};
+
 void __init tnetv107x_edma_init(void)
 {
 	platform_device_register(&edma_device);
 }
 
+void __init tnetv107x_watchdog_init(void)
+{
+	platform_device_register(&tnetv107x_wdt_device);
+}
+
 void __init tnetv107x_serial_init(struct plat_serial8250_port* ports)
 {
 	int i;
diff --git a/arch/arm/mach-davinci/include/mach/system.h b/arch/arm/mach-davinci/include/mach/system.h
index 90be3f6..141d910 100644
--- a/arch/arm/mach-davinci/include/mach/system.h
+++ b/arch/arm/mach-davinci/include/mach/system.h
@@ -16,8 +16,10 @@
 
 extern struct platform_device davinci_wdt_device;
 extern struct platform_device da8xx_wdt_device;
+extern struct platform_device tnetv107x_wdt_device;
 
 extern void davinci_watchdog_reset(struct platform_device *);
+extern void tnetv107x_watchdog_reset(struct platform_device *);
 
 static inline void arch_idle(void)
 {
@@ -31,6 +33,9 @@ static inline void arch_reset(char mode, const char *cmd)
 
 	if (cpu_class_is_da8xx())
 		davinci_watchdog_reset(&da8xx_wdt_device);
+
+	if (cpu_class_is_tnetv107x())
+		tnetv107x_watchdog_reset(&tnetv107x_wdt_device);
 }
 
 #endif /* __ASM_ARCH_SYSTEM_H */
diff --git a/arch/arm/mach-davinci/include/mach/tnetv107x.h b/arch/arm/mach-davinci/include/mach/tnetv107x.h
index 5eafdb8..0ad5466 100644
--- a/arch/arm/mach-davinci/include/mach/tnetv107x.h
+++ b/arch/arm/mach-davinci/include/mach/tnetv107x.h
@@ -59,6 +59,7 @@
 extern void __init tnetv107x_init(void);
 extern void __init tnetv107x_gpio_init(void);
 extern void __init tnetv107x_edma_init(void);
+extern void __init tnetv107x_watchdog_init(void);
 extern void __init tnetv107x_irq_init(void);
 extern void __init tnetv107x_serial_init(struct plat_serial8250_port* ports);
 #endif
diff --git a/arch/arm/mach-davinci/tnetv107x.c b/arch/arm/mach-davinci/tnetv107x.c
index a444ef7..fc5085d 100644
--- a/arch/arm/mach-davinci/tnetv107x.c
+++ b/arch/arm/mach-davinci/tnetv107x.c
@@ -81,6 +81,18 @@ struct sspll_regs {
 	u32	diag;
 };
 
+/* Watchdog Timer Registers */
+struct wdt_regs {
+	u32	kick_lock;
+	u32	kick;
+	u32	change_lock;
+	u32	change ;
+	u32	disable_lock;
+	u32	disable;
+	u32	prescale_lock;
+	u32	prescale;
+};
+
 static struct clk_ctrl_regs __iomem *clk_ctrl_regs;
 
 static struct sspll_regs __iomem *sspll_regs[N_PLLS];
@@ -1173,3 +1185,98 @@ static unsigned long clk_sspll_recalc(struct clk *clk)
 
 	return ret;
 }
+
+static int tnetv107x_wdt_set_period(struct wdt_regs __iomem *regs,
+		unsigned long msec, unsigned long refclk)
+{
+	unsigned long change;
+	unsigned long count;
+	unsigned long prescale = 1;
+
+	refclk /= 1000;
+
+	/* compute prescale and change reg values */
+	count = refclk * msec;
+
+	if (count > 0xffff) {
+		change = count / 0xffff + 1;
+		prescale = count / change;
+	}    else {
+		change =  count;
+	}
+
+	__raw_writel(0x5a5a, &regs->prescale_lock);
+	if ((__raw_readl(&regs->prescale_lock) & 0x3) != 1)
+		return -EIO;
+
+	__raw_writel(0xa5a5, &regs->prescale_lock);
+	if ((__raw_readl(&regs->prescale_lock) & 0x3) != 3)
+		return -EIO;
+
+	__raw_writel(prescale - 1, &regs->prescale);
+
+	__raw_writel(0x6666, &regs->change_lock);
+	if ((__raw_readl(&regs->change_lock) & 0x3) != 1)
+		return -EIO;
+
+	__raw_writel(0xbbbb, &regs->change_lock);
+	if ((__raw_readl(&regs->change_lock) & 0x3) != 3)
+		return -EIO;
+
+	__raw_writel(change, &regs->change);
+	return 0;
+}
+
+static int tnetv107x_wdt_ctrl(struct wdt_regs __iomem *regs, int enable)
+{
+
+	enable = enable ? 1 : 0;
+
+	__raw_writel(0x7777, &regs->disable_lock);
+	if ((__raw_readl(&regs->disable_lock) & 0x3) != 1)
+		return -EIO;
+
+	__raw_writel(0xcccc, &regs->disable_lock);
+	if ((__raw_readl(&regs->disable_lock) & 0x3) != 2)
+		return -EIO;
+
+	__raw_writel(0xdddd, &regs->disable_lock);
+	if ((__raw_readl(&regs->disable_lock) & 0x3) != 3)
+		return -EIO;
+
+	__raw_writel(enable, &regs->disable);
+	return 0;
+}
+
+static int tnetv107x_wdt_kick(struct wdt_regs __iomem *regs)
+{
+	__raw_writel(0x5555, &regs->kick_lock);
+	if ((__raw_readl(&regs->kick_lock) & 0x3) != 1)
+		return -EIO;
+
+	__raw_writel(0xaaaa, &regs->kick_lock);
+	if ((__raw_readl(&regs->kick_lock) & 0x3) != 3)
+		return -EIO;
+
+	__raw_writel(1, &regs->kick);
+	return 0;
+}
+
+void tnetv107x_watchdog_reset(struct platform_device *pdev)
+{
+	struct wdt_regs __iomem *regs;
+	struct clk		*wdt_clk;
+	unsigned long		wdt_clk_rate;
+
+	regs = ioremap(pdev->resource[0].start, SZ_4K);
+	wdt_clk = clk_get(&pdev->dev, NULL);
+	if (WARN_ON(IS_ERR(wdt_clk)))
+		return;
+	clk_enable(wdt_clk);
+	wdt_clk_rate	= clk_get_rate(wdt_clk);
+
+	tnetv107x_wdt_ctrl(regs, 0);
+	tnetv107x_wdt_set_period(regs, 1, wdt_clk_rate);
+	tnetv107x_wdt_ctrl(regs, 1);
+	tnetv107x_wdt_kick(regs);
+}
-- 
1.6.3.3


From cyril at ti.com  Wed Apr 14 13:44:55 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 14:44:55 -0400
Subject: [PATCH v3 09/16] Davinci: gpio - controller type support
In-Reply-To: <1271270702-28307-9-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
	<1271270702-28307-9-git-send-email-cyril@ti.com>
Message-ID: <1271270702-28307-10-git-send-email-cyril@ti.com>

This patch allows for gpio controllers that deviate from those found on
traditional davinci socs.  davinci_soc_info has an added field to indicate the
soc-specific gpio controller type.  The gpio initialization code then bails
out of necessary.

More elements (tnetv107x) to be added later into enum davinci_gpio_type.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
v3: added missing mach/gpio.h include in da8xx files

 arch/arm/mach-davinci/da830.c               |    2 ++
 arch/arm/mach-davinci/da850.c               |    2 ++
 arch/arm/mach-davinci/dm355.c               |    1 +
 arch/arm/mach-davinci/dm365.c               |    1 +
 arch/arm/mach-davinci/dm644x.c              |    1 +
 arch/arm/mach-davinci/dm646x.c              |    1 +
 arch/arm/mach-davinci/gpio.c                |    3 +++
 arch/arm/mach-davinci/include/mach/common.h |    1 +
 arch/arm/mach-davinci/include/mach/gpio.h   |    4 ++++
 9 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 168f277..107bfb9 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -19,6 +19,7 @@
 #include <mach/common.h>
 #include <mach/time.h>
 #include <mach/da8xx.h>
+#include <mach/gpio.h>
 
 #include "clock.h"
 #include "mux.h"
@@ -1199,6 +1200,7 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
 	.intc_irq_prios		= da830_default_priorities,
 	.intc_irq_num		= DA830_N_CP_INTC_IRQ,
 	.timer_info		= &da830_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DA8XX_GPIO_BASE),
 	.gpio_num		= 128,
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 27eb32e..04d4dc1 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -27,6 +27,7 @@
 #include <mach/da8xx.h>
 #include <mach/cpufreq.h>
 #include <mach/pm.h>
+#include <mach/gpio.h>
 
 #include "clock.h"
 #include "mux.h"
@@ -1084,6 +1085,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.intc_irq_prios		= da850_default_priorities,
 	.intc_irq_num		= DA850_N_CP_INTC_IRQ,
 	.timer_info		= &da850_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DA8XX_GPIO_BASE),
 	.gpio_num		= 144,
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 5efce70..f9a54ff 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -859,6 +859,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.intc_irq_prios		= dm355_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm355_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM355_GPIOBNK0,
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 871be5a..d81c440 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1063,6 +1063,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.intc_irq_prios		= dm365_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm365_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM365_GPIO0,
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 23cbe9d..4af349e 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -748,6 +748,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.intc_irq_prios 	= dm644x_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm644x_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
 	.gpio_num		= 71,
 	.gpio_irq		= IRQ_GPIOBNK0,
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index b67b997..899859c 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -858,6 +858,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.intc_irq_prios		= dm646x_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm646x_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
 	.gpio_num		= 43, /* Only 33 usable */
 	.gpio_irq		= IRQ_DM646X_GPIOBNK0,
diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index e15dbc8..419254a 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -145,6 +145,9 @@ static int __init davinci_gpio_setup(void)
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
 	struct davinci_gpio_regs *regs;
 
+	if (soc_info->gpio_type != GPIO_TYPE_DAVINCI)
+		return 0;
+
 	/*
 	 * The gpio banks conceptually expose a segmented bitmap,
 	 * and "ngpio" is one more than the largest zero-based
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index c85c795..174619b 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -56,6 +56,7 @@ struct davinci_soc_info {
 	u8				*intc_irq_prios;
 	unsigned long			intc_irq_num;
 	struct davinci_timer_info	*timer_info;
+	int				gpio_type;
 	void __iomem			*gpio_base;
 	unsigned			gpio_num;
 	unsigned			gpio_irq;
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index 82591d0..9a71a26 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -21,6 +21,10 @@
 
 #define DAVINCI_GPIO_BASE 0x01C67000
 
+enum davinci_gpio_type {
+	GPIO_TYPE_DAVINCI = 0,
+};
+
 /*
  * basic gpio routines
  *
-- 
1.6.3.3


From cyril at ti.com  Wed Apr 14 13:44:56 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 14:44:56 -0400
Subject: [PATCH v3 10/16] Davinci: gpio - fine grained locking
In-Reply-To: <1271270702-28307-10-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
	<1271270702-28307-9-git-send-email-cyril@ti.com>
	<1271270702-28307-10-git-send-email-cyril@ti.com>
Message-ID: <1271270702-28307-11-git-send-email-cyril@ti.com>

This patch eliminates the global gpio_lock, and implements a per-controller
lock instead.  This also switches to irqsave/irqrestore locks in case gpios
are manipulated in isr.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
v3: reverted back on direction_in/out unification
v3: changed gpio controller's registers field type to void, reflecting the
    fact that different underlying gpio controllers can have different
    register layouts

 arch/arm/mach-davinci/gpio.c              |   14 ++++++++------
 arch/arm/mach-davinci/include/mach/gpio.h |    3 +++
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index 419254a..60e59fc 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -33,8 +33,6 @@ struct davinci_gpio_regs {
 	u32	intstat;
 };
 
-static DEFINE_SPINLOCK(gpio_lock);
-
 #define chip2controller(chip)	\
 	container_of(chip, struct davinci_gpio_controller, chip)
 
@@ -83,13 +81,14 @@ static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
 {
 	struct davinci_gpio_controller *d = chip2controller(chip);
 	struct davinci_gpio_regs __iomem *g = d->regs;
+	unsigned long flags;
 	u32 temp;
 
-	spin_lock(&gpio_lock);
+	spin_lock_irqsave(&d->lock, flags);
 	temp = __raw_readl(&g->dir);
 	temp |= (1 << offset);
 	__raw_writel(temp, &g->dir);
-	spin_unlock(&gpio_lock);
+	spin_unlock_irqrestore(&d->lock, flags);
 
 	return 0;
 }
@@ -114,15 +113,16 @@ davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
 {
 	struct davinci_gpio_controller *d = chip2controller(chip);
 	struct davinci_gpio_regs __iomem *g = d->regs;
+	unsigned long flags;
 	u32 temp;
 	u32 mask = 1 << offset;
 
-	spin_lock(&gpio_lock);
+	spin_lock_irqsave(&d->lock, flags);
 	temp = __raw_readl(&g->dir);
 	temp &= ~mask;
 	__raw_writel(mask, value ? &g->set_data : &g->clr_data);
 	__raw_writel(temp, &g->dir);
-	spin_unlock(&gpio_lock);
+	spin_unlock_irqrestore(&d->lock, flags);
 	return 0;
 }
 
@@ -175,6 +175,8 @@ static int __init davinci_gpio_setup(void)
 		if (chips[i].chip.ngpio > 32)
 			chips[i].chip.ngpio = 32;
 
+		spin_lock_init(&chips[i].lock);
+
 		regs = gpio2regs(base);
 		chips[i].regs = regs;
 		chips[i].set_data = &regs->set_data;
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index 9a71a26..e3cbef1 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -14,6 +14,8 @@
 #define	__DAVINCI_GPIO_H
 
 #include <linux/io.h>
+#include <linux/spinlock.h>
+
 #include <asm-generic/gpio.h>
 
 #include <mach/irqs.h>
@@ -51,6 +53,7 @@ enum davinci_gpio_type {
 
 struct davinci_gpio_controller {
 	struct gpio_chip	chip;
+	spinlock_t		lock;
 	int			irq_base;
 	void __iomem		*regs;
 	void __iomem		*set_data;
-- 
1.6.3.3


From cyril at ti.com  Wed Apr 14 13:45:02 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 14:45:02 -0400
Subject: [PATCH v3 16/16] Davinci: tnetv107x evm board initial support
In-Reply-To: <1271270702-28307-16-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
	<1271270702-28307-9-git-send-email-cyril@ti.com>
	<1271270702-28307-10-git-send-email-cyril@ti.com>
	<1271270702-28307-11-git-send-email-cyril@ti.com>
	<1271270702-28307-12-git-send-email-cyril@ti.com>
	<1271270702-28307-13-git-send-email-cyril@ti.com>
	<1271270702-28307-14-git-send-email-cyril@ti.com>
	<1271270702-28307-15-git-send-email-cyril@ti.com>
	<1271270702-28307-16-git-send-email-cyril@ti.com>
Message-ID: <1271270702-28307-17-git-send-email-cyril@ti.com>

Added support for tnetv107x evaluation module.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
v3: moved some base address and edma channel definitions here
v3: minor formatting changes

 arch/arm/mach-davinci/Kconfig               |    7 +
 arch/arm/mach-davinci/Makefile              |    1 +
 arch/arm/mach-davinci/board-tnetv107x-evm.c |  281 +++++++++++++++++++++++++++
 3 files changed, 289 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-davinci/board-tnetv107x-evm.c

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index a67b47b..71f90f8 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -178,6 +178,13 @@ config DA850_UI_RMII
 
 endchoice
 
+config MACH_TNETV107X
+	bool "TI TNETV107X Reference Platform"
+	default ARCH_DAVINCI_TNETV107X
+	depends on ARCH_DAVINCI_TNETV107X
+	help
+	  Say Y here to select the TI TNETV107X Evaluation Module.
+
 config DAVINCI_MUX
 	bool "DAVINCI multiplexing support"
 	depends on ARCH_DAVINCI
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 62c5116..eab4c0f 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM)	+= board-dm646x-evm.o cdce949.o
 obj-$(CONFIG_MACH_DAVINCI_DM365_EVM)	+= board-dm365-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA830_EVM)	+= board-da830-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)	+= board-da850-evm.o
+obj-$(CONFIG_MACH_TNETV107X)		+= board-tnetv107x-evm.o
 
 # Power Management
 obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c b/arch/arm/mach-davinci/board-tnetv107x-evm.c
new file mode 100644
index 0000000..2fa06ec
--- /dev/null
+++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
@@ -0,0 +1,281 @@
+/*
+ * TI TNETV107X EVM board
+ *
+ * Author: Cyril Chemparathy <cyril at ti.com>
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Derived from: arch/arm/mach-davinci/board-da830-evm.c
+ * Original copyrights follow.
+ *
+ * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/console.h>
+#include <linux/dma-mapping.h>
+#include <linux/interrupt.h>
+#include <linux/gpio.h>
+#include <linux/delay.h>
+#include <linux/serial_8250.h>
+#include <linux/platform_device.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/physmap.h>
+#include <asm/mach/arch.h>
+#include <asm/mach-types.h>
+
+#include <mach/irqs.h>
+#include <mach/edma.h>
+#include <mach/mmc.h>
+#include <mach/serial.h>
+#include <mach/mux.h>
+#include <mach/nand.h>
+#include <mach/tnetv107x.h>
+
+/* Base addresses for on-chip devices */
+#define TNETV107X_SDIO1_BASE			0x08088800
+#define TNETV107X_ASYNC_EMIF_CNTRL_BASE		0x08200000
+#define TNETV107X_ASYNC_EMIF_DATA_CE0_BASE	0x30000000
+#define TNETV107X_DDR_BASE			0x80000000
+
+#define TNETV107X_DMACH_SDIO1_RX		28
+#define TNETV107X_DMACH_SDIO1_TX		29
+
+#define TNETV107X_EVM_MMC_WP_GPIO		21
+#define TNETV107X_EVM_MMC_CD_GPIO		24
+
+static struct plat_serial8250_port tnetv107x_serial_pdata[] = {
+	{
+		.mapbase	= TNETV107X_UART0_BASE,
+		.irq		= IRQ_TNETV107X_UART0,
+		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
+					UPF_FIXED_TYPE | UPF_IOREMAP,
+		.type		= PORT_AR7,
+		.iotype		= UPIO_MEM32,
+		.regshift	= 2,
+	},
+	{
+		.mapbase	= TNETV107X_UART1_BASE,
+		.irq		= IRQ_TNETV107X_UART1,
+		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
+					UPF_FIXED_TYPE | UPF_IOREMAP,
+		.type		= PORT_AR7,
+		.iotype		= UPIO_MEM32,
+		.regshift	= 2,
+	},
+	{
+		.flags	= 0,
+	},
+};
+
+static struct platform_device tnetv107x_serial_device = {
+	.name			= "serial8250",
+	.id			= PLAT8250_DEV_PLATFORM,
+	.dev			= {
+		.platform_data	= tnetv107x_serial_pdata,
+	},
+};
+
+static int tnetv107x_evm_mmc_get_ro(int index)
+{
+	return gpio_get_value(TNETV107X_EVM_MMC_WP_GPIO);
+}
+
+static int tnetv107x_evm_mmc_get_cd(int index)
+{
+	return !gpio_get_value(TNETV107X_EVM_MMC_CD_GPIO);
+}
+
+static struct resource tnetv107x_evm_mmc_resources[] = {
+	{ /* Memory mapped registers */
+		.start	= TNETV107X_SDIO1_BASE,
+		.end	= TNETV107X_SDIO1_BASE + 0x0ff,
+		.flags	= IORESOURCE_MEM
+	},
+	{ /* MMC interrupt */
+		.start	= IRQ_TNETV107X_MMC1,
+		.flags	= IORESOURCE_IRQ
+	},
+	{ /* SDIO interrupt */
+		.start	= IRQ_TNETV107X_SDIO1,
+		.flags	= IORESOURCE_IRQ
+	},
+	{ /* DMA RX */
+		.start	= EDMA_CTLR_CHAN(0, TNETV107X_DMACH_SDIO1_RX),
+		.flags	= IORESOURCE_DMA
+	},
+	{ /* DMA TX */
+		.start	= EDMA_CTLR_CHAN(0, TNETV107X_DMACH_SDIO1_TX),
+		.flags	= IORESOURCE_DMA
+	},
+};
+
+static struct davinci_mmc_config tnetv107x_evm_mmc_config = {
+	.get_cd		= tnetv107x_evm_mmc_get_cd,
+	.get_ro		= tnetv107x_evm_mmc_get_ro,
+	.wires		= 4,
+	.max_freq	= 50000000,
+	.caps		= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
+	.version	= MMC_CTLR_VERSION_1,
+};
+
+static u64 tnetv107x_evm_mmc_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device tnetv107x_evm_mmc_device = {
+	.name		= "davinci_mmc",
+	.id		= 1,
+	.dev		= {
+		.dma_mask		= &tnetv107x_evm_mmc_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+		.platform_data		= &tnetv107x_evm_mmc_config,
+	},
+	.num_resources	= ARRAY_SIZE(tnetv107x_evm_mmc_resources),
+	.resource	= tnetv107x_evm_mmc_resources
+};
+
+static const short tnetv107x_sdio1_pins[] = {
+	TNETV107X_SDIO1_CLK_1,		TNETV107X_SDIO1_CMD_1,
+	TNETV107X_SDIO1_DATA0_1,	TNETV107X_SDIO1_DATA1_1,
+	TNETV107X_SDIO1_DATA2_1,	TNETV107X_SDIO1_DATA3_1,
+	-1
+};
+
+const short tnetv107x_uart1_pins[] = {
+	TNETV107X_UART1_RD,		TNETV107X_UART1_TD,
+	-1
+};
+
+static const short tnetv107x_gpio_pins[] = {
+	TNETV107X_GPIO21, TNETV107X_GPIO24, TNETV107X_GPIO23,
+	-1
+};
+
+static struct mtd_partition tnetv107x_evm_nand_partitions[] = {
+	/* bootloader (U-Boot, etc) in first 12 sectors */
+	{
+		.name		= "bootloader",
+		.offset		= 0,
+		.size		= (12*SZ_128K),
+		.mask_flags	= MTD_WRITEABLE,	/* force read-only */
+	},
+	/* bootloader params in the next sector */
+	{
+		.name		= "params",
+		.offset		= MTDPART_OFS_NXTBLK,
+		.size		= SZ_128K,
+		.mask_flags	= MTD_WRITEABLE,	/* force read-only */
+	},
+	/* kernel */
+	{
+		.name		= "kernel",
+		.offset		= MTDPART_OFS_NXTBLK,
+		.size		= SZ_4M,
+		.mask_flags	= 0,
+	},
+	/* file system */
+	{
+		.name		= "filesystem",
+		.offset		= MTDPART_OFS_NXTBLK,
+		.size		= MTDPART_SIZ_FULL,
+		.mask_flags	= 0,
+	}
+};
+
+static struct davinci_nand_pdata tnetv107x_evm_nand_data = {
+	.mask_cle	= 0x4000,
+	.mask_ale	= 0x2000,
+	.parts		= tnetv107x_evm_nand_partitions,
+	.nr_parts	= ARRAY_SIZE(tnetv107x_evm_nand_partitions),
+	.ecc_mode	= NAND_ECC_HW,
+};
+
+static struct resource tnetv107x_evm_nand_resources[] = {
+	{
+		.start		= TNETV107X_ASYNC_EMIF_DATA_CE0_BASE,
+		.end		= TNETV107X_ASYNC_EMIF_DATA_CE0_BASE +
+					SZ_32K - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+	{
+		.start		= TNETV107X_ASYNC_EMIF_CNTRL_BASE,
+		.end		= TNETV107X_ASYNC_EMIF_CNTRL_BASE +
+					SZ_4K - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device tnetv107x_evm_nand_device = {
+	.name		= "davinci_nand",
+	.id		= 0,	/* chip select 0 */
+	.dev		= {
+		.platform_data	= &tnetv107x_evm_nand_data,
+	},
+	.num_resources	= ARRAY_SIZE(tnetv107x_evm_nand_resources),
+	.resource	= tnetv107x_evm_nand_resources,
+};
+
+static struct platform_device *tnetv107x_evm_devices[] __initdata = {
+	&tnetv107x_serial_device,
+	&tnetv107x_evm_nand_device,
+	&tnetv107x_evm_mmc_device,
+};
+
+static __init void tnetv107x_evm_board_init(void)
+{
+	int status;
+
+	davinci_cfg_reg_list(tnetv107x_sdio1_pins);
+	davinci_cfg_reg_list(tnetv107x_uart1_pins);
+	davinci_cfg_reg_list(tnetv107x_gpio_pins);
+
+	tnetv107x_edma_init();
+	tnetv107x_watchdog_init();
+	tnetv107x_serial_init(tnetv107x_serial_pdata);
+
+	status = gpio_request(TNETV107X_EVM_MMC_WP_GPIO, "MMC WP\n");
+	if (status < 0) {
+		printk(KERN_ERR "cannot open mmcsd write protect gpio %d\n",
+				TNETV107X_EVM_MMC_WP_GPIO);
+		tnetv107x_evm_mmc_config.get_ro = NULL;
+	} else {
+		gpio_direction_input(TNETV107X_EVM_MMC_WP_GPIO);
+	}
+
+	status = gpio_request(TNETV107X_EVM_MMC_CD_GPIO, "MMC CD\n");
+	if (status < 0) {
+		printk(KERN_ERR "cannot open mmcsd card detect gpio %d\n",
+				TNETV107X_EVM_MMC_CD_GPIO);
+		tnetv107x_evm_mmc_config.get_cd = NULL;
+	} else {
+		gpio_direction_input(TNETV107X_EVM_MMC_CD_GPIO);
+	}
+
+	platform_add_devices(tnetv107x_evm_devices,
+				ARRAY_SIZE(tnetv107x_evm_devices));
+}
+
+#ifdef CONFIG_SERIAL_8250_CONSOLE
+static int __init tnetv107x_evm_console_init(void)
+{
+	return add_preferred_console("ttyS", 1, "115200");
+}
+console_initcall(tnetv107x_evm_console_init);
+#endif
+
+static void __init map_io(void)
+{
+	tnetv107x_init();
+}
+
+MACHINE_START(TNETV107X, "TNETV107X EVM")
+	.phys_io	= TNETV107X_IO_BASE,
+	.io_pg_offst	= (TNETV107X_IO_VIRT >> 18) & 0xfffc,
+	.boot_params	= (TNETV107X_DDR_BASE + 0x100),
+	.map_io		= map_io,
+	.init_irq	= tnetv107x_irq_init,
+	.timer		= &davinci_timer,
+	.init_machine	= tnetv107x_evm_board_init,
+MACHINE_END
-- 
1.6.3.3


From cyril at ti.com  Wed Apr 14 13:44:57 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 14:44:57 -0400
Subject: [PATCH v3 11/16] Davinci: tnetv107x decompresser uart definitions
In-Reply-To: <1271270702-28307-11-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
	<1271270702-28307-9-git-send-email-cyril@ti.com>
	<1271270702-28307-10-git-send-email-cyril@ti.com>
	<1271270702-28307-11-git-send-email-cyril@ti.com>
Message-ID: <1271270702-28307-12-git-send-email-cyril@ti.com>

Added definitions for tnetv107x uart base addresses, and modified base address
selection for kernel decompressor to check for tnetv107x machine type.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
v3: migrated to uncompress.h based implementation added earlier in this series

 arch/arm/mach-davinci/include/mach/serial.h     |    8 ++++++++
 arch/arm/mach-davinci/include/mach/uncompress.h |    7 +++++++
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/include/mach/serial.h b/arch/arm/mach-davinci/include/mach/serial.h
index 8829dde..34b64be 100644
--- a/arch/arm/mach-davinci/include/mach/serial.h
+++ b/arch/arm/mach-davinci/include/mach/serial.h
@@ -33,6 +33,14 @@
 #define DA8XX_UART1_BASE	(IO_PHYS + 0x10c000)
 #define DA8XX_UART2_BASE	(IO_PHYS + 0x10d000)
 
+#define TNETV107X_UART0_BASE	(0x08108100)
+#define TNETV107X_UART1_BASE	(0x08088400)
+#define TNETV107X_UART2_BASE	(0x08108300)
+
+#define TNETV107X_UART0_VIRT	IOMEM(0xfee08100)
+#define TNETV107X_UART1_VIRT	IOMEM(0xfed88400)
+#define TNETV107X_UART2_VIRT	IOMEM(0xfee08300)
+
 /* DaVinci UART register offsets */
 #define UART_DAVINCI_PWREMU		0x0c
 #define UART_DM646X_SCR			0x10
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
index 20c23a3..15a6192 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -63,6 +63,10 @@ static inline void set_uart_info(u32 phys, void * __iomem virt)
 	_DEBUG_LL_ENTRY(machine, DA8XX_UART##port##_BASE,	\
 			IO_ADDRESS(DA8XX_UART##port##_BASE))
 
+#define DEBUG_LL_TNETV107X(machine, port)			\
+	_DEBUG_LL_ENTRY(machine, TNETV107X_UART##port##_BASE,	\
+			TNETV107X_UART##port##_VIRT)
+
 static inline void __arch_decomp_setup(unsigned long arch_id)
 {
 	/*
@@ -84,6 +88,9 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
 		/* DA8xx boards */
 		DEBUG_LL_DA8XX(davinci_da830_evm,	2);
 		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
+
+		/* TNETV107x boards */
+		DEBUG_LL_TNETV107X(tnetv107x,		1);
 	} while (0);
 }
 
-- 
1.6.3.3


From cyril at ti.com  Wed Apr 14 13:44:58 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 14:44:58 -0400
Subject: [PATCH v3 12/16] Davinci: tnetv107x soc specific header
In-Reply-To: <1271270702-28307-12-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
	<1271270702-28307-9-git-send-email-cyril@ti.com>
	<1271270702-28307-10-git-send-email-cyril@ti.com>
	<1271270702-28307-11-git-send-email-cyril@ti.com>
	<1271270702-28307-12-git-send-email-cyril@ti.com>
Message-ID: <1271270702-28307-13-git-send-email-cyril@ti.com>

Added tnetv107x soc specific definitions.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
v3: removed most base address definitions, moved necessary definitions to
    tnetv107x.c or devices-tnetv107x.c as appropriate

 arch/arm/mach-davinci/include/mach/tnetv107x.h |   66 ++++++++++++++++++++++++
 1 files changed, 66 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-davinci/include/mach/tnetv107x.h

diff --git a/arch/arm/mach-davinci/include/mach/tnetv107x.h b/arch/arm/mach-davinci/include/mach/tnetv107x.h
new file mode 100644
index 0000000..5eafdb8
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/tnetv107x.h
@@ -0,0 +1,66 @@
+/*
+ * Chip specific defines for TNETV107X SoC
+ *
+ * Author: Cyril Chemparathy <cyril at ti.com>
+ *
+ * 2009 (c) Texas Instruments, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#ifndef __ASM_ARCH_DAVINCI_TNETV107X_H
+#define __ASM_ARCH_DAVINCI_TNETV107X_H
+
+#include <asm/sizes.h>
+
+/*
+ * Fixed mapping for early init starts here. If low-level debug is enabled,
+ * this area also gets mapped via io_pg_offset and io_phys by the boot code.
+ * To fit in with the io_pg_offset calculation, the io base address selected
+ * here _must_ be a multiple of 2^20.
+ */
+#define TNETV107X_IO_BASE	0x08000000
+#define TNETV107X_IO_VIRT	(IO_VIRT + SZ_1M)
+
+#define PINMUX0		(0 << 2)
+#define PINMUX1		(1 << 2)
+#define PINMUX2		(2 << 2)
+#define PINMUX3		(3 << 2)
+#define PINMUX4		(4 << 2)
+#define PINMUX5		(5 << 2)
+#define PINMUX6		(6 << 2)
+#define PINMUX7		(7 << 2)
+#define PINMUX8		(8 << 2)
+#define PINMUX9		(9 << 2)
+#define PINMUX10	(10 << 2)
+#define PINMUX11	(11 << 2)
+#define PINMUX12	(12 << 2)
+#define PINMUX13	(13 << 2)
+#define PINMUX14	(14 << 2)
+#define PINMUX15	(15 << 2)
+#define PINMUX16	(16 << 2)
+#define PINMUX17	(17 << 2)
+#define PINMUX18	(18 << 2)
+#define PINMUX19	(19 << 2)
+#define PINMUX20	(20 << 2)
+#define PINMUX21	(21 << 2)
+#define PINMUX22	(22 << 2)
+#define PINMUX23	(23 << 2)
+#define PINMUX24	(24 << 2)
+#define PINMUX25	(25 << 2)
+#define PINMUX26	(26 << 2)
+
+#define TNETV107X_N_GPIOS	65
+
+#ifndef __ASSEMBLY__
+
+#include <linux/serial_8250.h>
+
+extern void __init tnetv107x_init(void);
+extern void __init tnetv107x_gpio_init(void);
+extern void __init tnetv107x_edma_init(void);
+extern void __init tnetv107x_irq_init(void);
+extern void __init tnetv107x_serial_init(struct plat_serial8250_port* ports);
+#endif
+
+#endif /* __ASM_ARCH_DAVINCI_TNETV107X_H */
-- 
1.6.3.3


From cyril at ti.com  Wed Apr 14 13:45:01 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 14:45:01 -0400
Subject: [PATCH v3 15/16] Davinci: tnetv107x initial gpio support
In-Reply-To: <1271270702-28307-15-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
	<1271270702-28307-9-git-send-email-cyril@ti.com>
	<1271270702-28307-10-git-send-email-cyril@ti.com>
	<1271270702-28307-11-git-send-email-cyril@ti.com>
	<1271270702-28307-12-git-send-email-cyril@ti.com>
	<1271270702-28307-13-git-send-email-cyril@ti.com>
	<1271270702-28307-14-git-send-email-cyril@ti.com>
	<1271270702-28307-15-git-send-email-cyril@ti.com>
Message-ID: <1271270702-28307-16-git-send-email-cyril@ti.com>

This patch adds support for the tnetv107x gpio controller.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
v3: switched to spin_lock_irq from local_irq_save/restore
v3: migrated to restructured gpio framework from earlier patches in this
    series

 arch/arm/mach-davinci/Makefile            |    1 +
 arch/arm/mach-davinci/gpio-tnetv107x.c    |  201 +++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/gpio.h |    1 +
 3 files changed, 203 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-davinci/gpio-tnetv107x.c

diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 1c7bcfe..62c5116 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_ARCH_DAVINCI_DM365)	+= dm365.o devices.o
 obj-$(CONFIG_ARCH_DAVINCI_DA830)        += da830.o devices-da8xx.o
 obj-$(CONFIG_ARCH_DAVINCI_DA850)        += da850.o devices-da8xx.o
 obj-$(CONFIG_ARCH_DAVINCI_TNETV107X)    += tnetv107x.o devices-tnetv107x.o
+obj-$(CONFIG_ARCH_DAVINCI_TNETV107X)    += gpio-tnetv107x.o
 
 obj-$(CONFIG_AINTC)			+= irq.o
 obj-$(CONFIG_CP_INTC)			+= cp_intc.o
diff --git a/arch/arm/mach-davinci/gpio-tnetv107x.c b/arch/arm/mach-davinci/gpio-tnetv107x.c
new file mode 100644
index 0000000..f49df0b
--- /dev/null
+++ b/arch/arm/mach-davinci/gpio-tnetv107x.c
@@ -0,0 +1,201 @@
+/*
+ * TI TNETV107X GPIO Support
+ *
+ * Author: Cyril Chemparathy <cyril at ti.com>
+ *
+ * 2009 (c) Texas Instruments, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/gpio.h>
+
+#include <mach/common.h>
+#include <mach/tnetv107x.h>
+
+struct tnetv107x_gpio_regs {
+	u32	idver;
+	u32	data_in[3];
+	u32	data_out[3];
+	u32	direction[3];
+	u32	enable[3];
+};
+
+#define gpio_reg_index(gpio)	((gpio) >> 5)
+#define gpio_reg_bit(gpio)	BIT((gpio) & 0x1f)
+
+#define gpio_reg_rmw(reg, mask, val)	\
+	__raw_writel((__raw_readl(reg) & ~(mask)) | (val), (reg))
+
+#define gpio_reg_set_bit(reg, gpio)	\
+	gpio_reg_rmw((reg) + gpio_reg_index(gpio), 0, gpio_reg_bit(gpio))
+
+#define gpio_reg_clear_bit(reg, gpio)	\
+	gpio_reg_rmw((reg) + gpio_reg_index(gpio), gpio_reg_bit(gpio), 0)
+
+#define gpio_reg_get_bit(reg, gpio)	\
+	(__raw_readl((reg) + gpio_reg_index(gpio)) & gpio_reg_bit(gpio))
+
+#define chip2controller(chip)		\
+	container_of(chip, struct davinci_gpio_controller, chip)
+
+#define TNETV107X_GPIO_CTLRS	DIV_ROUND_UP(TNETV107X_N_GPIOS, 32)
+
+static struct davinci_gpio_controller chips[TNETV107X_GPIO_CTLRS];
+
+static int tnetv107x_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+	struct davinci_gpio_controller *ctlr = chip2controller(chip);
+	struct tnetv107x_gpio_regs __iomem *regs = ctlr->regs;
+	unsigned gpio = chip->base + offset;
+	unsigned long flags;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+
+	gpio_reg_set_bit(&regs->enable, gpio);
+
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+
+	return 0;
+}
+
+static void tnetv107x_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+	struct davinci_gpio_controller *ctlr = chip2controller(chip);
+	struct tnetv107x_gpio_regs __iomem *regs = ctlr->regs;
+	unsigned gpio = chip->base + offset;
+	unsigned long flags;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+
+	gpio_reg_clear_bit(&regs->enable, gpio);
+
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+}
+
+static int tnetv107x_gpio_dir_in(struct gpio_chip *chip, unsigned offset)
+{
+	struct davinci_gpio_controller *ctlr = chip2controller(chip);
+	struct tnetv107x_gpio_regs __iomem *regs = ctlr->regs;
+	unsigned gpio = chip->base + offset;
+	unsigned long flags;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+
+	gpio_reg_set_bit(&regs->direction, gpio);
+
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+
+	return 0;
+}
+
+static int tnetv107x_gpio_dir_out(struct gpio_chip *chip,
+		unsigned offset, int value)
+{
+	struct davinci_gpio_controller *ctlr = chip2controller(chip);
+	struct tnetv107x_gpio_regs __iomem *regs = ctlr->regs;
+	unsigned gpio = chip->base + offset;
+	unsigned long flags;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+
+	if (value)
+		gpio_reg_set_bit(&regs->data_out, gpio);
+	else
+		gpio_reg_clear_bit(&regs->data_out, gpio);
+
+	gpio_reg_clear_bit(&regs->direction, gpio);
+
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+
+	return 0;
+}
+
+static int tnetv107x_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+	struct davinci_gpio_controller *ctlr = chip2controller(chip);
+	struct tnetv107x_gpio_regs __iomem *regs = ctlr->regs;
+	unsigned gpio = chip->base + offset;
+	int ret;
+
+	ret = gpio_reg_get_bit(&regs->data_in, gpio);
+
+	return ret ? 1 : 0;
+}
+
+static void tnetv107x_gpio_set(struct gpio_chip *chip,
+		unsigned offset, int value)
+{
+	struct davinci_gpio_controller *ctlr = chip2controller(chip);
+	struct tnetv107x_gpio_regs __iomem *regs = ctlr->regs;
+	unsigned gpio = chip->base + offset;
+	unsigned long flags;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+
+	if (value)
+		gpio_reg_set_bit(&regs->data_out, gpio);
+	else
+		gpio_reg_clear_bit(&regs->data_out, gpio);
+
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+}
+
+static int __init tnetv107x_gpio_setup(void)
+{
+	int i, base;
+	unsigned ngpio;
+	struct davinci_soc_info *soc_info = &davinci_soc_info;
+	struct tnetv107x_gpio_regs *regs;
+	struct davinci_gpio_controller *ctlr;
+
+	if (soc_info->gpio_type != GPIO_TYPE_TNETV107X)
+		return 0;
+
+	ngpio = soc_info->gpio_num;
+	if (ngpio == 0) {
+		pr_err("GPIO setup:  how many GPIOs?\n");
+		return -EINVAL;
+	}
+
+	if (WARN_ON(DAVINCI_N_GPIO < ngpio))
+		ngpio = DAVINCI_N_GPIO;
+
+	regs = soc_info->gpio_base;
+	if (WARN_ON(!regs))
+		return -EINVAL;
+
+	for (i = 0, base = 0; base < ngpio; i++, base += 32) {
+		ctlr = &chips[i];
+
+		ctlr->chip.label	= "tnetv107x";
+		ctlr->chip.can_sleep	= 0;
+		ctlr->chip.base		= base;
+		ctlr->chip.ngpio	= ngpio - base;
+		if (ctlr->chip.ngpio > 32)
+			ctlr->chip.ngpio = 32;
+
+		ctlr->chip.request		= tnetv107x_gpio_request;
+		ctlr->chip.free			= tnetv107x_gpio_free;
+		ctlr->chip.direction_input	= tnetv107x_gpio_dir_in;
+		ctlr->chip.get			= tnetv107x_gpio_get;
+		ctlr->chip.direction_output	= tnetv107x_gpio_dir_out;
+		ctlr->chip.set			= tnetv107x_gpio_set;
+
+		spin_lock_init(&ctlr->lock);
+
+		ctlr->regs	= regs;
+		ctlr->set_data	= &regs->data_out[i];
+		ctlr->clr_data	= &regs->data_out[i];
+		ctlr->in_data	= &regs->data_in[i];
+
+		gpiochip_add(&ctlr->chip);
+	}
+
+	soc_info->gpio_ctlrs = chips;
+	soc_info->gpio_ctlrs_num = DIV_ROUND_UP(ngpio, 32);
+	return 0;
+}
+pure_initcall(tnetv107x_gpio_setup);
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index e3cbef1..139ac4b 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -25,6 +25,7 @@
 
 enum davinci_gpio_type {
 	GPIO_TYPE_DAVINCI = 0,
+	GPIO_TYPE_TNETV107X,
 };
 
 /*
-- 
1.6.3.3


From cyril at ti.com  Wed Apr 14 13:44:59 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 14:44:59 -0400
Subject: [PATCH v3 13/16] Davinci: tnetv107x initial support
In-Reply-To: <1271270702-28307-13-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
	<1271270702-28307-9-git-send-email-cyril@ti.com>
	<1271270702-28307-10-git-send-email-cyril@ti.com>
	<1271270702-28307-11-git-send-email-cyril@ti.com>
	<1271270702-28307-12-git-send-email-cyril@ti.com>
	<1271270702-28307-13-git-send-email-cyril@ti.com>
Message-ID: <1271270702-28307-14-git-send-email-cyril@ti.com>

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 PLL.  Some
elements of the clock architecture are reused from Davinci (e.g. LPSC), but
the PLL related code is overridden using existing interfaces in "struct clk".

2. The MMR layout on this SOC is substantially different from Davinci.
Consequently, the fixed I/O map is a whole lot more convoluted (more so than
DA8xx).  The net impact here is that IO_ADDRESS() will not work on this SoC,
and therefore all mappings have to be through ioremap().

3. The Davinci reset mechanism (via Timer64 watchdog) will not work on this
SoC.  This difference has not been addressed here (dummy davinci_wdt_device),
but a more "extensible" reset mechanism will need to be established
eventually.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
v3: eliminated recalc routines for pll and leaf clocks
v3: stripped "clk_" prefix from clock names
v3: use newly added div_ratio_mask functionality (earlier in this series)
v3: move from fixed_ioremap to __davinci_ioremap() implementation (earlier in
    this series

 arch/arm/mach-davinci/Kconfig             |    5 +
 arch/arm/mach-davinci/Makefile            |    1 +
 arch/arm/mach-davinci/devices-tnetv107x.c |  128 ++++
 arch/arm/mach-davinci/tnetv107x.c         | 1175 +++++++++++++++++++++++++++++
 4 files changed, 1309 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-davinci/devices-tnetv107x.c
 create mode 100644 arch/arm/mach-davinci/tnetv107x.c

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 0316e20..a67b47b 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -50,6 +50,11 @@ config ARCH_DAVINCI_DM365
 	select AINTC
 	select ARCH_DAVINCI_DMx
 
+config ARCH_DAVINCI_TNETV107X
+	select CPU_V6
+	select CP_INTC
+	bool "TNETV107X based system"
+
 comment "DaVinci Board Type"
 
 config MACH_DAVINCI_EVM
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 6aac880..1c7bcfe 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_ARCH_DAVINCI_DM646x)       += dm646x.o devices.o
 obj-$(CONFIG_ARCH_DAVINCI_DM365)	+= dm365.o devices.o
 obj-$(CONFIG_ARCH_DAVINCI_DA830)        += da830.o devices-da8xx.o
 obj-$(CONFIG_ARCH_DAVINCI_DA850)        += da850.o devices-da8xx.o
+obj-$(CONFIG_ARCH_DAVINCI_TNETV107X)    += tnetv107x.o devices-tnetv107x.o
 
 obj-$(CONFIG_AINTC)			+= irq.o
 obj-$(CONFIG_CP_INTC)			+= cp_intc.o
diff --git a/arch/arm/mach-davinci/devices-tnetv107x.c b/arch/arm/mach-davinci/devices-tnetv107x.c
new file mode 100644
index 0000000..ab54c91
--- /dev/null
+++ b/arch/arm/mach-davinci/devices-tnetv107x.c
@@ -0,0 +1,128 @@
+/*
+ * TI TNETV107X platform devices
+ *
+ * Author: Cyril Chemparathy <cyril at ti.com>
+ *
+ * 2009 (c) Texas Instruments, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/dma-mapping.h>
+#include <linux/clk.h>
+
+#include <mach/common.h>
+#include <mach/irqs.h>
+#include <mach/edma.h>
+#include <mach/serial.h>
+#include <mach/tnetv107x.h>
+
+#include "clock.h"
+
+/* Base addresses for on-chip devices */
+#define TNETV107X_TPCC_BASE			0x01c00000
+#define TNETV107X_TPTC0_BASE			0x01c10000
+#define TNETV107X_TPTC1_BASE			0x01c10400
+
+/* TNETV107X specific EDMA3 information */
+#define EDMA_TNETV107X_NUM_DMACH	64
+#define EDMA_TNETV107X_NUM_TCC		64
+#define EDMA_TNETV107X_NUM_PARAMENTRY	128
+#define EDMA_TNETV107X_NUM_EVQUE	2
+#define EDMA_TNETV107X_NUM_TC		2
+#define EDMA_TNETV107X_CHMAP_EXIST	0
+#define EDMA_TNETV107X_NUM_REGIONS	4
+#define TNETV107X_DMACH2EVENT_MAP0	0x3C0CE000u
+#define TNETV107X_DMACH2EVENT_MAP1	0x000FFFFFu
+
+static const s8 edma_tc_mapping[][2] = {
+	/* event queue no	TC no	*/
+	{	 0,		 0	},
+	{	 1,		 1	},
+	{	-1,		-1	}
+};
+
+static const s8 edma_priority_mapping[][2] = {
+	/* event queue no	Prio	*/
+	{	 0,		 3	},
+	{	 1,		 7	},
+	{	-1,		-1	}
+};
+
+static struct edma_soc_info edma_info[] = {
+	{
+		.n_channel		= EDMA_TNETV107X_NUM_DMACH,
+		.n_region		= EDMA_TNETV107X_NUM_REGIONS,
+		.n_slot			= EDMA_TNETV107X_NUM_PARAMENTRY,
+		.n_tc			= EDMA_TNETV107X_NUM_TC,
+		.n_cc			= 1,
+		.queue_tc_mapping	= edma_tc_mapping,
+		.queue_priority_mapping	= edma_priority_mapping,
+	},
+};
+
+static struct resource edma_resources[] = {
+	{
+		.name	= "edma_cc0",
+		.start	= TNETV107X_TPCC_BASE,
+		.end	= TNETV107X_TPCC_BASE + SZ_32K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	{
+		.name	= "edma_tc0",
+		.start	= TNETV107X_TPTC0_BASE,
+		.end	= TNETV107X_TPTC0_BASE + SZ_1K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	{
+		.name	= "edma_tc1",
+		.start	= TNETV107X_TPTC1_BASE,
+		.end	= TNETV107X_TPTC1_BASE + SZ_1K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	{
+		.name	= "edma0",
+		.start	= IRQ_TNETV107X_TPCC,
+		.flags	= IORESOURCE_IRQ,
+	},
+	{
+		.name	= "edma0_err",
+		.start	= IRQ_TNETV107X_TPCC_ERR,
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device edma_device = {
+	.name		= "edma",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(edma_resources),
+	.resource	= edma_resources,
+	.dev.platform_data = edma_info,
+};
+
+void __init tnetv107x_edma_init(void)
+{
+	platform_device_register(&edma_device);
+}
+
+void __init tnetv107x_serial_init(struct plat_serial8250_port* ports)
+{
+	int i;
+	char name[16];
+	struct clk *uart_clk;
+
+	for (i = 0; ports[i].flags; i++) {
+		sprintf(name, "uart%d", i);
+		uart_clk = clk_get(NULL, name);
+		if (IS_ERR(uart_clk))
+			printk(KERN_ERR "%s:%d: failed to get UART%d clock\n",
+					__func__, __LINE__, i);
+		else {
+			clk_enable(uart_clk);
+			ports[i].uartclk = clk_get_rate(uart_clk);
+		}
+	}
+}
diff --git a/arch/arm/mach-davinci/tnetv107x.c b/arch/arm/mach-davinci/tnetv107x.c
new file mode 100644
index 0000000..a444ef7
--- /dev/null
+++ b/arch/arm/mach-davinci/tnetv107x.c
@@ -0,0 +1,1175 @@
+/*
+ * TI TNETV107X chip specific setup
+ *
+ * Author: Cyril Chemparathy <cyril at ti.com>
+ *
+ * 2009 (c) Texas Instruments, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+/*
+ * TNETV107X clock control implementation doesn't (at this point) reuse
+ * much of Davinci's generic implementation. This is because of the
+ * SSPLL nastiness that is present on this part.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+
+#include <asm/mach/map.h>
+
+#include <mach/common.h>
+#include <mach/time.h>
+#include <mach/cputype.h>
+#include <mach/psc.h>
+#include <mach/cp_intc.h>
+#include <mach/irqs.h>
+#include <mach/hardware.h>
+#include <mach/tnetv107x.h>
+
+#include "clock.h"
+#include "mux.h"
+
+/* Base addresses for on-chip devices */
+#define TNETV107X_INTC_BASE			0x03000000
+#define TNETV107X_TIMER0_BASE			0x08086500
+#define TNETV107X_TIMER1_BASE			0x08086600
+#define TNETV107X_CHIP_CFG_BASE			0x08087000
+#define TNETV107X_CLOCK_CONTROL_BASE		0x0808a000
+#define TNETV107X_PSC_BASE			0x0808b000
+
+/* Reference clock frequencies */
+#define OSC_FREQ_ONCHIP		(24000 * 1000)
+#define OSC_FREQ_OFFCHIP_SYS	(25000 * 1000)
+#define OSC_FREQ_OFFCHIP_ETH	(25000 * 1000)
+#define OSC_FREQ_OFFCHIP_TDM	(19200 * 1000)
+
+/* PLL Types */
+enum pll_type {
+	SYS_PLL,
+	TDM_PLL,
+	ETH_PLL,
+	N_PLLS
+};
+
+/* Clock Control Registers */
+struct clk_ctrl_regs {
+	u32	pll_bypass;
+	u32	_reserved0;
+	u32	gem_lrst;
+	u32	_reserved1;
+	u32	pll_unlock_stat;
+	u32	sys_unlock;
+	u32	eth_unlock;
+	u32	tdm_unlock;
+};
+
+/* SSPLL Registers */
+struct sspll_regs {
+	u32	modes;
+	u32	post_div;
+	u32	pre_div;
+	u32	mult_factor;
+	u32	divider_range;
+	u32	bw_divider;
+	u32	spr_amount;
+	u32	spr_rate_div;
+	u32	diag;
+};
+
+static struct clk_ctrl_regs __iomem *clk_ctrl_regs;
+
+static struct sspll_regs __iomem *sspll_regs[N_PLLS];
+static int sspll_regs_base[N_PLLS] = { 0x40, 0x80, 0xc0 };
+
+/* PLL Control Registers (same as in Davinci) */
+static void __iomem *pllctl_regs[N_PLLS];
+static int pllctl_regs_base[N_PLLS] = { 0x600, 0x200, 0x400 };
+
+/* PLL bypass bit shifts in clk_ctrl_regs->pll_bypass register */
+static u32 bypass_mask[N_PLLS] = { BIT(0), BIT(2), BIT(1) };
+
+/* offchip (external) reference clock frequencies */
+static u32 pll_ext_freq[] = {
+	OSC_FREQ_OFFCHIP_SYS,
+	OSC_FREQ_OFFCHIP_TDM,
+	OSC_FREQ_OFFCHIP_ETH
+};
+
+/* PSC control registers */
+static void __iomem *psc_regs[1];
+
+/* Host map for interrupt controller */
+static u32 intc_host_map[] = { 0x01010000, 0x01010101, -1 };
+
+static unsigned long clk_sspll_recalc(struct clk *clk);
+
+static struct pll_data pll_sys_data = {
+	.num		= SYS_PLL,
+	.div_ratio_mask	= 0x1ff,
+};
+
+static struct pll_data pll_eth_data = {
+	.num		= ETH_PLL,
+	.div_ratio_mask	= 0xff,
+};
+
+static struct pll_data pll_tdm_data = {
+	.num		= TDM_PLL,
+	.div_ratio_mask	= 0xff,
+};
+
+/* Top level of the clock tree - the PLLs */
+static struct clk pll_sys_clk = {
+	.name		= "pll_sys",
+	.pll_data	= &pll_sys_data,
+	.flags		= CLK_PLL,
+	.recalc		= clk_sspll_recalc,
+};
+
+static struct clk pll_eth_clk = {
+	.name		= "pll_eth",
+	.pll_data	= &pll_eth_data,
+	.flags		= CLK_PLL,
+	.recalc		= clk_sspll_recalc,
+};
+
+static struct clk pll_tdm_clk = {
+	.name		= "pll_tdm",
+	.pll_data	= &pll_tdm_data,
+	.flags		= CLK_PLL,
+	.recalc		= clk_sspll_recalc,
+};
+
+
+/* System PLL Dividers */
+static struct clk sys_arm1176_clk = {
+	.name		= "sys_arm1176_clk",
+	.parent		= &pll_sys_clk,
+	.flags		= CLK_PLL,
+	.div_reg	= PLLDIV1,
+};
+
+static struct clk sys_dsp_clk = {
+	.name		= "sys_dsp_clk",
+	.parent		= &pll_sys_clk,
+	.flags		= CLK_PLL,
+	.div_reg	= PLLDIV2,
+};
+
+static struct clk sys_ddr_clk = {
+	.name		= "sys_ddr_clk",
+	.parent		= &pll_sys_clk,
+	.flags		= CLK_PLL,
+	.div_reg	= PLLDIV3,
+};
+
+static struct clk sys_full_clk = {
+	.name		= "sys_full_clk",
+	.parent		= &pll_sys_clk,
+	.flags		= CLK_PLL,
+	.div_reg	= PLLDIV4,
+};
+
+static struct clk sys_lcd_clk = {
+	.name		= "sys_lcd_clk",
+	.parent		= &pll_sys_clk,
+	.flags		= CLK_PLL,
+	.div_reg	= PLLDIV5,
+};
+
+static struct clk sys_vlynq_ref_clk = {
+	.name		= "sys_vlynq_ref_clk",
+	.parent		= &pll_sys_clk,
+	.flags		= CLK_PLL,
+	.div_reg	= PLLDIV6,
+};
+
+static struct clk sys_tsc_clk = {
+	.name		= "sys_tsc_clk",
+	.parent		= &pll_sys_clk,
+	.flags		= CLK_PLL,
+	.div_reg	= PLLDIV7,
+};
+
+static struct clk sys_half_clk = {
+	.name		= "sys_half_clk",
+	.parent		= &pll_sys_clk,
+	.flags		= CLK_PLL,
+	.div_reg	= PLLDIV8,
+};
+
+
+/* Ethernet PLL Dividers */
+static struct clk eth_clk_5 = {
+	.name		= "eth_clk_5",
+	.parent		= &pll_eth_clk,
+	.flags		= CLK_PLL,
+	.div_reg	= PLLDIV1,
+};
+
+static struct clk eth_clk_50 = {
+	.name		= "eth_clk_50",
+	.parent		= &pll_eth_clk,
+	.flags		= CLK_PLL,
+	.div_reg	= PLLDIV2,
+};
+
+static struct clk eth_clk_125 = {
+	.name		= "eth_clk_125",
+	.parent		= &pll_eth_clk,
+	.flags		= CLK_PLL,
+	.div_reg	= PLLDIV3,
+};
+
+static struct clk eth_clk_250 = {
+	.name		= "eth_clk_250",
+	.parent		= &pll_eth_clk,
+	.flags		= CLK_PLL,
+	.div_reg	= PLLDIV4,
+};
+
+static struct clk eth_clk_25 = {
+	.name		= "eth_clk_25",
+	.parent		= &pll_eth_clk,
+	.flags		= CLK_PLL,
+	.div_reg	= PLLDIV5,
+};
+
+
+/* TDM PLL Dividers */
+static struct clk tdm_0_clk = {
+	.name		= "tdm_0_clk",
+	.parent		= &pll_tdm_clk,
+	.flags		= CLK_PLL,
+	.div_reg	= PLLDIV1,
+};
+
+static struct clk tdm_extra_clk = {
+	.name		= "tdm_extra_clk",
+	.parent		= &pll_tdm_clk,
+	.flags		= CLK_PLL,
+	.div_reg	= PLLDIV2,
+};
+
+static struct clk tdm_1_clk = {
+	.name		= "tdm_1_clk",
+	.parent		= &pll_tdm_clk,
+	.flags		= CLK_PLL,
+	.div_reg	= PLLDIV3,
+};
+
+
+/* LPSC Gated Clocks */
+static struct clk clk_arm = {
+	.name		= "arm",
+	.parent		= &sys_arm1176_clk,
+	.lpsc		= TNETV107X_LPSC_ARM,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk clk_gem = {
+	.name		= "gem",
+	.parent		= &sys_dsp_clk,
+	.lpsc		= TNETV107X_LPSC_GEM,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk clk_ddr2_phy = {
+	.name		= "ddr2_phy",
+	.parent		= &sys_ddr_clk,
+	.lpsc		= TNETV107X_LPSC_DDR2_PHY,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk clk_tpcc = {
+	.name		= "tpcc",
+	.parent		= &sys_full_clk,
+	.lpsc		= TNETV107X_LPSC_TPCC,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk clk_tptc0 = {
+	.name		= "tptc0",
+	.parent		= &sys_full_clk,
+	.lpsc		= TNETV107X_LPSC_TPTC0,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk clk_tptc1 = {
+	.name		= "tptc1",
+	.parent		= &sys_full_clk,
+	.lpsc		= TNETV107X_LPSC_TPTC1,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk clk_ram = {
+	.name		= "ram",
+	.parent		= &sys_full_clk,
+	.lpsc		= TNETV107X_LPSC_RAM,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk clk_mbx_lite = {
+	.name		= "mbx_lite",
+	.parent		= &sys_arm1176_clk,
+	.lpsc		= TNETV107X_LPSC_MBX_LITE,
+};
+
+static struct clk clk_lcd = {
+	.name		= "lcd",
+	.parent		= &sys_lcd_clk,
+	.lpsc		= TNETV107X_LPSC_LCD,
+	.flags		= PSC_SWRSTDISABLE,
+};
+
+static struct clk clk_ethss = {
+	.name		= "ethss",
+	.parent		= &eth_clk_125,
+	.lpsc		= TNETV107X_LPSC_ETHSS,
+};
+
+static struct clk clk_aemif = {
+	.name		= "aemif",
+	.parent		= &sys_full_clk,
+	.lpsc		= TNETV107X_LPSC_AEMIF,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk clk_chip_cfg = {
+	.name		= "chip_cfg",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_CHIP_CFG,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk clk_tsc = {
+	.name		= "tsc",
+	.parent		= &sys_tsc_clk,
+	.lpsc		= TNETV107X_LPSC_TSC,
+};
+
+static struct clk clk_rom = {
+	.name		= "rom",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_ROM,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk clk_uart2 = {
+	.name		= "uart2",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_UART2,
+};
+
+static struct clk clk_pktsec = {
+	.name		= "pktsec",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_PKTSEC,
+};
+
+static struct clk clk_rng = {
+	.name		= "rng",
+	.parent		= &clk_pktsec,
+};
+
+static struct clk clk_pka = {
+	.name		= "pka",
+	.parent		= &clk_pktsec,
+};
+
+static struct clk clk_secctl = {
+	.name		= "secctl",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_SECCTL,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk clk_keymgr = {
+	.name		= "keymgr",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_KEYMGR,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk clk_keypad = {
+	.name		= "keypad",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_KEYPAD,
+};
+
+static struct clk clk_gpio = {
+	.name		= "gpio",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_GPIO,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk clk_mdio = {
+	.name		= "mdio",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_MDIO,
+};
+
+static struct clk clk_sdio0 = {
+	.name		= "sdio0",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_SDIO0,
+};
+
+static struct clk clk_uart0 = {
+	.name		= "uart0",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_UART0,
+};
+
+static struct clk clk_uart1 = {
+	.name		= "uart1",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_UART1,
+};
+
+static struct clk clk_timer0 = {
+	.name		= "timer0",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_TIMER0,
+};
+
+static struct clk clk_timer1 = {
+	.name		= "timer1",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_TIMER1,
+};
+
+static struct clk clk_wdt_arm = {
+	.name		= "wdt_arm",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_WDT_ARM,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk clk_wdt_dsp = {
+	.name		= "wdt_dsp",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_WDT_DSP,
+};
+
+static struct clk clk_ssp = {
+	.name		= "ssp",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_SSP,
+};
+
+static struct clk clk_tdm0 = {
+	.name		= "tdm0",
+	.parent		= &tdm_0_clk,
+	.lpsc		= TNETV107X_LPSC_TDM0,
+};
+
+static struct clk clk_vlynq = {
+	.name		= "vlynq",
+	.parent		= &sys_vlynq_ref_clk,
+	.lpsc		= TNETV107X_LPSC_VLYNQ,
+};
+
+static struct clk clk_mcdma = {
+	.name		= "mcdma",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_MCDMA,
+};
+
+static struct clk clk_usb0 = {
+	.name		= "usb0",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_USB0,
+};
+
+static struct clk clk_tdm1 = {
+	.name		= "tdm1",
+	.parent		= &tdm_1_clk,
+	.lpsc		= TNETV107X_LPSC_TDM1,
+};
+
+static struct clk clk_debugss = {
+	.name		= "debugss",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_DEBUGSS,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk clk_ethss_rgmii = {
+	.name		= "ethss_rgmii",
+	.parent		= &eth_clk_250,
+	.lpsc		= TNETV107X_LPSC_ETHSS_RGMII,
+};
+
+static struct clk clk_system = {
+	.name		= "system",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_SYSTEM,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk clk_imcop = {
+	.name		= "imcop",
+	.parent		= &sys_dsp_clk,
+	.lpsc		= TNETV107X_LPSC_IMCOP,
+};
+
+static struct clk clk_spare = {
+	.name		= "spare",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_SPARE,
+};
+
+static struct clk clk_sdio1 = {
+	.name		= "sdio1",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_SDIO1,
+};
+
+static struct clk clk_usb1 = {
+	.name		= "usb1",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_USB1,
+};
+
+static struct clk clk_usbss = {
+	.name		= "usbss",
+	.parent		= &sys_half_clk,
+	.lpsc		= TNETV107X_LPSC_USBSS,
+};
+
+static struct clk clk_ddr2_vrst = {
+	.name		= "ddr2_vrst",
+	.parent		= &sys_ddr_clk,
+	.lpsc		= TNETV107X_LPSC_DDR2_EMIF1_VRST,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk clk_ddr2_vctl_rst = {
+	.name		= "ddr2_vctl_rst",
+	.parent		= &sys_ddr_clk,
+	.lpsc		= TNETV107X_LPSC_DDR2_EMIF2_VCTL_RST,
+	.flags		= ALWAYS_ENABLED,
+};
+
+static struct clk_lookup tnetv107x_clks[] = {
+	CLK(NULL,		"pll_sys_clk",		&pll_sys_clk),
+	CLK(NULL,		"pll_eth_clk",		&pll_eth_clk),
+	CLK(NULL,		"pll_tdm_clk",		&pll_tdm_clk),
+	CLK(NULL,		"sys_arm1176_clk",	&sys_arm1176_clk),
+	CLK(NULL,		"sys_dsp_clk",		&sys_dsp_clk),
+	CLK(NULL,		"sys_ddr_clk",		&sys_ddr_clk),
+	CLK(NULL,		"sys_full_clk",		&sys_full_clk),
+	CLK(NULL,		"sys_lcd_clk",		&sys_lcd_clk),
+	CLK(NULL,		"sys_vlynq_ref_clk",	&sys_vlynq_ref_clk),
+	CLK(NULL,		"sys_tsc_clk",		&sys_tsc_clk),
+	CLK(NULL,		"sys_half_clk",		&sys_half_clk),
+	CLK(NULL,		"eth_clk_5",		&eth_clk_5),
+	CLK(NULL,		"eth_clk_50",		&eth_clk_50),
+	CLK(NULL,		"eth_clk_125",		&eth_clk_125),
+	CLK(NULL,		"eth_clk_250",		&eth_clk_250),
+	CLK(NULL,		"eth_clk_25",		&eth_clk_25),
+	CLK(NULL,		"tdm_0_clk",		&tdm_0_clk),
+	CLK(NULL,		"tdm_extra_clk",	&tdm_extra_clk),
+	CLK(NULL,		"tdm_1_clk",		&tdm_1_clk),
+	CLK(NULL,		"clk_arm",		&clk_arm),
+	CLK(NULL,		"clk_gem",		&clk_gem),
+	CLK(NULL,		"clk_ddr2_phy",		&clk_ddr2_phy),
+	CLK(NULL,		"clk_tpcc",		&clk_tpcc),
+	CLK(NULL,		"clk_tptc0",		&clk_tptc0),
+	CLK(NULL,		"clk_tptc1",		&clk_tptc1),
+	CLK(NULL,		"clk_ram",		&clk_ram),
+	CLK(NULL,		"clk_mbx_lite",		&clk_mbx_lite),
+	CLK("tnetv107x-fb.0",	NULL,			&clk_lcd),
+	CLK(NULL,		"clk_ethss",		&clk_ethss),
+	CLK(NULL,		"aemif",		&clk_aemif),
+	CLK(NULL,		"clk_chip_cfg",		&clk_chip_cfg),
+	CLK("tnetv107x-ts.0",	NULL,			&clk_tsc),
+	CLK(NULL,		"clk_rom",		&clk_rom),
+	CLK(NULL,		"uart2",		&clk_uart2),
+	CLK(NULL,		"clk_pktsec",		&clk_pktsec),
+	CLK("tnetv107x-rng.0",	NULL,			&clk_rng),
+	CLK("tnetv107x-pka.0",	NULL,			&clk_pka),
+	CLK(NULL,		"clk_secctl",		&clk_secctl),
+	CLK(NULL,		"clk_keymgr",		&clk_keymgr),
+	CLK("tnetv107x-keypad.0", NULL,			&clk_keypad),
+	CLK(NULL,		"clk_gpio",		&clk_gpio),
+	CLK(NULL,		"clk_mdio",		&clk_mdio),
+	CLK("davinci_mmc.0",	NULL,			&clk_sdio0),
+	CLK(NULL,		"uart0",		&clk_uart0),
+	CLK(NULL,		"uart1",		&clk_uart1),
+	CLK(NULL,		"timer0",		&clk_timer0),
+	CLK(NULL,		"timer1",		&clk_timer1),
+	CLK(NULL,		"clk_wdt_arm",		&clk_wdt_arm),
+	CLK(NULL,		"clk_wdt_dsp",		&clk_wdt_dsp),
+	CLK("ti-ssp.0",		NULL,			&clk_ssp),
+	CLK(NULL,		"clk_tdm0",		&clk_tdm0),
+	CLK(NULL,		"clk_vlynq",		&clk_vlynq),
+	CLK(NULL,		"clk_mcdma",		&clk_mcdma),
+	CLK(NULL,		"clk_usb0",		&clk_usb0),
+	CLK(NULL,		"clk_tdm1",		&clk_tdm1),
+	CLK(NULL,		"clk_debugss",		&clk_debugss),
+	CLK(NULL,		"clk_ethss_rgmii",	&clk_ethss_rgmii),
+	CLK(NULL,		"clk_system",		&clk_system),
+	CLK(NULL,		"clk_imcop",		&clk_imcop),
+	CLK(NULL,		"clk_spare",		&clk_spare),
+	CLK("davinci_mmc.1",	NULL,			&clk_sdio1),
+	CLK(NULL,		"clk_usb1",		&clk_usb1),
+	CLK(NULL,		"clk_usbss",		&clk_usbss),
+	CLK(NULL,		"clk_ddr2_vrst",	&clk_ddr2_vrst),
+	CLK(NULL,		"clk_ddr2_vctl_rst",	&clk_ddr2_vctl_rst),
+	CLK(NULL,		NULL,			NULL),
+};
+
+static const struct mux_config tnetv107x_pins[] = {
+#ifdef CONFIG_DAVINCI_MUX
+	MUX_CFG(TNETV107X, ASR_A00,		0, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO32,		0, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A01,		0, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO33,		0, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A02,		0, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO34,		0, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A03,		0, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO35,		0, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A04,		0, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO36,		0, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A05,		0, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO37,		0, 25, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A06,		1, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO38,		1, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A07,		1, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO39,		1, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A08,		1, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO40,		1, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A09,		1, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO41,		1, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A10,		1, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO42,		1, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A11,		1, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, BOOT_STRP_0,		1, 25, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A12,		2, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, BOOT_STRP_1,		2, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A13,		2, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO43,		2, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A14,		2, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO44,		2, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A15,		2, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO45,		2, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A16,		2, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO46,		2, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A17,		2, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO47,		2, 25, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A18,		3, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO48,		3, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO1_DATA3_0,	3, 0, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_A19,		3, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO49,		3, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO1_DATA2_0,	3, 5, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_A20,		3, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO50,		3, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO1_DATA1_0,	3, 10, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_A21,		3, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO51,		3, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO1_DATA0_0,	3, 15, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_A22,		3, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO52,		3, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO1_CMD_0,		3, 20, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_A23,		3, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO53,		3, 25, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO1_CLK_0,		3, 25, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_BA_1,		4, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO54,		4, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SYS_PLL_CLK,		4, 0, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_CS0,		4, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, ASR_CS1,		4, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, ASR_CS2,		4, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM_PLL_CLK,		4, 15, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_CS3,		4, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, ETH_PHY_CLK,		4, 20, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, ASR_D00,		4, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO55,		4, 25, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D01,		5, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO56,		5, 0, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D02,		5, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO57,		5, 5, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D03,		5, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO58,		5, 10, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D04,		5, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO59_0,		5, 15, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D05,		5, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO60_0,		5, 20, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D06,		5, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO61_0,		5, 25, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D07,		6, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO62_0,		6, 0, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D08,		6, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO63_0,		6, 5, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D09,		6, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO64_0,		6, 10, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D10,		6, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SDIO1_DATA3_1,	6, 15, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D11,		6, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SDIO1_DATA2_1,	6, 20, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D12,		6, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SDIO1_DATA1_1,	6, 25, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D13,		7, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SDIO1_DATA0_1,	7, 0, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D14,		7, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SDIO1_CMD_1,		7, 5, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D15,		7, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SDIO1_CLK_1,		7, 10, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_OE,		7, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, BOOT_STRP_2,		7, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_RNW,		7, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO29_0,		7, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_WAIT,		7, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO30_0,		7, 25, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_WE,		8, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, BOOT_STRP_3,		8, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_WE_DQM0,		8, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO31,		8, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD17_0,		8, 5, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_WE_DQM1,		8, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, ASR_BA0_0,		8, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, VLYNQ_CLK,		9, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO14,		9, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD19_0,		9, 0, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, VLYNQ_RXD0,		9, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO15,		9, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD20_0,		9, 5, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, VLYNQ_RXD1,		9, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO16,		9, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD21_0,		9, 10, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, VLYNQ_TXD0,		9, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO17,		9, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD22_0,		9, 15, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, VLYNQ_TXD1,		9, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO18,		9, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD23_0,		9, 20, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, SDIO0_CLK,		10, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO19,		10, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO0_CMD,		10, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO20,		10, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO0_DATA0,		10, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO21,		10, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO0_DATA1,		10, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO22,		10, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO0_DATA2,		10, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO23,		10, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO0_DATA3,		10, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO24,		10, 25, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, EMU0,		11, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, EMU1,		11, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, RTCK,		12, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TRST_N,		12, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TCK,			12, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDI,			12, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDO,			12, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TMS,			12, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM1_CLK,		13, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM1_RX,		13, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM1_TX,		13, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM1_FS,		13, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_R0,		14, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_R1,		14, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_R2,		14, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_R3,		14, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_R4,		14, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_R5,		14, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_R6,		15, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO12,		15, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, KEYPAD_R7,		15, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO10,		15, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, KEYPAD_C0,		15, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_C1,		15, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_C2,		15, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_C3,		15, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_C4,		16, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_C5,		16, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_C6,		16, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO13,		16, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, TEST_CLK_IN,		16, 10, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, KEYPAD_C7,		16, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO11,		16, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SSP0_0,		17, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SCC_DCLK,		17, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD20_1,		17, 0, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, SSP0_1,		17, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SCC_CS_N,		17, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD21_1,		17, 5, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, SSP0_2,		17, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SCC_D,		17, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD22_1,		17, 10, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, SSP0_3,		17, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SCC_RESETN,		17, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD23_1,		17, 15, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, SSP1_0,		18, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO25,		18, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, UART2_CTS,		18, 0, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, SSP1_1,		18, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO26,		18, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, UART2_RD,		18, 5, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, SSP1_2,		18, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO27,		18, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, UART2_RTS,		18, 10, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, SSP1_3,		18, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO28,		18, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, UART2_TD,		18, 15, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, UART0_CTS,		19, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, UART0_RD,		19, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, UART0_RTS,		19, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, UART0_TD,		19, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, UART1_RD,		19, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, UART1_TD,		19, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_AC_NCS,		20, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_HSYNC_RNW,	20, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_VSYNC_A0,	20, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_MCLK,		20, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD16_0,		20, 15, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, LCD_PCLK_E,		20, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD00,		20, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD01,		21, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD02,		21, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD03,		21, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD04,		21, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD05,		21, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD06,		21, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD07,		22, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD08,		22, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO59_1,		22, 5, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, LCD_PD09,		22, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO60_1,		22, 10, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, LCD_PD10,		22, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, ASR_BA0_1,		22, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, GPIO61_1,		22, 15, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, LCD_PD11,		22, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO62_1,		22, 20, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, LCD_PD12,		22, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO63_1,		22, 25, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, LCD_PD13,		23, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO64_1,		23, 0, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, LCD_PD14,		23, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO29_1,		23, 5, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, LCD_PD15,		23, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO30_1,		23, 10, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, EINT0,		24, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO08,		24, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, EINT1,		24, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO09,		24, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, GPIO00,		24, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD20_2,		24, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, TDM_CLK_IN_2,	24, 10, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, GPIO01,		24, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD21_2,		24, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, 24M_CLK_OUT_1,	24, 15, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, GPIO02,		24, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD22_2,		24, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, GPIO03,		24, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD23_2,		24, 25, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, GPIO04,		25, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD16_1,		25, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, USB0_RXERR,		25, 0, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, GPIO05,		25, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD17_1,		25, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, TDM_CLK_IN_1,	25, 5, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, GPIO06,		25, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD18,		25, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, 24M_CLK_OUT_2,	25, 10, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, GPIO07,		25, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD19_1,		25, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, USB1_RXERR,		25, 15, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, ETH_PLL_CLK,		25, 15, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, MDIO,		26, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, MDC,			26, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, AIC_MUTE_STAT_N,	26, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM0_CLK,		26, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, AIC_HNS_EN_N,	26, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM0_FS,		26, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, AIC_HDS_EN_STAT_N,	26, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM0_TX,		26, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, AIC_HNF_EN_STAT_N,	26, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM0_RX,		26, 25, 0x1f, 0x04, false)
+#endif
+};
+
+/* FIQ are pri 0-1; otherwise 2-7, with 7 lowest priority */
+static u8 tnetv107x_irq_prios[TNETV107X_N_CP_INTC_IRQ] = {
+	[IRQ_TNETV107X_TDM1_TXDMA]		= 7,
+	[IRQ_TNETV107X_EXT_INT_0]		= 7,
+	[IRQ_TNETV107X_EXT_INT_1]		= 7,
+	[IRQ_TNETV107X_GPIO_INT12]		= 7,
+	[IRQ_TNETV107X_GPIO_INT13]		= 7,
+	[IRQ_TNETV107X_TIMER_0_TINT12]		= 7,
+	[IRQ_TNETV107X_TIMER_1_TINT12]		= 7,
+	[IRQ_TNETV107X_UART0]			= 7,
+	[IRQ_TNETV107X_TDM1_RXDMA]		= 7,
+	[IRQ_TNETV107X_MCDMA_INT0]		= 7,
+	[IRQ_TNETV107X_MCDMA_INT1]		= 7,
+	[IRQ_TNETV107X_TPCC]			= 7,
+	[IRQ_TNETV107X_TPCC_INT0]		= 7,
+	[IRQ_TNETV107X_TPCC_INT1]		= 7,
+	[IRQ_TNETV107X_TPCC_INT2]		= 7,
+	[IRQ_TNETV107X_TPCC_INT3]		= 7,
+	[IRQ_TNETV107X_TPTC0]			= 7,
+	[IRQ_TNETV107X_TPTC1]			= 7,
+	[IRQ_TNETV107X_TIMER_0_TINT34]		= 7,
+	[IRQ_TNETV107X_ETHSS]			= 7,
+	[IRQ_TNETV107X_TIMER_1_TINT34]		= 7,
+	[IRQ_TNETV107X_DSP2ARM_INT0]		= 7,
+	[IRQ_TNETV107X_DSP2ARM_INT1]		= 7,
+	[IRQ_TNETV107X_ARM_NPMUIRQ]		= 7,
+	[IRQ_TNETV107X_USB1]			= 7,
+	[IRQ_TNETV107X_VLYNQ]			= 7,
+	[IRQ_TNETV107X_UART0_DMATX]		= 7,
+	[IRQ_TNETV107X_UART0_DMARX]		= 7,
+	[IRQ_TNETV107X_TDM1_TXMCSP]		= 7,
+	[IRQ_TNETV107X_SSP]			= 7,
+	[IRQ_TNETV107X_MCDMA_INT2]		= 7,
+	[IRQ_TNETV107X_MCDMA_INT3]		= 7,
+	[IRQ_TNETV107X_TDM_CODECIF_EOT]		= 7,
+	[IRQ_TNETV107X_IMCOP_SQR_ARM]		= 7,
+	[IRQ_TNETV107X_USB0]			= 7,
+	[IRQ_TNETV107X_USB_CDMA]		= 7,
+	[IRQ_TNETV107X_LCD]			= 7,
+	[IRQ_TNETV107X_KEYPAD]			= 7,
+	[IRQ_TNETV107X_KEYPAD_FREE]		= 7,
+	[IRQ_TNETV107X_RNG]			= 7,
+	[IRQ_TNETV107X_PKA]			= 7,
+	[IRQ_TNETV107X_TDM0_TXDMA]		= 7,
+	[IRQ_TNETV107X_TDM0_RXDMA]		= 7,
+	[IRQ_TNETV107X_TDM0_TXMCSP]		= 7,
+	[IRQ_TNETV107X_TDM0_RXMCSP]		= 7,
+	[IRQ_TNETV107X_TDM1_RXMCSP]		= 7,
+	[IRQ_TNETV107X_SDIO1]			= 7,
+	[IRQ_TNETV107X_SDIO0]			= 7,
+	[IRQ_TNETV107X_TSC]			= 7,
+	[IRQ_TNETV107X_TS]			= 7,
+	[IRQ_TNETV107X_UART1]			= 7,
+	[IRQ_TNETV107X_MBX_LITE]		= 7,
+	[IRQ_TNETV107X_GPIO_INT00]		= 7,
+	[IRQ_TNETV107X_GPIO_INT01]		= 7,
+	[IRQ_TNETV107X_GPIO_INT02]		= 7,
+	[IRQ_TNETV107X_GPIO_INT03]		= 7,
+	[IRQ_TNETV107X_UART2]			= 7,
+	[IRQ_TNETV107X_UART2_DMATX]		= 7,
+	[IRQ_TNETV107X_UART2_DMARX]		= 7,
+	[IRQ_TNETV107X_IMCOP_IMX]		= 7,
+	[IRQ_TNETV107X_IMCOP_VLCD]		= 7,
+	[IRQ_TNETV107X_AES]			= 7,
+	[IRQ_TNETV107X_DES]			= 7,
+	[IRQ_TNETV107X_SHAMD5]			= 7,
+	[IRQ_TNETV107X_TPCC_ERR]		= 7,
+	[IRQ_TNETV107X_TPCC_PROT]		= 7,
+	[IRQ_TNETV107X_TPTC0_ERR]		= 7,
+	[IRQ_TNETV107X_TPTC1_ERR]		= 7,
+	[IRQ_TNETV107X_UART0_ERR]		= 7,
+	[IRQ_TNETV107X_UART1_ERR]		= 7,
+	[IRQ_TNETV107X_AEMIF_ERR]		= 7,
+	[IRQ_TNETV107X_DDR_ERR]			= 7,
+	[IRQ_TNETV107X_WDTARM_INT0]		= 7,
+	[IRQ_TNETV107X_MCDMA_ERR]		= 7,
+	[IRQ_TNETV107X_GPIO_ERR]		= 7,
+	[IRQ_TNETV107X_MPU_ADDR]		= 7,
+	[IRQ_TNETV107X_MPU_PROT]		= 7,
+	[IRQ_TNETV107X_IOPU_ADDR]		= 7,
+	[IRQ_TNETV107X_IOPU_PROT]		= 7,
+	[IRQ_TNETV107X_KEYPAD_ADDR_ERR]		= 7,
+	[IRQ_TNETV107X_WDT0_ADDR_ERR]		= 7,
+	[IRQ_TNETV107X_WDT1_ADDR_ERR]		= 7,
+	[IRQ_TNETV107X_CLKCTL_ADDR_ERR]		= 7,
+	[IRQ_TNETV107X_PLL_UNLOCK]		= 7,
+	[IRQ_TNETV107X_WDTDSP_INT0]		= 7,
+	[IRQ_TNETV107X_SEC_CTRL_VIOLATION]	= 7,
+	[IRQ_TNETV107X_KEY_MNG_VIOLATION]	= 7,
+	[IRQ_TNETV107X_PBIST_CPU]		= 7,
+	[IRQ_TNETV107X_WDTARM]			= 7,
+	[IRQ_TNETV107X_PSC]			= 7,
+	[IRQ_TNETV107X_MMC0]			= 7,
+	[IRQ_TNETV107X_MMC1]			= 7,
+};
+
+/* Contents of JTAG ID register used to identify exact cpu type */
+static struct davinci_id tnetv107x_ids[] = {
+	{
+		.variant	= 0x0,
+		.part_no	= 0xb8a1,
+		.manufacturer	= 0x017,
+		.cpu_id		= DAVINCI_CPU_ID_TNETV107X,
+		.name		= "tnetv107x rev1.0",
+	},
+};
+
+static struct davinci_timer_instance tnetv107x_timer_instance[2] = {
+	{
+		.bottom_irq	= IRQ_TNETV107X_TIMER_0_TINT12,
+		.top_irq	= IRQ_TNETV107X_TIMER_0_TINT34,
+	},
+	{
+		.bottom_irq	= IRQ_TNETV107X_TIMER_1_TINT12,
+		.top_irq	= IRQ_TNETV107X_TIMER_1_TINT34,
+	},
+};
+
+static struct davinci_timer_info tnetv107x_timer_info = {
+	.timers		= tnetv107x_timer_instance,
+	.clockevent_id	= T0_BOT,
+	.clocksource_id	= T0_TOP,
+};
+
+/*
+ * TNETV107X platforms do not use the static mappings from Davinci
+ * IO_PHYS/IO_VIRT. This SOC's interesting MMRs are at different addresses,
+ * and changing IO_PHYS would break away from existing Davinci SOCs.
+ *
+ * The primary impact of the current model is that IO_ADDRESS() is not to be
+ * used to map registers on TNETV107X. With the exception of early boot code
+ * in tnetv107x_init() (where fixed maps are necessary), all other pieces of
+ * code absolutely _must_ use ioremap().
+ *
+ * 1.	The first section in here is specifically for edma, even through the
+ *	edma driver code properly ioremap()s its register space.  This is
+ *	because the edma MMRs on tnetv107x unfortunately fall within the
+ *	davinci IO_PHYS - (IO_PHYS + IO_SIZE) range, and therefore the edma
+ *	driver's ioremap() gets subverted by davinci_ioremap(). Yikes!
+ *
+ * 2.	The second chunk is for INTC - no major issues here.  If the cp_intc
+ *	code were to someday ioremap() internally, we could very well get rid
+ *	of this map.
+ *
+ * 3.	The third chunk maps in register areas that need to be populated into
+ *	davinci_soc_info.  Note that alignment restrictions come into play if
+ *	low-level debug is enabled (see note in <mach/tnetv107x.h>).
+ */
+static struct map_desc tnetv107x_io_desc[] = {
+	{	/* EDMA */
+		.virtual	= IO_VIRT,
+		.pfn		= __phys_to_pfn(IO_PHYS),
+		.length		= SZ_128K,
+		.type		= MT_DEVICE
+	},
+	{	/* INTC */
+		.virtual	= IO_VIRT + SZ_128K,
+		.pfn		= __phys_to_pfn(TNETV107X_INTC_BASE),
+		.length		= SZ_16K,
+		.type		= MT_DEVICE
+	},
+	{	/* Most of the rest */
+		.virtual	= TNETV107X_IO_VIRT,
+		.pfn		= __phys_to_pfn(TNETV107X_IO_BASE),
+		.length		= IO_SIZE - SZ_1M,
+		.type		= MT_DEVICE
+	},
+};
+
+static struct davinci_soc_info tnetv107x_soc_info = {
+	.io_desc		= tnetv107x_io_desc,
+	.io_desc_num		= ARRAY_SIZE(tnetv107x_io_desc),
+	.ids			= tnetv107x_ids,
+	.ids_num		= ARRAY_SIZE(tnetv107x_ids),
+	.cpu_clks		= tnetv107x_clks,
+	.psc_bases		= psc_regs,
+	.psc_bases_num		= ARRAY_SIZE(psc_regs),
+	.pinmux_pins		= tnetv107x_pins,
+	.pinmux_pins_num	= ARRAY_SIZE(tnetv107x_pins),
+	.intc_type		= DAVINCI_INTC_TYPE_CP_INTC,
+	.intc_irq_prios		= tnetv107x_irq_prios,
+	.intc_irq_num		= TNETV107X_N_CP_INTC_IRQ,
+	.timer_info		= &tnetv107x_timer_info,
+};
+
+#define tnetv107x_early_ioremap(p, s)				\
+	__davinci_ioremap(p, s,					\
+			tnetv107x_soc_info.io_desc,		\
+			tnetv107x_soc_info.io_desc_num)
+
+void __init tnetv107x_init(void)
+{
+	void __iomem *tmp;
+	int i;
+
+	/*
+	 * Figure out virtual addresses for necessary peripherals, but do not
+	 * access any of these here. iotable_init() needs to happen for the
+	 * mappings to actually get setup
+	 */
+	clk_ctrl_regs = tmp =
+		tnetv107x_early_ioremap(TNETV107X_CLOCK_CONTROL_BASE, SZ_4K);
+
+	for (i = 0; i < N_PLLS; i++) {
+		sspll_regs[i] = tmp + sspll_regs_base[i];
+		pllctl_regs[i] = tmp + pllctl_regs_base[i];
+	}
+
+	pll_sys_data.base = pllctl_regs[SYS_PLL];
+	pll_eth_data.base = pllctl_regs[ETH_PLL];
+	pll_tdm_data.base = pllctl_regs[TDM_PLL];
+
+	psc_regs[0] = tnetv107x_early_ioremap(TNETV107X_PSC_BASE, SZ_4K);
+
+	tmp = tnetv107x_early_ioremap(TNETV107X_CHIP_CFG_BASE, SZ_4K);
+	tnetv107x_soc_info.jtag_id_base	= tmp + 0x018;
+	tnetv107x_soc_info.pinmux_base	= tmp + 0x150;
+
+	tnetv107x_soc_info.intc_base =
+		tnetv107x_early_ioremap(TNETV107X_INTC_BASE, SZ_16K);
+
+	tnetv107x_timer_instance[0].base =
+		tnetv107x_early_ioremap(TNETV107X_TIMER0_BASE, 0x100);
+
+	tnetv107x_timer_instance[1].base =
+		tnetv107x_early_ioremap(TNETV107X_TIMER1_BASE, 0x100);
+
+	davinci_common_init(&tnetv107x_soc_info);
+}
+
+void __init tnetv107x_irq_init(void)
+{
+	struct davinci_soc_info *soc_info = &davinci_soc_info;
+
+	cp_intc_init(soc_info->intc_base, soc_info->intc_irq_num,
+			soc_info->intc_irq_prios, intc_host_map);
+}
+
+static unsigned long clk_sspll_recalc(struct clk *clk)
+{
+	int		pll;
+	unsigned long	mult = 0, prediv = 1, postdiv = 1;
+	unsigned long	ref = OSC_FREQ_ONCHIP, ret;
+	u32		tmp;
+
+	if (WARN_ON(!clk->pll_data))
+		return clk->rate;
+
+	pll = clk->pll_data->num;
+
+	tmp = __raw_readl(&clk_ctrl_regs->pll_bypass);
+	if (!(tmp & bypass_mask[pll])) {
+		mult	= __raw_readl(&sspll_regs[pll]->mult_factor);
+		prediv	= __raw_readl(&sspll_regs[pll]->pre_div) + 1;
+		postdiv	= __raw_readl(&sspll_regs[pll]->post_div) + 1;
+	}
+
+	tmp = __raw_readl(pllctl_regs[pll] + PLLCTL);
+	if (tmp & PLLCTL_CLKMODE)
+		ref = pll_ext_freq[pll];
+
+	clk->pll_data->input_rate = ref;
+
+	tmp = __raw_readl(pllctl_regs[pll] + PLLCTL);
+	if (!(tmp & PLLCTL_PLLEN))
+		return ref;
+
+	ret = ref;
+	if (mult)
+		ret += ((unsigned long long)ref * mult) / 256;
+
+	ret /= (prediv * postdiv);
+
+	return ret;
+}
-- 
1.6.3.3


From mgrosen at ti.com  Wed Apr 14 14:20:07 2010
From: mgrosen at ti.com (Grosen, Mark)
Date: Wed, 14 Apr 2010 14:20:07 -0500
Subject: Codec engine lockup
In-Reply-To: <92CDD168D1E81F4F9D3839DC45903FC676C834C2@dlee03.ent.ti.com>
References: <95FAFD227E8A2947BA96E1C807505D0412CD5F@sbs001.office.local>
	<92CDD168D1E81F4F9D3839DC45903FC676C07D7E@dlee03.ent.ti.com>
	<95FAFD227E8A2947BA96E1C807505D0412CD67@sbs001.office.local>
	<92CDD168D1E81F4F9D3839DC45903FC676C834C2@dlee03.ent.ti.com>
Message-ID: <5F744A5A3C131242B81CE5874BD2CFFB87A37510@dlee01.ent.ti.com>

Check that your stack is large enough on the DSP. See this wiki article:
http://tiexpressdsp.com/index.php/Stack_issues

Also, look for global or static variables in your code that are not explicitly initialized. The C6000 compiler does not automatically globals/statics to zero.

Mark

________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Ring, Chris
Sent: Wednesday, April 14, 2010 9:32 AM
To: Etienne Eccles; davinci-linux-open-source at linux.davincidsp.com
Subject: RE: Codec engine lockup

After your process() fxn, the call flow returns into the VIDENC skeleton.  (You can find the sources in packages/ti/sdo/ce/video/videnc_skel.c)

There's basically some cache calls (your outbuf and outArgs->reconBufs buffer descriptors are correct, right?), and the skeleton's call() method returns.  After that, CE will send the "I'm done" reply msg to the ARM.  This reply will unblock the ARM side (which is what we're _not_ seeing).

Another thing to try is to link in the CE debug libs (when building your Server) which will let you step through the DSP-side CE code after your process() call returns.  How to link in debug libs unfortunately changes a little from release to release - I think in CE 2.10.02, you would set the following line in your Server's package.bld build script:

   Pkg.attrs.profile = "debug";

You can sanity check that you're linking in the debug libs as you'll see output during build like:

    will link with ti.sdo.ce.video:lib/debug/video.a64P
Chris

________________________________
From: Etienne Eccles [mailto:Etienne.Eccles at vcatechnology.com]
Sent: Wednesday, April 14, 2010 1:59 AM
To: Ring, Chris; davinci-linux-open-source at linux.davincidsp.com
Subject: RE: Codec engine lockup

Hi Chris

Thanks for the reply.
I have actually done what you suggested, and I can see that the DSP side process call completes successfully and returns. I have even gone so far as to remove the entire body of DSP side process function and immediately return with IALG_EOK.  That's why I suspected it must be locking up in the codec engine after completing the DSP side process.

This lock up  problem is also not repeatable. It only occurs on about 20% of hardware examples and under certain booting conditions

Etienne

From: Ring, Chris [mailto:cring at ti.com]
Sent: 13 April 2010 18:57
To: Etienne Eccles; davinci-linux-open-source at linux.davincidsp.com
Subject: RE: Codec engine lockup

The last line is an ARM-side Comm_get() call (implemented with MSGQ_get()) - which blocks until the DSP finishes it's job and sends an 'I'm done' reply message.  Basically, you've sent a request to VIDENC_process() a frame which never returns.  The DSP is hanging/crashing/waiting and never returning "I'm done" to the ARM.

Can you connect to CCS and see what's happening on the DSP side?  Since this is your codec, maybe set breakpoints in your process() method and see if it ever gets called.

http://wiki.davincidsp.com/index.php/Debugging_the_DSP_side_of_a_CE_application_using_CCS

Chris

________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Etienne Eccles
Sent: Tuesday, April 13, 2010 5:39 AM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: Codec engine lockup

H


I am getting the following debug output . using CE_DEBUG=3 when creating and using a custom VIDENC codec:



root at nvc1346:/opt/davinci# CE_DEBUG=3 ./stabd -d -p a
root at nvc1346:/opt/davinci# @0,196,096us: [+4 T:0x00004000 S:0xbec8cbbc] OG - Global_init> This program w
as built with the following packages:
@0,197,108us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package gnu.targets.rts470MV (/home/vcastab/svn/ud
p/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/gnu/targets/rts470MV/) [1,0,0,0,1203621000516]
@0,197,334us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package dsplink.gpp (/home/vcastab/svn/udp/linux/d
vsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/dsplink/gpp/) [3,0,0]
@0,197,516us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.xdais.dm (/home/vcastab/svn/udp/linux/d
vsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/dm/) [1,0,4,1210262746529]
@0,197,948us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.xdais (/home/vcastab/svn/udp/linux/dvsd
k/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/) [1,2,1,1210262742149]
@0,198,149us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.utils.trace (/home/vcastab/svn/udp/
linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/utils/trace/) [1,0,0,122094336
6422]
@0,198,331us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.utils.xdm (/home/vcastab/svn/udp
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/utils/xdm/) [1,0,1,1220951322616]
@0,198,510us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.fc.dman3 (/home/vcastab/svn/udp/lin
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/fc/dman3/) [1,0,3,1220943053023]
@0,198,682us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.fc.acpy3 (/home/vcastab/svn/udp/lin
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/fc/acpy3/) [1,0,2,1220943014135]
@0,198,852us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.linuxutils.cmem (/home/vcastab/svn/
udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/linuxutils/cmem/) [2,0,1,1
204929560755]
@0,199,030us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.catalog.c470 (/home/vcastab/svn/udp/lin
ux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/catalog/c470/) [1,0,1,0,1203561761475]
@0,199,200us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.platforms.evmDM6446 (/home/vcastab/svn/
udp/linux/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/platforms/evmDM6446/) [1,0,0,1,1192229600615]
@0,199,369us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.osal (/home/vcastab/svn/udp/linu
x/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/osal/) [2,0,2,1220951127739]
@0,199,539us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.ipc (/home/vcastab/svn/udp/linux
/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/) [2,0,1,1220951085787]
@0,199,704us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.alg (/home/vcastab/svn/udp/linux
/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/alg/) [1,0,1,1220950781938]
@0,199,875us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.osal.linux (/home/vcastab/svn/ud
p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/osal/linux/) [2,0,1,1220951140072
]
@0,200,049us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.ipc.dsplink (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/dsplink/) [2,0,1,12209510968
18]
@0,200,219us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce (/home/vcastab/svn/udp/linux/dvs
dk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/) [1,0,6,1220950771473]
@0,200,386us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.video (/home/vcastab/svn/udp/lin
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/video/) [1,0,3,1220951334122]
@0,200,559us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package codecs.vca_stab (/home/vcastab/svn/vt/davi
nci/trunk/ce1/codecs/vca_stab/) []
@0,200,718us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.bioslog (/home/vcastab/svn/udp/l
inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/bioslog/) [1,0,1,1220950800329]
@0,587,586us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package ti.sdo.ce.utils.trace (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/utils/trace/) [1,0,1,12209513170
87]
@0,587,929us: [+4 T:0x00004000 S:0xbec8cbbc] OG -     package apps.stab_client (/home/vcastab/svn/vt/dav
inci/trunk/ce1/apps/stab_client/) []
@0,588,146us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x20028)
@0,588,352us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x1f4c0)
@0,588,676us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> Enter(0x18)
@0,589,026us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return (0x5e138)
@0,589,716us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit> enter (fxn=0x1dda8)
@0,590,050us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> Enter(0x18)
@0,590,269us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return (0x5e188)
@0,590,492us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit> enter (fxn=0x1b9f4)
@0,590,839us: [+0 T:0x00004000 S:0xbec8cbbc] OG - Global_atexit> enter (fxn=0x1eb44)
@0,593,794us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem - Sem_create> count: 0
@0,594,023us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> Enter(0x14)
@0,594,212us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> return (0x5e208)
@0,594,470us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x5e208]
@0,594,698us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem - Sem_create> count: 0
@0,594,859us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> Enter(0x14)
@0,595,056us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> return (0x5e220)
@0,595,220us: [+0 T:0x00004000 S:0xbec8cba4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x5e220]
@0,595,378us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> Enter(0x18)
@0,595,544us: [+0 T:0x00004000 S:0xbec8cb8c] OM - Memory_alloc> return (0x5e238)
@0,595,707us: [+0 T:0x00004000 S:0xbec8cb8c] OT - Thread_create> Enter (fxn=0x1ab34, attrs=0x0)
@0,595,869us: [+0 T:0x00004000 S:0xbec8cb74] OM - Memory_alloc> Enter(0x64)
@0,596,064us: [+0 T:0x00004000 S:0xbec8cb74] OM - Memory_alloc> return (0x5e258)
@0,598,964us: [+1 T:0x00004002 S:0xbe5ffa74] OP - daemon> thread created.
@0,599,205us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d> Enter (proc=0xbe5ffaec)
@0,599,387us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem - Entered Sem_pend> sem[0x5e208] timeout
[0xffffffff]
@0,599,998us: [+0 T:0x00004000 S:0xbec8cb8c] OT - Thread_create> Exit (task=0x5e258)
@0,600,235us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x1a6f4)
@0,600,501us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x1c7e8)
@0,600,791us: [+0 T:0x00004000 S:0xbec8cbac] ti.sdo.ce.alg - ALG_init> Enter
@0,600,984us: [+0 T:0x00004000 S:0xbec8cb9c] OG - Global_atexit> enter (fxn=0x209f0)
@0,601,171us: [+0 T:0x00004000 S:0xbec8cbcc] ti.sdo.ce.alg - ALG_init> Exit
@0,601,339us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x20490)
@0,601,541us: [+0 T:0x00004000 S:0xbec8cb9c] OM - Memory_alloc> Enter(0x18)
@0,601,767us: [+0 T:0x00004000 S:0xbec8cb9c] OM - Memory_alloc> return (0x60418)
@0,601,955us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x1eca8)
@0,602,262us: [+6 T:0x00004000 S:0xbec8cbc4] CE - Engine_init> CE debugging on (CE_DEBUG=3; allowed CE_D
EBUG levels: 1=min, 2=good, 3=max)
@0,602,481us: [+0 T:0x00004000 S:0xbec8cbb4] OG - Global_atexit> enter (fxn=0x17734)
@0,602,667us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> Enter(0x18)
@0,602,852us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return (0x60458)
@0,603,024us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> Enter(0x18)
@0,603,247us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return (0x60478)
@0,603,423us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> Enter(0x18)
@0,603,600us: [+0 T:0x00004000 S:0xbec8cb94] OM - Memory_alloc> return (0x60498)
@0,944,735us: [+0 T:0x00004000 S:0xbec8cbc4] CS - Server_init()
@0,944,957us: [+0 T:0x00004000 S:0xbec8cbc4] CS - Server_init> Global_useLinkArbiter = 0
@0,945,138us: [+0 T:0x00004000 S:0xbec8cbc4] OG - Global_atexit> enter (fxn=0x16284)
@0,945,529us: [+0 T:0x00004000 S:0xbec8cbd4] OG - Global_atexit> enter (fxn=0x14148)
@0,945,950us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@0,946,486us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x403ee000.
@0,946,744us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x403ee000) = 0x8ff25
000.
@0,946,938us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x403ee000, size=
884736, physAddr=0x8ff25000)
@0,947,127us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@0,947,319us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@0,947,514us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60518)
@0,947,842us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8ff25000,
cb->size=884736, cb->virt=0x403ee000
@0,948,044us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x403ee000)
@0,948,270us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@0,948,643us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x404c9000.
@0,948,931us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x404c9000) = 0x8cac7
000.
@0,949,123us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x404c9000, size=
884736, physAddr=0x8cac7000)
@0,949,305us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@0,949,467us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@0,949,651us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60530)
@0,949,823us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8cac7000,
cb->size=884736, cb->virt=0x404c9000
@0,950,004us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x404c9000)
@0,950,206us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@0,950,595us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x405c9000.
@0,950,841us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x405c9000) = 0x8c9c7
000.
@0,951,032us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x405c9000, size=
884736, physAddr=0x8c9c7000)
@0,951,219us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@0,951,380us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@0,951,592us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60548)
@0,951,775us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8c9c7000,
cb->size=884736, cb->virt=0x405c9000
@0,951,959us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x405c9000)
@0,952,125us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@0,952,475us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x406c9000.
@0,952,718us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x406c9000) = 0x8c879
000.
@0,952,911us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x406c9000, size=
884736, physAddr=0x8c879000)
@0,953,145us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@0,953,310us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@0,953,490us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60560)
@1,294,466us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8c879000,
cb->size=884736, cb->virt=0x406c9000
@1,294,700us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x406c9000)
@1,294,877us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@1,295,385us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x407c9000.
@1,295,626us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x407c9000) = 0x8fc94
000.
@1,295,850us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x407c9000, size=
884736, physAddr=0x8fc94000)
@1,296,040us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@1,296,206us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@1,296,387us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60578)
@1,296,557us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8fc94000,
cb->size=884736, cb->virt=0x407c9000
@1,296,739us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x407c9000)
@1,296,908us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> Enter(size=884736, align=-1, cache
d=FALSE, heap=FALSE)
@1,297,589us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_alloc(884736) = 0x40a5a000.
@1,298,146us: [+4 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> CMEM_getPhys(0x40a5a000) = 0x8f8de
000.
@1,298,345us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> Enter(virtAddr=0x40a5a000, size=
884736, physAddr=0x8f8de000)
@1,298,538us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> creating new contigBuf object
@1,298,750us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> Enter(0x10)
@1,298,934us: [+0 T:0x00004000 S:0xbec8cb14] OM - Memory_alloc> return (0x60590)
@1,299,106us: [+1 T:0x00004000 S:0xbec8cb2c] OM - Memory__addContigBuf> returning: cb->phys=0x8f8de000,
cb->size=884736, cb->virt=0x40a5a000
@1,299,290us: [+0 T:0x00004000 S:0xbec8cb84] OM - Memory_contigAlloc> return (0x40a5a000)
@1,309,917us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - Engine_open> Enter('vca_engine', 0x0, 0xbe3ffa84)
@1,310,205us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc> Enter(0x2c)
@1,310,419us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc> return (0x605a8)
@1,310,604us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - rserverOpen('./server_release.x64P'), count = 0
@1,310,785us: [+0 T:0x00008003 S:0xbe3ff9ac] OP - Processor_create> Enter(imageName='./server_release.x6
4P', linkCfg='(null)', attrs=0xbe3ffa30)
@1,312,833us: [+0 T:0x00008003 S:0xbe3ff994] OM - Memory_alloc> Enter(0x24)
@1,313,100us: [+0 T:0x00008003 S:0xbe3ff994] OM - Memory_alloc> return (0x605d8)
@1,313,292us: [+0 T:0x00008003 S:0xbe3ff98c] OP - doCmd> Enter (cmdId=1, proc=0x605d8)
@1,313,470us: [+0 T:0x00008003 S:0xbe3ff97c] ti.sdo.ce.osal.Sem - Entered Sem_post> sem[0x5e208]
@1,313,801us: [+0 T:0x00008003 S:0xbe3ff98c] ti.sdo.ce.osal.Sem - Leaving Sem_post> sem[0x5e208]
@1,314,019us: [+0 T:0x00008003 S:0xbe3ff96c] ti.sdo.ce.osal.Sem - Entered Sem_pend> sem[0x5e220] timeout
[0xffffffff]
@1,314,506us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem - Leaving Sem_pend> sem[0x5e208] status[
0]
@1,314,978us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d> Exit (result=1)
@1,315,460us: [+0 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Enter(proc=0x605d8)
@1,315,900us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Initializing DSP PROC...
@1,316,335us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Using DspLink config data for entr
y #0 [server './server_release.x64P']
@1,316,786us: [+0 T:0x00004002 S:0xbe5ffa5c] OM - Memory_alloc> Enter(0xe0)
@1,317,458us: [+0 T:0x00004002 S:0xbe5ffa5c] OM - Memory_alloc> return (0x60600)
@1,318,325us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Adding DSP segment #0 to Link conf
iguration: name='DDR', startAddress=0x88200000, sizeInBytes=0x400000, shared=1
@1,660,152us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Adding DSP segment #1 to Link conf
iguration: name='DSPLINKMEM', startAddress=0x88100000, sizeInBytes=0x100000, shared=1
@1,660,412us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Adding DSP segment #2 to Link conf
iguration: name='RESET_VECTOR', startAddress=0x88000000, sizeInBytes=0x80, shared=0
@1,660,650us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Adding DSP segment #3 to Link conf
iguration: name='DDRALGHEAP', startAddress=0x88800000, sizeInBytes=0x1c00000, shared=0
@1,660,856us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> DOPOWERCONTROL was=0; now=0
SET WIDTH to 720 HEIGHT to 576
@1,685,617us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Attaching to DSP PROC...
@1,698,711us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Opening MSGQ pool...
@1,699,722us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Loading ./server_release.x64P on D
SP (1 args)...
@1,892,865us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Starting DSP PROC...
@1,916,709us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> Opening remote transport...
@1,917,511us: [+2 T:0x00004002 S:0xbe5ffa74] OP - Processor_create_d> return (1)
@1,918,475us: [+0 T:0x00004002 S:0xbe5ffa64] ti.sdo.ce.osal.Sem - Entered Sem_post> sem[0x5e220]
@1,918,948us: [+0 T:0x00008003 S:0xbe3ff96c] ti.sdo.ce.osal.Sem - Leaving Sem_pend> sem[0x5e220] status[
0]
@1,919,260us: [+0 T:0x00008003 S:0xbe3ff98c] OP - doCmd> Exit (result=1)
@1,919,438us: [+0 T:0x00008003 S:0xbe3ff9ac] OP - Processor_create> return (0x605d8)
@1,919,611us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - rserverOpen('./server_release.x64P'): 0x5701c done.
@1,919,799us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc> Enter(0x1e)
@1,919,990us: [+0 T:0x00008003 S:0xbe3ff9cc] OM - Memory_alloc> return (0x61fd0)
@1,920,188us: [+0 T:0x00008003 S:0xbe3ff9bc] OC - Comm_create> Enter(queueName='vca_engine_0', queue=0x6
05b8, attrs=0x0)
@1,920,370us: [+0 T:0x00008003 S:0xbe3ff9a4] OM - Memory_alloc> Enter(0x4)
@1,920,579us: [+0 T:0x00008003 S:0xbe3ff9a4] OM - Memory_alloc> return (0x61ff8)
@1,921,144us: [+0 T:0x00008003 S:0xbe3ff9bc] OC - Comm_create> return (0x61ff8)
@1,921,384us: [+0 T:0x00008003 S:0xbe3ff9bc] OM - Memory_free> Enter(0x61fd0, 0x1e)
@1,921,582us: [+0 T:0x00008003 S:0xbe3ff9bc] OM - Memory_free> return (0x1)
@1,921,758us: [+0 T:0x00008003 S:0xbe3ff9c4] OC - Comm_alloc> Enter(poolId=0x0, msg=0x605c4, size=576)
@1,921,990us: [+0 T:0x00008003 S:0xbe3ff9c4] OC - Comm_alloc> msg=0x413dbc80, returning (0)
@1,922,187us: [+0 T:0x00008003 S:0xbe3ff9a4] OC - Comm_locate> Enter(queueName='rmsq', queue=0x605b4)
@1,931,192us: [+0 T:0x00008003 S:0xbe3ff9a4] OC - Comm_locate> return (0)
@1,931,465us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - checkServer(0x605a8)
@1,931,739us: [+0 T:0x00008003 S:0xbe3ff9b4] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@1,932,050us: [+0 T:0x00008003 S:0xbe3ff9b4] OC - Comm_put> return (0)
@1,932,339us: [+0 T:0x00008003 S:0xbe3ff9ac] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ffa28, timeout
=-1)
@1,932,567us: [+0 T:0x00008003 S:0xbe3ff9ac] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@1,932,768us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - rmsInit> RMS initialized(0x605a8); CE_DEBUG on, settin
g DSP trace mask to *+01234567,GT_prefix=12345,GT_time=3
@1,932,966us: [+0 T:0x00008003 S:0xbe3ff9b4] CE - Engine_setTrace> Enter(engine=0x605a8, mask='*+0123456
7,GT_prefix=12345,GT_time=3')
@1,933,180us: [+1 T:0x00008003 S:0xbe3ff9b4] CE - Engine_setTrace> Requesting DSP set trace ...
@1,933,348us: [+0 T:0x00008003 S:0xbe3ff984] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@1,933,635us: [+0 T:0x00008003 S:0xbe3ff984] OC - Comm_put> return (0)
@1,933,821us: [+0 T:0x00008003 S:0xbe3ff97c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff9ec, timeout
=-1)
@1,934,437us: [+0 T:0x00004002 S:0xbe5ffa74] ti.sdo.ce.osal.Sem - Leaving Sem_post> sem[0x5e220]
@1,934,692us: [+0 T:0x00004002 S:0xbe5ffa74] OP - getCmd_d> Enter (proc=0xbe5ffaec)
@1,934,920us: [+0 T:0x00004002 S:0xbe5ffa54] ti.sdo.ce.osal.Sem - Entered Sem_pend> sem[0x5e208] timeout
[0xffffffff]
@1,937,498us: [+0 T:0x00008003 S:0xbe3ff97c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@1,937,904us: [+0 T:0x00008003 S:0xbe3ff9b4] CE - Engine_setTrace> return(0)
@1,938,126us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@1,938,384us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put> return (0)
@1,938,673us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff9d0, timeout
=-1)
@1,938,903us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @0x00000208:[T:0x00000000] ZZ - main> Welcome to loopback server's main().
[DSP] @0x0000086c:[T:0x8880415c] LS - server()
[DSP] @0x0000088d:[T:0x8880415c] OM - Memory_alloc> Enter(size=0x24)
[DSP] @0x000008b8:[T:0x8880415c] OM - Memory_alloc> return (0x882ab060)
[DSP] @0x000008e6:[T:0x8880415c] LS - server: serverMsgQueue = 0x00000001
[DSP] @0x0000090f:[T:0x8880415c] LS - server: waiting for cmd
[DSP] @0x00008cc2:[T:0x8880006c] CR - processRmsCmd(0x88105ca8, 4056): cmd = 6
[DSP] @0x00009b1c:[T:0x8880006c] CR - processRmsCmd(0x88105ca8, 4056): cmd = 8
[DSP] @0x00009b50:[T:0x8880006c] CR - setting trace mask to *+01234567,GT_prefix=12345,GT_time=3
[DSP] @0,039,852tk: [+0 T:0x8880006c S:0x88803fdc] OG - Global_setSpecialTrace> enter(mask='*+01234567,G
T_prefix=12345,GT_time=3')
[DSP] @0,039,938tk: [+4 T:0x8880006c S:0x88803fdc] OG - Global_setSpecialTrace> This program was built w
ith the following packages:
[DSP] @0,040,015tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.targets.rts6000 (/home/vcastab/sv
n/udp/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/targets/rts6000/) [1,0,0,0,1203621186754]
[DSP] @0,040,139tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.fc.dman3 (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/fc/dman3/) [1,0,3,122094305
3023]
[DSP] @0,040,255tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.rtdx (/home/vcastab/svn/udp/linux
/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/rtdx/) [2,0,0,1,1194024051755]
[DSP] @0,040,356tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.psl (/home/vcastab/svn/udp/linux/
dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/psl/) [5,0,0,0,0]
[DSP] @0,040,451tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.bios (/home/vcastab/svn/udp/linux
/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/bios/) [5,2,4,9,1193960176642]
[DSP] @0,040,552tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.fc.dskt2 (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/fc/dskt2/) [1,0,4,122094309
5081]
[DSP] @0,040,668tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.xdais.dm (/home/vcastab/svn/udp/l
inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/dm/) [1,0,4,1210262746529]
[DSP] @0,040,781tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.xdais (/home/vcastab/svn/udp/linu
x/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/) [1,2,1,1210262742149]
[DSP] @0,040,890tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.node (/home/vcastab/svn/ud
p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/node/) [1,0,0,1220951122176]
[DSP] @0,041,001tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.ipc.dsplink.dsp (/home/vca
stab/svn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/dsplink/dsp/) [2,0
,1,1220951102696]
[DSP] @0,041,122tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.utils.trace (/home/vcastab/sv
n/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/utils/trace/) [1,0,0,122
0943366422]
[DSP] @0,041,242tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.utils.xdm (/home/vcastab/s
vn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/utils/xdm/) [1,0,1,122095132
2616]
[DSP] @0,041,357tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.fc.acpy3 (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/fc/acpy3/) [1,0,2,122094301
4135]
[DSP] @0,041,473tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package dsplink.dsp (/home/vcastab/svn/udp/l
inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/dsplink/dsp/) [1,3,0]
[DSP] @0,041,578tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.bios.utils (/home/vcastab/svn/udp
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/bios/utils/) [2,0,1,0,11918918306
09]
[DSP] @0,041,693tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.catalog.c6000 (/home/vcastab/svn/
udp/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/catalog/c6000/) [1,0,0,0,1203561781695]
[DSP] @0,041,802t at 2,297,823us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put> Enter(queue=0x0, msg=0x413d
bc80)
@2,298,120us: [+0 T:0x00008003 S:0xbe3ff944] OC - Comm_put> return (0)
@2,298,417us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff9d0, timeout
=-1)
@2,298,649us: [+0 T:0x00008003 S:0xbe3ff93c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
k: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.platforms.evmDM6446 (/home/vcastab/svn/udp/linux/d
vsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/platforms/evmDM6446/) [1,0,0,1,1192229600615]
[DSP] @0,041,919tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.osal (/home/vcastab/svn/ud
p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/osal/) [2,0,2,1220951127739]
[DSP] @0,042,030tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.ipc (/home/vcastab/svn/udp
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/) [2,0,1,1220951085787]
[DSP] @0,042,139tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.alg (/home/vcastab/svn/udp
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/alg/) [1,0,1,1220950781938]
[DSP] @0,042,249tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.osal.bios (/home/vcastab/s
vn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/osal/bios/) [2,0,1,122095113
3740]
[DSP] @0,042,365tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.ipc.bios (/home/vcastab/sv
n/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/bios/) [2,0,1,12209510910
97]
[DSP] @0,042,487tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce (/home/vcastab/svn/udp/lin
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/) [1,0,6,1220950771473]
[DSP] @0,042,593tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.bioslog (/home/vcastab/svn
/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/bioslog/) [1,0,1,1220950800329
]
[DSP] @0,042,706tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package ti.sdo.ce.video (/home/vcastab/svn/u
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/video/) [1,0,3,1220951334122]
[DSP] @0,042,818tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package codecs.vca_stab (/home/vcastab/svn/v
t/davinci/trunk/ce1/codecs/vca_stab/) []
[DSP] @0,042,901tk: [+4 T:0x8880006c S:0x88803fdc] OG -     package servers.vca_stab_server (/home/vcast
ab/svn/vt/davinci/trunk/ce1/servers/vca_stab_server/) []
[DSP] @0,042,992tk: [+0 T:0x8880006c S:0x88803fdc] OG - Global_setSpecialTrace> return
[DSP] @0,050,728tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @0,050,799tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
[DSP] @0,885,481tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @0,885,547tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@2,650,231us: [+0 T:0x00008003 S:0xbe3ff974] CE - Engine_fwriteTrace> returning count [6828]
@2,650,445us: [+0 T:0x00008003 S:0xbe3ff9e4] CE - Engine_open> return(394664)
@2,650,660us: [+0 T:0x00008003 S:0xbe3ffa34] ti.sdo.ce.video.VIDENC - VIDENC_create> Enter (engine=0x605
a8, name='vca_stab', params=0xbe3ffa88)
@2,650,896us: [+0 T:0x00008003 S:0xbe3ffa04] CV - VISA_create(0x605a8, 'vca_stab', 0xbe3ffa88, 0x828, 't
i.sdo.ce.video.IVIDENC')
@2,651,104us: [+0 T:0x00008003 S:0xbe3ff92c] CV - VISA_create2(0x605a8, 'vca_stab', 0xbe3ffa88, 0x2c, 0x
828, 'ti.sdo.ce.video.IVIDENC')
@2,651,363us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc> Enter(0x30)
@2,651,589us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc> return (0x62058)
@2,651,782us: [+0 T:0x00008003 S:0xbe3ff8bc] CE - Engine_createNode(0x605a8, 'vca_stab', 828, 0xbe3ffa88
, 0x2c, 0xbe3ffa30)
@2,651,980us: [+0 T:0x00008003 S:0xbe3ff8a4] OM - Memory_alloc> Enter(0x20)
@2,652,163us: [+0 T:0x00008003 S:0xbe3ff8a4] OM - Memory_alloc> return (0x61fd0)
@2,652,361us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_create> Enter(queueName='gppfromnode_1', queue=0x
61fd8, attrs=0x0)
@2,652,545us: [+0 T:0x00008003 S:0xbe3ff87c] OM - Memory_alloc> Enter(0x4)
@2,652,730us: [+0 T:0x00008003 S:0xbe3ff87c] OM - Memory_alloc> return (0x62090)
@2,993,385us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_create> return (0x62090)
@2,993,649us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@2,993,987us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put> return (0)
@2,994,199us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff914, timeout
=-1)
@3,010,127us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@3,010,439us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@3,010,710us: [+0 T:0x00008003 S:0xbe3ff89c] OC - Comm_put> return (0)
@3,010,993us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff914, timeout
=-1)
@3,011,253us: [+0 T:0x00008003 S:0xbe3ff894] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@3,011,492us: [+4 T:0x00008003 S:0xbe3ff8bc] CE - Engine_createNode> created node(stdIn=0x2, stdOut=0x10
001, msgq=0x62090, algName='vca_stab', rmsNode=0x882ab088, algHandle=0x882ab168)
@3,011,735us: [+0 T:0x00008003 S:0xbe3ff81c] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@3,011,981us: [+0 T:0x00008003 S:0xbe3ff81c] OC - Comm_put> return (0)
@3,012,254us: [+0 T:0x00008003 S:0xbe3ff814] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff8a8, timeout
=-1)
@3,012,488us: [+0 T:0x00008003 S:0xbe3ff814] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @2,500,228tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 0
[DSP] @2,500,305tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc> Enter(size=0x18)
[DSP] @2,500,365tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc> return (0x882ab088)
[DSP] @2,500,425tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc> Enter(size=0xb)
[DSP] @2,500,480tk: [+0 T:0x8880006c S:0x88803f14] OM - Memory_alloc> return (0x882ab0a0)
[DSP] @2,500,549tk: [+0 T:0x8880006c S:0x88803edc] OM - Memory_alloc> Enter(size=0x20)
[DSP] @2,500,605tk: [+0 T:0x8880006c S:0x88803edc] OM - Memory_alloc> return (0x882ab0b0)
[DSP] @2,500,665tk: [+0 T:0x8880006c S:0x88803eac] OM - Memory_alloc> Enter(size=0x24)
[DSP] @2,500,722tk: [+0 T:0x8880006c S:0x88803eac] OM - Memory_alloc> return (0x882ab0d0)
[DSP] @2,500,806tk: [+0 T:0x8880006c S:0x88803ec4] ti.sdo.ce.video.VIDENC - VIDENC_create> Enter (engine
=0x0, name='vca_stab', params=0x88105cc0)
[DSP] @2,500,902tk: [+0 T:0x8880006c S:0x88803e8c] CV - VISA_create(0x0, 'vca_stab', 0x88105cc0, 0x828,
'ti.sdo.ce.video.IVIDENC')
[DSP] @2,500,988tk: [+0 T:0x8880006c S:0x88803d7c] CV - VISA_create2(0x0, 'vca_stab', 0x88105cc0, 0x2c,
0x828, 'ti.sdo.ce.video.IVIDENC')
[DSP] @2,501,089tk: [+0 T:0x8880006c S:0x88803d14] CE - Engine_open> Enter('local', 0x88803d6c, 0x33c)
[DSP] @2,501,158tk: [+0 T:0x8880006c S:0x88803cf4] OM - Memory_alloc> Enter(size=0x2c)
[DSP] @2,501,216tk: [+0 T:0x8880006c S:0x88803cf4] OM - Memory_alloc> return (0x882ab138)
[DSP] @2,501,287tk: [+0 T:0x8880006c S:0x88803d14] CE - Engine_open> return(-2010468040)
[DSP] @2,501,362tk: [+0 T:0x8880006c S:0x88803d5c] OM - Memory_alloc> Enter(size=0x30)
[DSP] @2,501,418tk: [+0 T:0x8880006c S:0x88803d5c] OM - Memory_alloc> return (0x882ab168)
[DSP] @2,501,484tk: [+0 T:0x8880006c S:0x88803d34] ti.sdo.ce.alg.Algorithm - Algorithm_create> Enter(fxn
s=0x88266574, idma3Fxns=0x882665a0, params=0x88105cc0, attrs=0x88803e80)
[DSP] @2,501,595tk: [+0 T:0x8880006c S:0x88803d14] OM - Memory_alloc> Enter(size=0x10)
[DSP] @2,501,652tk: [+0 T:0x8880006c S:0x88803d14] OM - Memory_alloc> return (0x882ab198)
[DSP] @2,519,578tk: [+0 T:0x8880006c S:0x88803c34] OM - Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn
Bytes=1008)
[DSP] @2,519,697tk: [+0 T:0x8880006c S:0x88803c34] OM - Memory_cacheWbInv> return
[DSP] @2,535,121tk: [+0 T:0x8880006c S:0x88803c0c] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @2,535,236tk: [+0 T:0x8880006c S:0x88803c0c] OM - Memory_cacheWbInv> return
[DSP] @2,535,480tk: [+0 T:0x8880006c S:0x88803bc4] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @2,535,566tk: [+0 T:0x8880006c S:0x88803bc4] OM - Memory_cacheWbInv> return
[DSP] @2,535,835tk: [+0 T:0x8880006c S:0x88803b9c] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @2,535,925tk: [+0 T:0x8880006c S:0x88803b9c] OM - Memory_cacheWbInv> return
[DSP] @2,536,688tk: [+0 T:0x8880006c S:0x88803cb4] OM - Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn
Bytes=1008)
[DSP] @2,536,793tk: [+0 T:0x8880006c S:0x88803cb4] OM - Memory_cacheWbInv> return
[DSP] @2,536,915tk: [+0 T:0x8880006c S:0x88803d34] ti.sdo.ce.alg.Algorithm - Algorithm_create> return (0
x882ab198)
[DSP] @2,536,997tk: [+0 T:0x8880006c S:0x88803ec4] ti.sdo.ce.video.VIDENC - VIDENC_create> return (0x882
ab168)
[DSP] @2,537,080tk: [+4 T:0x8880006c S:0x88803e84] OT - Thread_create > name: "vca_stab#0", pri:  -1, st
ack size:  16384, stack seg: 0
[DSP] @2,539,051tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 1
[DSP] @2,541,980tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @2,542,048tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@3,369,765us: [+0 T:0x00008003 S:0xbe3ff84c] CE - Engine_fwriteTrace> returning count [3758]
@3,369,981us: [+2 T:0x00008003 S:0xbe3ff8bc] CE - Engine_createNode> Returning 0x61fd0
@3,370,160us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc> Enter(0x4)
@3,370,349us: [+0 T:0x00008003 S:0xbe3ff914] OM - Memory_alloc> return (0x620a0)
@3,370,528us: [+0 T:0x00008003 S:0xbe3ff90c] OC - Comm_alloc> Enter(poolId=0x0, msg=0x620a0, size=828)
@3,370,760us: [+0 T:0x00008003 S:0xbe3ff90c] OC - Comm_alloc> msg=0x413dcc80, returning (0)
@3,370,981us: [+5 T:0x00008003 S:0xbe3ff92c] CV - VISA_create> remote codec created (name='vca_stab', lo
calQueueID=0x10001, remoteQueueID=0x0002)
@3,371,235us: [+0 T:0x00008003 S:0xbe3ffa34] ti.sdo.ce.video.VIDENC - VIDENC_create> return (0x62058)
@3,374,722us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62
058, id=257, params=0x5abe8, status=0xbe3ffa28
@3,375,009us: [+5 T:0x00008003 S:0xbe3ff844] CV - VISA_allocMsg> Allocating message for messageId=0x0002
0006
@3,375,208us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
0020006, command=0x1
@3,375,431us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@3,375,692us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put> return (0)
@3,375,884us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3ff884, timeout
=-1)
@3,376,737us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@3,377,056us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@3,377,322us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put> return (0)
@3,377,720us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff800, timeout
=-1)
@3,378,173us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @3,385,962tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88
2ab168, msg=0x88106c80); messageId=0x00020006
[DSP] @3,386,079tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl
e=0x882ab168, id=257, params=0x88106cb4, status=0x88106d00
[DSP] @3,386,192tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_enter(visa=0x882ab168): algHandle = 0x882ab
198
[DSP] @3,386,267tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h
andle=0x882ab198)
[DSP] @3,386,383tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> return
[DSP] @3,386,881tk: [+0 T:0x8892e644 S:0x889324c4] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @3,386,997tk: [+0 T:0x8892e644 S:0x889324c4] OM - Memory_cacheWbInv> return
[DSP] @3,387,126tk: [+0 T:0x8892e644 S:0x889324b4] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @3,387,203tk: [+0 T:0x8892e644 S:0x889324b4] OM - Memory_cacheWbInv> return
[DSP] @3,387,442tk: [+0 T:0x8892e644 S:0x8893248c] OM - Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn
Bytes=32)
[DSP] @3,387,538tk: [+0 T:0x8892e644 S:0x8893248c] OM - Memory_cacheWbInv> return
[DSP] @3,387,604tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_exit(visa=0x882ab168): algHandle = 0x882ab1
98
[DSP] @3,387,679tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter
(handle=0x882ab198)
[DSP] @3,387,760tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur
n
[DSP] @3,387,834tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle
=0x882ab168, retVal=0x0)
[DSP] @3,387,919tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned from call(algHandle=0x882ab168, m
sg=0x88106c80); messageId=0x00020006
[DSP] @3,389,753tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @3,389,829tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@3,727,875us: [+0 T:0x00008003 S:0xbe3ff7a4] CE - Engine_fwriteTrace> returning count [2039]
@3,728,094us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call Completed: messageId=0x00020006, command=0x1
, return(status=0)
@3,728,332us: [+5 T:0x00008003 S:0xbe3ff834] CV - VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit
h messageId=0x00020006
@3,728,530us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620
58, retVal=0x0)
@3,728,715us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62
058, id=259, params=0x5abe8, status=0xbe3ff930
@3,728,916us: [+5 T:0x00008003 S:0xbe3ff844] CV - VISA_allocMsg> Allocating message for messageId=0x0002
0007
@3,729,097us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
0020007, command=0x1
@3,729,285us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@3,729,551us: [+0 T:0x00008003 S:0xbe3ff7f4] OC - Comm_put> return (0)
@3,729,751us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3ff884, timeout
=-1)
@3,730,056us: [+0 T:0x00008003 S:0xbe3ff7ec] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@3,730,282us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@3,730,528us: [+0 T:0x00008003 S:0xbe3ff774] OC - Comm_put> return (0)
@3,730,802us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3ff800, timeout
=-1)
@3,731,055us: [+0 T:0x00008003 S:0xbe3ff76c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @4,206,979tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88
2ab168, msg=0x88106c80); messageId=0x00020007
[DSP] @4,207,083tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl
e=0x882ab168, id=259, params=0x88106cb4, status=0x88106d00
[DSP] @4,207,189tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_enter(visa=0x882ab168): algHandle = 0x882ab
198
[DSP] @4,207,262tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h
andle=0x882ab198)
[DSP] @4,207,346tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> return
[DSP] @4,207,420tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_exit(visa=0x882ab168): algHandle = 0x882ab1
98
[DSP] @4,207,494tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter
(handle=0x882ab198)
[DSP] @4,207,571tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur
n
[DSP] @4,207,636tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle
=0x882ab168, retVal=0x0)
[DSP] @4,207,714tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned from call(algHandle=0x882ab168, m
sg=0x88106c80); messageId=0x00020007
[DSP] @4,209,298tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @4,209,366tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@4,078,103us: [+0 T:0x00008003 S:0xbe3ff7a4] CE - Engine_fwriteTrace> returning count [1451]
@4,078,339us: [+0 T:0x00008003 S:0xbe3ff824] CV - VISA_call Completed: messageId=0x00020007, command=0x1
, return(status=0)
@4,078,546us: [+5 T:0x00008003 S:0xbe3ff834] CV - VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit
h messageId=0x00020007
@4,078,742us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620
58, retVal=0x0)
SVN Version: 3093:3110
STAB Version: 01.06.08
@4,079,044us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> Enter(size=28, align=-1, cached=FA
LSE, heap=FALSE)
@4,079,389us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> CMEM_alloc(28) = 0x4144b000.
@4,079,680us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> CMEM_getPhys(0x4144b000) = 0x8c9ba
000.
@4,079,883us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> Enter(virtAddr=0x4144b000, size=
28, physAddr=0x8c9ba000)
@4,080,074us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> creating new contigBuf object
@4,080,242us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc> Enter(0x10)
@4,080,453us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc> return (0x60fb0)
@4,080,628us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> returning: cb->phys=0x8c9ba000,
cb->size=28, cb->virt=0x4144b000
@4,080,810us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> return (0x4144b000)
@4,081,014us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> Enter(size=32, align=-1, cached=FA
LSE, heap=FALSE)
@4,081,323us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> CMEM_alloc(32) = 0x41458000.
@4,081,570us: [+4 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> CMEM_getPhys(0x41458000) = 0x8c9ad
000.
@4,081,763us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> Enter(virtAddr=0x41458000, size=
32, physAddr=0x8c9ad000)
@4,081,953us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> creating new contigBuf object
@4,082,119us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc> Enter(0x10)
@4,082,348us: [+0 T:0x00008003 S:0xbe3ff9f4] OM - Memory_alloc> return (0x620b0)
@4,082,535us: [+1 T:0x00008003 S:0xbe3ffa0c] OM - Memory__addContigBuf> returning: cb->phys=0x8c9ad000,
cb->size=32, cb->virt=0x41458000
@4,082,729us: [+0 T:0x00008003 S:0xbe3ffa64] OM - Memory_contigAlloc> return (0x41458000)
MAC: 00:13:23:04:13:46 USN: 970041346
@4,349,545us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62
058, id=41216, params=0xbe3fedb8, status=0xbe3fed28
@4,349,833us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg> Allocating message for messageId=0x0002
0008
@4,350,045us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
0020008, command=0x1
@4,350,250us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@4,350,512us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> return (0)
@4,350,710us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3fea24, timeout
=-1)
@4,351,302us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@4,351,574us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@4,351,839us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> return (0)
@4,352,129us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3fe9a0, timeout
=-1)
@4,352,373us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @5,647,854tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88
2ab168, msg=0x88106c80); messageId=0x00020008
[DSP] @5,647,953tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl
e=0x882ab168, id=41216, params=0x88106cb4, status=0x88106cfc
[DSP] @5,648,057tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_enter(visa=0x882ab168): algHandle = 0x882ab
198
[DSP] @5,648,128tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h
andle=0x882ab198)
[DSP] @5,648,202tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> return
[DSP] @5,648,776tk: [+0 T:0x8892e644 S:0x88932504] OM - Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn
Bytes=1008)
[DSP] @5,648,876tk: [+0 T:0x8892e644 S:0x88932504] OM - Memory_cacheWbInv> return
[DSP] @5,648,930tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_exit(visa=0x882ab168): algHandle = 0x882ab1
98
[DSP] @5,649,005tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter
(handle=0x882ab198)
[DSP] @5,649,084tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur
n
[DSP] @5,649,150tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle
=0x882ab168, retVal=0x0)
[DSP] @5,649,235tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned from call(algHandle=0x882ab168, m
sg=0x88106c80); messageId=0x00020008
[DSP] @5,650,934tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @5,651,005tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@4,359,446us: [+0 T:0x00008003 S:0xbe3fe944] CE - Engine_fwriteTrace> returning count [1651]
@4,359,654us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call Completed: messageId=0x00020008, command=0x1
, return(status=0)
@4,359,857us: [+5 T:0x00008003 S:0xbe3fe9d4] CV - VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit
h messageId=0x00020008
@4,360,055us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620
58, retVal=0x0)
@4,360,248us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62
058, id=41217, params=0xbe3fec28, status=0xbe3fed28
@4,360,484us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg> Allocating message for messageId=0x0002
0009
@4,360,680us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
0020009, command=0x1
@4,360,873us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@4,361,117us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> return (0)
@4,361,309us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3fea24, timeout
=-1)
@4,366,972us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@4,367,246us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@4,787,772us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> return (0)
@4,788,103us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3fe9a0, timeout
=-1)
@4,788,354us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @5,672,464tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88
2ab168, msg=0x88106c80); messageId=0x00020009
[DSP] @5,672,568tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl
e=0x882ab168, id=41217, params=0x88106cb4, status=0x88106db0
[DSP] @5,672,674tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_enter(visa=0x882ab168): algHandle = 0x882ab
198
[DSP] @5,672,747tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h
andle=0x882ab198)
[DSP] @5,672,827tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> return
[DSP] @5,685,069tk: [+0 T:0x8892e644 S:0x88932494] OM - Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn
Bytes=1008)
[DSP] @5,685,193tk: [+0 T:0x8892e644 S:0x88932494] OM - Memory_cacheWbInv> return
[DSP] @5,685,259tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_exit(visa=0x882ab168): algHandle = 0x882ab1
98
[DSP] @5,685,335tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter
(handle=0x882ab198)
[DSP] @5,685,417tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur
n
[DSP] @5,685,488tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle
=0x882ab168, retVal=0x0)
[DSP] @5,685,621tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned from call(algHandle=0x882ab168, m
sg=0x88106c80); messageId=0x00020009
[DSP] @6,662,444tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @6,662,522tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@4,795,428us: [+0 T:0x00008003 S:0xbe3fe944] CE - Engine_fwriteTrace> returning count [1651]
@4,795,640us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call Completed: messageId=0x00020009, command=0x1
, return(status=0)
@4,795,851us: [+5 T:0x00008003 S:0xbe3fe9d4] CV - VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit
h messageId=0x00020009
@4,796,075us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620
58, retVal=0x0)
@4,796,289us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62
058, id=41218, params=0xbe3fec28, status=0xbe3feac0
@4,796,501us: [+5 T:0x00008003 S:0xbe3fe9e4] CV - VISA_allocMsg> Allocating message for messageId=0x0002
000a
@4,796,692us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
002000a, command=0x1
@4,796,891us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@4,797,345us: [+0 T:0x00008003 S:0xbe3fe994] OC - Comm_put> return (0)
@4,797,723us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3fea24, timeout
=-1)
@4,798,173us: [+0 T:0x00008003 S:0xbe3fe98c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
@4,798,433us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> Enter(queue=0x0, msg=0x413dbc80)
@4,798,694us: [+0 T:0x00008003 S:0xbe3fe914] OC - Comm_put> return (0)
@4,799,015us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> Enter(queue=0x10000, msg=0xbe3fe9a0, timeout
=-1)
@4,799,256us: [+0 T:0x00008003 S:0xbe3fe90c] OC - Comm_get> MSGQ_Get() status=0x8000, return (0)
[DSP] @6,684,637tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88
2ab168, msg=0x88106c80); messageId=0x0002000a
[DSP] @6,684,743tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl
e=0x882ab168, id=41218, params=0x88106cb4, status=0x88106db0
[DSP] @6,684,853tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_enter(visa=0x882ab168): algHandle = 0x882ab
198
[DSP] @6,684,927tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h
andle=0x882ab198)
[DSP] @6,685,011tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> return
[DSP] @6,685,660tk: [+0 T:0x8892e644 S:0x88932504] OM - Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn
Bytes=1008)
[DSP] @6,685,789tk: [+0 T:0x8892e644 S:0x88932504] OM - Memory_cacheWbInv> return
[DSP] @6,685,848tk: [+5 T:0x8892e644 S:0x8893252c] CV - VISA_exit(visa=0x882ab168): algHandle = 0x882ab1
98
[DSP] @6,685,921tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter
(handle=0x882ab198)
[DSP] @6,686,001tk: [+0 T:0x8892e644 S:0x8893250c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur
n
[DSP] @6,686,067tk: [+0 T:0x8892e644 S:0x8893254c] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle
=0x882ab168, retVal=0x0)
[DSP] @6,686,152tk: [+5 T:0x8892e644 S:0x88932604] CN - NODE> returned from call(algHandle=0x882ab168, m
sg=0x88106c80); messageId=0x0002000a
[DSP] @6,687,790tk: [+0 T:0x8880006c S:0x88804024] CR - processRmsCmd(0x88105ca8, 4056): cmd = 5
[DSP] @6,687,860tk: [+0 T:0x8880006c S:0x88804024] CR - remote time = 0x0, trace buffer size = 4032
@5,146,922us: [+0 T:0x00008003 S:0xbe3fe944] CE - Engine_fwriteTrace> returning count [1651]
@5,147,356us: [+0 T:0x00008003 S:0xbe3fe9c4] CV - VISA_call Completed: messageId=0x0002000a, command=0x1
, return(status=0)
@5,147,728us: [+5 T:0x00008003 S:0xbe3fe9d4] CV - VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit
h messageId=0x0002000a
@5,147,971us: [+0 T:0x00008003 S:0xbe3fea14] ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620
58, retVal=0x0)
@5,174,837us: [+0 T:0x00008003 S:0xbe3ff874] ti.sdo.ce.video.VIDENC - VIDENC_process> Enter (handle=0x62
058, inBufs=0xbe3ffac0, outBufs=0xbe3ffab0, inArgs=0xbe3ff8fc, outArgs=0xbe3ffa10)
@5,175,123us: [+5 T:0x00008003 S:0xbe3ff7fc] CV - VISA_allocMsg> Allocating message for messageId=0x0002
000b
@5,175,328us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x404c
9000, size=884736)
@5,175,514us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x404c9000,
 size=884736)
@5,175,692us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> found in cb(Sc=0x404c9000,
 Ec=0x405a1000, Ss=0x404c9000, Es=0x405a1000, PSc=0x8cac7000)
@5,175,934us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> returning physAddr=0x8cac7
000
@5,176,105us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> return (0x8cac7000)
@5,176,280us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4145
8000, size=32)
@5,176,450us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x41458000,
 size=32)
@5,176,621us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> found in cb(Sc=0x41458000,
 Ec=0x41458020, Ss=0x41458000, Es=0x41458020, PSc=0x8c9ad000)
@5,176,811us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> returning physAddr=0x8c9ad
000
@5,176,980us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> return (0x8c9ad000)
@5,177,150us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x407c
9000, size=884736)
@5,177,369us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x407c9000,
 size=884736)
@5,177,545us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> found in cb(Sc=0x407c9000,
 Ec=0x408a1000, Ss=0x407c9000, Es=0x408a1000, PSc=0x8fc94000)
@5,177,918us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> returning physAddr=0x8fc94
000
@5,178,105us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> return (0x8fc94000)
@5,178,281us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4144
b000, size=28)
@5,178,460us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x4144b000,
 size=28)
@5,178,664us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> found in cb(Sc=0x4144b000,
 Ec=0x4144b01c, Ss=0x4144b000, Es=0x4144b01c, PSc=0x8c9ba000)
@5,520,076us: [+1 T:0x00008003 S:0xbe3ff7cc] OM - Memory__getPhysicalAddress> returning physAddr=0x8c9ba
000
@5,520,313us: [+0 T:0x00008003 S:0xbe3ff7cc] OM - Memory_getBufferPhysicalAddress> return (0x8c9ba000)
@5,520,501us: [+0 T:0x00008003 S:0xbe3ff80c] CV - VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0
002000b, command=0x0
@5,520,695us: [+0 T:0x00008003 S:0xbe3ff7dc] OC - Comm_put> Enter(queue=0x2, msg=0x413dcc80)
@5,520,929us: [+0 T:0x00008003 S:0xbe3ff7dc] OC - Comm_put> return (0)
@5,521,114us: [+0 T:0x00008003 S:0xbe3ff7d4] OC - Comm_get> Enter(queue=0x10001, msg=0xbe3ff87c, timeout
=-1)


After this it locks up and never returns control to the ARM after the VIDENC_process() call.

It looks like its locking up inside the Codec Engine after returning from the DSP side process call.

Can anyone shed some light on whats going wrong?


Regards,
Etienne Eccles

VCA Technology

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100414/87582db4/attachment-0001.html>

From sshtylyov at mvista.com  Wed Apr 14 16:18:15 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Thu, 15 Apr 2010 01:18:15 +0400
Subject: [PATCH v3 07/16] Davinci: gpio - struct renames
In-Reply-To: <1271270702-28307-8-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
Message-ID: <4BC63117.3050604@mvista.com>

Hello.

Cyril Chemparathy wrote:

> Renamed gpio structures to something more sensible:
> 	struct gpio_controller 	--> struct davinci_gpio_regs
> 	struct davinci_gpio	--> struct davinci_gpio_controller
>
> This change also moves davinci_gpio_controller definition to gpio.h.
> Eventually, the gpio registers structure will be moved to gpio.c and no longer
> a common cross-soc definition.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
> ---
> v3: reverted back on direction_in/out unification
>   

   Well, you could have kept it...

> diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
> index 5a045e6..6c470a7 100644
> --- a/arch/arm/mach-davinci/gpio.c
> +++ b/arch/arm/mach-davinci/gpio.c
>   
[...]
> @@ -288,7 +282,7 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset)
>  
>  static int gpio_irq_type_unbanked(unsigned irq, unsigned trigger)
>  {
> -	struct gpio_controller __iomem *g = irq2controller(irq);
> +	struct davinci_gpio_regs __iomem *g = irq2controller(irq);
>   

   The irq2controller() macro probably needs renaming too -- something 
like irq2regs()...

WBR, Sergei


From sshtylyov at mvista.com  Wed Apr 14 16:57:16 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Thu, 15 Apr 2010 01:57:16 +0400
Subject: [PATCH v3 16/16] Davinci: tnetv107x evm board initial support
In-Reply-To: <1271270702-28307-17-git-send-email-cyril@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
	<1271270702-28307-9-git-send-email-cyril@ti.com>
	<1271270702-28307-10-git-send-email-cyril@ti.com>
	<1271270702-28307-11-git-send-email-cyril@ti.com>
	<1271270702-28307-12-git-send-email-cyril@ti.com>
	<1271270702-28307-13-git-send-email-cyril@ti.com>
	<1271270702-28307-14-git-send-email-cyril@ti.com>
	<1271270702-28307-15-git-send-email-cyril@ti.com>
	<1271270702-28307-16-git-send-email-cyril@ti.com>
	<1271270702-28307-17-git-send-email-cyril@ti.com>
Message-ID: <4BC63A3C.7000402@mvista.com>

Hello.

Cyril Chemparathy wrote:

> Added support for tnetv107x evaluation module.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
>   
[...]
> diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c b/arch/arm/mach-davinci/board-tnetv107x-evm.c
> new file mode 100644
> index 0000000..2fa06ec
> --- /dev/null
> +++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
> @@ -0,0 +1,281 @@
> +/*
> + * TI TNETV107X EVM board
> + *
> + * Author: Cyril Chemparathy <cyril at ti.com>
> + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * Derived from: arch/arm/mach-davinci/board-da830-evm.c
> + * Original copyrights follow.
> + *
> + * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This program
> + * is licensed "as is" without any warranty of any kind, whether express
> + * or implied.
> + */
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/console.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/interrupt.h>
> +#include <linux/gpio.h>
> +#include <linux/delay.h>
> +#include <linux/serial_8250.h>
> +#include <linux/platform_device.h>
> +#include <linux/mtd/mtd.h>
> +#include <linux/mtd/partitions.h>
> +#include <linux/mtd/physmap.h>
>   

   You shouldn't need physmap.h as you don't have the corresponding device.

> +#include <asm/mach/arch.h>
> +#include <asm/mach-types.h>
> +
> +#include <mach/irqs.h>
> +#include <mach/edma.h>
> +#include <mach/mmc.h>
> +#include <mach/serial.h>
> +#include <mach/mux.h>
> +#include <mach/nand.h>
> +#include <mach/tnetv107x.h>
> +
> +/* Base addresses for on-chip devices */
> +#define TNETV107X_SDIO1_BASE			0x08088800
> +#define TNETV107X_ASYNC_EMIF_CNTRL_BASE		0x08200000
> +#define TNETV107X_ASYNC_EMIF_DATA_CE0_BASE	0x30000000
> +#define TNETV107X_DDR_BASE			0x80000000
>   

   I doubt that boarc code is a good place for base address macros. The 
"declare-where-used" rule shouldn't be taken to an absurdistic extreme. :-)
Althought you're following an existing example here... :-/

> +
> +#define TNETV107X_DMACH_SDIO1_RX		28
> +#define TNETV107X_DMACH_SDIO1_TX		29
>   

   Same remark here...

> +static struct plat_serial8250_port tnetv107x_serial_pdata[] = {
> +	{
> +		.mapbase	= TNETV107X_UART0_BASE,
> +		.irq		= IRQ_TNETV107X_UART0,
> +		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
> +					UPF_FIXED_TYPE | UPF_IOREMAP,
> +		.type		= PORT_AR7,
> +		.iotype		= UPIO_MEM32,
> +		.regshift	= 2,
> +	},
> +	{
> +		.mapbase	= TNETV107X_UART1_BASE,
> +		.irq		= IRQ_TNETV107X_UART1,
> +		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
> +					UPF_FIXED_TYPE | UPF_IOREMAP,
> +		.type		= PORT_AR7,
> +		.iotype		= UPIO_MEM32,
> +		.regshift	= 2,
> +	},
> +	{
> +		.flags	= 0,
> +	},
> +};
> +
> +static struct platform_device tnetv107x_serial_device = {
> +	.name			= "serial8250",
> +	.id			= PLAT8250_DEV_PLATFORM,
> +	.dev			= {
> +		.platform_data	= tnetv107x_serial_pdata,
> +	},
> +};
>   

   Why the SoC level UART device is registered at board level?

> +static struct platform_device tnetv107x_evm_mmc_device = {
> +	.name		= "davinci_mmc",
> +	.id		= 1,
> +	.dev		= {
> +		.dma_mask		= &tnetv107x_evm_mmc_dma_mask,
> +		.coherent_dma_mask	= DMA_BIT_MASK(32),
> +		.platform_data		= &tnetv107x_evm_mmc_config,
> +	},
> +	.num_resources	= ARRAY_SIZE(tnetv107x_evm_mmc_resources),
> +	.resource	= tnetv107x_evm_mmc_resources
> +};
>   

   Same question here...

> +static const short tnetv107x_sdio1_pins[] = {
> +	TNETV107X_SDIO1_CLK_1,		TNETV107X_SDIO1_CMD_1,
> +	TNETV107X_SDIO1_DATA0_1,	TNETV107X_SDIO1_DATA1_1,
> +	TNETV107X_SDIO1_DATA2_1,	TNETV107X_SDIO1_DATA3_1,
> +	-1
> +};
> +
> +const short tnetv107x_uart1_pins[] = {
> +	TNETV107X_UART1_RD,		TNETV107X_UART1_TD,
> +	-1
> +};
> +
> +static const short tnetv107x_gpio_pins[] = {
> +	TNETV107X_GPIO21, TNETV107X_GPIO24, TNETV107X_GPIO23,
>   

   These pins do not really belong with GPIO anymore, they belong to the 
MMC and whatever device, so should be in appropriate lists, shouldn't they?

WBR, Sergei


From cyril at ti.com  Wed Apr 14 17:16:09 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Wed, 14 Apr 2010 18:16:09 -0400
Subject: [PATCH v3 07/16] Davinci: gpio - struct renames
In-Reply-To: <4BC63117.3050604@mvista.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
	<4BC63117.3050604@mvista.com>
Message-ID: <4BC63EA9.8060507@ti.com>

Hi Sergei,

Thanks for the quick look.

>> v3: reverted back on direction_in/out unification
> 
>    Well, you could have kept it...

That would have ended up with unnecessary conditional logic, I thought.

>> diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
>> index 5a045e6..6c470a7 100644
>> --- a/arch/arm/mach-davinci/gpio.c
>> +++ b/arch/arm/mach-davinci/gpio.c
>>   
> [...]
>> @@ -288,7 +282,7 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset)
>>  
>>  static int gpio_irq_type_unbanked(unsigned irq, unsigned trigger)
>>  {
>> -	struct gpio_controller __iomem *g = irq2controller(irq);
>> +	struct davinci_gpio_regs __iomem *g = irq2controller(irq);
>>   
> 
>    The irq2controller() macro probably needs renaming too -- something 
> like irq2regs()...

Ok, will do.

Thanks
Cyril.

From idriss.ghodhbane at gmail.com  Thu Apr 15 03:47:38 2010
From: idriss.ghodhbane at gmail.com (Idriss Ghodhbane)
Date: Thu, 15 Apr 2010 10:47:38 +0200
Subject: AIC33+DM355
Message-ID: <s2s90d17c5d1004150147rb8e52058t352c8f1c672e11a4@mail.gmail.com>

Hi everybody,

I am wondering how I could support the AIC33 audio codec
for the ALSA driver on my DM355 EVM.
Thanks in advance.

Best Regards
-- 
IDRISS GHODHBANE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100415/5046e1dd/attachment.html>

From Etienne.Eccles at vcatechnology.com  Thu Apr 15 04:30:42 2010
From: Etienne.Eccles at vcatechnology.com (Etienne Eccles)
Date: Thu, 15 Apr 2010 10:30:42 +0100
Subject: Codec engine lockup
In-Reply-To: <92CDD168D1E81F4F9D3839DC45903FC676C834C2@dlee03.ent.ti.com>
References: <95FAFD227E8A2947BA96E1C807505D0412CD5F@sbs001.office.local>
	<92CDD168D1E81F4F9D3839DC45903FC676C07D7E@dlee03.ent.ti.com>
	<95FAFD227E8A2947BA96E1C807505D0412CD67@sbs001.office.local>
	<92CDD168D1E81F4F9D3839DC45903FC676C834C2@dlee03.ent.ti.com>
Message-ID: <95FAFD227E8A2947BA96E1C807505D0412CD6F@sbs001.office.local>

I found the problem was an uninitialized outArgs struct. Since I don't
use it in my codec I was not doing anything with it. 

What was happening is the reconBufs were pointing to garbage memory
locations so the Cache invalidation inside videnc_skel.c was causing the
lock up.

 

Thanks a lot for you help

 

Etienne 

 

From: Ring, Chris [mailto:cring at ti.com] 
Sent: 14 April 2010 17:32
To: Etienne Eccles; davinci-linux-open-source at linux.davincidsp.com
Subject: RE: Codec engine lockup

 

After your process() fxn, the call flow returns into the VIDENC
skeleton.  (You can find the sources in
packages/ti/sdo/ce/video/videnc_skel.c)

 

There's basically some cache calls (your outbuf and outArgs->reconBufs
buffer descriptors are correct, right?), and the skeleton's call()
method returns.  After that, CE will send the "I'm done" reply msg to
the ARM.  This reply will unblock the ARM side (which is what we're
_not_ seeing).

 

Another thing to try is to link in the CE debug libs (when building your
Server) which will let you step through the DSP-side CE code after your
process() call returns.  How to link in debug libs unfortunately changes
a little from release to release - I think in CE 2.10.02, you would set
the following line in your Server's package.bld build script:

 

   Pkg.attrs.profile = "debug";

 

You can sanity check that you're linking in the debug libs as you'll see
output during build like:

 

    will link with ti.sdo.ce.video:lib/debug/video.a64P

Chris

	 

	
________________________________


	From: Etienne Eccles [mailto:Etienne.Eccles at vcatechnology.com] 
	Sent: Wednesday, April 14, 2010 1:59 AM
	To: Ring, Chris; davinci-linux-open-source at linux.davincidsp.com
	Subject: RE: Codec engine lockup

	Hi Chris

	 

	Thanks for the reply. 

	I have actually done what you suggested, and I can see that the
DSP side process call completes successfully and returns. I have even
gone so far as to remove the entire body of DSP side process function
and immediately return with IALG_EOK.  That's why I suspected it must be
locking up in the codec engine after completing the DSP side process.

	 

	This lock up  problem is also not repeatable. It only occurs on
about 20% of hardware examples and under certain booting conditions 

	 

	Etienne  

	 

	From: Ring, Chris [mailto:cring at ti.com] 
	Sent: 13 April 2010 18:57
	To: Etienne Eccles;
davinci-linux-open-source at linux.davincidsp.com
	Subject: RE: Codec engine lockup

	 

	The last line is an ARM-side Comm_get() call (implemented with
MSGQ_get()) - which blocks until the DSP finishes it's job and sends an
'I'm done' reply message.  Basically, you've sent a request to
VIDENC_process() a frame which never returns.  The DSP is
hanging/crashing/waiting and never returning "I'm done" to the ARM.

	 

	Can you connect to CCS and see what's happening on the DSP side?
Since this is your codec, maybe set breakpoints in your process() method
and see if it ever gets called.

	 

	
http://wiki.davincidsp.com/index.php/Debugging_the_DSP_side_of_a_CE_appl
ication_using_CCS

	 

	Chris

		 

		
________________________________


		From:
davinci-linux-open-source-bounces at linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On
Behalf Of Etienne Eccles
		Sent: Tuesday, April 13, 2010 5:39 AM
		To: davinci-linux-open-source at linux.davincidsp.com
		Subject: Codec engine lockup

		 

		H

		 

		 

		I am getting the following debug output . using
CE_DEBUG=3 when creating and using a custom VIDENC codec:

		 

		 

		 

		root at nvc1346:/opt/davinci# CE_DEBUG=3 ./stabd -d -p a

		root at nvc1346:/opt/davinci# @0,196,096us: [+4
T:0x00004000 S:0xbec8cbbc] OG - Global_init> This program w

		as built with the following packages:

		@0,197,108us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package gnu.targets.rts470MV (/home/vcastab/svn/ud

	
p/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/gnu/targets/rts470MV
/) [1,0,0,0,1203621000516]

		@0,197,334us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package dsplink.gpp (/home/vcastab/svn/udp/linux/d

	
vsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/dsplink/gpp/
) [3,0,0]

		@0,197,516us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.xdais.dm (/home/vcastab/svn/udp/linux/d

	
vsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/dm/
) [1,0,4,1210262746529]

		@0,197,948us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.xdais (/home/vcastab/svn/udp/linux/dvsd

	
k/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/)
[1,2,1,1210262742149]

		@0,198,149us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.sdo.utils.trace (/home/vcastab/svn/udp/

	
linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sd
o/utils/trace/) [1,0,0,122094336

		6422]

		@0,198,331us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.sdo.ce.utils.xdm (/home/vcastab/svn/udp

	
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ut
ils/xdm/) [1,0,1,1220951322616]

		@0,198,510us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.sdo.fc.dman3 (/home/vcastab/svn/udp/lin

	
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/f
c/dman3/) [1,0,3,1220943053023]

		@0,198,682us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.sdo.fc.acpy3 (/home/vcastab/svn/udp/lin

	
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/sdo/f
c/acpy3/) [1,0,2,1220943014135]

		@0,198,852us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.sdo.linuxutils.cmem (/home/vcastab/svn/

	
udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/t
i/sdo/linuxutils/cmem/) [2,0,1,1

		204929560755]

		@0,199,030us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.catalog.c470 (/home/vcastab/svn/udp/lin

	
ux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/catalog/c470/)
[1,0,1,0,1203561761475]

		@0,199,200us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.platforms.evmDM6446 (/home/vcastab/svn/

	
udp/linux/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/platforms/evmD
M6446/) [1,0,0,1,1192229600615]

		@0,199,369us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.sdo.ce.osal (/home/vcastab/svn/udp/linu

	
x/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/osal/)
[2,0,2,1220951127739]

		@0,199,539us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.sdo.ce.ipc (/home/vcastab/svn/udp/linux

	
/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ipc/)
[2,0,1,1220951085787]

		@0,199,704us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.sdo.ce.alg (/home/vcastab/svn/udp/linux

	
/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/alg/)
[1,0,1,1220950781938]

		@0,199,875us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.sdo.ce.osal.linux (/home/vcastab/svn/ud

	
p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/o
sal/linux/) [2,0,1,1220951140072

		]

		@0,200,049us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.sdo.ce.ipc.dsplink (/home/vcastab/svn/u

	
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/
ipc/dsplink/) [2,0,1,12209510968

		18]

		@0,200,219us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.sdo.ce (/home/vcastab/svn/udp/linux/dvs

	
dk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/)
[1,0,6,1220950771473]

		@0,200,386us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.sdo.ce.video (/home/vcastab/svn/udp/lin

	
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/video/
) [1,0,3,1220951334122]

		@0,200,559us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package codecs.vca_stab (/home/vcastab/svn/vt/davi

		nci/trunk/ce1/codecs/vca_stab/) []

		@0,200,718us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.sdo.ce.bioslog (/home/vcastab/svn/udp/l

	
inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/bios
log/) [1,0,1,1220950800329]

		@0,587,586us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package ti.sdo.ce.utils.trace (/home/vcastab/svn/u

	
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/
utils/trace/) [1,0,1,12209513170

		87]

		@0,587,929us: [+4 T:0x00004000 S:0xbec8cbbc] OG -
package apps.stab_client (/home/vcastab/svn/vt/dav

		inci/trunk/ce1/apps/stab_client/) []

		@0,588,146us: [+0 T:0x00004000 S:0xbec8cbc4] OG -
Global_atexit> enter (fxn=0x20028)

		@0,588,352us: [+0 T:0x00004000 S:0xbec8cbc4] OG -
Global_atexit> enter (fxn=0x1f4c0)

		@0,588,676us: [+0 T:0x00004000 S:0xbec8cb94] OM -
Memory_alloc> Enter(0x18)

		@0,589,026us: [+0 T:0x00004000 S:0xbec8cb94] OM -
Memory_alloc> return (0x5e138)

		@0,589,716us: [+0 T:0x00004000 S:0xbec8cbb4] OG -
Global_atexit> enter (fxn=0x1dda8)

		@0,590,050us: [+0 T:0x00004000 S:0xbec8cb94] OM -
Memory_alloc> Enter(0x18)

		@0,590,269us: [+0 T:0x00004000 S:0xbec8cb94] OM -
Memory_alloc> return (0x5e188)

		@0,590,492us: [+0 T:0x00004000 S:0xbec8cbb4] OG -
Global_atexit> enter (fxn=0x1b9f4)

		@0,590,839us: [+0 T:0x00004000 S:0xbec8cbbc] OG -
Global_atexit> enter (fxn=0x1eb44)

		@0,593,794us: [+0 T:0x00004000 S:0xbec8cba4]
ti.sdo.ce.osal.Sem - Sem_create> count: 0

		@0,594,023us: [+0 T:0x00004000 S:0xbec8cb8c] OM -
Memory_alloc> Enter(0x14)

		@0,594,212us: [+0 T:0x00004000 S:0xbec8cb8c] OM -
Memory_alloc> return (0x5e208)

		@0,594,470us: [+0 T:0x00004000 S:0xbec8cba4]
ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x5e208]

		@0,594,698us: [+0 T:0x00004000 S:0xbec8cba4]
ti.sdo.ce.osal.Sem - Sem_create> count: 0

		@0,594,859us: [+0 T:0x00004000 S:0xbec8cb8c] OM -
Memory_alloc> Enter(0x14)

		@0,595,056us: [+0 T:0x00004000 S:0xbec8cb8c] OM -
Memory_alloc> return (0x5e220)

		@0,595,220us: [+0 T:0x00004000 S:0xbec8cba4]
ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x5e220]

		@0,595,378us: [+0 T:0x00004000 S:0xbec8cb8c] OM -
Memory_alloc> Enter(0x18)

		@0,595,544us: [+0 T:0x00004000 S:0xbec8cb8c] OM -
Memory_alloc> return (0x5e238)

		@0,595,707us: [+0 T:0x00004000 S:0xbec8cb8c] OT -
Thread_create> Enter (fxn=0x1ab34, attrs=0x0)

		@0,595,869us: [+0 T:0x00004000 S:0xbec8cb74] OM -
Memory_alloc> Enter(0x64)

		@0,596,064us: [+0 T:0x00004000 S:0xbec8cb74] OM -
Memory_alloc> return (0x5e258)

		@0,598,964us: [+1 T:0x00004002 S:0xbe5ffa74] OP -
daemon> thread created.

		@0,599,205us: [+0 T:0x00004002 S:0xbe5ffa74] OP -
getCmd_d> Enter (proc=0xbe5ffaec)

		@0,599,387us: [+0 T:0x00004002 S:0xbe5ffa54]
ti.sdo.ce.osal.Sem - Entered Sem_pend> sem[0x5e208] timeout

		[0xffffffff]

		@0,599,998us: [+0 T:0x00004000 S:0xbec8cb8c] OT -
Thread_create> Exit (task=0x5e258)

		@0,600,235us: [+0 T:0x00004000 S:0xbec8cbc4] OG -
Global_atexit> enter (fxn=0x1a6f4)

		@0,600,501us: [+0 T:0x00004000 S:0xbec8cbc4] OG -
Global_atexit> enter (fxn=0x1c7e8)

		@0,600,791us: [+0 T:0x00004000 S:0xbec8cbac]
ti.sdo.ce.alg - ALG_init> Enter

		@0,600,984us: [+0 T:0x00004000 S:0xbec8cb9c] OG -
Global_atexit> enter (fxn=0x209f0)

		@0,601,171us: [+0 T:0x00004000 S:0xbec8cbcc]
ti.sdo.ce.alg - ALG_init> Exit

		@0,601,339us: [+0 T:0x00004000 S:0xbec8cbc4] OG -
Global_atexit> enter (fxn=0x20490)

		@0,601,541us: [+0 T:0x00004000 S:0xbec8cb9c] OM -
Memory_alloc> Enter(0x18)

		@0,601,767us: [+0 T:0x00004000 S:0xbec8cb9c] OM -
Memory_alloc> return (0x60418)

		@0,601,955us: [+0 T:0x00004000 S:0xbec8cbc4] OG -
Global_atexit> enter (fxn=0x1eca8)

		@0,602,262us: [+6 T:0x00004000 S:0xbec8cbc4] CE -
Engine_init> CE debugging on (CE_DEBUG=3; allowed CE_D

		EBUG levels: 1=min, 2=good, 3=max)

		@0,602,481us: [+0 T:0x00004000 S:0xbec8cbb4] OG -
Global_atexit> enter (fxn=0x17734)

		@0,602,667us: [+0 T:0x00004000 S:0xbec8cb94] OM -
Memory_alloc> Enter(0x18)

		@0,602,852us: [+0 T:0x00004000 S:0xbec8cb94] OM -
Memory_alloc> return (0x60458)

		@0,603,024us: [+0 T:0x00004000 S:0xbec8cb94] OM -
Memory_alloc> Enter(0x18)

		@0,603,247us: [+0 T:0x00004000 S:0xbec8cb94] OM -
Memory_alloc> return (0x60478)

		@0,603,423us: [+0 T:0x00004000 S:0xbec8cb94] OM -
Memory_alloc> Enter(0x18)

		@0,603,600us: [+0 T:0x00004000 S:0xbec8cb94] OM -
Memory_alloc> return (0x60498)

		@0,944,735us: [+0 T:0x00004000 S:0xbec8cbc4] CS -
Server_init()

		@0,944,957us: [+0 T:0x00004000 S:0xbec8cbc4] CS -
Server_init> Global_useLinkArbiter = 0

		@0,945,138us: [+0 T:0x00004000 S:0xbec8cbc4] OG -
Global_atexit> enter (fxn=0x16284)

		@0,945,529us: [+0 T:0x00004000 S:0xbec8cbd4] OG -
Global_atexit> enter (fxn=0x14148)

		@0,945,950us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> Enter(size=884736, align=-1, cache

		d=FALSE, heap=FALSE)

		@0,946,486us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_alloc(884736) = 0x403ee000.

		@0,946,744us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_getPhys(0x403ee000) = 0x8ff25

		000.

		@0,946,938us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> Enter(virtAddr=0x403ee000, size=

		884736, physAddr=0x8ff25000)

		@0,947,127us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> creating new contigBuf object

		@0,947,319us: [+0 T:0x00004000 S:0xbec8cb14] OM -
Memory_alloc> Enter(0x10)

		@0,947,514us: [+0 T:0x00004000 S:0xbec8cb14] OM -
Memory_alloc> return (0x60518)

		@0,947,842us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> returning: cb->phys=0x8ff25000,

		cb->size=884736, cb->virt=0x403ee000

		@0,948,044us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> return (0x403ee000)

		@0,948,270us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> Enter(size=884736, align=-1, cache

		d=FALSE, heap=FALSE)

		@0,948,643us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_alloc(884736) = 0x404c9000.

		@0,948,931us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_getPhys(0x404c9000) = 0x8cac7

		000.

		@0,949,123us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> Enter(virtAddr=0x404c9000, size=

		884736, physAddr=0x8cac7000)

		@0,949,305us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> creating new contigBuf object

		@0,949,467us: [+0 T:0x00004000 S:0xbec8cb14] OM -
Memory_alloc> Enter(0x10)

		@0,949,651us: [+0 T:0x00004000 S:0xbec8cb14] OM -
Memory_alloc> return (0x60530)

		@0,949,823us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> returning: cb->phys=0x8cac7000,

		cb->size=884736, cb->virt=0x404c9000

		@0,950,004us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> return (0x404c9000)

		@0,950,206us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> Enter(size=884736, align=-1, cache

		d=FALSE, heap=FALSE)

		@0,950,595us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_alloc(884736) = 0x405c9000.

		@0,950,841us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_getPhys(0x405c9000) = 0x8c9c7

		000.

		@0,951,032us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> Enter(virtAddr=0x405c9000, size=

		884736, physAddr=0x8c9c7000)

		@0,951,219us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> creating new contigBuf object

		@0,951,380us: [+0 T:0x00004000 S:0xbec8cb14] OM -
Memory_alloc> Enter(0x10)

		@0,951,592us: [+0 T:0x00004000 S:0xbec8cb14] OM -
Memory_alloc> return (0x60548)

		@0,951,775us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> returning: cb->phys=0x8c9c7000,

		cb->size=884736, cb->virt=0x405c9000

		@0,951,959us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> return (0x405c9000)

		@0,952,125us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> Enter(size=884736, align=-1, cache

		d=FALSE, heap=FALSE)

		@0,952,475us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_alloc(884736) = 0x406c9000.

		@0,952,718us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_getPhys(0x406c9000) = 0x8c879

		000.

		@0,952,911us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> Enter(virtAddr=0x406c9000, size=

		884736, physAddr=0x8c879000)

		@0,953,145us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> creating new contigBuf object

		@0,953,310us: [+0 T:0x00004000 S:0xbec8cb14] OM -
Memory_alloc> Enter(0x10)

		@0,953,490us: [+0 T:0x00004000 S:0xbec8cb14] OM -
Memory_alloc> return (0x60560)

		@1,294,466us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> returning: cb->phys=0x8c879000,

		cb->size=884736, cb->virt=0x406c9000

		@1,294,700us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> return (0x406c9000)

		@1,294,877us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> Enter(size=884736, align=-1, cache

		d=FALSE, heap=FALSE)

		@1,295,385us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_alloc(884736) = 0x407c9000.

		@1,295,626us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_getPhys(0x407c9000) = 0x8fc94

		000.

		@1,295,850us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> Enter(virtAddr=0x407c9000, size=

		884736, physAddr=0x8fc94000)

		@1,296,040us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> creating new contigBuf object

		@1,296,206us: [+0 T:0x00004000 S:0xbec8cb14] OM -
Memory_alloc> Enter(0x10)

		@1,296,387us: [+0 T:0x00004000 S:0xbec8cb14] OM -
Memory_alloc> return (0x60578)

		@1,296,557us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> returning: cb->phys=0x8fc94000,

		cb->size=884736, cb->virt=0x407c9000

		@1,296,739us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> return (0x407c9000)

		@1,296,908us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> Enter(size=884736, align=-1, cache

		d=FALSE, heap=FALSE)

		@1,297,589us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_alloc(884736) = 0x40a5a000.

		@1,298,146us: [+4 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> CMEM_getPhys(0x40a5a000) = 0x8f8de

		000.

		@1,298,345us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> Enter(virtAddr=0x40a5a000, size=

		884736, physAddr=0x8f8de000)

		@1,298,538us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> creating new contigBuf object

		@1,298,750us: [+0 T:0x00004000 S:0xbec8cb14] OM -
Memory_alloc> Enter(0x10)

		@1,298,934us: [+0 T:0x00004000 S:0xbec8cb14] OM -
Memory_alloc> return (0x60590)

		@1,299,106us: [+1 T:0x00004000 S:0xbec8cb2c] OM -
Memory__addContigBuf> returning: cb->phys=0x8f8de000,

		cb->size=884736, cb->virt=0x40a5a000

		@1,299,290us: [+0 T:0x00004000 S:0xbec8cb84] OM -
Memory_contigAlloc> return (0x40a5a000)

		@1,309,917us: [+0 T:0x00008003 S:0xbe3ff9e4] CE -
Engine_open> Enter('vca_engine', 0x0, 0xbe3ffa84)

		@1,310,205us: [+0 T:0x00008003 S:0xbe3ff9cc] OM -
Memory_alloc> Enter(0x2c)

		@1,310,419us: [+0 T:0x00008003 S:0xbe3ff9cc] OM -
Memory_alloc> return (0x605a8)

		@1,310,604us: [+0 T:0x00008003 S:0xbe3ff9e4] CE -
rserverOpen('./server_release.x64P'), count = 0

		@1,310,785us: [+0 T:0x00008003 S:0xbe3ff9ac] OP -
Processor_create> Enter(imageName='./server_release.x6

		4P', linkCfg='(null)', attrs=0xbe3ffa30)

		@1,312,833us: [+0 T:0x00008003 S:0xbe3ff994] OM -
Memory_alloc> Enter(0x24)

		@1,313,100us: [+0 T:0x00008003 S:0xbe3ff994] OM -
Memory_alloc> return (0x605d8)

		@1,313,292us: [+0 T:0x00008003 S:0xbe3ff98c] OP - doCmd>
Enter (cmdId=1, proc=0x605d8)

		@1,313,470us: [+0 T:0x00008003 S:0xbe3ff97c]
ti.sdo.ce.osal.Sem - Entered Sem_post> sem[0x5e208]

		@1,313,801us: [+0 T:0x00008003 S:0xbe3ff98c]
ti.sdo.ce.osal.Sem - Leaving Sem_post> sem[0x5e208]

		@1,314,019us: [+0 T:0x00008003 S:0xbe3ff96c]
ti.sdo.ce.osal.Sem - Entered Sem_pend> sem[0x5e220] timeout

		[0xffffffff]

		@1,314,506us: [+0 T:0x00004002 S:0xbe5ffa54]
ti.sdo.ce.osal.Sem - Leaving Sem_pend> sem[0x5e208] status[

		0]

		@1,314,978us: [+0 T:0x00004002 S:0xbe5ffa74] OP -
getCmd_d> Exit (result=1)

		@1,315,460us: [+0 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Enter(proc=0x605d8)

		@1,315,900us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Initializing DSP PROC...

		@1,316,335us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Using DspLink config data for entr

		y #0 [server './server_release.x64P']

		@1,316,786us: [+0 T:0x00004002 S:0xbe5ffa5c] OM -
Memory_alloc> Enter(0xe0)

		@1,317,458us: [+0 T:0x00004002 S:0xbe5ffa5c] OM -
Memory_alloc> return (0x60600)

		@1,318,325us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Adding DSP segment #0 to Link conf

		iguration: name='DDR', startAddress=0x88200000,
sizeInBytes=0x400000, shared=1

		@1,660,152us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Adding DSP segment #1 to Link conf

		iguration: name='DSPLINKMEM', startAddress=0x88100000,
sizeInBytes=0x100000, shared=1

		@1,660,412us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Adding DSP segment #2 to Link conf

		iguration: name='RESET_VECTOR', startAddress=0x88000000,
sizeInBytes=0x80, shared=0

		@1,660,650us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Adding DSP segment #3 to Link conf

		iguration: name='DDRALGHEAP', startAddress=0x88800000,
sizeInBytes=0x1c00000, shared=0

		@1,660,856us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> DOPOWERCONTROL was=0; now=0

		SET WIDTH to 720 HEIGHT to 576

		@1,685,617us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Attaching to DSP PROC...

		@1,698,711us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Opening MSGQ pool...

		@1,699,722us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Loading ./server_release.x64P on D

		SP (1 args)...

		@1,892,865us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Starting DSP PROC...

		@1,916,709us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> Opening remote transport...

		@1,917,511us: [+2 T:0x00004002 S:0xbe5ffa74] OP -
Processor_create_d> return (1)

		@1,918,475us: [+0 T:0x00004002 S:0xbe5ffa64]
ti.sdo.ce.osal.Sem - Entered Sem_post> sem[0x5e220]

		@1,918,948us: [+0 T:0x00008003 S:0xbe3ff96c]
ti.sdo.ce.osal.Sem - Leaving Sem_pend> sem[0x5e220] status[

		0]

		@1,919,260us: [+0 T:0x00008003 S:0xbe3ff98c] OP - doCmd>
Exit (result=1)

		@1,919,438us: [+0 T:0x00008003 S:0xbe3ff9ac] OP -
Processor_create> return (0x605d8)

		@1,919,611us: [+0 T:0x00008003 S:0xbe3ff9e4] CE -
rserverOpen('./server_release.x64P'): 0x5701c done.

		@1,919,799us: [+0 T:0x00008003 S:0xbe3ff9cc] OM -
Memory_alloc> Enter(0x1e)

		@1,919,990us: [+0 T:0x00008003 S:0xbe3ff9cc] OM -
Memory_alloc> return (0x61fd0)

		@1,920,188us: [+0 T:0x00008003 S:0xbe3ff9bc] OC -
Comm_create> Enter(queueName='vca_engine_0', queue=0x6

		05b8, attrs=0x0)

		@1,920,370us: [+0 T:0x00008003 S:0xbe3ff9a4] OM -
Memory_alloc> Enter(0x4)

		@1,920,579us: [+0 T:0x00008003 S:0xbe3ff9a4] OM -
Memory_alloc> return (0x61ff8)

		@1,921,144us: [+0 T:0x00008003 S:0xbe3ff9bc] OC -
Comm_create> return (0x61ff8)

		@1,921,384us: [+0 T:0x00008003 S:0xbe3ff9bc] OM -
Memory_free> Enter(0x61fd0, 0x1e)

		@1,921,582us: [+0 T:0x00008003 S:0xbe3ff9bc] OM -
Memory_free> return (0x1)

		@1,921,758us: [+0 T:0x00008003 S:0xbe3ff9c4] OC -
Comm_alloc> Enter(poolId=0x0, msg=0x605c4, size=576)

		@1,921,990us: [+0 T:0x00008003 S:0xbe3ff9c4] OC -
Comm_alloc> msg=0x413dbc80, returning (0)

		@1,922,187us: [+0 T:0x00008003 S:0xbe3ff9a4] OC -
Comm_locate> Enter(queueName='rmsq', queue=0x605b4)

		@1,931,192us: [+0 T:0x00008003 S:0xbe3ff9a4] OC -
Comm_locate> return (0)

		@1,931,465us: [+0 T:0x00008003 S:0xbe3ff9e4] CE -
checkServer(0x605a8)

		@1,931,739us: [+0 T:0x00008003 S:0xbe3ff9b4] OC -
Comm_put> Enter(queue=0x0, msg=0x413dbc80)

		@1,932,050us: [+0 T:0x00008003 S:0xbe3ff9b4] OC -
Comm_put> return (0)

		@1,932,339us: [+0 T:0x00008003 S:0xbe3ff9ac] OC -
Comm_get> Enter(queue=0x10000, msg=0xbe3ffa28, timeout

		=-1)

		@1,932,567us: [+0 T:0x00008003 S:0xbe3ff9ac] OC -
Comm_get> MSGQ_Get() status=0x8000, return (0)

		@1,932,768us: [+0 T:0x00008003 S:0xbe3ff9e4] CE -
rmsInit> RMS initialized(0x605a8); CE_DEBUG on, settin

		g DSP trace mask to *+01234567,GT_prefix=12345,GT_time=3

		@1,932,966us: [+0 T:0x00008003 S:0xbe3ff9b4] CE -
Engine_setTrace> Enter(engine=0x605a8, mask='*+0123456

		7,GT_prefix=12345,GT_time=3')

		@1,933,180us: [+1 T:0x00008003 S:0xbe3ff9b4] CE -
Engine_setTrace> Requesting DSP set trace ...

		@1,933,348us: [+0 T:0x00008003 S:0xbe3ff984] OC -
Comm_put> Enter(queue=0x0, msg=0x413dbc80)

		@1,933,635us: [+0 T:0x00008003 S:0xbe3ff984] OC -
Comm_put> return (0)

		@1,933,821us: [+0 T:0x00008003 S:0xbe3ff97c] OC -
Comm_get> Enter(queue=0x10000, msg=0xbe3ff9ec, timeout

		=-1)

		@1,934,437us: [+0 T:0x00004002 S:0xbe5ffa74]
ti.sdo.ce.osal.Sem - Leaving Sem_post> sem[0x5e220]

		@1,934,692us: [+0 T:0x00004002 S:0xbe5ffa74] OP -
getCmd_d> Enter (proc=0xbe5ffaec)

		@1,934,920us: [+0 T:0x00004002 S:0xbe5ffa54]
ti.sdo.ce.osal.Sem - Entered Sem_pend> sem[0x5e208] timeout

		[0xffffffff]

		@1,937,498us: [+0 T:0x00008003 S:0xbe3ff97c] OC -
Comm_get> MSGQ_Get() status=0x8000, return (0)

		@1,937,904us: [+0 T:0x00008003 S:0xbe3ff9b4] CE -
Engine_setTrace> return(0)

		@1,938,126us: [+0 T:0x00008003 S:0xbe3ff944] OC -
Comm_put> Enter(queue=0x0, msg=0x413dbc80)

		@1,938,384us: [+0 T:0x00008003 S:0xbe3ff944] OC -
Comm_put> return (0)

		@1,938,673us: [+0 T:0x00008003 S:0xbe3ff93c] OC -
Comm_get> Enter(queue=0x10000, msg=0xbe3ff9d0, timeout

		=-1)

		@1,938,903us: [+0 T:0x00008003 S:0xbe3ff93c] OC -
Comm_get> MSGQ_Get() status=0x8000, return (0)

		[DSP] @0x00000208:[T:0x00000000] ZZ - main> Welcome to
loopback server's main().

		[DSP] @0x0000086c:[T:0x8880415c] LS - server()

		[DSP] @0x0000088d:[T:0x8880415c] OM - Memory_alloc>
Enter(size=0x24)

		[DSP] @0x000008b8:[T:0x8880415c] OM - Memory_alloc>
return (0x882ab060)

		[DSP] @0x000008e6:[T:0x8880415c] LS - server:
serverMsgQueue = 0x00000001

		[DSP] @0x0000090f:[T:0x8880415c] LS - server: waiting
for cmd

		[DSP] @0x00008cc2:[T:0x8880006c] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 6

		[DSP] @0x00009b1c:[T:0x8880006c] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 8

		[DSP] @0x00009b50:[T:0x8880006c] CR - setting trace mask
to *+01234567,GT_prefix=12345,GT_time=3

		[DSP] @0,039,852tk: [+0 T:0x8880006c S:0x88803fdc] OG -
Global_setSpecialTrace> enter(mask='*+01234567,G

		T_prefix=12345,GT_time=3')

		[DSP] @0,039,938tk: [+4 T:0x8880006c S:0x88803fdc] OG -
Global_setSpecialTrace> This program was built w

		ith the following packages:

		[DSP] @0,040,015tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.targets.rts6000 (/home/vcastab/sv

	
n/udp/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/targets/rts60
00/) [1,0,0,0,1203621186754]

		[DSP] @0,040,139tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.fc.dman3 (/home/vcastab/svn/u

	
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti
/sdo/fc/dman3/) [1,0,3,122094305

		3023]

		[DSP] @0,040,255tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.rtdx (/home/vcastab/svn/udp/linux

		/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/rtdx/)
[2,0,0,1,1194024051755]

		[DSP] @0,040,356tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.psl (/home/vcastab/svn/udp/linux/

		dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/psl/)
[5,0,0,0,0]

		[DSP] @0,040,451tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.bios (/home/vcastab/svn/udp/linux

		/dvsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/bios/)
[5,2,4,9,1193960176642]

		[DSP] @0,040,552tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.fc.dskt2 (/home/vcastab/svn/u

	
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti
/sdo/fc/dskt2/) [1,0,4,122094309

		5081]

		[DSP] @0,040,668tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.xdais.dm (/home/vcastab/svn/udp/l

	
inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xda
is/dm/) [1,0,4,1210262746529]

		[DSP] @0,040,781tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.xdais (/home/vcastab/svn/udp/linu

	
x/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/xdais/
) [1,2,1,1210262742149]

		[DSP] @0,040,890tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.node (/home/vcastab/svn/ud

	
p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/n
ode/) [1,0,0,1220951122176]

		[DSP] @0,041,001tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.ipc.dsplink.dsp (/home/vca

	
stab/svn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/
ti/sdo/ce/ipc/dsplink/dsp/) [2,0

		,1,1220951102696]

		[DSP] @0,041,122tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.utils.trace (/home/vcastab/sv

	
n/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages
/ti/sdo/utils/trace/) [1,0,0,122

		0943366422]

		[DSP] @0,041,242tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.utils.xdm (/home/vcastab/s

	
vn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo
/ce/utils/xdm/) [1,0,1,122095132

		2616]

		[DSP] @0,041,357tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.fc.acpy3 (/home/vcastab/svn/u

	
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti
/sdo/fc/acpy3/) [1,0,2,122094301

		4135]

		[DSP] @0,041,473tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package dsplink.dsp (/home/vcastab/svn/udp/l

	
inux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/dsplin
k/dsp/) [1,3,0]

		[DSP] @0,041,578tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.bios.utils (/home/vcastab/svn/udp

	
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/cetools/packages/ti/b
ios/utils/) [2,0,1,0,11918918306

		09]

		[DSP] @0,041,693tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.catalog.c6000 (/home/vcastab/svn/

	
udp/linux/dvsdk/dvsdk_1_30_01_41/xdc_3_00_06/packages/ti/catalog/c6000/)
[1,0,0,0,1203561781695]

		[DSP] @0,041,802t at 2,297,823us: [+0 T:0x00008003
S:0xbe3ff944] OC - Comm_put> Enter(queue=0x0, msg=0x413d

		bc80)

		@2,298,120us: [+0 T:0x00008003 S:0xbe3ff944] OC -
Comm_put> return (0)

		@2,298,417us: [+0 T:0x00008003 S:0xbe3ff93c] OC -
Comm_get> Enter(queue=0x10000, msg=0xbe3ff9d0, timeout

		=-1)

		@2,298,649us: [+0 T:0x00008003 S:0xbe3ff93c] OC -
Comm_get> MSGQ_Get() status=0x8000, return (0)

		k: [+4 T:0x8880006c S:0x88803fdc] OG -     package
ti.platforms.evmDM6446 (/home/vcastab/svn/udp/linux/d

	
vsdk/dvsdk_1_30_01_41/bios_5_32_01/packages/ti/platforms/evmDM6446/)
[1,0,0,1,1192229600615]

		[DSP] @0,041,919tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.osal (/home/vcastab/svn/ud

	
p/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/o
sal/) [2,0,2,1220951127739]

		[DSP] @0,042,030tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.ipc (/home/vcastab/svn/udp

	
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/ip
c/) [2,0,1,1220951085787]

		[DSP] @0,042,139tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.alg (/home/vcastab/svn/udp

	
/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/al
g/) [1,0,1,1220950781938]

		[DSP] @0,042,249tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.osal.bios (/home/vcastab/s

	
vn/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo
/ce/osal/bios/) [2,0,1,122095113

		3740]

		[DSP] @0,042,365tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.ipc.bios (/home/vcastab/sv

	
n/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/
ce/ipc/bios/) [2,0,1,12209510910

		97]

		[DSP] @0,042,487tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce (/home/vcastab/svn/udp/lin

	
ux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/)
[1,0,6,1220950771473]

		[DSP] @0,042,593tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.bioslog (/home/vcastab/svn

	
/udp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/c
e/bioslog/) [1,0,1,1220950800329

		]

		[DSP] @0,042,706tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package ti.sdo.ce.video (/home/vcastab/svn/u

	
dp/linux/dvsdk/dvsdk_1_30_01_41/codec_engine_2_10_02/packages/ti/sdo/ce/
video/) [1,0,3,1220951334122]

		[DSP] @0,042,818tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package codecs.vca_stab (/home/vcastab/svn/v

		t/davinci/trunk/ce1/codecs/vca_stab/) []

		[DSP] @0,042,901tk: [+4 T:0x8880006c S:0x88803fdc] OG -
package servers.vca_stab_server (/home/vcast

		ab/svn/vt/davinci/trunk/ce1/servers/vca_stab_server/) []

		[DSP] @0,042,992tk: [+0 T:0x8880006c S:0x88803fdc] OG -
Global_setSpecialTrace> return

		[DSP] @0,050,728tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

		[DSP] @0,050,799tk: [+0 T:0x8880006c S:0x88804024] CR -
remote time = 0x0, trace buffer size = 4032

		[DSP] @0,885,481tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

		[DSP] @0,885,547tk: [+0 T:0x8880006c S:0x88804024] CR -
remote time = 0x0, trace buffer size = 4032

		@2,650,231us: [+0 T:0x00008003 S:0xbe3ff974] CE -
Engine_fwriteTrace> returning count [6828]

		@2,650,445us: [+0 T:0x00008003 S:0xbe3ff9e4] CE -
Engine_open> return(394664)

		@2,650,660us: [+0 T:0x00008003 S:0xbe3ffa34]
ti.sdo.ce.video.VIDENC - VIDENC_create> Enter (engine=0x605

		a8, name='vca_stab', params=0xbe3ffa88)

		@2,650,896us: [+0 T:0x00008003 S:0xbe3ffa04] CV -
VISA_create(0x605a8, 'vca_stab', 0xbe3ffa88, 0x828, 't

		i.sdo.ce.video.IVIDENC')

		@2,651,104us: [+0 T:0x00008003 S:0xbe3ff92c] CV -
VISA_create2(0x605a8, 'vca_stab', 0xbe3ffa88, 0x2c, 0x

		828, 'ti.sdo.ce.video.IVIDENC')

		@2,651,363us: [+0 T:0x00008003 S:0xbe3ff914] OM -
Memory_alloc> Enter(0x30)

		@2,651,589us: [+0 T:0x00008003 S:0xbe3ff914] OM -
Memory_alloc> return (0x62058)

		@2,651,782us: [+0 T:0x00008003 S:0xbe3ff8bc] CE -
Engine_createNode(0x605a8, 'vca_stab', 828, 0xbe3ffa88

		, 0x2c, 0xbe3ffa30)

		@2,651,980us: [+0 T:0x00008003 S:0xbe3ff8a4] OM -
Memory_alloc> Enter(0x20)

		@2,652,163us: [+0 T:0x00008003 S:0xbe3ff8a4] OM -
Memory_alloc> return (0x61fd0)

		@2,652,361us: [+0 T:0x00008003 S:0xbe3ff894] OC -
Comm_create> Enter(queueName='gppfromnode_1', queue=0x

		61fd8, attrs=0x0)

		@2,652,545us: [+0 T:0x00008003 S:0xbe3ff87c] OM -
Memory_alloc> Enter(0x4)

		@2,652,730us: [+0 T:0x00008003 S:0xbe3ff87c] OM -
Memory_alloc> return (0x62090)

		@2,993,385us: [+0 T:0x00008003 S:0xbe3ff894] OC -
Comm_create> return (0x62090)

		@2,993,649us: [+0 T:0x00008003 S:0xbe3ff89c] OC -
Comm_put> Enter(queue=0x0, msg=0x413dbc80)

		@2,993,987us: [+0 T:0x00008003 S:0xbe3ff89c] OC -
Comm_put> return (0)

		@2,994,199us: [+0 T:0x00008003 S:0xbe3ff894] OC -
Comm_get> Enter(queue=0x10000, msg=0xbe3ff914, timeout

		=-1)

		@3,010,127us: [+0 T:0x00008003 S:0xbe3ff894] OC -
Comm_get> MSGQ_Get() status=0x8000, return (0)

		@3,010,439us: [+0 T:0x00008003 S:0xbe3ff89c] OC -
Comm_put> Enter(queue=0x0, msg=0x413dbc80)

		@3,010,710us: [+0 T:0x00008003 S:0xbe3ff89c] OC -
Comm_put> return (0)

		@3,010,993us: [+0 T:0x00008003 S:0xbe3ff894] OC -
Comm_get> Enter(queue=0x10000, msg=0xbe3ff914, timeout

		=-1)

		@3,011,253us: [+0 T:0x00008003 S:0xbe3ff894] OC -
Comm_get> MSGQ_Get() status=0x8000, return (0)

		@3,011,492us: [+4 T:0x00008003 S:0xbe3ff8bc] CE -
Engine_createNode> created node(stdIn=0x2, stdOut=0x10

		001, msgq=0x62090, algName='vca_stab',
rmsNode=0x882ab088, algHandle=0x882ab168)

		@3,011,735us: [+0 T:0x00008003 S:0xbe3ff81c] OC -
Comm_put> Enter(queue=0x0, msg=0x413dbc80)

		@3,011,981us: [+0 T:0x00008003 S:0xbe3ff81c] OC -
Comm_put> return (0)

		@3,012,254us: [+0 T:0x00008003 S:0xbe3ff814] OC -
Comm_get> Enter(queue=0x10000, msg=0xbe3ff8a8, timeout

		=-1)

		@3,012,488us: [+0 T:0x00008003 S:0xbe3ff814] OC -
Comm_get> MSGQ_Get() status=0x8000, return (0)

		[DSP] @2,500,228tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 0

		[DSP] @2,500,305tk: [+0 T:0x8880006c S:0x88803f14] OM -
Memory_alloc> Enter(size=0x18)

		[DSP] @2,500,365tk: [+0 T:0x8880006c S:0x88803f14] OM -
Memory_alloc> return (0x882ab088)

		[DSP] @2,500,425tk: [+0 T:0x8880006c S:0x88803f14] OM -
Memory_alloc> Enter(size=0xb)

		[DSP] @2,500,480tk: [+0 T:0x8880006c S:0x88803f14] OM -
Memory_alloc> return (0x882ab0a0)

		[DSP] @2,500,549tk: [+0 T:0x8880006c S:0x88803edc] OM -
Memory_alloc> Enter(size=0x20)

		[DSP] @2,500,605tk: [+0 T:0x8880006c S:0x88803edc] OM -
Memory_alloc> return (0x882ab0b0)

		[DSP] @2,500,665tk: [+0 T:0x8880006c S:0x88803eac] OM -
Memory_alloc> Enter(size=0x24)

		[DSP] @2,500,722tk: [+0 T:0x8880006c S:0x88803eac] OM -
Memory_alloc> return (0x882ab0d0)

		[DSP] @2,500,806tk: [+0 T:0x8880006c S:0x88803ec4]
ti.sdo.ce.video.VIDENC - VIDENC_create> Enter (engine

		=0x0, name='vca_stab', params=0x88105cc0)

		[DSP] @2,500,902tk: [+0 T:0x8880006c S:0x88803e8c] CV -
VISA_create(0x0, 'vca_stab', 0x88105cc0, 0x828,

		'ti.sdo.ce.video.IVIDENC')

		[DSP] @2,500,988tk: [+0 T:0x8880006c S:0x88803d7c] CV -
VISA_create2(0x0, 'vca_stab', 0x88105cc0, 0x2c,

		0x828, 'ti.sdo.ce.video.IVIDENC')

		[DSP] @2,501,089tk: [+0 T:0x8880006c S:0x88803d14] CE -
Engine_open> Enter('local', 0x88803d6c, 0x33c)

		[DSP] @2,501,158tk: [+0 T:0x8880006c S:0x88803cf4] OM -
Memory_alloc> Enter(size=0x2c)

		[DSP] @2,501,216tk: [+0 T:0x8880006c S:0x88803cf4] OM -
Memory_alloc> return (0x882ab138)

		[DSP] @2,501,287tk: [+0 T:0x8880006c S:0x88803d14] CE -
Engine_open> return(-2010468040)

		[DSP] @2,501,362tk: [+0 T:0x8880006c S:0x88803d5c] OM -
Memory_alloc> Enter(size=0x30)

		[DSP] @2,501,418tk: [+0 T:0x8880006c S:0x88803d5c] OM -
Memory_alloc> return (0x882ab168)

		[DSP] @2,501,484tk: [+0 T:0x8880006c S:0x88803d34]
ti.sdo.ce.alg.Algorithm - Algorithm_create> Enter(fxn

		s=0x88266574, idma3Fxns=0x882665a0, params=0x88105cc0,
attrs=0x88803e80)

		[DSP] @2,501,595tk: [+0 T:0x8880006c S:0x88803d14] OM -
Memory_alloc> Enter(size=0x10)

		[DSP] @2,501,652tk: [+0 T:0x8880006c S:0x88803d14] OM -
Memory_alloc> return (0x882ab198)

		[DSP] @2,519,578tk: [+0 T:0x8880006c S:0x88803c34] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

		Bytes=1008)

		[DSP] @2,519,697tk: [+0 T:0x8880006c S:0x88803c34] OM -
Memory_cacheWbInv> return

		[DSP] @2,535,121tk: [+0 T:0x8880006c S:0x88803c0c] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

		Bytes=32)

		[DSP] @2,535,236tk: [+0 T:0x8880006c S:0x88803c0c] OM -
Memory_cacheWbInv> return

		[DSP] @2,535,480tk: [+0 T:0x8880006c S:0x88803bc4] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

		Bytes=32)

		[DSP] @2,535,566tk: [+0 T:0x8880006c S:0x88803bc4] OM -
Memory_cacheWbInv> return

		[DSP] @2,535,835tk: [+0 T:0x8880006c S:0x88803b9c] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

		Bytes=32)

		[DSP] @2,535,925tk: [+0 T:0x8880006c S:0x88803b9c] OM -
Memory_cacheWbInv> return

		[DSP] @2,536,688tk: [+0 T:0x8880006c S:0x88803cb4] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

		Bytes=1008)

		[DSP] @2,536,793tk: [+0 T:0x8880006c S:0x88803cb4] OM -
Memory_cacheWbInv> return

		[DSP] @2,536,915tk: [+0 T:0x8880006c S:0x88803d34]
ti.sdo.ce.alg.Algorithm - Algorithm_create> return (0

		x882ab198)

		[DSP] @2,536,997tk: [+0 T:0x8880006c S:0x88803ec4]
ti.sdo.ce.video.VIDENC - VIDENC_create> return (0x882

		ab168)

		[DSP] @2,537,080tk: [+4 T:0x8880006c S:0x88803e84] OT -
Thread_create > name: "vca_stab#0", pri:  -1, st

		ack size:  16384, stack seg: 0

		[DSP] @2,539,051tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 1

		[DSP] @2,541,980tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

		[DSP] @2,542,048tk: [+0 T:0x8880006c S:0x88804024] CR -
remote time = 0x0, trace buffer size = 4032

		@3,369,765us: [+0 T:0x00008003 S:0xbe3ff84c] CE -
Engine_fwriteTrace> returning count [3758]

		@3,369,981us: [+2 T:0x00008003 S:0xbe3ff8bc] CE -
Engine_createNode> Returning 0x61fd0

		@3,370,160us: [+0 T:0x00008003 S:0xbe3ff914] OM -
Memory_alloc> Enter(0x4)

		@3,370,349us: [+0 T:0x00008003 S:0xbe3ff914] OM -
Memory_alloc> return (0x620a0)

		@3,370,528us: [+0 T:0x00008003 S:0xbe3ff90c] OC -
Comm_alloc> Enter(poolId=0x0, msg=0x620a0, size=828)

		@3,370,760us: [+0 T:0x00008003 S:0xbe3ff90c] OC -
Comm_alloc> msg=0x413dcc80, returning (0)

		@3,370,981us: [+5 T:0x00008003 S:0xbe3ff92c] CV -
VISA_create> remote codec created (name='vca_stab', lo

		calQueueID=0x10001, remoteQueueID=0x0002)

		@3,371,235us: [+0 T:0x00008003 S:0xbe3ffa34]
ti.sdo.ce.video.VIDENC - VIDENC_create> return (0x62058)

		@3,374,722us: [+0 T:0x00008003 S:0xbe3ff874]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62

		058, id=257, params=0x5abe8, status=0xbe3ffa28

		@3,375,009us: [+5 T:0x00008003 S:0xbe3ff844] CV -
VISA_allocMsg> Allocating message for messageId=0x0002

		0006

		@3,375,208us: [+0 T:0x00008003 S:0xbe3ff824] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

		0020006, command=0x1

		@3,375,431us: [+0 T:0x00008003 S:0xbe3ff7f4] OC -
Comm_put> Enter(queue=0x2, msg=0x413dcc80)

		@3,375,692us: [+0 T:0x00008003 S:0xbe3ff7f4] OC -
Comm_put> return (0)

		@3,375,884us: [+0 T:0x00008003 S:0xbe3ff7ec] OC -
Comm_get> Enter(queue=0x10001, msg=0xbe3ff884, timeout

		=-1)

		@3,376,737us: [+0 T:0x00008003 S:0xbe3ff7ec] OC -
Comm_get> MSGQ_Get() status=0x8000, return (0)

		@3,377,056us: [+0 T:0x00008003 S:0xbe3ff774] OC -
Comm_put> Enter(queue=0x0, msg=0x413dbc80)

		@3,377,322us: [+0 T:0x00008003 S:0xbe3ff774] OC -
Comm_put> return (0)

		@3,377,720us: [+0 T:0x00008003 S:0xbe3ff76c] OC -
Comm_get> Enter(queue=0x10000, msg=0xbe3ff800, timeout

		=-1)

		@3,378,173us: [+0 T:0x00008003 S:0xbe3ff76c] OC -
Comm_get> MSGQ_Get() status=0x8000, return (0)

		[DSP] @3,385,962tk: [+5 T:0x8892e644 S:0x88932604] CN -
NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88

		2ab168, msg=0x88106c80); messageId=0x00020006

		[DSP] @3,386,079tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

		e=0x882ab168, id=257, params=0x88106cb4,
status=0x88106d00

		[DSP] @3,386,192tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

		198

		[DSP] @3,386,267tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

		andle=0x882ab198)

		[DSP] @3,386,383tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

		[DSP] @3,386,881tk: [+0 T:0x8892e644 S:0x889324c4] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

		Bytes=32)

		[DSP] @3,386,997tk: [+0 T:0x8892e644 S:0x889324c4] OM -
Memory_cacheWbInv> return

		[DSP] @3,387,126tk: [+0 T:0x8892e644 S:0x889324b4] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

		Bytes=32)

		[DSP] @3,387,203tk: [+0 T:0x8892e644 S:0x889324b4] OM -
Memory_cacheWbInv> return

		[DSP] @3,387,442tk: [+0 T:0x8892e644 S:0x8893248c] OM -
Memory_cacheWbInv> Enter(addr=0x8884eec0, sizeIn

		Bytes=32)

		[DSP] @3,387,538tk: [+0 T:0x8892e644 S:0x8893248c] OM -
Memory_cacheWbInv> return

		[DSP] @3,387,604tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

		98

		[DSP] @3,387,679tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

		(handle=0x882ab198)

		[DSP] @3,387,760tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

		n

		[DSP] @3,387,834tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

		=0x882ab168, retVal=0x0)

		[DSP] @3,387,919tk: [+5 T:0x8892e644 S:0x88932604] CN -
NODE> returned from call(algHandle=0x882ab168, m

		sg=0x88106c80); messageId=0x00020006

		[DSP] @3,389,753tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

		[DSP] @3,389,829tk: [+0 T:0x8880006c S:0x88804024] CR -
remote time = 0x0, trace buffer size = 4032

		@3,727,875us: [+0 T:0x00008003 S:0xbe3ff7a4] CE -
Engine_fwriteTrace> returning count [2039]

		@3,728,094us: [+0 T:0x00008003 S:0xbe3ff824] CV -
VISA_call Completed: messageId=0x00020006, command=0x1

		, return(status=0)

		@3,728,332us: [+5 T:0x00008003 S:0xbe3ff834] CV -
VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit

		h messageId=0x00020006

		@3,728,530us: [+0 T:0x00008003 S:0xbe3ff874]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620

		58, retVal=0x0)

		@3,728,715us: [+0 T:0x00008003 S:0xbe3ff874]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62

		058, id=259, params=0x5abe8, status=0xbe3ff930

		@3,728,916us: [+5 T:0x00008003 S:0xbe3ff844] CV -
VISA_allocMsg> Allocating message for messageId=0x0002

		0007

		@3,729,097us: [+0 T:0x00008003 S:0xbe3ff824] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

		0020007, command=0x1

		@3,729,285us: [+0 T:0x00008003 S:0xbe3ff7f4] OC -
Comm_put> Enter(queue=0x2, msg=0x413dcc80)

		@3,729,551us: [+0 T:0x00008003 S:0xbe3ff7f4] OC -
Comm_put> return (0)

		@3,729,751us: [+0 T:0x00008003 S:0xbe3ff7ec] OC -
Comm_get> Enter(queue=0x10001, msg=0xbe3ff884, timeout

		=-1)

		@3,730,056us: [+0 T:0x00008003 S:0xbe3ff7ec] OC -
Comm_get> MSGQ_Get() status=0x8000, return (0)

		@3,730,282us: [+0 T:0x00008003 S:0xbe3ff774] OC -
Comm_put> Enter(queue=0x0, msg=0x413dbc80)

		@3,730,528us: [+0 T:0x00008003 S:0xbe3ff774] OC -
Comm_put> return (0)

		@3,730,802us: [+0 T:0x00008003 S:0xbe3ff76c] OC -
Comm_get> Enter(queue=0x10000, msg=0xbe3ff800, timeout

		=-1)

		@3,731,055us: [+0 T:0x00008003 S:0xbe3ff76c] OC -
Comm_get> MSGQ_Get() status=0x8000, return (0)

		[DSP] @4,206,979tk: [+5 T:0x8892e644 S:0x88932604] CN -
NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88

		2ab168, msg=0x88106c80); messageId=0x00020007

		[DSP] @4,207,083tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

		e=0x882ab168, id=259, params=0x88106cb4,
status=0x88106d00

		[DSP] @4,207,189tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

		198

		[DSP] @4,207,262tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

		andle=0x882ab198)

		[DSP] @4,207,346tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

		[DSP] @4,207,420tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

		98

		[DSP] @4,207,494tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

		(handle=0x882ab198)

		[DSP] @4,207,571tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

		n

		[DSP] @4,207,636tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

		=0x882ab168, retVal=0x0)

		[DSP] @4,207,714tk: [+5 T:0x8892e644 S:0x88932604] CN -
NODE> returned from call(algHandle=0x882ab168, m

		sg=0x88106c80); messageId=0x00020007

		[DSP] @4,209,298tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

		[DSP] @4,209,366tk: [+0 T:0x8880006c S:0x88804024] CR -
remote time = 0x0, trace buffer size = 4032

		@4,078,103us: [+0 T:0x00008003 S:0xbe3ff7a4] CE -
Engine_fwriteTrace> returning count [1451]

		@4,078,339us: [+0 T:0x00008003 S:0xbe3ff824] CV -
VISA_call Completed: messageId=0x00020007, command=0x1

		, return(status=0)

		@4,078,546us: [+5 T:0x00008003 S:0xbe3ff834] CV -
VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit

		h messageId=0x00020007

		@4,078,742us: [+0 T:0x00008003 S:0xbe3ff874]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620

		58, retVal=0x0)

		SVN Version: 3093:3110

		STAB Version: 01.06.08

		@4,079,044us: [+0 T:0x00008003 S:0xbe3ffa64] OM -
Memory_contigAlloc> Enter(size=28, align=-1, cached=FA

		LSE, heap=FALSE)

		@4,079,389us: [+4 T:0x00008003 S:0xbe3ffa64] OM -
Memory_contigAlloc> CMEM_alloc(28) = 0x4144b000.

		@4,079,680us: [+4 T:0x00008003 S:0xbe3ffa64] OM -
Memory_contigAlloc> CMEM_getPhys(0x4144b000) = 0x8c9ba

		000.

		@4,079,883us: [+1 T:0x00008003 S:0xbe3ffa0c] OM -
Memory__addContigBuf> Enter(virtAddr=0x4144b000, size=

		28, physAddr=0x8c9ba000)

		@4,080,074us: [+1 T:0x00008003 S:0xbe3ffa0c] OM -
Memory__addContigBuf> creating new contigBuf object

		@4,080,242us: [+0 T:0x00008003 S:0xbe3ff9f4] OM -
Memory_alloc> Enter(0x10)

		@4,080,453us: [+0 T:0x00008003 S:0xbe3ff9f4] OM -
Memory_alloc> return (0x60fb0)

		@4,080,628us: [+1 T:0x00008003 S:0xbe3ffa0c] OM -
Memory__addContigBuf> returning: cb->phys=0x8c9ba000,

		cb->size=28, cb->virt=0x4144b000

		@4,080,810us: [+0 T:0x00008003 S:0xbe3ffa64] OM -
Memory_contigAlloc> return (0x4144b000)

		@4,081,014us: [+0 T:0x00008003 S:0xbe3ffa64] OM -
Memory_contigAlloc> Enter(size=32, align=-1, cached=FA

		LSE, heap=FALSE)

		@4,081,323us: [+4 T:0x00008003 S:0xbe3ffa64] OM -
Memory_contigAlloc> CMEM_alloc(32) = 0x41458000.

		@4,081,570us: [+4 T:0x00008003 S:0xbe3ffa64] OM -
Memory_contigAlloc> CMEM_getPhys(0x41458000) = 0x8c9ad

		000.

		@4,081,763us: [+1 T:0x00008003 S:0xbe3ffa0c] OM -
Memory__addContigBuf> Enter(virtAddr=0x41458000, size=

		32, physAddr=0x8c9ad000)

		@4,081,953us: [+1 T:0x00008003 S:0xbe3ffa0c] OM -
Memory__addContigBuf> creating new contigBuf object

		@4,082,119us: [+0 T:0x00008003 S:0xbe3ff9f4] OM -
Memory_alloc> Enter(0x10)

		@4,082,348us: [+0 T:0x00008003 S:0xbe3ff9f4] OM -
Memory_alloc> return (0x620b0)

		@4,082,535us: [+1 T:0x00008003 S:0xbe3ffa0c] OM -
Memory__addContigBuf> returning: cb->phys=0x8c9ad000,

		cb->size=32, cb->virt=0x41458000

		@4,082,729us: [+0 T:0x00008003 S:0xbe3ffa64] OM -
Memory_contigAlloc> return (0x41458000)

		MAC: 00:13:23:04:13:46 USN: 970041346

		@4,349,545us: [+0 T:0x00008003 S:0xbe3fea14]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62

		058, id=41216, params=0xbe3fedb8, status=0xbe3fed28

		@4,349,833us: [+5 T:0x00008003 S:0xbe3fe9e4] CV -
VISA_allocMsg> Allocating message for messageId=0x0002

		0008

		@4,350,045us: [+0 T:0x00008003 S:0xbe3fe9c4] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

		0020008, command=0x1

		@4,350,250us: [+0 T:0x00008003 S:0xbe3fe994] OC -
Comm_put> Enter(queue=0x2, msg=0x413dcc80)

		@4,350,512us: [+0 T:0x00008003 S:0xbe3fe994] OC -
Comm_put> return (0)

		@4,350,710us: [+0 T:0x00008003 S:0xbe3fe98c] OC -
Comm_get> Enter(queue=0x10001, msg=0xbe3fea24, timeout

		=-1)

		@4,351,302us: [+0 T:0x00008003 S:0xbe3fe98c] OC -
Comm_get> MSGQ_Get() status=0x8000, return (0)

		@4,351,574us: [+0 T:0x00008003 S:0xbe3fe914] OC -
Comm_put> Enter(queue=0x0, msg=0x413dbc80)

		@4,351,839us: [+0 T:0x00008003 S:0xbe3fe914] OC -
Comm_put> return (0)

		@4,352,129us: [+0 T:0x00008003 S:0xbe3fe90c] OC -
Comm_get> Enter(queue=0x10000, msg=0xbe3fe9a0, timeout

		=-1)

		@4,352,373us: [+0 T:0x00008003 S:0xbe3fe90c] OC -
Comm_get> MSGQ_Get() status=0x8000, return (0)

		[DSP] @5,647,854tk: [+5 T:0x8892e644 S:0x88932604] CN -
NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88

		2ab168, msg=0x88106c80); messageId=0x00020008

		[DSP] @5,647,953tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

		e=0x882ab168, id=41216, params=0x88106cb4,
status=0x88106cfc

		[DSP] @5,648,057tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

		198

		[DSP] @5,648,128tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

		andle=0x882ab198)

		[DSP] @5,648,202tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

		[DSP] @5,648,776tk: [+0 T:0x8892e644 S:0x88932504] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

		Bytes=1008)

		[DSP] @5,648,876tk: [+0 T:0x8892e644 S:0x88932504] OM -
Memory_cacheWbInv> return

		[DSP] @5,648,930tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

		98

		[DSP] @5,649,005tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

		(handle=0x882ab198)

		[DSP] @5,649,084tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

		n

		[DSP] @5,649,150tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

		=0x882ab168, retVal=0x0)

		[DSP] @5,649,235tk: [+5 T:0x8892e644 S:0x88932604] CN -
NODE> returned from call(algHandle=0x882ab168, m

		sg=0x88106c80); messageId=0x00020008

		[DSP] @5,650,934tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

		[DSP] @5,651,005tk: [+0 T:0x8880006c S:0x88804024] CR -
remote time = 0x0, trace buffer size = 4032

		@4,359,446us: [+0 T:0x00008003 S:0xbe3fe944] CE -
Engine_fwriteTrace> returning count [1651]

		@4,359,654us: [+0 T:0x00008003 S:0xbe3fe9c4] CV -
VISA_call Completed: messageId=0x00020008, command=0x1

		, return(status=0)

		@4,359,857us: [+5 T:0x00008003 S:0xbe3fe9d4] CV -
VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit

		h messageId=0x00020008

		@4,360,055us: [+0 T:0x00008003 S:0xbe3fea14]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620

		58, retVal=0x0)

		@4,360,248us: [+0 T:0x00008003 S:0xbe3fea14]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62

		058, id=41217, params=0xbe3fec28, status=0xbe3fed28

		@4,360,484us: [+5 T:0x00008003 S:0xbe3fe9e4] CV -
VISA_allocMsg> Allocating message for messageId=0x0002

		0009

		@4,360,680us: [+0 T:0x00008003 S:0xbe3fe9c4] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

		0020009, command=0x1

		@4,360,873us: [+0 T:0x00008003 S:0xbe3fe994] OC -
Comm_put> Enter(queue=0x2, msg=0x413dcc80)

		@4,361,117us: [+0 T:0x00008003 S:0xbe3fe994] OC -
Comm_put> return (0)

		@4,361,309us: [+0 T:0x00008003 S:0xbe3fe98c] OC -
Comm_get> Enter(queue=0x10001, msg=0xbe3fea24, timeout

		=-1)

		@4,366,972us: [+0 T:0x00008003 S:0xbe3fe98c] OC -
Comm_get> MSGQ_Get() status=0x8000, return (0)

		@4,367,246us: [+0 T:0x00008003 S:0xbe3fe914] OC -
Comm_put> Enter(queue=0x0, msg=0x413dbc80)

		@4,787,772us: [+0 T:0x00008003 S:0xbe3fe914] OC -
Comm_put> return (0)

		@4,788,103us: [+0 T:0x00008003 S:0xbe3fe90c] OC -
Comm_get> Enter(queue=0x10000, msg=0xbe3fe9a0, timeout

		=-1)

		@4,788,354us: [+0 T:0x00008003 S:0xbe3fe90c] OC -
Comm_get> MSGQ_Get() status=0x8000, return (0)

		[DSP] @5,672,464tk: [+5 T:0x8892e644 S:0x88932604] CN -
NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88

		2ab168, msg=0x88106c80); messageId=0x00020009

		[DSP] @5,672,568tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

		e=0x882ab168, id=41217, params=0x88106cb4,
status=0x88106db0

		[DSP] @5,672,674tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

		198

		[DSP] @5,672,747tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

		andle=0x882ab198)

		[DSP] @5,672,827tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

		[DSP] @5,685,069tk: [+0 T:0x8892e644 S:0x88932494] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

		Bytes=1008)

		[DSP] @5,685,193tk: [+0 T:0x8892e644 S:0x88932494] OM -
Memory_cacheWbInv> return

		[DSP] @5,685,259tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

		98

		[DSP] @5,685,335tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

		(handle=0x882ab198)

		[DSP] @5,685,417tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

		n

		[DSP] @5,685,488tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

		=0x882ab168, retVal=0x0)

		[DSP] @5,685,621tk: [+5 T:0x8892e644 S:0x88932604] CN -
NODE> returned from call(algHandle=0x882ab168, m

		sg=0x88106c80); messageId=0x00020009

		[DSP] @6,662,444tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

		[DSP] @6,662,522tk: [+0 T:0x8880006c S:0x88804024] CR -
remote time = 0x0, trace buffer size = 4032

		@4,795,428us: [+0 T:0x00008003 S:0xbe3fe944] CE -
Engine_fwriteTrace> returning count [1651]

		@4,795,640us: [+0 T:0x00008003 S:0xbe3fe9c4] CV -
VISA_call Completed: messageId=0x00020009, command=0x1

		, return(status=0)

		@4,795,851us: [+5 T:0x00008003 S:0xbe3fe9d4] CV -
VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit

		h messageId=0x00020009

		@4,796,075us: [+0 T:0x00008003 S:0xbe3fea14]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620

		58, retVal=0x0)

		@4,796,289us: [+0 T:0x00008003 S:0xbe3fea14]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handle=0x62

		058, id=41218, params=0xbe3fec28, status=0xbe3feac0

		@4,796,501us: [+5 T:0x00008003 S:0xbe3fe9e4] CV -
VISA_allocMsg> Allocating message for messageId=0x0002

		000a

		@4,796,692us: [+0 T:0x00008003 S:0xbe3fe9c4] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

		002000a, command=0x1

		@4,796,891us: [+0 T:0x00008003 S:0xbe3fe994] OC -
Comm_put> Enter(queue=0x2, msg=0x413dcc80)

		@4,797,345us: [+0 T:0x00008003 S:0xbe3fe994] OC -
Comm_put> return (0)

		@4,797,723us: [+0 T:0x00008003 S:0xbe3fe98c] OC -
Comm_get> Enter(queue=0x10001, msg=0xbe3fea24, timeout

		=-1)

		@4,798,173us: [+0 T:0x00008003 S:0xbe3fe98c] OC -
Comm_get> MSGQ_Get() status=0x8000, return (0)

		@4,798,433us: [+0 T:0x00008003 S:0xbe3fe914] OC -
Comm_put> Enter(queue=0x0, msg=0x413dbc80)

		@4,798,694us: [+0 T:0x00008003 S:0xbe3fe914] OC -
Comm_put> return (0)

		@4,799,015us: [+0 T:0x00008003 S:0xbe3fe90c] OC -
Comm_get> Enter(queue=0x10000, msg=0xbe3fe9a0, timeout

		=-1)

		@4,799,256us: [+0 T:0x00008003 S:0xbe3fe90c] OC -
Comm_get> MSGQ_Get() status=0x8000, return (0)

		[DSP] @6,684,637tk: [+5 T:0x8892e644 S:0x88932604] CN -
NODE> 0x882ab0b0(vca_stab#0) call(algHandle=0x88

		2ab168, msg=0x88106c80); messageId=0x0002000a

		[DSP] @6,684,743tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Enter (handl

		e=0x882ab168, id=41218, params=0x88106cb4,
status=0x88106db0

		[DSP] @6,684,853tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_enter(visa=0x882ab168): algHandle = 0x882ab

		198

		[DSP] @6,684,927tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(h

		andle=0x882ab198)

		[DSP] @6,685,011tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_activate> return

		[DSP] @6,685,660tk: [+0 T:0x8892e644 S:0x88932504] OM -
Memory_cacheWbInv> Enter(addr=0x88928eac, sizeIn

		Bytes=1008)

		[DSP] @6,685,789tk: [+0 T:0x8892e644 S:0x88932504] OM -
Memory_cacheWbInv> return

		[DSP] @6,685,848tk: [+5 T:0x8892e644 S:0x8893252c] CV -
VISA_exit(visa=0x882ab168): algHandle = 0x882ab1

		98

		[DSP] @6,685,921tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter

		(handle=0x882ab198)

		[DSP] @6,686,001tk: [+0 T:0x8892e644 S:0x8893250c]
ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> retur

		n

		[DSP] @6,686,067tk: [+0 T:0x8892e644 S:0x8893254c]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle

		=0x882ab168, retVal=0x0)

		[DSP] @6,686,152tk: [+5 T:0x8892e644 S:0x88932604] CN -
NODE> returned from call(algHandle=0x882ab168, m

		sg=0x88106c80); messageId=0x0002000a

		[DSP] @6,687,790tk: [+0 T:0x8880006c S:0x88804024] CR -
processRmsCmd(0x88105ca8, 4056): cmd = 5

		[DSP] @6,687,860tk: [+0 T:0x8880006c S:0x88804024] CR -
remote time = 0x0, trace buffer size = 4032

		@5,146,922us: [+0 T:0x00008003 S:0xbe3fe944] CE -
Engine_fwriteTrace> returning count [1651]

		@5,147,356us: [+0 T:0x00008003 S:0xbe3fe9c4] CV -
VISA_call Completed: messageId=0x0002000a, command=0x1

		, return(status=0)

		@5,147,728us: [+5 T:0x00008003 S:0xbe3fe9d4] CV -
VISA_freeMsg(0x62058, 0x413dcc80): Freeing message wit

		h messageId=0x0002000a

		@5,147,971us: [+0 T:0x00008003 S:0xbe3fea14]
ti.sdo.ce.video.VIDENC - VIDENC_control> Exit (handle=0x620

		58, retVal=0x0)

		@5,174,837us: [+0 T:0x00008003 S:0xbe3ff874]
ti.sdo.ce.video.VIDENC - VIDENC_process> Enter (handle=0x62

		058, inBufs=0xbe3ffac0, outBufs=0xbe3ffab0,
inArgs=0xbe3ff8fc, outArgs=0xbe3ffa10)

		@5,175,123us: [+5 T:0x00008003 S:0xbe3ff7fc] CV -
VISA_allocMsg> Allocating message for messageId=0x0002

		000b

		@5,175,328us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x404c

		9000, size=884736)

		@5,175,514us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x404c9000,

		 size=884736)

		@5,175,692us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> found in cb(Sc=0x404c9000,

		 Ec=0x405a1000, Ss=0x404c9000, Es=0x405a1000,
PSc=0x8cac7000)

		@5,175,934us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> returning physAddr=0x8cac7

		000

		@5,176,105us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> return (0x8cac7000)

		@5,176,280us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4145

		8000, size=32)

		@5,176,450us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x41458000,

		 size=32)

		@5,176,621us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> found in cb(Sc=0x41458000,

		 Ec=0x41458020, Ss=0x41458000, Es=0x41458020,
PSc=0x8c9ad000)

		@5,176,811us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> returning physAddr=0x8c9ad

		000

		@5,176,980us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> return (0x8c9ad000)

		@5,177,150us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x407c

		9000, size=884736)

		@5,177,369us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x407c9000,

		 size=884736)

		@5,177,545us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> found in cb(Sc=0x407c9000,

		 Ec=0x408a1000, Ss=0x407c9000, Es=0x408a1000,
PSc=0x8fc94000)

		@5,177,918us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> returning physAddr=0x8fc94

		000

		@5,178,105us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> return (0x8fc94000)

		@5,178,281us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4144

		b000, size=28)

		@5,178,460us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x4144b000,

		 size=28)

		@5,178,664us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> found in cb(Sc=0x4144b000,

		 Ec=0x4144b01c, Ss=0x4144b000, Es=0x4144b01c,
PSc=0x8c9ba000)

		@5,520,076us: [+1 T:0x00008003 S:0xbe3ff7cc] OM -
Memory__getPhysicalAddress> returning physAddr=0x8c9ba

		000

		@5,520,313us: [+0 T:0x00008003 S:0xbe3ff7cc] OM -
Memory_getBufferPhysicalAddress> return (0x8c9ba000)

		@5,520,501us: [+0 T:0x00008003 S:0xbe3ff80c] CV -
VISA_call(visa=0x62058, msg=0x413dcc80): messageId=0x0

		002000b, command=0x0

		@5,520,695us: [+0 T:0x00008003 S:0xbe3ff7dc] OC -
Comm_put> Enter(queue=0x2, msg=0x413dcc80)

		@5,520,929us: [+0 T:0x00008003 S:0xbe3ff7dc] OC -
Comm_put> return (0)

		@5,521,114us: [+0 T:0x00008003 S:0xbe3ff7d4] OC -
Comm_get> Enter(queue=0x10001, msg=0xbe3ff87c, timeout

		=-1)

		 

		 

		After this it locks up and never returns control to the
ARM after the VIDENC_process() call.

		 

		It looks like its locking up inside the Codec Engine
after returning from the DSP side process call.

		 

		Can anyone shed some light on whats going wrong?

		 

		 

		Regards,

		Etienne Eccles

		 

		VCA Technology

		 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100415/81a4485f/attachment-0001.html>

From cyril at ti.com  Thu Apr 15 11:43:10 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 15 Apr 2010 12:43:10 -0400
Subject: [PATCH v3 16/16] Davinci: tnetv107x evm board initial support
In-Reply-To: <4BC63A3C.7000402@mvista.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
	<1271270702-28307-9-git-send-email-cyril@ti.com>
	<1271270702-28307-10-git-send-email-cyril@ti.com>
	<1271270702-28307-11-git-send-email-cyril@ti.com>
	<1271270702-28307-12-git-send-email-cyril@ti.com>
	<1271270702-28307-13-git-send-email-cyril@ti.com>
	<1271270702-28307-14-git-send-email-cyril@ti.com>
	<1271270702-28307-15-git-send-email-cyril@ti.com>
	<1271270702-28307-16-git-send-email-cyril@ti.com>
	<1271270702-28307-17-git-send-email-cyril@ti.com>
	<4BC63A3C.7000402@mvista.com>
Message-ID: <4BC7421E.8050002@ti.com>

Hi Sergei,

[...]
>> +#include <linux/mtd/physmap.h>
> 
>    You shouldn't need physmap.h as you don't have the corresponding device.

Agreed.  Will remove.

>> +/* Base addresses for on-chip devices */
>> +#define TNETV107X_SDIO1_BASE			0x08088800
>> +#define TNETV107X_ASYNC_EMIF_CNTRL_BASE		0x08200000
>> +#define TNETV107X_ASYNC_EMIF_DATA_CE0_BASE	0x30000000
>> +#define TNETV107X_DDR_BASE			0x80000000
> 
>    I doubt that boarc code is a good place for base address macros. The 
> "declare-where-used" rule shouldn't be taken to an absurdistic extreme. :-)
> Althought you're following an existing example here... :-/
> 

I guess there is a bit of a disconnect here.  In the first place, I fail 
to see the reasoning behind having soc definitions scattered all over 
the place.  Could someone with a bit more understanding elaborate on the 
declare-where-used rule?

[...]
>> +static struct plat_serial8250_port tnetv107x_serial_pdata[] = {
>> +	{
>> +		.mapbase	= TNETV107X_UART0_BASE,
>> +		.irq		= IRQ_TNETV107X_UART0,
>> +		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
>> +					UPF_FIXED_TYPE | UPF_IOREMAP,
>> +		.type		= PORT_AR7,
>> +		.iotype		= UPIO_MEM32,
>> +		.regshift	= 2,
>> +	},
>> +	{
>> +		.mapbase	= TNETV107X_UART1_BASE,
>> +		.irq		= IRQ_TNETV107X_UART1,
>> +		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
>> +					UPF_FIXED_TYPE | UPF_IOREMAP,
>> +		.type		= PORT_AR7,
>> +		.iotype		= UPIO_MEM32,
>> +		.regshift	= 2,
>> +	},
>> +	{
>> +		.flags	= 0,
>> +	},
>> +};
>> +
>> +static struct platform_device tnetv107x_serial_device = {
>> +	.name			= "serial8250",
>> +	.id			= PLAT8250_DEV_PLATFORM,
>> +	.dev			= {
>> +		.platform_data	= tnetv107x_serial_pdata,
>> +	},
>> +};
> 
>    Why the SoC level UART device is registered at board level?

My understanding was that a board-designer could chose to not add a 
UART, or possibly (unlikely) add an external UART.  For this reason, I 
thought it made sense to keep this in the board code.  Would you rather 
leave the serial platform data in the board code, and move the platform 
device to devices-tnetv107x?

>> +static struct platform_device tnetv107x_evm_mmc_device = {
>> +	.name		= "davinci_mmc",
>> +	.id		= 1,
>> +	.dev		= {
>> +		.dma_mask		= &tnetv107x_evm_mmc_dma_mask,
>> +		.coherent_dma_mask	= DMA_BIT_MASK(32),
>> +		.platform_data		= &tnetv107x_evm_mmc_config,
>> +	},
>> +	.num_resources	= ARRAY_SIZE(tnetv107x_evm_mmc_resources),
>> +	.resource	= tnetv107x_evm_mmc_resources
>> +};
> 
>    Same question here...

On this particular board, SDIO1 is where the device is hooked up. 
Potentially, SDIO0 could be used as well, depending on the board design. 
  Further, the mechanism for sensing card-detect and read-write is 
board-specific.

>> +static const short tnetv107x_sdio1_pins[] = {
>> +	TNETV107X_SDIO1_CLK_1,		TNETV107X_SDIO1_CMD_1,
>> +	TNETV107X_SDIO1_DATA0_1,	TNETV107X_SDIO1_DATA1_1,
>> +	TNETV107X_SDIO1_DATA2_1,	TNETV107X_SDIO1_DATA3_1,
>> +	-1
>> +};
>> +
>> +const short tnetv107x_uart1_pins[] = {
>> +	TNETV107X_UART1_RD,		TNETV107X_UART1_TD,
>> +	-1
>> +};
>> +
>> +static const short tnetv107x_gpio_pins[] = {
>> +	TNETV107X_GPIO21, TNETV107X_GPIO24, TNETV107X_GPIO23,
>>   
> 
>    These pins do not really belong with GPIO anymore, they belong to the 
> MMC and whatever device, so should be in appropriate lists, shouldn't they?

Agreed. I will move these pins to tnetv107x_sdio1_pins[]

Regards
Cyril.

From sshtylyov at ru.mvista.com  Thu Apr 15 13:04:52 2010
From: sshtylyov at ru.mvista.com (Sergei Shtylyov)
Date: Thu, 15 Apr 2010 22:04:52 +0400
Subject: [PATCH 1/2] DaVinci: move AEMIF #define's to proper headers
Message-ID: <201004152204.52821.sshtylyov@ru.mvista.com>

Currently each DaVinci board file #define's its own version of the EMIFA base
addresses (all named DAVINCI_ASYNC_EMIF_*_BASE), which leads to duplication.
Move these #define's to the SoC specific headers, changing their prefixes from
'DAVINCI' to the 'DM355', 'DM644X', and 'DM646X' since all these base addresses
are SoC specific...

Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>

---
The patch is against the recent DaVinci tree.

 arch/arm/mach-davinci/board-dm355-evm.c     |   11 ++++-------
 arch/arm/mach-davinci/board-dm355-leopard.c |   11 ++++-------
 arch/arm/mach-davinci/board-dm644x-evm.c    |   18 ++++++------------
 arch/arm/mach-davinci/board-dm646x-evm.c    |   11 ++++-------
 arch/arm/mach-davinci/board-neuros-osd2.c   |   11 ++++-------
 arch/arm/mach-davinci/board-sffsdr.c        |   11 ++++-------
 arch/arm/mach-davinci/include/mach/dm355.h  |    3 +++
 arch/arm/mach-davinci/include/mach/dm644x.h |    6 ++++++
 arch/arm/mach-davinci/include/mach/dm646x.h |    4 +++-
 9 files changed, 38 insertions(+), 48 deletions(-)

Index: linux-davinci/arch/arm/mach-davinci/board-dm355-evm.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-dm355-evm.c
+++ linux-davinci/arch/arm/mach-davinci/board-dm355-evm.c
@@ -33,9 +33,6 @@
 #include <mach/mmc.h>
 #include <mach/usb.h>
 
-#define DAVINCI_ASYNC_EMIF_CONTROL_BASE		0x01e10000
-#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, maybe with a different block size, partitioning may
@@ -86,12 +83,12 @@ static struct davinci_nand_pdata davinci
 
 static struct resource davinci_nand_resources[] = {
 	{
-		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_32M - 1,
+		.start		= DM355_ASYNC_EMIF_DATA_CE0_BASE,
+		.end		= DM355_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,
+		.start		= DM355_ASYNC_EMIF_CONTROL_BASE,
+		.end		= DM355_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
 		.flags		= IORESOURCE_MEM,
 	},
 };
Index: linux-davinci/arch/arm/mach-davinci/board-dm355-leopard.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-dm355-leopard.c
+++ linux-davinci/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -30,9 +30,6 @@
 #include <mach/mmc.h>
 #include <mach/usb.h>
 
-#define DAVINCI_ASYNC_EMIF_CONTROL_BASE		0x01e10000
-#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, maybe with a different block size, partitioning may
@@ -82,12 +79,12 @@ static struct davinci_nand_pdata davinci
 
 static struct resource davinci_nand_resources[] = {
 	{
-		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_32M - 1,
+		.start		= DM355_ASYNC_EMIF_DATA_CE0_BASE,
+		.end		= DM355_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,
+		.start		= DM355_ASYNC_EMIF_CONTROL_BASE,
+		.end		= DM355_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
 		.flags		= IORESOURCE_MEM,
 	},
 };
Index: linux-davinci/arch/arm/mach-davinci/board-dm644x-evm.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-dm644x-evm.c
+++ linux-davinci/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -43,12 +43,6 @@
 
 #define DAVINCI_CFC_ATA_BASE		  0x01C66000
 
-#define DAVINCI_ASYNC_EMIF_CONTROL_BASE   0x01e00000
-#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE  0x02000000
-#define DAVINCI_ASYNC_EMIF_DATA_CE1_BASE  0x04000000
-#define DAVINCI_ASYNC_EMIF_DATA_CE2_BASE  0x06000000
-#define DAVINCI_ASYNC_EMIF_DATA_CE3_BASE  0x08000000
-
 #define LXT971_PHY_ID	(0x001378e2)
 #define LXT971_PHY_MASK	(0xfffffff0)
 
@@ -92,8 +86,8 @@ static struct physmap_flash_data davinci
 /* NOTE: CFI probe will correctly detect flash part as 32M, but EMIF
  * limits addresses to 16M, so using addresses past 16M will wrap */
 static struct resource davinci_evm_norflash_resource = {
-	.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
-	.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
+	.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
+	.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
 	.flags		= IORESOURCE_MEM,
 };
 
@@ -154,12 +148,12 @@ static struct davinci_nand_pdata davinci
 
 static struct resource davinci_evm_nandflash_resource[] = {
 	{
-		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
+		.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
+		.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
 		.flags		= IORESOURCE_MEM,
 	}, {
-		.start		= DAVINCI_ASYNC_EMIF_CONTROL_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
+		.start		= DM644X_ASYNC_EMIF_CONTROL_BASE,
+		.end		= DM644X_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
 		.flags		= IORESOURCE_MEM,
 	},
 };
Index: linux-davinci/arch/arm/mach-davinci/board-neuros-osd2.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-neuros-osd2.c
+++ linux-davinci/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -43,9 +43,6 @@
 
 #define DAVINCI_CFC_ATA_BASE		 0x01C66000
 
-#define DAVINCI_ASYNC_EMIF_CONTROL_BASE	 0x01e00000
-#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x02000000
-
 #define LXT971_PHY_ID			0x001378e2
 #define LXT971_PHY_MASK			0xfffffff0
 
@@ -98,12 +95,12 @@ static struct davinci_nand_pdata davinci
 
 static struct resource davinci_ntosd2_nandflash_resource[] = {
 	{
-		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
+		.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
+		.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
 		.flags		= IORESOURCE_MEM,
 	}, {
-		.start		= DAVINCI_ASYNC_EMIF_CONTROL_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
+		.start		= DM644X_ASYNC_EMIF_CONTROL_BASE,
+		.end		= DM644X_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
 		.flags		= IORESOURCE_MEM,
 	},
 };
Index: linux-davinci/arch/arm/mach-davinci/board-sffsdr.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-sffsdr.c
+++ linux-davinci/arch/arm/mach-davinci/board-sffsdr.c
@@ -45,9 +45,6 @@
 #define SFFSDR_PHY_MASK		(0x2)
 #define SFFSDR_MDIO_FREQUENCY	(2200000) /* PHY bus frequency */
 
-#define DAVINCI_ASYNC_EMIF_CONTROL_BASE   0x01e00000
-#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE  0x02000000
-
 static struct mtd_partition davinci_sffsdr_nandflash_partition[] = {
 	/* U-Boot Environment: Block 0
 	 * UBL:                Block 1
@@ -76,12 +73,12 @@ static struct flash_platform_data davinc
 
 static struct resource davinci_sffsdr_nandflash_resource[] = {
 	{
-		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
+		.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
+		.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
 		.flags		= IORESOURCE_MEM,
 	}, {
-		.start		= DAVINCI_ASYNC_EMIF_CONTROL_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
+		.start		= DM644X_ASYNC_EMIF_CONTROL_BASE,
+		.end		= DM644X_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
 		.flags		= IORESOURCE_MEM,
 	},
 };
Index: linux-davinci/arch/arm/mach-davinci/include/mach/dm355.h
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/include/mach/dm355.h
+++ linux-davinci/arch/arm/mach-davinci/include/mach/dm355.h
@@ -15,6 +15,9 @@
 #include <mach/asp.h>
 #include <media/davinci/vpfe_capture.h>
 
+#define DM355_ASYNC_EMIF_CONTROL_BASE	0x01e10000
+#define DM355_ASYNC_EMIF_DATA_CE0_BASE	0x02000000
+
 #define ASP1_TX_EVT_EN	1
 #define ASP1_RX_EVT_EN	2
 
Index: linux-davinci/arch/arm/mach-davinci/include/mach/dm644x.h
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/include/mach/dm644x.h
+++ linux-davinci/arch/arm/mach-davinci/include/mach/dm644x.h
@@ -34,6 +34,12 @@
 #define DM644X_EMAC_MDIO_OFFSET		(0x4000)
 #define DM644X_EMAC_CNTRL_RAM_SIZE	(0x2000)
 
+#define DM644X_ASYNC_EMIF_CONTROL_BASE	0x01e00000
+#define DM644X_ASYNC_EMIF_DATA_CE0_BASE 0x02000000
+#define DM644X_ASYNC_EMIF_DATA_CE1_BASE 0x04000000
+#define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x06000000
+#define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x08000000
+
 void __init dm644x_init(void);
 void __init dm644x_init_asp(struct snd_platform_data *pdata);
 void dm644x_set_vpfe_config(struct vpfe_config *cfg);
Index: linux-davinci/arch/arm/mach-davinci/include/mach/dm646x.h
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/include/mach/dm646x.h
+++ linux-davinci/arch/arm/mach-davinci/include/mach/dm646x.h
@@ -25,7 +25,9 @@
 #define DM646X_EMAC_MDIO_OFFSET		(0x4000)
 #define DM646X_EMAC_CNTRL_RAM_SIZE	(0x2000)
 
-#define DM646X_ATA_REG_BASE		(0x01C66000)
+#define DM646X_ATA_REG_BASE		0x01C66000
+#define DM646X_ASYNC_EMIF_CONTROL_BASE	0x20008000
+#define DM646X_ASYNC_EMIF_DATA_CE0_BASE	0x42000000
 
 void __init dm646x_init(void);
 void __init dm646x_init_ide(void);
Index: linux-davinci/arch/arm/mach-davinci/board-dm646x-evm.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-dm646x-evm.c
+++ linux-davinci/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -80,17 +80,14 @@ static struct davinci_nand_pdata davinci
 	.options		= 0,
 };
 
-#define DAVINCI_ASYNC_EMIF_CONTROL_BASE		0x20008000
-#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE	0x42000000
-
 static struct resource davinci_nand_resources[] = {
 	{
-		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_32M - 1,
+		.start		= DM646X_ASYNC_EMIF_DATA_CE0_BASE,
+		.end		= DM646X_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,
+		.start		= DM646X_ASYNC_EMIF_CONTROL_BASE,
+		.end		= DM646X_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
 		.flags		= IORESOURCE_MEM,
 	},
 };

From sshtylyov at ru.mvista.com  Thu Apr 15 13:06:27 2010
From: sshtylyov at ru.mvista.com (Sergei Shtylyov)
Date: Thu, 15 Apr 2010 22:06:27 +0400
Subject: [PATCH 2/2] DA830 EVM: use DA8XX_AEMIF_*_BASE #define's
Message-ID: <201004152206.27493.sshtylyov@ru.mvista.com>

The board file #define's its own version of EMIFA base addresses, while there
are DA8XX_AEMIF_*_BASE macros #define'd in <mach/da8xx.h>.  Start using them
instead.

Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>

---
The patch is against the recent DaVinci tree.

 arch/arm/mach-davinci/board-da830-evm.c |   11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

Index: linux-davinci/arch/arm/mach-davinci/board-da830-evm.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-da830-evm.c
+++ linux-davinci/arch/arm/mach-davinci/board-da830-evm.c
@@ -33,9 +33,6 @@
 #define DA830_EVM_PHY_MASK		0x0
 #define DA830_EVM_MDIO_FREQUENCY	2200000	/* PHY bus frequency */
 
-#define DA830_EMIF25_ASYNC_DATA_CE3_BASE	0x62000000
-#define DA830_EMIF25_CONTROL_BASE		0x68000000
-
 /*
  * USB1 VBUS is controlled by GPIO1[15], over-current is reported on GPIO2[4].
  */
@@ -375,13 +372,13 @@ static struct davinci_nand_pdata da830_e
 
 static struct resource da830_evm_nand_resources[] = {
 	[0] = {		/* First memory resource is NAND I/O window */
-		.start	= DA830_EMIF25_ASYNC_DATA_CE3_BASE,
-		.end	= DA830_EMIF25_ASYNC_DATA_CE3_BASE + PAGE_SIZE - 1,
+		.start	= DA8XX_AEMIF_CS3_BASE,
+		.end	= DA8XX_AEMIF_CS3_BASE + PAGE_SIZE - 1,
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {		/* Second memory resource is AEMIF control registers */
-		.start	= DA830_EMIF25_CONTROL_BASE,
-		.end	= DA830_EMIF25_CONTROL_BASE + SZ_32K - 1,
+		.start	= DA8XX_AEMIF_CTL_BASE,
+		.end	= DA8XX_AEMIF_CTL_BASE + SZ_32K - 1,
 		.flags	= IORESOURCE_MEM,
 	},
 };

From sshtylyov at mvista.com  Thu Apr 15 15:26:57 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Fri, 16 Apr 2010 00:26:57 +0400
Subject: [PATCH 1/2] DaVinci: move AEMIF #define's to proper headers
In-Reply-To: <201004152204.52821.sshtylyov@ru.mvista.com>
References: <201004152204.52821.sshtylyov@ru.mvista.com>
Message-ID: <4BC77691.8070600@mvista.com>

Hello, I wrote:

> Currently each DaVinci board file #define's its own version of the EMIFA base
> addresses (all named DAVINCI_ASYNC_EMIF_*_BASE), which leads to duplication.
> Move these #define's to the SoC specific headers, changing their prefixes from
> 'DAVINCI' to the 'DM355', 'DM644X', and 'DM646X' since all these base addresses
> are SoC specific...
>
> Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>
>
> ---
> The patch is against the recent DaVinci tree.
>
>  arch/arm/mach-davinci/board-dm355-evm.c     |   11 ++++-------
>  arch/arm/mach-davinci/board-dm355-leopard.c |   11 ++++-------
>  arch/arm/mach-davinci/board-dm644x-evm.c    |   18 ++++++------------
>  arch/arm/mach-davinci/board-dm646x-evm.c    |   11 ++++-------
>  arch/arm/mach-davinci/board-neuros-osd2.c   |   11 ++++-------
>  arch/arm/mach-davinci/board-sffsdr.c        |   11 ++++-------
>  arch/arm/mach-davinci/include/mach/dm355.h  |    3 +++
>  arch/arm/mach-davinci/include/mach/dm644x.h |    6 ++++++
>  arch/arm/mach-davinci/include/mach/dm646x.h |    4 +++-
>  9 files changed, 38 insertions(+), 48 deletions(-)
>   

   Oops, I missed board-dm365.c and <mach/dm365.h>... :-/
   I'll resubmit the patch tomorrow.

WBR, Sergei


From sshtylyov at mvista.com  Thu Apr 15 16:00:33 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Fri, 16 Apr 2010 01:00:33 +0400
Subject: [PATCH v3 16/16] Davinci: tnetv107x evm board initial support
In-Reply-To: <4BC7421E.8050002@ti.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
	<1271270702-28307-9-git-send-email-cyril@ti.com>
	<1271270702-28307-10-git-send-email-cyril@ti.com>
	<1271270702-28307-11-git-send-email-cyril@ti.com>
	<1271270702-28307-12-git-send-email-cyril@ti.com>
	<1271270702-28307-13-git-send-email-cyril@ti.com>
	<1271270702-28307-14-git-send-email-cyril@ti.com>
	<1271270702-28307-15-git-send-email-cyril@ti.com>
	<1271270702-28307-16-git-send-email-cyril@ti.com>
	<1271270702-28307-17-git-send-email-cyril@ti.com>
	<4BC63A3C.7000402@mvista.com> <4BC7421E.8050002@ti.com>
Message-ID: <4BC77E71.2030304@mvista.com>

Hello.

Cyril Chemparathy wrote:

>>> +#include <linux/mtd/physmap.h>
>>
>>    You shouldn't need physmap.h as you don't have the corresponding 
>> device.
>
> Agreed.  Will remove.
>
>>> +/* Base addresses for on-chip devices */
>>> +#define TNETV107X_SDIO1_BASE            0x08088800
>>> +#define TNETV107X_ASYNC_EMIF_CNTRL_BASE        0x08200000
>>> +#define TNETV107X_ASYNC_EMIF_DATA_CE0_BASE    0x30000000
>>> +#define TNETV107X_DDR_BASE            0x80000000
>>
>>    I doubt that boarc code is a good place for base address macros. 
>> The "declare-where-used" rule shouldn't be taken to an absurdistic 
>> extreme. :-)
>> Althought you're following an existing example here... :-/

   And I've just submitted patch to move the AEMIF #define's from the 
board files ot the respective headers (have missed one board filethough...

> I guess there is a bit of a disconnect here.  In the first place, I 
> fail to see the reasoning behind having soc definitions scattered all 
> over the place.  Could someone with a bit more understanding elaborate 
> on the declare-where-used rule?

   I'll leave that to Kevin. :-)

> [...]
>>> +static struct plat_serial8250_port tnetv107x_serial_pdata[] = {
>>> +    {
>>> +        .mapbase    = TNETV107X_UART0_BASE,
>>> +        .irq        = IRQ_TNETV107X_UART0,
>>> +        .flags        = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
>>> +                    UPF_FIXED_TYPE | UPF_IOREMAP,
>>> +        .type        = PORT_AR7,
>>> +        .iotype        = UPIO_MEM32,
>>> +        .regshift    = 2,
>>> +    },
>>> +    {
>>> +        .mapbase    = TNETV107X_UART1_BASE,
>>> +        .irq        = IRQ_TNETV107X_UART1,
>>> +        .flags        = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
>>> +                    UPF_FIXED_TYPE | UPF_IOREMAP,
>>> +        .type        = PORT_AR7,
>>> +        .iotype        = UPIO_MEM32,
>>> +        .regshift    = 2,
>>> +    },
>>> +    {
>>> +        .flags    = 0,
>>> +    },
>>> +};
>>> +
>>> +static struct platform_device tnetv107x_serial_device = {
>>> +    .name            = "serial8250",
>>> +    .id            = PLAT8250_DEV_PLATFORM,
>>> +    .dev            = {
>>> +        .platform_data    = tnetv107x_serial_pdata,
>>> +    },
>>> +};
>>
>>    Why the SoC level UART device is registered at board level?
>
> My understanding was that a board-designer could chose to not add a 
> UART, or possibly (unlikely) add an external UART.  For this reason, I 
> thought it made sense to keep this in the board code.

   And you chose to not UART2 as I can see?

>   Would you rather leave the serial platform data in the board code, 
> and move the platform device to devices-tnetv107x?

  Worth doing so...

>>> +    .name        = "davinci_mmc",
>>> +    .id        = 1,
>>> +    .dev        = {
>>> +        .dma_mask        = &tnetv107x_evm_mmc_dma_mask,
>>> +        .coherent_dma_mask    = DMA_BIT_MASK(32),
>>> +        .platform_data        = &tnetv107x_evm_mmc_config,
>>> +    },
>>> +    .num_resources    = ARRAY_SIZE(tnetv107x_evm_mmc_resources),
>>> +    .resource    = tnetv107x_evm_mmc_resources
>>> +};
>>
>>    Same question here...
> +static struct platform_device tnetv107x_evm_mmc_device = {
>
> On this particular board, SDIO1 is where the device is hooked up. 
> Potentially, SDIO0 could be used as well, depending on the board design. 

   These should be in the SoC file, with a function to 
initialize/register them taking an interface number, like 
davinci_setup_mmc() in devices.c...

> Further, the mechanism for sensing card-detect and read-write is 
> board-specific.

   That is not an excuse. Normally, we have platfrom device in the SoC 
file and platform data in the board file (or the variation af thereof, 
where some platfrom data details get passed from the board code).

WBR, Sergei


From cyril at ti.com  Thu Apr 15 16:19:17 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 15 Apr 2010 17:19:17 -0400
Subject: [PATCH v3 16/16] Davinci: tnetv107x evm board initial support
In-Reply-To: <4BC77E71.2030304@mvista.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
	<1271270702-28307-9-git-send-email-cyril@ti.com>
	<1271270702-28307-10-git-send-email-cyril@ti.com>
	<1271270702-28307-11-git-send-email-cyril@ti.com>
	<1271270702-28307-12-git-send-email-cyril@ti.com>
	<1271270702-28307-13-git-send-email-cyril@ti.com>
	<1271270702-28307-14-git-send-email-cyril@ti.com>
	<1271270702-28307-15-git-send-email-cyril@ti.com>
	<1271270702-28307-16-git-send-email-cyril@ti.com>
	<1271270702-28307-17-git-send-email-cyril@ti.com>
	<4BC63A3C.7000402@mvista.com> <4BC7421E.8050002@ti.com>
	<4BC77E71.2030304@mvista.com>
Message-ID: <4BC782D5.1020503@ti.com>

Hi Sergei,

[...]
>>>> +static struct plat_serial8250_port tnetv107x_serial_pdata[] = {
>>>> +    {
>>>> +        .mapbase    = TNETV107X_UART0_BASE,
>>>> +        .irq        = IRQ_TNETV107X_UART0,
>>>> +        .flags        = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
>>>> +                    UPF_FIXED_TYPE | UPF_IOREMAP,
>>>> +        .type        = PORT_AR7,
>>>> +        .iotype        = UPIO_MEM32,
>>>> +        .regshift    = 2,
>>>> +    },
>>>> +    {
>>>> +        .mapbase    = TNETV107X_UART1_BASE,
>>>> +        .irq        = IRQ_TNETV107X_UART1,
>>>> +        .flags        = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
>>>> +                    UPF_FIXED_TYPE | UPF_IOREMAP,
>>>> +        .type        = PORT_AR7,
>>>> +        .iotype        = UPIO_MEM32,
>>>> +        .regshift    = 2,
>>>> +    },
>>>> +    {
>>>> +        .flags    = 0,
>>>> +    },
>>>> +};
>>>> +
>>>> +static struct platform_device tnetv107x_serial_device = {
>>>> +    .name            = "serial8250",
>>>> +    .id            = PLAT8250_DEV_PLATFORM,
>>>> +    .dev            = {
>>>> +        .platform_data    = tnetv107x_serial_pdata,
>>>> +    },
>>>> +};
>>>    Why the SoC level UART device is registered at board level?
>> My understanding was that a board-designer could chose to not add a 
>> UART, or possibly (unlikely) add an external UART.  For this reason, I 
>> thought it made sense to keep this in the board code.
> 
>    And you chose to not UART2 as I can see?

Correct.

>>   Would you rather leave the serial platform data in the board code, 
>> and move the platform device to devices-tnetv107x?
> 
>   Worth doing so...

Will do, thanks.

>> On this particular board, SDIO1 is where the device is hooked up. 
>> Potentially, SDIO0 could be used as well, depending on the board design. 
> 
>    These should be in the SoC file, with a function to 
> initialize/register them taking an interface number, like 
> davinci_setup_mmc() in devices.c...
> 
>> Further, the mechanism for sensing card-detect and read-write is 
>> board-specific.
> 
>    That is not an excuse. Normally, we have platfrom device in the SoC 
> file and platform data in the board file (or the variation af thereof, 
> where some platfrom data details get passed from the board code).

Ok.  I will have the platform data defined in the board code, and passed 
in to the equivalent of davinci_setup_mmc() in the soc code.  Would that 
be proper?


Regards
Cyril.

From pratik.joshi at einfochips.com  Fri Apr 16 02:30:03 2010
From: pratik.joshi at einfochips.com (Pratik Joshi)
Date: Fri, 16 Apr 2010 13:00:03 +0530
Subject: USB mass storage not detected in 2.6.32 kernel
In-Reply-To: <x2wb002f1321004090613j65f85bccuc0104dd23fdc3996@mail.gmail.com>
References: <8278439946330628762@unknownmsgid>
	<x2wb002f1321004090613j65f85bccuc0104dd23fdc3996@mail.gmail.com>
Message-ID: <000d01cadd36$a40b0ac0$ec212040$@joshi@einfochips.com>

Hi,

I have attached kernel configuration file for reference. Can anyone help me
out why I am not able to enable USB in kernel 2.6.32.11?

What am I missing here?

Regards,
Pratik Joshi
Embedded Engineer
eInfochips Ltd, Ahmedabad, India
+91-079-26563705 - ext - 303
www.einfochips.com

-----Original Message-----
From: Viral Sachde [mailto:viral at allaboutif.com] 
Sent: Friday, April 09, 2010 6:44 PM
To: Pratik Joshi
Cc: davinci-linux-open-source at linux.davincidsp.com
Subject: Re: USB mass storage not detected in 2.6.32 kernel

On Fri, Apr 9, 2010 at 6:30 PM, Pratik Joshi
<pratik.joshi at einfochips.com> wrote:
> Hi All,
> I am migrating from 2.6.10 kernel to 2.6.32 kernel for DM6446 platform. I
> took a kernel from www.kernel.org version 2.6.32.11.
> Problem statement:
> I have configured USB in new kernel for mass storage and I have also
enabled
> scsi module. To my knowledge I have done all configuration in kernel to
> enabled USB mass storage. But somehow it seems USB driver is not included
in
> the kernel image. On issuing "lsusb" command on the prompt yields nothing.
> Can anyone throw a light on issue that I am facing?
> Regards,
> Pratik Joshi

I assume your file system is mounting procfs & usbfs. If not mount them.
Can you check /proc/bus/usb/ directory and file "devices" inside it.
Send devices file here to start with.

Regards, Viral



Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com

-- 
_____________________________________________________________________
Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution, copying, or other use of
this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
replying to this message and please delete it from your computer. Any
views expressed in this message are those of the individual sender
unless otherwise stated.Company has taken enough precautions to prevent
the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email.
_____________________________________________________________________
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config
Type: application/octet-stream
Size: 42885 bytes
Desc: not available
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100416/a5ac6aeb/attachment-0001.obj>

From ipcevm at gmail.com  Fri Apr 16 04:28:18 2010
From: ipcevm at gmail.com (shaofeng zhang)
Date: Fri, 16 Apr 2010 17:28:18 +0800
Subject: How to use JRTPLIB in the Davinci encode project?
Message-ID: <o2tf1c20a311004160228oe9b5a59g9a2cad34289016a1@mail.gmail.com>

Hi,all
I want to use the JRTPLIB in my encode project base on DM6446 platform, but
I donot know how to use the c++ library in the C project,
could anyone give me some information about how to use the cpp file in the c
project?
how to use the jrtplib in the encode project? Now I have the *.h files and
the *.so files, but these files are the cpp project, how can I use them
in the C project like the encode project in the TI demos?
Thank you very much~~

-- 
Best Regards!                   zhangshaofeng
       @Xi'an JiaoTong University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100416/aaa47ec5/attachment.html>

From lamiaposta71 at gmail.com  Fri Apr 16 05:25:47 2010
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Fri, 16 Apr 2010 12:25:47 +0200
Subject: dm365 - davincifb with rgb lcd
Message-ID: <h2gade1bdc1004160325o4859dbdcqee5692374906b6d4@mail.gmail.com>

We have done some modifications for output=lcd and format=rgb.
We need some feedback if we are going to the right direction.
In the mailing list I haven't find any messages about this topic.

The file davincifb.h contained wrong registers, here you are the patch:

diff --git a/include/video/davincifb.h b/include/video/davincifb.h
index 96b5c20..33a2b70 100644
--- a/include/video/davincifb.h
+++ b/include/video/davincifb.h
@@ -16,10 +16,16 @@
 #include <mach/io.h>

 /* Base registers */
+#if 0
 #define        VPBE_REG_BASE                           0x01c72780
 #define        VENC_REG_BASE                           0x01c72400
 #define        OSD_REG_BASE                            0x01c72600
 #define OSD_REG_SIZE                           0x00000180
+#endif
+
+#define VENC_REG_BASE                           0x01C71E00
+#define OSD_REG_BASE                            0x01C71C00
+#define OSD_REG_SIZE                           0x00000100

 /* VPBE Global Registers */
 #define        VPBE_PID                                (VPBE_BASE + 0x0)

Then we have tried to add rgb support to davincifb.c.
The kernel starts if you use
video=davincifb:output=lcd:format=rgb:vid0=240x320 at 0,0:vid1=320x240 at 0
,0:osd0=240x320 at 0,0
osd0_default_var contains the setting for our lcd, but we should pass these
parameters from board file, but we don't know how to do it.

diff --git a/drivers/video/davincifb.c b/drivers/video/davincifb.c
index 1344be7..31dc147 100644
--- a/drivers/video/davincifb.c
+++ b/drivers/video/davincifb.c
@@ -171,14 +171,15 @@ static struct fb_var_screeninfo osd0_default_var = {
        .width = -1,
        .accel_flags = 0,
        .pixclock = LCD_PANEL_CLOCK,    /* picoseconds */
-       .left_margin = 40,      /* pixclocks */
-       .right_margin = 4,      /* pixclocks */
-       .upper_margin = 8,      /* line clocks */
-       .lower_margin = 2,      /* line clocks */
-       .hsync_len = 4,         /* pixclocks */
-       .vsync_len = 2,         /* line clocks */
+       .left_margin = 18,      /* pixclocks */
+       .right_margin = 12,     /* pixclocks */
+       .upper_margin = 20,     /* line clocks */
+       .lower_margin = 8,      /* line clocks */
+       .hsync_len = 1,         /* pixclocks */
+       .vsync_len = 1,         /* line clocks */
        .sync = 0,
-       .vmode = FB_VMODE_INTERLACED,
+/*     .vmode = FB_VMODE_INTERLACED,*/
+       .vmode = FB_VMODE_NONINTERLACED,
 };

 /* Using the full screen for OSD1 by default */
@@ -1394,6 +1395,52 @@ static void davincifb_pal_component_config(int on)
        }
 }

+static void davincifb_lcd_rgb_config(int on)
+{
+       printk("%s %d\n", __func__, __LINE__);
+        if (on) {
+                /* Reset video encoder module */
+       printk("%s %d\n", __func__, __LINE__);
+       printk("writing %X to register having address:%X\n", 0x25D3,
VENC_VMOD);
+                dispc_reg_out(VENC_VMOD, 0x25D3);
+
+                /* set hsync pulse width */
+                dispc_reg_out(VENC_HSPLS, dm->osd1->info.var.hsync_len);
+
+                /* set vsync pulse width */
+                dispc_reg_out(VENC_VSPLS, dm->osd1->info.var.vsync_len);
+
+                /* set horizontal interval  */
+                dispc_reg_out(VENC_HINT, dm->osd1->info.var.left_margin +
dm->osd1->info.var.right_margin + dm->osd1-
+
+                /* set horizontal data valid start position  */
+                dispc_reg_out(VENC_HSTART, dm->osd1->info.var.left_margin);
+
+                /* set Horizontal data valid range  */
+                dispc_reg_out(VENC_HVALID, dm->osd1->info.var.width);
+
+                /* set Vertical interval  */
+                dispc_reg_out(VENC_VINT, dm->osd1->info.var.upper_margin +
dm->osd1->info.var.lower_margin + dm->osd1
+
+                /* set Vertical data valid start position */
+                dispc_reg_out(VENC_HVALID,
dm->osd1->info.var.upper_margin);
+
+                /* set Horizontal data valid range  */
+                dispc_reg_out(VENC_VVALID, dm->osd1->info.var.height);
+#if 0
+                /* set Horizontal sync delay */
+                dispc_reg_out(VENC_HVALID, dm->osd1->info.??);
+
+                /* set vertical sync delay */
+                dispc_reg_out(VENC_HVALID, dm->osd1->info.var.??);
+#endif
+        } else {
+                /* Reset video encoder module */
+                dispc_reg_out(VENC_VMOD, 0);
+        }
+}
+
+
 static inline void fix_default_var(struct dm_win_info *w,
                                   u32 xres, u32 yres, u32 xpos, u32 ypos,
                                   int n_buf)
@@ -1486,6 +1533,8 @@ static int davincifb_probe(struct platform_device
*pdev)
                dm->output_device_config = davincifb_pal_svideo_config;
        else if ((dmparams.output == PAL) && (dmparams.format == COMPONENT))
                dm->output_device_config = davincifb_pal_component_config;
+       else if ((dmparams.output == LCD) /*&& (dmparams.format == RGB)*/)
+               dm->output_device_config = davincifb_lcd_rgb_config;
        /* Add support for other displays here */
        else {
                printk(KERN_WARNING "Unsupported output device!\n");
@@ -1714,7 +1763,7 @@ int __init davincifb_init(void)

        /* Register the driver with LDM */
        if (platform_driver_register(&davincifb_driver)) {
-               pr_debug("failed to register omapfb driver\n");
+               pr_debug("failed to register davincifb driver\n");
                return -ENODEV;
        }



Thank for any help,
Raffaele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100416/ab69e523/attachment.html>

From idriss.ghodhbane at gmail.com  Fri Apr 16 08:25:10 2010
From: idriss.ghodhbane at gmail.com (Idriss Ghodhbane)
Date: Fri, 16 Apr 2010 15:25:10 +0200
Subject: AIC33+DM355+gstreamer
Message-ID: <x2s90d17c5d1004160625i2c5a195bt97ed8c5246afc43c@mail.gmail.com>

Hello Everybody,

The project I'm working on consists in streaming audio and video between two
DM355 Evm using Gstreamer.
After many searches, I remarked that I require offloading all the audio
processing in the gstreamer pipelines (Alsasrc, alsasink, osssrc...) to the
DSP side and not to the ARM side because I have had a critical CPU overload.
So, I need to configure the DM355 EVM's *AIC33* codec to be supported with
my sound drivers.
I am wondering how to do this and what sound driver (ALSA or OSS) I have to
activate.
Thanks in advance.

Regards,
-- 
IDRISS GHODHBANE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100416/ec0faff8/attachment.html>

From sshtylyov at ru.mvista.com  Fri Apr 16 12:29:11 2010
From: sshtylyov at ru.mvista.com (Sergei Shtylyov)
Date: Fri, 16 Apr 2010 21:29:11 +0400
Subject: [PATCH v2 1/2] DaVinci: move AEMIF #define's to the proper headers
Message-ID: <201004162129.11843.sshtylyov@ru.mvista.com>

Currently each DaVinci board file #define's its own version of the EMIFA base
addresses (all named DAVINCI_ASYNC_EMIF_*_BASE), which leads to duplication.
Move these #define's to the SoC specific headers, changing their prefixes from
'DAVINCI' to the 'DM355', 'DM644X', and 'DM646X' since all these base addresses
are SoC specific...

And while at it, rename DM646X_ASYNC_EMIF_DATA_CE0_BASE to
DM646X_ASYNC_EMIF_CS2_SPACE_BASE in order to match the DM646x datasheet.

Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>

---
The patch is against the recent DaVinci tree.

Changes since the previous version:
- included changes to board-dm365-evm.c and <mach/dm365.h>;
- renamed DM646X_ASYNC_EMIF_DATA_CE0_BASE to DM646X_ASYNC_EMIF_CS2_SPACE_BASE;
- re-sorted the patch.

 arch/arm/mach-davinci/board-dm355-evm.c     |   11 ++++-------
 arch/arm/mach-davinci/board-dm355-leopard.c |   11 ++++-------
 arch/arm/mach-davinci/board-dm365-evm.c     |    5 -----
 arch/arm/mach-davinci/board-dm644x-evm.c    |   18 ++++++------------
 arch/arm/mach-davinci/board-dm646x-evm.c    |   11 ++++-------
 arch/arm/mach-davinci/board-neuros-osd2.c   |   11 ++++-------
 arch/arm/mach-davinci/board-sffsdr.c        |   11 ++++-------
 arch/arm/mach-davinci/include/mach/dm355.h  |    3 +++
 arch/arm/mach-davinci/include/mach/dm365.h  |    4 ++++
 arch/arm/mach-davinci/include/mach/dm644x.h |    6 ++++++
 arch/arm/mach-davinci/include/mach/dm646x.h |    3 +++
 11 files changed, 42 insertions(+), 52 deletions(-)

Index: linux-davinci/arch/arm/mach-davinci/board-dm355-evm.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-dm355-evm.c
+++ linux-davinci/arch/arm/mach-davinci/board-dm355-evm.c
@@ -33,9 +33,6 @@
 #include <mach/mmc.h>
 #include <mach/usb.h>
 
-#define DAVINCI_ASYNC_EMIF_CONTROL_BASE		0x01e10000
-#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, maybe with a different block size, partitioning may
@@ -86,12 +83,12 @@ static struct davinci_nand_pdata davinci
 
 static struct resource davinci_nand_resources[] = {
 	{
-		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_32M - 1,
+		.start		= DM355_ASYNC_EMIF_DATA_CE0_BASE,
+		.end		= DM355_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,
+		.start		= DM355_ASYNC_EMIF_CONTROL_BASE,
+		.end		= DM355_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
 		.flags		= IORESOURCE_MEM,
 	},
 };
Index: linux-davinci/arch/arm/mach-davinci/board-dm355-leopard.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-dm355-leopard.c
+++ linux-davinci/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -30,9 +30,6 @@
 #include <mach/mmc.h>
 #include <mach/usb.h>
 
-#define DAVINCI_ASYNC_EMIF_CONTROL_BASE		0x01e10000
-#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, maybe with a different block size, partitioning may
@@ -82,12 +79,12 @@ static struct davinci_nand_pdata davinci
 
 static struct resource davinci_nand_resources[] = {
 	{
-		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_32M - 1,
+		.start		= DM355_ASYNC_EMIF_DATA_CE0_BASE,
+		.end		= DM355_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,
+		.start		= DM355_ASYNC_EMIF_CONTROL_BASE,
+		.end		= DM355_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
 		.flags		= IORESOURCE_MEM,
 	},
 };
Index: linux-davinci/arch/arm/mach-davinci/board-dm365-evm.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-dm365-evm.c
+++ linux-davinci/arch/arm/mach-davinci/board-dm365-evm.c
@@ -53,11 +53,6 @@ static inline int have_tvp7002(void)
 	return 0;
 }
 
-
-#define DM365_ASYNC_EMIF_CONTROL_BASE	0x01d10000
-#define DM365_ASYNC_EMIF_DATA_CE0_BASE	0x02000000
-#define DM365_ASYNC_EMIF_DATA_CE1_BASE	0x04000000
-
 #define DM365_EVM_PHY_MASK		(0x2)
 #define DM365_EVM_MDIO_FREQUENCY	(2200000) /* PHY bus frequency */
 
Index: linux-davinci/arch/arm/mach-davinci/board-dm644x-evm.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-dm644x-evm.c
+++ linux-davinci/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -43,12 +43,6 @@
 
 #define DAVINCI_CFC_ATA_BASE		  0x01C66000
 
-#define DAVINCI_ASYNC_EMIF_CONTROL_BASE   0x01e00000
-#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE  0x02000000
-#define DAVINCI_ASYNC_EMIF_DATA_CE1_BASE  0x04000000
-#define DAVINCI_ASYNC_EMIF_DATA_CE2_BASE  0x06000000
-#define DAVINCI_ASYNC_EMIF_DATA_CE3_BASE  0x08000000
-
 #define LXT971_PHY_ID	(0x001378e2)
 #define LXT971_PHY_MASK	(0xfffffff0)
 
@@ -92,8 +86,8 @@ static struct physmap_flash_data davinci
 /* NOTE: CFI probe will correctly detect flash part as 32M, but EMIF
  * limits addresses to 16M, so using addresses past 16M will wrap */
 static struct resource davinci_evm_norflash_resource = {
-	.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
-	.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
+	.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
+	.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
 	.flags		= IORESOURCE_MEM,
 };
 
@@ -154,12 +148,12 @@ static struct davinci_nand_pdata davinci
 
 static struct resource davinci_evm_nandflash_resource[] = {
 	{
-		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
+		.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
+		.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
 		.flags		= IORESOURCE_MEM,
 	}, {
-		.start		= DAVINCI_ASYNC_EMIF_CONTROL_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
+		.start		= DM644X_ASYNC_EMIF_CONTROL_BASE,
+		.end		= DM644X_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
 		.flags		= IORESOURCE_MEM,
 	},
 };
Index: linux-davinci/arch/arm/mach-davinci/board-dm646x-evm.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-dm646x-evm.c
+++ linux-davinci/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -80,17 +80,14 @@ static struct davinci_nand_pdata davinci
 	.options		= 0,
 };
 
-#define DAVINCI_ASYNC_EMIF_CONTROL_BASE		0x20008000
-#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE	0x42000000
-
 static struct resource davinci_nand_resources[] = {
 	{
-		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_32M - 1,
+		.start		= DM646X_ASYNC_EMIF_CS2_SPACE_BASE,
+		.end		= DM646X_ASYNC_EMIF_CS2_SPACE_BASE + SZ_32M - 1,
 		.flags		= IORESOURCE_MEM,
 	}, {
-		.start		= DAVINCI_ASYNC_EMIF_CONTROL_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
+		.start		= DM646X_ASYNC_EMIF_CONTROL_BASE,
+		.end		= DM646X_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
 		.flags		= IORESOURCE_MEM,
 	},
 };
Index: linux-davinci/arch/arm/mach-davinci/board-neuros-osd2.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-neuros-osd2.c
+++ linux-davinci/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -43,9 +43,6 @@
 
 #define DAVINCI_CFC_ATA_BASE		 0x01C66000
 
-#define DAVINCI_ASYNC_EMIF_CONTROL_BASE	 0x01e00000
-#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x02000000
-
 #define LXT971_PHY_ID			0x001378e2
 #define LXT971_PHY_MASK			0xfffffff0
 
@@ -98,12 +95,12 @@ static struct davinci_nand_pdata davinci
 
 static struct resource davinci_ntosd2_nandflash_resource[] = {
 	{
-		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
+		.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
+		.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
 		.flags		= IORESOURCE_MEM,
 	}, {
-		.start		= DAVINCI_ASYNC_EMIF_CONTROL_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
+		.start		= DM644X_ASYNC_EMIF_CONTROL_BASE,
+		.end		= DM644X_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
 		.flags		= IORESOURCE_MEM,
 	},
 };
Index: linux-davinci/arch/arm/mach-davinci/board-sffsdr.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-sffsdr.c
+++ linux-davinci/arch/arm/mach-davinci/board-sffsdr.c
@@ -45,9 +45,6 @@
 #define SFFSDR_PHY_MASK		(0x2)
 #define SFFSDR_MDIO_FREQUENCY	(2200000) /* PHY bus frequency */
 
-#define DAVINCI_ASYNC_EMIF_CONTROL_BASE   0x01e00000
-#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE  0x02000000
-
 static struct mtd_partition davinci_sffsdr_nandflash_partition[] = {
 	/* U-Boot Environment: Block 0
 	 * UBL:                Block 1
@@ -76,12 +73,12 @@ static struct flash_platform_data davinc
 
 static struct resource davinci_sffsdr_nandflash_resource[] = {
 	{
-		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
+		.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
+		.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
 		.flags		= IORESOURCE_MEM,
 	}, {
-		.start		= DAVINCI_ASYNC_EMIF_CONTROL_BASE,
-		.end		= DAVINCI_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
+		.start		= DM644X_ASYNC_EMIF_CONTROL_BASE,
+		.end		= DM644X_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
 		.flags		= IORESOURCE_MEM,
 	},
 };
Index: linux-davinci/arch/arm/mach-davinci/include/mach/dm355.h
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/include/mach/dm355.h
+++ linux-davinci/arch/arm/mach-davinci/include/mach/dm355.h
@@ -15,6 +15,9 @@
 #include <mach/asp.h>
 #include <media/davinci/vpfe_capture.h>
 
+#define DM355_ASYNC_EMIF_CONTROL_BASE	0x01E10000
+#define DM355_ASYNC_EMIF_DATA_CE0_BASE	0x02000000
+
 #define ASP1_TX_EVT_EN	1
 #define ASP1_RX_EVT_EN	2
 
Index: linux-davinci/arch/arm/mach-davinci/include/mach/dm365.h
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/include/mach/dm365.h
+++ linux-davinci/arch/arm/mach-davinci/include/mach/dm365.h
@@ -36,6 +36,10 @@
 #define DAVINCI_DMA_VC_TX		2
 #define DAVINCI_DMA_VC_RX		3
 
+#define DM365_ASYNC_EMIF_CONTROL_BASE	0x01D10000
+#define DM365_ASYNC_EMIF_DATA_CE0_BASE	0x02000000
+#define DM365_ASYNC_EMIF_DATA_CE1_BASE	0x04000000
+
 void __init dm365_init(void);
 void __init dm365_init_asp(struct snd_platform_data *pdata);
 void __init dm365_init_vc(struct snd_platform_data *pdata);
Index: linux-davinci/arch/arm/mach-davinci/include/mach/dm644x.h
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/include/mach/dm644x.h
+++ linux-davinci/arch/arm/mach-davinci/include/mach/dm644x.h
@@ -34,6 +34,12 @@
 #define DM644X_EMAC_MDIO_OFFSET		(0x4000)
 #define DM644X_EMAC_CNTRL_RAM_SIZE	(0x2000)
 
+#define DM644X_ASYNC_EMIF_CONTROL_BASE	0x01E00000
+#define DM644X_ASYNC_EMIF_DATA_CE0_BASE 0x02000000
+#define DM644X_ASYNC_EMIF_DATA_CE1_BASE 0x04000000
+#define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x06000000
+#define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x08000000
+
 void __init dm644x_init(void);
 void __init dm644x_init_asp(struct snd_platform_data *pdata);
 void dm644x_set_vpfe_config(struct vpfe_config *cfg);
Index: linux-davinci/arch/arm/mach-davinci/include/mach/dm646x.h
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/include/mach/dm646x.h
+++ linux-davinci/arch/arm/mach-davinci/include/mach/dm646x.h
@@ -27,6 +27,9 @@
 
 #define DM646X_ATA_REG_BASE		(0x01C66000)
 
+#define DM646X_ASYNC_EMIF_CONTROL_BASE	0x20008000
+#define DM646X_ASYNC_EMIF_CS2_SPACE_BASE 0x42000000
+
 void __init dm646x_init(void);
 void __init dm646x_init_ide(void);
 void __init dm646x_init_mcasp0(struct snd_platform_data *pdata);

From sshtylyov at ru.mvista.com  Fri Apr 16 12:29:20 2010
From: sshtylyov at ru.mvista.com (Sergei Shtylyov)
Date: Fri, 16 Apr 2010 21:29:20 +0400
Subject: [PATCH 2/2] DA830 EVM: use DA8XX_AEMIF_*_BASE #define's
Message-ID: <201004162129.20112.sshtylyov@ru.mvista.com>

The board file #define's its own version of EMIFA base addresses, while there
are DA8XX_AEMIF_*_BASE macros #define'd in <mach/da8xx.h>.  Start using them
instead.

Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>

---
The patch is against the recent DaVinci tree.

 arch/arm/mach-davinci/board-da830-evm.c |   11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

Index: linux-davinci/arch/arm/mach-davinci/board-da830-evm.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-da830-evm.c
+++ linux-davinci/arch/arm/mach-davinci/board-da830-evm.c
@@ -33,9 +33,6 @@
 #define DA830_EVM_PHY_MASK		0x0
 #define DA830_EVM_MDIO_FREQUENCY	2200000	/* PHY bus frequency */
 
-#define DA830_EMIF25_ASYNC_DATA_CE3_BASE	0x62000000
-#define DA830_EMIF25_CONTROL_BASE		0x68000000
-
 /*
  * USB1 VBUS is controlled by GPIO1[15], over-current is reported on GPIO2[4].
  */
@@ -375,13 +372,13 @@ static struct davinci_nand_pdata da830_e
 
 static struct resource da830_evm_nand_resources[] = {
 	[0] = {		/* First memory resource is NAND I/O window */
-		.start	= DA830_EMIF25_ASYNC_DATA_CE3_BASE,
-		.end	= DA830_EMIF25_ASYNC_DATA_CE3_BASE + PAGE_SIZE - 1,
+		.start	= DA8XX_AEMIF_CS3_BASE,
+		.end	= DA8XX_AEMIF_CS3_BASE + PAGE_SIZE - 1,
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {		/* Second memory resource is AEMIF control registers */
-		.start	= DA830_EMIF25_CONTROL_BASE,
-		.end	= DA830_EMIF25_CONTROL_BASE + SZ_32K - 1,
+		.start	= DA8XX_AEMIF_CTL_BASE,
+		.end	= DA8XX_AEMIF_CTL_BASE + SZ_32K - 1,
 		.flags	= IORESOURCE_MEM,
 	},
 };

From m-karicheri2 at ti.com  Fri Apr 16 12:50:48 2010
From: m-karicheri2 at ti.com (Karicheri, Muralidharan)
Date: Fri, 16 Apr 2010 12:50:48 -0500
Subject: isif - debugging on dm365
In-Reply-To: <h2kade1bdc1004120146ged3ea83vd1d6ba6386af4f2e@mail.gmail.com>
References: <ade1bdc1003300750r111aeda4iaeab54f770a86331@mail.gmail.com>
	<A69FA2915331DC488A831521EAE36FE4016A8B3D35@dlee06.ent.ti.com>
	<ade1bdc1003300915q6a557cc8n9ac9684c439cad42@mail.gmail.com>
	<A69FA2915331DC488A831521EAE36FE4016A8B3DD2@dlee06.ent.ti.com>
	<j2qade1bdc1003310748t5b57539cs4c868911e7d464e5@mail.gmail.com>
	<A69FA2915331DC488A831521EAE36FE4016A92CC50@dlee06.ent.ti.com>
	<r2nade1bdc1004012338yb12139b8k697d9831df81de33@mail.gmail.com>
	<v2vade1bdc1004070238if288b7abx7b762d3d9d79ab91@mail.gmail.com>
	<4BBC9977.8080902@cynove.com>
	<h2kade1bdc1004120146ged3ea83vd1d6ba6386af4f2e@mail.gmail.com>
Message-ID: <A69FA2915331DC488A831521EAE36FE4016AADBD84@dlee06.ent.ti.com>

Hi,

Currently, the vpfe_capture driver assumes that the S_INPUT is always called. I think this is a wrong assumption
to make. I looked at the sample capture example in the v4l2 spec. It doesn't do S_INPUT or S_STD. So I guess
there should be a default standard and default input set in the driver. In vpfe_probe() current_subdev is initialized
to the first sub device i.e. vpfe_cfg->sub_devs[0]. We are setting the default input to first input on the
current_subdev and default standard to first standard supported by the sub device in vpfe_initialize_device().
I think we also need to read the sub device hw interface parameters in this function and set it in
ccdc after the ccdc device is opened (isif on DM365). i.e after the the call ccdc_dev->hw_ops.open(), call
set_hw_if_params() as well to setup the interface for the default sub device. The set_hw_if_params() in s_input()
is required when the application switch the input sub device. Please add this change as well to your patch.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-karicheri2 at ti.com

________________________________
From: Raffaele Recalcati [mailto:lamiaposta71 at gmail.com]
Sent: Monday, April 12, 2010 4:46 AM
To: Jean-Philippe Fran?ois
Cc: Karicheri, Muralidharan; davinci-linux-open-source
Subject: Re: isif - debugging on dm365

Hi Jean-Philippe,

I finally create my patch against f5cef8f45739db4c0c1c346296922cac274c87eb in attachment, but the problem is that isif_set_hw_if_params is not called by gstreamer.

If I set in drivers/media/video/davinci/isif.c (and not in drivers/media/video/davinci/dm365_ccdc.c as I don't have it !!)
   'ycswap=YCIN_NOT_SWP'
it works !!

The board file has no effect on my gstreamer command:
   gst-launch v4l2src ! video/x-raw-yuv ! filesink location=video_new3.raw
see below for my complete logs.

Here you are the board declaration:
static struct vpfe_subdev_info vpfe_sub_devs[] = {
        {
                .name = "adv7180",
                .grp_id = 0,
                .num_inputs = ARRAY_SIZE(adv7180_inputs),
                .inputs = adv7180_inputs,
                .routes = adv7180_routes,
                .can_route = 1,
                .ccdc_if_params = {
                        .if_type = VPFE_BT656,
                        .hdpol = VPFE_PINPOL_POSITIVE,
                        .vdpol = VPFE_PINPOL_POSITIVE,
                        .ycswap = YCIN_NOT_SWP,
                },
                .board_info = {
                        I2C_BOARD_INFO("adv7180", 0x20),
                        .platform_data = &adv7180_pdata,
                },
        },
};

The patch is very similar to yours, I change only the name of defines because they seem more clear to me.

The complete log (setting ycswap=YCIN_SWP inside isif.c file in order to try to get the correct parameter from my board file) follows:
(isif_set_hw_if_params is not called)

root at dm365-evm:~# gst-launch v4l2src ! video/x-raw-yuv ! filesink location=video
_new3.raw
Setting pipeline to PAUSED ...
vpfe-capture vpfe-capture: vpfe_open
vpfe-capture vpfe-capture: vpfe_querycap
vpfe-capture vpfe-capture: vpfe_enum_input
vpfe-capture vpfe-capture: vpfe_enum_input
vpfe-capture vpfe-capture: input information not found for the subdev
vpfe-capture vpfe-capture: vpfe_g_std
vpfe-capture vpfe-capture: vpfe_g_input
vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap
vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap
vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap
vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap
vpfe-capture vpfe-capture: width = 1, height = 1, bpp = 2
vpfe-capture vpfe-capture: adjusted width = 16, height = 2, bpp = 2, bytesperline = 32, sizeimage = 64
vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap
vpfe-capture vpfe-capture: width = 32768, height = 32768, bpp = 2
vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2, bytesperline = 1440, sizeimage = 691200
vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap
vpfe-capture vpfe-capture: width = 1, height = 1, bpp = 2
vpfe-capture vpfe-capture: adjusted width = 16, height = 2, bpp = 2, bytesperline = 32, sizeimage = 64
vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap
vpfe-capture vpfe-capture: width = 32768, height = 32768, bpp = 2
vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2, bytesperline = 1440, sizeimage = 691200
vpfe-capture vpfe-capture: vpfe_g_fmt_vid_cap
vpfe-capture vpfe-capture: vpfe_s_fmt_vid_cap
vpfe-capture vpfe-capture: width = 720, height = 480, bpp = 2
vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2, bytesperline = 1440, sizeimage = 691200
vpfe-capture vpfe-capture: vpfe_g_std
vpfe-capture vpfe-capture: vpfe_reqbufs
vpfe-capture vpfe-capture: vpfe_buffer_setup
vpfe-capture vpfe-capture: count=3, size=1147200
vpfe-capture vpfe-capture: vpfe_querybuf
vpfe-capture vpfe-capture: vpfe_mmap
vpfe-capture vpfe-capture: vpfe_querybuf
vpfe-capture vpfe-capture: vpfe_mmap
vpfe-capture vpfe-capture: vpfe_querybuf
vpfe-capture vpfe-capture: vpfe_mmap
vpfe-capture vpfe-capture: vpfe_qbuf
vpfe-capture vpfe-capture: vpfe_buffer_prepare
vpfe-capture vpfe-capture: vpfe_qbuf
vpfe-capture vpfe-capture: vpfe_buffer_prepare
vpfe-capture vpfe-capture: vpfe_qbuf
vpfe-capture vpfe-capture: vpfe_buffer_prepare
vpfe-capture vpfe-capture: vpfe_streamon
vpfe-capture vpfe-capture: vpfe_buffer_queue
vpfe-capture vpfe-capture: vpfe_buffer_queue
vpfe-capture vpfe-capture: vpfe_buffer_queue
vpfe-capture vpfe-capture: vpfe_calculate_offsets
isif_config_ycbcr - if_type = 0
isif_config_ycbcr - ycswap = 1
isif_config_ycbcr -924
isif_config_ycbcr -927
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
vpfe-capture vpfe-capture: vpfe_poll
New clock: GstSystemClock



2010/4/7 Jean-Philippe Fran?ois <jp.francois at cynove.com<mailto:jp.francois at cynove.com>>
Raffaele Recalcati a ?crit :

I was adding isif_cfg.y_c_swap variable, but it need a modification inside arch/arm/mach-davinci/dm365.c that I think is not the right direction.
I mean, the "isif" platform data is not board related, but it is cpu related.

sensor or decoder connection to the isif is definitely board related.

the ccdc_if_params field of the vpfe_subdev_info struct is used by
the ccdc code in the ccdc_set_hw_if_params function.

Here is a patch that implement an ycswap field.
It is set in the board file, and used in the ccdc driver.
It does only include the dm365 ccdc, but it can be extended.





--
www.opensurf.it<http://www.opensurf.it>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100416/41097131/attachment-0001.html>

From idriss.ghodhbane at gmail.com  Mon Apr 19 03:48:40 2010
From: idriss.ghodhbane at gmail.com (Idriss Ghodhbane)
Date: Mon, 19 Apr 2010 10:48:40 +0200
Subject: change sound properties
Message-ID: <i2x90d17c5d1004190148v5527d227g50a49bb356425f33@mail.gmail.com>

Hi everybody,

I intend to change the general properties of my sound card exactly when
appealing the "OSSsrc" which is the Gstreamer element I am using to record
from my sound driver, or simply a microphone on my Ubuntu hardy.
In fact, I am getting by default from my OSS device these capabilities :
*caps = audio/x-raw-int, width=(int)16, depth=(int)16, signed=(boolean)true,
endianness=(int)1234, channels=(int)2, rate=(int)44100*
For many reasons, I want to change these default properties to go with :
*caps = audio/x-raw-int, width=(int)16, depth=(int)16, signed=(boolean)true,
endianness=(int)1234, channels=(int)1, rate=(int)8000*
Thanks in advance for helping me resolve this issue.

Best Regards
-- 
IDRISS GHODHBANE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100419/0e6aabde/attachment.html>

From darren.longhorn at redembedded.com  Mon Apr 19 04:06:53 2010
From: darren.longhorn at redembedded.com (Darren Longhorn)
Date: Mon, 19 Apr 2010 10:06:53 +0100
Subject: Instantiating TI MPEG4 encoder as Baseline H.263
Message-ID: <4BCC1D2D.7030408@redembedded.com>

Hi all,

am trying to use the TI MPEG4 encoder as a baseline H.263 encoder. So
far I have discovered that I need to set the encodingPreset field of the
IVIDENC1_Params struct to XDM_USER_DEFINED (to use the extended
parameters) and the encodeMode field of the IMP4VENC_Params struct to 0
for H.263 mode. Before that the encoder simply preduced MPEG4 encoded
data. Now, while the appears to be created ok (VIDENC1_create returns a
handle) all calls to VIDENC1_process return -1 and the extendedError
field of the IVIDENC1_OutArgs struct is set to 0xa000,
XDM_UNSUPPORTEDINPUT & XDM_FATALERROR bits set.

Anyone have any ideas?

Cheers

Darren




From khilman at deeprootsystems.com  Mon Apr 19 16:43:42 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 19 Apr 2010 14:43:42 -0700
Subject: [PATCH] Davinci: iotable based ioremap() interception
In-Reply-To: <1270831964-22661-1-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Fri\, 9 Apr 2010 12\:52\:44 -0400")
References: <1270831964-22661-1-git-send-email-cyril@ti.com>
Message-ID: <87y6gjrucx.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> This patch allows for a more flexible ioremap() interception.  The mechanism
> works by translating physical addresses based on soc-specific iotable
> contents (davinci_soc_info.io_desc), once davinci_soc_info is populated by
> davinci_common_init().
>
> This change has been tested on dm365 and dm355 by Sandeep.  With additional
> changes (not included here), this was also tested on tnetv107x.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> Tested-by: Sandeep Paulraj <s-paulraj at ti.com>

Hmm, I don't like having a special class of ioremap without a *very*
well defined structure for when to use and not to use.

I'd rather just see the iotable stuff pulled out of _common_init()
and put into its own function that can be called early.

Kevin


> ---
>  arch/arm/mach-davinci/da830.c           |    7 +++++-
>  arch/arm/mach-davinci/da850.c           |    9 ++++++-
>  arch/arm/mach-davinci/include/mach/io.h |    4 +++
>  arch/arm/mach-davinci/io.c              |   33 +++++++++++++++++++++++++++---
>  4 files changed, 46 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
> index 122e61a..168f277 100644
> --- a/arch/arm/mach-davinci/da830.c
> +++ b/arch/arm/mach-davinci/da830.c
> @@ -1206,9 +1206,14 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
>  	.emac_pdata		= &da8xx_emac_pdata,
>  };
>  
> +#define da830_early_ioremap(p, s)				\
> +	__davinci_ioremap(p, s,					\
> +			davinci_soc_info_da830.io_desc,		\
> +			davinci_soc_info_da830.io_desc_num)
> +
>  void __init da830_init(void)
>  {
> -	da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
> +	da8xx_syscfg0_base = da830_early_ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
>  	if (WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module"))
>  		return;
>  
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index d0fd756..27eb32e 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -1093,15 +1093,20 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
>  	.sram_len		= SZ_8K,
>  };
>  
> +#define da850_early_ioremap(p, s)				\
> +	__davinci_ioremap(p, s,					\
> +			davinci_soc_info_da850.io_desc,		\
> +			davinci_soc_info_da850.io_desc_num)
> +
>  void __init da850_init(void)
>  {
>  	unsigned int v;
>  
> -	da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
> +	da8xx_syscfg0_base = da850_early_ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
>  	if (WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module"))
>  		return;
>  
> -	da8xx_syscfg1_base = ioremap(DA8XX_SYSCFG1_BASE, SZ_4K);
> +	da8xx_syscfg1_base = da850_early_ioremap(DA8XX_SYSCFG1_BASE, SZ_4K);
>  	if (WARN(!da8xx_syscfg1_base, "Unable to map syscfg1 module"))
>  		return;
>  
> diff --git a/arch/arm/mach-davinci/include/mach/io.h b/arch/arm/mach-davinci/include/mach/io.h
> index 62b0a90..4aa301c 100644
> --- a/arch/arm/mach-davinci/include/mach/io.h
> +++ b/arch/arm/mach-davinci/include/mach/io.h
> @@ -25,6 +25,10 @@
>  #define __arch_ioremap(p, s, t)	davinci_ioremap(p, s, t)
>  #define __arch_iounmap(v)	davinci_iounmap(v)
>  
> +struct map_desc;
> +
> +void __iomem *__davinci_ioremap(unsigned long p, size_t size,
> +		struct map_desc *io_desc, int io_desc_num);
>  void __iomem *davinci_ioremap(unsigned long phys, size_t size,
>  			      unsigned int type);
>  void davinci_iounmap(volatile void __iomem *addr);
> diff --git a/arch/arm/mach-davinci/io.c b/arch/arm/mach-davinci/io.c
> index a1c0b6b..3a62f14 100644
> --- a/arch/arm/mach-davinci/io.c
> +++ b/arch/arm/mach-davinci/io.c
> @@ -12,17 +12,42 @@
>  #include <linux/io.h>
>  
>  #include <asm/tlb.h>
> +#include <asm/mach/map.h>
>  
> -#define BETWEEN(p, st, sz)	((p) >= (st) && (p) < ((st) + (sz)))
> -#define XLATE(p, pst, vst)	((void __iomem *)((p) - (pst) + (vst)))
> +#include <mach/common.h>
> +
> +/*
> + * Remap io addresses based on a soc-specific io-descriptor table. This is
> + * useful in early arch init code before davinci_common_init().  After
> + * davinci_common_init(), regular ioremap() calls should be used.
> + */
> +void __iomem *__davinci_ioremap(unsigned long p, size_t size,
> +		struct map_desc *io_desc, int io_desc_num)
> +{
> +	int i;
> +
> +	for (i = 0; i < io_desc_num; i++, io_desc++) {
> +		unsigned long iophys = __pfn_to_phys(io_desc->pfn);
> +		unsigned long iosize = io_desc->length;
> +
> +		if (p >= iophys && (p + size) <= (iophys + iosize))
> +			return __io(io_desc->virtual + p - iophys);
> +	}
> +
> +	return NULL;
> +}
>  
>  /*
>   * Intercept ioremap() requests for addresses in our fixed mapping regions.
>   */
>  void __iomem *davinci_ioremap(unsigned long p, size_t size, unsigned int type)
>  {
> -	if (BETWEEN(p, IO_PHYS, IO_SIZE))
> -		return XLATE(p, IO_PHYS, IO_VIRT);
> +	void __iomem *ret;
> +
> +	ret = __davinci_ioremap(p, size, davinci_soc_info.io_desc,
> +			davinci_soc_info.io_desc_num);
> +	if (ret)
> +		return ret;
>  
>  	return __arm_ioremap_caller(p, size, type, __builtin_return_address(0));
>  }
> -- 
> 1.6.3.3

From khilman at deeprootsystems.com  Mon Apr 19 16:45:06 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 19 Apr 2010 14:45:06 -0700
Subject: [PATCH v2 15/16] Davinci: initial tnetv107x support
In-Reply-To: <4BBFA295.5010007@ti.com> (Cyril Chemparathy's message of "Fri\,
	09 Apr 2010 17\:56\:37 -0400")
References: <1269553439-14886-1-git-send-email-cyril@ti.com>
	<1269553439-14886-2-git-send-email-cyril@ti.com>
	<1269553439-14886-3-git-send-email-cyril@ti.com>
	<1269553439-14886-4-git-send-email-cyril@ti.com>
	<1269553439-14886-5-git-send-email-cyril@ti.com>
	<1269553439-14886-6-git-send-email-cyril@ti.com>
	<1269553439-14886-7-git-send-email-cyril@ti.com>
	<1269553439-14886-8-git-send-email-cyril@ti.com>
	<1269553439-14886-9-git-send-email-cyril@ti.com>
	<1269553439-14886-10-git-send-email-cyril@ti.com>
	<1269553439-14886-11-git-send-email-cyril@ti.com>
	<1269553439-14886-12-git-send-email-cyril@ti.com>
	<1269553439-14886-13-git-send-email-cyril@ti.com>
	<1269553439-14886-14-git-send-email-cyril@ti.com>
	<1269553439-14886-15-git-send-email-cyril@ti.com>
	<1269553439-14886-16-git-send-email-cyril@ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E669976F@dbde02.ent.ti.com>
	<4BBFA295.5010007@ti.com>
Message-ID: <87sk6rrual.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> Sekhar,
>
>> > +struct platform_device davinci_wdt_device = {
>> > +	.name		= "watchdog",
>> > +	.id		= -1,
>> > +	.num_resources	= ARRAY_SIZE(wdt_resources),
>> > +	.resource	= wdt_resources,
>> > +};
>>
>> IMO, a better way to overcome the 'no watchdog timer'
>> limitation would be to make the watchdog reset code
>> not use the wdt platform data directly, but instead
>> 'search' for watchdog device using bus_for_each_dev()
>> iterator on platform bus.
>>
>> In your case, the watchdog device wouldn't be found
>> and the reset function should exist gracefully.
>
> I realize that I agreed to your viewpoint earlier, but I see a problem
> with this approach.  If an arch_reset() were to somehow get triggered
> in early boot (e.g. via panic()), the watchdog device may not have
> been registered yet.
>
> Any thoughts on how to approach this situation?

Then just fail with an 'unable to reset' message due to missing wdt.

Kevin

From khilman at deeprootsystems.com  Mon Apr 19 16:56:23 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 19 Apr 2010 14:56:23 -0700
Subject: [PATCH v3 02/16] Davinci: generalized debug macros
In-Reply-To: <1271270702-28307-3-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Wed\, 14 Apr 2010 14\:44\:48 -0400")
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
Message-ID: <87mxwzrtrs.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> 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 macros through a small chunk of memory placed just
> below the page tables (@0x80003ff8).
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> Tested-by: Sandeep Paulraj <s-paulraj at ti.com>

This one looks ok, but needs broader testing on the DM* and DA*. 

Kevin

> ---
>  arch/arm/mach-davinci/include/mach/debug-macro.S |   51 +++++++++++---
>  arch/arm/mach-davinci/include/mach/serial.h      |   13 ++++
>  arch/arm/mach-davinci/include/mach/uncompress.h  |   80 ++++++++++++++++------
>  3 files changed, 112 insertions(+), 32 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/include/mach/debug-macro.S b/arch/arm/mach-davinci/include/mach/debug-macro.S
> index 3cd93a8..ac0fa02 100644
> --- a/arch/arm/mach-davinci/include/mach/debug-macro.S
> +++ b/arch/arm/mach-davinci/include/mach/debug-macro.S
> @@ -17,22 +17,51 @@
>   */
>  
>  #include <linux/serial_reg.h>
> +
> +#include <asm/memory.h>
> +
> +#include <mach/serial.h>
> +
>  #define UART_SHIFT	2
>  
> +		.pushsection .data
> +davinci_uart_phys:	.word	0
> +davinci_uart_virt:	.word	0
> +		.popsection
> +
>  		.macro addruart, rx, tmp
> +
> +		/* Use davinci_uart_phys/virt if already configured */
> +10:		mrc	p15, 0, \rx, c1, c0
> +		tst	\rx, #1			@ MMU enabled?
> +		ldreq	\rx, =__virt_to_phys(davinci_uart_phys)
> +		ldrne	\rx, =davinci_uart_virt
> +		ldr	\rx, [\rx]
> +		cmp	\rx, #0			@ is port configured?
> +		bne	99f			@ already configured
> +
> +		/* Copy uart phys address from decompressor uart info */
>  		mrc	p15, 0, \rx, c1, c0
>  		tst	\rx, #1			@ MMU enabled?
> -		moveq	\rx, #0x01000000	@ physical base address
> -		movne	\rx, #0xfe000000	@ virtual base
> -#if defined(CONFIG_ARCH_DAVINCI_DA8XX) && defined(CONFIG_ARCH_DAVINCI_DMx)
> -#error Cannot enable DaVinci and DA8XX platforms concurrently
> -#elif defined(CONFIG_MACH_DAVINCI_DA830_EVM) || \
> -	defined(CONFIG_MACH_DAVINCI_DA850_EVM)
> -		orr	\rx, \rx, #0x00d00000	@ physical base address
> -		orr	\rx, \rx, #0x0000d000	@ of UART 2
> -#else
> -		orr	\rx, \rx, #0x00c20000   @ UART 0
> -#endif
> +		ldreq	\tmp, =__virt_to_phys(davinci_uart_phys)
> +		ldrne	\tmp, =davinci_uart_phys
> +		ldreq	\rx, =DAVINCI_UART_INFO
> +		ldrne	\rx, =__phys_to_virt(DAVINCI_UART_INFO)
> +		ldr	\rx, [\rx, #0]
> +		str	\rx, [\tmp]
> +
> +		/* Copy uart virt address from decompressor uart info */
> +		mrc	p15, 0, \rx, c1, c0
> +		tst	\rx, #1			@ MMU enabled?
> +		ldreq	\tmp, =__virt_to_phys(davinci_uart_virt)
> +		ldrne	\tmp, =davinci_uart_virt
> +		ldreq	\rx, =DAVINCI_UART_INFO
> +		ldrne	\rx, =__phys_to_virt(DAVINCI_UART_INFO)
> +		ldr	\rx, [\rx, #4]
> +		str	\rx, [\tmp]
> +
> +		b	10b
> +99:
>  		.endm
>  
>  		.macro	senduart,rd,rx
> diff --git a/arch/arm/mach-davinci/include/mach/serial.h b/arch/arm/mach-davinci/include/mach/serial.h
> index a584697..8829dde 100644
> --- a/arch/arm/mach-davinci/include/mach/serial.h
> +++ b/arch/arm/mach-davinci/include/mach/serial.h
> @@ -11,8 +11,19 @@
>  #ifndef __ASM_ARCH_SERIAL_H
>  #define __ASM_ARCH_SERIAL_H
>  
> +#include <asm/memory.h>
> +
>  #include <mach/hardware.h>
>  
> +/*
> + * Stolen area that contains debug uart physical and virtual addresses.  These
> + * addresses are filled in by the uncompress.h code, and are used by the debug
> + * macros in debug-macro.S.
> + *
> + * This area sits just below the page tables (see arch/arm/kernel/head.S).
> + */
> +#define DAVINCI_UART_INFO	(PHYS_OFFSET + 0x3ff8)
> +
>  #define DAVINCI_MAX_NR_UARTS	3
>  #define DAVINCI_UART0_BASE	(IO_PHYS + 0x20000)
>  #define DAVINCI_UART1_BASE	(IO_PHYS + 0x20400)
> @@ -27,11 +38,13 @@
>  #define UART_DM646X_SCR			0x10
>  #define UART_DM646X_SCR_TX_WATERMARK	0x08
>  
> +#ifndef __ASSEMBLY__
>  struct davinci_uart_config {
>  	/* Bit field of UARTs present; bit 0 --> UART1 */
>  	unsigned int enabled_uarts;
>  };
>  
>  extern int davinci_serial_init(struct davinci_uart_config *);
> +#endif
>  
>  #endif /* __ASM_ARCH_SERIAL_H */
> diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
> index 33796b4..20c23a3 100644
> --- a/arch/arm/mach-davinci/include/mach/uncompress.h
> +++ b/arch/arm/mach-davinci/include/mach/uncompress.h
> @@ -1,8 +1,17 @@
>  /*
>   * Serial port stubs for kernel decompress status messages
>   *
> - *  Author:     Anant Gole
> - * (C) Copyright (C) 2006, Texas Instruments, Inc
> + * Initially based on:
> + * arch/arm/plat-omap/include/mach/uncompress.h
> + *
> + * Original copyrights follow.
> + *
> + * Copyright (C) 2000 RidgeRun, Inc.
> + * Author: Greg Lonnon <glonnon at ridgerun.com>
> + *
> + * Rewritten by:
> + * Author: <source at mvista.com>
> + * 2004 (c) MontaVista Software, Inc.
>   *
>   * This file is licensed under the terms of the GNU General Public License
>   * version 2. This program is licensed "as is" without any warranty of any
> @@ -11,30 +20,17 @@
>  
>  #include <linux/types.h>
>  #include <linux/serial_reg.h>
> -#include <mach/serial.h>
>  
>  #include <asm/mach-types.h>
>  
> -extern unsigned int __machine_arch_type;
> +#include <mach/serial.h>
>  
>  static u32 *uart;
> -
> -static u32 *get_uart_base(void)
> -{
> -	if (__machine_arch_type == MACH_TYPE_DAVINCI_DA830_EVM ||
> -		__machine_arch_type == MACH_TYPE_DAVINCI_DA850_EVM)
> -		return (u32 *)DA8XX_UART2_BASE;
> -	else
> -		return (u32 *)DAVINCI_UART0_BASE;
> -}
> +static u32 *uart_info = (u32 *)(DAVINCI_UART_INFO);
>  
>  /* PORT_16C550A, in polled non-fifo mode */
> -
>  static void putc(char c)
>  {
> -	if (!uart)
> -		uart = get_uart_base();
> -
>  	while (!(uart[UART_LSR] & UART_LSR_THRE))
>  		barrier();
>  	uart[UART_TX] = c;
> @@ -42,12 +38,54 @@ static void putc(char c)
>  
>  static inline void flush(void)
>  {
> -	if (!uart)
> -		uart = get_uart_base();
> -
>  	while (!(uart[UART_LSR] & UART_LSR_THRE))
>  		barrier();
>  }
>  
> -#define arch_decomp_setup()
> +static inline void set_uart_info(u32 phys, void * __iomem virt)
> +{
> +	uart = (u32 *)phys;
> +	uart_info[0] = phys;
> +	uart_info[1] = (u32)virt;
> +}
> +
> +#define _DEBUG_LL_ENTRY(machine, phys, virt)			\
> +	if (machine_is_##machine()) {				\
> +		set_uart_info(phys, virt);			\
> +		break;						\
> +	}
> +
> +#define DEBUG_LL_DAVINCI(machine, port)				\
> +	_DEBUG_LL_ENTRY(machine, DAVINCI_UART##port##_BASE,	\
> +			IO_ADDRESS(DAVINCI_UART##port##_BASE))
> +
> +#define DEBUG_LL_DA8XX(machine, port)				\
> +	_DEBUG_LL_ENTRY(machine, DA8XX_UART##port##_BASE,	\
> +			IO_ADDRESS(DA8XX_UART##port##_BASE))
> +
> +static inline void __arch_decomp_setup(unsigned long arch_id)
> +{
> +	/*
> +	 * Initialize the port based on the machine ID from the bootloader.
> +	 * Note that we're using macros here instead of switch statement
> +	 * as machine_is functions are optimized out for the boards that
> +	 * are not selected.
> +	 */
> +	do {
> +		/* Davinci boards */
> +		DEBUG_LL_DAVINCI(davinci_evm,		0);
> +		DEBUG_LL_DAVINCI(sffsdr,		0);
> +		DEBUG_LL_DAVINCI(neuros_osd2,		0);
> +		DEBUG_LL_DAVINCI(davinci_dm355_evm,	0);
> +		DEBUG_LL_DAVINCI(dm355_leopard,		0);
> +		DEBUG_LL_DAVINCI(davinci_dm6467_evm,	0);
> +		DEBUG_LL_DAVINCI(davinci_dm365_evm,	0);
> +
> +		/* DA8xx boards */
> +		DEBUG_LL_DA8XX(davinci_da830_evm,	2);
> +		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
> +	} while (0);
> +}
> +
> +#define arch_decomp_setup()	__arch_decomp_setup(arch_id)
>  #define arch_decomp_wdog()
> -- 
> 1.6.3.3

From khilman at deeprootsystems.com  Mon Apr 19 17:08:58 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 19 Apr 2010 15:08:58 -0700
Subject: [PATCH v3 06/16] Davinci: gpio - minor cleanup
In-Reply-To: <1271270702-28307-7-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Wed\, 14 Apr 2010 14\:44\:52 -0400")
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
Message-ID: <87eiibrt6t.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> macroized repeated container_of()s to improve readability.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
> ---
> v3: Reverted back on direction_in/out unification

Why?  I agree with Sergei that that was a nice cleanup.

Otherwise, patch looks fine.

Kevin


From khilman at deeprootsystems.com  Mon Apr 19 17:17:24 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 19 Apr 2010 15:17:24 -0700
Subject: [PATCH v3 03/16] Davinci: configurable pll divider mask
In-Reply-To: <1271270702-28307-4-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Wed\, 14 Apr 2010 14\:44\:49 -0400")
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
Message-ID: <87d3xvrssr.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> This patch allows socs to override the divider ratio mask by setting an
> optional field (div_ratio_mask) in the pll_data structure.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
> ---
> v3: moved div_ratio_mask setup to before clk->recalc()

Looks good, applying and queuing for 2.6.35 in davinci-next.

Kevin

>  arch/arm/mach-davinci/clock.c |    9 ++++++---
>  arch/arm/mach-davinci/clock.h |    1 +
>  2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
> index 5de60ae..868cb76 100644
> --- a/arch/arm/mach-davinci/clock.c
> +++ b/arch/arm/mach-davinci/clock.c
> @@ -279,7 +279,7 @@ static unsigned long clk_sysclk_recalc(struct clk *clk)
>  
>  	v = __raw_readl(pll->base + clk->div_reg);
>  	if (v & PLLDIV_EN) {
> -		plldiv = (v & PLLDIV_RATIO_MASK) + 1;
> +		plldiv = (v & pll->div_ratio_mask) + 1;
>  		if (plldiv)
>  			rate /= plldiv;
>  	}
> @@ -319,7 +319,7 @@ static unsigned long clk_pllclk_recalc(struct clk *clk)
>  	if (pll->flags & PLL_HAS_PREDIV) {
>  		prediv = __raw_readl(pll->base + PREDIV);
>  		if (prediv & PLLDIV_EN)
> -			prediv = (prediv & PLLDIV_RATIO_MASK) + 1;
> +			prediv = (prediv & pll->div_ratio_mask) + 1;
>  		else
>  			prediv = 1;
>  	}
> @@ -331,7 +331,7 @@ static unsigned long clk_pllclk_recalc(struct clk *clk)
>  	if (pll->flags & PLL_HAS_POSTDIV) {
>  		postdiv = __raw_readl(pll->base + POSTDIV);
>  		if (postdiv & PLLDIV_EN)
> -			postdiv = (postdiv & PLLDIV_RATIO_MASK) + 1;
> +			postdiv = (postdiv & pll->div_ratio_mask) + 1;
>  		else
>  			postdiv = 1;
>  	}
> @@ -458,6 +458,9 @@ int __init davinci_clk_init(struct clk_lookup *clocks)
>  				clk->recalc = clk_leafclk_recalc;
>  		}
>  
> +		if (clk->pll_data && !clk->pll_data->div_ratio_mask)
> +			clk->pll_data->div_ratio_mask = PLLDIV_RATIO_MASK;
> +
>  		if (clk->recalc)
>  			clk->rate = clk->recalc(clk);
>  
> diff --git a/arch/arm/mach-davinci/clock.h b/arch/arm/mach-davinci/clock.h
> index 53a0f7b..ce26015 100644
> --- a/arch/arm/mach-davinci/clock.h
> +++ b/arch/arm/mach-davinci/clock.h
> @@ -76,6 +76,7 @@ struct pll_data {
>  	u32 num;
>  	u32 flags;
>  	u32 input_rate;
> +	u32 div_ratio_mask;
>  };
>  #define PLL_HAS_PREDIV          0x01
>  #define PLL_HAS_POSTDIV         0x02
> -- 
> 1.6.3.3

From khilman at deeprootsystems.com  Mon Apr 19 17:21:24 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 19 Apr 2010 15:21:24 -0700
Subject: [PATCH v3 04/16] Davinci: cpu class macros
In-Reply-To: <1271270702-28307-5-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Wed\, 14 Apr 2010 14\:44\:50 -0400")
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
Message-ID: <87633nrsm3.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> This patches adds cpu class macros that can be used to differentiate between
> DMx, da8xx, and tnetv107x socs.
>
> These macros are available for use only after the JTAG ID looking is done by
> davinci_common_init().  If we need this earlier in the boot process, we may
> have to rely on machine_is_* macros to determine the cpu class.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
> ---
>  arch/arm/mach-davinci/include/mach/cputype.h |   13 +++++++++++++
>  1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/include/mach/cputype.h b/arch/arm/mach-davinci/include/mach/cputype.h
> index cea6b89..0bc6996 100644
> --- a/arch/arm/mach-davinci/include/mach/cputype.h
> +++ b/arch/arm/mach-davinci/include/mach/cputype.h
> @@ -91,4 +91,17 @@ IS_DAVINCI_CPU(tnetv107x, DAVINCI_CPU_ID_TNETV107X)
>  #define cpu_is_davinci_tnetv107x() 0
>  #endif
>  
> +#define cpu_class_is_dmx()		\
> +	(cpu_is_davinci_dm644x() ||	\
> +	 cpu_is_davinci_dm646x() ||	\
> +	 cpu_is_davinci_dm355()  ||	\
> +	 cpu_is_davinci_dm365())
> +
> +#define cpu_class_is_da8xx()		\
> +	(cpu_is_davinci_da830()	||	\
> +	 cpu_is_davinci_da850())
> +
> +#define cpu_class_is_tnetv107x()	\
> +	(cpu_is_davinci_tnetv107x())

This one seems like a very specific class name.  :)

Maybe drop the tnet one for now until a more general grouping is
needed.

Kevin


From khilman at deeprootsystems.com  Mon Apr 19 17:35:40 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 19 Apr 2010 15:35:40 -0700
Subject: [PATCH v3 05/16] Davinci: watchdog reset separation across socs
In-Reply-To: <1271270702-28307-6-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Wed\, 14 Apr 2010 14\:44\:51 -0400")
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
Message-ID: <87wrw3qddv.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> The earlier watchdog reset mechanism had a couple of limitations.  First, it
> embedded a reference to "davinci_wdt_device" inside common code.  This
> forced all derived platforms (da8xx and tnetv107x) to define such a device.
> This also would have caused problems in including multiple socs in a single
> build due to symbol redefinition.
>
> With this patch, davinci_watchdog_reset() now takes the platform device as an
> argument.  arch_reset() then uses the cpu_class_ macros and passes in an
> appropriate soc-dependent device to davinci_watchdog_reset().
>
> This way, as long as the compiler optimizer is active (tested with O2 and Os),
> irrelevant arch_reset code gets auto-magically stripped out along with hanging
> references to unknown symbols.

Good for runtime, but still not so good for readability.

I think the better option is to get rid of the global platform_devices
altogether.  There are a couple options here

1. just search for a watchdog device (I think this is what Sekhar
already pointed out.)

2. use platform_bus notifier callbacks and check when you get an
BUS_NOTIFY_ADD_DEVICE for a "watchdog" device.  Once you get this, you
can have a functioning reset, until then it will have to be a nop.

Kevin

From khilman at deeprootsystems.com  Mon Apr 19 18:08:15 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 19 Apr 2010 16:08:15 -0700
Subject: [PATCH v2 1/2] DaVinci: move AEMIF #define's to the proper headers
In-Reply-To: <201004162129.11843.sshtylyov@ru.mvista.com> (Sergei Shtylyov's
	message of "Fri\, 16 Apr 2010 21\:29\:11 +0400")
References: <201004162129.11843.sshtylyov@ru.mvista.com>
Message-ID: <87iq7nqbvk.fsf@deeprootsystems.com>

Sergei Shtylyov <sshtylyov at ru.mvista.com> writes:

> Currently each DaVinci board file #define's its own version of the EMIFA base
> addresses (all named DAVINCI_ASYNC_EMIF_*_BASE), which leads to duplication.
> Move these #define's to the SoC specific headers, changing their prefixes from
> 'DAVINCI' to the 'DM355', 'DM644X', and 'DM646X' since all these base addresses
> are SoC specific...
>
> And while at it, rename DM646X_ASYNC_EMIF_DATA_CE0_BASE to
> DM646X_ASYNC_EMIF_CS2_SPACE_BASE in order to match the DM646x datasheet.
>
> Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>

Nice, applying this series of 2, and queuing for 2.6.35 in davinci-next.

Kevin

> ---
> The patch is against the recent DaVinci tree.
>
> Changes since the previous version:
> - included changes to board-dm365-evm.c and <mach/dm365.h>;
> - renamed DM646X_ASYNC_EMIF_DATA_CE0_BASE to DM646X_ASYNC_EMIF_CS2_SPACE_BASE;
> - re-sorted the patch.
>
>  arch/arm/mach-davinci/board-dm355-evm.c     |   11 ++++-------
>  arch/arm/mach-davinci/board-dm355-leopard.c |   11 ++++-------
>  arch/arm/mach-davinci/board-dm365-evm.c     |    5 -----
>  arch/arm/mach-davinci/board-dm644x-evm.c    |   18 ++++++------------
>  arch/arm/mach-davinci/board-dm646x-evm.c    |   11 ++++-------
>  arch/arm/mach-davinci/board-neuros-osd2.c   |   11 ++++-------
>  arch/arm/mach-davinci/board-sffsdr.c        |   11 ++++-------
>  arch/arm/mach-davinci/include/mach/dm355.h  |    3 +++
>  arch/arm/mach-davinci/include/mach/dm365.h  |    4 ++++
>  arch/arm/mach-davinci/include/mach/dm644x.h |    6 ++++++
>  arch/arm/mach-davinci/include/mach/dm646x.h |    3 +++
>  11 files changed, 42 insertions(+), 52 deletions(-)
>
> Index: linux-davinci/arch/arm/mach-davinci/board-dm355-evm.c
> ===================================================================
> --- linux-davinci.orig/arch/arm/mach-davinci/board-dm355-evm.c
> +++ linux-davinci/arch/arm/mach-davinci/board-dm355-evm.c
> @@ -33,9 +33,6 @@
>  #include <mach/mmc.h>
>  #include <mach/usb.h>
>  
> -#define DAVINCI_ASYNC_EMIF_CONTROL_BASE		0x01e10000
> -#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, maybe with a different block size, partitioning may
> @@ -86,12 +83,12 @@ static struct davinci_nand_pdata davinci
>  
>  static struct resource davinci_nand_resources[] = {
>  	{
> -		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
> -		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_32M - 1,
> +		.start		= DM355_ASYNC_EMIF_DATA_CE0_BASE,
> +		.end		= DM355_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,
> +		.start		= DM355_ASYNC_EMIF_CONTROL_BASE,
> +		.end		= DM355_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
>  		.flags		= IORESOURCE_MEM,
>  	},
>  };
> Index: linux-davinci/arch/arm/mach-davinci/board-dm355-leopard.c
> ===================================================================
> --- linux-davinci.orig/arch/arm/mach-davinci/board-dm355-leopard.c
> +++ linux-davinci/arch/arm/mach-davinci/board-dm355-leopard.c
> @@ -30,9 +30,6 @@
>  #include <mach/mmc.h>
>  #include <mach/usb.h>
>  
> -#define DAVINCI_ASYNC_EMIF_CONTROL_BASE		0x01e10000
> -#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, maybe with a different block size, partitioning may
> @@ -82,12 +79,12 @@ static struct davinci_nand_pdata davinci
>  
>  static struct resource davinci_nand_resources[] = {
>  	{
> -		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
> -		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_32M - 1,
> +		.start		= DM355_ASYNC_EMIF_DATA_CE0_BASE,
> +		.end		= DM355_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,
> +		.start		= DM355_ASYNC_EMIF_CONTROL_BASE,
> +		.end		= DM355_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
>  		.flags		= IORESOURCE_MEM,
>  	},
>  };
> Index: linux-davinci/arch/arm/mach-davinci/board-dm365-evm.c
> ===================================================================
> --- linux-davinci.orig/arch/arm/mach-davinci/board-dm365-evm.c
> +++ linux-davinci/arch/arm/mach-davinci/board-dm365-evm.c
> @@ -53,11 +53,6 @@ static inline int have_tvp7002(void)
>  	return 0;
>  }
>  
> -
> -#define DM365_ASYNC_EMIF_CONTROL_BASE	0x01d10000
> -#define DM365_ASYNC_EMIF_DATA_CE0_BASE	0x02000000
> -#define DM365_ASYNC_EMIF_DATA_CE1_BASE	0x04000000
> -
>  #define DM365_EVM_PHY_MASK		(0x2)
>  #define DM365_EVM_MDIO_FREQUENCY	(2200000) /* PHY bus frequency */
>  
> Index: linux-davinci/arch/arm/mach-davinci/board-dm644x-evm.c
> ===================================================================
> --- linux-davinci.orig/arch/arm/mach-davinci/board-dm644x-evm.c
> +++ linux-davinci/arch/arm/mach-davinci/board-dm644x-evm.c
> @@ -43,12 +43,6 @@
>  
>  #define DAVINCI_CFC_ATA_BASE		  0x01C66000
>  
> -#define DAVINCI_ASYNC_EMIF_CONTROL_BASE   0x01e00000
> -#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE  0x02000000
> -#define DAVINCI_ASYNC_EMIF_DATA_CE1_BASE  0x04000000
> -#define DAVINCI_ASYNC_EMIF_DATA_CE2_BASE  0x06000000
> -#define DAVINCI_ASYNC_EMIF_DATA_CE3_BASE  0x08000000
> -
>  #define LXT971_PHY_ID	(0x001378e2)
>  #define LXT971_PHY_MASK	(0xfffffff0)
>  
> @@ -92,8 +86,8 @@ static struct physmap_flash_data davinci
>  /* NOTE: CFI probe will correctly detect flash part as 32M, but EMIF
>   * limits addresses to 16M, so using addresses past 16M will wrap */
>  static struct resource davinci_evm_norflash_resource = {
> -	.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
> -	.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
> +	.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
> +	.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
>  	.flags		= IORESOURCE_MEM,
>  };
>  
> @@ -154,12 +148,12 @@ static struct davinci_nand_pdata davinci
>  
>  static struct resource davinci_evm_nandflash_resource[] = {
>  	{
> -		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
> -		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
> +		.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
> +		.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
>  		.flags		= IORESOURCE_MEM,
>  	}, {
> -		.start		= DAVINCI_ASYNC_EMIF_CONTROL_BASE,
> -		.end		= DAVINCI_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
> +		.start		= DM644X_ASYNC_EMIF_CONTROL_BASE,
> +		.end		= DM644X_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
>  		.flags		= IORESOURCE_MEM,
>  	},
>  };
> Index: linux-davinci/arch/arm/mach-davinci/board-dm646x-evm.c
> ===================================================================
> --- linux-davinci.orig/arch/arm/mach-davinci/board-dm646x-evm.c
> +++ linux-davinci/arch/arm/mach-davinci/board-dm646x-evm.c
> @@ -80,17 +80,14 @@ static struct davinci_nand_pdata davinci
>  	.options		= 0,
>  };
>  
> -#define DAVINCI_ASYNC_EMIF_CONTROL_BASE		0x20008000
> -#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE	0x42000000
> -
>  static struct resource davinci_nand_resources[] = {
>  	{
> -		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
> -		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_32M - 1,
> +		.start		= DM646X_ASYNC_EMIF_CS2_SPACE_BASE,
> +		.end		= DM646X_ASYNC_EMIF_CS2_SPACE_BASE + SZ_32M - 1,
>  		.flags		= IORESOURCE_MEM,
>  	}, {
> -		.start		= DAVINCI_ASYNC_EMIF_CONTROL_BASE,
> -		.end		= DAVINCI_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
> +		.start		= DM646X_ASYNC_EMIF_CONTROL_BASE,
> +		.end		= DM646X_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
>  		.flags		= IORESOURCE_MEM,
>  	},
>  };
> Index: linux-davinci/arch/arm/mach-davinci/board-neuros-osd2.c
> ===================================================================
> --- linux-davinci.orig/arch/arm/mach-davinci/board-neuros-osd2.c
> +++ linux-davinci/arch/arm/mach-davinci/board-neuros-osd2.c
> @@ -43,9 +43,6 @@
>  
>  #define DAVINCI_CFC_ATA_BASE		 0x01C66000
>  
> -#define DAVINCI_ASYNC_EMIF_CONTROL_BASE	 0x01e00000
> -#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x02000000
> -
>  #define LXT971_PHY_ID			0x001378e2
>  #define LXT971_PHY_MASK			0xfffffff0
>  
> @@ -98,12 +95,12 @@ static struct davinci_nand_pdata davinci
>  
>  static struct resource davinci_ntosd2_nandflash_resource[] = {
>  	{
> -		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
> -		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
> +		.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
> +		.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
>  		.flags		= IORESOURCE_MEM,
>  	}, {
> -		.start		= DAVINCI_ASYNC_EMIF_CONTROL_BASE,
> -		.end		= DAVINCI_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
> +		.start		= DM644X_ASYNC_EMIF_CONTROL_BASE,
> +		.end		= DM644X_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
>  		.flags		= IORESOURCE_MEM,
>  	},
>  };
> Index: linux-davinci/arch/arm/mach-davinci/board-sffsdr.c
> ===================================================================
> --- linux-davinci.orig/arch/arm/mach-davinci/board-sffsdr.c
> +++ linux-davinci/arch/arm/mach-davinci/board-sffsdr.c
> @@ -45,9 +45,6 @@
>  #define SFFSDR_PHY_MASK		(0x2)
>  #define SFFSDR_MDIO_FREQUENCY	(2200000) /* PHY bus frequency */
>  
> -#define DAVINCI_ASYNC_EMIF_CONTROL_BASE   0x01e00000
> -#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE  0x02000000
> -
>  static struct mtd_partition davinci_sffsdr_nandflash_partition[] = {
>  	/* U-Boot Environment: Block 0
>  	 * UBL:                Block 1
> @@ -76,12 +73,12 @@ static struct flash_platform_data davinc
>  
>  static struct resource davinci_sffsdr_nandflash_resource[] = {
>  	{
> -		.start		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
> -		.end		= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
> +		.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
> +		.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
>  		.flags		= IORESOURCE_MEM,
>  	}, {
> -		.start		= DAVINCI_ASYNC_EMIF_CONTROL_BASE,
> -		.end		= DAVINCI_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
> +		.start		= DM644X_ASYNC_EMIF_CONTROL_BASE,
> +		.end		= DM644X_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
>  		.flags		= IORESOURCE_MEM,
>  	},
>  };
> Index: linux-davinci/arch/arm/mach-davinci/include/mach/dm355.h
> ===================================================================
> --- linux-davinci.orig/arch/arm/mach-davinci/include/mach/dm355.h
> +++ linux-davinci/arch/arm/mach-davinci/include/mach/dm355.h
> @@ -15,6 +15,9 @@
>  #include <mach/asp.h>
>  #include <media/davinci/vpfe_capture.h>
>  
> +#define DM355_ASYNC_EMIF_CONTROL_BASE	0x01E10000
> +#define DM355_ASYNC_EMIF_DATA_CE0_BASE	0x02000000
> +
>  #define ASP1_TX_EVT_EN	1
>  #define ASP1_RX_EVT_EN	2
>  
> Index: linux-davinci/arch/arm/mach-davinci/include/mach/dm365.h
> ===================================================================
> --- linux-davinci.orig/arch/arm/mach-davinci/include/mach/dm365.h
> +++ linux-davinci/arch/arm/mach-davinci/include/mach/dm365.h
> @@ -36,6 +36,10 @@
>  #define DAVINCI_DMA_VC_TX		2
>  #define DAVINCI_DMA_VC_RX		3
>  
> +#define DM365_ASYNC_EMIF_CONTROL_BASE	0x01D10000
> +#define DM365_ASYNC_EMIF_DATA_CE0_BASE	0x02000000
> +#define DM365_ASYNC_EMIF_DATA_CE1_BASE	0x04000000
> +
>  void __init dm365_init(void);
>  void __init dm365_init_asp(struct snd_platform_data *pdata);
>  void __init dm365_init_vc(struct snd_platform_data *pdata);
> Index: linux-davinci/arch/arm/mach-davinci/include/mach/dm644x.h
> ===================================================================
> --- linux-davinci.orig/arch/arm/mach-davinci/include/mach/dm644x.h
> +++ linux-davinci/arch/arm/mach-davinci/include/mach/dm644x.h
> @@ -34,6 +34,12 @@
>  #define DM644X_EMAC_MDIO_OFFSET		(0x4000)
>  #define DM644X_EMAC_CNTRL_RAM_SIZE	(0x2000)
>  
> +#define DM644X_ASYNC_EMIF_CONTROL_BASE	0x01E00000
> +#define DM644X_ASYNC_EMIF_DATA_CE0_BASE 0x02000000
> +#define DM644X_ASYNC_EMIF_DATA_CE1_BASE 0x04000000
> +#define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x06000000
> +#define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x08000000
> +
>  void __init dm644x_init(void);
>  void __init dm644x_init_asp(struct snd_platform_data *pdata);
>  void dm644x_set_vpfe_config(struct vpfe_config *cfg);
> Index: linux-davinci/arch/arm/mach-davinci/include/mach/dm646x.h
> ===================================================================
> --- linux-davinci.orig/arch/arm/mach-davinci/include/mach/dm646x.h
> +++ linux-davinci/arch/arm/mach-davinci/include/mach/dm646x.h
> @@ -27,6 +27,9 @@
>  
>  #define DM646X_ATA_REG_BASE		(0x01C66000)
>  
> +#define DM646X_ASYNC_EMIF_CONTROL_BASE	0x20008000
> +#define DM646X_ASYNC_EMIF_CS2_SPACE_BASE 0x42000000
> +
>  void __init dm646x_init(void);
>  void __init dm646x_init_ide(void);
>  void __init dm646x_init_mcasp0(struct snd_platform_data *pdata);

From khilman at deeprootsystems.com  Mon Apr 19 18:11:52 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 19 Apr 2010 16:11:52 -0700
Subject: [PATCH v3 16/16] Davinci: tnetv107x evm board initial support
In-Reply-To: <4BC77E71.2030304@mvista.com> (Sergei Shtylyov's message of "Fri\,
	16 Apr 2010 01\:00\:33 +0400")
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
	<1271270702-28307-9-git-send-email-cyril@ti.com>
	<1271270702-28307-10-git-send-email-cyril@ti.com>
	<1271270702-28307-11-git-send-email-cyril@ti.com>
	<1271270702-28307-12-git-send-email-cyril@ti.com>
	<1271270702-28307-13-git-send-email-cyril@ti.com>
	<1271270702-28307-14-git-send-email-cyril@ti.com>
	<1271270702-28307-15-git-send-email-cyril@ti.com>
	<1271270702-28307-16-git-send-email-cyril@ti.com>
	<1271270702-28307-17-git-send-email-cyril@ti.com>
	<4BC63A3C.7000402@mvista.com> <4BC7421E.8050002@ti.com>
	<4BC77E71.2030304@mvista.com>
Message-ID: <8739yrqbpj.fsf@deeprootsystems.com>

Sergei Shtylyov <sshtylyov at mvista.com> writes:

> Hello.
>
> Cyril Chemparathy wrote:
>
>>>> +#include <linux/mtd/physmap.h>
>>>
>>>    You shouldn't need physmap.h as you don't have the corresponding
>>> device.
>>
>> Agreed.  Will remove.
>>
>>>> +/* Base addresses for on-chip devices */
>>>> +#define TNETV107X_SDIO1_BASE            0x08088800
>>>> +#define TNETV107X_ASYNC_EMIF_CNTRL_BASE        0x08200000
>>>> +#define TNETV107X_ASYNC_EMIF_DATA_CE0_BASE    0x30000000
>>>> +#define TNETV107X_DDR_BASE            0x80000000
>>>
>>>    I doubt that boarc code is a good place for base address
>>> macros. The "declare-where-used" rule shouldn't be taken to an
>>> absurdistic extreme. :-)
>>> Althought you're following an existing example here... :-/
>
>   And I've just submitted patch to move the AEMIF #define's from the
> board files ot the respective headers (have missed one board
> filethough...
>
>> I guess there is a bit of a disconnect here.  In the first place, I
>> fail to see the reasoning behind having soc definitions scattered
>> all over the place.  Could someone with a bit more understanding
>> elaborate on the declare-where-used rule?
>
>   I'll leave that to Kevin. :-)

There is no hard and fast rule.  It would better be stated as "declare
locally."

I've been trying to get away from the model of a large header defining
all the base addresses, most of which are not used.  I also want to
make it difficult for drivers to be written which are dircectly using
global base addresses, when they should be coming via platform_device.

For this particular example, you should define in the local SoC header
as Sergei did in his cleanup.

Thanks,

Kevin



From khilman at deeprootsystems.com  Mon Apr 19 18:14:36 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 19 Apr 2010 16:14:36 -0700
Subject: [PATCH v3 12/16] Davinci: tnetv107x soc specific header
In-Reply-To: <1271270702-28307-13-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Wed\, 14 Apr 2010 14\:44\:58 -0400")
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
	<1271270702-28307-9-git-send-email-cyril@ti.com>
	<1271270702-28307-10-git-send-email-cyril@ti.com>
	<1271270702-28307-11-git-send-email-cyril@ti.com>
	<1271270702-28307-12-git-send-email-cyril@ti.com>
	<1271270702-28307-13-git-send-email-cyril@ti.com>
Message-ID: <87sk6rox0j.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> Added tnetv107x soc specific definitions.

... for pin-mux regs and init function declarations.

Have consideration of lazy people like me who just want to read the
changelog and not the whole patch to see what is changing.  ;)

Kevin


>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> ---
> v3: removed most base address definitions, moved necessary definitions to
>     tnetv107x.c or devices-tnetv107x.c as appropriate
>
>  arch/arm/mach-davinci/include/mach/tnetv107x.h |   66 ++++++++++++++++++++++++
>  1 files changed, 66 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-davinci/include/mach/tnetv107x.h
>
> diff --git a/arch/arm/mach-davinci/include/mach/tnetv107x.h b/arch/arm/mach-davinci/include/mach/tnetv107x.h
> new file mode 100644
> index 0000000..5eafdb8
> --- /dev/null
> +++ b/arch/arm/mach-davinci/include/mach/tnetv107x.h
> @@ -0,0 +1,66 @@
> +/*
> + * Chip specific defines for TNETV107X SoC
> + *
> + * Author: Cyril Chemparathy <cyril at ti.com>
> + *
> + * 2009 (c) Texas Instruments, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This program
> + * is licensed "as is" without any warranty of any kind, whether express
> + * or implied.
> + */
> +#ifndef __ASM_ARCH_DAVINCI_TNETV107X_H
> +#define __ASM_ARCH_DAVINCI_TNETV107X_H
> +
> +#include <asm/sizes.h>
> +
> +/*
> + * Fixed mapping for early init starts here. If low-level debug is enabled,
> + * this area also gets mapped via io_pg_offset and io_phys by the boot code.
> + * To fit in with the io_pg_offset calculation, the io base address selected
> + * here _must_ be a multiple of 2^20.
> + */
> +#define TNETV107X_IO_BASE	0x08000000
> +#define TNETV107X_IO_VIRT	(IO_VIRT + SZ_1M)
> +
> +#define PINMUX0		(0 << 2)
> +#define PINMUX1		(1 << 2)
> +#define PINMUX2		(2 << 2)
> +#define PINMUX3		(3 << 2)
> +#define PINMUX4		(4 << 2)
> +#define PINMUX5		(5 << 2)
> +#define PINMUX6		(6 << 2)
> +#define PINMUX7		(7 << 2)
> +#define PINMUX8		(8 << 2)
> +#define PINMUX9		(9 << 2)
> +#define PINMUX10	(10 << 2)
> +#define PINMUX11	(11 << 2)
> +#define PINMUX12	(12 << 2)
> +#define PINMUX13	(13 << 2)
> +#define PINMUX14	(14 << 2)
> +#define PINMUX15	(15 << 2)
> +#define PINMUX16	(16 << 2)
> +#define PINMUX17	(17 << 2)
> +#define PINMUX18	(18 << 2)
> +#define PINMUX19	(19 << 2)
> +#define PINMUX20	(20 << 2)
> +#define PINMUX21	(21 << 2)
> +#define PINMUX22	(22 << 2)
> +#define PINMUX23	(23 << 2)
> +#define PINMUX24	(24 << 2)
> +#define PINMUX25	(25 << 2)
> +#define PINMUX26	(26 << 2)
> +
> +#define TNETV107X_N_GPIOS	65
> +
> +#ifndef __ASSEMBLY__
> +
> +#include <linux/serial_8250.h>
> +
> +extern void __init tnetv107x_init(void);
> +extern void __init tnetv107x_gpio_init(void);
> +extern void __init tnetv107x_edma_init(void);
> +extern void __init tnetv107x_irq_init(void);
> +extern void __init tnetv107x_serial_init(struct plat_serial8250_port* ports);
> +#endif
> +
> +#endif /* __ASM_ARCH_DAVINCI_TNETV107X_H */
> -- 
> 1.6.3.3

From khilman at deeprootsystems.com  Mon Apr 19 18:33:39 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 19 Apr 2010 16:33:39 -0700
Subject: [PATCH v3 13/16] Davinci: tnetv107x initial support
In-Reply-To: <1271270702-28307-14-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Wed\, 14 Apr 2010 14\:44\:59 -0400")
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<1271270702-28307-7-git-send-email-cyril@ti.com>
	<1271270702-28307-8-git-send-email-cyril@ti.com>
	<1271270702-28307-9-git-send-email-cyril@ti.com>
	<1271270702-28307-10-git-send-email-cyril@ti.com>
	<1271270702-28307-11-git-send-email-cyril@ti.com>
	<1271270702-28307-12-git-send-email-cyril@ti.com>
	<1271270702-28307-13-git-send-email-cyril@ti.com>
	<1271270702-28307-14-git-send-email-cyril@ti.com>
Message-ID: <874oj7ow4s.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> 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 PLL.  Some
> elements of the clock architecture are reused from Davinci (e.g. LPSC), but
> the PLL related code is overridden using existing interfaces in "struct clk".
>
> 2. The MMR layout on this SOC is substantially different from Davinci.
> Consequently, the fixed I/O map is a whole lot more convoluted (more so than
> DA8xx).  The net impact here is that IO_ADDRESS() will not work on this SoC,
> and therefore all mappings have to be through ioremap().
>
> 3. The Davinci reset mechanism (via Timer64 watchdog) will not work on this
> SoC.  This difference has not been addressed here (dummy davinci_wdt_device),
> but a more "extensible" reset mechanism will need to be established
> eventually.

Based on following reset patch (PATCH v3 14/16), point 3 here should
be updated ore removed.

> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> ---
> v3: eliminated recalc routines for pll and leaf clocks
> v3: stripped "clk_" prefix from clock names
> v3: use newly added div_ratio_mask functionality (earlier in this series)
> v3: move from fixed_ioremap to __davinci_ioremap() implementation (earlier in
>     this series
>
>  arch/arm/mach-davinci/Kconfig             |    5 +
>  arch/arm/mach-davinci/Makefile            |    1 +
>  arch/arm/mach-davinci/devices-tnetv107x.c |  128 ++++
>  arch/arm/mach-davinci/tnetv107x.c         | 1175 +++++++++++++++++++++++++++++
>  4 files changed, 1309 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-davinci/devices-tnetv107x.c
>  create mode 100644 arch/arm/mach-davinci/tnetv107x.c
>
> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> index 0316e20..a67b47b 100644
> --- a/arch/arm/mach-davinci/Kconfig
> +++ b/arch/arm/mach-davinci/Kconfig
> @@ -50,6 +50,11 @@ config ARCH_DAVINCI_DM365
>  	select AINTC
>  	select ARCH_DAVINCI_DMx
>  
> +config ARCH_DAVINCI_TNETV107X
> +	select CPU_V6
> +	select CP_INTC
> +	bool "TNETV107X based system"
> +
>  comment "DaVinci Board Type"
>  
>  config MACH_DAVINCI_EVM
> diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
> index 6aac880..1c7bcfe 100644
> --- a/arch/arm/mach-davinci/Makefile
> +++ b/arch/arm/mach-davinci/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_ARCH_DAVINCI_DM646x)       += dm646x.o devices.o
>  obj-$(CONFIG_ARCH_DAVINCI_DM365)	+= dm365.o devices.o
>  obj-$(CONFIG_ARCH_DAVINCI_DA830)        += da830.o devices-da8xx.o
>  obj-$(CONFIG_ARCH_DAVINCI_DA850)        += da850.o devices-da8xx.o
> +obj-$(CONFIG_ARCH_DAVINCI_TNETV107X)    += tnetv107x.o devices-tnetv107x.o
>  
>  obj-$(CONFIG_AINTC)			+= irq.o
>  obj-$(CONFIG_CP_INTC)			+= cp_intc.o
> diff --git a/arch/arm/mach-davinci/devices-tnetv107x.c b/arch/arm/mach-davinci/devices-tnetv107x.c
> new file mode 100644
> index 0000000..ab54c91
> --- /dev/null
> +++ b/arch/arm/mach-davinci/devices-tnetv107x.c
> @@ -0,0 +1,128 @@
> +/*
> + * TI TNETV107X platform devices
> + *
> + * Author: Cyril Chemparathy <cyril at ti.com>
> + *
> + * 2009 (c) Texas Instruments, Inc. This file is licensed under

2010?  same for all the new files added.

> + * the terms of the GNU General Public License version 2. This program
> + * is licensed "as is" without any warranty of any kind, whether express
> + * or implied.
> + */
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/platform_device.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/clk.h>
> +
> +#include <mach/common.h>
> +#include <mach/irqs.h>
> +#include <mach/edma.h>
> +#include <mach/serial.h>
> +#include <mach/tnetv107x.h>
> +
> +#include "clock.h"
> +
> +/* Base addresses for on-chip devices */
> +#define TNETV107X_TPCC_BASE			0x01c00000
> +#define TNETV107X_TPTC0_BASE			0x01c10000
> +#define TNETV107X_TPTC1_BASE			0x01c10400
> +
> +/* TNETV107X specific EDMA3 information */
> +#define EDMA_TNETV107X_NUM_DMACH	64
> +#define EDMA_TNETV107X_NUM_TCC		64
> +#define EDMA_TNETV107X_NUM_PARAMENTRY	128
> +#define EDMA_TNETV107X_NUM_EVQUE	2
> +#define EDMA_TNETV107X_NUM_TC		2
> +#define EDMA_TNETV107X_CHMAP_EXIST	0
> +#define EDMA_TNETV107X_NUM_REGIONS	4
> +#define TNETV107X_DMACH2EVENT_MAP0	0x3C0CE000u
> +#define TNETV107X_DMACH2EVENT_MAP1	0x000FFFFFu
> +
> +static const s8 edma_tc_mapping[][2] = {
> +	/* event queue no	TC no	*/
> +	{	 0,		 0	},
> +	{	 1,		 1	},
> +	{	-1,		-1	}
> +};
> +
> +static const s8 edma_priority_mapping[][2] = {
> +	/* event queue no	Prio	*/
> +	{	 0,		 3	},
> +	{	 1,		 7	},
> +	{	-1,		-1	}
> +};
> +
> +static struct edma_soc_info edma_info[] = {
> +	{
> +		.n_channel		= EDMA_TNETV107X_NUM_DMACH,
> +		.n_region		= EDMA_TNETV107X_NUM_REGIONS,
> +		.n_slot			= EDMA_TNETV107X_NUM_PARAMENTRY,
> +		.n_tc			= EDMA_TNETV107X_NUM_TC,
> +		.n_cc			= 1,
> +		.queue_tc_mapping	= edma_tc_mapping,
> +		.queue_priority_mapping	= edma_priority_mapping,
> +	},
> +};
> +
> +static struct resource edma_resources[] = {
> +	{
> +		.name	= "edma_cc0",
> +		.start	= TNETV107X_TPCC_BASE,
> +		.end	= TNETV107X_TPCC_BASE + SZ_32K - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	{
> +		.name	= "edma_tc0",
> +		.start	= TNETV107X_TPTC0_BASE,
> +		.end	= TNETV107X_TPTC0_BASE + SZ_1K - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	{
> +		.name	= "edma_tc1",
> +		.start	= TNETV107X_TPTC1_BASE,
> +		.end	= TNETV107X_TPTC1_BASE + SZ_1K - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	{
> +		.name	= "edma0",
> +		.start	= IRQ_TNETV107X_TPCC,
> +		.flags	= IORESOURCE_IRQ,
> +	},
> +	{
> +		.name	= "edma0_err",
> +		.start	= IRQ_TNETV107X_TPCC_ERR,
> +		.flags	= IORESOURCE_IRQ,
> +	},
> +};
> +
> +static struct platform_device edma_device = {
> +	.name		= "edma",
> +	.id		= -1,
> +	.num_resources	= ARRAY_SIZE(edma_resources),
> +	.resource	= edma_resources,
> +	.dev.platform_data = edma_info,
> +};
> +
> +void __init tnetv107x_edma_init(void)
> +{
> +	platform_device_register(&edma_device);
> +}
> +
> +void __init tnetv107x_serial_init(struct plat_serial8250_port* ports)
> +{
> +	int i;
> +	char name[16];
> +	struct clk *uart_clk;
> +
> +	for (i = 0; ports[i].flags; i++) {
> +		sprintf(name, "uart%d", i);
> +		uart_clk = clk_get(NULL, name);
> +		if (IS_ERR(uart_clk))
> +			printk(KERN_ERR "%s:%d: failed to get UART%d clock\n",
> +					__func__, __LINE__, i);

pr_err()

> +		else {
> +			clk_enable(uart_clk);
> +			ports[i].uartclk = clk_get_rate(uart_clk);
> +		}

CodingStyle.  If one part of an if/else uses {} the others should too.


> +	}
> +}
> diff --git a/arch/arm/mach-davinci/tnetv107x.c b/arch/arm/mach-davinci/tnetv107x.c
> new file mode 100644
> index 0000000..a444ef7
> --- /dev/null
> +++ b/arch/arm/mach-davinci/tnetv107x.c
> @@ -0,0 +1,1175 @@
> +/*
> + * TI TNETV107X chip specific setup
> + *
> + * Author: Cyril Chemparathy <cyril at ti.com>
> + *
> + * 2009 (c) Texas Instruments, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This program
> + * is licensed "as is" without any warranty of any kind, whether express
> + * or implied.
> + */
> +
> +/*
> + * TNETV107X clock control implementation doesn't (at this point) reuse
> + * much of Davinci's generic implementation. This is because of the
> + * SSPLL nastiness that is present on this part.
> + */

This comment seems misplaced.  Maybe should be in with the clock code?

Also, the "at this point" captures my attention.  Do you have plans to
make it use the generic implementation?  Looking closer, it looks like
you're mostly using the generic implementation, with only recalc
override for the SSPLL-based clocks.  Maybe this comment just needs an
update?

> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +
> +#include <asm/mach/map.h>
> +
> +#include <mach/common.h>
> +#include <mach/time.h>
> +#include <mach/cputype.h>
> +#include <mach/psc.h>
> +#include <mach/cp_intc.h>
> +#include <mach/irqs.h>
> +#include <mach/hardware.h>
> +#include <mach/tnetv107x.h>
> +
> +#include "clock.h"
> +#include "mux.h"
> +
> +/* Base addresses for on-chip devices */
> +#define TNETV107X_INTC_BASE			0x03000000
> +#define TNETV107X_TIMER0_BASE			0x08086500
> +#define TNETV107X_TIMER1_BASE			0x08086600
> +#define TNETV107X_CHIP_CFG_BASE			0x08087000
> +#define TNETV107X_CLOCK_CONTROL_BASE		0x0808a000
> +#define TNETV107X_PSC_BASE			0x0808b000
> +
> +/* Reference clock frequencies */
> +#define OSC_FREQ_ONCHIP		(24000 * 1000)
> +#define OSC_FREQ_OFFCHIP_SYS	(25000 * 1000)
> +#define OSC_FREQ_OFFCHIP_ETH	(25000 * 1000)
> +#define OSC_FREQ_OFFCHIP_TDM	(19200 * 1000)
> +
> +/* PLL Types */
> +enum pll_type {
> +	SYS_PLL,
> +	TDM_PLL,
> +	ETH_PLL,
> +	N_PLLS
> +};
> +
> +/* Clock Control Registers */
> +struct clk_ctrl_regs {
> +	u32	pll_bypass;
> +	u32	_reserved0;
> +	u32	gem_lrst;
> +	u32	_reserved1;
> +	u32	pll_unlock_stat;
> +	u32	sys_unlock;
> +	u32	eth_unlock;
> +	u32	tdm_unlock;
> +};
> +
> +/* SSPLL Registers */
> +struct sspll_regs {
> +	u32	modes;
> +	u32	post_div;
> +	u32	pre_div;
> +	u32	mult_factor;
> +	u32	divider_range;
> +	u32	bw_divider;
> +	u32	spr_amount;
> +	u32	spr_rate_div;
> +	u32	diag;
> +};
> +
> +static struct clk_ctrl_regs __iomem *clk_ctrl_regs;
> +
> +static struct sspll_regs __iomem *sspll_regs[N_PLLS];
> +static int sspll_regs_base[N_PLLS] = { 0x40, 0x80, 0xc0 };
> +
> +/* PLL Control Registers (same as in Davinci) */
> +static void __iomem *pllctl_regs[N_PLLS];
> +static int pllctl_regs_base[N_PLLS] = { 0x600, 0x200, 0x400 };
> +
> +/* PLL bypass bit shifts in clk_ctrl_regs->pll_bypass register */
> +static u32 bypass_mask[N_PLLS] = { BIT(0), BIT(2), BIT(1) };
> +
> +/* offchip (external) reference clock frequencies */
> +static u32 pll_ext_freq[] = {
> +	OSC_FREQ_OFFCHIP_SYS,
> +	OSC_FREQ_OFFCHIP_TDM,
> +	OSC_FREQ_OFFCHIP_ETH
> +};
> +
> +/* PSC control registers */
> +static void __iomem *psc_regs[1];
> +
> +/* Host map for interrupt controller */
> +static u32 intc_host_map[] = { 0x01010000, 0x01010101, -1 };
> +
> +static unsigned long clk_sspll_recalc(struct clk *clk);
> +
> +static struct pll_data pll_sys_data = {
> +	.num		= SYS_PLL,
> +	.div_ratio_mask	= 0x1ff,
> +};
> +
> +static struct pll_data pll_eth_data = {
> +	.num		= ETH_PLL,
> +	.div_ratio_mask	= 0xff,
> +};
> +
> +static struct pll_data pll_tdm_data = {
> +	.num		= TDM_PLL,
> +	.div_ratio_mask	= 0xff,
> +};
> +
> +/* Top level of the clock tree - the PLLs */
> +static struct clk pll_sys_clk = {
> +	.name		= "pll_sys",
> +	.pll_data	= &pll_sys_data,
> +	.flags		= CLK_PLL,
> +	.recalc		= clk_sspll_recalc,
> +};
> +
> +static struct clk pll_eth_clk = {
> +	.name		= "pll_eth",
> +	.pll_data	= &pll_eth_data,
> +	.flags		= CLK_PLL,
> +	.recalc		= clk_sspll_recalc,
> +};
> +
> +static struct clk pll_tdm_clk = {
> +	.name		= "pll_tdm",
> +	.pll_data	= &pll_tdm_data,
> +	.flags		= CLK_PLL,
> +	.recalc		= clk_sspll_recalc,
> +};
> +
> +
> +/* System PLL Dividers */
> +static struct clk sys_arm1176_clk = {
> +	.name		= "sys_arm1176_clk",
> +	.parent		= &pll_sys_clk,
> +	.flags		= CLK_PLL,
> +	.div_reg	= PLLDIV1,
> +};
> +
> +static struct clk sys_dsp_clk = {
> +	.name		= "sys_dsp_clk",
> +	.parent		= &pll_sys_clk,
> +	.flags		= CLK_PLL,
> +	.div_reg	= PLLDIV2,
> +};
> +
> +static struct clk sys_ddr_clk = {
> +	.name		= "sys_ddr_clk",
> +	.parent		= &pll_sys_clk,
> +	.flags		= CLK_PLL,
> +	.div_reg	= PLLDIV3,
> +};
> +
> +static struct clk sys_full_clk = {
> +	.name		= "sys_full_clk",
> +	.parent		= &pll_sys_clk,
> +	.flags		= CLK_PLL,
> +	.div_reg	= PLLDIV4,
> +};
> +
> +static struct clk sys_lcd_clk = {
> +	.name		= "sys_lcd_clk",
> +	.parent		= &pll_sys_clk,
> +	.flags		= CLK_PLL,
> +	.div_reg	= PLLDIV5,
> +};
> +
> +static struct clk sys_vlynq_ref_clk = {
> +	.name		= "sys_vlynq_ref_clk",
> +	.parent		= &pll_sys_clk,
> +	.flags		= CLK_PLL,
> +	.div_reg	= PLLDIV6,
> +};
> +
> +static struct clk sys_tsc_clk = {
> +	.name		= "sys_tsc_clk",
> +	.parent		= &pll_sys_clk,
> +	.flags		= CLK_PLL,
> +	.div_reg	= PLLDIV7,
> +};
> +
> +static struct clk sys_half_clk = {
> +	.name		= "sys_half_clk",
> +	.parent		= &pll_sys_clk,
> +	.flags		= CLK_PLL,
> +	.div_reg	= PLLDIV8,
> +};
> +
> +
> +/* Ethernet PLL Dividers */
> +static struct clk eth_clk_5 = {
> +	.name		= "eth_clk_5",
> +	.parent		= &pll_eth_clk,
> +	.flags		= CLK_PLL,
> +	.div_reg	= PLLDIV1,
> +};
> +
> +static struct clk eth_clk_50 = {
> +	.name		= "eth_clk_50",
> +	.parent		= &pll_eth_clk,
> +	.flags		= CLK_PLL,
> +	.div_reg	= PLLDIV2,
> +};
> +
> +static struct clk eth_clk_125 = {
> +	.name		= "eth_clk_125",
> +	.parent		= &pll_eth_clk,
> +	.flags		= CLK_PLL,
> +	.div_reg	= PLLDIV3,
> +};
> +
> +static struct clk eth_clk_250 = {
> +	.name		= "eth_clk_250",
> +	.parent		= &pll_eth_clk,
> +	.flags		= CLK_PLL,
> +	.div_reg	= PLLDIV4,
> +};
> +
> +static struct clk eth_clk_25 = {
> +	.name		= "eth_clk_25",
> +	.parent		= &pll_eth_clk,
> +	.flags		= CLK_PLL,
> +	.div_reg	= PLLDIV5,
> +};
> +
> +
> +/* TDM PLL Dividers */
> +static struct clk tdm_0_clk = {
> +	.name		= "tdm_0_clk",
> +	.parent		= &pll_tdm_clk,
> +	.flags		= CLK_PLL,
> +	.div_reg	= PLLDIV1,
> +};
> +
> +static struct clk tdm_extra_clk = {
> +	.name		= "tdm_extra_clk",
> +	.parent		= &pll_tdm_clk,
> +	.flags		= CLK_PLL,
> +	.div_reg	= PLLDIV2,
> +};
> +
> +static struct clk tdm_1_clk = {
> +	.name		= "tdm_1_clk",
> +	.parent		= &pll_tdm_clk,
> +	.flags		= CLK_PLL,
> +	.div_reg	= PLLDIV3,
> +};
> +
> +
> +/* LPSC Gated Clocks */
> +static struct clk clk_arm = {
> +	.name		= "arm",
> +	.parent		= &sys_arm1176_clk,
> +	.lpsc		= TNETV107X_LPSC_ARM,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk clk_gem = {
> +	.name		= "gem",
> +	.parent		= &sys_dsp_clk,
> +	.lpsc		= TNETV107X_LPSC_GEM,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk clk_ddr2_phy = {
> +	.name		= "ddr2_phy",
> +	.parent		= &sys_ddr_clk,
> +	.lpsc		= TNETV107X_LPSC_DDR2_PHY,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk clk_tpcc = {
> +	.name		= "tpcc",
> +	.parent		= &sys_full_clk,
> +	.lpsc		= TNETV107X_LPSC_TPCC,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk clk_tptc0 = {
> +	.name		= "tptc0",
> +	.parent		= &sys_full_clk,
> +	.lpsc		= TNETV107X_LPSC_TPTC0,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk clk_tptc1 = {
> +	.name		= "tptc1",
> +	.parent		= &sys_full_clk,
> +	.lpsc		= TNETV107X_LPSC_TPTC1,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk clk_ram = {
> +	.name		= "ram",
> +	.parent		= &sys_full_clk,
> +	.lpsc		= TNETV107X_LPSC_RAM,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk clk_mbx_lite = {
> +	.name		= "mbx_lite",
> +	.parent		= &sys_arm1176_clk,
> +	.lpsc		= TNETV107X_LPSC_MBX_LITE,
> +};
> +
> +static struct clk clk_lcd = {
> +	.name		= "lcd",
> +	.parent		= &sys_lcd_clk,
> +	.lpsc		= TNETV107X_LPSC_LCD,
> +	.flags		= PSC_SWRSTDISABLE,
> +};
> +
> +static struct clk clk_ethss = {
> +	.name		= "ethss",
> +	.parent		= &eth_clk_125,
> +	.lpsc		= TNETV107X_LPSC_ETHSS,
> +};
> +
> +static struct clk clk_aemif = {
> +	.name		= "aemif",
> +	.parent		= &sys_full_clk,
> +	.lpsc		= TNETV107X_LPSC_AEMIF,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk clk_chip_cfg = {
> +	.name		= "chip_cfg",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_CHIP_CFG,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk clk_tsc = {
> +	.name		= "tsc",
> +	.parent		= &sys_tsc_clk,
> +	.lpsc		= TNETV107X_LPSC_TSC,
> +};
> +
> +static struct clk clk_rom = {
> +	.name		= "rom",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_ROM,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk clk_uart2 = {
> +	.name		= "uart2",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_UART2,
> +};
> +
> +static struct clk clk_pktsec = {
> +	.name		= "pktsec",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_PKTSEC,
> +};
> +
> +static struct clk clk_rng = {
> +	.name		= "rng",
> +	.parent		= &clk_pktsec,
> +};
> +
> +static struct clk clk_pka = {
> +	.name		= "pka",
> +	.parent		= &clk_pktsec,
> +};
> +
> +static struct clk clk_secctl = {
> +	.name		= "secctl",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_SECCTL,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk clk_keymgr = {
> +	.name		= "keymgr",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_KEYMGR,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk clk_keypad = {
> +	.name		= "keypad",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_KEYPAD,
> +};
> +
> +static struct clk clk_gpio = {
> +	.name		= "gpio",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_GPIO,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk clk_mdio = {
> +	.name		= "mdio",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_MDIO,
> +};
> +
> +static struct clk clk_sdio0 = {
> +	.name		= "sdio0",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_SDIO0,
> +};
> +
> +static struct clk clk_uart0 = {
> +	.name		= "uart0",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_UART0,
> +};
> +
> +static struct clk clk_uart1 = {
> +	.name		= "uart1",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_UART1,
> +};
> +
> +static struct clk clk_timer0 = {
> +	.name		= "timer0",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_TIMER0,
> +};
> +
> +static struct clk clk_timer1 = {
> +	.name		= "timer1",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_TIMER1,
> +};
> +
> +static struct clk clk_wdt_arm = {
> +	.name		= "wdt_arm",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_WDT_ARM,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk clk_wdt_dsp = {
> +	.name		= "wdt_dsp",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_WDT_DSP,
> +};
> +
> +static struct clk clk_ssp = {
> +	.name		= "ssp",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_SSP,
> +};
> +
> +static struct clk clk_tdm0 = {
> +	.name		= "tdm0",
> +	.parent		= &tdm_0_clk,
> +	.lpsc		= TNETV107X_LPSC_TDM0,
> +};
> +
> +static struct clk clk_vlynq = {
> +	.name		= "vlynq",
> +	.parent		= &sys_vlynq_ref_clk,
> +	.lpsc		= TNETV107X_LPSC_VLYNQ,
> +};
> +
> +static struct clk clk_mcdma = {
> +	.name		= "mcdma",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_MCDMA,
> +};
> +
> +static struct clk clk_usb0 = {
> +	.name		= "usb0",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_USB0,
> +};
> +
> +static struct clk clk_tdm1 = {
> +	.name		= "tdm1",
> +	.parent		= &tdm_1_clk,
> +	.lpsc		= TNETV107X_LPSC_TDM1,
> +};
> +
> +static struct clk clk_debugss = {
> +	.name		= "debugss",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_DEBUGSS,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk clk_ethss_rgmii = {
> +	.name		= "ethss_rgmii",
> +	.parent		= &eth_clk_250,
> +	.lpsc		= TNETV107X_LPSC_ETHSS_RGMII,
> +};
> +
> +static struct clk clk_system = {
> +	.name		= "system",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_SYSTEM,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk clk_imcop = {
> +	.name		= "imcop",
> +	.parent		= &sys_dsp_clk,
> +	.lpsc		= TNETV107X_LPSC_IMCOP,
> +};
> +
> +static struct clk clk_spare = {
> +	.name		= "spare",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_SPARE,
> +};
> +
> +static struct clk clk_sdio1 = {
> +	.name		= "sdio1",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_SDIO1,
> +};
> +
> +static struct clk clk_usb1 = {
> +	.name		= "usb1",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_USB1,
> +};
> +
> +static struct clk clk_usbss = {
> +	.name		= "usbss",
> +	.parent		= &sys_half_clk,
> +	.lpsc		= TNETV107X_LPSC_USBSS,
> +};
> +
> +static struct clk clk_ddr2_vrst = {
> +	.name		= "ddr2_vrst",
> +	.parent		= &sys_ddr_clk,
> +	.lpsc		= TNETV107X_LPSC_DDR2_EMIF1_VRST,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk clk_ddr2_vctl_rst = {
> +	.name		= "ddr2_vctl_rst",
> +	.parent		= &sys_ddr_clk,
> +	.lpsc		= TNETV107X_LPSC_DDR2_EMIF2_VCTL_RST,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +
> +static struct clk_lookup tnetv107x_clks[] = {
> +	CLK(NULL,		"pll_sys_clk",		&pll_sys_clk),
> +	CLK(NULL,		"pll_eth_clk",		&pll_eth_clk),
> +	CLK(NULL,		"pll_tdm_clk",		&pll_tdm_clk),
> +	CLK(NULL,		"sys_arm1176_clk",	&sys_arm1176_clk),
> +	CLK(NULL,		"sys_dsp_clk",		&sys_dsp_clk),
> +	CLK(NULL,		"sys_ddr_clk",		&sys_ddr_clk),
> +	CLK(NULL,		"sys_full_clk",		&sys_full_clk),
> +	CLK(NULL,		"sys_lcd_clk",		&sys_lcd_clk),
> +	CLK(NULL,		"sys_vlynq_ref_clk",	&sys_vlynq_ref_clk),
> +	CLK(NULL,		"sys_tsc_clk",		&sys_tsc_clk),
> +	CLK(NULL,		"sys_half_clk",		&sys_half_clk),
> +	CLK(NULL,		"eth_clk_5",		&eth_clk_5),
> +	CLK(NULL,		"eth_clk_50",		&eth_clk_50),
> +	CLK(NULL,		"eth_clk_125",		&eth_clk_125),
> +	CLK(NULL,		"eth_clk_250",		&eth_clk_250),
> +	CLK(NULL,		"eth_clk_25",		&eth_clk_25),
> +	CLK(NULL,		"tdm_0_clk",		&tdm_0_clk),
> +	CLK(NULL,		"tdm_extra_clk",	&tdm_extra_clk),
> +	CLK(NULL,		"tdm_1_clk",		&tdm_1_clk),
> +	CLK(NULL,		"clk_arm",		&clk_arm),
> +	CLK(NULL,		"clk_gem",		&clk_gem),
> +	CLK(NULL,		"clk_ddr2_phy",		&clk_ddr2_phy),
> +	CLK(NULL,		"clk_tpcc",		&clk_tpcc),
> +	CLK(NULL,		"clk_tptc0",		&clk_tptc0),
> +	CLK(NULL,		"clk_tptc1",		&clk_tptc1),
> +	CLK(NULL,		"clk_ram",		&clk_ram),
> +	CLK(NULL,		"clk_mbx_lite",		&clk_mbx_lite),
> +	CLK("tnetv107x-fb.0",	NULL,			&clk_lcd),
> +	CLK(NULL,		"clk_ethss",		&clk_ethss),
> +	CLK(NULL,		"aemif",		&clk_aemif),
> +	CLK(NULL,		"clk_chip_cfg",		&clk_chip_cfg),
> +	CLK("tnetv107x-ts.0",	NULL,			&clk_tsc),
> +	CLK(NULL,		"clk_rom",		&clk_rom),
> +	CLK(NULL,		"uart2",		&clk_uart2),
> +	CLK(NULL,		"clk_pktsec",		&clk_pktsec),
> +	CLK("tnetv107x-rng.0",	NULL,			&clk_rng),
> +	CLK("tnetv107x-pka.0",	NULL,			&clk_pka),
> +	CLK(NULL,		"clk_secctl",		&clk_secctl),
> +	CLK(NULL,		"clk_keymgr",		&clk_keymgr),
> +	CLK("tnetv107x-keypad.0", NULL,			&clk_keypad),
> +	CLK(NULL,		"clk_gpio",		&clk_gpio),
> +	CLK(NULL,		"clk_mdio",		&clk_mdio),
> +	CLK("davinci_mmc.0",	NULL,			&clk_sdio0),
> +	CLK(NULL,		"uart0",		&clk_uart0),
> +	CLK(NULL,		"uart1",		&clk_uart1),
> +	CLK(NULL,		"timer0",		&clk_timer0),
> +	CLK(NULL,		"timer1",		&clk_timer1),
> +	CLK(NULL,		"clk_wdt_arm",		&clk_wdt_arm),
> +	CLK(NULL,		"clk_wdt_dsp",		&clk_wdt_dsp),
> +	CLK("ti-ssp.0",		NULL,			&clk_ssp),
> +	CLK(NULL,		"clk_tdm0",		&clk_tdm0),
> +	CLK(NULL,		"clk_vlynq",		&clk_vlynq),
> +	CLK(NULL,		"clk_mcdma",		&clk_mcdma),
> +	CLK(NULL,		"clk_usb0",		&clk_usb0),
> +	CLK(NULL,		"clk_tdm1",		&clk_tdm1),
> +	CLK(NULL,		"clk_debugss",		&clk_debugss),
> +	CLK(NULL,		"clk_ethss_rgmii",	&clk_ethss_rgmii),
> +	CLK(NULL,		"clk_system",		&clk_system),
> +	CLK(NULL,		"clk_imcop",		&clk_imcop),
> +	CLK(NULL,		"clk_spare",		&clk_spare),
> +	CLK("davinci_mmc.1",	NULL,			&clk_sdio1),
> +	CLK(NULL,		"clk_usb1",		&clk_usb1),
> +	CLK(NULL,		"clk_usbss",		&clk_usbss),
> +	CLK(NULL,		"clk_ddr2_vrst",	&clk_ddr2_vrst),
> +	CLK(NULL,		"clk_ddr2_vctl_rst",	&clk_ddr2_vctl_rst),
> +	CLK(NULL,		NULL,			NULL),
> +};
> +
> +static const struct mux_config tnetv107x_pins[] = {
> +#ifdef CONFIG_DAVINCI_MUX
> +	MUX_CFG(TNETV107X, ASR_A00,		0, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO32,		0, 0, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A01,		0, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO33,		0, 5, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A02,		0, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO34,		0, 10, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A03,		0, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO35,		0, 15, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A04,		0, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO36,		0, 20, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A05,		0, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO37,		0, 25, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A06,		1, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO38,		1, 0, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A07,		1, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO39,		1, 5, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A08,		1, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO40,		1, 10, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A09,		1, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO41,		1, 15, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A10,		1, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO42,		1, 20, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A11,		1, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, BOOT_STRP_0,		1, 25, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A12,		2, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, BOOT_STRP_1,		2, 0, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A13,		2, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO43,		2, 5, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A14,		2, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO44,		2, 10, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A15,		2, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO45,		2, 15, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A16,		2, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO46,		2, 20, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A17,		2, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO47,		2, 25, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_A18,		3, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO48,		3, 0, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, SDIO1_DATA3_0,	3, 0, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_A19,		3, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO49,		3, 5, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, SDIO1_DATA2_0,	3, 5, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_A20,		3, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO50,		3, 10, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, SDIO1_DATA1_0,	3, 10, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_A21,		3, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO51,		3, 15, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, SDIO1_DATA0_0,	3, 15, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_A22,		3, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO52,		3, 20, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, SDIO1_CMD_0,		3, 20, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_A23,		3, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO53,		3, 25, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, SDIO1_CLK_0,		3, 25, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_BA_1,		4, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO54,		4, 0, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, SYS_PLL_CLK,		4, 0, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_CS0,		4, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, ASR_CS1,		4, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, ASR_CS2,		4, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, TDM_PLL_CLK,		4, 15, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_CS3,		4, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, ETH_PHY_CLK,		4, 20, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, ASR_D00,		4, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO55,		4, 25, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_D01,		5, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO56,		5, 0, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_D02,		5, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO57,		5, 5, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_D03,		5, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO58,		5, 10, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_D04,		5, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO59_0,		5, 15, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_D05,		5, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO60_0,		5, 20, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_D06,		5, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO61_0,		5, 25, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_D07,		6, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO62_0,		6, 0, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_D08,		6, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO63_0,		6, 5, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_D09,		6, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO64_0,		6, 10, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_D10,		6, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, SDIO1_DATA3_1,	6, 15, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_D11,		6, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, SDIO1_DATA2_1,	6, 20, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_D12,		6, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, SDIO1_DATA1_1,	6, 25, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_D13,		7, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, SDIO1_DATA0_1,	7, 0, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_D14,		7, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, SDIO1_CMD_1,		7, 5, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_D15,		7, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, SDIO1_CLK_1,		7, 10, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_OE,		7, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, BOOT_STRP_2,		7, 15, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_RNW,		7, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO29_0,		7, 20, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_WAIT,		7, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO30_0,		7, 25, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_WE,		8, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, BOOT_STRP_3,		8, 0, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, ASR_WE_DQM0,		8, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO31,		8, 5, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, LCD_PD17_0,		8, 5, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, ASR_WE_DQM1,		8, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, ASR_BA0_0,		8, 10, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, VLYNQ_CLK,		9, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO14,		9, 0, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, LCD_PD19_0,		9, 0, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, VLYNQ_RXD0,		9, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO15,		9, 5, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, LCD_PD20_0,		9, 5, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, VLYNQ_RXD1,		9, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO16,		9, 10, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, LCD_PD21_0,		9, 10, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, VLYNQ_TXD0,		9, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO17,		9, 15, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, LCD_PD22_0,		9, 15, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, VLYNQ_TXD1,		9, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO18,		9, 20, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, LCD_PD23_0,		9, 20, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, SDIO0_CLK,		10, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO19,		10, 0, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, SDIO0_CMD,		10, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO20,		10, 5, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, SDIO0_DATA0,		10, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO21,		10, 10, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, SDIO0_DATA1,		10, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO22,		10, 15, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, SDIO0_DATA2,		10, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO23,		10, 20, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, SDIO0_DATA3,		10, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO24,		10, 25, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, EMU0,		11, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, EMU1,		11, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, RTCK,		12, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, TRST_N,		12, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, TCK,			12, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, TDI,			12, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, TDO,			12, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, TMS,			12, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, TDM1_CLK,		13, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, TDM1_RX,		13, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, TDM1_TX,		13, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, TDM1_FS,		13, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, KEYPAD_R0,		14, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, KEYPAD_R1,		14, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, KEYPAD_R2,		14, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, KEYPAD_R3,		14, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, KEYPAD_R4,		14, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, KEYPAD_R5,		14, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, KEYPAD_R6,		15, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO12,		15, 0, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, KEYPAD_R7,		15, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO10,		15, 5, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, KEYPAD_C0,		15, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, KEYPAD_C1,		15, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, KEYPAD_C2,		15, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, KEYPAD_C3,		15, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, KEYPAD_C4,		16, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, KEYPAD_C5,		16, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, KEYPAD_C6,		16, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO13,		16, 10, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, TEST_CLK_IN,		16, 10, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, KEYPAD_C7,		16, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO11,		16, 15, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, SSP0_0,		17, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, SCC_DCLK,		17, 0, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, LCD_PD20_1,		17, 0, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, SSP0_1,		17, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, SCC_CS_N,		17, 5, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, LCD_PD21_1,		17, 5, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, SSP0_2,		17, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, SCC_D,		17, 10, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, LCD_PD22_1,		17, 10, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, SSP0_3,		17, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, SCC_RESETN,		17, 15, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, LCD_PD23_1,		17, 15, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, SSP1_0,		18, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO25,		18, 0, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, UART2_CTS,		18, 0, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, SSP1_1,		18, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO26,		18, 5, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, UART2_RD,		18, 5, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, SSP1_2,		18, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO27,		18, 10, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, UART2_RTS,		18, 10, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, SSP1_3,		18, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO28,		18, 15, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, UART2_TD,		18, 15, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, UART0_CTS,		19, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, UART0_RD,		19, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, UART0_RTS,		19, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, UART0_TD,		19, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, UART1_RD,		19, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, UART1_TD,		19, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_AC_NCS,		20, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_HSYNC_RNW,	20, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_VSYNC_A0,	20, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_MCLK,		20, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD16_0,		20, 15, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, LCD_PCLK_E,		20, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD00,		20, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD01,		21, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD02,		21, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD03,		21, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD04,		21, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD05,		21, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD06,		21, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD07,		22, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD08,		22, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO59_1,		22, 5, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, LCD_PD09,		22, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO60_1,		22, 10, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, LCD_PD10,		22, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, ASR_BA0_1,		22, 15, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, GPIO61_1,		22, 15, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, LCD_PD11,		22, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO62_1,		22, 20, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, LCD_PD12,		22, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO63_1,		22, 25, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, LCD_PD13,		23, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO64_1,		23, 0, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, LCD_PD14,		23, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO29_1,		23, 5, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, LCD_PD15,		23, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO30_1,		23, 10, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, EINT0,		24, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO08,		24, 0, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, EINT1,		24, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, GPIO09,		24, 5, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, GPIO00,		24, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD20_2,		24, 10, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, TDM_CLK_IN_2,	24, 10, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, GPIO01,		24, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD21_2,		24, 15, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, 24M_CLK_OUT_1,	24, 15, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, GPIO02,		24, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD22_2,		24, 20, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, GPIO03,		24, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD23_2,		24, 25, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, GPIO04,		25, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD16_1,		25, 0, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, USB0_RXERR,		25, 0, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, GPIO05,		25, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD17_1,		25, 5, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, TDM_CLK_IN_1,	25, 5, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, GPIO06,		25, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD18,		25, 10, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, 24M_CLK_OUT_2,	25, 10, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, GPIO07,		25, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, LCD_PD19_1,		25, 15, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, USB1_RXERR,		25, 15, 0x1f, 0x0c, false)
> +	MUX_CFG(TNETV107X, ETH_PLL_CLK,		25, 15, 0x1f, 0x1c, false)
> +	MUX_CFG(TNETV107X, MDIO,		26, 0, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, MDC,			26, 5, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, AIC_MUTE_STAT_N,	26, 10, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, TDM0_CLK,		26, 10, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, AIC_HNS_EN_N,	26, 15, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, TDM0_FS,		26, 15, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, AIC_HDS_EN_STAT_N,	26, 20, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, TDM0_TX,		26, 20, 0x1f, 0x04, false)
> +	MUX_CFG(TNETV107X, AIC_HNF_EN_STAT_N,	26, 25, 0x1f, 0x00, false)
> +	MUX_CFG(TNETV107X, TDM0_RX,		26, 25, 0x1f, 0x04, false)
> +#endif
> +};
> +
> +/* FIQ are pri 0-1; otherwise 2-7, with 7 lowest priority */
> +static u8 tnetv107x_irq_prios[TNETV107X_N_CP_INTC_IRQ] = {
> +	[IRQ_TNETV107X_TDM1_TXDMA]		= 7,
> +	[IRQ_TNETV107X_EXT_INT_0]		= 7,
> +	[IRQ_TNETV107X_EXT_INT_1]		= 7,
> +	[IRQ_TNETV107X_GPIO_INT12]		= 7,
> +	[IRQ_TNETV107X_GPIO_INT13]		= 7,
> +	[IRQ_TNETV107X_TIMER_0_TINT12]		= 7,
> +	[IRQ_TNETV107X_TIMER_1_TINT12]		= 7,
> +	[IRQ_TNETV107X_UART0]			= 7,
> +	[IRQ_TNETV107X_TDM1_RXDMA]		= 7,
> +	[IRQ_TNETV107X_MCDMA_INT0]		= 7,
> +	[IRQ_TNETV107X_MCDMA_INT1]		= 7,
> +	[IRQ_TNETV107X_TPCC]			= 7,
> +	[IRQ_TNETV107X_TPCC_INT0]		= 7,
> +	[IRQ_TNETV107X_TPCC_INT1]		= 7,
> +	[IRQ_TNETV107X_TPCC_INT2]		= 7,
> +	[IRQ_TNETV107X_TPCC_INT3]		= 7,
> +	[IRQ_TNETV107X_TPTC0]			= 7,
> +	[IRQ_TNETV107X_TPTC1]			= 7,
> +	[IRQ_TNETV107X_TIMER_0_TINT34]		= 7,
> +	[IRQ_TNETV107X_ETHSS]			= 7,
> +	[IRQ_TNETV107X_TIMER_1_TINT34]		= 7,
> +	[IRQ_TNETV107X_DSP2ARM_INT0]		= 7,
> +	[IRQ_TNETV107X_DSP2ARM_INT1]		= 7,
> +	[IRQ_TNETV107X_ARM_NPMUIRQ]		= 7,
> +	[IRQ_TNETV107X_USB1]			= 7,
> +	[IRQ_TNETV107X_VLYNQ]			= 7,
> +	[IRQ_TNETV107X_UART0_DMATX]		= 7,
> +	[IRQ_TNETV107X_UART0_DMARX]		= 7,
> +	[IRQ_TNETV107X_TDM1_TXMCSP]		= 7,
> +	[IRQ_TNETV107X_SSP]			= 7,
> +	[IRQ_TNETV107X_MCDMA_INT2]		= 7,
> +	[IRQ_TNETV107X_MCDMA_INT3]		= 7,
> +	[IRQ_TNETV107X_TDM_CODECIF_EOT]		= 7,
> +	[IRQ_TNETV107X_IMCOP_SQR_ARM]		= 7,
> +	[IRQ_TNETV107X_USB0]			= 7,
> +	[IRQ_TNETV107X_USB_CDMA]		= 7,
> +	[IRQ_TNETV107X_LCD]			= 7,
> +	[IRQ_TNETV107X_KEYPAD]			= 7,
> +	[IRQ_TNETV107X_KEYPAD_FREE]		= 7,
> +	[IRQ_TNETV107X_RNG]			= 7,
> +	[IRQ_TNETV107X_PKA]			= 7,
> +	[IRQ_TNETV107X_TDM0_TXDMA]		= 7,
> +	[IRQ_TNETV107X_TDM0_RXDMA]		= 7,
> +	[IRQ_TNETV107X_TDM0_TXMCSP]		= 7,
> +	[IRQ_TNETV107X_TDM0_RXMCSP]		= 7,
> +	[IRQ_TNETV107X_TDM1_RXMCSP]		= 7,
> +	[IRQ_TNETV107X_SDIO1]			= 7,
> +	[IRQ_TNETV107X_SDIO0]			= 7,
> +	[IRQ_TNETV107X_TSC]			= 7,
> +	[IRQ_TNETV107X_TS]			= 7,
> +	[IRQ_TNETV107X_UART1]			= 7,
> +	[IRQ_TNETV107X_MBX_LITE]		= 7,
> +	[IRQ_TNETV107X_GPIO_INT00]		= 7,
> +	[IRQ_TNETV107X_GPIO_INT01]		= 7,
> +	[IRQ_TNETV107X_GPIO_INT02]		= 7,
> +	[IRQ_TNETV107X_GPIO_INT03]		= 7,
> +	[IRQ_TNETV107X_UART2]			= 7,
> +	[IRQ_TNETV107X_UART2_DMATX]		= 7,
> +	[IRQ_TNETV107X_UART2_DMARX]		= 7,
> +	[IRQ_TNETV107X_IMCOP_IMX]		= 7,
> +	[IRQ_TNETV107X_IMCOP_VLCD]		= 7,
> +	[IRQ_TNETV107X_AES]			= 7,
> +	[IRQ_TNETV107X_DES]			= 7,
> +	[IRQ_TNETV107X_SHAMD5]			= 7,
> +	[IRQ_TNETV107X_TPCC_ERR]		= 7,
> +	[IRQ_TNETV107X_TPCC_PROT]		= 7,
> +	[IRQ_TNETV107X_TPTC0_ERR]		= 7,
> +	[IRQ_TNETV107X_TPTC1_ERR]		= 7,
> +	[IRQ_TNETV107X_UART0_ERR]		= 7,
> +	[IRQ_TNETV107X_UART1_ERR]		= 7,
> +	[IRQ_TNETV107X_AEMIF_ERR]		= 7,
> +	[IRQ_TNETV107X_DDR_ERR]			= 7,
> +	[IRQ_TNETV107X_WDTARM_INT0]		= 7,
> +	[IRQ_TNETV107X_MCDMA_ERR]		= 7,
> +	[IRQ_TNETV107X_GPIO_ERR]		= 7,
> +	[IRQ_TNETV107X_MPU_ADDR]		= 7,
> +	[IRQ_TNETV107X_MPU_PROT]		= 7,
> +	[IRQ_TNETV107X_IOPU_ADDR]		= 7,
> +	[IRQ_TNETV107X_IOPU_PROT]		= 7,
> +	[IRQ_TNETV107X_KEYPAD_ADDR_ERR]		= 7,
> +	[IRQ_TNETV107X_WDT0_ADDR_ERR]		= 7,
> +	[IRQ_TNETV107X_WDT1_ADDR_ERR]		= 7,
> +	[IRQ_TNETV107X_CLKCTL_ADDR_ERR]		= 7,
> +	[IRQ_TNETV107X_PLL_UNLOCK]		= 7,
> +	[IRQ_TNETV107X_WDTDSP_INT0]		= 7,
> +	[IRQ_TNETV107X_SEC_CTRL_VIOLATION]	= 7,
> +	[IRQ_TNETV107X_KEY_MNG_VIOLATION]	= 7,
> +	[IRQ_TNETV107X_PBIST_CPU]		= 7,
> +	[IRQ_TNETV107X_WDTARM]			= 7,
> +	[IRQ_TNETV107X_PSC]			= 7,
> +	[IRQ_TNETV107X_MMC0]			= 7,
> +	[IRQ_TNETV107X_MMC1]			= 7,
> +};
> +
> +/* Contents of JTAG ID register used to identify exact cpu type */
> +static struct davinci_id tnetv107x_ids[] = {
> +	{
> +		.variant	= 0x0,
> +		.part_no	= 0xb8a1,
> +		.manufacturer	= 0x017,
> +		.cpu_id		= DAVINCI_CPU_ID_TNETV107X,
> +		.name		= "tnetv107x rev1.0",
> +	},
> +};
> +
> +static struct davinci_timer_instance tnetv107x_timer_instance[2] = {
> +	{
> +		.bottom_irq	= IRQ_TNETV107X_TIMER_0_TINT12,
> +		.top_irq	= IRQ_TNETV107X_TIMER_0_TINT34,
> +	},
> +	{
> +		.bottom_irq	= IRQ_TNETV107X_TIMER_1_TINT12,
> +		.top_irq	= IRQ_TNETV107X_TIMER_1_TINT34,
> +	},
> +};
> +
> +static struct davinci_timer_info tnetv107x_timer_info = {
> +	.timers		= tnetv107x_timer_instance,
> +	.clockevent_id	= T0_BOT,
> +	.clocksource_id	= T0_TOP,
> +};
> +
> +/*
> + * TNETV107X platforms do not use the static mappings from Davinci
> + * IO_PHYS/IO_VIRT. This SOC's interesting MMRs are at different addresses,
> + * and changing IO_PHYS would break away from existing Davinci SOCs.
> + *
> + * The primary impact of the current model is that IO_ADDRESS() is not to be
> + * used to map registers on TNETV107X. With the exception of early boot code
> + * in tnetv107x_init() (where fixed maps are necessary), all other pieces of
> + * code absolutely _must_ use ioremap().
> + *

I don't think the above comments are needed in the code, since none of
the platforms should be using IO_ADDRESS() anymore.  The existing uses
are legacy and are to be removed as well.

> + * 1.	The first section in here is specifically for edma, even through the
> + *	edma driver code properly ioremap()s its register space.  This is
> + *	because the edma MMRs on tnetv107x unfortunately fall within the
> + *	davinci IO_PHYS - (IO_PHYS + IO_SIZE) range, and therefore the edma
> + *	driver's ioremap() gets subverted by davinci_ioremap(). Yikes!
> + *
> + * 2.	The second chunk is for INTC - no major issues here.  If the cp_intc
> + *	code were to someday ioremap() internally, we could very well get rid
> + *	of this map.

Sounds like we need a little more cleanup.

As I proposed earlier, I think we need to separate out the IO mapping
from _common_init() and move it earlier.

We could then use your cpu_is_class* macros in there to catch the
common cases for dm* and da8xx (IO_PHYS/IO_VIRT etc.) but will still
allow SoCs to have custom io_desc tables if needed.

With this, we could probably get rid of the hacky way we're mapping
the INTC and the SYSCFG* bases on da8xx.

Kevin

> + * 3.	The third chunk maps in register areas that need to be populated into
> + *	davinci_soc_info.  Note that alignment restrictions come into play if
> + *	low-level debug is enabled (see note in <mach/tnetv107x.h>).
> + */
> +static struct map_desc tnetv107x_io_desc[] = {
> +	{	/* EDMA */
> +		.virtual	= IO_VIRT,
> +		.pfn		= __phys_to_pfn(IO_PHYS),
> +		.length		= SZ_128K,
> +		.type		= MT_DEVICE
> +	},
> +	{	/* INTC */
> +		.virtual	= IO_VIRT + SZ_128K,
> +		.pfn		= __phys_to_pfn(TNETV107X_INTC_BASE),
> +		.length		= SZ_16K,
> +		.type		= MT_DEVICE
> +	},
> +	{	/* Most of the rest */
> +		.virtual	= TNETV107X_IO_VIRT,
> +		.pfn		= __phys_to_pfn(TNETV107X_IO_BASE),
> +		.length		= IO_SIZE - SZ_1M,
> +		.type		= MT_DEVICE
> +	},
> +};
> +
> +static struct davinci_soc_info tnetv107x_soc_info = {
> +	.io_desc		= tnetv107x_io_desc,
> +	.io_desc_num		= ARRAY_SIZE(tnetv107x_io_desc),
> +	.ids			= tnetv107x_ids,
> +	.ids_num		= ARRAY_SIZE(tnetv107x_ids),
> +	.cpu_clks		= tnetv107x_clks,
> +	.psc_bases		= psc_regs,
> +	.psc_bases_num		= ARRAY_SIZE(psc_regs),
> +	.pinmux_pins		= tnetv107x_pins,
> +	.pinmux_pins_num	= ARRAY_SIZE(tnetv107x_pins),
> +	.intc_type		= DAVINCI_INTC_TYPE_CP_INTC,
> +	.intc_irq_prios		= tnetv107x_irq_prios,
> +	.intc_irq_num		= TNETV107X_N_CP_INTC_IRQ,
> +	.timer_info		= &tnetv107x_timer_info,
> +};
> +
> +#define tnetv107x_early_ioremap(p, s)				\
> +	__davinci_ioremap(p, s,					\
> +			tnetv107x_soc_info.io_desc,		\
> +			tnetv107x_soc_info.io_desc_num)
> +
> +void __init tnetv107x_init(void)
> +{
> +	void __iomem *tmp;
> +	int i;
> +
> +	/*
> +	 * Figure out virtual addresses for necessary peripherals, but do not
> +	 * access any of these here. iotable_init() needs to happen for the
> +	 * mappings to actually get setup
> +	 */
> +	clk_ctrl_regs = tmp =
> +		tnetv107x_early_ioremap(TNETV107X_CLOCK_CONTROL_BASE, SZ_4K);
> +
> +	for (i = 0; i < N_PLLS; i++) {
> +		sspll_regs[i] = tmp + sspll_regs_base[i];
> +		pllctl_regs[i] = tmp + pllctl_regs_base[i];
> +	}
> +
> +	pll_sys_data.base = pllctl_regs[SYS_PLL];
> +	pll_eth_data.base = pllctl_regs[ETH_PLL];
> +	pll_tdm_data.base = pllctl_regs[TDM_PLL];
> +
> +	psc_regs[0] = tnetv107x_early_ioremap(TNETV107X_PSC_BASE, SZ_4K);
> +
> +	tmp = tnetv107x_early_ioremap(TNETV107X_CHIP_CFG_BASE, SZ_4K);
> +	tnetv107x_soc_info.jtag_id_base	= tmp + 0x018;
> +	tnetv107x_soc_info.pinmux_base	= tmp + 0x150;
> +
> +	tnetv107x_soc_info.intc_base =
> +		tnetv107x_early_ioremap(TNETV107X_INTC_BASE, SZ_16K);
> +
> +	tnetv107x_timer_instance[0].base =
> +		tnetv107x_early_ioremap(TNETV107X_TIMER0_BASE, 0x100);
> +
> +	tnetv107x_timer_instance[1].base =
> +		tnetv107x_early_ioremap(TNETV107X_TIMER1_BASE, 0x100);
> +
> +	davinci_common_init(&tnetv107x_soc_info);
> +}
> +
> +void __init tnetv107x_irq_init(void)
> +{
> +	struct davinci_soc_info *soc_info = &davinci_soc_info;
> +
> +	cp_intc_init(soc_info->intc_base, soc_info->intc_irq_num,
> +			soc_info->intc_irq_prios, intc_host_map);
> +}
> +
> +static unsigned long clk_sspll_recalc(struct clk *clk)
> +{
> +	int		pll;
> +	unsigned long	mult = 0, prediv = 1, postdiv = 1;
> +	unsigned long	ref = OSC_FREQ_ONCHIP, ret;
> +	u32		tmp;
> +
> +	if (WARN_ON(!clk->pll_data))
> +		return clk->rate;
> +
> +	pll = clk->pll_data->num;
> +
> +	tmp = __raw_readl(&clk_ctrl_regs->pll_bypass);
> +	if (!(tmp & bypass_mask[pll])) {
> +		mult	= __raw_readl(&sspll_regs[pll]->mult_factor);
> +		prediv	= __raw_readl(&sspll_regs[pll]->pre_div) + 1;
> +		postdiv	= __raw_readl(&sspll_regs[pll]->post_div) + 1;
> +	}
> +
> +	tmp = __raw_readl(pllctl_regs[pll] + PLLCTL);
> +	if (tmp & PLLCTL_CLKMODE)
> +		ref = pll_ext_freq[pll];
> +
> +	clk->pll_data->input_rate = ref;
> +
> +	tmp = __raw_readl(pllctl_regs[pll] + PLLCTL);
> +	if (!(tmp & PLLCTL_PLLEN))
> +		return ref;
> +
> +	ret = ref;
> +	if (mult)
> +		ret += ((unsigned long long)ref * mult) / 256;
> +
> +	ret /= (prediv * postdiv);
> +
> +	return ret;
> +}
> -- 
> 1.6.3.3

From jaya.krishnan at samsung.com  Mon Apr 19 19:00:49 2010
From: jaya.krishnan at samsung.com (Jaya krishnan)
Date: Tue, 20 Apr 2010 00:00:49 +0000 (GMT)
Subject: HDMI    driver
Message-ID: <16155596.641811271721649667.JavaMail.weblogic@epml03>


 
Hi  all,
I  would  like  to know if montavista (either 4.0.1  or  5.0 versions ) lsp    supports HDMI .
If  not ,where  can I get  it?
I am using Silicon Image sil9134 in a  custom  board which  uses  DM6467.  
 
Thanks  in advance
Jayakrishnan


 
Jayakrishnan M M
Research Engineer
Key Systems Development Group
Security & Imaging Solutions Division
SAMSUNG TECHWIN CO.,LTD

TEL +82-2-3467-7403
FAX +82-2-3467-7316
Mobile +82-10-6409-3619
E-mail:jaya.krishnan at samsung.com
 
  

From Jon.Povey at racelogic.co.uk  Tue Apr 20 00:57:21 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Tue, 20 Apr 2010 06:57:21 +0100
Subject: DM355 JTAG reset without SRST?
Message-ID: <70E876B0EA86DD4BAF101844BC814DFE11C4EB73@Cloud.RL.local>

Hi all,

Trying to setup OpenOCD for use on DM355 using an Amontec JTAGKey-Tiny and the TI 14-pin JTAG header - which doesn't have SRST.

I need to write a routine for OpenOCD that writes some registers or whatever through JTAG to do a full reset of the DM355. Not done this kind of reset stuff before, I'm looking at the watchdog timer at the moment, but any suggestions?

Thanks,

--
Jon Povey
jon.povey at racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network



From nyhetsbrev at dokumera.anp.se  Tue Apr 20 01:25:08 2010
From: nyhetsbrev at dokumera.anp.se (DokuMera Nyhetsbrev)
Date: Tue, 20 Apr 2010 08:25:08 +0200
Subject: =?iso-8859-1?Q?Bolagsst=E4mma?=
Message-ID: <1256584939.1278@dokumera.anp.se>


Om du har problem med att l?sa detta e-postmeddelande, klicka h?r (http://www.anp.se/newsletter/648526/44405D4074454B5C447043475843) f?r en webb-version.

V?rt nyhetsbrev skickas automatiskt till v?ra kunder och intressenter. Vill du inte ha detta nyhetsbrev fram?ver, klicka h?r f?r att avprenumerera (http://www.anp.se/oa/648526/44405D4074454B5C447043475843).

Nyhetsbrev nr 15/2010Detta nyhetsbrev ?r skickat till: davinci-linux-open-source at linux.davincidsp.com


(http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se&from=173902333&prefix=dm) (http://www.anp.se/taf/648526/44405D4074454B5C447043475843)  (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_newsletters.asp&from=173902333&prefix=dm)  (http://www.anp.se/newsletter.asp?sqid=648526&sid=44405D4074454B5C447043475843&print=true)


Bolagsst?mma (http://www.dokumera.se/arsstamma_1452_dc.html?source=email)

En bolagsst?mma eller ?rsst?mma ?r ett bolags h?gsta beslutande organ och det forum d?r aktie?garen kan ut?va sitt inflytande. I ett aktiebolag ska aktie?garna samlas minst en g?ng om ?ret, men bolagsordningen kan f?reskriva att det ska h?llas flera ordinarie bolagsst?mmor per ?r.

?rsst?mma ?r ben?mningen p? den ordinarie bolagsst?mman d?r styrelsen ska l?gga fram ?rsredovisningen och revisionsber?ttelsen. ?rsst?mman ska h?llas inom sex m?nader fr?n utg?ngen av varje r?kenskaps?r. Bolagsst?mma som inte ?r ordinarie st?mma kallas extra bolagsst?mma. En ?ndring av bolagsordningen kan med f?rdel g?ras vid ?rsst?mman.

Hos DokuMera finner du bland annat mallar f?r utformning av dagordning f?r ?rsst?mma liksom f?r fullmakt f?r annan att deltaga p? bolagsst?mma.


Veckans dokument

Disponibla vinstmedel
Kallelse ?rsst?mma (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/kallelse_arsstamma_disponibla_vinstmedel_509_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm) >>

Dagordning ?rsst?mma >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/dagordning_arsstamma_disponibla_vinstmedel_600_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Protokoll ?rsst?mma >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/protokoll_arsstamma_disponibla_vinstmedel_526_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Ansamlad f?rlust
Kallelse ?rsst?mma >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/kallelse_arsstamma_ansamlad_forlust_601_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Dagordning ?rsst?mma >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/dagordning_arsstamma_ansamlad_forlust_599_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Protokoll ?rsst?mma >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/protokoll_arsstamma_ansamlad_forlust_522_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Bolagsordning
Bolagsordning privat >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/bolagsordning_privat_462_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Checklista bolagsordning privat >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/checklista_bolagsordning_privat_2165_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)


Veckans expertsvar

Vad ?r en bolagsst?mma? >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/expertsvar/vad_ar_en_bolagsstamma_1621_ad.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Var skall en bolagsst?mma h?llas? >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/expertsvar/var_skall_en_bolagsstamma_hallas_1622_ad.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Hur sker kallelse till en bolagsst?mma? >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/expertsvar/hur_sker_kallelse_till_en_bolagsstamma_1623_ad.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Vem har r?tt att delta i en 
bolagsst?mma? >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/expertsvar/vem_har_ratt_att_delta_i_en_bolagsstamma_1624_ad.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Hur fattas ett beslut p? st?mman? >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/expertsvar/hur_fattas_ett_beslut_pa_stamman_1625_ad.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

(http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/foretagspaketet_1321_dc.html&from=173902333&prefix=dm) (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_atq_ppdviewer.asp&from=173902333&prefix=dm) (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/styckvisa_dokumentmallar_1330_dc.html&from=173902333&prefix=dm)

 (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_contactusmessage.asp&from=173902333&prefix=dm)

F?r en kostnadsfri exklusiv presentation av hur DokuMera kan spara tiotusentals kronor ?t just mitt f?retag.
Givetvis ?r du varmt v?lkommen att ringa oss p? 08-664 04 50.

Inneh?llet i nyhetsbrev ska inte tolkas som ett ?tagande fr?n DokuMeras sida. Informationen s?nds ut i befintligt skick, utan garantier och digitala signaturer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100420/0cddcec6/attachment-0001.html>

From lamiaposta71 at gmail.com  Tue Apr 20 03:00:57 2010
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Tue, 20 Apr 2010 10:00:57 +0200
Subject: dm365 - voice codec
In-Reply-To: <1271086922.4697.4126.camel@sax-lx>
References: <j2tade1bdc1004010931v440aa4fdz97de74bbb8c7ca25@mail.gmail.com>
	<u2nade1bdc1004120536w79762aa5t675b016e6b0a3248@mail.gmail.com>
	<1271086922.4697.4126.camel@sax-lx>
Message-ID: <o2vade1bdc1004200100mbd3fd0c7jb1b302b10e2cecb4@mail.gmail.com>

2010/4/12 Todd Fischer <todd.fischer at ridgerun.com>

>  Hi Raffaele,
>
> Miguel posted a patch to add voice codec to alsa-devel at alsa-project.org on
> March 9th.
>
> For DM365, you can either use external or built-in voice codec, but not
> both in a general way at the same time.  There is also some limitations in
> ALSA that make exposing both in a general way not possible (I don't recall
> the details).
>
> If you just want to use the built-in voice codec and not an external AIC
> chip, Miguel's patches should meet your needs.
>
> Todd
>

I cherry-pick Miguel Aguilar CQ93VC and AIC3X support and I tested rec and
play using arago_demo_image.
Here you are what I've added to my 2.6.34-rc1 tree from for-2.6.35 branch of
http://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git .

Author: Tejun Heo <tj at kernel.org>
Date:   Tue Mar 30 02:52:40 2010 +0900

Author: Miguel Aguilar <miguel.aguilar at ridgerun.com>
Date:   Thu Mar 11 09:32:21 2010 -0600

Author: Miguel Aguilar <miguel.aguilar at ridgerun.com>
Date:   Thu Mar 11 09:32:59 2010 -0600

Author: Miguel Aguilar <miguel.aguilar at ridgerun.com>
Date:   Thu Mar 11 09:32:42 2010 -0600

It works nice.
I have to verify the sound quality in recording and playback.
I was trying to amplify SPP/SPN output, but it seems they have the same
volume regulation of LINE OUT.

Thank you very much,
Raffaele.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100420/3d68b40c/attachment.html>

From khilman at deeprootsystems.com  Tue Apr 20 10:17:00 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Tue, 20 Apr 2010 08:17:00 -0700
Subject: [PATCH 1/4] DM365: Make all SPI units SPI0..SPI4 available
In-Reply-To: <1270738918-30050-3-git-send-email-thomas.koeller@baslerweb.com>
	(thomas koeller's message of "Thu\, 8 Apr 2010 17\:01\:55 +0200")
References: <1270738918-30050-1-git-send-email-thomas.koeller@baslerweb.com>
	<1270738918-30050-3-git-send-email-thomas.koeller@baslerweb.com>
Message-ID: <87ochekvbn.fsf@deeprootsystems.com>

thomas.koeller at baslerweb.com writes:

> From: Thomas Koeller <thomas.koeller at baslerweb.com>
>
> Change the SPI setup code to allow use of all SPI units. Also,
> move some resource assignments (DMA channels, interrupts)
> to the board code, where they belong. These really should not
> be hard-coded in dm365.c.
>
> Signed-off-by: Thomas Koeller <thomas.koeller at baslerweb.com>

Looks like a good reorg and cleanup.  I like the generalizing, Thanks.
Some specific comments below, but first some general comments:

Please run your patches through scripts/checkpatch.pl and fix the
errors warnings there.

Also, when fixing up dm365, could you do the same for dm355?  If you
don't have a dm355, others here can help test.  

With your cleanups, we can probably combine the dm355 and dm365 code
into common code.

> ---
>  arch/arm/mach-davinci/board-dm365-evm.c           |   37 +++-
>  arch/arm/mach-davinci/board_dm365_evm_resources.h |   17 ++
>  arch/arm/mach-davinci/dm365.c                     |  278 +++++++++++++++++----
>  arch/arm/mach-davinci/include/mach/dm365.h        |   16 +-
>  4 files changed, 293 insertions(+), 55 deletions(-)
>  create mode 100644 arch/arm/mach-davinci/board_dm365_evm_resources.h
>
> diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
> index ab3b0e2..6797d3e 100644
> --- a/arch/arm/mach-davinci/board-dm365-evm.c
> +++ b/arch/arm/mach-davinci/board-dm365-evm.c
> @@ -49,6 +49,8 @@
>  #include <media/tvp7002.h>
>  #include <media/davinci/videohd.h>
>  
> +#include "board_dm365_evm_resources.h"
> +
>  
>  
>  /* have_imager() - Check if we have support for imager interface */
> @@ -832,16 +834,39 @@ static struct spi_eeprom at25640 = {
>  	.flags		= EE_ADDR2,
>  };
>  
> -static struct spi_board_info dm365_evm_spi_info[] __initconst = {
> -	{
> +static const struct spi_board_info
> +	dm365_evm_spi_info_at25 __initconst = {

This line doesn't need to wrap.

Also, should keep this as an array for ease of adding others later and
also so you can use ARRAY_SIZE() for ninfo during the call to _init()

>  		.modalias	= "at25",
>  		.platform_data	= &at25640,
>  		.max_speed_hz	= 20 * 1000 * 1000,	/* at 3v3 */
>  		.bus_num	= 0,
>  		.chip_select	= 0,
>  		.mode		= SPI_MODE_0,
> -	},
> -};
> +	};
> +
> +static struct dm365_spi_unit_desc
> +	dm365_evm_spi_udesc_at25 = {

line doesn't need to wrap

> +		.spi_hwunit	= 0,
> +		.chipsel	= BIT(0),
> +		.irq		= IRQ_SPI0,

Here, just use the already defined IRQ_DM365_SPIINT0_0 instead of
having an extra #define.

> +		.dma_tx_chan	= DMA_CHAN_SPI0_TX,
> +		.dma_rx_chan	= DMA_CHAN_SPI0_RX,
> +		.dma_evtq	= DMA_EVQ_SPI0,

Here, just use EVENTQ_3.

> +		.pdata		= {
> +			.version 	= SPI_VERSION_1,
> +			.num_chipselect = 2,
> +			.clk_internal	= 1,
> +			.cs_hold	= 1,
> +			.intr_level	= 0,
> +			.poll_mode	= 1,	/* 0 -> interrupt mode 1-> polling mode */
> +			.use_dma	= 1,	/* when 1, value in poll_mode is ignored */
> +			.c2tdelay	= 0,
> +			.t2cdelay	= 0
> +		}
> +	};
> +
> +
> +
>  
>  static __init void dm365_evm_init(void)
>  {
> @@ -861,8 +886,8 @@ static __init void dm365_evm_init(void)
>  	dm365_init_rtc();
>  	dm365_init_ks(&dm365evm_ks_data);
>  
> -	dm365_init_spi0(BIT(0), dm365_evm_spi_info,
> -			ARRAY_SIZE(dm365_evm_spi_info));
> +	dm365_init_spi(&dm365_evm_spi_udesc_at25, 1, &dm365_evm_spi_info_at25);

as mentioned above, switch the info struct back to an array and switch
back to using ARRAY_SIZE() here instead of '1'.

> +	return;
>  }
>  
>  static __init void dm365_evm_irq_init(void)
> diff --git a/arch/arm/mach-davinci/board_dm365_evm_resources.h b/arch/arm/mach-davinci/board_dm365_evm_resources.h
> new file mode 100644
> index 0000000..d9cfc6b
> --- /dev/null
> +++ b/arch/arm/mach-davinci/board_dm365_evm_resources.h
> @@ -0,0 +1,17 @@
> +#ifndef _DAVINCI_EVM_RESOURCES_H
> +#define _DAVINCI_EVM_RESOURCES_H
> +
> +#include <mach/irqs.h>
> +#include <mach/edma.h>
> +
> +/* IRQs */
> +#define IRQ_SPI0		IRQ_DM365_SPIINT0_0

This can be dropped, and IRQ_DM365_SPIINT0_0 used directly.

> +/* DMA channels */
> +#define DMA_CHAN_SPI0_TX	16
> +#define DMA_CHAN_SPI0_RX	17

These are SoC common, should be in <soc>.h

> +/* DMA event queues */
> +#define DMA_EVQ_SPI0		EVENTQ_3

This can be dropped, and EVNETQ_3 used directly.

> +#endif /* _DAVINCI_EVM_RESOURCES_H */

I think it's best to just drop this file and these #defines altogether
and just use the values directly in the board files.  It will make the
board files a bit more readable and avoid a level of indirection.

> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index ed6c9c7..023d708 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -616,72 +616,256 @@ EVT_CFG(DM365,	EVT3_ASP_RX,         1,     1,    0,     false)
>  #endif
>  };
>  
> -static u64 dm365_spi0_dma_mask = DMA_BIT_MASK(32);
> +static u64 dm365_spi_dma_mask = DMA_BIT_MASK(32);
>  
> -static struct davinci_spi_platform_data dm365_spi0_pdata = {
> -	.version 	= SPI_VERSION_1,
> -	.num_chipselect = 2,
> -	.clk_internal	= 1,
> -	.cs_hold	= 1,
> -	.intr_level	= 0,
> -	.poll_mode	= 1,	/* 0 -> interrupt mode 1-> polling mode */
> -	.use_dma	= 1,	/* when 1, value in poll_mode is ignored */
> -	.c2tdelay	= 0,
> -	.t2cdelay	= 0,
> +enum dm365_spi_resource_index {
> +	spirsrc_iomem,
> +	spirsrc_irq,
> +	spirsrc_rxdma,
> +	spirsrc_txdma,
> +	spirsrc_evqdma
>  };
>
> -static struct resource dm365_spi0_resources[] = {
> +
> +static struct resource dm365_spi_resources[spirsrc_evqdma + 1][5] = {
>  	{
> -		.start = 0x01c66000,
> -		.end   = 0x01c667ff,
> -		.flags = IORESOURCE_MEM,
> +		[spirsrc_iomem] = {
> +			.start	= 0x01c66000,
> +			.end	= 0x01c667ff,
> +			.flags	= IORESOURCE_MEM,
> +		},
> +		[spirsrc_irq] = {
> +			.flags	= IORESOURCE_IRQ,
> +		},
> +		[spirsrc_rxdma] = {
> +			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
> +		},
> +		[spirsrc_txdma] = {
> +			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
> +		},
> +		[spirsrc_evqdma] = {
> +			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
> +		}
>  	},
>  	{
> -		.start = IRQ_DM365_SPIINT0_0,
> -		.flags = IORESOURCE_IRQ,
> +		[spirsrc_iomem] = {
> +			.start	= 0x01c66800,
> +			.end	= 0x01c66fff,
> +			.flags	= IORESOURCE_MEM,
> +		},
> +		[spirsrc_irq] = {
> +			.flags	= IORESOURCE_IRQ,
> +		},
> +		[spirsrc_rxdma] = {
> +			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
> +		},
> +		[spirsrc_txdma] = {
> +			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
> +		},
> +		[spirsrc_evqdma] = {
> +			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
> +		}
>  	},
>  	{
> -		.start = 17,
> -		.flags = IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
> +		[spirsrc_iomem] = {
> +			.start	= 0x01c67800,
> +			.end	= 0x01c67fff,
> +			.flags	= IORESOURCE_MEM,
> +		},
> +		[spirsrc_irq] = {
> +			.flags	= IORESOURCE_IRQ,
> +		},
> +		[spirsrc_rxdma] = {
> +			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
> +		},
> +		[spirsrc_txdma] = {
> +			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
> +		},
> +		[spirsrc_evqdma] = {
> +			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
> +		}
>  	},
>  	{
> -		.start = 16,
> -		.flags = IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
> +		[spirsrc_iomem] = {
> +			.start	= 0x01c68000,
> +			.end	= 0x01c687ff,
> +			.flags	= IORESOURCE_MEM,
> +		},
> +		[spirsrc_irq] = {
> +			.flags	= IORESOURCE_IRQ,
> +		},
> +		[spirsrc_rxdma] = {
> +			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
> +		},
> +		[spirsrc_txdma] = {
> +			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
> +		},
> +		[spirsrc_evqdma] = {
> +			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
> +		}
>  	},
>  	{
> -		.start = EVENTQ_3,
> -		.flags = IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
> +		[spirsrc_iomem] = {
> +			.start	= 0x01c23000,
> +			.end	= 0x01c237ff,
> +			.flags	= IORESOURCE_MEM,
> +		},
> +		[spirsrc_irq] = {
> +			.flags	= IORESOURCE_IRQ,
> +		},
> +		[spirsrc_rxdma] = {
> +			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
> +		},
> +		[spirsrc_txdma] = {
> +			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
> +		},
> +		[spirsrc_evqdma] = {
> +			.flags	= IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
> +		}
> +	}
> +};

Since most boards will not be using all of the above, Rather than
statically allocate the IRQ and DMA resources, why not allocate them
on demand during _init_spi()?

[...]

Kevin


From cyril at ti.com  Tue Apr 20 10:57:08 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Tue, 20 Apr 2010 11:57:08 -0400
Subject: [PATCH v3 05/16] Davinci: watchdog reset separation across socs
In-Reply-To: <87wrw3qddv.fsf@deeprootsystems.com>
References: <1271270702-28307-1-git-send-email-cyril@ti.com>	<1271270702-28307-2-git-send-email-cyril@ti.com>	<1271270702-28307-3-git-send-email-cyril@ti.com>	<1271270702-28307-4-git-send-email-cyril@ti.com>	<1271270702-28307-5-git-send-email-cyril@ti.com>	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<87wrw3qddv.fsf@deeprootsystems.com>
Message-ID: <4BCDCED4.3010000@ti.com>

Hi Kevin,

>> This way, as long as the compiler optimizer is active (tested with O2 and Os),
>> irrelevant arch_reset code gets auto-magically stripped out along with hanging
>> references to unknown symbols.
> 
> Good for runtime, but still not so good for readability.

Could you elaborate on this, please?

> I think the better option is to get rid of the global platform_devices
> altogether.  There are a couple options here
> 
> 1. just search for a watchdog device (I think this is what Sekhar
> already pointed out.)
> 
> 2. use platform_bus notifier callbacks and check when you get an
> BUS_NOTIFY_ADD_DEVICE for a "watchdog" device.  Once you get this, you
> can have a functioning reset, until then it will have to be a nop.

For devices deployed in the field, a failed reset attempt leaves a brick 
that can no longer be remotely managed.  Therefore, I think the reset 
mechanism must be functional as early in the boot sequence as possible.

With the bus search option, reset will be non-functional until 
arch_initcalls are executed.  Isn't that too wide a hole?

Would passing in WDT info via davinci_soc_info be a better alternative?

Regards
Cyril.

From adamzhao.cn at hotmail.com  Tue Apr 20 02:34:02 2010
From: adamzhao.cn at hotmail.com (adamzhao.cn at hotmail.com)
Date: Tue, 20 Apr 2010 00:34:02 -0700
Subject: TVP5158 and DM6467
Message-ID: <20438546.216172.1271748842544.JavaMail.root@jim.nabble.com>

Hi

Here is Adam Zhao from Hefei China, I find your info on the nabble.
Here is a tvp5158+DM6467 project, the video port of the 5158 works well on the DM6467 board, but the TDM audio port does not work, Could you kindly send the tvp5158 linux drivers on the dm6467 board to me for reference ?
Here is my email: adamzhao.cn at hotmail.com
Thank you much.

Adam Zhao

From khilman at deeprootsystems.com  Tue Apr 20 11:21:25 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Tue, 20 Apr 2010 09:21:25 -0700
Subject: [PATCH 3/4] DaVinci SPI: Fix SPI clock prescale factor computation
In-Reply-To: <1270738918-30050-5-git-send-email-thomas.koeller@baslerweb.com>
	(thomas koeller's message of "Thu\, 8 Apr 2010 17\:01\:57 +0200")
References: <1270738918-30050-1-git-send-email-thomas.koeller@baslerweb.com>
	<1270738918-30050-5-git-send-email-thomas.koeller@baslerweb.com>
Message-ID: <871veaksca.fsf@deeprootsystems.com>

thomas.koeller at baslerweb.com writes:

> From: Thomas Koeller <thomas.koeller at baslerweb.com>
>
> Computation of the clock prescaler value returned bogus results if
> the requested SPI clock was impossible to set. It now sets either
> the maximum or minimum clock frequency, as appropriate.
>
> Signed-off-by: Thomas Koeller <thomas.koeller at baslerweb.com>

What platforms was this tested on?

This looks like a fix that should be queued for 2.6.34-rc, but would
be helpful to have a review/ack from Sandeep on this.

Also, this fix needs to go upstream through the SPI maintainers.

Please send to spi-devel-general at lists.sourceforge.net, with
the davinci list in CC as well as these folks:

Grant Likely <grant.likely at secretlab.ca>
Sandeep Paulraj <s-paulraj at ti.com>
Philby John <pjohn at in.mvista.com>
Sudhakar Rajashekhara <sudhakar.raj at ti.com>

Thanks,

Kevin


> ---
>  drivers/spi/davinci_spi.c |   12 +++++++++---
>  1 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
> index 956f617..02e1a76 100644
> --- a/drivers/spi/davinci_spi.c
> +++ b/drivers/spi/davinci_spi.c
> @@ -153,7 +153,7 @@ static int davinci_spi_setup_transfer(struct spi_device *spi,
>  	struct davinci_spi *davinci_spi;
>  	struct davinci_spi_platform_data *pdata;
>  	u8 bits_per_word = 0;
> -	u32 hz = 0, prescale;
> +	u32 hz = 0, prescale = 0, clkspeed;
>  
>  	davinci_spi = spi_master_get_devdata(spi->master);
>  	pdata = davinci_spi->pdata;
> @@ -190,10 +190,16 @@ static int davinci_spi_setup_transfer(struct spi_device *spi,
>  	set_fmt_bits(davinci_spi->base, bits_per_word & 0x1f,
>  			spi->chip_select);
>  
> -	prescale = ((clk_get_rate(davinci_spi->clk) / hz) - 1) & 0xff;
> +	clkspeed = clk_get_rate(davinci_spi->clk);
> +	if (hz > clkspeed / 2)
> +		prescale = 1 << 8;
> +	if (hz < clkspeed / 256)
> +		prescale = 255 << 8;
> +	if (!prescale)
> +		prescale = ((clkspeed / hz - 1) << 8) & 0x0000ff00;
>  
>  	clear_fmt_bits(davinci_spi->base, 0x0000ff00, spi->chip_select);
> -	set_fmt_bits(davinci_spi->base, prescale << 8, spi->chip_select);
> +	set_fmt_bits(davinci_spi->base, prescale, spi->chip_select);
>  
>  	return 0;
>  }
> -- 
> 1.7.0.3
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From khilman at deeprootsystems.com  Tue Apr 20 11:38:12 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Tue, 20 Apr 2010 09:38:12 -0700
Subject: [PATCH v3 05/16] Davinci: watchdog reset separation across socs
In-Reply-To: <4BCDCED4.3010000@ti.com> (Cyril Chemparathy's message of "Tue\,
	20 Apr 2010 11\:57\:08 -0400")
References: <1271270702-28307-1-git-send-email-cyril@ti.com>
	<1271270702-28307-2-git-send-email-cyril@ti.com>
	<1271270702-28307-3-git-send-email-cyril@ti.com>
	<1271270702-28307-4-git-send-email-cyril@ti.com>
	<1271270702-28307-5-git-send-email-cyril@ti.com>
	<1271270702-28307-6-git-send-email-cyril@ti.com>
	<87wrw3qddv.fsf@deeprootsystems.com> <4BCDCED4.3010000@ti.com>
Message-ID: <87ochejczv.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> Hi Kevin,
>
>>> This way, as long as the compiler optimizer is active (tested with O2 and Os),
>>> irrelevant arch_reset code gets auto-magically stripped out along with hanging
>>> references to unknown symbols.
>>
>> Good for runtime, but still not so good for readability.
>
> Could you elaborate on this, please?

I'd like to avoid the cpu_is_* calls in this common code.

>> I think the better option is to get rid of the global platform_devices
>> altogether.  There are a couple options here
>>
>> 1. just search for a watchdog device (I think this is what Sekhar
>> already pointed out.)
>>
>> 2. use platform_bus notifier callbacks and check when you get an
>> BUS_NOTIFY_ADD_DEVICE for a "watchdog" device.  Once you get this, you
>> can have a functioning reset, until then it will have to be a nop.
>
> For devices deployed in the field, a failed reset attempt leaves a
> brick that can no longer be remotely managed.  Therefore, I think the
> reset mechanism must be functional as early in the boot sequence as
> possible.
>
> With the bus search option, reset will be non-functional until
> arch_initcalls are executed.  Isn't that too wide a hole?
>
> Would passing in WDT info via davinci_soc_info be a better alternative?

That's how we had it initially, but I've been trying to keep driver
stuff out of soc_info.  I've made an exception for serial because of
the importance to early debug, but I think an exception for watchdog
reset would probably be ok.

Kevin


From khilman at deeprootsystems.com  Tue Apr 20 17:20:37 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Tue, 20 Apr 2010 15:20:37 -0700
Subject: [PATCH 4/4] DM365: Add platform resource management
In-Reply-To: <1270738918-30050-6-git-send-email-thomas.koeller@baslerweb.com>
	(thomas koeller's message of "Thu\, 8 Apr 2010 17\:01\:58 +0200")
References: <1270738918-30050-1-git-send-email-thomas.koeller@baslerweb.com>
	<1270738918-30050-6-git-send-email-thomas.koeller@baslerweb.com>
Message-ID: <87633lepfu.fsf@deeprootsystems.com>

thomas.koeller at baslerweb.com writes:

> From: Thomas Koeller <thomas.koeller at baslerweb.com>
>
> Keeping track of resource assignments greatly simplifies
> the task of writing board support code. Many drivers for
> DaVinci peripherals were using resources that had never
> been allocated, with the notable exception of memory
> resources.
>
> Non-conflicting resource assignment is a responsibility
> of the bus the devices are on, in this case, the platform bus.
>
> The resource management scheme implemented by this patch is not
> perfect. The SoC code really has no business managing resources,
> it should only provide them to the platform (board support) code.
> The board support is the only place where information about the
> intended use of the various hardware resources is available.

Actually, the driver is the place where the resources are used and
therefore where they should be reserved and released.  This patch
removes this from the drivers and puts it in SoC code which I don't
like.

There are really two main things going on here that I see:

1. add parent resources (cfg, irq, dma, etc.)
2. move resource reservation from drivers to SoC code

It's primarily 2 that I object to.

While I think (1) may be helpful, if we're going to do it, we should
do it throughout all of mach-davinci/*.

Kevin

From khilman at deeprootsystems.com  Tue Apr 20 17:21:05 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Tue, 20 Apr 2010 15:21:05 -0700
Subject: [PATCH 2/4] DM365: Allow use of GPIO64_57
In-Reply-To: <1270738918-30050-4-git-send-email-thomas.koeller@baslerweb.com>
	(thomas koeller's message of "Thu\, 8 Apr 2010 17\:01\:56 +0200")
References: <1270738918-30050-1-git-send-email-thomas.koeller@baslerweb.com>
	<1270738918-30050-4-git-send-email-thomas.koeller@baslerweb.com>
Message-ID: <87zl0xdaum.fsf@deeprootsystems.com>

thomas.koeller at baslerweb.com writes:

> From: Thomas Koeller <thomas.koeller at baslerweb.com>
>
> Extended the MUX configuration to allow use of GPIO
> terminals 64..57.
>
> Signed-off-by: Thomas Koeller <thomas.koeller at baslerweb.com>

Thanks, applying and queuing for 2.6.35 in davinci-next branch.

Kevin

> ---
>  arch/arm/mach-davinci/dm365.c            |    1 +
>  arch/arm/mach-davinci/include/mach/mux.h |    1 +
>  2 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index 023d708..0813dce 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -580,6 +580,7 @@ MUX_CFG(DM365,	SPI4_SDENA1,	4,   16,    3,    2,	 false)
>  MUX_CFG(DM365,	GPIO20,		3,   21,    3,    0,	 false)
>  MUX_CFG(DM365,	GPIO33,		4,   12,    3,	  0,	 false)
>  MUX_CFG(DM365,	GPIO40,		4,   26,    3,	  0,	 false)
> +MUX_CFG(DM365,	GPIO64_57,	2,   6,     1,	  0,	 false)
>  
>  MUX_CFG(DM365,	VOUT_FIELD,	1,   18,    3,	  1,	 false)
>  MUX_CFG(DM365,	VOUT_FIELD_G81,	1,   18,    3,	  0,	 false)
> diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h
> index 05e35fa..d6c6921 100644
> --- a/arch/arm/mach-davinci/include/mach/mux.h
> +++ b/arch/arm/mach-davinci/include/mach/mux.h
> @@ -295,6 +295,7 @@ enum davinci_dm365_index {
>  	DM365_GPIO20,
>  	DM365_GPIO33,
>  	DM365_GPIO40,
> +	DM365_GPIO64_57,
>  
>  	/* Video */
>  	DM365_VOUT_FIELD,
> -- 
> 1.7.0.3
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From Thomas.Koeller at baslerweb.com  Wed Apr 21 03:13:55 2010
From: Thomas.Koeller at baslerweb.com (Koeller, T.)
Date: Wed, 21 Apr 2010 10:13:55 +0200
Subject: [PATCH 4/4] DM365: Add platform resource management
In-Reply-To: <87633lepfu.fsf@deeprootsystems.com>
References: <87633lepfu.fsf@deeprootsystems.com>
Message-ID: <C5A8FDEFF7647F4C9CB927D7DEB307730E5309C7@ahr075s.basler.corp>

Hi Kevin,

> 
> Actually, the driver is the place where the resources are used and
> therefore where they should be reserved and released.  This patch
> removes this from the drivers and puts it in SoC code which I don't
> like.
> 
> There are really two main things going on here that I see:
> 
> 1. add parent resources (cfg, irq, dma, etc.)
> 2. move resource reservation from drivers to SoC code
> 
> It's primarily 2 that I object to.
> 
> While I think (1) may be helpful, if we're going to do it, we should
> do it throughout all of mach-davinci/*.

Here I do not quite agree with your view. In general, resource managment
is about avoiding conflicts. This means that it must be done in a
place where the resource requirements of all devices are known, and this
is the bus, not the individual drivers. This is more obvious when
dealing with buses that enumerate their devices and collect their
resource requirements in order to make intelligent decisions. The
platform bus has been invented to extend this concept to devices that
are not really on such a bus.

For platform devices, resources are set up by the platform and passed to
the drivers via platform devices. At this point, the decision about which
resource is going to be used by a particular driver has already been made,
and nothing is gained by defering the actual allocation. Resource
allocation in the driver is only possible for resources for which
global root nodes exist (IO and MEMORY addresses). All other kinds of
resources cannot be allocated by drivers because these do not (and should
not) know about the root resource nodes in the platform. Consequently,
you see lots of drivers that do allocate memory resources, but ignore
all the others.

Therefore, if a platform wanted to do proper resource management covering
all kinds of resources, it would have to treat memory and io resources
specially, relying on the driver to do the actual allocation and implement
resource management only for the remaining resource types, which is
certainly ugly.

Thanks for your comments!

Thomas

From Thomas.Koeller at baslerweb.com  Wed Apr 21 03:21:37 2010
From: Thomas.Koeller at baslerweb.com (Koeller, T.)
Date: Wed, 21 Apr 2010 10:21:37 +0200
Subject: [PATCH 1/4] DM365: Make all SPI units SPI0..SPI4 available
In-Reply-To: <87ochekvbn.fsf@deeprootsystems.com>
References: <87ochekvbn.fsf@deeprootsystems.com>
Message-ID: <C5A8FDEFF7647F4C9CB927D7DEB307730E5309D5@ahr075s.basler.corp>

Hi Kevin,

> > --- /dev/null
> > +++ b/arch/arm/mach-davinci/board_dm365_evm_resources.h
> > @@ -0,0 +1,17 @@
> > +#ifndef _DAVINCI_EVM_RESOURCES_H
> > +#define _DAVINCI_EVM_RESOURCES_H
> > +
> > +#include <mach/irqs.h>
> > +#include <mach/edma.h>
> > +
> > +/* IRQs */
> > +#define IRQ_SPI0		IRQ_DM365_SPIINT0_0
> 
> This can be dropped, and IRQ_DM365_SPIINT0_0 used directly.
> 
> > +/* DMA channels */
> > +#define DMA_CHAN_SPI0_TX	16
> > +#define DMA_CHAN_SPI0_RX	17
> 
> These are SoC common, should be in <soc>.h
> 
> > +/* DMA event queues */
> > +#define DMA_EVQ_SPI0		EVENTQ_3
> 
> This can be dropped, and EVNETQ_3 used directly.
> 
> > +#endif /* _DAVINCI_EVM_RESOURCES_H */
> 
> I think it's best to just drop this file and these #defines altogether
> and just use the values directly in the board files.  It will make the
> board files a bit more readable and avoid a level of indirection.

I thought it a good idea to have central point where all those
resources (I am using this term in an informal way here) are defined
in terms of their intended use, making it easier to spot
possible conflicts.

> > diff --git a/arch/arm/mach-davinci/dm365.c 
> b/arch/arm/mach-davinci/dm365.c
> > index ed6c9c7..023d708 100644
> > --- a/arch/arm/mach-davinci/dm365.c
> > +++ b/arch/arm/mach-davinci/dm365.c
> > @@ -616,72 +616,256 @@ EVT_CFG(DM365,	EVT3_ASP_RX,    
>      1,     1,    0,     false)
> >  #endif
> >  };
> >  
> > -static u64 dm365_spi0_dma_mask = DMA_BIT_MASK(32);
> > +static u64 dm365_spi_dma_mask = DMA_BIT_MASK(32);
> >  
> > -static struct davinci_spi_platform_data dm365_spi0_pdata = {
> > -	.version 	= SPI_VERSION_1,
> > -	.num_chipselect = 2,
> > -	.clk_internal	= 1,
> > -	.cs_hold	= 1,
> > -	.intr_level	= 0,
> > -	.poll_mode	= 1,	/* 0 -> interrupt mode 1-> 
> polling mode */
> > -	.use_dma	= 1,	/* when 1, value in poll_mode 
> is ignored */
> > -	.c2tdelay	= 0,
> > -	.t2cdelay	= 0,
> > +enum dm365_spi_resource_index {
> > +	spirsrc_iomem,
> > +	spirsrc_irq,
> > +	spirsrc_rxdma,
> > +	spirsrc_txdma,
> > +	spirsrc_evqdma
> >  };
> >
> > -static struct resource dm365_spi0_resources[] = {
> > +
> > +static struct resource dm365_spi_resources[spirsrc_evqdma 
> + 1][5] = {
> >  	{
> > -		.start = 0x01c66000,
> > -		.end   = 0x01c667ff,
> > -		.flags = IORESOURCE_MEM,
> > +		[spirsrc_iomem] = {
> > +			.start	= 0x01c66000,
> > +			.end	= 0x01c667ff,
> > +			.flags	= IORESOURCE_MEM,
> > +		},
> > +		[spirsrc_irq] = {
> > +			.flags	= IORESOURCE_IRQ,
> > +		},
> > +		[spirsrc_rxdma] = {
> > +			.flags	= IORESOURCE_DMA | 
> IORESOURCE_DMA_RX_CHAN,
> > +		},
> > +		[spirsrc_txdma] = {
> > +			.flags	= IORESOURCE_DMA | 
> IORESOURCE_DMA_TX_CHAN,
> > +		},
> > +		[spirsrc_evqdma] = {
> > +			.flags	= IORESOURCE_DMA | 
> IORESOURCE_DMA_EVENT_Q,
> > +		}
> >  	},
> >  	{
> > -		.start = IRQ_DM365_SPIINT0_0,
> > -		.flags = IORESOURCE_IRQ,
> > +		[spirsrc_iomem] = {
> > +			.start	= 0x01c66800,
> > +			.end	= 0x01c66fff,
> > +			.flags	= IORESOURCE_MEM,
> > +		},
> > +		[spirsrc_irq] = {
> > +			.flags	= IORESOURCE_IRQ,
> > +		},
> > +		[spirsrc_rxdma] = {
> > +			.flags	= IORESOURCE_DMA | 
> IORESOURCE_DMA_RX_CHAN,
> > +		},
> > +		[spirsrc_txdma] = {
> > +			.flags	= IORESOURCE_DMA | 
> IORESOURCE_DMA_TX_CHAN,
> > +		},
> > +		[spirsrc_evqdma] = {
> > +			.flags	= IORESOURCE_DMA | 
> IORESOURCE_DMA_EVENT_Q,
> > +		}
> >  	},
> >  	{
> > -		.start = 17,
> > -		.flags = IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
> > +		[spirsrc_iomem] = {
> > +			.start	= 0x01c67800,
> > +			.end	= 0x01c67fff,
> > +			.flags	= IORESOURCE_MEM,
> > +		},
> > +		[spirsrc_irq] = {
> > +			.flags	= IORESOURCE_IRQ,
> > +		},
> > +		[spirsrc_rxdma] = {
> > +			.flags	= IORESOURCE_DMA | 
> IORESOURCE_DMA_RX_CHAN,
> > +		},
> > +		[spirsrc_txdma] = {
> > +			.flags	= IORESOURCE_DMA | 
> IORESOURCE_DMA_TX_CHAN,
> > +		},
> > +		[spirsrc_evqdma] = {
> > +			.flags	= IORESOURCE_DMA | 
> IORESOURCE_DMA_EVENT_Q,
> > +		}
> >  	},
> >  	{
> > -		.start = 16,
> > -		.flags = IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
> > +		[spirsrc_iomem] = {
> > +			.start	= 0x01c68000,
> > +			.end	= 0x01c687ff,
> > +			.flags	= IORESOURCE_MEM,
> > +		},
> > +		[spirsrc_irq] = {
> > +			.flags	= IORESOURCE_IRQ,
> > +		},
> > +		[spirsrc_rxdma] = {
> > +			.flags	= IORESOURCE_DMA | 
> IORESOURCE_DMA_RX_CHAN,
> > +		},
> > +		[spirsrc_txdma] = {
> > +			.flags	= IORESOURCE_DMA | 
> IORESOURCE_DMA_TX_CHAN,
> > +		},
> > +		[spirsrc_evqdma] = {
> > +			.flags	= IORESOURCE_DMA | 
> IORESOURCE_DMA_EVENT_Q,
> > +		}
> >  	},
> >  	{
> > -		.start = EVENTQ_3,
> > -		.flags = IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
> > +		[spirsrc_iomem] = {
> > +			.start	= 0x01c23000,
> > +			.end	= 0x01c237ff,
> > +			.flags	= IORESOURCE_MEM,
> > +		},
> > +		[spirsrc_irq] = {
> > +			.flags	= IORESOURCE_IRQ,
> > +		},
> > +		[spirsrc_rxdma] = {
> > +			.flags	= IORESOURCE_DMA | 
> IORESOURCE_DMA_RX_CHAN,
> > +		},
> > +		[spirsrc_txdma] = {
> > +			.flags	= IORESOURCE_DMA | 
> IORESOURCE_DMA_TX_CHAN,
> > +		},
> > +		[spirsrc_evqdma] = {
> > +			.flags	= IORESOURCE_DMA | 
> IORESOURCE_DMA_EVENT_Q,
> > +		}
> > +	}
> > +};
> 
> Since most boards will not be using all of the above, Rather than
> statically allocate the IRQ and DMA resources, why not allocate them
> on demand during _init_spi()?

Don't think this is worthwile. You save a couple of bytes, but have
to add code that does memory allocation and associated error handling.

thanks,
Thomas

From nsekhar at ti.com  Wed Apr 21 04:39:08 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Wed, 21 Apr 2010 15:09:08 +0530
Subject: [PATCH 4/4] DM365: Add platform resource management
In-Reply-To: <C5A8FDEFF7647F4C9CB927D7DEB307730E5309C7@ahr075s.basler.corp>
References: <87633lepfu.fsf@deeprootsystems.com>
	<C5A8FDEFF7647F4C9CB927D7DEB307730E5309C7@ahr075s.basler.corp>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E6A1520A@dbde02.ent.ti.com>

Hi Thomas,

On Wed, Apr 21, 2010 at 13:43:55, Koeller, T. wrote:
> Hi Kevin,
>
> >
> > Actually, the driver is the place where the resources are used and
> > therefore where they should be reserved and released.  This patch
> > removes this from the drivers and puts it in SoC code which I don't
> > like.
> >
> > There are really two main things going on here that I see:
> >
> > 1. add parent resources (cfg, irq, dma, etc.)
> > 2. move resource reservation from drivers to SoC code
> >
> > It's primarily 2 that I object to.
> >
> > While I think (1) may be helpful, if we're going to do it, we should
> > do it throughout all of mach-davinci/*.
>
> Here I do not quite agree with your view. In general, resource managment
> is about avoiding conflicts. This means that it must be done in a
> place where the resource requirements of all devices are known, and this
> is the bus, not the individual drivers. This is more obvious when
> dealing with buses that enumerate their devices and collect their
> resource requirements in order to make intelligent decisions. The
> platform bus has been invented to extend this concept to devices that
> are not really on such a bus.
>
> For platform devices, resources are set up by the platform and passed to
> the drivers via platform devices. At this point, the decision about which
> resource is going to be used by a particular driver has already been made,
> and nothing is gained by defering the actual allocation. Resource

I can think of one (admittedly esoteric) example where this not true.
On the DM6446 EVM, the NAND and NOR flash reside on the same chip-select
and it is possible to runtime switch between the flashes used by
flipping a jumper and insmoding the appropriate driver.

Currently, both nand and nor drivers do not make a memory region request,
but that should probably be fixed.

> allocation in the driver is only possible for resources for which
> global root nodes exist (IO and MEMORY addresses). All other kinds of
> resources cannot be allocated by drivers because these do not (and should
> not) know about the root resource nodes in the platform. Consequently,
> you see lots of drivers that do allocate memory resources, but ignore
> all the others.

IRQ resources are managed by request_irq(). EDMA does its own resource
management, but ideally should be using drivers/dma/ resource manager.

So, I tend to think of it as driver requesting and releasing all
shared resources.

Thanks,
Sekhar


From Thomas.Koeller at baslerweb.com  Wed Apr 21 07:10:29 2010
From: Thomas.Koeller at baslerweb.com (Koeller, T.)
Date: Wed, 21 Apr 2010 14:10:29 +0200
Subject: [PATCH 4/4] DM365: Add platform resource management
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E6A1520A@dbde02.ent.ti.com>
References: <C5A8FDEFF7647F4C9CB927D7DEB307730E5309C7@ahr075s.basler.corp>
	<B85A65D85D7EB246BE421B3FB0FBB59301E6A1520A@dbde02.ent.ti.com>
Message-ID: <C5A8FDEFF7647F4C9CB927D7DEB307730E530AA9@ahr075s.basler.corp>

From: Nori, Sekhar [mailto:nsekhar at ti.com] 

> IRQ resources are managed by request_irq(). EDMA does its own resource
> management, but ideally should be using drivers/dma/ resource manager.

This is not the kind of resource management I am talking about. You could
call request_irq() with any bogus irq number (similar for DMA) and not notice
that you are doing something wrong. You could attempt to set up an interrupt
as shared that is not sharable. Look at linux/ioport.h for a lot of stuff
designed to aid in avoiding such conflicts by proper use of resources.

Finally, a platform may define resources that are totally platform-specific,
and that can only be managed within the platform itself.

thanks,
Thomas

From mschnell at lumino.de  Wed Apr 21 08:02:36 2010
From: mschnell at lumino.de (Michael Schnell)
Date: Wed, 21 Apr 2010 15:02:36 +0200
Subject: AM1808
Message-ID: <4BCEF76C.8050405@lumino.de>

Hi Experts,

I'm new to this list.

Is this the right place to monitor when doing development with the new
AM1808 processor and it's "Sitara ARM9"  friends ?

Thanks,
-Michael

From mschnell at lumino.de  Wed Apr 21 08:24:03 2010
From: mschnell at lumino.de (Michael Schnell)
Date: Wed, 21 Apr 2010 15:24:03 +0200
Subject: AM1808
Message-ID: <4BCEFC73.5090702@lumino.de>

Hi Experts,

I'm new to this list.

Is this the right place to monitor when doing development with the new
AM1808 processor and it's "Sitara ARM9"  friends ?

Thanks,
-Michael

From thomas.koeller at baslerweb.com  Wed Apr 21 08:33:32 2010
From: thomas.koeller at baslerweb.com (thomas.koeller at baslerweb.com)
Date: Wed, 21 Apr 2010 15:33:32 +0200
Subject: [PATCH] DAVINCI: Added missing includes
Message-ID: <1271856812-24588-1-git-send-email-thomas.koeller@baslerweb.com>

From: Thomas Koeller <thomas.koeller at baslerweb.com>

linux/compiler.h is required for __iomem
linux/types.h is required u32

Signed-off-by: Thomas Koeller <thomas.koeller at baslerweb.com>
---
 arch/arm/mach-davinci/include/mach/common.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 1fd3917..f56fd5a 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -12,6 +12,9 @@
 #ifndef __ARCH_ARM_MACH_DAVINCI_COMMON_H
 #define __ARCH_ARM_MACH_DAVINCI_COMMON_H
 
+#include <linux/compiler.h>
+#include <linux/types.h>
+
 struct sys_timer;
 
 extern struct sys_timer davinci_timer;
-- 
1.7.0.3


From khasim at ti.com  Wed Apr 21 08:38:57 2010
From: khasim at ti.com (Syed Mohammed, Khasim)
Date: Wed, 21 Apr 2010 19:08:57 +0530
Subject: AM1808
In-Reply-To: <4BCEFC73.5090702@lumino.de>
References: <4BCEFC73.5090702@lumino.de>
Message-ID: <0680EC522D0CC943BC586913CF3768C003B30BC363@dbde02.ent.ti.com>

Hi Michael,

> -----Original Message-----
> From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-
> linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Michael Schnell
> Sent: Wednesday, April 21, 2010 6:54 PM
> To: davinci-linux-open-source at linux.davincidsp.com
> Subject: AM1808
> 
> Hi Experts,
> 
> I'm new to this list.
> 
> Is this the right place to monitor when doing development with the new
> AM1808 processor and it's "Sitara ARM9"  friends ?
>
AM1808 is derivative of DA850/OMAP L 138. Yes, it is right place to continue discussing AM1808 activities.

Thanks.

Regards,
Khasim

From sshtylyov at ru.mvista.com  Wed Apr 21 09:11:33 2010
From: sshtylyov at ru.mvista.com (Sergei Shtylyov)
Date: Wed, 21 Apr 2010 18:11:33 +0400
Subject: [PATCH] DaVinci: move IDE platform device to its proper place
Message-ID: <201004211811.34073.sshtylyov@ru.mvista.com>

The IDE platform device is registered in three different places (2 board files
for DM644x and in dm646x.c for DM646x) while both the IDE base address and the
IDE IRQ are the same for both SoCs -- therefore,  the proper place for the IDE
platform seems to be in devices.c. Merge the IDE platform data and registration
code and create davinci_init_ide() in place of dm646x_init_ide()...

Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>

---
The patch is against the recent DaVinci tree.
It has been tested on DM64{46|67}EVM boards.

 arch/arm/mach-davinci/board-dm644x-evm.c    |   33 ---------------------
 arch/arm/mach-davinci/board-dm646x-evm.c    |    2 -
 arch/arm/mach-davinci/board-neuros-osd2.c   |   34 +--------------------
 arch/arm/mach-davinci/devices.c             |   44 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/dm646x.c              |   32 --------------------
 arch/arm/mach-davinci/include/mach/common.h |    1 
 arch/arm/mach-davinci/include/mach/dm646x.h |    3 -
 7 files changed, 49 insertions(+), 100 deletions(-)

Index: linux-davinci/arch/arm/mach-davinci/board-dm644x-evm.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-dm644x-evm.c
+++ linux-davinci/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -41,8 +41,6 @@
 #define DM644X_EVM_PHY_MASK		(0x2)
 #define DM644X_EVM_MDIO_FREQUENCY	(2200000) /* PHY bus frequency */
 
-#define DAVINCI_CFC_ATA_BASE		  0x01C66000
-
 #define LXT971_PHY_ID	(0x001378e2)
 #define LXT971_PHY_MASK	(0xfffffff0)
 
@@ -252,32 +250,6 @@ static struct platform_device rtc_dev = 
 	.id             = -1,
 };
 
-static struct resource ide_resources[] = {
-	{
-		.start          = DAVINCI_CFC_ATA_BASE,
-		.end            = DAVINCI_CFC_ATA_BASE + 0x7ff,
-		.flags          = IORESOURCE_MEM,
-	},
-	{
-		.start          = IRQ_IDE,
-		.end            = IRQ_IDE,
-		.flags          = IORESOURCE_IRQ,
-	},
-};
-
-static u64 ide_dma_mask = DMA_BIT_MASK(32);
-
-static struct platform_device ide_dev = {
-	.name           = "palm_bk3710",
-	.id             = -1,
-	.resource       = ide_resources,
-	.num_resources  = ARRAY_SIZE(ide_resources),
-	.dev = {
-		.dma_mask		= &ide_dma_mask,
-		.coherent_dma_mask      = DMA_BIT_MASK(32),
-	},
-};
-
 static struct snd_platform_data dm644x_evm_snd_data;
 
 /*----------------------------------------------------------------------*/
@@ -698,10 +670,7 @@ static __init void davinci_evm_init(void
 			pr_warning("WARNING: both IDE and Flash are "
 				"enabled, but they share AEMIF pins.\n"
 				"\tDisable IDE for NAND/NOR support.\n");
-		davinci_cfg_reg(DM644X_HPIEN_DISABLE);
-		davinci_cfg_reg(DM644X_ATAEN);
-		davinci_cfg_reg(DM644X_HDIREN);
-		platform_device_register(&ide_dev);
+		davinci_init_ide();
 	} else if (HAS_NAND || HAS_NOR) {
 		davinci_cfg_reg(DM644X_HPIEN_DISABLE);
 		davinci_cfg_reg(DM644X_ATAEN_DISABLE);
Index: linux-davinci/arch/arm/mach-davinci/board-dm646x-evm.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-dm646x-evm.c
+++ linux-davinci/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -733,7 +733,7 @@ static __init void evm_init(void)
 	platform_device_register(&davinci_nand_device);
 
 	if (HAS_ATA)
-		dm646x_init_ide();
+		davinci_init_ide();
 
 	soc_info->emac_pdata->phy_mask = DM646X_EVM_PHY_MASK;
 	soc_info->emac_pdata->mdio_max_freq = DM646X_EVM_MDIO_FREQUENCY;
Index: linux-davinci/arch/arm/mach-davinci/board-neuros-osd2.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-neuros-osd2.c
+++ linux-davinci/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -31,6 +31,7 @@
 #include <asm/mach/arch.h>
 
 #include <mach/dm644x.h>
+#include <mach/common.h>
 #include <mach/i2c.h>
 #include <mach/serial.h>
 #include <mach/mux.h>
@@ -41,8 +42,6 @@
 #define NEUROS_OSD2_PHY_MASK		0x2
 #define NEUROS_OSD2_MDIO_FREQUENCY	2200000 /* PHY bus frequency */
 
-#define DAVINCI_CFC_ATA_BASE		 0x01C66000
-
 #define LXT971_PHY_ID			0x001378e2
 #define LXT971_PHY_MASK			0xfffffff0
 
@@ -127,32 +126,6 @@ static struct platform_device davinci_fb
 	.num_resources = 0,
 };
 
-static struct resource ide_resources[] = {
-	{
-		.start		= DAVINCI_CFC_ATA_BASE,
-		.end		= DAVINCI_CFC_ATA_BASE + 0x7ff,
-		.flags		= IORESOURCE_MEM,
-	},
-	{
-		.start		= IRQ_IDE,
-		.end		= IRQ_IDE,
-		.flags		= IORESOURCE_IRQ,
-	},
-};
-
-static u64 ide_dma_mask = DMA_BIT_MASK(32);
-
-static struct platform_device ide_dev = {
-	.name		= "palm_bk3710",
-	.id		= -1,
-	.resource	= ide_resources,
-	.num_resources	= ARRAY_SIZE(ide_resources),
-	.dev = {
-		.dma_mask		= &ide_dma_mask,
-		.coherent_dma_mask	= DMA_BIT_MASK(32),
-	},
-};
-
 static struct snd_platform_data dm644x_ntosd2_snd_data;
 
 static struct gpio_led ntosd2_leds[] = {
@@ -256,10 +229,7 @@ static __init void davinci_ntosd2_init(v
 			pr_warning("WARNING: both IDE and Flash are "
 				"enabled, but they share AEMIF pins.\n"
 				"\tDisable IDE for NAND/NOR support.\n");
-		davinci_cfg_reg(DM644X_HPIEN_DISABLE);
-		davinci_cfg_reg(DM644X_ATAEN);
-		davinci_cfg_reg(DM644X_HDIREN);
-		platform_device_register(&ide_dev);
+		davinci_init_ide();
 	} else if (HAS_NAND) {
 		davinci_cfg_reg(DM644X_HPIEN_DISABLE);
 		davinci_cfg_reg(DM644X_ATAEN_DISABLE);
Index: linux-davinci/arch/arm/mach-davinci/devices.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/devices.c
+++ linux-davinci/arch/arm/mach-davinci/devices.c
@@ -26,6 +26,7 @@
 #include "clock.h"
 
 #define DAVINCI_I2C_BASE	     0x01C21000
+#define DAVINCI_ATA_BASE	     0x01C66000
 #define DAVINCI_MMCSD0_BASE	     0x01E10000
 #define DM355_MMCSD0_BASE	     0x01E11000
 #define DM355_MMCSD1_BASE	     0x01E00000
@@ -60,6 +61,49 @@ void __init davinci_init_i2c(struct davi
 	(void) platform_device_register(&davinci_i2c_device);
 }
 
+static struct resource ide_resources[] = {
+	{
+		.start		= DAVINCI_ATA_BASE,
+		.end		= DAVINCI_ATA_BASE + 0x7ff,
+		.flags		= IORESOURCE_MEM,
+	},
+	{
+		.start		= IRQ_IDE,
+		.end		= IRQ_IDE,
+		.flags		= IORESOURCE_IRQ,
+	},
+};
+
+static u64 ide_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device ide_device = {
+	.name           = "palm_bk3710",
+	.id             = -1,
+	.resource       = ide_resources,
+	.num_resources  = ARRAY_SIZE(ide_resources),
+	.dev = {
+		.dma_mask		= &ide_dma_mask,
+		.coherent_dma_mask      = DMA_BIT_MASK(32),
+	},
+};
+
+void __init davinci_init_ide(void)
+{
+	if (cpu_is_davinci_dm644x()) {
+		davinci_cfg_reg(DM644X_HPIEN_DISABLE);
+		davinci_cfg_reg(DM644X_ATAEN);
+		davinci_cfg_reg(DM644X_HDIREN);
+	} else if (cpu_is_davinci_dm646x()) {
+		/* IRQ_DM646X_IDE is the same as IRQ_IDE */
+		davinci_cfg_reg(DM646X_ATAEN);
+	} else {
+		WARN_ON(1);
+		return;
+	}
+
+	platform_device_register(&ide_device);
+}
+
 #if	defined(CONFIG_MMC_DAVINCI) || defined(CONFIG_MMC_DAVINCI_MODULE)
 
 static u64 mmcsd0_dma_mask = DMA_BIT_MASK(32);
Index: linux-davinci/arch/arm/mach-davinci/dm646x.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/dm646x.c
+++ linux-davinci/arch/arm/mach-davinci/dm646x.c
@@ -596,32 +596,6 @@ static struct platform_device dm646x_edm
 	.resource		= edma_resources,
 };
 
-static struct resource ide_resources[] = {
-	{
-		.start          = DM646X_ATA_REG_BASE,
-		.end            = DM646X_ATA_REG_BASE + 0x7ff,
-		.flags          = IORESOURCE_MEM,
-	},
-	{
-		.start          = IRQ_DM646X_IDE,
-		.end            = IRQ_DM646X_IDE,
-		.flags          = IORESOURCE_IRQ,
-	},
-};
-
-static u64 ide_dma_mask = DMA_BIT_MASK(32);
-
-static struct platform_device ide_dev = {
-	.name           = "palm_bk3710",
-	.id             = -1,
-	.resource       = ide_resources,
-	.num_resources  = ARRAY_SIZE(ide_resources),
-	.dev = {
-		.dma_mask		= &ide_dma_mask,
-		.coherent_dma_mask      = DMA_BIT_MASK(32),
-	},
-};
-
 static struct resource dm646x_mcasp0_resources[] = {
 	{
 		.name	= "mcasp0",
@@ -867,12 +841,6 @@ static struct davinci_soc_info davinci_s
 	.sram_len		= SZ_32K,
 };
 
-void __init dm646x_init_ide(void)
-{
-	davinci_cfg_reg(DM646X_ATAEN);
-	platform_device_register(&ide_dev);
-}
-
 void __init dm646x_init_mcasp0(struct snd_platform_data *pdata)
 {
 	dm646x_mcasp0_device.dev.platform_data = pdata;
Index: linux-davinci/arch/arm/mach-davinci/include/mach/common.h
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/include/mach/common.h
+++ linux-davinci/arch/arm/mach-davinci/include/mach/common.h
@@ -67,6 +67,7 @@ struct davinci_soc_info {
 extern struct davinci_soc_info davinci_soc_info;
 
 extern void davinci_common_init(struct davinci_soc_info *soc_info);
+extern void davinci_init_ide(void);
 
 /* standard place to map on-chip SRAMs; they *may* support DMA */
 #define SRAM_VIRT	0xfffe0000
Index: linux-davinci/arch/arm/mach-davinci/include/mach/dm646x.h
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/include/mach/dm646x.h
+++ linux-davinci/arch/arm/mach-davinci/include/mach/dm646x.h
@@ -25,13 +25,10 @@
 #define DM646X_EMAC_MDIO_OFFSET		(0x4000)
 #define DM646X_EMAC_CNTRL_RAM_SIZE	(0x2000)
 
-#define DM646X_ATA_REG_BASE		(0x01C66000)
-
 #define DM646X_ASYNC_EMIF_CONTROL_BASE	0x20008000
 #define DM646X_ASYNC_EMIF_CS2_SPACE_BASE 0x42000000
 
 void __init dm646x_init(void);
-void __init dm646x_init_ide(void);
 void __init dm646x_init_mcasp0(struct snd_platform_data *pdata);
 void __init dm646x_init_mcasp1(struct snd_platform_data *pdata);
 void __init dm646x_board_setup_refclk(struct clk *clk);

From carnati at ebneuro.com  Wed Apr 21 09:37:38 2010
From: carnati at ebneuro.com (Emiliano Carnati)
Date: Wed, 21 Apr 2010 16:37:38 +0200
Subject: eMMC problem on omap-L137 
Message-ID: <9E7172901271444593588B761620E5AC@CARNATI>

Hi,
I've tried to connect a 16 GB eMMC to an omap l-137.
It is recognized and works almost all times, but...

Sometimes, at boot, I get the following error:

mmcblk0: error -110 requesting status
davinci_mmc davinci_mmc.0: still BUSY? bad ...
davinci_mmc davinci_mmc.0: still BUSY? bad ...
....

When it happens, the only solution seems to be a power off-on cycle. 
Does anybody have the same problem?
There is any tweak that I can try to mitigate the issue?

Thanks a lot!

Emiliano.

From mschnell at lumino.de  Wed Apr 21 10:23:37 2010
From: mschnell at lumino.de (Michael Schnell)
Date: Wed, 21 Apr 2010 17:23:37 +0200
Subject: AM1808
In-Reply-To: <0680EC522D0CC943BC586913CF3768C003B30BC363@dbde02.ent.ti.com>
References: <4BCEFC73.5090702@lumino.de>
	<0680EC522D0CC943BC586913CF3768C003B30BC363@dbde02.ent.ti.com>
Message-ID: <4BCF1879.3020203@lumino.de>

On 04/21/2010 03:38 PM, Syed Mohammed, Khasim wrote:
> Yes, it is right place to continue discussing AM1808 activities.
Great !
Thanks.

I'll be back :)

-Michael

From khilman at deeprootsystems.com  Wed Apr 21 11:58:41 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Wed, 21 Apr 2010 09:58:41 -0700
Subject: [PATCH] DAVINCI: Added missing includes
In-Reply-To: <1271856812-24588-1-git-send-email-thomas.koeller@baslerweb.com>
	(thomas koeller's message of "Wed\, 21 Apr 2010 15\:33\:32 +0200")
References: <1271856812-24588-1-git-send-email-thomas.koeller@baslerweb.com>
Message-ID: <87sk6oagji.fsf@deeprootsystems.com>

thomas.koeller at baslerweb.com writes:

> From: Thomas Koeller <thomas.koeller at baslerweb.com>
>
> linux/compiler.h is required for __iomem
> linux/types.h is required u32
>
> Signed-off-by: Thomas Koeller <thomas.koeller at baslerweb.com>

Thanks, applying and queueing for 2.6.35 in davinci-next.

Kevin

> ---
>  arch/arm/mach-davinci/include/mach/common.h |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
> index 1fd3917..f56fd5a 100644
> --- a/arch/arm/mach-davinci/include/mach/common.h
> +++ b/arch/arm/mach-davinci/include/mach/common.h
> @@ -12,6 +12,9 @@
>  #ifndef __ARCH_ARM_MACH_DAVINCI_COMMON_H
>  #define __ARCH_ARM_MACH_DAVINCI_COMMON_H
>  
> +#include <linux/compiler.h>
> +#include <linux/types.h>
> +
>  struct sys_timer;
>  
>  extern struct sys_timer davinci_timer;
> -- 
> 1.7.0.3
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From khilman at deeprootsystems.com  Wed Apr 21 12:51:51 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Wed, 21 Apr 2010 10:51:51 -0700
Subject: [PATCH] DaVinci: move IDE platform device to its proper place
In-Reply-To: <201004211811.34073.sshtylyov@ru.mvista.com> (Sergei Shtylyov's
	message of "Wed\, 21 Apr 2010 18\:11\:33 +0400")
References: <201004211811.34073.sshtylyov@ru.mvista.com>
Message-ID: <87iq7kae2w.fsf@deeprootsystems.com>

Sergei Shtylyov <sshtylyov at ru.mvista.com> writes:

> The IDE platform device is registered in three different places (2 board files
> for DM644x and in dm646x.c for DM646x) while both the IDE base address and the
> IDE IRQ are the same for both SoCs -- therefore,  the proper place for the IDE
> platform seems to be in devices.c. Merge the IDE platform data and registration
> code and create davinci_init_ide() in place of dm646x_init_ide()...
>
> Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>
>
> ---
> The patch is against the recent DaVinci tree.
> It has been tested on DM64{46|67}EVM boards.

Nice, Thanks.  

Applying and queueing for 2.6.35 in davinci-next branch.

Kevin

From khilman at deeprootsystems.com  Wed Apr 21 13:23:09 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Wed, 21 Apr 2010 11:23:09 -0700
Subject: [PATCH 4/4]-V3 Add MFD driver for TPS6507x family of
	multi-function chips and move TPS6507x regulator driver from
	being stand-alone to using the MFD driver.
In-Reply-To: <1270520639-20516-5-git-send-email-todd.fischer@ridgerun.com>
	(Todd Fischer's message of "Mon\, 5 Apr 2010 20\:23\:59 -0600")
References: <1270520639-20516-1-git-send-email-todd.fischer@ridgerun.com>
	<1270520639-20516-2-git-send-email-todd.fischer@ridgerun.com>
	<1270520639-20516-3-git-send-email-todd.fischer@ridgerun.com>
	<1270520639-20516-4-git-send-email-todd.fischer@ridgerun.com>
	<1270520639-20516-5-git-send-email-todd.fischer@ridgerun.com>
Message-ID: <87633kacmq.fsf@deeprootsystems.com>

Todd Fischer <todd.fischer at ridgerun.com> writes:

> Add MFD driver for TPS6507x family of multi-function chips.  Move TPS6507x 
> regulator driver from being stand-alone driver to using the MFD TPS6507x driver.
>
> Signed-off-by: Todd Fischer <todd.fischer at ridgerun.com>

[...]

Not sure whose tree this is queued in currently, but testing with
current davinci git, I had a compile problem...

> diff --git a/drivers/mfd/tps6507x.c b/drivers/mfd/tps6507x.c
> new file mode 100644
> index 0000000..5bca398
> --- /dev/null
> +++ b/drivers/mfd/tps6507x.c
> @@ -0,0 +1,155 @@
> +/*
> + * tps6507x.c  --  TPS6507x chip family multi-function driver
> + *
> + *  Copyright (c) 2010 RidgeRun (todd.fischer at ridgerun.com)
> + *
> + * Author: Todd Fischer
> + *         todd.fischer at ridgerun.com
> + *
> + * Credits:
> + *
> + *    Using code from wm831x-*.c, wm8400-core, Wolfson Microelectronics PLC.
> + *
> + * For licencing details see kernel-base/COPYING
> + *
> + */
> +
> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/init.h>
> +#include <linux/i2c.h>
> +#include <linux/mfd/core.h>
> +#include <linux/mfd/tps6507x.h>

Need an #include <linux/slab.h> here for kfree and kzalloc

Kevin

From nsekhar at ti.com  Thu Apr 22 04:45:17 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Thu, 22 Apr 2010 15:15:17 +0530
Subject: [PATCH 4/4] DM365: Add platform resource management
In-Reply-To: <C5A8FDEFF7647F4C9CB927D7DEB307730E530AA9@ahr075s.basler.corp>
References: <C5A8FDEFF7647F4C9CB927D7DEB307730E5309C7@ahr075s.basler.corp>
	<B85A65D85D7EB246BE421B3FB0FBB59301E6A1520A@dbde02.ent.ti.com>
	<C5A8FDEFF7647F4C9CB927D7DEB307730E530AA9@ahr075s.basler.corp>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E6A9A253@dbde02.ent.ti.com>


Hi Thomas,

On Wed, Apr 21, 2010 at 17:40:29, Koeller, T. wrote:
> From: Nori, Sekhar [mailto:nsekhar at ti.com]
>
> > IRQ resources are managed by request_irq(). EDMA does its own resource
> > management, but ideally should be using drivers/dma/ resource manager.
>
> This is not the kind of resource management I am talking about. You could
> call request_irq() with any bogus irq number (similar for DMA) and not notice
> that you are doing something wrong. You could attempt to set up an interrupt
> as shared that is not sharable. Look at linux/ioport.h for a lot of stuff
> designed to aid in avoiding such conflicts by proper use of resources.

I haven't seen any in-kernel driver where DMA and IRQ resources
are reserved using linux/ioport.h. Can you point to any such code?

A carefully placed typo should be able to trump any kind of
resource management you put in place. But, I agree, if there
is a way to make adding boards easy, that should be useful.

Thanks,
Sekhar


From Thomas.Koeller at baslerweb.com  Thu Apr 22 05:39:49 2010
From: Thomas.Koeller at baslerweb.com (Koeller, T.)
Date: Thu, 22 Apr 2010 12:39:49 +0200
Subject: [PATCH 4/4] DM365: Add platform resource management
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E6A9A253@dbde02.ent.ti.com>
References: <C5A8FDEFF7647F4C9CB927D7DEB307730E530AA9@ahr075s.basler.corp>
	<B85A65D85D7EB246BE421B3FB0FBB59301E6A9A253@dbde02.ent.ti.com>
Message-ID: <C5A8FDEFF7647F4C9CB927D7DEB307730E5B9DA8@ahr075s.basler.corp>

From: Nori, Sekhar [mailto:nsekhar at ti.com] 

> I haven't seen any in-kernel driver where DMA and IRQ resources
> are reserved using linux/ioport.h. Can you point to any such code?

No, of course not. My very point was that drivers are not supposed to
do resource management, this is a responsibility of the bus the
devices are on.

thanks,
Thomas

From nsekhar at ti.com  Thu Apr 22 06:03:43 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Thu, 22 Apr 2010 16:33:43 +0530
Subject: [PATCH 4/4] DM365: Add platform resource management
In-Reply-To: <C5A8FDEFF7647F4C9CB927D7DEB307730E5B9DA8@ahr075s.basler.corp>
References: <C5A8FDEFF7647F4C9CB927D7DEB307730E530AA9@ahr075s.basler.corp>
	<B85A65D85D7EB246BE421B3FB0FBB59301E6A9A253@dbde02.ent.ti.com>
	<C5A8FDEFF7647F4C9CB927D7DEB307730E5B9DA8@ahr075s.basler.corp>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E6A9A357@dbde02.ent.ti.com>

On Thu, Apr 22, 2010 at 16:09:49, Koeller, T. wrote:
> From: Nori, Sekhar [mailto:nsekhar at ti.com]
>
> > I haven't seen any in-kernel driver where DMA and IRQ resources
> > are reserved using linux/ioport.h. Can you point to any such code?
>
> No, of course not. My very point was that drivers are not supposed to
> do resource management, this is a responsibility of the bus the
> devices are on.

Okay. Sorry, but I have not seen any platforms doing this as well.
(of course, it doesn't help that I am familiar only with DaVinci).

Can you quote some example platform where this is being done?

Thanks,
Sekhar

From Thomas.Koeller at baslerweb.com  Thu Apr 22 11:40:06 2010
From: Thomas.Koeller at baslerweb.com (Koeller, T.)
Date: Thu, 22 Apr 2010 18:40:06 +0200
Subject: FW: [PATCH 4/4] DM365: Add platform resource management
Message-ID: <C5A8FDEFF7647F4C9CB927D7DEB307730E5B9F97@ahr075s.basler.corp>

From: Nori, Sekhar [mailto:nsekhar at ti.com]:
> Okay. Sorry, but I have not seen any platforms doing this as well.
> (of course, it doesn't help that I am familiar only with DaVinci).
> 
> Can you quote some example platform where this is being done?

See arch/mips/basler/excite, where I implemented this before.
This code has been removed recently (commit 7244be0905444e56f499e055f3ea51f26ec55c79),
as the hardware is out of production.

Thomas

From skiba.g at gmail.com  Thu Apr 22 13:27:13 2010
From: skiba.g at gmail.com (Grzegorz Skiba)
Date: Thu, 22 Apr 2010 20:27:13 +0200
Subject: MMC/SD problem - OMAPL137 EVM
Message-ID: <j2o38f801ba1004221127kc5971898r5a88fed0ebc98d8@mail.gmail.com>

I have problem with MMC/SD Linux device driver, I have OMAPL137 EVM board,
2.6.33-rc4 linux ver, form  DaVinci-PSP-SDK-03.20.00.11. Linux kernel
doesn't recognize either RS MMC or SD. I commented out part related to LCD
and NAND to make sure that pinmux configuration is ok. Even with default
config I'm unable to access to SD or MMC cord. I compiled MMC/SD driver with
debug and I this is what I get:

This is what I get without SD/MMC card:
    0.070000] Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
[    0.070000] serial8250.0: ttyS0 at MMIO 0x1c42000 (irq = 25) is a 16550A
[    0.070000] serial8250.0: ttyS1 at MMIO 0x1d0c000 (irq = 53) is a 16550A
[    0.070000] serial8250.0: ttyS2 at MMIO 0x1d0d000 (irq = 61) is a 16550A
[    0.080000] brd: module loaded
[    0.080000] spi_davinci spi_davinci.0: DaVinci SPI driver in EDMA mode
[    0.080000] Using RX channel = 14 , TX channel = 15 and event queue = 1
[    0.080000] spi_davinci spi_davinci.0: Controller at 0xfec41000
[    0.080000] console [netcon0] enabled
[    0.080000] netconsole: network logging started
[    0.080000] i2c /dev entries driver
[    0.080000] sdhci: Secure Digital Host Controller Interface driver
[    0.080000] sdhci: Copyright(c) Pierre Ossman
[    0.080000] davinci_mmc davinci_mmc.0: max_phys_segs=16
[    0.080000] davinci_mmc davinci_mmc.0: max_hw_segs=16
[    0.080000] davinci_mmc davinci_mmc.0: max_blk_size=4095
[    0.080000] davinci_mmc davinci_mmc.0: max_req_size=268365825
[    0.080000] davinci_mmc davinci_mmc.0: max_seg_size=2097120
[    0.080000] mmc0: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0
timing 0
[    0.080000] davinci_mmc davinci_mmc.0: clock 0Hz busmode 1 powermode 0
Vdd 0000
[    0.080000] davinci_mmc davinci_mmc.0: Disabling 4 bit mode
[    0.080000] davinci_mmc davinci_mmc.0: Using DMA, 4-bit mode

When I plug in SD card:

[    3.480000] Warning: unable to open an initial console.
[  282.080000] mmc0: clock 0Hz busmode 1 powermode 1 cs 0 Vdd 21 width 0
timing 0
[  282.080000] davinci_mmc davinci_mmc.0: clock 0Hz busmode 1 powermode 1
Vdd 0015
[  282.080000] davinci_mmc davinci_mmc.0: Disabling 4 bit mode
[  282.100000] mmc0: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 21 width
0 timing 0
[  282.100000] davinci_mmc davinci_mmc.0: clock 400000Hz busmode 1 powermode
2 Vdd 0015
[  282.100000] davinci_mmc davinci_mmc.0: Disabling 4 bit mode
[  282.120000] mmc0: clock 400000Hz busmode 1 powermode 2 cs 1 Vdd 21 width
0 timing 0
[  282.120000] davinci_mmc davinci_mmc.0: clock 400000Hz busmode 1 powermode
2 Vdd 0015
[  282.120000] davinci_mmc davinci_mmc.0: Disabling 4 bit mode
[  282.120000] mmc0: starting CMD0 arg 00000000 flags 000000c0
[  282.120000] davinci_mmc davinci_mmc.0: CMD0, arg 0x00000000, (R?
response)
[  282.120000] davinci_mmc davinci_mmc.0: unknown resp_type 0000
[  282.120000] mmc0: req done (CMD0): 0: 00000000 00000000 00000000 00000000
[  282.120000] mmc0: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 21 width
0 timing 0
[  282.120000] davinci_mmc davinci_mmc.0: clock 400000Hz busmode 1 powermode
2 Vdd 0015
[  282.120000] davinci_mmc davinci_mmc.0: Disabling 4 bit mode
[  282.120000] mmc0: starting CMD8 arg 000001aa flags 000002f5
[  282.120000] davinci_mmc davinci_mmc.0: CMD8, arg 0x000001aa, R1/R5/R6/R7
response
[  282.120000] mmc0: req done (CMD8): 0: 00000000 00000000 00000000 00000000
[  282.120000] mmc0: starting CMD5 arg 00000000 flags 000002e1
[  282.120000] davinci_mmc davinci_mmc.0: CMD5, arg 0x00000000, R3/R4
response
[  282.120000] mmc0: req done (CMD5): 0: 00000000 00000000 00000000 00000000
[  282.120000] mmc0: host doesn't support card's voltages

Here is kernel config related to MMC:
CONFIG_MMC=y
CONFIG_MMC_DEBUG=y
# CONFIG_MMC_UNSAFE_RESUME is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_SDHCI=y
# CONFIG_MMC_SDHCI_PLTFM is not set
# CONFIG_MMC_AT91 is not set
# CONFIG_MMC_ATMELMCI is not set
CONFIG_MMC_DAVINCI=y
# CONFIG_MMC_SPI is not set

Any ideas what I'm doing wrong ? I use 2 MB SD card and 1GB MMC card and I
have the same result
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100422/168f49e7/attachment.html>

From Andreas.Gaer at baslerweb.com  Fri Apr 23 04:32:17 2010
From: Andreas.Gaer at baslerweb.com (Gaer, A.)
Date: Fri, 23 Apr 2010 11:32:17 +0200
Subject: Layout of OOB data in NAND flash
Message-ID: <C5A8FDEFF7647F4C9CB927D7DEB307730682F671@ahr075s.basler.corp>

Hi!

It seems like the layout of OOB/4-Bit-ECC data in NAND flash differs from RBL/UBL to u-boot/linux (at least on a DM365 device). Is there any good reason for this?

As far as I understand, the RBL/UBL uses this layout (2048 byte pages):

(E = ECC byte, X = other oob)

XXXXXXEE
EEEEEEEE
XXXXXXEE
EEEEEEEE
XXXXXXEE
EEEEEEEE
XXXXXXEE
EEEEEEEE

The u-boot/linux drivers seems to use this instead:

XXXXXXXX
XXXXXXXX
XXXXXXXX
EEEEEEEE
EEEEEEEE
EEEEEEEE
EEEEEEEE
EEEEEEEE
 
The ECC bytes seem to be packed in the same way, though.

The different layout means that it is impossible to update UBL/u-boot from u-boot or linux.

I would really like to add a config option to u-boot/linux that enables the RBL/UBL layout also in u-boot/linux. Any objections to this?

Another question: 512 byte pages in linux seem to have a really funny oob layout

EEEEEXEE
XXXXXEEE

Does anybody know the reason for that? (I know the 6th byte is the manufacturer bad-block marker. But why not just put the ECC data into the last 10 byte of oob like RBL/UBL do it?)

Regards,
 Andreas.
_______________________________

Andreas G?er, Senior Software Engineer

Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany

Tel. +49 (0) 4102 - 463 517
Fax +49 (0) 4102 - 463 46 517 

mailto:Andreas.Gaer at baslerweb.com
http://www.baslerweb.com

Vorstand: Dr.-Ing. Dietmar Ley (Vorsitzender) ? John P. Jennings ? Aufsichtsratsvorsitzender: Norbert Basler Basler AG ? Amtsgericht Ahrensburg HRB 4090 ? Ust-IdNr.: DE 135 098 121 ? Steuer-Nr.: 30 292 04497 ? WEEE-Reg.-Nr. DE 83888045

_______________________________


From cyril at ti.com  Fri Apr 23 12:56:52 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 23 Apr 2010 13:56:52 -0400
Subject: [PATCH v4 01/13] Davinci: generalized debug macros
In-Reply-To: <1272045424-19240-1-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
Message-ID: <1272045424-19240-2-git-send-email-cyril@ti.com>

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 macros through a small chunk of memory placed just
below the page tables (@0x80003ff8).

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
v4: unchanged from v3

 arch/arm/mach-davinci/include/mach/debug-macro.S |   51 +++++++++++---
 arch/arm/mach-davinci/include/mach/serial.h      |   13 ++++
 arch/arm/mach-davinci/include/mach/uncompress.h  |   80 ++++++++++++++++------
 3 files changed, 112 insertions(+), 32 deletions(-)

diff --git a/arch/arm/mach-davinci/include/mach/debug-macro.S b/arch/arm/mach-davinci/include/mach/debug-macro.S
index 3cd93a8..ac0fa02 100644
--- a/arch/arm/mach-davinci/include/mach/debug-macro.S
+++ b/arch/arm/mach-davinci/include/mach/debug-macro.S
@@ -17,22 +17,51 @@
  */
 
 #include <linux/serial_reg.h>
+
+#include <asm/memory.h>
+
+#include <mach/serial.h>
+
 #define UART_SHIFT	2
 
+		.pushsection .data
+davinci_uart_phys:	.word	0
+davinci_uart_virt:	.word	0
+		.popsection
+
 		.macro addruart, rx, tmp
+
+		/* Use davinci_uart_phys/virt if already configured */
+10:		mrc	p15, 0, \rx, c1, c0
+		tst	\rx, #1			@ MMU enabled?
+		ldreq	\rx, =__virt_to_phys(davinci_uart_phys)
+		ldrne	\rx, =davinci_uart_virt
+		ldr	\rx, [\rx]
+		cmp	\rx, #0			@ is port configured?
+		bne	99f			@ already configured
+
+		/* Copy uart phys address from decompressor uart info */
 		mrc	p15, 0, \rx, c1, c0
 		tst	\rx, #1			@ MMU enabled?
-		moveq	\rx, #0x01000000	@ physical base address
-		movne	\rx, #0xfe000000	@ virtual base
-#if defined(CONFIG_ARCH_DAVINCI_DA8XX) && defined(CONFIG_ARCH_DAVINCI_DMx)
-#error Cannot enable DaVinci and DA8XX platforms concurrently
-#elif defined(CONFIG_MACH_DAVINCI_DA830_EVM) || \
-	defined(CONFIG_MACH_DAVINCI_DA850_EVM)
-		orr	\rx, \rx, #0x00d00000	@ physical base address
-		orr	\rx, \rx, #0x0000d000	@ of UART 2
-#else
-		orr	\rx, \rx, #0x00c20000   @ UART 0
-#endif
+		ldreq	\tmp, =__virt_to_phys(davinci_uart_phys)
+		ldrne	\tmp, =davinci_uart_phys
+		ldreq	\rx, =DAVINCI_UART_INFO
+		ldrne	\rx, =__phys_to_virt(DAVINCI_UART_INFO)
+		ldr	\rx, [\rx, #0]
+		str	\rx, [\tmp]
+
+		/* Copy uart virt address from decompressor uart info */
+		mrc	p15, 0, \rx, c1, c0
+		tst	\rx, #1			@ MMU enabled?
+		ldreq	\tmp, =__virt_to_phys(davinci_uart_virt)
+		ldrne	\tmp, =davinci_uart_virt
+		ldreq	\rx, =DAVINCI_UART_INFO
+		ldrne	\rx, =__phys_to_virt(DAVINCI_UART_INFO)
+		ldr	\rx, [\rx, #4]
+		str	\rx, [\tmp]
+
+		b	10b
+99:
 		.endm
 
 		.macro	senduart,rd,rx
diff --git a/arch/arm/mach-davinci/include/mach/serial.h b/arch/arm/mach-davinci/include/mach/serial.h
index a584697..8829dde 100644
--- a/arch/arm/mach-davinci/include/mach/serial.h
+++ b/arch/arm/mach-davinci/include/mach/serial.h
@@ -11,8 +11,19 @@
 #ifndef __ASM_ARCH_SERIAL_H
 #define __ASM_ARCH_SERIAL_H
 
+#include <asm/memory.h>
+
 #include <mach/hardware.h>
 
+/*
+ * Stolen area that contains debug uart physical and virtual addresses.  These
+ * addresses are filled in by the uncompress.h code, and are used by the debug
+ * macros in debug-macro.S.
+ *
+ * This area sits just below the page tables (see arch/arm/kernel/head.S).
+ */
+#define DAVINCI_UART_INFO	(PHYS_OFFSET + 0x3ff8)
+
 #define DAVINCI_MAX_NR_UARTS	3
 #define DAVINCI_UART0_BASE	(IO_PHYS + 0x20000)
 #define DAVINCI_UART1_BASE	(IO_PHYS + 0x20400)
@@ -27,11 +38,13 @@
 #define UART_DM646X_SCR			0x10
 #define UART_DM646X_SCR_TX_WATERMARK	0x08
 
+#ifndef __ASSEMBLY__
 struct davinci_uart_config {
 	/* Bit field of UARTs present; bit 0 --> UART1 */
 	unsigned int enabled_uarts;
 };
 
 extern int davinci_serial_init(struct davinci_uart_config *);
+#endif
 
 #endif /* __ASM_ARCH_SERIAL_H */
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
index 33796b4..20c23a3 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -1,8 +1,17 @@
 /*
  * Serial port stubs for kernel decompress status messages
  *
- *  Author:     Anant Gole
- * (C) Copyright (C) 2006, Texas Instruments, Inc
+ * Initially based on:
+ * arch/arm/plat-omap/include/mach/uncompress.h
+ *
+ * Original copyrights follow.
+ *
+ * Copyright (C) 2000 RidgeRun, Inc.
+ * Author: Greg Lonnon <glonnon at ridgerun.com>
+ *
+ * Rewritten by:
+ * Author: <source at mvista.com>
+ * 2004 (c) MontaVista Software, Inc.
  *
  * This file is licensed under the terms of the GNU General Public License
  * version 2. This program is licensed "as is" without any warranty of any
@@ -11,30 +20,17 @@
 
 #include <linux/types.h>
 #include <linux/serial_reg.h>
-#include <mach/serial.h>
 
 #include <asm/mach-types.h>
 
-extern unsigned int __machine_arch_type;
+#include <mach/serial.h>
 
 static u32 *uart;
-
-static u32 *get_uart_base(void)
-{
-	if (__machine_arch_type == MACH_TYPE_DAVINCI_DA830_EVM ||
-		__machine_arch_type == MACH_TYPE_DAVINCI_DA850_EVM)
-		return (u32 *)DA8XX_UART2_BASE;
-	else
-		return (u32 *)DAVINCI_UART0_BASE;
-}
+static u32 *uart_info = (u32 *)(DAVINCI_UART_INFO);
 
 /* PORT_16C550A, in polled non-fifo mode */
-
 static void putc(char c)
 {
-	if (!uart)
-		uart = get_uart_base();
-
 	while (!(uart[UART_LSR] & UART_LSR_THRE))
 		barrier();
 	uart[UART_TX] = c;
@@ -42,12 +38,54 @@ static void putc(char c)
 
 static inline void flush(void)
 {
-	if (!uart)
-		uart = get_uart_base();
-
 	while (!(uart[UART_LSR] & UART_LSR_THRE))
 		barrier();
 }
 
-#define arch_decomp_setup()
+static inline void set_uart_info(u32 phys, void * __iomem virt)
+{
+	uart = (u32 *)phys;
+	uart_info[0] = phys;
+	uart_info[1] = (u32)virt;
+}
+
+#define _DEBUG_LL_ENTRY(machine, phys, virt)			\
+	if (machine_is_##machine()) {				\
+		set_uart_info(phys, virt);			\
+		break;						\
+	}
+
+#define DEBUG_LL_DAVINCI(machine, port)				\
+	_DEBUG_LL_ENTRY(machine, DAVINCI_UART##port##_BASE,	\
+			IO_ADDRESS(DAVINCI_UART##port##_BASE))
+
+#define DEBUG_LL_DA8XX(machine, port)				\
+	_DEBUG_LL_ENTRY(machine, DA8XX_UART##port##_BASE,	\
+			IO_ADDRESS(DA8XX_UART##port##_BASE))
+
+static inline void __arch_decomp_setup(unsigned long arch_id)
+{
+	/*
+	 * Initialize the port based on the machine ID from the bootloader.
+	 * Note that we're using macros here instead of switch statement
+	 * as machine_is functions are optimized out for the boards that
+	 * are not selected.
+	 */
+	do {
+		/* Davinci boards */
+		DEBUG_LL_DAVINCI(davinci_evm,		0);
+		DEBUG_LL_DAVINCI(sffsdr,		0);
+		DEBUG_LL_DAVINCI(neuros_osd2,		0);
+		DEBUG_LL_DAVINCI(davinci_dm355_evm,	0);
+		DEBUG_LL_DAVINCI(dm355_leopard,		0);
+		DEBUG_LL_DAVINCI(davinci_dm6467_evm,	0);
+		DEBUG_LL_DAVINCI(davinci_dm365_evm,	0);
+
+		/* DA8xx boards */
+		DEBUG_LL_DA8XX(davinci_da830_evm,	2);
+		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
+	} while (0);
+}
+
+#define arch_decomp_setup()	__arch_decomp_setup(arch_id)
 #define arch_decomp_wdog()
-- 
1.6.3.3


From cyril at ti.com  Fri Apr 23 12:56:54 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 23 Apr 2010 13:56:54 -0400
Subject: [PATCH v4 03/13] Davinci: gpio - structs and functions renamed
In-Reply-To: <1272045424-19240-3-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
Message-ID: <1272045424-19240-4-git-send-email-cyril@ti.com>

Renamed gpio types to something more sensible:
	struct gpio_controller	--> struct davinci_gpio_regs
	struct davinci_gpio	--> struct davinci_gpio_controller
	gpio2controller()	--> gpio2regs()
	irq2controller()	--> irq2regs()

This change also moves davinci_gpio_controller definition to gpio.h.
Eventually, the gpio registers structure will be moved to gpio.c and no longer
a common cross-soc definition.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
v4: renamed irq2controller as per Sergei's comment

 arch/arm/mach-davinci/gpio.c              |   50 +++++++++++++----------------
 arch/arm/mach-davinci/include/mach/gpio.h |   14 ++++++--
 2 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index 93f7c68..c77683c 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -22,28 +22,22 @@
 
 static DEFINE_SPINLOCK(gpio_lock);
 
-struct davinci_gpio {
-	struct gpio_chip	chip;
-	struct gpio_controller	__iomem *regs;
-	int			irq_base;
-};
-
 #define chip2controller(chip)	\
-	container_of(chip, struct davinci_gpio, chip)
+	container_of(chip, struct davinci_gpio_controller, chip)
 
-static struct davinci_gpio chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
+static struct davinci_gpio_controller chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
 
 /* create a non-inlined version */
-static struct gpio_controller __iomem __init *gpio2controller(unsigned gpio)
+static struct davinci_gpio_regs __iomem __init *gpio2regs(unsigned gpio)
 {
 	return __gpio_to_controller(gpio);
 }
 
-static inline struct gpio_controller __iomem *irq2controller(int irq)
+static inline struct davinci_gpio_regs __iomem *irq2regs(int irq)
 {
-	struct gpio_controller __iomem *g;
+	struct davinci_gpio_regs __iomem *g;
 
-	g = (__force struct gpio_controller __iomem *)get_irq_chip_data(irq);
+	g = (__force struct davinci_gpio_regs __iomem *)get_irq_chip_data(irq);
 
 	return g;
 }
@@ -60,8 +54,8 @@ static int __init davinci_gpio_irq_setup(void);
 static inline int __davinci_direction(struct gpio_chip *chip,
 			unsigned offset, bool out, int value)
 {
-	struct davinci_gpio *d = chip2controller(chip);
-	struct gpio_controller __iomem *g = d->regs;
+	struct davinci_gpio_controller *d = chip2controller(chip);
+	struct davinci_gpio_regs __iomem *g = d->regs;
 	u32 temp;
 	u32 mask = 1 << offset;
 
@@ -99,8 +93,8 @@ davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
  */
 static int davinci_gpio_get(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = chip2controller(chip);
-	struct gpio_controller __iomem *g = d->regs;
+	struct davinci_gpio_controller *d = chip2controller(chip);
+	struct davinci_gpio_regs __iomem *g = d->regs;
 
 	return (1 << offset) & __raw_readl(&g->in_data);
 }
@@ -111,8 +105,8 @@ static int davinci_gpio_get(struct gpio_chip *chip, unsigned offset)
 static void
 davinci_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
 {
-	struct davinci_gpio *d = chip2controller(chip);
-	struct gpio_controller __iomem *g = d->regs;
+	struct davinci_gpio_controller *d = chip2controller(chip);
+	struct davinci_gpio_regs __iomem *g = d->regs;
 
 	__raw_writel((1 << offset), value ? &g->set_data : &g->clr_data);
 }
@@ -150,7 +144,7 @@ static int __init davinci_gpio_setup(void)
 		if (chips[i].chip.ngpio > 32)
 			chips[i].chip.ngpio = 32;
 
-		chips[i].regs = gpio2controller(base);
+		chips[i].regs = gpio2regs(base);
 
 		gpiochip_add(&chips[i].chip);
 	}
@@ -174,7 +168,7 @@ pure_initcall(davinci_gpio_setup);
 
 static void gpio_irq_disable(unsigned irq)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2regs(irq);
 	u32 mask = (u32) get_irq_data(irq);
 
 	__raw_writel(mask, &g->clr_falling);
@@ -183,7 +177,7 @@ static void gpio_irq_disable(unsigned irq)
 
 static void gpio_irq_enable(unsigned irq)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2regs(irq);
 	u32 mask = (u32) get_irq_data(irq);
 	unsigned status = irq_desc[irq].status;
 
@@ -199,7 +193,7 @@ static void gpio_irq_enable(unsigned irq)
 
 static int gpio_irq_type(unsigned irq, unsigned trigger)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2regs(irq);
 	u32 mask = (u32) get_irq_data(irq);
 
 	if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
@@ -228,7 +222,7 @@ static struct irq_chip gpio_irqchip = {
 static void
 gpio_irq_handler(unsigned irq, struct irq_desc *desc)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2regs(irq);
 	u32 mask = 0xffff;
 
 	/* we only care about one bank */
@@ -266,7 +260,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
 
 static int gpio_to_irq_banked(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = chip2controller(chip);
+	struct davinci_gpio_controller *d = chip2controller(chip);
 
 	if (d->irq_base >= 0)
 		return d->irq_base + offset;
@@ -289,7 +283,7 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset)
 
 static int gpio_irq_type_unbanked(unsigned irq, unsigned trigger)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2regs(irq);
 	u32 mask = (u32) get_irq_data(irq);
 
 	if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
@@ -318,7 +312,7 @@ static int __init davinci_gpio_irq_setup(void)
 	u32		binten = 0;
 	unsigned	ngpio, bank_irq;
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
-	struct gpio_controller	__iomem *g;
+	struct davinci_gpio_regs	__iomem *g;
 
 	ngpio = soc_info->gpio_num;
 
@@ -367,7 +361,7 @@ static int __init davinci_gpio_irq_setup(void)
 		gpio_irqchip_unbanked.set_type = gpio_irq_type_unbanked;
 
 		/* default trigger: both edges */
-		g = gpio2controller(0);
+		g = gpio2regs(0);
 		__raw_writel(~0, &g->set_falling);
 		__raw_writel(~0, &g->set_rising);
 
@@ -392,7 +386,7 @@ static int __init davinci_gpio_irq_setup(void)
 		unsigned		i;
 
 		/* disabled by default, enabled only as needed */
-		g = gpio2controller(gpio);
+		g = gpio2regs(gpio);
 		__raw_writel(~0, &g->clr_falling);
 		__raw_writel(~0, &g->clr_rising);
 
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index 0099e6e..bdab001 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -45,7 +45,7 @@
 /* Convert GPIO signal to GPIO pin number */
 #define GPIO_TO_PIN(bank, gpio)	(16 * (bank) + (gpio))
 
-struct gpio_controller {
+struct davinci_gpio_regs {
 	u32	dir;
 	u32	out_data;
 	u32	set_data;
@@ -58,6 +58,12 @@ struct gpio_controller {
 	u32	intstat;
 };
 
+struct davinci_gpio_controller {
+	struct davinci_gpio_regs __iomem *regs;
+	struct gpio_chip	chip;
+	int			irq_base;
+};
+
 /* The __gpio_to_controller() and __gpio_mask() functions inline to constants
  * with constant parameters; or in outlined code they execute at runtime.
  *
@@ -67,7 +73,7 @@ struct gpio_controller {
  *
  * These are NOT part of the cross-platform GPIO interface
  */
-static inline struct gpio_controller __iomem *
+static inline struct davinci_gpio_regs __iomem *
 __gpio_to_controller(unsigned gpio)
 {
 	void __iomem *ptr;
@@ -102,7 +108,7 @@ static inline u32 __gpio_mask(unsigned gpio)
 static inline void gpio_set_value(unsigned gpio, int value)
 {
 	if (__builtin_constant_p(value) && gpio < DAVINCI_N_GPIO) {
-		struct gpio_controller	__iomem *g;
+		struct davinci_gpio_regs	__iomem *g;
 		u32			mask;
 
 		g = __gpio_to_controller(gpio);
@@ -128,7 +134,7 @@ static inline void gpio_set_value(unsigned gpio, int value)
  */
 static inline int gpio_get_value(unsigned gpio)
 {
-	struct gpio_controller	__iomem *g;
+	struct davinci_gpio_regs	__iomem *g;
 
 	if (!__builtin_constant_p(gpio) || gpio >= DAVINCI_N_GPIO)
 		return __gpio_get_value(gpio);
-- 
1.6.3.3


From cyril at ti.com  Fri Apr 23 12:56:55 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 23 Apr 2010 13:56:55 -0400
Subject: [PATCH v4 04/13] Davinci: gpio - register layout invariant inlines
In-Reply-To: <1272045424-19240-4-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
Message-ID: <1272045424-19240-5-git-send-email-cyril@ti.com>

This patch renders the inlined gpio accessors in gpio.h independent of the
underlying controller's register layout.  This is done by including three new
fields in davinci_gpio_controller to hold the addresses of the set, clear, and
in data registers.

Other changes:

1. davinci_gpio_regs structure definition moved to gpio.c.  This structure is
no longer common across all davinci socs (davinci_gpio_controller is).

2. controller base address calculation code (gpio2controller()) moved to
gpio.c as this was no longer necessary for the inline implementation.

3. modified inline range checks to use davinci_soc_info.gpio_num instead of
DAVINCI_N_GPIO.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/gpio.c                |   41 ++++++++++++++++-
 arch/arm/mach-davinci/include/mach/common.h |    4 ++
 arch/arm/mach-davinci/include/mach/gpio.h   |   65 +++++++++-----------------
 3 files changed, 65 insertions(+), 45 deletions(-)

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index c77683c..d241b4f 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -20,6 +20,19 @@
 
 #include <asm/mach/irq.h>
 
+struct davinci_gpio_regs {
+	u32	dir;
+	u32	out_data;
+	u32	set_data;
+	u32	clr_data;
+	u32	in_data;
+	u32	set_rising;
+	u32	clr_rising;
+	u32	set_falling;
+	u32	clr_falling;
+	u32	intstat;
+};
+
 static DEFINE_SPINLOCK(gpio_lock);
 
 #define chip2controller(chip)	\
@@ -27,10 +40,24 @@ static DEFINE_SPINLOCK(gpio_lock);
 
 static struct davinci_gpio_controller chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
 
-/* create a non-inlined version */
 static struct davinci_gpio_regs __iomem __init *gpio2regs(unsigned gpio)
 {
-	return __gpio_to_controller(gpio);
+	void __iomem *ptr;
+	void __iomem *base = davinci_soc_info.gpio_base;
+
+	if (gpio < 32 * 1)
+		ptr = base + 0x10;
+	else if (gpio < 32 * 2)
+		ptr = base + 0x38;
+	else if (gpio < 32 * 3)
+		ptr = base + 0x60;
+	else if (gpio < 32 * 4)
+		ptr = base + 0x88;
+	else if (gpio < 32 * 5)
+		ptr = base + 0xb0;
+	else
+		ptr = NULL;
+	return ptr;
 }
 
 static inline struct davinci_gpio_regs __iomem *irq2regs(int irq)
@@ -116,6 +143,7 @@ static int __init davinci_gpio_setup(void)
 	int i, base;
 	unsigned ngpio;
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
+	struct davinci_gpio_regs *regs;
 
 	/*
 	 * The gpio banks conceptually expose a segmented bitmap,
@@ -144,11 +172,18 @@ static int __init davinci_gpio_setup(void)
 		if (chips[i].chip.ngpio > 32)
 			chips[i].chip.ngpio = 32;
 
-		chips[i].regs = gpio2regs(base);
+		regs = gpio2regs(base);
+		chips[i].regs = regs;
+		chips[i].set_data = &regs->set_data;
+		chips[i].clr_data = &regs->clr_data;
+		chips[i].in_data = &regs->in_data;
 
 		gpiochip_add(&chips[i].chip);
 	}
 
+	soc_info->gpio_ctlrs = chips;
+	soc_info->gpio_ctlrs_num = DIV_ROUND_UP(ngpio, 32);
+
 	davinci_gpio_irq_setup();
 	return 0;
 }
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 884dc72..1d72883 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -37,6 +37,8 @@ struct davinci_timer_info {
 	unsigned int			clocksource_id;
 };
 
+struct davinci_gpio_controller;
+
 /* SoC specific init support */
 struct davinci_soc_info {
 	struct map_desc			*io_desc;
@@ -61,6 +63,8 @@ struct davinci_soc_info {
 	unsigned			gpio_num;
 	unsigned			gpio_irq;
 	unsigned			gpio_unbanked;
+	struct davinci_gpio_controller	*gpio_ctlrs;
+	int				gpio_ctlrs_num;
 	struct platform_device		*serial_dev;
 	struct emac_platform_data	*emac_pdata;
 	dma_addr_t			sram_dma;
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index bdab001..82591d0 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -45,23 +45,13 @@
 /* Convert GPIO signal to GPIO pin number */
 #define GPIO_TO_PIN(bank, gpio)	(16 * (bank) + (gpio))
 
-struct davinci_gpio_regs {
-	u32	dir;
-	u32	out_data;
-	u32	set_data;
-	u32	clr_data;
-	u32	in_data;
-	u32	set_rising;
-	u32	clr_rising;
-	u32	set_falling;
-	u32	clr_falling;
-	u32	intstat;
-};
-
 struct davinci_gpio_controller {
-	struct davinci_gpio_regs __iomem *regs;
 	struct gpio_chip	chip;
 	int			irq_base;
+	void __iomem		*regs;
+	void __iomem		*set_data;
+	void __iomem		*clr_data;
+	void __iomem		*in_data;
 };
 
 /* The __gpio_to_controller() and __gpio_mask() functions inline to constants
@@ -73,25 +63,16 @@ struct davinci_gpio_controller {
  *
  * These are NOT part of the cross-platform GPIO interface
  */
-static inline struct davinci_gpio_regs __iomem *
+static inline struct davinci_gpio_controller *
 __gpio_to_controller(unsigned gpio)
 {
-	void __iomem *ptr;
-	void __iomem *base = davinci_soc_info.gpio_base;
-
-	if (gpio < 32 * 1)
-		ptr = base + 0x10;
-	else if (gpio < 32 * 2)
-		ptr = base + 0x38;
-	else if (gpio < 32 * 3)
-		ptr = base + 0x60;
-	else if (gpio < 32 * 4)
-		ptr = base + 0x88;
-	else if (gpio < 32 * 5)
-		ptr = base + 0xb0;
-	else
-		ptr = NULL;
-	return ptr;
+	struct davinci_gpio_controller *ctlrs = davinci_soc_info.gpio_ctlrs;
+	int index = gpio / 32;
+
+	if (!ctlrs || index >= davinci_soc_info.gpio_ctlrs_num)
+		return NULL;
+
+	return ctlrs + index;
 }
 
 static inline u32 __gpio_mask(unsigned gpio)
@@ -107,16 +88,16 @@ static inline u32 __gpio_mask(unsigned gpio)
  */
 static inline void gpio_set_value(unsigned gpio, int value)
 {
-	if (__builtin_constant_p(value) && gpio < DAVINCI_N_GPIO) {
-		struct davinci_gpio_regs	__iomem *g;
-		u32			mask;
+	if (__builtin_constant_p(value) && gpio < davinci_soc_info.gpio_num) {
+		struct davinci_gpio_controller *ctlr;
+		u32				mask;
 
-		g = __gpio_to_controller(gpio);
+		ctlr = __gpio_to_controller(gpio);
 		mask = __gpio_mask(gpio);
 		if (value)
-			__raw_writel(mask, &g->set_data);
+			__raw_writel(mask, ctlr->set_data);
 		else
-			__raw_writel(mask, &g->clr_data);
+			__raw_writel(mask, ctlr->clr_data);
 		return;
 	}
 
@@ -134,18 +115,18 @@ static inline void gpio_set_value(unsigned gpio, int value)
  */
 static inline int gpio_get_value(unsigned gpio)
 {
-	struct davinci_gpio_regs	__iomem *g;
+	struct davinci_gpio_controller *ctlr;
 
-	if (!__builtin_constant_p(gpio) || gpio >= DAVINCI_N_GPIO)
+	if (!__builtin_constant_p(gpio) || gpio >= davinci_soc_info.gpio_num)
 		return __gpio_get_value(gpio);
 
-	g = __gpio_to_controller(gpio);
-	return __gpio_mask(gpio) & __raw_readl(&g->in_data);
+	ctlr = __gpio_to_controller(gpio);
+	return __gpio_mask(gpio) & __raw_readl(ctlr->in_data);
 }
 
 static inline int gpio_cansleep(unsigned gpio)
 {
-	if (__builtin_constant_p(gpio) && gpio < DAVINCI_N_GPIO)
+	if (__builtin_constant_p(gpio) && gpio < davinci_soc_info.gpio_num)
 		return 0;
 	else
 		return __gpio_cansleep(gpio);
-- 
1.6.3.3


From cyril at ti.com  Fri Apr 23 12:56:51 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 23 Apr 2010 13:56:51 -0400
Subject: [PATCH v4 00/13] Davinci: initial tnetv107x patch series
Message-ID: <1272045424-19240-1-git-send-email-cyril@ti.com>

Hi,

This patch series adds support for TNETV107X - a Texas Instruments SOC that
shares a number of common features with the Davinci architecture.

Changes in this patch series (against v3):
	- gpio - renamed irq2controller(), restored direction_in/out cleanup
	- simplified pinmux register offset definitions across the board
	- ioremap() interception as per Kevin's recommendations
	- reimplemented watchdog reset separation to avoid cpu_is_ checks in
	  common code.  correspondingly eliminated unused cpu_class_ macros.
	- macroized tnetv107x clock definitions to reduce code volume
	- moved all tnetv107x platform_device definitions into soc code,
	  accessible to board specific code via tnetv107x_devices_init()
	- updated copyright headers

These changes were tested on tnetv107x evm and on dm365 evm (thanks to Sandeep
Paulraj).  On account of platform unavailability, da8xx architecture was _not_
tested with this patch series.

- Cyril.


Cyril Chemparathy (13):
  Davinci: generalized debug macros
  Davinci: gpio - minor cleanup
  Davinci: gpio - struct renames
  Davinci: gpio - register layout invariant inlines
  Davinci: gpio - controller type support
  Davinci: gpio - fine grained locking
  Davinci: eliminate pinmux offset verbosity
  Davinci: iotable based ioremap() interception
  Davinci: watchdog reset separation across socs
  Davinci: tnetv107x decompresser uart definitions
  Davinci: tnetv107x soc support
  Davinci: tnetv107x initial gpio support
  Davinci: tnetv107x evm board initial support

 arch/arm/mach-davinci/Kconfig                    |   12 +
 arch/arm/mach-davinci/Makefile                   |    3 +
 arch/arm/mach-davinci/board-tnetv107x-evm.c      |  171 +++++
 arch/arm/mach-davinci/clock.h                    |    1 +
 arch/arm/mach-davinci/common.c                   |   14 +-
 arch/arm/mach-davinci/da830.c                    |    5 +
 arch/arm/mach-davinci/da850.c                    |    5 +
 arch/arm/mach-davinci/devices-da8xx.c            |    4 +-
 arch/arm/mach-davinci/devices-tnetv107x.c        |  347 +++++++++
 arch/arm/mach-davinci/dm355.c                    |    8 +-
 arch/arm/mach-davinci/dm365.c                    |    8 +-
 arch/arm/mach-davinci/dm644x.c                   |    5 +-
 arch/arm/mach-davinci/dm646x.c                   |    5 +-
 arch/arm/mach-davinci/gpio-tnetv107x.c           |  205 ++++++
 arch/arm/mach-davinci/gpio.c                     |  137 +++--
 arch/arm/mach-davinci/include/mach/common.h      |    7 +
 arch/arm/mach-davinci/include/mach/da8xx.h       |   23 +-
 arch/arm/mach-davinci/include/mach/debug-macro.S |   51 +-
 arch/arm/mach-davinci/include/mach/gpio.h        |   73 +-
 arch/arm/mach-davinci/include/mach/io.h          |    5 +
 arch/arm/mach-davinci/include/mach/serial.h      |   21 +
 arch/arm/mach-davinci/include/mach/system.h      |    5 +-
 arch/arm/mach-davinci/include/mach/tnetv107x.h   |   55 ++
 arch/arm/mach-davinci/include/mach/uncompress.h  |   87 ++-
 arch/arm/mach-davinci/io.c                       |   49 ++-
 arch/arm/mach-davinci/mux.h                      |    2 +-
 arch/arm/mach-davinci/time.c                     |    9 +-
 arch/arm/mach-davinci/tnetv107x.c                |  841 ++++++++++++++++++++++
 28 files changed, 1980 insertions(+), 178 deletions(-)
 create mode 100644 arch/arm/mach-davinci/board-tnetv107x-evm.c
 create mode 100644 arch/arm/mach-davinci/devices-tnetv107x.c
 create mode 100644 arch/arm/mach-davinci/gpio-tnetv107x.c
 create mode 100644 arch/arm/mach-davinci/include/mach/tnetv107x.h
 create mode 100644 arch/arm/mach-davinci/tnetv107x.c


From cyril at ti.com  Fri Apr 23 12:56:53 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 23 Apr 2010 13:56:53 -0400
Subject: [PATCH v4 02/13] Davinci: gpio - minor cleanup
In-Reply-To: <1272045424-19240-2-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
Message-ID: <1272045424-19240-3-git-send-email-cyril@ti.com>

macroized repeated container_of()s to improve readability.
unified direction in/out functions.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/gpio.c |   50 ++++++++++++++++++++++-------------------
 1 files changed, 27 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index 5476ad1..93f7c68 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -28,6 +28,9 @@ struct davinci_gpio {
 	int			irq_base;
 };
 
+#define chip2controller(chip)	\
+	container_of(chip, struct davinci_gpio, chip)
+
 static struct davinci_gpio chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
 
 /* create a non-inlined version */
@@ -54,21 +57,39 @@ static int __init davinci_gpio_irq_setup(void);
  * needed, and enable the GPIO clock.
  */
 
-static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
+static inline int __davinci_direction(struct gpio_chip *chip,
+			unsigned offset, bool out, int value)
 {
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+	struct davinci_gpio *d = chip2controller(chip);
 	struct gpio_controller __iomem *g = d->regs;
 	u32 temp;
+	u32 mask = 1 << offset;
 
 	spin_lock(&gpio_lock);
 	temp = __raw_readl(&g->dir);
-	temp |= (1 << offset);
+	if (out) {
+		temp &= ~mask;
+		__raw_writel(mask, value ? &g->set_data : &g->clr_data);
+	} else {
+		temp |= mask;
+	}
 	__raw_writel(temp, &g->dir);
 	spin_unlock(&gpio_lock);
 
 	return 0;
 }
 
+static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
+{
+	return __davinci_direction(chip, offset, false, 0);
+}
+
+static int
+davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
+{
+	return __davinci_direction(chip, offset, true, value);
+}
+
 /*
  * Read the pin's value (works even if it's set up as output);
  * returns zero/nonzero.
@@ -78,36 +99,19 @@ static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
  */
 static int davinci_gpio_get(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+	struct davinci_gpio *d = chip2controller(chip);
 	struct gpio_controller __iomem *g = d->regs;
 
 	return (1 << offset) & __raw_readl(&g->in_data);
 }
 
-static int
-davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
-{
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
-	struct gpio_controller __iomem *g = d->regs;
-	u32 temp;
-	u32 mask = 1 << offset;
-
-	spin_lock(&gpio_lock);
-	temp = __raw_readl(&g->dir);
-	temp &= ~mask;
-	__raw_writel(mask, value ? &g->set_data : &g->clr_data);
-	__raw_writel(temp, &g->dir);
-	spin_unlock(&gpio_lock);
-	return 0;
-}
-
 /*
  * Assuming the pin is muxed as a gpio output, set its output value.
  */
 static void
 davinci_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
 {
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+	struct davinci_gpio *d = chip2controller(chip);
 	struct gpio_controller __iomem *g = d->regs;
 
 	__raw_writel((1 << offset), value ? &g->set_data : &g->clr_data);
@@ -262,7 +266,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
 
 static int gpio_to_irq_banked(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+	struct davinci_gpio *d = chip2controller(chip);
 
 	if (d->irq_base >= 0)
 		return d->irq_base + offset;
-- 
1.6.3.3


From cyril at ti.com  Fri Apr 23 12:56:56 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 23 Apr 2010 13:56:56 -0400
Subject: [PATCH v4 05/13] Davinci: gpio - controller type support
In-Reply-To: <1272045424-19240-5-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
Message-ID: <1272045424-19240-6-git-send-email-cyril@ti.com>

This patch allows for gpio controllers that deviate from those found on
traditional davinci socs.  davinci_soc_info has an added field to indicate the
soc-specific gpio controller type.  The gpio initialization code then bails
out of necessary.

More elements (tnetv107x) to be added later into enum davinci_gpio_type.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/da830.c               |    2 ++
 arch/arm/mach-davinci/da850.c               |    2 ++
 arch/arm/mach-davinci/dm355.c               |    1 +
 arch/arm/mach-davinci/dm365.c               |    1 +
 arch/arm/mach-davinci/dm644x.c              |    1 +
 arch/arm/mach-davinci/dm646x.c              |    1 +
 arch/arm/mach-davinci/gpio.c                |    3 +++
 arch/arm/mach-davinci/include/mach/common.h |    1 +
 arch/arm/mach-davinci/include/mach/gpio.h   |    4 ++++
 9 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 122e61a..68e5233 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -19,6 +19,7 @@
 #include <mach/common.h>
 #include <mach/time.h>
 #include <mach/da8xx.h>
+#include <mach/gpio.h>
 
 #include "clock.h"
 #include "mux.h"
@@ -1199,6 +1200,7 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
 	.intc_irq_prios		= da830_default_priorities,
 	.intc_irq_num		= DA830_N_CP_INTC_IRQ,
 	.timer_info		= &da830_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DA8XX_GPIO_BASE),
 	.gpio_num		= 128,
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index d0fd756..8aefcff 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -27,6 +27,7 @@
 #include <mach/da8xx.h>
 #include <mach/cpufreq.h>
 #include <mach/pm.h>
+#include <mach/gpio.h>
 
 #include "clock.h"
 #include "mux.h"
@@ -1084,6 +1085,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.intc_irq_prios		= da850_default_priorities,
 	.intc_irq_num		= DA850_N_CP_INTC_IRQ,
 	.timer_info		= &da850_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DA8XX_GPIO_BASE),
 	.gpio_num		= 144,
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 5efce70..f9a54ff 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -859,6 +859,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.intc_irq_prios		= dm355_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm355_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM355_GPIOBNK0,
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 1ee3fc8..0566675 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1064,6 +1064,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.intc_irq_prios		= dm365_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm365_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM365_GPIO0,
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 23cbe9d..4af349e 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -748,6 +748,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.intc_irq_prios 	= dm644x_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm644x_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
 	.gpio_num		= 71,
 	.gpio_irq		= IRQ_GPIOBNK0,
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index a0b3739..bdb1ace 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -832,6 +832,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.intc_irq_prios		= dm646x_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm646x_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
 	.gpio_num		= 43, /* Only 33 usable */
 	.gpio_irq		= IRQ_DM646X_GPIOBNK0,
diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index d241b4f..e422cd3 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -145,6 +145,9 @@ static int __init davinci_gpio_setup(void)
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
 	struct davinci_gpio_regs *regs;
 
+	if (soc_info->gpio_type != GPIO_TYPE_DAVINCI)
+		return 0;
+
 	/*
 	 * The gpio banks conceptually expose a segmented bitmap,
 	 * and "ngpio" is one more than the largest zero-based
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 1d72883..8ffef5b 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -59,6 +59,7 @@ struct davinci_soc_info {
 	u8				*intc_irq_prios;
 	unsigned long			intc_irq_num;
 	struct davinci_timer_info	*timer_info;
+	int				gpio_type;
 	void __iomem			*gpio_base;
 	unsigned			gpio_num;
 	unsigned			gpio_irq;
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index 82591d0..9a71a26 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -21,6 +21,10 @@
 
 #define DAVINCI_GPIO_BASE 0x01C67000
 
+enum davinci_gpio_type {
+	GPIO_TYPE_DAVINCI = 0,
+};
+
 /*
  * basic gpio routines
  *
-- 
1.6.3.3


From cyril at ti.com  Fri Apr 23 12:56:58 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 23 Apr 2010 13:56:58 -0400
Subject: [PATCH v4 07/13] Davinci: eliminate pinmux offset verbosity
In-Reply-To: <1272045424-19240-7-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
Message-ID: <1272045424-19240-8-git-send-email-cyril@ti.com>

Pinmux registers are sequential, and do not need to be enumerated out as they
currently are.  This reduces code volume and keeps things simple.

If some future SoC comes up with a discontiguous register map, PINMUX() can
then be expanded with local token pasting.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/dm355.c              |    6 +-----
 arch/arm/mach-davinci/dm365.c              |    6 +-----
 arch/arm/mach-davinci/dm644x.c             |    3 +--
 arch/arm/mach-davinci/dm646x.c             |    3 +--
 arch/arm/mach-davinci/include/mach/da8xx.h |   21 +--------------------
 arch/arm/mach-davinci/mux.h                |    2 +-
 6 files changed, 6 insertions(+), 35 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index f9a54ff..1073882 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -450,11 +450,7 @@ void __init dm355_init_spi0(unsigned chipselect_mask,
 
 /*----------------------------------------------------------------------*/
 
-#define PINMUX0		0x00
-#define PINMUX1		0x04
-#define PINMUX2		0x08
-#define PINMUX3		0x0c
-#define PINMUX4		0x10
+#define PINMUX(x)	(4 * (x))
 #define INTMUX		0x18
 #define EVTMUX		0x1c
 
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 0566675..e790da1 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -467,11 +467,7 @@ static struct clk_lookup dm365_clks[] = {
 
 /*----------------------------------------------------------------------*/
 
-#define PINMUX0		0x00
-#define PINMUX1		0x04
-#define PINMUX2		0x08
-#define PINMUX3		0x0c
-#define PINMUX4		0x10
+#define PINMUX(x)	(4 * (x))
 #define INTMUX		0x18
 #define EVTMUX		0x1c
 
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 4af349e..3f3d5cb 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -350,8 +350,7 @@ static struct platform_device dm644x_emac_device = {
        .resource	= dm644x_emac_resources,
 };
 
-#define PINMUX0		0x00
-#define PINMUX1		0x04
+#define PINMUX(x)	(4 * (x))
 
 /*
  * Device specific mux setup
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index bdb1ace..c82194a 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -401,8 +401,7 @@ static struct platform_device dm646x_emac_device = {
 	.resource	= dm646x_emac_resources,
 };
 
-#define PINMUX0		0x00
-#define PINMUX1		0x04
+#define PINMUX(x)	(4 * (x))
 
 /*
  * Device specific mux setup
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index 33471c9..02acedd 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -64,26 +64,7 @@ extern void __iomem *da8xx_syscfg1_base;
 #define DA8XX_DDR2_CTL_BASE	0xb0000000
 #define DA8XX_ARM_RAM_BASE	0xffff0000
 
-#define PINMUX0			0x00
-#define PINMUX1			0x04
-#define PINMUX2			0x08
-#define PINMUX3			0x0c
-#define PINMUX4			0x10
-#define PINMUX5			0x14
-#define PINMUX6			0x18
-#define PINMUX7			0x1c
-#define PINMUX8			0x20
-#define PINMUX9			0x24
-#define PINMUX10		0x28
-#define PINMUX11		0x2c
-#define PINMUX12		0x30
-#define PINMUX13		0x34
-#define PINMUX14		0x38
-#define PINMUX15		0x3c
-#define PINMUX16		0x40
-#define PINMUX17		0x44
-#define PINMUX18		0x48
-#define PINMUX19		0x4c
+#define PINMUX(x)		(4 * (x))
 
 void __init da830_init(void);
 void __init da850_init(void);
diff --git a/arch/arm/mach-davinci/mux.h b/arch/arm/mach-davinci/mux.h
index adc8694..5aad1e7 100644
--- a/arch/arm/mach-davinci/mux.h
+++ b/arch/arm/mach-davinci/mux.h
@@ -20,7 +20,7 @@
 			.name =  #desc,					\
 			.debug = dbg,					\
 			.mux_reg_name = "PINMUX"#muxreg,		\
-			.mux_reg = PINMUX##muxreg,			\
+			.mux_reg = PINMUX(muxreg),			\
 			.mask_offset = mode_offset,			\
 			.mask = mode_mask,				\
 			.mode = mux_mode,				\
-- 
1.6.3.3


From cyril at ti.com  Fri Apr 23 12:56:59 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 23 Apr 2010 13:56:59 -0400
Subject: [PATCH v4 08/13] Davinci: iotable based ioremap() interception
In-Reply-To: <1272045424-19240-8-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
Message-ID: <1272045424-19240-9-git-send-email-cyril@ti.com>

This patch allows for a more flexible ioremap() interception based on iotable
contents.

SoCs that need ioremap() to fill up davinci_soc_info may directly call
davinci_io_init() and use ioremap() as needed.  Such SoCs must not fill
io_desc and io_desc_num entries in struct davinci_soc_info.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
v4: removed __davinci_ioremap() and related infrastructure
v4: split davinci_io_init() out of davinci_common_init()

 arch/arm/mach-davinci/common.c          |   13 +-------
 arch/arm/mach-davinci/da830.c           |    2 +
 arch/arm/mach-davinci/da850.c           |    2 +
 arch/arm/mach-davinci/include/mach/io.h |    5 +++
 arch/arm/mach-davinci/io.c              |   49 +++++++++++++++++++++++++++---
 5 files changed, 55 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c
index 94f27cb..aac43b1 100644
--- a/arch/arm/mach-davinci/common.c
+++ b/arch/arm/mach-davinci/common.c
@@ -65,17 +65,8 @@ void __init davinci_common_init(struct davinci_soc_info *soc_info)
 
 	memcpy(&davinci_soc_info, soc_info, sizeof(struct davinci_soc_info));
 
-	if (davinci_soc_info.io_desc && (davinci_soc_info.io_desc_num > 0))
-		iotable_init(davinci_soc_info.io_desc,
-				davinci_soc_info.io_desc_num);
-
-	/*
-	 * Normally devicemaps_init() would flush caches and tlb after
-	 * mdesc->map_io(), but we must also do it here because of the CPU
-	 * revision check below.
-	 */
-	local_flush_tlb_all();
-	flush_cache_all();
+	davinci_io_init(davinci_soc_info.io_desc,
+			davinci_soc_info.io_desc_num);
 
 	/*
 	 * We want to check CPU revision early for cpu_is_xxxx() macros.
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 68e5233..4bcdc6f 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1210,6 +1210,8 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
 
 void __init da830_init(void)
 {
+	davinci_io_init(da830_io_desc, ARRAY_SIZE(da830_io_desc));
+
 	da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
 	if (WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module"))
 		return;
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 8aefcff..c2c2d58 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1099,6 +1099,8 @@ void __init da850_init(void)
 {
 	unsigned int v;
 
+	davinci_io_init(da850_io_desc, ARRAY_SIZE(da850_io_desc));
+
 	da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
 	if (WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module"))
 		return;
diff --git a/arch/arm/mach-davinci/include/mach/io.h b/arch/arm/mach-davinci/include/mach/io.h
index 62b0a90..3f456b7 100644
--- a/arch/arm/mach-davinci/include/mach/io.h
+++ b/arch/arm/mach-davinci/include/mach/io.h
@@ -25,8 +25,13 @@
 #define __arch_ioremap(p, s, t)	davinci_ioremap(p, s, t)
 #define __arch_iounmap(v)	davinci_iounmap(v)
 
+struct map_desc;
+
 void __iomem *davinci_ioremap(unsigned long phys, size_t size,
 			      unsigned int type);
 void davinci_iounmap(volatile void __iomem *addr);
+
+void davinci_io_init(struct map_desc *desc, unsigned long desc_num);
+
 #endif
 #endif /* __ASM_ARCH_IO_H */
diff --git a/arch/arm/mach-davinci/io.c b/arch/arm/mach-davinci/io.c
index a1c0b6b..81862ec 100644
--- a/arch/arm/mach-davinci/io.c
+++ b/arch/arm/mach-davinci/io.c
@@ -12,19 +12,31 @@
 #include <linux/io.h>
 
 #include <asm/tlb.h>
+#include <asm/mach/map.h>
 
-#define BETWEEN(p, st, sz)	((p) >= (st) && (p) < ((st) + (sz)))
-#define XLATE(p, pst, vst)	((void __iomem *)((p) - (pst) + (vst)))
+#include <mach/common.h>
+
+static struct map_desc	*davinci_io_desc;
+static unsigned long	davinci_io_desc_num;
 
 /*
  * Intercept ioremap() requests for addresses in our fixed mapping regions.
  */
 void __iomem *davinci_ioremap(unsigned long p, size_t size, unsigned int type)
 {
-	if (BETWEEN(p, IO_PHYS, IO_SIZE))
-		return XLATE(p, IO_PHYS, IO_VIRT);
+	struct map_desc *desc = davinci_io_desc;
+	int i;
+
+	for (i = 0; i < davinci_io_desc_num; i++, desc++) {
+		unsigned long iophys = __pfn_to_phys(desc->pfn);
+		unsigned long iosize = desc->length;
+
+		if (p >= iophys && (p + size) <= (iophys + iosize))
+			return __io(desc->virtual + p - iophys);
+	}
 
-	return __arm_ioremap_caller(p, size, type, __builtin_return_address(0));
+	return __arm_ioremap_caller(p, size, type,
+					__builtin_return_address(0));
 }
 EXPORT_SYMBOL(davinci_ioremap);
 
@@ -36,3 +48,30 @@ void davinci_iounmap(volatile void __iomem *addr)
 		__iounmap(addr);
 }
 EXPORT_SYMBOL(davinci_iounmap);
+
+void __init davinci_io_init(struct map_desc *desc, unsigned long desc_num)
+{
+	if (!desc || !desc_num)
+		return;
+
+	/* silently refuse to init twice ...*/
+	if (davinci_io_desc) {
+		/* ... unless things change */
+		BUG_ON(davinci_io_desc != desc ||
+			davinci_io_desc_num != desc_num);
+		return;
+	}
+
+	davinci_io_desc = desc;
+	davinci_io_desc_num = desc_num;
+
+	iotable_init(desc, desc_num);
+
+	/*
+	 * Normally devicemaps_init() would flush caches and tlb after
+	 * mdesc->map_io(), but we must also do it here because of the CPU
+	 * revision check below.
+	 */
+	local_flush_tlb_all();
+	flush_cache_all();
+}
-- 
1.6.3.3


From cyril at ti.com  Fri Apr 23 12:56:57 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 23 Apr 2010 13:56:57 -0400
Subject: [PATCH v4 06/13] Davinci: gpio - fine grained locking
In-Reply-To: <1272045424-19240-6-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
Message-ID: <1272045424-19240-7-git-send-email-cyril@ti.com>

This patch eliminates the global gpio_lock, and implements a per-controller
lock instead.  This also switches to irqsave/irqrestore locks in case gpios
are manipulated in isr.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/gpio.c              |    9 +++++----
 arch/arm/mach-davinci/include/mach/gpio.h |    3 +++
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index e422cd3..b62d5e2 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -33,8 +33,6 @@ struct davinci_gpio_regs {
 	u32	intstat;
 };
 
-static DEFINE_SPINLOCK(gpio_lock);
-
 #define chip2controller(chip)	\
 	container_of(chip, struct davinci_gpio_controller, chip)
 
@@ -83,10 +81,11 @@ static inline int __davinci_direction(struct gpio_chip *chip,
 {
 	struct davinci_gpio_controller *d = chip2controller(chip);
 	struct davinci_gpio_regs __iomem *g = d->regs;
+	unsigned long flags;
 	u32 temp;
 	u32 mask = 1 << offset;
 
-	spin_lock(&gpio_lock);
+	spin_lock_irqsave(&d->lock, flags);
 	temp = __raw_readl(&g->dir);
 	if (out) {
 		temp &= ~mask;
@@ -95,7 +94,7 @@ static inline int __davinci_direction(struct gpio_chip *chip,
 		temp |= mask;
 	}
 	__raw_writel(temp, &g->dir);
-	spin_unlock(&gpio_lock);
+	spin_unlock_irqrestore(&d->lock, flags);
 
 	return 0;
 }
@@ -175,6 +174,8 @@ static int __init davinci_gpio_setup(void)
 		if (chips[i].chip.ngpio > 32)
 			chips[i].chip.ngpio = 32;
 
+		spin_lock_init(&chips[i].lock);
+
 		regs = gpio2regs(base);
 		chips[i].regs = regs;
 		chips[i].set_data = &regs->set_data;
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index 9a71a26..504cc18 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -14,6 +14,8 @@
 #define	__DAVINCI_GPIO_H
 
 #include <linux/io.h>
+#include <linux/spinlock.h>
+
 #include <asm-generic/gpio.h>
 
 #include <mach/irqs.h>
@@ -52,6 +54,7 @@ enum davinci_gpio_type {
 struct davinci_gpio_controller {
 	struct gpio_chip	chip;
 	int			irq_base;
+	spinlock_t		lock;
 	void __iomem		*regs;
 	void __iomem		*set_data;
 	void __iomem		*clr_data;
-- 
1.6.3.3


From cyril at ti.com  Fri Apr 23 12:57:01 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 23 Apr 2010 13:57:01 -0400
Subject: [PATCH v4 10/13] Davinci: tnetv107x decompresser uart definitions
In-Reply-To: <1272045424-19240-10-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
	<1272045424-19240-10-git-send-email-cyril@ti.com>
Message-ID: <1272045424-19240-11-git-send-email-cyril@ti.com>

Added definitions for tnetv107x uart base addresses, and modified base address
selection for kernel decompressor to check for tnetv107x machine type.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
v4: unchanged from v3
v3: migrated to uncompress.h based implementation added earlier in this series

 arch/arm/mach-davinci/include/mach/serial.h     |    8 ++++++++
 arch/arm/mach-davinci/include/mach/uncompress.h |    7 +++++++
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/include/mach/serial.h b/arch/arm/mach-davinci/include/mach/serial.h
index 8829dde..34b64be 100644
--- a/arch/arm/mach-davinci/include/mach/serial.h
+++ b/arch/arm/mach-davinci/include/mach/serial.h
@@ -33,6 +33,14 @@
 #define DA8XX_UART1_BASE	(IO_PHYS + 0x10c000)
 #define DA8XX_UART2_BASE	(IO_PHYS + 0x10d000)
 
+#define TNETV107X_UART0_BASE	(0x08108100)
+#define TNETV107X_UART1_BASE	(0x08088400)
+#define TNETV107X_UART2_BASE	(0x08108300)
+
+#define TNETV107X_UART0_VIRT	IOMEM(0xfee08100)
+#define TNETV107X_UART1_VIRT	IOMEM(0xfed88400)
+#define TNETV107X_UART2_VIRT	IOMEM(0xfee08300)
+
 /* DaVinci UART register offsets */
 #define UART_DAVINCI_PWREMU		0x0c
 #define UART_DM646X_SCR			0x10
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
index 20c23a3..15a6192 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -63,6 +63,10 @@ static inline void set_uart_info(u32 phys, void * __iomem virt)
 	_DEBUG_LL_ENTRY(machine, DA8XX_UART##port##_BASE,	\
 			IO_ADDRESS(DA8XX_UART##port##_BASE))
 
+#define DEBUG_LL_TNETV107X(machine, port)			\
+	_DEBUG_LL_ENTRY(machine, TNETV107X_UART##port##_BASE,	\
+			TNETV107X_UART##port##_VIRT)
+
 static inline void __arch_decomp_setup(unsigned long arch_id)
 {
 	/*
@@ -84,6 +88,9 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
 		/* DA8xx boards */
 		DEBUG_LL_DA8XX(davinci_da830_evm,	2);
 		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
+
+		/* TNETV107x boards */
+		DEBUG_LL_TNETV107X(tnetv107x,		1);
 	} while (0);
 }
 
-- 
1.6.3.3


From cyril at ti.com  Fri Apr 23 12:57:03 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 23 Apr 2010 13:57:03 -0400
Subject: [PATCH v4 12/13] Davinci: tnetv107x initial gpio support
In-Reply-To: <1272045424-19240-12-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
	<1272045424-19240-10-git-send-email-cyril@ti.com>
	<1272045424-19240-11-git-send-email-cyril@ti.com>
	<1272045424-19240-12-git-send-email-cyril@ti.com>
Message-ID: <1272045424-19240-13-git-send-email-cyril@ti.com>

This patch adds support for the tnetv107x gpio controller.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
v4: range check against number of tnetv107x gpios
v3: switched to spin_lock_irq from local_irq_save/restore
v3: migrated to restructured gpio framework from earlier patches in this
    series

 arch/arm/mach-davinci/Makefile            |    1 +
 arch/arm/mach-davinci/gpio-tnetv107x.c    |  205 +++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/gpio.h |    1 +
 3 files changed, 207 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-davinci/gpio-tnetv107x.c

diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 1c7bcfe..62c5116 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_ARCH_DAVINCI_DM365)	+= dm365.o devices.o
 obj-$(CONFIG_ARCH_DAVINCI_DA830)        += da830.o devices-da8xx.o
 obj-$(CONFIG_ARCH_DAVINCI_DA850)        += da850.o devices-da8xx.o
 obj-$(CONFIG_ARCH_DAVINCI_TNETV107X)    += tnetv107x.o devices-tnetv107x.o
+obj-$(CONFIG_ARCH_DAVINCI_TNETV107X)    += gpio-tnetv107x.o
 
 obj-$(CONFIG_AINTC)			+= irq.o
 obj-$(CONFIG_CP_INTC)			+= cp_intc.o
diff --git a/arch/arm/mach-davinci/gpio-tnetv107x.c b/arch/arm/mach-davinci/gpio-tnetv107x.c
new file mode 100644
index 0000000..c02e98d
--- /dev/null
+++ b/arch/arm/mach-davinci/gpio-tnetv107x.c
@@ -0,0 +1,205 @@
+/*
+ * Texas Instruments TNETV107X GPIO Controller
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/gpio.h>
+
+#include <mach/common.h>
+#include <mach/tnetv107x.h>
+
+struct tnetv107x_gpio_regs {
+	u32	idver;
+	u32	data_in[3];
+	u32	data_out[3];
+	u32	direction[3];
+	u32	enable[3];
+};
+
+#define gpio_reg_index(gpio)	((gpio) >> 5)
+#define gpio_reg_bit(gpio)	BIT((gpio) & 0x1f)
+
+#define gpio_reg_rmw(reg, mask, val)	\
+	__raw_writel((__raw_readl(reg) & ~(mask)) | (val), (reg))
+
+#define gpio_reg_set_bit(reg, gpio)	\
+	gpio_reg_rmw((reg) + gpio_reg_index(gpio), 0, gpio_reg_bit(gpio))
+
+#define gpio_reg_clear_bit(reg, gpio)	\
+	gpio_reg_rmw((reg) + gpio_reg_index(gpio), gpio_reg_bit(gpio), 0)
+
+#define gpio_reg_get_bit(reg, gpio)	\
+	(__raw_readl((reg) + gpio_reg_index(gpio)) & gpio_reg_bit(gpio))
+
+#define chip2controller(chip)		\
+	container_of(chip, struct davinci_gpio_controller, chip)
+
+#define TNETV107X_GPIO_CTLRS	DIV_ROUND_UP(TNETV107X_N_GPIO, 32)
+
+static struct davinci_gpio_controller chips[TNETV107X_GPIO_CTLRS];
+
+static int tnetv107x_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+	struct davinci_gpio_controller *ctlr = chip2controller(chip);
+	struct tnetv107x_gpio_regs __iomem *regs = ctlr->regs;
+	unsigned gpio = chip->base + offset;
+	unsigned long flags;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+
+	gpio_reg_set_bit(&regs->enable, gpio);
+
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+
+	return 0;
+}
+
+static void tnetv107x_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+	struct davinci_gpio_controller *ctlr = chip2controller(chip);
+	struct tnetv107x_gpio_regs __iomem *regs = ctlr->regs;
+	unsigned gpio = chip->base + offset;
+	unsigned long flags;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+
+	gpio_reg_clear_bit(&regs->enable, gpio);
+
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+}
+
+static int tnetv107x_gpio_dir_in(struct gpio_chip *chip, unsigned offset)
+{
+	struct davinci_gpio_controller *ctlr = chip2controller(chip);
+	struct tnetv107x_gpio_regs __iomem *regs = ctlr->regs;
+	unsigned gpio = chip->base + offset;
+	unsigned long flags;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+
+	gpio_reg_set_bit(&regs->direction, gpio);
+
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+
+	return 0;
+}
+
+static int tnetv107x_gpio_dir_out(struct gpio_chip *chip,
+		unsigned offset, int value)
+{
+	struct davinci_gpio_controller *ctlr = chip2controller(chip);
+	struct tnetv107x_gpio_regs __iomem *regs = ctlr->regs;
+	unsigned gpio = chip->base + offset;
+	unsigned long flags;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+
+	if (value)
+		gpio_reg_set_bit(&regs->data_out, gpio);
+	else
+		gpio_reg_clear_bit(&regs->data_out, gpio);
+
+	gpio_reg_clear_bit(&regs->direction, gpio);
+
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+
+	return 0;
+}
+
+static int tnetv107x_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+	struct davinci_gpio_controller *ctlr = chip2controller(chip);
+	struct tnetv107x_gpio_regs __iomem *regs = ctlr->regs;
+	unsigned gpio = chip->base + offset;
+	int ret;
+
+	ret = gpio_reg_get_bit(&regs->data_in, gpio);
+
+	return ret ? 1 : 0;
+}
+
+static void tnetv107x_gpio_set(struct gpio_chip *chip,
+		unsigned offset, int value)
+{
+	struct davinci_gpio_controller *ctlr = chip2controller(chip);
+	struct tnetv107x_gpio_regs __iomem *regs = ctlr->regs;
+	unsigned gpio = chip->base + offset;
+	unsigned long flags;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+
+	if (value)
+		gpio_reg_set_bit(&regs->data_out, gpio);
+	else
+		gpio_reg_clear_bit(&regs->data_out, gpio);
+
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+}
+
+static int __init tnetv107x_gpio_setup(void)
+{
+	int i, base;
+	unsigned ngpio;
+	struct davinci_soc_info *soc_info = &davinci_soc_info;
+	struct tnetv107x_gpio_regs *regs;
+	struct davinci_gpio_controller *ctlr;
+
+	if (soc_info->gpio_type != GPIO_TYPE_TNETV107X)
+		return 0;
+
+	ngpio = soc_info->gpio_num;
+	if (ngpio == 0) {
+		pr_err("GPIO setup:  how many GPIOs?\n");
+		return -EINVAL;
+	}
+
+	if (WARN_ON(TNETV107X_N_GPIO < ngpio))
+		ngpio = TNETV107X_N_GPIO;
+
+	regs = soc_info->gpio_base;
+	if (WARN_ON(!regs))
+		return -EINVAL;
+
+	for (i = 0, base = 0; base < ngpio; i++, base += 32) {
+		ctlr = &chips[i];
+
+		ctlr->chip.label	= "tnetv107x";
+		ctlr->chip.can_sleep	= 0;
+		ctlr->chip.base		= base;
+		ctlr->chip.ngpio	= ngpio - base;
+		if (ctlr->chip.ngpio > 32)
+			ctlr->chip.ngpio = 32;
+
+		ctlr->chip.request		= tnetv107x_gpio_request;
+		ctlr->chip.free			= tnetv107x_gpio_free;
+		ctlr->chip.direction_input	= tnetv107x_gpio_dir_in;
+		ctlr->chip.get			= tnetv107x_gpio_get;
+		ctlr->chip.direction_output	= tnetv107x_gpio_dir_out;
+		ctlr->chip.set			= tnetv107x_gpio_set;
+
+		spin_lock_init(&ctlr->lock);
+
+		ctlr->regs	= regs;
+		ctlr->set_data	= &regs->data_out[i];
+		ctlr->clr_data	= &regs->data_out[i];
+		ctlr->in_data	= &regs->data_in[i];
+
+		gpiochip_add(&ctlr->chip);
+	}
+
+	soc_info->gpio_ctlrs = chips;
+	soc_info->gpio_ctlrs_num = DIV_ROUND_UP(ngpio, 32);
+	return 0;
+}
+pure_initcall(tnetv107x_gpio_setup);
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index 504cc18..411da55 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -25,6 +25,7 @@
 
 enum davinci_gpio_type {
 	GPIO_TYPE_DAVINCI = 0,
+	GPIO_TYPE_TNETV107X,
 };
 
 /*
-- 
1.6.3.3


From cyril at ti.com  Fri Apr 23 12:57:00 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 23 Apr 2010 13:57:00 -0400
Subject: [PATCH v4 09/13] Davinci: watchdog reset separation across socs
In-Reply-To: <1272045424-19240-9-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
Message-ID: <1272045424-19240-10-git-send-email-cyril@ti.com>

The earlier watchdog reset mechanism had a couple of limitations.  First, it
embedded a reference to "davinci_wdt_device" inside common code.  This
forced all derived platforms (da8xx and tnetv107x) to define such a device.
This also would have caused problems in including multiple socs in a single
build due to symbol redefinition.

With this patch, davinci_watchdog_reset() now takes the platform device as an
argument.  The davinci_soc_info struct has been extended to include a reset
function and a watchdog platform_device.  arch_reset() then uses these
elements to reset the system in a SoC specific fashion.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/clock.h               |    1 +
 arch/arm/mach-davinci/common.c              |    3 +++
 arch/arm/mach-davinci/da830.c               |    1 +
 arch/arm/mach-davinci/da850.c               |    1 +
 arch/arm/mach-davinci/devices-da8xx.c       |    4 ++--
 arch/arm/mach-davinci/dm355.c               |    1 +
 arch/arm/mach-davinci/dm365.c               |    1 +
 arch/arm/mach-davinci/dm644x.c              |    1 +
 arch/arm/mach-davinci/dm646x.c              |    1 +
 arch/arm/mach-davinci/include/mach/common.h |    2 ++
 arch/arm/mach-davinci/include/mach/da8xx.h  |    2 ++
 arch/arm/mach-davinci/include/mach/system.h |    5 +++--
 arch/arm/mach-davinci/time.c                |    9 ++++++---
 13 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-davinci/clock.h b/arch/arm/mach-davinci/clock.h
index ce26015..01e3648 100644
--- a/arch/arm/mach-davinci/clock.h
+++ b/arch/arm/mach-davinci/clock.h
@@ -120,6 +120,7 @@ int davinci_set_pllrate(struct pll_data *pll, unsigned int prediv,
 				unsigned int mult, unsigned int postdiv);
 
 extern struct platform_device davinci_wdt_device;
+extern void davinci_watchdog_reset(struct platform_device *);
 
 #endif
 
diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c
index aac43b1..9f4d4b3 100644
--- a/arch/arm/mach-davinci/common.c
+++ b/arch/arm/mach-davinci/common.c
@@ -68,6 +68,9 @@ void __init davinci_common_init(struct davinci_soc_info *soc_info)
 	davinci_io_init(davinci_soc_info.io_desc,
 			davinci_soc_info.io_desc_num);
 
+	if (!davinci_soc_info.reset)
+		davinci_soc_info.reset = davinci_watchdog_reset;
+
 	/*
 	 * We want to check CPU revision early for cpu_is_xxxx() macros.
 	 * IO space mapping must be initialized before we can do that.
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 4bcdc6f..9b75ea2 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1206,6 +1206,7 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
 	.serial_dev		= &da8xx_serial_device,
 	.emac_pdata		= &da8xx_emac_pdata,
+	.reset_device		= &da8xx_wdt_device,
 };
 
 void __init da830_init(void)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index c2c2d58..5fac6ee 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1093,6 +1093,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.emac_pdata		= &da8xx_emac_pdata,
 	.sram_dma		= DA8XX_ARM_RAM_BASE,
 	.sram_len		= SZ_8K,
+	.reset_device		= &da8xx_wdt_device,
 };
 
 void __init da850_init(void)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index 0a96791..67a6fbc 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -326,7 +326,7 @@ static struct resource da8xx_watchdog_resources[] = {
 	},
 };
 
-struct platform_device davinci_wdt_device = {
+struct platform_device da8xx_wdt_device = {
 	.name		= "watchdog",
 	.id		= -1,
 	.num_resources	= ARRAY_SIZE(da8xx_watchdog_resources),
@@ -335,7 +335,7 @@ struct platform_device davinci_wdt_device = {
 
 int __init da8xx_register_watchdog(void)
 {
-	return platform_device_register(&davinci_wdt_device);
+	return platform_device_register(&da8xx_wdt_device);
 }
 
 static struct resource da8xx_emac_resources[] = {
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 1073882..0a801b3 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -862,6 +862,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.serial_dev		= &dm355_serial_device,
 	.sram_dma		= 0x00010000,
 	.sram_len		= SZ_32K,
+	.reset_device		= &davinci_wdt_device,
 };
 
 void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index e790da1..ecb4ee8 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1069,6 +1069,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.emac_pdata		= &dm365_emac_pdata,
 	.sram_dma		= 0x00010000,
 	.sram_len		= SZ_32K,
+	.reset_device		= &davinci_wdt_device,
 };
 
 void __init dm365_init_asp(struct snd_platform_data *pdata)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 3f3d5cb..0a36963 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -755,6 +755,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.emac_pdata		= &dm644x_emac_pdata,
 	.sram_dma		= 0x00008000,
 	.sram_len		= SZ_16K,
+	.reset_device		= &davinci_wdt_device,
 };
 
 void __init dm644x_init_asp(struct snd_platform_data *pdata)
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index c82194a..962b9d9 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -839,6 +839,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.emac_pdata		= &dm646x_emac_pdata,
 	.sram_dma		= 0x10010000,
 	.sram_len		= SZ_32K,
+	.reset_device		= &davinci_wdt_device,
 };
 
 void __init dm646x_init_mcasp0(struct snd_platform_data *pdata)
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 8ffef5b..a58bd88 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -70,6 +70,8 @@ struct davinci_soc_info {
 	struct emac_platform_data	*emac_pdata;
 	dma_addr_t			sram_dma;
 	unsigned			sram_len;
+	struct platform_device		*reset_device;
+	void				(*reset)(struct platform_device *);
 };
 
 extern struct davinci_soc_info davinci_soc_info;
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index 02acedd..5cbadc2 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -89,6 +89,8 @@ extern struct emac_platform_data da8xx_emac_pdata;
 extern struct da8xx_lcdc_platform_data sharp_lcd035q3dg01_pdata;
 extern struct da8xx_lcdc_platform_data sharp_lk043t1dg01_pdata;
 
+extern struct platform_device da8xx_wdt_device;
+
 extern const short da830_emif25_pins[];
 extern const short da830_spi0_pins[];
 extern const short da830_spi1_pins[];
diff --git a/arch/arm/mach-davinci/include/mach/system.h b/arch/arm/mach-davinci/include/mach/system.h
index 5a7d758..e65629c 100644
--- a/arch/arm/mach-davinci/include/mach/system.h
+++ b/arch/arm/mach-davinci/include/mach/system.h
@@ -11,7 +11,7 @@
 #ifndef __ASM_ARCH_SYSTEM_H
 #define __ASM_ARCH_SYSTEM_H
 
-extern void davinci_watchdog_reset(void);
+#include <mach/common.h>
 
 static inline void arch_idle(void)
 {
@@ -20,7 +20,8 @@ static inline void arch_idle(void)
 
 static inline void arch_reset(char mode, const char *cmd)
 {
-	davinci_watchdog_reset();
+	if (davinci_soc_info.reset)
+		davinci_soc_info.reset(davinci_soc_info.reset_device);
 }
 
 #endif /* __ASM_ARCH_SYSTEM_H */
diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index b21f763..e5c598a 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c
@@ -399,13 +399,16 @@ struct sys_timer davinci_timer = {
 
 
 /* reset board using watchdog timer */
-void davinci_watchdog_reset(void)
+void davinci_watchdog_reset(struct platform_device *pdev)
 {
 	u32 tgcr, wdtcr;
-	struct platform_device *pdev = &davinci_wdt_device;
-	void __iomem *base = IO_ADDRESS(pdev->resource[0].start);
+	void __iomem *base;
 	struct clk *wd_clk;
 
+	base = ioremap(pdev->resource[0].start, SZ_4K);
+	if (WARN_ON(!base))
+		return;
+
 	wd_clk = clk_get(&pdev->dev, NULL);
 	if (WARN_ON(IS_ERR(wd_clk)))
 		return;
-- 
1.6.3.3


From cyril at ti.com  Fri Apr 23 12:57:02 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 23 Apr 2010 13:57:02 -0400
Subject: [PATCH v4 11/13] Davinci: tnetv107x soc support
In-Reply-To: <1272045424-19240-11-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
	<1272045424-19240-10-git-send-email-cyril@ti.com>
	<1272045424-19240-11-git-send-email-cyril@ti.com>
Message-ID: <1272045424-19240-12-git-send-email-cyril@ti.com>

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 PLL.  Some
elements of the clock architecture are reused from Davinci (e.g. LPSC), but
the PLL related code is overridden using existing interfaces in "struct clk".

2. The MMR layout on this SOC is substantially different from Davinci.
Consequently, the fixed I/O map is a whole lot more convoluted (more so than
DA8xx).  The net impact here is that IO_ADDRESS() will not work on this SoC,
and therefore all mappings have to be through ioremap().

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
v4: macroized clock definitions to reduce code volume
v4: moved to new davinci_io_init() mechanism (earlier in this series)
v4: squashed tnetv107x.h header and watchdog reset patches into this
v4: moved all platform_device definitions into soc code, accessible to board
    specific code via tnetv107x_devices_init()
v3: eliminated recalc routines for pll and leaf clocks
v3: stripped "clk_" prefix from clock names
v3: use newly added div_ratio_mask functionality (earlier in this series)
v3: move from fixed_ioremap to __davinci_ioremap() implementation (earlier in
    this series

 arch/arm/mach-davinci/Kconfig                  |    5 +
 arch/arm/mach-davinci/Makefile                 |    1 +
 arch/arm/mach-davinci/devices-tnetv107x.c      |  347 ++++++++++
 arch/arm/mach-davinci/include/mach/tnetv107x.h |   55 ++
 arch/arm/mach-davinci/tnetv107x.c              |  841 ++++++++++++++++++++++++
 5 files changed, 1249 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-davinci/devices-tnetv107x.c
 create mode 100644 arch/arm/mach-davinci/include/mach/tnetv107x.h
 create mode 100644 arch/arm/mach-davinci/tnetv107x.c

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 0316e20..a67b47b 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -50,6 +50,11 @@ config ARCH_DAVINCI_DM365
 	select AINTC
 	select ARCH_DAVINCI_DMx
 
+config ARCH_DAVINCI_TNETV107X
+	select CPU_V6
+	select CP_INTC
+	bool "TNETV107X based system"
+
 comment "DaVinci Board Type"
 
 config MACH_DAVINCI_EVM
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 6aac880..1c7bcfe 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_ARCH_DAVINCI_DM646x)       += dm646x.o devices.o
 obj-$(CONFIG_ARCH_DAVINCI_DM365)	+= dm365.o devices.o
 obj-$(CONFIG_ARCH_DAVINCI_DA830)        += da830.o devices-da8xx.o
 obj-$(CONFIG_ARCH_DAVINCI_DA850)        += da850.o devices-da8xx.o
+obj-$(CONFIG_ARCH_DAVINCI_TNETV107X)    += tnetv107x.o devices-tnetv107x.o
 
 obj-$(CONFIG_AINTC)			+= irq.o
 obj-$(CONFIG_CP_INTC)			+= cp_intc.o
diff --git a/arch/arm/mach-davinci/devices-tnetv107x.c b/arch/arm/mach-davinci/devices-tnetv107x.c
new file mode 100644
index 0000000..9048b22
--- /dev/null
+++ b/arch/arm/mach-davinci/devices-tnetv107x.c
@@ -0,0 +1,347 @@
+/*
+ * Texas Instruments TNETV107X SoC devices
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/dma-mapping.h>
+#include <linux/clk.h>
+#include <linux/slab.h>
+
+#include <mach/common.h>
+#include <mach/irqs.h>
+#include <mach/edma.h>
+#include <mach/tnetv107x.h>
+
+#include "clock.h"
+
+/* Base addresses for on-chip devices */
+#define TNETV107X_TPCC_BASE			0x01c00000
+#define TNETV107X_TPTC0_BASE			0x01c10000
+#define TNETV107X_TPTC1_BASE			0x01c10400
+#define TNETV107X_ASYNC_EMIF_DATA_CE0_BASE	0x30000000
+#define TNETV107X_WDOG_BASE			0x08086700
+#define TNETV107X_SDIO0_BASE			0x08088700
+#define TNETV107X_SDIO1_BASE			0x08088800
+#define TNETV107X_ASYNC_EMIF_CNTRL_BASE		0x08200000
+
+/* TNETV107X specific EDMA3 information */
+#define EDMA_TNETV107X_NUM_DMACH	64
+#define EDMA_TNETV107X_NUM_TCC		64
+#define EDMA_TNETV107X_NUM_PARAMENTRY	128
+#define EDMA_TNETV107X_NUM_EVQUE	2
+#define EDMA_TNETV107X_NUM_TC		2
+#define EDMA_TNETV107X_CHMAP_EXIST	0
+#define EDMA_TNETV107X_NUM_REGIONS	4
+#define TNETV107X_DMACH2EVENT_MAP0	0x3C0CE000u
+#define TNETV107X_DMACH2EVENT_MAP1	0x000FFFFFu
+
+#define TNETV107X_DMACH_SDIO0_RX		26
+#define TNETV107X_DMACH_SDIO0_TX		27
+#define TNETV107X_DMACH_SDIO1_RX		28
+#define TNETV107X_DMACH_SDIO1_TX		29
+
+static const s8 edma_tc_mapping[][2] = {
+	/* event queue no	TC no	*/
+	{	 0,		 0	},
+	{	 1,		 1	},
+	{	-1,		-1	}
+};
+
+static const s8 edma_priority_mapping[][2] = {
+	/* event queue no	Prio	*/
+	{	 0,		 3	},
+	{	 1,		 7	},
+	{	-1,		-1	}
+};
+
+static struct edma_soc_info edma_info[] = {
+	{
+		.n_channel		= EDMA_TNETV107X_NUM_DMACH,
+		.n_region		= EDMA_TNETV107X_NUM_REGIONS,
+		.n_slot			= EDMA_TNETV107X_NUM_PARAMENTRY,
+		.n_tc			= EDMA_TNETV107X_NUM_TC,
+		.n_cc			= 1,
+		.queue_tc_mapping	= edma_tc_mapping,
+		.queue_priority_mapping	= edma_priority_mapping,
+	},
+};
+
+static struct resource edma_resources[] = {
+	{
+		.name	= "edma_cc0",
+		.start	= TNETV107X_TPCC_BASE,
+		.end	= TNETV107X_TPCC_BASE + SZ_32K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	{
+		.name	= "edma_tc0",
+		.start	= TNETV107X_TPTC0_BASE,
+		.end	= TNETV107X_TPTC0_BASE + SZ_1K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	{
+		.name	= "edma_tc1",
+		.start	= TNETV107X_TPTC1_BASE,
+		.end	= TNETV107X_TPTC1_BASE + SZ_1K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	{
+		.name	= "edma0",
+		.start	= IRQ_TNETV107X_TPCC,
+		.flags	= IORESOURCE_IRQ,
+	},
+	{
+		.name	= "edma0_err",
+		.start	= IRQ_TNETV107X_TPCC_ERR,
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device edma_device = {
+	.name		= "edma",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(edma_resources),
+	.resource	= edma_resources,
+	.dev.platform_data = edma_info,
+};
+
+static struct plat_serial8250_port serial_data[] = {
+	{
+		.mapbase	= TNETV107X_UART0_BASE,
+		.irq		= IRQ_TNETV107X_UART0,
+		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
+					UPF_FIXED_TYPE | UPF_IOREMAP,
+		.type		= PORT_AR7,
+		.iotype		= UPIO_MEM32,
+		.regshift	= 2,
+	},
+	{
+		.mapbase	= TNETV107X_UART1_BASE,
+		.irq		= IRQ_TNETV107X_UART1,
+		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
+					UPF_FIXED_TYPE | UPF_IOREMAP,
+		.type		= PORT_AR7,
+		.iotype		= UPIO_MEM32,
+		.regshift	= 2,
+	},
+	{
+		.mapbase	= TNETV107X_UART2_BASE,
+		.irq		= IRQ_TNETV107X_UART2,
+		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
+					UPF_FIXED_TYPE | UPF_IOREMAP,
+		.type		= PORT_AR7,
+		.iotype		= UPIO_MEM32,
+		.regshift	= 2,
+	},
+	{
+		.flags	= 0,
+	},
+};
+
+static struct platform_device serial_device = {
+	.name			= "serial8250",
+	.id			= PLAT8250_DEV_PLATFORM,
+	.dev.platform_data	= serial_data,
+};
+
+static struct resource mmc0_resources[] = {
+	{ /* Memory mapped registers */
+		.start	= TNETV107X_SDIO0_BASE,
+		.end	= TNETV107X_SDIO0_BASE + 0x0ff,
+		.flags	= IORESOURCE_MEM
+	},
+	{ /* MMC interrupt */
+		.start	= IRQ_TNETV107X_MMC0,
+		.flags	= IORESOURCE_IRQ
+	},
+	{ /* SDIO interrupt */
+		.start	= IRQ_TNETV107X_SDIO0,
+		.flags	= IORESOURCE_IRQ
+	},
+	{ /* DMA RX */
+		.start	= EDMA_CTLR_CHAN(0, TNETV107X_DMACH_SDIO0_RX),
+		.flags	= IORESOURCE_DMA
+	},
+	{ /* DMA TX */
+		.start	= EDMA_CTLR_CHAN(0, TNETV107X_DMACH_SDIO0_TX),
+		.flags	= IORESOURCE_DMA
+	},
+};
+
+static struct resource mmc1_resources[] = {
+	{ /* Memory mapped registers */
+		.start	= TNETV107X_SDIO1_BASE,
+		.end	= TNETV107X_SDIO1_BASE + 0x0ff,
+		.flags	= IORESOURCE_MEM
+	},
+	{ /* MMC interrupt */
+		.start	= IRQ_TNETV107X_MMC1,
+		.flags	= IORESOURCE_IRQ
+	},
+	{ /* SDIO interrupt */
+		.start	= IRQ_TNETV107X_SDIO1,
+		.flags	= IORESOURCE_IRQ
+	},
+	{ /* DMA RX */
+		.start	= EDMA_CTLR_CHAN(0, TNETV107X_DMACH_SDIO1_RX),
+		.flags	= IORESOURCE_DMA
+	},
+	{ /* DMA TX */
+		.start	= EDMA_CTLR_CHAN(0, TNETV107X_DMACH_SDIO1_TX),
+		.flags	= IORESOURCE_DMA
+	},
+};
+
+static u64 mmc0_dma_mask = DMA_BIT_MASK(32);
+static u64 mmc1_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device mmc_devices[2] = {
+	{
+		.name		= "davinci_mmc",
+		.id		= 0,
+		.dev		= {
+			.dma_mask		= &mmc0_dma_mask,
+			.coherent_dma_mask	= DMA_BIT_MASK(32),
+		},
+		.num_resources	= ARRAY_SIZE(mmc0_resources),
+		.resource	= mmc0_resources
+	},
+	{
+		.name		= "davinci_mmc",
+		.id		= 1,
+		.dev		= {
+			.dma_mask		= &mmc1_dma_mask,
+			.coherent_dma_mask	= DMA_BIT_MASK(32),
+		},
+		.num_resources	= ARRAY_SIZE(mmc1_resources),
+		.resource	= mmc1_resources
+	},
+};
+
+static struct resource nand_resources[] = {
+	[0] = {
+		.start	= TNETV107X_ASYNC_EMIF_DATA_CE0_BASE,
+		/* size depends on ale and cle - figured out in nand_init() */
+		.end	= TNETV107X_ASYNC_EMIF_DATA_CE0_BASE,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= TNETV107X_ASYNC_EMIF_CNTRL_BASE,
+		.end	= TNETV107X_ASYNC_EMIF_CNTRL_BASE + SZ_4K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct resource wdt_resources[] = {
+	{
+		.start	= TNETV107X_WDOG_BASE,
+		.end	= TNETV107X_WDOG_BASE + SZ_4K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+struct platform_device tnetv107x_wdt_device = {
+	.name		= "tnetv107x_wdt",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(wdt_resources),
+	.resource	= wdt_resources,
+};
+
+/*
+ * The tnetv107x soc does not include PWREMU registers that exist on other
+ * davinci socs, and therefore the common serial initialization via
+ * davinci_serial_init() cannot be used here.
+ */
+static void __init serial_init(struct davinci_uart_config *config)
+{
+	int i;
+	char name[16];
+	struct clk *uart_clk;
+	struct plat_serial8250_port *ports = serial_data;
+
+	for (i = 0; ports[i].flags; i++) {
+		if ((config->enabled_uarts & BIT(i)) == 0)
+			continue;
+
+		sprintf(name, "uart%d", i);
+		uart_clk = clk_get(NULL, name);
+		if (IS_ERR(uart_clk)) {
+			printk(KERN_ERR "%s:%d: failed to get UART%d clock\n",
+					__func__, __LINE__, i);
+			continue;
+		}
+
+		clk_enable(uart_clk);
+
+		ports[i].uartclk = clk_get_rate(uart_clk);
+	}
+
+	platform_device_register(&serial_device);
+}
+
+static int __init nand_init(int chipsel, struct davinci_nand_pdata *data)
+{
+	struct platform_device *pdev;
+	u32	range;
+	int	ret;
+
+	/* Figure out the resource range from the ale/cle masks */
+	range = max(data->mask_cle, data->mask_ale);
+	range = PAGE_ALIGN(range + 4) - 1;
+
+	if (range >= SZ_16M)
+		return -EINVAL;
+
+	pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
+	if (!pdev)
+		return -ENOMEM;
+
+	pdev->name		= "davinci_nand";
+	pdev->id		= chipsel;
+	pdev->dev.platform_data	= data;
+
+	ret = platform_device_add_resources(pdev, nand_resources,
+			ARRAY_SIZE(nand_resources));
+	if (ret < 0) {
+		kfree(pdev);
+		return ret;
+	}
+
+	/* adjust emif window size */
+	pdev->resource[0].end += range;
+
+	return platform_device_register(pdev);
+}
+
+void __init tnetv107x_devices_init(struct tnetv107x_device_info *info)
+{
+	int i;
+
+	platform_device_register(&edma_device);
+	platform_device_register(&tnetv107x_wdt_device);
+
+	if (info->serial_config)
+		serial_init(info->serial_config);
+
+	for (i = 0; i < 2; i++)
+		if (info->mmc_config[i]) {
+			mmc_devices[i].dev.platform_data = info->mmc_config[i];
+			platform_device_register(&mmc_devices[i]);
+		}
+
+	for (i = 0; i < 4; i++)
+		if (info->nand_config[i])
+			nand_init(i, info->nand_config[i]);
+}
diff --git a/arch/arm/mach-davinci/include/mach/tnetv107x.h b/arch/arm/mach-davinci/include/mach/tnetv107x.h
new file mode 100644
index 0000000..2890893
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/tnetv107x.h
@@ -0,0 +1,55 @@
+/*
+ * Texas Instruments TNETV107X SoC Specific Defines
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#ifndef __ASM_ARCH_DAVINCI_TNETV107X_H
+#define __ASM_ARCH_DAVINCI_TNETV107X_H
+
+#include <asm/sizes.h>
+
+#define TNETV107X_DDR_BASE	0x80000000
+
+/*
+ * Fixed mapping for early init starts here. If low-level debug is enabled,
+ * this area also gets mapped via io_pg_offset and io_phys by the boot code.
+ * To fit in with the io_pg_offset calculation, the io base address selected
+ * here _must_ be a multiple of 2^20.
+ */
+#define TNETV107X_IO_BASE	0x08000000
+#define TNETV107X_IO_VIRT	(IO_VIRT + SZ_1M)
+
+#define PINMUX(x)		(4 * (x))
+#define TNETV107X_N_GPIO	65
+
+#ifndef __ASSEMBLY__
+
+#include <linux/serial_8250.h>
+#include <mach/mmc.h>
+#include <mach/nand.h>
+#include <mach/serial.h>
+
+struct tnetv107x_device_info {
+	struct davinci_uart_config	*serial_config;
+	struct davinci_mmc_config	*mmc_config[2];  /* 2 controllers */
+	struct davinci_nand_pdata	*nand_config[4]; /* 4 chipsels */
+};
+
+extern struct platform_device tnetv107x_wdt_device;
+
+extern void __init tnetv107x_init(void);
+extern void __init tnetv107x_devices_init(struct tnetv107x_device_info *);
+extern void __init tnetv107x_irq_init(void);
+
+#endif
+
+#endif /* __ASM_ARCH_DAVINCI_TNETV107X_H */
diff --git a/arch/arm/mach-davinci/tnetv107x.c b/arch/arm/mach-davinci/tnetv107x.c
new file mode 100644
index 0000000..2dfed3e
--- /dev/null
+++ b/arch/arm/mach-davinci/tnetv107x.c
@@ -0,0 +1,841 @@
+/*
+ * Texas Instruments TNETV107X SoC Support
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include <linux/platform_device.h>
+
+#include <asm/mach/map.h>
+
+#include <mach/common.h>
+#include <mach/time.h>
+#include <mach/cputype.h>
+#include <mach/psc.h>
+#include <mach/cp_intc.h>
+#include <mach/irqs.h>
+#include <mach/gpio.h>
+#include <mach/hardware.h>
+#include <mach/tnetv107x.h>
+
+#include "clock.h"
+#include "mux.h"
+
+/* Base addresses for on-chip devices */
+#define TNETV107X_INTC_BASE			0x03000000
+#define TNETV107X_TIMER0_BASE			0x08086500
+#define TNETV107X_TIMER1_BASE			0x08086600
+#define TNETV107X_CHIP_CFG_BASE			0x08087000
+#define TNETV107X_GPIO_BASE			0x08088000
+#define TNETV107X_CLOCK_CONTROL_BASE		0x0808a000
+#define TNETV107X_PSC_BASE			0x0808b000
+
+/* Reference clock frequencies */
+#define OSC_FREQ_ONCHIP		(24000 * 1000)
+#define OSC_FREQ_OFFCHIP_SYS	(25000 * 1000)
+#define OSC_FREQ_OFFCHIP_ETH	(25000 * 1000)
+#define OSC_FREQ_OFFCHIP_TDM	(19200 * 1000)
+
+#define N_PLLS	3
+
+/* Clock Control Registers */
+struct clk_ctrl_regs {
+	u32	pll_bypass;
+	u32	_reserved0;
+	u32	gem_lrst;
+	u32	_reserved1;
+	u32	pll_unlock_stat;
+	u32	sys_unlock;
+	u32	eth_unlock;
+	u32	tdm_unlock;
+};
+
+/* SSPLL Registers */
+struct sspll_regs {
+	u32	modes;
+	u32	post_div;
+	u32	pre_div;
+	u32	mult_factor;
+	u32	divider_range;
+	u32	bw_divider;
+	u32	spr_amount;
+	u32	spr_rate_div;
+	u32	diag;
+};
+
+/* Watchdog Timer Registers */
+struct wdt_regs {
+	u32	kick_lock;
+	u32	kick;
+	u32	change_lock;
+	u32	change ;
+	u32	disable_lock;
+	u32	disable;
+	u32	prescale_lock;
+	u32	prescale;
+};
+
+static struct clk_ctrl_regs __iomem *clk_ctrl_regs;
+
+static struct sspll_regs __iomem *sspll_regs[N_PLLS];
+static int sspll_regs_base[N_PLLS] = { 0x40, 0x80, 0xc0 };
+
+/* PLL Control Registers (same as in Davinci) */
+static void __iomem *pllctl_regs[N_PLLS];
+static int pllctl_regs_base[N_PLLS] = { 0x600, 0x200, 0x400 };
+
+/* PLL bypass bit shifts in clk_ctrl_regs->pll_bypass register */
+static u32 bypass_mask[N_PLLS] = { BIT(0), BIT(2), BIT(1) };
+
+/* offchip (external) reference clock frequencies */
+static u32 pll_ext_freq[] = {
+	OSC_FREQ_OFFCHIP_SYS,
+	OSC_FREQ_OFFCHIP_TDM,
+	OSC_FREQ_OFFCHIP_ETH
+};
+
+/* PSC control registers */
+static void __iomem *psc_regs[1];
+
+/* Host map for interrupt controller */
+static u32 intc_host_map[] = { 0x01010000, 0x01010101, -1 };
+
+static unsigned long clk_sspll_recalc(struct clk *clk);
+
+
+/* Level 1 - the PLLs */
+#define define_pll_clk(cname, pll, divmask)		\
+	static struct pll_data pll_##cname##_data = {	\
+		.num		= pll,			\
+		.div_ratio_mask	= divmask,		\
+	};						\
+	static struct clk pll_##cname##_clk = {		\
+		.name		= "pll_" #cname "_clk",	\
+		.pll_data	= &pll_##cname##_data,	\
+		.flags		= CLK_PLL,		\
+		.recalc		= clk_sspll_recalc,	\
+	}
+
+define_pll_clk(sys, 0, 0x1ff);
+define_pll_clk(tdm, 1, 0x0ff);
+define_pll_clk(eth, 2, 0x0ff);
+
+/* Level 2 - divided outputs from the PLLs */
+#define define_pll_div_clk(pll, cname, div)		\
+	static struct clk pll##_##cname##_clk = {	\
+		.name		= #pll "_" #cname "_clk",\
+		.parent		= &pll_##pll##_clk,	\
+		.flags		= CLK_PLL,		\
+		.div_reg	= PLLDIV##div,		\
+	}
+
+define_pll_div_clk(sys, arm1176,	1);
+define_pll_div_clk(sys, dsp,		2);
+define_pll_div_clk(sys, ddr,		3);
+define_pll_div_clk(sys, full,		4);
+define_pll_div_clk(sys, lcd,		5);
+define_pll_div_clk(sys, vlynq_ref,	6);
+define_pll_div_clk(sys, tsc,		7);
+define_pll_div_clk(sys, half,		8);
+
+define_pll_div_clk(eth, 5mhz,		1);
+define_pll_div_clk(eth, 50mhz,		2);
+define_pll_div_clk(eth, 125mhz,		3);
+define_pll_div_clk(eth, 250mhz,		4);
+define_pll_div_clk(eth, 25mhz,		5);
+
+define_pll_div_clk(tdm, 0,		1);
+define_pll_div_clk(tdm, extra,		2);
+define_pll_div_clk(tdm, 1,		3);
+
+
+/* Level 3 - LPSC gated clocks */
+#define __lpsc_clk(cname, _parent, mod, flg)		\
+	static struct clk clk_##cname = {		\
+		.name		= #cname,		\
+		.parent		= &_parent,		\
+		.lpsc		= TNETV107X_LPSC_##mod,\
+		.flags		= flg,			\
+	}
+
+#define lpsc_clk_enabled(cname, parent, mod)		\
+	__lpsc_clk(cname, parent, mod, ALWAYS_ENABLED)
+
+#define lpsc_clk(cname, parent, mod)			\
+	__lpsc_clk(cname, parent, mod, 0)
+
+lpsc_clk_enabled(arm,		sys_arm1176_clk, ARM);
+lpsc_clk_enabled(gem,		sys_dsp_clk,	GEM);
+lpsc_clk_enabled(ddr2_phy,	sys_ddr_clk,	DDR2_PHY);
+lpsc_clk_enabled(tpcc,		sys_full_clk,	TPCC);
+lpsc_clk_enabled(tptc0,		sys_full_clk,	TPTC0);
+lpsc_clk_enabled(tptc1,		sys_full_clk,	TPTC1);
+lpsc_clk_enabled(ram,		sys_full_clk,	RAM);
+lpsc_clk_enabled(aemif,		sys_full_clk,	AEMIF);
+lpsc_clk_enabled(chipcfg,	sys_half_clk,	CHIP_CFG);
+lpsc_clk_enabled(rom,		sys_half_clk,	ROM);
+lpsc_clk_enabled(secctl,	sys_half_clk,	SECCTL);
+lpsc_clk_enabled(keymgr,	sys_half_clk,	KEYMGR);
+lpsc_clk_enabled(gpio,		sys_half_clk,	GPIO);
+lpsc_clk_enabled(debugss,	sys_half_clk,	DEBUGSS);
+lpsc_clk_enabled(system,	sys_half_clk,	SYSTEM);
+lpsc_clk_enabled(ddr2_vrst,	sys_ddr_clk,	DDR2_EMIF1_VRST);
+lpsc_clk_enabled(ddr2_vctl_rst,	sys_ddr_clk,	DDR2_EMIF2_VCTL_RST);
+
+lpsc_clk(mbx_lite,	sys_arm1176_clk,	MBX_LITE);
+lpsc_clk(ethss,		eth_125mhz_clk,		ETHSS);
+lpsc_clk(tsc,		sys_tsc_clk,		TSC);
+lpsc_clk(uart0,		sys_half_clk,		UART0);
+lpsc_clk(uart1,		sys_half_clk,		UART1);
+lpsc_clk(uart2,		sys_half_clk,		UART2);
+lpsc_clk(pktsec,	sys_half_clk,		PKTSEC);
+lpsc_clk(keypad,	sys_half_clk,		KEYPAD);
+lpsc_clk(mdio,		sys_half_clk,		MDIO);
+lpsc_clk(sdio0,		sys_half_clk,		SDIO0);
+lpsc_clk(sdio1,		sys_half_clk,		SDIO1);
+lpsc_clk(timer0,	sys_half_clk,		TIMER0);
+lpsc_clk(timer1,	sys_half_clk,		TIMER1);
+lpsc_clk(wdt_arm,	sys_half_clk,		WDT_ARM);
+lpsc_clk(wdt_dsp,	sys_half_clk,		WDT_DSP);
+lpsc_clk(ssp,		sys_half_clk,		SSP);
+lpsc_clk(tdm0,		tdm_0_clk,		TDM0);
+lpsc_clk(tdm1,		tdm_1_clk,		TDM1);
+lpsc_clk(vlynq,		sys_vlynq_ref_clk,	VLYNQ);
+lpsc_clk(mcdma,		sys_half_clk,		MCDMA);
+lpsc_clk(usb0,		sys_half_clk,		USB0);
+lpsc_clk(usb1,		sys_half_clk,		USB1);
+lpsc_clk(usbss,		sys_half_clk,		USBSS);
+lpsc_clk(ethss_rgmii,	eth_250mhz_clk,		ETHSS_RGMII);
+lpsc_clk(imcop,		sys_dsp_clk,		IMCOP);
+lpsc_clk(spare,		sys_half_clk,		SPARE);
+
+/* LCD needs a full power down to clear controller state */
+__lpsc_clk(lcd, sys_lcd_clk, LCD, PSC_SWRSTDISABLE);
+
+
+/* Level 4 - leaf clocks for LPSC modules shared across drivers */
+static struct clk clk_rng = { .name = "rng", .parent = &clk_pktsec };
+static struct clk clk_pka = { .name = "pka", .parent = &clk_pktsec };
+
+static struct clk_lookup clks[] = {
+	CLK(NULL,		"pll_sys_clk",		&pll_sys_clk),
+	CLK(NULL,		"pll_eth_clk",		&pll_eth_clk),
+	CLK(NULL,		"pll_tdm_clk",		&pll_tdm_clk),
+	CLK(NULL,		"sys_arm1176_clk",	&sys_arm1176_clk),
+	CLK(NULL,		"sys_dsp_clk",		&sys_dsp_clk),
+	CLK(NULL,		"sys_ddr_clk",		&sys_ddr_clk),
+	CLK(NULL,		"sys_full_clk",		&sys_full_clk),
+	CLK(NULL,		"sys_lcd_clk",		&sys_lcd_clk),
+	CLK(NULL,		"sys_vlynq_ref_clk",	&sys_vlynq_ref_clk),
+	CLK(NULL,		"sys_tsc_clk",		&sys_tsc_clk),
+	CLK(NULL,		"sys_half_clk",		&sys_half_clk),
+	CLK(NULL,		"eth_5mhz_clk",		&eth_5mhz_clk),
+	CLK(NULL,		"eth_50mhz_clk",	&eth_50mhz_clk),
+	CLK(NULL,		"eth_125mhz_clk",	&eth_125mhz_clk),
+	CLK(NULL,		"eth_250mhz_clk",	&eth_250mhz_clk),
+	CLK(NULL,		"eth_25mhz_clk",	&eth_25mhz_clk),
+	CLK(NULL,		"tdm_0_clk",		&tdm_0_clk),
+	CLK(NULL,		"tdm_extra_clk",	&tdm_extra_clk),
+	CLK(NULL,		"tdm_1_clk",		&tdm_1_clk),
+	CLK(NULL,		"clk_arm",		&clk_arm),
+	CLK(NULL,		"clk_gem",		&clk_gem),
+	CLK(NULL,		"clk_ddr2_phy",		&clk_ddr2_phy),
+	CLK(NULL,		"clk_tpcc",		&clk_tpcc),
+	CLK(NULL,		"clk_tptc0",		&clk_tptc0),
+	CLK(NULL,		"clk_tptc1",		&clk_tptc1),
+	CLK(NULL,		"clk_ram",		&clk_ram),
+	CLK(NULL,		"clk_mbx_lite",		&clk_mbx_lite),
+	CLK("tnetv107x-fb.0",	NULL,			&clk_lcd),
+	CLK(NULL,		"clk_ethss",		&clk_ethss),
+	CLK(NULL,		"aemif",		&clk_aemif),
+	CLK(NULL,		"clk_chipcfg",		&clk_chipcfg),
+	CLK("tnetv107x-ts.0",	NULL,			&clk_tsc),
+	CLK(NULL,		"clk_rom",		&clk_rom),
+	CLK(NULL,		"uart2",		&clk_uart2),
+	CLK(NULL,		"clk_pktsec",		&clk_pktsec),
+	CLK("tnetv107x-rng.0",	NULL,			&clk_rng),
+	CLK("tnetv107x-pka.0",	NULL,			&clk_pka),
+	CLK(NULL,		"clk_secctl",		&clk_secctl),
+	CLK(NULL,		"clk_keymgr",		&clk_keymgr),
+	CLK("tnetv107x-keypad.0", NULL,			&clk_keypad),
+	CLK(NULL,		"clk_gpio",		&clk_gpio),
+	CLK(NULL,		"clk_mdio",		&clk_mdio),
+	CLK("davinci_mmc.0",	NULL,			&clk_sdio0),
+	CLK(NULL,		"uart0",		&clk_uart0),
+	CLK(NULL,		"uart1",		&clk_uart1),
+	CLK(NULL,		"timer0",		&clk_timer0),
+	CLK(NULL,		"timer1",		&clk_timer1),
+	CLK(NULL,		"clk_wdt_arm",		&clk_wdt_arm),
+	CLK(NULL,		"clk_wdt_dsp",		&clk_wdt_dsp),
+	CLK("ti-ssp.0",		NULL,			&clk_ssp),
+	CLK(NULL,		"clk_tdm0",		&clk_tdm0),
+	CLK(NULL,		"clk_vlynq",		&clk_vlynq),
+	CLK(NULL,		"clk_mcdma",		&clk_mcdma),
+	CLK(NULL,		"clk_usb0",		&clk_usb0),
+	CLK(NULL,		"clk_tdm1",		&clk_tdm1),
+	CLK(NULL,		"clk_debugss",		&clk_debugss),
+	CLK(NULL,		"clk_ethss_rgmii",	&clk_ethss_rgmii),
+	CLK(NULL,		"clk_system",		&clk_system),
+	CLK(NULL,		"clk_imcop",		&clk_imcop),
+	CLK(NULL,		"clk_spare",		&clk_spare),
+	CLK("davinci_mmc.1",	NULL,			&clk_sdio1),
+	CLK(NULL,		"clk_usb1",		&clk_usb1),
+	CLK(NULL,		"clk_usbss",		&clk_usbss),
+	CLK(NULL,		"clk_ddr2_vrst",	&clk_ddr2_vrst),
+	CLK(NULL,		"clk_ddr2_vctl_rst",	&clk_ddr2_vctl_rst),
+	CLK(NULL,		NULL,			NULL),
+};
+
+static const struct mux_config pins[] = {
+#ifdef CONFIG_DAVINCI_MUX
+	MUX_CFG(TNETV107X, ASR_A00,		0, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO32,		0, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A01,		0, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO33,		0, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A02,		0, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO34,		0, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A03,		0, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO35,		0, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A04,		0, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO36,		0, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A05,		0, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO37,		0, 25, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A06,		1, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO38,		1, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A07,		1, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO39,		1, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A08,		1, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO40,		1, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A09,		1, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO41,		1, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A10,		1, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO42,		1, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A11,		1, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, BOOT_STRP_0,		1, 25, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A12,		2, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, BOOT_STRP_1,		2, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A13,		2, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO43,		2, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A14,		2, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO44,		2, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A15,		2, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO45,		2, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A16,		2, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO46,		2, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A17,		2, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO47,		2, 25, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_A18,		3, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO48,		3, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO1_DATA3_0,	3, 0, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_A19,		3, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO49,		3, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO1_DATA2_0,	3, 5, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_A20,		3, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO50,		3, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO1_DATA1_0,	3, 10, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_A21,		3, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO51,		3, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO1_DATA0_0,	3, 15, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_A22,		3, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO52,		3, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO1_CMD_0,		3, 20, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_A23,		3, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO53,		3, 25, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO1_CLK_0,		3, 25, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_BA_1,		4, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO54,		4, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SYS_PLL_CLK,		4, 0, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_CS0,		4, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, ASR_CS1,		4, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, ASR_CS2,		4, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM_PLL_CLK,		4, 15, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_CS3,		4, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, ETH_PHY_CLK,		4, 20, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, ASR_D00,		4, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO55,		4, 25, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D01,		5, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO56,		5, 0, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D02,		5, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO57,		5, 5, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D03,		5, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO58,		5, 10, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D04,		5, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO59_0,		5, 15, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D05,		5, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO60_0,		5, 20, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D06,		5, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO61_0,		5, 25, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D07,		6, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO62_0,		6, 0, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D08,		6, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO63_0,		6, 5, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D09,		6, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO64_0,		6, 10, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D10,		6, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SDIO1_DATA3_1,	6, 15, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D11,		6, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SDIO1_DATA2_1,	6, 20, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D12,		6, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SDIO1_DATA1_1,	6, 25, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D13,		7, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SDIO1_DATA0_1,	7, 0, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D14,		7, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SDIO1_CMD_1,		7, 5, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_D15,		7, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SDIO1_CLK_1,		7, 10, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_OE,		7, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, BOOT_STRP_2,		7, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_RNW,		7, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO29_0,		7, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_WAIT,		7, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO30_0,		7, 25, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_WE,		8, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, BOOT_STRP_3,		8, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, ASR_WE_DQM0,		8, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO31,		8, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD17_0,		8, 5, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, ASR_WE_DQM1,		8, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, ASR_BA0_0,		8, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, VLYNQ_CLK,		9, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO14,		9, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD19_0,		9, 0, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, VLYNQ_RXD0,		9, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO15,		9, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD20_0,		9, 5, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, VLYNQ_RXD1,		9, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO16,		9, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD21_0,		9, 10, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, VLYNQ_TXD0,		9, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO17,		9, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD22_0,		9, 15, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, VLYNQ_TXD1,		9, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO18,		9, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD23_0,		9, 20, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, SDIO0_CLK,		10, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO19,		10, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO0_CMD,		10, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO20,		10, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO0_DATA0,		10, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO21,		10, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO0_DATA1,		10, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO22,		10, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO0_DATA2,		10, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO23,		10, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SDIO0_DATA3,		10, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO24,		10, 25, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, EMU0,		11, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, EMU1,		11, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, RTCK,		12, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TRST_N,		12, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TCK,			12, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDI,			12, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDO,			12, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TMS,			12, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM1_CLK,		13, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM1_RX,		13, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM1_TX,		13, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM1_FS,		13, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_R0,		14, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_R1,		14, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_R2,		14, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_R3,		14, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_R4,		14, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_R5,		14, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_R6,		15, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO12,		15, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, KEYPAD_R7,		15, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO10,		15, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, KEYPAD_C0,		15, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_C1,		15, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_C2,		15, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_C3,		15, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_C4,		16, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_C5,		16, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, KEYPAD_C6,		16, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO13,		16, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, TEST_CLK_IN,		16, 10, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, KEYPAD_C7,		16, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO11,		16, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, SSP0_0,		17, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SCC_DCLK,		17, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD20_1,		17, 0, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, SSP0_1,		17, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SCC_CS_N,		17, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD21_1,		17, 5, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, SSP0_2,		17, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SCC_D,		17, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD22_1,		17, 10, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, SSP0_3,		17, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, SCC_RESETN,		17, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, LCD_PD23_1,		17, 15, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, SSP1_0,		18, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO25,		18, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, UART2_CTS,		18, 0, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, SSP1_1,		18, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO26,		18, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, UART2_RD,		18, 5, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, SSP1_2,		18, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO27,		18, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, UART2_RTS,		18, 10, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, SSP1_3,		18, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO28,		18, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, UART2_TD,		18, 15, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, UART0_CTS,		19, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, UART0_RD,		19, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, UART0_RTS,		19, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, UART0_TD,		19, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, UART1_RD,		19, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, UART1_TD,		19, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_AC_NCS,		20, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_HSYNC_RNW,	20, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_VSYNC_A0,	20, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_MCLK,		20, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD16_0,		20, 15, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, LCD_PCLK_E,		20, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD00,		20, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD01,		21, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD02,		21, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD03,		21, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD04,		21, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD05,		21, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD06,		21, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD07,		22, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD08,		22, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO59_1,		22, 5, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, LCD_PD09,		22, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO60_1,		22, 10, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, LCD_PD10,		22, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, ASR_BA0_1,		22, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, GPIO61_1,		22, 15, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, LCD_PD11,		22, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO62_1,		22, 20, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, LCD_PD12,		22, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO63_1,		22, 25, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, LCD_PD13,		23, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO64_1,		23, 0, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, LCD_PD14,		23, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO29_1,		23, 5, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, LCD_PD15,		23, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO30_1,		23, 10, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, EINT0,		24, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO08,		24, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, EINT1,		24, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, GPIO09,		24, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, GPIO00,		24, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD20_2,		24, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, TDM_CLK_IN_2,	24, 10, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, GPIO01,		24, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD21_2,		24, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, 24M_CLK_OUT_1,	24, 15, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, GPIO02,		24, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD22_2,		24, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, GPIO03,		24, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD23_2,		24, 25, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, GPIO04,		25, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD16_1,		25, 0, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, USB0_RXERR,		25, 0, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, GPIO05,		25, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD17_1,		25, 5, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, TDM_CLK_IN_1,	25, 5, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, GPIO06,		25, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD18,		25, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, 24M_CLK_OUT_2,	25, 10, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, GPIO07,		25, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, LCD_PD19_1,		25, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, USB1_RXERR,		25, 15, 0x1f, 0x0c, false)
+	MUX_CFG(TNETV107X, ETH_PLL_CLK,		25, 15, 0x1f, 0x1c, false)
+	MUX_CFG(TNETV107X, MDIO,		26, 0, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, MDC,			26, 5, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, AIC_MUTE_STAT_N,	26, 10, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM0_CLK,		26, 10, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, AIC_HNS_EN_N,	26, 15, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM0_FS,		26, 15, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, AIC_HDS_EN_STAT_N,	26, 20, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM0_TX,		26, 20, 0x1f, 0x04, false)
+	MUX_CFG(TNETV107X, AIC_HNF_EN_STAT_N,	26, 25, 0x1f, 0x00, false)
+	MUX_CFG(TNETV107X, TDM0_RX,		26, 25, 0x1f, 0x04, false)
+#endif
+};
+
+/* FIQ are pri 0-1; otherwise 2-7, with 7 lowest priority */
+static u8 irq_prios[TNETV107X_N_CP_INTC_IRQ] = {
+	/* fill in default priority 7 */
+	[0 ... (TNETV107X_N_CP_INTC_IRQ - 1)]	= 7,
+	/* now override as needed, e.g. [xxx] = 5 */
+};
+
+/* Contents of JTAG ID register used to identify exact cpu type */
+static struct davinci_id ids[] = {
+	{
+		.variant	= 0x0,
+		.part_no	= 0xb8a1,
+		.manufacturer	= 0x017,
+		.cpu_id		= DAVINCI_CPU_ID_TNETV107X,
+		.name		= "tnetv107x rev1.0",
+	},
+};
+
+static struct davinci_timer_instance timer_instance[2] = {
+	{
+		.bottom_irq	= IRQ_TNETV107X_TIMER_0_TINT12,
+		.top_irq	= IRQ_TNETV107X_TIMER_0_TINT34,
+	},
+	{
+		.bottom_irq	= IRQ_TNETV107X_TIMER_1_TINT12,
+		.top_irq	= IRQ_TNETV107X_TIMER_1_TINT34,
+	},
+};
+
+static struct davinci_timer_info timer_info = {
+	.timers		= timer_instance,
+	.clockevent_id	= T0_BOT,
+	.clocksource_id	= T0_TOP,
+};
+
+/*
+ * TNETV107X platforms do not use the static mappings from Davinci
+ * IO_PHYS/IO_VIRT. This SOC's interesting MMRs are at different addresses,
+ * and changing IO_PHYS would break away from existing Davinci SOCs.
+ *
+ * The primary impact of the current model is that IO_ADDRESS() is not to be
+ * used to map registers on TNETV107X. With the exception of early boot code
+ * in tnetv107x_init() (where fixed maps are necessary), all other pieces of
+ * code absolutely _must_ use ioremap().
+ *
+ * 1.	The first section in here is specifically for edma, even through the
+ *	edma driver code properly ioremap()s its register space.  This is
+ *	because the edma MMRs on tnetv107x unfortunately fall within the
+ *	davinci IO_PHYS - (IO_PHYS + IO_SIZE) range, and therefore the edma
+ *	driver's ioremap() gets subverted by davinci_ioremap(). Yikes!
+ *
+ * 2.	The second chunk is for INTC - no major issues here.  If the cp_intc
+ *	code were to someday ioremap() internally, we could very well get rid
+ *	of this map.
+ *
+ * 3.	The third chunk maps in register areas that need to be populated into
+ *	davinci_soc_info.  Note that alignment restrictions come into play if
+ *	low-level debug is enabled (see note in <mach/tnetv107x.h>).
+ */
+static struct map_desc tnetv107x_io_desc[] = {
+	{	/* EDMA */
+		.virtual	= IO_VIRT,
+		.pfn		= __phys_to_pfn(IO_PHYS),
+		.length		= SZ_128K,
+		.type		= MT_DEVICE
+	},
+	{	/* INTC */
+		.virtual	= IO_VIRT + SZ_128K,
+		.pfn		= __phys_to_pfn(TNETV107X_INTC_BASE),
+		.length		= SZ_16K,
+		.type		= MT_DEVICE
+	},
+	{	/* Most of the rest */
+		.virtual	= TNETV107X_IO_VIRT,
+		.pfn		= __phys_to_pfn(TNETV107X_IO_BASE),
+		.length		= IO_SIZE - SZ_1M,
+		.type		= MT_DEVICE
+	},
+};
+
+void __init tnetv107x_irq_init(void)
+{
+	struct davinci_soc_info *soc_info = &davinci_soc_info;
+
+	cp_intc_init(soc_info->intc_base, soc_info->intc_irq_num,
+			soc_info->intc_irq_prios, intc_host_map);
+}
+
+static unsigned long clk_sspll_recalc(struct clk *clk)
+{
+	int		pll;
+	unsigned long	mult = 0, prediv = 1, postdiv = 1;
+	unsigned long	ref = OSC_FREQ_ONCHIP, ret;
+	u32		tmp;
+
+	if (WARN_ON(!clk->pll_data))
+		return clk->rate;
+
+	pll = clk->pll_data->num;
+
+	tmp = __raw_readl(&clk_ctrl_regs->pll_bypass);
+	if (!(tmp & bypass_mask[pll])) {
+		mult	= __raw_readl(&sspll_regs[pll]->mult_factor);
+		prediv	= __raw_readl(&sspll_regs[pll]->pre_div) + 1;
+		postdiv	= __raw_readl(&sspll_regs[pll]->post_div) + 1;
+	}
+
+	tmp = __raw_readl(pllctl_regs[pll] + PLLCTL);
+	if (tmp & PLLCTL_CLKMODE)
+		ref = pll_ext_freq[pll];
+
+	clk->pll_data->input_rate = ref;
+
+	tmp = __raw_readl(pllctl_regs[pll] + PLLCTL);
+	if (!(tmp & PLLCTL_PLLEN))
+		return ref;
+
+	ret = ref;
+	if (mult)
+		ret += ((unsigned long long)ref * mult) / 256;
+
+	ret /= (prediv * postdiv);
+
+	return ret;
+}
+
+static int tnetv107x_wdt_set_period(struct wdt_regs __iomem *regs,
+		unsigned long msec, unsigned long refclk)
+{
+	unsigned long change;
+	unsigned long count;
+	unsigned long prescale = 1;
+
+	refclk /= 1000;
+
+	/* compute prescale and change reg values */
+	count = refclk * msec;
+
+	if (count > 0xffff) {
+		change = count / 0xffff + 1;
+		prescale = count / change;
+	}    else {
+		change =  count;
+	}
+
+	__raw_writel(0x5a5a, &regs->prescale_lock);
+	if ((__raw_readl(&regs->prescale_lock) & 0x3) != 1)
+		return -EIO;
+
+	__raw_writel(0xa5a5, &regs->prescale_lock);
+	if ((__raw_readl(&regs->prescale_lock) & 0x3) != 3)
+		return -EIO;
+
+	__raw_writel(prescale - 1, &regs->prescale);
+
+	__raw_writel(0x6666, &regs->change_lock);
+	if ((__raw_readl(&regs->change_lock) & 0x3) != 1)
+		return -EIO;
+
+	__raw_writel(0xbbbb, &regs->change_lock);
+	if ((__raw_readl(&regs->change_lock) & 0x3) != 3)
+		return -EIO;
+
+	__raw_writel(change, &regs->change);
+	return 0;
+}
+
+static int tnetv107x_wdt_ctrl(struct wdt_regs __iomem *regs, int enable)
+{
+
+	enable = enable ? 1 : 0;
+
+	__raw_writel(0x7777, &regs->disable_lock);
+	if ((__raw_readl(&regs->disable_lock) & 0x3) != 1)
+		return -EIO;
+
+	__raw_writel(0xcccc, &regs->disable_lock);
+	if ((__raw_readl(&regs->disable_lock) & 0x3) != 2)
+		return -EIO;
+
+	__raw_writel(0xdddd, &regs->disable_lock);
+	if ((__raw_readl(&regs->disable_lock) & 0x3) != 3)
+		return -EIO;
+
+	__raw_writel(enable, &regs->disable);
+	return 0;
+}
+
+static int tnetv107x_wdt_kick(struct wdt_regs __iomem *regs)
+{
+	__raw_writel(0x5555, &regs->kick_lock);
+	if ((__raw_readl(&regs->kick_lock) & 0x3) != 1)
+		return -EIO;
+
+	__raw_writel(0xaaaa, &regs->kick_lock);
+	if ((__raw_readl(&regs->kick_lock) & 0x3) != 3)
+		return -EIO;
+
+	__raw_writel(1, &regs->kick);
+	return 0;
+}
+
+static void tnetv107x_watchdog_reset(struct platform_device *pdev)
+{
+	struct wdt_regs __iomem *regs;
+	struct clk		*wdt_clk;
+	unsigned long		wdt_clk_rate;
+
+	regs = ioremap(pdev->resource[0].start, SZ_4K);
+	wdt_clk = clk_get(&pdev->dev, NULL);
+	if (WARN_ON(IS_ERR(wdt_clk)))
+		return;
+	clk_enable(wdt_clk);
+	wdt_clk_rate	= clk_get_rate(wdt_clk);
+
+	tnetv107x_wdt_ctrl(regs, 0);
+	tnetv107x_wdt_set_period(regs, 1, wdt_clk_rate);
+	tnetv107x_wdt_ctrl(regs, 1);
+	tnetv107x_wdt_kick(regs);
+}
+
+static struct davinci_soc_info tnetv107x_soc_info = {
+	.ids			= ids,
+	.ids_num		= ARRAY_SIZE(ids),
+	.cpu_clks		= clks,
+	.psc_bases		= psc_regs,
+	.psc_bases_num		= ARRAY_SIZE(psc_regs),
+	.pinmux_pins		= pins,
+	.pinmux_pins_num	= ARRAY_SIZE(pins),
+	.intc_type		= DAVINCI_INTC_TYPE_CP_INTC,
+	.intc_irq_prios		= irq_prios,
+	.intc_irq_num		= TNETV107X_N_CP_INTC_IRQ,
+	.gpio_type		= GPIO_TYPE_TNETV107X,
+	.gpio_num		= TNETV107X_N_GPIO,
+	.timer_info		= &timer_info,
+	.reset			= tnetv107x_watchdog_reset,
+	.reset_device		= &tnetv107x_wdt_device,
+};
+
+void __init tnetv107x_init(void)
+{
+	void __iomem *tmp;
+	int i;
+
+	davinci_io_init(tnetv107x_io_desc, ARRAY_SIZE(tnetv107x_io_desc));
+
+	clk_ctrl_regs = tmp = ioremap(TNETV107X_CLOCK_CONTROL_BASE, SZ_4K);
+
+	for (i = 0; i < N_PLLS; i++) {
+		sspll_regs[i] = tmp + sspll_regs_base[i];
+		pllctl_regs[i] = tmp + pllctl_regs_base[i];
+	}
+
+	pll_sys_data.base = pllctl_regs[0];
+	pll_tdm_data.base = pllctl_regs[1];
+	pll_eth_data.base = pllctl_regs[2];
+
+	tmp = ioremap(TNETV107X_CHIP_CFG_BASE, SZ_4K);
+	tnetv107x_soc_info.jtag_id_base	= tmp + 0x018;
+	tnetv107x_soc_info.pinmux_base	= tmp + 0x150;
+
+	psc_regs[0] = ioremap(TNETV107X_PSC_BASE, SZ_4K);
+	tnetv107x_soc_info.intc_base = ioremap(TNETV107X_INTC_BASE, SZ_16K);
+	timer_instance[0].base = ioremap(TNETV107X_TIMER0_BASE, 0x100);
+	timer_instance[1].base = ioremap(TNETV107X_TIMER1_BASE, 0x100);
+	tnetv107x_soc_info.gpio_base = ioremap(TNETV107X_GPIO_BASE, SZ_4K);
+
+	davinci_common_init(&tnetv107x_soc_info);
+}
-- 
1.6.3.3


From cyril at ti.com  Fri Apr 23 12:57:04 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 23 Apr 2010 13:57:04 -0400
Subject: [PATCH v4 13/13] Davinci: tnetv107x evm board initial support
In-Reply-To: <1272045424-19240-13-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
	<1272045424-19240-10-git-send-email-cyril@ti.com>
	<1272045424-19240-11-git-send-email-cyril@ti.com>
	<1272045424-19240-12-git-send-email-cyril@ti.com>
	<1272045424-19240-13-git-send-email-cyril@ti.com>
Message-ID: <1272045424-19240-14-git-send-email-cyril@ti.com>

Added support for tnetv107x evaluation module.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
v4: updated copyrights
v4: squashed relevant gpio pins into sdio1 pin list
v4: eliminated platform device definitions, moved to tnetv107x_devices_init()
    implementation instead
v4: platform devices moved out to devices-tnetv107x.c
v3: moved some base address and edma channel definitions here
v3: minor formatting changes

 arch/arm/mach-davinci/Kconfig               |    7 +
 arch/arm/mach-davinci/Makefile              |    1 +
 arch/arm/mach-davinci/board-tnetv107x-evm.c |  171 +++++++++++++++++++++++++++
 3 files changed, 179 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-davinci/board-tnetv107x-evm.c

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index a67b47b..71f90f8 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -178,6 +178,13 @@ config DA850_UI_RMII
 
 endchoice
 
+config MACH_TNETV107X
+	bool "TI TNETV107X Reference Platform"
+	default ARCH_DAVINCI_TNETV107X
+	depends on ARCH_DAVINCI_TNETV107X
+	help
+	  Say Y here to select the TI TNETV107X Evaluation Module.
+
 config DAVINCI_MUX
 	bool "DAVINCI multiplexing support"
 	depends on ARCH_DAVINCI
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 62c5116..eab4c0f 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM)	+= board-dm646x-evm.o cdce949.o
 obj-$(CONFIG_MACH_DAVINCI_DM365_EVM)	+= board-dm365-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA830_EVM)	+= board-da830-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)	+= board-da850-evm.o
+obj-$(CONFIG_MACH_TNETV107X)		+= board-tnetv107x-evm.o
 
 # Power Management
 obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c b/arch/arm/mach-davinci/board-tnetv107x-evm.c
new file mode 100644
index 0000000..62a7b02
--- /dev/null
+++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
@@ -0,0 +1,171 @@
+/*
+ * Texas Instruments TNETV107X EVM Board Support
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/console.h>
+#include <linux/dma-mapping.h>
+#include <linux/interrupt.h>
+#include <linux/gpio.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+#include <linux/ratelimit.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+#include <asm/mach/arch.h>
+#include <asm/mach-types.h>
+
+#include <mach/irqs.h>
+#include <mach/edma.h>
+#include <mach/mux.h>
+#include <mach/tnetv107x.h>
+
+#define EVM_MMC_WP_GPIO		21
+#define EVM_MMC_CD_GPIO		24
+
+static int initialize_gpio(int gpio, char *desc)
+{
+	int ret;
+
+	ret = gpio_request(gpio, desc);
+	if (ret < 0) {
+		pr_err_ratelimited("cannot open %s gpio\n", desc);
+		return -ENOSYS;
+	}
+	gpio_direction_input(gpio);
+	return gpio;
+}
+
+static int mmc_get_cd(int index)
+{
+	static int gpio;
+
+	if (!gpio)
+		gpio = initialize_gpio(EVM_MMC_CD_GPIO, "mmc card detect");
+
+	if (gpio < 0)
+		return gpio;
+
+	return gpio_get_value(gpio) ? 0 : 1;
+}
+
+static int mmc_get_ro(int index)
+{
+	static int gpio;
+
+	if (!gpio)
+		gpio = initialize_gpio(EVM_MMC_WP_GPIO, "mmc write protect");
+
+	if (gpio < 0)
+		return gpio;
+
+	return gpio_get_value(gpio) ? 1 : 0;
+}
+
+static struct davinci_mmc_config mmc_config = {
+	.get_cd		= mmc_get_cd,
+	.get_ro		= mmc_get_ro,
+	.wires		= 4,
+	.max_freq	= 50000000,
+	.caps		= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
+	.version	= MMC_CTLR_VERSION_1,
+};
+
+static const short sdio1_pins[] __initdata = {
+	TNETV107X_SDIO1_CLK_1,		TNETV107X_SDIO1_CMD_1,
+	TNETV107X_SDIO1_DATA0_1,	TNETV107X_SDIO1_DATA1_1,
+	TNETV107X_SDIO1_DATA2_1,	TNETV107X_SDIO1_DATA3_1,
+	TNETV107X_GPIO21,		TNETV107X_GPIO24,
+	-1
+};
+
+const short uart1_pins[] __initdata = {
+	TNETV107X_UART1_RD,		TNETV107X_UART1_TD,
+	-1
+};
+
+static struct mtd_partition nand_partitions[] = {
+	/* bootloader (U-Boot, etc) in first 12 sectors */
+	{
+		.name		= "bootloader",
+		.offset		= 0,
+		.size		= (12*SZ_128K),
+		.mask_flags	= MTD_WRITEABLE,	/* force read-only */
+	},
+	/* bootloader params in the next sector */
+	{
+		.name		= "params",
+		.offset		= MTDPART_OFS_NXTBLK,
+		.size		= SZ_128K,
+		.mask_flags	= MTD_WRITEABLE,	/* force read-only */
+	},
+	/* kernel */
+	{
+		.name		= "kernel",
+		.offset		= MTDPART_OFS_NXTBLK,
+		.size		= SZ_4M,
+		.mask_flags	= 0,
+	},
+	/* file system */
+	{
+		.name		= "filesystem",
+		.offset		= MTDPART_OFS_NXTBLK,
+		.size		= MTDPART_SIZ_FULL,
+		.mask_flags	= 0,
+	}
+};
+
+static struct davinci_nand_pdata nand_config = {
+	.mask_cle	= 0x4000,
+	.mask_ale	= 0x2000,
+	.parts		= nand_partitions,
+	.nr_parts	= ARRAY_SIZE(nand_partitions),
+	.ecc_mode	= NAND_ECC_HW,
+};
+
+struct davinci_uart_config serial_config __initconst = {
+	.enabled_uarts	= BIT(1),
+};
+
+struct tnetv107x_device_info evm_device_info __initconst = {
+	.serial_config		= &serial_config,
+	.mmc_config[1]		= &mmc_config,
+	.nand_config[0]		= &nand_config,
+};
+
+static __init void tnetv107x_evm_board_init(void)
+{
+	davinci_cfg_reg_list(sdio1_pins);
+	davinci_cfg_reg_list(uart1_pins);
+
+	tnetv107x_devices_init(&evm_device_info);
+}
+
+#ifdef CONFIG_SERIAL_8250_CONSOLE
+static int __init tnetv107x_evm_console_init(void)
+{
+	return add_preferred_console("ttyS", 0, "115200");
+}
+console_initcall(tnetv107x_evm_console_init);
+#endif
+
+MACHINE_START(TNETV107X, "TNETV107X EVM")
+	.phys_io	= TNETV107X_IO_BASE,
+	.io_pg_offst	= (TNETV107X_IO_VIRT >> 18) & 0xfffc,
+	.boot_params	= (TNETV107X_DDR_BASE + 0x100),
+	.map_io		= tnetv107x_init,
+	.init_irq	= tnetv107x_irq_init,
+	.timer		= &davinci_timer,
+	.init_machine	= tnetv107x_evm_board_init,
+MACHINE_END
-- 
1.6.3.3


From jtobias at viaas.com  Fri Apr 23 15:09:51 2010
From: jtobias at viaas.com (John Tobias)
Date: Fri, 23 Apr 2010 13:09:51 -0700
Subject: Possible uboot crashes
Message-ID: <x2n66b2b2311004231309r3e885ab6yf9dce952cd4997af@mail.gmail.com>

Hello Guys,

I would like to know what are the possible chances that u-boot/ubl crashes?.
I am looking for some theory/scenario that I can possibly connect/apply the
scenario to what happened to my device based on dm6446.

The device has been running for a year now and for some reason it never come
back anymore. I connect through the serial port of the device and check if
there's something different. The device was in the state where the
bootloader is missing. I re-program the u-boot and the device boot it again
as I expected.
The /dev/mtd0 and /dev/mtd1 are not writable on linux space in order to
screwed up the uboot.

Thanks,

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100423/fb672353/attachment.html>

From sshtylyov at mvista.com  Fri Apr 23 16:10:56 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Sat, 24 Apr 2010 01:10:56 +0400
Subject: [PATCH v4 08/13] Davinci: iotable based ioremap() interception
In-Reply-To: <1272045424-19240-9-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
Message-ID: <4BD20CE0.8000409@mvista.com>

Hello.

Cyril Chemparathy wrote:

> This patch allows for a more flexible ioremap() interception based on iotable
> contents.
>
> SoCs that need ioremap() to fill up davinci_soc_info may directly call
> davinci_io_init() and use ioremap() as needed.  Such SoCs must not fill
> io_desc and io_desc_num entries in struct davinci_soc_info.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
> ---
> v4: removed __davinci_ioremap() and related infrastructure
> v4: split davinci_io_init() out of davinci_common_init()
>   

[...]

> diff --git a/arch/arm/mach-davinci/io.c b/arch/arm/mach-davinci/io.c
> index a1c0b6b..81862ec 100644
> --- a/arch/arm/mach-davinci/io.c
> +++ b/arch/arm/mach-davinci/io.c
>   
[...]
> @@ -36,3 +48,30 @@ void davinci_iounmap(volatile void __iomem *addr)
>  		__iounmap(addr);
>  }
>  EXPORT_SYMBOL(davinci_iounmap);
> +
> +void __init davinci_io_init(struct map_desc *desc, unsigned long desc_num)
> +{
> +	if (!desc || !desc_num)
> +		return;
> +
> +	/* silently refuse to init twice ...*/
> +	if (davinci_io_desc) {
> +		/* ... unless things change */
> +		BUG_ON(davinci_io_desc != desc ||
> +			davinci_io_desc_num != desc_num);
> +		return;
> +	}
> +
> +	davinci_io_desc = desc;
> +	davinci_io_desc_num = desc_num;
> +
> +	iotable_init(desc, desc_num);
> +
> +	/*
> +	 * Normally devicemaps_init() would flush caches and tlb after
> +	 * mdesc->map_io(), but we must also do it here because of the CPU
> +	 * revision check below.
>   

  This comments needs fixing as there's no revision check below -- it's 
in different file now. :-)

> +	 */
> +	local_flush_tlb_all();
> +	flush_cache_all();
> +}
>   

WBR, Sergei


From sshtylyov at mvista.com  Fri Apr 23 16:12:20 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Sat, 24 Apr 2010 01:12:20 +0400
Subject: [PATCH v4 05/13] Davinci: gpio - controller type support
In-Reply-To: <1272045424-19240-6-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
Message-ID: <4BD20D34.3020606@mvista.com>

Hello.

Cyril Chemparathy wrote:
> This patch allows for gpio controllers that deviate from those found on
> traditional davinci socs.  davinci_soc_info has an added field to indicate the
> soc-specific gpio controller type.  The gpio initialization code then bails
> out of necessary.
>   

   s/of/if/

> More elements (tnetv107x) to be added later into enum davinci_gpio_type.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> Tested-by: Sandeep Paulraj <s-paulraj at ti.com>

WBR, Sergei


From sshtylyov at mvista.com  Fri Apr 23 16:16:57 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Sat, 24 Apr 2010 01:16:57 +0400
Subject: [PATCH v4 07/13] Davinci: eliminate pinmux offset verbosity
In-Reply-To: <1272045424-19240-8-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
Message-ID: <4BD20E49.50309@mvista.com>

Hello.

Cyril Chemparathy wrote:

> Pinmux registers are sequential, and do not need to be enumerated out as they
> currently are.  This reduces code volume and keeps things simple.
>
> If some future SoC comes up with a discontiguous register map, PINMUX() can
> then be expanded with local token pasting.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
>   
[...]
> diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
> index f9a54ff..1073882 100644
> --- a/arch/arm/mach-davinci/dm355.c
> +++ b/arch/arm/mach-davinci/dm355.c
> @@ -450,11 +450,7 @@ void __init dm355_init_spi0(unsigned chipselect_mask,
>  
>  /*----------------------------------------------------------------------*/
>  
> -#define PINMUX0		0x00
> -#define PINMUX1		0x04
> -#define PINMUX2		0x08
> -#define PINMUX3		0x0c
> -#define PINMUX4		0x10
> +#define PINMUX(x)	(4 * (x))
>  #define INTMUX		0x18
>  #define EVTMUX		0x1c
>   

   That's what I've always wanted to do (and even done in a local tree 
IIRC :-).

>  
> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index 0566675..e790da1 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -467,11 +467,7 @@ static struct clk_lookup dm365_clks[] = {
>  
>  /*----------------------------------------------------------------------*/
>  
> -#define PINMUX0		0x00
> -#define PINMUX1		0x04
> -#define PINMUX2		0x08
> -#define PINMUX3		0x0c
> -#define PINMUX4		0x10
> +#define PINMUX(x)	(4 * (x))
>  #define INTMUX		0x18
>  #define EVTMUX		0x1c
>  
> diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
> index 4af349e..3f3d5cb 100644
> --- a/arch/arm/mach-davinci/dm644x.c
> +++ b/arch/arm/mach-davinci/dm644x.c
> @@ -350,8 +350,7 @@ static struct platform_device dm644x_emac_device = {
>         .resource	= dm644x_emac_resources,
>  };
>  
> -#define PINMUX0		0x00
> -#define PINMUX1		0x04
> +#define PINMUX(x)	(4 * (x))
>  
>  /*
>   * Device specific mux setup
> diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
> index bdb1ace..c82194a 100644
> --- a/arch/arm/mach-davinci/dm646x.c
> +++ b/arch/arm/mach-davinci/dm646x.c
> @@ -401,8 +401,7 @@ static struct platform_device dm646x_emac_device = {
>  	.resource	= dm646x_emac_resources,
>  };
>  
> -#define PINMUX0		0x00
> -#define PINMUX1		0x04
> +#define PINMUX(x)	(4 * (x))
>  
>  /*
>   * Device specific mux setup
>   

   Perhaps instead of being duplicated in each SoC file, these #define's 
should also be moved to some common header, like <mach/hardware.h> or 
<mach/mux.h>. I'll look into it if someone doesn't beat me to it...

> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
> index 33471c9..02acedd 100644
> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
> @@ -64,26 +64,7 @@ extern void __iomem *da8xx_syscfg1_base;
>  #define DA8XX_DDR2_CTL_BASE	0xb0000000
>  #define DA8XX_ARM_RAM_BASE	0xffff0000
>  
> -#define PINMUX0			0x00
> -#define PINMUX1			0x04
> -#define PINMUX2			0x08
> -#define PINMUX3			0x0c
> -#define PINMUX4			0x10
> -#define PINMUX5			0x14
> -#define PINMUX6			0x18
> -#define PINMUX7			0x1c
> -#define PINMUX8			0x20
> -#define PINMUX9			0x24
> -#define PINMUX10		0x28
> -#define PINMUX11		0x2c
> -#define PINMUX12		0x30
> -#define PINMUX13		0x34
> -#define PINMUX14		0x38
> -#define PINMUX15		0x3c
> -#define PINMUX16		0x40
> -#define PINMUX17		0x44
> -#define PINMUX18		0x48
> -#define PINMUX19		0x4c
> +#define PINMUX(x)		(4 * (x))
>   

   Yes, now this certainly needs to be put in a common header. :-)

WBR, Sergei


From sshtylyov at mvista.com  Fri Apr 23 16:26:00 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Sat, 24 Apr 2010 01:26:00 +0400
Subject: [PATCH v4 13/13] Davinci: tnetv107x evm board initial support
In-Reply-To: <1272045424-19240-14-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
	<1272045424-19240-10-git-send-email-cyril@ti.com>
	<1272045424-19240-11-git-send-email-cyril@ti.com>
	<1272045424-19240-12-git-send-email-cyril@ti.com>
	<1272045424-19240-13-git-send-email-cyril@ti.com>
	<1272045424-19240-14-git-send-email-cyril@ti.com>
Message-ID: <4BD21068.1000909@mvista.com>

Hello.

Cyril Chemparathy wrote:

> Added support for tnetv107x evaluation module.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> ---
> v4: updated copyrights
> v4: squashed relevant gpio pins into sdio1 pin list
> v4: eliminated platform device definitions, moved to tnetv107x_devices_init()
>     implementation instead
> v4: platform devices moved out to devices-tnetv107x.c
> v3: moved some base address and edma channel definitions here
> v3: minor formatting changes
>   

[...]

> diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c b/arch/arm/mach-davinci/board-tnetv107x-evm.c
> new file mode 100644
> index 0000000..62a7b02
> --- /dev/null
> +++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
> @@ -0,0 +1,171 @@
> +/*
> + * Texas Instruments TNETV107X EVM Board Support
> + *
> + * Copyright (C) 2010 Texas Instruments
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/console.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/interrupt.h>
> +#include <linux/gpio.h>
> +#include <linux/delay.h>
> +#include <linux/platform_device.h>
> +#include <linux/ratelimit.h>
> +#include <linux/mtd/mtd.h>
> +#include <linux/mtd/partitions.h>
> +#include <asm/mach/arch.h>
> +#include <asm/mach-types.h>
> +
> +#include <mach/irqs.h>
> +#include <mach/edma.h>
> +#include <mach/mux.h>
> +#include <mach/tnetv107x.h>
> +
> +#define EVM_MMC_WP_GPIO		21
> +#define EVM_MMC_CD_GPIO		24
> +
> +static int initialize_gpio(int gpio, char *desc)
> +{
> +	int ret;
> +
> +	ret = gpio_request(gpio, desc);
> +	if (ret < 0) {
> +		pr_err_ratelimited("cannot open %s gpio\n", desc);
> +		return -ENOSYS;
> +	}
> +	gpio_direction_input(gpio);
> +	return gpio;
> +}
> +
> +static int mmc_get_cd(int index)
> +{
> +	static int gpio;
> +
> +	if (!gpio)
> +		gpio = initialize_gpio(EVM_MMC_CD_GPIO, "mmc card detect");
> +
> +	if (gpio < 0)
> +		return gpio;
> +
> +	return gpio_get_value(gpio) ? 0 : 1;
> +}
> +
> +static int mmc_get_ro(int index)
> +{
> +	static int gpio;
> +
> +	if (!gpio)
> +		gpio = initialize_gpio(EVM_MMC_WP_GPIO, "mmc write protect");
> +
> +	if (gpio < 0)
> +		return gpio;
> +
> +	return gpio_get_value(gpio) ? 1 : 0;
> +}
> +
> +static struct davinci_mmc_config mmc_config = {
> +	.get_cd		= mmc_get_cd,
> +	.get_ro		= mmc_get_ro,
> +	.wires		= 4,
> +	.max_freq	= 50000000,
> +	.caps		= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
> +	.version	= MMC_CTLR_VERSION_1,
> +};
> +
> +static const short sdio1_pins[] __initdata = {
> +	TNETV107X_SDIO1_CLK_1,		TNETV107X_SDIO1_CMD_1,
> +	TNETV107X_SDIO1_DATA0_1,	TNETV107X_SDIO1_DATA1_1,
> +	TNETV107X_SDIO1_DATA2_1,	TNETV107X_SDIO1_DATA3_1,
> +	TNETV107X_GPIO21,		TNETV107X_GPIO24,
> +	-1
> +};
> +
> +const short uart1_pins[] __initdata = {
> +	TNETV107X_UART1_RD,		TNETV107X_UART1_TD,
> +	-1
> +};
> +
> +static struct mtd_partition nand_partitions[] = {
> +	/* bootloader (U-Boot, etc) in first 12 sectors */
> +	{
> +		.name		= "bootloader",
> +		.offset		= 0,
> +		.size		= (12*SZ_128K),
> +		.mask_flags	= MTD_WRITEABLE,	/* force read-only */
> +	},
> +	/* bootloader params in the next sector */
> +	{
> +		.name		= "params",
> +		.offset		= MTDPART_OFS_NXTBLK,
> +		.size		= SZ_128K,
> +		.mask_flags	= MTD_WRITEABLE,	/* force read-only */
> +	},
> +	/* kernel */
> +	{
> +		.name		= "kernel",
> +		.offset		= MTDPART_OFS_NXTBLK,
> +		.size		= SZ_4M,
> +		.mask_flags	= 0,
> +	},
> +	/* file system */
> +	{
> +		.name		= "filesystem",
> +		.offset		= MTDPART_OFS_NXTBLK,
> +		.size		= MTDPART_SIZ_FULL,
> +		.mask_flags	= 0,
> +	}
> +};
> +
> +static struct davinci_nand_pdata nand_config = {
> +	.mask_cle	= 0x4000,
> +	.mask_ale	= 0x2000,
> +	.parts		= nand_partitions,
> +	.nr_parts	= ARRAY_SIZE(nand_partitions),
> +	.ecc_mode	= NAND_ECC_HW,
> +};
> +
> +struct davinci_uart_config serial_config __initconst = {
> +	.enabled_uarts	= BIT(1),
> +};
> +
> +struct tnetv107x_device_info evm_device_info __initconst = {
> +	.serial_config		= &serial_config,
> +	.mmc_config[1]		= &mmc_config,
> +	.nand_config[0]		= &nand_config,
> +};
> +
> +static __init void tnetv107x_evm_board_init(void)
> +{
> +	davinci_cfg_reg_list(sdio1_pins);
> +	davinci_cfg_reg_list(uart1_pins);
> +
> +	tnetv107x_devices_init(&evm_device_info);
> +}
>   

   I totally disagree about moving NAND to devices-tnetv107x.c -- it's a 
board level device, not SoC level! Look at the existing boards, they all 
define NAND/NOR devices in the board file.
BTW, don't you also need a pin list for NAND?

WBR, Sergei


From cyril at ti.com  Fri Apr 23 16:49:29 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 23 Apr 2010 17:49:29 -0400
Subject: [PATCH v4 13/13] Davinci: tnetv107x evm board initial support
In-Reply-To: <4BD21068.1000909@mvista.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
	<1272045424-19240-10-git-send-email-cyril@ti.com>
	<1272045424-19240-11-git-send-email-cyril@ti.com>
	<1272045424-19240-12-git-send-email-cyril@ti.com>
	<1272045424-19240-13-git-send-email-cyril@ti.com>
	<1272045424-19240-14-git-send-email-cyril@ti.com>
	<4BD21068.1000909@mvista.com>
Message-ID: <4BD215E9.6080909@ti.com>

Hi Sergei,

[...]
>> +static struct davinci_nand_pdata nand_config = {
>> +	.mask_cle	= 0x4000,
>> +	.mask_ale	= 0x2000,
>> +	.parts		= nand_partitions,
>> +	.nr_parts	= ARRAY_SIZE(nand_partitions),
>> +	.ecc_mode	= NAND_ECC_HW,
>> +};
>> +
>> +struct davinci_uart_config serial_config __initconst = {
>> +	.enabled_uarts	= BIT(1),
>> +};
>> +
>> +struct tnetv107x_device_info evm_device_info __initconst = {
>> +	.serial_config		= &serial_config,
>> +	.mmc_config[1]		= &mmc_config,
>> +	.nand_config[0]		= &nand_config,
>> +};
>> +
>> +static __init void tnetv107x_evm_board_init(void)
>> +{
>> +	davinci_cfg_reg_list(sdio1_pins);
>> +	davinci_cfg_reg_list(uart1_pins);
>> +
>> +	tnetv107x_devices_init(&evm_device_info);
>> +}
>>   
> 
>    I totally disagree about moving NAND to devices-tnetv107x.c -- it's a 
> board level device, not SoC level! Look at the existing boards, they all 
> define NAND/NOR devices in the board file.

The EMIF controller in itself is a soc level device.  The resources in 
question - EMIF control registers and the chipsel windows - are not 
board specific.  Therefore I have moved these pieces into soc-level code.

The board-specific pieces are the ALE/CLE lines, and the chip-select on 
which the nand chip is connected.  These elements have been retained in 
board-specific code.

For these reasons, I retain the belief (until convinced otherwise) that 
the existing boards get this wrong.


That aside, there is a bug in this code - it incorrectly uses chipsel0 
window regardless of the chipsel index indicated by the board.  This 
will be fixed in the next rev.

> BTW, don't you also need a pin list for NAND?

The EMIF pins need to be muxed out by the bootloader for it to get the 
kernel into DDR.  If so, do we still need to forcibly configure these pins?

Thanks
Cyril.

From sshtylyov at mvista.com  Fri Apr 23 16:55:10 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Sat, 24 Apr 2010 01:55:10 +0400
Subject: [PATCH v4 13/13] Davinci: tnetv107x evm board initial support
In-Reply-To: <4BD215E9.6080909@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
	<1272045424-19240-10-git-send-email-cyril@ti.com>
	<1272045424-19240-11-git-send-email-cyril@ti.com>
	<1272045424-19240-12-git-send-email-cyril@ti.com>
	<1272045424-19240-13-git-send-email-cyril@ti.com>
	<1272045424-19240-14-git-send-email-cyril@ti.com>
	<4BD21068.1000909@mvista.com> <4BD215E9.6080909@ti.com>
Message-ID: <4BD2173E.2020604@mvista.com>

Cyril Chemparathy wrote:
> Hi Sergei,
>
> [...]
>>> +static struct davinci_nand_pdata nand_config = {
>>> +    .mask_cle    = 0x4000,
>>> +    .mask_ale    = 0x2000,
>>> +    .parts        = nand_partitions,
>>> +    .nr_parts    = ARRAY_SIZE(nand_partitions),
>>> +    .ecc_mode    = NAND_ECC_HW,
>>> +};
>>> +
>>> +struct davinci_uart_config serial_config __initconst = {
>>> +    .enabled_uarts    = BIT(1),
>>> +};
>>> +
>>> +struct tnetv107x_device_info evm_device_info __initconst = {
>>> +    .serial_config        = &serial_config,
>>> +    .mmc_config[1]        = &mmc_config,
>>> +    .nand_config[0]        = &nand_config,
>>> +};
>>> +
>>> +static __init void tnetv107x_evm_board_init(void)
>>> +{
>>> +    davinci_cfg_reg_list(sdio1_pins);
>>> +    davinci_cfg_reg_list(uart1_pins);
>>> +
>>> +    tnetv107x_devices_init(&evm_device_info);
>>> +}
>>>   
>>
>>    I totally disagree about moving NAND to devices-tnetv107x.c -- 
>> it's a board level device, not SoC level! Look at the existing 
>> boards, they all define NAND/NOR devices in the board file.
>
> The EMIF controller in itself is a soc level device.  The resources in 
> question - EMIF control registers and the chipsel windows - are not 
> board specific.

   No, they are. What CS is chosen for which flash is totally board 
specific. And *that* determines the set of the platfrom device resource 
you have.

> Therefore I have moved these pieces into soc-level code.
>
> The board-specific pieces are the ALE/CLE lines, and the chip-select 
> on which the nand chip is connected.  These elements have been 
> retained in board-specific code.

   Right, and I don't see where you retained the chip select.

> For these reasons, I retain the belief (until convinced otherwise) 
> that the existing boards get this wrong.

   Think again please. :-)

> That aside, there is a bug in this code - it incorrectly uses chipsel0 
> window regardless of the chipsel index indicated by the board.  This 
> will be fixed in the next rev.

  I don't see anything about chip select here, frankly...

>> BTW, don't you also need a pin list for NAND?
>
> The EMIF pins need to be muxed out by the bootloader for it to get the 
> kernel into DDR. If so, do we still need to forcibly configure these pins?

   I don't know -- asking you. We had to do in on DA830 EVM where NAND 
is on a daughter board...

> Thanks
> Cyril.

WBR, Sergei


From cyril at ti.com  Fri Apr 23 17:18:50 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 23 Apr 2010 18:18:50 -0400
Subject: [PATCH v4 13/13] Davinci: tnetv107x evm board initial support
In-Reply-To: <4BD2173E.2020604@mvista.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
	<1272045424-19240-10-git-send-email-cyril@ti.com>
	<1272045424-19240-11-git-send-email-cyril@ti.com>
	<1272045424-19240-12-git-send-email-cyril@ti.com>
	<1272045424-19240-13-git-send-email-cyril@ti.com>
	<1272045424-19240-14-git-send-email-cyril@ti.com>
	<4BD21068.1000909@mvista.com> <4BD215E9.6080909@ti.com>
	<4BD2173E.2020604@mvista.com>
Message-ID: <4BD21CCA.3040502@ti.com>

Hi Sergei,

[...]
>>>> +struct tnetv107x_device_info evm_device_info __initconst = {
>>>> +    .serial_config        = &serial_config,
>>>> +    .mmc_config[1]        = &mmc_config,
>>>> +    .nand_config[0]        = &nand_config,

Index 0 of the nand_config array indicates the chip select.
Please see the comment in the structure's definition:
 > struct davinci_nand_pdata	*nand_config[4]; /* 4 chipsels */

I guess I should explicitly put in a comment in the initializer as well.

>>>> +};
>>>> +
>>>> +static __init void tnetv107x_evm_board_init(void)
>>>> +{
>>>> +    davinci_cfg_reg_list(sdio1_pins);
>>>> +    davinci_cfg_reg_list(uart1_pins);
>>>> +
>>>> +    tnetv107x_devices_init(&evm_device_info);
>>>> +}
>>>>   
>>>    I totally disagree about moving NAND to devices-tnetv107x.c -- 
>>> it's a board level device, not SoC level! Look at the existing 
>>> boards, they all define NAND/NOR devices in the board file.
>> The EMIF controller in itself is a soc level device.  The resources in 
>> question - EMIF control registers and the chipsel windows - are not 
>> board specific.
> 
>    No, they are. What CS is chosen for which flash is totally board 
> specific. And *that* determines the set of the platfrom device resource 
> you have.

Sorry, Sergei.  I fail to see the argument.  In what way does the emif's 
control register space end up being board specific?

Further, given a specific chip-select (e.g. cs 0), the window is again 
fixed in the soc to be at 0x30000000.  Therefore, the mapping between 
chip select line and window is again board specific.

>> Therefore I have moved these pieces into soc-level code.
>>
>> The board-specific pieces are the ALE/CLE lines, and the chip-select 
>> on which the nand chip is connected.  These elements have been 
>> retained in board-specific code.
> 
>    Right, and I don't see where you retained the chip select.

Please see above, index in the nand_config array is the chip select.

>>> BTW, don't you also need a pin list for NAND?
>> The EMIF pins need to be muxed out by the bootloader for it to get the 
>> kernel into DDR. If so, do we still need to forcibly configure these pins?
> 
>    I don't know -- asking you. We had to do in on DA830 EVM where NAND 
> is on a daughter board...

The boot-loader on this platform absolutely must set this up to be able 
to load the kernel.  That said, unless I am unwittingly breaking an 
unwritten rule, I'd rather let the bootloader's setup remain.


Regards
Cyril.

From sshtylyov at mvista.com  Fri Apr 23 17:42:23 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Sat, 24 Apr 2010 02:42:23 +0400
Subject: [PATCH v4 13/13] Davinci: tnetv107x evm board initial support
In-Reply-To: <4BD21CCA.3040502@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
	<1272045424-19240-10-git-send-email-cyril@ti.com>
	<1272045424-19240-11-git-send-email-cyril@ti.com>
	<1272045424-19240-12-git-send-email-cyril@ti.com>
	<1272045424-19240-13-git-send-email-cyril@ti.com>
	<1272045424-19240-14-git-send-email-cyril@ti.com>
	<4BD21068.1000909@mvista.com> <4BD215E9.6080909@ti.com>
	<4BD2173E.2020604@mvista.com> <4BD21CCA.3040502@ti.com>
Message-ID: <4BD2224F.7010503@mvista.com>

Hello.

Cyril Chemparathy wrote:
> Hi Sergei,
>
> [...]
>>>>> +struct tnetv107x_device_info evm_device_info __initconst = {
>>>>> +    .serial_config        = &serial_config,
>>>>> +    .mmc_config[1]        = &mmc_config,
>>>>> +    .nand_config[0]        = &nand_config,
>
> Index 0 of the nand_config array indicates the chip select.
> Please see the comment in the structure's definition:
> > struct davinci_nand_pdata    *nand_config[4]; /* 4 chipsels */
>
> I guess I should explicitly put in a comment in the initializer as well.
>
>>>>> +};
>>>>> +
>>>>> +static __init void tnetv107x_evm_board_init(void)
>>>>> +{
>>>>> +    davinci_cfg_reg_list(sdio1_pins);
>>>>> +    davinci_cfg_reg_list(uart1_pins);
>>>>> +
>>>>> +    tnetv107x_devices_init(&evm_device_info);
>>>>> +}
>>>>>   
>>>>    I totally disagree about moving NAND to devices-tnetv107x.c -- 
>>>> it's a board level device, not SoC level! Look at the existing 
>>>> boards, they all define NAND/NOR devices in the board file.
>>> The EMIF controller in itself is a soc level device.  The resources 
>>> in question - EMIF control registers and the chipsel windows - are 
>>> not board specific.
>>
>>    No, they are. What CS is chosen for which flash is totally board 
>> specific. And *that* determines the set of the platfrom device 
>> resource you have.
>
> Sorry, Sergei.  I fail to see the argument.  In what way does the 
> emif's control register space end up being board specific?

   I'm talking about the 2nd resource all the time, i.e. CS space.

> Further, given a specific chip-select (e.g. cs 0), the window is again 
> fixed in the soc to be at 0x30000000.  Therefore, the mapping between 
> chip select line and window is again board specific.

   Yes. And I don't see how different CSs are handled by your code. The 
device always has CS0 space as a resource. If you'd make nand_init() 
change the resource on the fly before registering, then this would have 
worked out.

>
>>> Therefore I have moved these pieces into soc-level code.
>>>
>>> The board-specific pieces are the ALE/CLE lines, and the chip-select 
>>> on which the nand chip is connected.  These elements have been 
>>> retained in board-specific code.
>>
>>    Right, and I don't see where you retained the chip select.
>
> Please see above, index in the nand_config array is the chip select.

   Ah, indeed -- that wasn't obvious -- I rather expected to see 
something in the platfrom data...

>>>> BTW, don't you also need a pin list for NAND?
>>> The EMIF pins need to be muxed out by the bootloader for it to get 
>>> the kernel into DDR. If so, do we still need to forcibly configure 
>>> these pins?
>>
>>    I don't know -- asking you. We had to do in on DA830 EVM where 
>> NAND is on a daughter board...
>
> The boot-loader on this platform absolutely must set this up to be 
> able to load the kernel.  That said, unless I am unwittingly breaking 
> an unwritten rule, I'd rather let the bootloader's setup remain.

   Agreed.

> Regards
> Cyril.

WBR, Sergei


From cyril at ti.com  Fri Apr 23 17:49:34 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 23 Apr 2010 18:49:34 -0400
Subject: [PATCH v4 13/13] Davinci: tnetv107x evm board initial support
In-Reply-To: <4BD2224F.7010503@mvista.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
	<1272045424-19240-10-git-send-email-cyril@ti.com>
	<1272045424-19240-11-git-send-email-cyril@ti.com>
	<1272045424-19240-12-git-send-email-cyril@ti.com>
	<1272045424-19240-13-git-send-email-cyril@ti.com>
	<1272045424-19240-14-git-send-email-cyril@ti.com>
	<4BD21068.1000909@mvista.com> <4BD215E9.6080909@ti.com>
	<4BD2173E.2020604@mvista.com> <4BD21CCA.3040502@ti.com>
	<4BD2224F.7010503@mvista.com>
Message-ID: <4BD223FE.5090502@ti.com>

Hi Sergei,

[...]
>    Yes. And I don't see how different CSs are handled by your code. The 
> device always has CS0 space as a resource.

Correct.  And that's the bug I'd referred to in my first response:

[...]
 > That aside, there is a bug in this code - it incorrectly uses chipsel0
 > window regardless of the chipsel index indicated by the board.  This
 > will be fixed in the next rev.
[...]

>> Please see above, index in the nand_config array is the chip select.
>    Ah, indeed -- that wasn't obvious -- I rather expected to see 
> something in the platfrom data...

Hence the need for a comment in the initializer :-)

Regards
Cyril.

From liuyue18301 at 163.com  Fri Apr 23 21:10:14 2010
From: liuyue18301 at 163.com (liuyue18301)
Date: Sat, 24 Apr 2010 10:10:14 +0800 (CST)
Subject: linux emif driver
Message-ID: <b10e20.d65c.1282d944fdb.Coremail.liuyue18301@163.com>


   hello everyone
           in dm6446 we want to expand the seven uart devices by the emif bus.but i can not find the emif bus driver in the Linux,if i want to write/read data to the uart which expanded by the emif bus how can do it? now i have no idea.who can give me a guideline
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100424/41893992/attachment-0001.html>

From bharathi.list at gmail.com  Sat Apr 24 00:12:57 2010
From: bharathi.list at gmail.com (Bharathi Subramanian)
Date: Sat, 24 Apr 2010 10:42:57 +0530
Subject: OMAP-L138 X11 on S-Video
Message-ID: <z2y2b3771721004232212nea77d4bblc66dd71c8c09dc8a@mail.gmail.com>

Hi All,

In OMAP-L138 EVM, Is it possible to use the S-Video out as default
output device for X11.  Now I am able to access it using VPIF example
program. In beagle board, I used the S-Video out for X11 output. I am
thinking of using  the OMAP-L138 S-Video output also in the same
fashion. Please throw some light on this topic.

Thanks,
-- 
Bharathi Subramanian

From caglarakyuz at gmail.com  Sat Apr 24 00:40:11 2010
From: caglarakyuz at gmail.com (Caglar Akyuz)
Date: Sat, 24 Apr 2010 08:40:11 +0300
Subject: Possible uboot crashes
In-Reply-To: <x2n66b2b2311004231309r3e885ab6yf9dce952cd4997af@mail.gmail.com>
References: <x2n66b2b2311004231309r3e885ab6yf9dce952cd4997af@mail.gmail.com>
Message-ID: <201004240840.11552.caglarakyuz@gmail.com>

On Friday 23 April 2010 11:09:51 pm John Tobias wrote:
> Hello Guys,
> 
> I would like to know what are the possible chances that u-boot/ubl
>  crashes?. I am looking for some theory/scenario that I can possibly
>  connect/apply the scenario to what happened to my device based on dm6446.
> 
> The device has been running for a year now and for some reason it never
>  come back anymore. I connect through the serial port of the device and
>  check if there's something different. The device was in the state where
>  the bootloader is missing. I re-program the u-boot and the device boot it
>  again as I expected.
> The /dev/mtd0 and /dev/mtd1 are not writable on linux space in order to
> screwed up the uboot.
> 
> Thanks,
> 
> John
> 

Hi,

Since you are looking for theories, here is mine...

Assuming that you are using a NAND flash, I think it can be because of read 
disturb in NAND array. I know that it's a very long shot but its the first 
explanation coming to my ming.

Best Regards,
Caglar

From lamiaposta71 at gmail.com  Sat Apr 24 01:41:31 2010
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Sat, 24 Apr 2010 08:41:31 +0200
Subject: linux emif driver
In-Reply-To: <b10e20.d65c.1282d944fdb.Coremail.liuyue18301@163.com>
References: <b10e20.d65c.1282d944fdb.Coremail.liuyue18301@163.com>
Message-ID: <l2jade1bdc1004232341qaafcd3dco7090d739cd1cfa7d@mail.gmail.com>

the usual way to expand uart is using 16c550 compatible chipsets connected
on the bus.
the davinci driver for internal uart can manage also external chipsets.
I don't know doing that with emif i/f.




2010/4/24 liuyue18301 <liuyue18301 at 163.com>

>
>    hello everyone
>            in dm6446 we want to expand the seven uart devices by the emif
> bus.but i can not find the emif bus driver in the Linux,if i want to
> write/read data to the uart which expanded by the emif bus how can do it?
> now i have no idea.who can give me a guideline
>
>
> ------------------------------
> ???????????? <http://ym.163.com/?from=od2>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>


-- 
www.opensurf.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100424/6b534d9d/attachment.html>

From bgr at linespeed.net  Sat Apr 24 01:43:34 2010
From: bgr at linespeed.net (Brian G Rhodes)
Date: Sat, 24 Apr 2010 01:43:34 -0500
Subject: Possible uboot crashes
In-Reply-To: <201004240840.11552.caglarakyuz@gmail.com>
References: <x2n66b2b2311004231309r3e885ab6yf9dce952cd4997af@mail.gmail.com>
	<201004240840.11552.caglarakyuz@gmail.com>
Message-ID: <4BD29316.6000903@linespeed.net>

Caglar Akyuz wrote:
> On Friday 23 April 2010 11:09:51 pm John Tobias wrote:
>   
>> Hello Guys,
>>
>> I would like to know what are the possible chances that u-boot/ubl
>>  crashes?. I am looking for some theory/scenario that I can possibly
>>  connect/apply the scenario to what happened to my device based on dm6446.
>>
>> The device has been running for a year now and for some reason it never
>>  come back anymore. I connect through the serial port of the device and
>>  check if there's something different. The device was in the state where
>>  the bootloader is missing. I re-program the u-boot and the device boot it
>>  again as I expected.
>> The /dev/mtd0 and /dev/mtd1 are not writable on linux space in order to
>> screwed up the uboot.
>>
>> Thanks,
>>
>> John
>>
>>     
>
> Hi,
>
> Since you are looking for theories, here is mine...
>
> Assuming that you are using a NAND flash, I think it can be because of read 
> disturb in NAND array. I know that it's a very long shot but its the first 
> explanation coming to my ming.
>
>   

If it is caused by read disturb errors, the number of bits of ECC you 
are using would be useful to know.  If you are using 1 bit ECC, then I 
wouldn't say that it is entirely unlikely.  The UBL is setup to read 
from 5 consecutive blocks for the bootloader, so you can always program 
multiple backups, and use a similar strategy for Linux if you put the 
kernel in NAND as well.  So, I would second Caglar's theory, also 
assuming you are using a NAND device.

If you can recreate the failure, I would suggest reading the data off 
first before reprogramming again.  Then you can compare it to a good 
image and see how many bits are incorrect in the failing block(s), 
accounting for the number of bits which can be corrected by ECC or 
reading without ECC.

From gaojun at netposa.com  Sat Apr 24 04:27:43 2010
From: gaojun at netposa.com (gaojun)
Date: Sat, 24 Apr 2010 17:27:43 +0800
Subject: exit
Message-ID: <201004241727419533632@netposa.com>

exit

2010-04-24 



??
============================================= 
???????????? ?www.netposa.com?
============================================= 
?????????????6???????B?9?
???010-82325566-187
???010-82328940 
?????gaojun at netposa.com
============================================= 
??????
=============================================
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100424/4c3e0dae/attachment.html>

From ottavio.campana at dei.unipd.it  Sat Apr 24 05:14:37 2010
From: ottavio.campana at dei.unipd.it (Ottavio Campana)
Date: Sat, 24 Apr 2010 12:14:37 +0200
Subject: linux emif driver
In-Reply-To: <b10e20.d65c.1282d944fdb.Coremail.liuyue18301@163.com>
References: <b10e20.d65c.1282d944fdb.Coremail.liuyue18301@163.com>
Message-ID: <4BD2C48D.5050304@dei.unipd.it>

Il 24/04/10 04.10, liuyue18301 ha scritto:
> 
>    hello everyone
>            in dm6446 we want to expand the seven uart devices by the emif bus.but i can not find the emif bus driver in the Linux,if i want to write/read data to the uart which expanded by the emif bus how can do it? now i have no idea.who can give me a guideline
> 

if you have a regular uart, just connect it to the emif. Then, add the
serial port to arch/arm/mach-davinci/board-evm.c . This should work.

From lamiaposta71 at gmail.com  Sat Apr 24 11:16:13 2010
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Sat, 24 Apr 2010 18:16:13 +0200
Subject: linux emif driver
In-Reply-To: <4BD2C48D.5050304@dei.unipd.it>
References: <b10e20.d65c.1282d944fdb.Coremail.liuyue18301@163.com>
	<4BD2C48D.5050304@dei.unipd.it>
Message-ID: <p2kade1bdc1004240916ze8e4293cqe4362716b888a8b7@mail.gmail.com>

I'm sorry, I was telling the same thing.
I have to do this work.
I suppose that the interesting configs are:

CONFIG_SERIAL_8250
CONFIG_SERIAL_8250_CONSOLE
CONFIG_SERIAL_8250_NR_UARTS
CONFIG_SERIAL_8250_RUNTIME_UARTS
CONFIG_SERIAL_8250_EXTENDED
and
CONFIG_SND_SERIAL_U16550




2010/4/24 Ottavio Campana <ottavio.campana at dei.unipd.it>

> Il 24/04/10 04.10, liuyue18301 ha scritto:
> >
> >    hello everyone
> >            in dm6446 we want to expand the seven uart devices by the emif
> bus.but i can not find the emif bus driver in the Linux,if i want to
> write/read data to the uart which expanded by the emif bus how can do it?
> now i have no idea.who can give me a guideline
> >
>
> if you have a regular uart, just connect it to the emif. Then, add the
> serial port to arch/arm/mach-davinci/board-evm.c . This should work.
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>


-- 
www.opensurf.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100424/a4600b95/attachment.html>

From liuyue18301 at 163.com  Sun Apr 25 21:46:47 2010
From: liuyue18301 at 163.com (liuyue18301)
Date: Mon, 26 Apr 2010 10:46:47 +0800 (CST)
Subject: help for linux emif driver 2nd
Message-ID: <a76abd.9329.12838027f8f.Coremail.liuyue18301@163.com>



hello Guys:
     this is second time to turn to help on the same problem.
     i want to know is there EMIF driver in the linux? and if i want to send/recv data to the uarts which are expanded by FPGA ,how can i do it? which driver should i create or modify EMIF driver or UART driver?i want to write data to the EMIF in the application code,but i can't find the EMIF driver in the linux. confused 
     thank you  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100426/23bb2419/attachment.html>

From surfinbum at mac.com  Sun Apr 25 22:02:55 2010
From: surfinbum at mac.com (Chris)
Date: Sun, 25 Apr 2010 23:02:55 -0400
Subject: Can't Mount NFS from DVEVM 6446
Message-ID: <77544900650898055643541774144164931012-Webmail@me.com>

Hello all, 

I am having trouble mounting to the NFS server on my host Linux machine.  My configuration is as follows.

I am using Ubuntu 9.10 as host OS
I am working with TI DM6446 evaluation board
I am referencing the SPRUE66B document
My evaluation board ethernet cable is plugged directly into the ethernet port of my host machine, so i configured the ip statically.  

I have done the following steps from:

1.) Installed the target linux software on host.
2.) Installed the DVSDK software on host.
3.) Installed CODEC servers on host.
4.) Copied target file system with permisions to location  /home/chris/workdir/filesys
5.) Edit /etc/exports file to read:
          /home/chris/workdir/filesys *(rw,no_root_squash,no_all_squash,sync)
6.) Start NFS Server:
          sudo /etc/init.d/nfs-kernel-server restart
7.) Disable firewall using firestarter application
9.) Open terminal session in minicom
10.) Set following environment variables:
   
   EVM # setenv nfshost 192.168.1.100
   EVM # setenv rootpath home/chris/workdir/filesys
   EVM # setenv bootargs video=davincifb:vid0=0,2500K:
   vid1=0,2500K:osd0=720x576x16,2025K
   davinci_enc_mngr.ch0_output=COMPOSITE
   davinci_enc_mngr.ch0_mode=$(videostd)
   console=ttyS0,115200n8 noinitrd rw ip=192.168.1.101:192.168.1.100:192.168.1.1:255.255.255.0:::off
   root=/dev/nfs nfsroot=$(nfshost):$(rootpath),nolock
   mem=118M

This is the target printenv:

DaVinci EVM # printenv
bootdelay=3
baudrate=115200
bootfile="uImage"
filesize=1ecc28
fileaddr=80700000
bootcmd=nboot 0x80700000 0 0x200000; bootm
nfshost=192.168.1.100
rootpath=home/chris/workdir/filesys
stdin=serial
stdout=serial
stderr=serial
ethaddr=00:0e:99:02:42:8e
videostd=ntsc
serverip=192.168.1.100
ipaddr=192.168.1.101
gateway=192.168.1.1
netmask=255.255.255.0
bootargs=davinci_enc_mngr.ch0_mode=ntsc console=ttyS0,115200n8 noinitrd rw ip=192.168.1.101:192.168.1.100:192.168.1.1:255.255.255.0:::off root=/dev/nfs nfsroot=192.168.1.100:home/chris/workdir/filesys,nolock mem=
118M

Environment size: 565/16380 bytes

when i try to boot i am getting the following output:

Loading from NAND 64MiB 1,8V 8-bit, offset 0x200000
   Image Name:   Linux-2.6.18_pro500-davinci_evm-
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2018280 Bytes =  1.9 MB
   Load Address: 80008000
   Entry Point:  80008000
## Booting image at 80700000 ...
   Image Name:   Linux-2.6.18_pro500-davinci_evm-
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2018280 Bytes =  1.9 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux..................................................................................................................................... done, booting the kernel.
Linux version 2.6.18_pro500-davinci_evm-arm_v5t_le (x0029463 at aspbuild11) (gcc version 4.2.0 20070126 (prerelease) (MontaVista 4.2.0-3.0.0.0702771 2007-03-10)) #1 PREEMPT Wed May 20 01:14:17 IST 2009
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
Machine: DaVinci EVM
Memory policy: ECC disabled, Data cache writeback
DaVinci DM6443 variant 0x1
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets
Built 1 zonelists.  Total pages: 30208
Kernel command line: davinci_enc_mngr.ch0_mode=ntsc console=ttyS0,115200n8 noinitrd rw ip=192.168.1.101:192.168.1.100:192.168.1.1:255.255.255.0:::off root=/dev/nfs nfsroot=192.168.1.100:home/chris/workdir/filesys
,nolock mem=118M
PID hash table entries: 512 (order: 9, 2048 bytes)
Clock event device timer0_0 configured with caps set: 03
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 118MB = 118MB total
Memory: 115328KB available (3461K code, 689K data, 176K init)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
DaVinci: 71 gpio irqs
WARNING: both IDE and NOR flash are enabled, but share pins.
        Disable IDE for NOR support.
ch0 default output "COMPOSITE", mode "NTSC"
MUX: initialized LOEEN
MUX: initialized LFLDEN
VPBE Encoder Initialized
LogicPD encoder initialized
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 4096 bind 2048)
TCP reno registered
davinci_spi_board_init: NO spi support
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
squashfs: version 3.1 (2006/08/19) Phillip Lougher
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
yaffs May 20 2009 01:11:27 Installing. 
SGI XFS with no debug enabled
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered (default)
LTT : ltt-facilities init
LTT : ltt-facility-core init in kernel
davincifb davincifb: dm_osd0_fb: 720x480x16 at 0,0 with framebuffer size 675KB
davincifb davincifb: dm_vid0_fb: 0x0x16 at 0,0 with framebuffer size 1020KB
davincifb davincifb: dm_osd1_fb: 720x480x4 at 0,0 with framebuffer size 675KB
davincifb davincifb: dm_vid1_fb: 0x0x16 at 0,0 with framebuffer size 1020KB
davincifb davincifb.0: dm_osd0_fb: Failed to obtain ownership of OSD window.
DAVINCI-WDT: DaVinci Watchdog Timer: heartbeat 60 sec
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO map 0x1c20000 mem 0xfec20000 (irq = 40) is a 16550A
RAMDISK driver initialized: 1 RAM disks of 32768K size 1024 blocksize
netconsole: not configured, aborting
TI DaVinci EMAC: MAC address is 00:0e:99:02:42:8e
TI DaVinci EMAC Linux version updated 4.0
TI DaVinci EMAC: Installed 1 instances.
Linux video capture interface: v2.00
vpfe vpfe.1: DaVinci v4l2 capture driver V1.0 loaded
Trying to register davinci display video device.
layer=c728d600,layer->video_dev=c728d760
Trying to register davinci display video device.
layer=c728d400,layer->video_dev=c728d560
davinci_init:DaVinci V4L2 Display Driver V1.0 loaded

 Davici AEW Driver cannot be loaded
 VIDEO PORT is not enabledData Flow path from CCDC is disabled

 Davinci AF driver cannot be loaded
 VIDEO PORT is not enabled 
 CCDC needs to be configured<6>i2c /dev entries driver
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
MUX: initialized HDIREN
MUX: initialized ATAEN
    ide0: MMIO-DMA , BIOS settings: hda:pio, hdb:pio
hda: TOSHIBA MK4032GAX, ATA DISK drive
ide0 at 0xfec661f0-0xfec661f7,0xfec663f6 on irq 22
hda: max request size: 512KiB
hda: 78140160 sectors (40007 MB), CHS=16383/255/63, UDMA(66)
hda: cache flushes supported
 hda: hda1 hda2
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
musb_hdrc: version 6.0, cppi-dma, host, debug=0
musb_hdrc musb_hdrc: No DMA interrupt line
musb_hdrc: USB Host mode controller at c785e000 using DMA, IRQ 12
musb_hdrc musb_hdrc: MUSB HDRC host driver
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
mice: PS/2 mouse device common for all mice
rtc_davinci_evm rtc_davinci_evm: rtc intf: proc
rtc_davinci_evm rtc_davinci_evm: rtc intf: dev (254:0)
rtc_davinci_evm rtc_davinci_evm: rtc core: registered rtc_davinci_evm as rtc0
rtc0: hours 12-23 are misreported as duplicate hours 00-11
davinci-mmc davinci-mmc.0: Supporting 4-bit mode
davinci-mmc davinci-mmc.0: Using DMA mode
Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC).
ASoC version 0.13.1
MUX: initialized MCBSP
AIC3X Audio Codec 0.1
asoc: aic3x <-> davinci-i2s mapping ok
ALSA device list:
  #0: DaVinci EVM (aic3x)
IPv4 over IPv4 tunneling driver
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Time: timer0_1 clocksource has been installed.
Clock event device timer0_0 configured with caps set: 08
Switched to high resolution mode on CPU 0
rtc_davinci_evm rtc_davinci_evm: setting the system clock to 2004-02-01 12:13:16 (1075637596)
IP-Config: Complete:
      device=eth0, addr=192.168.1.101, mask=255.255.255.0, gw=192.168.1.1,
     host=192.168.1.101, domain=, nis-domain=(none),
     bootserver=192.168.1.100, rootserver=192.168.1.100, rootpath=
Looking up port of RPC 100003/2 on 192.168.1.100
Looking up port of RPC 100005/1 on 192.168.1.100
Root-NFS: Server returned error -13 while mounting home/chris/workdir/filesys
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "nfs" or unknown-block(2,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)


I cannot seem to figure out why this happening.  any help would be greatly appreciated

thank you, 

chris jackson





From caglarakyuz at gmail.com  Mon Apr 26 00:39:31 2010
From: caglarakyuz at gmail.com (Caglar Akyuz)
Date: Mon, 26 Apr 2010 08:39:31 +0300
Subject: Can't Mount NFS from DVEVM 6446
In-Reply-To: <77544900650898055643541774144164931012-Webmail@me.com>
References: <77544900650898055643541774144164931012-Webmail@me.com>
Message-ID: <201004260839.31991.caglarakyuz@gmail.com>

On Monday 26 April 2010 06:02:55 am Chris wrote:
> Hello all,
> 
> I am having trouble mounting to the NFS server on my host Linux machine. 
>  My configuration is as follows.
> 
> I am using Ubuntu 9.10 as host OS
> I am working with TI DM6446 evaluation board
> I am referencing the SPRUE66B document
> My evaluation board ethernet cable is plugged directly into the ethernet
>  port of my host machine, so i configured the ip statically.
> 
> I have done the following steps from:
> 
> 1.) Installed the target linux software on host.
> 2.) Installed the DVSDK software on host.
> 3.) Installed CODEC servers on host.
> 4.) Copied target file system with permisions to location 
>  /home/chris/workdir/filesys 5.) Edit /etc/exports file to read:
>           /home/chris/workdir/filesys
>  *(rw,no_root_squash,no_all_squash,sync) 6.) Start NFS Server:
>           sudo /etc/init.d/nfs-kernel-server restart
> 7.) Disable firewall using firestarter application
> 9.) Open terminal session in minicom
> 10.) Set following environment variables:
> 
>    EVM # setenv nfshost 192.168.1.100
>    EVM # setenv rootpath home/chris/workdir/filesys

Make this /home/chris/workdir/filesys and it should work.

Regards,
Caglar

>    EVM # setenv bootargs video=davincifb:vid0=0,2500K:
>    vid1=0,2500K:osd0=720x576x16,2025K
>    davinci_enc_mngr.ch0_output=COMPOSITE
>    davinci_enc_mngr.ch0_mode=$(videostd)
>    console=ttyS0,115200n8 noinitrd rw
>  ip=192.168.1.101:192.168.1.100:192.168.1.1:255.255.255.0:::off
>  root=/dev/nfs nfsroot=$(nfshost):$(rootpath),nolock
>    mem=118M
> 
> This is the target printenv:
> 
> DaVinci EVM # printenv
> bootdelay=3
> baudrate=115200
> bootfile="uImage"
> filesize=1ecc28
> fileaddr=80700000
> bootcmd=nboot 0x80700000 0 0x200000; bootm
> nfshost=192.168.1.100
> rootpath=home/chris/workdir/filesys
> stdin=serial
> stdout=serial
> stderr=serial
> ethaddr=00:0e:99:02:42:8e
> videostd=ntsc
> serverip=192.168.1.100
> ipaddr=192.168.1.101
> gateway=192.168.1.1
> netmask=255.255.255.0
> bootargs=davinci_enc_mngr.ch0_mode=ntsc console=ttyS0,115200n8 noinitrd rw
>  ip=192.168.1.101:192.168.1.100:192.168.1.1:255.255.255.0:::off
>  root=/dev/nfs nfsroot=192.168.1.100:home/chris/workdir/filesys,nolock mem=
>  118M
> 
> Environment size: 565/16380 bytes
> 
> when i try to boot i am getting the following output:
> 
> Loading from NAND 64MiB 1,8V 8-bit, offset 0x200000
>    Image Name:   Linux-2.6.18_pro500-davinci_evm-
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    2018280 Bytes =  1.9 MB
>    Load Address: 80008000
>    Entry Point:  80008000
> ## Booting image at 80700000 ...
>    Image Name:   Linux-2.6.18_pro500-davinci_evm-
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    2018280 Bytes =  1.9 MB
>    Load Address: 80008000
>    Entry Point:  80008000
>    Verifying Checksum ... OK
> OK
> 
> Starting kernel ...
> 
> Uncompressing
>  Linux.....................................................................
> ................................................................ done,
>  booting the kernel. Linux version 2.6.18_pro500-davinci_evm-arm_v5t_le
>  (x0029463 at aspbuild11) (gcc version 4.2.0 20070126 (prerelease) (MontaVista
>  4.2.0-3.0.0.0702771 2007-03-10)) #1 PREEMPT Wed May 20 01:14:17 IST 2009
>  CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
> Machine: DaVinci EVM
> Memory policy: ECC disabled, Data cache writeback
> DaVinci DM6443 variant 0x1
> CPU0: D VIVT write-back cache
> CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
> CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets
> Built 1 zonelists.  Total pages: 30208
> Kernel command line: davinci_enc_mngr.ch0_mode=ntsc console=ttyS0,115200n8
>  noinitrd rw ip=192.168.1.101:192.168.1.100:192.168.1.1:255.255.255.0:::off
>  root=/dev/nfs nfsroot=192.168.1.100:home/chris/workdir/filesys ,nolock
>  mem=118M
> PID hash table entries: 512 (order: 9, 2048 bytes)
> Clock event device timer0_0 configured with caps set: 03
> Console: colour dummy device 80x30
> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> Memory: 118MB = 118MB total
> Memory: 115328KB available (3461K code, 689K data, 176K init)
> Security Framework v1.0.0 initialized
> Capability LSM initialized
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> NET: Registered protocol family 16
> DaVinci: 71 gpio irqs
> WARNING: both IDE and NOR flash are enabled, but share pins.
>         Disable IDE for NOR support.
> ch0 default output "COMPOSITE", mode "NTSC"
> MUX: initialized LOEEN
> MUX: initialized LFLDEN
> VPBE Encoder Initialized
> LogicPD encoder initialized
> SCSI subsystem initialized
> usbcore: registered new driver usbfs
> usbcore: registered new driver hub
> NET: Registered protocol family 2
> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> TCP established hash table entries: 4096 (order: 2, 16384 bytes)
> TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
> TCP: Hash tables configured (established 4096 bind 2048)
> TCP reno registered
> davinci_spi_board_init: NO spi support
> VFS: Disk quotas dquot_6.5.1
> Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
> squashfs: version 3.1 (2006/08/19) Phillip Lougher
> JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
> yaffs May 20 2009 01:11:27 Installing.
> SGI XFS with no debug enabled
> Initializing Cryptographic API
> io scheduler noop registered
> io scheduler anticipatory registered (default)
> LTT : ltt-facilities init
> LTT : ltt-facility-core init in kernel
> davincifb davincifb: dm_osd0_fb: 720x480x16 at 0,0 with framebuffer size 675KB
> davincifb davincifb: dm_vid0_fb: 0x0x16 at 0,0 with framebuffer size 1020KB
> davincifb davincifb: dm_osd1_fb: 720x480x4 at 0,0 with framebuffer size 675KB
> davincifb davincifb: dm_vid1_fb: 0x0x16 at 0,0 with framebuffer size 1020KB
> davincifb davincifb.0: dm_osd0_fb: Failed to obtain ownership of OSD
>  window. DAVINCI-WDT: DaVinci Watchdog Timer: heartbeat 60 sec
> Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
> serial8250.0: ttyS0 at MMIO map 0x1c20000 mem 0xfec20000 (irq = 40) is a
>  16550A RAMDISK driver initialized: 1 RAM disks of 32768K size 1024
>  blocksize netconsole: not configured, aborting
> TI DaVinci EMAC: MAC address is 00:0e:99:02:42:8e
> TI DaVinci EMAC Linux version updated 4.0
> TI DaVinci EMAC: Installed 1 instances.
> Linux video capture interface: v2.00
> vpfe vpfe.1: DaVinci v4l2 capture driver V1.0 loaded
> Trying to register davinci display video device.
> layer=c728d600,layer->video_dev=c728d760
> Trying to register davinci display video device.
> layer=c728d400,layer->video_dev=c728d560
> davinci_init:DaVinci V4L2 Display Driver V1.0 loaded
> 
>  Davici AEW Driver cannot be loaded
>  VIDEO PORT is not enabledData Flow path from CCDC is disabled
> 
>  Davinci AF driver cannot be loaded
>  VIDEO PORT is not enabled
>  CCDC needs to be configured<6>i2c /dev entries driver
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
> MUX: initialized HDIREN
> MUX: initialized ATAEN
>     ide0: MMIO-DMA , BIOS settings: hda:pio, hdb:pio
> hda: TOSHIBA MK4032GAX, ATA DISK drive
> ide0 at 0xfec661f0-0xfec661f7,0xfec663f6 on irq 22
> hda: max request size: 512KiB
> hda: 78140160 sectors (40007 MB), CHS=16383/255/63, UDMA(66)
> hda: cache flushes supported
>  hda: hda1 hda2
> Initializing USB Mass Storage driver...
> usbcore: registered new driver usb-storage
> USB Mass Storage support registered.
> usbcore: registered new driver usbhid
> drivers/usb/input/hid-core.c: v2.6:USB HID core driver
> musb_hdrc: version 6.0, cppi-dma, host, debug=0
> musb_hdrc musb_hdrc: No DMA interrupt line
> musb_hdrc: USB Host mode controller at c785e000 using DMA, IRQ 12
> musb_hdrc musb_hdrc: MUSB HDRC host driver
> musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1
> usb usb1: configuration #1 chosen from 1 choice
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 1 port detected
> mice: PS/2 mouse device common for all mice
> rtc_davinci_evm rtc_davinci_evm: rtc intf: proc
> rtc_davinci_evm rtc_davinci_evm: rtc intf: dev (254:0)
> rtc_davinci_evm rtc_davinci_evm: rtc core: registered rtc_davinci_evm as
>  rtc0 rtc0: hours 12-23 are misreported as duplicate hours 00-11
> davinci-mmc davinci-mmc.0: Supporting 4-bit mode
> davinci-mmc davinci-mmc.0: Using DMA mode
> Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22
>  13:55:50 2006 UTC). ASoC version 0.13.1
> MUX: initialized MCBSP
> AIC3X Audio Codec 0.1
> asoc: aic3x <-> davinci-i2s mapping ok
> ALSA device list:
>   #0: DaVinci EVM (aic3x)
> IPv4 over IPv4 tunneling driver
> TCP bic registered
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> Time: timer0_1 clocksource has been installed.
> Clock event device timer0_0 configured with caps set: 08
> Switched to high resolution mode on CPU 0
> rtc_davinci_evm rtc_davinci_evm: setting the system clock to 2004-02-01
>  12:13:16 (1075637596) IP-Config: Complete:
>       device=eth0, addr=192.168.1.101, mask=255.255.255.0, gw=192.168.1.1,
>      host=192.168.1.101, domain=, nis-domain=(none),
>      bootserver=192.168.1.100, rootserver=192.168.1.100, rootpath=
> Looking up port of RPC 100003/2 on 192.168.1.100
> Looking up port of RPC 100005/1 on 192.168.1.100
> Root-NFS: Server returned error -13 while mounting
>  home/chris/workdir/filesys VFS: Unable to mount root fs via NFS, trying
>  floppy.
> VFS: Cannot open root device "nfs" or unknown-block(2,0)
> Please append a correct "root=" boot option
> Kernel panic - not syncing: VFS: Unable to mount root fs on
>  unknown-block(2,0)
> 
> 
> I cannot seem to figure out why this happening.  any help would be greatly
>  appreciated
> 
> thank you,
> 
> chris jackson
> 
> 
> 
> 
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 

From nsekhar at ti.com  Mon Apr 26 00:56:40 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 26 Apr 2010 11:26:40 +0530
Subject: [PATCH v4 01/13] Davinci: generalized debug macros
In-Reply-To: <1272045424-19240-2-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E6B13CC2@dbde02.ent.ti.com>


Hi Cyril,

On Fri, Apr 23, 2010 at 23:26:52, Chemparathy, Cyril wrote:
> 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 macros through a small chunk of memory placed just
> below the page tables (@0x80003ff8).

Thanks! Looks much better than the ifdefry being used currently.
Some comments below.

>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
> ---
> v4: unchanged from v3
>
>  arch/arm/mach-davinci/include/mach/debug-macro.S |   51 +++++++++++---
>  arch/arm/mach-davinci/include/mach/serial.h      |   13 ++++
>  arch/arm/mach-davinci/include/mach/uncompress.h  |   80 ++++++++++++++++------
>  3 files changed, 112 insertions(+), 32 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/include/mach/debug-macro.S b/arch/arm/mach-davinci/include/mach/debug-macro.S
> index 3cd93a8..ac0fa02 100644
> --- a/arch/arm/mach-davinci/include/mach/debug-macro.S
> +++ b/arch/arm/mach-davinci/include/mach/debug-macro.S
> @@ -17,22 +17,51 @@
>   */
>
>  #include <linux/serial_reg.h>
> +
> +#include <asm/memory.h>
> +
> +#include <mach/serial.h>
> +
>  #define UART_SHIFT   2
>
> +             .pushsection .data
> +davinci_uart_phys:   .word   0
> +davinci_uart_virt:   .word   0
> +             .popsection
> +
>               .macro addruart, rx, tmp
> +
> +             /* Use davinci_uart_phys/virt if already configured */
> +10:          mrc     p15, 0, \rx, c1, c0
> +             tst     \rx, #1                 @ MMU enabled?
> +             ldreq   \rx, =__virt_to_phys(davinci_uart_phys)
> +             ldrne   \rx, =davinci_uart_virt
> +             ldr     \rx, [\rx]
> +             cmp     \rx, #0                 @ is port configured?
> +             bne     99f                     @ already configured
> +
> +             /* Copy uart phys address from decompressor uart info */
>               mrc     p15, 0, \rx, c1, c0
>               tst     \rx, #1                 @ MMU enabled?
> -             moveq   \rx, #0x01000000        @ physical base address
> -             movne   \rx, #0xfe000000        @ virtual base
> -#if defined(CONFIG_ARCH_DAVINCI_DA8XX) && defined(CONFIG_ARCH_DAVINCI_DMx)
> -#error Cannot enable DaVinci and DA8XX platforms concurrently
> -#elif defined(CONFIG_MACH_DAVINCI_DA830_EVM) || \
> -     defined(CONFIG_MACH_DAVINCI_DA850_EVM)
> -             orr     \rx, \rx, #0x00d00000   @ physical base address
> -             orr     \rx, \rx, #0x0000d000   @ of UART 2
> -#else
> -             orr     \rx, \rx, #0x00c20000   @ UART 0
> -#endif
> +             ldreq   \tmp, =__virt_to_phys(davinci_uart_phys)
> +             ldrne   \tmp, =davinci_uart_phys
> +             ldreq   \rx, =DAVINCI_UART_INFO
> +             ldrne   \rx, =__phys_to_virt(DAVINCI_UART_INFO)
> +             ldr     \rx, [\rx, #0]
> +             str     \rx, [\tmp]
> +
> +             /* Copy uart virt address from decompressor uart info */
> +             mrc     p15, 0, \rx, c1, c0
> +             tst     \rx, #1                 @ MMU enabled?
> +             ldreq   \tmp, =__virt_to_phys(davinci_uart_virt)
> +             ldrne   \tmp, =davinci_uart_virt
> +             ldreq   \rx, =DAVINCI_UART_INFO
> +             ldrne   \rx, =__phys_to_virt(DAVINCI_UART_INFO)
> +             ldr     \rx, [\rx, #4]
> +             str     \rx, [\tmp]

You should be able to combine the code chunks into
one by using ldr/str{cond} to configure either the
virtual or physical base depending on whether MMU
is enabled on not. No need to configure both at the
same time.

Also please consider using a temporary variable to
store the result of the first mrc call.

Thanks,
Sekhar

From nsekhar at ti.com  Mon Apr 26 01:49:39 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 26 Apr 2010 12:19:39 +0530
Subject: [PATCH v4 08/13] Davinci: iotable based ioremap() interception
In-Reply-To: <1272045424-19240-9-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E6B13D82@dbde02.ent.ti.com>

On Fri, Apr 23, 2010 at 23:26:59, Chemparathy, Cyril wrote:
> This patch allows for a more flexible ioremap() interception based on iotable
> contents.
>
> SoCs that need ioremap() to fill up davinci_soc_info may directly call
> davinci_io_init() and use ioremap() as needed.  Such SoCs must not fill
> io_desc and io_desc_num entries in struct davinci_soc_info.

So, this patch should probably remove these entries for da850/da830
instead of letting your twice init protection logic to kick in.

I am wondering if it will be more intuitive to pluck davinci_io_init()
out of davinci_common_init() altogether. I think this is also what
Kevin had suggested previously.

Thanks,
Sekhar


From nsekhar at ti.com  Mon Apr 26 02:14:20 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 26 Apr 2010 12:44:20 +0530
Subject: [PATCH v4 11/13] Davinci: tnetv107x soc support
In-Reply-To: <1272045424-19240-12-git-send-email-cyril@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
	<1272045424-19240-10-git-send-email-cyril@ti.com>
	<1272045424-19240-11-git-send-email-cyril@ti.com>
	<1272045424-19240-12-git-send-email-cyril@ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E6B13DBB@dbde02.ent.ti.com>

On Fri, Apr 23, 2010 at 23:27:02, Chemparathy, Cyril wrote:
> 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 PLL.  Some
> elements of the clock architecture are reused from Davinci (e.g. LPSC), but
> the PLL related code is overridden using existing interfaces in "struct clk".
>
> 2. The MMR layout on this SOC is substantially different from Davinci.
> Consequently, the fixed I/O map is a whole lot more convoluted (more so than
> DA8xx).  The net impact here is that IO_ADDRESS() will not work on this SoC,
> and therefore all mappings have to be through ioremap().
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>

[...]

> +
> +/* Base addresses for on-chip devices */
> +#define TNETV107X_TPCC_BASE                  0x01c00000
> +#define TNETV107X_TPTC0_BASE                 0x01c10000
> +#define TNETV107X_TPTC1_BASE                 0x01c10400
> +#define TNETV107X_ASYNC_EMIF_DATA_CE0_BASE   0x30000000
> +#define TNETV107X_WDOG_BASE                  0x08086700
> +#define TNETV107X_SDIO0_BASE                 0x08088700
> +#define TNETV107X_SDIO1_BASE                 0x08088800
> +#define TNETV107X_ASYNC_EMIF_CNTRL_BASE              0x08200000

It will be nice to see these in ascending order.

[...]

> diff --git a/arch/arm/mach-davinci/tnetv107x.c b/arch/arm/mach-davinci/tnetv107x.c
> new file mode 100644
> index 0000000..2dfed3e
> --- /dev/null
> +++ b/arch/arm/mach-davinci/tnetv107x.c
> @@ -0,0 +1,841 @@
> +/*
> + * Texas Instruments TNETV107X SoC Support
> + *

[...]

> +static void __iomem *psc_regs[1];
> +
> +/* Host map for interrupt controller */
> +static u32 intc_host_map[] = { 0x01010000, 0x01010101, -1 };
> +
> +static unsigned long clk_sspll_recalc(struct clk *clk);
> +
> +

Extra line here.

[...]

> +
> +/*
> + * TNETV107X platforms do not use the static mappings from Davinci
> + * IO_PHYS/IO_VIRT. This SOC's interesting MMRs are at different addresses,
> + * and changing IO_PHYS would break away from existing Davinci SOCs.
> + *
> + * The primary impact of the current model is that IO_ADDRESS() is not to be
> + * used to map registers on TNETV107X. With the exception of early boot code
> + * in tnetv107x_init() (where fixed maps are necessary), all other pieces of
> + * code absolutely _must_ use ioremap().
> + *
> + * 1.        The first section in here is specifically for edma, even through the
> + *   edma driver code properly ioremap()s its register space.  This is
> + *   because the edma MMRs on tnetv107x unfortunately fall within the
> + *   davinci IO_PHYS - (IO_PHYS + IO_SIZE) range, and therefore the edma
> + *   driver's ioremap() gets subverted by davinci_ioremap(). Yikes!

I had pointed this earlier, but don't remember a follow-up discussion.

Why not just redefine IO_PHYS for this SoC?

Thanks,
Sekhar


From Jon.Povey at racelogic.co.uk  Sun Apr 25 23:48:11 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Mon, 26 Apr 2010 05:48:11 +0100
Subject: Can't Mount NFS from DVEVM 6446
In-Reply-To: <77544900650898055643541774144164931012-Webmail@me.com>
Message-ID: <70E876B0EA86DD4BAF101844BC814DFE28AA5087@Cloud.RL.local>

Chris wrote:
> Hello all,
>
> I am having trouble mounting to the NFS server on my host Linux
> machine.  My configuration is as follows.

You might need a leading slash on your env rootpath.

Also check "sudo exportfs" on the ubuntu host. You need to do "exportfs -ra" after changing /etc/exports, not sure if restarting the NFS server helps. I am not sure if error -13 means it has contacted the server OK or not.

If that fails, can you test basic networking from u-boot (ping, maybe dhcp)?
After that look for NFS traffic with tcpdump on the host machine.


--
Jon Povey
jon.povey at racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network



From Jon.Povey at racelogic.co.uk  Mon Apr 26 00:03:28 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Mon, 26 Apr 2010 06:03:28 +0100
Subject: Layout of OOB data in NAND flash
In-Reply-To: <C5A8FDEFF7647F4C9CB927D7DEB307730682F671@ahr075s.basler.corp>
Message-ID: <70E876B0EA86DD4BAF101844BC814DFE28AA5088@Cloud.RL.local>

Gaer, A. wrote:
> Hi!
>
> It seems like the layout of OOB/4-Bit-ECC data in NAND flash differs
> from RBL/UBL to u-boot/linux (at least on a DM365 device). Is there
> any good reason for this?

Hi, just to say I am working in similar areas (trying to understand what the hell TI are doing with their NAND ECC layouts), on DM355 so far but may start looking at DM365 before long. So I am interested in whatever progress you make.

The DM355 silicon errata admits that the DM355 RBL doesn't actually check 4-bit ECC at all. But the layout used by UBL, u-boot and linux is all messed up.
There is some stuff about DM365 RBL ECC handling in the DM365 silicon errata too, not the same thing, but maybe of interest.

> As far as I understand, the RBL/UBL uses this layout (2048 byte
> pages):

What is your understanding based on? What wrote that format? Are you reading that from flash or working it out by inspecting code?

> The different layout means that it is impossible to update UBL/u-boot
> from u-boot or linux.

Have you tried? On DM355 at least, it seems this would actually work.

> Another question: 512 byte pages in linux seem to have a really funny
> oob layout
>
> EEEEEXEE
> XXXXXEEE
>
> Does anybody know the reason for that? (I know the 6th byte is the
> manufacturer bad-block marker. But why not just put the ECC data into
> the last 10 byte of oob like RBL/UBL do it?)

Good luck getting good answers to these questions.

This might be worth some wiki documenting when it becomes clearer.

--
Jon Povey
jon.povey at racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network



From nsekhar at ti.com  Mon Apr 26 03:44:07 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 26 Apr 2010 14:14:07 +0530
Subject: OMAP-L138 X11 on S-Video
In-Reply-To: <z2y2b3771721004232212nea77d4bblc66dd71c8c09dc8a@mail.gmail.com>
References: <z2y2b3771721004232212nea77d4bblc66dd71c8c09dc8a@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E6B13ED3@dbde02.ent.ti.com>

Hello,

On Sat, Apr 24, 2010 at 10:42:57, Bharathi Subramanian wrote:
> Hi All,
>
> In OMAP-L138 EVM, Is it possible to use the S-Video out as default
> output device for X11.  Now I am able to access it using VPIF example
> program. In beagle board, I used the S-Video out for X11 output. I am
> thinking of using  the OMAP-L138 S-Video output also in the same
> fashion. Please throw some light on this topic.

X11 requires fbdev and VPIF supports v4l2 only.

It is not possible to get X11 output on OMAP-L138
S-Video. It is useful for streaming video only.

For X11 you can consider using the LCD interface
instead.

Thanks,
Sekhar


From Thomas.Koeller at baslerweb.com  Mon Apr 26 04:08:13 2010
From: Thomas.Koeller at baslerweb.com (Koeller, T.)
Date: Mon, 26 Apr 2010 11:08:13 +0200
Subject: [PATCH 3/4] DaVinci SPI: Fix SPI clock prescale factor computation
In-Reply-To: <871veaksca.fsf@deeprootsystems.com>
References: <871veaksca.fsf@deeprootsystems.com>
Message-ID: <C5A8FDEFF7647F4C9CB927D7DEB307730E5BA5EA@ahr075s.basler.corp>

From: Kevin Hilman [mailto:khilman at deeprootsystems.com]:

> What platforms was this tested on?
dm365_evm

>
> This looks like a fix that should be queued for 2.6.34-rc, but would
> be helpful to have a review/ack from Sandeep on this.
> 
> Also, this fix needs to go upstream through the SPI maintainers.
> 
> Please send to spi-devel-general at lists.sourceforge.net, with
> the davinci list in CC as well as these folks:
> 
> Grant Likely <grant.likely at secretlab.ca>
> Sandeep Paulraj <s-paulraj at ti.com>
> Philby John <pjohn at in.mvista.com>
> Sudhakar Rajashekhara <sudhakar.raj at ti.com>

I did.

thanks,
Thomas
 

From schen at mvista.com  Mon Apr 26 05:05:37 2010
From: schen at mvista.com (Steve Chen)
Date: Mon, 26 Apr 2010 05:05:37 -0500
Subject: help for linux emif driver 2nd
In-Reply-To: <a76abd.9329.12838027f8f.Coremail.liuyue18301@163.com>
References: <a76abd.9329.12838027f8f.Coremail.liuyue18301@163.com>
Message-ID: <i2ifca5cfb21004260305g80472546g2c77922116f57165@mail.gmail.com>

2010/4/25 liuyue18301 <liuyue18301 at 163.com>:
>
> hello Guys:
> ???? this is second time to turn to help on the same problem.
> ???? i want to know is there EMIF driver in the linux? and if i want to

There is no EMIF driver.

> send/recv data to the uarts which are expanded by FPGA ,how can i do it?

The dm9000 driver on dm365 is on EMIF.  Perhaps you can take a look.

> which driver should i create or modify EMIF driver or UART driver?i want to
> write data to the EMIF in the application code,but i can't find the EMIF
> driver in the linux. confused

If I remember correctly (it has been over a year since I worked on
DaVinci), devices on EMIF are accessed with 2 registers.  First you
configure the address you want to access in one registers, then you
read/write the value in another.  Again, take a look at the dm9000.
It will probably give you some ideas what you need to do to get UART
working on EMIF.

Regards,

Steve

From schen at mvista.com  Mon Apr 26 05:16:08 2010
From: schen at mvista.com (Steve Chen)
Date: Mon, 26 Apr 2010 05:16:08 -0500
Subject: help for linux emif driver 2nd
In-Reply-To: <i2ifca5cfb21004260305g80472546g2c77922116f57165@mail.gmail.com>
References: <a76abd.9329.12838027f8f.Coremail.liuyue18301@163.com>
	<i2ifca5cfb21004260305g80472546g2c77922116f57165@mail.gmail.com>
Message-ID: <y2ufca5cfb21004260316gb8cfde01yacd58e5c1966aded@mail.gmail.com>

On Mon, Apr 26, 2010 at 5:05 AM, Steve Chen <schen at mvista.com> wrote:
> 2010/4/25 liuyue18301 <liuyue18301 at 163.com>:
>>
>> hello Guys:
>> ???? this is second time to turn to help on the same problem.
>> ???? i want to know is there EMIF driver in the linux? and if i want to
>
> There is no EMIF driver.
>
>> send/recv data to the uarts which are expanded by FPGA ,how can i do it?
>
> The dm9000 driver on dm365 is on EMIF. ?Perhaps you can take a look.

Correction, this should be dm355.  --NOT-- dm365.

Regards,

Steve

From nsekhar at ti.com  Mon Apr 26 05:19:56 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 26 Apr 2010 15:49:56 +0530
Subject: help for linux emif driver 2nd
In-Reply-To: <i2ifca5cfb21004260305g80472546g2c77922116f57165@mail.gmail.com>
References: <a76abd.9329.12838027f8f.Coremail.liuyue18301@163.com>
	<i2ifca5cfb21004260305g80472546g2c77922116f57165@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E6B13FE7@dbde02.ent.ti.com>

Hi Steve,

On Mon, Apr 26, 2010 at 15:35:37, Steve Chen wrote:
> 2010/4/25 liuyue18301 <liuyue18301 at 163.com>:
> >
> > hello Guys:
> >      this is second time to turn to help on the same problem.
> >      i want to know is there EMIF driver in the linux? and if i want to
>
> There is no EMIF driver.
>
> > send/recv data to the uarts which are expanded by FPGA ,how can i do it?
>
> The dm9000 driver on dm365 is on EMIF.  Perhaps you can take a look.

s/dm365/dm355

>
> > which driver should i create or modify EMIF driver or UART driver?i want to
> > write data to the EMIF in the application code,but i can't find the EMIF
> > driver in the linux. confused
>
> If I remember correctly (it has been over a year since I worked on
> DaVinci), devices on EMIF are accessed with 2 registers.  First you
> configure the address you want to access in one registers, then you
> read/write the value in another.  Again, take a look at the dm9000.
> It will probably give you some ideas what you need to do to get UART
> working on EMIF.

Actually, there is just one access. You just choose the address
to be accessed based on which chip select you need asserted. This
information is present in the device memory map.

I can see some signs of a fading memory :)

Thanks,
Sekhar


From schen at mvista.com  Mon Apr 26 05:24:20 2010
From: schen at mvista.com (Steve Chen)
Date: Mon, 26 Apr 2010 05:24:20 -0500
Subject: help for linux emif driver 2nd
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E6B13FE7@dbde02.ent.ti.com>
References: <a76abd.9329.12838027f8f.Coremail.liuyue18301@163.com>
	<i2ifca5cfb21004260305g80472546g2c77922116f57165@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E6B13FE7@dbde02.ent.ti.com>
Message-ID: <z2jfca5cfb21004260324pb18f9de1z42f1b9dd50528434@mail.gmail.com>

On Mon, Apr 26, 2010 at 5:19 AM, Nori, Sekhar <nsekhar at ti.com> wrote:
> Hi Steve,
>
> On Mon, Apr 26, 2010 at 15:35:37, Steve Chen wrote:
>> 2010/4/25 liuyue18301 <liuyue18301 at 163.com>:
>> >
>> > hello Guys:
>> > ? ? ?this is second time to turn to help on the same problem.
>> > ? ? ?i want to know is there EMIF driver in the linux? and if i want to
>>
>> There is no EMIF driver.
>>
>> > send/recv data to the uarts which are expanded by FPGA ,how can i do it?
>>
>> The dm9000 driver on dm365 is on EMIF. ?Perhaps you can take a look.
>
> s/dm365/dm355
>
>>
>> > which driver should i create or modify EMIF driver or UART driver?i want to
>> > write data to the EMIF in the application code,but i can't find the EMIF
>> > driver in the linux. confused
>>
>> If I remember correctly (it has been over a year since I worked on
>> DaVinci), devices on EMIF are accessed with 2 registers. ?First you
>> configure the address you want to access in one registers, then you
>> read/write the value in another. ?Again, take a look at the dm9000.
>> It will probably give you some ideas what you need to do to get UART
>> working on EMIF.
>
> Actually, there is just one access. You just choose the address
> to be accessed based on which chip select you need asserted. This
> information is present in the device memory map.
>
> I can see some signs of a fading memory :)

And perhaps of old age as well :-)  Thanks for the corrections.

Regards,

Steve

From bharathi.list at gmail.com  Mon Apr 26 05:35:03 2010
From: bharathi.list at gmail.com (Bharathi Subramanian)
Date: Mon, 26 Apr 2010 16:05:03 +0530
Subject: OMAP-L138 X11 on S-Video
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E6B13ED3@dbde02.ent.ti.com>
References: <z2y2b3771721004232212nea77d4bblc66dd71c8c09dc8a@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E6B13ED3@dbde02.ent.ti.com>
Message-ID: <n2t2b3771721004260335rd1877313ycf78863daa73d4ef@mail.gmail.com>

On Mon, Apr 26, 2010 at 2:14 PM, Nori, Sekhar <nsekhar at ti.com> wrote:

>> In OMAP-L138 EVM, Is it possible to use the S-Video out as default
>> output device for X11. ?Now I am able to access it using VPIF example
>> program. In beagle board, I used the S-Video out for X11 output. I am
>> thinking of using ?the OMAP-L138 S-Video output also in the same
>> fashion. Please throw some light on this topic.
>
> X11 requires fbdev and VPIF supports v4l2 only.
> It is not possible to get X11 output on OMAP-L138
> S-Video. It is useful for streaming video only.
> For X11 you can consider using the LCD interface
> instead.

What about DirectFB? Will it help in this case? Any body tried in that
angle? Plz share your experience.

Bye :)
-- 
Bharathi Subramanian

From Andreas.Gaer at baslerweb.com  Mon Apr 26 06:40:41 2010
From: Andreas.Gaer at baslerweb.com (Gaer, A.)
Date: Mon, 26 Apr 2010 13:40:41 +0200
Subject: Layout of OOB data in NAND flash
In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE28AA5088@Cloud.RL.local>
References: <C5A8FDEFF7647F4C9CB927D7DEB307730682F671@ahr075s.basler.corp>
	<70E876B0EA86DD4BAF101844BC814DFE28AA5088@Cloud.RL.local>
Message-ID: <C5A8FDEFF7647F4C9CB927D7DEB307730682F678@ahr075s.basler.corp>

Hello Jon,

Jon Povey wrote:
> > As far as I understand, the RBL/UBL uses this layout (2048 byte
> > pages):

> What is your understanding based on? What wrote that format?
> Are you reading that from flash or working it out by inspecting code?

I worked through some sources:

sprufg5a.pdf, figure 98 & 99
nandwriter.c code from the flash_utils source
UBL source
Davinci NAND code in openocd
davinci_nand.c from u-boot and linux

I wrote UBL/u-boot with the sfh_DM36x.exe serial tool and verified
(reading back the pages in u-boot) that the OOB data has indeed the
layout mentioned in table 98&99 from sprufg5a.pdf. I wrote the same data
from u-boot and noticed that the layout is different. I tried booting
with that and failed, so I assume the DM365 actually does ECC4. After
changing the layout definition in davinci_nand.c I'm now able to write
UBL/u-boot from u-boot and correctly boot that.

Regards,
 Andreas.
 
-----Original Message-----
From: Jon Povey [mailto:Jon.Povey at racelogic.co.uk] 
Sent: Monday, April 26, 2010 7:03 AM
To: Gaer, A.
Cc: davinci-linux-open-source at linux.davincidsp.com
Subject: RE: Layout of OOB data in NAND flash

Gaer, A. wrote:
> Hi!
>
> It seems like the layout of OOB/4-Bit-ECC data in NAND flash differs 
> from RBL/UBL to u-boot/linux (at least on a DM365 device). Is there 
> any good reason for this?

Hi, just to say I am working in similar areas (trying to understand what
the hell TI are doing with their NAND ECC layouts), on DM355 so far but
may start looking at DM365 before long. So I am interested in whatever
progress you make.

The DM355 silicon errata admits that the DM355 RBL doesn't actually
check 4-bit ECC at all. But the layout used by UBL, u-boot and linux is
all messed up.
There is some stuff about DM365 RBL ECC handling in the DM365 silicon
errata too, not the same thing, but maybe of interest.

> As far as I understand, the RBL/UBL uses this layout (2048 byte
> pages):

What is your understanding based on? What wrote that format? Are you
reading that from flash or working it out by inspecting code?

> The different layout means that it is impossible to update UBL/u-boot 
> from u-boot or linux.

Have you tried? On DM355 at least, it seems this would actually work.

> Another question: 512 byte pages in linux seem to have a really funny 
> oob layout
>
> EEEEEXEE
> XXXXXEEE
>
> Does anybody know the reason for that? (I know the 6th byte is the 
> manufacturer bad-block marker. But why not just put the ECC data into 
> the last 10 byte of oob like RBL/UBL do it?)

Good luck getting good answers to these questions.

This might be worth some wiki documenting when it becomes clearer.

--
Jon Povey
jon.povey at racelogic.co.uk

Racelogic is a limited company registered in England. Registered number
2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham,
Bucks, MK18 1TB .

The information contained in this electronic mail transmission is
intended by Racelogic Ltd for the use of the named individual or entity
to which it is directed and may contain information that is confidential
or privileged. If you have received this electronic mail transmission in
error, please delete it from your system without copying or forwarding
it, and notify the sender of the error by reply email so that the
sender's address records can be corrected. The views expressed by the
sender of this communication do not necessarily represent those of
Racelogic Ltd. Please note that Racelogic reserves the right to monitor
e-mail communications passing through its network


From sudhakar.raj at ti.com  Mon Apr 26 07:12:26 2010
From: sudhakar.raj at ti.com (Sudhakar Rajashekhara)
Date: Mon, 26 Apr 2010 17:42:26 +0530
Subject: MMC/SD problem - OMAPL137 EVM
In-Reply-To: <j2o38f801ba1004221127kc5971898r5a88fed0ebc98d8@mail.gmail.com>
References: <j2o38f801ba1004221127kc5971898r5a88fed0ebc98d8@mail.gmail.com>
Message-ID: <017e01cae539$bc5082d0$34f18870$@raj@ti.com>

I have tested with the following cards on my OMAP-L137 EVM and I have not faced such issues:

 

.         Sandisk 4GB SDHC card

.         Patriot 8GB SDHC card

.         Transcend 2GB card

 

Regards,

Sudhakar

 

From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On
Behalf Of Grzegorz Skiba
Sent: Thursday, April 22, 2010 11:57 PM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: MMC/SD problem - OMAPL137 EVM

 

I have problem with MMC/SD Linux device driver, I have OMAPL137 EVM board, 2.6.33-rc4 linux ver, form  DaVinci-PSP-SDK-03.20.00.11.
Linux kernel doesn't recognize either RS MMC or SD. I commented out part related to LCD and NAND to make sure that pinmux
configuration is ok. Even with default config I'm unable to access to SD or MMC cord. I compiled MMC/SD driver with debug and I this
is what I get: 

This is what I get without SD/MMC card: 
    0.070000] Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
[    0.070000] serial8250.0: ttyS0 at MMIO 0x1c42000 (irq = 25) is a 16550A
[    0.070000] serial8250.0: ttyS1 at MMIO 0x1d0c000 (irq = 53) is a 16550A
[    0.070000] serial8250.0: ttyS2 at MMIO 0x1d0d000 (irq = 61) is a 16550A
[    0.080000] brd: module loaded
[    0.080000] spi_davinci spi_davinci.0: DaVinci SPI driver in EDMA mode
[    0.080000] Using RX channel = 14 , TX channel = 15 and event queue = 1
[    0.080000] spi_davinci spi_davinci.0: Controller at 0xfec41000 
[    0.080000] console [netcon0] enabled
[    0.080000] netconsole: network logging started
[    0.080000] i2c /dev entries driver
[    0.080000] sdhci: Secure Digital Host Controller Interface driver
[    0.080000] sdhci: Copyright(c) Pierre Ossman
[    0.080000] davinci_mmc davinci_mmc.0: max_phys_segs=16
[    0.080000] davinci_mmc davinci_mmc.0: max_hw_segs=16
[    0.080000] davinci_mmc davinci_mmc.0: max_blk_size=4095
[    0.080000] davinci_mmc davinci_mmc.0: max_req_size=268365825
[    0.080000] davinci_mmc davinci_mmc.0: max_seg_size=2097120
[    0.080000] mmc0: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0
[    0.080000] davinci_mmc davinci_mmc.0: clock 0Hz busmode 1 powermode 0 Vdd 0000
[    0.080000] davinci_mmc davinci_mmc.0: Disabling 4 bit mode
[    0.080000] davinci_mmc davinci_mmc.0: Using DMA, 4-bit mode

When I plug in SD card:

[    3.480000] Warning: unable to open an initial console.
[  282.080000] mmc0: clock 0Hz busmode 1 powermode 1 cs 0 Vdd 21 width 0 timing 0
[  282.080000] davinci_mmc davinci_mmc.0: clock 0Hz busmode 1 powermode 1 Vdd 0015
[  282.080000] davinci_mmc davinci_mmc.0: Disabling 4 bit mode
[  282.100000] mmc0: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 21 width 0 timing 0
[  282.100000] davinci_mmc davinci_mmc.0: clock 400000Hz busmode 1 powermode 2 Vdd 0015
[  282.100000] davinci_mmc davinci_mmc.0: Disabling 4 bit mode
[  282.120000] mmc0: clock 400000Hz busmode 1 powermode 2 cs 1 Vdd 21 width 0 timing 0
[  282.120000] davinci_mmc davinci_mmc.0: clock 400000Hz busmode 1 powermode 2 Vdd 0015
[  282.120000] davinci_mmc davinci_mmc.0: Disabling 4 bit mode
[  282.120000] mmc0: starting CMD0 arg 00000000 flags 000000c0
[  282.120000] davinci_mmc davinci_mmc.0: CMD0, arg 0x00000000, (R? response)
[  282.120000] davinci_mmc davinci_mmc.0: unknown resp_type 0000
[  282.120000] mmc0: req done (CMD0): 0: 00000000 00000000 00000000 00000000
[  282.120000] mmc0: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 21 width 0 timing 0
[  282.120000] davinci_mmc davinci_mmc.0: clock 400000Hz busmode 1 powermode 2 Vdd 0015
[  282.120000] davinci_mmc davinci_mmc.0: Disabling 4 bit mode
[  282.120000] mmc0: starting CMD8 arg 000001aa flags 000002f5
[  282.120000] davinci_mmc davinci_mmc.0: CMD8, arg 0x000001aa, R1/R5/R6/R7 response
[  282.120000] mmc0: req done (CMD8): 0: 00000000 00000000 00000000 00000000
[  282.120000] mmc0: starting CMD5 arg 00000000 flags 000002e1
[  282.120000] davinci_mmc davinci_mmc.0: CMD5, arg 0x00000000, R3/R4 response
[  282.120000] mmc0: req done (CMD5): 0: 00000000 00000000 00000000 00000000
[  282.120000] mmc0: host doesn't support card's voltages

Here is kernel config related to MMC: 
CONFIG_MMC=y
CONFIG_MMC_DEBUG=y
# CONFIG_MMC_UNSAFE_RESUME is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_SDHCI=y
# CONFIG_MMC_SDHCI_PLTFM is not set
# CONFIG_MMC_AT91 is not set
# CONFIG_MMC_ATMELMCI is not set
CONFIG_MMC_DAVINCI=y
# CONFIG_MMC_SPI is not set

Any ideas what I'm doing wrong ? I use 2 MB SD card and 1GB MMC card and I have the same result 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100426/1cd2821f/attachment-0001.html>

From Agraharam_Reddy at mindtree.com  Mon Apr 26 07:23:16 2010
From: Agraharam_Reddy at mindtree.com (Agraharam Samba Siva Reddy)
Date: Mon, 26 Apr 2010 17:53:16 +0530
Subject: Help to  find the ethernet driver related docs
In-Reply-To: <C5A8FDEFF7647F4C9CB927D7DEB307730682F678@ahr075s.basler.corp>
References: <C5A8FDEFF7647F4C9CB927D7DEB307730682F671@ahr075s.basler.corp>
	<70E876B0EA86DD4BAF101844BC814DFE28AA5088@Cloud.RL.local>
	<C5A8FDEFF7647F4C9CB927D7DEB307730682F678@ahr075s.basler.corp>
Message-ID: <F1172CE95E42B4409E3AFBFC9D00033301DFA8581D@MTW02MSG01.mindtree.com>

Hi All,

Could anyone help me to find the Ethernet driver related documents?

Regards
Siva

-----Original Message-----
From: davinci-linux-open-source-bounces+agraharam_reddy=mindtree.com at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+agraharam_reddy=mindtree.com at linux.davincidsp.com] On Behalf Of Gaer, A.
Sent: Monday, April 26, 2010 5:11 PM
To: Jon Povey
Cc: davinci-linux-open-source at linux.davincidsp.com
Subject: RE: Layout of OOB data in NAND flash

Hello Jon,

Jon Povey wrote:
> > As far as I understand, the RBL/UBL uses this layout (2048 byte
> > pages):

> What is your understanding based on? What wrote that format?
> Are you reading that from flash or working it out by inspecting code?

I worked through some sources:

sprufg5a.pdf, figure 98 & 99
nandwriter.c code from the flash_utils source
UBL source
Davinci NAND code in openocd
davinci_nand.c from u-boot and linux

I wrote UBL/u-boot with the sfh_DM36x.exe serial tool and verified
(reading back the pages in u-boot) that the OOB data has indeed the
layout mentioned in table 98&99 from sprufg5a.pdf. I wrote the same data
from u-boot and noticed that the layout is different. I tried booting
with that and failed, so I assume the DM365 actually does ECC4. After
changing the layout definition in davinci_nand.c I'm now able to write
UBL/u-boot from u-boot and correctly boot that.

Regards,
 Andreas.

-----Original Message-----
From: Jon Povey [mailto:Jon.Povey at racelogic.co.uk]
Sent: Monday, April 26, 2010 7:03 AM
To: Gaer, A.
Cc: davinci-linux-open-source at linux.davincidsp.com
Subject: RE: Layout of OOB data in NAND flash

Gaer, A. wrote:
> Hi!
>
> It seems like the layout of OOB/4-Bit-ECC data in NAND flash differs
> from RBL/UBL to u-boot/linux (at least on a DM365 device). Is there
> any good reason for this?

Hi, just to say I am working in similar areas (trying to understand what
the hell TI are doing with their NAND ECC layouts), on DM355 so far but
may start looking at DM365 before long. So I am interested in whatever
progress you make.

The DM355 silicon errata admits that the DM355 RBL doesn't actually
check 4-bit ECC at all. But the layout used by UBL, u-boot and linux is
all messed up.
There is some stuff about DM365 RBL ECC handling in the DM365 silicon
errata too, not the same thing, but maybe of interest.

> As far as I understand, the RBL/UBL uses this layout (2048 byte
> pages):

What is your understanding based on? What wrote that format? Are you
reading that from flash or working it out by inspecting code?

> The different layout means that it is impossible to update UBL/u-boot
> from u-boot or linux.

Have you tried? On DM355 at least, it seems this would actually work.

> Another question: 512 byte pages in linux seem to have a really funny
> oob layout
>
> EEEEEXEE
> XXXXXEEE
>
> Does anybody know the reason for that? (I know the 6th byte is the
> manufacturer bad-block marker. But why not just put the ECC data into
> the last 10 byte of oob like RBL/UBL do it?)

Good luck getting good answers to these questions.

This might be worth some wiki documenting when it becomes clearer.

--
Jon Povey
jon.povey at racelogic.co.uk

Racelogic is a limited company registered in England. Registered number
2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham,
Bucks, MK18 1TB .

The information contained in this electronic mail transmission is
intended by Racelogic Ltd for the use of the named individual or entity
to which it is directed and may contain information that is confidential
or privileged. If you have received this electronic mail transmission in
error, please delete it from your system without copying or forwarding
it, and notify the sender of the error by reply email so that the
sender's address records can be corrected. The views expressed by the
sender of this communication do not necessarily represent those of
Racelogic Ltd. Please note that Racelogic reserves the right to monitor
e-mail communications passing through its network

_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

http://www.mindtree.com/email/disclaimer.html

From mohameeed2010 at hotmail.com  Mon Apr 26 08:41:49 2010
From: mohameeed2010 at hotmail.com (Mohamed AbdElwahed)
Date: Mon, 26 Apr 2010 13:41:49 +0000
Subject: I need the cache layout tool
In-Reply-To: <mailman.1924.1272284105.11996.davinci-linux-open-source@linux.davincidsp.com>
References: <mailman.1924.1272284105.11996.davinci-linux-open-source@linux.davincidsp.com>
Message-ID: <COL106-W17B8CA680A7C3B2152A6DFAB040@phx.gbl>


Hi All,

kindly if anybody have a link to download "version 7.0.0 release of the C6000 Code Generation Tools" i need to use the cache layout tool .

i already have 6.1.x version.

---------

Any help is highly appreciated

BEST REGARD

Mohamed AbdElwahed 
 		 	   		  
_________________________________________________________________
Hotmail: Free, trusted and rich email service.
https://signup.live.com/signup.aspx?id=60969
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100426/95a133e8/attachment.html>

From surfinbum at mac.com  Mon Apr 26 08:55:53 2010
From: surfinbum at mac.com (Chris)
Date: Mon, 26 Apr 2010 09:55:53 -0400
Subject: Can't Mount NFS from DVEVM 6446
In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE28AA5087@Cloud.RL.local>
References: <70E876B0EA86DD4BAF101844BC814DFE28AA5087@Cloud.RL.local>
Message-ID: <135235346721833569084685780115313774572-Webmail@me.com>

Thanks for all the help, 

I got the board to mount to the NFS by adding the a "/" to my rootpath.  Also, restarting the NFS server and reexporting the exports file fixed the problem.  

thanks again, i was hung on that one for sometime!

chris jackson

From cyril at ti.com  Mon Apr 26 09:38:59 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Mon, 26 Apr 2010 10:38:59 -0400
Subject: [PATCH v4 01/13] Davinci: generalized debug macros
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E6B13CC2@dbde02.ent.ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E6B13CC2@dbde02.ent.ti.com>
Message-ID: <4BD5A583.3040002@ti.com>

Hi Sekhar,

Thanks for the review.  Please see my comments below...

/* Block 1 - UART phys and virt already configured locally */

[...]
>> +             /* Use davinci_uart_phys/virt if already configured */
>> +10:          mrc     p15, 0, \rx, c1, c0
>> +             tst     \rx, #1                 @ MMU enabled?
>> +             ldreq   \rx, =__virt_to_phys(davinci_uart_phys)
>> +             ldrne   \rx, =davinci_uart_virt
>> +             ldr     \rx, [\rx]
>> +             cmp     \rx, #0                 @ is port configured?
>> +             bne     99f                     @ already configured

/* Block 2 - local config missing, copy DAVINCI_UART_INFO */

[...]
>> +             /* Copy uart phys address from decompressor uart info */
>>               mrc     p15, 0, \rx, c1, c0
>>               tst     \rx, #1                 @ MMU enabled?
>> +             ldreq   \tmp, =__virt_to_phys(davinci_uart_phys)
>> +             ldrne   \tmp, =davinci_uart_phys
>> +             ldreq   \rx, =DAVINCI_UART_INFO
>> +             ldrne   \rx, =__phys_to_virt(DAVINCI_UART_INFO)
>> +             ldr     \rx, [\rx, #0]
>> +             str     \rx, [\tmp]

/* Block 3 - local config missing, copy DAVINCI_UART_INFO + 4 */

[...]
>> +             mrc     p15, 0, \rx, c1, c0
>> +             tst     \rx, #1                 @ MMU enabled?
>> +             ldreq   \tmp, =__virt_to_phys(davinci_uart_virt)
>> +             ldrne   \tmp, =davinci_uart_virt
>> +             ldreq   \rx, =DAVINCI_UART_INFO
>> +             ldrne   \rx, =__phys_to_virt(DAVINCI_UART_INFO)
>> +             ldr     \rx, [\rx, #4]
>> +             str     \rx, [\tmp]
> 
> You should be able to combine the code chunks into
> one by using ldr/str{cond} to configure either the
> virtual or physical base depending on whether MMU
> is enabled on not. No need to configure both at the
> same time.

The first time that the addruart macro is used, it copies the phys and 
virt base addresses from the DAVINCI_UART_INFO area.  Since this 
operation could be pre-mmu-init, it will need to copy both the phys and 
virt addresses from DAVINCI_UART_INFO to davinci_uart_[virt/phys].

Subsequent runs of addruart directly load davinci_uart_[virt/phys] 
(Block 1 above) without added jugglery.

> Also please consider using a temporary variable to
> store the result of the first mrc call.

Ouch.  I wish we had a few more usable registers to play with here, 
because that would have helped consolidate blocks 2 and 3 (above) into a 
single piece of streamlined code.

Since the register allocation in early boot is pretty tight, I couldn't 
take the liberty of clobbering anything beyond the macro's parameter 
list.  That said, if there is a register that we are free to clobber, 
I'd gladly use it to condense the code down a bit.  Any thoughts?

Regards
Cyril.

From cyril at ti.com  Mon Apr 26 09:44:13 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Mon, 26 Apr 2010 10:44:13 -0400
Subject: [PATCH v4 08/13] Davinci: iotable based ioremap() interception
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E6B13D82@dbde02.ent.ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E6B13D82@dbde02.ent.ti.com>
Message-ID: <4BD5A6BD.9050501@ti.com>

Hi Sekhar,

>> SoCs that need ioremap() to fill up davinci_soc_info may directly call
>> davinci_io_init() and use ioremap() as needed.  Such SoCs must not fill
>> io_desc and io_desc_num entries in struct davinci_soc_info.
> 
> So, this patch should probably remove these entries for da850/da830
> instead of letting your twice init protection logic to kick in.
> 
> I am wondering if it will be more intuitive to pluck davinci_io_init()
> out of davinci_common_init() altogether. I think this is also what
> Kevin had suggested previously.

I am open to either approach.  My approach so far was that the default 
case (i.e., SoCs that don't need to ioremap() early) should simply 
operate as before.

Regards
Cyril.

From cyril at ti.com  Mon Apr 26 09:54:53 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Mon, 26 Apr 2010 10:54:53 -0400
Subject: [PATCH v4 11/13] Davinci: tnetv107x soc support
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E6B13DBB@dbde02.ent.ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
	<1272045424-19240-10-git-send-email-cyril@ti.com>
	<1272045424-19240-11-git-send-email-cyril@ti.com>
	<1272045424-19240-12-git-send-email-cyril@ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E6B13DBB@dbde02.ent.ti.com>
Message-ID: <4BD5A93D.2080102@ti.com>

Hi Sekhar,

[...]
>> +/*
>> + * TNETV107X platforms do not use the static mappings from Davinci
>> + * IO_PHYS/IO_VIRT. This SOC's interesting MMRs are at different addresses,
>> + * and changing IO_PHYS would break away from existing Davinci SOCs.
>> + *
>> + * The primary impact of the current model is that IO_ADDRESS() is not to be
>> + * used to map registers on TNETV107X. With the exception of early boot code
>> + * in tnetv107x_init() (where fixed maps are necessary), all other pieces of
>> + * code absolutely _must_ use ioremap().
>> + *
>> + * 1.        The first section in here is specifically for edma, even through the
>> + *   edma driver code properly ioremap()s its register space.  This is
>> + *   because the edma MMRs on tnetv107x unfortunately fall within the
>> + *   davinci IO_PHYS - (IO_PHYS + IO_SIZE) range, and therefore the edma
>> + *   driver's ioremap() gets subverted by davinci_ioremap(). Yikes!
> 
> I had pointed this earlier, but don't remember a follow-up discussion.
> 
> Why not just redefine IO_PHYS for this SoC?

I thought I'd responded in [1].

But this does bring up a good point.  Now that ioremap interception no 
longer remaps per IO_PHYS/IO_VIRT, the edma ioremap() should operate 
correctly even without this special iotable entry.  I will get rid of 
this in the next  rev.

Regards
Cyril.

[1]http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-April/018453.html

From jtobias at viaas.com  Mon Apr 26 12:55:02 2010
From: jtobias at viaas.com (John Tobias)
Date: Mon, 26 Apr 2010 10:55:02 -0700
Subject: Possible uboot crashes
In-Reply-To: <4BD29316.6000903@linespeed.net>
References: <x2n66b2b2311004231309r3e885ab6yf9dce952cd4997af@mail.gmail.com>
	<201004240840.11552.caglarakyuz@gmail.com>
	<4BD29316.6000903@linespeed.net>
Message-ID: <s2w66b2b2311004261055sc48b5e8fnfc36bd8bc4458aac@mail.gmail.com>

Hi,

Yes, that is correct, I am using a NAND flash on my device.

Thanks for the input.

Best Regards,

John

On Fri, Apr 23, 2010 at 11:43 PM, Brian G Rhodes <bgr at linespeed.net> wrote:

> Caglar Akyuz wrote:
>
>> On Friday 23 April 2010 11:09:51 pm John Tobias wrote:
>>
>>
>>> Hello Guys,
>>>
>>> I would like to know what are the possible chances that u-boot/ubl
>>>  crashes?. I am looking for some theory/scenario that I can possibly
>>>  connect/apply the scenario to what happened to my device based on
>>> dm6446.
>>>
>>> The device has been running for a year now and for some reason it never
>>>  come back anymore. I connect through the serial port of the device and
>>>  check if there's something different. The device was in the state where
>>>  the bootloader is missing. I re-program the u-boot and the device boot
>>> it
>>>  again as I expected.
>>> The /dev/mtd0 and /dev/mtd1 are not writable on linux space in order to
>>> screwed up the uboot.
>>>
>>> Thanks,
>>>
>>> John
>>>
>>>
>>>
>>
>> Hi,
>>
>> Since you are looking for theories, here is mine...
>>
>> Assuming that you are using a NAND flash, I think it can be because of
>> read disturb in NAND array. I know that it's a very long shot but its the
>> first explanation coming to my ming.
>>
>>
>>
>
> If it is caused by read disturb errors, the number of bits of ECC you are
> using would be useful to know.  If you are using 1 bit ECC, then I wouldn't
> say that it is entirely unlikely.  The UBL is setup to read from 5
> consecutive blocks for the bootloader, so you can always program multiple
> backups, and use a similar strategy for Linux if you put the kernel in NAND
> as well.  So, I would second Caglar's theory, also assuming you are using a
> NAND device.
>
> If you can recreate the failure, I would suggest reading the data off first
> before reprogramming again.  Then you can compare it to a good image and see
> how many bits are incorrect in the failing block(s), accounting for the
> number of bits which can be corrected by ECC or reading without ECC.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100426/09b65bc7/attachment.html>

From spoulsen at css-design.com  Mon Apr 26 13:22:37 2010
From: spoulsen at css-design.com (Steve Poulsen)
Date: Mon, 26 Apr 2010 13:22:37 -0500
Subject: help for linux emif driver 2nd
In-Reply-To: <a76abd.9329.12838027f8f.Coremail.liuyue18301@163.com>
References: <a76abd.9329.12838027f8f.Coremail.liuyue18301@163.com>
Message-ID: <1272306157.16453.22.camel@ramuh>

I would recommend that you look at the 8250 driver and modify it
(duplicate) to change the memory addresses that it uses.  The memory
addresses should be changed to correspond to your EMIF.  If your EMIF,
which maps to an FPGA, has the standard UART register set, then it may
be a matter of simply changing the base address of the 8250 driver and
then making sure the arch specific setup code, configures the EMIF that
you will be using properly.

The proper flow should be:

application <-> UART driver <-> EMIF interface <-> FPGA



I suggest that 
On Mon, 2010-04-26 at 10:46 +0800, liuyue18301 wrote:
> 
> hello Guys:
>      this is second time to turn to help on the same problem.
>      i want to know is there EMIF driver in the linux? and if i want
> to send/recv data to the uarts which are expanded by FPGA ,how can i
> do it? which driver should i create or modify EMIF driver or UART
> driver?i want to write data to the EMIF in the application code,but i
> can't find the EMIF driver in the linux. confused 
>      thank you  
> 
> 
> 
> 
> ______________________________________________________________________
> ?????????????200?????
> -- 
> This message has been scanned for viruses and 
> dangerous content by MailScanner, and is 
> believed to be clean. 
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


From jtobias at viaas.com  Mon Apr 26 14:06:31 2010
From: jtobias at viaas.com (John Tobias)
Date: Mon, 26 Apr 2010 12:06:31 -0700
Subject: Possible uboot crashes
In-Reply-To: <4BD29316.6000903@linespeed.net>
References: <x2n66b2b2311004231309r3e885ab6yf9dce952cd4997af@mail.gmail.com>
	<201004240840.11552.caglarakyuz@gmail.com>
	<4BD29316.6000903@linespeed.net>
Message-ID: <l2n66b2b2311004261206ra2201319nabba8be8ffb6e36f@mail.gmail.com>

Hi Hedley,

Please read this threads. I've got the camera from Mexico and I've got the
same problem uboot/ubl.
I am going to ask the community again to get more information for what they
said to me.

john

On Fri, Apr 23, 2010 at 11:43 PM, Brian G Rhodes <bgr at linespeed.net> wrote:

> Caglar Akyuz wrote:
>
>> On Friday 23 April 2010 11:09:51 pm John Tobias wrote:
>>
>>
>>> Hello Guys,
>>>
>>> I would like to know what are the possible chances that u-boot/ubl
>>>  crashes?. I am looking for some theory/scenario that I can possibly
>>>  connect/apply the scenario to what happened to my device based on
>>> dm6446.
>>>
>>> The device has been running for a year now and for some reason it never
>>>  come back anymore. I connect through the serial port of the device and
>>>  check if there's something different. The device was in the state where
>>>  the bootloader is missing. I re-program the u-boot and the device boot
>>> it
>>>  again as I expected.
>>> The /dev/mtd0 and /dev/mtd1 are not writable on linux space in order to
>>> screwed up the uboot.
>>>
>>> Thanks,
>>>
>>> John
>>>
>>>
>>>
>>
>> Hi,
>>
>> Since you are looking for theories, here is mine...
>>
>> Assuming that you are using a NAND flash, I think it can be because of
>> read disturb in NAND array. I know that it's a very long shot but its the
>> first explanation coming to my ming.
>>
>>
>>
>
> If it is caused by read disturb errors, the number of bits of ECC you are
> using would be useful to know.  If you are using 1 bit ECC, then I wouldn't
> say that it is entirely unlikely.  The UBL is setup to read from 5
> consecutive blocks for the bootloader, so you can always program multiple
> backups, and use a similar strategy for Linux if you put the kernel in NAND
> as well.  So, I would second Caglar's theory, also assuming you are using a
> NAND device.
>
> If you can recreate the failure, I would suggest reading the data off first
> before reprogramming again.  Then you can compare it to a good image and see
> how many bits are incorrect in the failing block(s), accounting for the
> number of bits which can be corrected by ECC or reading without ECC.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100426/02aa12e8/attachment.html>

From jtobias at viaas.com  Mon Apr 26 14:40:57 2010
From: jtobias at viaas.com (John Tobias)
Date: Mon, 26 Apr 2010 12:40:57 -0700
Subject: Possible uboot crashes
In-Reply-To: <4BD29316.6000903@linespeed.net>
References: <x2n66b2b2311004231309r3e885ab6yf9dce952cd4997af@mail.gmail.com>
	<201004240840.11552.caglarakyuz@gmail.com>
	<4BD29316.6000903@linespeed.net>
Message-ID: <t2j66b2b2311004261240pcddf2564w73374114144ac7d4@mail.gmail.com>

Hi,

Sorry for the messed up. I was forwarding your email to my co-worker and I
accidentally send it to you.

Anyway, I have a few questions to follow up with you guys.

1. What are the possible cause of the "read disturb errors"?. Can you give
me a bit detail explanation?

2. I am using kernel 2.6.10 and the ECC that we are using is
NAND_ECC_HW3_512. Brian, in your suggestions (reading the failing blocks),
how I can possible access the nand blocks if am getting a constant "BOOTME
BOOTME ..." on my serial port?. Do you have any tools that I can use?

Thanks,

John






On Fri, Apr 23, 2010 at 11:43 PM, Brian G Rhodes <bgr at linespeed.net> wrote:

> Caglar Akyuz wrote:
>
>> On Friday 23 April 2010 11:09:51 pm John Tobias wrote:
>>
>>
>>> Hello Guys,
>>>
>>> I would like to know what are the possible chances that u-boot/ubl
>>>  crashes?. I am looking for some theory/scenario that I can possibly
>>>  connect/apply the scenario to what happened to my device based on
>>> dm6446.
>>>
>>> The device has been running for a year now and for some reason it never
>>>  come back anymore. I connect through the serial port of the device and
>>>  check if there's something different. The device was in the state where
>>>  the bootloader is missing. I re-program the u-boot and the device boot
>>> it
>>>  again as I expected.
>>> The /dev/mtd0 and /dev/mtd1 are not writable on linux space in order to
>>> screwed up the uboot.
>>>
>>> Thanks,
>>>
>>> John
>>>
>>>
>>>
>>
>> Hi,
>>
>> Since you are looking for theories, here is mine...
>>
>> Assuming that you are using a NAND flash, I think it can be because of
>> read disturb in NAND array. I know that it's a very long shot but its the
>> first explanation coming to my ming.
>>
>>
>>
>
> If it is caused by read disturb errors, the number of bits of ECC you are
> using would be useful to know.  If you are using 1 bit ECC, then I wouldn't
> say that it is entirely unlikely.  The UBL is setup to read from 5
> consecutive blocks for the bootloader, so you can always program multiple
> backups, and use a similar strategy for Linux if you put the kernel in NAND
> as well.  So, I would second Caglar's theory, also assuming you are using a
> NAND device.
>
> If you can recreate the failure, I would suggest reading the data off first
> before reprogramming again.  Then you can compare it to a good image and see
> how many bits are incorrect in the failing block(s), accounting for the
> number of bits which can be corrected by ECC or reading without ECC.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100426/80ba1134/attachment.html>

From albertbu at gmail.com  Mon Apr 26 14:48:15 2010
From: albertbu at gmail.com (Albert Burbea)
Date: Mon, 26 Apr 2010 21:48:15 +0200
Subject: Possible uboot crashes
In-Reply-To: <t2j66b2b2311004261240pcddf2564w73374114144ac7d4@mail.gmail.com>
References: <x2n66b2b2311004231309r3e885ab6yf9dce952cd4997af@mail.gmail.com>
	<201004240840.11552.caglarakyuz@gmail.com>
	<4BD29316.6000903@linespeed.net>
	<t2j66b2b2311004261240pcddf2564w73374114144ac7d4@mail.gmail.com>
Message-ID: <z2vb0389af41004261248pc3c26d0fo839080ada3704603@mail.gmail.com>

hi
just for my information:
How do you debug uboot ??
Albert

On Mon, Apr 26, 2010 at 9:40 PM, John Tobias <jtobias at viaas.com> wrote:

> Hi,
>
> Sorry for the messed up. I was forwarding your email to my co-worker and I
> accidentally send it to you.
>
> Anyway, I have a few questions to follow up with you guys.
>
> 1. What are the possible cause of the "read disturb errors"?. Can you give
> me a bit detail explanation?
>
> 2. I am using kernel 2.6.10 and the ECC that we are using is
> NAND_ECC_HW3_512. Brian, in your suggestions (reading the failing blocks),
> how I can possible access the nand blocks if am getting a constant "BOOTME
> BOOTME ..." on my serial port?. Do you have any tools that I can use?
>
> Thanks,
>
> John
>
>
>
>
>
>
> On Fri, Apr 23, 2010 at 11:43 PM, Brian G Rhodes <bgr at linespeed.net>wrote:
>
>>  Caglar Akyuz wrote:
>>
>>> On Friday 23 April 2010 11:09:51 pm John Tobias wrote:
>>>
>>>
>>>> Hello Guys,
>>>>
>>>> I would like to know what are the possible chances that u-boot/ubl
>>>>  crashes?. I am looking for some theory/scenario that I can possibly
>>>>  connect/apply the scenario to what happened to my device based on
>>>> dm6446.
>>>>
>>>> The device has been running for a year now and for some reason it never
>>>>  come back anymore. I connect through the serial port of the device and
>>>>  check if there's something different. The device was in the state where
>>>>  the bootloader is missing. I re-program the u-boot and the device boot
>>>> it
>>>>  again as I expected.
>>>> The /dev/mtd0 and /dev/mtd1 are not writable on linux space in order to
>>>> screwed up the uboot.
>>>>
>>>> Thanks,
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>
>>> Hi,
>>>
>>> Since you are looking for theories, here is mine...
>>>
>>> Assuming that you are using a NAND flash, I think it can be because of
>>> read disturb in NAND array. I know that it's a very long shot but its the
>>> first explanation coming to my ming.
>>>
>>>
>>>
>>
>> If it is caused by read disturb errors, the number of bits of ECC you are
>> using would be useful to know.  If you are using 1 bit ECC, then I wouldn't
>> say that it is entirely unlikely.  The UBL is setup to read from 5
>> consecutive blocks for the bootloader, so you can always program multiple
>> backups, and use a similar strategy for Linux if you put the kernel in NAND
>> as well.  So, I would second Caglar's theory, also assuming you are using a
>> NAND device.
>>
>> If you can recreate the failure, I would suggest reading the data off
>> first before reprogramming again.  Then you can compare it to a good image
>> and see how many bits are incorrect in the failing block(s), accounting for
>> the number of bits which can be corrected by ECC or reading without ECC.
>>
>
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>


-- 
Albert Burbea
Harishonim 8
Ramat Gan 52502, Israel
Tel/Fax + 972-3-7526016
Mobile: +972-52-3541842
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100426/f75ac171/attachment-0001.html>

From jtobias at viaas.com  Mon Apr 26 20:19:17 2010
From: jtobias at viaas.com (John Tobias)
Date: Mon, 26 Apr 2010 18:19:17 -0700
Subject: Writing UBL on blocks 2 - 5
Message-ID: <h2j66b2b2311004261819l5cc28bcfg6abc138677202417@mail.gmail.com>

Hi Guys,

1. The DVFlasher that I am using only works on the first UBL block. Is there
other utility that I can use to program the blocks 2 - 5?.

2. In Linux userspace, what utility did you use to check the CRC validity of
UBL data on blocks 1-5?.

3. Lastly, what utility did you use in linux userspace to re-program the UBL
block 1-5 just incase they messed up?. I do believe, using mtdwrite is not
possible due to CRC incompatibility.

Thanks,

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100426/fe5727b9/attachment.html>

From nsekhar at ti.com  Mon Apr 26 23:30:28 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 27 Apr 2010 10:00:28 +0530
Subject: [PATCH v4 01/13] Davinci: generalized debug macros
In-Reply-To: <4BD5A583.3040002@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E6B13CC2@dbde02.ent.ti.com>
	<4BD5A583.3040002@ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E6B1438E@dbde02.ent.ti.com>

Hi Cyril,

On Mon, Apr 26, 2010 at 20:08:59, Chemparathy, Cyril wrote:
> Hi Sekhar,
>
> Thanks for the review.  Please see my comments below...
>
> /* Block 1 - UART phys and virt already configured locally */
>
> [...]
> >> +             /* Use davinci_uart_phys/virt if already configured */
> >> +10:          mrc     p15, 0, \rx, c1, c0
> >> +             tst     \rx, #1                 @ MMU enabled?
> >> +             ldreq   \rx, =__virt_to_phys(davinci_uart_phys)
> >> +             ldrne   \rx, =davinci_uart_virt
> >> +             ldr     \rx, [\rx]
> >> +             cmp     \rx, #0                 @ is port configured?
> >> +             bne     99f                     @ already configured
>
> /* Block 2 - local config missing, copy DAVINCI_UART_INFO */
>
> [...]
> >> +             /* Copy uart phys address from decompressor uart info */
> >>               mrc     p15, 0, \rx, c1, c0
> >>               tst     \rx, #1                 @ MMU enabled?
> >> +             ldreq   \tmp, =__virt_to_phys(davinci_uart_phys)
> >> +             ldrne   \tmp, =davinci_uart_phys
> >> +             ldreq   \rx, =DAVINCI_UART_INFO
> >> +             ldrne   \rx, =__phys_to_virt(DAVINCI_UART_INFO)
> >> +             ldr     \rx, [\rx, #0]
> >> +             str     \rx, [\tmp]
>
> /* Block 3 - local config missing, copy DAVINCI_UART_INFO + 4 */
>
> [...]
> >> +             mrc     p15, 0, \rx, c1, c0
> >> +             tst     \rx, #1                 @ MMU enabled?
> >> +             ldreq   \tmp, =__virt_to_phys(davinci_uart_virt)
> >> +             ldrne   \tmp, =davinci_uart_virt
> >> +             ldreq   \rx, =DAVINCI_UART_INFO
> >> +             ldrne   \rx, =__phys_to_virt(DAVINCI_UART_INFO)
> >> +             ldr     \rx, [\rx, #4]
> >> +             str     \rx, [\tmp]
> >
> > You should be able to combine the code chunks into
> > one by using ldr/str{cond} to configure either the
> > virtual or physical base depending on whether MMU
> > is enabled on not. No need to configure both at the
> > same time.
>
> The first time that the addruart macro is used, it copies the phys and
> virt base addresses from the DAVINCI_UART_INFO area.

Yes, this is what I was objecting to. addruart _may_ be invoked while mmu
is off or on. Not necessarily in both cases. So, you can decide to copy
from DAVINCI_UART_INFO "Just in time".

Even if you decide to copy both the first time, there should be no need
to re-run mrc since the condition flag isn't disturbed by any of the
instructions that follow.

> Ouch.  I wish we had a few more usable registers to play with here,
> because that would have helped consolidate blocks 2 and 3 (above) into a
> single piece of streamlined code.
>
> Since the register allocation in early boot is pretty tight, I couldn't
> take the liberty of clobbering anything beyond the macro's parameter
> list.  That said, if there is a register that we are free to clobber,
> I'd gladly use it to condense the code down a bit.  Any thoughts?

At the least I would think the duplicate mrc (in blocks 2 and 3) can go.

Thanks,
Sekhar


From nsekhar at ti.com  Mon Apr 26 23:35:39 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 27 Apr 2010 10:05:39 +0530
Subject: [PATCH v4 11/13] Davinci: tnetv107x soc support
In-Reply-To: <4BD5A93D.2080102@ti.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
	<1272045424-19240-10-git-send-email-cyril@ti.com>
	<1272045424-19240-11-git-send-email-cyril@ti.com>
	<1272045424-19240-12-git-send-email-cyril@ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E6B13DBB@dbde02.ent.ti.com>
	<4BD5A93D.2080102@ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E6B14399@dbde02.ent.ti.com>

On Mon, Apr 26, 2010 at 20:24:53, Chemparathy, Cyril wrote:
> Hi Sekhar,
>
> [...]
> >> +/*
> >> + * TNETV107X platforms do not use the static mappings from Davinci
> >> + * IO_PHYS/IO_VIRT. This SOC's interesting MMRs are at different addresses,
> >> + * and changing IO_PHYS would break away from existing Davinci SOCs.
> >> + *
> >> + * The primary impact of the current model is that IO_ADDRESS() is not to be
> >> + * used to map registers on TNETV107X. With the exception of early boot code
> >> + * in tnetv107x_init() (where fixed maps are necessary), all other pieces of
> >> + * code absolutely _must_ use ioremap().
> >> + *
> >> + * 1.        The first section in here is specifically for edma, even through the
> >> + *   edma driver code properly ioremap()s its register space.  This is
> >> + *   because the edma MMRs on tnetv107x unfortunately fall within the
> >> + *   davinci IO_PHYS - (IO_PHYS + IO_SIZE) range, and therefore the edma
> >> + *   driver's ioremap() gets subverted by davinci_ioremap(). Yikes!
> >
> > I had pointed this earlier, but don't remember a follow-up discussion.
> >
> > Why not just redefine IO_PHYS for this SoC?
>
> I thought I'd responded in [1].

Ah right. I guess I missed it.

> But this does bring up a good point.  Now that ioremap interception no
> longer remaps per IO_PHYS/IO_VIRT, the edma ioremap() should operate
> correctly even without this special iotable entry.  I will get rid of
> this in the next  rev.

Thanks! The hack was quite unintuitive to me, so glad to see its back.

Regards,
Sekhar

From nsekhar at ti.com  Mon Apr 26 23:37:40 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 27 Apr 2010 10:07:40 +0530
Subject: OMAP-L138 X11 on S-Video
In-Reply-To: <n2t2b3771721004260335rd1877313ycf78863daa73d4ef@mail.gmail.com>
References: <z2y2b3771721004232212nea77d4bblc66dd71c8c09dc8a@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E6B13ED3@dbde02.ent.ti.com>
	<n2t2b3771721004260335rd1877313ycf78863daa73d4ef@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E6B1439E@dbde02.ent.ti.com>

On Mon, Apr 26, 2010 at 16:05:03, Bharathi Subramanian wrote:
> On Mon, Apr 26, 2010 at 2:14 PM, Nori, Sekhar <nsekhar at ti.com> wrote:
>
> >> In OMAP-L138 EVM, Is it possible to use the S-Video out as default
> >> output device for X11.  Now I am able to access it using VPIF example
> >> program. In beagle board, I used the S-Video out for X11 output. I am
> >> thinking of using  the OMAP-L138 S-Video output also in the same
> >> fashion. Please throw some light on this topic.
> >
> > X11 requires fbdev and VPIF supports v4l2 only.
> > It is not possible to get X11 output on OMAP-L138
> > S-Video. It is useful for streaming video only.
> > For X11 you can consider using the LCD interface
> > instead.
>
> What about DirectFB? Will it help in this case? Any body tried in that
> angle? Plz share your experience.

AFAIK, directFB builds on the basic fb support in kernel. So this
would not be possible as well.

Thanks,
Sekhar

From bgr at linespeed.net  Mon Apr 26 23:56:45 2010
From: bgr at linespeed.net (Brian G Rhodes)
Date: Mon, 26 Apr 2010 23:56:45 -0500
Subject: Possible uboot crashes
In-Reply-To: <t2j66b2b2311004261240pcddf2564w73374114144ac7d4@mail.gmail.com>
References: <x2n66b2b2311004231309r3e885ab6yf9dce952cd4997af@mail.gmail.com>	
	<201004240840.11552.caglarakyuz@gmail.com>	
	<4BD29316.6000903@linespeed.net>
	<t2j66b2b2311004261240pcddf2564w73374114144ac7d4@mail.gmail.com>
Message-ID: <4BD66E8D.1070804@linespeed.net>

John Tobias wrote:
> Hi,
>
> Sorry for the messed up. I was forwarding your email to my co-worker 
> and I accidentally send it to you.
>
> Anyway, I have a few questions to follow up with you guys.
>
> 1. What are the possible cause of the "read disturb errors"?. Can you 
> give me a bit detail explanation?

You will find information on read disturb in the datasheet for your NAND 
part.   Here is an excerpt from a Micron appnote.

*From Micron App note: 
**_http://download.micron.com/pdf/technotes/nand/tn2917.pdf_*

*Read Disturb:* A read disturb error occurs when one or more bits are 
changed from ?1?
to ?0? during a READ operation. Read disturb errors occur within the 
block being read,
but on a page or pages other than the page being read. Performing a high 
number
(hundreds of thousands or millions) of READ operations on individual 
pages before an
ERASE command for the block containing those pages can exacerbate this 
error.
To recover from this type of error, erase the block where the error 
occurred and reprogram
the data to that block.

------------------------------------------------------------------------------------ 


Accessing this code repeatedly, without erasing and
reprogramming the data, causes errors to occur over time (see ?Temporary 
Failures? on
page 2). Many factors influence the point at which errors begin to 
appear, including how
often the same physical area of the NAND Flash device is read and the 
extent to which
ECC is used to maintain data integrity in the system.

Also see:

_http://www.edn.com/blog/980000298/post/1670047767.html_

>
> 2. I am using kernel 2.6.10 and the ECC that we are using is 
> NAND_ECC_HW3_512. Brian, in your suggestions (reading the failing 
> blocks), how I can possible access the nand blocks if am getting a 
> constant "BOOTME BOOTME ..." on my serial port?. Do you have any tools 
> that I can use?

You can modify DVFlasher to read blocks from NAND and output over 
serial.  You are basically adding a command to ubl.  Look at 
DVFlasher.cs and uartboot.c.   It is likely more busywork than not, but 
it's nice to verify.  There may be better tools than DVFlasher as well 
out there, but I am not familiar with any of them.


From bgr at linespeed.net  Tue Apr 27 00:20:14 2010
From: bgr at linespeed.net (Brian G Rhodes)
Date: Tue, 27 Apr 2010 00:20:14 -0500
Subject: Writing UBL on blocks 2 - 5
In-Reply-To: <h2j66b2b2311004261819l5cc28bcfg6abc138677202417@mail.gmail.com>
References: <h2j66b2b2311004261819l5cc28bcfg6abc138677202417@mail.gmail.com>
Message-ID: <4BD6740E.1040400@linespeed.net>

John Tobias wrote:
> Hi Guys,
>
> 1. The DVFlasher that I am using only works on the first UBL block. Is 
> there other utility that I can use to program the blocks 2 - 5?.

DVFlasher does not support it directly, but you can modify ubl to write 
as many of the blocks as you want.  From uartboot.c.

        nandBoot.page = 1;
        // The block is always block is always 1 (to start with) for the 
UBL header
        nandBoot.block = START_UBL_BLOCK_NUM;
        // This field doesn't matter for the UBL header
        nandBoot.ldAddress = 0;
   
        // Write header to page 0 of block 1(or up to block 5)
        // Write the UBL to the same block, starting at page 1 (since 
blocks are 16k)
        UARTSendStringCRLF("Writing UBL to NAND flash");
        if (NAND_WriteHeaderAndData(&nandBoot, (uint8_t *) 
ackHeader.binAddr) != E_PASS)
            goto UART_tryAgain;

        // Send SENDAPP command
        UARTSendStringNULL("SENDAPP");

        // Get the application header and data
        if (UARTGetHeaderAndData(&ackHeader) != E_PASS)
        {
            goto UART_tryAgain;
        }

Write blocks from START_UBL_BLOCK_NUM to END_UBL_BLOCK_NUM. See 
nandBoot.block = START_UBL_BLOCK_NUM;.

You can do something similar with START_APP_BLOCK_NUM and write extra 
copies.  NAND_Copy already supports looking for a valid application in 
blocks 6-50.

>
> 2. In Linux userspace, what utility did you use to check the CRC 
> validity of UBL data on blocks 1-5?.

I have not ever done this from Linux.  This would require the Linux 
davinci NAND driver and UBL sharing the same layout.

>
> 3. Lastly, what utility did you use in linux userspace to re-program 
> the UBL block 1-5 just incase they messed up?. I do believe, using 
> mtdwrite is not possible due to CRC incompatibility.

Ditto.

>
> Thanks,
>
> John
>   

From nyhetsbrev at dokumera.anp.se  Tue Apr 27 01:25:36 2010
From: nyhetsbrev at dokumera.anp.se (DokuMera Nyhetsbrev)
Date: Tue, 27 Apr 2010 08:25:36 +0200
Subject: =?iso-8859-1?Q?Anst=E4llning?=
Message-ID: <1256585399.951@dokumera.anp.se>


Om du har problem med att l?sa detta e-postmeddelande, klicka h?r (http://www.anp.se/newsletter/660146/44405D4074454B5C447043475843) f?r en webb-version.


V?rt nyhetsbrev skickas automatiskt till v?ra kunder och intressenter. Vill du inte ha detta nyhetsbrev fram?ver, klicka h?r f?r att avprenumerera (http://www.anp.se/oa/660146/44405D4074454B5C447043475843).


Nyhetsbrev nr 16/2010Detta nyhetsbrev ?r skickat till: davinci-linux-open-source at linux.davincidsp.com


 (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se&from=173902333&prefix=dm) (http://www.anp.se/taf/660146/44405D4074454B5C447043475843)  (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_newsletters.asp&from=173902333&prefix=dm)  (http://www.anp.se/newsletter.asp?sqid=660146&sid=44405D4074454B5C447043475843&print=true)


Anst?llning

F?r att en anst?llning skall vara giltig skall ett anst?llningsavtal vara uppr?ttat mellan den anst?llde och f?retaget. Ett avtal tr?ffas i samma stund som arbetstagaren accepterar ett erbjudande om jobb fr?n arbetsgivarens sida, muntliga avtal ?r s?ledes g?llande. Fr?n b?de arbetsgivaren och arbetstagarens sida ?r det dock viktigt att ?ven ett skriftligt avtal uppr?ttas eftersom det d? finns ett bevis p? vilka villkor som g?ller f?r anst?llningen. 

Vid uppr?ttandet av ett anst?llningsavtal finns det en hel del att ta h?nsyn till. Vad som g?ller f?r en anst?llning regleras dels i lag men ocks? av kollektivavtal om s?dant finns uppr?ttat. Vissa anst?llningsvilkor som regleras i lag kan avtalas bort s.k. dispositiva lagar, medan andra ?r indispositiva vilket inneb?r att det ?r lagen som g?ller framf?r det som avtalats.

Nu n?r vi b?rjar n?rma oss sommaren kan det ocks? vara h?g tid att b?rja t?nka p? vad som g?ller n?r du anst?ller n?gon f?r en s?song dvs. tidsbegr?nsad anst?llning. 

Hos DokuMera hittar du bland annat Checklista f?r anst?llningsavtal som hj?lper dig som chef att uppr?tta ett anst?llningsavtal.


Veckans dokument

Anst?llningsavtal >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/aa01_anstallningsavtal_tillsvidareanstallning_370_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Checklista anst?llningsavtal >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/aa00_checklista_anstallningsavtal_787_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Arbetstidsschema >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/arbetstidsschema_1089_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Tidrapport >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/tidrapport_00_alla_manader_1099_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

L?neutbetalningsschema >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/loneutbetalningsschema_manadsvis_1107_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm)

Semesterplanering >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/semesterplanering_2006_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm) 

Ord fr?n kunder

Reinhold Rutks, VD

Swedish Electro Static AB

"F?retagspaketet bidrar till n?gon slags allm?nbildning och jag har det ocks? som informationsk?lla."

(http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/foretagspaketet_1321_dc.html&from=173902333&prefix=dm) (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_atq_ppdviewer.asp&from=173902333&prefix=dm) (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/styckvisa_dokumentmallar_1330_dc.html&from=173902333&prefix=dm)

 (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_contactusmessage.asp&from=173902333&prefix=dm)

F?r en kostnadsfri exklusiv presentation av hur DokuMera kan spara tiotusentals kronor ?t just mitt f?retag.
Givetvis ?r du varmt v?lkommen att ringa oss p? 08-664 04 50.

Inneh?llet i nyhetsbrev ska inte tolkas som ett ?tagande fr?n DokuMeras sida. Informationen s?nds ut i befintligt skick, utan garantier och digitala signaturer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100427/12954cd0/attachment-0001.html>

From kieranbingham at gmail.com  Tue Apr 27 06:28:06 2010
From: kieranbingham at gmail.com (Kieran Bingham)
Date: Tue, 27 Apr 2010 12:28:06 +0100
Subject: cppi_dma.c : channel_abort
Message-ID: <4BD6CA46.7020605@gmail.com>

Hi Guys,

We're running a DM365, with Montavista 2.6.18_pro500 kernel.

With a USB Flash drive, and a USB Connected DVD Drive, we're 
experiencing kernel lockups

Having connected the JTAG, and stepping through the assembly, it would 
appear that it is cycling through one of the two while loops in the 
function channel_abort, in drivers/usb/musb/cppi_dma.c

Unfortunately its doing this with interrupts off!! and it never leaves!

Has anyone else experienced Kernel Lockups with USB devices connected ?
--
Regards
Kieran Bingham

From mohameeed2010 at hotmail.com  Tue Apr 27 07:37:52 2010
From: mohameeed2010 at hotmail.com (Mohamed AbdElwahed)
Date: Tue, 27 Apr 2010 12:37:52 +0000
Subject: Compile Error
In-Reply-To: <mailman.1871.1271851892.11996.davinci-linux-open-source@linux.davincidsp.com>
References: <mailman.1871.1271851892.11996.davinci-linux-open-source@linux.davincidsp.com>
Message-ID: <COL106-W24DE8402A8629409CF4188AB030@phx.gbl>



I use DM6446 and  i implemented my own codec and i success to compile(the CGT is version 6.1.12) and run it.

but when i edit the "usr.bld" file by adding this options "-z -l forder.cmd" to the compiler options, it fail with the below error.

 

 

----------------------------------------------------------------------------

----------------------------------------------------------------------------

 

 

# generating interfaces for package codecs.decode_slice_h264 (because package/package.xdc.xml is older than package.xdc) ...
/opt/xdc_3_05/xs -Dxdc.path="/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264/../..;/opt/codec_engine_2_10/cetools/packages;/opt/codec_engine_2_10/packages;/opt/bios_5_32_02/packages;/opt/xdc_3_05/packages;../.." -Dxdc.root=/opt/xdc_3_05 -Dxdc.hostOS=Linux -Dconfig.importPath=".;/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264/../..;/opt/codec_engine_2_10/cetools/packages;/opt/codec_engine_2_10/packages;/opt/bios_5_32_02/packages;/opt/xdc_3_05/packages;../..;/opt/xdc_3_05;/opt/xdc_3_05/etc" -Dxdc.bld.targets="" -DTOOLS= -f xdc/services/intern/cmd/build.xs -m package/package.xdc.dep -i package/package.xdc.inc package.xdc
translating DECODE_SLICE_H264
.interfaces files complete: Tue Apr 27 14:04:08 EET 2010.
======== .libraries [/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264] ========
rm -f package/lib/lib/decode_slice_h264/package/package_codecs.decode_slice_h264.o64P
#
# cl64P package/package_codecs.decode_slice_h264.c ...
/opt/TI/C6000CGT6.1.13/bin/cl6x -c -mt -mo --opt_for_speed=5 -O3 --program_level_compile --silicon_version=6446 --keep_asm --opt_for_speed=5 -z -l forder.cmd -mv64p -eo.o64P -ea.s64P -D__xdc_bld_pkg_c__=package.bld.c -Dxdc_target_name__=C64P -Dxdc_target_types__=ti/targets/std.h -Dxdc_bld__profile_release -Dxdc_bld__vers_1_0_6_1_13 -o2 -I. -I/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264/../.. -I/opt/codec_engine_2_10/cetools/packages -I/opt/codec_engine_2_10/packages -I/opt/bios_5_32_02/packages -I/opt/xdc_3_05/packages -I../.. -I/opt/TI/C6000CGT6.1.13/include -fs=./package/lib/lib/decode_slice_h264/package -fr=./package/lib/lib/decode_slice_h264/package -fc package/package_codecs.decode_slice_h264.c
>> WARNING: invalid linker option -D__xdc_bld_pkg_c__=package.bld.c (ignored)
>> WARNING: invalid linker option -Dxdc_target_name__=C64P (ignored)
>> WARNING: invalid linker option -Dxdc_target_types__=ti/targets/std.h (ignored)
>> WARNING: invalid linker option -Dxdc_bld__profile_release (ignored)
>> WARNING: invalid linker option -Dxdc_bld__vers_1_0_6_1_13 (ignored)
ERROR: argument to option -f ("value") is out of range
gmake[1]: *** [package/lib/lib/decode_slice_h264/package/package_codecs.decode_slice_h264.o64P] Error 1
gmake: *** [/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264,.libraries] Error 2
make[2]: *** [all] Error 2
make[2]: Leaving directory `/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs'
make: *** [all] Error 2

 

 

----------------------------------------------------------------------------

----------------------------------------------------------------------------

Any help is highly appreciated

Mohamed AbdElwahed Ibrahim 


 

 



 

> From: davinci-linux-open-source-request at linux.davincidsp.com
> Subject: Davinci-linux-open-source Digest, Vol 52, Issue 65
> To: davinci-linux-open-source at linux.davincidsp.com
> Date: Wed, 21 Apr 2010 07:11:32 -0500
> 
> Send Davinci-linux-open-source mailing list submissions to
> davinci-linux-open-source at linux.davincidsp.com
> 
> 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
> davinci-linux-open-source-request at linux.davincidsp.com
> 
> You can reach the person managing the list at
> davinci-linux-open-source-owner at linux.davincidsp.com
> 
> 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. Re: [PATCH 4/4] DM365: Add platform resource management
> (Kevin Hilman)
> 2. Re: [PATCH 2/4] DM365: Allow use of GPIO64_57 (Kevin Hilman)
> 3. RE: [PATCH 4/4] DM365: Add platform resource management
> (Koeller, T.)
> 4. RE: [PATCH 1/4] DM365: Make all SPI units SPI0..SPI4
> available (Koeller, T.)
> 5. RE: [PATCH 4/4] DM365: Add platform resource management
> (Nori, Sekhar)
> 6. RE: [PATCH 4/4] DM365: Add platform resource management
> (Koeller, T.)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 20 Apr 2010 15:20:37 -0700
> From: Kevin Hilman <khilman at deeprootsystems.com>
> To: thomas.koeller at baslerweb.com
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Subject: Re: [PATCH 4/4] DM365: Add platform resource management
> Message-ID: <87633lepfu.fsf at deeprootsystems.com>
> Content-Type: text/plain; charset=us-ascii
> 
> thomas.koeller at baslerweb.com writes:
> 
> > From: Thomas Koeller <thomas.koeller at baslerweb.com>
> >
> > Keeping track of resource assignments greatly simplifies
> > the task of writing board support code. Many drivers for
> > DaVinci peripherals were using resources that had never
> > been allocated, with the notable exception of memory
> > resources.
> >
> > Non-conflicting resource assignment is a responsibility
> > of the bus the devices are on, in this case, the platform bus.
> >
> > The resource management scheme implemented by this patch is not
> > perfect. The SoC code really has no business managing resources,
> > it should only provide them to the platform (board support) code.
> > The board support is the only place where information about the
> > intended use of the various hardware resources is available.
> 
> Actually, the driver is the place where the resources are used and
> therefore where they should be reserved and released. This patch
> removes this from the drivers and puts it in SoC code which I don't
> like.
> 
> There are really two main things going on here that I see:
> 
> 1. add parent resources (cfg, irq, dma, etc.)
> 2. move resource reservation from drivers to SoC code
> 
> It's primarily 2 that I object to.
> 
> While I think (1) may be helpful, if we're going to do it, we should
> do it throughout all of mach-davinci/*.
> 
> Kevin
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 20 Apr 2010 15:21:05 -0700
> From: Kevin Hilman <khilman at deeprootsystems.com>
> To: thomas.koeller at baslerweb.com
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Subject: Re: [PATCH 2/4] DM365: Allow use of GPIO64_57
> Message-ID: <87zl0xdaum.fsf at deeprootsystems.com>
> Content-Type: text/plain; charset=us-ascii
> 
> thomas.koeller at baslerweb.com writes:
> 
> > From: Thomas Koeller <thomas.koeller at baslerweb.com>
> >
> > Extended the MUX configuration to allow use of GPIO
> > terminals 64..57.
> >
> > Signed-off-by: Thomas Koeller <thomas.koeller at baslerweb.com>
> 
> Thanks, applying and queuing for 2.6.35 in davinci-next branch.
> 
> Kevin
> 
> > ---
> > arch/arm/mach-davinci/dm365.c | 1 +
> > arch/arm/mach-davinci/include/mach/mux.h | 1 +
> > 2 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> > index 023d708..0813dce 100644
> > --- a/arch/arm/mach-davinci/dm365.c
> > +++ b/arch/arm/mach-davinci/dm365.c
> > @@ -580,6 +580,7 @@ MUX_CFG(DM365, SPI4_SDENA1, 4, 16, 3, 2, false)
> > MUX_CFG(DM365, GPIO20, 3, 21, 3, 0, false)
> > MUX_CFG(DM365, GPIO33, 4, 12, 3, 0, false)
> > MUX_CFG(DM365, GPIO40, 4, 26, 3, 0, false)
> > +MUX_CFG(DM365, GPIO64_57, 2, 6, 1, 0, false)
> > 
> > MUX_CFG(DM365, VOUT_FIELD, 1, 18, 3, 1, false)
> > MUX_CFG(DM365, VOUT_FIELD_G81, 1, 18, 3, 0, false)
> > diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h
> > index 05e35fa..d6c6921 100644
> > --- a/arch/arm/mach-davinci/include/mach/mux.h
> > +++ b/arch/arm/mach-davinci/include/mach/mux.h
> > @@ -295,6 +295,7 @@ enum davinci_dm365_index {
> > DM365_GPIO20,
> > DM365_GPIO33,
> > DM365_GPIO40,
> > + DM365_GPIO64_57,
> > 
> > /* Video */
> > DM365_VOUT_FIELD,
> > -- 
> > 1.7.0.3
> >
> > _______________________________________________
> > Davinci-linux-open-source mailing list
> > Davinci-linux-open-source at linux.davincidsp.com
> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 21 Apr 2010 10:13:55 +0200
> From: "Koeller, T." <Thomas.Koeller at baslerweb.com>
> To: "Kevin Hilman" <khilman at deeprootsystems.com>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Subject: RE: [PATCH 4/4] DM365: Add platform resource management
> Message-ID:
> <C5A8FDEFF7647F4C9CB927D7DEB307730E5309C7 at ahr075s.basler.corp>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi Kevin,
> 
> > 
> > Actually, the driver is the place where the resources are used and
> > therefore where they should be reserved and released. This patch
> > removes this from the drivers and puts it in SoC code which I don't
> > like.
> > 
> > There are really two main things going on here that I see:
> > 
> > 1. add parent resources (cfg, irq, dma, etc.)
> > 2. move resource reservation from drivers to SoC code
> > 
> > It's primarily 2 that I object to.
> > 
> > While I think (1) may be helpful, if we're going to do it, we should
> > do it throughout all of mach-davinci/*.
> 
> Here I do not quite agree with your view. In general, resource managment
> is about avoiding conflicts. This means that it must be done in a
> place where the resource requirements of all devices are known, and this
> is the bus, not the individual drivers. This is more obvious when
> dealing with buses that enumerate their devices and collect their
> resource requirements in order to make intelligent decisions. The
> platform bus has been invented to extend this concept to devices that
> are not really on such a bus.
> 
> For platform devices, resources are set up by the platform and passed to
> the drivers via platform devices. At this point, the decision about which
> resource is going to be used by a particular driver has already been made,
> and nothing is gained by defering the actual allocation. Resource
> allocation in the driver is only possible for resources for which
> global root nodes exist (IO and MEMORY addresses). All other kinds of
> resources cannot be allocated by drivers because these do not (and should
> not) know about the root resource nodes in the platform. Consequently,
> you see lots of drivers that do allocate memory resources, but ignore
> all the others.
> 
> Therefore, if a platform wanted to do proper resource management covering
> all kinds of resources, it would have to treat memory and io resources
> specially, relying on the driver to do the actual allocation and implement
> resource management only for the remaining resource types, which is
> certainly ugly.
> 
> Thanks for your comments!
> 
> Thomas
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Wed, 21 Apr 2010 10:21:37 +0200
> From: "Koeller, T." <Thomas.Koeller at baslerweb.com>
> To: "Kevin Hilman" <khilman at deeprootsystems.com>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Subject: RE: [PATCH 1/4] DM365: Make all SPI units SPI0..SPI4
> available
> Message-ID:
> <C5A8FDEFF7647F4C9CB927D7DEB307730E5309D5 at ahr075s.basler.corp>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi Kevin,
> 
> > > --- /dev/null
> > > +++ b/arch/arm/mach-davinci/board_dm365_evm_resources.h
> > > @@ -0,0 +1,17 @@
> > > +#ifndef _DAVINCI_EVM_RESOURCES_H
> > > +#define _DAVINCI_EVM_RESOURCES_H
> > > +
> > > +#include <mach/irqs.h>
> > > +#include <mach/edma.h>
> > > +
> > > +/* IRQs */
> > > +#define IRQ_SPI0 IRQ_DM365_SPIINT0_0
> > 
> > This can be dropped, and IRQ_DM365_SPIINT0_0 used directly.
> > 
> > > +/* DMA channels */
> > > +#define DMA_CHAN_SPI0_TX 16
> > > +#define DMA_CHAN_SPI0_RX 17
> > 
> > These are SoC common, should be in <soc>.h
> > 
> > > +/* DMA event queues */
> > > +#define DMA_EVQ_SPI0 EVENTQ_3
> > 
> > This can be dropped, and EVNETQ_3 used directly.
> > 
> > > +#endif /* _DAVINCI_EVM_RESOURCES_H */
> > 
> > I think it's best to just drop this file and these #defines altogether
> > and just use the values directly in the board files. It will make the
> > board files a bit more readable and avoid a level of indirection.
> 
> I thought it a good idea to have central point where all those
> resources (I am using this term in an informal way here) are defined
> in terms of their intended use, making it easier to spot
> possible conflicts.
> 
> > > diff --git a/arch/arm/mach-davinci/dm365.c 
> > b/arch/arm/mach-davinci/dm365.c
> > > index ed6c9c7..023d708 100644
> > > --- a/arch/arm/mach-davinci/dm365.c
> > > +++ b/arch/arm/mach-davinci/dm365.c
> > > @@ -616,72 +616,256 @@ EVT_CFG(DM365, EVT3_ASP_RX, 
> > 1, 1, 0, false)
> > > #endif
> > > };
> > > 
> > > -static u64 dm365_spi0_dma_mask = DMA_BIT_MASK(32);
> > > +static u64 dm365_spi_dma_mask = DMA_BIT_MASK(32);
> > > 
> > > -static struct davinci_spi_platform_data dm365_spi0_pdata = {
> > > - .version = SPI_VERSION_1,
> > > - .num_chipselect = 2,
> > > - .clk_internal = 1,
> > > - .cs_hold = 1,
> > > - .intr_level = 0,
> > > - .poll_mode = 1, /* 0 -> interrupt mode 1-> 
> > polling mode */
> > > - .use_dma = 1, /* when 1, value in poll_mode 
> > is ignored */
> > > - .c2tdelay = 0,
> > > - .t2cdelay = 0,
> > > +enum dm365_spi_resource_index {
> > > + spirsrc_iomem,
> > > + spirsrc_irq,
> > > + spirsrc_rxdma,
> > > + spirsrc_txdma,
> > > + spirsrc_evqdma
> > > };
> > >
> > > -static struct resource dm365_spi0_resources[] = {
> > > +
> > > +static struct resource dm365_spi_resources[spirsrc_evqdma 
> > + 1][5] = {
> > > {
> > > - .start = 0x01c66000,
> > > - .end = 0x01c667ff,
> > > - .flags = IORESOURCE_MEM,
> > > + [spirsrc_iomem] = {
> > > + .start = 0x01c66000,
> > > + .end = 0x01c667ff,
> > > + .flags = IORESOURCE_MEM,
> > > + },
> > > + [spirsrc_irq] = {
> > > + .flags = IORESOURCE_IRQ,
> > > + },
> > > + [spirsrc_rxdma] = {
> > > + .flags = IORESOURCE_DMA | 
> > IORESOURCE_DMA_RX_CHAN,
> > > + },
> > > + [spirsrc_txdma] = {
> > > + .flags = IORESOURCE_DMA | 
> > IORESOURCE_DMA_TX_CHAN,
> > > + },
> > > + [spirsrc_evqdma] = {
> > > + .flags = IORESOURCE_DMA | 
> > IORESOURCE_DMA_EVENT_Q,
> > > + }
> > > },
> > > {
> > > - .start = IRQ_DM365_SPIINT0_0,
> > > - .flags = IORESOURCE_IRQ,
> > > + [spirsrc_iomem] = {
> > > + .start = 0x01c66800,
> > > + .end = 0x01c66fff,
> > > + .flags = IORESOURCE_MEM,
> > > + },
> > > + [spirsrc_irq] = {
> > > + .flags = IORESOURCE_IRQ,
> > > + },
> > > + [spirsrc_rxdma] = {
> > > + .flags = IORESOURCE_DMA | 
> > IORESOURCE_DMA_RX_CHAN,
> > > + },
> > > + [spirsrc_txdma] = {
> > > + .flags = IORESOURCE_DMA | 
> > IORESOURCE_DMA_TX_CHAN,
> > > + },
> > > + [spirsrc_evqdma] = {
> > > + .flags = IORESOURCE_DMA | 
> > IORESOURCE_DMA_EVENT_Q,
> > > + }
> > > },
> > > {
> > > - .start = 17,
> > > - .flags = IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
> > > + [spirsrc_iomem] = {
> > > + .start = 0x01c67800,
> > > + .end = 0x01c67fff,
> > > + .flags = IORESOURCE_MEM,
> > > + },
> > > + [spirsrc_irq] = {
> > > + .flags = IORESOURCE_IRQ,
> > > + },
> > > + [spirsrc_rxdma] = {
> > > + .flags = IORESOURCE_DMA | 
> > IORESOURCE_DMA_RX_CHAN,
> > > + },
> > > + [spirsrc_txdma] = {
> > > + .flags = IORESOURCE_DMA | 
> > IORESOURCE_DMA_TX_CHAN,
> > > + },
> > > + [spirsrc_evqdma] = {
> > > + .flags = IORESOURCE_DMA | 
> > IORESOURCE_DMA_EVENT_Q,
> > > + }
> > > },
> > > {
> > > - .start = 16,
> > > - .flags = IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
> > > + [spirsrc_iomem] = {
> > > + .start = 0x01c68000,
> > > + .end = 0x01c687ff,
> > > + .flags = IORESOURCE_MEM,
> > > + },
> > > + [spirsrc_irq] = {
> > > + .flags = IORESOURCE_IRQ,
> > > + },
> > > + [spirsrc_rxdma] = {
> > > + .flags = IORESOURCE_DMA | 
> > IORESOURCE_DMA_RX_CHAN,
> > > + },
> > > + [spirsrc_txdma] = {
> > > + .flags = IORESOURCE_DMA | 
> > IORESOURCE_DMA_TX_CHAN,
> > > + },
> > > + [spirsrc_evqdma] = {
> > > + .flags = IORESOURCE_DMA | 
> > IORESOURCE_DMA_EVENT_Q,
> > > + }
> > > },
> > > {
> > > - .start = EVENTQ_3,
> > > - .flags = IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
> > > + [spirsrc_iomem] = {
> > > + .start = 0x01c23000,
> > > + .end = 0x01c237ff,
> > > + .flags = IORESOURCE_MEM,
> > > + },
> > > + [spirsrc_irq] = {
> > > + .flags = IORESOURCE_IRQ,
> > > + },
> > > + [spirsrc_rxdma] = {
> > > + .flags = IORESOURCE_DMA | 
> > IORESOURCE_DMA_RX_CHAN,
> > > + },
> > > + [spirsrc_txdma] = {
> > > + .flags = IORESOURCE_DMA | 
> > IORESOURCE_DMA_TX_CHAN,
> > > + },
> > > + [spirsrc_evqdma] = {
> > > + .flags = IORESOURCE_DMA | 
> > IORESOURCE_DMA_EVENT_Q,
> > > + }
> > > + }
> > > +};
> > 
> > Since most boards will not be using all of the above, Rather than
> > statically allocate the IRQ and DMA resources, why not allocate them
> > on demand during _init_spi()?
> 
> Don't think this is worthwile. You save a couple of bytes, but have
> to add code that does memory allocation and associated error handling.
> 
> thanks,
> Thomas
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Wed, 21 Apr 2010 15:09:08 +0530
> From: "Nori, Sekhar" <nsekhar at ti.com>
> To: "Koeller, T." <Thomas.Koeller at baslerweb.com>
> Cc: "davinci-linux-open-source at linux.davincidsp.com"
> <davinci-linux-open-source at linux.davincidsp.com>
> Subject: RE: [PATCH 4/4] DM365: Add platform resource management
> Message-ID:
> <B85A65D85D7EB246BE421B3FB0FBB59301E6A1520A at dbde02.ent.ti.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi Thomas,
> 
> On Wed, Apr 21, 2010 at 13:43:55, Koeller, T. wrote:
> > Hi Kevin,
> >
> > >
> > > Actually, the driver is the place where the resources are used and
> > > therefore where they should be reserved and released. This patch
> > > removes this from the drivers and puts it in SoC code which I don't
> > > like.
> > >
> > > There are really two main things going on here that I see:
> > >
> > > 1. add parent resources (cfg, irq, dma, etc.)
> > > 2. move resource reservation from drivers to SoC code
> > >
> > > It's primarily 2 that I object to.
> > >
> > > While I think (1) may be helpful, if we're going to do it, we should
> > > do it throughout all of mach-davinci/*.
> >
> > Here I do not quite agree with your view. In general, resource managment
> > is about avoiding conflicts. This means that it must be done in a
> > place where the resource requirements of all devices are known, and this
> > is the bus, not the individual drivers. This is more obvious when
> > dealing with buses that enumerate their devices and collect their
> > resource requirements in order to make intelligent decisions. The
> > platform bus has been invented to extend this concept to devices that
> > are not really on such a bus.
> >
> > For platform devices, resources are set up by the platform and passed to
> > the drivers via platform devices. At this point, the decision about which
> > resource is going to be used by a particular driver has already been made,
> > and nothing is gained by defering the actual allocation. Resource
> 
> I can think of one (admittedly esoteric) example where this not true.
> On the DM6446 EVM, the NAND and NOR flash reside on the same chip-select
> and it is possible to runtime switch between the flashes used by
> flipping a jumper and insmoding the appropriate driver.
> 
> Currently, both nand and nor drivers do not make a memory region request,
> but that should probably be fixed.
> 
> > allocation in the driver is only possible for resources for which
> > global root nodes exist (IO and MEMORY addresses). All other kinds of
> > resources cannot be allocated by drivers because these do not (and should
> > not) know about the root resource nodes in the platform. Consequently,
> > you see lots of drivers that do allocate memory resources, but ignore
> > all the others.
> 
> IRQ resources are managed by request_irq(). EDMA does its own resource
> management, but ideally should be using drivers/dma/ resource manager.
> 
> So, I tend to think of it as driver requesting and releasing all
> shared resources.
> 
> Thanks,
> Sekhar
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Wed, 21 Apr 2010 14:10:29 +0200
> From: "Koeller, T." <Thomas.Koeller at baslerweb.com>
> To: "Nori, Sekhar" <nsekhar at ti.com>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Subject: RE: [PATCH 4/4] DM365: Add platform resource management
> Message-ID:
> <C5A8FDEFF7647F4C9CB927D7DEB307730E530AA9 at ahr075s.basler.corp>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> From: Nori, Sekhar [mailto:nsekhar at ti.com] 
> 
> > IRQ resources are managed by request_irq(). EDMA does its own resource
> > management, but ideally should be using drivers/dma/ resource manager.
> 
> This is not the kind of resource management I am talking about. You could
> call request_irq() with any bogus irq number (similar for DMA) and not notice
> that you are doing something wrong. You could attempt to set up an interrupt
> as shared that is not sharable. Look at linux/ioport.h for a lot of stuff
> designed to aid in avoiding such conflicts by proper use of resources.
> 
> Finally, a platform may define resources that are totally platform-specific,
> and that can only be managed within the platform itself.
> 
> thanks,
> Thomas
> 
> 
> ------------------------------
> 
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 
> 
> End of Davinci-linux-open-source Digest, Vol 52, Issue 65
> *********************************************************
 		 	   		  
_________________________________________________________________
Hotmail: Free, trusted and rich email service.
https://signup.live.com/signup.aspx?id=60969
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100427/f809ce6a/attachment-0001.html>

From sshtylyov at mvista.com  Tue Apr 27 08:00:36 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Tue, 27 Apr 2010 17:00:36 +0400
Subject: cppi_dma.c : channel_abort
In-Reply-To: <4BD6CA46.7020605@gmail.com>
References: <4BD6CA46.7020605@gmail.com>
Message-ID: <4BD6DFF4.8020108@mvista.com>

Hello.

Kieran Bingham wrote:

> We're running a DM365, with Montavista 2.6.18_pro500 kernel.
>
> With a USB Flash drive, and a USB Connected DVD Drive, we're 
> experiencing kernel lockups
>
> Having connected the JTAG, and stepping through the assembly, it would 
> appear that it is cycling through one of the two while loops in the 
> function channel_abort, in drivers/usb/musb/cppi_dma.c
>
> Unfortunately its doing this with interrupts off!! and it never leaves!
>
> Has anyone else experienced Kernel Lockups with USB devices connected ?

   See if the following patch can fix it for you:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=patch;h=565969237ab6e73ce7192684d00d5b890ee308fa

WBR, Sergei


From davide.bonfanti at bticino.it  Tue Apr 27 08:38:17 2010
From: davide.bonfanti at bticino.it (davide.bonfanti at bticino.it)
Date: Tue, 27 Apr 2010 15:38:17 +0200
Subject: Parallel RGB signals out from DM365 
Message-ID: <OF965EB0DB.87E3931F-ONC1257712.004AEAA1@grpleg.it>


I'm trying to drive a parallel RGB LCD usign DM365 but  I'M NOT ABLE TO
OBTAIN ANY SIGNAL OUT FROM DM365.

I'm using khilman_master_2.6.34-rc1 kernel branch.

I've patched davincifb.c in order to manage output=lcd:format=rgb using
this function:

________________________________________________

static void davincifb_lcd_rgb_config(int on)
{
        if (on) {
                /* Reset video encoder module */
                dispc_reg_out(VENC_VMOD, 0x0);

                /* set hsync pulse width */
                dispc_reg_out(VENC_HSPLS, dm->osd0->info.var.hsync_len);

                /* set vsync pulse width */
                dispc_reg_out(VENC_VSPLS, dm->osd0->info.var.vsync_len);

                /* set horizontal interval  */
                dispc_reg_out(VENC_HINT, dm->osd0->info.var.left_margin +
                dm->osd0->info.var.right_margin + dm->osd0->
                info.var.width);

                /* set horizontal data valid start position  */
                dispc_reg_out(VENC_HSTART, dm->osd0->info.var.left_margin);

                /* set Horizontal data valid range  */
                dispc_reg_out(VENC_HVALID, dm->osd0->info.var.width);

                /* set Vertical interval  */
                dispc_reg_out(VENC_VINT, dm->osd0->info.var.upper_margin +
                dm->osd0->info.var.lower_margin + dm->osd0->
                info.var.height);

                /* set Vertical data valid start position */
                dispc_reg_out(VENC_VSTART, dm->osd0->
                info.var.upper_margin);

                /* set Horizontal data valid range  */
                dispc_reg_out(VENC_VVALID, dm->osd0->info.var.height);

                dispc_reg_out(VENC_DCLKCTL, 0x801);
                dispc_reg_out(VENC_DCLKPTN0, 0x03);
                dispc_reg_out(VENC_DCLKPTN1, 0x0);
                dispc_reg_out(VENC_DCLKPTN2, 0x0);
                dispc_reg_out(VENC_DCLKPTN3, 0x0);
                dispc_reg_out(VENC_DCLKPTN0A, 0x3);
                dispc_reg_out(VENC_DCLKPTN1A, 0x0);
                dispc_reg_out(VENC_DCLKPTN2A, 0x0);
                dispc_reg_out(VENC_DCLKPTN3A, 0x0);
                dispc_reg_out(VENC_OSDCLK1, 3);

                /* Enable VCLK */
                dispc_reg_out(VENC_VIDCTL, 0x2000);

                dispc_reg_out
(VENC_VMOD,(VENC_VMOD_VDMD_RGB666<<VENC_VMOD_VDMD_SHIFT) |VENC_VMOD_ITLCL |
VENC_VMOD_HDMD | VENC_VMOD_VIE | VENC_VMOD_VENC);
#endif
        } else {
                /* Reset video encoder module */
                dispc_reg_out(VENC_VMOD, 0);
        }
}

________________________________________________

This is my registers situation:

PINMUX:
a(1C40000):  0x00E00000 0x00285555 0x000018C0 0x375AFFFF
a(1C40010):  0x00007FFF


PLL configurations:
a(1C40800):  0x0001080E 0x00000000 0x00000000 0x00000000
a(1C40810):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C40820):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C40830):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C40840):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C40850):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C40860):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C40870):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C40880):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C40890):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C408A0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C408B0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C408C0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C408D0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C408E0):  0x00000000 0x00000004 0x00000000 0x00000000
a(1C408F0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C40900):  0x00000051 0x00000010 0x00410000 0x00000000
a(1C40910):  0x00000051 0x00008007 0x00008000 0x00008001
a(1C40920):  0x00008001 0x00000000 0x00008000 0x00008000
a(1C40930):  0x00000000 0x00000000 0x00000001 0x00000006
a(1C40940):  0x0000001C 0x00000000 0x00000001 0x00000009
a(1C40950):  0x000001FF 0x00000000 0x00000000 0x00000000
a(1C40960):  0x00008003 0x00008001 0x00008011 0x00008000
a(1C40970):  0x00008003 0x00008001 0x00000000 0x00000000
a(1C40980):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C40990):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C409A0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C409B0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C409C0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C409D0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C409E0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C409F0):  0x00000000 0x00000000 0x00000000 0x00000000

VENC registers
a(1C71E00):  0x00002903 0x00002000 0x00000000 0x00000000
a(1C71E10):  0x00000002 0x00000002 0x0000010E 0x00000012
a(1C71E20):  0x000000F0 0x0000015C 0x00000014 0x00000140
a(1C71E30):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71E40):  0x0000FF00 0x00000000 0x00000000 0x00000000
a(1C71E50):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71E60):  0x00000000 0x00000801 0x00000003 0x00000000
a(1C71E70):  0x00000000 0x00000000 0x00000003 0x00000000
a(1C71E80):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71E90):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71EA0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71EB0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71EC0):  0x00000000 0x00007000 0x00000000 0x0000017A
a(1C71ED0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71EE0):  0x00000100 0x00000000 0x00000000 0x00000000
a(1C71EF0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71F00):  0x00000400 0x0000057C 0x00000159 0x000002CB
a(1C71F10):  0x000006EE 0x00000400 0x0000057C 0x00000159
a(1C71F20):  0x000002CB 0x000006EE 0x00000000 0x00000001
a(1C71F30):  0x00000003 0x00000000 0x00000000 0x00000000
a(1C71F40):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71F50):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71F60):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71F70):  0x0000D642 0x00000000 0x00000000 0x00000000
a(1C71F80):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71F90):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71FA0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71FB0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71FC0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71FD0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71FE0):  0x00000000 0x00000000 0x00000087 0x0000FFE7
a(1C71FF0):  0x00000008 0x00000000 0x00000000 0x00000000

OSD Registers
a(1C71C00):  0x00000200 0x00000302 0x00002003 0x00008002
a(1C71C10):  0x00000000 0x00000000 0x0000002D 0x0000002D
a(1C71C20):  0x0000002D 0x0000000C 0x00000000 0x00000000
a(1C71C30):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71C40):  0x00000080 0x00000012 0x00000000 0x00000000
a(1C71C50):  0x000002D0 0x000000A0 0x00000000 0x00000000
a(1C71C60):  0x000002D0 0x000000A0 0x00000000 0x00000000
a(1C71C70):  0x000000F0 0x000000A0 0x00000000 0x00000000
a(1C71C80):  0x000002D0 0x000000A0 0x00000000 0x00000000
a(1C71C90):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71CA0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71CB0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71CC0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71CD0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C71CE0):  0x00000000 0x00000000 0x00001000 0x00000000
a(1C71CF0):  0x00000000 0x00000000 0x00000000 0x00000000

VPBE Clock Control Register
a(1C70200):  0x00000019

VPSS_CLKCTL
a(1c40044):  0x00000018

ISP System Configuration Registers
a(1C70000):  0x4C180800 0x0000007F 0x00000002 0x00300200
a(1C70010):  0x0B1F0100 0x1F0A0F1F 0x00000015 0x00000000
a(1C70020):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C70030):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C70040):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C70050):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C70060):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C70070):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C70080):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C70090):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C700A0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C700B0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C700C0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C700D0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C700E0):  0x00000000 0x00000000 0x00000000 0x00000000
a(1C700F0):  0x00000000 0x00000000 0x00000000 0x00000000

Can you give me any help? What can I test, what else can be wrong?

Thx

Davide Bonfanti
Tel.: +39 031-653357
Indirizzo: via Manara, 4 22036 - Erba (CO)
E-mail: davide.bonfanti at bticino.it
Web: www.bticino.it
Bticino
Legrand
Zucchini
Cablofil
Ortronics

Consider the environment
Please don't print this e-mail unless you really need to.



Ce message, ainsi que tous les fichiers joints ? ce message,
peuvent contenir des informations sensibles et/ ou confidentielles
ne devant pas ?tre divulgu?es. Si vous n'?tes pas le destinataire
de ce message (ou que vous recevez ce message par erreur), nous
vous remercions de le notifier imm?diatement ? son exp?diteur, et
de d?truire ce message. Toute copie, divulgation, modification,
utilisation ou diffusion, non autoris?e, directe ou indirecte, de
tout ou partie de ce message, est strictement interdite.

This e-mail, and any document attached hereby, may contain
confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any
unauthorized, direct or indirect, copying, disclosure, distribution
or other use of the material or parts thereof is strictly
forbidden.

From rtivy at ti.com  Tue Apr 27 12:32:26 2010
From: rtivy at ti.com (Tivy, Robert)
Date: Tue, 27 Apr 2010 12:32:26 -0500
Subject: Compile Error
In-Reply-To: <COL106-W24DE8402A8629409CF4188AB030@phx.gbl>
References: <mailman.1871.1271851892.11996.davinci-linux-open-source@linux.davincidsp.com>
	<COL106-W24DE8402A8629409CF4188AB030@phx.gbl>
Message-ID: <6B8224E84039B140AA662F0BB0361643012A406C18@dlee04.ent.ti.com>

-z means that every following option is for the linker, and since many compiler options follow the expansion of usr.bld, you can't use -z in that file.  Is there not a link.cmd or linker.cmd file that can be used instead (and is consumed by the XDC tooling)?

Regards,

- Rob

________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Mohamed AbdElwahed
Sent: Tuesday, April 27, 2010 5:38 AM
To: Davinci Mailing list
Subject: Compile Error


I use DM6446 and  i implemented my own codec and i success to compile(the CGT is version 6.1.12) and run it.
but when i edit the "usr.bld" file by adding this options "-z -l forder.cmd" to the compiler options, it fail with the below error.


----------------------------------------------------------------------------
----------------------------------------------------------------------------



# generating interfaces for package codecs.decode_slice_h264 (because package/package.xdc.xml is older than package.xdc) ...

/opt/xdc_3_05/xs -Dxdc.path="/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264/../..;/opt/codec_engine_2_10/cetools/packages;/opt/codec_engine_2_10/packages;/opt/bios_5_32_02/packages;/opt/xdc_3_05/packages;../.." -Dxdc.root=/opt/xdc_3_05 -Dxdc.hostOS=Linux -Dconfig.importPath=".;/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264/../..;/opt/codec_engine_2_10/cetools/packages;/opt/codec_engine_2_10/packages;/opt/bios_5_32_02/packages;/opt/xdc_3_05/packages;../..;/opt/xdc_3_05;/opt/xdc_3_05/etc" -Dxdc.bld.targets="" -DTOOLS= -f xdc/services/intern/cmd/build.xs -m package/package.xdc.dep -i package/package.xdc.inc package.xdc

translating DECODE_SLICE_H264

.interfaces files complete: Tue Apr 27 14:04:08 EET 2010.

======== .libraries [/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264] ========

rm -f package/lib/lib/decode_slice_h264/package/package_codecs.decode_slice_h264.o64P

#

# cl64P package/package_codecs.decode_slice_h264.c ...

/opt/TI/C6000CGT6.1.13/bin/cl6x -c -mt -mo --opt_for_speed=5 -O3 --program_level_compile --silicon_version=6446 --keep_asm --opt_for_speed=5 -z -l forder.cmd -mv64p -eo.o64P -ea.s64P -D__xdc_bld_pkg_c__=package.bld.c -Dxdc_target_name__=C64P -Dxdc_target_types__=ti/targets/std.h -Dxdc_bld__profile_release -Dxdc_bld__vers_1_0_6_1_13 -o2 -I. -I/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264/../.. -I/opt/codec_engine_2_10/cetools/packages -I/opt/codec_engine_2_10/packages -I/opt/bios_5_32_02/packages -I/opt/xdc_3_05/packages -I../.. -I/opt/TI/C6000CGT6.1.13/include -fs=./package/lib/lib/decode_slice_h264/package -fr=./package/lib/lib/decode_slice_h264/package -fc package/package_codecs.decode_slice_h264.c

>> WARNING: invalid linker option -D__xdc_bld_pkg_c__=package.bld.c (ignored)

>> WARNING: invalid linker option -Dxdc_target_name__=C64P (ignored)

>> WARNING: invalid linker option -Dxdc_target_types__=ti/targets/std.h (ignored)

>> WARNING: invalid linker option -Dxdc_bld__profile_release (ignored)

>> WARNING: invalid linker option -Dxdc_bld__vers_1_0_6_1_13 (ignored)

ERROR: argument to option -f ("value") is out of range

gmake[1]: *** [package/lib/lib/decode_slice_h264/package/package_codecs.decode_slice_h264.o64P] Error 1

gmake: *** [/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264,.libraries] Error 2

make[2]: *** [all] Error 2

make[2]: Leaving directory `/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264'

make[1]: *** [all] Error 2

make[1]: Leaving directory `/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs'

make: *** [all] Error 2


----------------------------------------------------------------------------
----------------------------------------------------------------------------
Any help is highly appreciated
Mohamed AbdElwahed Ibrahim [http://graphics.hotmail.com/i.p.emthup.gif]






> From: davinci-linux-open-source-request at linux.davincidsp.com
> Subject: Davinci-linux-open-source Digest, Vol 52, Issue 65
> To: davinci-linux-open-source at linux.davincidsp.com
> Date: Wed, 21 Apr 2010 07:11:32 -0500
>
> Send Davinci-linux-open-source mailing list submissions to
> davinci-linux-open-source at linux.davincidsp.com
>
> 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
> davinci-linux-open-source-request at linux.davincidsp.com
>
> You can reach the person managing the list at
> davinci-linux-open-source-owner at linux.davincidsp.com
>
> 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. Re: [PATCH 4/4] DM365: Add platform resource management
> (Kevin Hilman)
> 2. Re: [PATCH 2/4] DM365: Allow use of GPIO64_57 (Kevin Hilman)
> 3. RE: [PATCH 4/4] DM365: Add platform resource management
> (Koeller, T.)
> 4. RE: [PATCH 1/4] DM365: Make all SPI units SPI0..SPI4
> available (Koeller, T.)
> 5. RE: [PATCH 4/4] DM365: Add platform resource management
> (Nori, Sekhar)
> 6. RE: [PATCH 4/4] DM365: Add platform resource management
> (Koeller, T.)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 20 Apr 2010 15:20:37 -0700
> From: Kevin Hilman <khilman at deeprootsystems.com>
> To: thomas.koeller at baslerweb.com
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Subject: Re: [PATCH 4/4] DM365: Add platform resource management
> Message-ID: <87633lepfu.fsf at deeproots! ystems.com>
> Content-Type: text/plain; charset=us-ascii
& gt;
> thomas.koeller at baslerweb.com writes:
>
> > From: Thomas Koeller <thomas.koeller at baslerweb.com>
> >
> > Keeping track of resource assignments greatly simplifies
> > the task of writing board support code. Many drivers for
> > DaVinci peripherals were using resources that had never
> > been allocated, with the notable exception of memory
> > resources.
> >
> > Non-conflicting resource assignment is a responsibility
> > of the bus the devices are on, in this case, the platform bus.
> >
> > The resource management scheme implemented by this patch is not
> > perfect. The SoC code really has no business managing resources,
> > it should only provide them to the platform (board support) code.
> > The board support is the only place where information about the
> > intended use of the various hardware resources is av! ailable.
>
> Actually, the driver is the place where the resources are used and
> therefore where they should be reserved and released. This patch
> removes this from the drivers and puts it in SoC code which I don't
> like.
>
> There are really two main things going on here that I see:
>
> 1. add parent resources (cfg, irq, dma, etc.)
> 2. move resource reservation from drivers to SoC code
>
> It's primarily 2 that I object to.
>
> While I think (1) may be helpful, if we're going to do it, we should
> do it throughout all of mach-davinci/*.
>
> Kevin
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 20 Apr 2010 15:21:05 -0700
> From: Kevin Hilman <khilman at deeprootsystems.com>
> To: thomas.koeller at baslerweb.com
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Subject: Re: [PATCH ! 2/4] DM365: Allow use of GPIO64_57
> Message-ID: <87zl0xdaum. fsf at deeprootsystems.com>
> Content-Type: text/plain; charset=us-ascii
>
> thomas.koeller at baslerweb.com writes:
>
> > From: Thomas Koeller <thomas.koeller at baslerweb.com>
> >
> > Extended the MUX configuration to allow use of GPIO
> > terminals 64..57.
> >
> > Signed-off-by: Thomas Koeller <thomas.koeller at baslerweb.com>
>
> Thanks, applying and queuing for 2.6.35 in davinci-next branch.
>
> Kevin
>
> > ---
> > arch/arm/mach-davinci/dm365.c | 1 +
> > arch/arm/mach-davinci/include/mach/mux.h | 1 +
> > 2 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> > index 023d708..0813dce 100644
> > --- a/arch/arm/mach-davinci/dm365.c
> > +++ b/arch/arm/mach-davinci/dm365.c
> > @@ -580,6 +580,7 @! @ MUX_CFG(DM365, SPI4_SDENA1, 4, 16, 3, 2, false)
> > MUX_CFG(DM365, GPIO20, 3, 21, 3, 0, false)
> > MUX_CFG(DM365, GPIO33, 4, 12, 3, 0, false)
> > MUX_CFG(DM365, GPIO40, 4, 26, 3, 0, false)
> > +MUX_CFG(DM365, GPIO64_57, 2, 6, 1, 0, false)
> >
> > MUX_CFG(DM365, VOUT_FIELD, 1, 18, 3, 1, false)
> > MUX_CFG(DM365, VOUT_FIELD_G81, 1, 18, 3, 0, false)
> > diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h
> > index 05e35fa..d6c6921 100644
> > --- a/arch/arm/mach-davinci/include/mach/mux.h
> > +++ b/arch/arm/mach-davinci/include/mach/mux.h
> > @@ -295,6 +295,7 @@ enum davinci_dm365_index {
> > DM365_GPIO20,
> > DM365_GPIO33,
> > DM365_GPIO40,
> > + DM365_GPIO64_57,
> >
> > /* Video */
> > DM365_VOUT_FIELD,
> > --
> > 1.7.0.3
> >
>! ; > _______________________________________________
> > Da vinci-linux-open-source mailing list
> > Davinci-linux-open-source at linux.davincidsp.com
> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 21 Apr 2010 10:13:55 +0200
> From: "Koeller, T." <Thomas.Koeller at baslerweb.com>
> To: "Kevin Hilman" <khilman at deeprootsystems.com>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Subject: RE: [PATCH 4/4] DM365: Add platform resource management
> Message-ID:
> <C5A8FDEFF7647F4C9CB927D7DEB307730E5309C7 at ahr075s.basler.corp>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Kevin,
>
> >
> > Actually, the driver is the place where the resources are used and
> > therefore where they should be reserved and released. This patch
> > removes this from the drivers and puts it in! SoC code which I don't
> > like.
> >
> > There are really two main things going on here that I see:
> >
> > 1. add parent resources (cfg, irq, dma, etc.)
> > 2. move resource reservation from drivers to SoC code
> >
> > It's primarily 2 that I object to.
> >
> > While I think (1) may be helpful, if we're going to do it, we should
> > do it throughout all of mach-davinci/*.
>
> Here I do not quite agree with your view. In general, resource managment
> is about avoiding conflicts. This means that it must be done in a
> place where the resource requirements of all devices are known, and this
> is the bus, not the individual drivers. This is more obvious when
> dealing with buses that enumerate their devices and collect their
> resource requirements in order to make intelligent decisions. The
> platform bus has been invented to! extend this concept to devices that
> are not really on such a bus.
>
> For platform devices, resources are set up by the platform and passed to
> the drivers via platform devices. At this point, the decision about which
> resource is going to be used by a particular driver has already been made,
> and nothing is gained by defering the actual allocation. Resource
> allocation in the driver is only possible for resources for which
> global root nodes exist (IO and MEMORY addresses). All other kinds of
> resources cannot be allocated by drivers because these do not (and should
> not) know about the root resource nodes in the platform. Consequently,
> you see lots of drivers that do allocate memory resources, but ignore
> all the others.
>
> Therefore, if a platform wanted to do proper resource management covering
> all kinds of resources, it would have to treat memory and io resources
> specially, relying on the driver to do the actual allocation a! nd implement
> resource management only for the remaining resource types, which is
> certainly ugly.
>
> Thanks for your comments!
>
> Thomas
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 21 Apr 2010 10:21:37 +0200
> From: "Koeller, T." <Thomas.Koeller at baslerweb.com>
> To: "Kevin Hilman" <khilman at deeprootsystems.com>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Subject: RE: [PATCH 1/4] DM365: Make all SPI units SPI0..SPI4
> available
> Message-ID:
> <C5A8FDEFF7647F4C9CB927D7DEB307730E5309D5 at ahr075s.basler.corp>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Kevin,
>
> > > --- /dev/null
> > > +++ b/arch/arm/mach-davinci/board_dm365_evm_resources.h
> > > @@ -0,0 +1,17 @@
> > > +#ifndef _DAVINCI_EVM_RESOURCES_H
> > > +#d! efine _DAVINCI_EVM_RESOURCES_H
> > > +
> > > + #include <mach/irqs.h>
> > > +#include <mach/edma.h>
> > > +
> > > +/* IRQs */
> > > +#define IRQ_SPI0 IRQ_DM365_SPIINT0_0
> >
> > This can be dropped, and IRQ_DM365_SPIINT0_0 used directly.
> >
> > > +/* DMA channels */
> > > +#define DMA_CHAN_SPI0_TX 16
> > > +#define DMA_CHAN_SPI0_RX 17
> >
> > These are SoC common, should be in <soc>.h
> >
> > > +/* DMA event queues */
> > > +#define DMA_EVQ_SPI0 EVENTQ_3
> >
> > This can be dropped, and EVNETQ_3 used directly.
> >
> > > +#endif /* _DAVINCI_EVM_RESOURCES_H */
> >
> > I think it's best to just drop this file and these #defines altogether
> > and just use the values directly in the board files. It will make the
> > board files a bit more readable and avoid a level o! f indirection.
>
> I thought it a good idea to have central point where all those
> resources (I am using this term in an informal way here) are defined
> in terms of their intended use, making it easier to spot
> possible conflicts.
>
> > > diff --git a/arch/arm/mach-davinci/dm365.c
> > b/arch/arm/mach-davinci/dm365.c
> > > index ed6c9c7..023d708 100644
> > > --- a/arch/arm/mach-davinci/dm365.c
> > > +++ b/arch/arm/mach-davinci/dm365.c
> > > @@ -616,72 +616,256 @@ EVT_CFG(DM365, EVT3_ASP_RX,
> > 1, 1, 0, false)
> > > #endif
> > > };
> > >
> > > -static u64 dm365_spi0_dma_mask = DMA_BIT_MASK(32);
> > > +static u64 dm365_spi_dma_mask = DMA_BIT_MASK(32);
> > >
> > > -static struct davinci_spi_platform_data dm365_spi0_pdata = {
> > > - .version = SPI_VERSION_1,
! > > > - .num_chipselect = 2,
> > > - .clk_interna l = 1,
> > > - .cs_hold = 1,
> > > - .intr_level = 0,
> > > - .poll_mode = 1, /* 0 -> interrupt mode 1->
> > polling mode */
> > > - .use_dma = 1, /* when 1, value in poll_mode
> > is ignored */
> > > - .c2tdelay = 0,
> > > - .t2cdelay = 0,
> > > +enum dm365_spi_resource_index {
> > > + spirsrc_iomem,
> > > + spirsrc_irq,
> > > + spirsrc_rxdma,
> > > + spirsrc_txdma,
> > > + spirsrc_evqdma
> > > };
> > >
> > > -static struct resource dm365_spi0_resources[] = {
> > > +
> > > +static struct resource dm365_spi_resources[spirsrc_evqdma
> > + 1][5] = {
> > > {
> > > - .start = 0x01c66000,
> > > - .end = 0x01c667ff,
> > > - .flags = IORESOURCE_MEM,
> > > + [spirsrc_iomem] = {
> &g! t; > + .start = 0x01c66000,
> > > + .end = 0x01c667ff,
> > > + .flags = IORESOURCE_MEM,
> > > + },
> > > + [spirsrc_irq] = {
> > > + .flags = IORESOURCE_IRQ,
> > > + },
> > > + [spirsrc_rxdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_RX_CHAN,
> > > + },
> > > + [spirsrc_txdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_TX_CHAN,
> > > + },
> > > + [spirsrc_evqdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_EVENT_Q,
> > > + }
> > > },
> > > {
> > > - .start = IRQ_DM365_SPIINT0_0,
> > > - .flags = IORESOURCE_IRQ,
> > > + [spirsrc_iomem] = {
> > > + .start = 0x01c66800,
> > > + .end = 0x01c66fff,
> > > + .flags = IORESOURCE_MEM,> > > + },
> > > + [spirsrc_irq] = {
> > ; > + .flags = IORESOURCE_IRQ,
> > > + },
> > > + [spirsrc_rxdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_RX_CHAN,
> > > + },
> > > + [spirsrc_txdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_TX_CHAN,
> > > + },
> > > + [spirsrc_evqdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_EVENT_Q,
> > > + }
> > > },
> > > {
> > > - .start = 17,
> > > - .flags = IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
> > > + [spirsrc_iomem] = {
> > > + .start = 0x01c67800,
> > > + .end = 0x01c67fff,
> > > + .flags = IORESOURCE_MEM,
> > > + },
> > > + [spirsrc_irq] = {
> > > + .flags = IORESOURCE_IRQ,
> > > + },
> > > + [spirsrc_rxdma] = {
> > ! > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_RX_CHAN,
> > > + },
> > > + [spirsrc_txdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_TX_CHAN,
> > > + },
> > > + [spirsrc_evqdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_EVENT_Q,
> > > + }
> > > },
> > > {
> > > - .start = 16,
> > > - .flags = IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
> > > + [spirsrc_iomem] = {
> > > + .start = 0x01c68000,
> > > + .end = 0x01c687ff,
> > > + .flags = IORESOURCE_MEM,
> > > + },
> > > + [spirsrc_irq] = {
> > > + .flags = IORESOURCE_IRQ,
> > > + },
> > > + [spirsrc_rxdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_RX_CHAN,
> > > + },
> > &g! t; + [spirsrc_txdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_TX_CHAN,
> > > + },
> > > + [spirsrc_evqdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_EVENT_Q,
> > > + }
> > > },
> > > {
> > > - .start = EVENTQ_3,
> > > - .flags = IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
> > > + [spirsrc_iomem] = {
> > > + .start = 0x01c23000,
> > > + .end = 0x01c237ff,
> > > + .flags = IORESOURCE_MEM,
> > > + },
> > > + [spirsrc_irq] = {
> > > + .flags = IORESOURCE_IRQ,
> > > + },
> > > + [spirsrc_rxdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_RX_CHAN,
> > > + },
> > > + [spirsrc_txdma] = {
> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_TX_CHAN,
> > > + },
> > > + [spirsrc_evqdma] = {> > > + .flags = IORESOURCE_DMA |
> > IORESOURCE_DMA_EVENT_Q,
> > > + }
> > > + }
> > > +};
> >
> > Since most boards will not be using all of the above, Rather than
> > statically allocate the IRQ and DMA resources, why not allocate them
> > on demand during _init_spi()?
>
> Don't think this is worthwile. You save a couple of bytes, but have
> to add code that does memory allocation and associated error handling.
>
> thanks,
> Thomas
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 21 Apr 2010 15:09:08 +0530
> From: "Nori, Sekhar" <nsekhar at ti.com>
> To: "Koeller, T." <Thomas.Koeller at baslerweb.com>
> Cc: "davinci-linux-open-source at linux.davincidsp.com"
> <davinci-linux-open-source at linux.davincidsp.com>
> Subject: RE: [PATCH 4/4] DM365: Add pla! tform resource management
> Message-ID:
> <B85A65D85D7E B246BE421B3FB0FBB59301E6A1520A at dbde02.ent.ti.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Thomas,
>
> On Wed, Apr 21, 2010 at 13:43:55, Koeller, T. wrote:
> > Hi Kevin,
> >
> > >
> > > Actually, the driver is the place where the resources are used and
> > > therefore where they should be reserved and released. This patch
> > > removes this from the drivers and puts it in SoC code which I don't
> > > like.
> > >
> > > There are really two main things going on here that I see:
> > >
> > > 1. add parent resources (cfg, irq, dma, etc.)
> > > 2. move resource reservation from drivers to SoC code
> > >
> > > It's primarily 2 that I object to.
> > >
> > > While I think (1) may be helpful, if we're going to do it, we should
> > > do it thro! ughout all of mach-davinci/*.
> >
> > Here I do not quite agree with your view. In general, resource managment
> > is about avoiding conflicts. This means that it must be done in a
> > place where the resource requirements of all devices are known, and this
> > is the bus, not the individual drivers. This is more obvious when
> > dealing with buses that enumerate their devices and collect their
> > resource requirements in order to make intelligent decisions. The
> > platform bus has been invented to extend this concept to devices that
> > are not really on such a bus.
> >
> > For platform devices, resources are set up by the platform and passed to
> > the drivers via platform devices. At this point, the decision about which
> > resource is going to be used by a particular driver has already been made,
> > and nothing is gained by defering the actual! allocation. Resource
>
> I can think of one (admittedly esoteric) example where this not true.
> On the DM6446 EVM, the NAND and NOR flash reside on the same chip-select
> and it is possible to runtime switch between the flashes used by
> flipping a jumper and insmoding the appropriate driver.
>
> Currently, both nand and nor drivers do not make a memory region request,
> but that should probably be fixed.
>
> > allocation in the driver is only possible for resources for which
> > global root nodes exist (IO and MEMORY addresses). All other kinds of
> > resources cannot be allocated by drivers because these do not (and should
> > not) know about the root resource nodes in the platform. Consequently,
> > you see lots of drivers that do allocate memory resources, but ignore
> > all the others.
>
> IRQ resources are managed by request_irq(). EDMA does its own resource
> management, but ideally should be using drivers/! dma/ resource manager.
>
> So, I tend to think of it as driver requesting and releasing all
> shared resources.
>
> Thanks,
> Sekhar
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 21 Apr 2010 14:10:29 +0200
> From: "Koeller, T." <Thomas.Koeller at baslerweb.com>
> To: "Nori, Sekhar" <nsekhar at ti.com>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Subject: RE: [PATCH 4/4] DM365: Add platform resource management
> Message-ID:
> <C5A8FDEFF7647F4C9CB927D7DEB307730E530AA9 at ahr075s.basler.corp>
> Content-Type: text/plain; charset="iso-8859-1"
>
> From: Nori, Sekhar [mailto:nsekhar at ti.com]
>
> > IRQ resources are managed by request_irq(). EDMA does its own resource
> > management, but ideally should be using drivers/dma/ resource manager.
>
> This is not the kind of! resource management I am talking about. You could
> call reques t_irq() with any bogus irq number (similar for DMA) and not notice
> that you are doing something wrong. You could attempt to set up an interrupt
> as shared that is not sharable. Look at linux/ioport.h for a lot of stuff
> designed to aid in avoiding such conflicts by proper use of resources.
>
> Finally, a platform may define resources that are totally platform-specific,
> and that can only be managed within the platform itself.
>
> thanks,
> Thomas
>
>
> ------------------------------
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>
> End of Davinci-linux-open-source Digest, Vol 52, Issue 65
> *********************************************************

Hotmail: Free, trusted and rich email service. Get it now.<https://signup.live.com/signup.aspx?id=60969>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100427/1799cbeb/attachment-0001.html>

From jtobias at viaas.com  Tue Apr 27 18:47:59 2010
From: jtobias at viaas.com (John Tobias)
Date: Tue, 27 Apr 2010 16:47:59 -0700
Subject: Possible uboot crashes
In-Reply-To: <4BD66E8D.1070804@linespeed.net>
References: <x2n66b2b2311004231309r3e885ab6yf9dce952cd4997af@mail.gmail.com>
	<201004240840.11552.caglarakyuz@gmail.com>
	<4BD29316.6000903@linespeed.net>
	<t2j66b2b2311004261240pcddf2564w73374114144ac7d4@mail.gmail.com>
	<4BD66E8D.1070804@linespeed.net>
Message-ID: <l2p66b2b2311004271647kf67205baw60817da6157422fe@mail.gmail.com>

Hi Brian and Caglar,

I finally found the information that I need. I was able to modify the
DVFlahser/ubl to write the ubl data to block 1 to block 5.

And, for those who may experience the same scenario that I had, here's what
I did.

Since, the ubl default block in DVFlasher is block 1, I modified the
DVFlasher to write the ubl data onto block 5 . By doing this, I can dump the
contents of the failing block since the DVFlasher won't erase it.

After making sure that the ubl would be written on block 5, I re-program my
device. Then, I modified my kernel to expose the ubl block1 - block5 in
linux userspace and from there, I dumped the information of my failing ubl
block and compare it to the working copy.

I found out that the contents of address 0003900 to 0004000 are entirely
different.

Thanks for the info.

Best Regards,

john

On Mon, Apr 26, 2010 at 9:56 PM, Brian G Rhodes <bgr at linespeed.net> wrote:

> John Tobias wrote:
>
>> Hi,
>>
>> Sorry for the messed up. I was forwarding your email to my co-worker and I
>> accidentally send it to you.
>>
>> Anyway, I have a few questions to follow up with you guys.
>>
>> 1. What are the possible cause of the "read disturb errors"?. Can you give
>> me a bit detail explanation?
>>
>
> You will find information on read disturb in the datasheet for your NAND
> part.   Here is an excerpt from a Micron appnote.
>
> *From Micron App note: **_
> http://download.micron.com/pdf/technotes/nand/tn2917.pdf_*
>
> *Read Disturb:* A read disturb error occurs when one or more bits are
> changed from ?1?
> to ?0? during a READ operation. Read disturb errors occur within the block
> being read,
> but on a page or pages other than the page being read. Performing a high
> number
> (hundreds of thousands or millions) of READ operations on individual pages
> before an
> ERASE command for the block containing those pages can exacerbate this
> error.
> To recover from this type of error, erase the block where the error
> occurred and reprogram
> the data to that block.
>
> ------------------------------------------------------------------------------------
>
>
> Accessing this code repeatedly, without erasing and
> reprogramming the data, causes errors to occur over time (see ?Temporary
> Failures? on
> page 2). Many factors influence the point at which errors begin to appear,
> including how
> often the same physical area of the NAND Flash device is read and the
> extent to which
> ECC is used to maintain data integrity in the system.
>
> Also see:
>
> _http://www.edn.com/blog/980000298/post/1670047767.html_
>
>
>
>> 2. I am using kernel 2.6.10 and the ECC that we are using is
>> NAND_ECC_HW3_512. Brian, in your suggestions (reading the failing blocks),
>> how I can possible access the nand blocks if am getting a constant "BOOTME
>> BOOTME ..." on my serial port?. Do you have any tools that I can use?
>>
>
> You can modify DVFlasher to read blocks from NAND and output over serial.
>  You are basically adding a command to ubl.  Look at DVFlasher.cs and
> uartboot.c.   It is likely more busywork than not, but it's nice to verify.
>  There may be better tools than DVFlasher as well out there, but I am not
> familiar with any of them.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100427/e34b2afe/attachment.html>

From Jon.Povey at racelogic.co.uk  Tue Apr 27 23:21:46 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Wed, 28 Apr 2010 05:21:46 +0100
Subject: Possible uboot crashes
In-Reply-To: <l2p66b2b2311004271647kf67205baw60817da6157422fe@mail.gmail.com>
Message-ID: <70E876B0EA86DD4BAF101844BC814DFE28AA5470@Cloud.RL.local>

John Tobias wrote:
> Since, the ubl default block in DVFlasher is block 1, I modified the
> DVFlasher to write the ubl data onto block 5 . By doing this, I can
> dump the contents of the failing block since the DVFlasher won't
> erase it.
>
> After making sure that the ubl would be written on block 5, I
> re-program my device. Then, I modified my kernel to expose the ubl
> block1 - block5 in linux userspace and from there, I dumped the
> information of my failing ubl block and compare it to the working
> copy.

You can also read/write NAND flash through JTAG. This is very useful when you have bricked your NAND.
I have used a Ronetix PEEDI flash programmer a lot, it has a telnet interface and can read/write/erase things with or without OOB.
I am now just setting up to use OpenOCD which now has Davinci NAND support. Also good for debugging bootloaders, etc. And dirt cheap interface hardware is available.

--
Jon Povey
jon.povey at racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network



From suhas.jain at mavensystems.com  Wed Apr 28 02:09:00 2010
From: suhas.jain at mavensystems.com (Suhas Jain)
Date: Wed, 28 Apr 2010 12:39:00 +0530
Subject: TVP5158 driver with DVSDK 3.10
In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE28AA5470@Cloud.RL.local>
References: <l2p66b2b2311004271647kf67205baw60817da6157422fe@mail.gmail.com>
	<70E876B0EA86DD4BAF101844BC814DFE28AA5470@Cloud.RL.local>
Message-ID: <011601cae6a1$b6605490$2320fdb0$@jain@mavensystems.com>

Hello All,

I am trying to port TVP5158 driver for dvsdk 3.10. The current available
driver is released for DVSDK2.10. Has anybody tried porting this driver for
DVSDK 3.10? 
There seems to be change in EDMA architecture in LSP2.10 to LSP3.10. So is
there any guidelines to port EDMA code form LSP2.10 to LSP3.10. 
Has anybody already tried doing this porting before?

Please help.

Thanks in advance,

Suhas Jain


From kapil.pendse at gmail.com  Wed Apr 28 06:49:45 2010
From: kapil.pendse at gmail.com (Kapil Pendse)
Date: Wed, 28 Apr 2010 17:19:45 +0530
Subject: Bluetooth on Davinci DM355
Message-ID: <u2k65b6d8ff1004280449ja71e2bb8o20e522c340d35378@mail.gmail.com>

Hello,

I've been trying to get Bluetooth to work with DM355 based board. My kernel
is 2.6.10 with patchset PSP 01.20.01.004.

I've compiled BlueZ packages "bluez-libs-2.10" and "bluez-utils-2.10" for
the DaVinci. I know this is a very old version of BlueZ, but someone had
recommended this one as it doesn't depend on the D-Bus package.

So with this setup, when I connect my old Bluetooth USB dongle to the DM355
board (note that it is not the EVM), the device gets detected as a full
speed (12Mbps) USB device, and HCI interface is set up for it as hci0.

root at 192.168.0.4:~# lsusb

Bus 001 Device 013: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth
Dongle
Bus 001 Device 001: ID 04d6:0000 Mentor Graphics

root at 192.168.0.4:~# hciconfig -a

hci0:   Type: USB
        BD Address: 00:10:60:AB:D0:5C ACL MTU: 192:8  SCO MTU: 64:8
        UP RUNNING PSCAN ISCAN
        RX bytes:105 acl:0 sco:0 events:10 errors:0
        TX bytes:42 acl:0 sco:0 commands:10 errors:0
        Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy:
        Link mode: SLAVE ACCEPT
        Name: ''
Can't read class of device on hci0. Connection timed out(110)

But when I try to scan for remote BT devices, I get timeout error like
below:

root at 192.168.0.4:~# hcitool scan

Scanning ...
hci_cmd_task: hci0 command tx timeout
hci_usb_rx_complete: hci0 corrupted packet: type 4 count 16

I do remember that the scan DID WORK one or two times. It did manage to
detect my cellphone's BT. But that's about it, so I'd say that it is unable
to scan for devices 99% of the time.

I've tested this BT dongle on my LinuxMint based host PC, it works fine. So
although very old, the BT dongle is just fine. Looks like I need to fix
something in the BlueZ kernel modules or userspace libraries.

Could someone help me figure out what is wrong and what would be the way to
fix this?

Thanks and best regards,

Kapil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100428/3c4cbc17/attachment.html>

From nsekhar at ti.com  Wed Apr 28 08:14:18 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Wed, 28 Apr 2010 18:44:18 +0530
Subject: TVP5158 driver with DVSDK 3.10
In-Reply-To: <011601cae6a1$b6605490$2320fdb0$@jain@mavensystems.com>
References: <l2p66b2b2311004271647kf67205baw60817da6157422fe@mail.gmail.com>
	<70E876B0EA86DD4BAF101844BC814DFE28AA5470@Cloud.RL.local>
	<011601cae6a1$b6605490$2320fdb0$@jain@mavensystems.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E6BAC82C@dbde02.ent.ti.com>

Hi Suhas,

On Wed, Apr 28, 2010 at 12:39:00, Suhas Jain wrote:
> Hello All,
>
> I am trying to port TVP5158 driver for dvsdk 3.10. The current available
> driver is released for DVSDK2.10. Has anybody tried porting this driver for
> DVSDK 3.10?

No, not aware of any such effort.

> There seems to be change in EDMA architecture in LSP2.10 to LSP3.10. So is
> there any guidelines to port EDMA code form LSP2.10 to LSP3.10.
> Has anybody already tried doing this porting before?

The following notes should help:

http://processors.wiki.ti.com/index.php/DaVinci_PSP_3.02_Linux_Installation_User_Guide#EDMA

You can also look at drivers like VDCE (drivers/char/davinci_vdce.c)
as an example.

Thanks,
Sekhar

From suhas.jain at mavensystems.com  Wed Apr 28 09:44:19 2010
From: suhas.jain at mavensystems.com (Suhas Jain)
Date: Wed, 28 Apr 2010 20:14:19 +0530
Subject: TVP5158 driver with DVSDK 3.10
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E6BAC82C@dbde02.ent.ti.com>
References: <l2p66b2b2311004271647kf67205baw60817da6157422fe@mail.gmail.com>	<70E876B0EA86DD4BAF101844BC814DFE28AA5470@Cloud.RL.local>
	<011601cae6a1$b6605490$2320fdb0$@jain@mavensystems.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E6BAC82C@dbde02.ent.ti.com>
Message-ID: <014501cae6e1$49064c20$db12e460$@jain@mavensystems.com>

Thanks for your help.

I need more help on using edma in descriptor mode. i.e. use the edma_link
and edma_alloc_slot functionality.
How are these functions used? In LSP2.10 there was only one call
davinci_request_dma, whereas in 3.10 we will have to use edma_alloc_channel
and edma_alloc_slot functions.

How to make use of these?

-----Original Message-----
From: Nori, Sekhar [mailto:nsekhar at ti.com] 
Sent: 28 April 2010 18:44
To: Suhas Jain
Cc: davinci-linux-open-source at linux.davincidsp.com
Subject: RE: TVP5158 driver with DVSDK 3.10

Hi Suhas,

On Wed, Apr 28, 2010 at 12:39:00, Suhas Jain wrote:
> Hello All,
>
> I am trying to port TVP5158 driver for dvsdk 3.10. The current available
> driver is released for DVSDK2.10. Has anybody tried porting this driver
for
> DVSDK 3.10?

No, not aware of any such effort.

> There seems to be change in EDMA architecture in LSP2.10 to LSP3.10. So is
> there any guidelines to port EDMA code form LSP2.10 to LSP3.10.
> Has anybody already tried doing this porting before?

The following notes should help:

http://processors.wiki.ti.com/index.php/DaVinci_PSP_3.02_Linux_Installation_
User_Guide#EDMA

You can also look at drivers like VDCE (drivers/char/davinci_vdce.c)
as an example.

Thanks,
Sekhar


From mohameeed2010 at hotmail.com  Thu Apr 29 06:00:37 2010
From: mohameeed2010 at hotmail.com (Mohamed AbdElwahed)
Date: Thu, 29 Apr 2010 11:00:37 +0000
Subject: Help regarding Cache layout tool
In-Reply-To: <mailman.1947.1272460465.11996.davinci-linux-open-source@linux.davincidsp.com>
References: <mailman.1947.1272460465.11996.davinci-linux-open-source@linux.davincidsp.com>
Message-ID: <COL106-W22390C4D41BBD91908D4C3AB010@phx.gbl>


Hi all,

 

i developed my application based on the "video_copy" example and i success to compile it and run/utilize the codec in my application using CGT v6.1.13,

 

Note:- the codec compilation will result in a file as "lablabla.x64P" that may application use it at run time.

 

now i want some optimizations so i used CGT v7.0.1

i added the option "--gen_profile_info" in "user.bld" file as below:-

C64P.ccOpts.prefix = "-mv64+ --gen_profile_info";

also i modified the make file that effect linker options as below:-

$(LINK) -o $@ -m app.map -c $^

 

Now i can successfully compile and app.map file exist but when i try to run my application that utlize the generated codec it run slowly, not an issue now, and after closing the application. i search for the file named "pprofout.ppd" but it does not exist.

i want to continue but i can not since next step depend on the generated file.

---------------------------

Any help is highly appreciated

Mohamed AbdElwahed

 
 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with Microsoft?s powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100429/b4923a23/attachment.html>

From mohameeed2010 at hotmail.com  Thu Apr 29 07:13:09 2010
From: mohameeed2010 at hotmail.com (Mohamed AbdElwahed)
Date: Thu, 29 Apr 2010 12:13:09 +0000
Subject: Help regarding Cache layout tool
In-Reply-To: <mailman.1947.1272460465.11996.davinci-linux-open-source@linux.davincidsp.com>
References: <mailman.1947.1272460465.11996.davinci-linux-open-source@linux.davincidsp.com>
Message-ID: <COL106-W37D27AEE3D28F4D6446549AB010@phx.gbl>





Hi all,
i developed my application based on the video_copy example and i success to compile it and run the codec using CGT v6.1.13,
now i want some optimizations so i used CGT v7.0.1
i added the option "--gen_profile_info" in "user.bld" file as below
C64P.ccOpts.prefix = "-mv64+ --gen_profile_info";
also i modified the make file that effect linker options as below
$(LINK) -o $@ -m app.map -c $^
Now i can successfully compile but when i try to run my application that utlize the generated codec it run slowly and after closing it. i search for the file named "pprofout.ppd" but it does not exist.
i want to continue but i can not since next step depend on the generated file.

How to fix this and to have the "pprofout.ppd" file

 

-------------

BEST REGARD


 

 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100429/b56ef49a/attachment.html>

From ipcevm at gmail.com  Thu Apr 29 09:43:13 2010
From: ipcevm at gmail.com (shaofeng zhang)
Date: Thu, 29 Apr 2010 22:43:13 +0800
Subject: Why can not I ping several cameras for the same time?
Message-ID: <q2hf1c20a311004290743r33faf829p71c0faf8737b919f@mail.gmail.com>

Hi, all
I developed several Network Cameras base on DaVinci DM6446 platform, but I
found that when I connect them on the same network,such as 192.168.0.xxx
When I power on them, I found that I can not ping them at the same time.
That means when I make only one Camera working, I could ping it well,
but two or more cameras works on, I could not ping them at the same
time?
Anyone could tell me about some problems about that? Such as,the conflict
between MAC addr, the network heavy load, or some other hardware faults!
Thank you~

-- 
Best Regards!                   zhangshaofeng
       @Xi'an JiaoTong University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100429/53b60b72/attachment.html>

From khilman at deeprootsystems.com  Thu Apr 29 09:44:14 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 29 Apr 2010 07:44:14 -0700
Subject: [PATCH 02/14] omap: Make uncompress code and DEBUG_LL code generic
In-Reply-To: <20100126201239.15382.34792.stgit@baageli.muru.com>
References: <20100126200646.15382.52167.stgit@baageli.muru.com>
	<20100126201239.15382.34792.stgit@baageli.muru.com>
Message-ID: <1272552254.3051.121.camel@localhost>

On Tue, 2010-01-26 at 12:12 -0800, Tony Lindgren wrote:
> Define arch_decomp_setup() the same way as some other
> architectures do. Use arch_id to configure the debug uart
> based on the machine_is by storing it into the uart
> scratchpad register for DEBUG_LL code to use.
> 
> Note that to avoid merge conflicts, this patch is using
> hardcoded register r1 until tmp register is being passed
> for all addruart macros.
> 
> Signed-off-by: Tony Lindgren <tony at atomide.com>

This has been working well, but has a couple serious limitations:

1. assumes bootloader has enabled UART1 clocks
2. assumes all SoCs supported have the same UART1 base

With more platforms using USB-based UARTs, assumption (1) may not be
safe for very long, as bootloaders for these platforms don't really
*need* to enable UART1.  Currently, they happen to mainly because of
copied init code from other platforms. 

But more importantly, there are more OMAP derivative parts coming soon,
and one in particular coming soon[1] breaks assumption 2 by having a
different UART1 base (yes, it's branded as a DaVinci, but it's an OMAP
core as far as linux is concerned.  Don't get me started on TI
branding.)

To fix both problems, maybe we should just use a fixed memory location
to pass this temporary data from uncompress to the kernel.  We've had a
similar problem on DaVinci recently and a proposal has been made (and
tested) to use memory just below the page tables[2].)

Any comments on this proposal?  or alternative suggestions?

Kevin

[1] http://www.ti.com/ww/en/dsp/davinci-netra/index.shtml
[2] https://patchwork.kernel.org/patch/94724/


From todd.fischer at ridgerun.com  Thu Apr 29 09:54:05 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Thu, 29 Apr 2010 08:54:05 -0600
Subject: Why can not I ping several cameras for the same time?
In-Reply-To: <q2hf1c20a311004290743r33faf829p71c0faf8737b919f@mail.gmail.com>
References: <q2hf1c20a311004290743r33faf829p71c0faf8737b919f@mail.gmail.com>
Message-ID: <1272552845.25762.22960.camel@sax-lx>

Sounds like they all have the same Ethernet MAC address.  On each unit,
run

ifconfig eth0

and you should get output like:

root at arago:/# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:08:EE:03:85:87  
          inet addr:10.0.0.181  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::208:eeff:fe03:8587/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:68440 errors:0 dropped:0 overruns:0 frame:38
          TX packets:25533 errors:0 dropped:0 overruns:1 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:75131751 (71.6 MiB)  TX bytes:4378782 (4.1 MiB)
          Interrupt:33 

Look at the HWaddr and make sure each one has a unique value.  If they
all have the same value, I suspect you can set the MAC address by
passing the value from the bootloader to the kernel via the kernel
command line.

Also, when I have networking problems, I find wireshark very helpful to
figure out what is going on.

Todd


On Thu, 2010-04-29 at 22:43 +0800, shaofeng zhang wrote:

> Hi, all
> 
> I developed several Network Cameras base on DaVinci DM6446 platform,
> but I found that when I connect them on the same network,such as
> 192.168.0.xxx
> When I power on them, I found that I can not ping them at the same
> time.
> That means when I make only one Camera working, I could ping it well, but two or more cameras works on, I could not ping them at the same time?
> Anyone could tell me about some problems about that? Such as,the
> conflict between MAC addr,
> the network heavy load, or some other hardware faults!
> Thank you~
> 
> -- 
> Best Regards!                   zhangshaofeng
>              @Xi'an JiaoTong University
> 
> 
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100429/8a0e304b/attachment-0001.html>

From Dudi.Dolev at dspg.com  Sat Apr 24 14:21:51 2010
From: Dudi.Dolev at dspg.com (Dudi Dolev)
Date: Sat, 24 Apr 2010 22:21:51 +0300
Subject: GIT Kernel
Message-ID: <71D9F169A5BDCD4D8D52CFC9AF872B3501552BAD@ILMAIL01.dspg.com>

Hi

 

I'm looking for the latest V4l2 display drivers for the Video Processing
Back end of DaVinci (such ad OSD).

 

Can you please direct (give me URL, FTP or  GIT) me to the DaVinci Linux
kernel?

 

Best regards,

 

Dudi Dolev

Software Development Engineer

Tel. +972-9-9529-674

dudi.dolev at dspg.com

www.dspg.com <http://www.dspg.com/> 

 


______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using MessageLabs Email Security System.
_____________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100424/2305590e/attachment.html>

From cyril at ti.com  Thu Apr 29 17:27:26 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 29 Apr 2010 18:27:26 -0400
Subject: [RFC 00/22] Davinci: pre-tnetv107x ioremap() cleanup
Message-ID: <1272580062-17663-1-git-send-email-cyril@ti.com>

Hi,

This series takes a new approach to the ioremap() conundrum posed by the
introduction of the tnetv107x architecture.

Unlike earlier approaches, no new init time interfaces have been added in this
implementation.  Instead, this series converts the contents of davinci_soc_info
to use physical instead of virtual addresses.  These physical addresses are
then ioremap()ed as necessary in each individual module (psc, timer, etc.).

As a pleasant side-effect, this series also gets rid of a bunch of IO_ADDRESS()
uses. :-)

These changes were tested only on the tnetv107x evm platform.

- Cyril.


Cyril Chemparathy (22):
  Davinci: generalized debug macros
  Davinci: gpio - minor cleanup
  Davinci: gpio - structs and functions renamed
  Davinci: gpio - register layout invariant inlines
  Davinci: gpio - controller type support
  Davinci: gpio - fine grained locking
  Davinci: gpio - use ioremap()
  Davinci: da8xx: rtc - use ioremap
  Davinci: jtag_id - use ioremap()
  Davinci: timer - use ioremap()
  Davinci: psc - use ioremap()
  Davinci: aintc/cpintc - use ioremap()
  Davinci: pinmux - use ioremap()
  Davinci: eliminate pinmux offset verbosity
  Davinci: watchdog reset separation across socs
  Davinci: iotable based ioremap() interception

 arch/arm/mach-davinci/Kconfig                    |   12 +
 arch/arm/mach-davinci/Makefile                   |    3 +
 arch/arm/mach-davinci/board-da830-evm.c          |   10 +-
 arch/arm/mach-davinci/board-da850-evm.c          |   10 +-
 arch/arm/mach-davinci/board-dm355-evm.c          |    7 +-
 arch/arm/mach-davinci/board-dm355-leopard.c      |    7 +-
 arch/arm/mach-davinci/board-dm365-evm.c          |    7 +-
 arch/arm/mach-davinci/board-dm644x-evm.c         |    7 +-
 arch/arm/mach-davinci/board-dm646x-evm.c         |    9 +-
 arch/arm/mach-davinci/board-neuros-osd2.c        |    7 +-
 arch/arm/mach-davinci/board-sffsdr.c             |    7 +-
 arch/arm/mach-davinci/clock.c                    |   14 +-
 arch/arm/mach-davinci/clock.h                    |    1 +
 arch/arm/mach-davinci/common.c                   |   54 +-
 arch/arm/mach-davinci/cp_intc.c                  |   18 +-
 arch/arm/mach-davinci/da830.c                    |   29 +-
 arch/arm/mach-davinci/da850.c                    |   30 +-
 arch/arm/mach-davinci/devices-da8xx.c            |   15 +-
 arch/arm/mach-davinci/devices.c                  |    4 +-
 arch/arm/mach-davinci/dm355.c                    |   19 +-
 arch/arm/mach-davinci/dm365.c                    |   19 +-
 arch/arm/mach-davinci/dm644x.c                   |   17 +-
 arch/arm/mach-davinci/dm646x.c                   |   17 +-
 arch/arm/mach-davinci/gpio.c                     |  147 ++-
 arch/arm/mach-davinci/include/mach/common.h      |   20 +-
 arch/arm/mach-davinci/include/mach/cp_intc.h     |    3 +-
 arch/arm/mach-davinci/include/mach/da8xx.h       |   23 +-
 arch/arm/mach-davinci/include/mach/debug-macro.S |   50 +-
 arch/arm/mach-davinci/include/mach/gpio.h        |   73 +-
 arch/arm/mach-davinci/include/mach/mux.h         |    2 +
 arch/arm/mach-davinci/include/mach/serial.h      |   21 +
 arch/arm/mach-davinci/include/mach/system.h      |    5 +-
 arch/arm/mach-davinci/include/mach/uncompress.h  |   87 +-
 arch/arm/mach-davinci/io.c                       |   20 +-
 arch/arm/mach-davinci/irq.c                      |    7 +-
 arch/arm/mach-davinci/mux.c                      |   12 +-
 arch/arm/mach-davinci/mux.h                      |    2 +-
 arch/arm/mach-davinci/psc.c                      |    7 +-
 arch/arm/mach-davinci/time.c                     |   31 +-

From cyril at ti.com  Thu Apr 29 17:27:28 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 29 Apr 2010 18:27:28 -0400
Subject: [RFC 02/22] Davinci: gpio - minor cleanup
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com>
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <1272580062-17663-3-git-send-email-cyril@ti.com>

macroized repeated container_of()s to improve readability.
unified direction in/out functions.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/gpio.c |   50 ++++++++++++++++++++++-------------------
 1 files changed, 27 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index 5476ad1..93f7c68 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -28,6 +28,9 @@ struct davinci_gpio {
 	int			irq_base;
 };
 
+#define chip2controller(chip)	\
+	container_of(chip, struct davinci_gpio, chip)
+
 static struct davinci_gpio chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
 
 /* create a non-inlined version */
@@ -54,21 +57,39 @@ static int __init davinci_gpio_irq_setup(void);
  * needed, and enable the GPIO clock.
  */
 
-static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
+static inline int __davinci_direction(struct gpio_chip *chip,
+			unsigned offset, bool out, int value)
 {
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+	struct davinci_gpio *d = chip2controller(chip);
 	struct gpio_controller __iomem *g = d->regs;
 	u32 temp;
+	u32 mask = 1 << offset;
 
 	spin_lock(&gpio_lock);
 	temp = __raw_readl(&g->dir);
-	temp |= (1 << offset);
+	if (out) {
+		temp &= ~mask;
+		__raw_writel(mask, value ? &g->set_data : &g->clr_data);
+	} else {
+		temp |= mask;
+	}
 	__raw_writel(temp, &g->dir);
 	spin_unlock(&gpio_lock);
 
 	return 0;
 }
 
+static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
+{
+	return __davinci_direction(chip, offset, false, 0);
+}
+
+static int
+davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
+{
+	return __davinci_direction(chip, offset, true, value);
+}
+
 /*
  * Read the pin's value (works even if it's set up as output);
  * returns zero/nonzero.
@@ -78,36 +99,19 @@ static int davinci_direction_in(struct gpio_chip *chip, unsigned offset)
  */
 static int davinci_gpio_get(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+	struct davinci_gpio *d = chip2controller(chip);
 	struct gpio_controller __iomem *g = d->regs;
 
 	return (1 << offset) & __raw_readl(&g->in_data);
 }
 
-static int
-davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
-{
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
-	struct gpio_controller __iomem *g = d->regs;
-	u32 temp;
-	u32 mask = 1 << offset;
-
-	spin_lock(&gpio_lock);
-	temp = __raw_readl(&g->dir);
-	temp &= ~mask;
-	__raw_writel(mask, value ? &g->set_data : &g->clr_data);
-	__raw_writel(temp, &g->dir);
-	spin_unlock(&gpio_lock);
-	return 0;
-}
-
 /*
  * Assuming the pin is muxed as a gpio output, set its output value.
  */
 static void
 davinci_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
 {
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+	struct davinci_gpio *d = chip2controller(chip);
 	struct gpio_controller __iomem *g = d->regs;
 
 	__raw_writel((1 << offset), value ? &g->set_data : &g->clr_data);
@@ -262,7 +266,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
 
 static int gpio_to_irq_banked(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+	struct davinci_gpio *d = chip2controller(chip);
 
 	if (d->irq_base >= 0)
 		return d->irq_base + offset;
-- 
1.7.0.4


From cyril at ti.com  Thu Apr 29 17:27:27 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 29 Apr 2010 18:27:27 -0400
Subject: [RFC 01/22] Davinci: generalized debug macros
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com>
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <1272580062-17663-2-git-send-email-cyril@ti.com>

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 macros through a small chunk of memory placed just
below the page tables (@0x80003ff8).

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 arch/arm/mach-davinci/include/mach/debug-macro.S |   50 +++++++++++---
 arch/arm/mach-davinci/include/mach/serial.h      |   13 ++++
 arch/arm/mach-davinci/include/mach/uncompress.h  |   80 ++++++++++++++++------
 3 files changed, 111 insertions(+), 32 deletions(-)

diff --git a/arch/arm/mach-davinci/include/mach/debug-macro.S b/arch/arm/mach-davinci/include/mach/debug-macro.S
index 3cd93a8..f761dfd 100644
--- a/arch/arm/mach-davinci/include/mach/debug-macro.S
+++ b/arch/arm/mach-davinci/include/mach/debug-macro.S
@@ -17,22 +17,50 @@
  */
 
 #include <linux/serial_reg.h>
+
+#include <asm/memory.h>
+
+#include <mach/serial.h>
+
 #define UART_SHIFT	2
 
+		.pushsection .data
+davinci_uart_phys:	.word	0
+davinci_uart_virt:	.word	0
+		.popsection
+
 		.macro addruart, rx, tmp
+
+		/* Use davinci_uart_phys/virt if already configured */
+10:		mrc	p15, 0, \rx, c1, c0
+		tst	\rx, #1			@ MMU enabled?
+		ldreq	\rx, =__virt_to_phys(davinci_uart_phys)
+		ldrne	\rx, =davinci_uart_virt
+		ldr	\rx, [\rx]
+		cmp	\rx, #0			@ is port configured?
+		bne	99f			@ already configured
+
 		mrc	p15, 0, \rx, c1, c0
 		tst	\rx, #1			@ MMU enabled?
-		moveq	\rx, #0x01000000	@ physical base address
-		movne	\rx, #0xfe000000	@ virtual base
-#if defined(CONFIG_ARCH_DAVINCI_DA8XX) && defined(CONFIG_ARCH_DAVINCI_DMx)
-#error Cannot enable DaVinci and DA8XX platforms concurrently
-#elif defined(CONFIG_MACH_DAVINCI_DA830_EVM) || \
-	defined(CONFIG_MACH_DAVINCI_DA850_EVM)
-		orr	\rx, \rx, #0x00d00000	@ physical base address
-		orr	\rx, \rx, #0x0000d000	@ of UART 2
-#else
-		orr	\rx, \rx, #0x00c20000   @ UART 0
-#endif
+
+		/* Copy uart phys address from decompressor uart info */
+		ldreq	\tmp, =__virt_to_phys(davinci_uart_phys)
+		ldrne	\tmp, =davinci_uart_phys
+		ldreq	\rx, =DAVINCI_UART_INFO
+		ldrne	\rx, =__phys_to_virt(DAVINCI_UART_INFO)
+		ldr	\rx, [\rx, #0]
+		str	\rx, [\tmp]
+
+		/* Copy uart virt address from decompressor uart info */
+		ldreq	\tmp, =__virt_to_phys(davinci_uart_virt)
+		ldrne	\tmp, =davinci_uart_virt
+		ldreq	\rx, =DAVINCI_UART_INFO
+		ldrne	\rx, =__phys_to_virt(DAVINCI_UART_INFO)
+		ldr	\rx, [\rx, #4]
+		str	\rx, [\tmp]
+
+		b	10b
+99:
 		.endm
 
 		.macro	senduart,rd,rx
diff --git a/arch/arm/mach-davinci/include/mach/serial.h b/arch/arm/mach-davinci/include/mach/serial.h
index a584697..8829dde 100644
--- a/arch/arm/mach-davinci/include/mach/serial.h
+++ b/arch/arm/mach-davinci/include/mach/serial.h
@@ -11,8 +11,19 @@
 #ifndef __ASM_ARCH_SERIAL_H
 #define __ASM_ARCH_SERIAL_H
 
+#include <asm/memory.h>
+
 #include <mach/hardware.h>
 
+/*
+ * Stolen area that contains debug uart physical and virtual addresses.  These
+ * addresses are filled in by the uncompress.h code, and are used by the debug
+ * macros in debug-macro.S.
+ *
+ * This area sits just below the page tables (see arch/arm/kernel/head.S).
+ */
+#define DAVINCI_UART_INFO	(PHYS_OFFSET + 0x3ff8)
+
 #define DAVINCI_MAX_NR_UARTS	3
 #define DAVINCI_UART0_BASE	(IO_PHYS + 0x20000)
 #define DAVINCI_UART1_BASE	(IO_PHYS + 0x20400)
@@ -27,11 +38,13 @@
 #define UART_DM646X_SCR			0x10
 #define UART_DM646X_SCR_TX_WATERMARK	0x08
 
+#ifndef __ASSEMBLY__
 struct davinci_uart_config {
 	/* Bit field of UARTs present; bit 0 --> UART1 */
 	unsigned int enabled_uarts;
 };
 
 extern int davinci_serial_init(struct davinci_uart_config *);
+#endif
 
 #endif /* __ASM_ARCH_SERIAL_H */
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
index 33796b4..20c23a3 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -1,8 +1,17 @@
 /*
  * Serial port stubs for kernel decompress status messages
  *
- *  Author:     Anant Gole
- * (C) Copyright (C) 2006, Texas Instruments, Inc
+ * Initially based on:
+ * arch/arm/plat-omap/include/mach/uncompress.h
+ *
+ * Original copyrights follow.
+ *
+ * Copyright (C) 2000 RidgeRun, Inc.
+ * Author: Greg Lonnon <glonnon at ridgerun.com>
+ *
+ * Rewritten by:
+ * Author: <source at mvista.com>
+ * 2004 (c) MontaVista Software, Inc.
  *
  * This file is licensed under the terms of the GNU General Public License
  * version 2. This program is licensed "as is" without any warranty of any
@@ -11,30 +20,17 @@
 
 #include <linux/types.h>
 #include <linux/serial_reg.h>
-#include <mach/serial.h>
 
 #include <asm/mach-types.h>
 
-extern unsigned int __machine_arch_type;
+#include <mach/serial.h>
 
 static u32 *uart;
-
-static u32 *get_uart_base(void)
-{
-	if (__machine_arch_type == MACH_TYPE_DAVINCI_DA830_EVM ||
-		__machine_arch_type == MACH_TYPE_DAVINCI_DA850_EVM)
-		return (u32 *)DA8XX_UART2_BASE;
-	else
-		return (u32 *)DAVINCI_UART0_BASE;
-}
+static u32 *uart_info = (u32 *)(DAVINCI_UART_INFO);
 
 /* PORT_16C550A, in polled non-fifo mode */
-
 static void putc(char c)
 {
-	if (!uart)
-		uart = get_uart_base();
-
 	while (!(uart[UART_LSR] & UART_LSR_THRE))
 		barrier();
 	uart[UART_TX] = c;
@@ -42,12 +38,54 @@ static void putc(char c)
 
 static inline void flush(void)
 {
-	if (!uart)
-		uart = get_uart_base();
-
 	while (!(uart[UART_LSR] & UART_LSR_THRE))
 		barrier();
 }
 
-#define arch_decomp_setup()
+static inline void set_uart_info(u32 phys, void * __iomem virt)
+{
+	uart = (u32 *)phys;
+	uart_info[0] = phys;
+	uart_info[1] = (u32)virt;
+}
+
+#define _DEBUG_LL_ENTRY(machine, phys, virt)			\
+	if (machine_is_##machine()) {				\
+		set_uart_info(phys, virt);			\
+		break;						\
+	}
+
+#define DEBUG_LL_DAVINCI(machine, port)				\
+	_DEBUG_LL_ENTRY(machine, DAVINCI_UART##port##_BASE,	\
+			IO_ADDRESS(DAVINCI_UART##port##_BASE))
+
+#define DEBUG_LL_DA8XX(machine, port)				\
+	_DEBUG_LL_ENTRY(machine, DA8XX_UART##port##_BASE,	\
+			IO_ADDRESS(DA8XX_UART##port##_BASE))
+
+static inline void __arch_decomp_setup(unsigned long arch_id)
+{
+	/*
+	 * Initialize the port based on the machine ID from the bootloader.
+	 * Note that we're using macros here instead of switch statement
+	 * as machine_is functions are optimized out for the boards that
+	 * are not selected.
+	 */
+	do {
+		/* Davinci boards */
+		DEBUG_LL_DAVINCI(davinci_evm,		0);
+		DEBUG_LL_DAVINCI(sffsdr,		0);
+		DEBUG_LL_DAVINCI(neuros_osd2,		0);
+		DEBUG_LL_DAVINCI(davinci_dm355_evm,	0);
+		DEBUG_LL_DAVINCI(dm355_leopard,		0);
+		DEBUG_LL_DAVINCI(davinci_dm6467_evm,	0);
+		DEBUG_LL_DAVINCI(davinci_dm365_evm,	0);
+
+		/* DA8xx boards */
+		DEBUG_LL_DA8XX(davinci_da830_evm,	2);
+		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
+	} while (0);
+}
+
+#define arch_decomp_setup()	__arch_decomp_setup(arch_id)
 #define arch_decomp_wdog()
-- 
1.7.0.4


From cyril at ti.com  Thu Apr 29 17:27:30 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 29 Apr 2010 18:27:30 -0400
Subject: [RFC 04/22] Davinci: gpio - register layout invariant inlines
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com>
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <1272580062-17663-5-git-send-email-cyril@ti.com>

This patch renders the inlined gpio accessors in gpio.h independent of the
underlying controller's register layout.  This is done by including three new
fields in davinci_gpio_controller to hold the addresses of the set, clear, and
in data registers.

Other changes:

1. davinci_gpio_regs structure definition moved to gpio.c.  This structure is
no longer common across all davinci socs (davinci_gpio_controller is).

2. controller base address calculation code (gpio2controller()) moved to
gpio.c as this was no longer necessary for the inline implementation.

3. modified inline range checks to use davinci_soc_info.gpio_num instead of
DAVINCI_N_GPIO.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/gpio.c                |   41 ++++++++++++++++-
 arch/arm/mach-davinci/include/mach/common.h |    4 ++
 arch/arm/mach-davinci/include/mach/gpio.h   |   65 +++++++++-----------------
 3 files changed, 65 insertions(+), 45 deletions(-)

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index c77683c..d241b4f 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -20,6 +20,19 @@
 
 #include <asm/mach/irq.h>
 
+struct davinci_gpio_regs {
+	u32	dir;
+	u32	out_data;
+	u32	set_data;
+	u32	clr_data;
+	u32	in_data;
+	u32	set_rising;
+	u32	clr_rising;
+	u32	set_falling;
+	u32	clr_falling;
+	u32	intstat;
+};
+
 static DEFINE_SPINLOCK(gpio_lock);
 
 #define chip2controller(chip)	\
@@ -27,10 +40,24 @@ static DEFINE_SPINLOCK(gpio_lock);
 
 static struct davinci_gpio_controller chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
 
-/* create a non-inlined version */
 static struct davinci_gpio_regs __iomem __init *gpio2regs(unsigned gpio)
 {
-	return __gpio_to_controller(gpio);
+	void __iomem *ptr;
+	void __iomem *base = davinci_soc_info.gpio_base;
+
+	if (gpio < 32 * 1)
+		ptr = base + 0x10;
+	else if (gpio < 32 * 2)
+		ptr = base + 0x38;
+	else if (gpio < 32 * 3)
+		ptr = base + 0x60;
+	else if (gpio < 32 * 4)
+		ptr = base + 0x88;
+	else if (gpio < 32 * 5)
+		ptr = base + 0xb0;
+	else
+		ptr = NULL;
+	return ptr;
 }
 
 static inline struct davinci_gpio_regs __iomem *irq2regs(int irq)
@@ -116,6 +143,7 @@ static int __init davinci_gpio_setup(void)
 	int i, base;
 	unsigned ngpio;
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
+	struct davinci_gpio_regs *regs;
 
 	/*
 	 * The gpio banks conceptually expose a segmented bitmap,
@@ -144,11 +172,18 @@ static int __init davinci_gpio_setup(void)
 		if (chips[i].chip.ngpio > 32)
 			chips[i].chip.ngpio = 32;
 
-		chips[i].regs = gpio2regs(base);
+		regs = gpio2regs(base);
+		chips[i].regs = regs;
+		chips[i].set_data = &regs->set_data;
+		chips[i].clr_data = &regs->clr_data;
+		chips[i].in_data = &regs->in_data;
 
 		gpiochip_add(&chips[i].chip);
 	}
 
+	soc_info->gpio_ctlrs = chips;
+	soc_info->gpio_ctlrs_num = DIV_ROUND_UP(ngpio, 32);
+
 	davinci_gpio_irq_setup();
 	return 0;
 }
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 884dc72..1d72883 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -37,6 +37,8 @@ struct davinci_timer_info {
 	unsigned int			clocksource_id;
 };
 
+struct davinci_gpio_controller;
+
 /* SoC specific init support */
 struct davinci_soc_info {
 	struct map_desc			*io_desc;
@@ -61,6 +63,8 @@ struct davinci_soc_info {
 	unsigned			gpio_num;
 	unsigned			gpio_irq;
 	unsigned			gpio_unbanked;
+	struct davinci_gpio_controller	*gpio_ctlrs;
+	int				gpio_ctlrs_num;
 	struct platform_device		*serial_dev;
 	struct emac_platform_data	*emac_pdata;
 	dma_addr_t			sram_dma;
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index bdab001..82591d0 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -45,23 +45,13 @@
 /* Convert GPIO signal to GPIO pin number */
 #define GPIO_TO_PIN(bank, gpio)	(16 * (bank) + (gpio))
 
-struct davinci_gpio_regs {
-	u32	dir;
-	u32	out_data;
-	u32	set_data;
-	u32	clr_data;
-	u32	in_data;
-	u32	set_rising;
-	u32	clr_rising;
-	u32	set_falling;
-	u32	clr_falling;
-	u32	intstat;
-};
-
 struct davinci_gpio_controller {
-	struct davinci_gpio_regs __iomem *regs;
 	struct gpio_chip	chip;
 	int			irq_base;
+	void __iomem		*regs;
+	void __iomem		*set_data;
+	void __iomem		*clr_data;
+	void __iomem		*in_data;
 };
 
 /* The __gpio_to_controller() and __gpio_mask() functions inline to constants
@@ -73,25 +63,16 @@ struct davinci_gpio_controller {
  *
  * These are NOT part of the cross-platform GPIO interface
  */
-static inline struct davinci_gpio_regs __iomem *
+static inline struct davinci_gpio_controller *
 __gpio_to_controller(unsigned gpio)
 {
-	void __iomem *ptr;
-	void __iomem *base = davinci_soc_info.gpio_base;
-
-	if (gpio < 32 * 1)
-		ptr = base + 0x10;
-	else if (gpio < 32 * 2)
-		ptr = base + 0x38;
-	else if (gpio < 32 * 3)
-		ptr = base + 0x60;
-	else if (gpio < 32 * 4)
-		ptr = base + 0x88;
-	else if (gpio < 32 * 5)
-		ptr = base + 0xb0;
-	else
-		ptr = NULL;
-	return ptr;
+	struct davinci_gpio_controller *ctlrs = davinci_soc_info.gpio_ctlrs;
+	int index = gpio / 32;
+
+	if (!ctlrs || index >= davinci_soc_info.gpio_ctlrs_num)
+		return NULL;
+
+	return ctlrs + index;
 }
 
 static inline u32 __gpio_mask(unsigned gpio)
@@ -107,16 +88,16 @@ static inline u32 __gpio_mask(unsigned gpio)
  */
 static inline void gpio_set_value(unsigned gpio, int value)
 {
-	if (__builtin_constant_p(value) && gpio < DAVINCI_N_GPIO) {
-		struct davinci_gpio_regs	__iomem *g;
-		u32			mask;
+	if (__builtin_constant_p(value) && gpio < davinci_soc_info.gpio_num) {
+		struct davinci_gpio_controller *ctlr;
+		u32				mask;
 
-		g = __gpio_to_controller(gpio);
+		ctlr = __gpio_to_controller(gpio);
 		mask = __gpio_mask(gpio);
 		if (value)
-			__raw_writel(mask, &g->set_data);
+			__raw_writel(mask, ctlr->set_data);
 		else
-			__raw_writel(mask, &g->clr_data);
+			__raw_writel(mask, ctlr->clr_data);
 		return;
 	}
 
@@ -134,18 +115,18 @@ static inline void gpio_set_value(unsigned gpio, int value)
  */
 static inline int gpio_get_value(unsigned gpio)
 {
-	struct davinci_gpio_regs	__iomem *g;
+	struct davinci_gpio_controller *ctlr;
 
-	if (!__builtin_constant_p(gpio) || gpio >= DAVINCI_N_GPIO)
+	if (!__builtin_constant_p(gpio) || gpio >= davinci_soc_info.gpio_num)
 		return __gpio_get_value(gpio);
 
-	g = __gpio_to_controller(gpio);
-	return __gpio_mask(gpio) & __raw_readl(&g->in_data);
+	ctlr = __gpio_to_controller(gpio);
+	return __gpio_mask(gpio) & __raw_readl(ctlr->in_data);
 }
 
 static inline int gpio_cansleep(unsigned gpio)
 {
-	if (__builtin_constant_p(gpio) && gpio < DAVINCI_N_GPIO)
+	if (__builtin_constant_p(gpio) && gpio < davinci_soc_info.gpio_num)
 		return 0;
 	else
 		return __gpio_cansleep(gpio);
-- 
1.7.0.4


From cyril at ti.com  Thu Apr 29 17:27:34 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 29 Apr 2010 18:27:34 -0400
Subject: [RFC 08/22] Davinci: da8xx: rtc - use ioremap
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com>
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <1272580062-17663-9-git-send-email-cyril@ti.com>

This patch modifies the RTC unlock code to use ioremap() maps instead of
IO_ADDRESS() translation.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 arch/arm/mach-davinci/devices-da8xx.c |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index 0a96791..825a7c2 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -584,10 +584,17 @@ static struct platform_device da8xx_rtc_device = {
 int da8xx_register_rtc(void)
 {
 	int ret;
+	void __iomem *base;
+
+	base = ioremap(DA8XX_RTC_BASE, SZ_4K);
+	if (WARN_ON(!base))
+		return -EINVAL;
 
 	/* Unlock the rtc's registers */
-	__raw_writel(0x83e70b13, IO_ADDRESS(DA8XX_RTC_BASE + 0x6c));
-	__raw_writel(0x95a4f1e0, IO_ADDRESS(DA8XX_RTC_BASE + 0x70));
+	__raw_writel(0x83e70b13, base + 0x6c);
+	__raw_writel(0x95a4f1e0, base + 0x70);
+
+	iounmap(base);
 
 	ret = platform_device_register(&da8xx_rtc_device);
 	if (!ret)
-- 
1.7.0.4


From cyril at ti.com  Thu Apr 29 17:27:37 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 29 Apr 2010 18:27:37 -0400
Subject: [RFC 11/22] Davinci: psc - use ioremap()
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com>
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <1272580062-17663-12-git-send-email-cyril@ti.com>

This patch modifies the psc and clock control code to use ioremap()ed
registers.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 arch/arm/mach-davinci/clock.c               |   14 +++++++++++---
 arch/arm/mach-davinci/da830.c               |    5 +----
 arch/arm/mach-davinci/da850.c               |    5 +----
 arch/arm/mach-davinci/dm355.c               |    4 +---
 arch/arm/mach-davinci/dm365.c               |    4 +---
 arch/arm/mach-davinci/dm644x.c              |    4 +---
 arch/arm/mach-davinci/dm646x.c              |    4 +---
 arch/arm/mach-davinci/include/mach/common.h |    2 +-
 arch/arm/mach-davinci/psc.c                 |    7 +++++--
 9 files changed, 23 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
index 868cb76..3e2cbbe 100644
--- a/arch/arm/mach-davinci/clock.c
+++ b/arch/arm/mach-davinci/clock.c
@@ -302,7 +302,6 @@ static unsigned long clk_pllclk_recalc(struct clk *clk)
 	struct pll_data *pll = clk->pll_data;
 	unsigned long rate = clk->rate;
 
-	pll->base = IO_ADDRESS(pll->phys_base);
 	ctrl = __raw_readl(pll->base + PLLCTL);
 	rate = pll->input_rate = clk->parent->rate;
 
@@ -458,8 +457,17 @@ int __init davinci_clk_init(struct clk_lookup *clocks)
 				clk->recalc = clk_leafclk_recalc;
 		}
 
-		if (clk->pll_data && !clk->pll_data->div_ratio_mask)
-			clk->pll_data->div_ratio_mask = PLLDIV_RATIO_MASK;
+		if (clk->pll_data) {
+			struct pll_data *pll = clk->pll_data;
+
+			if (!pll->div_ratio_mask)
+				pll->div_ratio_mask = PLLDIV_RATIO_MASK;
+
+			if (pll->phys_base && !pll->base) {
+				pll->base = ioremap(pll->phys_base, SZ_4K);
+				BUG_ON(!pll->base);
+			}
+		}
 
 		if (clk->recalc)
 			clk->rate = clk->recalc(clk);
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 68a518f..132b489 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1127,10 +1127,7 @@ static struct map_desc da830_io_desc[] = {
 	},
 };
 
-static void __iomem *da830_psc_bases[] = {
-	IO_ADDRESS(DA8XX_PSC0_BASE),
-	IO_ADDRESS(DA8XX_PSC1_BASE),
-};
+static u32 da830_psc_bases[] = { DA8XX_PSC0_BASE, DA8XX_PSC1_BASE };
 
 /* Contents of JTAG ID register used to identify exact cpu type */
 static struct davinci_id da830_ids[] = {
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 5188b51..0f404cc 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -782,10 +782,7 @@ static struct map_desc da850_io_desc[] = {
 	},
 };
 
-static void __iomem *da850_psc_bases[] = {
-	IO_ADDRESS(DA8XX_PSC0_BASE),
-	IO_ADDRESS(DA8XX_PSC1_BASE),
-};
+static u32 da850_psc_bases[] = { DA8XX_PSC0_BASE, DA8XX_PSC1_BASE };
 
 /* Contents of JTAG ID register used to identify exact cpu type */
 static struct davinci_id da850_ids[] = {
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index c1104b6..9f1ce53 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -788,9 +788,7 @@ static struct davinci_id dm355_ids[] = {
 	},
 };
 
-static void __iomem *dm355_psc_bases[] = {
-	IO_ADDRESS(DAVINCI_PWR_SLEEP_CNTRL_BASE),
-};
+static u32 dm355_psc_bases[] = { DAVINCI_PWR_SLEEP_CNTRL_BASE };
 
 /*
  * T0_BOT: Timer 0, bottom:  clockevent source for hrtimers
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 0adc4d1..d92d50f 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1007,9 +1007,7 @@ static struct davinci_id dm365_ids[] = {
 	},
 };
 
-static void __iomem *dm365_psc_bases[] = {
-	IO_ADDRESS(DAVINCI_PWR_SLEEP_CNTRL_BASE),
-};
+static u32 dm365_psc_bases[] = { DAVINCI_PWR_SLEEP_CNTRL_BASE };
 
 static struct davinci_timer_info dm365_timer_info = {
 	.timers		= davinci_timer_instance,
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index e8b208c..8d69827 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -677,9 +677,7 @@ static struct davinci_id dm644x_ids[] = {
 	},
 };
 
-static void __iomem *dm644x_psc_bases[] = {
-	IO_ADDRESS(DAVINCI_PWR_SLEEP_CNTRL_BASE),
-};
+static u32 dm644x_psc_bases[] = { DAVINCI_PWR_SLEEP_CNTRL_BASE };
 
 /*
  * T0_BOT: Timer 0, bottom:  clockevent source for hrtimers
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 917f09f..5fe7744 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -761,9 +761,7 @@ static struct davinci_id dm646x_ids[] = {
 	},
 };
 
-static void __iomem *dm646x_psc_bases[] = {
-	IO_ADDRESS(DAVINCI_PWR_SLEEP_CNTRL_BASE),
-};
+static u32 dm646x_psc_bases[] = { DAVINCI_PWR_SLEEP_CNTRL_BASE };
 
 /*
  * T0_BOT: Timer 0, bottom:  clockevent source for hrtimers
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index b2ab985..013c882 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -49,7 +49,7 @@ struct davinci_soc_info {
 	struct davinci_id		*ids;
 	unsigned long			ids_num;
 	struct clk_lookup		*cpu_clks;
-	void __iomem			**psc_bases;
+	u32	 			*psc_bases;
 	unsigned long			psc_bases_num;
 	void __iomem			*pinmux_base;
 	const struct mux_config		*pinmux_pins;
diff --git a/arch/arm/mach-davinci/psc.c b/arch/arm/mach-davinci/psc.c
index d7cb438..1b15dbd 100644
--- a/arch/arm/mach-davinci/psc.c
+++ b/arch/arm/mach-davinci/psc.c
@@ -38,8 +38,9 @@ int __init davinci_psc_is_clk_active(unsigned int ctlr, unsigned int id)
 		return 0;
 	}
 
-	psc_base = soc_info->psc_bases[ctlr];
+	psc_base = ioremap(soc_info->psc_bases[ctlr], SZ_4K);
 	mdstat = __raw_readl(psc_base + MDSTAT + 4 * id);
+	iounmap(psc_base);
 
 	/* if clocked, state can be "Enable" or "SyncReset" */
 	return mdstat & BIT(12);
@@ -59,7 +60,7 @@ void davinci_psc_config(unsigned int domain, unsigned int ctlr,
 		return;
 	}
 
-	psc_base = soc_info->psc_bases[ctlr];
+	psc_base = ioremap(soc_info->psc_bases[ctlr], SZ_4K);
 
 	mdctl = __raw_readl(psc_base + MDCTL + 4 * id);
 	mdctl &= ~MDSTAT_STATE_MASK;
@@ -99,4 +100,6 @@ void davinci_psc_config(unsigned int domain, unsigned int ctlr,
 	do {
 		mdstat = __raw_readl(psc_base + MDSTAT + 4 * id);
 	} while (!((mdstat & MDSTAT_STATE_MASK) == next_state));
+
+	iounmap(psc_base);
 }
-- 
1.7.0.4


From cyril at ti.com  Thu Apr 29 17:27:33 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 29 Apr 2010 18:27:33 -0400
Subject: [RFC 07/22] Davinci: gpio - use ioremap()
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com>
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <1272580062-17663-8-git-send-email-cyril@ti.com>

This patch modifies the gpio_base definition in davinci_soc_info to be a
physical address, which is then ioremap()ed by the gpio initialization
function.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 arch/arm/mach-davinci/da830.c               |    2 +-
 arch/arm/mach-davinci/da850.c               |    2 +-
 arch/arm/mach-davinci/dm355.c               |    2 +-
 arch/arm/mach-davinci/dm365.c               |    2 +-
 arch/arm/mach-davinci/dm644x.c              |    2 +-
 arch/arm/mach-davinci/dm646x.c              |    2 +-
 arch/arm/mach-davinci/gpio.c                |   16 ++++++++++------
 arch/arm/mach-davinci/include/mach/common.h |    2 +-
 8 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 68e5233..84786ec 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1201,7 +1201,7 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
 	.intc_irq_num		= DA830_N_CP_INTC_IRQ,
 	.timer_info		= &da830_timer_info,
 	.gpio_type		= GPIO_TYPE_DAVINCI,
-	.gpio_base		= IO_ADDRESS(DA8XX_GPIO_BASE),
+	.gpio_base		= DA8XX_GPIO_BASE,
 	.gpio_num		= 128,
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
 	.serial_dev		= &da8xx_serial_device,
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 8aefcff..0697cfa 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1086,7 +1086,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.intc_irq_num		= DA850_N_CP_INTC_IRQ,
 	.timer_info		= &da850_timer_info,
 	.gpio_type		= GPIO_TYPE_DAVINCI,
-	.gpio_base		= IO_ADDRESS(DA8XX_GPIO_BASE),
+	.gpio_base		= DA8XX_GPIO_BASE,
 	.gpio_num		= 144,
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
 	.serial_dev		= &da8xx_serial_device,
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index f9a54ff..70c3032 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -860,7 +860,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm355_timer_info,
 	.gpio_type		= GPIO_TYPE_DAVINCI,
-	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
+	.gpio_base		= DAVINCI_GPIO_BASE,
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM355_GPIOBNK0,
 	.serial_dev		= &dm355_serial_device,
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 0566675..59bf298 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1065,7 +1065,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm365_timer_info,
 	.gpio_type		= GPIO_TYPE_DAVINCI,
-	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
+	.gpio_base		= DAVINCI_GPIO_BASE,
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM365_GPIO0,
 	.gpio_unbanked		= 8,	/* really 16 ... skip muxed GPIOs */
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 4af349e..2916b27 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -749,7 +749,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm644x_timer_info,
 	.gpio_type		= GPIO_TYPE_DAVINCI,
-	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
+	.gpio_base		= DAVINCI_GPIO_BASE,
 	.gpio_num		= 71,
 	.gpio_irq		= IRQ_GPIOBNK0,
 	.serial_dev		= &dm644x_serial_device,
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index bdb1ace..236f14f 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -833,7 +833,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm646x_timer_info,
 	.gpio_type		= GPIO_TYPE_DAVINCI,
-	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
+	.gpio_base		= DAVINCI_GPIO_BASE,
 	.gpio_num		= 43, /* Only 33 usable */
 	.gpio_irq		= IRQ_DM646X_GPIOBNK0,
 	.serial_dev		= &dm646x_serial_device,
diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index b62d5e2..e845966 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -37,22 +37,22 @@ struct davinci_gpio_regs {
 	container_of(chip, struct davinci_gpio_controller, chip)
 
 static struct davinci_gpio_controller chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
+static void __iomem *gpio_base;
 
 static struct davinci_gpio_regs __iomem __init *gpio2regs(unsigned gpio)
 {
 	void __iomem *ptr;
-	void __iomem *base = davinci_soc_info.gpio_base;
 
 	if (gpio < 32 * 1)
-		ptr = base + 0x10;
+		ptr = gpio_base + 0x10;
 	else if (gpio < 32 * 2)
-		ptr = base + 0x38;
+		ptr = gpio_base + 0x38;
 	else if (gpio < 32 * 3)
-		ptr = base + 0x60;
+		ptr = gpio_base + 0x60;
 	else if (gpio < 32 * 4)
-		ptr = base + 0x88;
+		ptr = gpio_base + 0x88;
 	else if (gpio < 32 * 5)
-		ptr = base + 0xb0;
+		ptr = gpio_base + 0xb0;
 	else
 		ptr = NULL;
 	return ptr;
@@ -161,6 +161,10 @@ static int __init davinci_gpio_setup(void)
 	if (WARN_ON(DAVINCI_N_GPIO < ngpio))
 		ngpio = DAVINCI_N_GPIO;
 
+	gpio_base = ioremap(soc_info->gpio_base, SZ_4K);
+	if (WARN_ON(!gpio_base))
+		return -EINVAL;
+
 	for (i = 0, base = 0; base < ngpio; i++, base += 32) {
 		chips[i].chip.label = "DaVinci";
 
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 8ffef5b..73fe289 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -60,7 +60,7 @@ struct davinci_soc_info {
 	unsigned long			intc_irq_num;
 	struct davinci_timer_info	*timer_info;
 	int				gpio_type;
-	void __iomem			*gpio_base;
+	u32				gpio_base;
 	unsigned			gpio_num;
 	unsigned			gpio_irq;
 	unsigned			gpio_unbanked;
-- 
1.7.0.4


From cyril at ti.com  Thu Apr 29 17:27:39 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 29 Apr 2010 18:27:39 -0400
Subject: [RFC 13/22] Davinci: pinmux - use ioremap()
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com>
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <1272580062-17663-14-git-send-email-cyril@ti.com>

This patch modifies the pinmux implementation so as to ioremap() the pinmux
register area on first use.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 arch/arm/mach-davinci/da830.c               |    3 +--
 arch/arm/mach-davinci/da850.c               |    3 +--
 arch/arm/mach-davinci/dm355.c               |    2 +-
 arch/arm/mach-davinci/dm365.c               |    2 +-
 arch/arm/mach-davinci/dm644x.c              |    2 +-
 arch/arm/mach-davinci/dm646x.c              |    2 +-
 arch/arm/mach-davinci/include/mach/common.h |    2 +-
 arch/arm/mach-davinci/mux.c                 |   12 +++++++++---
 8 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index bbc6d21..f8fef99 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1191,6 +1191,7 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
 	.cpu_clks		= da830_clks,
 	.psc_bases		= da830_psc_bases,
 	.psc_bases_num		= ARRAY_SIZE(da830_psc_bases),
+	.pinmux_base		= DA8XX_SYSCFG0_BASE + 0x120,
 	.pinmux_pins		= da830_pins,
 	.pinmux_pins_num	= ARRAY_SIZE(da830_pins),
 	.intc_base		= DA8XX_CP_INTC_BASE,
@@ -1212,7 +1213,5 @@ void __init da830_init(void)
 	if (WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module"))
 		return;
 
-	davinci_soc_info_da830.pinmux_base = DA8XX_SYSCFG0_VIRT(0x120);
-
 	davinci_common_init(&davinci_soc_info_da830);
 }
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 5aba1e0..cb56772 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1076,6 +1076,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.cpu_clks		= da850_clks,
 	.psc_bases		= da850_psc_bases,
 	.psc_bases_num		= ARRAY_SIZE(da850_psc_bases),
+	.pinmux_base		= DA8XX_SYSCFG0_BASE + 0x120,
 	.pinmux_pins		= da850_pins,
 	.pinmux_pins_num	= ARRAY_SIZE(da850_pins),
 	.intc_base		= DA8XX_CP_INTC_BASE,
@@ -1105,8 +1106,6 @@ void __init da850_init(void)
 	if (WARN(!da8xx_syscfg1_base, "Unable to map syscfg1 module"))
 		return;
 
-	davinci_soc_info_da850.pinmux_base = DA8XX_SYSCFG0_VIRT(0x120);
-
 	davinci_common_init(&davinci_soc_info_da850);
 
 	/*
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index a89bfbb..44f3940 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -849,7 +849,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.cpu_clks		= dm355_clks,
 	.psc_bases		= dm355_psc_bases,
 	.psc_bases_num		= ARRAY_SIZE(dm355_psc_bases),
-	.pinmux_base		= IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE),
+	.pinmux_base		= DAVINCI_SYSTEM_MODULE_BASE,
 	.pinmux_pins		= dm355_pins,
 	.pinmux_pins_num	= ARRAY_SIZE(dm355_pins),
 	.intc_base		= DAVINCI_ARM_INTC_BASE,
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 1c18bb6..6fec378 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1054,7 +1054,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.cpu_clks		= dm365_clks,
 	.psc_bases		= dm365_psc_bases,
 	.psc_bases_num		= ARRAY_SIZE(dm365_psc_bases),
-	.pinmux_base		= IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE),
+	.pinmux_base		= DAVINCI_SYSTEM_MODULE_BASE,
 	.pinmux_pins		= dm365_pins,
 	.pinmux_pins_num	= ARRAY_SIZE(dm365_pins),
 	.intc_base		= DAVINCI_ARM_INTC_BASE,
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index c1c208e..e89adcf 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -738,7 +738,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.cpu_clks		= dm644x_clks,
 	.psc_bases		= dm644x_psc_bases,
 	.psc_bases_num		= ARRAY_SIZE(dm644x_psc_bases),
-	.pinmux_base		= IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE),
+	.pinmux_base		= DAVINCI_SYSTEM_MODULE_BASE,
 	.pinmux_pins		= dm644x_pins,
 	.pinmux_pins_num	= ARRAY_SIZE(dm644x_pins),
 	.intc_base		= DAVINCI_ARM_INTC_BASE,
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 9898035..e760448 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -822,7 +822,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.cpu_clks		= dm646x_clks,
 	.psc_bases		= dm646x_psc_bases,
 	.psc_bases_num		= ARRAY_SIZE(dm646x_psc_bases),
-	.pinmux_base		= IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE),
+	.pinmux_base		= DAVINCI_SYSTEM_MODULE_BASE,
 	.pinmux_pins		= dm646x_pins,
 	.pinmux_pins_num	= ARRAY_SIZE(dm646x_pins),
 	.intc_base		= DAVINCI_ARM_INTC_BASE,
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index a7087d7..835422d 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -51,7 +51,7 @@ struct davinci_soc_info {
 	struct clk_lookup		*cpu_clks;
 	u32	 			*psc_bases;
 	unsigned long			psc_bases_num;
-	void __iomem			*pinmux_base;
+	u32				pinmux_base;
 	const struct mux_config		*pinmux_pins;
 	unsigned long			pinmux_pins_num;
 	u32				intc_base;
diff --git a/arch/arm/mach-davinci/mux.c b/arch/arm/mach-davinci/mux.c
index e9d530a..28b1b83 100644
--- a/arch/arm/mach-davinci/mux.c
+++ b/arch/arm/mach-davinci/mux.c
@@ -22,6 +22,8 @@
 #include <mach/mux.h>
 #include <mach/common.h>
 
+static void __iomem *pinmux_base;
+
 /*
  * Sets the DAVINCI MUX register based on the table
  */
@@ -29,7 +31,6 @@ int __init_or_module davinci_cfg_reg(const unsigned long index)
 {
 	static DEFINE_SPINLOCK(mux_spin_lock);
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
-	void __iomem *base = soc_info->pinmux_base;
 	unsigned long flags;
 	const struct mux_config *cfg;
 	unsigned int reg_orig = 0, reg = 0;
@@ -38,6 +39,11 @@ int __init_or_module davinci_cfg_reg(const unsigned long index)
 	if (!soc_info->pinmux_pins)
 		BUG();
 
+	if (!pinmux_base) {
+		pinmux_base = ioremap(soc_info->pinmux_base, SZ_4K);
+		BUG_ON(!pinmux_base);
+	}
+
 	if (index >= soc_info->pinmux_pins_num) {
 		printk(KERN_ERR "Invalid pin mux index: %lu (%lu)\n",
 		       index, soc_info->pinmux_pins_num);
@@ -57,7 +63,7 @@ int __init_or_module davinci_cfg_reg(const unsigned long index)
 		unsigned	tmp1, tmp2;
 
 		spin_lock_irqsave(&mux_spin_lock, flags);
-		reg_orig = __raw_readl(base + cfg->mux_reg);
+		reg_orig = __raw_readl(pinmux_base + cfg->mux_reg);
 
 		mask = (cfg->mask << cfg->mask_offset);
 		tmp1 = reg_orig & mask;
@@ -69,7 +75,7 @@ int __init_or_module davinci_cfg_reg(const unsigned long index)
 		if (tmp1 != tmp2)
 			warn = 1;
 
-		__raw_writel(reg, base + cfg->mux_reg);
+		__raw_writel(reg, pinmux_base + cfg->mux_reg);
 		spin_unlock_irqrestore(&mux_spin_lock, flags);
 	}
 
-- 
1.7.0.4


From cyril at ti.com  Thu Apr 29 17:27:29 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 29 Apr 2010 18:27:29 -0400
Subject: [RFC 03/22] Davinci: gpio - structs and functions renamed
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com>
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <1272580062-17663-4-git-send-email-cyril@ti.com>

Renamed gpio types to something more sensible:
	struct gpio_controller	--> struct davinci_gpio_regs
	struct davinci_gpio	--> struct davinci_gpio_controller
	gpio2controller()	--> gpio2regs()
	irq2controller()	--> irq2regs()

This change also moves davinci_gpio_controller definition to gpio.h.
Eventually, the gpio registers structure will be moved to gpio.c and no longer
a common cross-soc definition.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/gpio.c              |   50 +++++++++++++----------------
 arch/arm/mach-davinci/include/mach/gpio.h |   14 ++++++--
 2 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index 93f7c68..c77683c 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -22,28 +22,22 @@
 
 static DEFINE_SPINLOCK(gpio_lock);
 
-struct davinci_gpio {
-	struct gpio_chip	chip;
-	struct gpio_controller	__iomem *regs;
-	int			irq_base;
-};
-
 #define chip2controller(chip)	\
-	container_of(chip, struct davinci_gpio, chip)
+	container_of(chip, struct davinci_gpio_controller, chip)
 
-static struct davinci_gpio chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
+static struct davinci_gpio_controller chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
 
 /* create a non-inlined version */
-static struct gpio_controller __iomem __init *gpio2controller(unsigned gpio)
+static struct davinci_gpio_regs __iomem __init *gpio2regs(unsigned gpio)
 {
 	return __gpio_to_controller(gpio);
 }
 
-static inline struct gpio_controller __iomem *irq2controller(int irq)
+static inline struct davinci_gpio_regs __iomem *irq2regs(int irq)
 {
-	struct gpio_controller __iomem *g;
+	struct davinci_gpio_regs __iomem *g;
 
-	g = (__force struct gpio_controller __iomem *)get_irq_chip_data(irq);
+	g = (__force struct davinci_gpio_regs __iomem *)get_irq_chip_data(irq);
 
 	return g;
 }
@@ -60,8 +54,8 @@ static int __init davinci_gpio_irq_setup(void);
 static inline int __davinci_direction(struct gpio_chip *chip,
 			unsigned offset, bool out, int value)
 {
-	struct davinci_gpio *d = chip2controller(chip);
-	struct gpio_controller __iomem *g = d->regs;
+	struct davinci_gpio_controller *d = chip2controller(chip);
+	struct davinci_gpio_regs __iomem *g = d->regs;
 	u32 temp;
 	u32 mask = 1 << offset;
 
@@ -99,8 +93,8 @@ davinci_direction_out(struct gpio_chip *chip, unsigned offset, int value)
  */
 static int davinci_gpio_get(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = chip2controller(chip);
-	struct gpio_controller __iomem *g = d->regs;
+	struct davinci_gpio_controller *d = chip2controller(chip);
+	struct davinci_gpio_regs __iomem *g = d->regs;
 
 	return (1 << offset) & __raw_readl(&g->in_data);
 }
@@ -111,8 +105,8 @@ static int davinci_gpio_get(struct gpio_chip *chip, unsigned offset)
 static void
 davinci_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
 {
-	struct davinci_gpio *d = chip2controller(chip);
-	struct gpio_controller __iomem *g = d->regs;
+	struct davinci_gpio_controller *d = chip2controller(chip);
+	struct davinci_gpio_regs __iomem *g = d->regs;
 
 	__raw_writel((1 << offset), value ? &g->set_data : &g->clr_data);
 }
@@ -150,7 +144,7 @@ static int __init davinci_gpio_setup(void)
 		if (chips[i].chip.ngpio > 32)
 			chips[i].chip.ngpio = 32;
 
-		chips[i].regs = gpio2controller(base);
+		chips[i].regs = gpio2regs(base);
 
 		gpiochip_add(&chips[i].chip);
 	}
@@ -174,7 +168,7 @@ pure_initcall(davinci_gpio_setup);
 
 static void gpio_irq_disable(unsigned irq)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2regs(irq);
 	u32 mask = (u32) get_irq_data(irq);
 
 	__raw_writel(mask, &g->clr_falling);
@@ -183,7 +177,7 @@ static void gpio_irq_disable(unsigned irq)
 
 static void gpio_irq_enable(unsigned irq)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2regs(irq);
 	u32 mask = (u32) get_irq_data(irq);
 	unsigned status = irq_desc[irq].status;
 
@@ -199,7 +193,7 @@ static void gpio_irq_enable(unsigned irq)
 
 static int gpio_irq_type(unsigned irq, unsigned trigger)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2regs(irq);
 	u32 mask = (u32) get_irq_data(irq);
 
 	if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
@@ -228,7 +222,7 @@ static struct irq_chip gpio_irqchip = {
 static void
 gpio_irq_handler(unsigned irq, struct irq_desc *desc)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2regs(irq);
 	u32 mask = 0xffff;
 
 	/* we only care about one bank */
@@ -266,7 +260,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
 
 static int gpio_to_irq_banked(struct gpio_chip *chip, unsigned offset)
 {
-	struct davinci_gpio *d = chip2controller(chip);
+	struct davinci_gpio_controller *d = chip2controller(chip);
 
 	if (d->irq_base >= 0)
 		return d->irq_base + offset;
@@ -289,7 +283,7 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset)
 
 static int gpio_irq_type_unbanked(unsigned irq, unsigned trigger)
 {
-	struct gpio_controller __iomem *g = irq2controller(irq);
+	struct davinci_gpio_regs __iomem *g = irq2regs(irq);
 	u32 mask = (u32) get_irq_data(irq);
 
 	if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
@@ -318,7 +312,7 @@ static int __init davinci_gpio_irq_setup(void)
 	u32		binten = 0;
 	unsigned	ngpio, bank_irq;
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
-	struct gpio_controller	__iomem *g;
+	struct davinci_gpio_regs	__iomem *g;
 
 	ngpio = soc_info->gpio_num;
 
@@ -367,7 +361,7 @@ static int __init davinci_gpio_irq_setup(void)
 		gpio_irqchip_unbanked.set_type = gpio_irq_type_unbanked;
 
 		/* default trigger: both edges */
-		g = gpio2controller(0);
+		g = gpio2regs(0);
 		__raw_writel(~0, &g->set_falling);
 		__raw_writel(~0, &g->set_rising);
 
@@ -392,7 +386,7 @@ static int __init davinci_gpio_irq_setup(void)
 		unsigned		i;
 
 		/* disabled by default, enabled only as needed */
-		g = gpio2controller(gpio);
+		g = gpio2regs(gpio);
 		__raw_writel(~0, &g->clr_falling);
 		__raw_writel(~0, &g->clr_rising);
 
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index 0099e6e..bdab001 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -45,7 +45,7 @@
 /* Convert GPIO signal to GPIO pin number */
 #define GPIO_TO_PIN(bank, gpio)	(16 * (bank) + (gpio))
 
-struct gpio_controller {
+struct davinci_gpio_regs {
 	u32	dir;
 	u32	out_data;
 	u32	set_data;
@@ -58,6 +58,12 @@ struct gpio_controller {
 	u32	intstat;
 };
 
+struct davinci_gpio_controller {
+	struct davinci_gpio_regs __iomem *regs;
+	struct gpio_chip	chip;
+	int			irq_base;
+};
+
 /* The __gpio_to_controller() and __gpio_mask() functions inline to constants
  * with constant parameters; or in outlined code they execute at runtime.
  *
@@ -67,7 +73,7 @@ struct gpio_controller {
  *
  * These are NOT part of the cross-platform GPIO interface
  */
-static inline struct gpio_controller __iomem *
+static inline struct davinci_gpio_regs __iomem *
 __gpio_to_controller(unsigned gpio)
 {
 	void __iomem *ptr;
@@ -102,7 +108,7 @@ static inline u32 __gpio_mask(unsigned gpio)
 static inline void gpio_set_value(unsigned gpio, int value)
 {
 	if (__builtin_constant_p(value) && gpio < DAVINCI_N_GPIO) {
-		struct gpio_controller	__iomem *g;
+		struct davinci_gpio_regs	__iomem *g;
 		u32			mask;
 
 		g = __gpio_to_controller(gpio);
@@ -128,7 +134,7 @@ static inline void gpio_set_value(unsigned gpio, int value)
  */
 static inline int gpio_get_value(unsigned gpio)
 {
-	struct gpio_controller	__iomem *g;
+	struct davinci_gpio_regs	__iomem *g;
 
 	if (!__builtin_constant_p(gpio) || gpio >= DAVINCI_N_GPIO)
 		return __gpio_get_value(gpio);
-- 
1.7.0.4


From cyril at ti.com  Thu Apr 29 17:27:32 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 29 Apr 2010 18:27:32 -0400
Subject: [RFC 06/22] Davinci: gpio - fine grained locking
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com>
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <1272580062-17663-7-git-send-email-cyril@ti.com>

This patch eliminates the global gpio_lock, and implements a per-controller
lock instead.  This also switches to irqsave/irqrestore locks in case gpios
are manipulated in isr.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/gpio.c              |    9 +++++----
 arch/arm/mach-davinci/include/mach/gpio.h |    3 +++
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index e422cd3..b62d5e2 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -33,8 +33,6 @@ struct davinci_gpio_regs {
 	u32	intstat;
 };
 
-static DEFINE_SPINLOCK(gpio_lock);
-
 #define chip2controller(chip)	\
 	container_of(chip, struct davinci_gpio_controller, chip)
 
@@ -83,10 +81,11 @@ static inline int __davinci_direction(struct gpio_chip *chip,
 {
 	struct davinci_gpio_controller *d = chip2controller(chip);
 	struct davinci_gpio_regs __iomem *g = d->regs;
+	unsigned long flags;
 	u32 temp;
 	u32 mask = 1 << offset;
 
-	spin_lock(&gpio_lock);
+	spin_lock_irqsave(&d->lock, flags);
 	temp = __raw_readl(&g->dir);
 	if (out) {
 		temp &= ~mask;
@@ -95,7 +94,7 @@ static inline int __davinci_direction(struct gpio_chip *chip,
 		temp |= mask;
 	}
 	__raw_writel(temp, &g->dir);
-	spin_unlock(&gpio_lock);
+	spin_unlock_irqrestore(&d->lock, flags);
 
 	return 0;
 }
@@ -175,6 +174,8 @@ static int __init davinci_gpio_setup(void)
 		if (chips[i].chip.ngpio > 32)
 			chips[i].chip.ngpio = 32;
 
+		spin_lock_init(&chips[i].lock);
+
 		regs = gpio2regs(base);
 		chips[i].regs = regs;
 		chips[i].set_data = &regs->set_data;
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index 9a71a26..504cc18 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -14,6 +14,8 @@
 #define	__DAVINCI_GPIO_H
 
 #include <linux/io.h>
+#include <linux/spinlock.h>
+
 #include <asm-generic/gpio.h>
 
 #include <mach/irqs.h>
@@ -52,6 +54,7 @@ enum davinci_gpio_type {
 struct davinci_gpio_controller {
 	struct gpio_chip	chip;
 	int			irq_base;
+	spinlock_t		lock;
 	void __iomem		*regs;
 	void __iomem		*set_data;
 	void __iomem		*clr_data;
-- 
1.7.0.4


From cyril at ti.com  Thu Apr 29 17:27:36 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 29 Apr 2010 18:27:36 -0400
Subject: [RFC 10/22] Davinci: timer - use ioremap()
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com>
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <1272580062-17663-11-git-send-email-cyril@ti.com>

This patch eliminates IO_ADDRESS() usage for Davinci timer definitions.  The
timer code has correspondingly been modified to ioremap() MMRs instead.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 arch/arm/mach-davinci/da830.c               |    4 ++--
 arch/arm/mach-davinci/da850.c               |    8 ++++----
 arch/arm/mach-davinci/devices.c             |    4 ++--
 arch/arm/mach-davinci/include/mach/common.h |    2 +-
 arch/arm/mach-davinci/time.c                |   22 ++++++++++++++--------
 5 files changed, 23 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 4289fb9..68a518f 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1159,14 +1159,14 @@ static struct davinci_id da830_ids[] = {
 
 static struct davinci_timer_instance da830_timer_instance[2] = {
 	{
-		.base		= IO_ADDRESS(DA8XX_TIMER64P0_BASE),
+		.base		= DA8XX_TIMER64P0_BASE,
 		.bottom_irq	= IRQ_DA8XX_TINT12_0,
 		.top_irq	= IRQ_DA8XX_TINT34_0,
 		.cmp_off	= DA830_CMP12_0,
 		.cmp_irq	= IRQ_DA830_T12CMPINT0_0,
 	},
 	{
-		.base		= IO_ADDRESS(DA8XX_TIMER64P1_BASE),
+		.base		= DA8XX_TIMER64P1_BASE,
 		.bottom_irq	= IRQ_DA8XX_TINT12_1,
 		.top_irq	= IRQ_DA8XX_TINT34_1,
 		.cmp_off	= DA830_CMP12_0,
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 6287ed4..5188b51 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -800,22 +800,22 @@ static struct davinci_id da850_ids[] = {
 
 static struct davinci_timer_instance da850_timer_instance[4] = {
 	{
-		.base		= IO_ADDRESS(DA8XX_TIMER64P0_BASE),
+		.base		= DA8XX_TIMER64P0_BASE,
 		.bottom_irq	= IRQ_DA8XX_TINT12_0,
 		.top_irq	= IRQ_DA8XX_TINT34_0,
 	},
 	{
-		.base		= IO_ADDRESS(DA8XX_TIMER64P1_BASE),
+		.base		= DA8XX_TIMER64P1_BASE,
 		.bottom_irq	= IRQ_DA8XX_TINT12_1,
 		.top_irq	= IRQ_DA8XX_TINT34_1,
 	},
 	{
-		.base		= IO_ADDRESS(DA850_TIMER64P2_BASE),
+		.base		= DA850_TIMER64P2_BASE,
 		.bottom_irq	= IRQ_DA850_TINT12_2,
 		.top_irq	= IRQ_DA850_TINT34_2,
 	},
 	{
-		.base		= IO_ADDRESS(DA850_TIMER64P3_BASE),
+		.base		= DA850_TIMER64P3_BASE,
 		.bottom_irq	= IRQ_DA850_TINT12_3,
 		.top_irq	= IRQ_DA850_TINT34_3,
 	},
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index d9c82ee..8b7201e 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -297,12 +297,12 @@ static void davinci_init_wdt(void)
 
 struct davinci_timer_instance davinci_timer_instance[2] = {
 	{
-		.base		= IO_ADDRESS(DAVINCI_TIMER0_BASE),
+		.base		= DAVINCI_TIMER0_BASE,
 		.bottom_irq	= IRQ_TINT0_TINT12,
 		.top_irq	= IRQ_TINT0_TINT34,
 	},
 	{
-		.base		= IO_ADDRESS(DAVINCI_TIMER1_BASE),
+		.base		= DAVINCI_TIMER1_BASE,
 		.bottom_irq	= IRQ_TINT1_TINT12,
 		.top_irq	= IRQ_TINT1_TINT34,
 	},
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 9feccd5..b2ab985 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -24,7 +24,7 @@ extern void __iomem *davinci_intc_base;
 extern int davinci_intc_type;
 
 struct davinci_timer_instance {
-	void __iomem	*base;
+	u32		base;
 	u32		bottom_irq;
 	u32		top_irq;
 	unsigned long	cmp_off;
diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index b21f763..6c7b0e2 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c
@@ -197,32 +197,36 @@ static void __init timer_init(void)
 {
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
 	struct davinci_timer_instance *dtip = soc_info->timer_info->timers;
+	void __iomem *base[2];
 	int i;
 
 	/* Global init of each 64-bit timer as a whole */
 	for(i=0; i<2; i++) {
 		u32 tgcr;
-		void __iomem *base = dtip[i].base;
+
+		base[i] = ioremap(dtip[i].base, SZ_4K);
+		if (WARN_ON(!base[i]))
+			continue;
 
 		/* Disabled, Internal clock source */
-		__raw_writel(0, base + TCR);
+		__raw_writel(0, base[i] + TCR);
 
 		/* reset both timers, no pre-scaler for timer34 */
 		tgcr = 0;
-		__raw_writel(tgcr, base + TGCR);
+		__raw_writel(tgcr, base[i] + TGCR);
 
 		/* Set both timers to unchained 32-bit */
 		tgcr = TGCR_TIMMODE_32BIT_UNCHAINED << TGCR_TIMMODE_SHIFT;
-		__raw_writel(tgcr, base + TGCR);
+		__raw_writel(tgcr, base[i] + TGCR);
 
 		/* Unreset timers */
 		tgcr |= (TGCR_UNRESET << TGCR_TIM12RS_SHIFT) |
 			(TGCR_UNRESET << TGCR_TIM34RS_SHIFT);
-		__raw_writel(tgcr, base + TGCR);
+		__raw_writel(tgcr, base[i] + TGCR);
 
 		/* Init both counters to zero */
-		__raw_writel(0, base + TIM12);
-		__raw_writel(0, base + TIM34);
+		__raw_writel(0, base[i] + TIM12);
+		__raw_writel(0, base[i] + TIM34);
 	}
 
 	/* Init of each timer as a 32-bit timer */
@@ -231,7 +235,9 @@ static void __init timer_init(void)
 		int timer = ID_TO_TIMER(t->id);
 		u32 irq;
 
-		t->base = dtip[timer].base;
+		t->base = base[timer];
+		if (!t->base)
+			continue;
 
 		if (IS_TIMER_BOT(t->id)) {
 			t->enamode_shift = 6;
-- 
1.7.0.4


From cyril at ti.com  Thu Apr 29 17:27:38 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 29 Apr 2010 18:27:38 -0400
Subject: [RFC 12/22] Davinci: aintc/cpintc - use ioremap()
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com>
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <1272580062-17663-13-git-send-email-cyril@ti.com>

This patch implements the following:

 - interrupt initialization uses ioremap() instead of passing a virtual address
   via davinci_soc_info.

 - machine definitions directly point to cp_intc_init() or davinci_irq_init()

 - davinci_intc_type and davinci_intc_base now get initialized in controller
   specific init functions instead of davinci_common_init()

 - minor fix in davinci_irq_init() to use intc_irq_num instead of
   DAVINCI_N_AINTC_IRQ

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 arch/arm/mach-davinci/board-da830-evm.c      |   10 +---------
 arch/arm/mach-davinci/board-da850-evm.c      |   10 +---------
 arch/arm/mach-davinci/board-dm355-evm.c      |    7 +------
 arch/arm/mach-davinci/board-dm355-leopard.c  |    7 +------
 arch/arm/mach-davinci/board-dm365-evm.c      |    7 +------
 arch/arm/mach-davinci/board-dm644x-evm.c     |    7 +------
 arch/arm/mach-davinci/board-dm646x-evm.c     |    9 ++-------
 arch/arm/mach-davinci/board-neuros-osd2.c    |    7 +------
 arch/arm/mach-davinci/board-sffsdr.c         |    7 +------
 arch/arm/mach-davinci/common.c               |    2 --
 arch/arm/mach-davinci/cp_intc.c              |   18 +++++++++++-------
 arch/arm/mach-davinci/da830.c                |    2 +-
 arch/arm/mach-davinci/da850.c                |    2 +-
 arch/arm/mach-davinci/dm355.c                |    2 +-
 arch/arm/mach-davinci/dm365.c                |    2 +-
 arch/arm/mach-davinci/dm644x.c               |    2 +-
 arch/arm/mach-davinci/dm646x.c               |    2 +-
 arch/arm/mach-davinci/include/mach/common.h  |    3 ++-
 arch/arm/mach-davinci/include/mach/cp_intc.h |    3 +--
 arch/arm/mach-davinci/irq.c                  |    7 ++++++-
 20 files changed, 36 insertions(+), 80 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 8f079d2..212d970 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -561,14 +561,6 @@ static int __init da830_evm_console_init(void)
 console_initcall(da830_evm_console_init);
 #endif
 
-static __init void da830_evm_irq_init(void)
-{
-	struct davinci_soc_info *soc_info = &davinci_soc_info;
-
-	cp_intc_init((void __iomem *)DA8XX_CP_INTC_VIRT, DA830_N_CP_INTC_IRQ,
-			soc_info->intc_irq_prios, NULL);
-}
-
 static void __init da830_evm_map_io(void)
 {
 	da830_init();
@@ -579,7 +571,7 @@ MACHINE_START(DAVINCI_DA830_EVM, "DaVinci DA830/OMAP-L137 EVM")
 	.io_pg_offst	= (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
 	.boot_params	= (DA8XX_DDR_BASE + 0x100),
 	.map_io		= da830_evm_map_io,
-	.init_irq	= da830_evm_irq_init,
+	.init_irq	= cp_intc_init,
 	.timer		= &davinci_timer,
 	.init_machine	= da830_evm_init,
 MACHINE_END
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 6c137e0..abd0493 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -736,14 +736,6 @@ static int __init da850_evm_console_init(void)
 console_initcall(da850_evm_console_init);
 #endif
 
-static __init void da850_evm_irq_init(void)
-{
-	struct davinci_soc_info *soc_info = &davinci_soc_info;
-
-	cp_intc_init((void __iomem *)DA8XX_CP_INTC_VIRT, DA850_N_CP_INTC_IRQ,
-			soc_info->intc_irq_prios, NULL);
-}
-
 static void __init da850_evm_map_io(void)
 {
 	da850_init();
@@ -754,7 +746,7 @@ MACHINE_START(DAVINCI_DA850_EVM, "DaVinci DA850/OMAP-L138 EVM")
 	.io_pg_offst	= (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
 	.boot_params	= (DA8XX_DDR_BASE + 0x100),
 	.map_io		= da850_evm_map_io,
-	.init_irq	= da850_evm_irq_init,
+	.init_irq	= cp_intc_init,
 	.timer		= &davinci_timer,
 	.init_machine	= da850_evm_init,
 MACHINE_END
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
index a0ad7d9..a319101 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -350,17 +350,12 @@ static __init void dm355_evm_init(void)
 	dm355_init_asp1(ASP1_TX_EVT_EN | ASP1_RX_EVT_EN, &dm355_evm_snd_data);
 }
 
-static __init void dm355_evm_irq_init(void)
-{
-	davinci_irq_init();
-}
-
 MACHINE_START(DAVINCI_DM355_EVM, "DaVinci DM355 EVM")
 	.phys_io      = IO_PHYS,
 	.io_pg_offst  = (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
 	.boot_params  = (0x80000100),
 	.map_io	      = dm355_evm_map_io,
-	.init_irq     = dm355_evm_irq_init,
+	.init_irq     = davinci_irq_init,
 	.timer	      = &davinci_timer,
 	.init_machine = dm355_evm_init,
 MACHINE_END
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c
index c3d5a70..f1d8132 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -269,17 +269,12 @@ static __init void dm355_leopard_init(void)
 			ARRAY_SIZE(dm355_leopard_spi_info));
 }
 
-static __init void dm355_leopard_irq_init(void)
-{
-	davinci_irq_init();
-}
-
 MACHINE_START(DM355_LEOPARD, "DaVinci DM355 leopard")
 	.phys_io      = IO_PHYS,
 	.io_pg_offst  = (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
 	.boot_params  = (0x80000100),
 	.map_io	      = dm355_leopard_map_io,
-	.init_irq     = dm355_leopard_irq_init,
+	.init_irq     = davinci_irq_init,
 	.timer	      = &davinci_timer,
 	.init_machine = dm355_leopard_init,
 MACHINE_END
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index b98b35c..98814e6 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -608,17 +608,12 @@ static __init void dm365_evm_init(void)
 			ARRAY_SIZE(dm365_evm_spi_info));
 }
 
-static __init void dm365_evm_irq_init(void)
-{
-	davinci_irq_init();
-}
-
 MACHINE_START(DAVINCI_DM365_EVM, "DaVinci DM365 EVM")
 	.phys_io	= IO_PHYS,
 	.io_pg_offst	= (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
 	.boot_params	= (0x80000100),
 	.map_io		= dm365_evm_map_io,
-	.init_irq	= dm365_evm_irq_init,
+	.init_irq	= davinci_irq_init,
 	.timer		= &davinci_timer,
 	.init_machine	= dm365_evm_init,
 MACHINE_END
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 73c0b04..34c8b41 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -704,18 +704,13 @@ static __init void davinci_evm_init(void)
 
 }
 
-static __init void davinci_evm_irq_init(void)
-{
-	davinci_irq_init();
-}
-
 MACHINE_START(DAVINCI_EVM, "DaVinci DM644x EVM")
 	/* Maintainer: MontaVista Software <source at mvista.com> */
 	.phys_io      = IO_PHYS,
 	.io_pg_offst  = (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
 	.boot_params  = (DAVINCI_DDR_BASE + 0x100),
 	.map_io	      = davinci_evm_map_io,
-	.init_irq     = davinci_evm_irq_init,
+	.init_irq     = davinci_irq_init,
 	.timer	      = &davinci_timer,
 	.init_machine = davinci_evm_init,
 MACHINE_END
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index e2ac06f..6d88893 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -739,11 +739,6 @@ static __init void evm_init(void)
 	soc_info->emac_pdata->mdio_max_freq = DM646X_EVM_MDIO_FREQUENCY;
 }
 
-static __init void davinci_dm646x_evm_irq_init(void)
-{
-	davinci_irq_init();
-}
-
 #define DM646X_EVM_REF_FREQ		27000000
 #define DM6467T_EVM_REF_FREQ		33000000
 
@@ -760,7 +755,7 @@ MACHINE_START(DAVINCI_DM6467_EVM, "DaVinci DM646x EVM")
 	.io_pg_offst  = (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
 	.boot_params  = (0x80000100),
 	.map_io       = davinci_map_io,
-	.init_irq     = davinci_dm646x_evm_irq_init,
+	.init_irq     = davinci_irq_init,
 	.timer        = &davinci_timer,
 	.init_machine = evm_init,
 MACHINE_END
@@ -770,7 +765,7 @@ MACHINE_START(DAVINCI_DM6467TEVM, "DaVinci DM6467T EVM")
 	.io_pg_offst  = (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
 	.boot_params  = (0x80000100),
 	.map_io       = davinci_map_io,
-	.init_irq     = davinci_dm646x_evm_irq_init,
+	.init_irq     = davinci_irq_init,
 	.timer        = &davinci_timer,
 	.init_machine = evm_init,
 MACHINE_END
diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c
index 875770c..4c30e92 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -273,18 +273,13 @@ static __init void davinci_ntosd2_init(void)
 	davinci_setup_mmc(0, &davinci_ntosd2_mmc_config);
 }
 
-static __init void davinci_ntosd2_irq_init(void)
-{
-	davinci_irq_init();
-}
-
 MACHINE_START(NEUROS_OSD2, "Neuros OSD2")
 	/* Maintainer: Neuros Technologies <neuros at groups.google.com> */
 	.phys_io	= IO_PHYS,
 	.io_pg_offst	= (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
 	.boot_params	= (DAVINCI_DDR_BASE + 0x100),
 	.map_io		 = davinci_ntosd2_map_io,
-	.init_irq	= davinci_ntosd2_irq_init,
+	.init_irq	= davinci_irq_init,
 	.timer		= &davinci_timer,
 	.init_machine = davinci_ntosd2_init,
 MACHINE_END
diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c
index 1ed0662..23e664a 100644
--- a/arch/arm/mach-davinci/board-sffsdr.c
+++ b/arch/arm/mach-davinci/board-sffsdr.c
@@ -152,18 +152,13 @@ static __init void davinci_sffsdr_init(void)
 	davinci_cfg_reg(DM644X_VLYNQWD);
 }
 
-static __init void davinci_sffsdr_irq_init(void)
-{
-	davinci_irq_init();
-}
-
 MACHINE_START(SFFSDR, "Lyrtech SFFSDR")
 	/* Maintainer: Hugo Villeneuve hugo.villeneuve at lyrtech.com */
 	.phys_io      = IO_PHYS,
 	.io_pg_offst  = (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
 	.boot_params  = (DAVINCI_DDR_BASE + 0x100),
 	.map_io	      = davinci_sffsdr_map_io,
-	.init_irq     = davinci_sffsdr_irq_init,
+	.init_irq     = davinci_irq_init,
 	.timer	      = &davinci_timer,
 	.init_machine = davinci_sffsdr_init,
 MACHINE_END
diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c
index d35650f..0398711 100644
--- a/arch/arm/mach-davinci/common.c
+++ b/arch/arm/mach-davinci/common.c
@@ -108,8 +108,6 @@ void __init davinci_common_init(struct davinci_soc_info *soc_info)
 			goto err;
 	}
 
-	davinci_intc_base = davinci_soc_info.intc_base;
-	davinci_intc_type = davinci_soc_info.intc_type;
 	return;
 
 err:
diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
index 2a8d26e..28a3cdb 100644
--- a/arch/arm/mach-davinci/cp_intc.c
+++ b/arch/arm/mach-davinci/cp_intc.c
@@ -13,18 +13,17 @@
 #include <linux/irq.h>
 #include <linux/io.h>
 
+#include <mach/common.h>
 #include <mach/cp_intc.h>
 
-static void __iomem *cp_intc_base;
-
 static inline unsigned int cp_intc_read(unsigned offset)
 {
-	return __raw_readl(cp_intc_base + offset);
+	return __raw_readl(davinci_intc_base + offset);
 }
 
 static inline void cp_intc_write(unsigned long value, unsigned offset)
 {
-	__raw_writel(value, cp_intc_base + offset);
+	__raw_writel(value, davinci_intc_base + offset);
 }
 
 static void cp_intc_ack_irq(unsigned int irq)
@@ -100,13 +99,18 @@ static struct irq_chip cp_intc_irq_chip = {
 	.set_wake	= cp_intc_set_wake,
 };
 
-void __init cp_intc_init(void __iomem *base, unsigned short num_irq,
-			 u8 *irq_prio, u32 *host_map)
+void __init cp_intc_init(void)
 {
+	unsigned long num_irq	= davinci_soc_info.intc_irq_num;
+	u8 *irq_prio		= davinci_soc_info.intc_irq_prios;
+	u32 *host_map		= davinci_soc_info.intc_host_map;
 	unsigned num_reg	= BITS_TO_LONGS(num_irq);
 	int i;
 
-	cp_intc_base = base;
+	davinci_intc_type = DAVINCI_INTC_TYPE_CP_INTC;
+	davinci_intc_base = ioremap(davinci_soc_info.intc_base, SZ_4K);
+	if (WARN_ON(!davinci_intc_base))
+		return;
 
 	cp_intc_write(0, CP_INTC_GLOBAL_ENABLE);
 
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 132b489..bbc6d21 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1193,7 +1193,7 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
 	.psc_bases_num		= ARRAY_SIZE(da830_psc_bases),
 	.pinmux_pins		= da830_pins,
 	.pinmux_pins_num	= ARRAY_SIZE(da830_pins),
-	.intc_base		= (void __iomem *)DA8XX_CP_INTC_VIRT,
+	.intc_base		= DA8XX_CP_INTC_BASE,
 	.intc_type		= DAVINCI_INTC_TYPE_CP_INTC,
 	.intc_irq_prios		= da830_default_priorities,
 	.intc_irq_num		= DA830_N_CP_INTC_IRQ,
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 0f404cc..5aba1e0 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1078,7 +1078,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.psc_bases_num		= ARRAY_SIZE(da850_psc_bases),
 	.pinmux_pins		= da850_pins,
 	.pinmux_pins_num	= ARRAY_SIZE(da850_pins),
-	.intc_base		= (void __iomem *)DA8XX_CP_INTC_VIRT,
+	.intc_base		= DA8XX_CP_INTC_BASE,
 	.intc_type		= DAVINCI_INTC_TYPE_CP_INTC,
 	.intc_irq_prios		= da850_default_priorities,
 	.intc_irq_num		= DA850_N_CP_INTC_IRQ,
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 9f1ce53..a89bfbb 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -852,7 +852,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.pinmux_base		= IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE),
 	.pinmux_pins		= dm355_pins,
 	.pinmux_pins_num	= ARRAY_SIZE(dm355_pins),
-	.intc_base		= IO_ADDRESS(DAVINCI_ARM_INTC_BASE),
+	.intc_base		= DAVINCI_ARM_INTC_BASE,
 	.intc_type		= DAVINCI_INTC_TYPE_AINTC,
 	.intc_irq_prios		= dm355_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index d92d50f..1c18bb6 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1057,7 +1057,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.pinmux_base		= IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE),
 	.pinmux_pins		= dm365_pins,
 	.pinmux_pins_num	= ARRAY_SIZE(dm365_pins),
-	.intc_base		= IO_ADDRESS(DAVINCI_ARM_INTC_BASE),
+	.intc_base		= DAVINCI_ARM_INTC_BASE,
 	.intc_type		= DAVINCI_INTC_TYPE_AINTC,
 	.intc_irq_prios		= dm365_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 8d69827..c1c208e 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -741,7 +741,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.pinmux_base		= IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE),
 	.pinmux_pins		= dm644x_pins,
 	.pinmux_pins_num	= ARRAY_SIZE(dm644x_pins),
-	.intc_base		= IO_ADDRESS(DAVINCI_ARM_INTC_BASE),
+	.intc_base		= DAVINCI_ARM_INTC_BASE,
 	.intc_type		= DAVINCI_INTC_TYPE_AINTC,
 	.intc_irq_prios 	= dm644x_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 5fe7744..9898035 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -825,7 +825,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.pinmux_base		= IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE),
 	.pinmux_pins		= dm646x_pins,
 	.pinmux_pins_num	= ARRAY_SIZE(dm646x_pins),
-	.intc_base		= IO_ADDRESS(DAVINCI_ARM_INTC_BASE),
+	.intc_base		= DAVINCI_ARM_INTC_BASE,
 	.intc_type		= DAVINCI_INTC_TYPE_AINTC,
 	.intc_irq_prios		= dm646x_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 013c882..a7087d7 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -54,10 +54,11 @@ struct davinci_soc_info {
 	void __iomem			*pinmux_base;
 	const struct mux_config		*pinmux_pins;
 	unsigned long			pinmux_pins_num;
-	void __iomem			*intc_base;
+	u32				intc_base;
 	int				intc_type;
 	u8				*intc_irq_prios;
 	unsigned long			intc_irq_num;
+	u32				*intc_host_map;
 	struct davinci_timer_info	*timer_info;
 	int				gpio_type;
 	u32				gpio_base;
diff --git a/arch/arm/mach-davinci/include/mach/cp_intc.h b/arch/arm/mach-davinci/include/mach/cp_intc.h
index 121b114..4e8190e 100644
--- a/arch/arm/mach-davinci/include/mach/cp_intc.h
+++ b/arch/arm/mach-davinci/include/mach/cp_intc.h
@@ -51,7 +51,6 @@
 #define CP_INTC_HOST_PRIO_VECTOR(n)	(0x1600 + (n << 2))
 #define CP_INTC_VECTOR_ADDR(n)		(0x2000 + (n << 2))
 
-void __init cp_intc_init(void __iomem *base, unsigned short num_irq,
-			 u8 *irq_prio, u32 *host_map);
+void __init cp_intc_init(void);
 
 #endif	/* __ASM_HARDWARE_CP_INTC_H */
diff --git a/arch/arm/mach-davinci/irq.c b/arch/arm/mach-davinci/irq.c
index af92ffe..784ddf3 100644
--- a/arch/arm/mach-davinci/irq.c
+++ b/arch/arm/mach-davinci/irq.c
@@ -116,6 +116,11 @@ void __init davinci_irq_init(void)
 	unsigned i;
 	const u8 *davinci_def_priorities = davinci_soc_info.intc_irq_prios;
 
+	davinci_intc_type = DAVINCI_INTC_TYPE_AINTC;
+	davinci_intc_base = ioremap(davinci_soc_info.intc_base, SZ_4K);
+	if (WARN_ON(!davinci_intc_base))
+		return;
+
 	/* Clear all interrupt requests */
 	davinci_irq_writel(~0x0, FIQ_REG0_OFFSET);
 	davinci_irq_writel(~0x0, FIQ_REG1_OFFSET);
@@ -148,7 +153,7 @@ void __init davinci_irq_init(void)
 	}
 
 	/* set up genirq dispatch for ARM INTC */
-	for (i = 0; i < DAVINCI_N_AINTC_IRQ; i++) {
+	for (i = 0; i < davinci_soc_info.intc_irq_num; i++) {
 		set_irq_chip(i, &davinci_irq_chip_0);
 		set_irq_flags(i, IRQF_VALID | IRQF_PROBE);
 		if (i != IRQ_TINT1_TINT34)
-- 
1.7.0.4


From cyril at ti.com  Thu Apr 29 17:27:42 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 29 Apr 2010 18:27:42 -0400
Subject: [RFC 16/22] Davinci: iotable based ioremap() interception
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com>
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <1272580062-17663-17-git-send-email-cyril@ti.com>

This patch allows for a more flexible ioremap() interception based on iotable
contents.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 arch/arm/mach-davinci/da830.c |    7 +++----
 arch/arm/mach-davinci/da850.c |    4 ++--
 arch/arm/mach-davinci/io.c    |   20 +++++++++++++++-----
 3 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index afcc4ba..6804a59 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1210,9 +1210,8 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
 
 void __init da830_init(void)
 {
-	da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
-	if (WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module"))
-		return;
-
 	davinci_common_init(&davinci_soc_info_da830);
+
+	da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
+	WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module");
 }
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index df4b769..a08cb91 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1099,6 +1099,8 @@ void __init da850_init(void)
 {
 	unsigned int v;
 
+	davinci_common_init(&davinci_soc_info_da850);
+
 	da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
 	if (WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module"))
 		return;
@@ -1107,8 +1109,6 @@ void __init da850_init(void)
 	if (WARN(!da8xx_syscfg1_base, "Unable to map syscfg1 module"))
 		return;
 
-	davinci_common_init(&davinci_soc_info_da850);
-
 	/*
 	 * Move the clock source of Async3 domain to PLL1 SYSCLK2.
 	 * This helps keeping the peripherals on this domain insulated
diff --git a/arch/arm/mach-davinci/io.c b/arch/arm/mach-davinci/io.c
index a1c0b6b..8ea60a8 100644
--- a/arch/arm/mach-davinci/io.c
+++ b/arch/arm/mach-davinci/io.c
@@ -12,19 +12,29 @@
 #include <linux/io.h>
 
 #include <asm/tlb.h>
+#include <asm/mach/map.h>
 
-#define BETWEEN(p, st, sz)	((p) >= (st) && (p) < ((st) + (sz)))
-#define XLATE(p, pst, vst)	((void __iomem *)((p) - (pst) + (vst)))
+#include <mach/common.h>
 
 /*
  * Intercept ioremap() requests for addresses in our fixed mapping regions.
  */
 void __iomem *davinci_ioremap(unsigned long p, size_t size, unsigned int type)
 {
-	if (BETWEEN(p, IO_PHYS, IO_SIZE))
-		return XLATE(p, IO_PHYS, IO_VIRT);
+	struct map_desc *desc = davinci_soc_info.io_desc;
+	int desc_num = davinci_soc_info.io_desc_num;
+	int i;
 
-	return __arm_ioremap_caller(p, size, type, __builtin_return_address(0));
+	for (i = 0; i < desc_num; i++, desc++) {
+		unsigned long iophys = __pfn_to_phys(desc->pfn);
+		unsigned long iosize = desc->length;
+
+		if (p >= iophys && (p + size) <= (iophys + iosize))
+			return __io(desc->virtual + p - iophys);
+	}
+
+	return __arm_ioremap_caller(p, size, type,
+					__builtin_return_address(0));
 }
 EXPORT_SYMBOL(davinci_ioremap);
 
-- 
1.7.0.4


From cyril at ti.com  Thu Apr 29 17:27:41 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 29 Apr 2010 18:27:41 -0400
Subject: [RFC 15/22] Davinci: watchdog reset separation across socs
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com>
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <1272580062-17663-16-git-send-email-cyril@ti.com>

The earlier watchdog reset mechanism had a couple of limitations.  First, it
embedded a reference to "davinci_wdt_device" inside common code.  This
forced all derived platforms (da8xx and tnetv107x) to define such a device.
This also would have caused problems in including multiple socs in a single
build due to symbol redefinition.

With this patch, davinci_watchdog_reset() now takes the platform device as an
argument.  The davinci_soc_info struct has been extended to include a reset
function and a watchdog platform_device.  arch_reset() then uses these
elements to reset the system in a SoC specific fashion.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 arch/arm/mach-davinci/clock.h               |    1 +
 arch/arm/mach-davinci/common.c              |    3 +++
 arch/arm/mach-davinci/da830.c               |    1 +
 arch/arm/mach-davinci/da850.c               |    1 +
 arch/arm/mach-davinci/devices-da8xx.c       |    4 ++--
 arch/arm/mach-davinci/dm355.c               |    1 +
 arch/arm/mach-davinci/dm365.c               |    1 +
 arch/arm/mach-davinci/dm644x.c              |    1 +
 arch/arm/mach-davinci/dm646x.c              |    1 +
 arch/arm/mach-davinci/include/mach/common.h |    2 ++
 arch/arm/mach-davinci/include/mach/da8xx.h  |    2 ++
 arch/arm/mach-davinci/include/mach/system.h |    5 +++--
 arch/arm/mach-davinci/time.c                |    9 ++++++---
 13 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-davinci/clock.h b/arch/arm/mach-davinci/clock.h
index ce26015..01e3648 100644
--- a/arch/arm/mach-davinci/clock.h
+++ b/arch/arm/mach-davinci/clock.h
@@ -120,6 +120,7 @@ int davinci_set_pllrate(struct pll_data *pll, unsigned int prediv,
 				unsigned int mult, unsigned int postdiv);
 
 extern struct platform_device davinci_wdt_device;
+extern void davinci_watchdog_reset(struct platform_device *);
 
 #endif
 
diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c
index 0398711..e839f6e 100644
--- a/arch/arm/mach-davinci/common.c
+++ b/arch/arm/mach-davinci/common.c
@@ -93,6 +93,9 @@ void __init davinci_common_init(struct davinci_soc_info *soc_info)
 	local_flush_tlb_all();
 	flush_cache_all();
 
+	if (!davinci_soc_info.reset)
+		davinci_soc_info.reset = davinci_watchdog_reset;
+
 	/*
 	 * We want to check CPU revision early for cpu_is_xxxx() macros.
 	 * IO space mapping must be initialized before we can do that.
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index f8fef99..afcc4ba 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1205,6 +1205,7 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
 	.serial_dev		= &da8xx_serial_device,
 	.emac_pdata		= &da8xx_emac_pdata,
+	.reset_device		= &da8xx_wdt_device,
 };
 
 void __init da830_init(void)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index cb56772..df4b769 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1092,6 +1092,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.emac_pdata		= &da8xx_emac_pdata,
 	.sram_dma		= DA8XX_ARM_RAM_BASE,
 	.sram_len		= SZ_8K,
+	.reset_device		= &da8xx_wdt_device,
 };
 
 void __init da850_init(void)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index 825a7c2..e8b263b 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -326,7 +326,7 @@ static struct resource da8xx_watchdog_resources[] = {
 	},
 };
 
-struct platform_device davinci_wdt_device = {
+struct platform_device da8xx_wdt_device = {
 	.name		= "watchdog",
 	.id		= -1,
 	.num_resources	= ARRAY_SIZE(da8xx_watchdog_resources),
@@ -335,7 +335,7 @@ struct platform_device davinci_wdt_device = {
 
 int __init da8xx_register_watchdog(void)
 {
-	return platform_device_register(&davinci_wdt_device);
+	return platform_device_register(&da8xx_wdt_device);
 }
 
 static struct resource da8xx_emac_resources[] = {
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 08ec0ab..3834781 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -859,6 +859,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.serial_dev		= &dm355_serial_device,
 	.sram_dma		= 0x00010000,
 	.sram_len		= SZ_32K,
+	.reset_device		= &davinci_wdt_device,
 };
 
 void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 8a59130..e5e3dce 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1066,6 +1066,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.emac_pdata		= &dm365_emac_pdata,
 	.sram_dma		= 0x00010000,
 	.sram_len		= SZ_32K,
+	.reset_device		= &davinci_wdt_device,
 };
 
 void __init dm365_init_asp(struct snd_platform_data *pdata)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 425c5f3..7ad1520 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -751,6 +751,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.emac_pdata		= &dm644x_emac_pdata,
 	.sram_dma		= 0x00008000,
 	.sram_len		= SZ_16K,
+	.reset_device		= &davinci_wdt_device,
 };
 
 void __init dm644x_init_asp(struct snd_platform_data *pdata)
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index ff67a17..9404565 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -835,6 +835,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.emac_pdata		= &dm646x_emac_pdata,
 	.sram_dma		= 0x10010000,
 	.sram_len		= SZ_32K,
+	.reset_device		= &davinci_wdt_device,
 };
 
 void __init dm646x_init_mcasp0(struct snd_platform_data *pdata)
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 835422d..2927a06 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -71,6 +71,8 @@ struct davinci_soc_info {
 	struct emac_platform_data	*emac_pdata;
 	dma_addr_t			sram_dma;
 	unsigned			sram_len;
+	struct platform_device		*reset_device;
+	void				(*reset)(struct platform_device *);
 };
 
 extern struct davinci_soc_info davinci_soc_info;
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index dbb4ebe..1b31a9a 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -87,6 +87,8 @@ extern struct emac_platform_data da8xx_emac_pdata;
 extern struct da8xx_lcdc_platform_data sharp_lcd035q3dg01_pdata;
 extern struct da8xx_lcdc_platform_data sharp_lk043t1dg01_pdata;
 
+extern struct platform_device da8xx_wdt_device;
+
 extern const short da830_emif25_pins[];
 extern const short da830_spi0_pins[];
 extern const short da830_spi1_pins[];
diff --git a/arch/arm/mach-davinci/include/mach/system.h b/arch/arm/mach-davinci/include/mach/system.h
index 5a7d758..e65629c 100644
--- a/arch/arm/mach-davinci/include/mach/system.h
+++ b/arch/arm/mach-davinci/include/mach/system.h
@@ -11,7 +11,7 @@
 #ifndef __ASM_ARCH_SYSTEM_H
 #define __ASM_ARCH_SYSTEM_H
 
-extern void davinci_watchdog_reset(void);
+#include <mach/common.h>
 
 static inline void arch_idle(void)
 {
@@ -20,7 +20,8 @@ static inline void arch_idle(void)
 
 static inline void arch_reset(char mode, const char *cmd)
 {
-	davinci_watchdog_reset();
+	if (davinci_soc_info.reset)
+		davinci_soc_info.reset(davinci_soc_info.reset_device);
 }
 
 #endif /* __ASM_ARCH_SYSTEM_H */
diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index 6c7b0e2..0f21c36 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c
@@ -405,13 +405,16 @@ struct sys_timer davinci_timer = {
 
 
 /* reset board using watchdog timer */
-void davinci_watchdog_reset(void)
+void davinci_watchdog_reset(struct platform_device *pdev)
 {
 	u32 tgcr, wdtcr;
-	struct platform_device *pdev = &davinci_wdt_device;
-	void __iomem *base = IO_ADDRESS(pdev->resource[0].start);
+	void __iomem *base;
 	struct clk *wd_clk;
 
+	base = ioremap(pdev->resource[0].start, SZ_4K);
+	if (WARN_ON(!base))
+		return;
+
 	wd_clk = clk_get(&pdev->dev, NULL);
 	if (WARN_ON(IS_ERR(wd_clk)))
 		return;
-- 
1.7.0.4


From cyril at ti.com  Thu Apr 29 17:27:40 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 29 Apr 2010 18:27:40 -0400
Subject: [RFC 14/22] Davinci: eliminate pinmux offset verbosity
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com>
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <1272580062-17663-15-git-send-email-cyril@ti.com>

Pinmux registers are sequential, and do not need to be enumerated out as they
currently are.  This reduces code volume and keeps things simple.

If some future SoC comes up with a discontiguous register map, PINMUX() can
then be expanded with local token pasting.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 arch/arm/mach-davinci/dm355.c              |    5 -----
 arch/arm/mach-davinci/dm365.c              |    5 -----
 arch/arm/mach-davinci/dm644x.c             |    3 ---
 arch/arm/mach-davinci/dm646x.c             |    3 ---
 arch/arm/mach-davinci/gpio.c               |    6 +-----
 arch/arm/mach-davinci/include/mach/da8xx.h |   21 ---------------------
 arch/arm/mach-davinci/include/mach/mux.h   |    2 ++
 arch/arm/mach-davinci/mux.h                |    2 +-
 8 files changed, 4 insertions(+), 43 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 44f3940..08ec0ab 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -450,11 +450,6 @@ void __init dm355_init_spi0(unsigned chipselect_mask,
 
 /*----------------------------------------------------------------------*/
 
-#define PINMUX0		0x00
-#define PINMUX1		0x04
-#define PINMUX2		0x08
-#define PINMUX3		0x0c
-#define PINMUX4		0x10
 #define INTMUX		0x18
 #define EVTMUX		0x1c
 
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 6fec378..8a59130 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -467,11 +467,6 @@ static struct clk_lookup dm365_clks[] = {
 
 /*----------------------------------------------------------------------*/
 
-#define PINMUX0		0x00
-#define PINMUX1		0x04
-#define PINMUX2		0x08
-#define PINMUX3		0x0c
-#define PINMUX4		0x10
 #define INTMUX		0x18
 #define EVTMUX		0x1c
 
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index e89adcf..425c5f3 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -350,9 +350,6 @@ static struct platform_device dm644x_emac_device = {
        .resource	= dm644x_emac_resources,
 };
 
-#define PINMUX0		0x00
-#define PINMUX1		0x04
-
 /*
  * Device specific mux setup
  *
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index e760448..ff67a17 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -401,9 +401,6 @@ static struct platform_device dm646x_emac_device = {
 	.resource	= dm646x_emac_resources,
 };
 
-#define PINMUX0		0x00
-#define PINMUX1		0x04
-
 /*
  * Device specific mux setup
  *
diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index e845966..9e0c7a4 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -71,11 +71,7 @@ static int __init davinci_gpio_irq_setup(void);
 
 /*--------------------------------------------------------------------------*/
 
-/*
- * board setup code *MUST* set PINMUX0 and PINMUX1 as
- * needed, and enable the GPIO clock.
- */
-
+/* board setup code *MUST* setup pinmux and enable the GPIO clock. */
 static inline int __davinci_direction(struct gpio_chip *chip,
 			unsigned offset, bool out, int value)
 {
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index 33471c9..dbb4ebe 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -64,27 +64,6 @@ extern void __iomem *da8xx_syscfg1_base;
 #define DA8XX_DDR2_CTL_BASE	0xb0000000
 #define DA8XX_ARM_RAM_BASE	0xffff0000
 
-#define PINMUX0			0x00
-#define PINMUX1			0x04
-#define PINMUX2			0x08
-#define PINMUX3			0x0c
-#define PINMUX4			0x10
-#define PINMUX5			0x14
-#define PINMUX6			0x18
-#define PINMUX7			0x1c
-#define PINMUX8			0x20
-#define PINMUX9			0x24
-#define PINMUX10		0x28
-#define PINMUX11		0x2c
-#define PINMUX12		0x30
-#define PINMUX13		0x34
-#define PINMUX14		0x38
-#define PINMUX15		0x3c
-#define PINMUX16		0x40
-#define PINMUX17		0x44
-#define PINMUX18		0x48
-#define PINMUX19		0x4c
-
 void __init da830_init(void);
 void __init da850_init(void);
 
diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h
index 923debe..743dbd2 100644
--- a/arch/arm/mach-davinci/include/mach/mux.h
+++ b/arch/arm/mach-davinci/include/mach/mux.h
@@ -1174,6 +1174,8 @@ enum davinci_tnetv107x_index {
 	TNETV107X_TDM0_RX,
 };
 
+#define PINMUX(x)		(4 * (x))
+
 #ifdef CONFIG_DAVINCI_MUX
 /* setup pin muxing */
 extern int davinci_cfg_reg(unsigned long reg_cfg);
diff --git a/arch/arm/mach-davinci/mux.h b/arch/arm/mach-davinci/mux.h
index adc8694..5aad1e7 100644
--- a/arch/arm/mach-davinci/mux.h
+++ b/arch/arm/mach-davinci/mux.h
@@ -20,7 +20,7 @@
 			.name =  #desc,					\
 			.debug = dbg,					\
 			.mux_reg_name = "PINMUX"#muxreg,		\
-			.mux_reg = PINMUX##muxreg,			\
+			.mux_reg = PINMUX(muxreg),			\
 			.mask_offset = mode_offset,			\
 			.mask = mode_mask,				\
 			.mode = mux_mode,				\
-- 
1.7.0.4


From cyril at ti.com  Thu Apr 29 17:27:31 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 29 Apr 2010 18:27:31 -0400
Subject: [RFC 05/22] Davinci: gpio - controller type support
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com>
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <1272580062-17663-6-git-send-email-cyril@ti.com>

This patch allows for gpio controllers that deviate from those found on
traditional davinci socs.  davinci_soc_info has an added field to indicate the
soc-specific gpio controller type.  The gpio initialization code then bails
out if necessary.

More elements (tnetv107x) to be added later into enum davinci_gpio_type.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
Tested-by: Sandeep Paulraj <s-paulraj at ti.com>
---
 arch/arm/mach-davinci/da830.c               |    2 ++
 arch/arm/mach-davinci/da850.c               |    2 ++
 arch/arm/mach-davinci/dm355.c               |    1 +
 arch/arm/mach-davinci/dm365.c               |    1 +
 arch/arm/mach-davinci/dm644x.c              |    1 +
 arch/arm/mach-davinci/dm646x.c              |    1 +
 arch/arm/mach-davinci/gpio.c                |    3 +++
 arch/arm/mach-davinci/include/mach/common.h |    1 +
 arch/arm/mach-davinci/include/mach/gpio.h   |    4 ++++
 9 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 122e61a..68e5233 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -19,6 +19,7 @@
 #include <mach/common.h>
 #include <mach/time.h>
 #include <mach/da8xx.h>
+#include <mach/gpio.h>
 
 #include "clock.h"
 #include "mux.h"
@@ -1199,6 +1200,7 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
 	.intc_irq_prios		= da830_default_priorities,
 	.intc_irq_num		= DA830_N_CP_INTC_IRQ,
 	.timer_info		= &da830_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DA8XX_GPIO_BASE),
 	.gpio_num		= 128,
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index d0fd756..8aefcff 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -27,6 +27,7 @@
 #include <mach/da8xx.h>
 #include <mach/cpufreq.h>
 #include <mach/pm.h>
+#include <mach/gpio.h>
 
 #include "clock.h"
 #include "mux.h"
@@ -1084,6 +1085,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.intc_irq_prios		= da850_default_priorities,
 	.intc_irq_num		= DA850_N_CP_INTC_IRQ,
 	.timer_info		= &da850_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DA8XX_GPIO_BASE),
 	.gpio_num		= 144,
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 5efce70..f9a54ff 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -859,6 +859,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.intc_irq_prios		= dm355_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm355_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM355_GPIOBNK0,
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 1ee3fc8..0566675 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1064,6 +1064,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.intc_irq_prios		= dm365_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm365_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM365_GPIO0,
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 23cbe9d..4af349e 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -748,6 +748,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.intc_irq_prios 	= dm644x_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm644x_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
 	.gpio_num		= 71,
 	.gpio_irq		= IRQ_GPIOBNK0,
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index a0b3739..bdb1ace 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -832,6 +832,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.intc_irq_prios		= dm646x_default_priorities,
 	.intc_irq_num		= DAVINCI_N_AINTC_IRQ,
 	.timer_info		= &dm646x_timer_info,
+	.gpio_type		= GPIO_TYPE_DAVINCI,
 	.gpio_base		= IO_ADDRESS(DAVINCI_GPIO_BASE),
 	.gpio_num		= 43, /* Only 33 usable */
 	.gpio_irq		= IRQ_DM646X_GPIOBNK0,
diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index d241b4f..e422cd3 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -145,6 +145,9 @@ static int __init davinci_gpio_setup(void)
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
 	struct davinci_gpio_regs *regs;
 
+	if (soc_info->gpio_type != GPIO_TYPE_DAVINCI)
+		return 0;
+
 	/*
 	 * The gpio banks conceptually expose a segmented bitmap,
 	 * and "ngpio" is one more than the largest zero-based
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 1d72883..8ffef5b 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -59,6 +59,7 @@ struct davinci_soc_info {
 	u8				*intc_irq_prios;
 	unsigned long			intc_irq_num;
 	struct davinci_timer_info	*timer_info;
+	int				gpio_type;
 	void __iomem			*gpio_base;
 	unsigned			gpio_num;
 	unsigned			gpio_irq;
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index 82591d0..9a71a26 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -21,6 +21,10 @@
 
 #define DAVINCI_GPIO_BASE 0x01C67000
 
+enum davinci_gpio_type {
+	GPIO_TYPE_DAVINCI = 0,
+};
+
 /*
  * basic gpio routines
  *
-- 
1.7.0.4


From cyril at ti.com  Thu Apr 29 17:27:35 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Thu, 29 Apr 2010 18:27:35 -0400
Subject: [RFC 09/22] Davinci: jtag_id - use ioremap()
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com>
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <1272580062-17663-10-git-send-email-cyril@ti.com>

This patch replaces the jtag id base info in davinci_soc_info with a physical
address which is then ioremap()ed within common code.

This patch (in combination with a similar change for PSC) will allow us to
eliminate the SYSCFG nastiness in DA8xx code.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 arch/arm/mach-davinci/common.c              |   49 +++++++++++++++-----------
 arch/arm/mach-davinci/da830.c               |    3 +-
 arch/arm/mach-davinci/da850.c               |    3 +-
 arch/arm/mach-davinci/dm355.c               |    2 +-
 arch/arm/mach-davinci/dm365.c               |    2 +-
 arch/arm/mach-davinci/dm644x.c              |    2 +-
 arch/arm/mach-davinci/dm646x.c              |    2 +-
 arch/arm/mach-davinci/include/mach/common.h |    2 +-
 8 files changed, 35 insertions(+), 30 deletions(-)

diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c
index 94f27cb..d35650f 100644
--- a/arch/arm/mach-davinci/common.c
+++ b/arch/arm/mach-davinci/common.c
@@ -37,26 +37,42 @@ void davinci_get_mac_addr(struct memory_accessor *mem_acc, void *context)
 		pr_info("Read MAC addr from EEPROM: %pM\n", mac_addr);
 }
 
-static struct davinci_id * __init davinci_get_id(u32 jtag_id)
+static int __init davinci_init_id(struct davinci_soc_info *soc_info)
 {
-	int i;
-	struct davinci_id *dip;
-	u8 variant = (jtag_id & 0xf0000000) >> 28;
-	u16 part_no = (jtag_id & 0x0ffff000) >> 12;
+	int			i;
+	struct davinci_id	*dip;
+	u8			variant;
+	u16			part_no;
+	void __iomem		*base;
+
+	base = ioremap(davinci_soc_info.jtag_id_reg, SZ_4K);
+	if (!base) {
+		pr_err("Unable to map JTAG ID register\n");
+		return -EINVAL;
+	}
+
+	soc_info->jtag_id = __raw_readl(base);
+	iounmap(base);
+
+	variant = (soc_info->jtag_id & 0xf0000000) >> 28;
+	part_no = (soc_info->jtag_id & 0x0ffff000) >> 12;
 
 	for (i = 0, dip = davinci_soc_info.ids; i < davinci_soc_info.ids_num;
 			i++, dip++)
 		/* Don't care about the manufacturer right now */
-		if ((dip->part_no == part_no) && (dip->variant == variant))
-			return dip;
-
-	return NULL;
+		if ((dip->part_no == part_no) && (dip->variant == variant)) {
+			soc_info->cpu_id = dip->cpu_id;
+			pr_info("DaVinci %s variant 0x%x\n", dip->name, dip->variant);
+			return 0;
+		}
+
+	pr_err("Unknown DaVinci JTAG ID 0x%x\n", soc_info->jtag_id);
+	return -EINVAL;
 }
 
 void __init davinci_common_init(struct davinci_soc_info *soc_info)
 {
 	int ret;
-	struct davinci_id *dip;
 
 	if (!soc_info) {
 		ret = -EINVAL;
@@ -81,18 +97,9 @@ void __init davinci_common_init(struct davinci_soc_info *soc_info)
 	 * We want to check CPU revision early for cpu_is_xxxx() macros.
 	 * IO space mapping must be initialized before we can do that.
 	 */
-	davinci_soc_info.jtag_id = __raw_readl(davinci_soc_info.jtag_id_base);
-
-	dip = davinci_get_id(davinci_soc_info.jtag_id);
-	if (!dip) {
-		ret = -EINVAL;
-		pr_err("Unknown DaVinci JTAG ID 0x%x\n",
-						davinci_soc_info.jtag_id);
+	ret = davinci_init_id(&davinci_soc_info);
+	if (ret < 0)
 		goto err;
-	}
-
-	davinci_soc_info.cpu_id = dip->cpu_id;
-	pr_info("DaVinci %s variant 0x%x\n", dip->name, dip->variant);
 
 	if (davinci_soc_info.cpu_clks) {
 		ret = davinci_clk_init(davinci_soc_info.cpu_clks);
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 84786ec..4289fb9 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1188,6 +1188,7 @@ static struct davinci_timer_info da830_timer_info = {
 static struct davinci_soc_info davinci_soc_info_da830 = {
 	.io_desc		= da830_io_desc,
 	.io_desc_num		= ARRAY_SIZE(da830_io_desc),
+	.jtag_id_reg		= DA8XX_JTAG_ID_REG,
 	.ids			= da830_ids,
 	.ids_num		= ARRAY_SIZE(da830_ids),
 	.cpu_clks		= da830_clks,
@@ -1214,8 +1215,6 @@ void __init da830_init(void)
 	if (WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module"))
 		return;
 
-	davinci_soc_info_da830.jtag_id_base =
-					DA8XX_SYSCFG0_VIRT(DA8XX_JTAG_ID_REG);
 	davinci_soc_info_da830.pinmux_base = DA8XX_SYSCFG0_VIRT(0x120);
 
 	davinci_common_init(&davinci_soc_info_da830);
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 0697cfa..6287ed4 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1073,6 +1073,7 @@ no_ddrpll_mem:
 static struct davinci_soc_info davinci_soc_info_da850 = {
 	.io_desc		= da850_io_desc,
 	.io_desc_num		= ARRAY_SIZE(da850_io_desc),
+	.jtag_id_reg		= DA8XX_JTAG_ID_REG,
 	.ids			= da850_ids,
 	.ids_num		= ARRAY_SIZE(da850_ids),
 	.cpu_clks		= da850_clks,
@@ -1107,8 +1108,6 @@ void __init da850_init(void)
 	if (WARN(!da8xx_syscfg1_base, "Unable to map syscfg1 module"))
 		return;
 
-	davinci_soc_info_da850.jtag_id_base =
-					DA8XX_SYSCFG0_VIRT(DA8XX_JTAG_ID_REG);
 	davinci_soc_info_da850.pinmux_base = DA8XX_SYSCFG0_VIRT(0x120);
 
 	davinci_common_init(&davinci_soc_info_da850);
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 70c3032..c1104b6 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -845,7 +845,7 @@ static struct platform_device dm355_serial_device = {
 static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.io_desc		= dm355_io_desc,
 	.io_desc_num		= ARRAY_SIZE(dm355_io_desc),
-	.jtag_id_base		= IO_ADDRESS(0x01c40028),
+	.jtag_id_reg		= 0x01c40028,
 	.ids			= dm355_ids,
 	.ids_num		= ARRAY_SIZE(dm355_ids),
 	.cpu_clks		= dm355_clks,
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 59bf298..0adc4d1 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1050,7 +1050,7 @@ static struct platform_device dm365_serial_device = {
 static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.io_desc		= dm365_io_desc,
 	.io_desc_num		= ARRAY_SIZE(dm365_io_desc),
-	.jtag_id_base		= IO_ADDRESS(0x01c40028),
+	.jtag_id_reg		= 0x01c40028,
 	.ids			= dm365_ids,
 	.ids_num		= ARRAY_SIZE(dm365_ids),
 	.cpu_clks		= dm365_clks,
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 2916b27..e8b208c 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -734,7 +734,7 @@ static struct platform_device dm644x_serial_device = {
 static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.io_desc		= dm644x_io_desc,
 	.io_desc_num		= ARRAY_SIZE(dm644x_io_desc),
-	.jtag_id_base		= IO_ADDRESS(0x01c40028),
+	.jtag_id_reg		= 0x01c40028,
 	.ids			= dm644x_ids,
 	.ids_num		= ARRAY_SIZE(dm644x_ids),
 	.cpu_clks		= dm644x_clks,
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 236f14f..917f09f 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -818,7 +818,7 @@ static struct platform_device dm646x_serial_device = {
 static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.io_desc		= dm646x_io_desc,
 	.io_desc_num		= ARRAY_SIZE(dm646x_io_desc),
-	.jtag_id_base		= IO_ADDRESS(0x01c40028),
+	.jtag_id_reg		= 0x01c40028,
 	.ids			= dm646x_ids,
 	.ids_num		= ARRAY_SIZE(dm646x_ids),
 	.cpu_clks		= dm646x_clks,
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 73fe289..9feccd5 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -45,7 +45,7 @@ struct davinci_soc_info {
 	unsigned long			io_desc_num;
 	u32				cpu_id;
 	u32				jtag_id;
-	void __iomem			*jtag_id_base;
+	u32				jtag_id_reg;
 	struct davinci_id		*ids;
 	unsigned long			ids_num;
 	struct clk_lookup		*cpu_clks;
-- 
1.7.0.4


From khilman at deeprootsystems.com  Thu Apr 29 18:04:10 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 29 Apr 2010 16:04:10 -0700
Subject: [PATCH v4 08/13] Davinci: iotable based ioremap() interception
In-Reply-To: <1272045424-19240-9-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Fri\, 23 Apr 2010 13\:56\:59 -0400")
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
Message-ID: <87ljc5uahh.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> This patch allows for a more flexible ioremap() interception based on iotable
> contents.
>
> SoCs that need ioremap() to fill up davinci_soc_info may directly call
> davinci_io_init() and use ioremap() as needed.  Such SoCs must not fill
> io_desc and io_desc_num entries in struct davinci_soc_info.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> Tested-by: Sandeep Paulraj <s-paulraj at ti.com>

Very nice...   one minor nit below...

[...]

> +
> +void __init davinci_io_init(struct map_desc *desc, unsigned long desc_num)
> +{
> +	if (!desc || !desc_num)
> +		return;
> +
> +	/* silently refuse to init twice ...*/
> +	if (davinci_io_desc) {
> +		/* ... unless things change */
> +		BUG_ON(davinci_io_desc != desc ||
> +			davinci_io_desc_num != desc_num);

Should be a WARN_ON() here.  This is non fatal, and easy
to recover from.  (c.f. include/asm-generic/bug.h, below)

Kevin


/*
 * Don't use BUG() or BUG_ON() unless there's really no way out; one
 * example might be detecting data structure corruption in the middle
 * of an operation that can't be backed out of.  If the (sub)system
 * can somehow continue operating, perhaps with reduced functionality,
 * it's probably not BUG-worthy.
 *
 * If you're tempted to BUG(), think again:  is completely giving up
 * really the *only* solution?  There are usually better options, where
 * users don't need to reboot ASAP and can mostly shut down cleanly.
 */

From pratik.joshi at einfochips.com  Fri Apr 30 00:20:41 2010
From: pratik.joshi at einfochips.com (pratik.joshi)
Date: Fri, 30 Apr 2010 10:50:41 +0530
Subject: Audio over USB - kernel 2.6.33.2
Message-ID: <002e01cae824$e04c3d80$a0e4b880$@joshi@einfochips.com>

Hi,

 

I am trying to run Audio over USB with kernel 2.6.33.2 on DVEVM. I have
configured USB in DMA mode. I am able to playback the Audio but in record
"read" returns error and no recording takes place.

 

Can anyone let me know if Audio record over USB is tested for DMA enabled in
2.6.33.2 kernel?

 

Regards,

Pratik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100430/21cbed0d/attachment.html>

From sameer.subscriptions at damagehead.com  Fri Apr 30 00:43:16 2010
From: sameer.subscriptions at damagehead.com (Sameer Naik)
Date: Fri, 30 Apr 2010 11:13:16 +0530
Subject: GIT Kernel
In-Reply-To: <71D9F169A5BDCD4D8D52CFC9AF872B3501552BAD@ILMAIL01.dspg.com>
References: <71D9F169A5BDCD4D8D52CFC9AF872B3501552BAD@ILMAIL01.dspg.com>
Message-ID: <n2m1c12dfe71004292243o9ef603f6q8cc0941d81b7fc30@mail.gmail.com>

http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=summary

On Sun, Apr 25, 2010 at 12:51 AM, Dudi Dolev <Dudi.Dolev at dspg.com> wrote:
> Hi
>
>
>
> I?m looking for the latest V4l2 display drivers for the Video Processing
> Back end of DaVinci (such ad OSD).
>
>
>
> Can you please direct (give me URL, FTP or? GIT) me to the DaVinci Linux
> kernel?
>
>
>
> Best regards,
>
>
>
> Dudi Dolev
>
> Software Development Engineer
>
> Tel. +972-9-9529-674
>
> dudi.dolev at dspg.com
>
> www.dspg.com
>
>
>
> ______________________________________________________________________
> DSP Group, Inc. automatically scans all emails and attachments using
> MessageLabs Email Security System.
> _____________________________________________________________________
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>

From Dudi.Dolev at dspg.com  Fri Apr 30 01:16:55 2010
From: Dudi.Dolev at dspg.com (Dudi Dolev)
Date: Fri, 30 Apr 2010 09:16:55 +0300
Subject: GIT Kernel
In-Reply-To: <n2m1c12dfe71004292243o9ef603f6q8cc0941d81b7fc30@mail.gmail.com>
References: <71D9F169A5BDCD4D8D52CFC9AF872B3501552BAD@ILMAIL01.dspg.com>
	<n2m1c12dfe71004292243o9ef603f6q8cc0941d81b7fc30@mail.gmail.com>
Message-ID: <71D9F169A5BDCD4D8D52CFC9AF872B350159D51A@ILMAIL01.dspg.com>

First thanks a lot for your replay :)

As this http://focus.ti.com.cn/cn/lit/ug/spruel3/spruel3.pdf document suggests there is V4L2 driver (that work together with FBDev driver containing V4L2 IOCT's, please look at page 7)

I was not able to locate the code of the V4l2 IOCTL's in the link you sent. Me.

Can you please help me?

Thanks
Dudi



-----Original Message-----
From: Sameer Naik [mailto:sameer.subscriptions at damagehead.com] 
Sent: Friday, April 30, 2010 8:43 AM
To: Dudi Dolev
Cc: davinci-linux-open-source at linux.davincidsp.com
Subject: Re: GIT Kernel

http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=summary

On Sun, Apr 25, 2010 at 12:51 AM, Dudi Dolev <Dudi.Dolev at dspg.com> wrote:
> Hi
>
>
>
> I?m looking for the latest V4l2 display drivers for the Video Processing
> Back end of DaVinci (such ad OSD).
>
>
>
> Can you please direct (give me URL, FTP or? GIT) me to the DaVinci Linux
> kernel?
>
>
>
> Best regards,
>
>
>
> Dudi Dolev
>
> Software Development Engineer
>
> Tel. +972-9-9529-674
>
> dudi.dolev at dspg.com
>
> www.dspg.com
>
>
>
> ______________________________________________________________________
> DSP Group, Inc. automatically scans all emails and attachments using
> MessageLabs Email Security System.
> _____________________________________________________________________
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>

______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using MessageLabs Email Security System.
_____________________________________________________________________

______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using MessageLabs Email Security System.
_____________________________________________________________________

From mgrosen at ti.com  Fri Apr 30 01:34:26 2010
From: mgrosen at ti.com (Grosen, Mark)
Date: Fri, 30 Apr 2010 01:34:26 -0500
Subject: GIT Kernel
In-Reply-To: <71D9F169A5BDCD4D8D52CFC9AF872B350159D51A@ILMAIL01.dspg.com>
References: <71D9F169A5BDCD4D8D52CFC9AF872B3501552BAD@ILMAIL01.dspg.com>
	<n2m1c12dfe71004292243o9ef603f6q8cc0941d81b7fc30@mail.gmail.com>
	<71D9F169A5BDCD4D8D52CFC9AF872B350159D51A@ILMAIL01.dspg.com>
Message-ID: <5F744A5A3C131242B81CE5874BD2CFFB880F48D0@dlee01.ent.ti.com>

http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel

And more recent support waiting to get merged upstream is available via the Arago project:
http://arago-project.org/git/projects/

The document you list below is out-of-date compared to the newer V4L2 support for DaVinci family.  

-----Original Message-----
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Dudi Dolev
Sent: Thursday, April 29, 2010 11:17 PM
To: Sameer Naik
Cc: davinci-linux-open-source at linux.davincidsp.com
Subject: RE: GIT Kernel

First thanks a lot for your replay :)

As this http://focus.ti.com.cn/cn/lit/ug/spruel3/spruel3.pdf document suggests there is V4L2 driver (that work together with FBDev driver containing V4L2 IOCT's, please look at page 7)

I was not able to locate the code of the V4l2 IOCTL's in the link you sent. Me.

Can you please help me?

Thanks
Dudi



-----Original Message-----
From: Sameer Naik [mailto:sameer.subscriptions at damagehead.com]
Sent: Friday, April 30, 2010 8:43 AM
To: Dudi Dolev
Cc: davinci-linux-open-source at linux.davincidsp.com
Subject: Re: GIT Kernel

http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=summary

On Sun, Apr 25, 2010 at 12:51 AM, Dudi Dolev <Dudi.Dolev at dspg.com> wrote:
> Hi
>
>
>
> I'm looking for the latest V4l2 display drivers for the Video 
> Processing Back end of DaVinci (such ad OSD).
>
>
>
> Can you please direct (give me URL, FTP or? GIT) me to the DaVinci 
> Linux kernel?
>
>
>
> Best regards,
>
>
>
> Dudi Dolev
>
> Software Development Engineer
>
> Tel. +972-9-9529-674
>
> dudi.dolev at dspg.com
>
> www.dspg.com
>
>
>
> ______________________________________________________________________
> DSP Group, Inc. automatically scans all emails and attachments using 
> MessageLabs Email Security System.
> _____________________________________________________________________
>
> _______________________________________________
> Davinci-linux-open-source mailing list 
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>

______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using MessageLabs Email Security System.
_____________________________________________________________________

______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using MessageLabs Email Security System.
_____________________________________________________________________
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From lamiaposta71 at gmail.com  Fri Apr 30 04:43:48 2010
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Fri, 30 Apr 2010 11:43:48 +0200
Subject: dm365: davincifb
Message-ID: <g2xade1bdc1004300243g43303c3j18b78474305b1330@mail.gmail.com>

Comparing davincifb.c from arago to the git tree one I see many differences.
Seems that davincifb is not complete and surely it doesn't work with dm365
(also with evm trough composite output).
The file include/video/davincifb.h contains some wrong defines for dm365.
For instance these defines (for dm356) should be used:
#define VENC_REG_BASE                           0x01C71E00
#define OSD_REG_BASE                            0x01C71C00
#define OSD_REG_SIZE                           0x00000100

It is strange that VENC_REG_BASE is defined once for all DaVinci family and
instead it should be different for each cpu.

We are proceeding developing the support for dm365 trying to get information
from arago kernel.
But as it is a hard work and I'd like to know if there anybody developing
it.
The purpose is to have a working  lcd interface.

By now we have VENC block working.
We can enable cursor.
We can switch on/off OSD0,1 VID0,1 planes.
We can register frame buffer.
But seems it lacks some glue between DDR and FIFOs, as no pixel can be
correctly written, only green, white and black windows are displayed.

Thx in advance,
Raffaele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100430/d2a74953/attachment-0001.html>

From cyril at ti.com  Fri Apr 30 08:34:50 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 30 Apr 2010 09:34:50 -0400
Subject: [PATCH v4 08/13] Davinci: iotable based ioremap() interception
In-Reply-To: <87ljc5uahh.fsf@deeprootsystems.com>
References: <1272045424-19240-1-git-send-email-cyril@ti.com>	<1272045424-19240-2-git-send-email-cyril@ti.com>	<1272045424-19240-3-git-send-email-cyril@ti.com>	<1272045424-19240-4-git-send-email-cyril@ti.com>	<1272045424-19240-5-git-send-email-cyril@ti.com>	<1272045424-19240-6-git-send-email-cyril@ti.com>	<1272045424-19240-7-git-send-email-cyril@ti.com>	<1272045424-19240-8-git-send-email-cyril@ti.com>	<1272045424-19240-9-git-send-email-cyril@ti.com>
	<87ljc5uahh.fsf@deeprootsystems.com>
Message-ID: <4BDADC7A.3090407@ti.com>

Hi Kevin,

[...]
> Very nice...   one minor nit below...

Thanks.  However, I think the solution proposed in [1] is more elegant.

The way I see it, the root cause of the problem is that some of the
davinci_soc_info fields mapped virtual addresses.  Since these virtual
addresses need to be filled in before davinci_common_init(), the current
v4 series implementation contorts the init flow in da8xx and tnetv107x.

By replacing davinci_soc_info virtual address fields with physical
addresses, we can get by with a single uniform flow that works cleanly
across all three families without said contortions.

Physical addresses in davinci_soc_info have other pleasant side effects
as well.  First, doing so replaces a bunch of IO_ADDRESS() uses in the
mach-davinci code with ioremap().  Second, this also cleans up the early
uses of DA8XX_SYSCFG0_VIRT().

Any thoughts on this approach?

[...]
>> +void __init davinci_io_init(struct map_desc *desc, unsigned long desc_num)
>> +{
>> +	if (!desc || !desc_num)
>> +		return;
>> +
>> +	/* silently refuse to init twice ...*/
>> +	if (davinci_io_desc) {
>> +		/* ... unless things change */
>> +		BUG_ON(davinci_io_desc != desc ||
>> +			davinci_io_desc_num != desc_num);
> 
> Should be a WARN_ON() here.  This is non fatal, and easy
> to recover from.  (c.f. include/asm-generic/bug.h, below)
Thanks.

-- Cyril.

[1]
http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-April/018681.html


From khilman at deeprootsystems.com  Fri Apr 30 09:30:25 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 30 Apr 2010 07:30:25 -0700
Subject: [PATCH v4 08/13] Davinci: iotable based ioremap() interception
In-Reply-To: <4BDADC7A.3090407@ti.com> (Cyril Chemparathy's message of "Fri\,
	30 Apr 2010 09\:34\:50 -0400")
References: <1272045424-19240-1-git-send-email-cyril@ti.com>
	<1272045424-19240-2-git-send-email-cyril@ti.com>
	<1272045424-19240-3-git-send-email-cyril@ti.com>
	<1272045424-19240-4-git-send-email-cyril@ti.com>
	<1272045424-19240-5-git-send-email-cyril@ti.com>
	<1272045424-19240-6-git-send-email-cyril@ti.com>
	<1272045424-19240-7-git-send-email-cyril@ti.com>
	<1272045424-19240-8-git-send-email-cyril@ti.com>
	<1272045424-19240-9-git-send-email-cyril@ti.com>
	<87ljc5uahh.fsf@deeprootsystems.com> <4BDADC7A.3090407@ti.com>
Message-ID: <87r5lxrp1a.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> Hi Kevin,
>
> [...]
>> Very nice...   one minor nit below...
>
> Thanks.  However, I think the solution proposed in [1] is more elegant.
>
> The way I see it, the root cause of the problem is that some of the
> davinci_soc_info fields mapped virtual addresses.  Since these virtual
> addresses need to be filled in before davinci_common_init(), the current
> v4 series implementation contorts the init flow in da8xx and tnetv107x.
>
> By replacing davinci_soc_info virtual address fields with physical
> addresses, we can get by with a single uniform flow that works cleanly
> across all three families without said contortions.
>
> Physical addresses in davinci_soc_info have other pleasant side effects
> as well.  First, doing so replaces a bunch of IO_ADDRESS() uses in the
> mach-davinci code with ioremap().  Second, this also cleans up the early
> uses of DA8XX_SYSCFG0_VIRT().
>
> Any thoughts on this approach?
>

Now *this*, I really, really like.

This is an excellent approach.  I'll look through the new series later
today.

Kevin

From khilman at deeprootsystems.com  Fri Apr 30 10:07:02 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 30 Apr 2010 08:07:02 -0700
Subject: [PATCH 02/14] omap: Make uncompress code and DEBUG_LL code generic
In-Reply-To: <20100126201239.15382.34792.stgit@baageli.muru.com>
References: <20100126200646.15382.52167.stgit@baageli.muru.com>
	<20100126201239.15382.34792.stgit@baageli.muru.com>
Message-ID: <1272640022.3051.1534.camel@localhost>

[resend to include RMK]

On Tue, 2010-01-26 at 12:12 -0800, Tony Lindgren wrote:
> Define arch_decomp_setup() the same way as some other
> architectures do. Use arch_id to configure the debug uart
> based on the machine_is by storing it into the uart
> scratchpad register for DEBUG_LL code to use.
> 
> Note that to avoid merge conflicts, this patch is using
> hardcoded register r1 until tmp register is being passed
> for all addruart macros.

This patch (now in mainline[1]) has been working well, but has a couple
serious limitations:

1. assumes bootloader has enabled UART1 clocks
2. assumes all OMAPs supported have the same UART1 base

With more platforms using USB-based UARTs, assumption (1) may not be
safe for very long, as bootloaders for these platforms don't really
*need* to enable UART1.  Currently, they happen to mainly because of
copied init code from other platforms. 

But more importantly, there are more OMAP derivative parts coming soon,
and one in particular coming soon[2] breaks assumption 2 by having a
different UART1 base (yes, it's branded as a DaVinci, but it's an OMAP
core as far as linux is concerned.  Don't get me started on TI
branding.)

To fix both problems, maybe we should just use a fixed memory location
to pass this temporary data from uncompress to the kernel.  We've had a
similar problem on DaVinci recently and a proposal has been made (and
tested) to use memory just below the page tables[3].)

Any comments on this proposal?  or alternative suggestions?

Kevin

[1] commit 0c8219f0302d0d27fda52c790d38406801e547ec
[1] http://www.ti.com/ww/en/dsp/davinci-netra/index.shtml
[2] https://patchwork.kernel.org/patch/94724/




From sshtylyov at mvista.com  Fri Apr 30 10:40:13 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Fri, 30 Apr 2010 19:40:13 +0400
Subject: [RFC 09/22] Davinci: jtag_id - use ioremap()
In-Reply-To: <1272580062-17663-10-git-send-email-cyril@ti.com>
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
	<1272580062-17663-10-git-send-email-cyril@ti.com>
Message-ID: <4BDAF9DD.60703@mvista.com>

Hello.

Cyril Chemparathy wrote:

> This patch replaces the jtag id base info in davinci_soc_info with a physical
> address which is then ioremap()ed within common code.
>
> This patch (in combination with a similar change for PSC) will allow us to
> eliminate the SYSCFG nastiness in DA8xx code.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
>   
[...]
> diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c
> index 94f27cb..d35650f 100644
> --- a/arch/arm/mach-davinci/common.c
> +++ b/arch/arm/mach-davinci/common.c
> @@ -37,26 +37,42 @@ void davinci_get_mac_addr(struct memory_accessor *mem_acc, void *context)
>  		pr_info("Read MAC addr from EEPROM: %pM\n", mac_addr);
>  }
>  
> -static struct davinci_id * __init davinci_get_id(u32 jtag_id)
> +static int __init davinci_init_id(struct davinci_soc_info *soc_info)
>  {
> -	int i;
> -	struct davinci_id *dip;
> -	u8 variant = (jtag_id & 0xf0000000) >> 28;
> -	u16 part_no = (jtag_id & 0x0ffff000) >> 12;
> +	int			i;
> +	struct davinci_id	*dip;
> +	u8			variant;
> +	u16			part_no;
> +	void __iomem		*base;
> +
> +	base = ioremap(davinci_soc_info.jtag_id_reg, SZ_4K);
>   

   The register only takes 4 bytes, why remap an extra page (considering 
the register's address is not 4K-aligned)? Although it's a fixed mapping 
anyway...

WBR, Sergei


From cyril at ti.com  Fri Apr 30 11:20:35 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 30 Apr 2010 12:20:35 -0400
Subject: [PATCH 02/14] omap: Make uncompress code and DEBUG_LL code generic
In-Reply-To: <1272640022.3051.1534.camel@localhost>
References: <20100126200646.15382.52167.stgit@baageli.muru.com>	
	<20100126201239.15382.34792.stgit@baageli.muru.com>
	<1272640022.3051.1534.camel@localhost>
Message-ID: <4BDB0353.5090800@ti.com>

Hi,

[...]
> To fix both problems, maybe we should just use a fixed memory location
> to pass this temporary data from uncompress to the kernel.  We've had a
> similar problem on DaVinci recently and a proposal has been made (and
> tested) to use memory just below the page tables[3].)

Essentially both of these approaches (internal scratch register and
fixed address) implement a weird back-channel communication scheme
between the decompresser and the debug macros.

A more elegant solution may be as follows:
    - pass machine_arch_type as an argument into addruart.
    - move the uart base lookup logic to addruart using macros similar
      to DEBUG_LL_*, except that these expand to assembly code this
      time.
    - reuse these debug-macros in uncompress.h and implement putc() and
      flush() using addruart(), senduart(), etc.

This way, both the decompresser and the kernel debug macros end up using
machine_arch_type to get to the right debug uart, without resorting to
underhand back-channel tricks.

Any thoughts?

-- Cyril.

From jtobias at viaas.com  Fri Apr 30 13:14:04 2010
From: jtobias at viaas.com (John Tobias)
Date: Fri, 30 Apr 2010 11:14:04 -0700
Subject: UBL Question
Message-ID: <o2o66b2b2311004301114m5992da85s156d0ace0e3afec1@mail.gmail.com>

Hi,

Does anyone successfully written the UBL image in block 1/5 from linux
userspace? I need a way to write the ubl image for the firmware upgrade and
the only access that I have is the linux userspace.


Thanks,

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100430/391e6f3e/attachment.html>

From michael.williamson at criticallink.com  Fri Apr 30 13:34:09 2010
From: michael.williamson at criticallink.com (Mike Williamson)
Date: Fri, 30 Apr 2010 14:34:09 -0400
Subject: UBL Question
In-Reply-To: <o2o66b2b2311004301114m5992da85s156d0ace0e3afec1@mail.gmail.com>
References: <o2o66b2b2311004301114m5992da85s156d0ace0e3afec1@mail.gmail.com>
Message-ID: <y2s763e54b1004301134u80ee97c5w249e758c3b64368f@mail.gmail.com>

Hi John,

In the past, we've used the /dev/mtd* devices to write data back to NOR (spi
/ parallel) devices for updating firmware using something like:

dd if=newimage.bin of=/dev/mtd0

Of course, you need to have your kernel configured to have the mtd drivers
loaded and you need to make these areas writable (most linux board packages
set these to read-only, given the sizeable gun you have pointed at your
shoes....)

-Mike


On Fri, Apr 30, 2010 at 2:14 PM, John Tobias <jtobias at viaas.com> wrote:

> Hi,
>
> Does anyone successfully written the UBL image in block 1/5 from linux
> userspace? I need a way to write the ubl image for the firmware upgrade and
> the only access that I have is the linux userspace.
>
>
> Thanks,
>
> John
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>


-- 
Michael Williamson
315-425-4045x230
www.criticallink.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100430/a8c1c684/attachment.html>

From jtobias at viaas.com  Fri Apr 30 13:51:20 2010
From: jtobias at viaas.com (John Tobias)
Date: Fri, 30 Apr 2010 11:51:20 -0700
Subject: UBL Question
In-Reply-To: <y2s763e54b1004301134u80ee97c5w249e758c3b64368f@mail.gmail.com>
References: <o2o66b2b2311004301114m5992da85s156d0ace0e3afec1@mail.gmail.com>
	<y2s763e54b1004301134u80ee97c5w249e758c3b64368f@mail.gmail.com>
Message-ID: <j2l66b2b2311004301151u4c6632ddq49f005be818a36b5@mail.gmail.com>

Hi Mike,

Yes, that's my plan. I will expose the ubl blocks from linux userspace and
become writable.
And, I like the idea of using dd so no need to worry about the CRC issue.

Thanks,

John

On Fri, Apr 30, 2010 at 11:34 AM, Mike Williamson <
michael.williamson at criticallink.com> wrote:

> Hi John,
>
> In the past, we've used the /dev/mtd* devices to write data back to NOR
> (spi / parallel) devices for updating firmware using something like:
>
> dd if=newimage.bin of=/dev/mtd0
>
> Of course, you need to have your kernel configured to have the mtd drivers
> loaded and you need to make these areas writable (most linux board packages
> set these to read-only, given the sizeable gun you have pointed at your
> shoes....)
>
> -Mike
>
>
> On Fri, Apr 30, 2010 at 2:14 PM, John Tobias <jtobias at viaas.com> wrote:
>
>>  Hi,
>>
>> Does anyone successfully written the UBL image in block 1/5 from linux
>> userspace? I need a way to write the ubl image for the firmware upgrade and
>> the only access that I have is the linux userspace.
>>
>>
>> Thanks,
>>
>> John
>>
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source at linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>>
>>
>
>
> --
> Michael Williamson
> 315-425-4045x230
> www.criticallink.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100430/e3adac97/attachment.html>

From linux at arm.linux.org.uk  Fri Apr 30 12:18:02 2010
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 30 Apr 2010 18:18:02 +0100
Subject: [PATCH 02/14] omap: Make uncompress code and DEBUG_LL code generic
In-Reply-To: <4BDB0353.5090800@ti.com>
References: <20100126200646.15382.52167.stgit@baageli.muru.com>
	<20100126201239.15382.34792.stgit@baageli.muru.com>
	<1272640022.3051.1534.camel@localhost> <4BDB0353.5090800@ti.com>
Message-ID: <20100430171802.GB1639@n2100.arm.linux.org.uk>

On Fri, Apr 30, 2010 at 12:20:35PM -0400, Cyril Chemparathy wrote:
> Hi,
> 
> [...]
> > To fix both problems, maybe we should just use a fixed memory location
> > to pass this temporary data from uncompress to the kernel.  We've had a
> > similar problem on DaVinci recently and a proposal has been made (and
> > tested) to use memory just below the page tables[3].)
> 
> Essentially both of these approaches (internal scratch register and
> fixed address) implement a weird back-channel communication scheme
> between the decompresser and the debug macros.
> 
> A more elegant solution may be as follows:
>     - pass machine_arch_type as an argument into addruart.

Unfortunately, that breaks addruart.  Firstly, addruart is used from
assembly code where very limited registers are available (the fewer
registers it clobbers the less likely debug is going to cause stuff
to break.)

Secondly, the places that addruart may be called from, the location
of the machine type number is indeterminent.  Remember that this
macro can be called when the MMU is on or off, and can be called
before the machine_arch_type has been initialized.

>     - move the uart base lookup logic to addruart using macros similar
>       to DEBUG_LL_*, except that these expand to assembly code this
>       time.
>     - reuse these debug-macros in uncompress.h and implement putc() and
>       flush() using addruart(), senduart(), etc.

Given what I've said above about the debug macros, this is definitely the
wrong solution.

Having the decompressor macros work whatever the machine type is
reasonable, and the machine_is_xxx() macros already work at that point,
so there shouldn't be much of an issue there.

As far as the debug macros go, I think we're at the point where it's
basically just far easier to leave these macros as a developer debugging
tool and we'll just have to put up with it being something that an OMAP
developer has to edit according to his platform to make work.

After all, _NO_ production kernel what so ever should be using this
debug support.

From tony at atomide.com  Fri Apr 30 11:49:53 2010
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 30 Apr 2010 09:49:53 -0700
Subject: [PATCH 02/14] omap: Make uncompress code and DEBUG_LL code generic
In-Reply-To: <4BDB0353.5090800@ti.com>
References: <20100126200646.15382.52167.stgit@baageli.muru.com>
	<20100126201239.15382.34792.stgit@baageli.muru.com>
	<1272640022.3051.1534.camel@localhost> <4BDB0353.5090800@ti.com>
Message-ID: <20100430164953.GD29604@atomide.com>

* Cyril Chemparathy <cyril at ti.com> [100430 09:22]:
> Hi,
> 
> [...]
> > To fix both problems, maybe we should just use a fixed memory location
> > to pass this temporary data from uncompress to the kernel.  We've had a
> > similar problem on DaVinci recently and a proposal has been made (and
> > tested) to use memory just below the page tables[3].)
> 
> Essentially both of these approaches (internal scratch register and
> fixed address) implement a weird back-channel communication scheme
> between the decompresser and the debug macros.
> 
> A more elegant solution may be as follows:
>     - pass machine_arch_type as an argument into addruart.
>     - move the uart base lookup logic to addruart using macros similar
>       to DEBUG_LL_*, except that these expand to assembly code this
>       time.
>     - reuse these debug-macros in uncompress.h and implement putc() and
>       flush() using addruart(), senduart(), etc.
> 
> This way, both the decompresser and the kernel debug macros end up using
> machine_arch_type to get to the right debug uart, without resorting to
> underhand back-channel tricks.
> 
> Any thoughts?

Sounds good to me. There's already the tmp register added to addruart
that can be used for passing the machine id to addruart.

Regards,

Tony

From tony at atomide.com  Fri Apr 30 13:47:12 2010
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 30 Apr 2010 11:47:12 -0700
Subject: [PATCH 02/14] omap: Make uncompress code and DEBUG_LL code generic
In-Reply-To: <20100430171802.GB1639@n2100.arm.linux.org.uk>
References: <20100126200646.15382.52167.stgit@baageli.muru.com>
	<20100126201239.15382.34792.stgit@baageli.muru.com>
	<1272640022.3051.1534.camel@localhost> <4BDB0353.5090800@ti.com>
	<20100430171802.GB1639@n2100.arm.linux.org.uk>
Message-ID: <20100430184712.GF29604@atomide.com>

* Russell King - ARM Linux <linux at arm.linux.org.uk> [100430 10:13]:
> On Fri, Apr 30, 2010 at 12:20:35PM -0400, Cyril Chemparathy wrote:
> > Hi,
> > 
> > [...]
> > > To fix both problems, maybe we should just use a fixed memory location
> > > to pass this temporary data from uncompress to the kernel.  We've had a
> > > similar problem on DaVinci recently and a proposal has been made (and
> > > tested) to use memory just below the page tables[3].)
> > 
> > Essentially both of these approaches (internal scratch register and
> > fixed address) implement a weird back-channel communication scheme
> > between the decompresser and the debug macros.
> > 
> > A more elegant solution may be as follows:
> >     - pass machine_arch_type as an argument into addruart.
> 
> Unfortunately, that breaks addruart.  Firstly, addruart is used from
> assembly code where very limited registers are available (the fewer
> registers it clobbers the less likely debug is going to cause stuff
> to break.)

Right, this would be tricky.
 
> Secondly, the places that addruart may be called from, the location
> of the machine type number is indeterminent.  Remember that this
> macro can be called when the MMU is on or off, and can be called
> before the machine_arch_type has been initialized.

Another good point here.
 
> >     - move the uart base lookup logic to addruart using macros similar
> >       to DEBUG_LL_*, except that these expand to assembly code this
> >       time.
> >     - reuse these debug-macros in uncompress.h and implement putc() and
> >       flush() using addruart(), senduart(), etc.
> 
> Given what I've said above about the debug macros, this is definitely the
> wrong solution.
> 
> Having the decompressor macros work whatever the machine type is
> reasonable, and the machine_is_xxx() macros already work at that point,
> so there shouldn't be much of an issue there.

Just to bring it up, there's one issue to consider here though.
When the bootloader passes a wrong machine id, chances are things
break with no debug output.
 
> As far as the debug macros go, I think we're at the point where it's
> basically just far easier to leave these macros as a developer debugging
> tool and we'll just have to put up with it being something that an OMAP
> developer has to edit according to his platform to make work.
> 
> After all, _NO_ production kernel what so ever should be using this
> debug support.

Things work now for mach-omap2, but we assume the first uart is always 
in the same location. If this changes, then using some fixed memory
location for storing the debug configuration is probably the best way
to go considering the issues Russell mentioned.

Regards,

Tony


From jtobias at viaas.com  Fri Apr 30 15:15:30 2010
From: jtobias at viaas.com (John Tobias)
Date: Fri, 30 Apr 2010 13:15:30 -0700
Subject: UBL Question
In-Reply-To: <j2l66b2b2311004301151u4c6632ddq49f005be818a36b5@mail.gmail.com>
References: <o2o66b2b2311004301114m5992da85s156d0ace0e3afec1@mail.gmail.com>
	<y2s763e54b1004301134u80ee97c5w249e758c3b64368f@mail.gmail.com>
	<j2l66b2b2311004301151u4c6632ddq49f005be818a36b5@mail.gmail.com>
Message-ID: <t2v66b2b2311004301315wdb4652f1me76661bf31c4a9dc@mail.gmail.com>

Hi Mike,

I've used this two commands to copy the image on block 5 then, copy it over
to block 1.

dd if=/dev/mtd5 of=/ubl.bin bs=512 count=32
dd if=/ubl.bin of=/dev/mtd1 bs=512 count=32
(My NAND flash has 512 bytes per page with 32 pages per block or 16Kbytes in
 1 block).

In order to test the block 1 if it's working, I erased the block 5 and boot
my device but, it doesn't work.

Any idea?

Thanks,

John


On Fri, Apr 30, 2010 at 11:51 AM, John Tobias <jtobias at viaas.com> wrote:

> Hi Mike,
>
> Yes, that's my plan. I will expose the ubl blocks from linux userspace and
> become writable.
> And, I like the idea of using dd so no need to worry about the CRC issue.
>
> Thanks,
>
> John
>
> On Fri, Apr 30, 2010 at 11:34 AM, Mike Williamson <
> michael.williamson at criticallink.com> wrote:
>
>> Hi John,
>>
>> In the past, we've used the /dev/mtd* devices to write data back to NOR
>> (spi / parallel) devices for updating firmware using something like:
>>
>> dd if=newimage.bin of=/dev/mtd0
>>
>> Of course, you need to have your kernel configured to have the mtd drivers
>> loaded and you need to make these areas writable (most linux board packages
>> set these to read-only, given the sizeable gun you have pointed at your
>> shoes....)
>>
>> -Mike
>>
>>
>> On Fri, Apr 30, 2010 at 2:14 PM, John Tobias <jtobias at viaas.com> wrote:
>>
>>>  Hi,
>>>
>>> Does anyone successfully written the UBL image in block 1/5 from linux
>>> userspace? I need a way to write the ubl image for the firmware upgrade and
>>> the only access that I have is the linux userspace.
>>>
>>>
>>> Thanks,
>>>
>>> John
>>>
>>> _______________________________________________
>>> Davinci-linux-open-source mailing list
>>> Davinci-linux-open-source at linux.davincidsp.com
>>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>>>
>>>
>>
>>
>> --
>> Michael Williamson
>> 315-425-4045x230
>> www.criticallink.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100430/3dd1abb0/attachment.html>

From khilman at deeprootsystems.com  Fri Apr 30 16:16:22 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 30 Apr 2010 14:16:22 -0700
Subject: [PATCH 02/14] omap: Make uncompress code and DEBUG_LL code generic
In-Reply-To: <20100430184712.GF29604@atomide.com> (Tony Lindgren's message of
	"Fri\, 30 Apr 2010 11\:47\:12 -0700")
References: <20100126200646.15382.52167.stgit@baageli.muru.com>
	<20100126201239.15382.34792.stgit@baageli.muru.com>
	<1272640022.3051.1534.camel@localhost> <4BDB0353.5090800@ti.com>
	<20100430171802.GB1639@n2100.arm.linux.org.uk>
	<20100430184712.GF29604@atomide.com>
Message-ID: <874oisiqu1.fsf@deeprootsystems.com>

Tony Lindgren <tony at atomide.com> writes:

> * Russell King - ARM Linux <linux at arm.linux.org.uk> [100430 10:13]:
>> On Fri, Apr 30, 2010 at 12:20:35PM -0400, Cyril Chemparathy wrote:
>> > Hi,
>> > 
>> > [...]
>> > > To fix both problems, maybe we should just use a fixed memory location
>> > > to pass this temporary data from uncompress to the kernel.  We've had a
>> > > similar problem on DaVinci recently and a proposal has been made (and
>> > > tested) to use memory just below the page tables[3].)
>> > 
>> > Essentially both of these approaches (internal scratch register and
>> > fixed address) implement a weird back-channel communication scheme
>> > between the decompresser and the debug macros.
>> > 
>> > A more elegant solution may be as follows:
>> >     - pass machine_arch_type as an argument into addruart.
>> 
>> Unfortunately, that breaks addruart.  Firstly, addruart is used from
>> assembly code where very limited registers are available (the fewer
>> registers it clobbers the less likely debug is going to cause stuff
>> to break.)
>
> Right, this would be tricky.
>  
>> Secondly, the places that addruart may be called from, the location
>> of the machine type number is indeterminent.  Remember that this
>> macro can be called when the MMU is on or off, and can be called
>> before the machine_arch_type has been initialized.
>
> Another good point here.
>  
>> >     - move the uart base lookup logic to addruart using macros similar
>> >       to DEBUG_LL_*, except that these expand to assembly code this
>> >       time.
>> >     - reuse these debug-macros in uncompress.h and implement putc() and
>> >       flush() using addruart(), senduart(), etc.
>> 
>> Given what I've said above about the debug macros, this is definitely the
>> wrong solution.
>> 
>> Having the decompressor macros work whatever the machine type is
>> reasonable, and the machine_is_xxx() macros already work at that point,
>> so there shouldn't be much of an issue there.
>
> Just to bring it up, there's one issue to consider here though.
> When the bootloader passes a wrong machine id, chances are things
> break with no debug output.
>  
>> As far as the debug macros go, I think we're at the point where it's
>> basically just far easier to leave these macros as a developer debugging
>> tool and we'll just have to put up with it being something that an OMAP
>> developer has to edit according to his platform to make work.
>> 
>> After all, _NO_ production kernel what so ever should be using this
>> debug support.
>
> Things work now for mach-omap2, but we assume the first uart is always 
> in the same location. If this changes, then using some fixed memory
> location for storing the debug configuration is probably the best way
> to go considering the issues Russell mentioned.

I agree, using a fixed memory location seems the best way to keep this
working across new devices with different UART1 base.

Kevin

From khilman at deeprootsystems.com  Fri Apr 30 16:32:51 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 30 Apr 2010 14:32:51 -0700
Subject: [RFC 00/22] Davinci: pre-tnetv107x ioremap() cleanup
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Thu\, 29 Apr 2010 18\:27\:26 -0400")
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <87hbmshbi4.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> This series takes a new approach to the ioremap() conundrum posed by the
> introduction of the tnetv107x architecture.
>
> Unlike earlier approaches, no new init time interfaces have been added in this
> implementation.  Instead, this series converts the contents of davinci_soc_info
> to use physical instead of virtual addresses.  These physical addresses are
> then ioremap()ed as necessary in each individual module (psc, timer, etc.).
>
> As a pleasant side-effect, this series also gets rid of a bunch of IO_ADDRESS()
> uses. :-)
>
> These changes were tested only on the tnetv107x evm platform.

I really like this direction.  Thanks for putting in the extra work to
push us to the next level.

Was there supposed to be 22 patches, I only saw 16 and the shortlog below
only lists 16 as well.

Also, can you separate out the GPIO cleanup/rework (patches 2-7) into
a separate series.  I'm ready to merge that independently of the debug
macros and this ioremap rework.

Kevin

From khilman at deeprootsystems.com  Fri Apr 30 16:34:30 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 30 Apr 2010 14:34:30 -0700
Subject: [RFC 09/22] Davinci: jtag_id - use ioremap()
In-Reply-To: <1272580062-17663-10-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Thu\, 29 Apr 2010 18\:27\:35 -0400")
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
	<1272580062-17663-10-git-send-email-cyril@ti.com>
Message-ID: <87aaskhbfd.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> This patch replaces the jtag id base info in davinci_soc_info with a physical
> address which is then ioremap()ed within common code.
>
> This patch (in combination with a similar change for PSC) will allow us to
> eliminate the SYSCFG nastiness in DA8xx code.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>

me likey

[...]

> -static struct davinci_id * __init davinci_get_id(u32 jtag_id)
> +static int __init davinci_init_id(struct davinci_soc_info *soc_info)
>  {
> -	int i;
> -	struct davinci_id *dip;
> -	u8 variant = (jtag_id & 0xf0000000) >> 28;
> -	u16 part_no = (jtag_id & 0x0ffff000) >> 12;
> +	int			i;
> +	struct davinci_id	*dip;
> +	u8			variant;
> +	u16			part_no;
> +	void __iomem		*base;
> +
> +	base = ioremap(davinci_soc_info.jtag_id_reg, SZ_4K);
> +	if (!base) {
> +		pr_err("Unable to map JTAG ID register\n");
> +		return -EINVAL;

minor nit: use -ENOMEM for failed allocations.

Kevin

From khilman at deeprootsystems.com  Fri Apr 30 16:38:16 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 30 Apr 2010 14:38:16 -0700
Subject: [RFC 11/22] Davinci: psc - use ioremap()
In-Reply-To: <1272580062-17663-12-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Thu\, 29 Apr 2010 18\:27\:37 -0400")
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
	<1272580062-17663-12-git-send-email-cyril@ti.com>
Message-ID: <8739ychb93.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> This patch modifies the psc and clock control code to use ioremap()ed
> registers.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>

me really likey

[...]

> @@ -458,8 +457,17 @@ int __init davinci_clk_init(struct clk_lookup *clocks)
>  				clk->recalc = clk_leafclk_recalc;
>  		}
>  
> -		if (clk->pll_data && !clk->pll_data->div_ratio_mask)
> -			clk->pll_data->div_ratio_mask = PLLDIV_RATIO_MASK;
> +		if (clk->pll_data) {
> +			struct pll_data *pll = clk->pll_data;
> +
> +			if (!pll->div_ratio_mask)
> +				pll->div_ratio_mask = PLLDIV_RATIO_MASK;
> +
> +			if (pll->phys_base && !pll->base) {
> +				pll->base = ioremap(pll->phys_base, SZ_4K);
> +				BUG_ON(!pll->base);

except this.  please use WARN_ON() and fail more gracefully

Kevin

From khilman at deeprootsystems.com  Fri Apr 30 16:43:59 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 30 Apr 2010 14:43:59 -0700
Subject: [RFC 12/22] Davinci: aintc/cpintc - use ioremap()
In-Reply-To: <1272580062-17663-13-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Thu\, 29 Apr 2010 18\:27\:38 -0400")
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
	<1272580062-17663-13-git-send-email-cyril@ti.com>
Message-ID: <87r5lwfwf4.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> This patch implements the following:
>
>  - interrupt initialization uses ioremap() instead of passing a virtual address
>    via davinci_soc_info.
>
>  - machine definitions directly point to cp_intc_init() or davinci_irq_init()
>
>  - davinci_intc_type and davinci_intc_base now get initialized in controller
>    specific init functions instead of davinci_common_init()
>
>  - minor fix in davinci_irq_init() to use intc_irq_num instead of
>    DAVINCI_N_AINTC_IRQ
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> ---
>  arch/arm/mach-davinci/board-da830-evm.c      |   10 +---------
>  arch/arm/mach-davinci/board-da850-evm.c      |   10 +---------
>  arch/arm/mach-davinci/board-dm355-evm.c      |    7 +------
>  arch/arm/mach-davinci/board-dm355-leopard.c  |    7 +------
>  arch/arm/mach-davinci/board-dm365-evm.c      |    7 +------
>  arch/arm/mach-davinci/board-dm644x-evm.c     |    7 +------
>  arch/arm/mach-davinci/board-dm646x-evm.c     |    9 ++-------
>  arch/arm/mach-davinci/board-neuros-osd2.c    |    7 +------
>  arch/arm/mach-davinci/board-sffsdr.c         |    7 +------
>  arch/arm/mach-davinci/common.c               |    2 --

now that is a nice looking diffstat :)

no, really...  it's beautiful!  I can have a very peaceful weekend now
after looking at this, thanks!

cyril_beer_IOU++

Kevin

>  arch/arm/mach-davinci/cp_intc.c              |   18 +++++++++++-------
>  arch/arm/mach-davinci/da830.c                |    2 +-
>  arch/arm/mach-davinci/da850.c                |    2 +-
>  arch/arm/mach-davinci/dm355.c                |    2 +-
>  arch/arm/mach-davinci/dm365.c                |    2 +-
>  arch/arm/mach-davinci/dm644x.c               |    2 +-
>  arch/arm/mach-davinci/dm646x.c               |    2 +-
>  arch/arm/mach-davinci/include/mach/common.h  |    3 ++-
>  arch/arm/mach-davinci/include/mach/cp_intc.h |    3 +--
>  arch/arm/mach-davinci/irq.c                  |    7 ++++++-
>  20 files changed, 36 insertions(+), 80 deletions(-)

From khilman at deeprootsystems.com  Fri Apr 30 16:46:48 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 30 Apr 2010 14:46:48 -0700
Subject: [RFC 13/22] Davinci: pinmux - use ioremap()
In-Reply-To: <1272580062-17663-14-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Thu\, 29 Apr 2010 18\:27\:39 -0400")
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
	<1272580062-17663-14-git-send-email-cyril@ti.com>
Message-ID: <87k4rofwaf.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> This patch modifies the pinmux implementation so as to ioremap() the pinmux
> register area on first use.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>

overall, very nice again.  one minor nit...

[...]

> diff --git a/arch/arm/mach-davinci/mux.c b/arch/arm/mach-davinci/mux.c
> index e9d530a..28b1b83 100644
> --- a/arch/arm/mach-davinci/mux.c
> +++ b/arch/arm/mach-davinci/mux.c
> @@ -22,6 +22,8 @@
>  #include <mach/mux.h>
>  #include <mach/common.h>
>  
> +static void __iomem *pinmux_base;
> +
>  /*
>   * Sets the DAVINCI MUX register based on the table
>   */
> @@ -29,7 +31,6 @@ int __init_or_module davinci_cfg_reg(const unsigned long index)
>  {
>  	static DEFINE_SPINLOCK(mux_spin_lock);
>  	struct davinci_soc_info *soc_info = &davinci_soc_info;
> -	void __iomem *base = soc_info->pinmux_base;
>  	unsigned long flags;
>  	const struct mux_config *cfg;
>  	unsigned int reg_orig = 0, reg = 0;
> @@ -38,6 +39,11 @@ int __init_or_module davinci_cfg_reg(const unsigned long index)
>  	if (!soc_info->pinmux_pins)
>  		BUG();
>  
> +	if (!pinmux_base) {
> +		pinmux_base = ioremap(soc_info->pinmux_base, SZ_4K);
> +		BUG_ON(!pinmux_base);
> +	}
> +

Again, should fail more gracefully, and might as well fix BUG right
above this one while you're at it (with a comment in the changelog of
course.)

Kevin

From khilman at deeprootsystems.com  Fri Apr 30 16:48:32 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 30 Apr 2010 14:48:32 -0700
Subject: [RFC 14/22] Davinci: eliminate pinmux offset verbosity
In-Reply-To: <1272580062-17663-15-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Thu\, 29 Apr 2010 18\:27\:40 -0400")
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
	<1272580062-17663-15-git-send-email-cyril@ti.com>
Message-ID: <878w84fw7j.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> Pinmux registers are sequential, and do not need to be enumerated out as they
> currently are.  This reduces code volume and keeps things simple.
>
> If some future SoC comes up with a discontiguous register map, PINMUX() can
> then be expanded with local token pasting.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>

This one is ready for merge, and not related to the ioremap stuff.  
Please include in with the GPIO stuff that's ready for merge.

Kevin

From khilman at deeprootsystems.com  Fri Apr 30 16:50:17 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 30 Apr 2010 14:50:17 -0700
Subject: [RFC 15/22] Davinci: watchdog reset separation across socs
In-Reply-To: <1272580062-17663-16-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Thu\, 29 Apr 2010 18\:27\:41 -0400")
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
	<1272580062-17663-16-git-send-email-cyril@ti.com>
Message-ID: <87wrvoehk6.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> The earlier watchdog reset mechanism had a couple of limitations.  First, it
> embedded a reference to "davinci_wdt_device" inside common code.  This
> forced all derived platforms (da8xx and tnetv107x) to define such a device.
> This also would have caused problems in including multiple socs in a single
> build due to symbol redefinition.
>
> With this patch, davinci_watchdog_reset() now takes the platform device as an
> argument.  The davinci_soc_info struct has been extended to include a reset
> function and a watchdog platform_device.  arch_reset() then uses these
> elements to reset the system in a SoC specific fashion.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>

This one too is ready for merge.  Please include with GPIO + mux

Kevin

From sxie at grandstream.com  Fri Apr 30 16:50:38 2010
From: sxie at grandstream.com (Shaoyun Xie)
Date: Fri, 30 Apr 2010 16:50:38 -0500
Subject: UBL Question
In-Reply-To: <t2v66b2b2311004301315wdb4652f1me76661bf31c4a9dc@mail.gmail.com>
References: <o2o66b2b2311004301114m5992da85s156d0ace0e3afec1@mail.gmail.com>
	<y2s763e54b1004301134u80ee97c5w249e758c3b64368f@mail.gmail.com>
	<j2l66b2b2311004301151u4c6632ddq49f005be818a36b5@mail.gmail.com>
	<t2v66b2b2311004301315wdb4652f1me76661bf31c4a9dc@mail.gmail.com>
Message-ID: <1272664238.886.149.camel@sxie-laptop>

John,

>From my understanding, UBL is using special ECC scheme which is not same
as default one using in kernel. Normal dd will not work unless you
change MTD driver to detect UBL write.

Shaoyun


On Fri, 2010-04-30 at 13:15 -0700, John Tobias wrote:

> Hi Mike,
> 
> 
> 
> I've used this two commands to copy the image on block 5 then, copy it
> over to block 1. 
> 
> 
> dd if=/dev/mtd5 of=/ubl.bin bs=512 count=32 
> dd if=/ubl.bin of=/dev/mtd1 bs=512 count=32
> (My NAND flash has 512 bytes per page with 32 pages per block or
> 16Kbytes in  1 block).
> 
> 
> In order to test the block 1 if it's working, I erased the block 5 and
> boot my device but, it doesn't work.
> 
> 
> Any idea?
> 
> 
> Thanks,
> 
> 
> John 
> 
> 
> 
> 
> 
> On Fri, Apr 30, 2010 at 11:51 AM, John Tobias <jtobias at viaas.com>
> wrote:
> 
>         Hi Mike,
>         
>         
>         
>         Yes, that's my plan. I will expose the ubl blocks from linux
>         userspace and become writable.
>         And, I like the idea of using dd so no need to worry about the
>         CRC issue. 
>         
>         
>         Thanks,
>         
>         
>         John
>         
>         
>         
>         On Fri, Apr 30, 2010 at 11:34 AM, Mike Williamson
>         <michael.williamson at criticallink.com> wrote:
>         
>                 Hi John,
>                 
>                 In the past, we've used the /dev/mtd* devices to write
>                 data back to NOR (spi / parallel) devices for updating
>                 firmware using something like:
>                 
>                 dd if=newimage.bin of=/dev/mtd0 
>                 
>                 Of course, you need to have your kernel configured to
>                 have the mtd drivers loaded and you need to make these
>                 areas writable (most linux board packages set these to
>                 read-only, given the sizeable gun you have pointed at
>                 your shoes....)
>                 
>                 -Mike
>                 
>                 
>                 
>                 
>                 On Fri, Apr 30, 2010 at 2:14 PM, John Tobias
>                 <jtobias at viaas.com> wrote:
>                 
>                         
>                         Hi,
>                         
>                         Does anyone successfully written the UBL image
>                         in block 1/5 from linux userspace? I need a
>                         way to write the ubl image for the firmware
>                         upgrade and the only access that I have is the
>                         linux userspace.
>                         
>                         
>                         Thanks,
>                         
>                         John
>                         
>                         
>                         
>                         
>                         
>                         
>                         _______________________________________________
>                         Davinci-linux-open-source mailing list
>                         Davinci-linux-open-source at linux.davincidsp.com
>                         http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>                         
>                 
>                 
>                 
>                 
>                 -- 
>                 Michael Williamson
>                 315-425-4045x230
>                 www.criticallink.com
>         
>         
>         
> 
> 
> 
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100430/7faadbd2/attachment.html>

From khilman at deeprootsystems.com  Fri Apr 30 16:52:09 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 30 Apr 2010 14:52:09 -0700
Subject: [RFC 16/22] Davinci: iotable based ioremap() interception
In-Reply-To: <1272580062-17663-17-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Thu\, 29 Apr 2010 18\:27\:42 -0400")
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
	<1272580062-17663-17-git-send-email-cyril@ti.com>
Message-ID: <87pr1gehh2.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> This patch allows for a more flexible ioremap() interception based on iotable
> contents.

Changelog needs a little more verbosity, especially around why
the common init is now before the first ioremap.

Kevin

From sid at dsicentral.com  Fri Apr 30 16:57:56 2010
From: sid at dsicentral.com (Siddharth Choudhuri)
Date: Fri, 30 Apr 2010 14:57:56 -0700
Subject: UBL Question
In-Reply-To: <t2v66b2b2311004301315wdb4652f1me76661bf31c4a9dc@mail.gmail.com>
References: <o2o66b2b2311004301114m5992da85s156d0ace0e3afec1@mail.gmail.com>
	<y2s763e54b1004301134u80ee97c5w249e758c3b64368f@mail.gmail.com>
	<j2l66b2b2311004301151u4c6632ddq49f005be818a36b5@mail.gmail.com>
	<t2v66b2b2311004301315wdb4652f1me76661bf31c4a9dc@mail.gmail.com>
Message-ID: <E7D5CF88-E988-43FF-B15E-840475F51482@dsicentral.com>

Does dd also take care of writing the OOB area along with the actual  
data ? The OOB layout where the ECC is written could be an issue IMO.  
You might want to look at nandwrite i.e., read using nanddump -> erase  
-> nandwrite to see if it works. Also, nanddump and nandwrite might  
have an option to read page data and/or OOB.

-sid

On Apr 30, 2010, at 1:15 PM, John Tobias wrote:

> Hi Mike,
>
> I've used this two commands to copy the image on block 5 then, copy  
> it over to block 1.
>
> dd if=/dev/mtd5 of=/ubl.bin bs=512 count=32
> dd if=/ubl.bin of=/dev/mtd1 bs=512 count=32
> (My NAND flash has 512 bytes per page with 32 pages per block or  
> 16Kbytes in  1 block).
>
> In order to test the block 1 if it's working, I erased the block 5  
> and boot my device but, it doesn't work.
>
> Any idea?
>
> Thanks,
>
> John
>
>
> On Fri, Apr 30, 2010 at 11:51 AM, John Tobias <jtobias at viaas.com>  
> wrote:
> Hi Mike,
>
> Yes, that's my plan. I will expose the ubl blocks from linux  
> userspace and become writable.
> And, I like the idea of using dd so no need to worry about the CRC  
> issue.
>
> Thanks,
>
> John
>
> On Fri, Apr 30, 2010 at 11:34 AM, Mike Williamson <michael.williamson at criticallink.com 
> > wrote:
> Hi John,
>
> In the past, we've used the /dev/mtd* devices to write data back to  
> NOR (spi / parallel) devices for updating firmware using something  
> like:
>
> dd if=newimage.bin of=/dev/mtd0
>
> Of course, you need to have your kernel configured to have the mtd  
> drivers loaded and you need to make these areas writable (most linux  
> board packages set these to read-only, given the sizeable gun you  
> have pointed at your shoes....)
>
> -Mike
>
>
> On Fri, Apr 30, 2010 at 2:14 PM, John Tobias <jtobias at viaas.com>  
> wrote:
> Hi,
>
> Does anyone successfully written the UBL image in block 1/5 from  
> linux userspace? I need a way to write the ubl image for the  
> firmware upgrade and the only access that I have is the linux  
> userspace.
>
>
> Thanks,
>
> John
>
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>
>
>
> -- 
> Michael Williamson
> 315-425-4045x230
> www.criticallink.com
>
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100430/eeb35d52/attachment-0001.html>

From khilman at deeprootsystems.com  Fri Apr 30 16:57:56 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 30 Apr 2010 14:57:56 -0700
Subject: [RFC 00/22] Davinci: pre-tnetv107x ioremap() cleanup
In-Reply-To: <1272580062-17663-1-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Thu\, 29 Apr 2010 18\:27\:26 -0400")
References: <1272580062-17663-1-git-send-email-cyril@ti.com>
Message-ID: <874oiseh7f.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> This series takes a new approach to the ioremap() conundrum posed by the
> introduction of the tnetv107x architecture.
>
> Unlike earlier approaches, no new init time interfaces have been added in this
> implementation.  Instead, this series converts the contents of davinci_soc_info
> to use physical instead of virtual addresses.  These physical addresses are
> then ioremap()ed as necessary in each individual module (psc, timer, etc.).
>
> As a pleasant side-effect, this series also gets rid of a bunch of IO_ADDRESS()
> uses. :-)

As another pleasant side effect, you made my day. :)

This is something that's been on my TODO for some time and I've been
ignoring it.   Thanks a ton for tackling it.

So as a next step, lets break out the stuff I mentioned as ready to
merge into a separate series, and get that applied and in davinci-next
for 2.6.35.  Then, fixup some of the very minor issues I pointed out
and get some more testing on your ioremap series for the existing
platforms as well...

> These changes were tested only on the tnetv107x evm platform.

I tried a boot test on dm355 and da8xx and neither booted, but didn't
do any more digging, because I want to take off for the weekend on a
happy note. :)

Next step is to track the boot problems on dm* and da* and then get
this merged.  If we take care of it next week, I'd like to queue this
up for 2.6.35.

Thanks again Cyril,  and nice work!

Kevin

From jtobias at viaas.com  Fri Apr 30 17:19:56 2010
From: jtobias at viaas.com (John Tobias)
Date: Fri, 30 Apr 2010 15:19:56 -0700
Subject: UBL Question
In-Reply-To: <E7D5CF88-E988-43FF-B15E-840475F51482@dsicentral.com>
References: <o2o66b2b2311004301114m5992da85s156d0ace0e3afec1@mail.gmail.com>
	<y2s763e54b1004301134u80ee97c5w249e758c3b64368f@mail.gmail.com>
	<j2l66b2b2311004301151u4c6632ddq49f005be818a36b5@mail.gmail.com>
	<t2v66b2b2311004301315wdb4652f1me76661bf31c4a9dc@mail.gmail.com>
	<E7D5CF88-E988-43FF-B15E-840475F51482@dsicentral.com>
Message-ID: <s2r66b2b2311004301519pf2622273x53e09e53d1a24853@mail.gmail.com>

I've used the following commands and didn't get any success.

1. nanddump -n -f /ubl.bin /dev/mtd5
Block size 16384, page size 512, OOB size 16
Dumping data starting at 0x00000000 and ending at 0x00004000

2. flash_erase /dev/mtd1

3. nandwrite -n -o /dev/mtd1 /ubl.bin

4. flash_erase /dev/mtd5

Any more idea?

Thanks,

John



On Fri, Apr 30, 2010 at 2:57 PM, Siddharth Choudhuri <sid at dsicentral.com>wrote:

> Does dd also take care of writing the OOB area along with the actual data ?
> The OOB layout where the ECC is written could be an issue IMO. You might
> want to look at nandwrite i.e., read using nanddump -> erase -> nandwrite to
> see if it works. Also, nanddump and nandwrite might have an option to read
> page data and/or OOB.
>
> -sid
>
> On Apr 30, 2010, at 1:15 PM, John Tobias wrote:
>
> Hi Mike,
>
> I've used this two commands to copy the image on block 5 then, copy it over
> to block 1.
>
> dd if=/dev/mtd5 of=/ubl.bin bs=512 count=32
> dd if=/ubl.bin of=/dev/mtd1 bs=512 count=32
> (My NAND flash has 512 bytes per page with 32 pages per block or 16Kbytes
> in  1 block).
>
> In order to test the block 1 if it's working, I erased the block 5 and boot
> my device but, it doesn't work.
>
> Any idea?
>
> Thanks,
>
> John
>
>
> On Fri, Apr 30, 2010 at 11:51 AM, John Tobias <jtobias at viaas.com> wrote:
>
>> Hi Mike,
>>
>> Yes, that's my plan. I will expose the ubl blocks from linux userspace and
>> become writable.
>> And, I like the idea of using dd so no need to worry about the CRC issue.
>>
>> Thanks,
>>
>> John
>>
>> On Fri, Apr 30, 2010 at 11:34 AM, Mike Williamson <
>> michael.williamson at criticallink.com> wrote:
>>
>>> Hi John,
>>>
>>> In the past, we've used the /dev/mtd* devices to write data back to NOR
>>> (spi / parallel) devices for updating firmware using something like:
>>>
>>> dd if=newimage.bin of=/dev/mtd0
>>>
>>> Of course, you need to have your kernel configured to have the mtd
>>> drivers loaded and you need to make these areas writable (most linux board
>>> packages set these to read-only, given the sizeable gun you have pointed at
>>> your shoes....)
>>>
>>> -Mike
>>>
>>>
>>> On Fri, Apr 30, 2010 at 2:14 PM, John Tobias <jtobias at viaas.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Does anyone successfully written the UBL image in block 1/5 from linux
>>>> userspace? I need a way to write the ubl image for the firmware upgrade and
>>>> the only access that I have is the linux userspace.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> John
>>>>
>>>> _______________________________________________
>>>> Davinci-linux-open-source mailing list
>>>> Davinci-linux-open-source at linux.davincidsp.com
>>>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>>>>
>>>>
>>>
>>>
>>> --
>>> Michael Williamson
>>> 315-425-4045x230
>>> www.criticallink.com
>>>
>>
>>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100430/32212a46/attachment.html>

From blueskyjb at roadrunner.com  Fri Apr 30 17:50:52 2010
From: blueskyjb at roadrunner.com (Jimmy Blair)
Date: Fri, 30 Apr 2010 15:50:52 -0700
Subject: AIC3x audio on the DM365
Message-ID: <4BDB5ECC.8010402@roadrunner.com>

I'm using Mplayer to play an MP3 audio file (sample rate 44.1KHz)
on the DM365.  The audio is playing slightly fast -- a 535 second
audio clip plays in 533 seconds.  The problem is even worse on the
MVL kernel.  Them same 535 second clip plays in 505 seconds.  Has
anybody else encountered an audio problem like this?