RE: How to deinterlace on dm6467 for D1 videos ?
Hi, It is not possible to do deinterlacing in VDCE as it can only do down scaling. Thanks, Brijesh -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of yang shaobo Sent: Friday, August 28, 2009 10:40 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: How to deinterlace on dm6467 for D1 videos ? I am using dm6467 to encode D1 videos ( captured from TVP5147 ). I know that the resizer of dm6446 and the IPIPE of dm355 can do simple deinterlacing for videos. Can the VDCE module of dm6467 do the similar thing ? Thanks. Best regards. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: How to deinterlace on dm6467 for D1 videos ?
Thanks for your reply. Is there any other way to do deinterlace ? 2009/8/28, Jadav, Brijesh R : > Hi, > > It is not possible to do deinterlacing in VDCE as it can only do down > scaling. > > Thanks, > Brijesh > > -Original Message- > From: davinci-linux-open-source-boun...@linux.davincidsp.com > [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of > yang shaobo > Sent: Friday, August 28, 2009 10:40 AM > To: davinci-linux-open-source@linux.davincidsp.com > Subject: How to deinterlace on dm6467 for D1 videos ? > > I am using dm6467 to encode D1 videos ( captured from TVP5147 ). > I know that the resizer of dm6446 and the IPIPE of dm355 can do simple > deinterlacing for videos. > Can the VDCE module of dm6467 do the similar thing ? > > Thanks. > Best regards. > > ___ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [patch 2.6.31-rc7] spi: davinci spi driver
Hello. David Brownell wrote: From: Sandeep Paulraj The patch adds a SPI driver for DaVinci series SOC's. [dbrown...@users.sourceforge.net: fixes and cleanup] Signed-off-by: Sandeep Paulraj Signed-off-by: David Brownell This patch lacks MV people's signoffs (and MV copyright on the driver). WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [patch 2.6.31-rc7] spi: davinci spi driver
Hello. David Brownell wrote: From: Sandeep Paulraj The patch adds a SPI driver for DaVinci series SOC's. [dbrown...@users.sourceforge.net: fixes and cleanup] Signed-off-by: Sandeep Paulraj Signed-off-by: David Brownell This patch lacks MV people's signoffs (and MV copyright on the driver). -ENOPATCH I don't recall seeing any version with MV attributions, FWIW. Because there was none. :-) I have just mailed Sandeep about this yesterday. WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [patch 2.6.31-rc7] spi: davinci spi driver
On Friday 28 August 2009, Sergei Shtylyov wrote: > Hello. > > David Brownell wrote: > > > From: Sandeep Paulraj > > > > The patch adds a SPI driver for DaVinci series SOC's. > > > > [dbrown...@users.sourceforge.net: fixes and cleanup] > > > > Signed-off-by: Sandeep Paulraj > > Signed-off-by: David Brownell > > > > This patch lacks MV people's signoffs (and MV copyright on the driver). -ENOPATCH I don't recall seeing any version with MV attributions, FWIW. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [patch 2.6.31-rc7] spi: davinci spi driver
Sergei, Dave, When i started this SPI process many moons ago, i am absolutely sure that i sent out e-mails on our internal TI MV mailing list asking for the appropriate signoffs. I can dig out the e-mails but i don't see what can be achieved on doing that. I did not get any responses then. Obviously that time the driver was not ready for submission and now seems an auspicious time. I'll take care of all pending issues, i.e signoffs, copyright(which as pointed out was not present in the original driver) and send the patch. Thanks, Sandeep From: davinci-linux-open-source-boun...@linux.davincidsp.com [davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Sergei Shtylyov [sshtyl...@ru.mvista.com] Sent: Friday, August 28, 2009 6:09 AM To: David Brownell Cc: spi-devel-gene...@lists.sourceforge.net; Andrew Morton; DaVinci Subject: Re: [patch 2.6.31-rc7] spi: davinci spi driver Hello. David Brownell wrote: >>> From: Sandeep Paulraj >>> >>> The patch adds a SPI driver for DaVinci series SOC's. >>> >>> [dbrown...@users.sourceforge.net: fixes and cleanup] >>> >>> Signed-off-by: Sandeep Paulraj >>> Signed-off-by: David Brownell >>> >>> >> This patch lacks MV people's signoffs (and MV copyright on the driver). >> > > -ENOPATCH > > I don't recall seeing any version with MV attributions, FWIW. Because there was none. :-) I have just mailed Sandeep about this yesterday. WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
DSP Server Search Path at Runtime
Hi, I wonder if there is any environment variable to control DSP server search path either in Codec Engine or Dsplink. Currently I copy(or link) my dsp binaries to $pwd before launcing any application. It would be helpful to define dsp search path with an env variable. Thanks for any pointers, Caglar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: How to deinterlace on dm6467 for D1 videos ?
No, you have to do some s/w dei only. Brijesh -Original Message- From: yang shaobo [mailto:yangs...@gmail.com] Sent: Friday, August 28, 2009 2:21 PM To: Jadav, Brijesh R Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: How to deinterlace on dm6467 for D1 videos ? Thanks for your reply. Is there any other way to do deinterlace ? 2009/8/28, Jadav, Brijesh R : > Hi, > > It is not possible to do deinterlacing in VDCE as it can only do down > scaling. > > Thanks, > Brijesh > > -Original Message- > From: davinci-linux-open-source-boun...@linux.davincidsp.com > [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of > yang shaobo > Sent: Friday, August 28, 2009 10:40 AM > To: davinci-linux-open-source@linux.davincidsp.com > Subject: How to deinterlace on dm6467 for D1 videos ? > > I am using dm6467 to encode D1 videos ( captured from TVP5147 ). > I know that the resizer of dm6446 and the IPIPE of dm355 can do simple > deinterlacing for videos. > Can the VDCE module of dm6467 do the similar thing ? > > Thanks. > Best regards. > > ___ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: audio issue on 2.6.31 kernel
On Fri, 2009-08-28 at 09:30 +0800, Jeff wrote: > All, > > > > When I played sound clip using ALSA interface + kernel 2.6.31 on DM355 > EVM, I can not hear anything. I can hear sound when I played it using > ASLA OSS emulation interface. But the sound volume is very low and > with some noise. Could anyone help me? Thanks a lot! > amixer can be used to adjust volume. Not sure about the noise. Regards, Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: both IDE and Flash are enabled, but they share AEMIF pins.Disable IDE for NAND/NOR support
On Fri, 2009-08-28 at 10:18 +0800, linghai624 wrote: > Hi，I'm trying to boot kernel 2.6.31-rc4 on dm6446 evm ,but when it > booted we can get this information both IDE and Flash are enabled, but > they share AEMIF pins.Disable IDE for NAND/NOR support. So I can't > mount my filesysterm via NFS, how to ? > Actually, the IDE/FLASH both enabled message has nothing to do with mount filesystem on NFS. The IDE/FLASH message is just a warning that you need to disable either IDE or FLASH in kernel config because they are pin muxed. In other words, only one will work, but not both at the same time. Assuming you enable NFS on kernel config and set up everything up correctly, it would just work. Regards, Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] ARM: DaVinci: Add or modify AIC3x I2C board info
On Fri, 2009-08-28 at 09:47 +0530, Chaithrika U S wrote: > On Fri, Aug 28, 2009 at 08:22:52, J.C. Wren wrote: > > This patch seems to break audio on a Davinci 6446 EVM. > > > > -rc7---> > > > > Hi, > > Which branch of the DaVinci GIT are you checking it on? > This patch works for temp/asoc branch. It will not work for the > master branch as some changes from the ASoC tree are not yet > available on master. > > Regards, > Chaithrika > > > Advanced Linux Sound Architecture Driver Version 1.0.20. > > No device for DAI tlv320aic3x > > No device for DAI davinci-i2s > > AIC3X Audio Codec 0.2 > > i2c-adapter i2c-1: Failed to register i2c client tlv320aic3x at 0x1b > > (-16) > > soc-audio soc-audio.0: can't add i2c device at 0x1b ALSA device list: > > No soundcards found. > > TCP cubic registered > > > > It was working under -rc5 ---> > > > > Advanced Linux Sound Architecture Driver Version 1.0.20. > > No device for DAI tlv320aic3x > > No device for DAI davinci-i2s > > AIC3X Audio Codec 0.2 > > asoc: tlv320aic3x <-> davinci-i2s mapping ok ALSA device list: > > #0: DaVinci EVM (tlv320aic3x) > > TCP cubic registered > > > > --jc > > > > On Wed, Aug 26, 2009 at 12:08 PM, Chaithrika U S > > wrote: > > > > > > This patch includes the codec I2C board info for DM6446 EVM > > and DM355 EVM. Also, it corrects the codec names in DA8xx/OMAP-L1xx > > board files. > > > > Tested on DM6446, DM355, DM6447, DA850 EVMs. > > Does this mean the patch was not tested on DA830 EVM? Should we expect the audio to work for DA830 on the tmp/asoc or master? Thanks Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Question about davinci-linux-open-source behavior
On Thu, 2009-08-27 at 22:31 -0400, J.C. Wren wrote: > Any time I post a message or a response, I get some garbaged message > back from gs5...@sina.com > Not exactly garbage if you read Chinese :-). The direct translation is "Received your e-mail, appreciate the cooperation" I also received this very annoying message when I post. In addition, I also received postmas...@paran.com saying To: seuh...@hitel.net, 402 Local User Inbox Full (seuh...@hitel.net) 5,5242,5242 If someone knows the proper authority to file a complain, please do share the information. Regards, Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] ARM: DaVinci: Add or modify AIC3x I2C board info
On Fri, Aug 28, 2009 at 17:04:08, Steve Chen wrote: > On Fri, 2009-08-28 at 09:47 +0530, Chaithrika U S wrote: > > On Fri, Aug 28, 2009 at 08:22:52, J.C. Wren wrote: > > > This patch seems to break audio on a Davinci 6446 EVM. > > > > > > -rc7---> > > > > > > > Hi, > > > > Which branch of the DaVinci GIT are you checking it on? > > This patch works for temp/asoc branch. It will not work for the > > master branch as some changes from the ASoC tree are not yet > > available on master. > > > > Regards, > > Chaithrika > > > > > Advanced Linux Sound Architecture Driver Version 1.0.20. > > > No device for DAI tlv320aic3x > > > No device for DAI davinci-i2s > > > AIC3X Audio Codec 0.2 > > > i2c-adapter i2c-1: Failed to register i2c client tlv320aic3x at 0x1b > > > (-16) > > > soc-audio soc-audio.0: can't add i2c device at 0x1b ALSA device list: > > > No soundcards found. > > > TCP cubic registered > > > > > > It was working under -rc5 ---> > > > > > > Advanced Linux Sound Architecture Driver Version 1.0.20. > > > No device for DAI tlv320aic3x > > > No device for DAI davinci-i2s > > > AIC3X Audio Codec 0.2 > > > asoc: tlv320aic3x <-> davinci-i2s mapping ok ALSA device list: > > > #0: DaVinci EVM (tlv320aic3x) > > > TCP cubic registered > > > > > > --jc > > > > > > On Wed, Aug 26, 2009 at 12:08 PM, Chaithrika U S > > > wrote: > > > > > > > > > This patch includes the codec I2C board info for DM6446 EVM > > > and DM355 EVM. Also, it corrects the codec names in DA8xx/OMAP-L1xx > > > board files. > > > > > > Tested on DM6446, DM355, DM6447, DA850 EVMs. > > > > > Does this mean the patch was not tested on DA830 EVM? Should we expect > the audio to work for DA830 on the tmp/asoc or master? > > Thanks > > Steve > > I could not test it yesterday since the board was not readily available with me. Checked it now on a DA830/OMAP-L137 EVM. Audio works on the temp/asoc branch. Regards, Chaithrika ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: davinci vs. v4l2: lots of conflicts in merge for linux-next
"Karicheri, Muralidharan" writes: > Kevin, > > Ok, I see you have merged vpif capture architecture part to master branch > of davinci. > > So what you are suggesting is to remove all vpif/vpfe patches from > arch/arm/davinci of v4l linux-next tree (So I guess this is what > Mauro should do on linux-next). So architecture part of all future > video patches are to be re-created and re-submitted based on > davinci-next and will be merged only to davinci tree and Mauro will > merge the v4l part. Yes. Also note the two patches below that I dropped in davinci-next. These should be re-added as well. Kevin > Kevin & Mauro, > > So only concern I have is that these patches may not compile (either > architecture part or v4l part) until the counter part becomes available on > the tree. Is this fine? > > Murali Karicheri > Software Design Engineer > Texas Instruments Inc. > Germantown, MD 20874 > new phone: 301-407-9583 > Old Phone : 301-515-3736 (will be deprecated) > email: m-kariche...@ti.com > >>-Original Message- >>From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >>Sent: Wednesday, August 26, 2009 5:00 AM >>To: Karicheri, Muralidharan; Mauro Carvalho Chehab >>Cc: linux-me...@vger.kernel.org; Hans Verkuil; DaVinci >>Subject: davinci vs. v4l2: lots of conflicts in merge for linux-next >> >>OK, this has gotten a bit out of control, to the point where I cannot >>solve this myself. This is partially due to me being on the road and >>not keeping a close enough eye on the various video patches. >> >>I've pushed a new 'davinci-next' branch to davinci git[1] which is >>what I would like to make available for linux-next. This includes all >>the patches from davinci git master which touch >>arch/arm/mach-davinci/*. >> >>I then went to do a test a merge of the master branch of Mauro's >>linux-next tree, and there are lots of conflicts. Some are trivial to >>resolve (the various I2C_BOARD_INFO() conflicts) but others are more >>difficult, and someone more familar with the video drivers should sort >>them out. >> >>The two patches from davinci master that seem to be causing all the >>problems are: >> >> ARM: DaVinci: DM646x Video: Platform and board specific setup >> davinci: video: restructuring to support vpif capture driver >> >>These cause the conflicts with the v4l2 next tree. So, in >>davinci-next I've dropped these two patches. >> >>I think the way to fix this is for someone to take all the board >>changes from the v4l2 tree and rebase them on top of my davinci-next, >>dropping them from v4l2 next. I'll then merge them into davinci-next, >>and this should make the two trees merge properly in linux-next. >> >>We need to get this sorted out soon so that they can be merged for the >>next merge window. >> >>Going forward, I would prefer that all changes to arch/arm/* stuff go >>through davinci git and all drivers/* stuff goes through V4L2. This >>will avoid this kind of overlap/conflict in the future since DaVinci >>core code is going through lots of changes. >> >>Kevin >> >>[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: audio issue on 2.6.31 kernel
What application are you using? Thanks, Arun From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Jeff Sent: Thursday, August 27, 2009 9:30 PM To: Davinci-Linux-Source Subject: audio issue on 2.6.31 kernel All, When I played sound clip using ALSA interface + kernel 2.6.31 on DM355 EVM, I can not hear anything. I can hear sound when I played it using ASLA OSS emulation interface. But the sound volume is very low and with some noise. Could anyone help me? Thanks a lot! BR Jeff ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/6] Support for TVP7002 in v4l2 definitions
Sandeep,
Thanks for the review. I will send the patches to the linux-media list.
Regards.
Paulraj, Sandeep wrote:
I think you should have sent these patches to linux-me...@vger.kernel.org
as well.
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf
Of santiago.nu...@ridgerun.com
Sent: Thursday, August 27, 2009 8:17 PM
To: Karicheri, Muralidharan
Cc: davinci-linux-open-source@linux.davincidsp.com;
clark.bec...@ridgerun.com; Santiago Nunez-Corrales;
todd.fisc...@ridgerun.com
Subject: [PATCH 1/6] Support for TVP7002 in v4l2 definitions
From: Santiago Nunez-Corrales
This patch provides required std and control definitions in TVP7002
within v4l2.
Signed-off-by: Santiago Nunez-Corrales
---
include/linux/videodev2.h | 87
+-
include/media/v4l2-chip-ident.h |3 +
2 files changed, 87 insertions(+), 3 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 74f1687..5a735be 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -704,11 +704,66 @@ typedef __u64 v4l2_std_id;
V4L2_STD_PAL_Nc|\
V4L2_STD_SECAM)
#define V4L2_STD_ATSC (V4L2_STD_ATSC_8_VSB|\
-V4L2_STD_ATSC_16_VSB)
+
V4L2_STD_ATSC_16_VSB)
+/* Frequency for HD (i.e. 60 vs 50) */
+#define V4L2_STD_HDTV_50 ((v4l2_std_id)0x0400)
+#define V4L2_STD_HDTV_60 ((v4l2_std_id)0x)
+
+/* interlaced vs progressive for HD */
+#define V4L2_STD_HDTV_I((v4l2_std_id)0x0800)
+#define V4L2_STD_HDTV_P((v4l2_std_id)0x)
+
+/* 720 vs 1080 HD modes */
+#define V4L2_STD_HDTV_720 ((v4l2_std_id)0x0800)
+#define V4L2_STD_HDTV_1080 ((v4l2_std_id)0x1000)
+
+/* FIXME:
+ *
+ * Definitions equal to zero are listed for clarity. In general,
+ * definitions of standards should be improved by using bits to
+ * denote properties, not specific standards and forcing the use
+ * of unnatural combinatorics tricks. Otherwise, as such is the
+ * current case, the descriptor bit space gets exhausted very
+ * rapidly.
+ */
+
+/* some standards for SDTV and HDTV */
+#define V4L2_STD_480P_60 (V4L2_STD_525_60|\
+V4L2_STD_HDTV_P)
+#define V4L2_STD_480I_60 (V4L2_STD_525_60|\
+V4L2_STD_HDTV_I)
+#define V4L2_STD_576P_50 (V4L2_STD_625_50|\
+V4L2_STD_HDTV_P)
+#define V4L2_STD_576I_50 (V4L2_STD_625_50|\
+V4L2_STD_HDTV_I)
+#define V4L2_STD_720P_50 (V4L2_STD_ATSC |\
+V4L2_STD_HDTV_50 |\
+V4L2_STD_HDTV_P|\
+V4L2_STD_HDTV_720)
+#define V4L2_STD_720P_60 (V4L2_STD_ATSC |\
+V4L2_STD_HDTV_60 |\
+V4L2_STD_HDTV_P|\
+V4L2_STD_HDTV_720)
+#define V4L2_STD_1080I_50 (V4L2_STD_ATSC |\
+V4L2_STD_HDTV_50 |\
+V4L2_STD_HDTV_I|\
+V4L2_STD_HDTV_1080)
+#define V4L2_STD_1080I_60 (V4L2_STD_ATSC |\
+V4L2_STD_HDTV_60 |\
+V4L2_STD_HDTV_I|\
+V4L2_STD_HDTV_1080)
+#define V4L2_STD_1080P_50 (V4L2_STD_ATSC |\
+V4L2_STD_HDTV_50 |\
+V4L2_STD_HDTV_P|\
+V4L2_STD_HDTV_1080)
+#define V4L2_STD_1080P_60 (V4L2_STD_ATSC |\
+V4L2_STD_HDTV_60 |\
+V4L2_STD_HDTV_P|\
+V4L2_STD_HDTV_1080)
+
+
#define V4L2_STD_UNKNOWN0
-#define V4L2_STD_ALL(V4L2_STD_525_60 |\
-V4L2_STD_625_50)
struct v4l2_standard {
__u32index;
@@ -808,6 +863,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_USER 0x0098/* Old-style 'user' controls */
#define V4L2_CTRL_CLASS_MPEG 0x0099/* MPEG-compression controls */
#define V4L2_CTRL_CLASS_CAMERA 0x009a /* Camera class controls
*/
+#define V4L2_CTRL_CLASS_DECODER 0x009c /* Decoder class controls
*/
#define V4L2_CTRL_ID_MASK(0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) & 0x0fffUL)
@@ -1147,6 +1203,31 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_PRIVACY (V4L2_CI
Re: [PATCH 1/6] Support for TVP7002 in v4l2 definitions
Hans, Thanks for your review. In fact, one of my main concerns after looking at current viable implementations for HD was the structure implied by v4l2_std_id -and its organization- was on how to improve the way controls and standards are defined. I am eager to see the new proposal after the Linux Plumbers Conference and keep in the loop, in particular in the new kernel abstraction mechanisms for low-level access controls. Now on the patch, ideally this patch is intended for being merged in the davinci branch, but I am aware that . Sandeep suggested me to send those patches to the linux-media list too. Regards, Hans Verkuil wrote: On Friday 28 August 2009 02:16:47 santiago.nu...@ridgerun.com wrote: From: Santiago Nunez-Corrales This patch provides required std and control definitions in TVP7002 within v4l2. Is this supposed to be merged into the mainline kernel? Or is this for a non-mainline tree only? If you want to get it merged in the mainline, then you should be aware that there will be a new API for HD resolutions. I hope to have a good proposal available for discussion during the Linux Plumbers Conference in September. We are definitely not going to extend v4l2_std_id. That will be frozen for use with PAL/SECAM/NTSC formats only. Note that I also have serious doubts about the usefulness of the decoder controls. Is anyone actually interested in setting those? It will be another topic for discussion during that conference: how to give applications access to these low-level controls and whether we even want that. Regards, Hans Signed-off-by: Santiago Nunez-Corrales --- include/linux/videodev2.h | 87 +- include/media/v4l2-chip-ident.h |3 + 2 files changed, 87 insertions(+), 3 deletions(-) diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h index 74f1687..5a735be 100644 --- a/include/linux/videodev2.h +++ b/include/linux/videodev2.h @@ -704,11 +704,66 @@ typedef __u64 v4l2_std_id; V4L2_STD_PAL_Nc|\ V4L2_STD_SECAM) #define V4L2_STD_ATSC (V4L2_STD_ATSC_8_VSB|\ -V4L2_STD_ATSC_16_VSB) + V4L2_STD_ATSC_16_VSB) +/* Frequency for HD (i.e. 60 vs 50) */ +#define V4L2_STD_HDTV_50 ((v4l2_std_id)0x0400) +#define V4L2_STD_HDTV_60 ((v4l2_std_id)0x) + +/* interlaced vs progressive for HD */ +#define V4L2_STD_HDTV_I((v4l2_std_id)0x0800) +#define V4L2_STD_HDTV_P((v4l2_std_id)0x) + +/* 720 vs 1080 HD modes */ +#define V4L2_STD_HDTV_720 ((v4l2_std_id)0x0800) +#define V4L2_STD_HDTV_1080 ((v4l2_std_id)0x1000) + +/* FIXME: + * + * Definitions equal to zero are listed for clarity. In general, + * definitions of standards should be improved by using bits to + * denote properties, not specific standards and forcing the use + * of unnatural combinatorics tricks. Otherwise, as such is the + * current case, the descriptor bit space gets exhausted very + * rapidly. + */ + +/* some standards for SDTV and HDTV */ +#define V4L2_STD_480P_60 (V4L2_STD_525_60|\ +V4L2_STD_HDTV_P) +#define V4L2_STD_480I_60 (V4L2_STD_525_60|\ +V4L2_STD_HDTV_I) +#define V4L2_STD_576P_50 (V4L2_STD_625_50|\ +V4L2_STD_HDTV_P) +#define V4L2_STD_576I_50 (V4L2_STD_625_50|\ +V4L2_STD_HDTV_I) +#define V4L2_STD_720P_50 (V4L2_STD_ATSC |\ +V4L2_STD_HDTV_50 |\ +V4L2_STD_HDTV_P|\ +V4L2_STD_HDTV_720) +#define V4L2_STD_720P_60 (V4L2_STD_ATSC |\ +V4L2_STD_HDTV_60 |\ +V4L2_STD_HDTV_P|\ +V4L2_STD_HDTV_720) +#define V4L2_STD_1080I_50 (V4L2_STD_ATSC |\ +V4L2_STD_HDTV_50 |\ +V4L2_STD_HDTV_I|\ +V4L2_STD_HDTV_1080) +#define V4L2_STD_1080I_60 (V4L2_STD_ATSC |\ +V4L2_STD_HDTV_60 |\ +V4L2_STD_HDTV_I|\ +V4L2_STD_HDTV_1080) +#define V4L2_STD_1080P_50 (V4L2_STD_ATSC |\ +V4L2_STD_HDTV_50 |\ +V4L2_STD_HDTV_P|\ +V4L2_STD_HDTV_1080) +#define V4L2_STD_1080P_60 (V4L2_STD_ATSC |\ +V4L2_STD_HDTV_60 |\ +V4L2_STD_HDTV_P|\ +
Re: [PATCH 3/6] Support for TVP7002 in VPFE
Hiremath, Vaibhav wrote:
[Hiremath, Vaibhav] may be I am missing something, the above changes is already
there except changes in standard table (vpfe_standard). I am referring to the
Murali's Arago repo.
Thanks,
Vaibhav
Yes, my mistake. Those changes were already there, just did a git pull.
Changing accordingly.
ret = request_irq(vpfe_dev->ccdc_irq0, vpfe_isr,
IRQF_DISABLED,
"vpfe_capture0", vpfe_dev);
if (0 != ret) {
v4l2_err(pdev->dev.driver, "Unable to request
interrupt\n");
- goto probe_disable_clock;
+ goto probe_out_unmap1;
}
/* Allocate memory for video device */
@@ -2331,6 +2368,10 @@ probe_out_video_release:
video_device_release(vpfe_dev->video_dev);
probe_out_release_irq:
free_irq(vpfe_dev->ccdc_irq0, vpfe_dev);
+probe_out_unmap1:
+ iounmap(ccdc_cfg->ccdc_addr);
+probe_out_release_mem1:
+ release_mem_region(res1->start, res1->end - res1->start + 1);
probe_disable_clock:
vpfe_disable_clock(vpfe_dev);
mutex_unlock(&ccdc_lock);
@@ -2346,6 +2387,7 @@ probe_free_dev_mem:
static int vpfe_remove(struct platform_device *pdev)
{
struct vpfe_device *vpfe_dev = platform_get_drvdata(pdev);
+ struct resource *res;
v4l2_info(pdev->dev.driver, "vpfe_remove\n");
@@ -2353,6 +2395,11 @@ static int vpfe_remove(struct platform_device
*pdev)
kfree(vpfe_dev->sd);
v4l2_device_unregister(&vpfe_dev->v4l2_dev);
video_unregister_device(vpfe_dev->video_dev);
+ mutex_lock(&ccdc_lock);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ release_mem_region(res->start, res->end - res->start + 1);
+ iounmap(ccdc_cfg->ccdc_addr);
+ mutex_unlock(&ccdc_lock);
vpfe_disable_clock(vpfe_dev);
kfree(vpfe_dev);
kfree(ccdc_cfg);
--
1.6.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-
source
--
Santiago Nunez-Corrales, Eng.
RidgeRun Engineering, LLC
Guayabos, Curridabat
San Jose, Costa Rica
+(506) 2271 1487
+(506) 8313 0536
http://www.ridgerun.com
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] davinci: dm646x-evm: Add platform data for NAND
This patch adds platform data and partition info for NAND on dm6467 EVM.
Note that the partition layout is dependent on the UBL, U-Boot combination used.
This patch uses partition organization suitable with latest U-Boot of LSP 1.3.
For example, U-Boot environment goes in block 0, UBL resides in block form 1 to
5 and so on.
Signed-off-by: Hemant Pedanekar
---
Depends on patch "[MTD] [NAND] davinci: fix to use mask_ale from
pdata" submitted earlier. Without this patch "No NAND device found" error will
be shown on dm6467-evm when booting with NAND enabled in config and NAND won't
be accessible.
arch/arm/mach-davinci/board-dm646x-evm.c | 83 ++
1 files changed, 83 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 434253e..f349e4d 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -34,6 +34,10 @@
#include
#include
#include
+#include
+#include
+#include
+
#include
#include
#include
@@ -45,6 +49,7 @@
#include
#include
#include
+#include
#include
#include
@@ -55,6 +60,18 @@
#define HAS_ATA 0
#endif
+#if defined(CONFIG_MTD_NAND_DAVINCI) || \
+defined(CONFIG_MTD_NAND_DAVINCI_MODULE)
+#define HAS_NAND 1
+#else
+#define HAS_NAND 0
+#endif
+
+#define DAVINCI_ASYNC_EMIF_CONTROL_BASE0x20008000
+#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x4200
+
+#define NAND_BLOCK_SIZESZ_128K
+
/* CPLD Register 0 bits to control ATA */
#define DM646X_EVM_ATA_RST BIT(0)
#define DM646X_EVM_ATA_PWD BIT(1)
@@ -91,6 +108,69 @@ static struct davinci_uart_config uart_config __initdata = {
.enabled_uarts = (1 << 0),
};
+/* Note: The partitioning is driven by combination of UBL and U-Boot. For
+ * example, in the layout below, U-Boot puts environment in block 0
+ * and UBL can be in blocks 1-5 while U-Boot resides after UBL blocks.
+ */
+static struct mtd_partition davinci_nand_partitions[] = {
+ {
+ /* U-Boot environment */
+ .name = "params",
+ .offset = 0,
+ .size = 1 * NAND_BLOCK_SIZE,
+ .mask_flags = 0,
+ }, {
+ /* UBL, U-Boot */
+ .name = "bootloader",
+ .offset = MTDPART_OFS_APPEND,
+ .size = 10 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ }, {
+ .name = "kernel",
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_4M,
+ .mask_flags = 0,
+ }, {
+ .name = "filesystem",
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ .mask_flags = 0,
+ }
+};
+
+static struct davinci_nand_pdata davinci_nand_data = {
+ .mask_cle = 0x8,
+ .mask_ale = 0x4,
+ .parts = davinci_nand_partitions,
+ .nr_parts = ARRAY_SIZE(davinci_nand_partitions),
+ .ecc_mode = NAND_ECC_HW,
+ .options= 0,
+};
+
+static struct resource davinci_nand_resources[] = {
+ {
+ .start = DAVINCI_ASYNC_EMIF_DATA_CE0_BASE,
+ .end= DAVINCI_ASYNC_EMIF_DATA_CE0_BASE + SZ_32M - 1,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = DAVINCI_ASYNC_EMIF_CONTROL_BASE,
+ .end= DAVINCI_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device davinci_nand_device = {
+ .name = "davinci_nand",
+ .id = 0,
+
+ .num_resources = ARRAY_SIZE(davinci_nand_resources),
+ .resource = davinci_nand_resources,
+
+ .dev= {
+ .platform_data = &davinci_nand_data,
+ },
+};
+
/* CPLD Register 0 Client: used for I/O Control */
static int cpld_reg0_probe(struct i2c_client *client,
const struct i2c_device_id *id)
@@ -645,6 +725,9 @@ static __init void evm_init(void)
dm646x_init_mcasp0(&dm646x_evm_snd_data[0]);
dm646x_init_mcasp1(&dm646x_evm_snd_data[1]);
+ if (HAS_NAND)
+ platform_device_register(&davinci_nand_device);
+
if (HAS_ATA)
dm646x_init_ide();
--
1.6.2.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH RFC] MUSB: DA8xx/OMAP-L1x glue layer (take 4)
Texas Instruments DA8xx/OMAP-L1x glue layer for the MUSBMHRDC driver. Signed-off-by: Sergei Shtylyov Signed-off-by: Yadviga Grigorieva --- This patch is against the recent DaVinci tree. WARNING: the MUSB and OHCI drivers will only work if your boot loader leaves the DA8xx boot configuration registers unlocked, otherwise they will lock up the kernel! Changes since the previous take: - added the now necessary calls to usb_nop_xceiv_register() and otg_get_transceiver(); - removed unneeded clk_get() call; - stopped checking clk_enable() result -- it shouldn't fail... arch/arm/mach-davinci/include/mach/da8xx.h |1 arch/arm/mach-davinci/include/mach/usb.h | 37 ++ drivers/usb/musb/Kconfig |5 drivers/usb/musb/Makefile |6 drivers/usb/musb/da8xx.c | 522 + drivers/usb/musb/musb_core.h |1 6 files changed, 570 insertions(+), 2 deletions(-) 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 @@ -30,6 +30,7 @@ #define DA8XX_CP_INTC_VIRT (IO_VIRT - DA8XX_CP_INTC_SIZE - SZ_4K) #define DA8XX_BOOT_CFG_BASE(IO_PHYS + 0x14000) +#define DA8XX_CFGCHIP2_REG (DA8XX_BOOT_CFG_BASE + 0x184) #define DA8XX_PSC0_BASE0x01c1 #define DA8XX_PLL0_BASE0x01c11000 Index: linux-davinci/arch/arm/mach-davinci/include/mach/usb.h === --- /dev/null +++ linux-davinci/arch/arm/mach-davinci/include/mach/usb.h @@ -0,0 +1,37 @@ +/* + * USB related definitions + * + * Copyright (C) 2009 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. + */ + +#ifndef __ASM_ARCH_USB_H +#define __ASM_ARCH_USB_H + +/* DA8xx CFGCHIP2 (USB 2.0 PHY Control) register bits */ +#define CFGCHIP2_PHYCLKGD (1 << 17) +#define CFGCHIP2_VBUSSENSE (1 << 16) +#define CFGCHIP2_RESET (1 << 15) +#define CFGCHIP2_OTGMODE (3 << 13) +#define CFGCHIP2_NO_OVERRIDE (0 << 13) +#define CFGCHIP2_FORCE_HOST(1 << 13) +#define CFGCHIP2_FORCE_DEVICE (2 << 13) +#define CFGCHIP2_FORCE_HOST_VBUS_LOW (3 << 13) +#define CFGCHIP2_USB1PHYCLKMUX (1 << 12) +#define CFGCHIP2_USB2PHYCLKMUX (1 << 11) +#define CFGCHIP2_PHYPWRDN (1 << 10) +#define CFGCHIP2_OTGPWRDN (1 << 9) +#define CFGCHIP2_DATPOL(1 << 8) +#define CFGCHIP2_USB1SUSPENDM (1 << 7) +#define CFGCHIP2_PHY_PLLON (1 << 6)/* override PLL suspend */ +#define CFGCHIP2_SESENDEN (1 << 5)/* Vsess_end comparator */ +#define CFGCHIP2_VBDTCTEN (1 << 4)/* Vbus comparator */ +#define CFGCHIP2_REFFREQ (0xf << 0) +#define CFGCHIP2_REFFREQ_12MHZ (1 << 0) +#define CFGCHIP2_REFFREQ_24MHZ (2 << 0) +#define CFGCHIP2_REFFREQ_48MHZ (3 << 0) + +#endif /* ifndef __ASM_ARCH_USB_H */ Index: linux-davinci/drivers/usb/musb/Kconfig === --- linux-davinci.orig/drivers/usb/musb/Kconfig +++ linux-davinci/drivers/usb/musb/Kconfig @@ -42,7 +42,10 @@ config USB_MUSB_SOC default y if (BF52x && !BF522 && !BF523) comment "DaVinci 35x and 644x USB support" - depends on USB_MUSB_HDRC && ARCH_DAVINCI + depends on USB_MUSB_HDRC && ARCH_DAVINCI_DMx + +comment "DA8xx/OMAP-L1x USB support" + depends on USB_MUSB_HDRC && ARCH_DAVINCI_DA8XX comment "OMAP 243x high speed USB support" depends on USB_MUSB_HDRC && ARCH_OMAP2430 Index: linux-davinci/drivers/usb/musb/Makefile === --- linux-davinci.orig/drivers/usb/musb/Makefile +++ linux-davinci/drivers/usb/musb/Makefile @@ -6,10 +6,14 @@ musb_hdrc-objs := musb_core.o obj-$(CONFIG_USB_MUSB_HDRC)+= musb_hdrc.o -ifeq ($(CONFIG_ARCH_DAVINCI),y) +ifeq ($(CONFIG_ARCH_DAVINCI_DMx),y) musb_hdrc-objs += davinci.o endif +ifeq ($(CONFIG_ARCH_DAVINCI_DA8XX),y) + musb_hdrc-objs += da8xx.o +endif + ifeq ($(CONFIG_USB_TUSB6010),y) musb_hdrc-objs += tusb6010.o endif Index: linux-davinci/drivers/usb/musb/da8xx.c === --- /dev/null +++ linux-davinci/drivers/usb/musb/da8xx.c @@ -0,0 +1,522 @@ +/* + * Texas Instruments DA8XX/OMAP-L137 "glue layer" + * + * Copyright (c) 2008-2009 MontaVista Software, Inc. + * + * Based on the DaVinci "glue layer" code. + * Copyright (C) 2005-2006 by Texas Instruments + * + * This file is part of the Inventra Controller Driver for Linux. + * + * The Inventra Controller Driver for Linux is free software; you + * can redistribute it and/or modify it under the terms of th
[PATCH 1/3] DaVinci: move MUSB platform device to devices.c
There's absolutely no reason why the DaVinci USB platfrom device should
be in its own module; moreover, it will stand in the way of DA8xx's USB
platfrom device which occupies different region and IRQ -- so, move it
into devices.c and get rid of usb.c...
While at it, add 'davinci_' prefix to setup_usb(), remove its duplicate
declaration in common.h, and rename 'usb_dev' to 'davinci_usb_device' to
match the naming pattern established for devices.c...
Signed-off-by: Sergei Shtylyov
---
The patch is against the recent DaVinci tree...
arch/arm/mach-davinci/usb.c | 110
arch/arm/mach-davinci/Makefile |2
arch/arm/mach-davinci/board-dm355-evm.c |2
arch/arm/mach-davinci/board-dm355-leopard.c |2
arch/arm/mach-davinci/board-dm644x-evm.c|2
arch/arm/mach-davinci/board-sffsdr.c|2
arch/arm/mach-davinci/devices.c | 94 +++
arch/arm/mach-davinci/include/mach/common.h |5 -
8 files changed, 100 insertions(+), 119 deletions(-)
Index: linux-davinci/arch/arm/mach-davinci/Makefile
===
--- linux-davinci.orig/arch/arm/mach-davinci/Makefile
+++ linux-davinci/arch/arm/mach-davinci/Makefile
@@ -5,7 +5,7 @@
# Common objects
obj-y := time.o clock.o serial.o io.o psc.o \
- gpio.o dma.o usb.o common.o sram.o
+ gpio.o dma.o common.o sram.o
obj-$(CONFIG_DAVINCI_MUX) += mux.o
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
@@ -275,7 +275,7 @@ static __init void dm355_evm_init(void)
gpio_request(2, "usb_id_toggle");
gpio_direction_output(2, USB_ID_VALUE);
/* irlml6401 switches over 1A in under 8 msec */
- setup_usb(500, 8);
+ davinci_setup_usb(500, 8);
davinci_setup_mmc(0, &dm355evm_mmc_config);
davinci_setup_mmc(1, &dm355evm_mmc_config);
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
@@ -271,7 +271,7 @@ static __init void dm355_leopard_init(vo
gpio_request(2, "usb_id_toggle");
gpio_direction_output(2, USB_ID_VALUE);
/* irlml6401 switches over 1A in under 8 msec */
- setup_usb(500, 8);
+ davinci_setup_usb(500, 8);
davinci_setup_mmc(0, &dm355leopard_mmc_config);
davinci_setup_mmc(1, &dm355leopard_mmc_config);
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
@@ -409,7 +409,7 @@ evm_u35_setup(struct i2c_client *client,
/* irlml6401 switches over 1A, in under 8 msec;
* now it can be managed by nDRV_VBUS ...
*/
- setup_usb(500, 8);
+ davinci_setup_usb(500, 8);
return 0;
}
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
@@ -165,7 +165,7 @@ static __init void davinci_sffsdr_init(v
davinci_serial_init(&uart_config);
soc_info->emac_pdata->phy_mask = SFFSDR_PHY_MASK;
soc_info->emac_pdata->mdio_max_freq = SFFSDR_MDIO_FREQUENCY;
- setup_usb(0, 0); /* We support only peripheral mode. */
+ davinci_setup_usb(0, 0); /* We support only peripheral mode. */
/* mux VLYNQ pins */
davinci_cfg_reg(DM644X_VLYNQEN);
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
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
@@ -28,6 +29,7 @@
#include
#define DAVINCI_I2C_BASE0x01C21000
+#define DAVINCI_USB_OTG_BASE0x01C64000
#define DAVINCI_MMCSD0_BASE 0x01E1
#define DM355_MMCSD0_BASE 0x01E11000
#define DM355_MMCSD1_BASE 0x01E0
@@ -62,6 +64,98 @@ void __init davinci_init_i2c(struct davi
(void) platform_device_register(&davinci_i2c_device);
}
+#if defined(CONFIG_USB_MUSB_HDRC) || defined(CONFIG_USB_MUSB_HDRC_MODULE)
+
+static struct musb_hdrc_eps_bits musb_eps[] = {
+ { "ep1_tx", 8, },
+ { "ep1_rx", 8, },
+ { "ep2_tx", 8, },
+ { "ep2_rx", 8, },
+ { "ep3_tx", 5, },
+
[PATCH 2/3] DA8xx: MUSB platform device
Add the function to register the MUSB platform device.
Signed-off-by: Sergei Shtylyov
---
The patch is against the recent DaVinci tree plus the OHCI platform patches
that I posted a week ago...
arch/arm/mach-davinci/devices-da8xx.c | 74 +
arch/arm/mach-davinci/include/mach/da8xx.h |1
2 files changed, 75 insertions(+)
Index: linux-davinci/arch/arm/mach-davinci/devices-da8xx.c
===
--- linux-davinci.orig/arch/arm/mach-davinci/devices-da8xx.c
+++ linux-davinci/arch/arm/mach-davinci/devices-da8xx.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -30,6 +31,7 @@
#define DA8XX_TPTC1_BASE 0x01c08400
#define DA8XX_WDOG_BASE0x01c21000 /*
DA8XX_TIMER64P1_BASE */
#define DA8XX_I2C0_BASE0x01c22000
+#define DA8XX_USB0_BASE0x01e0
#define DA8XX_EMAC_CPPI_PORT_BASE 0x01e2
#define DA8XX_EMAC_CPGMACSS_BASE 0x01e22000
#define DA8XX_EMAC_CPGMAC_BASE 0x01e23000
@@ -236,6 +238,78 @@ int __init da8xx_register_watchdog(void)
return platform_device_register(&davinci_wdt_device);
}
+static struct musb_hdrc_eps_bits musb_eps[] = {
+ { "ep1_tx", 8, },
+ { "ep1_rx", 8, },
+ { "ep2_tx", 8, },
+ { "ep2_rx", 8, },
+ { "ep3_tx", 5, },
+ { "ep3_rx", 5, },
+ { "ep4_tx", 5, },
+ { "ep4_rx", 5, },
+};
+
+static struct musb_hdrc_config musb_config = {
+ .multipoint = true,
+ .dyn_fifo = true,
+ .soft_con = true,
+ .dma= true,
+
+ .num_eps= 5,
+ .dma_channels = 8,
+ .ram_bits = 10,
+ .eps_bits = musb_eps,
+};
+
+static struct musb_hdrc_platform_data da8xx_usb20_data = {
+#if defined(CONFIG_USB_MUSB_OTG)
+ /* OTG requires a Mini-AB connector */
+ .mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_PERIPHERAL)
+ .mode = MUSB_PERIPHERAL,
+#elif defined(CONFIG_USB_MUSB_HOST)
+ .mode = MUSB_HOST,
+#endif
+ .clock = "usb20",
+ .config = &musb_config,
+};
+
+static struct resource da8xx_usb20_resources[] = {
+ {
+ /* physical address */
+ .start = DA8XX_USB0_BASE,
+ .end= DA8XX_USB0_BASE + SZ_64K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = IRQ_DA8XX_USB_INT,
+ .end= IRQ_DA8XX_USB_INT,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 da8xx_usb20_dmamask = DMA_BIT_MASK(32);
+
+static struct platform_device da8xx_usb20_device = {
+ .name = "musb_hdrc",
+ .id = -1,
+ .dev = {
+ .platform_data = &da8xx_usb20_data,
+ .dma_mask = &da8xx_usb20_dmamask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+ .resource = da8xx_usb20_resources,
+ .num_resources = ARRAY_SIZE(da8xx_usb20_resources),
+};
+
+int __init da8xx_register_usb20(unsigned mA, unsigned potpgt)
+{
+ da8xx_usb20_data.power = mA > 510 ? 255 : mA / 2;
+ da8xx_usb20_data.potpgt = (potpgt + 1) / 2;
+
+ return platform_device_register(&da8xx_usb20_device);
+}
+
static struct resource da8xx_usb11_resources[] = {
[0] = {
.start = DA8XX_USB1_BASE,
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
@@ -73,6 +73,7 @@ void __init da850_init(void);
int da8xx_register_edma(void);
int da8xx_register_i2c(int instance, struct davinci_i2c_platform_data *pdata);
int da8xx_register_watchdog(void);
+int da8xx_register_usb20(unsigned mA, unsigned potpgt);
int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
int da8xx_register_emac(void);
int da8xx_register_lcdc(void);
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 3/3] DA830 EVM: MUSB platform code
Properly set up the OTG mode thru the CFGCHIP2 register, enable the
USB0_DRVVBUS pin, and finally register the MUSB platform device.
Signed-off-by: Sergei Shtylyov
---
The patch is against the recent DaVinci tree plus the OHCI platform patches
that I posted a week ago...
arch/arm/mach-davinci/board-da830-evm.c | 29 +
1 files changed, 29 insertions(+)
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
@@ -142,8 +142,37 @@ static __init void da830_evm_usb_init(vo
cfgchip2 &= ~CFGCHIP2_USB1PHYCLKMUX;
cfgchip2 |= CFGCHIP2_USB2PHYCLKMUX;
+ /*
+* We have to override VBUS/ID signals when MUSB is configured into the
+* host-only mode -- ID pin will float if no cable is connected, so the
+* controller won't be able to drive VBUS thinking that it's a B-device.
+* Otherwise, we want to use the OTG mode and enable VBUS comparators.
+*/
+ cfgchip2 &= ~CFGCHIP2_OTGMODE;
+#ifdef CONFIG_USB_MUSB_HOST
+ cfgchip2 |= CFGCHIP2_FORCE_HOST;
+#else
+ cfgchip2 |= CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN;
+#endif
+
__raw_writel(cfgchip2, IO_ADDRESS(DA8XX_CFGCHIP2_REG));
+ /* USB_REFCLKIN is not used. */
+ ret = davinci_cfg_reg(DA830_USB0_DRVVBUS);
+ if (ret)
+ pr_warning("%s: USB 2.0 PinMux setup failed: %d\n",
+ __func__, ret);
+ else {
+ /*
+* TPS2065 switch @ 5V supplies 1 A (sustains 1.5 A),
+* with the power on to power good time of 3 ms.
+*/
+ ret = da8xx_register_usb20(1000, 3);
+ if (ret)
+ pr_warning("%s: USB 2.0 registration failed: %d\n",
+ __func__, ret);
+ }
+
ret = da8xx_pinmux_setup(da830_evm_usb11_pins);
if (ret) {
pr_warning("%s: USB 1.1 PinMux setup failed: %d\n",
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH RFC] MUSB: DA8xx/OMAP-L1x glue layer (take 5)
Texas Instruments DA8xx/OMAP-L1x glue layer for the MUSBMHRDC driver. Signed-off-by: Sergei Shtylyov Signed-off-by: Yadviga Grigorieva --- And immediately follows take 5... argh! This patch is against the recent DaVinci tree. WARNING: the MUSB and OHCI drivers will only work if your boot loader leaves the DA8xx boot configuration registers unlocked, otherwise they will lock up the kernel! Changes since the previous take: - added the necessary calls to usb_nop_xceiv_unregister(); - added clk_disable() call to musb_platform_exit()... arch/arm/mach-davinci/include/mach/da8xx.h |1 arch/arm/mach-davinci/include/mach/usb.h | 37 ++ drivers/usb/musb/Kconfig |5 drivers/usb/musb/Makefile |6 drivers/usb/musb/da8xx.c | 529 + drivers/usb/musb/musb_core.h |1 6 files changed, 577 insertions(+), 2 deletions(-) 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 @@ -30,6 +30,7 @@ #define DA8XX_CP_INTC_VIRT (IO_VIRT - DA8XX_CP_INTC_SIZE - SZ_4K) #define DA8XX_BOOT_CFG_BASE(IO_PHYS + 0x14000) +#define DA8XX_CFGCHIP2_REG (DA8XX_BOOT_CFG_BASE + 0x184) #define DA8XX_PSC0_BASE0x01c1 #define DA8XX_PLL0_BASE0x01c11000 Index: linux-davinci/arch/arm/mach-davinci/include/mach/usb.h === --- /dev/null +++ linux-davinci/arch/arm/mach-davinci/include/mach/usb.h @@ -0,0 +1,37 @@ +/* + * USB related definitions + * + * Copyright (C) 2009 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. + */ + +#ifndef __ASM_ARCH_USB_H +#define __ASM_ARCH_USB_H + +/* DA8xx CFGCHIP2 (USB 2.0 PHY Control) register bits */ +#define CFGCHIP2_PHYCLKGD (1 << 17) +#define CFGCHIP2_VBUSSENSE (1 << 16) +#define CFGCHIP2_RESET (1 << 15) +#define CFGCHIP2_OTGMODE (3 << 13) +#define CFGCHIP2_NO_OVERRIDE (0 << 13) +#define CFGCHIP2_FORCE_HOST(1 << 13) +#define CFGCHIP2_FORCE_DEVICE (2 << 13) +#define CFGCHIP2_FORCE_HOST_VBUS_LOW (3 << 13) +#define CFGCHIP2_USB1PHYCLKMUX (1 << 12) +#define CFGCHIP2_USB2PHYCLKMUX (1 << 11) +#define CFGCHIP2_PHYPWRDN (1 << 10) +#define CFGCHIP2_OTGPWRDN (1 << 9) +#define CFGCHIP2_DATPOL(1 << 8) +#define CFGCHIP2_USB1SUSPENDM (1 << 7) +#define CFGCHIP2_PHY_PLLON (1 << 6)/* override PLL suspend */ +#define CFGCHIP2_SESENDEN (1 << 5)/* Vsess_end comparator */ +#define CFGCHIP2_VBDTCTEN (1 << 4)/* Vbus comparator */ +#define CFGCHIP2_REFFREQ (0xf << 0) +#define CFGCHIP2_REFFREQ_12MHZ (1 << 0) +#define CFGCHIP2_REFFREQ_24MHZ (2 << 0) +#define CFGCHIP2_REFFREQ_48MHZ (3 << 0) + +#endif /* ifndef __ASM_ARCH_USB_H */ Index: linux-davinci/drivers/usb/musb/Kconfig === --- linux-davinci.orig/drivers/usb/musb/Kconfig +++ linux-davinci/drivers/usb/musb/Kconfig @@ -42,7 +42,10 @@ config USB_MUSB_SOC default y if (BF52x && !BF522 && !BF523) comment "DaVinci 35x and 644x USB support" - depends on USB_MUSB_HDRC && ARCH_DAVINCI + depends on USB_MUSB_HDRC && ARCH_DAVINCI_DMx + +comment "DA8xx/OMAP-L1x USB support" + depends on USB_MUSB_HDRC && ARCH_DAVINCI_DA8XX comment "OMAP 243x high speed USB support" depends on USB_MUSB_HDRC && ARCH_OMAP2430 Index: linux-davinci/drivers/usb/musb/Makefile === --- linux-davinci.orig/drivers/usb/musb/Makefile +++ linux-davinci/drivers/usb/musb/Makefile @@ -6,10 +6,14 @@ musb_hdrc-objs := musb_core.o obj-$(CONFIG_USB_MUSB_HDRC)+= musb_hdrc.o -ifeq ($(CONFIG_ARCH_DAVINCI),y) +ifeq ($(CONFIG_ARCH_DAVINCI_DMx),y) musb_hdrc-objs += davinci.o endif +ifeq ($(CONFIG_ARCH_DAVINCI_DA8XX),y) + musb_hdrc-objs += da8xx.o +endif + ifeq ($(CONFIG_USB_TUSB6010),y) musb_hdrc-objs += tusb6010.o endif Index: linux-davinci/drivers/usb/musb/da8xx.c === --- /dev/null +++ linux-davinci/drivers/usb/musb/da8xx.c @@ -0,0 +1,529 @@ +/* + * Texas Instruments DA8XX/OMAP-L137 "glue layer" + * + * Copyright (c) 2008-2009 MontaVista Software, Inc. + * + * Based on the DaVinci "glue layer" code. + * Copyright (C) 2005-2006 by Texas Instruments + * + * This file is part of the Inventra Controller Driver for Linux. + * + * The Inventra Controller Driver for Linux is free software; you + * can redistribute it and/or modify it under the terms of the GNU + * General Public License v
RE: [PATCH 1/6] Support for TVP7002 in v4l2 definitions
Hans, Murali would be discussing with you about the new API for HD resolutions. Until then we would be using the following patch from Murali that adds a separate header file for HD resolutions - http://arago-project.org/git/projects/?p=linux-davinci.git;a=commitdiff;h=42f40088864730bceaaec0388600145e76d124c7 Since TVP7002 is mainly for HD resolutions, Santiago would be using the above patch to test TVP7002 driver on DM365. I understand, for upstream submission, the TVP7002 driver should be using the new API. Apart from this, the driver should be ready for review. Thanks Sneha > -Original Message- > From: davinci-linux-open-source-boun...@linux.davincidsp.com > [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf > Of Santiago Nunez-Corrales > Sent: Friday, August 28, 2009 12:17 PM > To: Hans Verkuil > Cc: santiago.nu...@ridgerun.com; todd.fisc...@ridgerun.com; davinci-linux- > open-sou...@linux.davincidsp.com; clark.bec...@ridgerun.com > Subject: Re: [PATCH 1/6] Support for TVP7002 in v4l2 definitions > > Hans, > > > Thanks for your review. In fact, one of my main concerns after looking > at current viable > implementations for HD was the structure implied by v4l2_std_id -and its > organization- was > on how to improve the way controls and standards are defined. I am eager > to see the new > proposal after the Linux Plumbers Conference and keep in the loop, in > particular in the > new kernel abstraction mechanisms for low-level access controls. > > Now on the patch, ideally this patch is intended for being merged in the > davinci branch, but > I am aware that . Sandeep suggested me to send those patches to the > linux-media list too. > > Regards, > > Hans Verkuil wrote: > > On Friday 28 August 2009 02:16:47 santiago.nu...@ridgerun.com wrote: > > > >> From: Santiago Nunez-Corrales > >> > >> This patch provides required std and control definitions in TVP7002 > >> within v4l2. > >> > > > > Is this supposed to be merged into the mainline kernel? Or is this for a > > non-mainline tree only? > > > > If you want to get it merged in the mainline, then you should be aware > that > > there will be a new API for HD resolutions. I hope to have a good > proposal > > available for discussion during the Linux Plumbers Conference in > September. > > > > We are definitely not going to extend v4l2_std_id. That will be frozen > for > > use with PAL/SECAM/NTSC formats only. > > > > Note that I also have serious doubts about the usefulness of the decoder > > controls. Is anyone actually interested in setting those? > > > > It will be another topic for discussion during that conference: how to > give > > applications access to these low-level controls and whether we even want > that. > > > > Regards, > > > > Hans > > > > > >> Signed-off-by: Santiago Nunez-Corrales > >> --- > >> include/linux/videodev2.h | 87 > +- > >> include/media/v4l2-chip-ident.h |3 + > >> 2 files changed, 87 insertions(+), 3 deletions(-) > >> > >> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h > >> index 74f1687..5a735be 100644 > >> --- a/include/linux/videodev2.h > >> +++ b/include/linux/videodev2.h > >> @@ -704,11 +704,66 @@ typedef __u64 v4l2_std_id; > >> V4L2_STD_PAL_Nc|\ > >> V4L2_STD_SECAM) > >> #define V4L2_STD_ATSC (V4L2_STD_ATSC_8_VSB|\ > >> - V4L2_STD_ATSC_16_VSB) > >> + > >> V4L2_STD_ATSC_16_VSB) > >> > >> +/* Frequency for HD (i.e. 60 vs 50) */ > >> +#define V4L2_STD_HDTV_50 ((v4l2_std_id)0x0400) > >> +#define V4L2_STD_HDTV_60 ((v4l2_std_id)0x) > >> + > >> +/* interlaced vs progressive for HD */ > >> +#define V4L2_STD_HDTV_I ((v4l2_std_id)0x0800) > >> +#define V4L2_STD_HDTV_P ((v4l2_std_id)0x) > >> + > >> +/* 720 vs 1080 HD modes */ > >> +#define V4L2_STD_HDTV_720 ((v4l2_std_id)0x0800) > >> +#define V4L2_STD_HDTV_1080((v4l2_std_id)0x1000) > >> + > >> +/* FIXME: > >> + * > >> + * Definitions equal to zero are listed for clarity. In general, > >> + * definitions of standards should be improved by using bits to > >> + * denote properties, not specific standards and forcing the use > >> + * of unnatural combinatorics tricks. Otherwise, as such is the > >> + * current case, the descriptor bit space gets exhausted very > >> + * rapidly. > >> + */ > >> + > >> +/* some standards for SDTV and HDTV */ > >> +#define V4L2_STD_480P_60 (V4L2_STD_525_60|\ > >> + V4L2_STD_HDTV_P) > >> +#define V4L2_STD_480I_60 (V4L2_STD_525_60|\ > >> + V4L2_STD_HDTV_I) > >> +#define V4L2_STD_576P_50 (V4L2_STD_625_50|\ > >> + V4L2_STD_HDTV_P) > >> +#define V4L2_STD_576I_50 (V4L2_STD_625_50|\ > >> +
[PATCH 3/4] Davinci: DM365: Add platform device for McBSP
From: Miguel Aguilar
1) Registers the platform device for McBSP on DM365.
2) Add platform data to DM365 EVM board file.
Signed-off-by: Miguel Aguilar
---
arch/arm/mach-davinci/board-dm365-evm.c|4 ++
arch/arm/mach-davinci/dm365.c | 42 +++-
arch/arm/mach-davinci/include/mach/asp.h |3 ++
arch/arm/mach-davinci/include/mach/dm365.h |2 +
4 files changed, 50 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index f6adf79..fd2db78 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -177,6 +177,8 @@ static struct at24_platform_data eeprom_info = {
.context= (void *)0x7f00,
};
+static struct snd_platform_data dm365_evm_snd_data;
+
static struct i2c_board_info i2c_info[] = {
{
I2C_BOARD_INFO("dm365evm_keys", 0x25),
@@ -476,6 +478,8 @@ static __init void dm365_evm_init(void)
/* maybe setup mmc1/etc ... _after_ mmc0 */
evm_init_cpld();
+
+ dm365_init_asp(&dm365_evm_snd_data);
}
static __init void dm365_evm_irq_init(void)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index e815174..cba09b0 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "clock.h"
#include "mux.h"
@@ -456,7 +457,7 @@ static struct davinci_clk dm365_clks[] = {
CLK(NULL, "usb", &usb_clk),
CLK("davinci_emac.1", NULL, &emac_clk),
CLK("voice_codec", NULL, &voicecodec_clk),
- CLK("soc-audio.0", NULL, &asp0_clk),
+ CLK("davinci-asp.0", NULL, &asp0_clk),
CLK(NULL, "rto", &rto_clk),
CLK(NULL, "mjcp", &mjcp_clk),
CLK(NULL, NULL, NULL),
@@ -806,6 +807,31 @@ static struct platform_device dm365_edma_device = {
.resource = edma_resources,
};
+static struct resource dm365_asp_resources[] = {
+ {
+ .start = DAVINCI_DM365_ASP0_BASE,
+ .end= DAVINCI_DM365_ASP0_BASE + SZ_8K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = DAVINCI_DMA_ASP0_TX,
+ .end= DAVINCI_DMA_ASP0_TX,
+ .flags = IORESOURCE_DMA,
+ },
+ {
+ .start = DAVINCI_DMA_ASP0_RX,
+ .end= DAVINCI_DMA_ASP0_RX,
+ .flags = IORESOURCE_DMA,
+ },
+};
+
+static struct platform_device dm365_asp_device = {
+ .name = "davinci-asp",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(dm365_asp_resources),
+ .resource = dm365_asp_resources,
+};
+
static struct map_desc dm365_io_desc[] = {
{
.virtual= IO_VIRT,
@@ -907,6 +933,20 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
.sram_len = SZ_32K,
};
+void __init dm365_init_asp(struct snd_platform_data *pdata)
+{
+ davinci_cfg_reg(DM365_MCBSP0_BDX);
+ davinci_cfg_reg(DM365_MCBSP0_X);
+ davinci_cfg_reg(DM365_MCBSP0_BFSX);
+ davinci_cfg_reg(DM365_MCBSP0_BDR);
+ davinci_cfg_reg(DM365_MCBSP0_R);
+ davinci_cfg_reg(DM365_MCBSP0_BFSR);
+ 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);
+}
+
void __init dm365_init(void)
{
davinci_common_init(&davinci_soc_info_dm365);
diff --git a/arch/arm/mach-davinci/include/mach/asp.h
b/arch/arm/mach-davinci/include/mach/asp.h
index 18e4ce3..fbcbed0 100644
--- a/arch/arm/mach-davinci/include/mach/asp.h
+++ b/arch/arm/mach-davinci/include/mach/asp.h
@@ -15,6 +15,9 @@
#defineDAVINCI_DM646X_MCASP0_REG_BASE 0x01D01000
#define DAVINCI_DM646X_MCASP1_REG_BASE 0x01D01800
+/* Bases of dm365 register banks */
+#define DAVINCI_DM365_ASP0_BASE0x01D02000
+
/* Bases of da850/da830 McASP0 register banks */
#define DAVINCI_DA8XX_MCASP0_REG_BASE 0x01D0
diff --git a/arch/arm/mach-davinci/include/mach/dm365.h
b/arch/arm/mach-davinci/include/mach/dm365.h
index 09db434..2291c0d 100644
--- a/arch/arm/mach-davinci/include/mach/dm365.h
+++ b/arch/arm/mach-davinci/include/mach/dm365.h
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#define DM365_EMAC_BASE(0x01D07000)
#define DM365_EMAC_CNTRL_OFFSET(0x)
@@ -25,5 +26,6 @@
#define DM365_EMAC_CNTRL_RAM_SIZE (0x2000)
void __init dm365_init(void);
+void __init dm365_init_asp(struct snd_platform_data *pdata);
#endif /* __ASM_ARCH_DM365_H */
--
1.6.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 4/4] ASoC: Davinci: Add audio codec support for DM365 EVM
From: Miguel Aguilar
1) Enables tlv320aic3101 support on DM365 EVM.
2) Set tlv320aic3x i2c setup into DM365 EVM board file.
This patch was tested on DM365 EVM rev c.
Signed-off-by: Miguel Aguilar
---
arch/arm/mach-davinci/board-dm365-evm.c |3 +++
sound/soc/davinci/Kconfig |9 +
sound/soc/davinci/Makefile |1 +
sound/soc/davinci/davinci-evm.c | 29 +++--
4 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index fd2db78..cff68e1 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -187,6 +187,9 @@ static struct i2c_board_info i2c_info[] = {
I2C_BOARD_INFO("24c256", 0x50),
.platform_data = &eeprom_info,
},
+ {
+ I2C_BOARD_INFO("tlv320aic3x", 0x18),
+ },
};
static struct davinci_i2c_platform_data i2c_pdata = {
diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig
index 6802dd5..b78b882 100644
--- a/sound/soc/davinci/Kconfig
+++ b/sound/soc/davinci/Kconfig
@@ -32,6 +32,15 @@ config SND_DM6467_SOC_EVM
help
Say Y if you want to add support for SoC audio on TI
+config SND_DM365_SOC_EVM
+ tristate "SoC Audio support for DaVinci DM365 EVM"
+ depends on SND_DAVINCI_SOC && MACH_DAVINCI_DM365_EVM
+ select SND_DAVINCI_SOC_I2S
+ select SND_SOC_TLV320AIC3X
+
+ help
+ Say Y if you want to add support for SoC audio on TI
+
config SND_DAVINCI_SOC_SFFSDR
tristate "SoC Audio support for SFFSDR"
depends on SND_DAVINCI_SOC && MACH_SFFSDR
diff --git a/sound/soc/davinci/Makefile b/sound/soc/davinci/Makefile
index 67be54f..8238612 100644
--- a/sound/soc/davinci/Makefile
+++ b/sound/soc/davinci/Makefile
@@ -13,4 +13,5 @@ snd-soc-sffsdr-objs := davinci-sffsdr.o
obj-$(CONFIG_SND_DAVINCI_SOC_EVM) += snd-soc-evm.o
obj-$(CONFIG_SND_DM6467_SOC_EVM) += snd-soc-evm.o
+obj-$(CONFIG_SND_DM365_SOC_EVM) += snd-soc-evm.o
obj-$(CONFIG_SND_DAVINCI_SOC_SFFSDR) += snd-soc-sffsdr.o
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index f3bb6f6..a859208 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -44,7 +44,8 @@ static int evm_hw_params(struct snd_pcm_substream *substream,
unsigned sysclk;
/* ASP1 on DM355 EVM is clocked by an external oscillator */
- if (machine_is_davinci_dm355_evm() || machine_is_davinci_dm6467_evm())
+ if (machine_is_davinci_dm355_evm() || machine_is_davinci_dm6467_evm()
+ || machine_is_davinci_dm365_evm())
sysclk = 2700;
/* ASP0 in DM6446 EVM is clocked by U55, as configured by
@@ -179,6 +180,14 @@ static struct snd_soc_card dm6467_snd_soc_card_evm = {
.num_links = ARRAY_SIZE(dm6467_evm_dai),
};
+/* davinci dm365 evm audio machine driver */
+static struct snd_soc_card dm365_snd_soc_card_evm = {
+ .name = "DaVinci DM365 EVM",
+ .platform = &davinci_soc_platform,
+ .dai_link = &evm_dai,
+ .num_links = 1,
+};
+
/* evm audio private data */
static struct aic3x_setup_data evm_aic3x_setup = {
.i2c_bus = 1,
@@ -191,6 +200,12 @@ static struct aic3x_setup_data dm6467_evm_aic3x_setup = {
.i2c_address = 0x18,
};
+/* dm365 evm audio private data */
+static struct aic3x_setup_data dm365_evm_aic3x_setup = {
+ .i2c_bus = 1,
+ .i2c_address = 0x18,
+};
+
/* evm audio subsystem */
static struct snd_soc_device evm_snd_devdata = {
.card = &snd_soc_card_evm,
@@ -198,13 +213,20 @@ static struct snd_soc_device evm_snd_devdata = {
.codec_data = &evm_aic3x_setup,
};
-/* evm audio subsystem */
+/* dm6467 evm audio subsystem */
static struct snd_soc_device dm6467_evm_snd_devdata = {
.card = &dm6467_snd_soc_card_evm,
.codec_dev = &soc_codec_dev_aic3x,
.codec_data = &dm6467_evm_aic3x_setup,
};
+/* dm365 evm audio subsystem */
+static struct snd_soc_device dm365_evm_snd_devdata = {
+ .card = &dm365_snd_soc_card_evm,
+ .codec_dev = &soc_codec_dev_aic3x,
+ .codec_data = &dm365_evm_aic3x_setup,
+};
+
static struct platform_device *evm_snd_device;
static int __init evm_init(void)
@@ -222,6 +244,9 @@ static int __init evm_init(void)
} else if (machine_is_davinci_dm6467_evm()) {
evm_snd_dev_data = &dm6467_evm_snd_devdata;
index = 0;
+ }else if (machine_is_davinci_dm365_evm()) {
+ evm_snd_dev_data = &dm365_evm_snd_devdata;
+ index = 0;
} else
return -EINVAL;
--
1.6.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 1/2] Davinci: DM365: Add platform device for McBSP
From: Miguel Aguilar
1) Registers the platform device for McBSP on DM365.
2) Add platform data to DM365 EVM board file.
Signed-off-by: Miguel Aguilar
---
arch/arm/mach-davinci/board-dm365-evm.c|4 ++
arch/arm/mach-davinci/dm365.c | 42 +++-
arch/arm/mach-davinci/include/mach/asp.h |3 ++
arch/arm/mach-davinci/include/mach/dm365.h |2 +
4 files changed, 50 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index f6adf79..fd2db78 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -177,6 +177,8 @@ static struct at24_platform_data eeprom_info = {
.context= (void *)0x7f00,
};
+static struct snd_platform_data dm365_evm_snd_data;
+
static struct i2c_board_info i2c_info[] = {
{
I2C_BOARD_INFO("dm365evm_keys", 0x25),
@@ -476,6 +478,8 @@ static __init void dm365_evm_init(void)
/* maybe setup mmc1/etc ... _after_ mmc0 */
evm_init_cpld();
+
+ dm365_init_asp(&dm365_evm_snd_data);
}
static __init void dm365_evm_irq_init(void)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index e815174..cba09b0 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "clock.h"
#include "mux.h"
@@ -456,7 +457,7 @@ static struct davinci_clk dm365_clks[] = {
CLK(NULL, "usb", &usb_clk),
CLK("davinci_emac.1", NULL, &emac_clk),
CLK("voice_codec", NULL, &voicecodec_clk),
- CLK("soc-audio.0", NULL, &asp0_clk),
+ CLK("davinci-asp.0", NULL, &asp0_clk),
CLK(NULL, "rto", &rto_clk),
CLK(NULL, "mjcp", &mjcp_clk),
CLK(NULL, NULL, NULL),
@@ -806,6 +807,31 @@ static struct platform_device dm365_edma_device = {
.resource = edma_resources,
};
+static struct resource dm365_asp_resources[] = {
+ {
+ .start = DAVINCI_DM365_ASP0_BASE,
+ .end= DAVINCI_DM365_ASP0_BASE + SZ_8K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = DAVINCI_DMA_ASP0_TX,
+ .end= DAVINCI_DMA_ASP0_TX,
+ .flags = IORESOURCE_DMA,
+ },
+ {
+ .start = DAVINCI_DMA_ASP0_RX,
+ .end= DAVINCI_DMA_ASP0_RX,
+ .flags = IORESOURCE_DMA,
+ },
+};
+
+static struct platform_device dm365_asp_device = {
+ .name = "davinci-asp",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(dm365_asp_resources),
+ .resource = dm365_asp_resources,
+};
+
static struct map_desc dm365_io_desc[] = {
{
.virtual= IO_VIRT,
@@ -907,6 +933,20 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
.sram_len = SZ_32K,
};
+void __init dm365_init_asp(struct snd_platform_data *pdata)
+{
+ davinci_cfg_reg(DM365_MCBSP0_BDX);
+ davinci_cfg_reg(DM365_MCBSP0_X);
+ davinci_cfg_reg(DM365_MCBSP0_BFSX);
+ davinci_cfg_reg(DM365_MCBSP0_BDR);
+ davinci_cfg_reg(DM365_MCBSP0_R);
+ davinci_cfg_reg(DM365_MCBSP0_BFSR);
+ 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);
+}
+
void __init dm365_init(void)
{
davinci_common_init(&davinci_soc_info_dm365);
diff --git a/arch/arm/mach-davinci/include/mach/asp.h
b/arch/arm/mach-davinci/include/mach/asp.h
index 18e4ce3..fbcbed0 100644
--- a/arch/arm/mach-davinci/include/mach/asp.h
+++ b/arch/arm/mach-davinci/include/mach/asp.h
@@ -15,6 +15,9 @@
#defineDAVINCI_DM646X_MCASP0_REG_BASE 0x01D01000
#define DAVINCI_DM646X_MCASP1_REG_BASE 0x01D01800
+/* Bases of dm365 register banks */
+#define DAVINCI_DM365_ASP0_BASE0x01D02000
+
/* Bases of da850/da830 McASP0 register banks */
#define DAVINCI_DA8XX_MCASP0_REG_BASE 0x01D0
diff --git a/arch/arm/mach-davinci/include/mach/dm365.h
b/arch/arm/mach-davinci/include/mach/dm365.h
index 09db434..2291c0d 100644
--- a/arch/arm/mach-davinci/include/mach/dm365.h
+++ b/arch/arm/mach-davinci/include/mach/dm365.h
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#define DM365_EMAC_BASE(0x01D07000)
#define DM365_EMAC_CNTRL_OFFSET(0x)
@@ -25,5 +26,6 @@
#define DM365_EMAC_CNTRL_RAM_SIZE (0x2000)
void __init dm365_init(void);
+void __init dm365_init_asp(struct snd_platform_data *pdata);
#endif /* __ASM_ARCH_DM365_H */
--
1.6.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] ARM: DaVinci: Add or modify AIC3x I2C board info
On Fri, 2009-08-28 at 18:19 +0530, Chaithrika U S wrote: > > > > On Wed, Aug 26, 2009 at 12:08 PM, Chaithrika U S > > > > wrote: > > > > > > > > > > > > This patch includes the codec I2C board info for DM6446 EVM > > > > and DM355 EVM. Also, it corrects the codec names in > > > > DA8xx/OMAP-L1xx > > > > board files. > > > > > > > > Tested on DM6446, DM355, DM6447, DA850 EVMs. > > > > > > > > Does this mean the patch was not tested on DA830 EVM? Should we expect > > the audio to work for DA830 on the tmp/asoc or master? > > > > Thanks > > > > Steve > > > > > I could not test it yesterday since the board was not readily available > with me. Checked it now on a DA830/OMAP-L137 EVM. Audio works on the > temp/asoc branch. > I see similar problem as JC. aplay is not producing any sounds for me on my rev B DA830/OMAP-l137 EVM (no daughter cards attached) with the temp/asoc branch. I updated the da830_omapl137_defconfig to build ALSA statically into the kernel. I also enable kernel config to build all CODEC. Are there any other patches that I need to include? Also, would you mind sharing the kernel config you use to verify ALSA? Regards, Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Problem with the current EDMA driver in the DaVinci GIT kernel
Does anyone have any feedback/thoughts on my suggestion below? We at TI need to know, and hopefully have some say in, the availability of EDMA channel allocations. Regards, - Rob > -Original Message- > From: Tivy, Robert > Sent: Wednesday, August 26, 2009 8:25 PM > To: David Brownell; Paulraj, Sandeep > Cc: davinci-linux-open-source@linux.davincidsp.com > Subject: RE: Problem with the current EDMA driver in the > DaVinci GIT kernel > > It seems that arriving at a consensus for reserved channels > isn't going to be easy. > > I'd like to suggest a scheme involving some sort of > driver-controlled unlocking of reserved channels, intended to > be used late in the EDMA acquisition timeline. The > LinuxUtils EDMA driver has a strong need for EDMA_ANY type of > allocation, to support memory-to-memory transfers by codecs, > mostly. It could call a kernel API when it's first > open()'ed, that tells the EDMA driver to transfer all > unallocated reserved channels over to the EDMA_ANY bitmask. > Most EDMA allocations will have already happened at that > point, and even if more fixed-channel request are coming, > there's more than a small chance that it will still be > available (not picked for an EDMA_ANY request). There could > be a "priority" to the EDMA_ANY acquisition, whereby certain > reserved channels are deemed to be more or less likely to be > requested later on, affecting how soon a channel is chosen > for EDMA_ANY. > > There could also be an API for a driver to request that a > certain channel not be allowed to be transferred to the > EDMA_ANY list, or some sort of a notification of future usage. > > It would be nice to also solve the issue of "raw" EDMA usage > through mmap()'ing the EDMA register set and directly writing > registers. Perhaps the /dev/mem driver can intercept these > requests and somehow negotiate or control access to those > registers (I'm just tossing this out there with not much idea > of how to solve it). > > Regards, > > - Rob > > > From: > davinci-linux-open-source-bounces+rtivy=ti@linux.davincids > p.com > [davinci-linux-open-source-bounces+rtivy=ti@linux.davincid > sp.com] On Behalf Of David Brownell [davi...@pacbell.net] > Sent: Wednesday, August 26, 2009 12:00 PM > To: Paulraj, Sandeep > Cc: davinci-linux-open-source@linux.davincidsp.com > Subject: Re: Problem with the current EDMA driver in the > DaVinci GIT kernel > > On Wednesday 26 August 2009, Paulraj, Sandeep wrote: > > > > > > > What's unclear is just why you chose those numbers. > I suspect > > > > > the issue is that you just want to avoid channels which are > > > > > (a) used by Linux drivers, and (b) the board uses the > relevant > > > > > driver. > > > > [Sandeep] yes > > > > Suggesting a name like EDMA_CHANNEL_HW_UNUSED. > > > > [Sandeep] I don't think this is needed > > > > > > Maybe not. If all devices associated with DMA drivers > can be relied > > > on to (i) register by a certain point in the init > sequence, and (ii) > > > properly list the DMA channels they use in their platform > resources, > > > then it's obviously possible to construct a set of all > DMA channels > > > "potentially in use" > > > by drivers on that particular board. > > > > [Sandeep] this can also be achieved by updating the structure > > appropriately as I have done in the patches whose links I had given > > earlier > > No; that's not maintainable. Each time a new driver starts > to use a channel, someone has to remember to update that > table. That's why it's just a hack. People WILL forget to > update that stuff, and then things WILL break. > > Plus, notice that your static updates won't accomodate > board-specific differences either ... like a board not using > one peripheral, and thereby making its DMA channels available > for other use. > > > > > And the list of channels available for use with software > triggering, > > > or chaining, or whatever this LinuxUtils thing is ... > would be the > > > inverse of that set. At that point in the init sequence -- and > > > before drivers are expected to make CHANNEL_ > allocations > > > -- feed the set of "free" channels to the EDMA infrastructure. > > > > > > IMCOP and similar codec drivers would of course need to claim the > > > channels they need; same deal. > > > > [Sandeep] how the IMCOP deals with its channels is handled by other > > components of the DVSDK. I am not sure of how exactly it is handled > > and I don't even know if the IMCOP actually used hardware > triggering. > > If those components don't say that they use those DMA > channels, then something other than IMCOP will be able to > allocate them... > trouble. So you'd better *find out* how it allocates those > resources, if you're trying to redefine the semantics of the > mechanism you identified. Or at least, you need to make sure > they use the right allocation scheme. > >
[PATCH] Davinci: Enable ASoC support for DM365 EVM in defconfig
From: Miguel Aguilar Signed-off-by: Miguel Aguilar --- arch/arm/configs/davinci_all_defconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig index ec63c15..cbe18b4 100644 --- a/arch/arm/configs/davinci_all_defconfig +++ b/arch/arm/configs/davinci_all_defconfig @@ -1099,6 +1099,7 @@ CONFIG_SND_DAVINCI_SOC_I2S=m CONFIG_SND_DAVINCI_SOC_MCASP=m CONFIG_SND_DAVINCI_SOC_EVM=m CONFIG_SND_DM6467_SOC_EVM=m +CONFIG_SND_DM365_SOC_EVM=m # CONFIG_SND_DAVINCI_SOC_SFFSDR is not set CONFIG_SND_SOC_I2C_AND_SPI=m # CONFIG_SND_SOC_ALL_CODECS is not set -- 1.6.0.4 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 2/2] ASoC: Davinci: Add audio codec support for DM365 EVM
From: Miguel Aguilar
1) Enables tlv320aic3101 support on DM365 EVM.
2) Set tlv320aic3x i2c setup into DM365 EVM board file.
This patch was tested on DM365 EVM rev c.
Signed-off-by: Miguel Aguilar
---
arch/arm/mach-davinci/board-dm365-evm.c |3 +++
sound/soc/davinci/Kconfig |9 +
sound/soc/davinci/Makefile |1 +
sound/soc/davinci/davinci-evm.c | 29 +++--
4 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index fd2db78..cff68e1 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -187,6 +187,9 @@ static struct i2c_board_info i2c_info[] = {
I2C_BOARD_INFO("24c256", 0x50),
.platform_data = &eeprom_info,
},
+ {
+ I2C_BOARD_INFO("tlv320aic3x", 0x18),
+ },
};
static struct davinci_i2c_platform_data i2c_pdata = {
diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig
index 6802dd5..b78b882 100644
--- a/sound/soc/davinci/Kconfig
+++ b/sound/soc/davinci/Kconfig
@@ -32,6 +32,15 @@ config SND_DM6467_SOC_EVM
help
Say Y if you want to add support for SoC audio on TI
+config SND_DM365_SOC_EVM
+ tristate "SoC Audio support for DaVinci DM365 EVM"
+ depends on SND_DAVINCI_SOC && MACH_DAVINCI_DM365_EVM
+ select SND_DAVINCI_SOC_I2S
+ select SND_SOC_TLV320AIC3X
+
+ help
+ Say Y if you want to add support for SoC audio on TI
+
config SND_DAVINCI_SOC_SFFSDR
tristate "SoC Audio support for SFFSDR"
depends on SND_DAVINCI_SOC && MACH_SFFSDR
diff --git a/sound/soc/davinci/Makefile b/sound/soc/davinci/Makefile
index 67be54f..8238612 100644
--- a/sound/soc/davinci/Makefile
+++ b/sound/soc/davinci/Makefile
@@ -13,4 +13,5 @@ snd-soc-sffsdr-objs := davinci-sffsdr.o
obj-$(CONFIG_SND_DAVINCI_SOC_EVM) += snd-soc-evm.o
obj-$(CONFIG_SND_DM6467_SOC_EVM) += snd-soc-evm.o
+obj-$(CONFIG_SND_DM365_SOC_EVM) += snd-soc-evm.o
obj-$(CONFIG_SND_DAVINCI_SOC_SFFSDR) += snd-soc-sffsdr.o
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index f3bb6f6..a859208 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -44,7 +44,8 @@ static int evm_hw_params(struct snd_pcm_substream *substream,
unsigned sysclk;
/* ASP1 on DM355 EVM is clocked by an external oscillator */
- if (machine_is_davinci_dm355_evm() || machine_is_davinci_dm6467_evm())
+ if (machine_is_davinci_dm355_evm() || machine_is_davinci_dm6467_evm()
+ || machine_is_davinci_dm365_evm())
sysclk = 2700;
/* ASP0 in DM6446 EVM is clocked by U55, as configured by
@@ -179,6 +180,14 @@ static struct snd_soc_card dm6467_snd_soc_card_evm = {
.num_links = ARRAY_SIZE(dm6467_evm_dai),
};
+/* davinci dm365 evm audio machine driver */
+static struct snd_soc_card dm365_snd_soc_card_evm = {
+ .name = "DaVinci DM365 EVM",
+ .platform = &davinci_soc_platform,
+ .dai_link = &evm_dai,
+ .num_links = 1,
+};
+
/* evm audio private data */
static struct aic3x_setup_data evm_aic3x_setup = {
.i2c_bus = 1,
@@ -191,6 +200,12 @@ static struct aic3x_setup_data dm6467_evm_aic3x_setup = {
.i2c_address = 0x18,
};
+/* dm365 evm audio private data */
+static struct aic3x_setup_data dm365_evm_aic3x_setup = {
+ .i2c_bus = 1,
+ .i2c_address = 0x18,
+};
+
/* evm audio subsystem */
static struct snd_soc_device evm_snd_devdata = {
.card = &snd_soc_card_evm,
@@ -198,13 +213,20 @@ static struct snd_soc_device evm_snd_devdata = {
.codec_data = &evm_aic3x_setup,
};
-/* evm audio subsystem */
+/* dm6467 evm audio subsystem */
static struct snd_soc_device dm6467_evm_snd_devdata = {
.card = &dm6467_snd_soc_card_evm,
.codec_dev = &soc_codec_dev_aic3x,
.codec_data = &dm6467_evm_aic3x_setup,
};
+/* dm365 evm audio subsystem */
+static struct snd_soc_device dm365_evm_snd_devdata = {
+ .card = &dm365_snd_soc_card_evm,
+ .codec_dev = &soc_codec_dev_aic3x,
+ .codec_data = &dm365_evm_aic3x_setup,
+};
+
static struct platform_device *evm_snd_device;
static int __init evm_init(void)
@@ -222,6 +244,9 @@ static int __init evm_init(void)
} else if (machine_is_davinci_dm6467_evm()) {
evm_snd_dev_data = &dm6467_evm_snd_devdata;
index = 0;
+ }else if (machine_is_davinci_dm365_evm()) {
+ evm_snd_dev_data = &dm365_evm_snd_devdata;
+ index = 0;
} else
return -EINVAL;
--
1.6.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Change logo
How can i change logo on dvrs hikvision aneone can help me Best Regards Filipe Andrade___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/2] ASoC: Davinci: Add audio codec support for DM365 EVM
Hi,
See the comment below:
miguel.agui...@ridgerun.com wrote:
From: Miguel Aguilar
1) Enables tlv320aic3101 support on DM365 EVM.
2) Set tlv320aic3x i2c setup into DM365 EVM board file.
This patch was tested on DM365 EVM rev c.
Signed-off-by: Miguel Aguilar
---
arch/arm/mach-davinci/board-dm365-evm.c |3 +++
sound/soc/davinci/Kconfig |9 +
sound/soc/davinci/Makefile |1 +
sound/soc/davinci/davinci-evm.c | 29 +++--
4 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index fd2db78..cff68e1 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -187,6 +187,9 @@ static struct i2c_board_info i2c_info[] = {
I2C_BOARD_INFO("24c256", 0x50),
.platform_data = &eeprom_info,
},
+ {tlv320aic3x
+ I2C_BOARD_INFO("tlv320aic3x", 0x18),
+ },
};
I just found that by adding the tlv320aic3x address in the DM365 EVM board file
the AIC is not being registered properly over I2C, so I need to resend this
patch without the AIC info in i2c_info[].
static struct davinci_i2c_platform_data i2c_pdata = {
diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig
index 6802dd5..b78b882 100644
--- a/sound/soc/davinci/Kconfig
+++ b/sound/soc/davinci/Kconfig
@@ -32,6 +32,15 @@ config SND_DM6467_SOC_EVM
help
Say Y if you want to add support for SoC audio on TI
+config SND_DM365_SOC_EVM
+ tristate "SoC Audio support for DaVinci DM365 EVM"
+ depends on SND_DAVINCI_SOC && MACH_DAVINCI_DM365_EVM
+ select SND_DAVINCI_SOC_I2S
+ select SND_SOC_TLV320AIC3X
+
+ help
+ Say Y if you want to add support for SoC audio on TI
+
config SND_DAVINCI_SOC_SFFSDR
tristate "SoC Audio support for SFFSDR"
depends on SND_DAVINCI_SOC && MACH_SFFSDR
diff --git a/sound/soc/davinci/Makefile b/sound/soc/davinci/Makefile
index 67be54f..8238612 100644
--- a/sound/soc/davinci/Makefile
+++ b/sound/soc/davinci/Makefile
@@ -13,4 +13,5 @@ snd-soc-sffsdr-objs := davinci-sffsdr.o
obj-$(CONFIG_SND_DAVINCI_SOC_EVM) += snd-soc-evm.o
obj-$(CONFIG_SND_DM6467_SOC_EVM) += snd-soc-evm.o
+obj-$(CONFIG_SND_DM365_SOC_EVM) += snd-soc-evm.o
obj-$(CONFIG_SND_DAVINCI_SOC_SFFSDR) += snd-soc-sffsdr.o
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index f3bb6f6..a859208 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -44,7 +44,8 @@ static int evm_hw_params(struct snd_pcm_substream *substream,
unsigned sysclk;
/* ASP1 on DM355 EVM is clocked by an external oscillator */
- if (machine_is_davinci_dm355_evm() || machine_is_davinci_dm6467_evm())
+ if (machine_is_davinci_dm355_evm() || machine_is_davinci_dm6467_evm()
+ || machine_is_davinci_dm365_evm())
sysclk = 2700;
/* ASP0 in DM6446 EVM is clocked by U55, as configured by
@@ -179,6 +180,14 @@ static struct snd_soc_card dm6467_snd_soc_card_evm = {
.num_links = ARRAY_SIZE(dm6467_evm_dai),
};
+/* davinci dm365 evm audio machine driver */
+static struct snd_soc_card dm365_snd_soc_card_evm = {
+ .name = "DaVinci DM365 EVM",
+ .platform = &davinci_soc_platform,
+ .dai_link = &evm_dai,
+ .num_links = 1,
+};
+
/* evm audio private data */
static struct aic3x_setup_data evm_aic3x_setup = {
.i2c_bus = 1,
@@ -191,6 +200,12 @@ static struct aic3x_setup_data dm6467_evm_aic3x_setup = {
.i2c_address = 0x18,
};
+/* dm365 evm audio private data */
+static struct aic3x_setup_data dm365_evm_aic3x_setup = {
+ .i2c_bus = 1,
+ .i2c_address = 0x18,
+};
+
/* evm audio subsystem */
static struct snd_soc_device evm_snd_devdata = {
.card = &snd_soc_card_evm,
@@ -198,13 +213,20 @@ static struct snd_soc_device evm_snd_devdata = {
.codec_data = &evm_aic3x_setup,
};
-/* evm audio subsystem */
+/* dm6467 evm audio subsystem */
static struct snd_soc_device dm6467_evm_snd_devdata = {
.card = &dm6467_snd_soc_card_evm,
.codec_dev = &soc_codec_dev_aic3x,
.codec_data = &dm6467_evm_aic3x_setup,
};
+/* dm365 evm audio subsystem */
+static struct snd_soc_device dm365_evm_snd_devdata = {
+ .card = &dm365_snd_soc_card_evm,
+ .codec_dev = &soc_codec_dev_aic3x,
+ .codec_data = &dm365_evm_aic3x_setup,
+};
+
static struct platform_device *evm_snd_device;
static int __init evm_init(void)
@@ -222,6 +244,9 @@ static int __init evm_init(void)
} else if (machine_is_davinci_dm6467_evm()) {
evm_snd_dev_data = &dm6467_evm_snd_devdata;
index = 0;
+ }else if (machine_is_davinci_dm365_evm()) {
+ evm_snd_dev_data = &dm365_evm_snd_devdata;
+ index = 0;
} else
Re: [PATCH 1/2] Davinci: DM365: Add platform device for McBSP
Hi,
See the comment below:
miguel.agui...@ridgerun.com wrote:
From: Miguel Aguilar
1) Registers the platform device for McBSP on DM365.
2) Add platform data to DM365 EVM board file.
Signed-off-by: Miguel Aguilar
---
arch/arm/mach-davinci/board-dm365-evm.c|4 ++
arch/arm/mach-davinci/dm365.c | 42 +++-
arch/arm/mach-davinci/include/mach/asp.h |3 ++
arch/arm/mach-davinci/include/mach/dm365.h |2 +
4 files changed, 50 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index f6adf79..fd2db78 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -177,6 +177,8 @@ static struct at24_platform_data eeprom_info = {
.context= (void *)0x7f00,
};
+static struct snd_platform_data dm365_evm_snd_data;
+
static struct i2c_board_info i2c_info[] = {
{
I2C_BOARD_INFO("dm365evm_keys", 0x25),
@@ -476,6 +478,8 @@ static __init void dm365_evm_init(void)
/* maybe setup mmc1/etc ... _after_ mmc0 */
evm_init_cpld();
+
+ dm365_init_asp(&dm365_evm_snd_data);
}
static __init void dm365_evm_irq_init(void)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index e815174..cba09b0 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "clock.h"
#include "mux.h"
@@ -456,7 +457,7 @@ static struct davinci_clk dm365_clks[] = {
CLK(NULL, "usb", &usb_clk),
CLK("davinci_emac.1", NULL, &emac_clk),
CLK("voice_codec", NULL, &voicecodec_clk),
- CLK("soc-audio.0", NULL, &asp0_clk),
+ CLK("davinci-asp.0", NULL, &asp0_clk),
CLK(NULL, "rto", &rto_clk),
CLK(NULL, "mjcp", &mjcp_clk),
CLK(NULL, NULL, NULL),
@@ -806,6 +807,31 @@ static struct platform_device dm365_edma_device = {
.resource = edma_resources,
};
+static struct resource dm365_asp_resources[] = {
+ {
+ .start = DAVINCI_DM365_ASP0_BASE,
+ .end= DAVINCI_DM365_ASP0_BASE + SZ_8K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = DAVINCI_DMA_ASP0_TX,
+ .end= DAVINCI_DMA_ASP0_TX,
+ .flags = IORESOURCE_DMA,
+ },
+ {
+ .start = DAVINCI_DMA_ASP0_RX,
+ .end= DAVINCI_DMA_ASP0_RX,
+ .flags = IORESOURCE_DMA,
+ },
+};
+
+static struct platform_device dm365_asp_device = {
+ .name = "davinci-asp",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(dm365_asp_resources),
+ .resource = dm365_asp_resources,
+};
+
static struct map_desc dm365_io_desc[] = {
{
.virtual= IO_VIRT,
@@ -907,6 +933,20 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
.sram_len = SZ_32K,
};
+void __init dm365_init_asp(struct snd_platform_data *pdata)
+{
+ davinci_cfg_reg(DM365_MCBSP0_BDX);
+ davinci_cfg_reg(DM365_MCBSP0_X);
+ davinci_cfg_reg(DM365_MCBSP0_BFSX);
+ davinci_cfg_reg(DM365_MCBSP0_BDR);
+ davinci_cfg_reg(DM365_MCBSP0_R);
+ davinci_cfg_reg(DM365_MCBSP0_BFSR);
+ davinci_cfg_reg(DM365_EVT2_ASP_TX);
+ davinci_cfg_reg(DM365_EVT3_ASP_RX);
DM365_EVT2_ASP_TX and DM365_EVT3_ASP_RX are defined but not registered in
dm365_pins[], so I need to resend this patch.
+ dm365_asp_device.dev.platform_data = pdata;
+ platform_device_register(&dm365_asp_device);
+}
+
void __init dm365_init(void)
{
davinci_common_init(&davinci_soc_info_dm365);
diff --git a/arch/arm/mach-davinci/include/mach/asp.h
b/arch/arm/mach-davinci/include/mach/asp.h
index 18e4ce3..fbcbed0 100644
--- a/arch/arm/mach-davinci/include/mach/asp.h
+++ b/arch/arm/mach-davinci/include/mach/asp.h
@@ -15,6 +15,9 @@
#defineDAVINCI_DM646X_MCASP0_REG_BASE 0x01D01000
#define DAVINCI_DM646X_MCASP1_REG_BASE 0x01D01800
+/* Bases of dm365 register banks */
+#define DAVINCI_DM365_ASP0_BASE0x01D02000
+
/* Bases of da850/da830 McASP0 register banks */
#define DAVINCI_DA8XX_MCASP0_REG_BASE 0x01D0
diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h
index 09db434..2291c0d 100644
--- a/arch/arm/mach-davinci/include/mach/dm365.h
+++ b/arch/arm/mach-davinci/include/mach/dm365.h
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#define DM365_EMAC_BASE (0x01D07000)
#define DM365_EMAC_CNTRL_OFFSET(0x)
@@ -25,5 +26,6 @@
#define DM365_EMAC_CNTRL_RAM_SIZE (0x2000)
void __init dm365_init(void);
+void __init dm365_init_asp(struct snd_platform_data *pdata);
#endif /* __ASM_ARCH_DM365_H */
__
Re: Problem with the current EDMA driver in the DaVinci GIT kernel
On Friday 28 August 2009, Tivy, Robert wrote: > > > I'd like to suggest a scheme involving some sort of > > driver-controlled unlocking of reserved channels, intended to > > be used late in the EDMA acquisition timeline. I think the suggestion I made was a lot simpler, and less error prone. The very *notion* of locking/unlocking things is asking for trouble. Why expose such a concept when it's clearly not needed? Before exploring different solutions ... how about giving my previous suggestion a fair shake first?? A simple implementation would be just scanning all the platform devices at some point (say, the first EDMA_ANY allocation) to construct that mask of "potentially used on this board" EDMA channels ... making the rest available for EDMA_ANY usage. Completely transparent to callers, and no need for SOC-specific hackery. And a fairly trivial thing to implement too ... just a driver model call to walk the platform_bus devices, then an array iteration to find the DMA resources. > > The > > LinuxUtils EDMA driver has a strong need for EDMA_ANY type of > > allocation, to support memory-to-memory transfers by codecs, > > mostly. My suggestion made many such channels available. > > It would be nice to also solve the issue of "raw" EDMA usage > > through mmap()'ing the EDMA register set and directly writing > > registers. Perhaps the /dev/mem driver can intercept these > > requests and somehow negotiate or control access to those > > registers (I'm just tossing this out there with not much idea > > of how to solve it). The /dev/mem (and /dev/kmem etc) drivers embed no policy. If you want policy, you'd need to write a new driver. - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 1/3] davinci: Move DA8xx/OMAP-L13x emac register routine
From: Mark A. Greer
Some mcasp code was inserted between the emac resource setup
and the related register routine that registers the emac.
Signed-off-by: Mark A. Greer
---
These patches are for the temp/asoc branch.
The first two are aesthetic but the last one is functional.
Unfortunately, sound doesn't seem to work before or afer
these patches.
arch/arm/mach-davinci/devices-da8xx.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 58ad5b6..94ce7a1 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -282,6 +282,11 @@ static struct platform_device da8xx_emac_device = {
.resource = da8xx_emac_resources,
};
+int __init da8xx_register_emac(void)
+{
+ return platform_device_register(&da8xx_emac_device);
+}
+
static struct resource da830_mcasp1_resources[] = {
{
.name = "mcasp1",
@@ -338,11 +343,6 @@ static struct platform_device da850_mcasp_device = {
.resource = da850_mcasp_resources,
};
-int __init da8xx_register_emac(void)
-{
- return platform_device_register(&da8xx_emac_device);
-}
-
void __init da8xx_init_mcasp(int id, struct snd_platform_data *pdata)
{
/* DA830/OMAP-L137 has 3 instances of McASP */
--
1.6.2.5.182.ga808d
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 3/3] davinci: Add DA830/OMAP-L137 EVM specific pinmux setting for McASP1
From: Mark A. Greer
The DA830/OMAP-L137 EVM cannot use the default pinmux setup for McASP1
so put the correct settings in the board file for that platform.
Signed-off-by: Mark A. Greer
---
arch/arm/mach-davinci/board-da830-evm.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index 22d9fe4..39711c1 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -55,6 +56,14 @@ static struct davinci_uart_config da830_evm_uart_config
__initdata = {
.enabled_uarts = 0x7,
};
+static const short da830_evm_mcasp1_pins[] = {
+ DA830_AHCLKX1, DA830_ACLKX1, DA830_AFSX1, DA830_AHCLKR1, DA830_AFSR1,
+ DA830_AMUTE1, DA830_AXR1_0, DA830_AXR1_1, DA830_AXR1_2, DA830_AXR1_5,
+ DA830_ACLKR1, DA830_AXR1_6, DA830_AXR1_7, DA830_AXR1_8, DA830_AXR1_10,
+ DA830_AXR1_11,
+ -1
+};
+
static u8 da830_iis_serializer_direction[] = {
RX_MODE,INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE,
INACTIVE_MODE, TX_MODE,INACTIVE_MODE, INACTIVE_MODE,
@@ -117,7 +126,7 @@ static __init void da830_evm_init(void)
i2c_register_board_info(1, da830_evm_i2c_devices,
ARRAY_SIZE(da830_evm_i2c_devices));
- ret = da8xx_pinmux_setup(da830_mcasp1_pins);
+ ret = da8xx_pinmux_setup(da830_evm_mcasp1_pins);
if (ret)
pr_warning("da830_evm_init: mcasp1 mux setup failed: %d\n",
ret);
--
1.6.2.5.182.ga808d
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 2/3] davinci: Change DA8xx/OMAP-L13x McASP registration routine name
From: Mark A. Greer
For consistency with existing code, change the name of
da8xx_init_mcasp() to da8xx_register_mcasp().
Signed-off-by: Mark A. Greer
---
arch/arm/mach-davinci/board-da830-evm.c|2 +-
arch/arm/mach-davinci/board-da850-evm.c|2 +-
arch/arm/mach-davinci/devices-da8xx.c |2 +-
arch/arm/mach-davinci/include/mach/da8xx.h |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index bfbb639..22d9fe4 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -122,7 +122,7 @@ static __init void da830_evm_init(void)
pr_warning("da830_evm_init: mcasp1 mux setup failed: %d\n",
ret);
- da8xx_init_mcasp(1, &da830_evm_snd_data);
+ da8xx_register_mcasp(1, &da830_evm_snd_data);
}
#ifdef CONFIG_SERIAL_8250_CONSOLE
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index c759d72..fbc7aae 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -365,7 +365,7 @@ static __init void da850_evm_init(void)
pr_warning("da850_evm_init: mcasp mux setup failed: %d\n",
ret);
- da8xx_init_mcasp(0, &da850_evm_snd_data);
+ da8xx_register_mcasp(0, &da850_evm_snd_data);
ret = da8xx_pinmux_setup(da850_lcdcntl_pins);
if (ret)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 94ce7a1..a54aa4e 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -343,7 +343,7 @@ static struct platform_device da850_mcasp_device = {
.resource = da850_mcasp_resources,
};
-void __init da8xx_init_mcasp(int id, struct snd_platform_data *pdata)
+void __init da8xx_register_mcasp(int id, struct snd_platform_data *pdata)
{
/* DA830/OMAP-L137 has 3 instances of McASP */
if (cpu_is_davinci_da830() && id == 1) {
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h
b/arch/arm/mach-davinci/include/mach/da8xx.h
index d4095d0..7576e8c 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -74,7 +74,7 @@ int da8xx_register_watchdog(void);
int da8xx_register_emac(void);
int da8xx_register_lcdc(void);
int da8xx_register_mmcsd0(struct davinci_mmc_config *config);
-void __init da8xx_init_mcasp(int id, struct snd_platform_data *pdata);
+void __init da8xx_register_mcasp(int id, struct snd_platform_data *pdata);
extern struct platform_device da8xx_serial_device;
extern struct emac_platform_data da8xx_emac_pdata;
--
1.6.2.5.182.ga808d
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Problem with the current EDMA driver in the DaVinci GIT kernel
Thanks for the reply, please see below... Regards, - Rob > -Original Message- > From: David Brownell [mailto:davi...@pacbell.net] > Sent: Friday, August 28, 2009 2:37 PM > > On Friday 28 August 2009, Tivy, Robert wrote: > > > > > I'd like to suggest a scheme involving some sort of > > > driver-controlled unlocking of reserved channels, intended to be > > > used late in the EDMA acquisition timeline. > > I think the suggestion I made was a lot simpler, and less > error prone. The very *notion* of locking/unlocking things > is asking for trouble. Why expose such a concept when it's > clearly not needed? Perhaps "locking/unlocking" was a poor choice of terminology, but essentially my scheme is the same as your's - transfer a set of unused channels to the "free" list late in the game, after you already have a good idea of specific need. I was just trying to avoid implementation-specific terminology, whereby the current implementation uses wording for the bitmasks such as "reserved" and "no_event". > > Before exploring different solutions ... how about giving my > previous suggestion a fair shake first?? Sure, and to be honest, I didn't much notice your original suggestion, it got "buried" at the end of a back-and-forth discussion about what should go in the static bitmasks, and at that point I was thinking your suggestion was more "static" in nature. In no way did I intend to supercede your suggestion. > > A simple implementation would be just scanning all the > platform devices at some point (say, the first EDMA_ANY > allocation) to construct that mask of "potentially used on > this board" EDMA channels ... making the rest available for > EDMA_ANY usage. Completely transparent to callers, and no > need for SOC-specific hackery. That sounds good, better than having a driver trigger this action explicitly (as per my original suggestion). > > And a fairly trivial thing to implement too ... just a driver > model call to walk the platform_bus devices, then an array > iteration to find the DMA resources. Is this something that can be implemented today, with the current driver model, or would it need some new information to be added to every DMA-using driver? (sorry for asking you to educate me, but I'm just not that familiar with all the driver specifics) > > > > > The > > > LinuxUtils EDMA driver has a strong need for EDMA_ANY type of > > > allocation, to support memory-to-memory transfers by > codecs, mostly. > > My suggestion made many such channels available. > Great. BTW, I've been told that future codecs would want on the order of 50 EDMA_ANY-type channels. > > - Dave > > ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2 1/2] Davinci: DM365: Add platform device for McBSP
From: Miguel Aguilar
1) Registers the platform device for McBSP on dm365.
2) Add platform data to DM365 EVM board file.
Signed-off-by: Miguel Aguilar
---
arch/arm/mach-davinci/board-dm365-evm.c|4 ++
arch/arm/mach-davinci/dm365.c | 45 +++-
arch/arm/mach-davinci/include/mach/asp.h |3 ++
arch/arm/mach-davinci/include/mach/dm365.h |2 +
4 files changed, 53 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index f6adf79..fd2db78 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -177,6 +177,8 @@ static struct at24_platform_data eeprom_info = {
.context= (void *)0x7f00,
};
+static struct snd_platform_data dm365_evm_snd_data;
+
static struct i2c_board_info i2c_info[] = {
{
I2C_BOARD_INFO("dm365evm_keys", 0x25),
@@ -476,6 +478,8 @@ static __init void dm365_evm_init(void)
/* maybe setup mmc1/etc ... _after_ mmc0 */
evm_init_cpld();
+
+ dm365_init_asp(&dm365_evm_snd_data);
}
static __init void dm365_evm_irq_init(void)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index e815174..c8bff14 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "clock.h"
#include "mux.h"
@@ -456,7 +457,7 @@ static struct davinci_clk dm365_clks[] = {
CLK(NULL, "usb", &usb_clk),
CLK("davinci_emac.1", NULL, &emac_clk),
CLK("voice_codec", NULL, &voicecodec_clk),
- CLK("soc-audio.0", NULL, &asp0_clk),
+ CLK("davinci-asp.0", NULL, &asp0_clk),
CLK(NULL, "rto", &rto_clk),
CLK(NULL, "mjcp", &mjcp_clk),
CLK(NULL, NULL, NULL),
@@ -603,6 +604,9 @@ INT_CFG(DM365, INT_IMX1_ENABLE, 24,1,1,
false)
INT_CFG(DM365, INT_IMX1_DISABLE,24,1,0, false)
INT_CFG(DM365, INT_NSF_ENABLE, 25,1,1, false)
INT_CFG(DM365, INT_NSF_DISABLE, 25,1,0, false)
+
+EVT_CFG(DM365, EVT2_ASP_TX, 0, 1,0, false)
+EVT_CFG(DM365, EVT3_ASP_RX, 1, 1,0, false)
#endif
};
@@ -806,6 +810,31 @@ static struct platform_device dm365_edma_device = {
.resource = edma_resources,
};
+static struct resource dm365_asp_resources[] = {
+ {
+ .start = DAVINCI_DM365_ASP0_BASE,
+ .end= DAVINCI_DM365_ASP0_BASE + SZ_8K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = DAVINCI_DMA_ASP0_TX,
+ .end= DAVINCI_DMA_ASP0_TX,
+ .flags = IORESOURCE_DMA,
+ },
+ {
+ .start = DAVINCI_DMA_ASP0_RX,
+ .end= DAVINCI_DMA_ASP0_RX,
+ .flags = IORESOURCE_DMA,
+ },
+};
+
+static struct platform_device dm365_asp_device = {
+ .name = "davinci-asp",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(dm365_asp_resources),
+ .resource = dm365_asp_resources,
+};
+
static struct map_desc dm365_io_desc[] = {
{
.virtual= IO_VIRT,
@@ -907,6 +936,20 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
.sram_len = SZ_32K,
};
+void __init dm365_init_asp(struct snd_platform_data *pdata)
+{
+ davinci_cfg_reg(DM365_MCBSP0_BDX);
+ davinci_cfg_reg(DM365_MCBSP0_X);
+ davinci_cfg_reg(DM365_MCBSP0_BFSX);
+ davinci_cfg_reg(DM365_MCBSP0_BDR);
+ davinci_cfg_reg(DM365_MCBSP0_R);
+ davinci_cfg_reg(DM365_MCBSP0_BFSR);
+ 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);
+}
+
void __init dm365_init(void)
{
davinci_common_init(&davinci_soc_info_dm365);
diff --git a/arch/arm/mach-davinci/include/mach/asp.h
b/arch/arm/mach-davinci/include/mach/asp.h
index 18e4ce3..fbcbed0 100644
--- a/arch/arm/mach-davinci/include/mach/asp.h
+++ b/arch/arm/mach-davinci/include/mach/asp.h
@@ -15,6 +15,9 @@
#defineDAVINCI_DM646X_MCASP0_REG_BASE 0x01D01000
#define DAVINCI_DM646X_MCASP1_REG_BASE 0x01D01800
+/* Bases of dm365 register banks */
+#define DAVINCI_DM365_ASP0_BASE0x01D02000
+
/* Bases of da850/da830 McASP0 register banks */
#define DAVINCI_DA8XX_MCASP0_REG_BASE 0x01D0
diff --git a/arch/arm/mach-davinci/include/mach/dm365.h
b/arch/arm/mach-davinci/include/mach/dm365.h
index 09db434..2291c0d 100644
--- a/arch/arm/mach-davinci/include/mach/dm365.h
+++ b/arch/arm/mach-davinci/include/mach/dm365.h
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#define DM365_EMAC_BASE(0x01D07000)
#define DM365_EMAC_CNTRL_OFFSET(0x
[PATCH v2 2/2] ASoC: Davinci: Add audio codec support for DM365 EVM
From: Miguel Aguilar
This patch enables tlv320aic3101 support on DM365 EVM and
it was tested on DM365 EVM rev c.
Signed-off-by: Miguel Aguilar
---
sound/soc/davinci/Kconfig |9 +
sound/soc/davinci/Makefile |1 +
sound/soc/davinci/davinci-evm.c | 29 +++--
3 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig
index 6802dd5..b78b882 100644
--- a/sound/soc/davinci/Kconfig
+++ b/sound/soc/davinci/Kconfig
@@ -32,6 +32,15 @@ config SND_DM6467_SOC_EVM
help
Say Y if you want to add support for SoC audio on TI
+config SND_DM365_SOC_EVM
+ tristate "SoC Audio support for DaVinci DM365 EVM"
+ depends on SND_DAVINCI_SOC && MACH_DAVINCI_DM365_EVM
+ select SND_DAVINCI_SOC_I2S
+ select SND_SOC_TLV320AIC3X
+
+ help
+ Say Y if you want to add support for SoC audio on TI
+
config SND_DAVINCI_SOC_SFFSDR
tristate "SoC Audio support for SFFSDR"
depends on SND_DAVINCI_SOC && MACH_SFFSDR
diff --git a/sound/soc/davinci/Makefile b/sound/soc/davinci/Makefile
index 67be54f..8238612 100644
--- a/sound/soc/davinci/Makefile
+++ b/sound/soc/davinci/Makefile
@@ -13,4 +13,5 @@ snd-soc-sffsdr-objs := davinci-sffsdr.o
obj-$(CONFIG_SND_DAVINCI_SOC_EVM) += snd-soc-evm.o
obj-$(CONFIG_SND_DM6467_SOC_EVM) += snd-soc-evm.o
+obj-$(CONFIG_SND_DM365_SOC_EVM) += snd-soc-evm.o
obj-$(CONFIG_SND_DAVINCI_SOC_SFFSDR) += snd-soc-sffsdr.o
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index f3bb6f6..a859208 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -44,7 +44,8 @@ static int evm_hw_params(struct snd_pcm_substream *substream,
unsigned sysclk;
/* ASP1 on DM355 EVM is clocked by an external oscillator */
- if (machine_is_davinci_dm355_evm() || machine_is_davinci_dm6467_evm())
+ if (machine_is_davinci_dm355_evm() || machine_is_davinci_dm6467_evm()
+ || machine_is_davinci_dm365_evm())
sysclk = 2700;
/* ASP0 in DM6446 EVM is clocked by U55, as configured by
@@ -179,6 +180,14 @@ static struct snd_soc_card dm6467_snd_soc_card_evm = {
.num_links = ARRAY_SIZE(dm6467_evm_dai),
};
+/* davinci dm365 evm audio machine driver */
+static struct snd_soc_card dm365_snd_soc_card_evm = {
+ .name = "DaVinci DM365 EVM",
+ .platform = &davinci_soc_platform,
+ .dai_link = &evm_dai,
+ .num_links = 1,
+};
+
/* evm audio private data */
static struct aic3x_setup_data evm_aic3x_setup = {
.i2c_bus = 1,
@@ -191,6 +200,12 @@ static struct aic3x_setup_data dm6467_evm_aic3x_setup = {
.i2c_address = 0x18,
};
+/* dm365 evm audio private data */
+static struct aic3x_setup_data dm365_evm_aic3x_setup = {
+ .i2c_bus = 1,
+ .i2c_address = 0x18,
+};
+
/* evm audio subsystem */
static struct snd_soc_device evm_snd_devdata = {
.card = &snd_soc_card_evm,
@@ -198,13 +213,20 @@ static struct snd_soc_device evm_snd_devdata = {
.codec_data = &evm_aic3x_setup,
};
-/* evm audio subsystem */
+/* dm6467 evm audio subsystem */
static struct snd_soc_device dm6467_evm_snd_devdata = {
.card = &dm6467_snd_soc_card_evm,
.codec_dev = &soc_codec_dev_aic3x,
.codec_data = &dm6467_evm_aic3x_setup,
};
+/* dm365 evm audio subsystem */
+static struct snd_soc_device dm365_evm_snd_devdata = {
+ .card = &dm365_snd_soc_card_evm,
+ .codec_dev = &soc_codec_dev_aic3x,
+ .codec_data = &dm365_evm_aic3x_setup,
+};
+
static struct platform_device *evm_snd_device;
static int __init evm_init(void)
@@ -222,6 +244,9 @@ static int __init evm_init(void)
} else if (machine_is_davinci_dm6467_evm()) {
evm_snd_dev_data = &dm6467_evm_snd_devdata;
index = 0;
+ }else if (machine_is_davinci_dm365_evm()) {
+ evm_snd_dev_data = &dm365_evm_snd_devdata;
+ index = 0;
} else
return -EINVAL;
--
1.6.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Problem with the current EDMA driver in the DaVinci GIT kernel
On Friday 28 August 2009, Tivy, Robert wrote: > > > > And a fairly trivial thing to implement too ... just a driver > > model call to walk the platform_bus devices, then an array > > iteration to find the DMA resources. > > Is this something that can be implemented today, with the current > driver model, Yes; bus_for_each_dev(&platform_bus_type, ...) then using platform_device.resource[] to check for channels. > or would it need some new information to be added to every DMA-using > driver? (sorry for asking you to educate me, but I'm just not that > familiar with all the driver specifics) Given they fetch their channels correctly (as resources), all the data is already in place. ASoC was trouble in the past; fixed now, I hope. > > > > The > > > > LinuxUtils EDMA driver has a strong need for EDMA_ANY type of > > > > allocation, to support memory-to-memory transfers by > > codecs, mostly. > > > > My suggestion made many such channels available. > > > > Great. BTW, I've been told that future codecs would want on the > order of 50 EDMA_ANY-type channels. Sounds a bit excessive; like they needlessly refuse to share those resources! But if that's on hardware with channels to burn, so be it. - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Problem with the current EDMA driver in the DaVinci GIT kernel
> -Original Message- > From: David Brownell [mailto:davi...@pacbell.net] > Sent: Friday, August 28, 2009 3:27 PM > > On Friday 28 August 2009, Tivy, Robert wrote: > > > > Great. BTW, I've been told that future codecs would want > on the order > > of 50 EDMA_ANY-type channels. > > Sounds a bit excessive; like they needlessly refuse to share > those resources! But if that's on hardware with channels to > burn, so be it. > > - Dave > Below is a "codec DMA needs" FAQ that a TI codec programmer supplied me. Regards, - Rob 1. Why does codec need so many EDMA channels ? Ans: DM365 HDVICP architecture needs data to be transferred from one buffer to another for its encode/decode operation. The src/destination can be DDR, ARM TCM or HDVICP/VICP internal buffers. EDMA is used for doing these data transfers. The nature of the HDVICP architecture requires multiple transfers to happen in parallel which mandates need to as many as 36 channels. Going forward in future codec release, there are further optimization planned which will require even more channels. Viz, in DM375, codecs plan to use as many as 50 channels. 2 Can there be any other alternative to do memory transfer? Ans: CPU copy is very slow and needs CPU intervention. EDMA is the only option available. 3. If codec blocks so many channels, can it effect application use case ? Ans: DM365/DM375 is planned for wide variety of application. Hence it has got so many peripherals and EDMA events associated. In a given use case/application, all the EDMA events does not get used. Hence ample EDMA channels are available for other use. For example, in a video record application, audio will need 1 edma event, SPI may need 1/2, SDCRD may need 1. Out of 64, almost 60 channels would be free. 4. Why does codec need EDMA_ANY channel support? Ans: Codec needs EDMA ch only for internal memory transfer. It always operate in manual sync mode(writing to ESR bits), the transfers are not really related to events. Hence codec does not want to ask specifically for any EDMA channels. LSP is free to give any channel which is free at that point of time. This arrangements gives lot of flexibility to the application design. Imagine a situation if codec asks specific EDMA channels, there is a good probability that it will block an EDMA channel which could be needed by some driver. In case it doesn't block, it is impossible for the codec to predict which are the free channels available at the time to its creation. On the other hand, if codec uses EDMA_ANY, then LSP can give any free channel available at that time. Application has to just ensure that it asks the edma channel for the drivers before creating the codec instance. 5. What is the market demand for codecs ? Ans: DM365 is basically a media processor chip. Hence Codec is the primary use case. BU/ marketing will have the exact answer of how much % of the chips gets used for video related application. I feel it would be majority of the %. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 1/6] Updated Support for TVP7002 in v4l2 definitions
From: Santiago Nunez-Corrales
This patch provides required std and control definitions in TVP7002
within v4l2. Removed HD definitions.
Signed-off-by: Santiago Nunez-Corrales
---
include/linux/videodev2.h | 25 +
include/media/v4l2-chip-ident.h |3 +++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 74f1687..685bc7e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1147,6 +1147,31 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16)
+
+/* tvp7002 control IDs*/
+#define V4L2_CID_TVP7002_BASE V4L2_CTRL_CLASS_DECODER
+#define V4L2_CID_TVP7002_COARSE_GAIN_R (V4L2_CID_TVP7002_BASE + 1)
+#define V4L2_CID_TVP7002_COARSE_GAIN_G (V4L2_CID_TVP7002_BASE + 2)
+#define V4L2_CID_TVP7002_COARSE_GAIN_B (V4L2_CID_TVP7002_BASE + 3)
+#define V4L2_CID_TVP7002_FINE_GAIN_R (V4L2_CID_TVP7002_BASE + 4)
+#define V4L2_CID_TVP7002_FINE_GAIN_G (V4L2_CID_TVP7002_BASE + 5)
+#define V4L2_CID_TVP7002_FINE_GAIN_B (V4L2_CID_TVP7002_BASE + 6)
+#define V4L2_CID_TVP7002_B_CLAMP (V4L2_CID_TVP7002_BASE + 7)
+#define V4L2_CID_TVP7002_G_CLAMP (V4L2_CID_TVP7002_BASE + 8)
+#define V4L2_CID_TVP7002_R_CLAMP (V4L2_CID_TVP7002_BASE + 9)
+#define V4L2_CID_TVP7002_CLAMP_OFF_EN (V4L2_CID_TVP7002_BASE + 10)
+#define V4L2_CID_TVP7002_FCTCA (V4L2_CID_PRIVATE_BASE + 11)
+#define V4L2_CID_TVP7002_F_CLAMP_GB(V4L2_CID_TVP7002_BASE + 12)
+#define V4L2_CID_TVP7002_F_CLAMP_R (V4L2_CID_TVP7002_BASE + 13)
+#define V4L2_CID_TVP7002_CLAMP_START (V4L2_CID_TVP7002_BASE + 14)
+#define V4L2_CID_TVP7002_CLAMP_W (V4L2_CID_TVP7002_BASE + 15)
+#define V4L2_CID_TVP7002_B_COARSE_OFF (V4L2_CID_TVP7002_BASE + 16)
+#define V4L2_CID_TVP7002_G_COARSE_OFF (V4L2_CID_TVP7002_BASE + 17)
+#define V4L2_CID_TVP7002_R_COARSE_OFF (V4L2_CID_TVP7002_BASE + 18)
+#define V4L2_CID_TVP7002_B_FINE_OFF(V4L2_CID_TVP7002_BASE + 19)
+#define V4L2_CID_TVP7002_G_FINE_OFF(V4L2_CID_TVP7002_BASE + 20)
+#define V4L2_CID_TVP7002_R_FINE_OFF(V4L2_CID_TVP7002_BASE + 21)
+
/*
* T U N I N G
*/
diff --git a/include/media/v4l2-chip-ident.h b/include/media/v4l2-chip-ident.h
index 56b31cb..14c83b5 100644
--- a/include/media/v4l2-chip-ident.h
+++ b/include/media/v4l2-chip-ident.h
@@ -129,6 +129,9 @@ enum {
V4L2_IDENT_SAA6752HS = 6752,
V4L2_IDENT_SAA6752HS_AC3 = 6753,
+ /* module tvp7002: just ident 7002 */
+ V4L2_IDENT_TVP7002 = 7002,
+
/* module adv7170: just ident 7170 */
V4L2_IDENT_ADV7170 = 7170,
--
1.6.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 5/6] Updated TVP7002 driver for DM365
From: Santiago Nunez-Corrales
This patch provides the implementation of the TVP7002 decoder
driver for DM365. Implemented revisions by Vaibhav Hiremath.
Signed-off-by: Santiago Nunez-Corrales
---
drivers/media/video/tvp7002.c | 2179 +
1 files changed, 2179 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/tvp7002.c
diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c
new file mode 100644
index 000..f70b6d3
--- /dev/null
+++ b/drivers/media/video/tvp7002.c
@@ -0,0 +1,2179 @@
+/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics
+ * Digitizer with Horizontal PLL registers
+ *
+ * Copyright (C) 2009 Texas Instruments Inc
+ * Author: Santiago Nunez-Corrales
+ *
+ * This code is partially based upon the TVP5150 driver
+ * written by Mauro Carvalho Chehab (mche...@infradead.org)
+ * and the TVP514x driver written by Vaibhav Hiremath
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "tvp7002_reg.h"
+
+MODULE_DESCRIPTION("TI TVP7002 Video and Graphics Digitizer driver");
+MODULE_AUTHOR("Santiago Nunez-Corrales (santiago.nu...@ridgerun.com)");
+MODULE_LICENSE("GPL");
+
+/* I2C retry attempts */
+#define I2C_RETRY_COUNT (5)
+
+/* Debugging information */
+
+static int debug;
+module_param(debug, int, 0);
+MODULE_PARM_DESC(debug, "Debug level (0-2)");
+
+/* Reference to tvp7002_platform_data */
+extern static struct tvp7002_platform_data;
+
+/* Struct for handling resolutions and associate register values */
+struct tvp7002_resol {
+ v4l2_std_id id;
+ int hres;
+ int vres;
+ int frate;
+ int lrate;
+ int prate;
+ unsigned char reg01;
+ unsigned char reg02;
+ unsigned char reg03;
+ unsigned char reg04;
+};
+
+/* Struct for handling register values */
+struct i2c_reg_value {
+ unsigned char reg;
+ unsigned char value;
+};
+
+/* Register default values (according to tvp7002 datasheet) */
+static const struct i2c_reg_value tvp7002_init_default[] = {
+ /* 0x00: read only */
+ {
+ TVP7002_HPLL_FDBK_DIV_MSBS, 0x67
+ },
+ {
+ TVP7002_HPLL_FDBK_DIV_LSBS, 0x20
+ },
+ {
+ TVP7002_HPLL_CRTL, 0xa8
+ },
+ {
+ TVP7002_HPLL_PHASE_SEL, 0x80
+ },
+ {
+ TVP7002_CLAMP_START, 0x32
+ },
+ {
+ TVP7002_CLAMP_W, 0x20
+ },
+ {
+ TVP7002_HSYNC_OUT_W, 0x20
+ },
+ {
+ TVP7002_B_FINE_GAIN, 0x00
+ },
+ {
+ TVP7002_G_FINE_GAIN, 0x00
+ },
+ {
+ TVP7002_R_FINE_GAIN, 0x00
+ },
+ {
+ TVP7002_B_FINE_OFF_MSBS, 0x80
+ },
+ {
+ TVP7002_G_FINE_OFF_MSBS, 0x80
+ },
+ {
+ TVP7002_R_FINE_OFF_MSBS, 0x80
+ },
+ {
+ TVP7002_SYNC_CTL_1, 0x5b
+ },
+ {
+ TVP7002_HPLL_AND_CLAMP_CTL, 0x2e
+ },
+ {
+ TVP7002_SYNC_ON_G_THRS, 0x5d
+ },
+ {
+ TVP7002_SYNC_SEPARATOR_THRS, 0x20
+ },
+ {
+ TVP7002_HPLL_PRE_COAST, 0x00
+ },
+ {
+ TVP7002_HPLL_POST_COAST, 0x00
+ },
+ /* 0x14: read only */
+ {
+ TVP7002_OUT_FORMATTER, 0x00
+ },
+ {
+ TVP7002_MISC_CTL_1, 0x11
+ },
+ {
+ TVP7002_MISC_CTL_2, 0x03
+ },
+ {
+ TVP7002_MISC_CTL_3, 0x00
+ },
+ {
+ TVP7002_IN_MUX_SEL_1, 0x00
+ },
+ {
+ TVP7002_IN_MUX_SEL_2, 0xc2
+ },
+ {
+ TVP7002_B_AND_G_COARSE_GAIN, 0x77
+ },
+ {
+ TVP7002_R_COARSE_GAIN, 0x07
+ },
+ {
+ TVP7002_COARSE_CLAMP_CTL, 0x00
+ },
+ {
+ TVP7002_FINE_OFF_LSBS, 0x00
+ },
+ {
+ TVP7002_B_COARSE_OFF, 0x10
+ },
+ {
+ TVP7002_G_COARSE_OFF, 0x10
+ },
+ {
+ TVP7002_R_COARSE_OFF, 0x10
+ },
+ {
+
[PATCH 2/6] Updated Support for TVP7002 in dm365 board
From: Santiago Nunez-Corrales
This patch provides support for TVP7002 in architecture definitions
within DM365. Moved tvp7002 platform data here.
Signed-off-by: Santiago Nunez-Corrales
---
arch/arm/mach-davinci/board-dm365-evm.c | 67 +--
1 files changed, 63 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index 362ac62..78d0346 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
static inline int have_imager(void)
@@ -53,14 +54,20 @@ static inline int have_imager(void)
static inline int have_tvp7002(void)
{
- /* REVISIT when it's supported, trigger via Kconfig */
+#ifdef CONFIG_VIDEO_TVP7002
+ return 1;
+#else
return 0;
+#endif
}
#define DM365_ASYNC_EMIF_CONTROL_BASE 0x01d1
#define DM365_ASYNC_EMIF_DATA_CE0_BASE 0x0200
#define DM365_ASYNC_EMIF_DATA_CE1_BASE 0x0400
+#define DM365_ASYNC_EMIF_DATA_CE1_REG3 0x18
+#define DM365_ASYNC_EMIF_VIDEO_MUX_MASK(0x07070707)
+#define DM365_ASYNC_EMIF_TVP7002_SEL (0x01010101)
#define DM365_EVM_PHY_MASK (0x2)
#define DM365_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
@@ -109,6 +116,14 @@ static struct tvp514x_platform_data tvp5146_pdata = {
.vs_polarity = 1
};
+/* tvp7002 platform data, used during reset and probe operations */
+static struct tvp7002_platform_data tvp7002_pdata = {
+ .clk_polarity = 1,
+ .hs_polarity = 1,
+ .vs_polarity = 1,
+ .fid_polarity = 1,
+};
+
/* 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
@@ -243,6 +258,22 @@ static struct v4l2_input tvp5146_inputs[] = {
},
};
+#define TVP7002_STD_ALL(V4L2_STD_525P_60 | V4L2_STD_625P_50 |\
+ V4L2_STD_720P_50 | V4L2_STD_720P_60 |\
+ V4L2_STD_1080I_50 | V4L2_STD_1080I_60 |\
+ V4L2_STD_1080P_50 | V4L2_STD_1080P_60)
+
+
+/* Inputs available at the TVP7002 */
+static struct v4l2_input tvp7002_inputs[] = {
+ {
+ .index = 0,
+ .name = "Component",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP7002_STD_ALL,
+ },
+};
+
/*
* this is the route info for connecting each input to decoder
* ouput that goes to vpfe. There is a one to one correspondence
@@ -260,7 +291,7 @@ static struct vpfe_route tvp5146_routes[] = {
};
static struct vpfe_subdev_info vpfe_sub_devs[] = {
-{
+{
.module_name = "tvp5146",
.grp_id = 0,
.num_inputs = ARRAY_SIZE(tvp5146_inputs),
@@ -276,6 +307,22 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = {
I2C_BOARD_INFO("tvp5146", 0x5d),
.platform_data = &tvp5146_pdata,
},
+ },
+{
+ .module_name = "tvp7002",
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp7002_inputs),
+ .inputs = tvp7002_inputs,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT1120,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO("tvp7002", 0x5c),
+ .platform_data = &tvp7002_pdata,
+ },
}
};
@@ -439,6 +486,16 @@ static int __init cpld_leds_init(void)
/* run after subsys_initcall() for LEDs */
fs_initcall(cpld_leds_init);
+/* Set the input mux for TVP7002 */
+int tvp7002_set_input_mux(unsigned char channel)
+{
+ u32 val;
+ val = __raw_readl(DM365_ASYNC_EMIF_DATA_CE1_REG3);
+ val &= ~DM365_ASYNC_EMIF_VIDEO_MUX_MASK;
+ val |= DM365_ASYNC_EMIF_TVP7002_SEL;
+ __raw_writel(val, DM365_ASYNC_EMIF_DATA_CE1_REG3);
+ return 0;
+}
static void __init evm_init_cpld(void)
{
@@ -519,6 +576,8 @@ fail:
mux |= 2;
resets &= ~BIT(2);
label = "tvp7002 HD";
+ // Call the input setter
+ tvp7002_set_input_mux(0);
} else {
/* default to tvp5146 */
mux |= 5;
@@ -526,8 +585,8 @@ fail:
label = "tvp5146 SD";
}
}
- __raw_writeb(mux, cpld + CPLD_MUX);
- __raw_writeb(resets, cpld + CPLD_RESETS);
+ __raw_writel(mux, cpld + CPLD_MUX);
+ __raw_writel(resets, cpld + CPLD_RESETS);
pr_info("EVM: %s video input\n", label);
[PATCH 3/6] Updated Support for TVP7002 in VPFE
From: Santiago Nunez-Corrales
This patch adds support for TVP7002 in the DM365 VPFE inteface.
Updated to latest code in linux-staging repository.
Signed-off-by: Santiago Nunez-Corrales
---
drivers/media/video/davinci/vpfe_capture.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 2a4a05a..a71c48b 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -140,8 +140,15 @@ static DEFINE_MUTEX(ccdc_lock);
static struct ccdc_config *ccdc_cfg;
const struct vpfe_standard vpfe_standards[] = {
- {V4L2_STD_525_60, 720, 480, {11, 10}, 1},
- {V4L2_STD_625_50, 720, 576, {54, 59}, 1},
+ {V4L2_STD_525P_60, 720, 480, {11, 10}, 0},
+ {V4L2_STD_625P_50, 720, 576, {54, 59}, 0},
+ {V4L2_STD_720P_50, 1280, 720, {12, 10}, 0},
+ {V4L2_STD_720P_50, 1280, 720, {12, 10}, 0},
+ {V4L2_STD_720P_60, 1280, 720, {12, 10}, 0},
+ {V4L2_STD_1080I_50, 1920, 1080, {12, 10}, 1},
+ {V4L2_STD_1080I_60, 1920, 1080, {12, 10}, 1},
+ {V4L2_STD_1080P_50, 1920, 1080, {12, 10}, 0},
+ {V4L2_STD_1080P_60, 1920, 1080, {12, 10}, 0},
};
/* Used when raw Bayer image from ccdc is directly captured to SDRAM */
--
1.6.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 4/6] Updated Definitions for TVP7002 in DM365
From: Santiago Nunez-Corrales This patch provides the required definitions for the TVP7002 driver in DM365. Move private data structures to driver/media/video/tvp7002.c Signed-off-by: Santiago Nunez-Corrales --- drivers/media/video/tvp7002_reg.h | 148 + include/media/tvp7002.h | 76 +++ 2 files changed, 224 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/tvp7002_reg.h create mode 100644 include/media/tvp7002.h diff --git a/drivers/media/video/tvp7002_reg.h b/drivers/media/video/tvp7002_reg.h new file mode 100644 index 000..4c9aa31 --- /dev/null +++ b/drivers/media/video/tvp7002_reg.h @@ -0,0 +1,148 @@ +/* + * tvp7002_reg.h - Register definitions for TVP7002 + * + * Copyright (C) 2009 Texas Instruments Inc + * Author: Santiago Nunez-Corrales + * + * This code is partially based upon the TVP5150 driver + * written by Mauro Carvalho Chehab (mche...@infradead.org) + * + * 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; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +/* Naming conventions + * -- + * + * FDBK: Feedback + * DIV: Divider + * CTL: Control + * SEL: Select + * IN:Input + * OUT: Output + * R: Red + * G: Green + * B: Blue + * OFF: Offset + * THRS: Threshold + * DGTL: Digital + * LVL: Level + * PWR: Power + * MVIS: Macrovision + * W: Width + * H: Height + * ALGN: Alignment + * CLK: Clocks + * TOL: Tolerance + * BWTH: Bandwidth + * COEF: Coefficient + * STAT: Status + * AUTO: Automatic + * FLD: Field + * L:Line + */ + +#define TVP7002_CHIP_REV 0x00 +#define TVP7002_HPLL_FDBK_DIV_MSBS 0x01 +#define TVP7002_HPLL_FDBK_DIV_LSBS 0x02 +#define TVP7002_HPLL_CRTL 0x03 +#define TVP7002_HPLL_PHASE_SEL 0x04 +#define TVP7002_CLAMP_START0x05 +#define TVP7002_CLAMP_W0x06 +#define TVP7002_HSYNC_OUT_W0x07 +#define TVP7002_B_FINE_GAIN0x08 +#define TVP7002_G_FINE_GAIN0x09 +#define TVP7002_R_FINE_GAIN0x0a +#define TVP7002_B_FINE_OFF_MSBS0x0b +#define TVP7002_G_FINE_OFF_MSBS 0x0c +#define TVP7002_R_FINE_OFF_MSBS 0x0d +#define TVP7002_SYNC_CTL_1 0x0e +#define TVP7002_HPLL_AND_CLAMP_CTL 0x0f +#define TVP7002_SYNC_ON_G_THRS 0x10 +#define TVP7002_SYNC_SEPARATOR_THRS0x11 +#define TVP7002_HPLL_PRE_COAST 0x12 +#define TVP7002_HPLL_POST_COAST0x13 +#define TVP7002_SYNC_DETECT_STAT 0x14 +#define TVP7002_OUT_FORMATTER 0x15 +#define TVP7002_MISC_CTL_1 0x16 +#define TVP7002_MISC_CTL_2 0x17 +#define TVP7002_MISC_CTL_3 0x18 +#define TVP7002_IN_MUX_SEL_1 0x19 +#define TVP7002_IN_MUX_SEL_20x1a +#define TVP7002_B_AND_G_COARSE_GAIN0x1b +#define TVP7002_R_COARSE_GAIN 0x1c +#define TVP7002_FINE_OFF_LSBS 0x1d +#define TVP7002_B_COARSE_OFF 0x1e +#define TVP7002_G_COARSE_OFF0x1f +#define TVP7002_R_COARSE_OFF0x20 +#define TVP7002_HSOUT_OUT_START0x21 +#define TVP7002_MISC_CTL_4 0x22 +#define TVP7002_B_DGTL_ALC_OUT_LSBS0x23 +#define TVP7002_G_DGTL_ALC_OUT_LSBS 0x24 +#define TVP7002_R_DGTL_ALC_OUT_LSBS 0x25 +#define TVP7002_AUTO_LVL_CTL_ENABLE0x26 +#define TVP7002_DGTL_ALC_OUT_MSBS 0x27 +#define TVP7002_AUTO_LVL_CTL_FILTER0x28 +/* Reserved 0x29*/ +#define TVP7002_FINE_CLAMP_CTL 0x2a +#define TVP7002_PWR_CTL0x2b +#define TVP7002_ADC_SETUP 0x2c +#define TVP7002_COARSE_CLAMP_CTL 0x2d +#define TVP7002_SOG_CLAMP 0x2e +#define TVP7002_RGB_COARSE_CLAMP_CTL 0x2f +#define TVP7002_SOG_COARSE_CLAMP_CTL 0x30 +#define TVP7002_ALC_PLACEMENT 0x31 +/* Reserved 0x32 */ +/* Reserved 0x33 */ +#define TVP7002_MVIS_STRIPPER_W0x34 +#define TVP7002_VSYNC_ALGN 0x35 +#define TVP7002_SYNC_BYPASS0x36 +#define TVP7002_L_FRAME_STAT_LSBS 0x37 +#define TVP7002_L_FRAME_STAT_MSBS 0x38 +#define TVP7002_CLK_L_STAT_LSBS0x39 +#define TVP7002_CLK_L_STAT_MSBS0x3a +#define TVP7002_HSYNC_W0x3b +#define TVP7002_VSYNC_W 0x3c +#
RE: Problem with the current EDMA driver in the DaVinci GIT kernel
First, I should mention that I'm in favor of what you've been discussing, Rob and David. I think having a mechanism in place to make more EDMA channels available for consumption is a good thing. I question the number of channels the codec team needs. See below. > Below is a "codec DMA needs" FAQ that a TI codec programmer supplied me. > > Regards, > > - Rob > > 1. Why does codec need so many EDMA channels ? > Ans: DM365 HDVICP architecture needs data to be transferred from one > buffer to another for its encode/decode operation. The src/destination can > be DDR, ARM TCM or HDVICP/VICP internal buffers. EDMA is used for doing > these data transfers. The nature of the HDVICP architecture requires > multiple transfers to happen in parallel which mandates need to as many as > 36 channels. Going forward in future codec release, there are further > optimization planned which will require even more channels. Viz, in DM375, > codecs plan to use as many as 50 channels. I'm not sure I agree with their implementation for a several reasons: 1) The number of simultaneous transfers is limited to the number of Transfer Controllers (TCs), generally 2-4 on a device. The channels are more like logical channels, but ultimately they map to a TC and are queued in the Channel Controller (CC) until the TC becomes free again. 2) How does the codec know (or even request) which TCs a given EDMA channel gets mapped to? It seems like the channels granted to the codec could potentially all map to the exact same TC in which case NONE of the transfers would actually happen in parallel. Instead they would all be queued by the CC. 3) QDMA exists solely for the purpose of memory to memory transfers! > > 2 Can there be any other alternative to do memory transfer? > Ans: CPU copy is very slow and needs CPU intervention. EDMA is the only > option available. Well, QDMA is also an option. There are fewer QDMA channels so a software queue would be necessary. The QDMA supports "linked lists" of transfer so the software queue could be optimized to create a linked list of transfers. For example, say one transfer is in progress and then 3 more events are queued. When the software goes to setup the next transfer it could create a linked list for all 3 transfers. This would use 1 QDMA channel and 3 parameter RAM entries. > > 3. If codec blocks so many channels, can it effect application use case ? > Ans: DM365/DM375 is planned for wide variety of application. Hence it has > got so many peripherals and EDMA events associated. In a given use > case/application, all the EDMA events does not get used. Hence ample EDMA > channels are available for other use. For example, in a video record > application, audio will need 1 edma event, SPI may need 1/2, SDCRD may > need 1. Out of 64, almost 60 channels would be free. Each audio channel would have 2 events: transmit and receive. Often you might have two audio interfaces, e.g. an audio codec (AIC33) plus Bluetooth (BRF6350). Hence you'd have 4 events for that. Plus you have events for GPIO, SPI, I2C, SD Card, etc. Some devices like OMAP-L137 have only 32 channels to begin with, so I don't think reckless allocation of channels is a good thing. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
