From kapil.pendse at gmail.com Mon Mar 1 03:24:38 2010 From: kapil.pendse at gmail.com (Kapil Pendse) Date: Mon, 1 Mar 2010 14:54:38 +0530 Subject: MVL4.0.1 kernel compiled with MVL5.0 toolchain Message-ID: <65b6d8ff1003010124n1644066p498c384158964a09@mail.gmail.com> Hello, I have compiled the MVL4.0.1 kernel (2.6.10) with the tool chain of MVL5.0 (gcc version 4.2.0). I am trying to add a driver for RaLink USB WiFi module RT2070 to this kernel. The driver is compiled as a kernel module rt2070.ko. I used the same MVL5.0 toolchain to compile this driver rt2070.ko. Now the problem is when I try to load the module using insmod, I get the following error: root at 192.168.0.4:/opt# insmod rt2070sta.ko rt2070sta: no version for "struct_module" found: kernel tainted. rt2070sta: version magic '2.6.10_mvl401 preempt ARMv5 gcc-4.2' should be '2.6.10_mvl401 preempt ARMv5 gcc-3.4' insmod: error inserting 'rt2070sta.ko': -1 Invalid module format I don't understand why this error even though I have used same toolchain to compile the kernel as well as the driver. Can someone kindly help me? Warm regards, Kapil -- "The Power to Imagine, is The Power to Create!" -TTux -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.debief at renilg.com Mon Mar 1 03:32:46 2010 From: eric.debief at renilg.com (eric Debief) Date: Mon, 1 Mar 2010 10:32:46 +0100 Subject: MVL4.0.1 kernel compiled with MVL5.0 toolchain In-Reply-To: <65b6d8ff1003010124n1644066p498c384158964a09@mail.gmail.com> References: <65b6d8ff1003010124n1644066p498c384158964a09@mail.gmail.com> Message-ID: <201003011032.46982.eric.debief@renilg.com> Hi, This is a matter of kernel versions. The former is the 2.6.10 kernel compiled with the MVL 5.0 toolchain (the one you've compiled) and the latter has been compiled with the MVL 4.0 toolchain. Check the value of KERNELDIR in your module makefile. It should point to the MV5.0 compiled kernel. Hope this help. Regards, Eric. Le Monday 01 March 2010 10:24:38 Kapil Pendse, vous avez ?crit?: > Hello, > > I have compiled the MVL4.0.1 kernel (2.6.10) with the tool chain of MVL5.0 > (gcc version 4.2.0). I am trying to add a driver for RaLink USB WiFi module > RT2070 to this kernel. The driver is compiled as a kernel module rt2070.ko. > I used the same MVL5.0 toolchain to compile this driver rt2070.ko. > > Now the problem is when I try to load the module using insmod, I get the > following error: > > root at 192.168.0.4:/opt# insmod rt2070sta.ko > rt2070sta: no version for "struct_module" found: kernel tainted. > rt2070sta: version magic '2.6.10_mvl401 preempt ARMv5 gcc-4.2' should be > '2.6.10_mvl401 preempt ARMv5 gcc-3.4' > insmod: error inserting 'rt2070sta.ko': -1 Invalid module format > > I don't understand why this error even though I have used same toolchain to > compile the kernel as well as the driver. Can someone kindly help me? > > Warm regards, > Kapil From deepaks at hcl.in Mon Mar 1 04:20:13 2010 From: deepaks at hcl.in (Deepak Shankar-ERS,HCLTech.) Date: Mon, 1 Mar 2010 15:50:13 +0530 Subject: Aieee Killing Interrupt handler after 2 days. Message-ID: Hello all, I have a system running based on mvl4.0.1-2.6.10 Linux in dm355 davinci. Now on a sporadic basis after 2 days or so, if I leave the sytem, the system crashes(Aieee) throwing the following crashdump. I could not make much out of the log, I have looked into my application and it seems to be fine. If any of you have faced a similar problem, could you please help me in finding out what is the problem. Please provide me any inputs in this regard. Start of dump: ************************************************************************************************************** Internal error: Oops - undefined instruction: 0 [#1] Modules linked in: g_zero GPIOd cmemk PMd dm350mmap CPU: 0 PC is at 0xc021f048 LR is at do_hrtimers_expire_timers+0x1cc/0x228 pc : [] lr : [] Not tainted sp : c01cfe58 ip : c01d11e8 fp : c01cfe7c r10: c01d11e8 r9 : c0214ce0 r8 : c021ff50 r7 : c021ddfc r6 : c021ddfc r5 : c021ff48 r4 : c01ce000 r3 : 00000000 r2 : c021ff48 r1 : c021ff48 r0 : 40000440 Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment kernel Control: 5317F Table: 855B8000 DAC: 00000017 Process swapper (pid: 0, stack limit = 0xc01ce1a0) Stack: (0xc01cfe58 to 0xc01d0000) fe40: c006435c c01ce000 fe60: 00000001 bf00b10c c021d7fc c01cfe98 c01cfe94 c01cfe80 c0064724 c00643ac fe80: 00000103 c01ce000 c01cfecc c01cfe98 c0054bf8 c00646bc c021ddec c021ddfc fea0: c01ce000 c021d7b4 c01ce000 00000103 00000001 c021d590 0000000a c021d560 fec0: c01cfef4 c01cfed0 c0050070 c0054abc c01ce000 00000000 c003e90c 00000002 fee0: c01ce000 c01cff60 c01cff0c c01cfef8 c005014c c005002c c01ce000 c01ce000 ff00: c01cff24 c01cff10 c0050304 c0050124 c01ce000 c01cff94 c01cff5c c01cff28 ff20: c00304c0 c00502c8 00000000 c5b184a0 c02182d0 c01cff94 e1048000 c003e90c ff40: 00000002 c01ce000 00000001 800276bc c01cffb4 c01cff60 c002e780 c00303b0 ff60: 00000000 60000093 c0217fa0 60000013 c01ce000 c003eee8 c02201c4 c0226ad8 ff80: 800276ec 41069265 800276bc c01cffb4 c01cffa8 c01cffa8 c003e90c c003ef64 ffa0: 60000013 ffffffff c01cffcc c01cffb8 c0031004 c003eef8 00000000 c021481c ffc0: c01cfffc c01cffd0 c00087d8 c0030fc4 c0008304 00000000 00000000 c02174d8 ffe0: 00000000 00053175 c02174bc c01d0f10 00000000 c01d0000 8000809c c0008660 Backtrace: [] (do_hrtimers_expire_timers+0x0/0x228) from [] (do_high_res_timer+0x78/0xa0) r8 = C01CFE98 r7 = C021D7FC r6 = BF00B10C r5 = 00000001 r4 = C01CE000 [] (do_high_res_timer+0x0/0xa0) from [] (run_timer_softirq+0x14c/0x278) r5 = C01CE000 r4 = 00000103 [] (run_timer_softirq+0x0/0x278) from [] (___do_softirq+0x54/0xf8) [] (___do_softirq+0x0/0xf8) from [] (__do_softirq+0x38/0x58) [] (__do_softirq+0x0/0x58) from [] (irq_exit+0x4c/0x60) r5 = C01CE000 r4 = C01CE000 [] (irq_exit+0x0/0x60) from [] (asm_do_IRQ+0x120/0x138) r4 = C01CFF94 [] (asm_do_IRQ+0x0/0x138) from [] (__irq_svc+0x40/0x6c) [] (davinci_pm_idle+0x0/0x84) from [] (cpu_idle+0x50/0x88) [] (cpu_idle+0x0/0x88) from [] (start_kernel+0x188/0x1cc) r5 = C021481C r4 = 00000000 [] (start_kernel+0x0/0x1cc) from [<8000809c>] (0x8000809c) Code: c02fa5e0 c02fade0 c02fb5e0 00000009 (fffffed4) <0>Kernel panic - not syncing: Aiee, killing interrupt handler! ************************************************************************************************************** End of dump: Cheers, Deepak Shankar V DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- From deepaks at hcl.in Mon Mar 1 04:49:26 2010 From: deepaks at hcl.in (Deepak Shankar-ERS,HCLTech.) Date: Mon, 1 Mar 2010 16:19:26 +0530 Subject: Aieee Killing Interrupt handler after 2 days. Message-ID: Hello all, I have a system running based on mvl4.0.1-2.6.10 Linux in dm355 davinci. Now on a sporadic basis after 2 days or so, if I leave the sytem, the system crashes(Aieee) throwing the following crashdump. I could not make much out of the log, I have looked into my application and it seems to be fine. If any of you have faced a similar problem, could you please help me in finding out what is the problem. Please provide me any inputs in this regard. Start of dump: ************************************************************************************************************** Internal error: Oops - undefined instruction: 0 [#1] Modules linked in: g_zero GPIOd cmemk PMd dm350mmap CPU: 0 PC is at 0xc021f048 LR is at do_hrtimers_expire_timers+0x1cc/0x228 pc : [] lr : [] Not tainted sp : c01cfe58 ip : c01d11e8 fp : c01cfe7c r10: c01d11e8 r9 : c0214ce0 r8 : c021ff50 r7 : c021ddfc r6 : c021ddfc r5 : c021ff48 r4 : c01ce000 r3 : 00000000 r2 : c021ff48 r1 : c021ff48 r0 : 40000440 Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment kernel Control: 5317F Table: 855B8000 DAC: 00000017 Process swapper (pid: 0, stack limit = 0xc01ce1a0) Stack: (0xc01cfe58 to 0xc01d0000) fe40: c006435c c01ce000 fe60: 00000001 bf00b10c c021d7fc c01cfe98 c01cfe94 c01cfe80 c0064724 c00643ac fe80: 00000103 c01ce000 c01cfecc c01cfe98 c0054bf8 c00646bc c021ddec c021ddfc fea0: c01ce000 c021d7b4 c01ce000 00000103 00000001 c021d590 0000000a c021d560 fec0: c01cfef4 c01cfed0 c0050070 c0054abc c01ce000 00000000 c003e90c 00000002 fee0: c01ce000 c01cff60 c01cff0c c01cfef8 c005014c c005002c c01ce000 c01ce000 ff00: c01cff24 c01cff10 c0050304 c0050124 c01ce000 c01cff94 c01cff5c c01cff28 ff20: c00304c0 c00502c8 00000000 c5b184a0 c02182d0 c01cff94 e1048000 c003e90c ff40: 00000002 c01ce000 00000001 800276bc c01cffb4 c01cff60 c002e780 c00303b0 ff60: 00000000 60000093 c0217fa0 60000013 c01ce000 c003eee8 c02201c4 c0226ad8 ff80: 800276ec 41069265 800276bc c01cffb4 c01cffa8 c01cffa8 c003e90c c003ef64 ffa0: 60000013 ffffffff c01cffcc c01cffb8 c0031004 c003eef8 00000000 c021481c ffc0: c01cfffc c01cffd0 c00087d8 c0030fc4 c0008304 00000000 00000000 c02174d8 ffe0: 00000000 00053175 c02174bc c01d0f10 00000000 c01d0000 8000809c c0008660 Backtrace: [] (do_hrtimers_expire_timers+0x0/0x228) from [] (do_high_res_timer+0x78/0xa0) r8 = C01CFE98 r7 = C021D7FC r6 = BF00B10C r5 = 00000001 r4 = C01CE000 [] (do_high_res_timer+0x0/0xa0) from [] (run_timer_softirq+0x14c/0x278) r5 = C01CE000 r4 = 00000103 [] (run_timer_softirq+0x0/0x278) from [] (___do_softirq+0x54/0xf8) [] (___do_softirq+0x0/0xf8) from [] (__do_softirq+0x38/0x58) [] (__do_softirq+0x0/0x58) from [] (irq_exit+0x4c/0x60) r5 = C01CE000 r4 = C01CE000 [] (irq_exit+0x0/0x60) from [] (asm_do_IRQ+0x120/0x138) r4 = C01CFF94 [] (asm_do_IRQ+0x0/0x138) from [] (__irq_svc+0x40/0x6c) [] (davinci_pm_idle+0x0/0x84) from [] (cpu_idle+0x50/0x88) [] (cpu_idle+0x0/0x88) from [] (start_kernel+0x188/0x1cc) r5 = C021481C r4 = 00000000 [] (start_kernel+0x0/0x1cc) from [<8000809c>] (0x8000809c) Code: c02fa5e0 c02fade0 c02fb5e0 00000009 (fffffed4) <0>Kernel panic - not syncing: Aiee, killing interrupt handler! ************************************************************************************************************** End of dump: Cheers, Deepak Shankar V DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- From khilman at deeprootsystems.com Mon Mar 1 12:28:02 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Mon, 01 Mar 2010 10:28:02 -0800 Subject: [GIT PULL] davinci platform updates for 2.6.34 Message-ID: <87d3zngaml.fsf@deeprootsystems.com> Linus, Please pull the following changes for the TI davinci platform. Note that the drivers/net changes are Acked by David Miller but we agreed to merge them via my tree to keep them along with other relevant platform changes for the davinci driver. Also, the last 5 or so patches were rebased today from what has been in linux-next, but it was only to fixup one changelog and add a missing signoff. Thanks, Kevin The following changes since commit abe94c756c08d50566c09a65b9c7fe72f83071c5: Linus Torvalds (1): Linux 2.6.33-rc6 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git davinci-for-linus Chaithrika U S (1): davinci: clock: Check CLK_PSC flag before disabling PSC Kevin Hilman (2): davinci: clkdev cleanup: remove clk_lookup wrapper, use clkdev_add_table() davinci: dm646x: CDCE clocks: davinci_clk converted to clk_lookup Miguel Aguilar (1): DaVinci: DM365: Voice codec support for the DM365 SoC Murali Karicheri (1): DaVinci - Adding platform & board changes for vpfe capture on DM365 Nageswari Srinivasan (2): davinci: add support for CDCE949 clock synthesizer davinci: add CDCE949 support on DM6467 EVM Philby John (1): Add SDA and SCL pin numbers to i2c platform data Sandeep Paulraj (5): DaVinci: DM365: Changing default queue for DM365. DaVinci: SPI: Adding header file for SPI support. DaVinci DM355: Modifications to DM355 SPI support DaVinci DM365: Adding DM365 SPI support DaVinci DM365: Adding support for SPI EEPROM Sekhar Nori (17): davinci: da8xx/omapl1: add support for the second sysconfig module davinci: move PLL wait time values to clock.h davinci: move DDR2 controller defines to memory.h davinci: move PSC register definitions from psc.c to psc.h davinci: make it possible to include clock.h and psc.h in assembly code davinci: cpuidle: move mapping of DDR2 controller registers out of driver davinci: da850/omap-l138: unlock PLL registers during init davinci: da850/omap-l138: create static map for SRAM davinci: explain CLOCK_TICK_RATE of 27MHz in include/mach/timex.h davinci: board-dm646x-evm.c: arrange related code together davinci: add support for DM6467T EVM davinci: make /proc/davinci_clocks display multi-rooted clock tree davinci: move /proc/davinci_clocks to debugfs davinci: add power management support davinci: da850/omap-l138: add support for SoC suspend davinci: da850/omap-l138 EVM: register for suspend support davinci: clock: let clk->set_rate function sleep Sriramakrishnan (3): TI Davinci EMAC : Re-use driver for other platforms. TI Davinci EMAC : add platform specific interrupt enable/disable logic. TI Davinci EMAC : Abstract Buffer address translation logic. Sudhakar Rajashekhara (7): davinci: da850/omap-l138: Modify NOR partition info davinci: da850/omap-l138: Enable 4-bit ecc davinci: Correct return value of edma_alloc_channel api davinci: Keep count of channel controllers on a platform davinci: Fix edma_alloc_channel api for EDMA_CHANNEL_ANY case davinci: build list of unused EDMA events dynamically davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 arch/arm/mach-davinci/Kconfig | 4 + arch/arm/mach-davinci/Makefile | 3 +- arch/arm/mach-davinci/board-da830-evm.c | 4 +- arch/arm/mach-davinci/board-da850-evm.c | 34 +++- arch/arm/mach-davinci/board-dm355-evm.c | 2 + arch/arm/mach-davinci/board-dm365-evm.c | 94 +++++++ arch/arm/mach-davinci/board-dm644x-evm.c | 2 + arch/arm/mach-davinci/board-dm646x-evm.c | 143 +++++++--- arch/arm/mach-davinci/cdce949.c | 293 ++++++++++++++++++++ arch/arm/mach-davinci/clock.c | 93 +++---- arch/arm/mach-davinci/clock.h | 45 ++- arch/arm/mach-davinci/common.c | 2 +- arch/arm/mach-davinci/cpuidle.c | 38 +--- arch/arm/mach-davinci/da830.c | 10 +- arch/arm/mach-davinci/da850.c | 90 +++++- arch/arm/mach-davinci/devices-da8xx.c | 146 +++++++++- arch/arm/mach-davinci/dm355.c | 49 ++-- arch/arm/mach-davinci/dm365.c | 213 ++++++++++++++- arch/arm/mach-davinci/dm644x.c | 12 +- arch/arm/mach-davinci/dm646x.c | 14 +- arch/arm/mach-davinci/dma.c | 67 ++++- arch/arm/mach-davinci/include/mach/cdce949.h | 19 ++ arch/arm/mach-davinci/include/mach/common.h | 2 +- arch/arm/mach-davinci/include/mach/cpuidle.h | 1 + arch/arm/mach-davinci/include/mach/da8xx.h | 18 +- arch/arm/mach-davinci/include/mach/dm365.h | 11 +- arch/arm/mach-davinci/include/mach/dm644x.h | 2 +- arch/arm/mach-davinci/include/mach/dm646x.h | 4 +- arch/arm/mach-davinci/include/mach/edma.h | 2 - arch/arm/mach-davinci/include/mach/i2c.h | 2 + arch/arm/mach-davinci/include/mach/memory.h | 5 + arch/arm/mach-davinci/include/mach/mux.h | 3 + arch/arm/mach-davinci/include/mach/pm.h | 54 ++++ arch/arm/mach-davinci/include/mach/psc.h | 15 + arch/arm/mach-davinci/include/mach/spi.h | 44 +++ arch/arm/mach-davinci/include/mach/timex.h | 7 +- arch/arm/mach-davinci/pm.c | 158 +++++++++++ arch/arm/mach-davinci/psc.c | 11 - arch/arm/mach-davinci/sleep.S | 224 +++++++++++++++ drivers/net/Kconfig | 2 +- drivers/net/davinci_emac.c | 55 +++-- .../mach/emac.h => include/linux/davinci_emac.h | 7 +- 42 files changed, 1708 insertions(+), 296 deletions(-) create mode 100644 arch/arm/mach-davinci/cdce949.c create mode 100644 arch/arm/mach-davinci/include/mach/cdce949.h create mode 100644 arch/arm/mach-davinci/include/mach/pm.h create mode 100644 arch/arm/mach-davinci/include/mach/spi.h create mode 100644 arch/arm/mach-davinci/pm.c create mode 100644 arch/arm/mach-davinci/sleep.S rename arch/arm/mach-davinci/include/mach/emac.h => include/linux/davinci_emac.h (83%) From m-karicheri2 at ti.com Mon Mar 1 14:02:48 2010 From: m-karicheri2 at ti.com (Karicheri, Muralidharan) Date: Mon, 1 Mar 2010 14:02:48 -0600 Subject: [GIT PULL] davinci platform updates for 2.6.34 In-Reply-To: <87d3zngaml.fsf@deeprootsystems.com> References: <87d3zngaml.fsf@deeprootsystems.com> Message-ID: Kevin, The arch part (shown below) of the vpfe capture driver on DM365 is already part of Mauro's request to Linus as we had agreed before. So please drop it from your request. Murali Karicheri (1): DaVinci - Adding platform & board changes for vpfe capture on DM365 Here is the request from Mauro for 2.6.33.rc1 that has the above arch part. http://www.mail-archive.com/linux-media at vger.kernel.org/msg16109.html Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-karicheri2 at ti.com >-----Original Message----- >From: davinci-linux-open-source-bounces at linux.davincidsp.com >[mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf >Of Kevin Hilman >Sent: Monday, March 01, 2010 1:28 PM >To: Linus Torvalds >Cc: davinci-linux-open-source at linux.davincidsp.com; linux- >kernel at vger.kernel.org >Subject: [GIT PULL] davinci platform updates for 2.6.34 > >Linus, > >Please pull the following changes for the TI davinci platform. > >Note that the drivers/net changes are Acked by David Miller but we >agreed to merge them via my tree to keep them along with other >relevant platform changes for the davinci driver. > >Also, the last 5 or so patches were rebased today from what has been >in linux-next, but it was only to fixup one changelog and add a missing >signoff. > >Thanks, > >Kevin > >The following changes since commit >abe94c756c08d50566c09a65b9c7fe72f83071c5: > Linus Torvalds (1): > Linux 2.6.33-rc6 > >are available in the git repository at: > > ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux- >davinci.git davinci-for-linus > >Chaithrika U S (1): > davinci: clock: Check CLK_PSC flag before disabling PSC > >Kevin Hilman (2): > davinci: clkdev cleanup: remove clk_lookup wrapper, use >clkdev_add_table() > davinci: dm646x: CDCE clocks: davinci_clk converted to clk_lookup > >Miguel Aguilar (1): > DaVinci: DM365: Voice codec support for the DM365 SoC > >Murali Karicheri (1): > DaVinci - Adding platform & board changes for vpfe capture on DM365 > >Nageswari Srinivasan (2): > davinci: add support for CDCE949 clock synthesizer > davinci: add CDCE949 support on DM6467 EVM > >Philby John (1): > Add SDA and SCL pin numbers to i2c platform data > >Sandeep Paulraj (5): > DaVinci: DM365: Changing default queue for DM365. > DaVinci: SPI: Adding header file for SPI support. > DaVinci DM355: Modifications to DM355 SPI support > DaVinci DM365: Adding DM365 SPI support > DaVinci DM365: Adding support for SPI EEPROM > >Sekhar Nori (17): > davinci: da8xx/omapl1: add support for the second sysconfig module > davinci: move PLL wait time values to clock.h > davinci: move DDR2 controller defines to memory.h > davinci: move PSC register definitions from psc.c to psc.h > davinci: make it possible to include clock.h and psc.h in assembly >code > davinci: cpuidle: move mapping of DDR2 controller registers out of >driver > davinci: da850/omap-l138: unlock PLL registers during init > davinci: da850/omap-l138: create static map for SRAM > davinci: explain CLOCK_TICK_RATE of 27MHz in include/mach/timex.h > davinci: board-dm646x-evm.c: arrange related code together > davinci: add support for DM6467T EVM > davinci: make /proc/davinci_clocks display multi-rooted clock tree > davinci: move /proc/davinci_clocks to debugfs > davinci: add power management support > davinci: da850/omap-l138: add support for SoC suspend > davinci: da850/omap-l138 EVM: register for suspend support > davinci: clock: let clk->set_rate function sleep > >Sriramakrishnan (3): > TI Davinci EMAC : Re-use driver for other platforms. > TI Davinci EMAC : add platform specific interrupt enable/disable >logic. > TI Davinci EMAC : Abstract Buffer address translation logic. > >Sudhakar Rajashekhara (7): > davinci: da850/omap-l138: Modify NOR partition info > davinci: da850/omap-l138: Enable 4-bit ecc > davinci: Correct return value of edma_alloc_channel api > davinci: Keep count of channel controllers on a platform > davinci: Fix edma_alloc_channel api for EDMA_CHANNEL_ANY case > davinci: build list of unused EDMA events dynamically > davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 > > arch/arm/mach-davinci/Kconfig | 4 + > arch/arm/mach-davinci/Makefile | 3 +- > arch/arm/mach-davinci/board-da830-evm.c | 4 +- > arch/arm/mach-davinci/board-da850-evm.c | 34 +++- > arch/arm/mach-davinci/board-dm355-evm.c | 2 + > arch/arm/mach-davinci/board-dm365-evm.c | 94 +++++++ > arch/arm/mach-davinci/board-dm644x-evm.c | 2 + > arch/arm/mach-davinci/board-dm646x-evm.c | 143 +++++++--- > arch/arm/mach-davinci/cdce949.c | 293 >++++++++++++++++++++ > arch/arm/mach-davinci/clock.c | 93 +++---- > arch/arm/mach-davinci/clock.h | 45 ++- > arch/arm/mach-davinci/common.c | 2 +- > arch/arm/mach-davinci/cpuidle.c | 38 +--- > arch/arm/mach-davinci/da830.c | 10 +- > arch/arm/mach-davinci/da850.c | 90 +++++- > arch/arm/mach-davinci/devices-da8xx.c | 146 +++++++++- > arch/arm/mach-davinci/dm355.c | 49 ++-- > arch/arm/mach-davinci/dm365.c | 213 ++++++++++++++- > arch/arm/mach-davinci/dm644x.c | 12 +- > arch/arm/mach-davinci/dm646x.c | 14 +- > arch/arm/mach-davinci/dma.c | 67 ++++- > arch/arm/mach-davinci/include/mach/cdce949.h | 19 ++ > arch/arm/mach-davinci/include/mach/common.h | 2 +- > arch/arm/mach-davinci/include/mach/cpuidle.h | 1 + > arch/arm/mach-davinci/include/mach/da8xx.h | 18 +- > arch/arm/mach-davinci/include/mach/dm365.h | 11 +- > arch/arm/mach-davinci/include/mach/dm644x.h | 2 +- > arch/arm/mach-davinci/include/mach/dm646x.h | 4 +- > arch/arm/mach-davinci/include/mach/edma.h | 2 - > arch/arm/mach-davinci/include/mach/i2c.h | 2 + > arch/arm/mach-davinci/include/mach/memory.h | 5 + > arch/arm/mach-davinci/include/mach/mux.h | 3 + > arch/arm/mach-davinci/include/mach/pm.h | 54 ++++ > arch/arm/mach-davinci/include/mach/psc.h | 15 + > arch/arm/mach-davinci/include/mach/spi.h | 44 +++ > arch/arm/mach-davinci/include/mach/timex.h | 7 +- > arch/arm/mach-davinci/pm.c | 158 +++++++++++ > arch/arm/mach-davinci/psc.c | 11 - > arch/arm/mach-davinci/sleep.S | 224 +++++++++++++++ > drivers/net/Kconfig | 2 +- > drivers/net/davinci_emac.c | 55 +++-- > .../mach/emac.h => include/linux/davinci_emac.h | 7 +- > 42 files changed, 1708 insertions(+), 296 deletions(-) > create mode 100644 arch/arm/mach-davinci/cdce949.c > create mode 100644 arch/arm/mach-davinci/include/mach/cdce949.h > create mode 100644 arch/arm/mach-davinci/include/mach/pm.h > create mode 100644 arch/arm/mach-davinci/include/mach/spi.h > create mode 100644 arch/arm/mach-davinci/pm.c > create mode 100644 arch/arm/mach-davinci/sleep.S > rename arch/arm/mach-davinci/include/mach/emac.h => >include/linux/davinci_emac.h (83%) >_______________________________________________ >Davinci-linux-open-source mailing list >Davinci-linux-open-source at linux.davincidsp.com >http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source From khilman at deeprootsystems.com Mon Mar 1 15:03:59 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Mon, 01 Mar 2010 13:03:59 -0800 Subject: [GIT PULL] davinci platform updates for 2.6.34 In-Reply-To: (Muralidharan Karicheri's message of "Mon\, 1 Mar 2010 14\:02\:48 -0600") References: <87d3zngaml.fsf@deeprootsystems.com> Message-ID: <87vddfbvpc.fsf@deeprootsystems.com> "Karicheri, Muralidharan" writes: > The arch part (shown below) of the vpfe capture driver on DM365 is > already part of Mauro's request to Linus as we had agreed before. So > please drop it from your request. Murali, This was intentional, and will not cause any problems since we sorted this out for linux-next. It's in my tree also to address dependencies and avoid merge conflicts in linux-next. Linus has already merged Mauro's tree, so if/when he merges mine, git will figure it out and "do the right thing." Kevin > Murali Karicheri (1): > DaVinci - Adding platform & board changes for vpfe capture on DM365 > > > Here is the request from Mauro for 2.6.33.rc1 that has the above arch part. > > http://www.mail-archive.com/linux-media at vger.kernel.org/msg16109.html > > > Murali Karicheri > Software Design Engineer > Texas Instruments Inc. > Germantown, MD 20874 > phone: 301-407-9583 > email: m-karicheri2 at ti.com > >>-----Original Message----- >>From: davinci-linux-open-source-bounces at linux.davincidsp.com >>[mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf >>Of Kevin Hilman >>Sent: Monday, March 01, 2010 1:28 PM >>To: Linus Torvalds >>Cc: davinci-linux-open-source at linux.davincidsp.com; linux- >>kernel at vger.kernel.org >>Subject: [GIT PULL] davinci platform updates for 2.6.34 >> >>Linus, >> >>Please pull the following changes for the TI davinci platform. >> >>Note that the drivers/net changes are Acked by David Miller but we >>agreed to merge them via my tree to keep them along with other >>relevant platform changes for the davinci driver. >> >>Also, the last 5 or so patches were rebased today from what has been >>in linux-next, but it was only to fixup one changelog and add a missing >>signoff. >> >>Thanks, >> >>Kevin >> >>The following changes since commit >>abe94c756c08d50566c09a65b9c7fe72f83071c5: >> Linus Torvalds (1): >> Linux 2.6.33-rc6 >> >>are available in the git repository at: >> >> ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux- >>davinci.git davinci-for-linus >> >>Chaithrika U S (1): >> davinci: clock: Check CLK_PSC flag before disabling PSC >> >>Kevin Hilman (2): >> davinci: clkdev cleanup: remove clk_lookup wrapper, use >>clkdev_add_table() >> davinci: dm646x: CDCE clocks: davinci_clk converted to clk_lookup >> >>Miguel Aguilar (1): >> DaVinci: DM365: Voice codec support for the DM365 SoC >> >>Murali Karicheri (1): >> DaVinci - Adding platform & board changes for vpfe capture on DM365 >> >>Nageswari Srinivasan (2): >> davinci: add support for CDCE949 clock synthesizer >> davinci: add CDCE949 support on DM6467 EVM >> >>Philby John (1): >> Add SDA and SCL pin numbers to i2c platform data >> >>Sandeep Paulraj (5): >> DaVinci: DM365: Changing default queue for DM365. >> DaVinci: SPI: Adding header file for SPI support. >> DaVinci DM355: Modifications to DM355 SPI support >> DaVinci DM365: Adding DM365 SPI support >> DaVinci DM365: Adding support for SPI EEPROM >> >>Sekhar Nori (17): >> davinci: da8xx/omapl1: add support for the second sysconfig module >> davinci: move PLL wait time values to clock.h >> davinci: move DDR2 controller defines to memory.h >> davinci: move PSC register definitions from psc.c to psc.h >> davinci: make it possible to include clock.h and psc.h in assembly >>code >> davinci: cpuidle: move mapping of DDR2 controller registers out of >>driver >> davinci: da850/omap-l138: unlock PLL registers during init >> davinci: da850/omap-l138: create static map for SRAM >> davinci: explain CLOCK_TICK_RATE of 27MHz in include/mach/timex.h >> davinci: board-dm646x-evm.c: arrange related code together >> davinci: add support for DM6467T EVM >> davinci: make /proc/davinci_clocks display multi-rooted clock tree >> davinci: move /proc/davinci_clocks to debugfs >> davinci: add power management support >> davinci: da850/omap-l138: add support for SoC suspend >> davinci: da850/omap-l138 EVM: register for suspend support >> davinci: clock: let clk->set_rate function sleep >> >>Sriramakrishnan (3): >> TI Davinci EMAC : Re-use driver for other platforms. >> TI Davinci EMAC : add platform specific interrupt enable/disable >>logic. >> TI Davinci EMAC : Abstract Buffer address translation logic. >> >>Sudhakar Rajashekhara (7): >> davinci: da850/omap-l138: Modify NOR partition info >> davinci: da850/omap-l138: Enable 4-bit ecc >> davinci: Correct return value of edma_alloc_channel api >> davinci: Keep count of channel controllers on a platform >> davinci: Fix edma_alloc_channel api for EDMA_CHANNEL_ANY case >> davinci: build list of unused EDMA events dynamically >> davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 >> >> arch/arm/mach-davinci/Kconfig | 4 + >> arch/arm/mach-davinci/Makefile | 3 +- >> arch/arm/mach-davinci/board-da830-evm.c | 4 +- >> arch/arm/mach-davinci/board-da850-evm.c | 34 +++- >> arch/arm/mach-davinci/board-dm355-evm.c | 2 + >> arch/arm/mach-davinci/board-dm365-evm.c | 94 +++++++ >> arch/arm/mach-davinci/board-dm644x-evm.c | 2 + >> arch/arm/mach-davinci/board-dm646x-evm.c | 143 +++++++--- >> arch/arm/mach-davinci/cdce949.c | 293 >>++++++++++++++++++++ >> arch/arm/mach-davinci/clock.c | 93 +++---- >> arch/arm/mach-davinci/clock.h | 45 ++- >> arch/arm/mach-davinci/common.c | 2 +- >> arch/arm/mach-davinci/cpuidle.c | 38 +--- >> arch/arm/mach-davinci/da830.c | 10 +- >> arch/arm/mach-davinci/da850.c | 90 +++++- >> arch/arm/mach-davinci/devices-da8xx.c | 146 +++++++++- >> arch/arm/mach-davinci/dm355.c | 49 ++-- >> arch/arm/mach-davinci/dm365.c | 213 ++++++++++++++- >> arch/arm/mach-davinci/dm644x.c | 12 +- >> arch/arm/mach-davinci/dm646x.c | 14 +- >> arch/arm/mach-davinci/dma.c | 67 ++++- >> arch/arm/mach-davinci/include/mach/cdce949.h | 19 ++ >> arch/arm/mach-davinci/include/mach/common.h | 2 +- >> arch/arm/mach-davinci/include/mach/cpuidle.h | 1 + >> arch/arm/mach-davinci/include/mach/da8xx.h | 18 +- >> arch/arm/mach-davinci/include/mach/dm365.h | 11 +- >> arch/arm/mach-davinci/include/mach/dm644x.h | 2 +- >> arch/arm/mach-davinci/include/mach/dm646x.h | 4 +- >> arch/arm/mach-davinci/include/mach/edma.h | 2 - >> arch/arm/mach-davinci/include/mach/i2c.h | 2 + >> arch/arm/mach-davinci/include/mach/memory.h | 5 + >> arch/arm/mach-davinci/include/mach/mux.h | 3 + >> arch/arm/mach-davinci/include/mach/pm.h | 54 ++++ >> arch/arm/mach-davinci/include/mach/psc.h | 15 + >> arch/arm/mach-davinci/include/mach/spi.h | 44 +++ >> arch/arm/mach-davinci/include/mach/timex.h | 7 +- >> arch/arm/mach-davinci/pm.c | 158 +++++++++++ >> arch/arm/mach-davinci/psc.c | 11 - >> arch/arm/mach-davinci/sleep.S | 224 +++++++++++++++ >> drivers/net/Kconfig | 2 +- >> drivers/net/davinci_emac.c | 55 +++-- >> .../mach/emac.h => include/linux/davinci_emac.h | 7 +- >> 42 files changed, 1708 insertions(+), 296 deletions(-) >> create mode 100644 arch/arm/mach-davinci/cdce949.c >> create mode 100644 arch/arm/mach-davinci/include/mach/cdce949.h >> create mode 100644 arch/arm/mach-davinci/include/mach/pm.h >> create mode 100644 arch/arm/mach-davinci/include/mach/spi.h >> create mode 100644 arch/arm/mach-davinci/pm.c >> create mode 100644 arch/arm/mach-davinci/sleep.S >> rename arch/arm/mach-davinci/include/mach/emac.h => >>include/linux/davinci_emac.h (83%) >>_______________________________________________ >>Davinci-linux-open-source mailing list >>Davinci-linux-open-source at linux.davincidsp.com >>http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source From m-karicheri2 at ti.com Mon Mar 1 15:10:54 2010 From: m-karicheri2 at ti.com (Karicheri, Muralidharan) Date: Mon, 1 Mar 2010 15:10:54 -0600 Subject: [GIT PULL] davinci platform updates for 2.6.34 In-Reply-To: <87vddfbvpc.fsf@deeprootsystems.com> References: <87d3zngaml.fsf@deeprootsystems.com> <87vddfbvpc.fsf@deeprootsystems.com> Message-ID: Kevin, Just want to alert you in case it was not intentional. Good to know that there are no issues. Regards, Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-karicheri2 at ti.com >-----Original Message----- >From: Kevin Hilman [mailto:khilman at deeprootsystems.com] >Sent: Monday, March 01, 2010 4:04 PM >To: Karicheri, Muralidharan >Cc: davinci-linux-open-source at linux.davincidsp.com; linux- >kernel at vger.kernel.org >Subject: Re: [GIT PULL] davinci platform updates for 2.6.34 > >"Karicheri, Muralidharan" writes: > >> The arch part (shown below) of the vpfe capture driver on DM365 is >> already part of Mauro's request to Linus as we had agreed before. So >> please drop it from your request. > >Murali, > >This was intentional, and will not cause any problems since we sorted >this out for linux-next. It's in my tree also to address dependencies >and avoid merge conflicts in linux-next. > >Linus has already merged Mauro's tree, so if/when he merges mine, git >will figure it out and "do the right thing." > >Kevin > > >> Murali Karicheri (1): >> DaVinci - Adding platform & board changes for vpfe capture on DM365 >> >> >> Here is the request from Mauro for 2.6.33.rc1 that has the above arch >part. >> >> http://www.mail-archive.com/linux-media at vger.kernel.org/msg16109.html >> >> >> Murali Karicheri >> Software Design Engineer >> Texas Instruments Inc. >> Germantown, MD 20874 >> phone: 301-407-9583 >> email: m-karicheri2 at ti.com >> >>>-----Original Message----- >>>From: davinci-linux-open-source-bounces at linux.davincidsp.com >>>[mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf >>>Of Kevin Hilman >>>Sent: Monday, March 01, 2010 1:28 PM >>>To: Linus Torvalds >>>Cc: davinci-linux-open-source at linux.davincidsp.com; linux- >>>kernel at vger.kernel.org >>>Subject: [GIT PULL] davinci platform updates for 2.6.34 >>> >>>Linus, >>> >>>Please pull the following changes for the TI davinci platform. >>> >>>Note that the drivers/net changes are Acked by David Miller but we >>>agreed to merge them via my tree to keep them along with other >>>relevant platform changes for the davinci driver. >>> >>>Also, the last 5 or so patches were rebased today from what has been >>>in linux-next, but it was only to fixup one changelog and add a missing >>>signoff. >>> >>>Thanks, >>> >>>Kevin >>> >>>The following changes since commit >>>abe94c756c08d50566c09a65b9c7fe72f83071c5: >>> Linus Torvalds (1): >>> Linux 2.6.33-rc6 >>> >>>are available in the git repository at: >>> >>> ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux- >>>davinci.git davinci-for-linus >>> >>>Chaithrika U S (1): >>> davinci: clock: Check CLK_PSC flag before disabling PSC >>> >>>Kevin Hilman (2): >>> davinci: clkdev cleanup: remove clk_lookup wrapper, use >>>clkdev_add_table() >>> davinci: dm646x: CDCE clocks: davinci_clk converted to clk_lookup >>> >>>Miguel Aguilar (1): >>> DaVinci: DM365: Voice codec support for the DM365 SoC >>> >>>Murali Karicheri (1): >>> DaVinci - Adding platform & board changes for vpfe capture on DM365 >>> >>>Nageswari Srinivasan (2): >>> davinci: add support for CDCE949 clock synthesizer >>> davinci: add CDCE949 support on DM6467 EVM >>> >>>Philby John (1): >>> Add SDA and SCL pin numbers to i2c platform data >>> >>>Sandeep Paulraj (5): >>> DaVinci: DM365: Changing default queue for DM365. >>> DaVinci: SPI: Adding header file for SPI support. >>> DaVinci DM355: Modifications to DM355 SPI support >>> DaVinci DM365: Adding DM365 SPI support >>> DaVinci DM365: Adding support for SPI EEPROM >>> >>>Sekhar Nori (17): >>> davinci: da8xx/omapl1: add support for the second sysconfig module >>> davinci: move PLL wait time values to clock.h >>> davinci: move DDR2 controller defines to memory.h >>> davinci: move PSC register definitions from psc.c to psc.h >>> davinci: make it possible to include clock.h and psc.h in assembly >>>code >>> davinci: cpuidle: move mapping of DDR2 controller registers out of >>>driver >>> davinci: da850/omap-l138: unlock PLL registers during init >>> davinci: da850/omap-l138: create static map for SRAM >>> davinci: explain CLOCK_TICK_RATE of 27MHz in include/mach/timex.h >>> davinci: board-dm646x-evm.c: arrange related code together >>> davinci: add support for DM6467T EVM >>> davinci: make /proc/davinci_clocks display multi-rooted clock tree >>> davinci: move /proc/davinci_clocks to debugfs >>> davinci: add power management support >>> davinci: da850/omap-l138: add support for SoC suspend >>> davinci: da850/omap-l138 EVM: register for suspend support >>> davinci: clock: let clk->set_rate function sleep >>> >>>Sriramakrishnan (3): >>> TI Davinci EMAC : Re-use driver for other platforms. >>> TI Davinci EMAC : add platform specific interrupt enable/disable >>>logic. >>> TI Davinci EMAC : Abstract Buffer address translation logic. >>> >>>Sudhakar Rajashekhara (7): >>> davinci: da850/omap-l138: Modify NOR partition info >>> davinci: da850/omap-l138: Enable 4-bit ecc >>> davinci: Correct return value of edma_alloc_channel api >>> davinci: Keep count of channel controllers on a platform >>> davinci: Fix edma_alloc_channel api for EDMA_CHANNEL_ANY case >>> davinci: build list of unused EDMA events dynamically >>> davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap- >l138 >>> >>> arch/arm/mach-davinci/Kconfig | 4 + >>> arch/arm/mach-davinci/Makefile | 3 +- >>> arch/arm/mach-davinci/board-da830-evm.c | 4 +- >>> arch/arm/mach-davinci/board-da850-evm.c | 34 +++- >>> arch/arm/mach-davinci/board-dm355-evm.c | 2 + >>> arch/arm/mach-davinci/board-dm365-evm.c | 94 +++++++ >>> arch/arm/mach-davinci/board-dm644x-evm.c | 2 + >>> arch/arm/mach-davinci/board-dm646x-evm.c | 143 +++++++--- >>> arch/arm/mach-davinci/cdce949.c | 293 >>>++++++++++++++++++++ >>> arch/arm/mach-davinci/clock.c | 93 +++---- >>> arch/arm/mach-davinci/clock.h | 45 ++- >>> arch/arm/mach-davinci/common.c | 2 +- >>> arch/arm/mach-davinci/cpuidle.c | 38 +--- >>> arch/arm/mach-davinci/da830.c | 10 +- >>> arch/arm/mach-davinci/da850.c | 90 +++++- >>> arch/arm/mach-davinci/devices-da8xx.c | 146 +++++++++- >>> arch/arm/mach-davinci/dm355.c | 49 ++-- >>> arch/arm/mach-davinci/dm365.c | 213 >++++++++++++++- >>> arch/arm/mach-davinci/dm644x.c | 12 +- >>> arch/arm/mach-davinci/dm646x.c | 14 +- >>> arch/arm/mach-davinci/dma.c | 67 ++++- >>> arch/arm/mach-davinci/include/mach/cdce949.h | 19 ++ >>> arch/arm/mach-davinci/include/mach/common.h | 2 +- >>> arch/arm/mach-davinci/include/mach/cpuidle.h | 1 + >>> arch/arm/mach-davinci/include/mach/da8xx.h | 18 +- >>> arch/arm/mach-davinci/include/mach/dm365.h | 11 +- >>> arch/arm/mach-davinci/include/mach/dm644x.h | 2 +- >>> arch/arm/mach-davinci/include/mach/dm646x.h | 4 +- >>> arch/arm/mach-davinci/include/mach/edma.h | 2 - >>> arch/arm/mach-davinci/include/mach/i2c.h | 2 + >>> arch/arm/mach-davinci/include/mach/memory.h | 5 + >>> arch/arm/mach-davinci/include/mach/mux.h | 3 + >>> arch/arm/mach-davinci/include/mach/pm.h | 54 ++++ >>> arch/arm/mach-davinci/include/mach/psc.h | 15 + >>> arch/arm/mach-davinci/include/mach/spi.h | 44 +++ >>> arch/arm/mach-davinci/include/mach/timex.h | 7 +- >>> arch/arm/mach-davinci/pm.c | 158 +++++++++++ >>> arch/arm/mach-davinci/psc.c | 11 - >>> arch/arm/mach-davinci/sleep.S | 224 >+++++++++++++++ >>> drivers/net/Kconfig | 2 +- >>> drivers/net/davinci_emac.c | 55 +++-- >>> .../mach/emac.h => include/linux/davinci_emac.h | 7 +- >>> 42 files changed, 1708 insertions(+), 296 deletions(-) >>> create mode 100644 arch/arm/mach-davinci/cdce949.c >>> create mode 100644 arch/arm/mach-davinci/include/mach/cdce949.h >>> create mode 100644 arch/arm/mach-davinci/include/mach/pm.h >>> create mode 100644 arch/arm/mach-davinci/include/mach/spi.h >>> create mode 100644 arch/arm/mach-davinci/pm.c >>> create mode 100644 arch/arm/mach-davinci/sleep.S >>> rename arch/arm/mach-davinci/include/mach/emac.h => >>>include/linux/davinci_emac.h (83%) >>>_______________________________________________ >>>Davinci-linux-open-source mailing list >>>Davinci-linux-open-source at linux.davincidsp.com >>>http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source From madhu.chinakonda at gmail.com Mon Mar 1 10:22:58 2010 From: madhu.chinakonda at gmail.com (Madhu) Date: Mon, 01 Mar 2010 21:52:58 +0530 Subject: Aieee Killing Interrupt handler after 2 days. In-Reply-To: References: Message-ID: <4B8BE9E2.3020401@gmail.com> Hello Deepak, From the log, I could see some problem or conflict between the hrtimer and pm. One way is you can try disabling hrtimer and check. Regards, Madhu On 03/01/2010 04:19 PM, Deepak Shankar-ERS,HCLTech. wrote: > Hello all, > > I have a system running based on mvl4.0.1-2.6.10 Linux in dm355 davinci. > Now on a sporadic basis after 2 days or so, if I leave the sytem, the system crashes(Aieee) throwing the following crashdump. > > I could not make much out of the log, I have looked into my application and it seems to be fine. > > If any of you have faced a similar problem, could you please help me in finding out what is the problem. > > Please provide me any inputs in this regard. > > Start of dump: > ************************************************************************************************************** > > Internal error: Oops - undefined instruction: 0 [#1] > > Modules linked in: g_zero GPIOd cmemk PMd dm350mmap > > CPU: 0 > > PC is at 0xc021f048 > > LR is at do_hrtimers_expire_timers+0x1cc/0x228 > > pc : [] lr : [] Not tainted > > sp : c01cfe58 ip : c01d11e8 fp : c01cfe7c > > r10: c01d11e8 r9 : c0214ce0 r8 : c021ff50 > > r7 : c021ddfc r6 : c021ddfc r5 : c021ff48 r4 : c01ce000 > > r3 : 00000000 r2 : c021ff48 r1 : c021ff48 r0 : 40000440 > > Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment kernel > > Control: 5317F Table: 855B8000 DAC: 00000017 > > Process swapper (pid: 0, stack limit = 0xc01ce1a0) > > Stack: (0xc01cfe58 to 0xc01d0000) > > fe40: c006435c c01ce000 > > fe60: 00000001 bf00b10c c021d7fc c01cfe98 c01cfe94 c01cfe80 c0064724 c00643ac > > fe80: 00000103 c01ce000 c01cfecc c01cfe98 c0054bf8 c00646bc c021ddec c021ddfc > > fea0: c01ce000 c021d7b4 c01ce000 00000103 00000001 c021d590 0000000a c021d560 > > fec0: c01cfef4 c01cfed0 c0050070 c0054abc c01ce000 00000000 c003e90c 00000002 > > fee0: c01ce000 c01cff60 c01cff0c c01cfef8 c005014c c005002c c01ce000 c01ce000 > > ff00: c01cff24 c01cff10 c0050304 c0050124 c01ce000 c01cff94 c01cff5c c01cff28 > > ff20: c00304c0 c00502c8 00000000 c5b184a0 c02182d0 c01cff94 e1048000 c003e90c > > ff40: 00000002 c01ce000 00000001 800276bc c01cffb4 c01cff60 c002e780 c00303b0 > > ff60: 00000000 60000093 c0217fa0 60000013 c01ce000 c003eee8 c02201c4 c0226ad8 > > ff80: 800276ec 41069265 800276bc c01cffb4 c01cffa8 c01cffa8 c003e90c c003ef64 > > ffa0: 60000013 ffffffff c01cffcc c01cffb8 c0031004 c003eef8 00000000 c021481c > > ffc0: c01cfffc c01cffd0 c00087d8 c0030fc4 c0008304 00000000 00000000 c02174d8 > > ffe0: 00000000 00053175 c02174bc c01d0f10 00000000 c01d0000 8000809c c0008660 > > Backtrace: > > [] (do_hrtimers_expire_timers+0x0/0x228) from [] (do_high_res_timer+0x78/0xa0) > > r8 = C01CFE98 r7 = C021D7FC r6 = BF00B10C r5 = 00000001 > > r4 = C01CE000 > > [] (do_high_res_timer+0x0/0xa0) from [] (run_timer_softirq+0x14c/0x278) > > r5 = C01CE000 r4 = 00000103 > > [] (run_timer_softirq+0x0/0x278) from [] (___do_softirq+0x54/0xf8) > > [] (___do_softirq+0x0/0xf8) from [] (__do_softirq+0x38/0x58) > > [] (__do_softirq+0x0/0x58) from [] (irq_exit+0x4c/0x60) > > r5 = C01CE000 r4 = C01CE000 > > [] (irq_exit+0x0/0x60) from [] (asm_do_IRQ+0x120/0x138) > > r4 = C01CFF94 > > [] (asm_do_IRQ+0x0/0x138) from [] (__irq_svc+0x40/0x6c) > > [] (davinci_pm_idle+0x0/0x84) from [] (cpu_idle+0x50/0x88) > > [] (cpu_idle+0x0/0x88) from [] (start_kernel+0x188/0x1cc) > > r5 = C021481C r4 = 00000000 > > [] (start_kernel+0x0/0x1cc) from [<8000809c>] (0x8000809c) > > Code: c02fa5e0 c02fade0 c02fb5e0 00000009 (fffffed4) > > <0>Kernel panic - not syncing: Aiee, killing interrupt handler! > > ************************************************************************************************************** > End of dump: > > > Cheers, > Deepak Shankar V > DISCLAIMER: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of > this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > From kapil.pendse at gmail.com Tue Mar 2 04:04:41 2010 From: kapil.pendse at gmail.com (Kapil Pendse) Date: Tue, 2 Mar 2010 15:34:41 +0530 Subject: MVL4.0.1 kernel compiled with MVL5.0 toolchain Message-ID: <65b6d8ff1003020204k2ac9bcbcn9c6117350b4142d6@mail.gmail.com> Hi Eric, > This is a matter of kernel versions. The former is the 2.6.10 kernel > compiled > with the MVL 5.0 toolchain (the one you've compiled) and the latter has > been > compiled with the MVL 4.0 toolchain. > Check the value of KERNELDIR in your module makefile. It should point to > the > MV5.0 compiled kernel. > My kernel module Makefile has a LINUX_SRC which points to the right kernel tree path. So then I checked the built-up kernel module's vermagic using the "modinfo" command and here's what I got: # modinfo rt2070.ko ...... vermagic: 2.6.10_mvl401 preempt ARMv5 gcc-4.2 ...... So it seems that the driver is compiled with the MVL5.0 toolchain all right. But the insmod command still returns the previously mentioned error of version mismatch. So I manually changed the vermagic string in the rt2070.ko file, which is certainly not the solution. I changed it to "2.6.10_mvl401 preempt ARMv5 gcc3.4" which is what the insmod command error asks for. Now I can load the module all right. So, this seems to indicate that the linux kernel compilation seems to have happened with the older MVL4.0.1 toolchain? To check this, I did the following: # cat /proc/version Linux version 2.6.10_mvl401 (kapil at kapil-desktop) (gcc version 4.2.0 (MontaVista 4.2.0-16.0.32.0801914 2008-08-30)) #4 Fri Feb 26 22:11:31 IST 2010 So that surely indicates that the kernel too is compiled properly with the MVL5.0 toolchain (gcc version 4.2.0). So now what could be the reason behind this error that I still get: > root at 192.168.0.4:/opt# insmod rt2070sta.ko > rt2070sta: no version for "struct_module" found: kernel tainted. > rt2070sta: version magic '2.6.10_mvl401 preempt ARMv5 gcc-4.2' should be > '2.6.10_mvl401 preempt ARMv5 gcc-3.4' > insmod: error inserting 'rt2070sta.ko': -1 Invalid module format Warm regards, Kapil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dato at digimeq.ru Tue Mar 2 06:16:28 2010 From: dato at digimeq.ru (David Goshadze) Date: Tue, 2 Mar 2010 15:16:28 +0300 Subject: 2.6.32 musb_hdrc fails to load (DM6446) In-Reply-To: References: <1284591885.20100224212923@digimeq.ru> , <1341891187.20100227153538@digimeq.ru> Message-ID: <18610177235.20100302151628@digimeq.ru> Swami, Thanks again for help. I compiled I2C Support, though my board doesn't have one. As I noticed, due to dev->bus->probe failure for I2C devices, evm_u35_setup is never called. Can you suggest some workaround? (calling usb_setup registered USB devise, but crashed kernel later as expected, due to chip was not registered). David. SS> David, SS> Did you compile in the I2c Expander support in the kernel. I SS> think you are missing this part of the config. Can you confirm. SS> regards SS> swami SS> ________________________________________ SS> From: davinci-linux-open-source-bounces at linux.davincidsp.com SS> [davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf SS> Of David Goshadze [dato at digimeq.ru] SS> Sent: Saturday, February 27, 2010 6:05 PM SS> To: davinci-linux-open-source at linux.davincidsp.com SS> Subject: Re: 2.6.32 musb_hdrc fails to load (DM6446) SS> Hi all again. SS> Digging into sources I discovered that setup_usb (from SS> arch/arm/mach-davinci/usb.c) is never called, thus platform device SS> register for usb_dev is also never called. SS> Wondering for a reason. SS> Please help. SS> David. SS>> David, SS>> Could you try the aarago git davinci tree? SS>> From the below log it seems there could be a SS>> configuration issue between the base port and the driver init. SS>> Regards SS>> swami >>> -----Original Message----- >>> From: davinci-linux-open-source- >>> bounces+swami.iyer=ti.com at linux.davincidsp.com [mailto:davinci-linux-open- >>> source-bounces+swami.iyer=ti.com at linux.davincidsp.com] On Behalf Of David >>> Goshadze >>> Sent: Wednesday, February 24, 2010 11:59 PM >>> To: davinci-linux-open-source at linux.davincidsp.com >>> Subject: 2.6.32 musb_hdrc fails to load (DM6446) >>> >>> Hi all! >>> >>> Please help with the following problem: >>> >>> I successfully loaded an built 2.6.32 for our DM6446 based board. >>> >>> Everything's just fine except I cannot load musb_hdrc driver. >>> I got: >>> modprobe musb_hdrc : version 6.0, cppi-dma, peripherial, debug=0 >>> FATAL: Error inserting musb_hdrc >>> (/lib/modules/2/6/32/kernel/drivers/usb/musb/musb_hdrc.ko): No such device >>> nop_usb_xceiv loaded successfully. >>> >>> use_dma=n doesn't help. >>> >>> Spending 2 days trying various kernel configurations and googling didn't >>> help. >>> >>> With 2.6.10 (mvl) everything was fine. >>> >>> I'm nearly gone mad with this. >>> >>> David. >>> >>> >>> >>> _______________________________________________ >>> Davinci-linux-open-source mailing list >>> Davinci-linux-open-source at linux.davincidsp.com >>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source SS> ___________________________ SS> David Goshadze, SS> Chief project developer, SS> PLC Digimeq, SS> 5, Vozdvizhenka str. SS> Moscow, Russian Federation SS> Ph +7 495 9505231 SS> Mob +7 916 604 56 93 SS> Fax +7 495 9505231 SS> dato at digimeq.ru SS> www.digimeq.com SS> _______________________________________________ SS> Davinci-linux-open-source mailing list SS> Davinci-linux-open-source at linux.davincidsp.com SS> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___________________________ David Goshadze, Chief project developer, PLC Digimeq, 5, Vozdvizhenka str. Moscow, Russian Federation Ph +7 495 9505231 Mob +7 916 604 56 93 Fax +7 495 9505231 dato at digimeq.ru www.digimeq.com From swami.iyer at ti.com Tue Mar 2 06:20:29 2010 From: swami.iyer at ti.com (Subbrathnam, Swaminathan) Date: Tue, 2 Mar 2010 17:50:29 +0530 Subject: 2.6.32 musb_hdrc fails to load (DM6446) In-Reply-To: <18610177235.20100302151628@digimeq.ru> References: <1284591885.20100224212923@digimeq.ru> , <1341891187.20100227153538@digimeq.ru> <18610177235.20100302151628@digimeq.ru> Message-ID: David, I was assuming that you are using TI EVM platform. If you are using your own platform you can call the usb_setup directly from your board init file. Regards swami > -----Original Message----- > From: davinci-linux-open-source-bounces at linux.davincidsp.com > [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf > Of David Goshadze > Sent: Tuesday, March 02, 2010 5:46 PM > To: davinci-linux-open-source at linux.davincidsp.com > Subject: Re: 2.6.32 musb_hdrc fails to load (DM6446) > > Swami, Thanks again for help. > > I compiled I2C Support, though my board doesn't have one. > As I noticed, due to dev->bus->probe failure for I2C devices, > evm_u35_setup is never called. > > Can you suggest some workaround? (calling usb_setup registered USB > devise, but crashed kernel later as expected, due to chip was not > registered). > > David. > > > > SS> David, > > SS> Did you compile in the I2c Expander support in the kernel. I > SS> think you are missing this part of the config. Can you confirm. > > SS> regards > SS> swami > > SS> ________________________________________ > SS> From: davinci-linux-open-source-bounces at linux.davincidsp.com > SS> [davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf > SS> Of David Goshadze [dato at digimeq.ru] > SS> Sent: Saturday, February 27, 2010 6:05 PM > SS> To: davinci-linux-open-source at linux.davincidsp.com > SS> Subject: Re: 2.6.32 musb_hdrc fails to load (DM6446) > > SS> Hi all again. > > SS> Digging into sources I discovered that setup_usb (from > SS> arch/arm/mach-davinci/usb.c) is never called, thus platform device > SS> register for usb_dev is also never called. > > SS> Wondering for a reason. > SS> Please help. > > SS> David. > > SS>> David, > SS>> Could you try the aarago git davinci tree? > > SS>> From the below log it seems there could be a > SS>> configuration issue between the base port and the driver init. > > SS>> Regards > SS>> swami > > >>> -----Original Message----- > >>> From: davinci-linux-open-source- > >>> bounces+swami.iyer=ti.com at linux.davincidsp.com [mailto:davinci-linux- > open- > >>> source-bounces+swami.iyer=ti.com at linux.davincidsp.com] On Behalf Of > David > >>> Goshadze > >>> Sent: Wednesday, February 24, 2010 11:59 PM > >>> To: davinci-linux-open-source at linux.davincidsp.com > >>> Subject: 2.6.32 musb_hdrc fails to load (DM6446) > >>> > >>> Hi all! > >>> > >>> Please help with the following problem: > >>> > >>> I successfully loaded an built 2.6.32 for our DM6446 based board. > >>> > >>> Everything's just fine except I cannot load musb_hdrc driver. > >>> I got: > >>> modprobe musb_hdrc : version 6.0, cppi-dma, peripherial, debug=0 > >>> FATAL: Error inserting musb_hdrc > >>> (/lib/modules/2/6/32/kernel/drivers/usb/musb/musb_hdrc.ko): No such > device > >>> nop_usb_xceiv loaded successfully. > >>> > >>> use_dma=n doesn't help. > >>> > >>> Spending 2 days trying various kernel configurations and googling > didn't > >>> help. > >>> > >>> With 2.6.10 (mvl) everything was fine. > >>> > >>> I'm nearly gone mad with this. > >>> > >>> David. > >>> > >>> > >>> > >>> _______________________________________________ > >>> Davinci-linux-open-source mailing list > >>> Davinci-linux-open-source at linux.davincidsp.com > >>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > > SS> ___________________________ > SS> David Goshadze, > SS> Chief project developer, > SS> PLC Digimeq, > SS> 5, Vozdvizhenka str. > SS> Moscow, Russian Federation > > SS> Ph +7 495 9505231 > SS> Mob +7 916 604 56 93 > SS> Fax +7 495 9505231 > SS> dato at digimeq.ru > SS> www.digimeq.com > > SS> _______________________________________________ > SS> Davinci-linux-open-source mailing list > SS> Davinci-linux-open-source at linux.davincidsp.com > SS> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > ___________________________ > David Goshadze, > Chief project developer, > PLC Digimeq, > 5, Vozdvizhenka str. > Moscow, Russian Federation > > Ph +7 495 9505231 > Mob +7 916 604 56 93 > Fax +7 495 9505231 > dato at digimeq.ru > www.digimeq.com > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source From schen at mvista.com Tue Mar 2 07:40:11 2010 From: schen at mvista.com (Steve Chen) Date: Tue, 2 Mar 2010 07:40:11 -0600 Subject: MVL4.0.1 kernel compiled with MVL5.0 toolchain In-Reply-To: <65b6d8ff1003020204k2ac9bcbcn9c6117350b4142d6@mail.gmail.com> References: <65b6d8ff1003020204k2ac9bcbcn9c6117350b4142d6@mail.gmail.com> Message-ID: On Tue, Mar 2, 2010 at 4:04 AM, Kapil Pendse wrote: > Hi Eric, > > > >> This is a matter of kernel versions. The former is the 2.6.10 kernel >> compiled >> with the MVL 5.0 toolchain (the one you've compiled) and the latter has >> been >> compiled with the MVL 4.0 toolchain. >> Check the value of KERNELDIR in your module makefile. It should point to >> the >> MV5.0 compiled kernel. >> > > My kernel module Makefile has a LINUX_SRC which points to the right kernel > tree path. So then I checked the built-up kernel module's vermagic using the > "modinfo" command and here's what I got: > > # modinfo rt2070.ko > ...... > vermagic: 2.6.10_mvl401 preempt ARMv5 gcc-4.2 > ...... > > So it seems that the driver is compiled with the MVL5.0 toolchain all > right. But the insmod command still returns the previously mentioned error > of version mismatch. So I manually changed the vermagic string in the > rt2070.ko file, which is certainly not the solution. I changed it to > "2.6.10_mvl401 preempt ARMv5 gcc3.4" which is what the insmod command error > asks for. > > Now I can load the module all right. So, this seems to indicate that the > linux kernel compilation seems to have happened with the older MVL4.0.1 > toolchain? To check this, I did the following: > > # cat /proc/version > Linux version 2.6.10_mvl401 (kapil at kapil-desktop) (gcc version 4.2.0 > (MontaVista 4.2.0-16.0.32.0801914 2008-08-30)) #4 Fri Feb 26 22:11:31 IST > 2010 > > So that surely indicates that the kernel too is compiled properly with the > MVL5.0 toolchain (gcc version 4.2.0). > > So now what could be the reason behind this error that I still get: > > > root at 192.168.0.4:/opt# insmod rt2070sta.ko > > rt2070sta: no version for "struct_module" found: kernel tainted. > > rt2070sta: version magic '2.6.10_mvl401 preempt ARMv5 gcc-4.2' should be > > '2.6.10_mvl401 preempt ARMv5 gcc-3.4' > > insmod: error inserting 'rt2070sta.ko': -1 Invalid module format > > May want to try rebuilding the module-init-tools (which contains insmod) with Pro5 toolchain. See if that helps. Regards, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From kapil.pendse at gmail.com Tue Mar 2 08:31:04 2010 From: kapil.pendse at gmail.com (Kapil Pendse) Date: Tue, 2 Mar 2010 20:01:04 +0530 Subject: MVL4.0.1 kernel compiled with MVL5.0 toolchain In-Reply-To: References: <65b6d8ff1003020204k2ac9bcbcn9c6117350b4142d6@mail.gmail.com> Message-ID: <65b6d8ff1003020631x348a699fo4dae84ef3ce14e42@mail.gmail.com> On Tue, Mar 2, 2010 at 7:10 PM, Steve Chen wrote: > > May want to try rebuilding the module-init-tools (which contains insmod) > with Pro5 toolchain. See if that helps. > > The module-init-tools seems to be an init script. I'm guessing re-compiling the "insmod" utility with MVL5.0 might help? Could you direct me to where I can find the source code for insmod and rmmod utilities that are available in binary form in the MVL target file system? I found a file module-init-tools-3.1pre5-4.0.1.0600975.arm_v5t_le.mvl and another one that has "debuginfo" in its name. These seem to be the binary files in some "extractable" format that's decoded by the MVL installer? So, is the source code available on the myportal.ti.com TI support pages? Warm regards, Kapil -- "The Power to Imagine, is The Power to Create!" -TTux -------------- next part -------------- An HTML attachment was scrubbed... URL: From schen at mvista.com Tue Mar 2 08:50:31 2010 From: schen at mvista.com (Steve Chen) Date: Tue, 2 Mar 2010 08:50:31 -0600 Subject: MVL4.0.1 kernel compiled with MVL5.0 toolchain In-Reply-To: <65b6d8ff1003020631x348a699fo4dae84ef3ce14e42@mail.gmail.com> References: <65b6d8ff1003020204k2ac9bcbcn9c6117350b4142d6@mail.gmail.com> <65b6d8ff1003020631x348a699fo4dae84ef3ce14e42@mail.gmail.com> Message-ID: On Tue, Mar 2, 2010 at 8:31 AM, Kapil Pendse wrote: > On Tue, Mar 2, 2010 at 7:10 PM, Steve Chen wrote: > >> >> May want to try rebuilding the module-init-tools (which contains insmod) >> with Pro5 toolchain. See if that helps. >> >> > The module-init-tools seems to be an init script. I'm guessing re-compiling > the "insmod" utility with MVL5.0 might help? Could you direct me to where I > can find the source code for insmod and rmmod utilities that are available > in binary form in the MVL target file system? > > I found a file module-init-tools-3.1pre5-4.0.1.0600975.arm_v5t_le.mvl and > another one that has "debuginfo" in its name. These seem to be the binary > files in some "extractable" format that's decoded by the MVL installer? So, > is the source code available on the myportal.ti.com TI support pages? > > module-init-tools-3.1pre5-4.0.1.0600975.arm_v5t_le.mvl is essentially a rpm file. It contains the executable files. The insmod is part of a larger collection of utilities. Personally, I always found it easier to compile the entire package instead of individual utilities. Anyway, depend on where you got your kernel/toolchain, 1. If you are a Monta Vista customer, you can get it from support.mvista.com. Please note that you need a subscription to access the site. 2. If you got the SDK from TI, TI should be able to supply the source code. Regards, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From kapil.pendse at gmail.com Tue Mar 2 09:15:52 2010 From: kapil.pendse at gmail.com (Kapil Pendse) Date: Tue, 2 Mar 2010 20:45:52 +0530 Subject: MVL4.0.1 kernel compiled with MVL5.0 toolchain In-Reply-To: References: <65b6d8ff1003020204k2ac9bcbcn9c6117350b4142d6@mail.gmail.com> <65b6d8ff1003020631x348a699fo4dae84ef3ce14e42@mail.gmail.com> Message-ID: <65b6d8ff1003020715p1168d73ap4d7505ef3cbe3aed@mail.gmail.com> On Tue, Mar 2, 2010 at 8:20 PM, Steve Chen wrote: > module-init-tools-3.1pre5-4.0.1.0600975.arm_v5t_le.mvl is essentially a rpm > file. It contains the executable files. > The insmod is part of a larger collection of utilities. Personally, I > always found it easier to compile the entire package instead of individual > utilities. Anyway, depend on where you got your kernel/toolchain, > > 1. If you are a Monta Vista customer, you can get it from > support.mvista.com. Please note that you need a subscription to access > the site. > > 2. If you got the SDK from TI, TI should be able to supply the source > code. > > Thanks Steve. I got the SDK from TI so I've initiated contact with their support. I could not find the same version of module-init-tools on kernel.org otherwise I could have just taken it from there. The one on DM355 target file system is version 3.1-pre5. I'm also considering to use the MVL5.0 "insmod" utility in my MVL4.0.1 target file system with kernel 2.6.10 (compiled with MVL5.0 toolchain). Just to see what happens. Warm regards, Kapil -- "The Power to Imagine, is The Power to Create!" -TTux -------------- next part -------------- An HTML attachment was scrubbed... URL: From khilman at deeprootsystems.com Tue Mar 2 10:07:01 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 02 Mar 2010 08:07:01 -0800 Subject: [GIT PULL] davinci platform updates for 2.6.34 In-Reply-To: <87d3zngaml.fsf@deeprootsystems.com> (Kevin Hilman's message of "Mon\, 01 Mar 2010 10\:28\:02 -0800") References: <87d3zngaml.fsf@deeprootsystems.com> Message-ID: <87wrxu4sii.fsf@deeprootsystems.com> [trimmed to only davinci list] FYI... Linus pulled all our pending changes for 2.6.34. Special thanks to those listed below for helping get davinci support to mainline. Kevin [...] > Chaithrika U S (1): > davinci: clock: Check CLK_PSC flag before disabling PSC > > Kevin Hilman (2): > davinci: clkdev cleanup: remove clk_lookup wrapper, use clkdev_add_table() > davinci: dm646x: CDCE clocks: davinci_clk converted to clk_lookup > > Miguel Aguilar (1): > DaVinci: DM365: Voice codec support for the DM365 SoC > > Murali Karicheri (1): > DaVinci - Adding platform & board changes for vpfe capture on DM365 > > Nageswari Srinivasan (2): > davinci: add support for CDCE949 clock synthesizer > davinci: add CDCE949 support on DM6467 EVM > > Philby John (1): > Add SDA and SCL pin numbers to i2c platform data > > Sandeep Paulraj (5): > DaVinci: DM365: Changing default queue for DM365. > DaVinci: SPI: Adding header file for SPI support. > DaVinci DM355: Modifications to DM355 SPI support > DaVinci DM365: Adding DM365 SPI support > DaVinci DM365: Adding support for SPI EEPROM > > Sekhar Nori (17): > davinci: da8xx/omapl1: add support for the second sysconfig module > davinci: move PLL wait time values to clock.h > davinci: move DDR2 controller defines to memory.h > davinci: move PSC register definitions from psc.c to psc.h > davinci: make it possible to include clock.h and psc.h in assembly code > davinci: cpuidle: move mapping of DDR2 controller registers out of driver > davinci: da850/omap-l138: unlock PLL registers during init > davinci: da850/omap-l138: create static map for SRAM > davinci: explain CLOCK_TICK_RATE of 27MHz in include/mach/timex.h > davinci: board-dm646x-evm.c: arrange related code together > davinci: add support for DM6467T EVM > davinci: make /proc/davinci_clocks display multi-rooted clock tree > davinci: move /proc/davinci_clocks to debugfs > davinci: add power management support > davinci: da850/omap-l138: add support for SoC suspend > davinci: da850/omap-l138 EVM: register for suspend support > davinci: clock: let clk->set_rate function sleep > > Sriramakrishnan (3): > TI Davinci EMAC : Re-use driver for other platforms. > TI Davinci EMAC : add platform specific interrupt enable/disable logic. > TI Davinci EMAC : Abstract Buffer address translation logic. > > Sudhakar Rajashekhara (7): > davinci: da850/omap-l138: Modify NOR partition info > davinci: da850/omap-l138: Enable 4-bit ecc > davinci: Correct return value of edma_alloc_channel api > davinci: Keep count of channel controllers on a platform > davinci: Fix edma_alloc_channel api for EDMA_CHANNEL_ANY case > davinci: build list of unused EDMA events dynamically > davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 > > arch/arm/mach-davinci/Kconfig | 4 + > arch/arm/mach-davinci/Makefile | 3 +- > arch/arm/mach-davinci/board-da830-evm.c | 4 +- > arch/arm/mach-davinci/board-da850-evm.c | 34 +++- > arch/arm/mach-davinci/board-dm355-evm.c | 2 + > arch/arm/mach-davinci/board-dm365-evm.c | 94 +++++++ > arch/arm/mach-davinci/board-dm644x-evm.c | 2 + > arch/arm/mach-davinci/board-dm646x-evm.c | 143 +++++++--- > arch/arm/mach-davinci/cdce949.c | 293 ++++++++++++++++++++ > arch/arm/mach-davinci/clock.c | 93 +++---- > arch/arm/mach-davinci/clock.h | 45 ++- > arch/arm/mach-davinci/common.c | 2 +- > arch/arm/mach-davinci/cpuidle.c | 38 +--- > arch/arm/mach-davinci/da830.c | 10 +- > arch/arm/mach-davinci/da850.c | 90 +++++- > arch/arm/mach-davinci/devices-da8xx.c | 146 +++++++++- > arch/arm/mach-davinci/dm355.c | 49 ++-- > arch/arm/mach-davinci/dm365.c | 213 ++++++++++++++- > arch/arm/mach-davinci/dm644x.c | 12 +- > arch/arm/mach-davinci/dm646x.c | 14 +- > arch/arm/mach-davinci/dma.c | 67 ++++- > arch/arm/mach-davinci/include/mach/cdce949.h | 19 ++ > arch/arm/mach-davinci/include/mach/common.h | 2 +- > arch/arm/mach-davinci/include/mach/cpuidle.h | 1 + > arch/arm/mach-davinci/include/mach/da8xx.h | 18 +- > arch/arm/mach-davinci/include/mach/dm365.h | 11 +- > arch/arm/mach-davinci/include/mach/dm644x.h | 2 +- > arch/arm/mach-davinci/include/mach/dm646x.h | 4 +- > arch/arm/mach-davinci/include/mach/edma.h | 2 - > arch/arm/mach-davinci/include/mach/i2c.h | 2 + > arch/arm/mach-davinci/include/mach/memory.h | 5 + > arch/arm/mach-davinci/include/mach/mux.h | 3 + > arch/arm/mach-davinci/include/mach/pm.h | 54 ++++ > arch/arm/mach-davinci/include/mach/psc.h | 15 + > arch/arm/mach-davinci/include/mach/spi.h | 44 +++ > arch/arm/mach-davinci/include/mach/timex.h | 7 +- > arch/arm/mach-davinci/pm.c | 158 +++++++++++ > arch/arm/mach-davinci/psc.c | 11 - > arch/arm/mach-davinci/sleep.S | 224 +++++++++++++++ > drivers/net/Kconfig | 2 +- > drivers/net/davinci_emac.c | 55 +++-- > .../mach/emac.h => include/linux/davinci_emac.h | 7 +- > 42 files changed, 1708 insertions(+), 296 deletions(-) > create mode 100644 arch/arm/mach-davinci/cdce949.c > create mode 100644 arch/arm/mach-davinci/include/mach/cdce949.h > create mode 100644 arch/arm/mach-davinci/include/mach/pm.h > create mode 100644 arch/arm/mach-davinci/include/mach/spi.h > create mode 100644 arch/arm/mach-davinci/pm.c > create mode 100644 arch/arm/mach-davinci/sleep.S > rename arch/arm/mach-davinci/include/mach/emac.h => include/linux/davinci_emac.h (83%) From khilman at deeprootsystems.com Tue Mar 2 10:07:42 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 02 Mar 2010 08:07:42 -0800 Subject: davinci git updated to v2.6.33 Message-ID: <87tysy4shd.fsf@deeprootsystems.com> FYI... The 2.6.33 kernel was released last week, and has been merged into davinci git. This release has been tagged as v2.6.33-davinci1. Kevin From ShahradP at verathon.ca Tue Mar 2 14:48:20 2010 From: ShahradP at verathon.ca (Shahrad Payandeh) Date: Tue, 2 Mar 2010 12:48:20 -0800 Subject: Progressive YUV in V4L driver In-Reply-To: <1246053826-8266-1-git-send-email-m-karicheri2@ti.com> References: <1246053826-8266-1-git-send-email-m-karicheri2@ti.com> Message-ID: <7BBD52B45DC7754293D263F6741569F6D255BC90EB@SMCP-P-EX02.sm.dxu.com> Hello All, I am trying to have our progressive YUV camera to DM365, and seem that the progressive section of V4L driver of MV Linux is not functional, am I right? Thanks, NOTICE: This communication may contain privileged or other confidential information. If you have received it in error, please advise the sender by reply email and immediately delete the message and any attachments without copying or disclosing the contents. Thank you. From deepaks at hcl.in Tue Mar 2 21:42:01 2010 From: deepaks at hcl.in (Deepak Shankar-ERS,HCLTech.) Date: Wed, 3 Mar 2010 09:12:01 +0530 Subject: Aieee Killing Interrupt handler after 2 days. In-Reply-To: <4B8BE9E2.3020401@gmail.com> References: <4B8BE9E2.3020401@gmail.com> Message-ID: Madhu, I tried this - However the tree would not compile since the ../ti-davinci/arch/arm/mach-davinci/time.c uses the arch_cycle_to_nsec which is a part of the hrtimers. unsigned long davinci_gettimeoffset(void) { unsigned long now, elapsed, nsec; now = davinci_timer32_read(davinci_timers[tid_freerun]); elapsed = now - davinci_timer32_last; nsec = arch_cycle_to_nsec(elapsed); return nsec / 1000; } I'm not sure why hrtimers are made configurable then - this is specific to davinci/mv tree it seems! Please provide me any other pointer in this regard. Best Regards, Deepak Shankar V -----Original Message----- From: Madhu [mailto:madhu.chinakonda at gmail.com] Sent: Monday, March 01, 2010 9:53 PM To: Deepak Shankar-ERS,HCLTech. Cc: davinci-linux-open-source at linux.davincidsp.com; davinci-linux-open-source-bounces at linux.davincidsp.com Subject: Re: Aieee Killing Interrupt handler after 2 days. Hello Deepak, From the log, I could see some problem or conflict between the hrtimer and pm. One way is you can try disabling hrtimer and check. Regards, Madhu On 03/01/2010 04:19 PM, Deepak Shankar-ERS,HCLTech. wrote: > Hello all, > > I have a system running based on mvl4.0.1-2.6.10 Linux in dm355 davinci. > Now on a sporadic basis after 2 days or so, if I leave the sytem, the system crashes(Aieee) throwing the following crashdump. > > I could not make much out of the log, I have looked into my application and it seems to be fine. > > If any of you have faced a similar problem, could you please help me in finding out what is the problem. > > Please provide me any inputs in this regard. > > Start of dump: > ********************************************************************** > **************************************** > > Internal error: Oops - undefined instruction: 0 [#1] > > Modules linked in: g_zero GPIOd cmemk PMd dm350mmap > > CPU: 0 > > PC is at 0xc021f048 > > LR is at do_hrtimers_expire_timers+0x1cc/0x228 > > pc : [] lr : [] Not tainted > > sp : c01cfe58 ip : c01d11e8 fp : c01cfe7c > > r10: c01d11e8 r9 : c0214ce0 r8 : c021ff50 > > r7 : c021ddfc r6 : c021ddfc r5 : c021ff48 r4 : c01ce000 > > r3 : 00000000 r2 : c021ff48 r1 : c021ff48 r0 : 40000440 > > Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment kernel > > Control: 5317F Table: 855B8000 DAC: 00000017 > > Process swapper (pid: 0, stack limit = 0xc01ce1a0) > > Stack: (0xc01cfe58 to 0xc01d0000) > > fe40: c006435c c01ce000 > > fe60: 00000001 bf00b10c c021d7fc c01cfe98 c01cfe94 c01cfe80 c0064724 > c00643ac > > fe80: 00000103 c01ce000 c01cfecc c01cfe98 c0054bf8 c00646bc c021ddec > c021ddfc > > fea0: c01ce000 c021d7b4 c01ce000 00000103 00000001 c021d590 0000000a > c021d560 > > fec0: c01cfef4 c01cfed0 c0050070 c0054abc c01ce000 00000000 c003e90c > 00000002 > > fee0: c01ce000 c01cff60 c01cff0c c01cfef8 c005014c c005002c c01ce000 > c01ce000 > > ff00: c01cff24 c01cff10 c0050304 c0050124 c01ce000 c01cff94 c01cff5c > c01cff28 > > ff20: c00304c0 c00502c8 00000000 c5b184a0 c02182d0 c01cff94 e1048000 > c003e90c > > ff40: 00000002 c01ce000 00000001 800276bc c01cffb4 c01cff60 c002e780 > c00303b0 > > ff60: 00000000 60000093 c0217fa0 60000013 c01ce000 c003eee8 c02201c4 > c0226ad8 > > ff80: 800276ec 41069265 800276bc c01cffb4 c01cffa8 c01cffa8 c003e90c > c003ef64 > > ffa0: 60000013 ffffffff c01cffcc c01cffb8 c0031004 c003eef8 00000000 > c021481c > > ffc0: c01cfffc c01cffd0 c00087d8 c0030fc4 c0008304 00000000 00000000 > c02174d8 > > ffe0: 00000000 00053175 c02174bc c01d0f10 00000000 c01d0000 8000809c > c0008660 > > Backtrace: > > [] (do_hrtimers_expire_timers+0x0/0x228) from [] > (do_high_res_timer+0x78/0xa0) > > r8 = C01CFE98 r7 = C021D7FC r6 = BF00B10C r5 = 00000001 > > r4 = C01CE000 > > [] (do_high_res_timer+0x0/0xa0) from [] > (run_timer_softirq+0x14c/0x278) > > r5 = C01CE000 r4 = 00000103 > > [] (run_timer_softirq+0x0/0x278) from [] > (___do_softirq+0x54/0xf8) > > [] (___do_softirq+0x0/0xf8) from [] > (__do_softirq+0x38/0x58) > > [] (__do_softirq+0x0/0x58) from [] > (irq_exit+0x4c/0x60) > > r5 = C01CE000 r4 = C01CE000 > > [] (irq_exit+0x0/0x60) from [] > (asm_do_IRQ+0x120/0x138) > > r4 = C01CFF94 > > [] (asm_do_IRQ+0x0/0x138) from [] > (__irq_svc+0x40/0x6c) > > [] (davinci_pm_idle+0x0/0x84) from [] > (cpu_idle+0x50/0x88) > > [] (cpu_idle+0x0/0x88) from [] > (start_kernel+0x188/0x1cc) > > r5 = C021481C r4 = 00000000 > > [] (start_kernel+0x0/0x1cc) from [<8000809c>] (0x8000809c) > > Code: c02fa5e0 c02fade0 c02fb5e0 00000009 (fffffed4) > > <0>Kernel panic - not syncing: Aiee, killing interrupt handler! > > ********************************************************************** > **************************************** > End of dump: > > > Cheers, > Deepak Shankar V > DISCLAIMER: > ---------------------------------------------------------------------- > ------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of this message > without the prior written consent of the author of this e-mail is > strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. > > ---------------------------------------------------------------------- > ------------------------------------------------- > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > From madhu.chinakonda at gmail.com Tue Mar 2 20:21:36 2010 From: madhu.chinakonda at gmail.com (Madhu) Date: Wed, 03 Mar 2010 07:51:36 +0530 Subject: Aieee Killing Interrupt handler after 2 days. In-Reply-To: References: <4B8BE9E2.3020401@gmail.com> Message-ID: <4B8DC7B0.2090907@gmail.com> Deepak, I dont see this function in the latest davinci sources so I cant check. Between can you check by disabling power management . These are just to confirm whether the conflict exists. Regards, Madhu On 03/03/2010 09:12 AM, Deepak Shankar-ERS,HCLTech. wrote: > Madhu, > > I tried this - However the tree would not compile since the ../ti-davinci/arch/arm/mach-davinci/time.c uses the arch_cycle_to_nsec which is a part of the hrtimers. > > unsigned long davinci_gettimeoffset(void) > { > unsigned long now, elapsed, nsec; > > now = davinci_timer32_read(davinci_timers[tid_freerun]); > elapsed = now - davinci_timer32_last; > > nsec = arch_cycle_to_nsec(elapsed); > return nsec / 1000; > } > > I'm not sure why hrtimers are made configurable then - this is specific to davinci/mv tree it seems! > > Please provide me any other pointer in this regard. > > Best Regards, > Deepak Shankar V > > -----Original Message----- > From: Madhu [mailto:madhu.chinakonda at gmail.com] > Sent: Monday, March 01, 2010 9:53 PM > To: Deepak Shankar-ERS,HCLTech. > Cc: davinci-linux-open-source at linux.davincidsp.com; davinci-linux-open-source-bounces at linux.davincidsp.com > Subject: Re: Aieee Killing Interrupt handler after 2 days. > > Hello Deepak, > > From the log, I could see some problem or conflict between the hrtimer and pm. One way is you can try disabling hrtimer and check. > > > Regards, > Madhu > > On 03/01/2010 04:19 PM, Deepak Shankar-ERS,HCLTech. wrote: > >> Hello all, >> >> I have a system running based on mvl4.0.1-2.6.10 Linux in dm355 davinci. >> Now on a sporadic basis after 2 days or so, if I leave the sytem, the system crashes(Aieee) throwing the following crashdump. >> >> I could not make much out of the log, I have looked into my application and it seems to be fine. >> >> If any of you have faced a similar problem, could you please help me in finding out what is the problem. >> >> Please provide me any inputs in this regard. >> >> Start of dump: >> ********************************************************************** >> **************************************** >> >> Internal error: Oops - undefined instruction: 0 [#1] >> >> Modules linked in: g_zero GPIOd cmemk PMd dm350mmap >> >> CPU: 0 >> >> PC is at 0xc021f048 >> >> LR is at do_hrtimers_expire_timers+0x1cc/0x228 >> >> pc : [] lr : [] Not tainted >> I'm not sure why hrtimers are made configurable then - this is specific to davinci/mv tree it seems! >> >> sp : c01cfe58 ip : c01d11e8 fp : c01cfe7c >> >> r10: c01d11e8 r9 : c0214ce0 r8 : c021ff50 >> >> r7 : c021ddfc r6 : c021ddfc r5 : c021ff48 r4 : c01ce000 >> >> r3 : 00000000 r2 : c021ff48 r1 : c021ff48 r0 : 40000440 >> >> Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment kernel >> >> Control: 5317F Table: 855B8000 DAC: 00000017 >> >> Process swapper (pid: 0, stack limit = 0xc01ce1a0) >> >> Stack: (0xc01cfe58 to 0xc01d0000) >> >> fe40: c006435c c01ce000 >> >> fe60: 00000001 bf00b10c c021d7fc c01cfe98 c01cfe94 c01cfe80 c0064724 >> c00643ac >> >> fe80: 00000103 c01ce000 c01cfecc c01cfe98 c0054bf8 c00646bc c021ddec >> c021ddfc >> >> fea0: c01ce000 c021d7b4 c01ce000 00000103 00000001 c021d590 0000000a >> c021d560 >> >> fec0: c01cfef4 c01cfed0 c0050070 c0054abc c01ce000 00000000 c003e90c >> 00000002 >> >> fee0: c01ce000 c01cff60 c01cff0c c01cfef8 c005014c c005002c c01ce000 >> c01ce000 >> >> ff00: c01cff24 c01cff10 c0050304 c0050124 c01ce000 c01cff94 c01cff5c >> c01cff28 >> >> ff20: c00304c0 c00502c8 00000000 c5b184a0 c02182d0 c01cff94 e1048000 >> c003e90c >> >> ff40: 00000002 c01ce000 00000001 800276bc c01cffb4 c01cff60 c002e780 >> c00303b0 >> >> ff60: 00000000 60000093 c0217fa0 60000013 c01ce000 c003eee8 c02201c4 >> c0226ad8 >> >> ff80: 800276ec 41069265 800276bc c01cffb4 c01cffa8 c01cffa8 c003e90c >> c003ef64 >> >> ffa0: 60000013 ffffffff c01cffcc c01cffb8 c0031004 c003eef8 00000000 >> c021481c >> >> ffc0: c01cfffc c01cffd0 c00087d8 c0030fc4 c0008304 00000000 00000000 >> c02174d8 >> >> ffe0: 00000000 00053175 c02174bc c01d0f10 00000000 c01d0000 8000809c >> c0008660 >> >> Backtrace: >> >> [] (do_hrtimers_expire_timers+0x0/0x228) from [] >> (do_high_res_timer+0x78/0xa0) >> >> r8 = C01CFE98 r7 = C021D7FC r6 = BF00B10C r5 = 00000001 >> >> r4 = C01CE000 >> >> [] (do_high_res_timer+0x0/0xa0) from [] >> (run_timer_softirq+0x14c/0x278) >> >> r5 = C01CE000 r4 = 00000103 >> >> [] (run_timer_softirq+0x0/0x278) from [] >> (___do_softirq+0x54/0xf8) >> >> [] (___do_softirq+0x0/0xf8) from [] >> (__do_softirq+0x38/0x58) >> >> [] (__do_softirq+0x0/0x58) from [] >> (irq_exit+0x4c/0x60) >> >> r5 = C01CE000 r4 = C01CE000 >> >> [] (irq_exit+0x0/0x60) from [] >> (asm_do_IRQ+0x120/0x138) >> >> r4 = C01CFF94 >> >> [] (asm_do_IRQ+0x0/0x138) from [] >> (__irq_svc+0x40/0x6c) >> >> [] (davinci_pm_idle+0x0/0x84) from [] >> (cpu_idle+0x50/0x88) >> >> [] (cpu_idle+0x0/0x88) from [] >> (start_kernel+0x188/0x1cc) >> >> r5 = C021481C r4 = 00000000 >> >> [] (start_kernel+0x0/0x1cc) from [<8000809c>] (0x8000809c) >> >> Code: c02fa5e0 c02fade0 c02fb5e0 00000009 (fffffed4) >> >> <0>Kernel panic - not syncing: Aiee, killing interrupt handler! >> >> ********************************************************************** >> **************************************** >> End of dump: >> >> >> Cheers, >> Deepak Shankar V >> DISCLAIMER: >> ---------------------------------------------------------------------- >> ------------------------------------------------- >> >> The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. >> It shall not attach any liability on the originator or HCL or its >> affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. >> Any form of reproduction, dissemination, copying, disclosure, >> modification, distribution and / or publication of this message >> without the prior written consent of the author of this e-mail is >> strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. >> >> ---------------------------------------------------------------------- >> ------------------------------------------------- >> _______________________________________________ >> Davinci-linux-open-source mailing list >> Davinci-linux-open-source at linux.davincidsp.com >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source >> >> > > From dato at digimeq.ru Wed Mar 3 10:41:03 2010 From: dato at digimeq.ru (David Goshadze) Date: Wed, 3 Mar 2010 19:41:03 +0300 Subject: 2.6.32 musb_hdrc fails to load (DM6446) In-Reply-To: References: <1284591885.20100224212923@digimeq.ru> , <1341891187.20100227153538@digimeq.ru> <18610177235.20100302151628@digimeq.ru> Message-ID: <3110095842.20100303194103@digimeq.ru> Swami, as I told you calling usb_setup succeeds, but kernel crashes while loading musb_hdrc: ******************************************************************************************* musb_hdrc: version 6.0, pio, peripheral, debug=0 bus: 'platform': really_probe: probing driver musb_hdrc with device musb_hdrc bus: 'platform': really_probe: probing driver nop_usb_xceiv with device nop_usb_xceiv BY DTG: __gpio_cansleep called with gpio = 160 Unable to handle kernel NULL pointer dereference at virtual address 00000020 pgd = c1114000 [00000020] *pgd=811ba031, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT last sysfs file: /sys/devices/platform/davinci_nand.0/mtd/mtd4/mtdblock4/removable Modules linked in: musb_hdrc(+) nop_usb_xceiv CPU: 0 Not tainted (2.6.32 #40) PC is at gpio_set_value_cansleep+0x2c/0x5c LR is at gpio_set_value_cansleep+0x18/0x5c pc : [] lr : [] psr: 40000013 sp : c2b47dc0 ip : 00003411 fp : c02d0b28 r10: 00000000 r9 : c02d0b20 r8 : c3c26360 r7 : 00147900 r6 : 00000001 r5 : 000000a0 r4 : 00000000 r3 : c0304940 r2 : 00000780 r1 : c0294777 r0 : c02947a9 Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 0005317f Table: 81114000 DAC: 00000015 Process modprobe (pid: 278, stack limit = 0xc2b46270) Stack: (0xc2b47dc0 to 0xc2b48000) 7dc0: 00000000 bf00b310 fec64000 bf006e20 c1472000 c1472000 fec64000 bf00fc18 7de0: c02d0bd8 c1472000 c02d0b00 00000000 c3c26360 bf00f354 c3803180 00000001 7e00: 00000000 00000000 0000000c fec64000 c1472044 c014bcb8 c2b47e6c 00000ba0 7e20: a0000013 c3806850 00000000 000000d0 c039dadc c00d1d00 c384b240 c3805000 7e40: c3437520 c3437520 c2b47e90 c009db4c c2b47e58 c00d25dc 00000006 17d828dc 7e60: c384b240 c00d21c8 c3c27540 c3c27540 c2b47e90 00000000 c3c27540 c2b47e90 7e80: c384b240 00000001 00000000 c00d3128 c384b240 c3437520 00000000 c02d0b28 7ea0: c02d0b28 bf00b29c c02de300 c3c26360 c2b46000 00000000 00000000 c01737b4 7ec0: c02d0b28 c01728dc c3849540 c02d0b28 c2b47ed8 c02d0b28 c02d0b5c bf00b29c 7ee0: c02de300 c0172a48 00000000 c01729e8 bf00b29c c0172088 c3803638 c384a1b0 7f00: 00000001 bf00b29c bf00b29c c01719b0 bf009cb6 bf009cb6 c2b47f18 00000001 7f20: bf00b288 bf00b29c 00000000 c0021064 000160d0 c0172d1c 00000001 bf00b288 7f40: bf00f000 00000000 c0021064 c0173a24 00000000 bf00b328 bf00f000 c00203ac 7f60: 0000c074 bf00b328 00000000 40164000 c0021064 00000000 bf00b328 00000000 7f80: 40164000 c005e294 40164000 0000c074 00016230 0000979c 00000000 00000000 7fa0: 00000080 c0020ee0 0000979c 00000000 40164000 0000c074 00016230 00016230 7fc0: 0000979c 00000000 00000000 00000080 00000000 000160dc 000160d0 00000000 7fe0: 00016240 be916a04 0000b208 400fd7d4 60000010 40164000 e59de040 e28dd048 [] (gpio_set_value_cansleep+0x2c/0x5c) from [] (davinci_source_power+0x34/0x4c [musb_hdrc]) [] (davinci_source_power+0x34/0x4c [musb_hdrc]) from [] (musb_platform_init+0x5c/0xd4 [musb_hdrc]) [] (musb_platform_init+0x5c/0xd4 [musb_hdrc]) from [] (musb_probe+0x1c8/0xa30 [musb_hdrc]) [] (musb_probe+0x1c8/0xa30 [musb_hdrc]) from [] (platform_drv_probe+0x18/0x1c) [] (platform_drv_probe+0x18/0x1c) from [] (driver_probe_device+0x114/0x220) [] (driver_probe_device+0x114/0x220) from [] (__driver_attach+0x60/0x84) [] (__driver_attach+0x60/0x84) from [] (bus_for_each_dev+0x44/0x74) [] (bus_for_each_dev+0x44/0x74) from [] (bus_add_driver+0xa8/0x234) [] (bus_add_driver+0xa8/0x234) from [] (driver_register+0xa8/0x134) [] (driver_register+0xa8/0x134) from [] (platform_driver_probe+0x18/0x98) [] (platform_driver_probe+0x18/0x98) from [] (do_one_initcall+0x5c/0x1bc) [] (do_one_initcall+0x5c/0x1bc) from [] (sys_init_module+0xbc/0x1e8) [] (sys_init_module+0xbc/0x1e8) from [] (ret_fast_syscall+0x0/0x28) Code: e0020593 e59f302c e59f002c e7934002 (e5941020) bus: 'platform': add driver watchdog ---[ end trace 49c8ae5707d7b633 ]--- udevd-event[271]: '/sbin/modprobe -b platform:musb_hdrc' abnormal exit ******************************************************************************************* As I can see davinci_source_power from musb/davinci.c calls gpio_set_value_cansleep while chip structure is not initialized. I'll try to disable this call. Thanks. David. SS> David, SS> I was assuming that you are using TI EVM platform. If SS> you are using your own platform you can call the usb_setup SS> directly from your board init file. SS> Regards SS> swami >> -----Original Message----- >> From: davinci-linux-open-source-bounces at linux.davincidsp.com >> [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf >> Of David Goshadze >> Sent: Tuesday, March 02, 2010 5:46 PM >> To: davinci-linux-open-source at linux.davincidsp.com >> Subject: Re: 2.6.32 musb_hdrc fails to load (DM6446) >> >> Swami, Thanks again for help. >> >> I compiled I2C Support, though my board doesn't have one. >> As I noticed, due to dev->bus->probe failure for I2C devices, >> evm_u35_setup is never called. >> >> Can you suggest some workaround? (calling usb_setup registered USB >> devise, but crashed kernel later as expected, due to chip was not >> registered). >> >> David. >> >> >> >> SS> David, >> >> SS> Did you compile in the I2c Expander support in the kernel. I >> SS> think you are missing this part of the config. Can you confirm. >> >> SS> regards >> SS> swami >> >> SS> ________________________________________ >> SS> From: davinci-linux-open-source-bounces at linux.davincidsp.com >> SS> [davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf >> SS> Of David Goshadze [dato at digimeq.ru] >> SS> Sent: Saturday, February 27, 2010 6:05 PM >> SS> To: davinci-linux-open-source at linux.davincidsp.com >> SS> Subject: Re: 2.6.32 musb_hdrc fails to load (DM6446) >> >> SS> Hi all again. >> >> SS> Digging into sources I discovered that setup_usb (from >> SS> arch/arm/mach-davinci/usb.c) is never called, thus platform device >> SS> register for usb_dev is also never called. >> >> SS> Wondering for a reason. >> SS> Please help. >> >> SS> David. >> >> SS>> David, >> SS>> Could you try the aarago git davinci tree? >> >> SS>> From the below log it seems there could be a >> SS>> configuration issue between the base port and the driver init. >> >> SS>> Regards >> SS>> swami >> >> >>> -----Original Message----- >> >>> From: davinci-linux-open-source- >> >>> bounces+swami.iyer=ti.com at linux.davincidsp.com [mailto:davinci-linux- >> open- >> >>> source-bounces+swami.iyer=ti.com at linux.davincidsp.com] On Behalf Of >> David >> >>> Goshadze >> >>> Sent: Wednesday, February 24, 2010 11:59 PM >> >>> To: davinci-linux-open-source at linux.davincidsp.com >> >>> Subject: 2.6.32 musb_hdrc fails to load (DM6446) >> >>> >> >>> Hi all! >> >>> >> >>> Please help with the following problem: >> >>> >> >>> I successfully loaded an built 2.6.32 for our DM6446 based board. >> >>> >> >>> Everything's just fine except I cannot load musb_hdrc driver. >> >>> I got: >> >>> modprobe musb_hdrc : version 6.0, cppi-dma, peripherial, debug=0 >> >>> FATAL: Error inserting musb_hdrc >> >>> (/lib/modules/2/6/32/kernel/drivers/usb/musb/musb_hdrc.ko): No such >> device >> >>> nop_usb_xceiv loaded successfully. >> >>> >> >>> use_dma=n doesn't help. >> >>> >> >>> Spending 2 days trying various kernel configurations and googling >> didn't >> >>> help. >> >>> >> >>> With 2.6.10 (mvl) everything was fine. >> >>> >> >>> I'm nearly gone mad with this. >> >>> >> >>> David. >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Davinci-linux-open-source mailing list >> >>> Davinci-linux-open-source at linux.davincidsp.com >> >>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source >> >> >> >> SS> ___________________________ >> SS> David Goshadze, >> SS> Chief project developer, >> SS> PLC Digimeq, >> SS> 5, Vozdvizhenka str. >> SS> Moscow, Russian Federation >> >> SS> Ph +7 495 9505231 >> SS> Mob +7 916 604 56 93 >> SS> Fax +7 495 9505231 >> SS> dato at digimeq.ru >> SS> www.digimeq.com >> >> SS> _______________________________________________ >> SS> Davinci-linux-open-source mailing list >> SS> Davinci-linux-open-source at linux.davincidsp.com >> SS> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source >> >> >> ___________________________ >> David Goshadze, >> Chief project developer, >> PLC Digimeq, >> 5, Vozdvizhenka str. >> Moscow, Russian Federation >> >> Ph +7 495 9505231 >> Mob +7 916 604 56 93 >> Fax +7 495 9505231 >> dato at digimeq.ru >> www.digimeq.com >> >> _______________________________________________ >> Davinci-linux-open-source mailing list >> Davinci-linux-open-source at linux.davincidsp.com >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___________________________ David Goshadze, Chief project developer, PLC Digimeq, 5, Vozdvizhenka str. Moscow, Russian Federation Ph +7 495 9505231 Mob +7 916 604 56 93 Fax +7 495 9505231 dato at digimeq.ru www.digimeq.com From dilip814 at gmail.com Wed Mar 3 12:44:55 2010 From: dilip814 at gmail.com (Dilip Patel) Date: Wed, 3 Mar 2010 12:44:55 -0600 Subject: IRQ#0 getting disabled automatically after 25-30mins Message-ID: <518dd75e1003031044s1dcffa23gbfb1ca93c32c4ce9@mail.gmail.com> Hi All, I developed the video capture driver which able to capture the 2 channel video data on DM365. I am facing the issue about IRQ#0 getting disabled automatically after 20-30 minutes. I mapped IRQ with VDINT_0 which is used for video capture port interrupt. I can not understand why it behaving like this. If any one is having idea why kernel gets disabled the interrupt please let me know that could be helpful to me. Below the kernel message I got on console after 20-30 minutes. irq 0: nobody cared (try booting with the "irqpoll" option) > handlers: > [] (ccdcInterruptISR+0x0/0x68 [csl]) > Disabling IRQ # -- Regards, Dilip -------------- next part -------------- An HTML attachment was scrubbed... URL: From swami.iyer at ti.com Thu Mar 4 02:01:48 2010 From: swami.iyer at ti.com (Subbrathnam, Swaminathan) Date: Thu, 4 Mar 2010 13:31:48 +0530 Subject: 2.6.32 musb_hdrc fails to load (DM6446) In-Reply-To: <3110095842.20100303194103@digimeq.ru> References: <1284591885.20100224212923@digimeq.ru> , <1341891187.20100227153538@digimeq.ru> <18610177235.20100302151628@digimeq.ru> <3110095842.20100303194103@digimeq.ru> Message-ID: David, You would have to provide an appropriate way of controlling the charge pump on your board. You would have to do the same in davinci.c file (at this point in time). It seems that we are invoking TI EVM way of controlling the charge pump but that is not the case with you and hence the crash. Regards swami > -----Original Message----- > From: davinci-linux-open-source-bounces at linux.davincidsp.com > [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf > Of David Goshadze > Sent: Wednesday, March 03, 2010 10:11 PM > To: davinci-linux-open-source at linux.davincidsp.com > Subject: Re: 2.6.32 musb_hdrc fails to load (DM6446) > > Swami, > > as I told you calling usb_setup succeeds, but kernel crashes while > loading musb_hdrc: > > > ************************************************************************** > ***************** > > musb_hdrc: version 6.0, pio, peripheral, debug=0 > bus: 'platform': really_probe: probing driver musb_hdrc with device > musb_hdrc > bus: 'platform': really_probe: probing driver nop_usb_xceiv with device > nop_usb_xceiv > BY DTG: __gpio_cansleep called with gpio = 160 > Unable to handle kernel NULL pointer dereference at virtual address > 00000020 > pgd = c1114000 > [00000020] *pgd=811ba031, *pte=00000000, *ppte=00000000 > Internal error: Oops: 17 [#1] PREEMPT > last sysfs file: > /sys/devices/platform/davinci_nand.0/mtd/mtd4/mtdblock4/removable > Modules linked in: musb_hdrc(+) nop_usb_xceiv > CPU: 0 Not tainted (2.6.32 #40) > PC is at gpio_set_value_cansleep+0x2c/0x5c > LR is at gpio_set_value_cansleep+0x18/0x5c > pc : [] lr : [] psr: 40000013 > sp : c2b47dc0 ip : 00003411 fp : c02d0b28 > r10: 00000000 r9 : c02d0b20 r8 : c3c26360 > r7 : 00147900 r6 : 00000001 r5 : 000000a0 r4 : 00000000 > r3 : c0304940 r2 : 00000780 r1 : c0294777 r0 : c02947a9 > Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user > Control: 0005317f Table: 81114000 DAC: 00000015 > Process modprobe (pid: 278, stack limit = 0xc2b46270) > Stack: (0xc2b47dc0 to 0xc2b48000) > 7dc0: 00000000 bf00b310 fec64000 bf006e20 c1472000 c1472000 fec64000 > bf00fc18 > 7de0: c02d0bd8 c1472000 c02d0b00 00000000 c3c26360 bf00f354 c3803180 > 00000001 > 7e00: 00000000 00000000 0000000c fec64000 c1472044 c014bcb8 c2b47e6c > 00000ba0 > 7e20: a0000013 c3806850 00000000 000000d0 c039dadc c00d1d00 c384b240 > c3805000 > 7e40: c3437520 c3437520 c2b47e90 c009db4c c2b47e58 c00d25dc 00000006 > 17d828dc > 7e60: c384b240 c00d21c8 c3c27540 c3c27540 c2b47e90 00000000 c3c27540 > c2b47e90 > 7e80: c384b240 00000001 00000000 c00d3128 c384b240 c3437520 00000000 > c02d0b28 > 7ea0: c02d0b28 bf00b29c c02de300 c3c26360 c2b46000 00000000 00000000 > c01737b4 > 7ec0: c02d0b28 c01728dc c3849540 c02d0b28 c2b47ed8 c02d0b28 c02d0b5c > bf00b29c > 7ee0: c02de300 c0172a48 00000000 c01729e8 bf00b29c c0172088 c3803638 > c384a1b0 > 7f00: 00000001 bf00b29c bf00b29c c01719b0 bf009cb6 bf009cb6 c2b47f18 > 00000001 > 7f20: bf00b288 bf00b29c 00000000 c0021064 000160d0 c0172d1c 00000001 > bf00b288 > 7f40: bf00f000 00000000 c0021064 c0173a24 00000000 bf00b328 bf00f000 > c00203ac > 7f60: 0000c074 bf00b328 00000000 40164000 c0021064 00000000 bf00b328 > 00000000 > 7f80: 40164000 c005e294 40164000 0000c074 00016230 0000979c 00000000 > 00000000 > 7fa0: 00000080 c0020ee0 0000979c 00000000 40164000 0000c074 00016230 > 00016230 > 7fc0: 0000979c 00000000 00000000 00000080 00000000 000160dc 000160d0 > 00000000 > 7fe0: 00016240 be916a04 0000b208 400fd7d4 60000010 40164000 e59de040 > e28dd048 > [] (gpio_set_value_cansleep+0x2c/0x5c) from [] > (davinci_source_power+0x34/0x4c [musb_hdrc]) > [] (davinci_source_power+0x34/0x4c [musb_hdrc]) from > [] (musb_platform_init+0x5c/0xd4 [musb_hdrc]) > [] (musb_platform_init+0x5c/0xd4 [musb_hdrc]) from [] > (musb_probe+0x1c8/0xa30 [musb_hdrc]) > [] (musb_probe+0x1c8/0xa30 [musb_hdrc]) from [] > (platform_drv_probe+0x18/0x1c) > [] (platform_drv_probe+0x18/0x1c) from [] > (driver_probe_device+0x114/0x220) > [] (driver_probe_device+0x114/0x220) from [] > (__driver_attach+0x60/0x84) > [] (__driver_attach+0x60/0x84) from [] > (bus_for_each_dev+0x44/0x74) > [] (bus_for_each_dev+0x44/0x74) from [] > (bus_add_driver+0xa8/0x234) > [] (bus_add_driver+0xa8/0x234) from [] > (driver_register+0xa8/0x134) > [] (driver_register+0xa8/0x134) from [] > (platform_driver_probe+0x18/0x98) > [] (platform_driver_probe+0x18/0x98) from [] > (do_one_initcall+0x5c/0x1bc) > [] (do_one_initcall+0x5c/0x1bc) from [] > (sys_init_module+0xbc/0x1e8) > [] (sys_init_module+0xbc/0x1e8) from [] > (ret_fast_syscall+0x0/0x28) > Code: e0020593 e59f302c e59f002c e7934002 (e5941020) > bus: 'platform': add driver watchdog > ---[ end trace 49c8ae5707d7b633 ]--- > udevd-event[271]: '/sbin/modprobe -b platform:musb_hdrc' abnormal exit > > ************************************************************************** > ***************** > > > As I can see davinci_source_power from musb/davinci.c calls > gpio_set_value_cansleep while chip structure is not initialized. > I'll try to disable this call. > > > Thanks. > David. > > > SS> David, > SS> I was assuming that you are using TI EVM platform. If > SS> you are using your own platform you can call the usb_setup > SS> directly from your board init file. > > SS> Regards > SS> swami > > >> -----Original Message----- > >> From: davinci-linux-open-source-bounces at linux.davincidsp.com > >> [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On > Behalf > >> Of David Goshadze > >> Sent: Tuesday, March 02, 2010 5:46 PM > >> To: davinci-linux-open-source at linux.davincidsp.com > >> Subject: Re: 2.6.32 musb_hdrc fails to load (DM6446) > >> > >> Swami, Thanks again for help. > >> > >> I compiled I2C Support, though my board doesn't have one. > >> As I noticed, due to dev->bus->probe failure for I2C devices, > >> evm_u35_setup is never called. > >> > >> Can you suggest some workaround? (calling usb_setup registered USB > >> devise, but crashed kernel later as expected, due to chip was not > >> registered). > >> > >> David. > >> > >> > >> > >> SS> David, > >> > >> SS> Did you compile in the I2c Expander support in the kernel. I > >> SS> think you are missing this part of the config. Can you confirm. > >> > >> SS> regards > >> SS> swami > >> > >> SS> ________________________________________ > >> SS> From: davinci-linux-open-source-bounces at linux.davincidsp.com > >> SS> [davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf > >> SS> Of David Goshadze [dato at digimeq.ru] > >> SS> Sent: Saturday, February 27, 2010 6:05 PM > >> SS> To: davinci-linux-open-source at linux.davincidsp.com > >> SS> Subject: Re: 2.6.32 musb_hdrc fails to load (DM6446) > >> > >> SS> Hi all again. > >> > >> SS> Digging into sources I discovered that setup_usb (from > >> SS> arch/arm/mach-davinci/usb.c) is never called, thus platform device > >> SS> register for usb_dev is also never called. > >> > >> SS> Wondering for a reason. > >> SS> Please help. > >> > >> SS> David. > >> > >> SS>> David, > >> SS>> Could you try the aarago git davinci tree? > >> > >> SS>> From the below log it seems there could be a > >> SS>> configuration issue between the base port and the driver init. > >> > >> SS>> Regards > >> SS>> swami > >> > >> >>> -----Original Message----- > >> >>> From: davinci-linux-open-source- > >> >>> bounces+swami.iyer=ti.com at linux.davincidsp.com [mailto:davinci- > linux- > >> open- > >> >>> source-bounces+swami.iyer=ti.com at linux.davincidsp.com] On Behalf Of > >> David > >> >>> Goshadze > >> >>> Sent: Wednesday, February 24, 2010 11:59 PM > >> >>> To: davinci-linux-open-source at linux.davincidsp.com > >> >>> Subject: 2.6.32 musb_hdrc fails to load (DM6446) > >> >>> > >> >>> Hi all! > >> >>> > >> >>> Please help with the following problem: > >> >>> > >> >>> I successfully loaded an built 2.6.32 for our DM6446 based board. > >> >>> > >> >>> Everything's just fine except I cannot load musb_hdrc driver. > >> >>> I got: > >> >>> modprobe musb_hdrc : version 6.0, cppi-dma, peripherial, debug=0 > >> >>> FATAL: Error inserting musb_hdrc > >> >>> (/lib/modules/2/6/32/kernel/drivers/usb/musb/musb_hdrc.ko): No such > >> device > >> >>> nop_usb_xceiv loaded successfully. > >> >>> > >> >>> use_dma=n doesn't help. > >> >>> > >> >>> Spending 2 days trying various kernel configurations and googling > >> didn't > >> >>> help. > >> >>> > >> >>> With 2.6.10 (mvl) everything was fine. > >> >>> > >> >>> I'm nearly gone mad with this. > >> >>> > >> >>> David. > >> >>> > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> Davinci-linux-open-source mailing list > >> >>> Davinci-linux-open-source at linux.davincidsp.com > >> >>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- > source > >> > >> > >> > >> SS> ___________________________ > >> SS> David Goshadze, > >> SS> Chief project developer, > >> SS> PLC Digimeq, > >> SS> 5, Vozdvizhenka str. > >> SS> Moscow, Russian Federation > >> > >> SS> Ph +7 495 9505231 > >> SS> Mob +7 916 604 56 93 > >> SS> Fax +7 495 9505231 > >> SS> dato at digimeq.ru > >> SS> www.digimeq.com > >> > >> SS> _______________________________________________ > >> SS> Davinci-linux-open-source mailing list > >> SS> Davinci-linux-open-source at linux.davincidsp.com > >> SS> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- > source > >> > >> > >> ___________________________ > >> David Goshadze, > >> Chief project developer, > >> PLC Digimeq, > >> 5, Vozdvizhenka str. > >> Moscow, Russian Federation > >> > >> Ph +7 495 9505231 > >> Mob +7 916 604 56 93 > >> Fax +7 495 9505231 > >> dato at digimeq.ru > >> www.digimeq.com > >> > >> _______________________________________________ > >> Davinci-linux-open-source mailing list > >> Davinci-linux-open-source at linux.davincidsp.com > >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > > ___________________________ > David Goshadze, > Chief project developer, > PLC Digimeq, > 5, Vozdvizhenka str. > Moscow, Russian Federation > > Ph +7 495 9505231 > Mob +7 916 604 56 93 > Fax +7 495 9505231 > dato at digimeq.ru > www.digimeq.com > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source From gasparini at imavis.com Thu Mar 4 02:34:11 2010 From: gasparini at imavis.com (Andrea Gasparini) Date: Thu, 4 Mar 2010 09:34:11 +0100 Subject: IRQ#0 getting disabled automatically after 25-30mins In-Reply-To: <518dd75e1003031044s1dcffa23gbfb1ca93c32c4ce9@mail.gmail.com> References: <518dd75e1003031044s1dcffa23gbfb1ca93c32c4ce9@mail.gmail.com> Message-ID: <201003040934.11892.gasparini@imavis.com> Dilip Patel spiffera, alle Wednesday 03 March 2010 circa: > I mapped IRQ with VDINT_0 which is used for video capture port > interrupt. I can not understand why it behaving like this. If any one > is having idea why kernel gets disabled the interrupt please let me > know that could be helpful to me. Below the kernel message I got on > console after 20-30 minutes Did you return IRQ_HANDLED at the end of your handler? bye! -- Andrea Gasparini ---- ImaVis S.r.l. ---- web: www.imavis.com From dato at digimeq.ru Thu Mar 4 04:43:12 2010 From: dato at digimeq.ru (David Goshadze) Date: Thu, 4 Mar 2010 13:43:12 +0300 Subject: 2.6.32 musb_hdrc fails to load (DM6446) In-Reply-To: References: <1284591885.20100224212923@digimeq.ru> , <1341891187.20100227153538@digimeq.ru> <18610177235.20100302151628@digimeq.ru> <3110095842.20100303194103@digimeq.ru> Message-ID: <12496044.20100304134312@digimeq.ru> Hello Swami, Yes, davinci_source_power is contolling VBUS power through I2C/pcf8754 via gpio_set_value_cansleep. We do not need to be a usb host, thus disabling this call solved my problem. Thanks again. David. SS> David, SS> You would have to provide an appropriate way of SS> controlling the charge pump on your board. You would have to do SS> the same in davinci.c file (at this point in time). SS> It seems that we are invoking TI EVM way of controlling SS> the charge pump but that is not the case with you and hence the crash. SS> Regards SS> swami >> -----Original Message----- >> From: davinci-linux-open-source-bounces at linux.davincidsp.com >> [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf >> Of David Goshadze >> Sent: Wednesday, March 03, 2010 10:11 PM >> To: davinci-linux-open-source at linux.davincidsp.com >> Subject: Re: 2.6.32 musb_hdrc fails to load (DM6446) >> >> Swami, >> >> as I told you calling usb_setup succeeds, but kernel crashes while >> loading musb_hdrc: >> >> >> ************************************************************************** >> ***************** >> >> musb_hdrc: version 6.0, pio, peripheral, debug=0 >> bus: 'platform': really_probe: probing driver musb_hdrc with device >> musb_hdrc >> bus: 'platform': really_probe: probing driver nop_usb_xceiv with device >> nop_usb_xceiv >> BY DTG: __gpio_cansleep called with gpio = 160 >> Unable to handle kernel NULL pointer dereference at virtual address >> 00000020 >> pgd = c1114000 >> [00000020] *pgd=811ba031, *pte=00000000, *ppte=00000000 >> Internal error: Oops: 17 [#1] PREEMPT >> last sysfs file: >> /sys/devices/platform/davinci_nand.0/mtd/mtd4/mtdblock4/removable >> Modules linked in: musb_hdrc(+) nop_usb_xceiv >> CPU: 0 Not tainted (2.6.32 #40) >> PC is at gpio_set_value_cansleep+0x2c/0x5c >> LR is at gpio_set_value_cansleep+0x18/0x5c >> pc : [] lr : [] psr: 40000013 >> sp : c2b47dc0 ip : 00003411 fp : c02d0b28 >> r10: 00000000 r9 : c02d0b20 r8 : c3c26360 >> r7 : 00147900 r6 : 00000001 r5 : 000000a0 r4 : 00000000 >> r3 : c0304940 r2 : 00000780 r1 : c0294777 r0 : c02947a9 >> Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user >> Control: 0005317f Table: 81114000 DAC: 00000015 >> Process modprobe (pid: 278, stack limit = 0xc2b46270) >> Stack: (0xc2b47dc0 to 0xc2b48000) >> 7dc0: 00000000 bf00b310 fec64000 bf006e20 c1472000 c1472000 fec64000 >> bf00fc18 >> 7de0: c02d0bd8 c1472000 c02d0b00 00000000 c3c26360 bf00f354 c3803180 >> 00000001 >> 7e00: 00000000 00000000 0000000c fec64000 c1472044 c014bcb8 c2b47e6c >> 00000ba0 >> 7e20: a0000013 c3806850 00000000 000000d0 c039dadc c00d1d00 c384b240 >> c3805000 >> 7e40: c3437520 c3437520 c2b47e90 c009db4c c2b47e58 c00d25dc 00000006 >> 17d828dc >> 7e60: c384b240 c00d21c8 c3c27540 c3c27540 c2b47e90 00000000 c3c27540 >> c2b47e90 >> 7e80: c384b240 00000001 00000000 c00d3128 c384b240 c3437520 00000000 >> c02d0b28 >> 7ea0: c02d0b28 bf00b29c c02de300 c3c26360 c2b46000 00000000 00000000 >> c01737b4 >> 7ec0: c02d0b28 c01728dc c3849540 c02d0b28 c2b47ed8 c02d0b28 c02d0b5c >> bf00b29c >> 7ee0: c02de300 c0172a48 00000000 c01729e8 bf00b29c c0172088 c3803638 >> c384a1b0 >> 7f00: 00000001 bf00b29c bf00b29c c01719b0 bf009cb6 bf009cb6 c2b47f18 >> 00000001 >> 7f20: bf00b288 bf00b29c 00000000 c0021064 000160d0 c0172d1c 00000001 >> bf00b288 >> 7f40: bf00f000 00000000 c0021064 c0173a24 00000000 bf00b328 bf00f000 >> c00203ac >> 7f60: 0000c074 bf00b328 00000000 40164000 c0021064 00000000 bf00b328 >> 00000000 >> 7f80: 40164000 c005e294 40164000 0000c074 00016230 0000979c 00000000 >> 00000000 >> 7fa0: 00000080 c0020ee0 0000979c 00000000 40164000 0000c074 00016230 >> 00016230 >> 7fc0: 0000979c 00000000 00000000 00000080 00000000 000160dc 000160d0 >> 00000000 >> 7fe0: 00016240 be916a04 0000b208 400fd7d4 60000010 40164000 e59de040 >> e28dd048 >> [] (gpio_set_value_cansleep+0x2c/0x5c) from [] >> (davinci_source_power+0x34/0x4c [musb_hdrc]) >> [] (davinci_source_power+0x34/0x4c [musb_hdrc]) from >> [] (musb_platform_init+0x5c/0xd4 [musb_hdrc]) >> [] (musb_platform_init+0x5c/0xd4 [musb_hdrc]) from [] >> (musb_probe+0x1c8/0xa30 [musb_hdrc]) >> [] (musb_probe+0x1c8/0xa30 [musb_hdrc]) from [] >> (platform_drv_probe+0x18/0x1c) >> [] (platform_drv_probe+0x18/0x1c) from [] >> (driver_probe_device+0x114/0x220) >> [] (driver_probe_device+0x114/0x220) from [] >> (__driver_attach+0x60/0x84) >> [] (__driver_attach+0x60/0x84) from [] >> (bus_for_each_dev+0x44/0x74) >> [] (bus_for_each_dev+0x44/0x74) from [] >> (bus_add_driver+0xa8/0x234) >> [] (bus_add_driver+0xa8/0x234) from [] >> (driver_register+0xa8/0x134) >> [] (driver_register+0xa8/0x134) from [] >> (platform_driver_probe+0x18/0x98) >> [] (platform_driver_probe+0x18/0x98) from [] >> (do_one_initcall+0x5c/0x1bc) >> [] (do_one_initcall+0x5c/0x1bc) from [] >> (sys_init_module+0xbc/0x1e8) >> [] (sys_init_module+0xbc/0x1e8) from [] >> (ret_fast_syscall+0x0/0x28) >> Code: e0020593 e59f302c e59f002c e7934002 (e5941020) >> bus: 'platform': add driver watchdog >> ---[ end trace 49c8ae5707d7b633 ]--- >> udevd-event[271]: '/sbin/modprobe -b platform:musb_hdrc' abnormal exit >> >> ************************************************************************** >> ***************** >> >> >> As I can see davinci_source_power from musb/davinci.c calls >> gpio_set_value_cansleep while chip structure is not initialized. >> I'll try to disable this call. >> >> >> Thanks. >> David. >> >> >> SS> David, >> SS> I was assuming that you are using TI EVM platform. If >> SS> you are using your own platform you can call the usb_setup >> SS> directly from your board init file. >> >> SS> Regards >> SS> swami >> >> >> -----Original Message----- >> >> From: davinci-linux-open-source-bounces at linux.davincidsp.com >> >> [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On >> Behalf >> >> Of David Goshadze >> >> Sent: Tuesday, March 02, 2010 5:46 PM >> >> To: davinci-linux-open-source at linux.davincidsp.com >> >> Subject: Re: 2.6.32 musb_hdrc fails to load (DM6446) >> >> >> >> Swami, Thanks again for help. >> >> >> >> I compiled I2C Support, though my board doesn't have one. >> >> As I noticed, due to dev->bus->probe failure for I2C devices, >> >> evm_u35_setup is never called. >> >> >> >> Can you suggest some workaround? (calling usb_setup registered USB >> >> devise, but crashed kernel later as expected, due to chip was not >> >> registered). >> >> >> >> David. >> >> >> >> >> >> >> >> SS> David, >> >> >> >> SS> Did you compile in the I2c Expander support in the kernel. I >> >> SS> think you are missing this part of the config. Can you confirm. >> >> >> >> SS> regards >> >> SS> swami >> >> >> >> SS> ________________________________________ >> >> SS> From: davinci-linux-open-source-bounces at linux.davincidsp.com >> >> SS> [davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf >> >> SS> Of David Goshadze [dato at digimeq.ru] >> >> SS> Sent: Saturday, February 27, 2010 6:05 PM >> >> SS> To: davinci-linux-open-source at linux.davincidsp.com >> >> SS> Subject: Re: 2.6.32 musb_hdrc fails to load (DM6446) >> >> >> >> SS> Hi all again. >> >> >> >> SS> Digging into sources I discovered that setup_usb (from >> >> SS> arch/arm/mach-davinci/usb.c) is never called, thus platform device >> >> SS> register for usb_dev is also never called. >> >> >> >> SS> Wondering for a reason. >> >> SS> Please help. >> >> >> >> SS> David. >> >> >> >> SS>> David, >> >> SS>> Could you try the aarago git davinci tree? >> >> >> >> SS>> From the below log it seems there could be a >> >> SS>> configuration issue between the base port and the driver init. >> >> >> >> SS>> Regards >> >> SS>> swami >> >> >> >> >>> -----Original Message----- >> >> >>> From: davinci-linux-open-source- >> >> >>> bounces+swami.iyer=ti.com at linux.davincidsp.com [mailto:davinci- >> linux- >> >> open- >> >> >>> source-bounces+swami.iyer=ti.com at linux.davincidsp.com] On Behalf Of >> >> David >> >> >>> Goshadze >> >> >>> Sent: Wednesday, February 24, 2010 11:59 PM >> >> >>> To: davinci-linux-open-source at linux.davincidsp.com >> >> >>> Subject: 2.6.32 musb_hdrc fails to load (DM6446) >> >> >>> >> >> >>> Hi all! >> >> >>> >> >> >>> Please help with the following problem: >> >> >>> >> >> >>> I successfully loaded an built 2.6.32 for our DM6446 based board. >> >> >>> >> >> >>> Everything's just fine except I cannot load musb_hdrc driver. >> >> >>> I got: >> >> >>> modprobe musb_hdrc : version 6.0, cppi-dma, peripherial, debug=0 >> >> >>> FATAL: Error inserting musb_hdrc >> >> >>> (/lib/modules/2/6/32/kernel/drivers/usb/musb/musb_hdrc.ko): No such >> >> device >> >> >>> nop_usb_xceiv loaded successfully. >> >> >>> >> >> >>> use_dma=n doesn't help. >> >> >>> >> >> >>> Spending 2 days trying various kernel configurations and googling >> >> didn't >> >> >>> help. >> >> >>> >> >> >>> With 2.6.10 (mvl) everything was fine. >> >> >>> >> >> >>> I'm nearly gone mad with this. >> >> >>> >> >> >>> David. >> >> >>> >> >> >>> >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Davinci-linux-open-source mailing list >> >> >>> Davinci-linux-open-source at linux.davincidsp.com >> >> >>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- >> source >> >> >> >> >> >> >> >> SS> ___________________________ >> >> SS> David Goshadze, >> >> SS> Chief project developer, >> >> SS> PLC Digimeq, >> >> SS> 5, Vozdvizhenka str. >> >> SS> Moscow, Russian Federation >> >> >> >> SS> Ph +7 495 9505231 >> >> SS> Mob +7 916 604 56 93 >> >> SS> Fax +7 495 9505231 >> >> SS> dato at digimeq.ru >> >> SS> www.digimeq.com >> >> >> >> SS> _______________________________________________ >> >> SS> Davinci-linux-open-source mailing list >> >> SS> Davinci-linux-open-source at linux.davincidsp.com >> >> SS> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- >> source >> >> >> >> >> >> ___________________________ >> >> David Goshadze, >> >> Chief project developer, >> >> PLC Digimeq, >> >> 5, Vozdvizhenka str. >> >> Moscow, Russian Federation >> >> >> >> Ph +7 495 9505231 >> >> Mob +7 916 604 56 93 >> >> Fax +7 495 9505231 >> >> dato at digimeq.ru >> >> www.digimeq.com >> >> >> >> _______________________________________________ >> >> Davinci-linux-open-source mailing list >> >> Davinci-linux-open-source at linux.davincidsp.com >> >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source >> >> >> >> ___________________________ >> David Goshadze, >> Chief project developer, >> PLC Digimeq, >> 5, Vozdvizhenka str. >> Moscow, Russian Federation >> >> Ph +7 495 9505231 >> Mob +7 916 604 56 93 >> Fax +7 495 9505231 >> dato at digimeq.ru >> www.digimeq.com >> >> _______________________________________________ >> Davinci-linux-open-source mailing list >> Davinci-linux-open-source at linux.davincidsp.com >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___________________________ David Goshadze, Chief project developer, PLC Digimeq, 5, Vozdvizhenka str. Moscow, Russian Federation Ph +7 495 9505231 Mob +7 916 604 56 93 Fax +7 495 9505231 dato at digimeq.ru www.digimeq.com From Alex.Tarter at ultra-cis.com Thu Mar 4 05:58:32 2010 From: Alex.Tarter at ultra-cis.com (Alex Tarter) Date: Thu, 4 Mar 2010 11:58:32 -0000 Subject: SYSCLK5, SPI_CLK enable Message-ID: <5B30463C3CBD6E42AF0DBB4E95DB3857677447@SCS-21.ultra-scs.com> I'm using a dm6446 evm and am trying to enable SPI. I've modified the drivers and set up the registers OK, however when I come to actually outputting a message, nothing comes out on the DC3 pins. If I change the polarity of the CLK I can see the pin go high. My question is do I need to initialise any of the clocks such as SYSCLK5 so that it feeds out onto the pins? I've initialised SPI in the PINMUX1 register (set bits 8 & 9), and written and read all of the SPI registers to make sure they're correct. I can see my code enable the SPI drivers and set the enable pins etc, but nothing comes out when I write to SPIDAT1. My code checks the RXEMPTY flag in SPIBUF after each Tx and its always cleared and loopback mode works. This is driving me insane! Is there some PLL or Clock that I'm not powering up or enabling that means my data isn't being clocked out even though the software is all set up? Thanks, Alex Alex Tarter Ultra Electronics Communication & Integrated Systems www.ultra-electronics.com Please note that our email address has changed to firstname.lastname at ultra-cis.com. This is to reflect the change in name to Ultra Electronics Communication and Integrated Systems, a business name of Ultra Electronics Limited. DISCLAIMER This e-mail from Ultra Electronics Limited and any attachments to it are confidential to the intended recipient and may also be privileged. If you have received it in error please notify the sender and delete it from your system. If you are not the intended recipient you must not copy it or use it for any purpose nor disclose or distribute its contents to any other person. All communications may be subject to interception or monitoring for operational and/or security purposes. Please rely on your own virus checking as the sender cannot accept any liability for any damage arising from any bug or virus infection. Ultra Electronics Limited is a company registered in England and Wales, registration number 2830644. The address of its registered office is 417 Bridport Road, Greenford, Middlesex, UB6 8UA. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Tarter at ultra-cis.com Thu Mar 4 08:33:01 2010 From: Alex.Tarter at ultra-cis.com (Alex Tarter) Date: Thu, 4 Mar 2010 14:33:01 -0000 Subject: SYSCLK5, SPI_CLK enable Message-ID: <5B30463C3CBD6E42AF0DBB4E95DB38576774B9@SCS-21.ultra-scs.com> Forgot to mention I've checked the SPI clock module register (MDSTAT22) and it says that the state is enabled. I've also checked PLL1 SYSTAT, PLLDIV5 and PLLCTR registers and it all looks good. Alex Alex Tarter Ultra Electronics Communication & Integrated Systems www.ultra-electronics.com Please note that our email address has changed to firstname.lastname at ultra-cis.com. This is to reflect the change in name to Ultra Electronics Communication and Integrated Systems, a business name of Ultra Electronics Limited. DISCLAIMER This e-mail from Ultra Electronics Limited and any attachments to it are confidential to the intended recipient and may also be privileged. If you have received it in error please notify the sender and delete it from your system. If you are not the intended recipient you must not copy it or use it for any purpose nor disclose or distribute its contents to any other person. All communications may be subject to interception or monitoring for operational and/or security purposes. Please rely on your own virus checking as the sender cannot accept any liability for any damage arising from any bug or virus infection. Ultra Electronics Limited is a company registered in England and Wales, registration number 2830644. The address of its registered office is 417 Bridport Road, Greenford, Middlesex, UB6 8UA.________________________________ From: Alex Tarter Sent: 04 March 2010 11:59 To: 'davinci-linux-open-source at linux.davincidsp.com' Subject: SYSCLK5, SPI_CLK enable I'm using a dm6446 evm and am trying to enable SPI. I've modified the drivers and set up the registers OK, however when I come to actually outputting a message, nothing comes out on the DC3 pins. If I change the polarity of the CLK I can see the pin go high. My question is do I need to initialise any of the clocks such as SYSCLK5 so that it feeds out onto the pins? I've initialised SPI in the PINMUX1 register (set bits 8 & 9), and written and read all of the SPI registers to make sure they're correct. I can see my code enable the SPI drivers and set the enable pins etc, but nothing comes out when I write to SPIDAT1. My code checks the RXEMPTY flag in SPIBUF after each Tx and its always cleared and loopback mode works. This is driving me insane! Is there some PLL or Clock that I'm not powering up or enabling that means my data isn't being clocked out even though the software is all set up? Thanks, Alex Alex Tarter Ultra Electronics Communication & Integrated Systems www.ultra-electronics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepaks at hcl.in Thu Mar 4 10:03:54 2010 From: deepaks at hcl.in (Deepak Shankar-ERS,HCLTech.) Date: Thu, 4 Mar 2010 21:33:54 +0530 Subject: Aieee Killing Interrupt handler after 2 days. In-Reply-To: <4B8DC7B0.2090907@gmail.com> References: <4B8BE9E2.3020401@gmail.com> <4B8DC7B0.2090907@gmail.com> Message-ID: Madhu, Thank you for the inputs - It seems that the hrtimers are intensively used in the mv Linux. arch/arm/mach-davinci/built-in.o(.text+0x144): In function `davinci_gettimeoffset': i2c-client.c: undefined reference to `arch_cycle_to_nsec' I think the hrtimers provides the basic timing in the mvl 4.0.1 kernel tree. What do you mean by latest davinci sources - please are you referring to 2.6.33 mainline kernel. Could you please provide me pointers in this regard? Cheers, Deepak Shankar V -----Original Message----- From: Madhu [mailto:madhu.chinakonda at gmail.com] Sent: Wednesday, March 03, 2010 7:52 AM To: Deepak Shankar-ERS,HCLTech. Cc: davinci-linux-open-source at linux.davincidsp.com; davinci-linux-open-source-bounces at linux.davincidsp.com Subject: Re: Aieee Killing Interrupt handler after 2 days. Deepak, I dont see this function in the latest davinci sources so I cant check. Between can you check by disabling power management . These are just to confirm whether the conflict exists. Regards, Madhu On 03/03/2010 09:12 AM, Deepak Shankar-ERS,HCLTech. wrote: > Madhu, > > I tried this - However the tree would not compile since the ../ti-davinci/arch/arm/mach-davinci/time.c uses the arch_cycle_to_nsec which is a part of the hrtimers. > > unsigned long davinci_gettimeoffset(void) { > unsigned long now, elapsed, nsec; > > now = davinci_timer32_read(davinci_timers[tid_freerun]); > elapsed = now - davinci_timer32_last; > > nsec = arch_cycle_to_nsec(elapsed); > return nsec / 1000; > } > > I'm not sure why hrtimers are made configurable then - this is specific to davinci/mv tree it seems! > > Please provide me any other pointer in this regard. > > Best Regards, > Deepak Shankar V > > -----Original Message----- > From: Madhu [mailto:madhu.chinakonda at gmail.com] > Sent: Monday, March 01, 2010 9:53 PM > To: Deepak Shankar-ERS,HCLTech. > Cc: davinci-linux-open-source at linux.davincidsp.com; > davinci-linux-open-source-bounces at linux.davincidsp.com > Subject: Re: Aieee Killing Interrupt handler after 2 days. > > Hello Deepak, > > From the log, I could see some problem or conflict between the hrtimer and pm. One way is you can try disabling hrtimer and check. > > > Regards, > Madhu > > On 03/01/2010 04:19 PM, Deepak Shankar-ERS,HCLTech. wrote: > >> Hello all, >> >> I have a system running based on mvl4.0.1-2.6.10 Linux in dm355 davinci. >> Now on a sporadic basis after 2 days or so, if I leave the sytem, the system crashes(Aieee) throwing the following crashdump. >> >> I could not make much out of the log, I have looked into my application and it seems to be fine. >> >> If any of you have faced a similar problem, could you please help me in finding out what is the problem. >> >> Please provide me any inputs in this regard. >> >> Start of dump: >> ********************************************************************* >> * >> **************************************** >> >> Internal error: Oops - undefined instruction: 0 [#1] >> >> Modules linked in: g_zero GPIOd cmemk PMd dm350mmap >> >> CPU: 0 >> >> PC is at 0xc021f048 >> >> LR is at do_hrtimers_expire_timers+0x1cc/0x228 >> >> pc : [] lr : [] Not tainted >> I'm not sure why hrtimers are made configurable then - this is specific to davinci/mv tree it seems! >> >> sp : c01cfe58 ip : c01d11e8 fp : c01cfe7c >> >> r10: c01d11e8 r9 : c0214ce0 r8 : c021ff50 >> >> r7 : c021ddfc r6 : c021ddfc r5 : c021ff48 r4 : c01ce000 >> >> r3 : 00000000 r2 : c021ff48 r1 : c021ff48 r0 : 40000440 >> >> Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment kernel >> >> Control: 5317F Table: 855B8000 DAC: 00000017 >> >> Process swapper (pid: 0, stack limit = 0xc01ce1a0) >> >> Stack: (0xc01cfe58 to 0xc01d0000) >> >> fe40: c006435c c01ce000 >> >> fe60: 00000001 bf00b10c c021d7fc c01cfe98 c01cfe94 c01cfe80 c0064724 >> c00643ac >> >> fe80: 00000103 c01ce000 c01cfecc c01cfe98 c0054bf8 c00646bc c021ddec >> c021ddfc >> >> fea0: c01ce000 c021d7b4 c01ce000 00000103 00000001 c021d590 0000000a >> c021d560 >> >> fec0: c01cfef4 c01cfed0 c0050070 c0054abc c01ce000 00000000 c003e90c >> 00000002 >> >> fee0: c01ce000 c01cff60 c01cff0c c01cfef8 c005014c c005002c c01ce000 >> c01ce000 >> >> ff00: c01cff24 c01cff10 c0050304 c0050124 c01ce000 c01cff94 c01cff5c >> c01cff28 >> >> ff20: c00304c0 c00502c8 00000000 c5b184a0 c02182d0 c01cff94 e1048000 >> c003e90c >> >> ff40: 00000002 c01ce000 00000001 800276bc c01cffb4 c01cff60 c002e780 >> c00303b0 >> >> ff60: 00000000 60000093 c0217fa0 60000013 c01ce000 c003eee8 c02201c4 >> c0226ad8 >> >> ff80: 800276ec 41069265 800276bc c01cffb4 c01cffa8 c01cffa8 c003e90c >> c003ef64 >> >> ffa0: 60000013 ffffffff c01cffcc c01cffb8 c0031004 c003eef8 00000000 >> c021481c >> >> ffc0: c01cfffc c01cffd0 c00087d8 c0030fc4 c0008304 00000000 00000000 >> c02174d8 >> >> ffe0: 00000000 00053175 c02174bc c01d0f10 00000000 c01d0000 8000809c >> c0008660 >> >> Backtrace: >> >> [] (do_hrtimers_expire_timers+0x0/0x228) from [] >> (do_high_res_timer+0x78/0xa0) >> >> r8 = C01CFE98 r7 = C021D7FC r6 = BF00B10C r5 = 00000001 >> >> r4 = C01CE000 >> >> [] (do_high_res_timer+0x0/0xa0) from [] >> (run_timer_softirq+0x14c/0x278) >> >> r5 = C01CE000 r4 = 00000103 >> >> [] (run_timer_softirq+0x0/0x278) from [] >> (___do_softirq+0x54/0xf8) >> >> [] (___do_softirq+0x0/0xf8) from [] >> (__do_softirq+0x38/0x58) >> >> [] (__do_softirq+0x0/0x58) from [] >> (irq_exit+0x4c/0x60) >> >> r5 = C01CE000 r4 = C01CE000 >> >> [] (irq_exit+0x0/0x60) from [] >> (asm_do_IRQ+0x120/0x138) >> >> r4 = C01CFF94 >> >> [] (asm_do_IRQ+0x0/0x138) from [] >> (__irq_svc+0x40/0x6c) >> >> [] (davinci_pm_idle+0x0/0x84) from [] >> (cpu_idle+0x50/0x88) >> >> [] (cpu_idle+0x0/0x88) from [] >> (start_kernel+0x188/0x1cc) >> >> r5 = C021481C r4 = 00000000 >> >> [] (start_kernel+0x0/0x1cc) from [<8000809c>] (0x8000809c) >> >> Code: c02fa5e0 c02fade0 c02fb5e0 00000009 (fffffed4) >> >> <0>Kernel panic - not syncing: Aiee, killing interrupt handler! >> >> ********************************************************************* >> * >> **************************************** >> End of dump: >> >> >> Cheers, >> Deepak Shankar V >> DISCLAIMER: >> --------------------------------------------------------------------- >> - >> ------------------------------------------------- >> >> The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. >> It shall not attach any liability on the originator or HCL or its >> affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. >> Any form of reproduction, dissemination, copying, disclosure, >> modification, distribution and / or publication of this message >> without the prior written consent of the author of this e-mail is >> strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. >> >> --------------------------------------------------------------------- >> - >> ------------------------------------------------- >> _______________________________________________ >> Davinci-linux-open-source mailing list >> Davinci-linux-open-source at linux.davincidsp.com >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-sourc >> e >> >> > > From fordham at tieline.com.au Thu Mar 4 18:02:09 2010 From: fordham at tieline.com.au (Grant Fordham) Date: Fri, 5 Mar 2010 08:02:09 +0800 Subject: DSPLink CPU loading very high on Linux PCI platform Message-ID: <84AE9FADA7A1C440807899CFD7E2016B5920E7@tlcex01.tieline.com.au> Hi, Does anyone have experience with dsplink on a Linux PCI platform? We're experiencing some performance issues and wondering whether it's something we're doing wrong or whether it's dsplink which has some serious performance issues. We're currently evaluating DSPLink as a possible IPC solution for a new low latency audio streaming product. The test setup is as follows: * Pentium 4 (2.4GHz) running 2.6.31 kernel with RT and bigphysarea patches * DSP/BIOS Link version 1.64 (with minor changes to support 2.6.31 kernel) * Following options used to configure dsplink: --platform=LINUXPC --nodsp=1 --dspcfg_0=DM648PCI --dspos_0=DSPBIOS5XX --gppos=RHEL4 --comps=ponslrmc --dspdma=1 * DM648 EVM from Lyrtech plugged into Pentium 4 PCI bus I've modified the MSGQ samples supplied with dsplink 1.64 slightly by making the gpp the message initiator and adding a usleep() call in the for loop. This is to vary the message send rate to match audio frame rates that we expect to handle in our final system. The following are some observations: With no usleep() call I see a round-trip delay of about 480us. CPU loading is about 70%. See output of top below (modified msgq sample app is called atest): PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2726 root -96 0 11560 1096 924 S 38.4 0.1 0:08.87 atest 2732 root 10 -10 0 0 0 S 29.8 0.0 0:06.82 DSPLINK_DPC_2 2728 root 10 -10 0 0 0 R 4.6 0.0 0:01.09 DSPLINK_DPC_0 2729 root -51 -5 0 0 0 S 1.0 0.0 0:00.21 irq/9-DSPLINK With usleep() call to set loop rate to 1ms (i.e. one MSGQ_put followed by one MSGQ_get every 1ms) CPU loading is about 32%. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2577 root -96 0 11560 1104 928 S 16.9 0.1 0:05.15 atest 2583 root 10 -10 0 0 0 S 12.9 0.0 0:03.89 DSPLINK_DPC_2 2579 root 10 -10 0 0 0 R 2.0 0.0 0:00.65 DSPLINK_DPC_0 2580 root -51 -5 0 0 0 S 0.7 0.0 0:00.16 irq/9-DSPLINK With usleep() call to set loop rate to 4ms (i.e. one MSGQ_put followed by one MSGQ_get every 4ms) CPU loading is about 9%. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2698 root -96 0 11560 1100 928 S 5.0 0.1 0:02.65 atest 2703 root 10 -10 0 0 0 S 3.3 0.0 0:01.91 DSPLINK_DPC_2 2699 root 10 -10 0 0 0 S 0.7 0.0 0:00.32 DSPLINK_DPC_0 186 root -51 -5 0 0 0 S 0.3 0.0 0:00.84 irq/9-acpi 2700 root -51 -5 0 0 0 S 0.3 0.0 0:00.05 irq/9-DSPLINK My question is, has anyone tested dsplink in a similar scenario and do the latency and cpu loading figures look comparable? I was expecting to see lower latency than this and much lower CPU loading. I read somewhere in the CodecEngine documentation that applications should limit CodecEngine transaction rate to about 7000 transactions per second (not sure which platform this applies to - maybe DM644x?). I would have expected that raw dsplink on a 2.4GHz P4 would be able to achieve far better performance than the measly 4000 transactions per second that I'm seeing (assuming that CE uses the MSGQ protocol of course, which I think it does). Ideas anyone? Regards, Grant This email has been processed by SmoothZap - www.smoothwall.net From iso at cypress.com Fri Mar 5 05:10:04 2010 From: iso at cypress.com (Arun Siluvery) Date: Fri, 5 Mar 2010 16:40:04 +0530 Subject: DM365EVM SPI usage Message-ID: <061CE9DF02274B38BB9B598E2177A3B3@india.cypress.com> Hello All, I am using dm365evm to interface with a cmos sensor using Imager interface connector(J10). The sensor supports only SPI to configure its registers and needs SPI_CLK, SPI_DATA, and SPI_EN. Could you please clarify the following and provide some suggestions regarding the SPI usage. 1. Only SPI4 can be used to communicate with the sensor using imager interface connector? 2. From the schematics, SPI_EN = SPI4_SDI_GPIO_MD2_CONN, SPI_CLK = SPI4_SCLK_CONN, SPI_DATA = SPI4_SDO_CONN; ofcourse PINMUX4 register need to be configured accordingly. 3. ~/drivers/spi/davinci_spi_master.c, is this the driver to be used? 4. What are the changes expected in /arch/arm/mach-davinci/board-dm365evm.c? How to register SPI4 device with the platform? 5. I couldn't find any user level interface to the driver; could you please point to any related information in this regard? Would it be on the similar lines like the example present in ~/drivers/mtd/devices/at25xxA_eeprom.c? Currently I am using dvsdk_2_10_01_18 and PSP_02_10_00_08 (as received with the EVM). Please let me know which kernel tree should I look for to update the source with new patches? Thanks in advance for your time and help. -- Best Regards Arun From bgriffis at ti.com Fri Mar 5 09:20:07 2010 From: bgriffis at ti.com (Griffis, Brad) Date: Fri, 5 Mar 2010 09:20:07 -0600 Subject: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus In-Reply-To: References: <1264549293-25556-1-git-send-email-khilman@deeprootsystems.com> <1264549293-25556-7-git-send-email-khilman@deeprootsystems.com> <225d086e1002050553tc1a696avce827cc115f56b1c@mail.gmail.com> <4B702A17.3070104@mvista.com> <4B7135B3.9080104@mvista.com> Message-ID: > > Right. I was also hoping to rid of cpu_is_xxx usage. The only other way > > I could think of is to add pinmux index into i2c platform data struct. > > What do you think is the best approach? > > > > I think passing pinmux index through platform data is fair. > > Thanks, > Sekhar I recently was told of a clever solution for this issue which I documented here: http://wiki.davincidsp.com/index.php/I2C_Tips#External_Slave_Device_Hanging_the_Bus_by_Holding_SDA_Low Basically the solution was to switch to "free data format" and perform a read. This will cause the I2C to start toggling SCL. I mention it here because I think the "free data format" mode is available on most processors. (The only device I know that does NOT support "free data format" is OMAP35x.) You might have a lot less processor-specific code with this approach and it would be applicable to more devices. I don't have any time to write the code/patch myself, but I thought I would at least toss the idea out there. Brad From mile.davidovic at gmail.com Sat Mar 6 09:26:32 2010 From: mile.davidovic at gmail.com (Mile Davidovic) Date: Sat, 6 Mar 2010 16:26:32 +0100 Subject: Qt and video Message-ID: <6988e0d1003060726r5ae2d83anfb7a3fc07b00dd26@mail.gmail.com> Hello I am wondering if someone has managed to create small Qt based app which can deal with video (I want to have OSD and video in same time). What can be best starting point for this? Kind regards Mile From caglarakyuz at gmail.com Sat Mar 6 10:27:14 2010 From: caglarakyuz at gmail.com (Caglar Akyuz) Date: Sat, 6 Mar 2010 18:27:14 +0200 Subject: Qt and video In-Reply-To: <6988e0d1003060726r5ae2d83anfb7a3fc07b00dd26@mail.gmail.com> References: <6988e0d1003060726r5ae2d83anfb7a3fc07b00dd26@mail.gmail.com> Message-ID: <201003061827.14535.caglarakyuz@gmail.com> On Saturday 06 March 2010 17:26:32 Mile Davidovic wrote: > Hello > I am wondering if someone has managed to create small Qt based app > which can deal with video (I want to have OSD and video in same time). > > What can be best starting point for this? > Hi, I'm integrating GStreamer with Qt. Since GStreamer-ti plugins provide acceleration for GStreamer, this combination has everything I need. Following can be a starting point: 1) Create a filesystem image from Narcissus[1]. Most of the DaVinci processors are present. My suggestion is to use unstable branch. Either select gstreamer-ti plugins while creating the image or install those while running on your device. Package list can be found at [2]. 2) Try gstreamer plugins using the command line, i.e. gst-launch. Many example pipelines can be found at [3]. Some examples present at the filesystem as well. 3) After deciding which pipelines are suitable for your case, set-up an OpenEmbedded environment. This will permit you compile your own applications with Qt. 4) Write your Qt application and integrate your pipelines you decided in step 2 using 'gst_parse_launch' command from GStreamer library. More information and examples about using GStreamer can be found at [4]. 5) Use attribute window for controlling video and osd layers in your application. An example code is attached at the end of this mail. Best regards, Caglar [1] http://www.angstrom-distribution.org/narcissus [2] http://www.angstrom-distribution.org/repo/ [3] http://wiki.davincidsp.com/index.php/Example_GStreamer_Pipelines [4] http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/index.html ___________________________________________________________________________ /** * DM6446 has separate framebuffers(windows) for OSD and Video layers. * This function controls attribute window for transparency adjustment. * * trans: A value between 0-127. 0 means Video visible, and 127 means OSD. * x: Start horizontal offset, must be multiple of 32. * y: Start vertical offset * width: Horizontal length, must be multiple of 32. * height: vertical length */ bool MainWindow::SetOsdTransparency(unsigned char trans, unsigned int x, unsigned int y, unsigned int width, unsigned int height) { struct fb_var_screeninfo vScreenInfo; struct fb_fix_screeninfo fScreenInfo; unsigned short *attrDisplay; int attrSize; /* * Check parameters */ if(((x & 31) != 0) || ((width & 31) != 0)) { qDebug() << "Wrong tranparency width/x values"; return false; } int fd = open("/dev/fb2", O_RDWR); if(fd < 0) { qDebug() << "Error opening attribute window"; return false;// err; } if (ioctl(fd, FBIOGET_FSCREENINFO, &fScreenInfo) == -1) { ::close(fd); qDebug() << "Unable to get screen info"; return false; } if (ioctl(fd, FBIOGET_VSCREENINFO, &vScreenInfo) == -1) { qDebug() << "Unable to get screen info"; ::close(fd); return false; } attrSize = fScreenInfo.line_length * vScreenInfo.yres; /* Map the attribute window to this user space process */ attrDisplay = (unsigned short *) mmap(NULL, attrSize, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (attrDisplay == MAP_FAILED) { qDebug() << "Unable to map attribute window"; ::close(fd); return false; } /* Fill the window with the new attribute value */ if(height < vScreenInfo.yres) { for(unsigned int i = y; i < y + height; i++) { int start = fScreenInfo.line_length * i + x / 2; int size = (width + x) / 2 < fScreenInfo.line_length ? width / 2 : fScreenInfo.line_length - x / 2; memset(attrDisplay + start / 2, trans, size); } } else memset(attrDisplay, trans, attrSize); munmap(attrDisplay, attrSize); ::close(fd); return true; } From nsekhar at ti.com Sun Mar 7 06:35:54 2010 From: nsekhar at ti.com (Sekhar Nori) Date: Sun, 7 Mar 2010 18:05:54 +0530 Subject: [PATCH v2] rtc: omap: let device wakeup capability be configured from chip init logic Message-ID: <1267965354-16805-1-git-send-email-nsekhar@ti.com> The rtc-omap driver currently hardcodes the RTC wakeup capability to be "not capable". While this seems to be true for existing OMAP1 boards which are not wired for this, the DA850/OMAP-L138 SoC, the RTC can always be wake up source from its "deep sleep" mode. This patch lets the wakeup capability to be set from platform data and does not override the setting from the driver. For DA850/OMAP-L138, this is done from arch/arm/mach-davinci/devices-da8xx.c:da8xx_register_rtc() Note that this patch does not change the behavior on any existing OMAP1 board since the platform device registration sets the wakeup capability to 0 by default. Signed-off-by: Sekhar Nori Signed-off-by: Kevin Hilman --- Dave, would you please ack this patch if you are satisfied? drivers/rtc/rtc-omap.c | 12 +++++++----- 1 files changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c index 64d9727..73377b0 100644 --- a/drivers/rtc/rtc-omap.c +++ b/drivers/rtc/rtc-omap.c @@ -34,7 +34,8 @@ * Board-specific wiring options include using split power mode with * RTC_OFF_NOFF used as the reset signal (so the RTC won't be reset), * and wiring RTC_WAKE_INT (so the RTC alarm can wake the system from - * low power modes). See the BOARD-SPECIFIC CUSTOMIZATION comment. + * low power modes) for OMAP1 boards (OMAP-L138 has this built into + * the SoC). See the BOARD-SPECIFIC CUSTOMIZATION comment. */ #define OMAP_RTC_BASE 0xfffb4800 @@ -401,16 +402,17 @@ static int __init omap_rtc_probe(struct platform_device *pdev) /* BOARD-SPECIFIC CUSTOMIZATION CAN GO HERE: * - * - Boards wired so that RTC_WAKE_INT does something, and muxed - * right (W13_1610_RTC_WAKE_INT is the default after chip reset), - * should initialize the device wakeup flag appropriately. + * - Device wake-up capability setting should come through chip + * init logic. OMAP1 boards should initialize the "wakeup capable" + * flag in the platform device if the board is wired right for + * being woken up by RTC alarm. For OMAP-L138, this capability + * is built into the SoC by the "Deep Sleep" capability. * * - Boards wired so RTC_ON_nOFF is used as the reset signal, * rather than nPWRON_RESET, should forcibly enable split * power mode. (Some chip errata report that RTC_CTRL_SPLIT * is write-only, and always reads as zero...) */ - device_init_wakeup(&pdev->dev, 0); if (new_ctrl & (u8) OMAP_RTC_CTRL_SPLIT) pr_info("%s: split power mode\n", pdev->name); -- 1.6.2.4 From nsekhar at ti.com Mon Mar 8 03:35:58 2010 From: nsekhar at ti.com (Sekhar Nori) Date: Mon, 8 Mar 2010 15:05:58 +0530 Subject: [PATCH] davinci: edma: clear interrupt status for interrupt enabled channels only Message-ID: <1268040958-16232-1-git-send-email-nsekhar@ti.com> From: Anuj Aggarwal Currently, the ISR in the EDMA driver clears the pending interrupt for all channels without regard to whether that channel has a registered callback or not. This causes problems for devices like DM355/DM365 where the multimedia accelerator uses EDMA by polling on the interrupt pending bits of some of the EDMA channels. Since these channels are actually allocated through the Linux EDMA driver (by an out-of-kernel module), the same shadow region is used by Linux and accelerator. There a race between the Linux ISR and the polling code running on the accelerator on the IPR (interrupt pending register). This patch fixes the issue by making the ISR clear the interrupts only for those channels which have interrupt enabled. The channels which are allocated for the purpose of being polled on by the accelerator will not have a callback function provided and so will not have IER (interrupt enable register) bits set. Tested on DM365 and OMAP-L137/L138 with audio and MMC/SD (as EDMA users). Signed-off-by: Anuj Aggarwal Signed-off-by: Sekhar Nori CC: Archith John Bency --- arch/arm/mach-davinci/dma.c | 11 +++++++---- 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index 15dd886..ea74a90 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -358,9 +358,11 @@ static irqreturn_t dma_irq_handler(int irq, void *data) while (1) { int j; - if (edma_shadow0_read_array(ctlr, SH_IPR, 0)) + if (edma_shadow0_read_array(ctlr, SH_IPR, 0) & + edma_shadow0_read_array(ctlr, SH_IER, 0)) j = 0; - else if (edma_shadow0_read_array(ctlr, SH_IPR, 1)) + else if (edma_shadow0_read_array(ctlr, SH_IPR, 1) & + edma_shadow0_read_array(ctlr, SH_IER, 1)) j = 1; else break; @@ -368,8 +370,9 @@ static irqreturn_t dma_irq_handler(int irq, void *data) edma_shadow0_read_array(ctlr, SH_IPR, j)); for (i = 0; i < 32; i++) { int k = (j << 5) + i; - if (edma_shadow0_read_array(ctlr, SH_IPR, j) & - (1 << i)) { + if ((edma_shadow0_read_array(ctlr, SH_IPR, j) & BIT(i)) + && (edma_shadow0_read_array(ctlr, + SH_IER, j) & BIT(i))) { /* Clear the corresponding IPR bits */ edma_shadow0_write_array(ctlr, SH_ICR, j, (1 << i)); -- 1.6.2.4 From pjohn at mvista.com Mon Mar 8 07:36:47 2010 From: pjohn at mvista.com (Philby John) Date: Mon, 08 Mar 2010 19:06:47 +0530 Subject: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus In-Reply-To: References: <1264549293-25556-1-git-send-email-khilman@deeprootsystems.com> <1264549293-25556-7-git-send-email-khilman@deeprootsystems.com> <225d086e1002050553tc1a696avce827cc115f56b1c@mail.gmail.com> Message-ID: <4B94FD6F.7050603@mvista.com> On 02/08/2010 04:05 PM, Nori, Sekhar wrote: > Hi Philby, > > On Fri, Feb 05, 2010 at 19:23:43, Philby John wrote: >> Hello Sekhar, >> > > [...] > >>>> +/* Generate a pulse on the i2c clock pin. */ >>>> +static void generic_i2c_clock_pulse(unsigned int scl_pin) >>>> +{ >>>> + u16 i; >>>> + >>>> + if (scl_pin) { >>>> + /* Send high and low on the SCL line */ >>>> + for (i = 0; i< 9; i++) { >>>> + gpio_set_value(scl_pin, 0); >>>> + udelay(20); >>>> + gpio_set_value(scl_pin, 1); >>>> + udelay(20); >>>> + } >>> >>> Before using the pins as GPIO, you would have to set the >>> functionality of these pins as GPIO. You had this code in >>> previous incarnations of this patch - not sure why it is >>> dropped now. >>> I now think that the previous versions were incorrect since davinci_cfg_reg() does not set the scl or sda pins for gpio functionality. Instead they set them as scl or sda which is not what we want at the time of pulsing. The previous versions used gpio_set_value() in disable_i2c_pins() and then called davinci_cfg_reg(). After which it called pulse_i2c_clock(). Please correct me if my interpretation of the code is incorrect. Regards, Philby From pjohn at mvista.com Mon Mar 8 07:37:08 2010 From: pjohn at mvista.com (Philby John) Date: Mon, 08 Mar 2010 19:07:08 +0530 Subject: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus In-Reply-To: References: <1264549293-25556-1-git-send-email-khilman@deeprootsystems.com> <1264549293-25556-7-git-send-email-khilman@deeprootsystems.com> <225d086e1002050553tc1a696avce827cc115f56b1c@mail.gmail.com> <4B702A17.3070104@mvista.com> <4B7135B3.9080104@mvista.com> Message-ID: <4B94FD84.3060100@mvista.com> On 03/05/2010 08:50 PM, Griffis, Brad wrote: >>> Right. I was also hoping to rid of cpu_is_xxx usage. The only other way >>> I could think of is to add pinmux index into i2c platform data struct. >>> What do you think is the best approach? >>> >> >> I think passing pinmux index through platform data is fair. >> >> Thanks, >> Sekhar > > I recently was told of a clever solution for this issue which I documented here: > > http://wiki.davincidsp.com/index.php/I2C_Tips#External_Slave_Device_Hanging_the_Bus_by_Holding_SDA_Low > > Basically the solution was to switch to "free data format" and perform a read. This will cause the I2C to start toggling SCL. I mention it here because I think the "free data format" mode is available on most processors. (The only device I know that does NOT support "free data format" is OMAP35x.) You might have a lot less processor-specific code with this approach and it would be applicable to more devices. > > I don't have any time to write the code/patch myself, but I thought I would at least toss the idea out there. > > Brad > I did go through your document, but what does "free data format" mean? It would be good to expand the procedure that enables you to move into this mode. If this wouldn't require modfying pinmux settings shouldn't it be part of the core i2c implementation? At present we follow the i2c spec. recovery procedure which you explained in method 1, and as per AN10216-01 I2C Manual is ... ?SDA line is then non usable anymore because of the ?Slave-Transmitter?mode. ?Methods to recover the SDA line are: ?Reset the slave device (assuming the device has a Reset pin) ?Use a bus recovery sequence to leave the ?Slave-Transmitter? mode ?Bus recovery sequence is done as following: 1-Send 9 clock pulses on SCL line 2-Ask the master to keep SDA High until the ?Slave-Transmitter? releases the SDA line to perform the ACK operation 3-Keeping SDA High during the ACK means that the ?Master-Receiver?does not acknowledge the previous byte receive 4-The ?Slave-Transmitter? then goes in an idle state 5-The master then sends a STOP command initializing completely the bus Regards, Philby From lamiaposta71 at gmail.com Mon Mar 8 08:17:49 2010 From: lamiaposta71 at gmail.com (Raffaele Recalcati) Date: Mon, 8 Mar 2010 15:17:49 +0100 Subject: kernel tree for dm365 Message-ID: Hi, I'm customizing http://arago-project.org/git/projects/linux-davinci.git for my board based on evm-dm365. Some days ago I saw that http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git has been merged into 2.6.33. So now I am a little bit confused about what is the "right" kernel. By now I'm going on with arago tree, but I'd like to understand better when r31 stable will be available and if it is better to move now to khilman tree. Thanks, Raffaele -------------- next part -------------- An HTML attachment was scrubbed... URL: From s-paulraj at ti.com Mon Mar 8 08:27:54 2010 From: s-paulraj at ti.com (Paulraj, Sandeep) Date: Mon, 8 Mar 2010 08:27:54 -0600 Subject: kernel tree for dm365 In-Reply-To: References: Message-ID: <0554BEF07D437848AF01B9C9B5F0BC5D9C18CF0D@dlee01.ent.ti.com> Raffaele, At this point of time, it is better to be with the arago tree. There will be a merge with Kevin's tree soon but I'm not sure of the exact timeline. Kevin's tree does not, at the moment, have a lot of the video drivers for DM365. Regards, Sandeep ________________________________ From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Raffaele Recalcati Sent: Monday, March 08, 2010 9:18 AM To: davinci-linux-open-source Subject: kernel tree for dm365 Hi, I'm customizing http://arago-project.org/git/projects/linux-davinci.git for my board based on evm-dm365. Some days ago I saw that http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git has been merged into 2.6.33. So now I am a little bit confused about what is the "right" kernel. By now I'm going on with arago tree, but I'd like to understand better when r31 stable will be available and if it is better to move now to khilman tree. Thanks, Raffaele -------------- next part -------------- An HTML attachment was scrubbed... URL: From lamiaposta71 at gmail.com Mon Mar 8 10:08:05 2010 From: lamiaposta71 at gmail.com (Raffaele Recalcati) Date: Mon, 8 Mar 2010 17:08:05 +0100 Subject: kernel tree for dm365 In-Reply-To: <0554BEF07D437848AF01B9C9B5F0BC5D9C18CF0D@dlee01.ent.ti.com> References: <0554BEF07D437848AF01B9C9B5F0BC5D9C18CF0D@dlee01.ent.ti.com> Message-ID: Thank you for you answer. Regards, Raffaele 2010/3/8 Paulraj, Sandeep > Raffaele, > > > > At this point of time, it is better to be with the arago tree. > > There will be a merge with Kevin?s tree soon but I?m not sure of the exact > timeline. > > Kevin?s tree does not, at the moment, have a lot of the video drivers for > DM365. > > > > Regards, > > Sandeep > > > ------------------------------ > > *From:* davinci-linux-open-source-bounces at linux.davincidsp.com [mailto: > davinci-linux-open-source-bounces at linux.davincidsp.com] *On Behalf Of *Raffaele > Recalcati > *Sent:* Monday, March 08, 2010 9:18 AM > *To:* davinci-linux-open-source > *Subject:* kernel tree for dm365 > > > > Hi, > I'm customizing http://arago-project.org/git/projects/linux-davinci.gitfor my board based on evm-dm365. > Some days ago I saw that > http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.githas been merged into 2.6.33. > So now I am a little bit confused about what is the "right" kernel. > By now I'm going on with arago tree, but I'd like to understand better when > r31 stable will be available and if it is better to move now to khilman > tree. > > Thanks, > Raffaele > -- www.opensurf.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguel.aguilar at ridgerun.com Mon Mar 8 11:26:47 2010 From: miguel.aguilar at ridgerun.com (Miguel Aguilar) Date: Mon, 08 Mar 2010 11:26:47 -0600 Subject: [alsa-devel] [PATCH 3/5] ASoC: DaVinci: CQ93VC Voice Codec In-Reply-To: <20100125111104.GC22909@sirena.org.uk> References: <1264095660-1323-1-git-send-email-miguel.aguilar@ridgerun.com> <20100125111104.GC22909@sirena.org.uk> Message-ID: <4B953357.9080904@ridgerun.com> Hi Mark, What is the status of this patch series?, I'm still missing the change pointed below for third patch. Regards, Miguel Aguilar Mark Brown wrote: > On Thu, Jan 21, 2010 at 11:41:00AM -0600, miguel.aguilar at ridgerun.com wrote: > >> +static __init int cq93vc_codec_probe(struct platform_device *pdev) >> +{ > > ... > >> + cq93vc_codec = codec; >> + >> + ret = snd_soc_register_dai(&cq93vc_dai); >> + if (ret != 0) { >> + dev_err(davinci_vc->dev, "could register dai\n"); >> + goto fail1; >> + } >> + return 0; > > There should also be a snd_soc_register_codec() before this, and > similarly on the remove. Otherwise this looks good. From broonie at opensource.wolfsonmicro.com Mon Mar 8 11:36:30 2010 From: broonie at opensource.wolfsonmicro.com (Mark Brown) Date: Mon, 8 Mar 2010 17:36:30 +0000 Subject: [alsa-devel] [PATCH 3/5] ASoC: DaVinci: CQ93VC Voice Codec In-Reply-To: <4B953357.9080904@ridgerun.com> (sfid-20100308_173059_529890_60E499EE) References: <1264095660-1323-1-git-send-email-miguel.aguilar@ridgerun.com> <20100125111104.GC22909@sirena.org.uk> <4B953357.9080904@ridgerun.com> (sfid-20100308_173059_529890_60E499EE) Message-ID: On 8 Mar 2010, at 17:26, Miguel Aguilar wrote: Please don't top post. > What is the status of this patch series?, I'm still missing the > change pointed below for third patch. It's waiting for someone to post a version with that change made. > Mark Brown wrote: >> On Thu, Jan 21, 2010 at 11:41:00AM -0600, >> miguel.aguilar at ridgerun.com wrote: >>> +static __init int cq93vc_codec_probe(struct platform_device *pdev) >>> +{ >> ... >>> + cq93vc_codec = codec; >>> + >>> + ret = snd_soc_register_dai(&cq93vc_dai); >>> + if (ret != 0) { >>> + dev_err(davinci_vc->dev, "could register dai\n"); >>> + goto fail1; >>> + } >>> + return 0; >> There should also be a snd_soc_register_codec() before this, and >> similarly on the remove. Otherwise this looks good. Like I say, the codec needs to be registered as well, not just the DAIs. Please refer to other codec drivers for examples. From mile.davidovic at gmail.com Mon Mar 8 13:39:20 2010 From: mile.davidovic at gmail.com (Mile Davidovic) Date: Mon, 8 Mar 2010 20:39:20 +0100 Subject: Qt and video In-Reply-To: <201003061827.14535.caglarakyuz@gmail.com> References: <6988e0d1003060726r5ae2d83anfb7a3fc07b00dd26@mail.gmail.com> <201003061827.14535.caglarakyuz@gmail.com> Message-ID: <6988e0d1003081139v6b32f907m73146da1689d2870@mail.gmail.com> Thanks a lot. Regards mile On Sat, Mar 6, 2010 at 5:27 PM, Caglar Akyuz wrote: > On Saturday 06 March 2010 17:26:32 Mile Davidovic wrote: >> Hello >> I am wondering if someone has managed to create small Qt based app >> which can deal with video (I want to have OSD and video in same time). >> >> What can be best starting point for this? >> > > Hi, > > I'm integrating GStreamer with Qt. Since GStreamer-ti plugins provide > acceleration for GStreamer, this combination has everything I need. > > Following can be a starting point: > > 1) Create a filesystem image from Narcissus[1]. Most of the DaVinci processors > ? are present. My suggestion is to use unstable branch. Either select > ? gstreamer-ti plugins while creating the image or install those while > ? running on your device. Package list can be found at [2]. > > 2) Try gstreamer plugins using the command line, i.e. gst-launch. Many example > ? ?pipelines can be found at [3]. Some examples present at the filesystem as > ? ?well. > > 3) After deciding which pipelines are suitable for your case, set-up an > ? OpenEmbedded environment. This will permit you compile your own > ? applications with Qt. > > 4) Write your Qt application and integrate your pipelines you decided in step > ? ?2 using 'gst_parse_launch' command from GStreamer library. More > ? ?information and examples about using GStreamer can be found at [4]. > > 5) Use attribute window for controlling video and osd layers in your > ? application. An example code is attached at the end of this mail. > > Best regards, > Caglar > > [1] http://www.angstrom-distribution.org/narcissus > [2] http://www.angstrom-distribution.org/repo/ > [3] http://wiki.davincidsp.com/index.php/Example_GStreamer_Pipelines > [4] > http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/index.html > > ___________________________________________________________________________ > > /** > ?* DM6446 has separate framebuffers(windows) for OSD and Video layers. > ?* This function controls attribute window for transparency adjustment. > ?* > ?* trans: A value between 0-127. 0 means Video visible, and 127 means OSD. > ?* x: Start horizontal offset, must be multiple of 32. > ?* y: Start vertical offset > ?* width: Horizontal length, must be multiple of 32. > ?* height: vertical length > ?*/ > bool MainWindow::SetOsdTransparency(unsigned char trans, unsigned int x, > ? ? ? ? ? ? ? ?unsigned int y, unsigned int width, unsigned int height) > { > ? ? ? ?struct fb_var_screeninfo vScreenInfo; > ? ? ? ?struct fb_fix_screeninfo fScreenInfo; > ? ? ? ?unsigned short ? ? ? ? ?*attrDisplay; > ? ? ? ?int ? ? ? ? ? ? ? ? ? ? ?attrSize; > ? ? ? ?/* > ? ? ? ? * Check parameters > ? ? ? ? */ > ? ? ? ?if(((x & 31) != 0) || ((width & 31) != 0)) { > ? ? ? ? ? ? ? ?qDebug() << "Wrong tranparency width/x values"; > ? ? ? ? ? ? ? ?return false; > ? ? ? ?} > ? ? ? ?int fd = open("/dev/fb2", O_RDWR); > ? ? ? ?if(fd < 0) { > ? ? ? ? ? ? ? ?qDebug() << "Error opening attribute window"; > ? ? ? ? ? ? ? ?return false;// err; > ? ? ? ?} > > ? ? ? ?if (ioctl(fd, FBIOGET_FSCREENINFO, &fScreenInfo) == -1) { > ? ? ? ? ? ? ? ?::close(fd); > ? ? ? ? ? ? ? ?qDebug() << "Unable to get screen info"; > ? ? ? ? ? ? ? ?return false; > ? ? ? ?} > > ? ? ? ?if (ioctl(fd, FBIOGET_VSCREENINFO, &vScreenInfo) == -1) { > ? ? ? ? ? ? ? ?qDebug() << "Unable to get screen info"; > ? ? ? ? ? ? ? ?::close(fd); > ? ? ? ? ? ? ? ?return false; > ? ? ? ?} > > ? ? ? ?attrSize = fScreenInfo.line_length * vScreenInfo.yres; > ? ? ? ?/* Map the attribute window to this user space process */ > ? ? ? ?attrDisplay = (unsigned short *) mmap(NULL, attrSize, > ? ? ? ? ? ? ? ? ? ? ? ?PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); > ? ? ? ?if (attrDisplay == MAP_FAILED) { > ? ? ? ? ? ? ? ?qDebug() << "Unable to map attribute window"; > ? ? ? ? ? ? ? ?::close(fd); > ? ? ? ?return false; > ? ? ? ?} > > ? ? ? ?/* Fill the window with the new attribute value */ > ? ? ? ?if(height < vScreenInfo.yres) { > ? ? ? ? ? ? ? ?for(unsigned int i = y; i < y + height; i++) { > ? ? ? ? ? ? ? ? ? ? ? ?int start = fScreenInfo.line_length * i + x / 2; > ? ? ? ? ? ? ? ? ? ? ? ?int size = (width + x) / 2 < fScreenInfo.line_length ? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?width / 2 : fScreenInfo.line_length - x / 2; > ? ? ? ? ? ? ? ? ? ? ? ?memset(attrDisplay + start / 2, trans, size); > ? ? ? ? ? ? ? ?} > ? ? ? ?} else > ? ? ? ? ? ? ? ?memset(attrDisplay, trans, attrSize); > > ? ? ? ?munmap(attrDisplay, attrSize); > ? ? ? ?::close(fd); > > ? ? ? ?return true; > > } > From Michael.Rondeau at andrew.com Mon Mar 8 14:12:01 2010 From: Michael.Rondeau at andrew.com (Rondeau, Michael) Date: Mon, 8 Mar 2010 14:12:01 -0600 Subject: Question using DSPLINK with kernel from git tree. Message-ID: <55D474137AF1C541A021F8D73F85CF5D3ED16A948B@ACDCE7MB3.commscope.com> I am looking for help or suggestion for updating our system. We are using the TI TMS320DM6446 (Davinci) and I am trying to update the kernel, dsplink, and dspbios. I got the dsplink 1.64 from the TI wiki and the 2.6.32 kernel from the khilman git tree and followed the Building DSPLink instructions but I get compile errors. I have successfully compiled and linked dsplink 1.64 with the MV5 LSP with kernel version 2.6.18. Is there an open source for the dpslink that is compatible with the latest kernel? Thanks Mike Rondeau -------------- next part -------------- An HTML attachment was scrubbed... URL: From luna.id at gmail.com Mon Mar 8 14:33:02 2010 From: luna.id at gmail.com (Nicolas Luna) Date: Mon, 8 Mar 2010 15:33:02 -0500 Subject: OMAP-L138 SPI kernel panic Message-ID: <36999cfe1003081233y2491c16fk14d359f13147ab5d@mail.gmail.com> Hi everyone, I got the ZOOM OMAP-L138 EVM DEVELOPMENT KIT and DaVinci-PSP-SDK-03.20.00.06 with Arago distribution developed by TI for OMAP processor. I'm trying to communicate with an external spi device. I configured my kernel to support spi and modified arch source file to add "spidev" to /dev directory. *Here?s what I changed in board-da850-evm.c :* *static struct spi_board_info da850_spi_board_info[] = {* * [0] = {* * // .modalias = "m25p80",* * .modalias = "spidev",* * // .platform_data = &spi_flash_data,* * // .controller_data = &m25p64_spi_cfg,* * .mode = SPI_MODE_0,* * .max_speed_hz = 30000000, /* max sample rate at 3V */ * * .bus_num = 1,* * .chip_select = 0,* * },* *};* Also, in the menuconfig I added support for SPI and Device Drivers ---> SPI support ---> User mode SPI device driver support. I currently have spidev1.0 in /dev directory. There are a lot of ioctl command with the SPI, I successfully executed few of them: SPI_IOC_RD_MODE, SPI_IOC_RD_BITS_PER_WORD, SPI_IOC_RD_MAX_SPEED_HZ. The problem is when I execute ioctl(.., SPI_IOC_MESSAGE(1), ..) the board crash. *Here?s what happens when I execute SPI_IOC_MESSAGE:* *Unable to handle kernel NULL pointer dereference at virtual address 00000010* *pgd = c0004000* *[00000010] *pgd=00000000* *Internal error: Oops: 17 [#1] PREEMPT* *CPU: 0 Not tainted (2.6.31-rc7-davinci1 #2)* *PC is at davinci_spi_bufs_prep+0xc/0x47c* *LR is at davinci_spi_bufs_pio+0x68/0x2b4* *pc : [] lr : [] psr: 60000013* *sp : c1dcbf04 ip : c1dcbf18 fp : c1dcbf14* *r10: c1d042b8 r9 : 00000001 r8 : c1ddbf00* *r7 : 00000000 r6 : c02a06dc r5 : c1ce7300 r4 : c1d042b8* *r3 : 00000000 r2 : 00000000 r1 : c1d042b8 r0 : c1ce7300* *Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel* *Control: 0005317f Table: c1e30000 DAC: 00000017* *Process dm_spi.1 (pid: 236, stack limit = 0xc1dca270)* *Stack: (0xc1dcbf04 to 0xc1dcc000)* *bf00: c1d042b8 c1dcbf44 c1dcbf18 c01abb7c c01ab0f8 00000000 c1ddbf00* *bf20: 00000000 c1c6de9c c1c6debc c1dca000 00000000 c1d042b8 c1dcbf84 c1dcbf48* *bf40: c01aacfc c01abb24 c1d042cc ffffffff c01ac3b0 c1ce7300 00000000 c1d042c0* *bf60: c1d042bc c1dca000 c1dcdf80 c01aab74 00000000 c1dcdf88 c1dcbfc4 c1dcbf88* *bf80: c0049b30 c01aab84 c0234400 00000000 c1cd4000 c004d750 c1dcbf98 c1dcbf98* *bfa0: c1dcbfcc c1c21d78 c1dcdf80 c00499e8 00000000 00000000 c1dcbff4 c1dcbfc8* *bfc0: c004d4e0 c00499f8 00000000 00000000 c1dcbfd0 c1dcbfd0 00000000 00000000* *bfe0: 00000000 00000000 00000000 c1dcbff8 c003ac50 c004d468 00000000 00000000* *Backtrace:* *[] (davinci_spi_bufs_prep+0x0/0x47c) from [] (davinci_spi_bufs_pio+0x68/0x2b4)* * r4:c1d042b8* *[] (davinci_spi_bufs_pio+0x0/0x2b4) from [] (bitbang_work+0x188/0x2ec)* *[] (bitbang_work+0x0/0x2ec) from [] (worker_thread+0x148/0x20c)* *[] (worker_thread+0x0/0x20c) from [] (kthread+0x88/0x90)* *[] (kthread+0x0/0x90) from [] (do_exit+0x0/0x650)* * r7:00000000 r6:00000000 r5:00000000 r4:00000000* *Code: e89da800 e1a0c00d e92dd810 e24cb004 (e5923010)* *---[ end trace 4f0e16f9f2f85b61 ]---* Do you have any idea why the board is crashing? Thanks Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: From rohan_javed at yahoo.co.uk Tue Mar 9 03:43:02 2010 From: rohan_javed at yahoo.co.uk (rohan tabish) Date: Tue, 9 Mar 2010 01:43:02 -0800 (PST) Subject: DM6446:how to change PLL1 frequecy in linux Message-ID: <393830.25169.qm@web24106.mail.ird.yahoo.com> Hello I want to know how to change the PLL1 frequency in Linux Have read the sprue14 it says that the all the peripherals using this frequency should be powered off.more over since i want to low the frequency of only SYSCLK 5 but that is not programmable i have changed the value in that register but that isn't working Regard's RT -------------- next part -------------- An HTML attachment was scrubbed... URL: From kapil.pendse at gmail.com Tue Mar 9 04:46:33 2010 From: kapil.pendse at gmail.com (Kapil Pendse) Date: Tue, 9 Mar 2010 16:16:33 +0530 Subject: MVL4.0.1 kernel compiled with MVL5.0 toolchain In-Reply-To: <65b6d8ff1003020715p1168d73ap4d7505ef3cbe3aed@mail.gmail.com> References: <65b6d8ff1003020204k2ac9bcbcn9c6117350b4142d6@mail.gmail.com> <65b6d8ff1003020631x348a699fo4dae84ef3ce14e42@mail.gmail.com> <65b6d8ff1003020715p1168d73ap4d7505ef3cbe3aed@mail.gmail.com> Message-ID: <65b6d8ff1003090246v6fbea8e0rf958bd65d1879a8d@mail.gmail.com> > > >> 2. If you got the SDK from TI, TI should be able to supply the source >> code. >> >> > Thanks Steve. I got the SDK from TI so I've initiated contact with their > support. I could not find the same version of module-init-tools on > kernel.org otherwise I could have just taken it from there. The one on > DM355 target file system is version 3.1-pre5. > > This was completely my bad. I have this big build script that first builds the kernel, the modules and some more things follow. I looked at the build log closely and saw that the kernel 2.6.10 was never getting built properly with the MVL5.0 toolchain. And the board was booting of the old uImage. So, lesson learnt: have the build script delete all old files before they are re-built. Anyway, so finally I did manage to get the 2.6.10 kernel to build with MVL5.0 toolchain. It needed some minor changes to the code, but they were straight forward on comparing with the 2.6.18 kernel of MVL5.0. Now I have another problem, it looks like the DVSDK 1.30.01.41 also has to be re-built with MVL5.0 toolchain. I did this, which ensures that the cmem.ko module, among others, is re-built with the new toolchain. When I try to load this module, I get the following errors: #insmod cmemk.ko phys_start=0x87400000 phys_end=0x88000000 pools=1x2097152,2x1529856,7x829440,1x524288,1x108680,2x81920,1x9600,2x8192,6x4096 cmemk: disagrees about version of symbol strcpy cmemk: Unknown symbol strcpy cmemk: disagrees about version of symbol __arch_copy_to_user cmemk: Unknown symbol __arch_copy_to_user cmemk: disagrees about version of symbol __put_user_4 cmemk: Unknown symbol __put_user_4 cmemk: disagrees about version of symbol __memzero cmemk: Unknown symbol __memzero cmemk: disagrees about version of symbol __get_user_4 cmemk: Unknown symbol __get_user_4 cmemk: disagrees about version of symbol __arch_copy_from_user cmemk: Unknown symbol __arch_copy_from_user insmod: error inserting 'cmemk.ko': -1 Unknown symbol in module root at 192.168.0.4:/opt/dvsdk/dm355# Can anyone please point out what else do I need to re-build with MVL5.0 toolchain? Why the complaint about "strcpy"?? Best regards, Kapil -- "The Power to Imagine, is The Power to Create!" -TTux -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsekhar at ti.com Tue Mar 9 05:20:37 2010 From: nsekhar at ti.com (Sekhar Nori) Date: Tue, 9 Mar 2010 16:50:37 +0530 Subject: [PATCH] net: davinci emac: use dma_{map, unmap}_single API for cache coherency Message-ID: <1268133637-23399-1-git-send-email-nsekhar@ti.com> The davinci emac driver uses some ARM specific DMA APIs for cache coherency which have been removed from kernel with the 2.6.34 merge. Modify the driver to use the dma_{map, unmap}_single() APIs defined in dma-mapping.h Without this fix, the driver fails to compile on Linus's tree. Tested on DM365 and OMAP-L138 EVMs. Signed-off-by: Sekhar Nori --- Applies to latest of Linus's tree. drivers/net/davinci_emac.c | 45 +++++++++++++++++++++++++------------------ 1 files changed, 26 insertions(+), 19 deletions(-) diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c index 1ac9440..ef0dacf 100644 --- a/drivers/net/davinci_emac.c +++ b/drivers/net/davinci_emac.c @@ -29,10 +29,6 @@ * PHY layer usage */ -/** Pending Items in this driver: - * 1. Use Linux cache infrastcture for DMA'ed memory (dma_xxx functions) - */ - #include #include #include @@ -504,12 +500,6 @@ static unsigned long mdio_max_freq; /* Cache macros - Packet buffers would be from skb pool which is cached */ #define EMAC_VIRT_NOCACHE(addr) (addr) -#define EMAC_CACHE_INVALIDATE(addr, size) \ - dma_cache_maint((void *)addr, size, DMA_FROM_DEVICE) -#define EMAC_CACHE_WRITEBACK(addr, size) \ - dma_cache_maint((void *)addr, size, DMA_TO_DEVICE) -#define EMAC_CACHE_WRITEBACK_INVALIDATE(addr, size) \ - dma_cache_maint((void *)addr, size, DMA_BIDIRECTIONAL) /* DM644x does not have BD's in cached memory - so no cache functions */ #define BD_CACHE_INVALIDATE(addr, size) @@ -1235,6 +1225,10 @@ static void emac_txch_teardown(struct emac_priv *priv, u32 ch) if (1 == txch->queue_active) { curr_bd = txch->active_queue_head; while (curr_bd != NULL) { + dma_unmap_single(emac_dev, curr_bd->buff_ptr, + curr_bd->off_b_len & EMAC_RX_BD_BUF_SIZE, + DMA_TO_DEVICE); + emac_net_tx_complete(priv, (void __force *) &curr_bd->buf_token, 1, ch); if (curr_bd != txch->active_queue_tail) @@ -1327,6 +1321,11 @@ static int emac_tx_bdproc(struct emac_priv *priv, u32 ch, u32 budget) txch->queue_active = 0; /* end of queue */ } } + + dma_unmap_single(emac_dev, curr_bd->buff_ptr, + curr_bd->off_b_len & EMAC_RX_BD_BUF_SIZE, + DMA_TO_DEVICE); + *tx_complete_ptr = (u32) curr_bd->buf_token; ++tx_complete_ptr; ++tx_complete_cnt; @@ -1387,8 +1386,8 @@ static int emac_send(struct emac_priv *priv, struct emac_netpktobj *pkt, u32 ch) txch->bd_pool_head = curr_bd->next; curr_bd->buf_token = buf_list->buf_token; - /* FIXME buff_ptr = dma_map_single(... data_ptr ...) */ - curr_bd->buff_ptr = virt_to_phys(buf_list->data_ptr); + curr_bd->buff_ptr = dma_map_single(&priv->ndev->dev, buf_list->data_ptr, + buf_list->length, DMA_TO_DEVICE); curr_bd->off_b_len = buf_list->length; curr_bd->h_next = 0; curr_bd->next = NULL; @@ -1468,7 +1467,6 @@ static int emac_dev_xmit(struct sk_buff *skb, struct net_device *ndev) tx_buf.length = skb->len; tx_buf.buf_token = (void *)skb; tx_buf.data_ptr = skb->data; - EMAC_CACHE_WRITEBACK((unsigned long)skb->data, skb->len); ndev->trans_start = jiffies; ret_code = emac_send(priv, &tx_packet, EMAC_DEF_TX_CH); if (unlikely(ret_code != 0)) { @@ -1543,7 +1541,6 @@ static void *emac_net_alloc_rx_buf(struct emac_priv *priv, int buf_size, p_skb->dev = ndev; skb_reserve(p_skb, NET_IP_ALIGN); *data_token = (void *) p_skb; - EMAC_CACHE_WRITEBACK_INVALIDATE((unsigned long)p_skb->data, buf_size); return p_skb->data; } @@ -1612,8 +1609,8 @@ static int emac_init_rxch(struct emac_priv *priv, u32 ch, char *param) /* populate the hardware descriptor */ curr_bd->h_next = emac_virt_to_phys(rxch->active_queue_head, priv); - /* FIXME buff_ptr = dma_map_single(... data_ptr ...) */ - curr_bd->buff_ptr = virt_to_phys(curr_bd->data_ptr); + curr_bd->buff_ptr = dma_map_single(emac_dev, curr_bd->data_ptr, + rxch->buf_size, DMA_FROM_DEVICE); curr_bd->off_b_len = rxch->buf_size; curr_bd->mode = EMAC_CPPI_OWNERSHIP_BIT; @@ -1697,6 +1694,12 @@ static void emac_cleanup_rxch(struct emac_priv *priv, u32 ch) curr_bd = rxch->active_queue_head; while (curr_bd) { if (curr_bd->buf_token) { + dma_unmap_single(&priv->ndev->dev, + curr_bd->buff_ptr, + curr_bd->off_b_len + & EMAC_RX_BD_BUF_SIZE, + DMA_FROM_DEVICE); + dev_kfree_skb_any((struct sk_buff *)\ curr_bd->buf_token); } @@ -1871,8 +1874,8 @@ static void emac_addbd_to_rx_queue(struct emac_priv *priv, u32 ch, /* populate the hardware descriptor */ curr_bd->h_next = 0; - /* FIXME buff_ptr = dma_map_single(... buffer ...) */ - curr_bd->buff_ptr = virt_to_phys(buffer); + curr_bd->buff_ptr = dma_map_single(&priv->ndev->dev, buffer, + rxch->buf_size, DMA_FROM_DEVICE); curr_bd->off_b_len = rxch->buf_size; curr_bd->mode = EMAC_CPPI_OWNERSHIP_BIT; curr_bd->next = NULL; @@ -1927,7 +1930,6 @@ static int emac_net_rx_cb(struct emac_priv *priv, p_skb = (struct sk_buff *)net_pkt_list->pkt_token; /* set length of packet */ skb_put(p_skb, net_pkt_list->pkt_length); - EMAC_CACHE_INVALIDATE((unsigned long)p_skb->data, p_skb->len); p_skb->protocol = eth_type_trans(p_skb, priv->ndev); netif_receive_skb(p_skb); priv->net_dev_stats.rx_bytes += net_pkt_list->pkt_length; @@ -1990,6 +1992,11 @@ static int emac_rx_bdproc(struct emac_priv *priv, u32 ch, u32 budget) rx_buf_obj->data_ptr = (char *)curr_bd->data_ptr; rx_buf_obj->length = curr_bd->off_b_len & EMAC_RX_BD_BUF_SIZE; rx_buf_obj->buf_token = curr_bd->buf_token; + + dma_unmap_single(&priv->ndev->dev, curr_bd->buff_ptr, + curr_bd->off_b_len & EMAC_RX_BD_BUF_SIZE, + DMA_FROM_DEVICE); + curr_pkt->pkt_token = curr_pkt->buf_list->buf_token; curr_pkt->num_bufs = 1; curr_pkt->pkt_length = -- 1.6.2.4 From lamiaposta71 at gmail.com Tue Mar 9 09:30:35 2010 From: lamiaposta71 at gmail.com (Raffaele Recalcati) Date: Tue, 9 Mar 2010 16:30:35 +0100 Subject: evm-dm365 testing usb slave : added in defconfig Message-ID: I'd like to add as more as possible functionalities davinci_dm365_defconfig in order to have something to compare easily with my hardware. Using the patch below against e87a8397d2830db11ce1518bd2abc4e8815763f1 commit of http://arago-project.org/git/projects/linux-davinci.git. That patch contains a little fix. I have used the following command launched on the target mkdosfs /dev/mtdblock4 modprobe g_file_storage file=/dev/mtdblock4 so I have connected the evm-dm365 to my host pc, mounted the evm as a usb storage, and written some files (10MB). I have umount it. Re-mount and check that files are equal. diff --git a/arch/arm/configs/davinci_dm365_defconfig b/arch/arm/configs/davinci_dm365_defconfig index 12ff7a1..42d2d04 100644 --- a/arch/arm/configs/davinci_dm365_defconfig +++ b/arch/arm/configs/davinci_dm365_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.32-rc2-davinci1 -# Mon Nov 2 10:40:20 2009 +# Tue Mar 9 11:17:44 2010 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -32,7 +32,7 @@ CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" -CONFIG_LOCALVERSION_AUTO=y +# CONFIG_LOCALVERSION_AUTO is not set # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y @@ -75,7 +75,7 @@ CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y -# CONFIG_KALLSYMS_ALL is not set +CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y @@ -138,7 +138,7 @@ CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" -# CONFIG_FREEZER is not set +CONFIG_FREEZER=y # # System Type @@ -210,7 +210,7 @@ CONFIG_ARCH_DAVINCI_DM365=y # CONFIG_MACH_DAVINCI_DM365_EVM=y CONFIG_DAVINCI_MUX=y -# CONFIG_DAVINCI_MUX_DEBUG is not set +CONFIG_DAVINCI_MUX_DEBUG=y # CONFIG_DAVINCI_MUX_WARNINGS is not set CONFIG_DAVINCI_RESET_CLOCKS=y CONFIG_OSC_CLK_FREQ=27000000 @@ -324,7 +324,13 @@ CONFIG_HAVE_AOUT=y # # Power management options # -# CONFIG_PM is not set +CONFIG_PM=y +# CONFIG_PM_DEBUG is not set +CONFIG_PM_SLEEP=y +CONFIG_SUSPEND=y +CONFIG_SUSPEND_FREEZER=y +# CONFIG_APM_EMULATION is not set +# CONFIG_PM_RUNTIME is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_NET=y @@ -475,7 +481,7 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" -# CONFIG_DEBUG_DRIVER is not set +CONFIG_DEBUG_DRIVER=y # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_CONNECTOR is not set @@ -874,7 +880,7 @@ CONFIG_SPI_BITBANG=y CONFIG_ARCH_REQUIRE_GPIOLIB=y CONFIG_GPIOLIB=y # CONFIG_DEBUG_GPIO is not set -# CONFIG_GPIO_SYSFS is not set +CONFIG_GPIO_SYSFS=y # # Memory mapped GPIO expanders: @@ -1225,7 +1231,9 @@ CONFIG_SND_DRIVERS=y # CONFIG_SND_MPU401 is not set CONFIG_SND_ARM=y CONFIG_SND_SPI=y -# CONFIG_SND_USB is not set +CONFIG_SND_USB=y +# CONFIG_SND_USB_AUDIO is not set +# CONFIG_SND_USB_CAIAQ is not set CONFIG_SND_SOC=y CONFIG_SND_DAVINCI_SOC=y CONFIG_SND_DAVINCI_SOC_I2S=y @@ -1288,10 +1296,11 @@ CONFIG_USB=y # # Miscellaneous USB options # -CONFIG_USB_DEVICEFS=y +# CONFIG_USB_DEVICEFS is not set CONFIG_USB_DEVICE_CLASS=y # CONFIG_USB_DYNAMIC_MINORS is not set -# CONFIG_USB_OTG is not set +# CONFIG_USB_SUSPEND is not set +CONFIG_USB_OTG=y # CONFIG_USB_OTG_WHITELIST is not set # CONFIG_USB_OTG_BLACKLIST_HUB is not set # CONFIG_USB_MON is not set @@ -1315,15 +1324,16 @@ CONFIG_USB_MUSB_SOC=y # # DaVinci 35x, 36x, 644x USB support # -CONFIG_USB_MUSB_HOST=y +# CONFIG_USB_MUSB_HOST is not set # CONFIG_USB_MUSB_PERIPHERAL is not set -# CONFIG_USB_MUSB_OTG is not set +CONFIG_USB_MUSB_OTG=y # CONFIG_MUSB_SCHEDULE_INTR_EP is not set +CONFIG_USB_GADGET_MUSB_HDRC=y CONFIG_USB_MUSB_HDRC_HCD=y # CONFIG_MUSB_PIO_ONLY is not set # CONFIG_USB_INVENTRA_DMA is not set CONFIG_USB_TI_CPPI_DMA=y -# CONFIG_USB_MUSB_DEBUG is not set +CONFIG_USB_MUSB_DEBUG=y # # USB Device Class drivers @@ -1340,19 +1350,7 @@ CONFIG_USB_TI_CPPI_DMA=y # # also be needed; see USB_STORAGE Help for more info # -CONFIG_USB_STORAGE=y -# CONFIG_USB_STORAGE_DEBUG is not set -# CONFIG_USB_STORAGE_DATAFAB is not set -# CONFIG_USB_STORAGE_FREECOM is not set -# CONFIG_USB_STORAGE_ISD200 is not set -# CONFIG_USB_STORAGE_USBAT is not set -# CONFIG_USB_STORAGE_SDDR09 is not set -# CONFIG_USB_STORAGE_SDDR55 is not set -# CONFIG_USB_STORAGE_JUMPSHOT is not set -# CONFIG_USB_STORAGE_ALAUDA is not set -# CONFIG_USB_STORAGE_ONETOUCH is not set -# CONFIG_USB_STORAGE_KARMA is not set -# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set +# CONFIG_USB_STORAGE is not set # CONFIG_USB_LIBUSUAL is not set # @@ -1387,16 +1385,51 @@ CONFIG_USB_STORAGE=y # CONFIG_USB_LD is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set -CONFIG_USB_TEST=y +# CONFIG_USB_TEST is not set # CONFIG_USB_ISIGHTFW is not set # CONFIG_USB_VST is not set -# CONFIG_USB_GADGET is not set +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DEBUG=y +# CONFIG_USB_GADGET_DEBUG_FILES is not set +# CONFIG_USB_GADGET_DEBUG_FS is not set +CONFIG_USB_GADGET_VBUS_DRAW=500 +CONFIG_USB_GADGET_SELECTED=y +# CONFIG_USB_GADGET_AT91 is not set +# CONFIG_USB_GADGET_ATMEL_USBA is not set +# CONFIG_USB_GADGET_FSL_USB2 is not set +# CONFIG_USB_GADGET_LH7A40X is not set +# CONFIG_USB_GADGET_OMAP is not set +# CONFIG_USB_GADGET_PXA25X is not set +# CONFIG_USB_GADGET_R8A66597 is not set +# CONFIG_USB_GADGET_PXA27X is not set +# CONFIG_USB_GADGET_S3C_HSOTG is not set +# CONFIG_USB_GADGET_IMX is not set +# CONFIG_USB_GADGET_S3C2410 is not set +# CONFIG_USB_GADGET_M66592 is not set +# CONFIG_USB_GADGET_AMD5536UDC is not set +# CONFIG_USB_GADGET_FSL_QE is not set +# CONFIG_USB_GADGET_CI13XXX is not set +# CONFIG_USB_GADGET_NET2280 is not set +# CONFIG_USB_GADGET_GOKU is not set +# CONFIG_USB_GADGET_LANGWELL is not set +# CONFIG_USB_GADGET_DUMMY_HCD is not set +CONFIG_USB_GADGET_DUALSPEED=y +# CONFIG_USB_ZERO is not set +# CONFIG_USB_AUDIO is not set +# CONFIG_USB_ETH is not set +CONFIG_USB_GADGETFS=m +CONFIG_USB_FILE_STORAGE=m +# CONFIG_USB_FILE_STORAGE_TEST is not set +# CONFIG_USB_G_SERIAL is not set +# CONFIG_USB_MIDI_GADGET is not set +# CONFIG_USB_G_PRINTER is not set +# CONFIG_USB_CDC_COMPOSITE is not set # # OTG and related infrastructure # CONFIG_USB_OTG_UTILS=y -# CONFIG_USB_GPIO_VBUS is not set +CONFIG_USB_GPIO_VBUS=y CONFIG_NOP_USB_XCEIV=y CONFIG_MMC=y # CONFIG_MMC_DEBUG is not set @@ -1646,7 +1679,7 @@ CONFIG_NLS_UTF8=m # # Kernel hacking # -# CONFIG_PRINTK_TIME is not set +CONFIG_PRINTK_TIME=y CONFIG_ENABLE_WARN_DEPRECATED=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=1024 diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c index 2c73d93..9a129d4 100644 --- a/drivers/usb/musb/davinci.c +++ b/drivers/usb/musb/davinci.c @@ -71,12 +71,14 @@ static inline void phy_on(void) /* power everything up; start the on-chip PHY and its PLL */ phy_ctrl &= ~(USBPHY_OSCPDWN | USBPHY_OTGPDWN | USBPHY_PHYPDWN); phy_ctrl |= USBPHY_SESNDEN | USBPHY_VBDTCTEN | USBPHY_PHYPLLON; +#ifndef CONFIG_USB_MUSB_OTG if (cpu_is_davinci_dm646x()) { phy_ctrl |= USBPHY_NDATAPOL | USBPHY_SESSION_VBUS; phy_ctrl |= is_peripheral_enabled() ? USBPHY_PERI_USBID : phy_ctrl; phy_ctrl &= ~USBPHY_VBDTCTEN; } +#endif if (cpu_is_davinci_dm365()) { /* * DM365 PHYCLKFREQ field [15:12] is set to 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From darren.longhorn at redembedded.com Tue Mar 9 11:12:29 2010 From: darren.longhorn at redembedded.com (Darren Longhorn) Date: Tue, 09 Mar 2010 17:12:29 +0000 Subject: USB camera In-Reply-To: References: Message-ID: <4B96817D.1080404@redembedded.com> Yuvraj Pasi wrote: > Hi, > I am using a usb camera with gspca driver for dm6446 based system. i > have used capture application given in v4l2 documentation Does gspca support v4l2 now? It didn't when I was using it a couple of years ago. From miguel.aguilar at ridgerun.com Tue Mar 9 11:35:18 2010 From: miguel.aguilar at ridgerun.com (miguel.aguilar at ridgerun.com) Date: Tue, 9 Mar 2010 11:35:18 -0600 Subject: [PATCH v2 3/5] ASoC: DaVinci: CQ93VC Voice Codec Message-ID: <1268156118-16939-1-git-send-email-miguel.aguilar@ridgerun.com> From: Miguel Aguilar Currently the DM365 is the only SoC that includes this Voice Codec. Signed-off-by: Miguel Aguilar --- sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/cq93vc.c | 298 +++++++++++++++++++++++++++++++++++++++++++++ sound/soc/codecs/cq93vc.h | 29 +++++ 4 files changed, 333 insertions(+), 0 deletions(-) create mode 100644 sound/soc/codecs/cq93vc.c create mode 100644 sound/soc/codecs/cq93vc.h diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 52b005f..0daca22 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -21,6 +21,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_AK4535 if I2C select SND_SOC_AK4642 if I2C select SND_SOC_AK4671 if I2C + select SND_SOC_CQ0093VC if MFD_DAVINCI_VOICECODEC select SND_SOC_CS4270 if I2C select SND_SOC_MAX9877 if I2C select SND_SOC_PCM3008 @@ -108,6 +109,9 @@ config SND_SOC_AK4642 config SND_SOC_AK4671 tristate +config SND_SOC_CQ0093VC + tristate + # Cirrus Logic CS4270 Codec config SND_SOC_CS4270 tristate diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index dbaecb1..dff91fb 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -8,6 +8,7 @@ snd-soc-ak4104-objs := ak4104.o snd-soc-ak4535-objs := ak4535.o snd-soc-ak4642-objs := ak4642.o snd-soc-ak4671-objs := ak4671.o +snd-soc-cq93vc-objs := cq93vc.o snd-soc-cs4270-objs := cs4270.o snd-soc-cx20442-objs := cx20442.o snd-soc-l3-objs := l3.o @@ -64,6 +65,7 @@ obj-$(CONFIG_SND_SOC_AK4104) += snd-soc-ak4104.o obj-$(CONFIG_SND_SOC_AK4535) += snd-soc-ak4535.o obj-$(CONFIG_SND_SOC_AK4642) += snd-soc-ak4642.o obj-$(CONFIG_SND_SOC_AK4671) += snd-soc-ak4671.o +obj-$(CONFIG_SND_SOC_CQ0093VC) += snd-soc-cq93vc.o obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o obj-$(CONFIG_SND_SOC_CX20442) += snd-soc-cx20442.o obj-$(CONFIG_SND_SOC_L3) += snd-soc-l3.o diff --git a/sound/soc/codecs/cq93vc.c b/sound/soc/codecs/cq93vc.c new file mode 100644 index 0000000..5132974 --- /dev/null +++ b/sound/soc/codecs/cq93vc.c @@ -0,0 +1,298 @@ +/* + * ALSA SoC CQ0093 Voice Codec Driver for DaVinci platforms + * + * Copyright (C) 2010 Texas Instruments, Inc + * + * Author: Miguel Aguilar + * + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "cq93vc.h" + +static inline unsigned int cq93vc_read(struct snd_soc_codec *codec, + unsigned int reg) +{ + struct davinci_vc *davinci_vc = codec->control_data; + + return readl(davinci_vc->base + reg); +} + +static inline int cq93vc_write(struct snd_soc_codec *codec, unsigned int reg, + unsigned int value) +{ + struct davinci_vc *davinci_vc = codec->control_data; + + writel(value, davinci_vc->base + reg); + + return 0; +} + +static const struct snd_kcontrol_new cq93vc_snd_controls[] = { + SOC_SINGLE("PGA Capture Volume", DAVINCI_VC_REG05, 0, 0x03, 0), + SOC_SINGLE("Mono DAC Playback Volume", DAVINCI_VC_REG09, 0, 0x3f, 0), +}; + +static int cq93vc_mute(struct snd_soc_dai *dai, int mute) +{ + struct snd_soc_codec *codec = dai->codec; + u8 reg = cq93vc_read(codec, DAVINCI_VC_REG09) & ~DAVINCI_VC_REG09_MUTE; + + if (mute) + cq93vc_write(codec, DAVINCI_VC_REG09, + reg | DAVINCI_VC_REG09_MUTE); + else + cq93vc_write(codec, DAVINCI_VC_REG09, reg); + + return 0; +} + +static int cq93vc_set_dai_sysclk(struct snd_soc_dai *codec_dai, + int clk_id, unsigned int freq, int dir) +{ + struct snd_soc_codec *codec = codec_dai->codec; + struct davinci_vc *davinci_vc = codec->control_data; + + switch (freq) { + case 22579200: + case 27000000: + case 33868800: + davinci_vc->cq93vc.sysclk = freq; + return 0; + } + + return -EINVAL; +} + +static int cq93vc_set_bias_level(struct snd_soc_codec *codec, + enum snd_soc_bias_level level) +{ + switch (level) { + case SND_SOC_BIAS_ON: + cq93vc_write(codec, DAVINCI_VC_REG12, + DAVINCI_VC_REG12_POWER_ALL_ON); + break; + case SND_SOC_BIAS_PREPARE: + break; + case SND_SOC_BIAS_STANDBY: + cq93vc_write(codec, DAVINCI_VC_REG12, + DAVINCI_VC_REG12_POWER_ALL_OFF); + break; + case SND_SOC_BIAS_OFF: + /* force all power off */ + cq93vc_write(codec, DAVINCI_VC_REG12, + DAVINCI_VC_REG12_POWER_ALL_OFF); + break; + } + codec->bias_level = level; + + return 0; +} + +#define CQ93VC_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_16000) +#define CQ93VC_FORMATS (SNDRV_PCM_FMTBIT_U8 | SNDRV_PCM_FMTBIT_S16_LE) + +static struct snd_soc_dai_ops cq93vc_dai_ops = { + .digital_mute = cq93vc_mute, + .set_sysclk = cq93vc_set_dai_sysclk, +}; + +struct snd_soc_dai cq93vc_dai = { + .name = "CQ93VC", + .playback = { + .stream_name = "Playback", + .channels_min = 1, + .channels_max = 2, + .rates = CQ93VC_RATES, + .formats = CQ93VC_FORMATS,}, + .capture = { + .stream_name = "Capture", + .channels_min = 1, + .channels_max = 2, + .rates = CQ93VC_RATES, + .formats = CQ93VC_FORMATS,}, + .ops = &cq93vc_dai_ops, +}; +EXPORT_SYMBOL_GPL(cq93vc_dai); + +static int cq93vc_resume(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + struct snd_soc_codec *codec = socdev->card->codec; + + cq93vc_set_bias_level(codec, codec->suspend_bias_level); + + return 0; +} + +static struct snd_soc_codec *cq93vc_codec; + +static int cq93vc_probe(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + struct device *dev = &pdev->dev; + struct snd_soc_codec *codec; + int ret; + + socdev->card->codec = cq93vc_codec; + codec = socdev->card->codec; + + /* Register pcms */ + ret = snd_soc_new_pcms(socdev, SNDRV_DEFAULT_IDX1, SNDRV_DEFAULT_STR1); + if (ret < 0) { + dev_err(dev, "%s: failed to create pcms\n", pdev->name); + return ret; + } + + /* Set controls */ + snd_soc_add_controls(codec, cq93vc_snd_controls, + ARRAY_SIZE(cq93vc_snd_controls)); + + /* Off, with power on */ + cq93vc_set_bias_level(codec, SND_SOC_BIAS_STANDBY); + + return 0; +} + +static int cq93vc_remove(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + + snd_soc_free_pcms(socdev); + snd_soc_dapm_free(socdev); + + return 0; +} + +struct snd_soc_codec_device soc_codec_dev_cq93vc = { + .probe = cq93vc_probe, + .remove = cq93vc_remove, + .resume = cq93vc_resume, +}; +EXPORT_SYMBOL_GPL(soc_codec_dev_cq93vc); + +static __init int cq93vc_codec_probe(struct platform_device *pdev) +{ + struct davinci_vc *davinci_vc = platform_get_drvdata(pdev); + struct snd_soc_codec *codec; + int ret; + + codec = kzalloc(sizeof(struct snd_soc_codec), GFP_KERNEL); + if (codec == NULL) { + dev_dbg(davinci_vc->dev, + "could not allocate memory for codec data\n"); + return -ENOMEM; + } + + davinci_vc->cq93vc.codec = codec; + + cq93vc_dai.dev = &pdev->dev; + + mutex_init(&codec->mutex); + INIT_LIST_HEAD(&codec->dapm_widgets); + INIT_LIST_HEAD(&codec->dapm_paths); + codec->dev = &pdev->dev; + codec->name = "CQ93VC"; + codec->owner = THIS_MODULE; + codec->read = cq93vc_read; + codec->write = cq93vc_write; + codec->set_bias_level = cq93vc_set_bias_level; + codec->dai = &cq93vc_dai; + codec->num_dai = 1; + codec->control_data = davinci_vc; + + cq93vc_codec = codec; + + ret = snd_soc_register_codec(codec); + if (ret) { + dev_err(davinci_vc->dev, "failed to register codec\n"); + goto fail1; + } + + ret = snd_soc_register_dai(&cq93vc_dai); + if (ret) { + dev_err(davinci_vc->dev, "could register dai\n"); + goto fail2; + } + return 0; + +fail2: + snd_soc_unregister_codec(codec); + +fail1: + kfree(codec); + cq93vc_codec = NULL; + + return ret; +} + +static int __devexit cq93vc_codec_remove(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + struct snd_soc_codec *codec = socdev->card->codec; + + snd_soc_unregister_dai(&cq93vc_dai); + snd_soc_unregister_codec(&codec); + + kfree(codec); + cq93vc_codec = NULL; + + return 0; +} + +static struct platform_driver cq93vc_codec_driver = { + .driver = { + .name = "cq93vc", + .owner = THIS_MODULE, + }, + .probe = cq93vc_codec_probe, + .remove = __devexit_p(cq93vc_codec_remove), +}; + +static __init int cq93vc_init(void) +{ + return platform_driver_probe(&cq93vc_codec_driver, cq93vc_codec_probe); +} +module_init(cq93vc_init); + +static __exit void cq93vc_exit(void) +{ + platform_driver_unregister(&cq93vc_codec_driver); +} +module_exit(cq93vc_exit); + +MODULE_DESCRIPTION("Texas Instruments DaVinci ASoC CQ0093 Voice Codec Driver"); +MODULE_AUTHOR("Miguel Aguilar"); +MODULE_LICENSE("GPL"); diff --git a/sound/soc/codecs/cq93vc.h b/sound/soc/codecs/cq93vc.h new file mode 100644 index 0000000..845b196 --- /dev/null +++ b/sound/soc/codecs/cq93vc.h @@ -0,0 +1,29 @@ +/* + * ALSA SoC CQ0093 Voice Codec Driver for DaVinci platforms + * + * Copyright (C) 2010 Texas Instruments, Inc + * + * Author: Miguel Aguilar + * + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef _CQ93VC_H +#define _CQ93VC_H + +extern struct snd_soc_dai cq93vc_dai; +extern struct snd_soc_codec_device soc_codec_dev_cq93vc; + +#endif -- 1.6.0.4 From yuvraj.pasi at nextbitcpu.com Tue Mar 9 22:35:11 2010 From: yuvraj.pasi at nextbitcpu.com (Yuvraj Pasi) Date: Wed, 10 Mar 2010 10:05:11 +0530 Subject: USB camera In-Reply-To: <4B96817D.1080404@redembedded.com> References: <4B96817D.1080404@redembedded.com> Message-ID: Yes it does now. i downloaded it from http://moinejf.free.fr/ i guess it is the same driver that they have ported to davinci git kernel. On Tue, Mar 9, 2010 at 10:42 PM, Darren Longhorn < darren.longhorn at redembedded.com> wrote: > Yuvraj Pasi wrote: > > Hi, > > I am using a usb camera with gspca driver for dm6446 based system. i > > have used capture application given in v4l2 documentation > > Does gspca support v4l2 now? It didn't when I was using it a couple of > years ago. > -- Thanks & regards yuvraj pasi -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jon.Povey at racelogic.co.uk Wed Mar 10 00:49:56 2010 From: Jon.Povey at racelogic.co.uk (Jon Povey) Date: Wed, 10 Mar 2010 06:49:56 -0000 Subject: Custom pinmuxing on DM355 with git kernel Message-ID: <2992BF78ED49594EB72AD7F4F8642BBDF5E86D@RL-SBS.racelogic.local> I am porting our drivers from MV 2.6.10 kernel to Kevin's git kernel. We have 3 different boards using DM355, with different gpio / pinmux setups. So far, our device drivers are modules which fiddle the pinmux registers directly. I see in the git kernel that pinmux settings are defined in an array per-CPU (i.e. dm355.c) and the board file calls davinci_cfg_reg for those it wants setup. I'd like to build a single kernel which can support all of our board types, possibly detecting which it is running on by a parameter passed from u-boot. I could just update the hacks in our drivers, and our bootloader should setup the muxing right anyway, but if there is a supported "right" way to do this then I'd be interested to hear it. I like the debug warning messages if muxing is changed and feel like I should be using that code. At the moment I am thinking that I might want to split up davinci_cfg_reg into two functions so it's not hardwired to soc_info->pinmux_pins, and I could pass my own mux_config structs in. If this is of interest I can have a go at doing this and submitting the patch here. Any thoughts welcome. thanks. -- Jon Povey jon.povey at racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network From nsekhar at ti.com Wed Mar 10 02:33:01 2010 From: nsekhar at ti.com (Sekhar Nori) Date: Wed, 10 Mar 2010 14:03:01 +0530 Subject: [PATCH 1/2 v2] davinci: da830/omap-l137 evm: add support for GPIO based MMC/SD card detection Message-ID: <1268209982-25477-1-git-send-email-nsekhar@ti.com> From: Vipin Bhandari The DA830/OMAP-L137 EVM has GPIO based card detection logic, but the current code does not use it. Add support for GPIO based card detection to avoid reading the card to see if a card is present or not. Signed-off-by: Vipin Bhandari Signed-off-by: Sekhar Nori --- This is a replacement for patch submitted by Vipin earlier. http://patchwork.kernel.org/patch/69999/ The patch has been split into two and the description updated. arch/arm/mach-davinci/board-da830-evm.c | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c index dc19870..8e67037 100644 --- a/arch/arm/mach-davinci/board-da830-evm.c +++ b/arch/arm/mach-davinci/board-da830-evm.c @@ -229,14 +229,21 @@ static const short da830_evm_mmc_sd_pins[] = { }; #define DA830_MMCSD_WP_PIN GPIO_TO_PIN(2, 1) +#define DA830_MMCSD_CD_PIN GPIO_TO_PIN(2, 2) static int da830_evm_mmc_get_ro(int index) { return gpio_get_value(DA830_MMCSD_WP_PIN); } +static int da830_evm_mmc_get_cd(int index) +{ + return !gpio_get_value(DA830_MMCSD_CD_PIN); +} + static struct davinci_mmc_config da830_evm_mmc_config = { .get_ro = da830_evm_mmc_get_ro, + .get_cd = da830_evm_mmc_get_cd, .wires = 4, .max_freq = 50000000, .caps = MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED, @@ -262,6 +269,14 @@ static inline void da830_evm_init_mmc(void) } gpio_direction_input(DA830_MMCSD_WP_PIN); + ret = gpio_request(DA830_MMCSD_CD_PIN, "MMC CD\n"); + if (ret) { + pr_warning("da830_evm_init: can not open GPIO %d\n", + DA830_MMCSD_CD_PIN); + return; + } + gpio_direction_input(DA830_MMCSD_CD_PIN); + ret = da8xx_register_mmcsd0(&da830_evm_mmc_config); if (ret) { pr_warning("da830_evm_init: mmc/sd registration failed: %d\n", -- 1.6.2.4 From nsekhar at ti.com Wed Mar 10 02:33:02 2010 From: nsekhar at ti.com (Sekhar Nori) Date: Wed, 10 Mar 2010 14:03:02 +0530 Subject: [PATCH 2/2 v2] davinci: da830/omap-l137 evm: use 8-wire MMC/SD card support In-Reply-To: <1268209982-25477-1-git-send-email-nsekhar@ti.com> References: <1268209982-25477-1-git-send-email-nsekhar@ti.com> Message-ID: <1268209982-25477-2-git-send-email-nsekhar@ti.com> From: Vipin Bhandari The merge for 2.6.34 brings in 8-bit support to the DaVinci MMC/SD driver. This patch updates the platform data for DA830/OMAP-L137 EVM to use 8-wire support available in the driver. Signed-off-by: Vipin Bhandari Signed-off-by: Sekhar Nori --- arch/arm/mach-davinci/board-da830-evm.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c index 8e67037..ea293b8 100644 --- a/arch/arm/mach-davinci/board-da830-evm.c +++ b/arch/arm/mach-davinci/board-da830-evm.c @@ -244,7 +244,7 @@ static int da830_evm_mmc_get_cd(int index) static struct davinci_mmc_config da830_evm_mmc_config = { .get_ro = da830_evm_mmc_get_ro, .get_cd = da830_evm_mmc_get_cd, - .wires = 4, + .wires = 8, .max_freq = 50000000, .caps = MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED, .version = MMC_CTLR_VERSION_2, -- 1.6.2.4 From raghu_ramaraj at mindtree.com Wed Mar 10 03:04:09 2010 From: raghu_ramaraj at mindtree.com (Raghu Ramaraj) Date: Wed, 10 Mar 2010 14:34:09 +0530 Subject: RAW capture mode on DM6467 Message-ID: Hi , We are trying to Interface a Image Sensor with Dm6467 in Raw Caputure Mode .Our sensor that will give YUV foramt. We have tried the following values in vpif .c . But we didn't get any interrupt (Means its not capturing ) {"NTSC", 720, 480, 30, 1, 1, 2090, 1472, 1, 350, 839, 0, \ 0, 0, 488, 1, 0, 0}, \ {"NTSC-T", 720, 480, 30, 1, 1, 1352, 1280, 1, 405, 1122, 0, \ 0, 0, 525, 1, 0, 0},\ {"NTSC-NWI", 720, 480, 30, 1, 1, 1352, 1280, 1, 405, 1122, 0, \ 0, 0, 525, 1, 0, 0} Do we need to fill sav2eav, eav2sav? Thanks & Regards, Raghu ________________________________ http://www.mindtree.com/email/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsekhar at ti.com Wed Mar 10 03:41:24 2010 From: nsekhar at ti.com (Sekhar Nori) Date: Wed, 10 Mar 2010 15:11:24 +0530 Subject: [PATCH] davinci: da8xx/omap-l1: fix build error when CONFIG_DAVINCI_MUX is undefined Message-ID: <1268214084-2416-1-git-send-email-nsekhar@ti.com> The da8xx/omap-l1 boards refuse to build when CONFIG_DAVINCI_MUX is undefined because arch/arm/mach-davinci/mux.c:da8xx_pinmux_setup() is not defined. This patch fixes this issue. This is build tested with davinci_all_defconfig and da8xx_omapl_defconfig and boot tested on DA830 EVM. Reported-by: Shanmuga Sundaram Mahendran Signed-off-by: Sekhar Nori --- arch/arm/mach-davinci/include/mach/da8xx.h | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h index cc9be7f..b87a6ba 100644 --- a/arch/arm/mach-davinci/include/mach/da8xx.h +++ b/arch/arm/mach-davinci/include/mach/da8xx.h @@ -144,6 +144,10 @@ extern const short da850_mmcsd0_pins[]; extern const short da850_nand_pins[]; extern const short da850_nor_pins[]; +#ifdef CONFIG_DAVINCI_MUX int da8xx_pinmux_setup(const short pins[]); +#else +static inline int da8xx_pinmux_setup(const short pins[]) { return 0; } +#endif #endif /* __ASM_ARCH_DAVINCI_DA8XX_H */ -- 1.6.2.4 From chaithrika at ti.com Wed Mar 10 03:18:33 2010 From: chaithrika at ti.com (Chaithrika U S) Date: Wed, 10 Mar 2010 14:48:33 +0530 Subject: [PATCH] ASoC: DaVinci: Add hw_param callback for S/PDIF DIT link Message-ID: <1268212713-12041-1-git-send-email-chaithrika@ti.com> On TI DM6467 EVM, S/PDIF DIT codec fails to open as it is unable to install hardware params. This dummy codec has no set_fmt and set_sysclk implementations and calls from the application to these functions cause errors. This patch adds a new hardware params callback function for S/PDIF transciever codec. Signed-off-by: Chaithrika U S Tested-by: Anuj Aggarwal --- This patch has been re-worked upon based on the review comments for http://mailman.alsa-project.org/pipermail/alsa-devel/2010-January/024621.html Applies to ALSA GIT tree on branch topic/asoc at http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=shortlog; h=topic/asoc sound/soc/davinci/davinci-evm.c | 16 +++++++++++++++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c index 7ccbe66..dba6651 100644 --- a/sound/soc/davinci/davinci-evm.c +++ b/sound/soc/davinci/davinci-evm.c @@ -81,10 +81,24 @@ static int evm_hw_params(struct snd_pcm_substream *substream, return 0; } +static int evm_spdif_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai; + + /* set cpu DAI configuration */ + return snd_soc_dai_set_fmt(cpu_dai, AUDIO_FORMAT); +} + static struct snd_soc_ops evm_ops = { .hw_params = evm_hw_params, }; +static struct snd_soc_ops evm_spdif_ops = { + .hw_params = evm_spdif_hw_params, +}; + /* davinci-evm machine dapm widgets */ static const struct snd_soc_dapm_widget aic3x_dapm_widgets[] = { SND_SOC_DAPM_HP("Headphone Jack", NULL), @@ -165,7 +179,7 @@ static struct snd_soc_dai_link dm6467_evm_dai[] = { .stream_name = "spdif", .cpu_dai = &davinci_mcasp_dai[DAVINCI_MCASP_DIT_DAI], .codec_dai = &dit_stub_dai, - .ops = &evm_ops, + .ops = &evm_spdif_ops, }, }; static struct snd_soc_dai_link da8xx_evm_dai = { -- 1.5.6 From broonie at opensource.wolfsonmicro.com Wed Mar 10 06:00:22 2010 From: broonie at opensource.wolfsonmicro.com (Mark Brown) Date: Wed, 10 Mar 2010 12:00:22 +0000 Subject: [PATCH] ASoC: DaVinci: Add hw_param callback for S/PDIF DIT link In-Reply-To: <1268212713-12041-1-git-send-email-chaithrika@ti.com> References: <1268212713-12041-1-git-send-email-chaithrika@ti.com> Message-ID: <20100310120022.GL24422@rakim.wolfsonmicro.main> On Wed, Mar 10, 2010 at 02:48:33PM +0530, Chaithrika U S wrote: > On TI DM6467 EVM, S/PDIF DIT codec fails to open as it is unable to install > hardware params. This dummy codec has no set_fmt and set_sysclk implementations > and calls from the application to these functions cause errors. This patch adds > a new hardware params callback function for S/PDIF transciever codec. Applied, thanks. From schen at mvista.com Wed Mar 10 06:24:52 2010 From: schen at mvista.com (Steve Chen) Date: Wed, 10 Mar 2010 06:24:52 -0600 Subject: Custom pinmuxing on DM355 with git kernel In-Reply-To: <2992BF78ED49594EB72AD7F4F8642BBDF5E86D@RL-SBS.racelogic.local> References: <2992BF78ED49594EB72AD7F4F8642BBDF5E86D@RL-SBS.racelogic.local> Message-ID: On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey wrote: > I am porting our drivers from MV 2.6.10 kernel to Kevin's git kernel. > > We have 3 different boards using DM355, with different gpio / pinmux > setups. So far, our device drivers are modules which fiddle the pinmux > registers directly. > > I see in the git kernel that pinmux settings are defined in an array > per-CPU (i.e. dm355.c) and the board file calls davinci_cfg_reg for > those it wants setup. > > I'd like to build a single kernel which can support all of our board > types, possibly detecting which it is running on by a parameter passed > from u-boot. > > I could just update the hacks in our drivers, and our bootloader should > setup the muxing right anyway, but if there is a supported "right" way > to do this then I'd be interested to hear it. I like the debug warning > messages if muxing is changed and feel like I should be using that code. > > At the moment I am thinking that I might want to split up > davinci_cfg_reg into two functions so it's not hardwired to > soc_info->pinmux_pins, and I could pass my own mux_config structs in. If > this is of interest I can have a go at doing this and submitting the > patch here. > > Any thoughts welcome. thanks. > For board specific pinmux, you can put them in board-dm355-*.c. There are some board specific pinmux setup in board-da830-evm.c. Look for da8xx_pinmux_setup. Regards, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From mile.davidovic at gmail.com Wed Mar 10 06:57:28 2010 From: mile.davidovic at gmail.com (Mile Davidovic) Date: Wed, 10 Mar 2010 13:57:28 +0100 Subject: DM365, NAND and FS Message-ID: <6988e0d1003100457g53b5f70ftfdcd144ecba2adc3@mail.gmail.com> Hello On DM365 board I saw following printout: U-Boot 2009.03 (Nov 16 2009 - 13:02:47) I2C: ready DRAM: 128 MB NAND: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit) Bad block table found at page 524224, version 0x01 Bad block table found at page 524160, version 0x01 NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit) Bad block table found at page 524224, version 0x01 Bad block table found at page 524096, version 0x01 2048 MiB In: serial .... NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit) 2 NAND chips detected Bad block table found at page 524224, version 0x01 Bad block table found at page 1048512, version 0x01 Bad block table found at page 524160, version 0x01 Bad block table found at page 1048384, version 0x01 nand_read_bbt: Bad block at 0x000000820000 nand_read_bbt: Bad block at 0x000008aa0000 nand_read_bbt: Bad block at 0x00000fac0000 nand_read_bbt: Bad block at 0x000015280000 nand_read_bbt: Bad block at 0x000016ea0000 nand_read_bbt: Bad block at 0x00001a720000 nand_read_bbt: Bad block at 0x00001c120000 nand_read_bbt: Bad block at 0x0000238e0000 nand_read_bbt: Bad block at 0x000028340000 nand_read_bbt: Bad block at 0x000028680000 nand_read_bbt: Bad block at 0x000030640000 nand_read_bbt: Bad block at 0x000032560000 nand_read_bbt: Bad block at 0x0000382c0000 nand_read_bbt: Bad block at 0x00003bec0000 nand_read_bbt: Bad block at 0x00003c240000 nand_read_bbt: Bad block at 0x00004bd60000 nand_read_bbt: Bad block at 0x00004be40000 nand_read_bbt: Bad block at 0x0000685c0000 nand_read_bbt: Bad block at 0x00006ea20000 nand_read_bbt: Bad block at 0x00006ede0000 nand_read_bbt: Bad block at 0x00006fda0000 nand_read_bbt: Bad block at 0x000076020000 nand_read_bbt: Bad block at 0x00007df40000 nand_read_bbt: Bad block at 0x00007e720000 nand_read_bbt: Bad block at 0x00007ffc0000 Creating 5 MTD partitions on "davinci_nand.0": 0x000000000000-0x000000f00000 : "bootloader" 0x000000f00000-0x000001000000 : "params" 0x000001000000-0x000001400000 : "kernel" 0x000001400000-0x000021400000 : "filesystem1" 0x000021400000-0x000080000000 : "filesystem2" davinci_nand davinci_nand.0: controller rev. 2.3 ... mtd->read(0xb8 bytes from 0x190c6f48) returned ECC error JFFS2 notice: (1007) jffs2_get_inode_nodes: Node header CRC failed at 0x190c6f48. {0219,c0e0,71000000,99faccda} JFFS2 notice: (1007) jffs2_get_inode_nodes: Node header CRC failed at 0x190c6e88. {0219,c0e0,71000000,99faccda} JFFS2 notice: (1007) jffs2_get_inode_nodes: Node header CRC failed at 0x190c6d20. {0219,68e0,ac000001,9973d181} JFFS2 notice: (1007) jffs2_get_inode_nodes: Node header CRC failed at 0x190c6c60. {0219,c0e0,71000000,99faccda} JFFS2 notice: (1007) jffs2_get_inode_nodes: Node header CRC failed at 0x190c6ba0. {0219,c0e0,71000000,99faccda} ... Also during boot I got following: Empty flash at 0x092b9700 ends at 0x092b9800 Empty flash at 0x460b4d44 ends at 0x460b5000 Empty flash at 0x59a0d8dc ends at 0x59a0e000 My questions are: - is it normal board behavior (we have issues with JFFS2 and NAND) from start - is it possible that we somehow "repair" this board? - what is "recommended" FS for NAND? - is any chance that problems with NAND is caused with wrong u-boot, linux, ... Kind regards mile From idriss.ghodhbane at gmail.com Wed Mar 10 07:10:49 2010 From: idriss.ghodhbane at gmail.com (Idriss Ghodhbane) Date: Wed, 10 Mar 2010 14:10:49 +0100 Subject: SVN Checkout problem Message-ID: <90d17c5d1003100510m28cdb00cna6689abeaae170c2@mail.gmail.com> Hi everybody, I want to use the latest SVN Code of gstreamer Dmai for TI Davinci DM355. For this I have used the command line listed in this url : https://gforge.ti.com/gf/project/gstreamer_ti/scmsvn/?action=AccessInfo and this command was $ svn checkout --username *username* https://gstreamer.ti.com/svn/gstreamer_ti/trunk/gstreamer_ti But I have this error : svn: PROPFIND request failed on '/svn/gstreamer_ti/trunk' svn: PROPFIND of '/svn/gstreamer_ti/trunk': Could not resolve hostname ` gstreamer.ti.com': No address associated with hostname ( https://gstreamer.ti.com) I am wondering how to fix this problem. Can you help me to get the latest SVN Code ? Big Thanks -- IDRISS GHODHBANE -------------- next part -------------- An HTML attachment was scrubbed... URL: From gasparini at imavis.com Wed Mar 10 07:46:24 2010 From: gasparini at imavis.com (Andrea Gasparini) Date: Wed, 10 Mar 2010 14:46:24 +0100 Subject: SVN Checkout problem In-Reply-To: <90d17c5d1003100510m28cdb00cna6689abeaae170c2@mail.gmail.com> References: <90d17c5d1003100510m28cdb00cna6689abeaae170c2@mail.gmail.com> Message-ID: <201003101446.24785.gasparini@imavis.com> Hi, Given that: > svn: PROPFIND of '/svn/gstreamer_ti/trunk': Could not resolve hostname ` > gstreamer.ti.com': No address associated with hostname ( > https://gstreamer.ti.com) > > I am wondering how to fix this problem. > Can you help me to get the latest SVN Code ? perhaps configuring your network in order to resolv gstreamer.ti.com ?? :) bye -- Andrea Gasparini ---- ImaVis S.r.l. ---- web: www.imavis.com From nyhetsbrev at dokumera.anp.se Tue Mar 9 01:36:57 2010 From: nyhetsbrev at dokumera.anp.se (DokuMera Nyhetsbrev) Date: Tue, 09 Mar 2010 08:36:57 +0100 Subject: Krishantering Message-ID: <1256581096.5140@dokumera.anp.se> Om du har problem med att l?sa detta e-postmeddelande, klicka h?r (http://www.anp.se/newsletter/581870/44405D4074454B5C447043475843) f?r en webb-version. V?rt nyhetsbrev skickas automatiskt till v?ra kunder och intressenter. Vill du inte ha detta nyhetsbrev fram?ver, klicka h?r f?r att avprenumerera (http://www.anp.se/oa/581870/44405D4074454B5C447043475843). Nyhetsbrev 10/2010Detta nyhetsbrev ?r skickat till: davinci-linux-open-source at linux.davincidsp.com (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se&from=173902333&prefix=dm) (http://www.anp.se/taf/581870/44405D4074454B5C447043475843) (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_newsletters.asp&from=173902333&prefix=dm) (http://www.anp.se/newsletter.asp?sqid=581870&sid=44405D4074454B5C447043475843&print=true) Krishantering Genom att vara v?l f?rberedd kan kritiska situationer hanteras l?ttare, men det kr?ver ocks? planering. Genom att ha en handlingsplan n?r krisen v?l uppst?tt samt ?va krisledning kan mycket vara vunnet. N?gra av f?rdelarna med krislednings?vning; - Krisledningen blir b?ttre f?rberedd vid en eventuell kris - Verksamhetens krav p? hur en kris ska hanteras simuleras, testas och ?vas - Krisledningen f?r m?jlighet att ?va sin samarbetsf?rm?ga under sv?ra f?rh?llanden - Viktiga f?rb?ttringsomr?den i f?retagets krisorganisation kan identifieras N?r ni ser ?ver eventuella krissituationer kanske ni ?ven b?r passa p? att g? igenom rutinerna kring det systematiska brandskyddet. Lag (2003:778) om skydd mot olyckor ?r den lag som fr?mst styr brandskyddsarbetet i f?retag. Enligt lagen har den som ?ger en byggnad eller den som bedriver verksamhet d?r, det yttersta ansvaret f?r sitt brandskydd. Veckans dokument Checklista kontinuitetsplan >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/checklista_kontinuitetsplan_sakerhet_3225_dd.html&from=173902333&prefix=dm) Delegeringshandling krisledning >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/delegeringshandling_sammankallande_krisledning_3232_dd.html&from=173902333&prefix=dm) Loggbok incidenter >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/loggbok_intraffade_incidenter_kris_3231_dd.html&from=173902333&prefix=dm) Checklista systematiskt brandskyddsarbete>> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/checklista_systematiskt_brandskyddsarbete_1518_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm) Brandskyddsregler>> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/brandskyddsregler_1524_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm) Brandskyddspolicy>> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/brandskyddspolicy_1520_dd.html&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm) Veckans expertsvar Vilka lagar g?ller inom brandskyddsomr?det? >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_atq_search.asp?s_kw=190$SearchButtonWasPushed=Yes&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm) Vad g?r man p? en skyddsrond? >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_atq_search.asp?s_kw=591$SearchButtonWasPushed=Yes&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm) ?r arbetsgivaren tvungen att utreda olyckor p? arbetsplatsen? >> (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_atq_search.asp?s_kw=1650$SearchButtonWasPushed=Yes&from=davinci-linux-open-source at linux.davincidsp.com&prefix=dm) (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/foretagspaketet_1321_dc.html&from=173902333&prefix=dm) (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_atq_ppdviewer.asp&from=173902333&prefix=dm) (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/styckvisa_dokumentmallar_1330_dc.html&from=173902333&prefix=dm) (http://www.dokumera.se/newsletter_redirect.asp?to=http://www.dokumera.se/out_contactusmessage.asp&from=173902333&prefix=dm) F?r en kostnadsfri exklusiv presentation av hur DokuMera kan spara tiotusentals kronor ?t just mitt f?retag. Givetvis ?r du varmt v?lkommen att ringa oss p? 08-664 04 50. Inneh?llet i nyhetsbrev ska inte tolkas som ett ?tagande fr?n DokuMeras sida. Informationen s?nds ut i befintligt skick, utan garantier och digitala signaturer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bniebuhr3 at gmail.com Tue Mar 9 16:48:03 2010 From: bniebuhr3 at gmail.com (Brian Niebuhr) Date: Tue, 9 Mar 2010 16:48:03 -0600 Subject: [PATCH] davinci: edma: clear events in edma_start() Message-ID: <1268174883-13933-1-git-send-email-bniebuhr@efjohnson.com> This patch fixes an issue where a DMA channel can erroneously process an event generated by a previous transfer. A failure case is where DMA is being used for SPI transmit and receive channels on OMAP L138. In this case there is a single bit that controls all event generation from the SPI peripheral. Therefore it is possible that between when edma_stop() has been called for the transmit channel on a previous transfer and edma_start() is called for the transmit channel on a subsequent transfer, that a transmit event has been generated. The fix is to clear events in edma_start(). This prevents false events from being processed when events are enabled for that channel. Signed-off-by: Brian Niebuhr --- arch/arm/mach-davinci/dma.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index 5cd48fa..52c16ff 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -1290,7 +1290,8 @@ int edma_start(unsigned channel) /* EDMA channel with event association */ pr_debug("EDMA: ER%d %08x\n", j, edma_shadow0_read_array(ctlr, SH_ER, j)); - /* Clear any pending error */ + /* Clear any pending event or error */ + edma_write_array(ctlr, EDMA_ECR, j, mask); edma_write_array(ctlr, EDMA_EMCR, j, mask); /* Clear any SER */ edma_shadow0_write_array(ctlr, SH_SECR, j, mask); -- 1.6.3.3 From cornel at upload-ro.ro Wed Mar 10 14:36:54 2010 From: cornel at upload-ro.ro (cornel) Date: Wed, 10 Mar 2010 12:36:54 -0800 Subject: invitatie Message-ID: <20100310.AHPRJEPYYODIIIZL@upload-ro.ro> An HTML attachment was scrubbed... URL: From lrg at slimlogic.co.uk Wed Mar 10 05:08:13 2010 From: lrg at slimlogic.co.uk (Liam Girdwood) Date: Wed, 10 Mar 2010 11:08:13 +0000 Subject: [alsa-devel] [PATCH] ASoC: DaVinci: Add hw_param callback for S/PDIF DIT link In-Reply-To: <1268212713-12041-1-git-send-email-chaithrika@ti.com> References: <1268212713-12041-1-git-send-email-chaithrika@ti.com> Message-ID: <1268219293.3760.29.camel@odin> On Wed, 2010-03-10 at 14:48 +0530, Chaithrika U S wrote: > On TI DM6467 EVM, S/PDIF DIT codec fails to open as it is unable to install > hardware params. This dummy codec has no set_fmt and set_sysclk implementations > and calls from the application to these functions cause errors. This patch adds > a new hardware params callback function for S/PDIF transciever codec. > > Signed-off-by: Chaithrika U S > Tested-by: Anuj Aggarwal Acked-by: Liam Girdwood -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk From idriss.ghodhbane at gmail.com Wed Mar 10 08:36:52 2010 From: idriss.ghodhbane at gmail.com (Idriss Ghodhbane) Date: Wed, 10 Mar 2010 15:36:52 +0100 Subject: G711 encoder decoder+Gstreamer+DM355 Message-ID: <90d17c5d1003100636r31e60aakde262ecc7a863253@mail.gmail.com> Hi everybody, After installing DMAI Gstreamer plugin on DM355, I tried to play a G711 audio file using the "TIauddec" element but i didn't find the g711dec (decoder) in codecName property. I found in the net that G711 codec is supported by Dm355 DVEM but is not integrated in gstreamer. Is there a solution to integrate g711 codec in gstreamer? -- IDRISS GHODHBANE -------------- next part -------------- An HTML attachment was scrubbed... URL: From s-paulraj at ti.com Wed Mar 10 09:25:27 2010 From: s-paulraj at ti.com (Paulraj, Sandeep) Date: Wed, 10 Mar 2010 09:25:27 -0600 Subject: DM365, NAND and FS In-Reply-To: <6988e0d1003100457g53b5f70ftfdcd144ecba2adc3@mail.gmail.com> References: <6988e0d1003100457g53b5f70ftfdcd144ecba2adc3@mail.gmail.com> Message-ID: <0554BEF07D437848AF01B9C9B5F0BC5D9C3624DB@dlee01.ent.ti.com> > > Hello > On DM365 board I saw following printout: > U-Boot 2009.03 (Nov 16 2009 - 13:02:47) > > I2C: ready > DRAM: 128 MB > NAND: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND > 1GiB 3,3V 8-bit) > Bad block table found at page 524224, version 0x01 > Bad block table found at page 524160, version 0x01 > NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V > 8-bit) > Bad block table found at page 524224, version 0x01 > Bad block table found at page 524096, version 0x01 > 2048 MiB > In: serial > .... > NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V > 8-bit) > 2 NAND chips detected > Bad block table found at page 524224, version 0x01 > Bad block table found at page 1048512, version 0x01 > Bad block table found at page 524160, version 0x01 > Bad block table found at page 1048384, version 0x01 > nand_read_bbt: Bad block at 0x000000820000 > nand_read_bbt: Bad block at 0x000008aa0000 > nand_read_bbt: Bad block at 0x00000fac0000 > nand_read_bbt: Bad block at 0x000015280000 > nand_read_bbt: Bad block at 0x000016ea0000 > nand_read_bbt: Bad block at 0x00001a720000 > nand_read_bbt: Bad block at 0x00001c120000 > nand_read_bbt: Bad block at 0x0000238e0000 > nand_read_bbt: Bad block at 0x000028340000 > nand_read_bbt: Bad block at 0x000028680000 > nand_read_bbt: Bad block at 0x000030640000 > nand_read_bbt: Bad block at 0x000032560000 > nand_read_bbt: Bad block at 0x0000382c0000 > nand_read_bbt: Bad block at 0x00003bec0000 > nand_read_bbt: Bad block at 0x00003c240000 > nand_read_bbt: Bad block at 0x00004bd60000 > nand_read_bbt: Bad block at 0x00004be40000 > nand_read_bbt: Bad block at 0x0000685c0000 > nand_read_bbt: Bad block at 0x00006ea20000 > nand_read_bbt: Bad block at 0x00006ede0000 > nand_read_bbt: Bad block at 0x00006fda0000 > nand_read_bbt: Bad block at 0x000076020000 > nand_read_bbt: Bad block at 0x00007df40000 > nand_read_bbt: Bad block at 0x00007e720000 > nand_read_bbt: Bad block at 0x00007ffc0000 There is nothing wrong in getting these messages. U-boot is merely reporting bad blocks > Creating 5 MTD partitions on "davinci_nand.0": > 0x000000000000-0x000000f00000 : "bootloader" > 0x000000f00000-0x000001000000 : "params" > 0x000001000000-0x000001400000 : "kernel" > 0x000001400000-0x000021400000 : "filesystem1" > 0x000021400000-0x000080000000 : "filesystem2" > davinci_nand davinci_nand.0: controller rev. 2.3 > ... > mtd->read(0xb8 bytes from 0x190c6f48) returned ECC error > JFFS2 notice: (1007) jffs2_get_inode_nodes: Node header CRC failed at > 0x190c6f48. {0219,c0e0,71000000,99faccda} > JFFS2 notice: (1007) jffs2_get_inode_nodes: Node header CRC failed at > 0x190c6e88. {0219,c0e0,71000000,99faccda} > JFFS2 notice: (1007) jffs2_get_inode_nodes: Node header CRC failed at > 0x190c6d20. {0219,68e0,ac000001,9973d181} > JFFS2 notice: (1007) jffs2_get_inode_nodes: Node header CRC failed at > 0x190c6c60. {0219,c0e0,71000000,99faccda} > JFFS2 notice: (1007) jffs2_get_inode_nodes: Node header CRC failed at > 0x190c6ba0. {0219,c0e0,71000000,99faccda} > ... > Also during boot I got following: > Empty flash at 0x092b9700 ends at 0x092b9800 > Empty flash at 0x460b4d44 ends at 0x460b5000 > Empty flash at 0x59a0d8dc ends at 0x59a0e000 > > My questions are: > - is it normal board behavior (we have issues with JFFS2 and NAND) from > start > - is it possible that we somehow "repair" this board? > - what is "recommended" FS for NAND? > - is any chance that problems with NAND is caused with wrong u-boot, > linux, ... > > Kind regards > mile > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source From deepaks at hcl.in Wed Mar 10 10:47:53 2010 From: deepaks at hcl.in (Deepak Shankar-ERS,HCLTech.) Date: Wed, 10 Mar 2010 22:17:53 +0530 Subject: libmpeg4.a math.h dependency. Message-ID: Hi, I tried to update the png library to the v1.4(latest from libpng). However after updating this when I tried to rebuild the dvsdk the libmpeg4enc.a is not linking. I did a diff and found that the math.h related operations are removed from the latest pnglibrary(which Im not able to reason out - separately). Now since the code libraries are dependent on the math.h why is it include through the libpng shared object instead of directly from libmpeg4.a Is there a way the libmpeg4.a could be locally rebuilt? ********** /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/../target/usr/lib/libpng. so: undefined reference to `pow' ************** Rest of dump: ************** /home/avalon/dvsdk_1_30_00_40/dm355_codecs_1_13_000/packages/ti/sdo/codecs/mpeg4 enc/dm355/lib/libmp4enc.a(mp4venc_rate_cnt.o)(.text+0x30): In function `MP4VENC_ TI_DM350_calc_d0': mp4venc_rate_cnt.c: undefined reference to `floor' /home/avalon/dvsdk_1_30_00_40/dm355_codecs_1_13_000/packages/ti/sdo/codecs/mpeg4 enc/dm355/lib/libmp4enc.a(mp4venc_rate_cnt.o)(.text+0xa0): In function `MP4VENC_ TI_DM350_calc_r': mp4venc_rate_cnt.c: undefined reference to `floor' /home/avalon/dvsdk_1_30_00_40/dm355_codecs_1_13_000/packages/ti/sdo/codecs/mpeg4 enc/dm355/lib/libmp4enc.a(mp4venc_rate_cnt.o)(.text+0xe4): In function `MP4VENC_ TI_DM350_calc_Xi': mp4venc_rate_cnt.c: undefined reference to `floor' /home/avalon/dvsdk_1_30_00_40/dm355_codecs_1_13_000/packages/ti/sdo/codecs/mpeg4 enc/dm355/lib/libmp4enc.a(mp4venc_rate_cnt.o)(.text+0x134): In function `MP4VENC _TI_DM350_calc_Xp': mp4venc_rate_cnt.c: undefined reference to `floor' /home/avalon/dvsdk_1_30_00_40/dm355_codecs_1_13_000/packages/ti/sdo/codecs/mpeg4 enc/dm355/lib/libmp4enc.a(mp4venc_rate_cnt.o)(.text+0x1cc): In function `MP4VENC _TI_DM350_calc_T': mp4venc_rate_cnt.c: undefined reference to `floor' /home/avalon/dvsdk_1_30_00_40/dm355_codecs_1_13_000/packages/ti/sdo/codecs/mpeg4 enc/dm355/lib/libmp4enc.a(mp4venc_rate_cnt.o)(.text+0x21c):mp4venc_rate_cnt.c: m ore undefined references to `floor' follow /home/avalon/dvsdk_1_30_00_40/dm355_codecs_1_13_000/packages/ti/sdo/codecs/mpeg4 enc/dm355/lib/libmp4enc.a(mp4venc_rate_cnt_init.o)(.text+0xc4): In function `MP4 VENC_TI_DM350_rc_init_seq': mp4venc_rate_cnt_init.c: undefined reference to `ceil' /home/avalon/dvsdk_1_30_00_40/dm355_codecs_1_13_000/packages/ti/sdo/codecs/mpeg4 enc/dm355/lib/libmp4enc.a(mp4venc_rate_cnt_init.o)(.text+0x104):mp4venc_rate_cnt _init.c: undefined reference to `floor' /home/avalon/dvsdk_1_30_00_40/dm355_codecs_1_13_000/packages/ti/sdo/codecs/mpeg4 enc/dm355/lib/libmp4enc.a(mp4venc_rate_cnt_init.o)(.text+0x13c):mp4venc_rate_cnt _init.c: undefined reference to `floor' /home/avalon/dvsdk_1_30_00_40/dm355_codecs_1_13_000/packages/ti/sdo/codecs/mpeg4 enc/dm355/lib/libmp4enc.a(mp4venc_rate_cnt_init.o)(.text+0x174):mp4venc_rate_cnt _init.c: undefined reference to `floor' /home/avalon/dvsdk_1_30_00_40/dm355_codecs_1_13_000/packages/ti/sdo/codecs/mpeg4 enc/dm355/lib/libmp4enc.a(mp4venc_rate_cnt_init.o)(.text+0x200): In function `MP 4VENC_TI_DM350_rc_init_GOP': mp4venc_rate_cnt_init.c: undefined reference to `floor' /home/avalon/dvsdk_1_30_00_40/dm355_codecs_1_13_000/packages/ti/sdo/codecs/mpeg4 enc/dm355/lib/libmp4enc.a(mp4venc_rate_cnt_init.o)(.text+0x274): In function `MP 4VENC_TI_DM350_rc_init_pict': mp4venc_rate_cnt_init.c: undefined reference to `floor' /home/avalon/dvsdk_1_30_00_40/dm355_codecs_1_13_000/packages/ti/sdo/codecs/mpeg4 enc/dm355/lib/libmp4enc.a(mp4venc_rate_cnt_init.o)(.text+0x2dc):mp4venc_rate_cnt _init.c: more undefined references to `floor' follow /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/../target/usr/lib/libpng. so: undefined reference to `pow' Cheers, Deepak Shankar V DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- From broonie at opensource.wolfsonmicro.com Wed Mar 10 11:02:06 2010 From: broonie at opensource.wolfsonmicro.com (Mark Brown) Date: Wed, 10 Mar 2010 17:02:06 +0000 Subject: [PATCH v2 3/5] ASoC: DaVinci: CQ93VC Voice Codec In-Reply-To: <1268156118-16939-1-git-send-email-miguel.aguilar@ridgerun.com> References: <1268156118-16939-1-git-send-email-miguel.aguilar@ridgerun.com> Message-ID: <20100310170205.GB22626@rakim.wolfsonmicro.main> On Tue, Mar 09, 2010 at 11:35:18AM -0600, miguel.aguilar at ridgerun.com wrote: > From: Miguel Aguilar > > Currently the DM365 is the only SoC that includes this Voice Codec. This looks OK to me but could you please resend the full series rather than just this one patch? From albertbu at gmail.com Wed Mar 10 13:47:47 2010 From: albertbu at gmail.com (Albert Burbea) Date: Wed, 10 Mar 2010 21:47:47 +0200 Subject: invitatie In-Reply-To: <20100310.AHPRJEPYYODIIIZL@upload-ro.ro> References: <20100310.AHPRJEPYYODIIIZL@upload-ro.ro> Message-ID: hi everybody on list is it possible to filter out this kind of spam mail ? Thanks for your attention Albert 2010/3/10 cornel > *Cursuri Gratuite* > > > Salut , > > *Ai primit o invitatie la Cursuri Gratuite !* > > - Iti poti alege singur timpul si ritmul de invatare; > - Echipa de profesionisti; > - Usor accesibil; > - Forma de pregatire moderna; > - GRATUIT ! > > Succes ! > www.cursurigratuiteonline.ro > > > Ai fost invitat pe Cursuri Gratuite. > Copyright ? 2009 Cursuri Gratuite. Toate drepturile rezervate. > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > -- Albert Burbea Harishonim 8 Ramat Gan 52502, Israel Tel/Fax + 972-3-7526016 Mobile: +972-52-3541842 -------------- next part -------------- An HTML attachment was scrubbed... URL: From diego.dompe at ridgerun.com Wed Mar 10 14:46:08 2010 From: diego.dompe at ridgerun.com (Diego Dompe) Date: Wed, 10 Mar 2010 14:46:08 -0600 Subject: G711 encoder decoder+Gstreamer+DM355 In-Reply-To: <90d17c5d1003100636r31e60aakde262ecc7a863253@mail.gmail.com> References: <90d17c5d1003100636r31e60aakde262ecc7a863253@mail.gmail.com> Message-ID: Hi, Yes, the SPEECH interface isn't supported on trunk. The easier way to add support for it would be to copy & paste the auddec plugins and modify them to use the speech API. Is also probably easy to add in DDOMPE branch with a couple of if cases (speech interface is in to-do list for this branch). Regards, Diego On Mar 10, 2010, at 8:36 AM, Idriss Ghodhbane wrote: > Hi everybody, > > After installing DMAI Gstreamer plugin on DM355, I tried to play a G711 audio file using the "TIauddec" element but i didn't find the g711dec (decoder) in codecName property. > I found in the net that G711 codec is supported by Dm355 DVEM but is not integrated in gstreamer. > Is there a solution to integrate g711 codec in gstreamer? > -- > IDRISS GHODHBANE > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source From Jon.Povey at racelogic.co.uk Wed Mar 10 20:05:02 2010 From: Jon.Povey at racelogic.co.uk (Jon Povey) Date: Thu, 11 Mar 2010 02:05:02 -0000 Subject: libmpeg4.a math.h dependency. In-Reply-To: Message-ID: <2992BF78ED49594EB72AD7F4F8642BBDF5E971@RL-SBS.racelogic.local> Deepak Shankar-ERS,HCLTech. wrote: > I tried to update the png library to the v1.4(latest from libpng). > However after updating this when I tried to rebuild the dvsdk the > libmpeg4enc.a is not linking. I did a diff and found that the math.h > related operations are removed from the latest pnglibrary(which Im > not able to reason out - separately). > > Now since the code libraries are dependent on the math.h why is it > include through the libpng shared object instead of directly from > libmpeg4.a > > Is there a way the libmpeg4.a could be locally rebuilt? > ********** > /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/../target/usr/lib /libpng. > so: undefined reference to `pow' ************** > Rest of dump: > ************** > > /home/avalon/dvsdk_1_30_00_40/dm355_codecs_1_13_000/packages/ti/sdo/code cs/mpeg4 > enc/dm355/lib/libmp4enc.a(mp4venc_rate_cnt.o)(.text+0x30): In > function `MP4VENC_ > TI_DM350_calc_d0': > mp4venc_rate_cnt.c: undefined reference to `floor' Looks like you need to link against the math library libm, is "-lm" in your CFLAGS? If that doesn't help please paste the compiler command line which is failing (you may need to turn on verbose output with a switch, maybe V=1) -- Jon Povey jon.povey at racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network From deepaks at hcl.in Wed Mar 10 23:56:23 2010 From: deepaks at hcl.in (Deepak Shankar-ERS,HCLTech.) Date: Thu, 11 Mar 2010 11:26:23 +0530 Subject: libmpeg4.a math.h dependency. In-Reply-To: <2992BF78ED49594EB72AD7F4F8642BBDF5E971@RL-SBS.racelogic.local> References: <2992BF78ED49594EB72AD7F4F8642BBDF5E971@RL-SBS.racelogic.local> Message-ID: Jon, Thank you for the inputs - I was only thinking how to fix the libmpeg4.a. for quite some time :) I just added the -lm to LDflags of application and its working now. Thanks a lot for the response. Best Regards, Deepak Shankar V -----Original Message----- From: Jon Povey [mailto:Jon.Povey at racelogic.co.uk] Sent: Thursday, March 11, 2010 7:35 AM To: Deepak Shankar-ERS,HCLTech. Cc: davinci-linux-open-source at linux.davincidsp.com Subject: RE: libmpeg4.a math.h dependency. Deepak Shankar-ERS,HCLTech. wrote: > I tried to update the png library to the v1.4(latest from libpng). > However after updating this when I tried to rebuild the dvsdk the > libmpeg4enc.a is not linking. I did a diff and found that the math.h > related operations are removed from the latest pnglibrary(which Im > not able to reason out - separately). > > Now since the code libraries are dependent on the math.h why is it > include through the libpng shared object instead of directly from > libmpeg4.a > > Is there a way the libmpeg4.a could be locally rebuilt? > ********** > /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/../target/usr/lib /libpng. > so: undefined reference to `pow' ************** Rest of dump: > ************** > > /home/avalon/dvsdk_1_30_00_40/dm355_codecs_1_13_000/packages/ti/sdo/code cs/mpeg4 > enc/dm355/lib/libmp4enc.a(mp4venc_rate_cnt.o)(.text+0x30): In > function `MP4VENC_ > TI_DM350_calc_d0': > mp4venc_rate_cnt.c: undefined reference to `floor' Looks like you need to link against the math library libm, is "-lm" in your CFLAGS? If that doesn't help please paste the compiler command line which is failing (you may need to turn on verbose output with a switch, maybe V=1) -- Jon Povey jon.povey at racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- From Jon.Povey at racelogic.co.uk Thu Mar 11 00:15:47 2010 From: Jon.Povey at racelogic.co.uk (Jon Povey) Date: Thu, 11 Mar 2010 06:15:47 -0000 Subject: Custom pinmuxing on DM355 with git kernel In-Reply-To: Message-ID: <2992BF78ED49594EB72AD7F4F8642BBDF5E974@RL-SBS.racelogic.local> Steve Chen wrote: > On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey > wrote: >> We have 3 different boards using DM355, with different gpio / pinmux >> setups. So far, our device drivers are modules which fiddle the >> pinmux registers directly. >> At the moment I am thinking that I might want to split up >> davinci_cfg_reg into two functions so it's not hardwired to >> soc_info->pinmux_pins, and I could pass my own mux_config structs >> in. If this is of interest I can have a go at doing this and >> submitting the patch here. > > For board specific pinmux, you can put them in board-dm355-*.c. > There are some board specific pinmux setup in board-da830-evm.c. > Look for da8xx_pinmux_setup. Thanks, I see this. I have also been looking at the gpiolib support and something like that would be useful. At minimum it would be helpful to split out the davinci_cfg_reg stuff as described above so that driver modules can use the same functions. Then I may extend the mux.c interface to support debugfs for reporting, and perhaps an owner name string. The mux.c interface could maintain a bitmap of claimed mux bits and warn/deny on conflicts like the gpiolib does. I recently found the gpiolib tracking of owners and debugfs support very useful, which inspired me to look at muxing in that way. Again comments are welcome, especially "you're an idiot, do it like this instead" or "all fixed in arago", otherwise I will quietly hack away on my own and maybe submit a patch later. Cc'd KH as he seems to have been most active in mux.c recently. -- Jon Povey jon.povey at racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network From nsekhar at ti.com Thu Mar 11 01:07:00 2010 From: nsekhar at ti.com (Nori, Sekhar) Date: Thu, 11 Mar 2010 12:37:00 +0530 Subject: Custom pinmuxing on DM355 with git kernel In-Reply-To: <2992BF78ED49594EB72AD7F4F8642BBDF5E974@RL-SBS.racelogic.local> References: <2992BF78ED49594EB72AD7F4F8642BBDF5E974@RL-SBS.racelogic.local> Message-ID: On Thu, Mar 11, 2010 at 11:45:47, Jon Povey wrote: > Steve Chen wrote: > > On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey > > wrote: > > >> We have 3 different boards using DM355, with different gpio / pinmux > >> setups. So far, our device drivers are modules which fiddle the > >> pinmux registers directly. > > >> At the moment I am thinking that I might want to split up > >> davinci_cfg_reg into two functions so it's not hardwired to > >> soc_info->pinmux_pins, and I could pass my own mux_config structs > >> in. If this is of interest I can have a go at doing this and > >> submitting the patch here. > > > > For board specific pinmux, you can put them in board-dm355-*.c. > > There are some board specific pinmux setup in board-da830-evm.c. > > Look for da8xx_pinmux_setup. > > Thanks, I see this. I have also been looking at the gpiolib support and > something like that would be useful. > > At minimum it would be helpful to split out the davinci_cfg_reg stuff as > described above so that driver modules can use the same functions. Methods of handing pinmux were debated at length on this list. I think this thread captures most of it: http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg11281.html It's a long thread, but very useful read. I don't think having drivers handle pinmux directly is acceptable at all. I still think splitting davinci_cfg_reg() they way you describe may have some merit in terms of code organization, but I fail to see where it will be useful (at least in the current kernel). > I may extend the mux.c interface to support debugfs for reporting, and > perhaps an owner name string. The mux.c interface could maintain a > bitmap of claimed mux bits and warn/deny on conflicts like the gpiolib > does. Something like this was implemented (I think by Steve Chen) for MV kernel. It has not been submitted for upstream acceptance, but I do not seem to recall any major opposition to the idea (you should check the thread above). > > I recently found the gpiolib tracking of owners and debugfs support very > useful, which inspired me to look at muxing in that way. > > Again comments are welcome, especially "you're an idiot, do it like this > instead" or "all fixed in arago", otherwise I will quietly hack away on > my own and maybe submit a patch later. > > Cc'd KH as he seems to have been most active in mux.c recently. You didn't actually do it (I did now), but there should be no need to do that since he tracks this list pretty closely. Thanks, Sekhar From sudhakar.raj at ti.com Thu Mar 11 01:32:36 2010 From: sudhakar.raj at ti.com (Sudhakar Rajashekhara) Date: Thu, 11 Mar 2010 13:02:36 +0530 Subject: [PATCH] davinci: MMC: Pass number of SG segments as platform data Message-ID: <1268292756-5369-1-git-send-email-sudhakar.raj@ti.com> On some platforms like DM355, the number of EDMA parameter slots available for EDMA_SLOT_ANY usage are few. In such cases, if MMC/SD uses 16 slots for each instance of MMC controller, then the number of slots available for other modules will be very few. By passing the number of EDMA slots to be used in MMC driver from platform data, EDMA slots available for other purposes can be controlled. Signed-off-by: Sudhakar Rajashekhara --- arch/arm/mach-davinci/include/mach/mmc.h | 3 +++ drivers/mmc/host/davinci_mmc.c | 22 +++++++++++++++------- 2 files changed, 18 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-davinci/include/mach/mmc.h b/arch/arm/mach-davinci/include/mach/mmc.h index 5a85e24..384fc0e 100644 --- a/arch/arm/mach-davinci/include/mach/mmc.h +++ b/arch/arm/mach-davinci/include/mach/mmc.h @@ -22,6 +22,9 @@ struct davinci_mmc_config { /* Version of the MMC/SD controller */ u8 version; + + /* Number of sg segments */ + u32 nr_sg; }; void davinci_setup_mmc(int module, struct davinci_mmc_config *config); diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c index 3bd0ba2..19c050c 100644 --- a/drivers/mmc/host/davinci_mmc.c +++ b/drivers/mmc/host/davinci_mmc.c @@ -137,15 +137,15 @@ /* * One scatterlist dma "segment" is at most MAX_CCNT rw_threshold units, - * and we handle up to NR_SG segments. MMC_BLOCK_BOUNCE kicks in only + * and we handle up to MAX_NR_SG segments. MMC_BLOCK_BOUNCE kicks in only * for drivers with max_hw_segs == 1, making the segments bigger (64KB) - * than the page or two that's otherwise typical. NR_SG == 16 gives at - * least the same throughput boost, using EDMA transfer linkage instead - * of spending CPU time copying pages. + * than the page or two that's otherwise typical. nr_sg (passed from + * platform data) == 16 gives at least the same throughput boost, using + * EDMA transfer linkage instead of spending CPU time copying pages. */ #define MAX_CCNT ((1 << 16) - 1) -#define NR_SG 16 +#define MAX_NR_SG 16 static unsigned rw_threshold = 32; module_param(rw_threshold, uint, S_IRUGO); @@ -192,7 +192,7 @@ struct mmc_davinci_host { struct edmacc_param tx_template; struct edmacc_param rx_template; unsigned n_link; - u32 links[NR_SG - 1]; + u32 links[MAX_NR_SG - 1]; /* For PIO we walk scatterlists one segment at a time. */ unsigned int sg_len; @@ -202,6 +202,8 @@ struct mmc_davinci_host { u8 version; /* for ns in one cycle calculation */ unsigned ns_in_one_cycle; + /* Number of sg segments */ + u32 nr_sg; #ifdef CONFIG_CPU_FREQ struct notifier_block freq_transition; #endif @@ -568,6 +570,7 @@ davinci_release_dma_channels(struct mmc_davinci_host *host) static int __init davinci_acquire_dma_channels(struct mmc_davinci_host *host) { + u32 link_size; int r, i; /* Acquire master DMA write channel */ @@ -593,7 +596,8 @@ static int __init davinci_acquire_dma_channels(struct mmc_davinci_host *host) /* Allocate parameter RAM slots, which will later be bound to a * channel as needed to handle a scatterlist. */ - for (i = 0; i < ARRAY_SIZE(host->links); i++) { + link_size = min_t(unsigned, host->nr_sg, ARRAY_SIZE(host->links)); + for (i = 0; i < link_size; i++) { r = edma_alloc_slot(EDMA_CTLR(host->txdma), EDMA_SLOT_ANY); if (r < 0) { dev_dbg(mmc_dev(host->mmc), "dma PaRAM alloc --> %d\n", @@ -1202,6 +1206,10 @@ static int __init davinci_mmcsd_probe(struct platform_device *pdev) init_mmcsd_host(host); + host->nr_sg = pdata->nr_sg - 1; + if (host->nr_sg > MAX_NR_SG || host->nr_sg == 0) + host->nr_sg = MAX_NR_SG; + host->use_dma = use_dma; host->irq = irq; -- 1.5.6 From chaithrika at ti.com Thu Mar 11 02:37:56 2010 From: chaithrika at ti.com (Chaithrika U S) Date: Thu, 11 Mar 2010 14:07:56 +0530 Subject: [PATCH] TI DaVinci EMAC: Convert to dev_pm_ops Message-ID: <1268296676-12514-1-git-send-email-chaithrika@ti.com> Migrate from the legacy PM hooks to use dev_pm_ops structure. Signed-off-by: Chaithrika U S --- This patch applies to Linus' kernel tree. The fixes provided in this patch[1] are needed for EMAC driver to build. [1]http://patchwork.kernel.org/patch/84267/ drivers/net/davinci_emac.c | 27 ++++++++++++++++----------- 1 files changed, 16 insertions(+), 11 deletions(-) diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c index 2526a9b..eb67fa6 100644 --- a/drivers/net/davinci_emac.c +++ b/drivers/net/davinci_emac.c @@ -2829,31 +2829,37 @@ static int __devexit davinci_emac_remove(struct platform_device *pdev) return 0; } -static -int davinci_emac_suspend(struct platform_device *pdev, pm_message_t state) +static int davinci_emac_suspend(struct device *dev) { - struct net_device *dev = platform_get_drvdata(pdev); + struct platform_device *pdev = to_platform_device(dev); + struct net_device *ndev = platform_get_drvdata(pdev); - if (netif_running(dev)) - emac_dev_stop(dev); + if (netif_running(ndev)) + emac_dev_stop(ndev); clk_disable(emac_clk); return 0; } -static int davinci_emac_resume(struct platform_device *pdev) +static int davinci_emac_resume(struct device *dev) { - struct net_device *dev = platform_get_drvdata(pdev); + struct platform_device *pdev = to_platform_device(dev); + struct net_device *ndev = platform_get_drvdata(pdev); clk_enable(emac_clk); - if (netif_running(dev)) - emac_dev_open(dev); + if (netif_running(ndev)) + emac_dev_open(ndev); return 0; } +static const struct dev_pm_ops davinci_emac_pm_ops = { + .suspend = davinci_emac_suspend, + .resume = davinci_emac_resume, +}; + /** * davinci_emac_driver: EMAC platform driver structure */ @@ -2861,11 +2867,10 @@ static struct platform_driver davinci_emac_driver = { .driver = { .name = "davinci_emac", .owner = THIS_MODULE, + .pm = &davinci_emac_pm_ops, }, .probe = davinci_emac_probe, .remove = __devexit_p(davinci_emac_remove), - .suspend = davinci_emac_suspend, - .resume = davinci_emac_resume, }; /** -- 1.5.6 From srk at ti.com Thu Mar 11 08:24:49 2010 From: srk at ti.com (Sriramakrishnan) Date: Thu, 11 Mar 2010 19:54:49 +0530 Subject: [PATCH 0/2] TI DaVinci EMAC: Add support for handling PHY Clock. Message-ID: <1268317491-3822-1-git-send-email-srk@ti.com> In addition to the EMAC module clock, the EMAC PHY clock needs to be managed separately. Until now, on most DaVinci platforms, the PHY clock is always enabled. On AM35x platform where the same EMAC module is used, the PHY clock needs to be managed explicitly. This patch series add support for handling PHY clock in the EMAC driver. Clock definitions for platforms using the EMAC module have be modified accordingly. This patch series is generated against tip of Linus tree and depends on the following patches submitted earlier [1].http://patchwork.ozlabs.org/patch/47156/ [2].http://patchwork.ozlabs.org/patch/47303/ Sekhar Nori (1): davinci: introduce EMAC PHY clock usage Sriramakrishnan (1): TI DaVinci EMAC: Add EMAC PHY clock handling. arch/arm/mach-davinci/board-da830-evm.c | 19 +++++++++++++++++++ arch/arm/mach-davinci/board-da850-evm.c | 21 +++++++++++++++++++++ arch/arm/mach-davinci/board-dm365-evm.c | 18 ++++++++++++++++++ arch/arm/mach-davinci/board-dm644x-evm.c | 18 ++++++++++++++++++ arch/arm/mach-davinci/board-dm646x-evm.c | 15 +++++++++++++++ arch/arm/mach-davinci/board-neuros-osd2.c | 19 +++++++++++++++++++ arch/arm/mach-davinci/board-sffsdr.c | 19 +++++++++++++++++++ arch/arm/mach-davinci/da830.c | 2 +- arch/arm/mach-davinci/da850.c | 2 +- arch/arm/mach-davinci/dm365.c | 2 +- arch/arm/mach-davinci/dm644x.c | 2 +- arch/arm/mach-davinci/dm646x.c | 2 +- drivers/net/davinci_emac.c | 22 ++++++++++++++++++++-- 13 files changed, 154 insertions(+), 7 deletions(-) From srk at ti.com Thu Mar 11 08:24:51 2010 From: srk at ti.com (Sriramakrishnan) Date: Thu, 11 Mar 2010 19:54:51 +0530 Subject: [PATCH 2/2] davinci: introduce EMAC PHY clock usage In-Reply-To: <1268317491-3822-2-git-send-email-srk@ti.com> References: <1268317491-3822-1-git-send-email-srk@ti.com> <1268317491-3822-2-git-send-email-srk@ti.com> Message-ID: <1268317491-3822-3-git-send-email-srk@ti.com> From: Sekhar Nori The patch "TI DaVinci EMAC: Add EMAC PHY clock handling" adds support for enabling and disabling the EMAC PHY clock. The PHY clock on all DaVinci boards is derived from a fixed on board clock. This patch adds the PHY clock definition to the clock tree for all the DaVinci boards using EMAC. Also, the existing input to EMAC module is differentiated from the PHY clock using the clock name "emac_clk". Without this patch ethernet fails to initialize since it cannot get the PHY clock and EMAC clock. Tested on EVM boards for DM365, DM6467, DM644x, DA830 and DA850. Signed-off-by: Sekhar Nori --- Though i have made changes for Neuros OSD2 and SFFSDR boards, i do not have the hardware to test. Appreciate if folks having this hardware ack the patch. arch/arm/mach-davinci/board-da830-evm.c | 19 +++++++++++++++++++ arch/arm/mach-davinci/board-da850-evm.c | 21 +++++++++++++++++++++ arch/arm/mach-davinci/board-dm365-evm.c | 18 ++++++++++++++++++ arch/arm/mach-davinci/board-dm644x-evm.c | 18 ++++++++++++++++++ arch/arm/mach-davinci/board-dm646x-evm.c | 15 +++++++++++++++ arch/arm/mach-davinci/board-neuros-osd2.c | 19 +++++++++++++++++++ arch/arm/mach-davinci/board-sffsdr.c | 19 +++++++++++++++++++ arch/arm/mach-davinci/da830.c | 2 +- arch/arm/mach-davinci/da850.c | 2 +- arch/arm/mach-davinci/dm365.c | 2 +- arch/arm/mach-davinci/dm644x.c | 2 +- arch/arm/mach-davinci/dm646x.c | 2 +- 12 files changed, 134 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c index dc19870..54e8567 100644 --- a/arch/arm/mach-davinci/board-da830-evm.c +++ b/arch/arm/mach-davinci/board-da830-evm.c @@ -20,9 +20,11 @@ #include #include #include +#include #include #include +#include #include #include @@ -30,6 +32,8 @@ #include #include +#include "clock.h" + #define DA830_EVM_PHY_MASK 0x0 #define DA830_EVM_MDIO_FREQUENCY 2200000 /* PHY bus frequency */ @@ -557,9 +561,24 @@ static __init void da830_evm_irq_init(void) soc_info->intc_irq_prios); } +#define EMAC_PHY_CLK_RATE 50000000 + +static struct clk emac_phy = { + .name = "emac_phy", + .rate = EMAC_PHY_CLK_RATE, +}; + +static struct clk_lookup emac_phy_clks[] = { + CLK("davinci_emac.1", "phy_clk", &emac_phy), + CLK(NULL, NULL, NULL), +}; + static void __init da830_evm_map_io(void) { da830_init(); + + clkdev_add(emac_phy_clks); + clk_register(&emac_phy); } MACHINE_START(DAVINCI_DA830_EVM, "DaVinci DA830/OMAP-L137 EVM") diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index 411284d..c43ae45 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include @@ -32,6 +33,9 @@ #include #include #include +#include + +#include "clock.h" #define DA850_EVM_PHY_MASK 0x1 #define DA850_EVM_MDIO_FREQUENCY 2200000 /* PHY bus frequency */ @@ -551,6 +555,18 @@ static const short da850_evm_lcdc_pins[] = { -1 }; +#define EMAC_MII_PHY_CLK_RATE 25000000 +#define EMAC_RMII_PHY_CLK_RATE 50000000 + +static struct clk emac_phy = { + .name = "emac_phy", +}; + +static struct clk_lookup emac_phy_clks[] = { + CLK("davinci_emac.1", "phy_clk", &emac_phy), + CLK(NULL, NULL, NULL), +}; + static int __init da850_evm_config_emac(void) { void __iomem *cfg_chip3_base; @@ -571,17 +587,22 @@ static int __init da850_evm_config_emac(void) ret = da8xx_pinmux_setup(da850_rmii_pins); pr_info("EMAC: RMII PHY configured, MII PHY will not be" " functional\n"); + emac_phy.rate = EMAC_RMII_PHY_CLK_RATE; } else { val &= ~BIT(8); ret = da8xx_pinmux_setup(da850_cpgmac_pins); pr_info("EMAC: MII PHY configured, RMII PHY will not be" " functional\n"); + emac_phy.rate = EMAC_MII_PHY_CLK_RATE; } if (ret) pr_warning("da850_evm_init: cpgmac/rmii mux setup failed: %d\n", ret); + clkdev_add(emac_phy_clks); + clk_register(&emac_phy); + /* configure the CFGCHIP3 register for RMII or MII */ __raw_writel(val, cfg_chip3_base); diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c index d15bece..c36e034 100644 --- a/arch/arm/mach-davinci/board-dm365-evm.c +++ b/arch/arm/mach-davinci/board-dm365-evm.c @@ -38,9 +38,12 @@ #include #include #include +#include #include +#include "clock.h" + static inline int have_imager(void) { /* REVISIT when it's supported, trigger via Kconfig */ @@ -566,11 +569,26 @@ static struct davinci_uart_config uart_config __initdata = { .enabled_uarts = (1 << 0), }; +#define EMAC_PHY_CLK_RATE 25000000 + +static struct clk emac_phy = { + .name = "emac_phy", + .rate = EMAC_PHY_CLK_RATE, +}; + +static struct clk_lookup emac_phy_clks[] = { + CLK("davinci_emac.1", "phy_clk", &emac_phy), + CLK(NULL, NULL, NULL), +}; + static void __init dm365_evm_map_io(void) { /* setup input configuration for VPFE input devices */ dm365_set_vpfe_config(&vpfe_cfg); dm365_init(); + + clkdev_add(emac_phy_clks); + clk_register(&emac_phy); } static struct spi_eeprom at25640 = { diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 976e11b..ba90181 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -37,6 +37,9 @@ #include #include #include +#include + +#include "clock.h" #define DM644X_EVM_PHY_MASK (0x2) #define DM644X_EVM_MDIO_FREQUENCY (2200000) /* PHY bus frequency */ @@ -649,12 +652,27 @@ static struct davinci_uart_config uart_config __initdata = { .enabled_uarts = (1 << 0), }; +#define EMAC_PHY_CLK_RATE 25000000 + +static struct clk emac_phy = { + .name = "emac_phy", + .rate = EMAC_PHY_CLK_RATE, +}; + +static struct clk_lookup emac_phy_clks[] = { + CLK("davinci_emac.1", "phy_clk", &emac_phy), + CLK(NULL, NULL, NULL), +}; + static void __init davinci_evm_map_io(void) { /* setup input configuration for VPFE input devices */ dm644x_set_vpfe_config(&vpfe_cfg); dm644x_init(); + + clkdev_add(emac_phy_clks); + clk_register(&emac_phy); } static int davinci_phy_fixup(struct phy_device *phydev) diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c index 5ba3cb2..6241893 100644 --- a/arch/arm/mach-davinci/board-dm646x-evm.c +++ b/arch/arm/mach-davinci/board-dm646x-evm.c @@ -711,10 +711,25 @@ static void __init cdce_clk_init(void) } } +#define EMAC_PHY_CLK_RATE 25000000 + +static struct clk emac_phy = { + .name = "emac_phy", + .rate = EMAC_PHY_CLK_RATE, +}; + +static struct clk_lookup emac_phy_clks[] = { + CLK("davinci_emac.1", "phy_clk", &emac_phy), + CLK(NULL, NULL, NULL), +}; + static void __init davinci_map_io(void) { dm646x_init(); cdce_clk_init(); + + clkdev_add(emac_phy_clks); + clk_register(&emac_phy); } static struct davinci_uart_config uart_config __initdata = { diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c index bd9ca07..075962c 100644 --- a/arch/arm/mach-davinci/board-neuros-osd2.c +++ b/arch/arm/mach-davinci/board-neuros-osd2.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include @@ -37,6 +38,9 @@ #include #include #include +#include + +#include "clock.h" #define NEUROS_OSD2_PHY_MASK 0x2 #define NEUROS_OSD2_MDIO_FREQUENCY 2200000 /* PHY bus frequency */ @@ -188,9 +192,24 @@ static struct davinci_uart_config uart_config __initdata = { .enabled_uarts = (1 << 0), }; +#define EMAC_PHY_CLK_RATE 25000000 + +static struct clk emac_phy = { + .name = "emac_phy", + .rate = EMAC_PHY_CLK_RATE, +}; + +static struct clk_lookup emac_phy_clks[] = { + CLK("davinci_emac.1", "phy_clk", &emac_phy), + CLK(NULL, NULL, NULL), +}; + static void __init davinci_ntosd2_map_io(void) { dm644x_init(); + + clkdev_add(emac_phy_clks); + clk_register(&emac_phy); } /* diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c index 08d373b..7faa6cf 100644 --- a/arch/arm/mach-davinci/board-sffsdr.c +++ b/arch/arm/mach-davinci/board-sffsdr.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include @@ -41,6 +42,9 @@ #include #include #include +#include + +#include "clock.h" #define SFFSDR_PHY_MASK (0x2) #define SFFSDR_MDIO_FREQUENCY (2200000) /* PHY bus frequency */ @@ -133,9 +137,24 @@ static struct davinci_uart_config uart_config __initdata = { .enabled_uarts = (1 << 0), }; +#define EMAC_PHY_CLK_RATE 25000000 + +static struct clk emac_phy = { + .name = "emac_phy", + .rate = EMAC_PHY_CLK_RATE, +}; + +static struct clk_lookup emac_phy_clks[] = { + CLK("davinci_emac.1", "phy_clk", &emac_phy), + CLK(NULL, NULL, NULL), +}; + static void __init davinci_sffsdr_map_io(void) { dm644x_init(); + + clkdev_add(emac_phy_clks); + clk_register(&emac_phy); } static __init void davinci_sffsdr_init(void) diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c index 122e61a..31903e2 100644 --- a/arch/arm/mach-davinci/da830.c +++ b/arch/arm/mach-davinci/da830.c @@ -414,7 +414,7 @@ static struct clk_lookup da830_clks[] = { CLK(NULL, "aemif", &aemif_clk), CLK(NULL, "aintc", &aintc_clk), CLK(NULL, "secu_mgr", &secu_mgr_clk), - CLK("davinci_emac.1", NULL, &emac_clk), + CLK("davinci_emac.1", "emac_clk", &emac_clk), CLK(NULL, "gpio", &gpio_clk), CLK("i2c_davinci.2", NULL, &i2c1_clk), CLK(NULL, "usb11", &usb11_clk), diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c index d0fd756..4fd92d9 100644 --- a/arch/arm/mach-davinci/da850.c +++ b/arch/arm/mach-davinci/da850.c @@ -371,7 +371,7 @@ static struct clk_lookup da850_clks[] = { CLK(NULL, "emif3", &emif3_clk), CLK(NULL, "arm", &arm_clk), CLK(NULL, "rmii", &rmii_clk), - CLK("davinci_emac.1", NULL, &emac_clk), + CLK("davinci_emac.1", "emac_clk", &emac_clk), CLK("davinci-mcasp.0", NULL, &mcasp_clk), CLK("da8xx_lcdc.0", NULL, &lcdc_clk), CLK("davinci_mmc.0", NULL, &mmcsd_clk), diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index 27772e1..71f773c 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -457,7 +457,7 @@ static struct clk_lookup dm365_clks[] = { CLK("watchdog", NULL, &timer2_clk), CLK(NULL, "timer3", &timer3_clk), CLK(NULL, "usb", &usb_clk), - CLK("davinci_emac.1", NULL, &emac_clk), + CLK("davinci_emac.1", "emac_clk", &emac_clk), CLK("davinci_voicecodec", NULL, &voicecodec_clk), CLK("davinci-asp.0", NULL, &asp0_clk), CLK(NULL, "rto", &rto_clk), diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 2f2ae8b..70948d4 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -299,7 +299,7 @@ struct clk_lookup dm644x_clks[] = { CLK(NULL, "uart0", &uart0_clk), CLK(NULL, "uart1", &uart1_clk), CLK(NULL, "uart2", &uart2_clk), - CLK("davinci_emac.1", NULL, &emac_clk), + CLK("davinci_emac.1", "emac_clk", &emac_clk), CLK("i2c_davinci.1", NULL, &i2c_clk), CLK("palm_bk3710", NULL, &ide_clk), CLK("davinci-asp", NULL, &asp_clk), diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index 893baf4..464cebc 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -342,7 +342,7 @@ struct clk_lookup dm646x_clks[] = { CLK("davinci-mcasp.0", NULL, &mcasp0_clk), CLK("davinci-mcasp.1", NULL, &mcasp1_clk), CLK(NULL, "aemif", &aemif_clk), - CLK("davinci_emac.1", NULL, &emac_clk), + CLK("davinci_emac.1", "emac_clk", &emac_clk), CLK(NULL, "pwm0", &pwm0_clk), CLK(NULL, "pwm1", &pwm1_clk), CLK(NULL, "timer0", &timer0_clk), -- 1.6.2.4 From srk at ti.com Thu Mar 11 08:24:50 2010 From: srk at ti.com (Sriramakrishnan) Date: Thu, 11 Mar 2010 19:54:50 +0530 Subject: [PATCH 1/2] TI DaVinci EMAC: Add EMAC PHY clock handling. In-Reply-To: <1268317491-3822-1-git-send-email-srk@ti.com> References: <1268317491-3822-1-git-send-email-srk@ti.com> Message-ID: <1268317491-3822-2-git-send-email-srk@ti.com> Source for the EMAC PHY clock can be different from the module clock and driver needs to request/enable the EMAC phy clock explicitly. This was not required earlier as on most Davinci platforms the phy clock is always on . On AM35x platform the phy clock needs to be managed explicitly , hence adding clock management for phy clock. Signed-off-by: Sriramakrishnan --- drivers/net/davinci_emac.c | 22 ++++++++++++++++++++-- 1 files changed, 20 insertions(+), 2 deletions(-) diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c index 8a42dbe..d9ae6ee 100644 --- a/drivers/net/davinci_emac.c +++ b/drivers/net/davinci_emac.c @@ -491,6 +491,7 @@ struct emac_priv { /* clock frequency for EMAC */ static struct clk *emac_clk; +static struct clk *emac_phy_clk; static unsigned long emac_bus_frequency; static unsigned long mdio_max_freq; @@ -2637,18 +2638,28 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev) struct emac_platform_data *pdata; struct device *emac_dev; - /* obtain emac clock from kernel */ - emac_clk = clk_get(&pdev->dev, NULL); + /* obtain emac module clock from kernel */ + emac_clk = clk_get(&pdev->dev, "emac_clk"); if (IS_ERR(emac_clk)) { printk(KERN_ERR "DaVinci EMAC: Failed to get EMAC clock\n"); return -EBUSY; } + + /* obtain emac phy clock from kernel */ + emac_phy_clk = clk_get(&pdev->dev, "phy_clk"); + if (IS_ERR(emac_phy_clk)) { + printk(KERN_ERR "DaVinci EMAC: Failed to get PHY clock\n"); + clk_put(emac_clk); + return -EBUSY; + } + emac_bus_frequency = clk_get_rate(emac_clk); /* TODO: Probe PHY here if possible */ ndev = alloc_etherdev(sizeof(struct emac_priv)); if (!ndev) { printk(KERN_ERR "DaVinci EMAC: Error allocating net_device\n"); + clk_put(emac_phy_clk); clk_put(emac_clk); return -ENOMEM; } @@ -2734,6 +2745,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev) netif_napi_add(ndev, &priv->napi, emac_poll, EMAC_POLL_WEIGHT); clk_enable(emac_clk); + clk_enable(emac_phy_clk); /* register the network device */ SET_NETDEV_DEV(ndev, &pdev->dev); @@ -2783,6 +2795,7 @@ mdiobus_quit: netdev_reg_err: mdio_alloc_err: + clk_disable(emac_phy_clk); clk_disable(emac_clk); no_irq_res: res = platform_get_resource(pdev, IORESOURCE_MEM, 0); @@ -2790,6 +2803,7 @@ no_irq_res: iounmap(priv->remap_addr); probe_quit: + clk_put(emac_phy_clk); clk_put(emac_clk); free_netdev(ndev); return rc; @@ -2821,7 +2835,9 @@ static int __devexit davinci_emac_remove(struct platform_device *pdev) free_netdev(ndev); iounmap(priv->remap_addr); + clk_disable(emac_phy_clk); clk_disable(emac_clk); + clk_put(emac_phy_clk); clk_put(emac_clk); return 0; @@ -2835,6 +2851,7 @@ static int davinci_emac_suspend(struct device *dev) if (netif_running(ndev)) emac_dev_stop(ndev); + clk_disable(emac_phy_clk); clk_disable(emac_clk); return 0; @@ -2846,6 +2863,7 @@ static int davinci_emac_resume(struct device *dev) struct net_device *ndev = platform_get_drvdata(pdev); clk_enable(emac_clk); + clk_enable(emac_phy_clk); if (netif_running(ndev)) emac_dev_open(ndev); -- 1.6.2.4 From srk at ti.com Thu Mar 11 09:13:41 2010 From: srk at ti.com (Sriramakrishnan) Date: Thu, 11 Mar 2010 20:43:41 +0530 Subject: [PATCH 3/4] OMAP3 : clock data: Update name string for EMAC clocks. In-Reply-To: <1268320422-32656-3-git-send-email-srk@ti.com> References: <1268320422-32656-1-git-send-email-srk@ti.com> <1268320422-32656-2-git-send-email-srk@ti.com> <1268320422-32656-3-git-send-email-srk@ti.com> Message-ID: <1268320422-32656-4-git-send-email-srk@ti.com> The emac driver uses generic name for the module and phy clocks. Updated the omap3xxx_clks table to match the names used by the Davinci emac driver. Signed-off-by: Sriramakrishnan --- arch/arm/mach-omap2/clock3xxx_data.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c index d5153b6..989da2e 100644 --- a/arch/arm/mach-omap2/clock3xxx_data.c +++ b/arch/arm/mach-omap2/clock3xxx_data.c @@ -3472,8 +3472,8 @@ static struct omap_clk omap3xxx_clks[] = { CLK(NULL, "ipss_ick", &ipss_ick, CK_AM35XX), CLK(NULL, "rmii_ck", &rmii_ck, CK_AM35XX), CLK(NULL, "pclk_ck", &pclk_ck, CK_AM35XX), - CLK("davinci_emac", "ick", &emac_ick, CK_AM35XX), - CLK("davinci_emac", "fck", &emac_fck, CK_AM35XX), + CLK("davinci_emac", "emac_clk", &emac_ick, CK_AM35XX), + CLK("davinci_emac", "phy_clk", &emac_fck, CK_AM35XX), CLK("vpfe-capture", "master", &vpfe_ick, CK_AM35XX), CLK("vpfe-capture", "slave", &vpfe_fck, CK_AM35XX), CLK("musb_hdrc", "ick", &hsotgusb_ick_am35xx, CK_AM35XX), -- 1.6.2.4 From srk at ti.com Thu Mar 11 09:13:40 2010 From: srk at ti.com (Sriramakrishnan) Date: Thu, 11 Mar 2010 20:43:40 +0530 Subject: [PATCH 2/4] AM35xx : Platform specific hookup for EMAC module In-Reply-To: <1268320422-32656-2-git-send-email-srk@ti.com> References: <1268320422-32656-1-git-send-email-srk@ti.com> <1268320422-32656-2-git-send-email-srk@ti.com> Message-ID: <1268320422-32656-3-git-send-email-srk@ti.com> Modified AM35xx EVM init sequence to handle EMAC initialization. Signed-off-by: Sriramakrishnan --- arch/arm/mach-omap2/board-am3517evm.c | 98 +++++++++++++++++++++++++++++++++ 1 files changed, 98 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c index 6ae8805..a454995 100644 --- a/arch/arm/mach-omap2/board-am3517evm.c +++ b/arch/arm/mach-omap2/board-am3517evm.c @@ -21,6 +21,7 @@ #include #include #include +#include #include #include @@ -30,11 +31,106 @@ #include #include +#include #include #include #include "mux.h" +#define AM35XX_EVM_PHY_MASK (0xF) +#define AM35XX_EVM_MDIO_FREQUENCY (1000000) + +static struct emac_platform_data am3517_evm_emac_pdata = { + .phy_mask = AM35XX_EVM_PHY_MASK, + .mdio_max_freq = AM35XX_EVM_MDIO_FREQUENCY, + .rmii_en = 1, +}; + +static struct resource am3517_emac_resources[] = { + { + .start = AM35XX_IPSS_EMAC_BASE, + .end = AM35XX_IPSS_EMAC_BASE + 0x3FFFF, + .flags = IORESOURCE_MEM, + }, + { + .start = INT_35XX_EMAC_C0_RXTHRESH_IRQ, + .end = INT_35XX_EMAC_C0_RXTHRESH_IRQ, + .flags = IORESOURCE_IRQ, + }, + { + .start = INT_35XX_EMAC_C0_RX_PULSE_IRQ, + .end = INT_35XX_EMAC_C0_RX_PULSE_IRQ, + .flags = IORESOURCE_IRQ, + }, + { + .start = INT_35XX_EMAC_C0_TX_PULSE_IRQ, + .end = INT_35XX_EMAC_C0_TX_PULSE_IRQ, + .flags = IORESOURCE_IRQ, + }, + { + .start = INT_35XX_EMAC_C0_MISC_PULSE_IRQ, + .end = INT_35XX_EMAC_C0_MISC_PULSE_IRQ, + .flags = IORESOURCE_IRQ, + }, +}; + +static struct platform_device am3517_emac_device = { + .name = "davinci_emac", + .id = -1, + .num_resources = ARRAY_SIZE(am3517_emac_resources), + .resource = am3517_emac_resources, +}; + +static void am3517_enable_ethernet_int(void) +{ + u32 regval; + + regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); + regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR | + AM35XX_CPGMAC_C0_TX_PULSE_CLR | + AM35XX_CPGMAC_C0_MISC_PULSE_CLR | + AM35XX_CPGMAC_C0_RX_THRESH_CLR); + omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR); + regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); +} + +static void am3517_disable_ethernet_int(void) +{ + u32 regval; + + regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); + regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR | + AM35XX_CPGMAC_C0_TX_PULSE_CLR); + omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR); + regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); +} + +void am3517_evm_ethernet_init(struct emac_platform_data *pdata) +{ + unsigned int regval; + + pdata->ctrl_reg_offset = AM35XX_EMAC_CNTRL_OFFSET; + pdata->ctrl_mod_reg_offset = AM35XX_EMAC_CNTRL_MOD_OFFSET; + pdata->ctrl_ram_offset = AM35XX_EMAC_CNTRL_RAM_OFFSET; + pdata->mdio_reg_offset = AM35XX_EMAC_MDIO_OFFSET; + pdata->ctrl_ram_size = AM35XX_EMAC_CNTRL_RAM_SIZE; + pdata->version = EMAC_VERSION_2; + pdata->hw_ram_addr = AM35XX_EMAC_HW_RAM_ADDR; + pdata->interrupt_enable = am3517_enable_ethernet_int; + pdata->interrupt_disable = am3517_disable_ethernet_int; + am3517_emac_device.dev.platform_data = pdata; + platform_device_register(&am3517_emac_device); + + regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET); + regval = regval & (~(AM35XX_CPGMACSS_SW_RST)); + omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET); + regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET); + + return ; +} + + + #define LCD_PANEL_PWR 176 #define LCD_PANEL_BKLIGHT_PWR 182 #define LCD_PANEL_PWM 181 @@ -313,6 +409,8 @@ static void __init am3517_evm_init(void) i2c_register_board_info(1, am3517evm_i2c_boardinfo, ARRAY_SIZE(am3517evm_i2c_boardinfo)); + /*Ethernet*/ + am3517_evm_ethernet_init(&am3517_evm_emac_pdata); } static void __init am3517_evm_map_io(void) -- 1.6.2.4 From srk at ti.com Thu Mar 11 09:13:42 2010 From: srk at ti.com (Sriramakrishnan) Date: Thu, 11 Mar 2010 20:43:42 +0530 Subject: [PATCH 4/4] AM3517 defconfig update : enable EMAC support In-Reply-To: <1268320422-32656-4-git-send-email-srk@ti.com> References: <1268320422-32656-1-git-send-email-srk@ti.com> <1268320422-32656-2-git-send-email-srk@ti.com> <1268320422-32656-3-git-send-email-srk@ti.com> <1268320422-32656-4-git-send-email-srk@ti.com> Message-ID: <1268320422-32656-5-git-send-email-srk@ti.com> Update the default configuration for AM3517EVM to enable support for EMAC peripheral. Signed-off-by: Sriramakrishnan --- arch/arm/configs/am3517_evm_defconfig | 70 ++++++++++++++++++++++++++++++++- 1 files changed, 69 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/am3517_evm_defconfig b/arch/arm/configs/am3517_evm_defconfig index 66a10b5..8d79b20 100644 --- a/arch/arm/configs/am3517_evm_defconfig +++ b/arch/arm/configs/am3517_evm_defconfig @@ -517,7 +517,75 @@ CONFIG_SCSI_LOWLEVEL=y # CONFIG_SCSI_OSD_INITIATOR is not set # CONFIG_ATA is not set # CONFIG_MD is not set -# CONFIG_NETDEVICES is not set +CONFIG_NETDEVICES=y +# CONFIG_DUMMY is not set +# CONFIG_BONDING is not set +# CONFIG_MACVLAN is not set +# CONFIG_EQUALIZER is not set +# CONFIG_TUN is not set +# CONFIG_VETH is not set +CONFIG_PHYLIB=y + +# +# MII PHY device drivers +# +# CONFIG_MARVELL_PHY is not set +# CONFIG_DAVICOM_PHY is not set +# CONFIG_QSEMI_PHY is not set +# CONFIG_LXT_PHY is not set +# CONFIG_CICADA_PHY is not set +# CONFIG_VITESSE_PHY is not set +# CONFIG_SMSC_PHY is not set +# CONFIG_BROADCOM_PHY is not set +# CONFIG_ICPLUS_PHY is not set +# CONFIG_REALTEK_PHY is not set +# CONFIG_NATIONAL_PHY is not set +# CONFIG_STE10XP is not set +# CONFIG_LSI_ET1011C_PHY is not set +# CONFIG_FIXED_PHY is not set +# CONFIG_MDIO_BITBANG is not set +CONFIG_NET_ETHERNET=y +# CONFIG_MII is not set +# CONFIG_AX88796 is not set +# CONFIG_SMC91X is not set +CONFIG_TI_DAVINCI_EMAC=y +# CONFIG_DM9000 is not set +# CONFIG_ETHOC is not set +# CONFIG_SMC911X is not set +# CONFIG_SMSC911X is not set +# CONFIG_DNET is not set +# CONFIG_IBM_NEW_EMAC_ZMII is not set +# CONFIG_IBM_NEW_EMAC_RGMII is not set +# CONFIG_IBM_NEW_EMAC_TAH is not set +# CONFIG_IBM_NEW_EMAC_EMAC4 is not set +# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set +# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set +# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set +# CONFIG_B44 is not set +# CONFIG_KS8842 is not set +# CONFIG_KS8851_MLL is not set +# CONFIG_NETDEV_1000 is not set +# CONFIG_NETDEV_10000 is not set +# CONFIG_WLAN is not set + +# +# Enable WiMAX (Networking options) to see the WiMAX drivers +# + +# +# USB Network Adapters +# +# CONFIG_USB_CATC is not set +# CONFIG_USB_KAWETH is not set +# CONFIG_USB_PEGASUS is not set +# CONFIG_USB_RTL8150 is not set +# CONFIG_USB_USBNET is not set +# CONFIG_WAN is not set +# CONFIG_PPP is not set +# CONFIG_SLIP is not set +# CONFIG_NETCONSOLE is not set +# CONFIG_NETPOLL is not set +# CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_ISDN is not set # CONFIG_PHONE is not set -- 1.6.2.4 From srk at ti.com Thu Mar 11 09:13:39 2010 From: srk at ti.com (Sriramakrishnan) Date: Thu, 11 Mar 2010 20:43:39 +0530 Subject: [PATCH 1/4] AM35xx EMAC : define submodule offsets. In-Reply-To: <1268320422-32656-1-git-send-email-srk@ti.com> References: <1268320422-32656-1-git-send-email-srk@ti.com> Message-ID: <1268320422-32656-2-git-send-email-srk@ti.com> Define offsets for EMAC sub modules. Signed-off-by: Sriramakrishnan --- arch/arm/mach-omap2/include/mach/am35xx.h | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/am35xx.h b/arch/arm/mach-omap2/include/mach/am35xx.h index a705f94..472867e 100644 --- a/arch/arm/mach-omap2/include/mach/am35xx.h +++ b/arch/arm/mach-omap2/include/mach/am35xx.h @@ -23,4 +23,13 @@ #define AM35XX_IPSS_HECC_BASE 0x5C050000 #define AM35XX_IPSS_VPFE_BASE 0x5C060000 -#endif /* __ASM_ARCH_AM35XX_H */ +#define AM35XX_EMAC_CNTRL_OFFSET (0x10000) +#define AM35XX_EMAC_CNTRL_MOD_OFFSET (0x0) +#define AM35XX_EMAC_CNTRL_RAM_OFFSET (0x20000) +#define AM35XX_EMAC_MDIO_OFFSET (0x30000) +#define AM35XX_EMAC_CNTRL_RAM_SIZE (0x2000) +#define AM35XX_EMAC_RAM_ADDR (AM3517_EMAC_BASE + \ + AM3517_EMAC_CNTRL_RAM_OFFSET) +#define AM35XX_EMAC_HW_RAM_ADDR (0x01E20000) + +#endif /* __ASM_ARCH_AM35XX_H */ -- 1.6.2.4 From srk at ti.com Thu Mar 11 09:13:38 2010 From: srk at ti.com (Sriramakrishnan) Date: Thu, 11 Mar 2010 20:43:38 +0530 Subject: [PATCH 0/4] AM35xx : Add support for EMAC Peripheral Message-ID: <1268320422-32656-1-git-send-email-srk@ti.com> This patch series adds support for EMAC peripheral on AM35xx platform. The EMAC peripheral is borrowed from the DaVinci platform and hence the same driver(davinci_emac) is used. This patch series has been generated against tip of linux-omap and depends on the following patches submitted to netdev/linux-davinci list. [1].http://patchwork.ozlabs.org/patch/47331/ [2].http://patchwork.ozlabs.org/patch/47332/ Sriramakrishnan (4): AM35xx EMAC : define submodule offsets. AM35xx : Platform specific hookup for EMAC module OMAP3 : clock data: Update name string for EMAC clocks. AM3517 defconfig update : enable EMAC support arch/arm/configs/am3517_evm_defconfig | 70 ++++++++++++++++++++- arch/arm/mach-omap2/board-am3517evm.c | 98 +++++++++++++++++++++++++++++ arch/arm/mach-omap2/clock3xxx_data.c | 4 +- arch/arm/mach-omap2/include/mach/am35xx.h | 11 +++- 4 files changed, 179 insertions(+), 4 deletions(-) From miguel.aguilar at ridgerun.com Thu Mar 11 09:32:21 2010 From: miguel.aguilar at ridgerun.com (miguel.aguilar at ridgerun.com) Date: Thu, 11 Mar 2010 09:32:21 -0600 Subject: [PATCH v2 1/5] MFD: DaVinci Voice Codec Message-ID: <1268321541-18922-1-git-send-email-miguel.aguilar@ridgerun.com> From: Miguel Aguilar This is the MFD driver for the DaVinci Voice codec, it has two clients: * Voice codec interface * Voice codec CQ93VC Signed-off-by: Miguel Aguilar --- drivers/mfd/Kconfig | 4 + drivers/mfd/Makefile | 1 + drivers/mfd/davinci_voicecodec.c | 189 ++++++++++++++++++++++++++++++++ include/linux/mfd/davinci_voicecodec.h | 126 +++++++++++++++++++++ 4 files changed, 320 insertions(+), 0 deletions(-) create mode 100644 drivers/mfd/davinci_voicecodec.c create mode 100644 include/linux/mfd/davinci_voicecodec.h diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 8782978..6e93c0b 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -43,6 +43,10 @@ config MFD_SH_MOBILE_SDHI This driver supports the SDHI hardware block found in many SuperH Mobile SoCs. +config MFD_DAVINCI_VOICECODEC + tristate + select MFD_CORE + config MFD_DM355EVM_MSP bool "DaVinci DM355 EVM microcontroller" depends on I2C && MACH_DAVINCI_DM355_EVM diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index ca2f2c4..f5c617f 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -9,6 +9,7 @@ obj-$(CONFIG_MFD_SH_MOBILE_SDHI) += sh_mobile_sdhi.o obj-$(CONFIG_HTC_EGPIO) += htc-egpio.o obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o +obj-$(CONFIG_MFD_DAVINCI_VOICECODEC) += davinci_voicecodec.o obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o obj-$(CONFIG_MFD_T7L66XB) += t7l66xb.o diff --git a/drivers/mfd/davinci_voicecodec.c b/drivers/mfd/davinci_voicecodec.c new file mode 100644 index 0000000..9886aa8 --- /dev/null +++ b/drivers/mfd/davinci_voicecodec.c @@ -0,0 +1,189 @@ +/* + * DaVinci Voice Codec Core Interface for TI platforms + * + * Copyright (C) 2010 Texas Instruments, Inc + * + * Author: Miguel Aguilar + * + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include +#include +#include +#include +#include +#include + +#include + +#include + +u32 davinci_vc_read(struct davinci_vc *davinci_vc, int reg) +{ + return __raw_readl(davinci_vc->base + reg); +} + +void davinci_vc_write(struct davinci_vc *davinci_vc, + int reg, u32 val) +{ + __raw_writel(val, davinci_vc->base + reg); +} + +static int __init davinci_vc_probe(struct platform_device *pdev) +{ + struct davinci_vc *davinci_vc; + struct resource *res, *mem; + struct mfd_cell *cell = NULL; + int ret; + + davinci_vc = kzalloc(sizeof(struct davinci_vc), GFP_KERNEL); + if (!davinci_vc) { + dev_dbg(&pdev->dev, + "could not allocate memory for private data\n"); + return -ENOMEM; + } + + davinci_vc->clk = clk_get(&pdev->dev, NULL); + if (IS_ERR(davinci_vc->clk)) { + dev_dbg(&pdev->dev, + "could not get the clock for voice codec\n"); + ret = -ENODEV; + goto fail1; + } + clk_enable(davinci_vc->clk); + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (!res) { + dev_err(&pdev->dev, "no mem resource\n"); + ret = -ENODEV; + goto fail2; + } + + davinci_vc->pbase = res->start; + davinci_vc->base_size = resource_size(res); + + mem = request_mem_region(davinci_vc->pbase, davinci_vc->base_size, + pdev->name); + if (!mem) { + dev_err(&pdev->dev, "VCIF region already claimed\n"); + ret = -EBUSY; + goto fail2; + } + + davinci_vc->base = ioremap(davinci_vc->pbase, davinci_vc->base_size); + if (!davinci_vc->base) { + dev_err(&pdev->dev, "can't ioremap mem resource.\n"); + ret = -ENOMEM; + goto fail3; + } + + res = platform_get_resource(pdev, IORESOURCE_DMA, 0); + if (!res) { + dev_err(&pdev->dev, "no DMA resource\n"); + return -ENXIO; + } + + davinci_vc->davinci_vcif.dma_tx_channel = res->start; + davinci_vc->davinci_vcif.dma_tx_addr = + (dma_addr_t)(io_v2p(davinci_vc->base) + DAVINCI_VC_WFIFO); + + res = platform_get_resource(pdev, IORESOURCE_DMA, 1); + if (!res) { + dev_err(&pdev->dev, "no DMA resource\n"); + return -ENXIO; + } + + davinci_vc->davinci_vcif.dma_rx_channel = res->start; + davinci_vc->davinci_vcif.dma_rx_addr = + (dma_addr_t)(io_v2p(davinci_vc->base) + DAVINCI_VC_RFIFO); + + davinci_vc->dev = &pdev->dev; + davinci_vc->pdev = pdev; + + /* Voice codec interface client */ + cell = &davinci_vc->cells[DAVINCI_VC_VCIF_CELL]; + cell->name = "davinci_vcif"; + cell->driver_data = davinci_vc; + + /* Voice codec CQ93VC client */ + cell = &davinci_vc->cells[DAVINCI_VC_CQ93VC_CELL]; + cell->name = "cq93vc"; + cell->driver_data = davinci_vc; + + ret = mfd_add_devices(&pdev->dev, pdev->id, davinci_vc->cells, + DAVINCI_VC_CELLS, NULL, 0); + if (ret != 0) { + dev_err(&pdev->dev, "fail to register client devices\n"); + goto fail4; + } + + return 0; + +fail4: + iounmap(davinci_vc->base); +fail3: + release_mem_region(davinci_vc->pbase, davinci_vc->base_size); +fail2: + clk_disable(davinci_vc->clk); + clk_put(davinci_vc->clk); + davinci_vc->clk = NULL; +fail1: + kfree(davinci_vc); + + return ret; +} + +static int __devexit davinci_vc_remove(struct platform_device *pdev) +{ + struct davinci_vc *davinci_vc = platform_get_drvdata(pdev); + + mfd_remove_devices(&pdev->dev); + + iounmap(davinci_vc->base); + release_mem_region(davinci_vc->pbase, davinci_vc->base_size); + + clk_disable(davinci_vc->clk); + clk_put(davinci_vc->clk); + davinci_vc->clk = NULL; + + kfree(davinci_vc); + + return 0; +} + +static struct platform_driver davinci_vc_driver = { + .driver = { + .name = "davinci_voicecodec", + .owner = THIS_MODULE, + }, + .remove = __devexit_p(davinci_vc_remove), +}; + +static int __init davinci_vc_init(void) +{ + return platform_driver_probe(&davinci_vc_driver, davinci_vc_probe); +} +module_init(davinci_vc_init); + +static void __exit davinci_vc_exit(void) +{ + platform_driver_unregister(&davinci_vc_driver); +} +module_exit(davinci_vc_exit); + +MODULE_AUTHOR("Miguel Aguilar"); +MODULE_DESCRIPTION("Texas Instruments DaVinci Voice Codec Core Interface"); +MODULE_LICENSE("GPL"); diff --git a/include/linux/mfd/davinci_voicecodec.h b/include/linux/mfd/davinci_voicecodec.h new file mode 100644 index 0000000..0ab6132 --- /dev/null +++ b/include/linux/mfd/davinci_voicecodec.h @@ -0,0 +1,126 @@ +/* + * DaVinci Voice Codec Core Interface for TI platforms + * + * Copyright (C) 2010 Texas Instruments, Inc + * + * Author: Miguel Aguilar + * + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef __LINUX_MFD_DAVINCI_VOICECODEC_H_ +#define __LINUX_MFD_DAVINIC_VOICECODEC_H_ + +#include +#include +#include + +#include + +/* + * Register values. + */ +#define DAVINCI_VC_PID 0x00 +#define DAVINCI_VC_CTRL 0x04 +#define DAVINCI_VC_INTEN 0x08 +#define DAVINCI_VC_INTSTATUS 0x0c +#define DAVINCI_VC_INTCLR 0x10 +#define DAVINCI_VC_EMUL_CTRL 0x14 +#define DAVINCI_VC_RFIFO 0x20 +#define DAVINCI_VC_WFIFO 0x24 +#define DAVINCI_VC_FIFOSTAT 0x28 +#define DAVINCI_VC_TST_CTRL 0x2C +#define DAVINCI_VC_REG05 0x94 +#define DAVINCI_VC_REG09 0xA4 +#define DAVINCI_VC_REG12 0xB0 + +/* DAVINCI_VC_CTRL bit fields */ +#define DAVINCI_VC_CTRL_MASK 0x5500 +#define DAVINCI_VC_CTRL_RSTADC BIT(0) +#define DAVINCI_VC_CTRL_RSTDAC BIT(1) +#define DAVINCI_VC_CTRL_RD_BITS_8 BIT(4) +#define DAVINCI_VC_CTRL_RD_UNSIGNED BIT(5) +#define DAVINCI_VC_CTRL_WD_BITS_8 BIT(6) +#define DAVINCI_VC_CTRL_WD_UNSIGNED BIT(7) +#define DAVINCI_VC_CTRL_RFIFOEN BIT(8) +#define DAVINCI_VC_CTRL_RFIFOCL BIT(9) +#define DAVINCI_VC_CTRL_RFIFOMD_WORD_1 BIT(10) +#define DAVINCI_VC_CTRL_WFIFOEN BIT(12) +#define DAVINCI_VC_CTRL_WFIFOCL BIT(13) +#define DAVINCI_VC_CTRL_WFIFOMD_WORD_1 BIT(14) + +/* DAVINCI_VC_INT bit fields */ +#define DAVINCI_VC_INT_MASK 0x3F +#define DAVINCI_VC_INT_RDRDY_MASK BIT(0) +#define DAVINCI_VC_INT_RERROVF_MASK BIT(1) +#define DAVINCI_VC_INT_RERRUDR_MASK BIT(2) +#define DAVINCI_VC_INT_WDREQ_MASK BIT(3) +#define DAVINCI_VC_INT_WERROVF_MASKBIT BIT(4) +#define DAVINCI_VC_INT_WERRUDR_MASK BIT(5) + +/* DAVINCI_VC_REG05 bit fields */ +#define DAVINCI_VC_REG05_PGA_GAIN 0x07 + +/* DAVINCI_VC_REG09 bit fields */ +#define DAVINCI_VC_REG09_MUTE 0x40 +#define DAVINCI_VC_REG09_DIG_ATTEN 0x3F + +/* DAVINCI_VC_REG12 bit fields */ +#define DAVINCI_VC_REG12_POWER_ALL_ON 0xFD +#define DAVINCI_VC_REG12_POWER_ALL_OFF 0x00 + +#define DAVINCI_VC_CELLS 2 + +enum davinci_vc_cells { + DAVINCI_VC_VCIF_CELL, + DAVINCI_VC_CQ93VC_CELL, +}; + +struct davinci_vcif { + struct platform_device *pdev; + u32 dma_tx_channel; + u32 dma_rx_channel; + dma_addr_t dma_tx_addr; + dma_addr_t dma_rx_addr; +}; + +struct cq93vc { + struct platform_device *pdev; + struct snd_soc_codec *codec; + u32 sysclk; +}; + +struct davinci_vc; + +struct davinci_vc { + /* Device data */ + struct device *dev; + struct platform_device *pdev; + struct clk *clk; + + /* Memory resources */ + void __iomem *base; + resource_size_t pbase; + size_t base_size; + + /* MFD cells */ + struct mfd_cell cells[DAVINCI_VC_CELLS]; + + /* Client devices */ + struct davinci_vcif davinci_vcif; + struct cq93vc cq93vc; +}; + +#endif -- 1.6.0.4 From miguel.aguilar at ridgerun.com Thu Mar 11 09:32:42 2010 From: miguel.aguilar at ridgerun.com (miguel.aguilar at ridgerun.com) Date: Thu, 11 Mar 2010 09:32:42 -0600 Subject: [PATCH v2 2/5] ASoC: DaVinci: Voice Codec Interface Message-ID: <1268321562-18951-1-git-send-email-miguel.aguilar@ridgerun.com> From: Miguel Aguilar This patch adds the support for the interface needed by the DaVinci Voice Codec CQ93VC. Signed-off-by: Miguel Aguilar --- sound/soc/davinci/Kconfig | 3 + sound/soc/davinci/Makefile | 2 + sound/soc/davinci/davinci-vcif.c | 272 ++++++++++++++++++++++++++++++++++++++ sound/soc/davinci/davinci-vcif.h | 28 ++++ 4 files changed, 305 insertions(+), 0 deletions(-) create mode 100644 sound/soc/davinci/davinci-vcif.c create mode 100644 sound/soc/davinci/davinci-vcif.h diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig index 047ee39..47e7cce 100644 --- a/sound/soc/davinci/Kconfig +++ b/sound/soc/davinci/Kconfig @@ -12,6 +12,9 @@ config SND_DAVINCI_SOC_I2S config SND_DAVINCI_SOC_MCASP tristate +config SND_DAVINCI_SOC_VCIF + tristate + config SND_DAVINCI_SOC_EVM tristate "SoC Audio support for DaVinci DM6446, DM355 or DM365 EVM" depends on SND_DAVINCI_SOC diff --git a/sound/soc/davinci/Makefile b/sound/soc/davinci/Makefile index a6939d7..a93679d 100644 --- a/sound/soc/davinci/Makefile +++ b/sound/soc/davinci/Makefile @@ -2,10 +2,12 @@ snd-soc-davinci-objs := davinci-pcm.o snd-soc-davinci-i2s-objs := davinci-i2s.o snd-soc-davinci-mcasp-objs:= davinci-mcasp.o +snd-soc-davinci-vcif-objs:= davinci-vcif.o obj-$(CONFIG_SND_DAVINCI_SOC) += snd-soc-davinci.o obj-$(CONFIG_SND_DAVINCI_SOC_I2S) += snd-soc-davinci-i2s.o obj-$(CONFIG_SND_DAVINCI_SOC_MCASP) += snd-soc-davinci-mcasp.o +obj-$(CONFIG_SND_DAVINCI_SOC_VCIF) += snd-soc-davinci-vcif.o # DAVINCI Machine Support snd-soc-evm-objs := davinci-evm.o diff --git a/sound/soc/davinci/davinci-vcif.c b/sound/soc/davinci/davinci-vcif.c new file mode 100644 index 0000000..03f3feb --- /dev/null +++ b/sound/soc/davinci/davinci-vcif.c @@ -0,0 +1,272 @@ +/* + * ALSA SoC Voice Codec Interface for TI DAVINCI processor + * + * Copyright (C) 2010 Texas Instruments. + * + * Author: Miguel Aguilar + * + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#include "davinci-pcm.h" +#include "davinci-i2s.h" +#include "davinci-vcif.h" + +#define MOD_REG_BIT(val, mask, set) do { \ + if (set) { \ + val |= mask; \ + } else { \ + val &= ~mask; \ + } \ +} while (0) + +struct davinci_vcif_dev { + struct davinci_vc *davinci_vc; + struct davinci_pcm_dma_params dma_params[2]; +}; + +static void davinci_vcif_start(struct snd_pcm_substream *substream) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct davinci_vcif_dev *davinci_vcif_dev = + rtd->dai->cpu_dai->private_data; + struct davinci_vc *davinci_vc = davinci_vcif_dev->davinci_vc; + u32 w; + + /* Start the sample generator and enable transmitter/receiver */ + w = readl(davinci_vc->base + DAVINCI_VC_CTRL); + + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTDAC, 1); + else + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTADC, 1); + + writel(w, davinci_vc->base + DAVINCI_VC_CTRL); +} + +static void davinci_vcif_stop(struct snd_pcm_substream *substream) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct davinci_vcif_dev *davinci_vcif_dev = + rtd->dai->cpu_dai->private_data; + struct davinci_vc *davinci_vc = davinci_vcif_dev->davinci_vc; + u32 w; + + /* Reset transmitter/receiver and sample rate/frame sync generators */ + w = readl(davinci_vc->base + DAVINCI_VC_CTRL); + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTDAC, 0); + else + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTADC, 0); + + writel(w, davinci_vc->base + DAVINCI_VC_CTRL); +} + +static int davinci_vcif_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params, + struct snd_soc_dai *dai) +{ + struct davinci_vcif_dev *davinci_vcif_dev = dai->private_data; + struct davinci_vc *davinci_vc = davinci_vcif_dev->davinci_vc; + struct davinci_pcm_dma_params *dma_params = + &davinci_vcif_dev->dma_params[substream->stream]; + u32 w; + + /* Restart the codec before setup */ + davinci_vcif_stop(substream); + davinci_vcif_start(substream); + + /* General line settings */ + writel(DAVINCI_VC_CTRL_MASK, davinci_vc->base + DAVINCI_VC_CTRL); + + writel(DAVINCI_VC_INT_MASK, davinci_vc->base + DAVINCI_VC_INTCLR); + + writel(DAVINCI_VC_INT_MASK, davinci_vc->base + DAVINCI_VC_INTEN); + + w = readl(davinci_vc->base + DAVINCI_VC_CTRL); + + /* Determine xfer data type */ + switch (params_format(params)) { + case SNDRV_PCM_FORMAT_U8: + dma_params->data_type = 0; + + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RD_BITS_8 | + DAVINCI_VC_CTRL_RD_UNSIGNED | + DAVINCI_VC_CTRL_WD_BITS_8 | + DAVINCI_VC_CTRL_WD_UNSIGNED, 1); + break; + case SNDRV_PCM_FORMAT_S8: + dma_params->data_type = 1; + + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RD_BITS_8 | + DAVINCI_VC_CTRL_WD_BITS_8, 1); + + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RD_UNSIGNED | + DAVINCI_VC_CTRL_WD_UNSIGNED, 0); + break; + case SNDRV_PCM_FORMAT_S16_LE: + dma_params->data_type = 2; + + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RD_BITS_8 | + DAVINCI_VC_CTRL_RD_UNSIGNED | + DAVINCI_VC_CTRL_WD_BITS_8 | + DAVINCI_VC_CTRL_WD_UNSIGNED, 0); + break; + default: + printk(KERN_WARNING "davinci-vcif: unsupported PCM format"); + return -EINVAL; + } + + dma_params->acnt = dma_params->data_type; + + writel(w, davinci_vc->base + DAVINCI_VC_CTRL); + + return 0; +} + +static int davinci_vcif_trigger(struct snd_pcm_substream *substream, int cmd, + struct snd_soc_dai *dai) +{ + int ret = 0; + + switch (cmd) { + case SNDRV_PCM_TRIGGER_START: + case SNDRV_PCM_TRIGGER_RESUME: + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: + davinci_vcif_start(substream); + case SNDRV_PCM_TRIGGER_STOP: + case SNDRV_PCM_TRIGGER_SUSPEND: + case SNDRV_PCM_TRIGGER_PAUSE_PUSH: + davinci_vcif_stop(substream); + break; + default: + ret = -EINVAL; + } + + return ret; +} + +#define DAVINCI_VCIF_RATES SNDRV_PCM_RATE_8000_48000 + +static struct snd_soc_dai_ops davinci_vcif_dai_ops = { + .trigger = davinci_vcif_trigger, + .hw_params = davinci_vcif_hw_params, +}; + +struct snd_soc_dai davinci_vcif_dai = { + .name = "davinci-vcif", + .playback = { + .channels_min = 1, + .channels_max = 2, + .rates = DAVINCI_VCIF_RATES, + .formats = SNDRV_PCM_FMTBIT_S16_LE,}, + .capture = { + .channels_min = 1, + .channels_max = 2, + .rates = DAVINCI_VCIF_RATES, + .formats = SNDRV_PCM_FMTBIT_S16_LE,}, + .ops = &davinci_vcif_dai_ops, + +}; +EXPORT_SYMBOL_GPL(davinci_vcif_dai); + +static int davinci_vcif_probe(struct platform_device *pdev) +{ + struct davinci_vc *davinci_vc = platform_get_drvdata(pdev); + struct davinci_vcif_dev *davinci_vcif_dev; + int ret; + + davinci_vcif_dev = kzalloc(sizeof(struct davinci_vcif_dev), GFP_KERNEL); + if (!davinci_vc) { + dev_dbg(&pdev->dev, + "could not allocate memory for private data\n"); + return -ENOMEM; + } + + /* DMA tx params */ + davinci_vcif_dev->davinci_vc = davinci_vc; + davinci_vcif_dev->dma_params[SNDRV_PCM_STREAM_PLAYBACK].channel = + davinci_vc->davinci_vcif.dma_tx_channel; + davinci_vcif_dev->dma_params[SNDRV_PCM_STREAM_PLAYBACK].dma_addr = + davinci_vc->davinci_vcif.dma_tx_addr; + + /* DMA rx params */ + davinci_vcif_dev->dma_params[SNDRV_PCM_STREAM_CAPTURE].channel = + davinci_vc->davinci_vcif.dma_rx_channel; + davinci_vcif_dev->dma_params[SNDRV_PCM_STREAM_CAPTURE].dma_addr = + davinci_vc->davinci_vcif.dma_rx_addr; + + davinci_vcif_dai.dev = &pdev->dev; + davinci_vcif_dai.dma_data = davinci_vcif_dev->dma_params; + davinci_vcif_dai.private_data = davinci_vcif_dev; + + ret = snd_soc_register_dai(&davinci_vcif_dai); + if (ret != 0) { + dev_err(&pdev->dev, "could not register dai\n"); + goto fail; + } + + return 0; + +fail: + kfree(davinci_vcif_dev); + + return ret; +} + +static int davinci_vcif_remove(struct platform_device *pdev) +{ + snd_soc_unregister_dai(&davinci_vcif_dai); + + return 0; +} + +static struct platform_driver davinci_vcif_driver = { + .probe = davinci_vcif_probe, + .remove = davinci_vcif_remove, + .driver = { + .name = "davinci_vcif", + .owner = THIS_MODULE, + }, +}; + +static int __init davinci_vcif_init(void) +{ + return platform_driver_probe(&davinci_vcif_driver, davinci_vcif_probe); +} +module_init(davinci_vcif_init); + +static void __exit davinci_vcif_exit(void) +{ + platform_driver_unregister(&davinci_vcif_driver); +} +module_exit(davinci_vcif_exit); + +MODULE_AUTHOR("Miguel Aguilar"); +MODULE_DESCRIPTION("Texas Instruments DaVinci ASoC Voice Codec Interface"); +MODULE_LICENSE("GPL"); diff --git a/sound/soc/davinci/davinci-vcif.h b/sound/soc/davinci/davinci-vcif.h new file mode 100644 index 0000000..571c994 --- /dev/null +++ b/sound/soc/davinci/davinci-vcif.h @@ -0,0 +1,28 @@ +/* + * ALSA SoC Voice Codec Interface for TI DAVINCI processor + * + * Copyright (C) 2010 Texas Instruments. + * + * Author: Miguel Aguilar + * + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef _DAVINCI_VCIF_H +#define _DAVINCI_VCIF_H + +extern struct snd_soc_dai davinci_vcif_dai; + +#endif -- 1.6.0.4 From miguel.aguilar at ridgerun.com Thu Mar 11 09:32:59 2010 From: miguel.aguilar at ridgerun.com (miguel.aguilar at ridgerun.com) Date: Thu, 11 Mar 2010 09:32:59 -0600 Subject: [PATCH v2 3/5] ASoC: DaVinci: CQ93VC Voice Codec Message-ID: <1268321579-18978-1-git-send-email-miguel.aguilar@ridgerun.com> From: Miguel Aguilar Currently the DM365 is the only SoC that includes this Voice Codec. Signed-off-by: Miguel Aguilar --- sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/cq93vc.c | 298 +++++++++++++++++++++++++++++++++++++++++++++ sound/soc/codecs/cq93vc.h | 29 +++++ 4 files changed, 333 insertions(+), 0 deletions(-) create mode 100644 sound/soc/codecs/cq93vc.c create mode 100644 sound/soc/codecs/cq93vc.h diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 52b005f..0daca22 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -21,6 +21,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_AK4535 if I2C select SND_SOC_AK4642 if I2C select SND_SOC_AK4671 if I2C + select SND_SOC_CQ0093VC if MFD_DAVINCI_VOICECODEC select SND_SOC_CS4270 if I2C select SND_SOC_MAX9877 if I2C select SND_SOC_PCM3008 @@ -108,6 +109,9 @@ config SND_SOC_AK4642 config SND_SOC_AK4671 tristate +config SND_SOC_CQ0093VC + tristate + # Cirrus Logic CS4270 Codec config SND_SOC_CS4270 tristate diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index dbaecb1..dff91fb 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -8,6 +8,7 @@ snd-soc-ak4104-objs := ak4104.o snd-soc-ak4535-objs := ak4535.o snd-soc-ak4642-objs := ak4642.o snd-soc-ak4671-objs := ak4671.o +snd-soc-cq93vc-objs := cq93vc.o snd-soc-cs4270-objs := cs4270.o snd-soc-cx20442-objs := cx20442.o snd-soc-l3-objs := l3.o @@ -64,6 +65,7 @@ obj-$(CONFIG_SND_SOC_AK4104) += snd-soc-ak4104.o obj-$(CONFIG_SND_SOC_AK4535) += snd-soc-ak4535.o obj-$(CONFIG_SND_SOC_AK4642) += snd-soc-ak4642.o obj-$(CONFIG_SND_SOC_AK4671) += snd-soc-ak4671.o +obj-$(CONFIG_SND_SOC_CQ0093VC) += snd-soc-cq93vc.o obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o obj-$(CONFIG_SND_SOC_CX20442) += snd-soc-cx20442.o obj-$(CONFIG_SND_SOC_L3) += snd-soc-l3.o diff --git a/sound/soc/codecs/cq93vc.c b/sound/soc/codecs/cq93vc.c new file mode 100644 index 0000000..5132974 --- /dev/null +++ b/sound/soc/codecs/cq93vc.c @@ -0,0 +1,298 @@ +/* + * ALSA SoC CQ0093 Voice Codec Driver for DaVinci platforms + * + * Copyright (C) 2010 Texas Instruments, Inc + * + * Author: Miguel Aguilar + * + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "cq93vc.h" + +static inline unsigned int cq93vc_read(struct snd_soc_codec *codec, + unsigned int reg) +{ + struct davinci_vc *davinci_vc = codec->control_data; + + return readl(davinci_vc->base + reg); +} + +static inline int cq93vc_write(struct snd_soc_codec *codec, unsigned int reg, + unsigned int value) +{ + struct davinci_vc *davinci_vc = codec->control_data; + + writel(value, davinci_vc->base + reg); + + return 0; +} + +static const struct snd_kcontrol_new cq93vc_snd_controls[] = { + SOC_SINGLE("PGA Capture Volume", DAVINCI_VC_REG05, 0, 0x03, 0), + SOC_SINGLE("Mono DAC Playback Volume", DAVINCI_VC_REG09, 0, 0x3f, 0), +}; + +static int cq93vc_mute(struct snd_soc_dai *dai, int mute) +{ + struct snd_soc_codec *codec = dai->codec; + u8 reg = cq93vc_read(codec, DAVINCI_VC_REG09) & ~DAVINCI_VC_REG09_MUTE; + + if (mute) + cq93vc_write(codec, DAVINCI_VC_REG09, + reg | DAVINCI_VC_REG09_MUTE); + else + cq93vc_write(codec, DAVINCI_VC_REG09, reg); + + return 0; +} + +static int cq93vc_set_dai_sysclk(struct snd_soc_dai *codec_dai, + int clk_id, unsigned int freq, int dir) +{ + struct snd_soc_codec *codec = codec_dai->codec; + struct davinci_vc *davinci_vc = codec->control_data; + + switch (freq) { + case 22579200: + case 27000000: + case 33868800: + davinci_vc->cq93vc.sysclk = freq; + return 0; + } + + return -EINVAL; +} + +static int cq93vc_set_bias_level(struct snd_soc_codec *codec, + enum snd_soc_bias_level level) +{ + switch (level) { + case SND_SOC_BIAS_ON: + cq93vc_write(codec, DAVINCI_VC_REG12, + DAVINCI_VC_REG12_POWER_ALL_ON); + break; + case SND_SOC_BIAS_PREPARE: + break; + case SND_SOC_BIAS_STANDBY: + cq93vc_write(codec, DAVINCI_VC_REG12, + DAVINCI_VC_REG12_POWER_ALL_OFF); + break; + case SND_SOC_BIAS_OFF: + /* force all power off */ + cq93vc_write(codec, DAVINCI_VC_REG12, + DAVINCI_VC_REG12_POWER_ALL_OFF); + break; + } + codec->bias_level = level; + + return 0; +} + +#define CQ93VC_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_16000) +#define CQ93VC_FORMATS (SNDRV_PCM_FMTBIT_U8 | SNDRV_PCM_FMTBIT_S16_LE) + +static struct snd_soc_dai_ops cq93vc_dai_ops = { + .digital_mute = cq93vc_mute, + .set_sysclk = cq93vc_set_dai_sysclk, +}; + +struct snd_soc_dai cq93vc_dai = { + .name = "CQ93VC", + .playback = { + .stream_name = "Playback", + .channels_min = 1, + .channels_max = 2, + .rates = CQ93VC_RATES, + .formats = CQ93VC_FORMATS,}, + .capture = { + .stream_name = "Capture", + .channels_min = 1, + .channels_max = 2, + .rates = CQ93VC_RATES, + .formats = CQ93VC_FORMATS,}, + .ops = &cq93vc_dai_ops, +}; +EXPORT_SYMBOL_GPL(cq93vc_dai); + +static int cq93vc_resume(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + struct snd_soc_codec *codec = socdev->card->codec; + + cq93vc_set_bias_level(codec, codec->suspend_bias_level); + + return 0; +} + +static struct snd_soc_codec *cq93vc_codec; + +static int cq93vc_probe(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + struct device *dev = &pdev->dev; + struct snd_soc_codec *codec; + int ret; + + socdev->card->codec = cq93vc_codec; + codec = socdev->card->codec; + + /* Register pcms */ + ret = snd_soc_new_pcms(socdev, SNDRV_DEFAULT_IDX1, SNDRV_DEFAULT_STR1); + if (ret < 0) { + dev_err(dev, "%s: failed to create pcms\n", pdev->name); + return ret; + } + + /* Set controls */ + snd_soc_add_controls(codec, cq93vc_snd_controls, + ARRAY_SIZE(cq93vc_snd_controls)); + + /* Off, with power on */ + cq93vc_set_bias_level(codec, SND_SOC_BIAS_STANDBY); + + return 0; +} + +static int cq93vc_remove(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + + snd_soc_free_pcms(socdev); + snd_soc_dapm_free(socdev); + + return 0; +} + +struct snd_soc_codec_device soc_codec_dev_cq93vc = { + .probe = cq93vc_probe, + .remove = cq93vc_remove, + .resume = cq93vc_resume, +}; +EXPORT_SYMBOL_GPL(soc_codec_dev_cq93vc); + +static __init int cq93vc_codec_probe(struct platform_device *pdev) +{ + struct davinci_vc *davinci_vc = platform_get_drvdata(pdev); + struct snd_soc_codec *codec; + int ret; + + codec = kzalloc(sizeof(struct snd_soc_codec), GFP_KERNEL); + if (codec == NULL) { + dev_dbg(davinci_vc->dev, + "could not allocate memory for codec data\n"); + return -ENOMEM; + } + + davinci_vc->cq93vc.codec = codec; + + cq93vc_dai.dev = &pdev->dev; + + mutex_init(&codec->mutex); + INIT_LIST_HEAD(&codec->dapm_widgets); + INIT_LIST_HEAD(&codec->dapm_paths); + codec->dev = &pdev->dev; + codec->name = "CQ93VC"; + codec->owner = THIS_MODULE; + codec->read = cq93vc_read; + codec->write = cq93vc_write; + codec->set_bias_level = cq93vc_set_bias_level; + codec->dai = &cq93vc_dai; + codec->num_dai = 1; + codec->control_data = davinci_vc; + + cq93vc_codec = codec; + + ret = snd_soc_register_codec(codec); + if (ret) { + dev_err(davinci_vc->dev, "failed to register codec\n"); + goto fail1; + } + + ret = snd_soc_register_dai(&cq93vc_dai); + if (ret) { + dev_err(davinci_vc->dev, "could register dai\n"); + goto fail2; + } + return 0; + +fail2: + snd_soc_unregister_codec(codec); + +fail1: + kfree(codec); + cq93vc_codec = NULL; + + return ret; +} + +static int __devexit cq93vc_codec_remove(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + struct snd_soc_codec *codec = socdev->card->codec; + + snd_soc_unregister_dai(&cq93vc_dai); + snd_soc_unregister_codec(&codec); + + kfree(codec); + cq93vc_codec = NULL; + + return 0; +} + +static struct platform_driver cq93vc_codec_driver = { + .driver = { + .name = "cq93vc", + .owner = THIS_MODULE, + }, + .probe = cq93vc_codec_probe, + .remove = __devexit_p(cq93vc_codec_remove), +}; + +static __init int cq93vc_init(void) +{ + return platform_driver_probe(&cq93vc_codec_driver, cq93vc_codec_probe); +} +module_init(cq93vc_init); + +static __exit void cq93vc_exit(void) +{ + platform_driver_unregister(&cq93vc_codec_driver); +} +module_exit(cq93vc_exit); + +MODULE_DESCRIPTION("Texas Instruments DaVinci ASoC CQ0093 Voice Codec Driver"); +MODULE_AUTHOR("Miguel Aguilar"); +MODULE_LICENSE("GPL"); diff --git a/sound/soc/codecs/cq93vc.h b/sound/soc/codecs/cq93vc.h new file mode 100644 index 0000000..845b196 --- /dev/null +++ b/sound/soc/codecs/cq93vc.h @@ -0,0 +1,29 @@ +/* + * ALSA SoC CQ0093 Voice Codec Driver for DaVinci platforms + * + * Copyright (C) 2010 Texas Instruments, Inc + * + * Author: Miguel Aguilar + * + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef _CQ93VC_H +#define _CQ93VC_H + +extern struct snd_soc_dai cq93vc_dai; +extern struct snd_soc_codec_device soc_codec_dev_cq93vc; + +#endif -- 1.6.0.4 From miguel.aguilar at ridgerun.com Thu Mar 11 09:33:22 2010 From: miguel.aguilar at ridgerun.com (miguel.aguilar at ridgerun.com) Date: Thu, 11 Mar 2010 09:33:22 -0600 Subject: [PATCH 4/5] DaVinci: DM365: Voice codec support for the DM365 SoC Message-ID: <1268321602-19007-1-git-send-email-miguel.aguilar@ridgerun.com> From: Miguel Aguilar This patch adds the generic Voice Codec support for the DM365 based platforms. Signed-off-by: Miguel Aguilar --- arch/arm/mach-davinci/dm365.c | 37 +++++++++++++++++++++++++++- arch/arm/mach-davinci/include/mach/dm365.h | 5 ++++ arch/arm/mach-davinci/include/mach/mux.h | 2 + 3 files changed, 43 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index c63afc0..b5345d5 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -455,7 +455,7 @@ static struct clk_lookup dm365_clks[] = { CLK(NULL, "timer3", &timer3_clk), CLK(NULL, "usb", &usb_clk), CLK("davinci_emac.1", NULL, &emac_clk), - CLK("voice_codec", NULL, &voicecodec_clk), + CLK("davinci_voicecodec", NULL, &voicecodec_clk), CLK("davinci-asp.0", NULL, &asp0_clk), CLK(NULL, "rto", &rto_clk), CLK(NULL, "mjcp", &mjcp_clk), @@ -606,6 +606,8 @@ 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) +EVT_CFG(DM365, EVT2_VC_TX, 0, 1, 1, false) +EVT_CFG(DM365, EVT3_VC_RX, 1, 1, 1, false) #endif }; @@ -835,6 +837,31 @@ static struct platform_device dm365_asp_device = { .resource = dm365_asp_resources, }; +static struct resource dm365_vc_resources[] = { + { + .start = DAVINCI_DM365_VC_BASE, + .end = DAVINCI_DM365_VC_BASE + SZ_1K - 1, + .flags = IORESOURCE_MEM, + }, + { + .start = DAVINCI_DMA_VC_TX, + .end = DAVINCI_DMA_VC_TX, + .flags = IORESOURCE_DMA, + }, + { + .start = DAVINCI_DMA_VC_RX, + .end = DAVINCI_DMA_VC_RX, + .flags = IORESOURCE_DMA, + }, +}; + +static struct platform_device dm365_vc_device = { + .name = "davinci_voicecodec", + .id = -1, + .num_resources = ARRAY_SIZE(dm365_vc_resources), + .resource = dm365_vc_resources, +}; + static struct resource dm365_rtc_resources[] = { { .start = DM365_RTC_BASE, @@ -991,6 +1018,14 @@ void __init dm365_init_asp(struct snd_platform_data *pdata) platform_device_register(&dm365_asp_device); } +void __init dm365_init_vc(struct snd_platform_data *pdata) +{ + davinci_cfg_reg(DM365_EVT2_VC_TX); + davinci_cfg_reg(DM365_EVT3_VC_RX); + dm365_vc_device.dev.platform_data = pdata; + platform_device_register(&dm365_vc_device); +} + void __init dm365_init_ks(struct davinci_ks_platform_data *pdata) { dm365_ks_device.dev.platform_data = pdata; diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h index 3c07a88..57e51eb 100644 --- a/arch/arm/mach-davinci/include/mach/dm365.h +++ b/arch/arm/mach-davinci/include/mach/dm365.h @@ -31,8 +31,13 @@ #define DM365_RTC_BASE (0x01C69000) +#define DAVINCI_DM365_VC_BASE (0x01D0C000) +#define DAVINCI_DMA_VC_TX 2 +#define DAVINCI_DMA_VC_RX 3 + void __init dm365_init(void); void __init dm365_init_asp(struct snd_platform_data *pdata); +void __init dm365_init_vc(struct snd_platform_data *pdata); void __init dm365_init_ks(struct davinci_ks_platform_data *pdata); void __init dm365_init_rtc(void); diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h index 137bfba..2a68c1d 100644 --- a/arch/arm/mach-davinci/include/mach/mux.h +++ b/arch/arm/mach-davinci/include/mach/mux.h @@ -327,6 +327,8 @@ enum davinci_dm365_index { /* EDMA event muxing */ DM365_EVT2_ASP_TX, DM365_EVT3_ASP_RX, + DM365_EVT2_VC_TX, + DM365_EVT3_VC_RX, DM365_EVT26_MMC0_RX, }; -- 1.6.0.4 From miguel.aguilar at ridgerun.com Thu Mar 11 09:33:40 2010 From: miguel.aguilar at ridgerun.com (miguel.aguilar at ridgerun.com) Date: Thu, 11 Mar 2010 09:33:40 -0600 Subject: [PATCH 5/5] DaVinci: DM365: Voice Codec support for the DM365 EVM Message-ID: <1268321620-19074-1-git-send-email-miguel.aguilar@ridgerun.com> From: Miguel Aguilar The DM365 EVM has two codecs: the Audio Codec (AIC3x) and the Voice Codec, the idea is to have both enabled in the same kernel simultaneously. However, the current soc-core doesn't support simultaneous codecs, once that support will have added, a patch will be posted to enable both codecs in the DM365 EVM. Signed-off-by: Miguel Aguilar --- arch/arm/mach-davinci/board-dm365-evm.c | 4 +++ sound/soc/davinci/Kconfig | 24 +++++++++++++++- sound/soc/davinci/davinci-evm.c | 45 +++++++++++++++++++++++++++++- 3 files changed, 69 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c index 5c2636c..865d06a 100644 --- a/arch/arm/mach-davinci/board-dm365-evm.c +++ b/arch/arm/mach-davinci/board-dm365-evm.c @@ -516,7 +516,11 @@ static __init void dm365_evm_init(void) /* maybe setup mmc1/etc ... _after_ mmc0 */ evm_init_cpld(); +#ifdef CONFIG_SND_DM365_AIC3X_CODEC dm365_init_asp(&dm365_evm_snd_data); +#elif defined(CONFIG_SND_DM365_VOICE_CODEC) + dm365_init_vc(&dm365_evm_snd_data); +#endif dm365_init_rtc(); dm365_init_ks(&dm365evm_ks_data); } diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig index 47e7cce..6bbf001 100644 --- a/sound/soc/davinci/Kconfig +++ b/sound/soc/davinci/Kconfig @@ -18,12 +18,32 @@ config SND_DAVINCI_SOC_VCIF config SND_DAVINCI_SOC_EVM tristate "SoC Audio support for DaVinci DM6446, DM355 or DM365 EVM" depends on SND_DAVINCI_SOC - depends on MACH_DAVINCI_EVM || MACH_DAVINCI_DM355_EVM || MACH_DAVINCI_DM365_EVM + depends on MACH_DAVINCI_EVM || MACH_DAVINCI_DM355_EVM || 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 - DaVinci DM6446 or DM355 EVM platforms. + DaVinci DM6446, DM355 or DM365 EVM platforms. + +choice + prompt "DM365 codec select" + depends on SND_DAVINCI_SOC_EVM + depends on MACH_DAVINCI_DM365_EVM + default SND_DM365_EXTERNAL_CODEC + +config SND_DM365_AIC3X_CODEC + bool "Audio Codec - AIC3101" + help + Say Y if you want to add support for AIC3101 audio codec + +config SND_DM365_VOICE_CODEC + bool "Voice Codec - CQ93VC" + select MFD_DAVINCI_VOICECODEC + select SND_DAVINCI_SOC_VCIF + select SND_SOC_CQ0093VC + help + Say Y if you want to add support for SoC On-chip voice codec +endchoice config SND_DM6467_SOC_EVM tristate "SoC Audio support for DaVinci DM6467 EVM" diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c index 7ccbe66..ef63096 100644 --- a/sound/soc/davinci/davinci-evm.c +++ b/sound/soc/davinci/davinci-evm.c @@ -28,10 +28,12 @@ #include #include "../codecs/tlv320aic3x.h" +#include "../codecs/cq93vc.h" #include "../codecs/spdif_transciever.h" #include "davinci-pcm.h" #include "davinci-i2s.h" #include "davinci-mcasp.h" +#include "davinci-vcif.h" #define AUDIO_FORMAT (SND_SOC_DAIFMT_DSP_B | \ SND_SOC_DAIFMT_CBM_CFM | SND_SOC_DAIFMT_IB_NF) @@ -151,6 +153,22 @@ static struct snd_soc_dai_link evm_dai = { .ops = &evm_ops, }; +static struct snd_soc_dai_link dm365_evm_dai = { +#ifdef CONFIG_SND_DM365_AIC3X_CODEC + .name = "TLV320AIC3X", + .stream_name = "AIC3X", + .cpu_dai = &davinci_i2s_dai, + .codec_dai = &aic3x_dai, + .init = evm_aic3x_init, + .ops = &evm_ops, +#elif defined(CONFIG_SND_DM365_VOICE_CODEC) + .name = "Voice Codec - CQ93VC", + .stream_name = "CQ93", + .cpu_dai = &davinci_vcif_dai, + .codec_dai = &cq93vc_dai, +#endif +}; + static struct snd_soc_dai_link dm6467_evm_dai[] = { { .name = "TLV320AIC3X", @@ -177,7 +195,7 @@ static struct snd_soc_dai_link da8xx_evm_dai = { .ops = &evm_ops, }; -/* davinci dm6446, dm355 or dm365 evm audio machine driver */ +/* davinci dm6446, dm355 evm audio machine driver */ static struct snd_soc_card snd_soc_card_evm = { .name = "DaVinci EVM", .platform = &davinci_soc_platform, @@ -185,6 +203,15 @@ static struct snd_soc_card snd_soc_card_evm = { .num_links = 1, }; +/* 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 = &dm365_evm_dai, + .num_links = 1, +}; + + /* davinci dm6467 evm audio machine driver */ static struct snd_soc_card dm6467_snd_soc_card_evm = { .name = "DaVinci DM6467 EVM", @@ -217,6 +244,17 @@ static struct snd_soc_device evm_snd_devdata = { }; /* evm audio subsystem */ +static struct snd_soc_device dm365_evm_snd_devdata = { + .card = &dm365_snd_soc_card_evm, +#ifdef CONFIG_SND_DM365_AIC3X_CODEC + .codec_dev = &soc_codec_dev_aic3x, + .codec_data = &aic3x_setup, +#elif defined(CONFIG_SND_DM365_VOICE_CODEC) + .codec_dev = &soc_codec_dev_cq93vc, +#endif +}; + +/* evm audio subsystem */ static struct snd_soc_device dm6467_evm_snd_devdata = { .card = &dm6467_snd_soc_card_evm, .codec_dev = &soc_codec_dev_aic3x, @@ -244,12 +282,15 @@ static int __init evm_init(void) int index; int ret; - if (machine_is_davinci_evm() || machine_is_davinci_dm365_evm()) { + if (machine_is_davinci_evm()) { evm_snd_dev_data = &evm_snd_devdata; index = 0; } else if (machine_is_davinci_dm355_evm()) { evm_snd_dev_data = &evm_snd_devdata; index = 1; + } else if (machine_is_davinci_dm365_evm()) { + evm_snd_dev_data = &dm365_evm_snd_devdata; + index = 0; } else if (machine_is_davinci_dm6467_evm()) { evm_snd_dev_data = &dm6467_evm_snd_devdata; index = 0; -- 1.6.0.4 From lamiaposta71 at gmail.com Thu Mar 11 10:14:58 2010 From: lamiaposta71 at gmail.com (Raffaele Recalcati) Date: Thu, 11 Mar 2010 17:14:58 +0100 Subject: adv7180 support Message-ID: We are starting developing adv7180 support compliant to arago tree. I hope it is a good idea, and when khilman tree will be the possible davinci standard tree we'll move to it changing adv7180 support. Any suggestion is welcome. -- www.opensurf.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgriffis at ti.com Thu Mar 11 10:28:24 2010 From: bgriffis at ti.com (Griffis, Brad) Date: Thu, 11 Mar 2010 10:28:24 -0600 Subject: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus In-Reply-To: <4B94FD84.3060100@mvista.com> References: <1264549293-25556-1-git-send-email-khilman@deeprootsystems.com> <1264549293-25556-7-git-send-email-khilman@deeprootsystems.com> <225d086e1002050553tc1a696avce827cc115f56b1c@mail.gmail.com> <4B702A17.3070104@mvista.com> <4B7135B3.9080104@mvista.com> <4B94FD84.3060100@mvista.com> Message-ID: > -----Original Message----- > From: Philby John [mailto:pjohn at mvista.com] > Sent: Monday, March 08, 2010 7:37 AM > To: Griffis, Brad > Cc: Nori, Sekhar; davinci-linux-open-source at linux.davincidsp.com; linux- > i2c at vger.kernel.org > Subject: Re: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the > bus > > I did go through your document, but what does "free data format" mean? > It would be good to expand the procedure that enables you to move into > this mode. If this wouldn't require modfying pinmux settings shouldn't > it be part of the core i2c implementation? Just to make sure my point was clear, I think the GPIO method is simpler/easier if you're just looking at a single device and assuming that device has muxed the I2C with GPIO. That said, my method is a little more complicated/convoluted when looking at a single device, but I think the code would scale better across the entire Davinci tree since it requires no knowledge of whether the pin-muxing option is available and how the pin-muxing is implemented for that particular device. You enter the "free data format" mode by setting the FDF bit in the ICMDR register. It is described in Section 2.6.3 of the OMAP-L138 I2C Guide: http://www.ti.com/lit/sprufl9 The advantage of using this mode is that you would not require any device-specific pin-muxing knowledge/changes. The entire recovery can occur within the context of the I2C controller. So to do a read in the "free data format" mode you would write ICMDR.FDF = 1 (free data format), ICMDR.TRX = 0 (read), ICMDR.STT = 1 (start), ICMDR.STP = 1. This should cause it to clock in 8 bits of data plus an ack, freeing up the bus. Brad From wwang at evertz.com Thu Mar 11 11:04:16 2010 From: wwang at evertz.com (Wendy Wang) Date: Thu, 11 Mar 2010 12:04:16 -0500 Subject: xDM vs xDAIS Message-ID: <13B290A06827324E9ADB71AA314F8189277D60@otis.burlington.evertz.tv> Any examples (ie fft dct) of using cache memory instead of external memory? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sshtylyov at mvista.com Thu Mar 11 05:00:45 2010 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Thu, 11 Mar 2010 14:00:45 +0300 Subject: [PATCH] davinci: MMC: Pass number of SG segments as platform data In-Reply-To: <1268292756-5369-1-git-send-email-sudhakar.raj@ti.com> References: <1268292756-5369-1-git-send-email-sudhakar.raj@ti.com> Message-ID: <4B98CD5D.3080709@mvista.com> Hello. Sudhakar Rajashekhara wrote: > On some platforms like DM355, the number of EDMA parameter > slots available for EDMA_SLOT_ANY usage are few. In such cases, > if MMC/SD uses 16 slots for each instance of MMC controller, > then the number of slots available for other modules will be > very few. > > By passing the number of EDMA slots to be used in MMC driver > from platform data, EDMA slots available for other purposes > can be controlled. > > Signed-off-by: Sudhakar Rajashekhara > --- > arch/arm/mach-davinci/include/mach/mmc.h | 3 +++ > drivers/mmc/host/davinci_mmc.c | 22 +++++++++++++++------- > 2 files changed, 18 insertions(+), 7 deletions(-) > > diff --git a/arch/arm/mach-davinci/include/mach/mmc.h b/arch/arm/mach-davinci/include/mach/mmc.h > index 5a85e24..384fc0e 100644 > --- a/arch/arm/mach-davinci/include/mach/mmc.h > +++ b/arch/arm/mach-davinci/include/mach/mmc.h > @@ -22,6 +22,9 @@ struct davinci_mmc_config { > > /* Version of the MMC/SD controller */ > u8 version; > + > + /* Number of sg segments */ > + u32 nr_sg; > Why waste 4 bytres if the maximum number is 16? > diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c > index 3bd0ba2..19c050c 100644 > --- a/drivers/mmc/host/davinci_mmc.c > +++ b/drivers/mmc/host/davinci_mmc.c > @@ -137,15 +137,15 @@ > > /* > * One scatterlist dma "segment" is at most MAX_CCNT rw_threshold units, > - * and we handle up to NR_SG segments. MMC_BLOCK_BOUNCE kicks in only > + * and we handle up to MAX_NR_SG segments. MMC_BLOCK_BOUNCE kicks in only > * for drivers with max_hw_segs == 1, making the segments bigger (64KB) > - * than the page or two that's otherwise typical. NR_SG == 16 gives at > - * least the same throughput boost, using EDMA transfer linkage instead > - * of spending CPU time copying pages. > + * than the page or two that's otherwise typical. nr_sg (passed from > + * platform data) == 16 gives at least the same throughput boost, using > + * EDMA transfer linkage instead of spending CPU time copying pages. > */ > #define MAX_CCNT ((1 << 16) - 1) > > -#define NR_SG 16 > +#define MAX_NR_SG 16 > > static unsigned rw_threshold = 32; > module_param(rw_threshold, uint, S_IRUGO); > @@ -192,7 +192,7 @@ struct mmc_davinci_host { > struct edmacc_param tx_template; > struct edmacc_param rx_template; > unsigned n_link; > - u32 links[NR_SG - 1]; > + u32 links[MAX_NR_SG - 1]; > > /* For PIO we walk scatterlists one segment at a time. */ > > unsigned int sg_len; > @@ -202,6 +202,8 @@ struct mmc_davinci_host { > u8 version; > /* for ns in one cycle calculation */ > unsigned ns_in_one_cycle; > + /* Number of sg segments */ > + u32 nr_sg; > Same question. WBR, Sergei From bgoetz at altierre.com Thu Mar 11 13:06:59 2010 From: bgoetz at altierre.com (Bill Goetz) Date: Thu, 11 Mar 2010 11:06:59 -0800 Subject: DM365, NAND and FS In-Reply-To: <0554BEF07D437848AF01B9C9B5F0BC5D9C3624DB@dlee01.ent.ti.com> References: <6988e0d1003100457g53b5f70ftfdcd144ecba2adc3@mail.gmail.com> <0554BEF07D437848AF01B9C9B5F0BC5D9C3624DB@dlee01.ent.ti.com> Message-ID: Hi Sandeep, To fix the "jffs2_get_inode_nodes: Node header CRC failed at 0x190c6f48" errors, I've been using the "nand markbad" from U-Boot to mark the bad blocks (in the above case, the command would be 'nand markbad 0x190c0000'). Now that I've updated to the latest U-Boot code, Linux now does pick up the bad block tables written from U-Boot (thanks for that!) Once the particular block(s) as bad, I then reflash the NAND partition that was affected and the CRC errors are gone. However, we're seeing quite a few CRC errors. On one unit, after marking a bunch of bad blocks, then reflashing, we're seeing a few more CRC errors so we have to repeat the process. Again, after the reflash, CRC errors appeared on yet a different address!! Is this common???? We've got an FPGA also on the EMIFA bus (using a different CS). That shouldn't be causing it. If it were, I'm sure we'd be seeing errors on many other units. Any insights? Thanks, Bill -----Original Message----- From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Paulraj, Sandeep Sent: Wednesday, March 10, 2010 7:25 AM To: Mile Davidovic; davinci Subject: RE: DM365, NAND and FS > > Hello > On DM365 board I saw following printout: > U-Boot 2009.03 (Nov 16 2009 - 13:02:47) > > I2C: ready > DRAM: 128 MB > NAND: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND > 1GiB 3,3V 8-bit) > Bad block table found at page 524224, version 0x01 > Bad block table found at page 524160, version 0x01 > NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V > 8-bit) > Bad block table found at page 524224, version 0x01 > Bad block table found at page 524096, version 0x01 > 2048 MiB > In: serial > .... > NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V > 8-bit) > 2 NAND chips detected > Bad block table found at page 524224, version 0x01 > Bad block table found at page 1048512, version 0x01 > Bad block table found at page 524160, version 0x01 > Bad block table found at page 1048384, version 0x01 > nand_read_bbt: Bad block at 0x000000820000 > nand_read_bbt: Bad block at 0x000008aa0000 > nand_read_bbt: Bad block at 0x00000fac0000 > nand_read_bbt: Bad block at 0x000015280000 > nand_read_bbt: Bad block at 0x000016ea0000 > nand_read_bbt: Bad block at 0x00001a720000 > nand_read_bbt: Bad block at 0x00001c120000 > nand_read_bbt: Bad block at 0x0000238e0000 > nand_read_bbt: Bad block at 0x000028340000 > nand_read_bbt: Bad block at 0x000028680000 > nand_read_bbt: Bad block at 0x000030640000 > nand_read_bbt: Bad block at 0x000032560000 > nand_read_bbt: Bad block at 0x0000382c0000 > nand_read_bbt: Bad block at 0x00003bec0000 > nand_read_bbt: Bad block at 0x00003c240000 > nand_read_bbt: Bad block at 0x00004bd60000 > nand_read_bbt: Bad block at 0x00004be40000 > nand_read_bbt: Bad block at 0x0000685c0000 > nand_read_bbt: Bad block at 0x00006ea20000 > nand_read_bbt: Bad block at 0x00006ede0000 > nand_read_bbt: Bad block at 0x00006fda0000 > nand_read_bbt: Bad block at 0x000076020000 > nand_read_bbt: Bad block at 0x00007df40000 > nand_read_bbt: Bad block at 0x00007e720000 > nand_read_bbt: Bad block at 0x00007ffc0000 There is nothing wrong in getting these messages. U-boot is merely reporting bad blocks > Creating 5 MTD partitions on "davinci_nand.0": > 0x000000000000-0x000000f00000 : "bootloader" > 0x000000f00000-0x000001000000 : "params" > 0x000001000000-0x000001400000 : "kernel" > 0x000001400000-0x000021400000 : "filesystem1" > 0x000021400000-0x000080000000 : "filesystem2" > davinci_nand davinci_nand.0: controller rev. 2.3 > ... > mtd->read(0xb8 bytes from 0x190c6f48) returned ECC error > JFFS2 notice: (1007) jffs2_get_inode_nodes: Node header CRC failed at > 0x190c6f48. {0219,c0e0,71000000,99faccda} > JFFS2 notice: (1007) jffs2_get_inode_nodes: Node header CRC failed at > 0x190c6e88. {0219,c0e0,71000000,99faccda} > JFFS2 notice: (1007) jffs2_get_inode_nodes: Node header CRC failed at > 0x190c6d20. {0219,68e0,ac000001,9973d181} > JFFS2 notice: (1007) jffs2_get_inode_nodes: Node header CRC failed at > 0x190c6c60. {0219,c0e0,71000000,99faccda} > JFFS2 notice: (1007) jffs2_get_inode_nodes: Node header CRC failed at > 0x190c6ba0. {0219,c0e0,71000000,99faccda} > ... > Also during boot I got following: > Empty flash at 0x092b9700 ends at 0x092b9800 > Empty flash at 0x460b4d44 ends at 0x460b5000 > Empty flash at 0x59a0d8dc ends at 0x59a0e000 > > My questions are: > - is it normal board behavior (we have issues with JFFS2 and NAND) from > start > - is it possible that we somehow "repair" this board? > - what is "recommended" FS for NAND? > - is any chance that problems with NAND is caused with wrong u-boot, > linux, ... > > Kind regards > mile > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source at linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source From khilman at deeprootsystems.com Thu Mar 11 16:56:01 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Thu, 11 Mar 2010 14:56:01 -0800 Subject: [PATCH] net: davinci emac: use dma_{map, unmap}_single API for cache coherency In-Reply-To: <1268133637-23399-1-git-send-email-nsekhar@ti.com> (Sekhar Nori's message of "Tue\, 9 Mar 2010 16\:50\:37 +0530") References: <1268133637-23399-1-git-send-email-nsekhar@ti.com> Message-ID: <87eijqbh8e.fsf@deeprootsystems.com> Sekhar Nori writes: > The davinci emac driver uses some ARM specific DMA APIs > for cache coherency which have been removed from kernel > with the 2.6.34 merge. > > Modify the driver to use the dma_{map, unmap}_single() APIs > defined in dma-mapping.h > > Without this fix, the driver fails to compile on Linus's > tree. > > Tested on DM365 and OMAP-L138 EVMs. > > Signed-off-by: Sekhar Nori Acked-by: Kevin Hilman Verified that this is compiling/running again with v2.6.34-rc1. Kevin From khilman at deeprootsystems.com Thu Mar 11 17:32:57 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Thu, 11 Mar 2010 15:32:57 -0800 Subject: [PATCH] davinci: edma: clear events in edma_start() In-Reply-To: <1268174883-13933-1-git-send-email-bniebuhr@efjohnson.com> (Brian Niebuhr's message of "Tue\, 9 Mar 2010 16\:48\:03 -0600") References: <1268174883-13933-1-git-send-email-bniebuhr@efjohnson.com> Message-ID: <874okmbfiu.fsf@deeprootsystems.com> Brian Niebuhr writes: > This patch fixes an issue where a DMA channel can erroneously process an > event generated by a previous transfer. A failure case is where DMA is > being used for SPI transmit and receive channels on OMAP L138. In this > case there is a single bit that controls all event generation from the > SPI peripheral. Therefore it is possible that between when edma_stop() > has been called for the transmit channel on a previous transfer and > edma_start() is called for the transmit channel on a subsequent transfer, > that a transmit event has been generated. > > The fix is to clear events in edma_start(). This prevents false events > from being processed when events are enabled for that channel. > > Signed-off-by: Brian Niebuhr Thanks, applying and queuing in davinci-fixes for v2.6.34-rc Kevin > --- > arch/arm/mach-davinci/dma.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c > index 5cd48fa..52c16ff 100644 > --- a/arch/arm/mach-davinci/dma.c > +++ b/arch/arm/mach-davinci/dma.c > @@ -1290,7 +1290,8 @@ int edma_start(unsigned channel) > /* EDMA channel with event association */ > pr_debug("EDMA: ER%d %08x\n", j, > edma_shadow0_read_array(ctlr, SH_ER, j)); > - /* Clear any pending error */ > + /* Clear any pending event or error */ > + edma_write_array(ctlr, EDMA_ECR, j, mask); > edma_write_array(ctlr, EDMA_EMCR, j, mask); > /* Clear any SER */ > edma_shadow0_write_array(ctlr, SH_SECR, j, mask); > -- > 1.6.3.3 > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source From khilman at deeprootsystems.com Thu Mar 11 17:39:24 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Thu, 11 Mar 2010 15:39:24 -0800 Subject: [PATCH] davinci: MMC: Pass number of SG segments as platform data In-Reply-To: <1268292756-5369-1-git-send-email-sudhakar.raj@ti.com> (Sudhakar Rajashekhara's message of "Thu\, 11 Mar 2010 13\:02\:36 +0530") References: <1268292756-5369-1-git-send-email-sudhakar.raj@ti.com> Message-ID: <87wrxia0nn.fsf@deeprootsystems.com> Sudhakar Rajashekhara writes: > On some platforms like DM355, the number of EDMA parameter > slots available for EDMA_SLOT_ANY usage are few. In such cases, > if MMC/SD uses 16 slots for each instance of MMC controller, > then the number of slots available for other modules will be > very few. > > By passing the number of EDMA slots to be used in MMC driver > from platform data, EDMA slots available for other purposes > can be controlled. > > Signed-off-by: Sudhakar Rajashekhara > --- > arch/arm/mach-davinci/include/mach/mmc.h | 3 +++ > drivers/mmc/host/davinci_mmc.c | 22 +++++++++++++++------- > 2 files changed, 18 insertions(+), 7 deletions(-) > [...] > @@ -1202,6 +1206,10 @@ static int __init davinci_mmcsd_probe(struct platform_device *pdev) > > init_mmcsd_host(host); > > + host->nr_sg = pdata->nr_sg - 1; If a board doesn't setup pdata->nr_sg it will be zero, leaving host->nr_sg = -1. > + if (host->nr_sg > MAX_NR_SG || host->nr_sg == 0) > + host->nr_sg = MAX_NR_SG; Since host->nr_sg is unsigned, you get lucky and fix it up here, but for readability, this not too clean and should be more thorough. Wrapping the above in 'if (pdata->nr_sg)' is a more standard way of handling optional platform_data paramaters. Kevin From khilman at deeprootsystems.com Thu Mar 11 18:05:59 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Thu, 11 Mar 2010 16:05:59 -0800 Subject: davinci git updated to v2.6.34-rc1 Message-ID: <87hbom9zfc.fsf@deeprootsystems.com> FYI... Davinci git has now been updated to v2.6.34-rc1. With this release, we have dramatically reduced the gap between davinci git and mainline with lots of stuff making it in for 2.6.34. Nice work! Currently there are only 21 patches in davinci git that are not in mainline, and several of those are fixes that will be queued for 2.6.34-rc. Kevin From paul at pwsan.com Thu Mar 11 20:02:24 2010 From: paul at pwsan.com (Paul Walmsley) Date: Thu, 11 Mar 2010 19:02:24 -0700 (MST) Subject: [PATCH 3/4] OMAP3 : clock data: Update name string for EMAC clocks. In-Reply-To: <1268320422-32656-4-git-send-email-srk@ti.com> References: <1268320422-32656-1-git-send-email-srk@ti.com> <1268320422-32656-2-git-send-email-srk@ti.com> <1268320422-32656-3-git-send-email-srk@ti.com> <1268320422-32656-4-git-send-email-srk@ti.com> Message-ID: On Thu, 11 Mar 2010, Sriramakrishnan wrote: > The emac driver uses generic name for the module and phy > clocks. Updated the omap3xxx_clks table to match the names > used by the Davinci emac driver. > > Signed-off-by: Sriramakrishnan Acked-by: Paul Walmsley At some point, someone should go through that davinci_emac.c driver and change the DaVinci references to "TI" or something generic, now that this core exists on DaVinci, OMAP, etc. > --- > arch/arm/mach-omap2/clock3xxx_data.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c > index d5153b6..989da2e 100644 > --- a/arch/arm/mach-omap2/clock3xxx_data.c > +++ b/arch/arm/mach-omap2/clock3xxx_data.c > @@ -3472,8 +3472,8 @@ static struct omap_clk omap3xxx_clks[] = { > CLK(NULL, "ipss_ick", &ipss_ick, CK_AM35XX), > CLK(NULL, "rmii_ck", &rmii_ck, CK_AM35XX), > CLK(NULL, "pclk_ck", &pclk_ck, CK_AM35XX), > - CLK("davinci_emac", "ick", &emac_ick, CK_AM35XX), > - CLK("davinci_emac", "fck", &emac_fck, CK_AM35XX), > + CLK("davinci_emac", "emac_clk", &emac_ick, CK_AM35XX), > + CLK("davinci_emac", "phy_clk", &emac_fck, CK_AM35XX), > CLK("vpfe-capture", "master", &vpfe_ick, CK_AM35XX), > CLK("vpfe-capture", "slave", &vpfe_fck, CK_AM35XX), > CLK("musb_hdrc", "ick", &hsotgusb_ick_am35xx, CK_AM35XX), > -- > 1.6.2.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > - Paul From nsekhar at ti.com Fri Mar 12 00:47:40 2010 From: nsekhar at ti.com (Nori, Sekhar) Date: Fri, 12 Mar 2010 12:17:40 +0530 Subject: adv7180 support In-Reply-To: References: Message-ID: Hello Raffaele, On Thu, Mar 11, 2010 at 21:44:58, Raffaele Recalcati wrote: > We are starting developing adv7180 support compliant to arago tree. > I hope it is a good idea, and when khilman tree will be the possible > davinci standard tree we'll move to it changing adv7180 support. > Any suggestion is welcome. Note that patches are not accepted against arago tree. It is only a TI development tree. You can use it for testing, but the patch you submit should be against the tree V4L2 maintainer mandates. Typically only arch/arm/mach-davinci/* changes are merged through Kevin's tree. Thanks, Sekhar From lamiaposta71 at gmail.com Fri Mar 12 00:51:11 2010 From: lamiaposta71 at gmail.com (Raffaele Recalcati) Date: Fri, 12 Mar 2010 07:51:11 +0100 Subject: davinci git updated to v2.6.34-rc1 In-Reply-To: <87hbom9zfc.fsf@deeprootsystems.com> References: <87hbom9zfc.fsf@deeprootsystems.com> Message-ID: 2010/3/12 Kevin Hilman > FYI... > > Davinci git has now been updated to v2.6.34-rc1. With this release, > we have dramatically reduced the gap between davinci git and mainline > with lots of stuff making it in for 2.6.34. Nice work! > > Nice! I need anyway more explanations. I see you are talking about: http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git and not: http://arago-project.org/git/projects/linux-davinci.git So, the best thing for me should be to move exactly now to it for testing input video with adv7180 on dm365? Maybe I spend more time at this moment, but if it is "the right thing" I will spend less time in the future rebasing my code from arago old tree. Suggestions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lamiaposta71 at gmail.com Fri Mar 12 00:54:04 2010 From: lamiaposta71 at gmail.com (Raffaele Recalcati) Date: Fri, 12 Mar 2010 07:54:04 +0100 Subject: adv7180 support In-Reply-To: References: Message-ID: 2010/3/12 Nori, Sekhar > > Hello Raffaele, > > On Thu, Mar 11, 2010 at 21:44:58, Raffaele Recalcati wrote: > > We are starting developing adv7180 support compliant to arago tree. > > I hope it is a good idea, and when khilman tree will be the possible > > davinci standard tree we'll move to it changing adv7180 support. > > Any suggestion is welcome. > > Note that patches are not accepted against arago tree. It is only > a TI development tree. You can use it for testing, but the patch > you submit should be against the tree V4L2 maintainer mandates. > > Typically only arch/arm/mach-davinci/* changes are merged through > Kevin's tree. > I was writing now about adv7180 replying to Hilman. So "the right thing" is moving my development to Kevin branch. I'd like to be as near as possible to the mainline, by now. Any idea about evm-dm365 peripheral tests? > > Thanks, > Sekhar > -- www.opensurf.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From lrg at slimlogic.co.uk Fri Mar 12 02:00:57 2010 From: lrg at slimlogic.co.uk (Liam Girdwood) Date: Fri, 12 Mar 2010 08:00:57 +0000 Subject: [alsa-devel] [PATCH v2 2/5] ASoC: DaVinci: Voice Codec Interface In-Reply-To: <1268321562-18951-1-git-send-email-miguel.aguilar@ridgerun.com> References: <1268321562-18951-1-git-send-email-miguel.aguilar@ridgerun.com> Message-ID: <1268380857.3755.3.camel@odin> On Thu, 2010-03-11 at 09:32 -0600, miguel.aguilar at ridgerun.com wrote: > From: Miguel Aguilar > > This patch adds the support for the interface needed by the DaVinci > Voice Codec CQ93VC. > > Signed-off-by: Miguel Aguilar > --- snip > + > +static int davinci_vcif_hw_params(struct snd_pcm_substream *substream, > + struct snd_pcm_hw_params *params, > + struct snd_soc_dai *dai) > +{ > + struct davinci_vcif_dev *davinci_vcif_dev = dai->private_data; > + struct davinci_vc *davinci_vc = davinci_vcif_dev->davinci_vc; > + struct davinci_pcm_dma_params *dma_params = > + &davinci_vcif_dev->dma_params[substream->stream]; > + u32 w; > + > + /* Restart the codec before setup */ > + davinci_vcif_stop(substream); > + davinci_vcif_start(substream); > + > + /* General line settings */ > + writel(DAVINCI_VC_CTRL_MASK, davinci_vc->base + DAVINCI_VC_CTRL); > + > + writel(DAVINCI_VC_INT_MASK, davinci_vc->base + DAVINCI_VC_INTCLR); > + > + writel(DAVINCI_VC_INT_MASK, davinci_vc->base + DAVINCI_VC_INTEN); > + > + w = readl(davinci_vc->base + DAVINCI_VC_CTRL); > + > + /* Determine xfer data type */ > + switch (params_format(params)) { > + case SNDRV_PCM_FORMAT_U8: > + dma_params->data_type = 0; > + > + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RD_BITS_8 | > + DAVINCI_VC_CTRL_RD_UNSIGNED | > + DAVINCI_VC_CTRL_WD_BITS_8 | > + DAVINCI_VC_CTRL_WD_UNSIGNED, 1); > + break; > + case SNDRV_PCM_FORMAT_S8: > + dma_params->data_type = 1; > + > + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RD_BITS_8 | > + DAVINCI_VC_CTRL_WD_BITS_8, 1); > + > + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RD_UNSIGNED | > + DAVINCI_VC_CTRL_WD_UNSIGNED, 0); > + break; > + case SNDRV_PCM_FORMAT_S16_LE: > + dma_params->data_type = 2; > + > + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RD_BITS_8 | > + DAVINCI_VC_CTRL_RD_UNSIGNED | > + DAVINCI_VC_CTRL_WD_BITS_8 | > + DAVINCI_VC_CTRL_WD_UNSIGNED, 0); > + break; > + default: > + printk(KERN_WARNING "davinci-vcif: unsupported PCM format"); > + return -EINVAL; > + } > + > + dma_params->acnt = dma_params->data_type; > + > + writel(w, davinci_vc->base + DAVINCI_VC_CTRL); > + > + return 0; > +} > + > +static int davinci_vcif_trigger(struct snd_pcm_substream *substream, int cmd, > + struct snd_soc_dai *dai) > +{ > + int ret = 0; > + > + switch (cmd) { > + case SNDRV_PCM_TRIGGER_START: > + case SNDRV_PCM_TRIGGER_RESUME: > + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: > + davinci_vcif_start(substream); > + case SNDRV_PCM_TRIGGER_STOP: > + case SNDRV_PCM_TRIGGER_SUSPEND: > + case SNDRV_PCM_TRIGGER_PAUSE_PUSH: > + davinci_vcif_stop(substream); > + break; > + default: > + ret = -EINVAL; > + } > + > + return ret; > +} > + > +#define DAVINCI_VCIF_RATES SNDRV_PCM_RATE_8000_48000 > + > +static struct snd_soc_dai_ops davinci_vcif_dai_ops = { > + .trigger = davinci_vcif_trigger, > + .hw_params = davinci_vcif_hw_params, > +}; > + > +struct snd_soc_dai davinci_vcif_dai = { > + .name = "davinci-vcif", > + .playback = { > + .channels_min = 1, > + .channels_max = 2, > + .rates = DAVINCI_VCIF_RATES, > + .formats = SNDRV_PCM_FMTBIT_S16_LE,}, > + .capture = { > + .channels_min = 1, > + .channels_max = 2, > + .rates = DAVINCI_VCIF_RATES, > + .formats = SNDRV_PCM_FMTBIT_S16_LE,}, Your hw_params() supports more formats than just this one. Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk From lrg at slimlogic.co.uk Fri Mar 12 02:01:56 2010 From: lrg at slimlogic.co.uk (Liam Girdwood) Date: Fri, 12 Mar 2010 08:01:56 +0000 Subject: [alsa-devel] [PATCH v2 1/5] MFD: DaVinci Voice Codec In-Reply-To: <1268321541-18922-1-git-send-email-miguel.aguilar@ridgerun.com> References: <1268321541-18922-1-git-send-email-miguel.aguilar@ridgerun.com> Message-ID: <1268380916.3755.4.camel@odin> On Thu, 2010-03-11 at 09:32 -0600, miguel.aguilar at ridgerun.com wrote: > From: Miguel Aguilar > > This is the MFD driver for the DaVinci Voice codec, it has two clients: > > * Voice codec interface > * Voice codec CQ93VC > > Signed-off-by: Miguel Aguilar Please CC the MFD maintainer too for this one. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk From broonie at opensource.wolfsonmicro.com Fri Mar 12 02:13:25 2010 From: broonie at opensource.wolfsonmicro.com (Mark Brown) Date: Fri, 12 Mar 2010 08:13:25 +0000 Subject: [alsa-devel] [PATCH v2 1/5] MFD: DaVinci Voice Codec In-Reply-To: <1268380916.3755.4.camel@odin> (sfid-20100312_080205_765150_09FEB7AD) References: <1268321541-18922-1-git-send-email-miguel.aguilar@ridgerun.com> <1268380916.3755.4.camel@odin> (sfid-20100312_080205_765150_09FEB7AD) Message-ID: <9FFC5872-87B8-452E-B85C-D029B4F67E5B@opensource.wolfsonmicro.com> On 12 Mar 2010, at 08:01, Liam Girdwood wrote: > On Thu, 2010-03-11 at 09:32 -0600, miguel.aguilar at ridgerun.com wrote: >> From: Miguel Aguilar >> >> This is the MFD driver for the DaVinci Voice codec, it has two >> clients: >> >> * Voice codec interface >> * Voice codec CQ93VC >> >> Signed-off-by: Miguel Aguilar > > Please CC the MFD maintainer too for this one. Or if, as is the case here IIRC, they've already acked it include their ack in repostings. > > Thanks > > Liam > > -- > Freelance Developer, SlimLogic Ltd > ASoC and Voltage Regulator Maintainer. > http://www.slimlogic.co.uk > From sudhakar.raj at ti.com Fri Mar 12 03:47:00 2010 From: sudhakar.raj at ti.com (Sudhakar Rajashekhara) Date: Fri, 12 Mar 2010 15:17:00 +0530 Subject: [PATCH] davinci: MMC: Pass number of SG segments as platform data In-Reply-To: <4B98CD5D.3080709@mvista.com> References: <1268292756-5369-1-git-send-email-sudhakar.raj@ti.com> <4B98CD5D.3080709@mvista.com> Message-ID: <048c01cac1c8$f65c1410$e3143c30$@raj@ti.com> Hi, On Thu, Mar 11, 2010 at 16:30:45, Sergei Shtylyov wrote: > Hello. > > Sudhakar Rajashekhara wrote: > > > On some platforms like DM355, the number of EDMA parameter > > slots available for EDMA_SLOT_ANY usage are few. In such cases, > > if MMC/SD uses 16 slots for each instance of MMC controller, > > then the number of slots available for other modules will be > > very few. > > > > By passing the number of EDMA slots to be used in MMC driver > > from platform data, EDMA slots available for other purposes > > can be controlled. > > > > Signed-off-by: Sudhakar Rajashekhara > > --- > > arch/arm/mach-davinci/include/mach/mmc.h | 3 +++ > > drivers/mmc/host/davinci_mmc.c | 22 +++++++++++++++------- > > 2 files changed, 18 insertions(+), 7 deletions(-) > > > > diff --git a/arch/arm/mach-davinci/include/mach/mmc.h b/arch/arm/mach-davinci/include/mach/mmc.h > > index 5a85e24..384fc0e 100644 > > --- a/arch/arm/mach-davinci/include/mach/mmc.h > > +++ b/arch/arm/mach-davinci/include/mach/mmc.h > > @@ -22,6 +22,9 @@ struct davinci_mmc_config { > > > > /* Version of the MMC/SD controller */ > > u8 version; > > + > > + /* Number of sg segments */ > > + u32 nr_sg; > > > > Why waste 4 bytres if the maximum number is 16? > I'll modify it to u8 and re-submit the patch. Thanks, Sudhakar From sudhakar.raj at ti.com Fri Mar 12 03:48:11 2010 From: sudhakar.raj at ti.com (Sudhakar Rajashekhara) Date: Fri, 12 Mar 2010 15:18:11 +0530 Subject: [PATCH] davinci: MMC: Pass number of SG segments as platform data In-Reply-To: <87wrxia0nn.fsf@deeprootsystems.com> References: <1268292756-5369-1-git-send-email-sudhakar.raj@ti.com> <87wrxia0nn.fsf@deeprootsystems.com> Message-ID: <048d01cac1c9$21034490$6309cdb0$@raj@ti.com> Kevin, On Fri, Mar 12, 2010 at 05:09:24, Kevin Hilman wrote: > Sudhakar Rajashekhara writes: > > > On some platforms like DM355, the number of EDMA parameter > > slots available for EDMA_SLOT_ANY usage are few. In such cases, > > if MMC/SD uses 16 slots for each instance of MMC controller, > > then the number of slots available for other modules will be > > very few. > > > > By passing the number of EDMA slots to be used in MMC driver > > from platform data, EDMA slots available for other purposes > > can be controlled. > > > > Signed-off-by: Sudhakar Rajashekhara > > --- > > arch/arm/mach-davinci/include/mach/mmc.h | 3 +++ > > drivers/mmc/host/davinci_mmc.c | 22 +++++++++++++++------- > > 2 files changed, 18 insertions(+), 7 deletions(-) > > > > [...] > > > @@ -1202,6 +1206,10 @@ static int __init davinci_mmcsd_probe(struct platform_device *pdev) > > > > init_mmcsd_host(host); > > > > + host->nr_sg = pdata->nr_sg - 1; > > If a board doesn't setup pdata->nr_sg it will be zero, leaving > host->nr_sg = -1. > > > + if (host->nr_sg > MAX_NR_SG || host->nr_sg == 0) > > + host->nr_sg = MAX_NR_SG; > > Since host->nr_sg is unsigned, you get lucky and fix it up here, but > for readability, this not too clean and should be more thorough. > > Wrapping the above in 'if (pdata->nr_sg)' is a more standard way > of handling optional platform_data paramaters. > I'll modify the patch as per your suggestion and resubmit it. Thanks, Sudhakar From lamiaposta71 at gmail.com Fri Mar 12 04:27:02 2010 From: lamiaposta71 at gmail.com (Raffaele Recalcati) Date: Fri, 12 Mar 2010 11:27:02 +0100 Subject: [PATCH v2 1/5] MFD: DaVinci Voice Codec In-Reply-To: <1268321541-18922-1-git-send-email-miguel.aguilar@ridgerun.com> References: <1268321541-18922-1-git-send-email-miguel.aguilar@ridgerun.com> Message-ID: Thank for the support. I'm sorry, maybe my question is too simple, anyway I have to understand which is the default git tree where the patches are normally done against. I guess you have written the patch against http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git git tree. It is right? If I'm right I can guess that the default git tree where every developer is working on davinci is actually http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git. Please somebody can give a clear information about this point? 2010/3/11 > From: Miguel Aguilar > > This is the MFD driver for the DaVinci Voice codec, it has two clients: > > * Voice codec interface > * Voice codec CQ93VC > > Signed-off-by: Miguel Aguilar > --- > drivers/mfd/Kconfig | 4 + > drivers/mfd/Makefile | 1 + > drivers/mfd/davinci_voicecodec.c | 189 > ++++++++++++++++++++++++++++++++ > include/linux/mfd/davinci_voicecodec.h | 126 +++++++++++++++++++++ > 4 files changed, 320 insertions(+), 0 deletions(-) > create mode 100644 drivers/mfd/davinci_voicecodec.c > create mode 100644 include/linux/mfd/davinci_voicecodec.h > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 8782978..6e93c0b 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -43,6 +43,10 @@ config MFD_SH_MOBILE_SDHI > This driver supports the SDHI hardware block found in many > SuperH Mobile SoCs. > > +config MFD_DAVINCI_VOICECODEC > + tristate > + select MFD_CORE > + > config MFD_DM355EVM_MSP > bool "DaVinci DM355 EVM microcontroller" > depends on I2C && MACH_DAVINCI_DM355_EVM > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > index ca2f2c4..f5c617f 100644 > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -9,6 +9,7 @@ obj-$(CONFIG_MFD_SH_MOBILE_SDHI) += > sh_mobile_sdhi.o > obj-$(CONFIG_HTC_EGPIO) += htc-egpio.o > obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o > > +obj-$(CONFIG_MFD_DAVINCI_VOICECODEC) += davinci_voicecodec.o > obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o > > obj-$(CONFIG_MFD_T7L66XB) += t7l66xb.o > diff --git a/drivers/mfd/davinci_voicecodec.c > b/drivers/mfd/davinci_voicecodec.c > new file mode 100644 > index 0000000..9886aa8 > --- /dev/null > +++ b/drivers/mfd/davinci_voicecodec.c > @@ -0,0 +1,189 @@ > +/* > + * DaVinci Voice Codec Core Interface for TI platforms > + * > + * Copyright (C) 2010 Texas Instruments, Inc > + * > + * Author: Miguel Aguilar > + * > + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#include > + > +u32 davinci_vc_read(struct davinci_vc *davinci_vc, int reg) > +{ > + return __raw_readl(davinci_vc->base + reg); > +} > + > +void davinci_vc_write(struct davinci_vc *davinci_vc, > + int reg, u32 val) > +{ > + __raw_writel(val, davinci_vc->base + reg); > +} > + > +static int __init davinci_vc_probe(struct platform_device *pdev) > +{ > + struct davinci_vc *davinci_vc; > + struct resource *res, *mem; > + struct mfd_cell *cell = NULL; > + int ret; > + > + davinci_vc = kzalloc(sizeof(struct davinci_vc), GFP_KERNEL); > + if (!davinci_vc) { > + dev_dbg(&pdev->dev, > + "could not allocate memory for private > data\n"); > + return -ENOMEM; > + } > + > + davinci_vc->clk = clk_get(&pdev->dev, NULL); > + if (IS_ERR(davinci_vc->clk)) { > + dev_dbg(&pdev->dev, > + "could not get the clock for voice codec\n"); > + ret = -ENODEV; > + goto fail1; > + } > + clk_enable(davinci_vc->clk); > + > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + if (!res) { > + dev_err(&pdev->dev, "no mem resource\n"); > + ret = -ENODEV; > + goto fail2; > + } > + > + davinci_vc->pbase = res->start; > + davinci_vc->base_size = resource_size(res); > + > + mem = request_mem_region(davinci_vc->pbase, davinci_vc->base_size, > + pdev->name); > + if (!mem) { > + dev_err(&pdev->dev, "VCIF region already claimed\n"); > + ret = -EBUSY; > + goto fail2; > + } > + > + davinci_vc->base = ioremap(davinci_vc->pbase, > davinci_vc->base_size); > + if (!davinci_vc->base) { > + dev_err(&pdev->dev, "can't ioremap mem resource.\n"); > + ret = -ENOMEM; > + goto fail3; > + } > + > + res = platform_get_resource(pdev, IORESOURCE_DMA, 0); > + if (!res) { > + dev_err(&pdev->dev, "no DMA resource\n"); > + return -ENXIO; > + } > + > + davinci_vc->davinci_vcif.dma_tx_channel = res->start; > + davinci_vc->davinci_vcif.dma_tx_addr = > + (dma_addr_t)(io_v2p(davinci_vc->base) + DAVINCI_VC_WFIFO); > + > + res = platform_get_resource(pdev, IORESOURCE_DMA, 1); > + if (!res) { > + dev_err(&pdev->dev, "no DMA resource\n"); > + return -ENXIO; > + } > + > + davinci_vc->davinci_vcif.dma_rx_channel = res->start; > + davinci_vc->davinci_vcif.dma_rx_addr = > + (dma_addr_t)(io_v2p(davinci_vc->base) + DAVINCI_VC_RFIFO); > + > + davinci_vc->dev = &pdev->dev; > + davinci_vc->pdev = pdev; > + > + /* Voice codec interface client */ > + cell = &davinci_vc->cells[DAVINCI_VC_VCIF_CELL]; > + cell->name = "davinci_vcif"; > + cell->driver_data = davinci_vc; > + > + /* Voice codec CQ93VC client */ > + cell = &davinci_vc->cells[DAVINCI_VC_CQ93VC_CELL]; > + cell->name = "cq93vc"; > + cell->driver_data = davinci_vc; > + > + ret = mfd_add_devices(&pdev->dev, pdev->id, davinci_vc->cells, > + DAVINCI_VC_CELLS, NULL, 0); > + if (ret != 0) { > + dev_err(&pdev->dev, "fail to register client devices\n"); > + goto fail4; > + } > + > + return 0; > + > +fail4: > + iounmap(davinci_vc->base); > +fail3: > + release_mem_region(davinci_vc->pbase, davinci_vc->base_size); > +fail2: > + clk_disable(davinci_vc->clk); > + clk_put(davinci_vc->clk); > + davinci_vc->clk = NULL; > +fail1: > + kfree(davinci_vc); > + > + return ret; > +} > + > +static int __devexit davinci_vc_remove(struct platform_device *pdev) > +{ > + struct davinci_vc *davinci_vc = platform_get_drvdata(pdev); > + > + mfd_remove_devices(&pdev->dev); > + > + iounmap(davinci_vc->base); > + release_mem_region(davinci_vc->pbase, davinci_vc->base_size); > + > + clk_disable(davinci_vc->clk); > + clk_put(davinci_vc->clk); > + davinci_vc->clk = NULL; > + > + kfree(davinci_vc); > + > + return 0; > +} > + > +static struct platform_driver davinci_vc_driver = { > + .driver = { > + .name = "davinci_voicecodec", > + .owner = THIS_MODULE, > + }, > + .remove = __devexit_p(davinci_vc_remove), > +}; > + > +static int __init davinci_vc_init(void) > +{ > + return platform_driver_probe(&davinci_vc_driver, davinci_vc_probe); > +} > +module_init(davinci_vc_init); > + > +static void __exit davinci_vc_exit(void) > +{ > + platform_driver_unregister(&davinci_vc_driver); > +} > +module_exit(davinci_vc_exit); > + > +MODULE_AUTHOR("Miguel Aguilar"); > +MODULE_DESCRIPTION("Texas Instruments DaVinci Voice Codec Core > Interface"); > +MODULE_LICENSE("GPL"); > diff --git a/include/linux/mfd/davinci_voicecodec.h > b/include/linux/mfd/davinci_voicecodec.h > new file mode 100644 > index 0000000..0ab6132 > --- /dev/null > +++ b/include/linux/mfd/davinci_voicecodec.h > @@ -0,0 +1,126 @@ > +/* > + * DaVinci Voice Codec Core Interface for TI platforms > + * > + * Copyright (C) 2010 Texas Instruments, Inc > + * > + * Author: Miguel Aguilar > + * > + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > + */ > + > +#ifndef __LINUX_MFD_DAVINCI_VOICECODEC_H_ > +#define __LINUX_MFD_DAVINIC_VOICECODEC_H_ > + > +#include > +#include > +#include > + > +#include > + > +/* > + * Register values. > + */ > +#define DAVINCI_VC_PID 0x00 > +#define DAVINCI_VC_CTRL 0x04 > +#define DAVINCI_VC_INTEN 0x08 > +#define DAVINCI_VC_INTSTATUS 0x0c > +#define DAVINCI_VC_INTCLR 0x10 > +#define DAVINCI_VC_EMUL_CTRL 0x14 > +#define DAVINCI_VC_RFIFO 0x20 > +#define DAVINCI_VC_WFIFO 0x24 > +#define DAVINCI_VC_FIFOSTAT 0x28 > +#define DAVINCI_VC_TST_CTRL 0x2C > +#define DAVINCI_VC_REG05 0x94 > +#define DAVINCI_VC_REG09 0xA4 > +#define DAVINCI_VC_REG12 0xB0 > + > +/* DAVINCI_VC_CTRL bit fields */ > +#define DAVINCI_VC_CTRL_MASK 0x5500 > +#define DAVINCI_VC_CTRL_RSTADC BIT(0) > +#define DAVINCI_VC_CTRL_RSTDAC BIT(1) > +#define DAVINCI_VC_CTRL_RD_BITS_8 BIT(4) > +#define DAVINCI_VC_CTRL_RD_UNSIGNED BIT(5) > +#define DAVINCI_VC_CTRL_WD_BITS_8 BIT(6) > +#define DAVINCI_VC_CTRL_WD_UNSIGNED BIT(7) > +#define DAVINCI_VC_CTRL_RFIFOEN BIT(8) > +#define DAVINCI_VC_CTRL_RFIFOCL BIT(9) > +#define DAVINCI_VC_CTRL_RFIFOMD_WORD_1 BIT(10) > +#define DAVINCI_VC_CTRL_WFIFOEN BIT(12) > +#define DAVINCI_VC_CTRL_WFIFOCL BIT(13) > +#define DAVINCI_VC_CTRL_WFIFOMD_WORD_1 BIT(14) > + > +/* DAVINCI_VC_INT bit fields */ > +#define DAVINCI_VC_INT_MASK 0x3F > +#define DAVINCI_VC_INT_RDRDY_MASK BIT(0) > +#define DAVINCI_VC_INT_RERROVF_MASK BIT(1) > +#define DAVINCI_VC_INT_RERRUDR_MASK BIT(2) > +#define DAVINCI_VC_INT_WDREQ_MASK BIT(3) > +#define DAVINCI_VC_INT_WERROVF_MASKBIT BIT(4) > +#define DAVINCI_VC_INT_WERRUDR_MASK BIT(5) > + > +/* DAVINCI_VC_REG05 bit fields */ > +#define DAVINCI_VC_REG05_PGA_GAIN 0x07 > + > +/* DAVINCI_VC_REG09 bit fields */ > +#define DAVINCI_VC_REG09_MUTE 0x40 > +#define DAVINCI_VC_REG09_DIG_ATTEN 0x3F > + > +/* DAVINCI_VC_REG12 bit fields */ > +#define DAVINCI_VC_REG12_POWER_ALL_ON 0xFD > +#define DAVINCI_VC_REG12_POWER_ALL_OFF 0x00 > + > +#define DAVINCI_VC_CELLS 2 > + > +enum davinci_vc_cells { > + DAVINCI_VC_VCIF_CELL, > + DAVINCI_VC_CQ93VC_CELL, > +}; > + > +struct davinci_vcif { > + struct platform_device *pdev; > + u32 dma_tx_channel; > + u32 dma_rx_channel; > + dma_addr_t dma_tx_addr; > + dma_addr_t dma_rx_addr; > +}; > + > +struct cq93vc { > + struct platform_device *pdev; > + struct snd_soc_codec *codec; > + u32 sysclk; > +}; > + > +struct davinci_vc; > + > +struct davinci_vc { > + /* Device data */ > + struct device *dev; > + struct platform_device *pdev; > + struct clk *clk; > + > + /* Memory resources */ > + void __iomem *base; > + resource_size_t pbase; > + size_t base_size; > + > + /* MFD cells */ > + struct mfd_cell cells[DAVINCI_VC_CELLS]; > + > + /* Client devices */ > + struct davinci_vcif davinci_vcif; > + struct cq93vc cq93vc; > +}; > + > +#endif > -- > 1.6.0.4 > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > -- www.opensurf.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From broonie at opensource.wolfsonmicro.com Fri Mar 12 05:22:54 2010 From: broonie at opensource.wolfsonmicro.com (Mark Brown) Date: Fri, 12 Mar 2010 11:22:54 +0000 Subject: [alsa-devel] [PATCH v2 1/5] MFD: DaVinci Voice Codec In-Reply-To: <9FFC5872-87B8-452E-B85C-D029B4F67E5B@opensource.wolfsonmicro.com> References: <1268321541-18922-1-git-send-email-miguel.aguilar@ridgerun.com> <1268380916.3755.4.camel@odin> <9FFC5872-87B8-452E-B85C-D029B4F67E5B@opensource.wolfsonmicro.com> Message-ID: <20100312112254.GB23739@sirena.org.uk> On Fri, Mar 12, 2010 at 08:13:25AM +0000, Mark Brown wrote: > On 12 Mar 2010, at 08:01, Liam Girdwood wrote: > > On Thu, 2010-03-11 at 09:32 -0600, miguel.aguilar at ridgerun.com wrote: > >> This is the MFD driver for the DaVinci Voice codec, it has two > >> clients: > >> * Voice codec interface > >> * Voice codec CQ93VC > >> Signed-off-by: Miguel Aguilar > > Please CC the MFD maintainer too for this one. > Or if, as is the case here IIRC, they've already acked it include > their ack in repostings. I've found Samuel's previous ack so I've applied the series now - the issue with the capabilities not covering everything the hw_params do that Liam identified can be addressed with an incremental patch. Thanks! From sudhakar.raj at ti.com Fri Mar 12 06:34:09 2010 From: sudhakar.raj at ti.com (Sudhakar Rajashekhara) Date: Fri, 12 Mar 2010 18:04:09 +0530 Subject: [PATCH v2] davinci: MMC: Pass number of SG segments as platform data Message-ID: <1268397249-7654-1-git-send-email-sudhakar.raj@ti.com> On some platforms like DM355, the number of EDMA parameter slots available for EDMA_SLOT_ANY usage are few. In such cases, if MMC/SD uses 16 slots for each instance of MMC controller, then the number of slots available for other modules will be very few. By passing the number of EDMA slots to be used in MMC driver from platform data, EDMA slots available for other purposes can be controlled. Signed-off-by: Sudhakar Rajashekhara --- Following are the modifications from the previous version: 1. Changed the type of nr_sg variable to u8 from u32. 2. 'if (pdata->nr_sg)' check was introduced before initializing host->nr_sg. arch/arm/mach-davinci/include/mach/mmc.h | 3 +++ drivers/mmc/host/davinci_mmc.c | 24 +++++++++++++++++------- 2 files changed, 20 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-davinci/include/mach/mmc.h b/arch/arm/mach-davinci/include/mach/mmc.h index 5a85e24..d4f1e96 100644 --- a/arch/arm/mach-davinci/include/mach/mmc.h +++ b/arch/arm/mach-davinci/include/mach/mmc.h @@ -22,6 +22,9 @@ struct davinci_mmc_config { /* Version of the MMC/SD controller */ u8 version; + + /* Number of sg segments */ + u8 nr_sg; }; void davinci_setup_mmc(int module, struct davinci_mmc_config *config); diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c index 3bd0ba2..547d29c 100644 --- a/drivers/mmc/host/davinci_mmc.c +++ b/drivers/mmc/host/davinci_mmc.c @@ -137,15 +137,15 @@ /* * One scatterlist dma "segment" is at most MAX_CCNT rw_threshold units, - * and we handle up to NR_SG segments. MMC_BLOCK_BOUNCE kicks in only + * and we handle up to MAX_NR_SG segments. MMC_BLOCK_BOUNCE kicks in only * for drivers with max_hw_segs == 1, making the segments bigger (64KB) - * than the page or two that's otherwise typical. NR_SG == 16 gives at - * least the same throughput boost, using EDMA transfer linkage instead - * of spending CPU time copying pages. + * than the page or two that's otherwise typical. nr_sg (passed from + * platform data) == 16 gives at least the same throughput boost, using + * EDMA transfer linkage instead of spending CPU time copying pages. */ #define MAX_CCNT ((1 << 16) - 1) -#define NR_SG 16 +#define MAX_NR_SG 16 static unsigned rw_threshold = 32; module_param(rw_threshold, uint, S_IRUGO); @@ -192,7 +192,7 @@ struct mmc_davinci_host { struct edmacc_param tx_template; struct edmacc_param rx_template; unsigned n_link; - u32 links[NR_SG - 1]; + u32 links[MAX_NR_SG - 1]; /* For PIO we walk scatterlists one segment at a time. */ unsigned int sg_len; @@ -202,6 +202,8 @@ struct mmc_davinci_host { u8 version; /* for ns in one cycle calculation */ unsigned ns_in_one_cycle; + /* Number of sg segments */ + u8 nr_sg; #ifdef CONFIG_CPU_FREQ struct notifier_block freq_transition; #endif @@ -568,6 +570,7 @@ davinci_release_dma_channels(struct mmc_davinci_host *host) static int __init davinci_acquire_dma_channels(struct mmc_davinci_host *host) { + u32 link_size; int r, i; /* Acquire master DMA write channel */ @@ -593,7 +596,8 @@ static int __init davinci_acquire_dma_channels(struct mmc_davinci_host *host) /* Allocate parameter RAM slots, which will later be bound to a * channel as needed to handle a scatterlist. */ - for (i = 0; i < ARRAY_SIZE(host->links); i++) { + link_size = min_t(unsigned, host->nr_sg, ARRAY_SIZE(host->links)); + for (i = 0; i < link_size; i++) { r = edma_alloc_slot(EDMA_CTLR(host->txdma), EDMA_SLOT_ANY); if (r < 0) { dev_dbg(mmc_dev(host->mmc), "dma PaRAM alloc --> %d\n", @@ -1202,6 +1206,12 @@ static int __init davinci_mmcsd_probe(struct platform_device *pdev) init_mmcsd_host(host); + if (pdata->nr_sg) + host->nr_sg = pdata->nr_sg - 1; + + if (host->nr_sg > MAX_NR_SG || !host->nr_sg) + host->nr_sg = MAX_NR_SG; + host->use_dma = use_dma; host->irq = irq; -- 1.5.6 From bniebuhr3 at gmail.com Fri Mar 12 08:20:57 2010 From: bniebuhr3 at gmail.com (Brian Niebuhr) Date: Fri, 12 Mar 2010 08:20:57 -0600 Subject: [PATCH 0/2] overhaul davinci spi driver to fix multiple errors Message-ID: <1268403659-20348-1-git-send-email-bniebuhr@efjohnson.com> INTRODUCTION I have been working on a custom OMAP-L138 board that has multiple spi devices (seven) on one controller. These devices have a wide range of transfer parameters (speed, phase, polarity, internal and gpio chip selects). During my testing I found multiple errors in the davinci spi driver as a result of this complex setup. The primary issues were: 1. There is a race condition due to the SPIBUF read busy-waits for slow devices 2. I found some DMA transfer length errors under some conditions 3. The chip select code caused extra byte transfers (with no chip select active) due to writes to SPIDAT1 4. Several issues prevented using multiple SPI devices, especially the DMA code, as disucussed previously on the davinci list. The fixes to these problems were not simple. I ended up making fairly large changes to the driver, and those changes are contained in these patches. The full list of changes follows. CHANGE LIST 1. davinci_spi_chipelect() now performs both activation and deactivation of chip selects. This lets spi_bitbang fully control chip select activation, as intended by the SPI API. 2. Chip select activation does not cause extra writes to the SPI bus 3. Chip select activation does not use SPIDEF for control. This change will also allow for implementation of inverted (active high) chip selects in the future. 4. Added back gpio chip select capability from the old driver 5. Fixed prescale calculation for non-integer fractions of spi clock 6. Allow specification of SPI transfer parameters on a per-device (instead of per-controller) basis 7. Allow specification of polled, interrupt-based, or DMA operation on a per-device basis 8. Allow DMA with when more than one device is connected 9. Combined pio and dma txrx_bufs functions into one since they share large parts of their functionality, and to simplify item (8). 10. Use only SPIFMT0 to allow more than 4 devices TESTING I have tested the driver using a custom SPI stress test on my OMAP-L138-based board with three devices connected. I have tested configurations with all three devices polled, all three interrupt-based, all three DMA, and a mixture. I have compiled with the davinci_all_defconfig, but I don't have EVMs for the other davinci platforms to test with. SUMMARY I realize that this is a very large patch, but I hope that it's not thrown out just because of its size. It does solve a lot of issues that should save a lot of people time down the road. I would appreciate any feedback from those who can test it out on other davinci EVMs. Brian Niebuhr (2): spi: overhaul davinci spi driver to correct multiple errors spi: modify davinci platform data for updated driver arch/arm/mach-davinci/board-dm355-evm.c | 10 + arch/arm/mach-davinci/board-dm355-leopard.c | 10 + arch/arm/mach-davinci/board-dm365-evm.c | 10 + arch/arm/mach-davinci/board-dm646x-evm.c | 12 + arch/arm/mach-davinci/dm355.c | 7 - arch/arm/mach-davinci/dm365.c | 7 - arch/arm/mach-davinci/dm646x.c | 7 - arch/arm/mach-davinci/include/mach/spi.h | 30 +- drivers/spi/davinci_spi.c | 1021 +++++++++++---------------- drivers/spi/davinci_spi.h | 53 +- 10 files changed, 495 insertions(+), 672 deletions(-) From bniebuhr3 at gmail.com Fri Mar 12 08:20:58 2010 From: bniebuhr3 at gmail.com (Brian Niebuhr) Date: Fri, 12 Mar 2010 08:20:58 -0600 Subject: [PATCH 1/2] spi: overhaul davinci spi driver to correct multiple errors In-Reply-To: <1268403659-20348-1-git-send-email-bniebuhr@efjohnson.com> References: <1268403659-20348-1-git-send-email-bniebuhr@efjohnson.com> Message-ID: <1268403659-20348-2-git-send-email-bniebuhr@efjohnson.com> This patch is a significant overhaul of the davinci spi controller driver that corrects multiple errors: - Eliminate a race condition that exists for slow SPI devices - Fix DMA transfer length error - Fix limitations preventing multiple SPI devices on the same controller Signed-off-by: Brian Niebuhr --- arch/arm/mach-davinci/include/mach/spi.h | 30 +- drivers/spi/davinci_spi.c | 1021 ++++++++++++------------------ drivers/spi/davinci_spi.h | 53 +- 3 files changed, 453 insertions(+), 651 deletions(-) diff --git a/arch/arm/mach-davinci/include/mach/spi.h b/arch/arm/mach-davinci/include/mach/spi.h index 7b54926..f88f1ec 100644 --- a/arch/arm/mach-davinci/include/mach/spi.h +++ b/arch/arm/mach-davinci/include/mach/spi.h @@ -34,18 +34,24 @@ enum { struct davinci_spi_platform_data { u8 version; u16 num_chipselect; - u32 wdelay; - u32 odd_parity; - u32 parity_enable; - u32 wait_enable; - u32 timer_disable; - u32 clk_internal; - u32 cs_hold; - u32 intr_level; - u32 poll_mode; - u32 use_dma; - u8 c2tdelay; - u8 t2cdelay; + u8 *chip_sel; +}; + +struct davinci_spi_config { + u32 odd_parity : 1; + u32 parity_enable : 1; + u32 intr_level : 1; + u32 io_type : 2; +#define SPI_IO_TYPE_INTR 0 +#define SPI_IO_TYPE_POLL 1 +#define SPI_IO_TYPE_DMA 2 + u32 bytes_per_word : 2; + u32 wdelay : 6; + u32 timer_disable : 1; + u8 c2t_delay; + u8 t2c_delay; + u8 t2e_delay; + u8 c2e_delay; }; #endif /* __ARCH_ARM_DAVINCI_SPI_H */ diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c index 956f617..eec2fe9 100644 --- a/drivers/spi/davinci_spi.c +++ b/drivers/spi/davinci_spi.c @@ -1,5 +1,6 @@ /* * Copyright (C) 2009 Texas Instruments. + * Copyright (C) 2010 EF Johnson Technologies * * 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 @@ -33,43 +34,45 @@ #include "davinci_spi.h" -static unsigned use_dma; - #define DAVINCI_SPI_NO_RESOURCE ((resource_size_t)-1) static void davinci_spi_rx_buf_u8(u32 data, struct davinci_spi *davinci_spi) { - u8 *rx = davinci_spi->rx; - - *rx++ = (u8)data; - davinci_spi->rx = rx; + if (davinci_spi->rx) { + u8 *rx = davinci_spi->rx; + *rx++ = (u8)data; + davinci_spi->rx = rx; + } } static void davinci_spi_rx_buf_u16(u32 data, struct davinci_spi *davinci_spi) { - u16 *rx = davinci_spi->rx; - - *rx++ = (u16)data; - davinci_spi->rx = rx; + if (davinci_spi->rx) { + u16 *rx = davinci_spi->rx; + *rx++ = (u16)data; + davinci_spi->rx = rx; + } } static u32 davinci_spi_tx_buf_u8(struct davinci_spi *davinci_spi) { - u32 data; - const u8 *tx = davinci_spi->tx; - - data = *tx++; - davinci_spi->tx = tx; + u32 data = 0; + if (davinci_spi->tx) { + const u8 *tx = davinci_spi->tx; + data = *tx++; + davinci_spi->tx = tx; + } return data; } static u32 davinci_spi_tx_buf_u16(struct davinci_spi *davinci_spi) { - u32 data; - const u16 *tx = davinci_spi->tx; - - data = *tx++; - davinci_spi->tx = tx; + u32 data = 0; + if (davinci_spi->tx) { + const u16 *tx = davinci_spi->tx; + data = *tx++; + davinci_spi->tx = tx; + } return data; } @@ -89,26 +92,6 @@ static inline void clear_io_bits(void __iomem *addr, u32 bits) iowrite32(v, addr); } -static inline void set_fmt_bits(void __iomem *addr, u32 bits, int cs_num) -{ - set_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits); -} - -static inline void clear_fmt_bits(void __iomem *addr, u32 bits, int cs_num) -{ - clear_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits); -} - -static void davinci_spi_set_dma_req(const struct spi_device *spi, int enable) -{ - struct davinci_spi *davinci_spi = spi_master_get_devdata(spi->master); - - if (enable) - set_io_bits(davinci_spi->base + SPIINT, SPIINT_DMA_REQ_EN); - else - clear_io_bits(davinci_spi->base + SPIINT, SPIINT_DMA_REQ_EN); -} - /* * Interface to control the chip select signal */ @@ -116,25 +99,54 @@ static void davinci_spi_chipselect(struct spi_device *spi, int value) { struct davinci_spi *davinci_spi; struct davinci_spi_platform_data *pdata; - u32 data1_reg_val = 0; + u8 i, chip_sel = spi->chip_select; + u32 spidat1; + u16 spidat1_cfg; davinci_spi = spi_master_get_devdata(spi->master); pdata = davinci_spi->pdata; - /* - * Board specific chip select logic decides the polarity and cs - * line for the controller - */ - if (value == BITBANG_CS_INACTIVE) { - set_io_bits(davinci_spi->base + SPIDEF, CS_DEFAULT); - - data1_reg_val |= CS_DEFAULT << SPIDAT1_CSNR_SHIFT; - iowrite32(data1_reg_val, davinci_spi->base + SPIDAT1); + spidat1 = SPIDAT1_CSNR_MASK; + if (value == BITBANG_CS_ACTIVE) + spidat1 |= SPIDAT1_CSHOLD_MASK; + else + spidat1 |= SPIDAT1_WDEL_MASK; + + if (pdata->chip_sel == NULL) { + if (value == BITBANG_CS_ACTIVE) + spidat1 &= ~((0x1 << chip_sel) << SPIDAT1_CSNR_SHIFT); + } else { + for (i = 0; i < pdata->num_chipselect; i++) { + if (pdata->chip_sel[i] == SPI_INTERN_CS) { + if ((i == chip_sel) && + (value == BITBANG_CS_ACTIVE)) { + spidat1 &= ~((0x1 << chip_sel) + << SPIDAT1_CSNR_SHIFT); + } + } else { + if (value == BITBANG_CS_INACTIVE) + gpio_set_value(pdata->chip_sel[i], 1); + else if (i == chip_sel) + gpio_set_value(pdata->chip_sel[i], 0); + } + } + } + + spidat1_cfg = spidat1 >> SPIDAT1_CSNR_SHIFT; + iowrite16(spidat1_cfg, davinci_spi->base + SPIDAT1 + 2); +} - while ((ioread32(davinci_spi->base + SPIBUF) - & SPIBUF_RXEMPTY_MASK) == 0) - cpu_relax(); - } +/* + * davinci_spi_get_prescale - Calculates the correct prescale value + * @max_speed_hz: the maximum rate the SPI clock can run at + * + * This function calculates the prescale value that generates a clock rate + * less than or equal to the specified maximum + */ +static inline u32 davinci_spi_get_prescale(struct davinci_spi *davinci_spi, + u32 max_speed_hz) +{ + return ((clk_get_rate(davinci_spi->clk) - 1) / max_speed_hz) & 0xff; } /* @@ -149,14 +161,15 @@ static void davinci_spi_chipselect(struct spi_device *spi, int value) static int davinci_spi_setup_transfer(struct spi_device *spi, struct spi_transfer *t) { - - struct davinci_spi *davinci_spi; - struct davinci_spi_platform_data *pdata; - u8 bits_per_word = 0; - u32 hz = 0, prescale; + struct davinci_spi *davinci_spi; + struct davinci_spi_platform_data *pdata; + struct davinci_spi_config* spi_cfg; + u8 bits_per_word = 0; + u32 hz = 0, spifmt = 0, prescale, delay = 0; davinci_spi = spi_master_get_devdata(spi->master); pdata = davinci_spi->pdata; + spi_cfg = spi->controller_data; if (t) { bits_per_word = t->bits_per_word; @@ -174,72 +187,112 @@ static int davinci_spi_setup_transfer(struct spi_device *spi, if (bits_per_word <= 8 && bits_per_word >= 2) { davinci_spi->get_rx = davinci_spi_rx_buf_u8; davinci_spi->get_tx = davinci_spi_tx_buf_u8; - davinci_spi->slave[spi->chip_select].bytes_per_word = 1; + spi_cfg->bytes_per_word = 1; } else if (bits_per_word <= 16 && bits_per_word >= 2) { davinci_spi->get_rx = davinci_spi_rx_buf_u16; davinci_spi->get_tx = davinci_spi_tx_buf_u16; - davinci_spi->slave[spi->chip_select].bytes_per_word = 2; + spi_cfg->bytes_per_word = 2; } else return -EINVAL; if (!hz) hz = spi->max_speed_hz; - clear_fmt_bits(davinci_spi->base, SPIFMT_CHARLEN_MASK, - spi->chip_select); - set_fmt_bits(davinci_spi->base, bits_per_word & 0x1f, - spi->chip_select); + prescale = davinci_spi_get_prescale(davinci_spi, hz); + spifmt |= (prescale << SPIFMT_PRESCALE_SHIFT); + + spifmt |= (bits_per_word & 0x1f); + + if (spi->mode & SPI_LSB_FIRST) + spifmt |= SPIFMT_SHIFTDIR_MASK; + + if (spi->mode & SPI_CPOL) + spifmt |= SPIFMT_POLARITY_MASK; + + if (!(spi->mode & SPI_CPHA)) + spifmt |= SPIFMT_PHASE_MASK; + + if (davinci_spi->version == SPI_VERSION_2) { + spifmt |= ((spi_cfg->wdelay << SPIFMT_WDELAY_SHIFT) + & SPIFMT_WDELAY_MASK); + + if (spi_cfg->odd_parity) + spifmt |= SPIFMT_ODD_PARITY_MASK; - prescale = ((clk_get_rate(davinci_spi->clk) / hz) - 1) & 0xff; + if (spi_cfg->parity_enable) + spifmt |= SPIFMT_PARITYENA_MASK; - clear_fmt_bits(davinci_spi->base, 0x0000ff00, spi->chip_select); - set_fmt_bits(davinci_spi->base, prescale << 8, spi->chip_select); + if (spi->mode & SPI_READY) { + spifmt |= SPIFMT_WAITENA_MASK; + delay |= (spi_cfg->t2e_delay + << SPIDELAY_T2EDELAY_SHIFT) + & SPIDELAY_T2EDELAY_MASK; + delay |= (spi_cfg->c2e_delay + << SPIDELAY_C2EDELAY_SHIFT) + & SPIDELAY_C2EDELAY_MASK; + } + + if (spi_cfg->timer_disable) { + spifmt |= SPIFMT_DISTIMER_MASK; + } else { + delay |= (spi_cfg->c2t_delay + << SPIDELAY_C2TDELAY_SHIFT) + & SPIDELAY_C2TDELAY_MASK; + delay |= (spi_cfg->t2c_delay + << SPIDELAY_T2CDELAY_SHIFT) + & SPIDELAY_T2CDELAY_MASK; + } + + iowrite32(delay, davinci_spi->base + SPIDELAY); + } + + iowrite32(spifmt, davinci_spi->base + SPIFMT0); + + if (spi_cfg->intr_level) + iowrite32(SPI_INTLVL_1, davinci_spi->base + SPILVL); + else + iowrite32(SPI_INTLVL_0, davinci_spi->base + SPILVL); + + if (spi->mode & SPI_LOOP) + set_io_bits(davinci_spi->base + SPIGCR1, + SPIGCR1_LOOPBACK_MASK); + else + clear_io_bits(davinci_spi->base + SPIGCR1, + SPIGCR1_LOOPBACK_MASK); return 0; } static void davinci_spi_dma_rx_callback(unsigned lch, u16 ch_status, void *data) { - struct spi_device *spi = (struct spi_device *)data; - struct davinci_spi *davinci_spi; + struct davinci_spi *davinci_spi = (struct davinci_spi *)data; struct davinci_spi_dma *davinci_spi_dma; struct davinci_spi_platform_data *pdata; - davinci_spi = spi_master_get_devdata(spi->master); - davinci_spi_dma = &(davinci_spi->dma_channels[spi->chip_select]); + davinci_spi_dma = &(davinci_spi->dma_channels); pdata = davinci_spi->pdata; - if (ch_status == DMA_COMPLETE) - edma_stop(davinci_spi_dma->dma_rx_channel); - else - edma_clean_channel(davinci_spi_dma->dma_rx_channel); + edma_stop(davinci_spi_dma->dma_rx_channel); - complete(&davinci_spi_dma->dma_rx_completion); - /* We must disable the DMA RX request */ - davinci_spi_set_dma_req(spi, 0); + if (ch_status == DMA_COMPLETE) + davinci_spi->rcount = 0; + complete(&davinci_spi->done); } static void davinci_spi_dma_tx_callback(unsigned lch, u16 ch_status, void *data) { - struct spi_device *spi = (struct spi_device *)data; - struct davinci_spi *davinci_spi; + struct davinci_spi *davinci_spi = (struct davinci_spi *)data; struct davinci_spi_dma *davinci_spi_dma; struct davinci_spi_platform_data *pdata; - davinci_spi = spi_master_get_devdata(spi->master); - davinci_spi_dma = &(davinci_spi->dma_channels[spi->chip_select]); + davinci_spi_dma = &(davinci_spi->dma_channels); pdata = davinci_spi->pdata; - if (ch_status == DMA_COMPLETE) - edma_stop(davinci_spi_dma->dma_tx_channel); - else - edma_clean_channel(davinci_spi_dma->dma_tx_channel); - - complete(&davinci_spi_dma->dma_tx_completion); - /* We must disable the DMA TX request */ - davinci_spi_set_dma_req(spi, 0); + edma_stop(davinci_spi_dma->dma_tx_channel); + if (ch_status == DMA_COMPLETE) + davinci_spi->wcount = 0; } static int davinci_spi_request_dma(struct spi_device *spi) @@ -251,30 +304,51 @@ static int davinci_spi_request_dma(struct spi_device *spi) int r; davinci_spi = spi_master_get_devdata(spi->master); - davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select]; + davinci_spi_dma = &davinci_spi->dma_channels; pdata = davinci_spi->pdata; sdev = davinci_spi->bitbang.master->dev.parent; r = edma_alloc_channel(davinci_spi_dma->dma_rx_sync_dev, - davinci_spi_dma_rx_callback, spi, + davinci_spi_dma_rx_callback, davinci_spi, davinci_spi_dma->eventq); if (r < 0) { dev_dbg(sdev, "Unable to request DMA channel for MibSPI RX\n"); - return -EAGAIN; + r = -EAGAIN; + goto rx_dma_failed; } davinci_spi_dma->dma_rx_channel = r; + r = edma_alloc_channel(davinci_spi_dma->dma_tx_sync_dev, - davinci_spi_dma_tx_callback, spi, + davinci_spi_dma_tx_callback, davinci_spi, davinci_spi_dma->eventq); if (r < 0) { - edma_free_channel(davinci_spi_dma->dma_rx_channel); - davinci_spi_dma->dma_rx_channel = -1; dev_dbg(sdev, "Unable to request DMA channel for MibSPI TX\n"); - return -EAGAIN; + r = -EAGAIN; + goto tx_dma_failed; } davinci_spi_dma->dma_tx_channel = r; + r = edma_alloc_slot(EDMA_CTLR(davinci_spi_dma->dma_tx_sync_dev), + EDMA_SLOT_ANY); + if (r < 0) { + dev_dbg(sdev, "Unable to request SPI DMA param slot\n"); + r = -EAGAIN; + goto param_failed; + } + davinci_spi_dma->dummy_param_slot = r; + edma_link(davinci_spi_dma->dummy_param_slot, + davinci_spi_dma->dummy_param_slot); + return 0; + +param_failed: + edma_free_channel(davinci_spi_dma->dma_tx_channel); + davinci_spi_dma->dma_tx_channel = -1; +tx_dma_failed: + edma_free_channel(davinci_spi_dma->dma_rx_channel); + davinci_spi_dma->dma_rx_channel = -1; +rx_dma_failed: + return r; } /* @@ -286,124 +360,51 @@ static int davinci_spi_request_dma(struct spi_device *spi) static int davinci_spi_setup(struct spi_device *spi) { - int retval; + int retval = 0; struct davinci_spi *davinci_spi; - struct davinci_spi_dma *davinci_spi_dma; + struct davinci_spi_dma *davinci_dma; + struct davinci_spi_platform_data *pdata; + struct davinci_spi_config *spi_cfg; + u32 prescale; davinci_spi = spi_master_get_devdata(spi->master); + pdata = davinci_spi->pdata; + spi_cfg = (struct davinci_spi_config *)spi->controller_data; + davinci_dma = &(davinci_spi->dma_channels); /* if bits per word length is zero then set it default 8 */ if (!spi->bits_per_word) spi->bits_per_word = 8; - davinci_spi->slave[spi->chip_select].cmd_to_write = 0; + if (!(spi->mode & SPI_NO_CS)) { + if ((pdata->chip_sel == NULL) || + (pdata->chip_sel[spi->chip_select] == SPI_INTERN_CS)) + set_io_bits(davinci_spi->base + SPIPC0, + 1 << spi->chip_select); - if (use_dma && davinci_spi->dma_channels) { - davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select]; - - if ((davinci_spi_dma->dma_rx_channel == -1) - || (davinci_spi_dma->dma_tx_channel == -1)) { - retval = davinci_spi_request_dma(spi); - if (retval < 0) - return retval; - } } - /* - * SPI in DaVinci and DA8xx operate between - * 600 KHz and 50 MHz - */ - if (spi->max_speed_hz < 600000 || spi->max_speed_hz > 50000000) - return -EINVAL; - - /* - * Set up SPIFMTn register, unique to this chipselect. - * - * NOTE: we could do all of these with one write. Also, some - * of the "version 2" features are found in chips that don't - * support all of them... - */ - if (spi->mode & SPI_LSB_FIRST) - set_fmt_bits(davinci_spi->base, SPIFMT_SHIFTDIR_MASK, - spi->chip_select); - else - clear_fmt_bits(davinci_spi->base, SPIFMT_SHIFTDIR_MASK, - spi->chip_select); + if (spi->mode & SPI_READY) + set_io_bits(davinci_spi->base + SPIPC0, SPIPC0_SPIENA_MASK); - if (spi->mode & SPI_CPOL) - set_fmt_bits(davinci_spi->base, SPIFMT_POLARITY_MASK, - spi->chip_select); - else - clear_fmt_bits(davinci_spi->base, SPIFMT_POLARITY_MASK, - spi->chip_select); + if (spi_cfg->io_type == SPI_IO_TYPE_DMA) { + davinci_dma = &(davinci_spi->dma_channels); - if (!(spi->mode & SPI_CPHA)) - set_fmt_bits(davinci_spi->base, SPIFMT_PHASE_MASK, - spi->chip_select); - else - clear_fmt_bits(davinci_spi->base, SPIFMT_PHASE_MASK, - spi->chip_select); + if ((davinci_dma->dma_tx_sync_dev == DAVINCI_SPI_NO_RESOURCE) || + (davinci_dma->dma_rx_sync_dev == DAVINCI_SPI_NO_RESOURCE) || + (davinci_dma->eventq == DAVINCI_SPI_NO_RESOURCE)) + spi_cfg->io_type = SPI_IO_TYPE_INTR; + else if ((davinci_dma->dma_rx_channel == -1) || + (davinci_dma->dma_tx_channel == -1)) + retval = davinci_spi_request_dma(spi); + } /* - * Version 1 hardware supports two basic SPI modes: - * - Standard SPI mode uses 4 pins, with chipselect - * - 3 pin SPI is a 4 pin variant without CS (SPI_NO_CS) - * (distinct from SPI_3WIRE, with just one data wire; - * or similar variants without MOSI or without MISO) - * - * Version 2 hardware supports an optional handshaking signal, - * so it can support two more modes: - * - 5 pin SPI variant is standard SPI plus SPI_READY - * - 4 pin with enable is (SPI_READY | SPI_NO_CS) + * Validate desired clock rate */ - - if (davinci_spi->version == SPI_VERSION_2) { - clear_fmt_bits(davinci_spi->base, SPIFMT_WDELAY_MASK, - spi->chip_select); - set_fmt_bits(davinci_spi->base, - (davinci_spi->pdata->wdelay - << SPIFMT_WDELAY_SHIFT) - & SPIFMT_WDELAY_MASK, - spi->chip_select); - - if (davinci_spi->pdata->odd_parity) - set_fmt_bits(davinci_spi->base, - SPIFMT_ODD_PARITY_MASK, - spi->chip_select); - else - clear_fmt_bits(davinci_spi->base, - SPIFMT_ODD_PARITY_MASK, - spi->chip_select); - - if (davinci_spi->pdata->parity_enable) - set_fmt_bits(davinci_spi->base, - SPIFMT_PARITYENA_MASK, - spi->chip_select); - else - clear_fmt_bits(davinci_spi->base, - SPIFMT_PARITYENA_MASK, - spi->chip_select); - - if (davinci_spi->pdata->wait_enable) - set_fmt_bits(davinci_spi->base, - SPIFMT_WAITENA_MASK, - spi->chip_select); - else - clear_fmt_bits(davinci_spi->base, - SPIFMT_WAITENA_MASK, - spi->chip_select); - - if (davinci_spi->pdata->timer_disable) - set_fmt_bits(davinci_spi->base, - SPIFMT_DISTIMER_MASK, - spi->chip_select); - else - clear_fmt_bits(davinci_spi->base, - SPIFMT_DISTIMER_MASK, - spi->chip_select); - } - - retval = davinci_spi_setup_transfer(spi, NULL); + prescale = davinci_spi_get_prescale(davinci_spi, spi->max_speed_hz); + if ((prescale < 2) || (prescale > 255)) + return -EINVAL; return retval; } @@ -412,50 +413,19 @@ static void davinci_spi_cleanup(struct spi_device *spi) { struct davinci_spi *davinci_spi = spi_master_get_devdata(spi->master); struct davinci_spi_dma *davinci_spi_dma; + struct davinci_spi_platform_data *pdata; - davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select]; - - if (use_dma && davinci_spi->dma_channels) { - davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select]; - - if ((davinci_spi_dma->dma_rx_channel != -1) - && (davinci_spi_dma->dma_tx_channel != -1)) { - edma_free_channel(davinci_spi_dma->dma_tx_channel); - edma_free_channel(davinci_spi_dma->dma_rx_channel); - } - } -} - -static int davinci_spi_bufs_prep(struct spi_device *spi, - struct davinci_spi *davinci_spi) -{ - int op_mode = 0; - - /* - * REVISIT unless devices disagree about SPI_LOOP or - * SPI_READY (SPI_NO_CS only allows one device!), this - * should not need to be done before each message... - * optimize for both flags staying cleared. - */ - - op_mode = SPIPC0_DIFUN_MASK - | SPIPC0_DOFUN_MASK - | SPIPC0_CLKFUN_MASK; - if (!(spi->mode & SPI_NO_CS)) - op_mode |= 1 << spi->chip_select; - if (spi->mode & SPI_READY) - op_mode |= SPIPC0_SPIENA_MASK; + davinci_spi_dma = &davinci_spi->dma_channels; + pdata = davinci_spi->pdata; - iowrite32(op_mode, davinci_spi->base + SPIPC0); + if (davinci_spi_dma->dma_rx_channel != -1) + edma_free_channel(davinci_spi_dma->dma_rx_channel); - if (spi->mode & SPI_LOOP) - set_io_bits(davinci_spi->base + SPIGCR1, - SPIGCR1_LOOPBACK_MASK); - else - clear_io_bits(davinci_spi->base + SPIGCR1, - SPIGCR1_LOOPBACK_MASK); + if (davinci_spi_dma->dma_tx_channel != -1) + edma_free_channel(davinci_spi_dma->dma_tx_channel); - return 0; + if (davinci_spi_dma->dummy_param_slot != -1) + edma_free_slot(davinci_spi_dma->dummy_param_slot); } static int davinci_spi_check_error(struct davinci_spi *davinci_spi, @@ -503,7 +473,52 @@ static int davinci_spi_check_error(struct davinci_spi *davinci_spi, } /* - * davinci_spi_bufs - functions which will handle transfer data + * davinci_spi_process_events - check for and handle any SPI controller events + * @davinci_spi - the controller data + * + * This function will check the SPIFLG register and handle any events that are + * detected there + */ +static int davinci_spi_process_events(struct davinci_spi *davinci_spi) +{ + u32 status, tx_data, rx_data, spidat1; + u8 tx_word = 0; + + status = ioread32(davinci_spi->base + SPIFLG); + + if ((davinci_spi->version == SPI_VERSION_2) && + (likely(status & SPIFLG_TX_INTR_MASK)) && + (likely(davinci_spi->wcount > 0))) + tx_word = 1; + + if (likely(status & SPIFLG_RX_INTR_MASK)) { + rx_data = ioread32(davinci_spi->base + SPIBUF) & 0xFFFF; + davinci_spi->get_rx(rx_data, davinci_spi); + davinci_spi->rcount--; + if ((davinci_spi->version != SPI_VERSION_2) && + (likely(davinci_spi->wcount > 0))) + tx_word = 1; + } + + if (unlikely(status & SPIFLG_ERROR_MASK)) { + davinci_spi->errors = (status & SPIFLG_ERROR_MASK); + return -1; + } + + if (likely(tx_word)) { + spidat1 = ioread32(davinci_spi->base + SPIDAT1); + davinci_spi->wcount--; + tx_data = davinci_spi->get_tx(davinci_spi); + spidat1 &= 0xFFFF0000; + spidat1 |= (tx_data & 0xFFFF); + iowrite32(spidat1, davinci_spi->base + SPIDAT1); + } + + return 0; +} + +/* + * davinci_spi_txrx_bufs - function which will handle transfer data * @spi: spi device on which data transfer to be done * @t: spi transfer in which transfer info is filled * @@ -511,323 +526,140 @@ static int davinci_spi_check_error(struct davinci_spi *davinci_spi, * of SPI controller and then wait until the completion will be marked * by the IRQ Handler. */ -static int davinci_spi_bufs_pio(struct spi_device *spi, struct spi_transfer *t) -{ - struct davinci_spi *davinci_spi; - int int_status, count, ret; - u8 conv, tmp; - u32 tx_data, data1_reg_val; - u32 buf_val, flg_val; - struct davinci_spi_platform_data *pdata; - - davinci_spi = spi_master_get_devdata(spi->master); - pdata = davinci_spi->pdata; - - davinci_spi->tx = t->tx_buf; - davinci_spi->rx = t->rx_buf; - - /* convert len to words bbased on bits_per_word */ - conv = davinci_spi->slave[spi->chip_select].bytes_per_word; - davinci_spi->count = t->len / conv; - - INIT_COMPLETION(davinci_spi->done); - - ret = davinci_spi_bufs_prep(spi, davinci_spi); - if (ret) - return ret; - - /* Enable SPI */ - set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_SPIENA_MASK); - - iowrite32(0 | (pdata->c2tdelay << SPI_C2TDELAY_SHIFT) | - (pdata->t2cdelay << SPI_T2CDELAY_SHIFT), - davinci_spi->base + SPIDELAY); - - count = davinci_spi->count; - data1_reg_val = pdata->cs_hold << SPIDAT1_CSHOLD_SHIFT; - tmp = ~(0x1 << spi->chip_select); - - clear_io_bits(davinci_spi->base + SPIDEF, ~tmp); - - data1_reg_val |= tmp << SPIDAT1_CSNR_SHIFT; - - while ((ioread32(davinci_spi->base + SPIBUF) - & SPIBUF_RXEMPTY_MASK) == 0) - cpu_relax(); - - /* Determine the command to execute READ or WRITE */ - if (t->tx_buf) { - clear_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKALL); - - while (1) { - tx_data = davinci_spi->get_tx(davinci_spi); - - data1_reg_val &= ~(0xFFFF); - data1_reg_val |= (0xFFFF & tx_data); - - buf_val = ioread32(davinci_spi->base + SPIBUF); - if ((buf_val & SPIBUF_TXFULL_MASK) == 0) { - iowrite32(data1_reg_val, - davinci_spi->base + SPIDAT1); - - count--; - } - while (ioread32(davinci_spi->base + SPIBUF) - & SPIBUF_RXEMPTY_MASK) - cpu_relax(); - - /* getting the returned byte */ - if (t->rx_buf) { - buf_val = ioread32(davinci_spi->base + SPIBUF); - davinci_spi->get_rx(buf_val, davinci_spi); - } - if (count <= 0) - break; - } - } else { - if (pdata->poll_mode) { - while (1) { - /* keeps the serial clock going */ - if ((ioread32(davinci_spi->base + SPIBUF) - & SPIBUF_TXFULL_MASK) == 0) - iowrite32(data1_reg_val, - davinci_spi->base + SPIDAT1); - - while (ioread32(davinci_spi->base + SPIBUF) & - SPIBUF_RXEMPTY_MASK) - cpu_relax(); - - flg_val = ioread32(davinci_spi->base + SPIFLG); - buf_val = ioread32(davinci_spi->base + SPIBUF); - - davinci_spi->get_rx(buf_val, davinci_spi); - - count--; - if (count <= 0) - break; - } - } else { /* Receive in Interrupt mode */ - int i; - - for (i = 0; i < davinci_spi->count; i++) { - set_io_bits(davinci_spi->base + SPIINT, - SPIINT_BITERR_INTR - | SPIINT_OVRRUN_INTR - | SPIINT_RX_INTR); - - iowrite32(data1_reg_val, - davinci_spi->base + SPIDAT1); - - while (ioread32(davinci_spi->base + SPIINT) & - SPIINT_RX_INTR) - cpu_relax(); - } - iowrite32((data1_reg_val & 0x0ffcffff), - davinci_spi->base + SPIDAT1); - } - } - - /* - * Check for bit error, desync error,parity error,timeout error and - * receive overflow errors - */ - int_status = ioread32(davinci_spi->base + SPIFLG); - - ret = davinci_spi_check_error(davinci_spi, int_status); - if (ret != 0) - return ret; - - /* SPI Framework maintains the count only in bytes so convert back */ - davinci_spi->count *= conv; - - return t->len; -} - -#define DAVINCI_DMA_DATA_TYPE_S8 0x01 -#define DAVINCI_DMA_DATA_TYPE_S16 0x02 -#define DAVINCI_DMA_DATA_TYPE_S32 0x04 - -static int davinci_spi_bufs_dma(struct spi_device *spi, struct spi_transfer *t) +static int davinci_spi_txrx_bufs(struct spi_device *spi, struct spi_transfer *t) { - struct davinci_spi *davinci_spi; - int int_status = 0; - int count; - u8 conv = 1; - u8 tmp; - u32 data1_reg_val; - struct davinci_spi_dma *davinci_spi_dma; - int word_len, data_type, ret; - unsigned long tx_reg, rx_reg; - struct davinci_spi_platform_data *pdata; + struct davinci_spi *davinci_spi; + int data_type, ret = 0; + u32 tx_data, spidat1; + u16 tx_buf_count = 0, rx_buf_count = 0; + struct davinci_spi_config *spi_cfg; + struct davinci_spi_platform_data *pdata; + struct davinci_spi_dma *davinci_dma; struct device *sdev; + dma_addr_t tx_reg, rx_reg; + void *tx_buf, *rx_buf; + struct edmacc_param rx_param, tx_param; - davinci_spi = spi_master_get_devdata(spi->master); - pdata = davinci_spi->pdata; - sdev = davinci_spi->bitbang.master->dev.parent; - - BUG_ON(davinci_spi->dma_channels == NULL); - - davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select]; + davinci_spi = spi_master_get_devdata(spi->master); + pdata = davinci_spi->pdata; + spi_cfg = (struct davinci_spi_config *)spi->controller_data; + davinci_dma = &(davinci_spi->dma_channels); - tx_reg = (unsigned long)davinci_spi->pbase + SPIDAT1; - rx_reg = (unsigned long)davinci_spi->pbase + SPIBUF; + davinci_spi->tx = t->tx_buf; + davinci_spi->rx = t->rx_buf; + davinci_spi->wcount = t->len / spi_cfg->bytes_per_word; + davinci_spi->rcount = davinci_spi->wcount; + davinci_spi->errors = 0; - /* used for macro defs */ - davinci_spi->tx = t->tx_buf; - davinci_spi->rx = t->rx_buf; + spidat1 = ioread32(davinci_spi->base + SPIDAT1); - /* convert len to words based on bits_per_word */ - conv = davinci_spi->slave[spi->chip_select].bytes_per_word; - davinci_spi->count = t->len / conv; + clear_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_POWERDOWN_MASK); + set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_SPIENA_MASK); INIT_COMPLETION(davinci_spi->done); - init_completion(&davinci_spi_dma->dma_rx_completion); - init_completion(&davinci_spi_dma->dma_tx_completion); - - word_len = conv * 8; - - if (word_len <= 8) - data_type = DAVINCI_DMA_DATA_TYPE_S8; - else if (word_len <= 16) - data_type = DAVINCI_DMA_DATA_TYPE_S16; - else if (word_len <= 32) - data_type = DAVINCI_DMA_DATA_TYPE_S32; - else - return -1; - - ret = davinci_spi_bufs_prep(spi, davinci_spi); - if (ret) - return ret; - - /* Put delay val if required */ - iowrite32(0 | (pdata->c2tdelay << SPI_C2TDELAY_SHIFT) | - (pdata->t2cdelay << SPI_T2CDELAY_SHIFT), - davinci_spi->base + SPIDELAY); - - count = davinci_spi->count; /* the number of elements */ - data1_reg_val = pdata->cs_hold << SPIDAT1_CSHOLD_SHIFT; - - /* CD default = 0xFF */ - tmp = ~(0x1 << spi->chip_select); - - clear_io_bits(davinci_spi->base + SPIDEF, ~tmp); - - data1_reg_val |= tmp << SPIDAT1_CSNR_SHIFT; - - /* disable all interrupts for dma transfers */ - clear_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKALL); - /* Disable SPI to write configuration bits in SPIDAT */ - clear_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_SPIENA_MASK); - iowrite32(data1_reg_val, davinci_spi->base + SPIDAT1); - /* Enable SPI */ - set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_SPIENA_MASK); - - while ((ioread32(davinci_spi->base + SPIBUF) - & SPIBUF_RXEMPTY_MASK) == 0) - cpu_relax(); - - - if (t->tx_buf != NULL) { - t->tx_dma = dma_map_single(&spi->dev, (void *)t->tx_buf, count, - DMA_TO_DEVICE); - if (dma_mapping_error(&spi->dev, t->tx_dma)) { - dev_dbg(sdev, "Couldn't DMA map a %d bytes TX buffer\n", - count); - return -1; + if ((spi_cfg->io_type == SPI_IO_TYPE_INTR) || + (spi_cfg->io_type == SPI_IO_TYPE_POLL)) { + + if (spi_cfg->io_type == SPI_IO_TYPE_INTR) + set_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKINT); + + /* start the transfer */ + davinci_spi->wcount--; + tx_data = davinci_spi->get_tx(davinci_spi); + spidat1 &= 0xFFFF0000; + spidat1 |= (tx_data & 0xFFFF); + iowrite32(spidat1, davinci_spi->base + SPIDAT1); + + } else if (spi_cfg->io_type == SPI_IO_TYPE_DMA) { + data_type = spi_cfg->bytes_per_word; + tx_reg = (dma_addr_t)davinci_spi->pbase + SPIDAT1; + rx_reg = (dma_addr_t)davinci_spi->pbase + SPIBUF; + + if (t->tx_buf) { + tx_buf = ((void *)t->tx_buf); + tx_buf_count = davinci_spi->wcount; + } else { + tx_buf = (void *)davinci_spi->tmp_buf; + tx_buf_count = SPI_BUFSIZ; } - edma_set_transfer_params(davinci_spi_dma->dma_tx_channel, data_type, - count, 1, 0, ASYNC); - edma_set_dest(davinci_spi_dma->dma_tx_channel, - tx_reg, INCR, W8BIT); - edma_set_src(davinci_spi_dma->dma_tx_channel, - t->tx_dma, INCR, W8BIT); - edma_set_src_index(davinci_spi_dma->dma_tx_channel, data_type, 0); - edma_set_dest_index(davinci_spi_dma->dma_tx_channel, 0, 0); - } else { - /* We need TX clocking for RX transaction */ - t->tx_dma = dma_map_single(&spi->dev, - (void *)davinci_spi->tmp_buf, count + 1, - DMA_TO_DEVICE); - if (dma_mapping_error(&spi->dev, t->tx_dma)) { - dev_dbg(sdev, "Couldn't DMA map a %d bytes TX tmp buffer\n", - count); - return -1; + if (t->rx_buf) { + rx_buf = (void *)t->rx_buf; + rx_buf_count = davinci_spi->rcount; + } else { + rx_buf = (void *)davinci_spi->tmp_buf; + rx_buf_count = SPI_BUFSIZ; } - edma_set_transfer_params(davinci_spi_dma->dma_tx_channel, - data_type, count + 1, 1, 0, ASYNC); - edma_set_dest(davinci_spi_dma->dma_tx_channel, tx_reg, - INCR, W8BIT); - edma_set_src(davinci_spi_dma->dma_tx_channel, - t->tx_dma, INCR, W8BIT); - edma_set_src_index(davinci_spi_dma->dma_tx_channel, - data_type, 0); - edma_set_dest_index(davinci_spi_dma->dma_tx_channel, 0, 0); + + t->tx_dma = dma_map_single(&spi->dev, tx_buf, + tx_buf_count, DMA_TO_DEVICE); + t->rx_dma = dma_map_single(&spi->dev, rx_buf, + rx_buf_count, DMA_FROM_DEVICE); + + tx_param.opt = TCINTEN | EDMA_TCC(davinci_dma->dma_tx_channel); + tx_param.src = t->tx_buf ? t->tx_dma : tx_reg; + tx_param.a_b_cnt = davinci_spi->wcount << 16 | data_type; + tx_param.dst = tx_reg; + tx_param.src_dst_bidx = t->tx_buf ? data_type : 0; + tx_param.link_bcntrld = 0xffff; + tx_param.src_dst_cidx = 0; + tx_param.ccnt = 1; + edma_write_slot(davinci_dma->dma_tx_channel, &tx_param); + edma_link(davinci_dma->dma_tx_channel, + davinci_dma->dummy_param_slot); + + rx_param.opt = TCINTEN | EDMA_TCC(davinci_dma->dma_rx_channel); + rx_param.src = rx_reg; + rx_param.a_b_cnt = davinci_spi->rcount << 16 | data_type; + rx_param.dst = t->rx_dma; + rx_param.src_dst_bidx = (t->rx_buf ? data_type : 0) << 16; + rx_param.link_bcntrld = 0xffff; + rx_param.src_dst_cidx = 0; + rx_param.ccnt = 1; + edma_write_slot(davinci_dma->dma_rx_channel, &rx_param); + + iowrite16(spidat1 >> SPIDAT1_CSNR_SHIFT, + davinci_spi->base + SPIDAT1 + 2); + + edma_start(davinci_dma->dma_rx_channel); + edma_start(davinci_dma->dma_tx_channel); + set_io_bits(davinci_spi->base + SPIINT, SPIINT_DMA_REQ_EN); } - if (t->rx_buf != NULL) { - /* initiate transaction */ - iowrite32(data1_reg_val, davinci_spi->base + SPIDAT1); - - t->rx_dma = dma_map_single(&spi->dev, (void *)t->rx_buf, count, - DMA_FROM_DEVICE); - if (dma_mapping_error(&spi->dev, t->rx_dma)) { - dev_dbg(sdev, "Couldn't DMA map a %d bytes RX buffer\n", - count); - if (t->tx_buf != NULL) - dma_unmap_single(NULL, t->tx_dma, - count, DMA_TO_DEVICE); - return -1; + /* Wait for the transfer to complete */ + if (spi_cfg->io_type != SPI_IO_TYPE_POLL) { + wait_for_completion_interruptible(&(davinci_spi->done)); + } + else { + while ((davinci_spi->rcount > 0) && (ret == 0)) { + ret = davinci_spi_process_events(davinci_spi); + cpu_relax(); } - edma_set_transfer_params(davinci_spi_dma->dma_rx_channel, data_type, - count, 1, 0, ASYNC); - edma_set_src(davinci_spi_dma->dma_rx_channel, - rx_reg, INCR, W8BIT); - edma_set_dest(davinci_spi_dma->dma_rx_channel, - t->rx_dma, INCR, W8BIT); - edma_set_src_index(davinci_spi_dma->dma_rx_channel, 0, 0); - edma_set_dest_index(davinci_spi_dma->dma_rx_channel, data_type, 0); } - if ((t->tx_buf != NULL) || (t->rx_buf != NULL)) - edma_start(davinci_spi_dma->dma_tx_channel); - - if (t->rx_buf != NULL) - edma_start(davinci_spi_dma->dma_rx_channel); - - if ((t->rx_buf != NULL) || (t->tx_buf != NULL)) - davinci_spi_set_dma_req(spi, 1); - - if (t->tx_buf != NULL) - wait_for_completion_interruptible( - &davinci_spi_dma->dma_tx_completion); - - if (t->rx_buf != NULL) - wait_for_completion_interruptible( - &davinci_spi_dma->dma_rx_completion); - - if (t->tx_buf != NULL) - dma_unmap_single(NULL, t->tx_dma, count, DMA_TO_DEVICE); - else - dma_unmap_single(NULL, t->tx_dma, count + 1, DMA_TO_DEVICE); - - if (t->rx_buf != NULL) - dma_unmap_single(NULL, t->rx_dma, count, DMA_FROM_DEVICE); - - /* - * Check for bit error, desync error,parity error,timeout error and - * receive overflow errors - */ - int_status = ioread32(davinci_spi->base + SPIFLG); - - ret = davinci_spi_check_error(davinci_spi, int_status); - if (ret != 0) - return ret; - - /* SPI Framework maintains the count only in bytes so convert back */ - davinci_spi->count *= conv; + clear_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKALL); + if (spi_cfg->io_type == SPI_IO_TYPE_DMA) { + dma_unmap_single(NULL, t->tx_dma, tx_buf_count, + DMA_TO_DEVICE); + dma_unmap_single(NULL, t->rx_dma, rx_buf_count, + DMA_FROM_DEVICE); + } - return t->len; + clear_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_SPIENA_MASK); + set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_POWERDOWN_MASK); + + if (davinci_spi->errors) { + ret = davinci_spi_check_error(davinci_spi, davinci_spi->errors); + if (ret != 0) + return ret; + } + if ((davinci_spi->rcount != 0) || (davinci_spi->wcount != 0)) { + sdev = davinci_spi->bitbang.master->dev.parent; + dev_info(sdev, "SPI data transfer error\n"); + return -EIO; + } + + return t->len; } /* @@ -844,28 +676,16 @@ static int davinci_spi_bufs_dma(struct spi_device *spi, struct spi_transfer *t) static irqreturn_t davinci_spi_irq(s32 irq, void *context_data) { struct davinci_spi *davinci_spi = context_data; - u32 int_status, rx_data = 0; - irqreturn_t ret = IRQ_NONE; + int status; - int_status = ioread32(davinci_spi->base + SPIFLG); + status = davinci_spi_process_events(davinci_spi); + if (unlikely(status != 0)) + clear_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKINT); - while ((int_status & SPIFLG_RX_INTR_MASK)) { - if (likely(int_status & SPIFLG_RX_INTR_MASK)) { - ret = IRQ_HANDLED; + if ((davinci_spi->rcount == 0) || (status != 0)) + complete(&(davinci_spi->done)); - rx_data = ioread32(davinci_spi->base + SPIBUF); - davinci_spi->get_rx(rx_data, davinci_spi); - - /* Disable Receive Interrupt */ - iowrite32(~(SPIINT_RX_INTR | SPIINT_TX_INTR), - davinci_spi->base + SPIINT); - } else - (void)davinci_spi_check_error(davinci_spi, int_status); - - int_status = ioread32(davinci_spi->base + SPIFLG); - } - - return ret; + return IRQ_HANDLED; } resource_size_t davinci_spi_get_dma_by_flag(struct platform_device *dev, @@ -906,6 +726,7 @@ static int davinci_spi_probe(struct platform_device *pdev) resource_size_t dma_tx_chan = DAVINCI_SPI_NO_RESOURCE; resource_size_t dma_eventq = DAVINCI_SPI_NO_RESOURCE; int i = 0, ret = 0; + u32 spipc0; pdata = pdev->dev.platform_data; if (pdata == NULL) { @@ -992,52 +813,23 @@ static int davinci_spi_probe(struct platform_device *pdev) davinci_spi->bitbang.chipselect = davinci_spi_chipselect; davinci_spi->bitbang.setup_transfer = davinci_spi_setup_transfer; + davinci_spi->bitbang.txrx_bufs = davinci_spi_txrx_bufs; davinci_spi->version = pdata->version; - use_dma = pdata->use_dma; davinci_spi->bitbang.flags = SPI_NO_CS | SPI_LSB_FIRST | SPI_LOOP; if (davinci_spi->version == SPI_VERSION_2) davinci_spi->bitbang.flags |= SPI_READY; - if (use_dma) { - dma_rx_chan = davinci_spi_get_dma_by_flag(pdev, - IORESOURCE_DMA_RX_CHAN); - dma_tx_chan = davinci_spi_get_dma_by_flag(pdev, - IORESOURCE_DMA_TX_CHAN); - dma_eventq = davinci_spi_get_dma_by_flag(pdev, - IORESOURCE_DMA_EVENT_Q); - } - - if (!use_dma || - dma_rx_chan == DAVINCI_SPI_NO_RESOURCE || - dma_tx_chan == DAVINCI_SPI_NO_RESOURCE || - dma_eventq == DAVINCI_SPI_NO_RESOURCE) { - davinci_spi->bitbang.txrx_bufs = davinci_spi_bufs_pio; - use_dma = 0; - } else { - davinci_spi->bitbang.txrx_bufs = davinci_spi_bufs_dma; - davinci_spi->dma_channels = kzalloc(master->num_chipselect - * sizeof(struct davinci_spi_dma), GFP_KERNEL); - if (davinci_spi->dma_channels == NULL) { - ret = -ENOMEM; - goto free_clk; - } - - for (i = 0; i < master->num_chipselect; i++) { - davinci_spi->dma_channels[i].dma_rx_channel = -1; - davinci_spi->dma_channels[i].dma_rx_sync_dev = - dma_rx_chan; - davinci_spi->dma_channels[i].dma_tx_channel = -1; - davinci_spi->dma_channels[i].dma_tx_sync_dev = - dma_tx_chan; - davinci_spi->dma_channels[i].eventq = dma_eventq; - } - dev_info(&pdev->dev, "DaVinci SPI driver in EDMA mode\n" - "Using RX channel = %d , TX channel = %d and " - "event queue = %d", dma_rx_chan, dma_tx_chan, - dma_eventq); - } + dma_rx_chan = davinci_spi_get_dma_by_flag(pdev, IORESOURCE_DMA_RX_CHAN); + dma_tx_chan = davinci_spi_get_dma_by_flag(pdev, IORESOURCE_DMA_TX_CHAN); + dma_eventq = davinci_spi_get_dma_by_flag(pdev, IORESOURCE_DMA_EVENT_Q); + davinci_spi->dma_channels.dma_rx_channel = -1; + davinci_spi->dma_channels.dma_rx_sync_dev = dma_rx_chan; + davinci_spi->dma_channels.dma_tx_channel = -1; + davinci_spi->dma_channels.dma_tx_sync_dev = dma_tx_chan; + davinci_spi->dma_channels.dummy_param_slot = -1; + davinci_spi->dma_channels.eventq = dma_eventq; davinci_spi->get_rx = davinci_spi_rx_buf_u8; davinci_spi->get_tx = davinci_spi_tx_buf_u8; @@ -1049,21 +841,22 @@ static int davinci_spi_probe(struct platform_device *pdev) udelay(100); iowrite32(1, davinci_spi->base + SPIGCR0); - /* Clock internal */ - if (davinci_spi->pdata->clk_internal) - set_io_bits(davinci_spi->base + SPIGCR1, - SPIGCR1_CLKMOD_MASK); - else - clear_io_bits(davinci_spi->base + SPIGCR1, - SPIGCR1_CLKMOD_MASK); + /* Set up SPIPC0. CS and ENA init is done in davinci_spi_setup */ + spipc0 = SPIPC0_DIFUN_MASK | SPIPC0_DOFUN_MASK | SPIPC0_CLKFUN_MASK; + iowrite32(spipc0, davinci_spi->base + SPIPC0); - /* master mode default */ - set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_MASTER_MASK); + /* initialize chip selects */ + if (pdata->chip_sel != NULL) { + for (i = 0; i < pdata->num_chipselect; i++) { + if (pdata->chip_sel[i] != SPI_INTERN_CS) + gpio_direction_output(pdata->chip_sel[i], 1); + } + } + iowrite32(SPIDEF_CSDEF_MASK, davinci_spi->base + SPIDEF); - if (davinci_spi->pdata->intr_level) - iowrite32(SPI_INTLVL_1, davinci_spi->base + SPILVL); - else - iowrite32(SPI_INTLVL_0, davinci_spi->base + SPILVL); + set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_CLKMOD_MASK); + set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_MASTER_MASK); + set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_POWERDOWN_MASK); ret = spi_bitbang_start(&davinci_spi->bitbang); if (ret != 0) @@ -1071,10 +864,6 @@ static int davinci_spi_probe(struct platform_device *pdev) dev_info(&pdev->dev, "Controller at 0x%p \n", davinci_spi->base); - if (!pdata->poll_mode) - dev_info(&pdev->dev, "Operating in interrupt mode" - " using IRQ %d\n", davinci_spi->irq); - return ret; free_clk: diff --git a/drivers/spi/davinci_spi.h b/drivers/spi/davinci_spi.h index 52acf47..16ebfad 100644 --- a/drivers/spi/davinci_spi.h +++ b/drivers/spi/davinci_spi.h @@ -19,8 +19,6 @@ #ifndef __DAVINCI_SPI_H #define __DAVINCI_SPI_H -#define SPI_MAX_CHIPSELECT 2 - #define CS_DEFAULT 0xFF #define SCS0_SELECT 0x01 #define SCS1_SELECT 0x02 @@ -41,9 +39,11 @@ #define SPIFMT_WDELAY_MASK 0x3f000000u #define SPIFMT_WDELAY_SHIFT 24 #define SPIFMT_CHARLEN_MASK 0x0000001Fu +#define SPIFMT_PRESCALE_SHIFT 8 /* SPIGCR1 */ -#define SPIGCR1_SPIENA_MASK 0x01000000u +#define SPIGCR1_SPIENA_MASK BIT(24) +#define SPIGCR1_POWERDOWN_MASK BIT(8) /* SPIPC0 */ #define SPIPC0_DIFUN_MASK BIT(11) /* MISO */ @@ -53,14 +53,16 @@ #define SPIPC0_EN1FUN_MASK BIT(1) #define SPIPC0_EN0FUN_MASK BIT(0) -#define SPIINT_MASKALL 0x0101035F +#define SPIINT_MASKALL 0x0101035Fu +#define SPIINT_MASKINT 0x0000035Fu #define SPI_INTLVL_1 0x000001FFu #define SPI_INTLVL_0 0x00000000u /* SPIDAT1 */ #define SPIDAT1_CSHOLD_MASK BIT(28) #define SPIDAT1_CSHOLD_SHIFT 28 -#define SPIDAT1_CSNR_MASK (BIT(17 | BIT(16)) +#define SPIDAT1_WDEL_MASK BIT(26) +#define SPIDAT1_CSNR_MASK 0x00FF0000u #define SPIDAT1_CSNR_SHIFT 16 #define SPIDAT1_DFSEL_MASK (BIT(24 | BIT(25)) #define SPIGCR1_CLKMOD_MASK BIT(1) @@ -71,6 +73,19 @@ #define SPIBUF_TXFULL_MASK BIT(29) #define SPIBUF_RXEMPTY_MASK BIT(31) +/* SPIDELAY */ +#define SPIDELAY_C2TDELAY_MASK 0xFF000000u +#define SPIDELAY_C2TDELAY_SHIFT 24 +#define SPIDELAY_T2CDELAY_MASK 0x00FF0000u +#define SPIDELAY_T2CDELAY_SHIFT 16 +#define SPIDELAY_T2EDELAY_MASK 0x0000FF00u +#define SPIDELAY_T2EDELAY_SHIFT 8 +#define SPIDELAY_C2EDELAY_MASK 0x000000FFu +#define SPIDELAY_C2EDELAY_SHIFT 0 + +/* SPIDEF */ +#define SPIDEF_CSDEF_MASK 0x000000FFu + /* Error Masks */ #define SPIFLG_DLEN_ERR_MASK BIT(0) #define SPIFLG_TIMEOUT_MASK BIT(1) @@ -81,11 +96,12 @@ #define SPIFLG_RX_INTR_MASK BIT(8) #define SPIFLG_TX_INTR_MASK BIT(9) #define SPIFLG_BUF_INIT_ACTIVE_MASK BIT(24) -#define SPIFLG_MASK (SPIFLG_DLEN_ERR_MASK \ +#define SPIFLG_ERROR_MASK (SPIFLG_DLEN_ERR_MASK \ | SPIFLG_TIMEOUT_MASK | SPIFLG_PARERR_MASK \ | SPIFLG_DESYNC_MASK | SPIFLG_BITERR_MASK \ - | SPIFLG_OVRRUN_MASK | SPIFLG_RX_INTR_MASK \ - | SPIFLG_TX_INTR_MASK \ + | SPIFLG_OVRRUN_MASK) +#define SPIFLG_MASK (SPIFLG_ERROR_MASK \ + | SPIFLG_RX_INTR_MASK | SPIFLG_TX_INTR_MASK \ | SPIFLG_BUF_INIT_ACTIVE_MASK) #define SPIINT_DLEN_ERR_INTR BIT(0) @@ -130,13 +146,6 @@ #define TGINTVEC0 0x60 #define TGINTVEC1 0x64 -struct davinci_spi_slave { - u32 cmd_to_write; - u32 clk_ctrl_to_write; - u32 bytes_per_word; - u8 active_cs; -}; - #define SPI_BUFSIZ (SMP_CACHE_BYTES + 1) /* We have 2 DMA channels per CS, one for RX and one for TX */ @@ -145,10 +154,8 @@ struct davinci_spi_dma { int dma_rx_channel; int dma_tx_sync_dev; int dma_rx_sync_dev; + int dummy_param_slot; enum dma_event_q eventq; - - struct completion dma_tx_completion; - struct completion dma_rx_completion; }; /* SPI Controller driver's private data. */ @@ -166,14 +173,14 @@ struct davinci_spi { const void *tx; void *rx; u8 *tmp_buf; - int count; - struct davinci_spi_dma *dma_channels; - struct davinci_spi_platform_data *pdata; + int rcount; + int wcount; + u32 errors; + struct davinci_spi_dma dma_channels; + struct davinci_spi_platform_data *pdata; void (*get_rx)(u32 rx_data, struct davinci_spi *); u32 (*get_tx)(struct davinci_spi *); - - struct davinci_spi_slave slave[SPI_MAX_CHIPSELECT]; }; #endif /* __DAVINCI_SPI_H */ -- 1.6.3.3 From bniebuhr3 at gmail.com Fri Mar 12 08:20:59 2010 From: bniebuhr3 at gmail.com (Brian Niebuhr) Date: Fri, 12 Mar 2010 08:20:59 -0600 Subject: [PATCH 2/2] spi: modify davinci platform data for updated driver In-Reply-To: <1268403659-20348-2-git-send-email-bniebuhr@efjohnson.com> References: <1268403659-20348-1-git-send-email-bniebuhr@efjohnson.com> <1268403659-20348-2-git-send-email-bniebuhr@efjohnson.com> Message-ID: <1268403659-20348-3-git-send-email-bniebuhr@efjohnson.com> These changes update the davinci platform data to match the modifications that were done to the davinci spi controller driver. The driver update allowed per-device transfer settings, which are provided by this patch. Signed-off-by: Brian Niebuhr --- arch/arm/mach-davinci/board-dm355-evm.c | 10 ++++++++++ arch/arm/mach-davinci/board-dm355-leopard.c | 10 ++++++++++ arch/arm/mach-davinci/board-dm365-evm.c | 10 ++++++++++ arch/arm/mach-davinci/board-dm646x-evm.c | 12 ++++++++++++ arch/arm/mach-davinci/dm355.c | 7 ------- arch/arm/mach-davinci/dm365.c | 7 ------- arch/arm/mach-davinci/dm646x.c | 7 ------- 7 files changed, 42 insertions(+), 21 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c index a0724fa..b1a21a4 100644 --- a/arch/arm/mach-davinci/board-dm355-evm.c +++ b/arch/arm/mach-davinci/board-dm355-evm.c @@ -40,6 +40,7 @@ #include #include #include +#include #define DAVINCI_ASYNC_EMIF_CONTROL_BASE 0x01e10000 #define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 @@ -445,10 +446,19 @@ static struct spi_eeprom at25640a = { .flags = EE_ADDR2, }; +static struct davinci_spi_config at25640a_spi_cfg = { + .parity_enable = 0, + .intr_level = 0, + .io_type = SPI_IO_TYPE_DMA, + .wdelay = 0, + .timer_disable = 1, +}; + static struct spi_board_info dm355_evm_spi_info[] __initconst = { { .modalias = "at25", .platform_data = &at25640a, + .controller_data = &at25640a_spi_cfg, .max_speed_hz = 30 * 1000 * 1000, /* at 3v3 */ .bus_num = 0, .chip_select = 0, diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c index 84ad5d1..d87ff0b 100644 --- a/arch/arm/mach-davinci/board-dm355-leopard.c +++ b/arch/arm/mach-davinci/board-dm355-leopard.c @@ -36,6 +36,7 @@ #include #include #include +#include #define DAVINCI_ASYNC_EMIF_CONTROL_BASE 0x01e10000 #define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 @@ -232,10 +233,19 @@ static struct spi_eeprom at25640a = { .flags = EE_ADDR2, }; +struct davinci_spi_config at25640a_spi_cfg = { + .parity_enable = 0, + .intr_level = 0, + .io_type = SPI_IO_TYPE_DMA, + .wdelay = 0, + .timer_disable = 1, +}; + static struct spi_board_info dm355_leopard_spi_info[] __initconst = { { .modalias = "at25", .platform_data = &at25640a, + .controller_data = &at25640a_spi_cfg, .max_speed_hz = 10 * 1000 * 1000, /* at 3v3 */ .bus_num = 0, .chip_select = 0, diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c index ab3b0e2..8559c84 100644 --- a/arch/arm/mach-davinci/board-dm365-evm.c +++ b/arch/arm/mach-davinci/board-dm365-evm.c @@ -44,6 +44,7 @@ #include #include #include +#include #include #include #include @@ -832,10 +833,19 @@ static struct spi_eeprom at25640 = { .flags = EE_ADDR2, }; +static struct davinci_spi_config at25640_spi_cfg = { + .parity_enable = 0, + .intr_level = 0, + .io_type = SPI_IO_TYPE_DMA, + .wdelay = 0, + .timer_disable = 1, +}; + static struct spi_board_info dm365_evm_spi_info[] __initconst = { { .modalias = "at25", .platform_data = &at25640, + .controller_data = &at25640_spi_cfg, .max_speed_hz = 20 * 1000 * 1000, /* at 3v3 */ .bus_num = 0, .chip_select = 0, diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c index 94271a6..5430b00 100644 --- a/arch/arm/mach-davinci/board-dm646x-evm.c +++ b/arch/arm/mach-davinci/board-dm646x-evm.c @@ -58,6 +58,7 @@ #include #include #include +#include #include #include "clock.h" @@ -911,10 +912,21 @@ static struct spi_eeprom at25640a = { .flags = EE_ADDR2, }; +static struct davinci_spi_config at25640a_spi_cfg = { + .parity_enable = 0, + .intr_level = 0, + .io_type = SPI_IO_TYPE_DMA, + .wdelay = 0, + .timer_disable = 0, + .c2t_delay = 8, + .t2c_delay = 8, +}; + static struct spi_board_info dm646x_evm_spi_info[] __initconst = { { .modalias = "at25", .platform_data = &at25640a, + .controller_data = &at25640a_spi_cfg, .max_speed_hz = 10 * 1000 * 1000, /* at 3v3 */ .bus_num = 0, .chip_select = 0, diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c index 6925242..90d1fda 100644 --- a/arch/arm/mach-davinci/dm355.c +++ b/arch/arm/mach-davinci/dm355.c @@ -418,13 +418,6 @@ static struct resource dm355_spi0_resources[] = { static struct davinci_spi_platform_data dm355_spi0_pdata = { .version = SPI_VERSION_1, .num_chipselect = 2, - .clk_internal = 1, - .cs_hold = 1, - .intr_level = 0, - .poll_mode = 1, /* 0 -> interrupt mode 1-> polling mode */ - .use_dma = 1, /* when 1, value in poll_mode is ignored */ - .c2tdelay = 0, - .t2cdelay = 0, }; static struct platform_device dm355_spi0_device = { diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index ed6c9c7..600dab5 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -621,13 +621,6 @@ static u64 dm365_spi0_dma_mask = DMA_BIT_MASK(32); static struct davinci_spi_platform_data dm365_spi0_pdata = { .version = SPI_VERSION_1, .num_chipselect = 2, - .clk_internal = 1, - .cs_hold = 1, - .intr_level = 0, - .poll_mode = 1, /* 0 -> interrupt mode 1-> polling mode */ - .use_dma = 1, /* when 1, value in poll_mode is ignored */ - .c2tdelay = 0, - .t2cdelay = 0, }; static struct resource dm365_spi0_resources[] = { diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index efb4863..f9b49cb 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -387,13 +387,6 @@ static u64 dm646x_spi0_dma_mask = DMA_BIT_MASK(32); static struct davinci_spi_platform_data dm646x_spi0_pdata = { .version = SPI_VERSION_1, .num_chipselect = 2, - .clk_internal = 1, - .cs_hold = 1, - .intr_level = 0, - .poll_mode = 1, /* 0 -> interrupt mode 1-> polling mode */ - .use_dma = 1, /* when 1, value in poll_mode is ignored */ - .c2tdelay = 8, - .t2cdelay = 8, }; static struct resource dm646x_spi0_resources[] = { -- 1.6.3.3 From khilman at deeprootsystems.com Fri Mar 12 12:03:10 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Fri, 12 Mar 2010 10:03:10 -0800 Subject: [PATCH] davinci: edma: clear interrupt status for interrupt enabled channels only In-Reply-To: <1268040958-16232-1-git-send-email-nsekhar@ti.com> (Sekhar Nori's message of "Mon\, 8 Mar 2010 15\:05\:58 +0530") References: <1268040958-16232-1-git-send-email-nsekhar@ti.com> Message-ID: <87fx458lk1.fsf@deeprootsystems.com> Sekhar Nori writes: > From: Anuj Aggarwal > > Currently, the ISR in the EDMA driver clears the pending interrupt for all > channels without regard to whether that channel has a registered callback > or not. > > This causes problems for devices like DM355/DM365 where the multimedia > accelerator uses EDMA by polling on the interrupt pending bits of some of the > EDMA channels. Since these channels are actually allocated through the Linux > EDMA driver (by an out-of-kernel module), the same shadow region is used by > Linux and accelerator. There a race between the Linux ISR and the polling code > running on the accelerator on the IPR (interrupt pending register). > > This patch fixes the issue by making the ISR clear the interrupts only for > those channels which have interrupt enabled. The channels which are allocated > for the purpose of being polled on by the accelerator will not have a callback > function provided and so will not have IER (interrupt enable register) bits set. Dumb question: why cat the MM accelerator use the normal ISR + callback? Kevin > Tested on DM365 and OMAP-L137/L138 with audio and MMC/SD (as EDMA users). > > Signed-off-by: Anuj Aggarwal > Signed-off-by: Sekhar Nori > CC: Archith John Bency > --- > arch/arm/mach-davinci/dma.c | 11 +++++++---- > 1 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c > index 15dd886..ea74a90 100644 > --- a/arch/arm/mach-davinci/dma.c > +++ b/arch/arm/mach-davinci/dma.c > @@ -358,9 +358,11 @@ static irqreturn_t dma_irq_handler(int irq, void *data) > > while (1) { > int j; > - if (edma_shadow0_read_array(ctlr, SH_IPR, 0)) > + if (edma_shadow0_read_array(ctlr, SH_IPR, 0) & > + edma_shadow0_read_array(ctlr, SH_IER, 0)) > j = 0; > - else if (edma_shadow0_read_array(ctlr, SH_IPR, 1)) > + else if (edma_shadow0_read_array(ctlr, SH_IPR, 1) & > + edma_shadow0_read_array(ctlr, SH_IER, 1)) > j = 1; > else > break; > @@ -368,8 +370,9 @@ static irqreturn_t dma_irq_handler(int irq, void *data) > edma_shadow0_read_array(ctlr, SH_IPR, j)); > for (i = 0; i < 32; i++) { > int k = (j << 5) + i; > - if (edma_shadow0_read_array(ctlr, SH_IPR, j) & > - (1 << i)) { > + if ((edma_shadow0_read_array(ctlr, SH_IPR, j) & BIT(i)) > + && (edma_shadow0_read_array(ctlr, > + SH_IER, j) & BIT(i))) { > /* Clear the corresponding IPR bits */ > edma_shadow0_write_array(ctlr, SH_ICR, j, > (1 << i)); > -- > 1.6.2.4 > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source From khilman at deeprootsystems.com Fri Mar 12 12:35:17 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Fri, 12 Mar 2010 10:35:17 -0800 Subject: VPFE fixes and enhancments patch Message-ID: <87aaud8k2i.fsf@deeprootsystems.com> Hi Murali, When rebasing for 2.6.34, I notcied that all the V4L2 stuff I was carrying in davinci git was merged upstream, except the patch "V4L - vpfe_capture - bug fixes and enhancements" This is currently still in davinci git, in the 'davinci-upstream-accepted' branch[1]. If this is still needed, please (re)submit to V4L2 and have it merged in the .34-rc cycle. Thanks, Kevin [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=shortlog;h=refs/heads/davinci-upstream-accepted From BNiebuhr at efjohnson.com Fri Mar 12 13:34:59 2010 From: BNiebuhr at efjohnson.com (Brian Niebuhr) Date: Fri, 12 Mar 2010 13:34:59 -0600 Subject: [PATCH 0/2] overhaul davinci spi driver to fix multiple errors In-Reply-To: <1268403659-20348-1-git-send-email-bniebuhr@efjohnson.com> References: <1268403659-20348-1-git-send-email-bniebuhr@efjohnson.com> Message-ID: Sorry, the last version had a bunch of whitespace problems. I will resubmit the patch shortly. From bniebuhr3 at gmail.com Fri Mar 12 13:35:18 2010 From: bniebuhr3 at gmail.com (Brian Niebuhr) Date: Fri, 12 Mar 2010 13:35:18 -0600 Subject: [PATCH 0/2 v2] overhaul davinci spi driver to fix multiple errors Message-ID: <1268422520-22642-1-git-send-email-bniebuhr@efjohnson.com> INTRODUCTION I have been working on a custom OMAP-L138 board that has multiple spi devices (seven) on one controller. These devices have a wide range of transfer parameters (speed, phase, polarity, internal and gpio chip selects). During my testing I found multiple errors in the davinci spi driver as a result of this complex setup. The primary issues were: 1. There is a race condition due to the SPIBUF read busy-waits for slow devices 2. I found some DMA transfer length errors under some conditions 3. The chip select code caused extra byte transfers (with no chip select active) due to writes to SPIDAT1 4. Several issues prevented using multiple SPI devices, especially the DMA code, as disucussed previously on the davinci list. The fixes to these problems were not simple. I ended up making fairly large changes to the driver, and those changes are contained in these patches. The full list of changes follows. CHANGE LIST 1. davinci_spi_chipelect() now performs both activation and deactivation of chip selects. This lets spi_bitbang fully control chip select activation, as intended by the SPI API. 2. Chip select activation does not cause extra writes to the SPI bus 3. Chip select activation does not use SPIDEF for control. This change will also allow for implementation of inverted (active high) chip selects in the future. 4. Added back gpio chip select capability from the old driver 5. Fixed prescale calculation for non-integer fractions of spi clock 6. Allow specification of SPI transfer parameters on a per-device (instead of per-controller) basis 7. Allow specification of polled, interrupt-based, or DMA operation on a per-device basis 8. Allow DMA with when more than one device is connected 9. Combined pio and dma txrx_bufs functions into one since they share large parts of their functionality, and to simplify item (8). 10. Use only SPIFMT0 to allow more than 4 devices TESTING I have tested the driver using a custom SPI stress test on my OMAP-L138-based board with three devices connected. I have tested configurations with all three devices polled, all three interrupt-based, all three DMA, and a mixture. I have compiled with the davinci_all_defconfig, but I don't have EVMs for the other davinci platforms to test with. SUMMARY I realize that this is a very large patch, but I hope that it's not thrown out just because of its size. It does solve a lot of issues that should save a lot of people time down the road. I would appreciate any feedback from those who can test it out on other davinci EVMs. Brian Niebuhr (2): spi: overhaul davinci spi driver to correct multiple errors spi: modify davinci platform data for updated driver arch/arm/mach-davinci/board-dm355-evm.c | 10 + arch/arm/mach-davinci/board-dm355-leopard.c | 10 + arch/arm/mach-davinci/board-dm365-evm.c | 10 + arch/arm/mach-davinci/board-dm646x-evm.c | 12 + arch/arm/mach-davinci/dm355.c | 7 - arch/arm/mach-davinci/dm365.c | 7 - arch/arm/mach-davinci/dm646x.c | 7 - arch/arm/mach-davinci/include/mach/spi.h | 30 +- drivers/spi/davinci_spi.c | 990 +++++++++++---------------- drivers/spi/davinci_spi.h | 53 +- 10 files changed, 479 insertions(+), 657 deletions(-) From bniebuhr3 at gmail.com Fri Mar 12 13:35:19 2010 From: bniebuhr3 at gmail.com (Brian Niebuhr) Date: Fri, 12 Mar 2010 13:35:19 -0600 Subject: [PATCH 1/2 v2] spi: overhaul davinci spi driver to correct multiple errors In-Reply-To: <1268422520-22642-1-git-send-email-bniebuhr@efjohnson.com> References: <1268422520-22642-1-git-send-email-bniebuhr@efjohnson.com> Message-ID: <1268422520-22642-2-git-send-email-bniebuhr@efjohnson.com> This patch is a significant overhaul of the davinci spi controller driver that corrects multiple errors: - Eliminate a race condition that exists for slow SPI devices - Fix DMA transfer length error - Fix limitations preventing multiple SPI devices on the same controller Signed-off-by: Brian Niebuhr --- arch/arm/mach-davinci/include/mach/spi.h | 30 +- drivers/spi/davinci_spi.c | 990 ++++++++++++------------------ drivers/spi/davinci_spi.h | 53 +- 3 files changed, 437 insertions(+), 636 deletions(-) diff --git a/arch/arm/mach-davinci/include/mach/spi.h b/arch/arm/mach-davinci/include/mach/spi.h index 7b54926..10c39d8 100644 --- a/arch/arm/mach-davinci/include/mach/spi.h +++ b/arch/arm/mach-davinci/include/mach/spi.h @@ -34,18 +34,24 @@ enum { struct davinci_spi_platform_data { u8 version; u16 num_chipselect; - u32 wdelay; - u32 odd_parity; - u32 parity_enable; - u32 wait_enable; - u32 timer_disable; - u32 clk_internal; - u32 cs_hold; - u32 intr_level; - u32 poll_mode; - u32 use_dma; - u8 c2tdelay; - u8 t2cdelay; + u8 *chip_sel; +}; + +struct davinci_spi_config { + u32 odd_parity:1; + u32 parity_enable:1; + u32 intr_level:1; + u32 io_type:2; +#define SPI_IO_TYPE_INTR 0 +#define SPI_IO_TYPE_POLL 1 +#define SPI_IO_TYPE_DMA 2 + u32 bytes_per_word:2; + u32 wdelay:6; + u32 timer_disable:1; + u8 c2t_delay; + u8 t2c_delay; + u8 t2e_delay; + u8 c2e_delay; }; #endif /* __ARCH_ARM_DAVINCI_SPI_H */ diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c index 956f617..0bed840 100644 --- a/drivers/spi/davinci_spi.c +++ b/drivers/spi/davinci_spi.c @@ -1,5 +1,6 @@ /* * Copyright (C) 2009 Texas Instruments. + * Copyright (C) 2010 EF Johnson Technologies * * 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 @@ -33,43 +34,45 @@ #include "davinci_spi.h" -static unsigned use_dma; - #define DAVINCI_SPI_NO_RESOURCE ((resource_size_t)-1) static void davinci_spi_rx_buf_u8(u32 data, struct davinci_spi *davinci_spi) { - u8 *rx = davinci_spi->rx; - - *rx++ = (u8)data; - davinci_spi->rx = rx; + if (davinci_spi->rx) { + u8 *rx = davinci_spi->rx; + *rx++ = (u8)data; + davinci_spi->rx = rx; + } } static void davinci_spi_rx_buf_u16(u32 data, struct davinci_spi *davinci_spi) { - u16 *rx = davinci_spi->rx; - - *rx++ = (u16)data; - davinci_spi->rx = rx; + if (davinci_spi->rx) { + u16 *rx = davinci_spi->rx; + *rx++ = (u16)data; + davinci_spi->rx = rx; + } } static u32 davinci_spi_tx_buf_u8(struct davinci_spi *davinci_spi) { - u32 data; - const u8 *tx = davinci_spi->tx; - - data = *tx++; - davinci_spi->tx = tx; + u32 data = 0; + if (davinci_spi->tx) { + const u8 *tx = davinci_spi->tx; + data = *tx++; + davinci_spi->tx = tx; + } return data; } static u32 davinci_spi_tx_buf_u16(struct davinci_spi *davinci_spi) { - u32 data; - const u16 *tx = davinci_spi->tx; - - data = *tx++; - davinci_spi->tx = tx; + u32 data = 0; + if (davinci_spi->tx) { + const u16 *tx = davinci_spi->tx; + data = *tx++; + davinci_spi->tx = tx; + } return data; } @@ -89,26 +92,6 @@ static inline void clear_io_bits(void __iomem *addr, u32 bits) iowrite32(v, addr); } -static inline void set_fmt_bits(void __iomem *addr, u32 bits, int cs_num) -{ - set_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits); -} - -static inline void clear_fmt_bits(void __iomem *addr, u32 bits, int cs_num) -{ - clear_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits); -} - -static void davinci_spi_set_dma_req(const struct spi_device *spi, int enable) -{ - struct davinci_spi *davinci_spi = spi_master_get_devdata(spi->master); - - if (enable) - set_io_bits(davinci_spi->base + SPIINT, SPIINT_DMA_REQ_EN); - else - clear_io_bits(davinci_spi->base + SPIINT, SPIINT_DMA_REQ_EN); -} - /* * Interface to control the chip select signal */ @@ -116,25 +99,54 @@ static void davinci_spi_chipselect(struct spi_device *spi, int value) { struct davinci_spi *davinci_spi; struct davinci_spi_platform_data *pdata; - u32 data1_reg_val = 0; + u8 i, chip_sel = spi->chip_select; + u32 spidat1; + u16 spidat1_cfg; davinci_spi = spi_master_get_devdata(spi->master); pdata = davinci_spi->pdata; - /* - * Board specific chip select logic decides the polarity and cs - * line for the controller - */ - if (value == BITBANG_CS_INACTIVE) { - set_io_bits(davinci_spi->base + SPIDEF, CS_DEFAULT); - - data1_reg_val |= CS_DEFAULT << SPIDAT1_CSNR_SHIFT; - iowrite32(data1_reg_val, davinci_spi->base + SPIDAT1); + spidat1 = SPIDAT1_CSNR_MASK; + if (value == BITBANG_CS_ACTIVE) + spidat1 |= SPIDAT1_CSHOLD_MASK; + else + spidat1 |= SPIDAT1_WDEL_MASK; - while ((ioread32(davinci_spi->base + SPIBUF) - & SPIBUF_RXEMPTY_MASK) == 0) - cpu_relax(); + if (pdata->chip_sel == NULL) { + if (value == BITBANG_CS_ACTIVE) + spidat1 &= ~((0x1 << chip_sel) << SPIDAT1_CSNR_SHIFT); + } else { + for (i = 0; i < pdata->num_chipselect; i++) { + if (pdata->chip_sel[i] == SPI_INTERN_CS) { + if ((i == chip_sel) && + (value == BITBANG_CS_ACTIVE)) { + spidat1 &= ~((0x1 << chip_sel) + << SPIDAT1_CSNR_SHIFT); + } + } else { + if (value == BITBANG_CS_INACTIVE) + gpio_set_value(pdata->chip_sel[i], 1); + else if (i == chip_sel) + gpio_set_value(pdata->chip_sel[i], 0); + } + } } + + spidat1_cfg = spidat1 >> SPIDAT1_CSNR_SHIFT; + iowrite16(spidat1_cfg, davinci_spi->base + SPIDAT1 + 2); +} + +/* + * davinci_spi_get_prescale - Calculates the correct prescale value + * @max_speed_hz: the maximum rate the SPI clock can run at + * + * This function calculates the prescale value that generates a clock rate + * less than or equal to the specified maximum + */ +static inline u32 davinci_spi_get_prescale(struct davinci_spi *davinci_spi, + u32 max_speed_hz) +{ + return ((clk_get_rate(davinci_spi->clk) - 1) / max_speed_hz) & 0xff; } /* @@ -149,14 +161,15 @@ static void davinci_spi_chipselect(struct spi_device *spi, int value) static int davinci_spi_setup_transfer(struct spi_device *spi, struct spi_transfer *t) { - struct davinci_spi *davinci_spi; struct davinci_spi_platform_data *pdata; + struct davinci_spi_config *spi_cfg; u8 bits_per_word = 0; - u32 hz = 0, prescale; + u32 hz = 0, spifmt = 0, prescale, delay = 0; davinci_spi = spi_master_get_devdata(spi->master); pdata = davinci_spi->pdata; + spi_cfg = spi->controller_data; if (t) { bits_per_word = t->bits_per_word; @@ -174,72 +187,112 @@ static int davinci_spi_setup_transfer(struct spi_device *spi, if (bits_per_word <= 8 && bits_per_word >= 2) { davinci_spi->get_rx = davinci_spi_rx_buf_u8; davinci_spi->get_tx = davinci_spi_tx_buf_u8; - davinci_spi->slave[spi->chip_select].bytes_per_word = 1; + spi_cfg->bytes_per_word = 1; } else if (bits_per_word <= 16 && bits_per_word >= 2) { davinci_spi->get_rx = davinci_spi_rx_buf_u16; davinci_spi->get_tx = davinci_spi_tx_buf_u16; - davinci_spi->slave[spi->chip_select].bytes_per_word = 2; + spi_cfg->bytes_per_word = 2; } else return -EINVAL; if (!hz) hz = spi->max_speed_hz; - clear_fmt_bits(davinci_spi->base, SPIFMT_CHARLEN_MASK, - spi->chip_select); - set_fmt_bits(davinci_spi->base, bits_per_word & 0x1f, - spi->chip_select); + prescale = davinci_spi_get_prescale(davinci_spi, hz); + spifmt |= (prescale << SPIFMT_PRESCALE_SHIFT); + + spifmt |= (bits_per_word & 0x1f); + + if (spi->mode & SPI_LSB_FIRST) + spifmt |= SPIFMT_SHIFTDIR_MASK; + + if (spi->mode & SPI_CPOL) + spifmt |= SPIFMT_POLARITY_MASK; + + if (!(spi->mode & SPI_CPHA)) + spifmt |= SPIFMT_PHASE_MASK; - prescale = ((clk_get_rate(davinci_spi->clk) / hz) - 1) & 0xff; + if (davinci_spi->version == SPI_VERSION_2) { + spifmt |= ((spi_cfg->wdelay << SPIFMT_WDELAY_SHIFT) + & SPIFMT_WDELAY_MASK); + + if (spi_cfg->odd_parity) + spifmt |= SPIFMT_ODD_PARITY_MASK; + + if (spi_cfg->parity_enable) + spifmt |= SPIFMT_PARITYENA_MASK; + + if (spi->mode & SPI_READY) { + spifmt |= SPIFMT_WAITENA_MASK; + delay |= (spi_cfg->t2e_delay + << SPIDELAY_T2EDELAY_SHIFT) + & SPIDELAY_T2EDELAY_MASK; + delay |= (spi_cfg->c2e_delay + << SPIDELAY_C2EDELAY_SHIFT) + & SPIDELAY_C2EDELAY_MASK; + } - clear_fmt_bits(davinci_spi->base, 0x0000ff00, spi->chip_select); - set_fmt_bits(davinci_spi->base, prescale << 8, spi->chip_select); + if (spi_cfg->timer_disable) { + spifmt |= SPIFMT_DISTIMER_MASK; + } else { + delay |= (spi_cfg->c2t_delay + << SPIDELAY_C2TDELAY_SHIFT) + & SPIDELAY_C2TDELAY_MASK; + delay |= (spi_cfg->t2c_delay + << SPIDELAY_T2CDELAY_SHIFT) + & SPIDELAY_T2CDELAY_MASK; + } + + iowrite32(delay, davinci_spi->base + SPIDELAY); + } + + iowrite32(spifmt, davinci_spi->base + SPIFMT0); + + if (spi_cfg->intr_level) + iowrite32(SPI_INTLVL_1, davinci_spi->base + SPILVL); + else + iowrite32(SPI_INTLVL_0, davinci_spi->base + SPILVL); + + if (spi->mode & SPI_LOOP) + set_io_bits(davinci_spi->base + SPIGCR1, + SPIGCR1_LOOPBACK_MASK); + else + clear_io_bits(davinci_spi->base + SPIGCR1, + SPIGCR1_LOOPBACK_MASK); return 0; } static void davinci_spi_dma_rx_callback(unsigned lch, u16 ch_status, void *data) { - struct spi_device *spi = (struct spi_device *)data; - struct davinci_spi *davinci_spi; + struct davinci_spi *davinci_spi = (struct davinci_spi *)data; struct davinci_spi_dma *davinci_spi_dma; struct davinci_spi_platform_data *pdata; - davinci_spi = spi_master_get_devdata(spi->master); - davinci_spi_dma = &(davinci_spi->dma_channels[spi->chip_select]); + davinci_spi_dma = &(davinci_spi->dma_channels); pdata = davinci_spi->pdata; - if (ch_status == DMA_COMPLETE) - edma_stop(davinci_spi_dma->dma_rx_channel); - else - edma_clean_channel(davinci_spi_dma->dma_rx_channel); + edma_stop(davinci_spi_dma->dma_rx_channel); - complete(&davinci_spi_dma->dma_rx_completion); - /* We must disable the DMA RX request */ - davinci_spi_set_dma_req(spi, 0); + if (ch_status == DMA_COMPLETE) + davinci_spi->rcount = 0; + complete(&davinci_spi->done); } static void davinci_spi_dma_tx_callback(unsigned lch, u16 ch_status, void *data) { - struct spi_device *spi = (struct spi_device *)data; - struct davinci_spi *davinci_spi; + struct davinci_spi *davinci_spi = (struct davinci_spi *)data; struct davinci_spi_dma *davinci_spi_dma; struct davinci_spi_platform_data *pdata; - davinci_spi = spi_master_get_devdata(spi->master); - davinci_spi_dma = &(davinci_spi->dma_channels[spi->chip_select]); + davinci_spi_dma = &(davinci_spi->dma_channels); pdata = davinci_spi->pdata; - if (ch_status == DMA_COMPLETE) - edma_stop(davinci_spi_dma->dma_tx_channel); - else - edma_clean_channel(davinci_spi_dma->dma_tx_channel); - - complete(&davinci_spi_dma->dma_tx_completion); - /* We must disable the DMA TX request */ - davinci_spi_set_dma_req(spi, 0); + edma_stop(davinci_spi_dma->dma_tx_channel); + if (ch_status == DMA_COMPLETE) + davinci_spi->wcount = 0; } static int davinci_spi_request_dma(struct spi_device *spi) @@ -251,30 +304,51 @@ static int davinci_spi_request_dma(struct spi_device *spi) int r; davinci_spi = spi_master_get_devdata(spi->master); - davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select]; + davinci_spi_dma = &davinci_spi->dma_channels; pdata = davinci_spi->pdata; sdev = davinci_spi->bitbang.master->dev.parent; r = edma_alloc_channel(davinci_spi_dma->dma_rx_sync_dev, - davinci_spi_dma_rx_callback, spi, + davinci_spi_dma_rx_callback, davinci_spi, davinci_spi_dma->eventq); if (r < 0) { dev_dbg(sdev, "Unable to request DMA channel for MibSPI RX\n"); - return -EAGAIN; + r = -EAGAIN; + goto rx_dma_failed; } davinci_spi_dma->dma_rx_channel = r; + r = edma_alloc_channel(davinci_spi_dma->dma_tx_sync_dev, - davinci_spi_dma_tx_callback, spi, + davinci_spi_dma_tx_callback, davinci_spi, davinci_spi_dma->eventq); if (r < 0) { - edma_free_channel(davinci_spi_dma->dma_rx_channel); - davinci_spi_dma->dma_rx_channel = -1; dev_dbg(sdev, "Unable to request DMA channel for MibSPI TX\n"); - return -EAGAIN; + r = -EAGAIN; + goto tx_dma_failed; } davinci_spi_dma->dma_tx_channel = r; + r = edma_alloc_slot(EDMA_CTLR(davinci_spi_dma->dma_tx_sync_dev), + EDMA_SLOT_ANY); + if (r < 0) { + dev_dbg(sdev, "Unable to request SPI DMA param slot\n"); + r = -EAGAIN; + goto param_failed; + } + davinci_spi_dma->dummy_param_slot = r; + edma_link(davinci_spi_dma->dummy_param_slot, + davinci_spi_dma->dummy_param_slot); + return 0; + +param_failed: + edma_free_channel(davinci_spi_dma->dma_tx_channel); + davinci_spi_dma->dma_tx_channel = -1; +tx_dma_failed: + edma_free_channel(davinci_spi_dma->dma_rx_channel); + davinci_spi_dma->dma_rx_channel = -1; +rx_dma_failed: + return r; } /* @@ -286,124 +360,51 @@ static int davinci_spi_request_dma(struct spi_device *spi) static int davinci_spi_setup(struct spi_device *spi) { - int retval; + int retval = 0; struct davinci_spi *davinci_spi; - struct davinci_spi_dma *davinci_spi_dma; + struct davinci_spi_dma *davinci_dma; + struct davinci_spi_platform_data *pdata; + struct davinci_spi_config *spi_cfg; + u32 prescale; davinci_spi = spi_master_get_devdata(spi->master); + pdata = davinci_spi->pdata; + spi_cfg = (struct davinci_spi_config *)spi->controller_data; + davinci_dma = &(davinci_spi->dma_channels); /* if bits per word length is zero then set it default 8 */ if (!spi->bits_per_word) spi->bits_per_word = 8; - davinci_spi->slave[spi->chip_select].cmd_to_write = 0; - - if (use_dma && davinci_spi->dma_channels) { - davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select]; + if (!(spi->mode & SPI_NO_CS)) { + if ((pdata->chip_sel == NULL) || + (pdata->chip_sel[spi->chip_select] == SPI_INTERN_CS)) + set_io_bits(davinci_spi->base + SPIPC0, + 1 << spi->chip_select); - if ((davinci_spi_dma->dma_rx_channel == -1) - || (davinci_spi_dma->dma_tx_channel == -1)) { - retval = davinci_spi_request_dma(spi); - if (retval < 0) - return retval; - } } - /* - * SPI in DaVinci and DA8xx operate between - * 600 KHz and 50 MHz - */ - if (spi->max_speed_hz < 600000 || spi->max_speed_hz > 50000000) - return -EINVAL; + if (spi->mode & SPI_READY) + set_io_bits(davinci_spi->base + SPIPC0, SPIPC0_SPIENA_MASK); - /* - * Set up SPIFMTn register, unique to this chipselect. - * - * NOTE: we could do all of these with one write. Also, some - * of the "version 2" features are found in chips that don't - * support all of them... - */ - if (spi->mode & SPI_LSB_FIRST) - set_fmt_bits(davinci_spi->base, SPIFMT_SHIFTDIR_MASK, - spi->chip_select); - else - clear_fmt_bits(davinci_spi->base, SPIFMT_SHIFTDIR_MASK, - spi->chip_select); + if (spi_cfg->io_type == SPI_IO_TYPE_DMA) { + davinci_dma = &(davinci_spi->dma_channels); - if (spi->mode & SPI_CPOL) - set_fmt_bits(davinci_spi->base, SPIFMT_POLARITY_MASK, - spi->chip_select); - else - clear_fmt_bits(davinci_spi->base, SPIFMT_POLARITY_MASK, - spi->chip_select); - - if (!(spi->mode & SPI_CPHA)) - set_fmt_bits(davinci_spi->base, SPIFMT_PHASE_MASK, - spi->chip_select); - else - clear_fmt_bits(davinci_spi->base, SPIFMT_PHASE_MASK, - spi->chip_select); + if ((davinci_dma->dma_tx_sync_dev == DAVINCI_SPI_NO_RESOURCE) || + (davinci_dma->dma_rx_sync_dev == DAVINCI_SPI_NO_RESOURCE) || + (davinci_dma->eventq == DAVINCI_SPI_NO_RESOURCE)) + spi_cfg->io_type = SPI_IO_TYPE_INTR; + else if ((davinci_dma->dma_rx_channel == -1) || + (davinci_dma->dma_tx_channel == -1)) + retval = davinci_spi_request_dma(spi); + } /* - * Version 1 hardware supports two basic SPI modes: - * - Standard SPI mode uses 4 pins, with chipselect - * - 3 pin SPI is a 4 pin variant without CS (SPI_NO_CS) - * (distinct from SPI_3WIRE, with just one data wire; - * or similar variants without MOSI or without MISO) - * - * Version 2 hardware supports an optional handshaking signal, - * so it can support two more modes: - * - 5 pin SPI variant is standard SPI plus SPI_READY - * - 4 pin with enable is (SPI_READY | SPI_NO_CS) + * Validate desired clock rate */ - - if (davinci_spi->version == SPI_VERSION_2) { - clear_fmt_bits(davinci_spi->base, SPIFMT_WDELAY_MASK, - spi->chip_select); - set_fmt_bits(davinci_spi->base, - (davinci_spi->pdata->wdelay - << SPIFMT_WDELAY_SHIFT) - & SPIFMT_WDELAY_MASK, - spi->chip_select); - - if (davinci_spi->pdata->odd_parity) - set_fmt_bits(davinci_spi->base, - SPIFMT_ODD_PARITY_MASK, - spi->chip_select); - else - clear_fmt_bits(davinci_spi->base, - SPIFMT_ODD_PARITY_MASK, - spi->chip_select); - - if (davinci_spi->pdata->parity_enable) - set_fmt_bits(davinci_spi->base, - SPIFMT_PARITYENA_MASK, - spi->chip_select); - else - clear_fmt_bits(davinci_spi->base, - SPIFMT_PARITYENA_MASK, - spi->chip_select); - - if (davinci_spi->pdata->wait_enable) - set_fmt_bits(davinci_spi->base, - SPIFMT_WAITENA_MASK, - spi->chip_select); - else - clear_fmt_bits(davinci_spi->base, - SPIFMT_WAITENA_MASK, - spi->chip_select); - - if (davinci_spi->pdata->timer_disable) - set_fmt_bits(davinci_spi->base, - SPIFMT_DISTIMER_MASK, - spi->chip_select); - else - clear_fmt_bits(davinci_spi->base, - SPIFMT_DISTIMER_MASK, - spi->chip_select); - } - - retval = davinci_spi_setup_transfer(spi, NULL); + prescale = davinci_spi_get_prescale(davinci_spi, spi->max_speed_hz); + if ((prescale < 2) || (prescale > 255)) + return -EINVAL; return retval; } @@ -412,50 +413,19 @@ static void davinci_spi_cleanup(struct spi_device *spi) { struct davinci_spi *davinci_spi = spi_master_get_devdata(spi->master); struct davinci_spi_dma *davinci_spi_dma; + struct davinci_spi_platform_data *pdata; - davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select]; - - if (use_dma && davinci_spi->dma_channels) { - davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select]; - - if ((davinci_spi_dma->dma_rx_channel != -1) - && (davinci_spi_dma->dma_tx_channel != -1)) { - edma_free_channel(davinci_spi_dma->dma_tx_channel); - edma_free_channel(davinci_spi_dma->dma_rx_channel); - } - } -} - -static int davinci_spi_bufs_prep(struct spi_device *spi, - struct davinci_spi *davinci_spi) -{ - int op_mode = 0; - - /* - * REVISIT unless devices disagree about SPI_LOOP or - * SPI_READY (SPI_NO_CS only allows one device!), this - * should not need to be done before each message... - * optimize for both flags staying cleared. - */ - - op_mode = SPIPC0_DIFUN_MASK - | SPIPC0_DOFUN_MASK - | SPIPC0_CLKFUN_MASK; - if (!(spi->mode & SPI_NO_CS)) - op_mode |= 1 << spi->chip_select; - if (spi->mode & SPI_READY) - op_mode |= SPIPC0_SPIENA_MASK; + davinci_spi_dma = &davinci_spi->dma_channels; + pdata = davinci_spi->pdata; - iowrite32(op_mode, davinci_spi->base + SPIPC0); + if (davinci_spi_dma->dma_rx_channel != -1) + edma_free_channel(davinci_spi_dma->dma_rx_channel); - if (spi->mode & SPI_LOOP) - set_io_bits(davinci_spi->base + SPIGCR1, - SPIGCR1_LOOPBACK_MASK); - else - clear_io_bits(davinci_spi->base + SPIGCR1, - SPIGCR1_LOOPBACK_MASK); + if (davinci_spi_dma->dma_tx_channel != -1) + edma_free_channel(davinci_spi_dma->dma_tx_channel); - return 0; + if (davinci_spi_dma->dummy_param_slot != -1) + edma_free_slot(davinci_spi_dma->dummy_param_slot); } static int davinci_spi_check_error(struct davinci_spi *davinci_spi, @@ -503,329 +473,190 @@ static int davinci_spi_check_error(struct davinci_spi *davinci_spi, } /* - * davinci_spi_bufs - functions which will handle transfer data - * @spi: spi device on which data transfer to be done - * @t: spi transfer in which transfer info is filled + * davinci_spi_process_events - check for and handle any SPI controller events + * @davinci_spi - the controller data * - * This function will put data to be transferred into data register - * of SPI controller and then wait until the completion will be marked - * by the IRQ Handler. + * This function will check the SPIFLG register and handle any events that are + * detected there */ -static int davinci_spi_bufs_pio(struct spi_device *spi, struct spi_transfer *t) +static int davinci_spi_process_events(struct davinci_spi *davinci_spi) { - struct davinci_spi *davinci_spi; - int int_status, count, ret; - u8 conv, tmp; - u32 tx_data, data1_reg_val; - u32 buf_val, flg_val; - struct davinci_spi_platform_data *pdata; - - davinci_spi = spi_master_get_devdata(spi->master); - pdata = davinci_spi->pdata; - - davinci_spi->tx = t->tx_buf; - davinci_spi->rx = t->rx_buf; - - /* convert len to words bbased on bits_per_word */ - conv = davinci_spi->slave[spi->chip_select].bytes_per_word; - davinci_spi->count = t->len / conv; - - INIT_COMPLETION(davinci_spi->done); - - ret = davinci_spi_bufs_prep(spi, davinci_spi); - if (ret) - return ret; - - /* Enable SPI */ - set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_SPIENA_MASK); - - iowrite32(0 | (pdata->c2tdelay << SPI_C2TDELAY_SHIFT) | - (pdata->t2cdelay << SPI_T2CDELAY_SHIFT), - davinci_spi->base + SPIDELAY); - - count = davinci_spi->count; - data1_reg_val = pdata->cs_hold << SPIDAT1_CSHOLD_SHIFT; - tmp = ~(0x1 << spi->chip_select); - - clear_io_bits(davinci_spi->base + SPIDEF, ~tmp); - - data1_reg_val |= tmp << SPIDAT1_CSNR_SHIFT; - - while ((ioread32(davinci_spi->base + SPIBUF) - & SPIBUF_RXEMPTY_MASK) == 0) - cpu_relax(); - - /* Determine the command to execute READ or WRITE */ - if (t->tx_buf) { - clear_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKALL); - - while (1) { - tx_data = davinci_spi->get_tx(davinci_spi); - - data1_reg_val &= ~(0xFFFF); - data1_reg_val |= (0xFFFF & tx_data); - - buf_val = ioread32(davinci_spi->base + SPIBUF); - if ((buf_val & SPIBUF_TXFULL_MASK) == 0) { - iowrite32(data1_reg_val, - davinci_spi->base + SPIDAT1); - - count--; - } - while (ioread32(davinci_spi->base + SPIBUF) - & SPIBUF_RXEMPTY_MASK) - cpu_relax(); - - /* getting the returned byte */ - if (t->rx_buf) { - buf_val = ioread32(davinci_spi->base + SPIBUF); - davinci_spi->get_rx(buf_val, davinci_spi); - } - if (count <= 0) - break; - } - } else { - if (pdata->poll_mode) { - while (1) { - /* keeps the serial clock going */ - if ((ioread32(davinci_spi->base + SPIBUF) - & SPIBUF_TXFULL_MASK) == 0) - iowrite32(data1_reg_val, - davinci_spi->base + SPIDAT1); - - while (ioread32(davinci_spi->base + SPIBUF) & - SPIBUF_RXEMPTY_MASK) - cpu_relax(); - - flg_val = ioread32(davinci_spi->base + SPIFLG); - buf_val = ioread32(davinci_spi->base + SPIBUF); - - davinci_spi->get_rx(buf_val, davinci_spi); - - count--; - if (count <= 0) - break; - } - } else { /* Receive in Interrupt mode */ - int i; - - for (i = 0; i < davinci_spi->count; i++) { - set_io_bits(davinci_spi->base + SPIINT, - SPIINT_BITERR_INTR - | SPIINT_OVRRUN_INTR - | SPIINT_RX_INTR); - - iowrite32(data1_reg_val, - davinci_spi->base + SPIDAT1); - - while (ioread32(davinci_spi->base + SPIINT) & - SPIINT_RX_INTR) - cpu_relax(); - } - iowrite32((data1_reg_val & 0x0ffcffff), - davinci_spi->base + SPIDAT1); - } + u32 status, tx_data, rx_data, spidat1; + u8 tx_word = 0; + + status = ioread32(davinci_spi->base + SPIFLG); + + if ((davinci_spi->version == SPI_VERSION_2) && + (likely(status & SPIFLG_TX_INTR_MASK)) && + (likely(davinci_spi->wcount > 0))) + tx_word = 1; + + if (likely(status & SPIFLG_RX_INTR_MASK)) { + rx_data = ioread32(davinci_spi->base + SPIBUF) & 0xFFFF; + davinci_spi->get_rx(rx_data, davinci_spi); + davinci_spi->rcount--; + if ((davinci_spi->version != SPI_VERSION_2) && + (likely(davinci_spi->wcount > 0))) + tx_word = 1; } - /* - * Check for bit error, desync error,parity error,timeout error and - * receive overflow errors - */ - int_status = ioread32(davinci_spi->base + SPIFLG); - - ret = davinci_spi_check_error(davinci_spi, int_status); - if (ret != 0) - return ret; + if (unlikely(status & SPIFLG_ERROR_MASK)) { + davinci_spi->errors = (status & SPIFLG_ERROR_MASK); + return -1; + } - /* SPI Framework maintains the count only in bytes so convert back */ - davinci_spi->count *= conv; + if (likely(tx_word)) { + spidat1 = ioread32(davinci_spi->base + SPIDAT1); + davinci_spi->wcount--; + tx_data = davinci_spi->get_tx(davinci_spi); + spidat1 &= 0xFFFF0000; + spidat1 |= (tx_data & 0xFFFF); + iowrite32(spidat1, davinci_spi->base + SPIDAT1); + } - return t->len; + return 0; } -#define DAVINCI_DMA_DATA_TYPE_S8 0x01 -#define DAVINCI_DMA_DATA_TYPE_S16 0x02 -#define DAVINCI_DMA_DATA_TYPE_S32 0x04 - -static int davinci_spi_bufs_dma(struct spi_device *spi, struct spi_transfer *t) +/* + * davinci_spi_txrx_bufs - function which will handle transfer data + * @spi: spi device on which data transfer to be done + * @t: spi transfer in which transfer info is filled + * + * This function will put data to be transferred into data register + * of SPI controller and then wait until the completion will be marked + * by the IRQ Handler. + */ +static int davinci_spi_txrx_bufs(struct spi_device *spi, struct spi_transfer *t) { struct davinci_spi *davinci_spi; - int int_status = 0; - int count; - u8 conv = 1; - u8 tmp; - u32 data1_reg_val; - struct davinci_spi_dma *davinci_spi_dma; - int word_len, data_type, ret; - unsigned long tx_reg, rx_reg; + int data_type, ret = 0; + u32 tx_data, spidat1; + u16 tx_buf_count = 0, rx_buf_count = 0; + struct davinci_spi_config *spi_cfg; struct davinci_spi_platform_data *pdata; + struct davinci_spi_dma *davinci_dma; struct device *sdev; + dma_addr_t tx_reg, rx_reg; + void *tx_buf, *rx_buf; + struct edmacc_param rx_param, tx_param; davinci_spi = spi_master_get_devdata(spi->master); pdata = davinci_spi->pdata; - sdev = davinci_spi->bitbang.master->dev.parent; - - BUG_ON(davinci_spi->dma_channels == NULL); - - davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select]; - - tx_reg = (unsigned long)davinci_spi->pbase + SPIDAT1; - rx_reg = (unsigned long)davinci_spi->pbase + SPIBUF; + spi_cfg = (struct davinci_spi_config *)spi->controller_data; + davinci_dma = &(davinci_spi->dma_channels); - /* used for macro defs */ davinci_spi->tx = t->tx_buf; davinci_spi->rx = t->rx_buf; + davinci_spi->wcount = t->len / spi_cfg->bytes_per_word; + davinci_spi->rcount = davinci_spi->wcount; + davinci_spi->errors = 0; - /* convert len to words based on bits_per_word */ - conv = davinci_spi->slave[spi->chip_select].bytes_per_word; - davinci_spi->count = t->len / conv; + spidat1 = ioread32(davinci_spi->base + SPIDAT1); - INIT_COMPLETION(davinci_spi->done); - - init_completion(&davinci_spi_dma->dma_rx_completion); - init_completion(&davinci_spi_dma->dma_tx_completion); - - word_len = conv * 8; - - if (word_len <= 8) - data_type = DAVINCI_DMA_DATA_TYPE_S8; - else if (word_len <= 16) - data_type = DAVINCI_DMA_DATA_TYPE_S16; - else if (word_len <= 32) - data_type = DAVINCI_DMA_DATA_TYPE_S32; - else - return -1; - - ret = davinci_spi_bufs_prep(spi, davinci_spi); - if (ret) - return ret; - - /* Put delay val if required */ - iowrite32(0 | (pdata->c2tdelay << SPI_C2TDELAY_SHIFT) | - (pdata->t2cdelay << SPI_T2CDELAY_SHIFT), - davinci_spi->base + SPIDELAY); - - count = davinci_spi->count; /* the number of elements */ - data1_reg_val = pdata->cs_hold << SPIDAT1_CSHOLD_SHIFT; - - /* CD default = 0xFF */ - tmp = ~(0x1 << spi->chip_select); - - clear_io_bits(davinci_spi->base + SPIDEF, ~tmp); - - data1_reg_val |= tmp << SPIDAT1_CSNR_SHIFT; - - /* disable all interrupts for dma transfers */ - clear_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKALL); - /* Disable SPI to write configuration bits in SPIDAT */ - clear_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_SPIENA_MASK); - iowrite32(data1_reg_val, davinci_spi->base + SPIDAT1); - /* Enable SPI */ + clear_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_POWERDOWN_MASK); set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_SPIENA_MASK); - while ((ioread32(davinci_spi->base + SPIBUF) - & SPIBUF_RXEMPTY_MASK) == 0) - cpu_relax(); - + INIT_COMPLETION(davinci_spi->done); - if (t->tx_buf != NULL) { - t->tx_dma = dma_map_single(&spi->dev, (void *)t->tx_buf, count, - DMA_TO_DEVICE); - if (dma_mapping_error(&spi->dev, t->tx_dma)) { - dev_dbg(sdev, "Couldn't DMA map a %d bytes TX buffer\n", - count); - return -1; + if ((spi_cfg->io_type == SPI_IO_TYPE_INTR) || + (spi_cfg->io_type == SPI_IO_TYPE_POLL)) { + + if (spi_cfg->io_type == SPI_IO_TYPE_INTR) + set_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKINT); + + /* start the transfer */ + davinci_spi->wcount--; + tx_data = davinci_spi->get_tx(davinci_spi); + spidat1 &= 0xFFFF0000; + spidat1 |= (tx_data & 0xFFFF); + iowrite32(spidat1, davinci_spi->base + SPIDAT1); + + } else if (spi_cfg->io_type == SPI_IO_TYPE_DMA) { + data_type = spi_cfg->bytes_per_word; + tx_reg = (dma_addr_t)davinci_spi->pbase + SPIDAT1; + rx_reg = (dma_addr_t)davinci_spi->pbase + SPIBUF; + + if (t->tx_buf) { + tx_buf = ((void *)t->tx_buf); + tx_buf_count = davinci_spi->wcount; + } else { + tx_buf = (void *)davinci_spi->tmp_buf; + tx_buf_count = SPI_BUFSIZ; } - edma_set_transfer_params(davinci_spi_dma->dma_tx_channel, data_type, - count, 1, 0, ASYNC); - edma_set_dest(davinci_spi_dma->dma_tx_channel, - tx_reg, INCR, W8BIT); - edma_set_src(davinci_spi_dma->dma_tx_channel, - t->tx_dma, INCR, W8BIT); - edma_set_src_index(davinci_spi_dma->dma_tx_channel, data_type, 0); - edma_set_dest_index(davinci_spi_dma->dma_tx_channel, 0, 0); - } else { - /* We need TX clocking for RX transaction */ - t->tx_dma = dma_map_single(&spi->dev, - (void *)davinci_spi->tmp_buf, count + 1, - DMA_TO_DEVICE); - if (dma_mapping_error(&spi->dev, t->tx_dma)) { - dev_dbg(sdev, "Couldn't DMA map a %d bytes TX tmp buffer\n", - count); - return -1; + if (t->rx_buf) { + rx_buf = (void *)t->rx_buf; + rx_buf_count = davinci_spi->rcount; + } else { + rx_buf = (void *)davinci_spi->tmp_buf; + rx_buf_count = SPI_BUFSIZ; } - edma_set_transfer_params(davinci_spi_dma->dma_tx_channel, - data_type, count + 1, 1, 0, ASYNC); - edma_set_dest(davinci_spi_dma->dma_tx_channel, tx_reg, - INCR, W8BIT); - edma_set_src(davinci_spi_dma->dma_tx_channel, - t->tx_dma, INCR, W8BIT); - edma_set_src_index(davinci_spi_dma->dma_tx_channel, - data_type, 0); - edma_set_dest_index(davinci_spi_dma->dma_tx_channel, 0, 0); + + t->tx_dma = dma_map_single(&spi->dev, tx_buf, + tx_buf_count, DMA_TO_DEVICE); + t->rx_dma = dma_map_single(&spi->dev, rx_buf, + rx_buf_count, DMA_FROM_DEVICE); + + tx_param.opt = TCINTEN | EDMA_TCC(davinci_dma->dma_tx_channel); + tx_param.src = t->tx_buf ? t->tx_dma : tx_reg; + tx_param.a_b_cnt = davinci_spi->wcount << 16 | data_type; + tx_param.dst = tx_reg; + tx_param.src_dst_bidx = t->tx_buf ? data_type : 0; + tx_param.link_bcntrld = 0xffff; + tx_param.src_dst_cidx = 0; + tx_param.ccnt = 1; + edma_write_slot(davinci_dma->dma_tx_channel, &tx_param); + edma_link(davinci_dma->dma_tx_channel, + davinci_dma->dummy_param_slot); + + rx_param.opt = TCINTEN | EDMA_TCC(davinci_dma->dma_rx_channel); + rx_param.src = rx_reg; + rx_param.a_b_cnt = davinci_spi->rcount << 16 | data_type; + rx_param.dst = t->rx_dma; + rx_param.src_dst_bidx = (t->rx_buf ? data_type : 0) << 16; + rx_param.link_bcntrld = 0xffff; + rx_param.src_dst_cidx = 0; + rx_param.ccnt = 1; + edma_write_slot(davinci_dma->dma_rx_channel, &rx_param); + + iowrite16(spidat1 >> SPIDAT1_CSNR_SHIFT, + davinci_spi->base + SPIDAT1 + 2); + + edma_start(davinci_dma->dma_rx_channel); + edma_start(davinci_dma->dma_tx_channel); + set_io_bits(davinci_spi->base + SPIINT, SPIINT_DMA_REQ_EN); } - if (t->rx_buf != NULL) { - /* initiate transaction */ - iowrite32(data1_reg_val, davinci_spi->base + SPIDAT1); - - t->rx_dma = dma_map_single(&spi->dev, (void *)t->rx_buf, count, - DMA_FROM_DEVICE); - if (dma_mapping_error(&spi->dev, t->rx_dma)) { - dev_dbg(sdev, "Couldn't DMA map a %d bytes RX buffer\n", - count); - if (t->tx_buf != NULL) - dma_unmap_single(NULL, t->tx_dma, - count, DMA_TO_DEVICE); - return -1; + /* Wait for the transfer to complete */ + if (spi_cfg->io_type != SPI_IO_TYPE_POLL) { + wait_for_completion_interruptible(&(davinci_spi->done)); + } else { + while ((davinci_spi->rcount > 0) && (ret == 0)) { + ret = davinci_spi_process_events(davinci_spi); + cpu_relax(); } - edma_set_transfer_params(davinci_spi_dma->dma_rx_channel, data_type, - count, 1, 0, ASYNC); - edma_set_src(davinci_spi_dma->dma_rx_channel, - rx_reg, INCR, W8BIT); - edma_set_dest(davinci_spi_dma->dma_rx_channel, - t->rx_dma, INCR, W8BIT); - edma_set_src_index(davinci_spi_dma->dma_rx_channel, 0, 0); - edma_set_dest_index(davinci_spi_dma->dma_rx_channel, data_type, 0); } - if ((t->tx_buf != NULL) || (t->rx_buf != NULL)) - edma_start(davinci_spi_dma->dma_tx_channel); - - if (t->rx_buf != NULL) - edma_start(davinci_spi_dma->dma_rx_channel); - - if ((t->rx_buf != NULL) || (t->tx_buf != NULL)) - davinci_spi_set_dma_req(spi, 1); - - if (t->tx_buf != NULL) - wait_for_completion_interruptible( - &davinci_spi_dma->dma_tx_completion); - - if (t->rx_buf != NULL) - wait_for_completion_interruptible( - &davinci_spi_dma->dma_rx_completion); - - if (t->tx_buf != NULL) - dma_unmap_single(NULL, t->tx_dma, count, DMA_TO_DEVICE); - else - dma_unmap_single(NULL, t->tx_dma, count + 1, DMA_TO_DEVICE); - - if (t->rx_buf != NULL) - dma_unmap_single(NULL, t->rx_dma, count, DMA_FROM_DEVICE); - - /* - * Check for bit error, desync error,parity error,timeout error and - * receive overflow errors - */ - int_status = ioread32(davinci_spi->base + SPIFLG); + clear_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKALL); + if (spi_cfg->io_type == SPI_IO_TYPE_DMA) { + dma_unmap_single(NULL, t->tx_dma, tx_buf_count, + DMA_TO_DEVICE); + dma_unmap_single(NULL, t->rx_dma, rx_buf_count, + DMA_FROM_DEVICE); + } - ret = davinci_spi_check_error(davinci_spi, int_status); - if (ret != 0) - return ret; + clear_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_SPIENA_MASK); + set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_POWERDOWN_MASK); - /* SPI Framework maintains the count only in bytes so convert back */ - davinci_spi->count *= conv; + if (davinci_spi->errors) { + ret = davinci_spi_check_error(davinci_spi, davinci_spi->errors); + if (ret != 0) + return ret; + } + if ((davinci_spi->rcount != 0) || (davinci_spi->wcount != 0)) { + sdev = davinci_spi->bitbang.master->dev.parent; + dev_info(sdev, "SPI data transfer error\n"); + return -EIO; + } return t->len; } @@ -844,28 +675,16 @@ static int davinci_spi_bufs_dma(struct spi_device *spi, struct spi_transfer *t) static irqreturn_t davinci_spi_irq(s32 irq, void *context_data) { struct davinci_spi *davinci_spi = context_data; - u32 int_status, rx_data = 0; - irqreturn_t ret = IRQ_NONE; + int status; - int_status = ioread32(davinci_spi->base + SPIFLG); + status = davinci_spi_process_events(davinci_spi); + if (unlikely(status != 0)) + clear_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKINT); - while ((int_status & SPIFLG_RX_INTR_MASK)) { - if (likely(int_status & SPIFLG_RX_INTR_MASK)) { - ret = IRQ_HANDLED; + if ((davinci_spi->rcount == 0) || (status != 0)) + complete(&(davinci_spi->done)); - rx_data = ioread32(davinci_spi->base + SPIBUF); - davinci_spi->get_rx(rx_data, davinci_spi); - - /* Disable Receive Interrupt */ - iowrite32(~(SPIINT_RX_INTR | SPIINT_TX_INTR), - davinci_spi->base + SPIINT); - } else - (void)davinci_spi_check_error(davinci_spi, int_status); - - int_status = ioread32(davinci_spi->base + SPIFLG); - } - - return ret; + return IRQ_HANDLED; } resource_size_t davinci_spi_get_dma_by_flag(struct platform_device *dev, @@ -906,6 +725,7 @@ static int davinci_spi_probe(struct platform_device *pdev) resource_size_t dma_tx_chan = DAVINCI_SPI_NO_RESOURCE; resource_size_t dma_eventq = DAVINCI_SPI_NO_RESOURCE; int i = 0, ret = 0; + u32 spipc0; pdata = pdev->dev.platform_data; if (pdata == NULL) { @@ -992,52 +812,23 @@ static int davinci_spi_probe(struct platform_device *pdev) davinci_spi->bitbang.chipselect = davinci_spi_chipselect; davinci_spi->bitbang.setup_transfer = davinci_spi_setup_transfer; + davinci_spi->bitbang.txrx_bufs = davinci_spi_txrx_bufs; davinci_spi->version = pdata->version; - use_dma = pdata->use_dma; davinci_spi->bitbang.flags = SPI_NO_CS | SPI_LSB_FIRST | SPI_LOOP; if (davinci_spi->version == SPI_VERSION_2) davinci_spi->bitbang.flags |= SPI_READY; - if (use_dma) { - dma_rx_chan = davinci_spi_get_dma_by_flag(pdev, - IORESOURCE_DMA_RX_CHAN); - dma_tx_chan = davinci_spi_get_dma_by_flag(pdev, - IORESOURCE_DMA_TX_CHAN); - dma_eventq = davinci_spi_get_dma_by_flag(pdev, - IORESOURCE_DMA_EVENT_Q); - } - - if (!use_dma || - dma_rx_chan == DAVINCI_SPI_NO_RESOURCE || - dma_tx_chan == DAVINCI_SPI_NO_RESOURCE || - dma_eventq == DAVINCI_SPI_NO_RESOURCE) { - davinci_spi->bitbang.txrx_bufs = davinci_spi_bufs_pio; - use_dma = 0; - } else { - davinci_spi->bitbang.txrx_bufs = davinci_spi_bufs_dma; - davinci_spi->dma_channels = kzalloc(master->num_chipselect - * sizeof(struct davinci_spi_dma), GFP_KERNEL); - if (davinci_spi->dma_channels == NULL) { - ret = -ENOMEM; - goto free_clk; - } - - for (i = 0; i < master->num_chipselect; i++) { - davinci_spi->dma_channels[i].dma_rx_channel = -1; - davinci_spi->dma_channels[i].dma_rx_sync_dev = - dma_rx_chan; - davinci_spi->dma_channels[i].dma_tx_channel = -1; - davinci_spi->dma_channels[i].dma_tx_sync_dev = - dma_tx_chan; - davinci_spi->dma_channels[i].eventq = dma_eventq; - } - dev_info(&pdev->dev, "DaVinci SPI driver in EDMA mode\n" - "Using RX channel = %d , TX channel = %d and " - "event queue = %d", dma_rx_chan, dma_tx_chan, - dma_eventq); - } + dma_rx_chan = davinci_spi_get_dma_by_flag(pdev, IORESOURCE_DMA_RX_CHAN); + dma_tx_chan = davinci_spi_get_dma_by_flag(pdev, IORESOURCE_DMA_TX_CHAN); + dma_eventq = davinci_spi_get_dma_by_flag(pdev, IORESOURCE_DMA_EVENT_Q); + davinci_spi->dma_channels.dma_rx_channel = -1; + davinci_spi->dma_channels.dma_rx_sync_dev = dma_rx_chan; + davinci_spi->dma_channels.dma_tx_channel = -1; + davinci_spi->dma_channels.dma_tx_sync_dev = dma_tx_chan; + davinci_spi->dma_channels.dummy_param_slot = -1; + davinci_spi->dma_channels.eventq = dma_eventq; davinci_spi->get_rx = davinci_spi_rx_buf_u8; davinci_spi->get_tx = davinci_spi_tx_buf_u8; @@ -1049,21 +840,22 @@ static int davinci_spi_probe(struct platform_device *pdev) udelay(100); iowrite32(1, davinci_spi->base + SPIGCR0); - /* Clock internal */ - if (davinci_spi->pdata->clk_internal) - set_io_bits(davinci_spi->base + SPIGCR1, - SPIGCR1_CLKMOD_MASK); - else - clear_io_bits(davinci_spi->base + SPIGCR1, - SPIGCR1_CLKMOD_MASK); + /* Set up SPIPC0. CS and ENA init is done in davinci_spi_setup */ + spipc0 = SPIPC0_DIFUN_MASK | SPIPC0_DOFUN_MASK | SPIPC0_CLKFUN_MASK; + iowrite32(spipc0, davinci_spi->base + SPIPC0); - /* master mode default */ - set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_MASTER_MASK); + /* initialize chip selects */ + if (pdata->chip_sel != NULL) { + for (i = 0; i < pdata->num_chipselect; i++) { + if (pdata->chip_sel[i] != SPI_INTERN_CS) + gpio_direction_output(pdata->chip_sel[i], 1); + } + } + iowrite32(SPIDEF_CSDEF_MASK, davinci_spi->base + SPIDEF); - if (davinci_spi->pdata->intr_level) - iowrite32(SPI_INTLVL_1, davinci_spi->base + SPILVL); - else - iowrite32(SPI_INTLVL_0, davinci_spi->base + SPILVL); + set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_CLKMOD_MASK); + set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_MASTER_MASK); + set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_POWERDOWN_MASK); ret = spi_bitbang_start(&davinci_spi->bitbang); if (ret != 0) @@ -1071,10 +863,6 @@ static int davinci_spi_probe(struct platform_device *pdev) dev_info(&pdev->dev, "Controller at 0x%p \n", davinci_spi->base); - if (!pdata->poll_mode) - dev_info(&pdev->dev, "Operating in interrupt mode" - " using IRQ %d\n", davinci_spi->irq); - return ret; free_clk: diff --git a/drivers/spi/davinci_spi.h b/drivers/spi/davinci_spi.h index 52acf47..462b2a2 100644 --- a/drivers/spi/davinci_spi.h +++ b/drivers/spi/davinci_spi.h @@ -19,8 +19,6 @@ #ifndef __DAVINCI_SPI_H #define __DAVINCI_SPI_H -#define SPI_MAX_CHIPSELECT 2 - #define CS_DEFAULT 0xFF #define SCS0_SELECT 0x01 #define SCS1_SELECT 0x02 @@ -41,9 +39,11 @@ #define SPIFMT_WDELAY_MASK 0x3f000000u #define SPIFMT_WDELAY_SHIFT 24 #define SPIFMT_CHARLEN_MASK 0x0000001Fu +#define SPIFMT_PRESCALE_SHIFT 8 /* SPIGCR1 */ -#define SPIGCR1_SPIENA_MASK 0x01000000u +#define SPIGCR1_SPIENA_MASK BIT(24) +#define SPIGCR1_POWERDOWN_MASK BIT(8) /* SPIPC0 */ #define SPIPC0_DIFUN_MASK BIT(11) /* MISO */ @@ -53,14 +53,16 @@ #define SPIPC0_EN1FUN_MASK BIT(1) #define SPIPC0_EN0FUN_MASK BIT(0) -#define SPIINT_MASKALL 0x0101035F +#define SPIINT_MASKALL 0x0101035Fu +#define SPIINT_MASKINT 0x0000035Fu #define SPI_INTLVL_1 0x000001FFu #define SPI_INTLVL_0 0x00000000u /* SPIDAT1 */ #define SPIDAT1_CSHOLD_MASK BIT(28) #define SPIDAT1_CSHOLD_SHIFT 28 -#define SPIDAT1_CSNR_MASK (BIT(17 | BIT(16)) +#define SPIDAT1_WDEL_MASK BIT(26) +#define SPIDAT1_CSNR_MASK 0x00FF0000u #define SPIDAT1_CSNR_SHIFT 16 #define SPIDAT1_DFSEL_MASK (BIT(24 | BIT(25)) #define SPIGCR1_CLKMOD_MASK BIT(1) @@ -71,6 +73,19 @@ #define SPIBUF_TXFULL_MASK BIT(29) #define SPIBUF_RXEMPTY_MASK BIT(31) +/* SPIDELAY */ +#define SPIDELAY_C2TDELAY_MASK 0xFF000000u +#define SPIDELAY_C2TDELAY_SHIFT 24 +#define SPIDELAY_T2CDELAY_MASK 0x00FF0000u +#define SPIDELAY_T2CDELAY_SHIFT 16 +#define SPIDELAY_T2EDELAY_MASK 0x0000FF00u +#define SPIDELAY_T2EDELAY_SHIFT 8 +#define SPIDELAY_C2EDELAY_MASK 0x000000FFu +#define SPIDELAY_C2EDELAY_SHIFT 0 + +/* SPIDEF */ +#define SPIDEF_CSDEF_MASK 0x000000FFu + /* Error Masks */ #define SPIFLG_DLEN_ERR_MASK BIT(0) #define SPIFLG_TIMEOUT_MASK BIT(1) @@ -81,11 +96,12 @@ #define SPIFLG_RX_INTR_MASK BIT(8) #define SPIFLG_TX_INTR_MASK BIT(9) #define SPIFLG_BUF_INIT_ACTIVE_MASK BIT(24) -#define SPIFLG_MASK (SPIFLG_DLEN_ERR_MASK \ +#define SPIFLG_ERROR_MASK (SPIFLG_DLEN_ERR_MASK \ | SPIFLG_TIMEOUT_MASK | SPIFLG_PARERR_MASK \ | SPIFLG_DESYNC_MASK | SPIFLG_BITERR_MASK \ - | SPIFLG_OVRRUN_MASK | SPIFLG_RX_INTR_MASK \ - | SPIFLG_TX_INTR_MASK \ + | SPIFLG_OVRRUN_MASK) +#define SPIFLG_MASK (SPIFLG_ERROR_MASK \ + | SPIFLG_RX_INTR_MASK | SPIFLG_TX_INTR_MASK \ | SPIFLG_BUF_INIT_ACTIVE_MASK) #define SPIINT_DLEN_ERR_INTR BIT(0) @@ -130,13 +146,6 @@ #define TGINTVEC0 0x60 #define TGINTVEC1 0x64 -struct davinci_spi_slave { - u32 cmd_to_write; - u32 clk_ctrl_to_write; - u32 bytes_per_word; - u8 active_cs; -}; - #define SPI_BUFSIZ (SMP_CACHE_BYTES + 1) /* We have 2 DMA channels per CS, one for RX and one for TX */ @@ -145,10 +154,8 @@ struct davinci_spi_dma { int dma_rx_channel; int dma_tx_sync_dev; int dma_rx_sync_dev; + int dummy_param_slot; enum dma_event_q eventq; - - struct completion dma_tx_completion; - struct completion dma_rx_completion; }; /* SPI Controller driver's private data. */ @@ -166,14 +173,14 @@ struct davinci_spi { const void *tx; void *rx; u8 *tmp_buf; - int count; - struct davinci_spi_dma *dma_channels; - struct davinci_spi_platform_data *pdata; + int rcount; + int wcount; + u32 errors; + struct davinci_spi_dma dma_channels; + struct davinci_spi_platform_data *pdata; void (*get_rx)(u32 rx_data, struct davinci_spi *); u32 (*get_tx)(struct davinci_spi *); - - struct davinci_spi_slave slave[SPI_MAX_CHIPSELECT]; }; #endif /* __DAVINCI_SPI_H */ -- 1.6.3.3 From bniebuhr3 at gmail.com Fri Mar 12 13:35:20 2010 From: bniebuhr3 at gmail.com (Brian Niebuhr) Date: Fri, 12 Mar 2010 13:35:20 -0600 Subject: [PATCH 2/2 v2] spi: modify davinci platform data for updated driver In-Reply-To: <1268422520-22642-2-git-send-email-bniebuhr@efjohnson.com> References: <1268422520-22642-1-git-send-email-bniebuhr@efjohnson.com> <1268422520-22642-2-git-send-email-bniebuhr@efjohnson.com> Message-ID: <1268422520-22642-3-git-send-email-bniebuhr@efjohnson.com> These changes update the davinci platform data to match the modifications that were done to the davinci spi controller driver. The driver update allowed per-device transfer settings, which are provided by this patch. Signed-off-by: Brian Niebuhr --- arch/arm/mach-davinci/board-dm355-evm.c | 10 ++++++++++ arch/arm/mach-davinci/board-dm355-leopard.c | 10 ++++++++++ arch/arm/mach-davinci/board-dm365-evm.c | 10 ++++++++++ arch/arm/mach-davinci/board-dm646x-evm.c | 12 ++++++++++++ arch/arm/mach-davinci/dm355.c | 7 ------- arch/arm/mach-davinci/dm365.c | 7 ------- arch/arm/mach-davinci/dm646x.c | 7 ------- 7 files changed, 42 insertions(+), 21 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c index a0724fa..b1a21a4 100644 --- a/arch/arm/mach-davinci/board-dm355-evm.c +++ b/arch/arm/mach-davinci/board-dm355-evm.c @@ -40,6 +40,7 @@ #include #include #include +#include #define DAVINCI_ASYNC_EMIF_CONTROL_BASE 0x01e10000 #define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 @@ -445,10 +446,19 @@ static struct spi_eeprom at25640a = { .flags = EE_ADDR2, }; +static struct davinci_spi_config at25640a_spi_cfg = { + .parity_enable = 0, + .intr_level = 0, + .io_type = SPI_IO_TYPE_DMA, + .wdelay = 0, + .timer_disable = 1, +}; + static struct spi_board_info dm355_evm_spi_info[] __initconst = { { .modalias = "at25", .platform_data = &at25640a, + .controller_data = &at25640a_spi_cfg, .max_speed_hz = 30 * 1000 * 1000, /* at 3v3 */ .bus_num = 0, .chip_select = 0, diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c index 84ad5d1..d87ff0b 100644 --- a/arch/arm/mach-davinci/board-dm355-leopard.c +++ b/arch/arm/mach-davinci/board-dm355-leopard.c @@ -36,6 +36,7 @@ #include #include #include +#include #define DAVINCI_ASYNC_EMIF_CONTROL_BASE 0x01e10000 #define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 @@ -232,10 +233,19 @@ static struct spi_eeprom at25640a = { .flags = EE_ADDR2, }; +struct davinci_spi_config at25640a_spi_cfg = { + .parity_enable = 0, + .intr_level = 0, + .io_type = SPI_IO_TYPE_DMA, + .wdelay = 0, + .timer_disable = 1, +}; + static struct spi_board_info dm355_leopard_spi_info[] __initconst = { { .modalias = "at25", .platform_data = &at25640a, + .controller_data = &at25640a_spi_cfg, .max_speed_hz = 10 * 1000 * 1000, /* at 3v3 */ .bus_num = 0, .chip_select = 0, diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c index ab3b0e2..8559c84 100644 --- a/arch/arm/mach-davinci/board-dm365-evm.c +++ b/arch/arm/mach-davinci/board-dm365-evm.c @@ -44,6 +44,7 @@ #include #include #include +#include #include #include #include @@ -832,10 +833,19 @@ static struct spi_eeprom at25640 = { .flags = EE_ADDR2, }; +static struct davinci_spi_config at25640_spi_cfg = { + .parity_enable = 0, + .intr_level = 0, + .io_type = SPI_IO_TYPE_DMA, + .wdelay = 0, + .timer_disable = 1, +}; + static struct spi_board_info dm365_evm_spi_info[] __initconst = { { .modalias = "at25", .platform_data = &at25640, + .controller_data = &at25640_spi_cfg, .max_speed_hz = 20 * 1000 * 1000, /* at 3v3 */ .bus_num = 0, .chip_select = 0, diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c index 94271a6..5430b00 100644 --- a/arch/arm/mach-davinci/board-dm646x-evm.c +++ b/arch/arm/mach-davinci/board-dm646x-evm.c @@ -58,6 +58,7 @@ #include #include #include +#include #include #include "clock.h" @@ -911,10 +912,21 @@ static struct spi_eeprom at25640a = { .flags = EE_ADDR2, }; +static struct davinci_spi_config at25640a_spi_cfg = { + .parity_enable = 0, + .intr_level = 0, + .io_type = SPI_IO_TYPE_DMA, + .wdelay = 0, + .timer_disable = 0, + .c2t_delay = 8, + .t2c_delay = 8, +}; + static struct spi_board_info dm646x_evm_spi_info[] __initconst = { { .modalias = "at25", .platform_data = &at25640a, + .controller_data = &at25640a_spi_cfg, .max_speed_hz = 10 * 1000 * 1000, /* at 3v3 */ .bus_num = 0, .chip_select = 0, diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c index 6925242..90d1fda 100644 --- a/arch/arm/mach-davinci/dm355.c +++ b/arch/arm/mach-davinci/dm355.c @@ -418,13 +418,6 @@ static struct resource dm355_spi0_resources[] = { static struct davinci_spi_platform_data dm355_spi0_pdata = { .version = SPI_VERSION_1, .num_chipselect = 2, - .clk_internal = 1, - .cs_hold = 1, - .intr_level = 0, - .poll_mode = 1, /* 0 -> interrupt mode 1-> polling mode */ - .use_dma = 1, /* when 1, value in poll_mode is ignored */ - .c2tdelay = 0, - .t2cdelay = 0, }; static struct platform_device dm355_spi0_device = { diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index ed6c9c7..600dab5 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -621,13 +621,6 @@ static u64 dm365_spi0_dma_mask = DMA_BIT_MASK(32); static struct davinci_spi_platform_data dm365_spi0_pdata = { .version = SPI_VERSION_1, .num_chipselect = 2, - .clk_internal = 1, - .cs_hold = 1, - .intr_level = 0, - .poll_mode = 1, /* 0 -> interrupt mode 1-> polling mode */ - .use_dma = 1, /* when 1, value in poll_mode is ignored */ - .c2tdelay = 0, - .t2cdelay = 0, }; static struct resource dm365_spi0_resources[] = { diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index efb4863..f9b49cb 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -387,13 +387,6 @@ static u64 dm646x_spi0_dma_mask = DMA_BIT_MASK(32); static struct davinci_spi_platform_data dm646x_spi0_pdata = { .version = SPI_VERSION_1, .num_chipselect = 2, - .clk_internal = 1, - .cs_hold = 1, - .intr_level = 0, - .poll_mode = 1, /* 0 -> interrupt mode 1-> polling mode */ - .use_dma = 1, /* when 1, value in poll_mode is ignored */ - .c2tdelay = 8, - .t2cdelay = 8, }; static struct resource dm646x_spi0_resources[] = { -- 1.6.3.3 From khilman at deeprootsystems.com Fri Mar 12 16:18:12 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Fri, 12 Mar 2010 14:18:12 -0800 Subject: Custom pinmuxing on DM355 with git kernel In-Reply-To: (Sekhar Nori's message of "Thu\, 11 Mar 2010 12\:37\:00 +0530") References: <2992BF78ED49594EB72AD7F4F8642BBDF5E974@RL-SBS.racelogic.local> Message-ID: <87sk856v6j.fsf@deeprootsystems.com> "Nori, Sekhar" writes: > On Thu, Mar 11, 2010 at 11:45:47, Jon Povey wrote: >> Steve Chen wrote: >> > On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey >> > wrote: >> >> >> We have 3 different boards using DM355, with different gpio / pinmux >> >> setups. So far, our device drivers are modules which fiddle the >> >> pinmux registers directly. >> >> >> At the moment I am thinking that I might want to split up >> >> davinci_cfg_reg into two functions so it's not hardwired to >> >> soc_info->pinmux_pins, and I could pass my own mux_config structs >> >> in. If this is of interest I can have a go at doing this and >> >> submitting the patch here. >> > >> > For board specific pinmux, you can put them in board-dm355-*.c. >> > There are some board specific pinmux setup in board-da830-evm.c. >> > Look for da8xx_pinmux_setup. >> >> Thanks, I see this. I have also been looking at the gpiolib support and >> something like that would be useful. >> >> At minimum it would be helpful to split out the davinci_cfg_reg stuff as >> described above so that driver modules can use the same functions. > > Methods of handing pinmux were debated at length on this list. I think this > thread captures most of it: > > http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg11281.html > > It's a long thread, but very useful read. > > I don't think having drivers handle pinmux directly is acc