From rohan_javed at yahoo.co.uk Fri Jan 1 01:58:28 2010 From: rohan_javed at yahoo.co.uk (rohan tabish) Date: Thu, 31 Dec 2009 23:58:28 -0800 (PST) Subject: Configuring VLYNQ interface? Message-ID: <250143.33686.qm@web24103.mail.ird.yahoo.com> Hello everyone i want to enable the VLYNQ interface for the open source git kernel but make menuconfig under Device Driver under TI VLYNQ(EMPTY) Regard's Rohan Tabish -------------- next part -------------- An HTML attachment was scrubbed... URL: From swami.iyer at ti.com Fri Jan 1 07:10:02 2010 From: swami.iyer at ti.com (Subbrathnam, Swaminathan) Date: Fri, 1 Jan 2010 18:40:02 +0530 Subject: USB storage error In-Reply-To: <03A2FA9E0D3DC841992E682BF528771801747AD2@lipwig.Cernium.local> References: <03A2FA9E0D3DC841992E682BF528771801747AD2@lipwig.Cernium.local> Message-ID: Gopala, Could you try the latest DaVinci Git. It works for me. regards swami ________________________________ From: davinci-linux-open-source-bounces at linux.davincidsp.com [davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Gopala Gottumukkala [ggottumu at Cernium.com] Sent: Friday, January 01, 2010 1:38 AM To: davinci-linux-open-source at linux.davincidsp.com Subject: USB storage error I have compiled davinci 2.6.30 I mounted the usb manually I ran some sample program which will open, write and delete the file into usb drive. While writing the file into usb drive. It gives the following error and the program dies. Any help would be appreciated on this usb 1-1: reset high speed USB device using musb_hdrc and address 2 usb 1-1: reset high speed USB device using musb_hdrc and address 2 usb 1-1: reset high speed USB device using musb_hdrc and address 2 sd 0:0:0:0: Device offlined - not ready after error recovery sd 0:0:0:0: [sda] Unhandled error code sd 0:0:0:0: [sda] Result: hostbyte=0x05 driverbyte=0x00 end_request: I/O error, dev sda, sector 41584 sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: [sda] Unhandled error code sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sda, sector 40000 sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device - Gopala NOTICE: The information contained in this email and any document attached hereto is intended only for the named recipient(s). It is the property of Cernium Corporation and shall not be used, disclosed or reproduced without the express written consent of Cernium Corporation. If you are not the intended recipient (or the employee or agent responsible for delivering this message in confidence to the intended recipient(s)), you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this transmittal or its attachments is strictly prohibited. If you have received this transmittal and/or attachments in error, please notify me immediately by reply email or telephone and immediately delete this message and all its attachments. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at felipebalbi.com Fri Jan 1 08:46:09 2010 From: me at felipebalbi.com (Felipe Balbi) Date: Fri, 01 Jan 2010 16:46:09 +0200 Subject: USB storage error In-Reply-To: References: <03A2FA9E0D3DC841992E682BF528771801747AD2@lipwig.Cernium.local> Message-ID: <1262357169.17250.31.camel@gandalf> Hi, On Fri, 2010-01-01 at 18:40 +0530, Subbrathnam, Swaminathan wrote > usb 1-1: reset high speed USB device using musb_hdrc and address 2 > > usb 1-1: reset high speed USB device using musb_hdrc and address 2 > > usb 1-1: reset high speed USB device using musb_hdrc and address 2 > > sd 0:0:0:0: Device offlined - not ready after error recovery > > sd 0:0:0:0: [sda] Unhandled error code > > sd 0:0:0:0: [sda] Result: hostbyte=0x05 driverbyte=0x00 > > end_request: I/O error, dev sda, sector 41584 > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: [sda] Unhandled error code > > sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00 > > end_request: I/O error, dev sda, sector 40000 > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device could it be overcurrent protection ? I remember seen something similar with a few storage devices. While doing i/o power consumption goes higher. Would be nice to see what happens if you measure the current consumed on the bus when the problem happens. > NOTICE: The information contained in this email and any document > attached hereto is intended only for the named recipient(s). It is the > property of Cernium Corporation and shall not be used, disclosed or > reproduced without the express written consent of Cernium Corporation. > If you are not the intended recipient (or the employee or agent > responsible for delivering this message in confidence to the intended > recipient(s)), you are hereby notified that you have received this > transmittal in error, and any review, dissemination, distribution or > copying of this transmittal or its attachments is strictly prohibited. > If you have received this transmittal and/or attachments in error, > please notify me immediately by reply email or telephone and > immediately delete this message and all its attachments. Thank you. when sending mails to the list, be sure to remove this. It forbids mail archives when it says it shouldn't be reproduced. -- balbi From rohan_javed at yahoo.co.uk Mon Jan 4 00:50:31 2010 From: rohan_javed at yahoo.co.uk (rohan tabish) Date: Sun, 3 Jan 2010 22:50:31 -0800 (PST) Subject: VLYNQ:Problem in git kernel Message-ID: <812667.9745.qm@web24107.mail.ird.yahoo.com> Hello everyone i am using open source code from git kernel when i configure the VLYNQ at kernel compilation get the following errors *************************************************************************************************** ?CC????? drivers/vlynq/vlynq.o drivers/vlynq/vlynq.c: In function 'vlynq_irq_unmask': drivers/vlynq/vlynq.c:139: error: implicit declaration of function 'get_irq_chip_data' drivers/vlynq/vlynq.c:139: warning: initialization makes pointer from integer without a cast drivers/vlynq/vlynq.c: In function 'vlynq_irq_mask': drivers/vlynq/vlynq.c:152: warning: initialization makes pointer from integer without a cast drivers/vlynq/vlynq.c: In function 'vlynq_irq_type': drivers/vlynq/vlynq.c:165: warning: initialization makes pointer from integer without a cast drivers/vlynq/vlynq.c:171: error: 'IRQ_TYPE_SENSE_MASK' undeclared (first use in this function) drivers/vlynq/vlynq.c:171: error: (Each undeclared identifier is reported only once drivers/vlynq/vlynq.c:171: error: for each function it appears in.) drivers/vlynq/vlynq.c:172: error: 'IRQ_TYPE_EDGE_RISING' undeclared (first use in this function) drivers/vlynq/vlynq.c:173: error: 'IRQ_TYPE_EDGE_FALLING' undeclared (first use in this function) drivers/vlynq/vlynq.c:174: error: 'IRQ_TYPE_EDGE_BOTH' undeclared (first use in this function) drivers/vlynq/vlynq.c:178: error: 'IRQ_TYPE_LEVEL_HIGH' undeclared (first use in this function) drivers/vlynq/vlynq.c:182: error: 'IRQ_TYPE_LEVEL_LOW' undeclared (first use in this function) drivers/vlynq/vlynq.c: In function 'vlynq_local_ack': drivers/vlynq/vlynq.c:195: warning: initialization makes pointer from integer without a cast drivers/vlynq/vlynq.c: In function 'vlynq_remote_ack': drivers/vlynq/vlynq.c:206: warning: initialization makes pointer from integer without a cast drivers/vlynq/vlynq.c: In function 'vlynq_irq': drivers/vlynq/vlynq.c:225: error: implicit declaration of function 'spurious_interrupt' drivers/vlynq/vlynq.c:229: error: implicit declaration of function 'do_IRQ' drivers/vlynq/vlynq.c: At top level: drivers/vlynq/vlynq.c:237: error: variable 'vlynq_irq_chip' has initializer but incomplete type drivers/vlynq/vlynq.c:238: error: unknown field 'name' specified in initializer drivers/vlynq/vlynq.c:238: warning: excess elements in struct initializer drivers/vlynq/vlynq.c:238: warning: (near initialization for 'vlynq_irq_chip') drivers/vlynq/vlynq.c:239: error: unknown field 'unmask' specified in initializer drivers/vlynq/vlynq.c:239: warning: excess elements in struct initializer drivers/vlynq/vlynq.c:239: warning: (near initialization for 'vlynq_irq_chip') drivers/vlynq/vlynq.c:240: error: unknown field 'mask' specified in initializer drivers/vlynq/vlynq.c:240: warning: excess elements in struct initializer drivers/vlynq/vlynq.c:240: warning: (near initialization for 'vlynq_irq_chip') drivers/vlynq/vlynq.c:241: error: unknown field 'set_type' specified in initializer drivers/vlynq/vlynq.c:241: warning: excess elements in struct initializer drivers/vlynq/vlynq.c:241: warning: (near initialization for 'vlynq_irq_chip') drivers/vlynq/vlynq.c:244: error: variable 'vlynq_local_chip' has initializer but incomplete type drivers/vlynq/vlynq.c:245: error: unknown field 'name' specified in initializer drivers/vlynq/vlynq.c:245: warning: excess elements in struct initializer drivers/vlynq/vlynq.c:245: warning: (near initialization for 'vlynq_local_chip') drivers/vlynq/vlynq.c:246: error: unknown field 'unmask' specified in initializer drivers/vlynq/vlynq.c:246: warning: excess elements in struct initializer drivers/vlynq/vlynq.c:246: warning: (near initialization for 'vlynq_local_chip') drivers/vlynq/vlynq.c:247: error: unknown field 'mask' specified in initializer drivers/vlynq/vlynq.c:247: warning: excess elements in struct initializer drivers/vlynq/vlynq.c:247: warning: (near initialization for 'vlynq_local_chip') drivers/vlynq/vlynq.c:248: error: unknown field 'ack' specified in initializer drivers/vlynq/vlynq.c:248: warning: excess elements in struct initializer drivers/vlynq/vlynq.c:248: warning: (near initialization for 'vlynq_local_chip') drivers/vlynq/vlynq.c:251: error: variable 'vlynq_remote_chip' has initializer but incomplete type drivers/vlynq/vlynq.c:252: error: unknown field 'name' specified in initializer drivers/vlynq/vlynq.c:252: warning: excess elements in struct initializer drivers/vlynq/vlynq.c:252: warning: (near initialization for 'vlynq_remote_chip') drivers/vlynq/vlynq.c:253: error: unknown field 'unmask' specified in initializer drivers/vlynq/vlynq.c:253: warning: excess elements in struct initializer drivers/vlynq/vlynq.c:253: warning: (near initialization for 'vlynq_remote_chip') drivers/vlynq/vlynq.c:254: error: unknown field 'mask' specified in initializer drivers/vlynq/vlynq.c:254: warning: excess elements in struct initializer drivers/vlynq/vlynq.c:254: warning: (near initialization for 'vlynq_remote_chip') drivers/vlynq/vlynq.c:255: error: unknown field 'ack' specified in initializer drivers/vlynq/vlynq.c:255: warning: excess elements in struct initializer drivers/vlynq/vlynq.c:255: warning: (near initialization for 'vlynq_remote_chip') drivers/vlynq/vlynq.c: In function 'vlynq_setup_irq': drivers/vlynq/vlynq.c:292: error: implicit declaration of function 'set_irq_chip_and_handler' drivers/vlynq/vlynq.c:293: error: 'handle_level_irq' undeclared (first use in this function) drivers/vlynq/vlynq.c:294: error: implicit declaration of function 'set_irq_chip_data' drivers/vlynq/vlynq.c:301: error: 'handle_simple_irq' undeclared (first use in this function) make[2]: *** [drivers/vlynq/vlynq.o] Error 1 make[1]: *** [drivers/vlynq] Error 2 make: *** [drivers] Error 2 ***************************************************************************************************** aNY ONE KNOWS HOW TO RESOLVE THIS ISSUE Regard's Rohan Tabish -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsekhar at ti.com Mon Jan 4 01:03:41 2010 From: nsekhar at ti.com (Nori, Sekhar) Date: Mon, 4 Jan 2010 12:33:41 +0530 Subject: VLYNQ:Problem in git kernel In-Reply-To: <812667.9745.qm@web24107.mail.ird.yahoo.com> References: <812667.9745.qm@web24107.mail.ird.yahoo.com> Message-ID: On Mon, Jan 04, 2010 at 12:20:31, rohan tabish wrote: > Hello everyone i am using open source code from git kernel when i > configure the VLYNQ at kernel compilation get the following errors Hi Rohan, This driver has been verified on TI's AR7 platform by openWRT guys. I don't know of anyone who has tried it on a DaVinci platform so far. That said, driver failing to compile altogether seems bad. You can contact the list provided in the MAINTAINERS file for help on this. VLYNQ BUS M: Florian Fainelli L: openwrt-devel at lists.openwrt.org S: Maintained F: drivers/vlynq/vlynq.c F: include/linux/vlynq.h Thanks, Sekhar From elbertshiang at yahoo.com Mon Jan 4 03:16:09 2010 From: elbertshiang at yahoo.com (elbert shiang) Date: Mon, 4 Jan 2010 01:16:09 -0800 (PST) Subject: Davinci-linux-open-source Digest, Vol 49, Issue 2 In-Reply-To: Message-ID: <584755.36549.qm@web81207.mail.mud.yahoo.com> Hi, Dear All: ? Is anyone can tell me how to start to read/write a Ethernet port for DM355? What is the documentation I should refer to? ? Thanks, Elbert --- On Fri, 1/1/10, davinci-linux-open-source-request at linux.davincidsp.com wrote: From: davinci-linux-open-source-request at linux.davincidsp.com Subject: Davinci-linux-open-source Digest, Vol 49, Issue 2 To: davinci-linux-open-source at linux.davincidsp.com Date: Friday, January 1, 2010, 10:00 AM Send Davinci-linux-open-source mailing list submissions to ??? davinci-linux-open-source at linux.davincidsp.com To subscribe or unsubscribe via the World Wide Web, visit ??? http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source or, via email, send a message with subject or body 'help' to ??? davinci-linux-open-source-request at linux.davincidsp.com You can reach the person managing the list at ??? davinci-linux-open-source-owner at linux.davincidsp.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Davinci-linux-open-source digest..." Today's Topics: ???1. RE: USB storage error (Felipe Balbi) ---------------------------------------------------------------------- Message: 1 Date: Fri, 01 Jan 2010 16:46:09 +0200 From: Felipe Balbi To: "Subbrathnam, Swaminathan" Cc: "davinci-linux-open-source at linux.davincidsp.com" ??? Subject: RE: USB storage error Message-ID: <1262357169.17250.31.camel at gandalf> Content-Type: text/plain; charset="UTF-8" Hi, On Fri, 2010-01-01 at 18:40 +0530, Subbrathnam, Swaminathan wrote > usb 1-1: reset high speed USB device using musb_hdrc and address 2 > > usb 1-1: reset high speed USB device using musb_hdrc and address 2 > > usb 1-1: reset high speed USB device using musb_hdrc and address 2 > > sd 0:0:0:0: Device offlined - not ready after error recovery > > sd 0:0:0:0: [sda] Unhandled error code > > sd 0:0:0:0: [sda] Result: hostbyte=0x05 driverbyte=0x00 > > end_request: I/O error, dev sda, sector 41584 > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: [sda] Unhandled error code > > sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00 > > end_request: I/O error, dev sda, sector 40000 > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device could it be overcurrent protection ? I remember seen something similar with a few storage devices. While doing i/o power consumption goes higher. Would be nice to see what happens if you measure the current consumed on the bus when the problem happens. > NOTICE: The information contained in this email and any document > attached hereto is intended only for the named recipient(s). It is the > property of Cernium Corporation and shall not be used, disclosed or > reproduced without the express written consent of Cernium Corporation. > If you are not the intended recipient (or the employee or agent > responsible for delivering this message in confidence to the intended > recipient(s)), you are hereby notified that you have received this > transmittal in error, and any review, dissemination, distribution or > copying of this transmittal or its attachments is strictly prohibited. > If you have received this transmittal and/or attachments in error, > please notify me immediately by reply email or telephone and > immediately delete this message and all its attachments. Thank you. when sending mails to the list, be sure to remove this. It forbids mail archives when it says it shouldn't be reproduced. -- balbi ------------------------------ _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source at linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source End of Davinci-linux-open-source Digest, Vol 49, Issue 2 ******************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvaibhav at ti.com Mon Jan 4 08:02:53 2010 From: hvaibhav at ti.com (hvaibhav at ti.com) Date: Mon, 4 Jan 2010 19:32:53 +0530 Subject: [PATCH 0/9] Feature enhancement of VPFE/CCDC Capture driver In-Reply-To: References: Message-ID: <1262613782-20463-1-git-send-email-hvaibhav@ti.com> From: Vaibhav Hiremath While adding support for AM3517/05 devices I have implemented/came-across these features/enhancement/bug-fixes for VPFE-Capture driver. Also the important change added is, to introduced "ti-media" directory for all TI devices. Vaibhav Hiremath (9): Makfile:Removed duplicate entry of davinci TVP514x:Switch to automode for querystd tvp514x: add YUYV format support Introducing ti-media directory DMx:Update board files for ti-media directory change Davinci VPFE Capture:Return 0 from suspend/resume DM644x CCDC : Add Suspend/Resume Support VPFE Capture: Add call back function for interrupt clear to vpfe_cfg DM644x CCDC: Add 10bit BT support arch/arm/mach-davinci/include/mach/dm355.h | 2 +- arch/arm/mach-davinci/include/mach/dm644x.h | 2 +- drivers/media/video/Kconfig | 84 +- drivers/media/video/Makefile | 4 +- drivers/media/video/davinci/Makefile | 17 - drivers/media/video/davinci/ccdc_hw_device.h | 110 -- drivers/media/video/davinci/dm355_ccdc.c | 1081 ----------- drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ---- drivers/media/video/davinci/dm644x_ccdc.c | 966 ---------- drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 -- drivers/media/video/davinci/vpfe_capture.c | 2055 --------------------- drivers/media/video/davinci/vpif.c | 296 --- drivers/media/video/davinci/vpif.h | 642 ------- drivers/media/video/davinci/vpif_capture.c | 2168 ----------------------- drivers/media/video/davinci/vpif_capture.h | 165 -- drivers/media/video/davinci/vpif_display.c | 1654 ----------------- drivers/media/video/davinci/vpif_display.h | 175 -- drivers/media/video/davinci/vpss.c | 301 ---- drivers/media/video/ti-media/Kconfig | 88 + drivers/media/video/ti-media/Makefile | 17 + drivers/media/video/ti-media/ccdc_hw_device.h | 110 ++ drivers/media/video/ti-media/dm355_ccdc.c | 1081 +++++++++++ drivers/media/video/ti-media/dm355_ccdc_regs.h | 310 ++++ drivers/media/video/ti-media/dm644x_ccdc.c | 1090 ++++++++++++ drivers/media/video/ti-media/dm644x_ccdc_regs.h | 153 ++ drivers/media/video/ti-media/vpfe_capture.c | 2067 +++++++++++++++++++++ drivers/media/video/ti-media/vpif.c | 296 +++ drivers/media/video/ti-media/vpif.h | 642 +++++++ drivers/media/video/ti-media/vpif_capture.c | 2168 +++++++++++++++++++++++ drivers/media/video/ti-media/vpif_capture.h | 165 ++ drivers/media/video/ti-media/vpif_display.c | 1654 +++++++++++++++++ drivers/media/video/ti-media/vpif_display.h | 175 ++ drivers/media/video/ti-media/vpss.c | 301 ++++ drivers/media/video/tvp514x.c | 15 + include/media/davinci/ccdc_types.h | 43 - include/media/davinci/dm355_ccdc.h | 321 ---- include/media/davinci/dm644x_ccdc.h | 184 -- include/media/davinci/vpfe_capture.h | 200 --- include/media/davinci/vpfe_types.h | 51 - include/media/davinci/vpss.h | 69 - include/media/ti-media/ccdc_types.h | 43 + include/media/ti-media/dm355_ccdc.h | 321 ++++ include/media/ti-media/dm644x_ccdc.h | 184 ++ include/media/ti-media/vpfe_capture.h | 202 +++ include/media/ti-media/vpfe_types.h | 51 + include/media/ti-media/vpss.h | 69 + 46 files changed, 11207 insertions(+), 11040 deletions(-) delete mode 100644 drivers/media/video/davinci/Makefile delete mode 100644 drivers/media/video/davinci/ccdc_hw_device.h delete mode 100644 drivers/media/video/davinci/dm355_ccdc.c delete mode 100644 drivers/media/video/davinci/dm355_ccdc_regs.h delete mode 100644 drivers/media/video/davinci/dm644x_ccdc.c delete mode 100644 drivers/media/video/davinci/dm644x_ccdc_regs.h delete mode 100644 drivers/media/video/davinci/vpfe_capture.c delete mode 100644 drivers/media/video/davinci/vpif.c delete mode 100644 drivers/media/video/davinci/vpif.h delete mode 100644 drivers/media/video/davinci/vpif_capture.c delete mode 100644 drivers/media/video/davinci/vpif_capture.h delete mode 100644 drivers/media/video/davinci/vpif_display.c delete mode 100644 drivers/media/video/davinci/vpif_display.h delete mode 100644 drivers/media/video/davinci/vpss.c create mode 100644 drivers/media/video/ti-media/Kconfig create mode 100644 drivers/media/video/ti-media/Makefile create mode 100644 drivers/media/video/ti-media/ccdc_hw_device.h create mode 100644 drivers/media/video/ti-media/dm355_ccdc.c create mode 100644 drivers/media/video/ti-media/dm355_ccdc_regs.h create mode 100644 drivers/media/video/ti-media/dm644x_ccdc.c create mode 100644 drivers/media/video/ti-media/dm644x_ccdc_regs.h create mode 100644 drivers/media/video/ti-media/vpfe_capture.c create mode 100644 drivers/media/video/ti-media/vpif.c create mode 100644 drivers/media/video/ti-media/vpif.h create mode 100644 drivers/media/video/ti-media/vpif_capture.c create mode 100644 drivers/media/video/ti-media/vpif_capture.h create mode 100644 drivers/media/video/ti-media/vpif_display.c create mode 100644 drivers/media/video/ti-media/vpif_display.h create mode 100644 drivers/media/video/ti-media/vpss.c delete mode 100644 include/media/davinci/ccdc_types.h delete mode 100644 include/media/davinci/dm355_ccdc.h delete mode 100644 include/media/davinci/dm644x_ccdc.h delete mode 100644 include/media/davinci/vpfe_capture.h delete mode 100644 include/media/davinci/vpfe_types.h delete mode 100644 include/media/davinci/vpss.h create mode 100644 include/media/ti-media/ccdc_types.h create mode 100644 include/media/ti-media/dm355_ccdc.h create mode 100644 include/media/ti-media/dm644x_ccdc.h create mode 100644 include/media/ti-media/vpfe_capture.h create mode 100644 include/media/ti-media/vpfe_types.h create mode 100644 include/media/ti-media/vpss.h From hvaibhav at ti.com Mon Jan 4 08:02:55 2010 From: hvaibhav at ti.com (hvaibhav at ti.com) Date: Mon, 4 Jan 2010 19:32:55 +0530 Subject: [PATCH 2/9] TVP514x:Switch to automode for querystd In-Reply-To: References: Message-ID: <1262613782-20463-3-git-send-email-hvaibhav@ti.com> From: Vaibhav Hiremath Driver should switch to AutoSwitch mode on QUERYSTD ioctls. It has been observed that, if user configure the standard explicitely then driver preserves the old settings, but query_std must detect the standard instead of returning old settings. Signed-off-by: Vaibhav Hiremath --- drivers/media/video/tvp514x.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c index 26b4e71..4cf3593 100644 --- a/drivers/media/video/tvp514x.c +++ b/drivers/media/video/tvp514x.c @@ -523,10 +523,18 @@ static int tvp514x_querystd(struct v4l2_subdev *sd, v4l2_std_id *std_id) enum tvp514x_std current_std; enum tvp514x_input input_sel; u8 sync_lock_status, lock_mask; + int err; if (std_id == NULL) return -EINVAL; + err = tvp514x_write_reg(sd, REG_VIDEO_STD, + VIDEO_STD_AUTO_SWITCH_BIT); + if (err < 0) + return err; + + msleep(LOCK_RETRY_DELAY); + /* get the current standard */ current_std = tvp514x_get_current_std(sd); if (current_std == STD_INVALID) -- 1.6.2.4 From hvaibhav at ti.com Mon Jan 4 08:02:54 2010 From: hvaibhav at ti.com (hvaibhav at ti.com) Date: Mon, 4 Jan 2010 19:32:54 +0530 Subject: [PATCH 1/9] Makfile:Removed duplicate entry of davinci In-Reply-To: References: Message-ID: <1262613782-20463-2-git-send-email-hvaibhav@ti.com> From: Vaibhav Hiremath Signed-off-by: Vaibhav Hiremath --- drivers/media/video/Makefile | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 2af68ee..bebbee6 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -158,8 +158,6 @@ obj-$(CONFIG_VIDEO_MX3) += mx3_camera.o obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o -obj-$(CONFIG_ARCH_DAVINCI) += davinci/ - obj-$(CONFIG_VIDEO_AU0828) += au0828/ obj-$(CONFIG_USB_VIDEO_CLASS) += uvc/ -- 1.6.2.4 From hvaibhav at ti.com Mon Jan 4 08:02:56 2010 From: hvaibhav at ti.com (hvaibhav at ti.com) Date: Mon, 4 Jan 2010 19:32:56 +0530 Subject: [PATCH 3/9] tvp514x: add YUYV format support In-Reply-To: References: Message-ID: <1262613782-20463-4-git-send-email-hvaibhav@ti.com> From: Vaibhav Hiremath Signed-off-by: Vaibhav Hiremath --- drivers/media/video/tvp514x.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c index 4cf3593..b344b58 100644 --- a/drivers/media/video/tvp514x.c +++ b/drivers/media/video/tvp514x.c @@ -212,6 +212,13 @@ static const struct v4l2_fmtdesc tvp514x_fmt_list[] = { .description = "8-bit UYVY 4:2:2 Format", .pixelformat = V4L2_PIX_FMT_UYVY, }, + { + .index = 1, + .type = V4L2_BUF_TYPE_VIDEO_CAPTURE, + .flags = 0, + .description = "8-bit YUYV 4:2:2 Format", + .pixelformat = V4L2_PIX_FMT_YUYV, + }, }; /** -- 1.6.2.4 From hvaibhav at ti.com Mon Jan 4 08:02:58 2010 From: hvaibhav at ti.com (hvaibhav at ti.com) Date: Mon, 4 Jan 2010 19:32:58 +0530 Subject: [PATCH 5/9] DMx:Update board files for ti-media directory change In-Reply-To: References: Message-ID: <1262613782-20463-6-git-send-email-hvaibhav@ti.com> From: Vaibhav Hiremath Signed-off-by: Vaibhav Hiremath --- arch/arm/mach-davinci/include/mach/dm355.h | 2 +- arch/arm/mach-davinci/include/mach/dm644x.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-davinci/include/mach/dm355.h b/arch/arm/mach-davinci/include/mach/dm355.h index 85536d8..ffba662 100644 --- a/arch/arm/mach-davinci/include/mach/dm355.h +++ b/arch/arm/mach-davinci/include/mach/dm355.h @@ -13,7 +13,7 @@ #include #include -#include +#include #define ASP1_TX_EVT_EN 1 #define ASP1_RX_EVT_EN 2 diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h b/arch/arm/mach-davinci/include/mach/dm644x.h index 44e8f0f..95f1e65 100644 --- a/arch/arm/mach-davinci/include/mach/dm644x.h +++ b/arch/arm/mach-davinci/include/mach/dm644x.h @@ -25,7 +25,7 @@ #include #include #include -#include +#include #define DM644X_EMAC_BASE (0x01C80000) #define DM644X_EMAC_CNTRL_OFFSET (0x0000) -- 1.6.2.4 From hvaibhav at ti.com Mon Jan 4 08:02:59 2010 From: hvaibhav at ti.com (hvaibhav at ti.com) Date: Mon, 4 Jan 2010 19:32:59 +0530 Subject: [PATCH 6/9] Davinci VPFE Capture:Return 0 from suspend/resume In-Reply-To: References: Message-ID: <1262613782-20463-7-git-send-email-hvaibhav@ti.com> From: Vaibhav Hiremath Now Suspend/Resume functionality is being handled by respective CCDC code, so return true (0) from bridge suspend/resume function. Signed-off-by: Vaibhav Hiremath --- drivers/media/video/ti-media/vpfe_capture.c | 12 ++++-------- 1 files changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/media/video/ti-media/vpfe_capture.c b/drivers/media/video/ti-media/vpfe_capture.c index 3257d26..7187eaa 100644 --- a/drivers/media/video/ti-media/vpfe_capture.c +++ b/drivers/media/video/ti-media/vpfe_capture.c @@ -2007,18 +2007,14 @@ static int vpfe_remove(struct platform_device *pdev) return 0; } -static int -vpfe_suspend(struct device *dev) +static int vpfe_suspend(struct device *dev) { - /* add suspend code here later */ - return -1; + return 0; } -static int -vpfe_resume(struct device *dev) +static int vpfe_resume(struct device *dev) { - /* add resume code here later */ - return -1; + return 0; } static const struct dev_pm_ops vpfe_dev_pm_ops = { -- 1.6.2.4 From hvaibhav at ti.com Mon Jan 4 08:03:00 2010 From: hvaibhav at ti.com (hvaibhav at ti.com) Date: Mon, 4 Jan 2010 19:33:00 +0530 Subject: [PATCH 7/9] DM644x CCDC : Add Suspend/Resume Support In-Reply-To: References: Message-ID: <1262613782-20463-8-git-send-email-hvaibhav@ti.com> From: Vaibhav Hiremath Signed-off-by: Vaibhav Hiremath --- drivers/media/video/ti-media/dm644x_ccdc.c | 114 +++++++++++++++++++++++ drivers/media/video/ti-media/dm644x_ccdc_regs.h | 2 +- 2 files changed, 115 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/ti-media/dm644x_ccdc.c b/drivers/media/video/ti-media/dm644x_ccdc.c index 8b5d4c5..b762f99 100644 --- a/drivers/media/video/ti-media/dm644x_ccdc.c +++ b/drivers/media/video/ti-media/dm644x_ccdc.c @@ -99,6 +99,9 @@ static u32 ccdc_raw_bayer_pix_formats[] = static u32 ccdc_raw_yuv_pix_formats[] = {V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YUYV}; +/* CCDC Save/Restore context */ +static u32 ccdc_ctx[CCDC_REG_END / sizeof(u32)]; + /* register access routines */ static inline u32 regr(u32 offset) { @@ -835,6 +838,87 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param *params) return 0; } +static void ccdc_save_context(void) +{ + ccdc_ctx[CCDC_PCR >> 2] = regr(CCDC_PCR); + ccdc_ctx[CCDC_SYN_MODE >> 2] = regr(CCDC_SYN_MODE); + ccdc_ctx[CCDC_HD_VD_WID >> 2] = regr(CCDC_HD_VD_WID); + ccdc_ctx[CCDC_PIX_LINES >> 2] = regr(CCDC_PIX_LINES); + ccdc_ctx[CCDC_HORZ_INFO >> 2] = regr(CCDC_HORZ_INFO); + ccdc_ctx[CCDC_VERT_START >> 2] = regr(CCDC_VERT_START); + ccdc_ctx[CCDC_VERT_LINES >> 2] = regr(CCDC_VERT_LINES); + ccdc_ctx[CCDC_CULLING >> 2] = regr(CCDC_CULLING); + ccdc_ctx[CCDC_HSIZE_OFF >> 2] = regr(CCDC_HSIZE_OFF); + ccdc_ctx[CCDC_SDOFST >> 2] = regr(CCDC_SDOFST); + ccdc_ctx[CCDC_SDR_ADDR >> 2] = regr(CCDC_SDR_ADDR); + ccdc_ctx[CCDC_CLAMP >> 2] = regr(CCDC_CLAMP); + ccdc_ctx[CCDC_DCSUB >> 2] = regr(CCDC_DCSUB); + ccdc_ctx[CCDC_COLPTN >> 2] = regr(CCDC_COLPTN); + ccdc_ctx[CCDC_BLKCMP >> 2] = regr(CCDC_BLKCMP); + ccdc_ctx[CCDC_FPC >> 2] = regr(CCDC_FPC); + ccdc_ctx[CCDC_FPC_ADDR >> 2] = regr(CCDC_FPC_ADDR); + ccdc_ctx[CCDC_VDINT >> 2] = regr(CCDC_VDINT); + ccdc_ctx[CCDC_ALAW >> 2] = regr(CCDC_ALAW); + ccdc_ctx[CCDC_REC656IF >> 2] = regr(CCDC_REC656IF); + ccdc_ctx[CCDC_CCDCFG >> 2] = regr(CCDC_CCDCFG); + ccdc_ctx[CCDC_FMTCFG >> 2] = regr(CCDC_FMTCFG); + ccdc_ctx[CCDC_FMT_HORZ >> 2] = regr(CCDC_FMT_HORZ); + ccdc_ctx[CCDC_FMT_VERT >> 2] = regr(CCDC_FMT_VERT); + ccdc_ctx[CCDC_FMT_ADDR0 >> 2] = regr(CCDC_FMT_ADDR0); + ccdc_ctx[CCDC_FMT_ADDR1 >> 2] = regr(CCDC_FMT_ADDR1); + ccdc_ctx[CCDC_FMT_ADDR2 >> 2] = regr(CCDC_FMT_ADDR2); + ccdc_ctx[CCDC_FMT_ADDR3 >> 2] = regr(CCDC_FMT_ADDR3); + ccdc_ctx[CCDC_FMT_ADDR4 >> 2] = regr(CCDC_FMT_ADDR4); + ccdc_ctx[CCDC_FMT_ADDR5 >> 2] = regr(CCDC_FMT_ADDR5); + ccdc_ctx[CCDC_FMT_ADDR6 >> 2] = regr(CCDC_FMT_ADDR6); + ccdc_ctx[CCDC_FMT_ADDR7 >> 2] = regr(CCDC_FMT_ADDR7); + ccdc_ctx[CCDC_PRGEVEN_0 >> 2] = regr(CCDC_PRGEVEN_0); + ccdc_ctx[CCDC_PRGEVEN_1 >> 2] = regr(CCDC_PRGEVEN_1); + ccdc_ctx[CCDC_PRGODD_0 >> 2] = regr(CCDC_PRGODD_0); + ccdc_ctx[CCDC_PRGODD_1 >> 2] = regr(CCDC_PRGODD_1); + ccdc_ctx[CCDC_VP_OUT >> 2] = regr(CCDC_VP_OUT); +} + +static void ccdc_restore_context(void) +{ + regw(ccdc_ctx[CCDC_SYN_MODE >> 2], CCDC_SYN_MODE); + regw(ccdc_ctx[CCDC_HD_VD_WID >> 2], CCDC_HD_VD_WID); + regw(ccdc_ctx[CCDC_PIX_LINES >> 2], CCDC_PIX_LINES); + regw(ccdc_ctx[CCDC_HORZ_INFO >> 2], CCDC_HORZ_INFO); + regw(ccdc_ctx[CCDC_VERT_START >> 2], CCDC_VERT_START); + regw(ccdc_ctx[CCDC_VERT_LINES >> 2], CCDC_VERT_LINES); + regw(ccdc_ctx[CCDC_CULLING >> 2], CCDC_CULLING); + regw(ccdc_ctx[CCDC_HSIZE_OFF >> 2], CCDC_HSIZE_OFF); + regw(ccdc_ctx[CCDC_SDOFST >> 2], CCDC_SDOFST); + regw(ccdc_ctx[CCDC_SDR_ADDR >> 2], CCDC_SDR_ADDR); + regw(ccdc_ctx[CCDC_CLAMP >> 2], CCDC_CLAMP); + regw(ccdc_ctx[CCDC_DCSUB >> 2], CCDC_DCSUB); + regw(ccdc_ctx[CCDC_COLPTN >> 2], CCDC_COLPTN); + regw(ccdc_ctx[CCDC_BLKCMP >> 2], CCDC_BLKCMP); + regw(ccdc_ctx[CCDC_FPC >> 2], CCDC_FPC); + regw(ccdc_ctx[CCDC_FPC_ADDR >> 2], CCDC_FPC_ADDR); + regw(ccdc_ctx[CCDC_VDINT >> 2], CCDC_VDINT); + regw(ccdc_ctx[CCDC_ALAW >> 2], CCDC_ALAW); + regw(ccdc_ctx[CCDC_REC656IF >> 2], CCDC_REC656IF); + regw(ccdc_ctx[CCDC_CCDCFG >> 2], CCDC_CCDCFG); + regw(ccdc_ctx[CCDC_FMTCFG >> 2], CCDC_FMTCFG); + regw(ccdc_ctx[CCDC_FMT_HORZ >> 2], CCDC_FMT_HORZ); + regw(ccdc_ctx[CCDC_FMT_VERT >> 2], CCDC_FMT_VERT); + regw(ccdc_ctx[CCDC_FMT_ADDR0 >> 2], CCDC_FMT_ADDR0); + regw(ccdc_ctx[CCDC_FMT_ADDR1 >> 2], CCDC_FMT_ADDR1); + regw(ccdc_ctx[CCDC_FMT_ADDR2 >> 2], CCDC_FMT_ADDR2); + regw(ccdc_ctx[CCDC_FMT_ADDR3 >> 2], CCDC_FMT_ADDR3); + regw(ccdc_ctx[CCDC_FMT_ADDR4 >> 2], CCDC_FMT_ADDR4); + regw(ccdc_ctx[CCDC_FMT_ADDR5 >> 2], CCDC_FMT_ADDR5); + regw(ccdc_ctx[CCDC_FMT_ADDR6 >> 2], CCDC_FMT_ADDR6); + regw(ccdc_ctx[CCDC_FMT_ADDR7 >> 2], CCDC_FMT_ADDR7); + regw(ccdc_ctx[CCDC_PRGEVEN_0 >> 2], CCDC_PRGEVEN_0); + regw(ccdc_ctx[CCDC_PRGEVEN_1 >> 2], CCDC_PRGEVEN_1); + regw(ccdc_ctx[CCDC_PRGODD_0 >> 2], CCDC_PRGODD_0); + regw(ccdc_ctx[CCDC_PRGODD_1 >> 2], CCDC_PRGODD_1); + regw(ccdc_ctx[CCDC_VP_OUT >> 2], CCDC_VP_OUT); + regw(ccdc_ctx[CCDC_PCR >> 2], CCDC_PCR); +} static struct ccdc_hw_device ccdc_hw_dev = { .name = "DM6446 CCDC", .owner = THIS_MODULE, @@ -943,10 +1027,40 @@ static int dm644x_ccdc_remove(struct platform_device *pdev) return 0; } +static int dm644x_ccdc_suspend(struct device *dev) +{ + /* Save CCDC context */ + ccdc_save_context(); + /* Disable CCDC */ + ccdc_enable(0); + /* Disable both master and slave clock */ + clk_disable(ccdc_cfg.mclk); + clk_disable(ccdc_cfg.sclk); + + return 0; +} + +static int dm644x_ccdc_resume(struct device *dev) +{ + /* Enable both master and slave clock */ + clk_enable(ccdc_cfg.mclk); + clk_enable(ccdc_cfg.sclk); + /* Restore CCDC context */ + ccdc_restore_context(); + + return 0; +} + +static const struct dev_pm_ops dm644x_ccdc_pm_ops = { + .suspend = dm644x_ccdc_suspend, + .resume = dm644x_ccdc_resume, +}; + static struct platform_driver dm644x_ccdc_driver = { .driver = { .name = "dm644x_ccdc", .owner = THIS_MODULE, + .pm = &dm644x_ccdc_pm_ops, }, .remove = __devexit_p(dm644x_ccdc_remove), .probe = dm644x_ccdc_probe, diff --git a/drivers/media/video/ti-media/dm644x_ccdc_regs.h b/drivers/media/video/ti-media/dm644x_ccdc_regs.h index 6e5d053..319253a 100644 --- a/drivers/media/video/ti-media/dm644x_ccdc_regs.h +++ b/drivers/media/video/ti-media/dm644x_ccdc_regs.h @@ -59,7 +59,7 @@ #define CCDC_PRGODD_0 0x8c #define CCDC_PRGODD_1 0x90 #define CCDC_VP_OUT 0x94 - +#define CCDC_REG_END 0x98 /*************************************************************** * Define for various register bit mask and shifts for CCDC -- 1.6.2.4 From hvaibhav at ti.com Mon Jan 4 08:03:01 2010 From: hvaibhav at ti.com (hvaibhav at ti.com) Date: Mon, 4 Jan 2010 19:33:01 +0530 Subject: [PATCH 8/9] VPFE Capture: Add call back function for interrupt clear to vpfe_cfg In-Reply-To: References: Message-ID: <1262613782-20463-9-git-send-email-hvaibhav@ti.com> From: Vaibhav Hiremath For the devices like AM3517, it is expected that driver clears the interrupt in ISR. Since this is device spcific, callback function added to the platform_data. Signed-off-by: Vaibhav Hiremath --- drivers/media/video/ti-media/vpfe_capture.c | 24 ++++++++++++++++++++---- include/media/ti-media/vpfe_capture.h | 2 ++ 2 files changed, 22 insertions(+), 4 deletions(-) diff --git a/drivers/media/video/ti-media/vpfe_capture.c b/drivers/media/video/ti-media/vpfe_capture.c index 7187eaa..95538b2 100644 --- a/drivers/media/video/ti-media/vpfe_capture.c +++ b/drivers/media/video/ti-media/vpfe_capture.c @@ -475,6 +475,11 @@ static int vpfe_initialize_device(struct vpfe_device *vpfe_dev) ret = ccdc_dev->hw_ops.open(vpfe_dev->pdev); if (!ret) vpfe_dev->initialized = 1; + + /* Clear all VPFE/CCDC interrupts */ + if (vpfe_dev->cfg->clr_intr) + vpfe_dev->cfg->clr_intr(-1); + unlock: mutex_unlock(&ccdc_lock); return ret; @@ -562,7 +567,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id) /* if streaming not started, don't do anything */ if (!vpfe_dev->started) - return IRQ_HANDLED; + goto clear_intr; /* only for 6446 this will be applicable */ if (NULL != ccdc_dev->hw_ops.reset) @@ -574,7 +579,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id) "frame format is progressive...\n"); if (vpfe_dev->cur_frm != vpfe_dev->next_frm) vpfe_process_buffer_complete(vpfe_dev); - return IRQ_HANDLED; + goto clear_intr; } /* interlaced or TB capture check which field we are in hardware */ @@ -604,7 +609,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id) addr += vpfe_dev->field_off; ccdc_dev->hw_ops.setfbaddr(addr); } - return IRQ_HANDLED; + goto clear_intr; } /* * if one field is just being captured configure @@ -624,6 +629,10 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id) */ vpfe_dev->field_id = fid; } +clear_intr: + if (vpfe_dev->cfg->clr_intr) + vpfe_dev->cfg->clr_intr(irq); + return IRQ_HANDLED; } @@ -635,8 +644,11 @@ static irqreturn_t vdint1_isr(int irq, void *dev_id) v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "\nInside vdint1_isr...\n"); /* if streaming not started, don't do anything */ - if (!vpfe_dev->started) + if (!vpfe_dev->started) { + if (vpfe_dev->cfg->clr_intr) + vpfe_dev->cfg->clr_intr(irq); return IRQ_HANDLED; + } spin_lock(&vpfe_dev->dma_queue_lock); if ((vpfe_dev->fmt.fmt.pix.field == V4L2_FIELD_NONE) && @@ -644,6 +656,10 @@ static irqreturn_t vdint1_isr(int irq, void *dev_id) vpfe_dev->cur_frm == vpfe_dev->next_frm) vpfe_schedule_next_buffer(vpfe_dev); spin_unlock(&vpfe_dev->dma_queue_lock); + + if (vpfe_dev->cfg->clr_intr) + vpfe_dev->cfg->clr_intr(irq); + return IRQ_HANDLED; } diff --git a/include/media/ti-media/vpfe_capture.h b/include/media/ti-media/vpfe_capture.h index 5287368..f0a7b7a 100644 --- a/include/media/ti-media/vpfe_capture.h +++ b/include/media/ti-media/vpfe_capture.h @@ -94,6 +94,8 @@ struct vpfe_config { /* vpfe clock */ struct clk *vpssclk; struct clk *slaveclk; + /* Function for Clearing the interrupt */ + void (*clr_intr)(int vdint); }; struct vpfe_device { -- 1.6.2.4 From hvaibhav at ti.com Mon Jan 4 08:03:02 2010 From: hvaibhav at ti.com (hvaibhav at ti.com) Date: Mon, 4 Jan 2010 19:33:02 +0530 Subject: [PATCH 9/9] DM644x CCDC: Add 10bit BT support In-Reply-To: References: Message-ID: <1262613782-20463-10-git-send-email-hvaibhav@ti.com> From: Vaibhav Hiremath Signed-off-by: Vaibhav Hiremath --- drivers/media/video/ti-media/dm644x_ccdc.c | 16 +++++++++++++--- drivers/media/video/ti-media/dm644x_ccdc_regs.h | 8 ++++++++ 2 files changed, 21 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/ti-media/dm644x_ccdc.c b/drivers/media/video/ti-media/dm644x_ccdc.c index b762f99..8483467 100644 --- a/drivers/media/video/ti-media/dm644x_ccdc.c +++ b/drivers/media/video/ti-media/dm644x_ccdc.c @@ -401,7 +401,11 @@ void ccdc_config_ycbcr(void) * configure the FID, VD, HD pin polarity, * fld,hd pol positive, vd negative, 8-bit data */ - syn_mode |= CCDC_SYN_MODE_VD_POL_NEGATIVE | CCDC_SYN_MODE_8BITS; + syn_mode |= CCDC_SYN_MODE_VD_POL_NEGATIVE; + if (ccdc_cfg.if_type == VPFE_BT656_10BIT) + syn_mode |= CCDC_SYN_MODE_10BITS; + else + syn_mode |= CCDC_SYN_MODE_8BITS; } else { /* y/c external sync mode */ syn_mode |= (((params->fid_pol & CCDC_FID_POL_MASK) << @@ -420,8 +424,13 @@ void ccdc_config_ycbcr(void) * configure the order of y cb cr in SDRAM, and disable latch * internal register on vsync */ - regw((params->pix_order << CCDC_CCDCFG_Y8POS_SHIFT) | - CCDC_LATCH_ON_VSYNC_DISABLE, CCDC_CCDCFG); + if (ccdc_cfg.if_type == VPFE_BT656_10BIT) + regw((params->pix_order << CCDC_CCDCFG_Y8POS_SHIFT) | + CCDC_LATCH_ON_VSYNC_DISABLE | CCDC_CCDCFG_BW656_10BIT, + CCDC_CCDCFG); + else + regw((params->pix_order << CCDC_CCDCFG_Y8POS_SHIFT) | + CCDC_LATCH_ON_VSYNC_DISABLE, CCDC_CCDCFG); /* * configure the horizontal line offset. This should be a @@ -828,6 +837,7 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param *params) case VPFE_BT656: case VPFE_YCBCR_SYNC_16: case VPFE_YCBCR_SYNC_8: + case VPFE_BT656_10BIT: ccdc_cfg.ycbcr.vd_pol = params->vdpol; ccdc_cfg.ycbcr.hd_pol = params->hdpol; break; diff --git a/drivers/media/video/ti-media/dm644x_ccdc_regs.h b/drivers/media/video/ti-media/dm644x_ccdc_regs.h index 319253a..90370e4 100644 --- a/drivers/media/video/ti-media/dm644x_ccdc_regs.h +++ b/drivers/media/video/ti-media/dm644x_ccdc_regs.h @@ -135,11 +135,19 @@ #define CCDC_SYN_MODE_INPMOD_SHIFT 12 #define CCDC_SYN_MODE_INPMOD_MASK 3 #define CCDC_SYN_MODE_8BITS (7 << 8) +#define CCDC_SYN_MODE_10BITS (6 << 8) +#define CCDC_SYN_MODE_11BITS (5 << 8) +#define CCDC_SYN_MODE_12BITS (4 << 8) +#define CCDC_SYN_MODE_13BITS (3 << 8) +#define CCDC_SYN_MODE_14BITS (2 << 8) +#define CCDC_SYN_MODE_15BITS (1 << 8) +#define CCDC_SYN_MODE_16BITS (0 << 8) #define CCDC_SYN_FLDMODE_MASK 1 #define CCDC_SYN_FLDMODE_SHIFT 7 #define CCDC_REC656IF_BT656_EN 3 #define CCDC_SYN_MODE_VD_POL_NEGATIVE (1 << 2) #define CCDC_CCDCFG_Y8POS_SHIFT 11 +#define CCDC_CCDCFG_BW656_10BIT (1 << 5) #define CCDC_SDOFST_FIELD_INTERLEAVED 0x249 #define CCDC_NO_CULLING 0xffff00ff #endif -- 1.6.2.4 From ggottumu at Cernium.com Mon Jan 4 08:12:46 2010 From: ggottumu at Cernium.com (Gopala Gottumukkala) Date: Mon, 4 Jan 2010 09:12:46 -0500 Subject: USB storage error In-Reply-To: References: <03A2FA9E0D3DC841992E682BF528771801747AD2@lipwig.Cernium.local> Message-ID: <03A2FA9E0D3DC841992E682BF528771801747B16@lipwig.Cernium.local> Can I know the latest Davinci Git kernel version which is working for you. The kernel version number and where can I down load the latest one. - Gopala From: Subbrathnam, Swaminathan [mailto:swami.iyer at ti.com] Sent: Friday, January 01, 2010 8:10 AM To: Gopala Gottumukkala; davinci-linux-open-source at linux.davincidsp.com Subject: RE: USB storage error Gopala, Could you try the latest DaVinci Git. It works for me. regards swami ________________________________ From: davinci-linux-open-source-bounces at linux.davincidsp.com [davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Gopala Gottumukkala [ggottumu at Cernium.com] Sent: Friday, January 01, 2010 1:38 AM To: davinci-linux-open-source at linux.davincidsp.com Subject: USB storage error I have compiled davinci 2.6.30 I mounted the usb manually I ran some sample program which will open, write and delete the file into usb drive. While writing the file into usb drive. It gives the following error and the program dies. Any help would be appreciated on this usb 1-1: reset high speed USB device using musb_hdrc and address 2 usb 1-1: reset high speed USB device using musb_hdrc and address 2 usb 1-1: reset high speed USB device using musb_hdrc and address 2 sd 0:0:0:0: Device offlined - not ready after error recovery sd 0:0:0:0: [sda] Unhandled error code sd 0:0:0:0: [sda] Result: hostbyte=0x05 driverbyte=0x00 end_request: I/O error, dev sda, sector 41584 sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: [sda] Unhandled error code sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sda, sector 40000 sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device - Gopala NOTICE: The information contained in this email and any document attached hereto is intended only for the named recipient(s). It is the property of Cernium Corporation and shall not be used, disclosed or reproduced without the express written consent of Cernium Corporation. If you are not the intended recipient (or the employee or agent responsible for delivering this message in confidence to the intended recipient(s)), you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this transmittal or its attachments is strictly prohibited. If you have received this transmittal and/or attachments in error, please notify me immediately by reply email or telephone and immediately delete this message and all its attachments. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erezk at radvision.com Mon Jan 4 11:03:51 2010 From: erezk at radvision.com (Erez Kinarti) Date: Mon, 4 Jan 2010 19:03:51 +0200 Subject: Cmem address translation when working with Codec Engine In-Reply-To: <6B8224E84039B140AA662F0BB03616430122930FB8@dlee04.ent.ti.com> References: <6B8224E84039B140AA662F0BB03616430122930FB8@dlee04.ent.ti.com> Message-ID: <10B9B66481AB544596EF70B519D5899601D52422@rvil-mail1.RADVISION.com> Thanks a lot Rob. calling this function for each of the pointers used with CodecEngine solved the problem. However, we need something else, some function that invalidates all this virt->phy table and not each of the virtual pointers separately. Is there a way to do a full invalidate in a single call without keep tracking on each of the virtual pointers? The reason that Memory_unregisterContigBuf it is not enough for us: In our system, we allocate a very big buffer from CMEM (258048 bytes), but we don't call CodecEngine with a pointer to the big buffer. We are dividing the buffer to small slices (can be hundreds, not necessarily with the same size), and call CodecEngine with pointers to these small slices. Thus, CodecEngine keeps the pointers to the small slices in its virt->phy tables, so we need to call Memory_unregisterContigBuf for each and every one of the small slices. In the current structure of our application it is not practical for us to keep tracking on each of the slices and its size. Thanks in advance, Erez From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Tivy, Robert Sent: Wednesday, December 30, 2009 8:59 PM To: Amit Klir; Davinci-linux-open-source at linux.davincidsp.com Subject: FW: Cmem address translation when working with Codec Engine Oops, forgot to "Reply All"... - Rob ________________________________ From: Tivy, Robert Sent: Wednesday, December 30, 2009 10:57 AM To: 'Erez Kinarti' Subject: RE: Cmem address translation when working with Codec Engine Erez, Thanks for your detailed explanation, it allows me to understand your problem and the solution. The bottom line is that you should be using CE's Memory module to allocate CMEM memory. This will alleviate your wrong phys addr to the DSP. If you want to continue using CMEM_alloc/free, then you can remove CE's cached virt->phys translation with: Memory_unregisterContigBuf(virtAddr, 258048); The reason you need to use CE's Memory module is because the codec class stub file is using it to get the phys addr of a virt buffer. What happens when you allocate outside of Memory is the following: - allocate with CMEM_alloc(), which causes the kernel to create the virt-phys mapping (there is no table in CMEM). - pass this buffer to _process() - _process() calls Memory_getBufferPhysicalAddress(virtAddr) - the Memory module keeps a cache of virt->phys mappings, and since Memory hasn't seen this buffer before, it asks CMEM with CMEM_getPhys(). - CMEM returns the correct phys addr and Memory caches this mapping. - you free the buffer, which frees the kernel mapping for it, then allocate a new one, and the Linux kernel creates a new mapping - the Linux kernel decides to reuse the same virt addr from before, but this time with a different phys addr - _process() calls Memory_getBufferPhysicalAddress(virtAddr) - since Memory module didn't know about the freeing of the previous buffer, it uses its old cached translation. To allocate CMEM through Memory: Memory_AllocParams params; params.type = Memory_CONTIGPOOL; params.flags = Memory_CACHED; // or Memory_NONCACHED if so desired addr = Memory_alloc(258048, ¶ms); ... Memory_free(addr, 258048, ¶ms); Regards, - Rob ________________________________ From: Erez Kinarti [mailto:erezk at radvision.com] Sent: Wednesday, December 30, 2009 12:10 AM To: Tivy, Robert; Amit Klir; Davinci-linux-open-source at linux.davincidsp.com Subject: RE: Cmem address translation when working with Codec Engine Hello Rob, I'm working with Amit on the same problem. Thank you very much for your quick answer and willing to help. We take the buffers directly from Cmem pool. We have a pool of 3x258048 in cmem (three buffers with size 258048), and we take one of the buffers from CMEM directly using CMEM_alloc. We do it only once for the speech codec, and this buffer is the only buffer used by us as for output buffer. After we close the codec (SPHENC_delete), we release the buffer back to CMEM directly using CMEM_free. All the CMEM allocation and free is done directly with CMEM and NOT via CodecEngine. In our case, after closing the codec and releasing the buffer, we want to reopen the codec. What we do is getting a new buffer from CMEM directly using CMEM_alloc, and then opening the codec using SPHENC_create. Another issue that is important is that in the second time, we get from CMEM a buffer with the same virtual address as the first buffer, just with different physical address. It seems like CMEM changed the virtual to physical mapping. However, when calling the DSP, it seems like CE is using the same mapping as in the first time which is no longer valid, and the DSP codec is getting a pointer to the physical buffer used in the first time. Is it possible that CMEM is changing the address translation mapping and CE is not synchronized with it and is using its old virt-to-phy mapping. Our main question: =============== What action should we do in order to synchronize the virt-to-phys cache in CE's Memory module with the CMEM virtual to physical mapping? Is there any CE command that tells CE to invalidate its virt-to-phys cache and take the updated values from CMEM? Thanks, Erez From: Tivy, Robert [mailto:rtivy at ti.com] Sent: Tuesday, December 29, 2009 7:52 PM To: Amit Klir; Davinci-linux-open-source at linux.davincidsp.com Cc: Erez Kinarti Subject: RE: Cmem address translation when working with Codec Engine How are you "returning CMEM buf to the pool" for each codec thread? CE contains a virt-to-phys cache in CE's Memory module, and a CE codec class stubs file will use the Memory module to translate the virt addr to a phys addr. If CMEM buffer allocation is happening through the Memory module but CMEM buffer freeing is done through just CMEM then this situation can happen. There is no known problem in CMEM 2.10 of this sort, however CMEM 2.10 is older and I believe you could upgrade to LinuxUtils 2.25 which contains a later CMEM. There is also a CE 2.25 that you could upgrade to. In order for me to tell more of what's going on I would need to see some trace output from your application. Later CE releases contain support for an environment variable called CE_DEBUG that can be set to 1|2|3. Setting it to 3 will generate lots of useful output (and lots of "noise" too, unfortunately). I don't recall if 2.10 supports CE_DEBUG or if that came after 2.10, if not then you would have to use CE_TRACE instead (which is documented). If you can run your app with this trace output enabled and send it to me I can take a look. Regards, - Rob ________________________________ From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Amit Klir Sent: Tuesday, December 29, 2009 7:26 AM To: Davinci-linux-open-source at linux.davincidsp.com Cc: Erez Kinarti Subject: Cmem address translation when working with Codec Engine Hello, I'm working with DaVinci DM6467, using ARM running linux, and CodecEngine as the interface between ARM and DSP. My application is doing audio and video encoding in parallel in two different threads. I'm also using CMEM version 2.10 for continuous buffers allocation. The problem is that, in some situation, the CMEM buffer physical address viewed by ARM (using CMEM_getPhys()) is different than the physical address sent to DSP (translated by CodecEngine). Scenario where ArmPhyAddr != DspPhyAddr: =================================== In my application, I open CodecEngine and then open two codecs on the DSP: VIDENC1 and SPHENC1. In the beginning both codecs are running in two different threads, and for each of them we keep a CMEM buffers pool in ARM for their IO buffers. When the app starts running, for each Codec it take a single buffer from the relevant Cmem pool, and use only this buffer for all the run. In the beginning the physical addresses viewed by ARM and DSP are equal. After a while, we do the following sequence of closing and opening the codecs: 1. Close and open the video codec - VIDENC1_delete() - Return the CMEM buf of VIDENC to the pool. - Take a new CMEM buffer from the pool to be used for VIDENC. - VIDENC_create() - Running video processing of a stream ... 2. Close and open the speech codec: - SPHENC1_delete() - Return the CMEM buf of SPHENC to the pool. - Take a new CMEM buffer from the pool to be used for SPHENC. - SPHENC_create() - Running speech processing of a stream .. After doing this sequence and continue running the video and audio processing. Now on the SPHENC codec, the CMEM buffer physical address viewed by ARM is different than the one viewed by the DSP for the same buffer. In addition I see that there is a constant offset between them which is the size of a CMEM buffer used for the speech (in our case 258048). That means that the same virtual address in the ARM is translated in ARM to different physical address than the one translated by CodecEngine. It seems like two different translation tables are used, and they are not synchronized. Our CMEM pool for the speech usage is made of 3 buffers of size 258048. Does anyone know what can cause this problem? To me it seems like CMEM problem, however, when checking in TI site I see that version 2_10 that I'm using is currently the official version. Thanks in advance for any help, -------------- next part -------------- An HTML attachment was scrubbed... URL: From pan at nt.tu-darmstadt.de Mon Jan 4 11:08:55 2010 From: pan at nt.tu-darmstadt.de (Vladimir Pantelic) Date: Mon, 04 Jan 2010 18:08:55 +0100 Subject: Cmem address translation when working with Codec Engine In-Reply-To: <10B9B66481AB544596EF70B519D5899601D52422@rvil-mail1.RADVISION.com> References: <6B8224E84039B140AA662F0BB03616430122930FB8@dlee04.ent.ti.com> <10B9B66481AB544596EF70B519D5899601D52422@rvil-mail1.RADVISION.com> Message-ID: <4B4220A7.6090506@nt.tu-darmstadt.de> Erez Kinarti wrote: > Thanks a lot Rob. > > calling this function for each of the pointers used with CodecEngine > solved the problem. > > However, we need something else, some function that invalidates all this > virt->phy table and not each of the virtual pointers separately. > > Is there a way to do a full invalidate in a single call without keep > tracking on each of the virtual pointers? > > The reason that Memory_unregisterContigBuf it is not enough for us: > > In our system, we allocate a very big buffer from CMEM (258048 bytes), > but we don?t call CodecEngine with a pointer to the big buffer. You dont need to call Memory_unregisterContigBuf, just alloc and free the buffers via CE and CE will know that you are calling it with a smaller buffer inside a larger one that it knows the translation to... From erezk at radvision.com Mon Jan 4 11:14:43 2010 From: erezk at radvision.com (Erez Kinarti) Date: Mon, 4 Jan 2010 19:14:43 +0200 Subject: Cmem address translation when working with Codec Engine In-Reply-To: <4B4220A7.6090506@nt.tu-darmstadt.de> References: <6B8224E84039B140AA662F0BB03616430122930FB8@dlee04.ent.ti.com><10B9B66481AB544596EF70B519D5899601D52422@rvil-mail1.RADVISION.com> <4B4220A7.6090506@nt.tu-darmstadt.de> Message-ID: <10B9B66481AB544596EF70B519D5899601D52423@rvil-mail1.RADVISION.com> Thank you Vladimir, But we are not able to allocate and free via CodecEngine due to the structure of our application and the need to call the alloc not before calling CERuntimeInit(). -----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 Vladimir Pantelic Sent: Monday, January 04, 2010 7:09 PM To: Davinci-linux-open-source at linux.davincidsp.com Subject: Re: Cmem address translation when working with Codec Engine Erez Kinarti wrote: > Thanks a lot Rob. > > calling this function for each of the pointers used with CodecEngine > solved the problem. > > However, we need something else, some function that invalidates all this > virt->phy table and not each of the virtual pointers separately. > > Is there a way to do a full invalidate in a single call without keep > tracking on each of the virtual pointers? > > The reason that Memory_unregisterContigBuf it is not enough for us: > > In our system, we allocate a very big buffer from CMEM (258048 bytes), > but we don't call CodecEngine with a pointer to the big buffer. You dont need to call Memory_unregisterContigBuf, just alloc and free the buffers via CE and CE will know that you are calling it with a smaller buffer inside a larger one that it knows the translation to... _______________________________________________ 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 elbertshiang at yahoo.com Mon Jan 4 13:01:14 2010 From: elbertshiang at yahoo.com (elbert shiang) Date: Mon, 4 Jan 2010 11:01:14 -0800 (PST) Subject: read/write a Ethernet port In-Reply-To: Message-ID: <849096.71591.qm@web81203.mail.mud.yahoo.com> Hi, Dear All: ? Is anyone can tell me how to start to read/write a Ethernet port for DM355? What is the documentation I should refer to? ? I post before but did not insert right subject. sorry for that. ? Thanks, Elbert --- On Mon, 1/4/10, davinci-linux-open-source-request at linux.davincidsp.com wrote: From: davinci-linux-open-source-request at linux.davincidsp.com Subject: Davinci-linux-open-source Digest, Vol 49, Issue 6 To: davinci-linux-open-source at linux.davincidsp.com Date: Monday, January 4, 2010, 10:00 AM Send Davinci-linux-open-source mailing list submissions to ??? davinci-linux-open-source at linux.davincidsp.com To subscribe or unsubscribe via the World Wide Web, visit ??? http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source or, via email, send a message with subject or body 'help' to ??? davinci-linux-open-source-request at linux.davincidsp.com You can reach the person managing the list at ??? davinci-linux-open-source-owner at linux.davincidsp.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Davinci-linux-open-source digest..." Today's Topics: ???1. Re: Cmem address translation when working with Codec Engine ? ? ? (Vladimir Pantelic) ???2. RE: Cmem address translation when working with Codec Engine ? ? ? (Erez Kinarti) ---------------------------------------------------------------------- Message: 1 Date: Mon, 04 Jan 2010 18:08:55 +0100 From: Vladimir Pantelic To: Davinci-linux-open-source at linux.davincidsp.com Subject: Re: Cmem address translation when working with Codec Engine Message-ID: <4B4220A7.6090506 at nt.tu-darmstadt.de> Content-Type: text/plain; charset=windows-1252; format=flowed Erez Kinarti wrote: > Thanks a lot Rob. > > calling this function for each of the pointers used with CodecEngine > solved the problem. > > However, we need something else, some function that invalidates all this > virt->phy table and not each of the virtual pointers separately. > > Is there a way to do a full invalidate in a single call without keep > tracking on each of the virtual pointers? > > The reason that Memory_unregisterContigBuf it is not enough for us: > > In our system, we allocate a very big buffer from CMEM (258048 bytes), > but we don?t call CodecEngine with a pointer to the big buffer. You dont need to call Memory_unregisterContigBuf, just alloc and free the buffers via CE and CE will know that you are calling it with a smaller buffer inside a larger one that it knows the translation to... ------------------------------ Message: 2 Date: Mon, 4 Jan 2010 19:14:43 +0200 From: "Erez Kinarti" To: "Vladimir Pantelic" , ??? Subject: RE: Cmem address translation when working with Codec Engine Message-ID: ??? <10B9B66481AB544596EF70B519D5899601D52423 at rvil-mail1.RADVISION.com> Content-Type: text/plain;??? charset="us-ascii" Thank you Vladimir, But we are not able to allocate and free via CodecEngine due to the structure of our application and the need to call the alloc not before calling CERuntimeInit(). -----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 Vladimir Pantelic Sent: Monday, January 04, 2010 7:09 PM To: Davinci-linux-open-source at linux.davincidsp.com Subject: Re: Cmem address translation when working with Codec Engine Erez Kinarti wrote: > Thanks a lot Rob. > > calling this function for each of the pointers used with CodecEngine > solved the problem. > > However, we need something else, some function that invalidates all this > virt->phy table and not each of the virtual pointers separately. > > Is there a way to do a full invalidate in a single call without keep > tracking on each of the virtual pointers? > > The reason that Memory_unregisterContigBuf it is not enough for us: > > In our system, we allocate a very big buffer from CMEM (258048 bytes), > but we don't call CodecEngine with a pointer to the big buffer. You dont need to call Memory_unregisterContigBuf, just alloc and free the buffers via CE and CE will know that you are calling it with a smaller buffer inside a larger one that it knows the translation to... _______________________________________________ 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 End of Davinci-linux-open-source Digest, Vol 49, Issue 6 ******************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From albertbu at gmail.com Mon Jan 4 14:22:23 2010 From: albertbu at gmail.com (Albert Burbea) Date: Mon, 4 Jan 2010 22:22:23 +0200 Subject: jpeg encoder stuck Message-ID: hi all i repost this quewstion - I did not get any answer about it. I am using the JPEG encoder from TI. I have wrapped it with a codec server and a codec engine. The codec is opened successfully by the application but the first IMGENC1_control with XDM_SETPARAMS command call never returns. I can see that the VISA_call2 is stuck waiting endlessly for the message queue from the DSP to the ARM to return something, but nothing happens. Any ideas? I checked many times the TCF and the CFG files and they seem OK to me Albert -- 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 rtivy at ti.com Mon Jan 4 17:29:43 2010 From: rtivy at ti.com (Tivy, Robert) Date: Mon, 4 Jan 2010 17:29:43 -0600 Subject: Cmem address translation when working with Codec Engine In-Reply-To: <10B9B66481AB544596EF70B519D5899601D52423@rvil-mail1.RADVISION.com> References: <6B8224E84039B140AA662F0BB03616430122930FB8@dlee04.ent.ti.com><10B9B66481AB544596EF70B519D5899601D52422@rvil-mail1.RADVISION.com> <4B4220A7.6090506@nt.tu-darmstadt.de> <10B9B66481AB544596EF70B519D5899601D52423@rvil-mail1.RADVISION.com> Message-ID: <6B8224E84039B140AA662F0BB03616430122A5A903@dlee04.ent.ti.com> There is no function available to invalidate all the Memory module virt-phys translations. If your app structure allows it, you can call Memory_registerContigBuf(bigCMEMBufferVirtAddr, 258048, CMEM_getPhys(bigCMEMBufferVirtAddr)); once, and all smaller subdivided buffers will be covered by this one registration (or, even simpler, just call Memory_getBufferPhysicalAddress(bigCMEMBufferVirtAddr, 258048, NULL); and ignore the result, which will do the CMEM_getPhys() for you and register it). You can then call Memory_unregisterContigBuf(bigCMEMBufferVirtAddr, 258048) once when you're ready to free the CMEM buffer. FYI, if you want to double-check me, you can call Memory_dumpKnownContigBufsList() to display (through GT tracing) the contig buffer list (AKA, the Memory module virt-phys translation table). Regards, - Rob > -----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 Erez Kinarti > Sent: Monday, January 04, 2010 9:15 AM > To: Vladimir Pantelic; Davinci-linux-open-source at linux.davincidsp.com > Subject: RE: Cmem address translation when working with Codec Engine > > Thank you Vladimir, > But we are not able to allocate and free via CodecEngine due > to the structure of our application and the need to call the > alloc not before calling CERuntimeInit(). > > > -----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 Vladimir Pantelic > Sent: Monday, January 04, 2010 7:09 PM > To: Davinci-linux-open-source at linux.davincidsp.com > Subject: Re: Cmem address translation when working with Codec Engine > > Erez Kinarti wrote: > > Thanks a lot Rob. > > > > calling this function for each of the pointers used with > CodecEngine > > solved the problem. > > > > However, we need something else, some function that invalidates all > this > > virt->phy table and not each of the virtual pointers separately. > > > > Is there a way to do a full invalidate in a single call > without keep > > tracking on each of the virtual pointers? > > > > The reason that Memory_unregisterContigBuf it is not enough for us: > > > > In our system, we allocate a very big buffer from CMEM > (258048 bytes), > > but we don't call CodecEngine with a pointer to the big buffer. > > You dont need to call Memory_unregisterContigBuf, just alloc > and free the buffers via CE and CE will know that you are > calling it with a smaller buffer inside a larger one that it > knows the translation to... > > _______________________________________________ > 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 rtivy at ti.com Mon Jan 4 19:47:22 2010 From: rtivy at ti.com (Tivy, Robert) Date: Mon, 4 Jan 2010 19:47:22 -0600 Subject: codec hangs In-Reply-To: References: Message-ID: <6B8224E84039B140AA662F0BB03616430122A5A994@dlee04.ent.ti.com> Nothing comes to mind from just your description. BTW, that "really strange" address (0xbeffc850) seems like a Linux user stack address. Since nothing jumps out from your top-down description, I would suggest a bottom-up investigation - debugging the DSP. Seems that the codec's "control()" code is sending the DSP into the weeds, at least with the parameters passed in. I would suggest putting a BP on the codec's "control()" function and stepping that function to see where the DSP goes bad. Regards, - Rob ________________________________ From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Albert Burbea Sent: Tuesday, December 29, 2009 11:22 AM To: davinci-linux-open-source Subject: codec hangs Hi everybody, I am using mv 4.01 with codec engine 2.01. I am integrating the TI JPEG encoder 1.1.13. At the beginning it did not work,it did not even open, until I modified the JPEGENC.xs to return the saram and daram scratch sizes. Before that, I modified also the ce/JPEGENC.xdc to use an IMGENC1 VISA interface instead of the IMGENC interface. I was able to open it and do an XDM_SETPARAMS control, but I did not try anything more. I restored the IMGENC interface in ce/JPEGENC.xdc, and compiled. Still worked. Then, I added a CMEM allocation for the output buffer, and... it hangs! Of course I removed the allocation and retried, but nope, I can only open it. Wen I execute the XDM_SETPARAMS, everything seems fine until the VISA_call for the XDM_SETPARAMS. The pointers it receives seem really strange to me, one of them if beffc850 or something like. It only enters the call, is able to queue the call, but then waits forever for the message queue to return, and everyting dies. What can be the problem? I verified several times the tcf file and the cmem settings and seem correct to me. Thanks in advance Albert -- 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 rtivy at ti.com Mon Jan 4 20:07:17 2010 From: rtivy at ti.com (Tivy, Robert) Date: Mon, 4 Jan 2010 20:07:17 -0600 Subject: Arago Kerenel w/ codec_engine_2_00_01 issues? In-Reply-To: <7F1B6BBBDF05C649BBBA3C853F488A6119BDDFC806@Hawking.deepsea.com> References: <7F1B6BBBDF05C649BBBA3C853F488A6119BDDFC806@Hawking.deepsea.com> Message-ID: <6B8224E84039B140AA662F0BB03616430122A5A9AC@dlee04.ent.ti.com> Generally, user-level code doesn't care much about the kernel version, and CE itself is all user-level code. Since CE encapsulates other packages that do contain kernel modules (which do care about kernel version), such as CMEM in LinuxUtils and DSPLink, the problem probably is with those. The kernel modules call APIs that can come or go with particular Linux kernels, hence the dependency of kernel modules on the kernel. Typically you will need to rebuild the kernel modules for the particular kernel that you're running. Rebuilding is also important with respect to simply inserting the kernel modules (usually done with a "loadmodules.sh" script) - you can't insert a kernel module that's been built against a kernel other than the one you're running (although there is some flexibility if the kernels in question are "close enough" to each other). It would help if you described your problem opening the mpeg4enc video encode algorithm. CE 2.00.01 is fairly old at this point, much older than 2.6.26 Linux. I would suggest updating to a newer CE, which also might just fix your problem. Regards, - Rob > -----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 Paul Stuart > Sent: Thursday, December 31, 2009 12:55 PM > To: davinci-linux-open-source at linux.davincidsp.com > Subject: Arago Kerenel w/ codec_engine_2_00_01 issues? > > Hi There, > Wondering if there is any magic that has to happen to make > the dvsdk's codec engine (2_00_01) play with the arago kernel > (2.6.26)? Everything compiles fine, but my app can't open the > mpeg4enc video encode algorithm. > Thanks, > Paul > _______________________________________________ > 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 albertbu at gmail.com Tue Jan 5 01:54:48 2010 From: albertbu at gmail.com (Albert Burbea) Date: Tue, 5 Jan 2010 09:54:48 +0200 Subject: codec hangs In-Reply-To: <6B8224E84039B140AA662F0BB03616430122A5A994@dlee04.ent.ti.com> References: <6B8224E84039B140AA662F0BB03616430122A5A994@dlee04.ent.ti.com> Message-ID: Hi thanks for your help - the problem is that the JPEG codec is TI's and I do not have access to its source code. What could hang the message queue ? Thanks again Albert On Tue, Jan 5, 2010 at 3:47 AM, Tivy, Robert wrote: > Nothing comes to mind from just your description. BTW, that "really > strange" address (0xbeffc850) seems like a Linux user stack address. > > Since nothing jumps out from your top-down description, I would suggest a > bottom-up investigation - debugging the DSP. Seems that the codec's > "control()" code is sending the DSP into the weeds, at least with the > parameters passed in. I would suggest putting a BP on the codec's > "control()" function and stepping that function to see where the DSP goes > bad. > > Regards, > > - Rob > > ------------------------------ > *From:* davinci-linux-open-source-bounces at linux.davincidsp.com [mailto: > davinci-linux-open-source-bounces at linux.davincidsp.com] *On Behalf Of *Albert > Burbea > *Sent:* Tuesday, December 29, 2009 11:22 AM > *To:* davinci-linux-open-source > *Subject:* codec hangs > > Hi everybody, > I am using mv 4.01 with codec engine 2.01. I am integrating the TI JPEG > encoder 1.1.13. At the beginning it did not work,it did not even open, > until I modified the JPEGENC.xs to return the saram and daram scratch > sizes. Before that, I modified also the ce/JPEGENC.xdc to use an IMGENC1 > VISA interface instead of the IMGENC interface. I was able to open it and do > an XDM_SETPARAMS control, but I did not try anything more. I restored the > IMGENC interface in ce/JPEGENC.xdc, and compiled. Still worked. Then, I > added a CMEM allocation for the output buffer, and... it hangs! Of course I > removed the allocation and retried, but nope, I can only open it. Wen > I execute the XDM_SETPARAMS, everything seems fine until the VISA_call for > the XDM_SETPARAMS. The pointers it receives seem really strange to me, one > of them if beffc850 or something like. It only enters the call, is able to > queue the call, but then waits forever for the message queue to return, and > everyting dies. > What can be the problem? I verified several times the tcf file and the cmem > settings and seem correct to me. > Thanks in advance > Albert > > -- > Albert Burbea > Harishonim 8 > Ramat Gan 52502, Israel > Tel/Fax + 972-3-7526016 > Mobile: +972-52-3541842 > > -- 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 nsekhar at ti.com Tue Jan 5 02:16:17 2010 From: nsekhar at ti.com (Nori, Sekhar) Date: Tue, 5 Jan 2010 13:46:17 +0530 Subject: [PATCH] rtc: make rtc-omap wakeup capable In-Reply-To: <1259068720-26113-1-git-send-email-nsekhar@ti.com> References: <1259068720-26113-1-git-send-email-nsekhar@ti.com> Message-ID: Hello, On Tue, Nov 24, 2009 at 18:48:40, Nori, Sekhar wrote: > The rtc-omap driver currently hardcodes the RTC to be > not capable of wakeup events. On the DA850/OMAP-L138 > SoC, the RTC is a wake up source from its "deep sleep" > mode. > > Let platform data set the wakeup capability flag instead. > > Signed-off-by: Sekhar Nori > Signed-off-by: Kevin Hilman Any comments on this patch? Thanks, Sekhar From erezk at radvision.com Tue Jan 5 02:20:59 2010 From: erezk at radvision.com (Erez Kinarti) Date: Tue, 5 Jan 2010 10:20:59 +0200 Subject: Cmem address translation when working with Codec Engine In-Reply-To: <6B8224E84039B140AA662F0BB03616430122A5A903@dlee04.ent.ti.com> References: <6B8224E84039B140AA662F0BB03616430122930FB8@dlee04.ent.ti.com><10B9B66481AB544596EF70B519D5899601D52422@rvil-mail1.RADVISION.com><4B4220A7.6090506@nt.tu-darmstadt.de><10B9B66481AB544596EF70B519D5899601D52423@rvil-mail1.RADVISION.com> <6B8224E84039B140AA662F0BB03616430122A5A903@dlee04.ent.ti.com> Message-ID: <10B9B66481AB544596EF70B519D5899601D52458@rvil-mail1.RADVISION.com> Thank you very much Rob, I'm going to try it now. Just one open issue is the size of the big buffer: In the app I cannot be sure what is the buffer size that CMEM allocated for me, I just know that the size is at least the size that I requested. Do I have to put the size parameter in these function the exact size allocated by CMEM, or just the size that I use is enough? In case I must use the size allocated by CMEM, is there a way to know what this size is? Thanks, Erez -----Original Message----- From: Tivy, Robert [mailto:rtivy at ti.com] Sent: Tuesday, January 05, 2010 1:30 AM To: Erez Kinarti; Vladimir Pantelic; Davinci-linux-open-source at linux.davincidsp.com Subject: RE: Cmem address translation when working with Codec Engine There is no function available to invalidate all the Memory module virt-phys translations. If your app structure allows it, you can call Memory_registerContigBuf(bigCMEMBufferVirtAddr, 258048, CMEM_getPhys(bigCMEMBufferVirtAddr)); once, and all smaller subdivided buffers will be covered by this one registration (or, even simpler, just call Memory_getBufferPhysicalAddress(bigCMEMBufferVirtAddr, 258048, NULL); and ignore the result, which will do the CMEM_getPhys() for you and register it). You can then call Memory_unregisterContigBuf(bigCMEMBufferVirtAddr, 258048) once when you're ready to free the CMEM buffer. FYI, if you want to double-check me, you can call Memory_dumpKnownContigBufsList() to display (through GT tracing) the contig buffer list (AKA, the Memory module virt-phys translation table). Regards, - Rob > -----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 Erez Kinarti > Sent: Monday, January 04, 2010 9:15 AM > To: Vladimir Pantelic; Davinci-linux-open-source at linux.davincidsp.com > Subject: RE: Cmem address translation when working with Codec Engine > > Thank you Vladimir, > But we are not able to allocate and free via CodecEngine due > to the structure of our application and the need to call the > alloc not before calling CERuntimeInit(). > > > -----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 Vladimir Pantelic > Sent: Monday, January 04, 2010 7:09 PM > To: Davinci-linux-open-source at linux.davincidsp.com > Subject: Re: Cmem address translation when working with Codec Engine > > Erez Kinarti wrote: > > Thanks a lot Rob. > > > > calling this function for each of the pointers used with > CodecEngine > > solved the problem. > > > > However, we need something else, some function that invalidates all > this > > virt->phy table and not each of the virtual pointers separately. > > > > Is there a way to do a full invalidate in a single call > without keep > > tracking on each of the virtual pointers? > > > > The reason that Memory_unregisterContigBuf it is not enough for us: > > > > In our system, we allocate a very big buffer from CMEM > (258048 bytes), > > but we don't call CodecEngine with a pointer to the big buffer. > > You dont need to call Memory_unregisterContigBuf, just alloc > and free the buffers via CE and CE will know that you are > calling it with a smaller buffer inside a larger one that it > knows the translation to... > > _______________________________________________ > 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 pan at nt.tu-darmstadt.de Tue Jan 5 02:59:08 2010 From: pan at nt.tu-darmstadt.de (Vladimir Pantelic) Date: Tue, 05 Jan 2010 09:59:08 +0100 Subject: codec hangs In-Reply-To: References: <6B8224E84039B140AA662F0BB03616430122A5A994@dlee04.ent.ti.com> Message-ID: <4B42FF5C.8080007@nt.tu-darmstadt.de> Albert Burbea wrote: > Hi > thanks for your help - the problem is that the JPEG codec is TI's and I > do not have access to its source code. > What could hang the message queue ? > Thanks again > Albert > Hi everybody, > I am using mv 4.01 with codec engine 2.01. I am integrating the > TI JPEG encoder 1.1.13. At the beginning it did not work,it did > not even open, until I modified the JPEGENC.xs to return the > saram and daram scratch sizes. Before that, I modified also the > ce/JPEGENC.xdc to use an IMGENC1 VISA interface instead of the > IMGENC interface. I was able to open it and do an XDM_SETPARAMS > control, but I did not try anything more. I restored the IMGENC > interface in ce/JPEGENC.xdc, and compiled. Still worked. Then, I well, what API is this codec using? IMGENC or IMGENC1? You have to use the correct API of course and you say that IMGENC1 worked, so why are you trying IMGENC? From erezk at radvision.com Tue Jan 5 03:00:44 2010 From: erezk at radvision.com (Erez Kinarti) Date: Tue, 5 Jan 2010 11:00:44 +0200 Subject: Cmem address translation when working with Codec Engine In-Reply-To: <6B8224E84039B140AA662F0BB03616430122A5A903@dlee04.ent.ti.com> References: <6B8224E84039B140AA662F0BB03616430122930FB8@dlee04.ent.ti.com><10B9B66481AB544596EF70B519D5899601D52422@rvil-mail1.RADVISION.com><4B4220A7.6090506@nt.tu-darmstadt.de><10B9B66481AB544596EF70B519D5899601D52423@rvil-mail1.RADVISION.com> <6B8224E84039B140AA662F0BB03616430122A5A903@dlee04.ent.ti.com> Message-ID: <10B9B66481AB544596EF70B519D5899601D5245F@rvil-mail1.RADVISION.com> Hey Rob, I see that calling the register functions require that CE is in the air (CERuntimeInit) so it is problematic for us in the same way as doing the CMEM allocations via CodecEngine. So I guess I have no solution except redesigning my system such that CERuntimeInit will be before any buffers allocation. Do you have any other offer that can save me this effort (which is huge)? Thanks in advance, Erez -----Original Message----- From: Tivy, Robert [mailto:rtivy at ti.com] Sent: Tuesday, January 05, 2010 1:30 AM To: Erez Kinarti; Vladimir Pantelic; Davinci-linux-open-source at linux.davincidsp.com Subject: RE: Cmem address translation when working with Codec Engine There is no function available to invalidate all the Memory module virt-phys translations. If your app structure allows it, you can call Memory_registerContigBuf(bigCMEMBufferVirtAddr, 258048, CMEM_getPhys(bigCMEMBufferVirtAddr)); once, and all smaller subdivided buffers will be covered by this one registration (or, even simpler, just call Memory_getBufferPhysicalAddress(bigCMEMBufferVirtAddr, 258048, NULL); and ignore the result, which will do the CMEM_getPhys() for you and register it). You can then call Memory_unregisterContigBuf(bigCMEMBufferVirtAddr, 258048) once when you're ready to free the CMEM buffer. FYI, if you want to double-check me, you can call Memory_dumpKnownContigBufsList() to display (through GT tracing) the contig buffer list (AKA, the Memory module virt-phys translation table). Regards, - Rob > -----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 Erez Kinarti > Sent: Monday, January 04, 2010 9:15 AM > To: Vladimir Pantelic; Davinci-linux-open-source at linux.davincidsp.com > Subject: RE: Cmem address translation when working with Codec Engine > > Thank you Vladimir, > But we are not able to allocate and free via CodecEngine due > to the structure of our application and the need to call the > alloc not before calling CERuntimeInit(). > > > -----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 Vladimir Pantelic > Sent: Monday, January 04, 2010 7:09 PM > To: Davinci-linux-open-source at linux.davincidsp.com > Subject: Re: Cmem address translation when working with Codec Engine > > Erez Kinarti wrote: > > Thanks a lot Rob. > > > > calling this function for each of the pointers used with > CodecEngine > > solved the problem. > > > > However, we need something else, some function that invalidates all > this > > virt->phy table and not each of the virtual pointers separately. > > > > Is there a way to do a full invalidate in a single call > without keep > > tracking on each of the virtual pointers? > > > > The reason that Memory_unregisterContigBuf it is not enough for us: > > > > In our system, we allocate a very big buffer from CMEM > (258048 bytes), > > but we don't call CodecEngine with a pointer to the big buffer. > > You dont need to call Memory_unregisterContigBuf, just alloc > and free the buffers via CE and CE will know that you are > calling it with a smaller buffer inside a larger one that it > knows the translation to... > > _______________________________________________ > 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 pan at nt.tu-darmstadt.de Tue Jan 5 03:14:49 2010 From: pan at nt.tu-darmstadt.de (Vladimir Pantelic) Date: Tue, 05 Jan 2010 10:14:49 +0100 Subject: Cmem address translation when working with Codec Engine In-Reply-To: <10B9B66481AB544596EF70B519D5899601D5245F@rvil-mail1.RADVISION.com> References: <6B8224E84039B140AA662F0BB03616430122930FB8@dlee04.ent.ti.com><10B9B66481AB544596EF70B519D5899601D52422@rvil-mail1.RADVISION.com><4B4220A7.6090506@nt.tu-darmstadt.de><10B9B66481AB544596EF70B519D5899601D52423@rvil-mail1.RADVISION.com> <6B8224E84039B140AA662F0BB03616430122A5A903@dlee04.ent.ti.com> <10B9B66481AB544596EF70B519D5899601D5245F@rvil-mail1.RADVISION.com> Message-ID: <4B430309.30009@nt.tu-darmstadt.de> Erez Kinarti wrote: > Hey Rob, > I see that calling the register functions require that CE is in the air > (CERuntimeInit) so it is problematic for us in the same way as doing the > CMEM allocations via CodecEngine. as you have to call CERuntimeInit() before using any of CE, you can do the Memory_registerContigBuf() after CERuntimeInit(), no? From erezk at radvision.com Tue Jan 5 03:25:37 2010 From: erezk at radvision.com (Erez Kinarti) Date: Tue, 5 Jan 2010 11:25:37 +0200 Subject: Cmem address translation when working with Codec Engine In-Reply-To: <4B430309.30009@nt.tu-darmstadt.de> References: <6B8224E84039B140AA662F0BB03616430122930FB8@dlee04.ent.ti.com><10B9B66481AB544596EF70B519D5899601D52422@rvil-mail1.RADVISION.com><4B4220A7.6090506@nt.tu-darmstadt.de><10B9B66481AB544596EF70B519D5899601D52423@rvil-mail1.RADVISION.com><6B8224E84039B140AA662F0BB03616430122A5A903@dlee04.ent.ti.com><10B9B66481AB544596EF70B519D5899601D5245F@rvil-mail1.RADVISION.com> <4B430309.30009@nt.tu-darmstadt.de> Message-ID: <10B9B66481AB544596EF70B519D5899601D52460@rvil-mail1.RADVISION.com> No, because in my system, the first codec that is generated is calling CERuntimeInit (working with C++, keeping reference counter for the call to CERuntimeInit and CERuntimeExit), while the system buffers are allocated before that. -----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 Vladimir Pantelic Sent: Tuesday, January 05, 2010 11:15 AM To: Davinci-linux-open-source at linux.davincidsp.com Cc: Davinci-linux-open-source at linux.davincidsp.com Subject: Re: Cmem address translation when working with Codec Engine Erez Kinarti wrote: > Hey Rob, > I see that calling the register functions require that CE is in the air > (CERuntimeInit) so it is problematic for us in the same way as doing the > CMEM allocations via CodecEngine. as you have to call CERuntimeInit() before using any of CE, you can do the Memory_registerContigBuf() after CERuntimeInit(), no? _______________________________________________ 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 pan at nt.tu-darmstadt.de Tue Jan 5 03:47:43 2010 From: pan at nt.tu-darmstadt.de (Vladimir Pantelic) Date: Tue, 05 Jan 2010 10:47:43 +0100 Subject: Cmem address translation when working with Codec Engine In-Reply-To: <10B9B66481AB544596EF70B519D5899601D52460@rvil-mail1.RADVISION.com> References: <6B8224E84039B140AA662F0BB03616430122930FB8@dlee04.ent.ti.com><10B9B66481AB544596EF70B519D5899601D52422@rvil-mail1.RADVISION.com><4B4220A7.6090506@nt.tu-darmstadt.de><10B9B66481AB544596EF70B519D5899601D52423@rvil-mail1.RADVISION.com><6B8224E84039B140AA662F0BB03616430122A5A903@dlee04.ent.ti.com><10B9B66481AB544596EF70B519D5899601D5245F@rvil-mail1.RADVISION.com> <4B430309.30009@nt.tu-darmstadt.de> <10B9B66481AB544596EF70B519D5899601D52460@rvil-mail1.RADVISION.com> Message-ID: <4B430ABF.9090808@nt.tu-darmstadt.de> Erez Kinarti wrote: > No, because in my system, the first codec that is generated is calling > CERuntimeInit (working with C++, keeping reference counter for the call > to CERuntimeInit and CERuntimeExit), while the system buffers are > allocated before that. well, then move that call outside of the codecs.... From erezk at radvision.com Tue Jan 5 04:41:41 2010 From: erezk at radvision.com (Erez Kinarti) Date: Tue, 5 Jan 2010 12:41:41 +0200 Subject: Cmem address translation when working with Codec Engine In-Reply-To: <4B430ABF.9090808@nt.tu-darmstadt.de> References: <6B8224E84039B140AA662F0BB03616430122930FB8@dlee04.ent.ti.com><10B9B66481AB544596EF70B519D5899601D52422@rvil-mail1.RADVISION.com><4B4220A7.6090506@nt.tu-darmstadt.de><10B9B66481AB544596EF70B519D5899601D52423@rvil-mail1.RADVISION.com><6B8224E84039B140AA662F0BB03616430122A5A903@dlee04.ent.ti.com><10B9B66481AB544596EF70B519D5899601D5245F@rvil-mail1.RADVISION.com><4B430309.30009@nt.tu-darmstadt.de><10B9B66481AB544596EF70B519D5899601D52460@rvil-mail1.RADVISION.com> <4B430ABF.9090808@nt.tu-darmstadt.de> Message-ID: <10B9B66481AB544596EF70B519D5899601D52473@rvil-mail1.RADVISION.com> You are totally correct, it is just that our system is in a validation stage where we don't want to touch anything (in order to avoid doing all the testing cycle again), and moving the CERuntimeInit to be before the buffers allocation will require some changes that I don't want to do in such stage. Of course I'll do it if I have no other choice ... -----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 Vladimir Pantelic Sent: Tuesday, January 05, 2010 11:48 AM To: Davinci-linux-open-source at linux.davincidsp.com Subject: Re: Cmem address translation when working with Codec Engine Erez Kinarti wrote: > No, because in my system, the first codec that is generated is calling > CERuntimeInit (working with C++, keeping reference counter for the call > to CERuntimeInit and CERuntimeExit), while the system buffers are > allocated before that. well, then move that call outside of the codecs.... _______________________________________________ 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 jatinpasrija at gmail.com Tue Jan 5 06:23:03 2010 From: jatinpasrija at gmail.com (Jatin Pasrija) Date: Tue, 5 Jan 2010 20:23:03 +0800 Subject: Image manipulation on DM355 Message-ID: <1c4ff37f1001050423w31629520h4b91f954f63d84ab@mail.gmail.com> Hi I want to display an image using DM355 along with a text menu and some other images on the side. What is the best way that I can manipulate size and location of images displayed on the screen. Till now I have only managed to display a full jpeg image using the demo code in DM355 and the frame buffer. I am a student and have just started working on Da Vinci, hence kindly reply accordingly. Thanks a lot Jatin Pasrija -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggottumu at Cernium.com Tue Jan 5 08:35:46 2010 From: ggottumu at Cernium.com (Gopala Gottumukkala) Date: Tue, 5 Jan 2010 09:35:46 -0500 Subject: USB storage error References: <03A2FA9E0D3DC841992E682BF528771801747AD2@lipwig.Cernium.local> Message-ID: <03A2FA9E0D3DC841992E682BF528771801747D65@lipwig.Cernium.local> Which kernel version number is working for you can I know the kernel version number and if any patches please let me know the patches also. - Gopala From: Gopala Gottumukkala Sent: Monday, January 04, 2010 9:13 AM To: 'Subbrathnam, Swaminathan'; davinci-linux-open-source at linux.davincidsp.com Subject: RE: USB storage error Can I know the latest Davinci Git kernel version which is working for you. The kernel version number and where can I down load the latest one. - Gopala From: Subbrathnam, Swaminathan [mailto:swami.iyer at ti.com] Sent: Friday, January 01, 2010 8:10 AM To: Gopala Gottumukkala; davinci-linux-open-source at linux.davincidsp.com Subject: RE: USB storage error Gopala, Could you try the latest DaVinci Git. It works for me. regards swami ________________________________ From: davinci-linux-open-source-bounces at linux.davincidsp.com [davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Gopala Gottumukkala [ggottumu at Cernium.com] Sent: Friday, January 01, 2010 1:38 AM To: davinci-linux-open-source at linux.davincidsp.com Subject: USB storage error I have compiled davinci 2.6.30 I mounted the usb manually I ran some sample program which will open, write and delete the file into usb drive. While writing the file into usb drive. It gives the following error and the program dies. Any help would be appreciated on this usb 1-1: reset high speed USB device using musb_hdrc and address 2 usb 1-1: reset high speed USB device using musb_hdrc and address 2 usb 1-1: reset high speed USB device using musb_hdrc and address 2 sd 0:0:0:0: Device offlined - not ready after error recovery sd 0:0:0:0: [sda] Unhandled error code sd 0:0:0:0: [sda] Result: hostbyte=0x05 driverbyte=0x00 end_request: I/O error, dev sda, sector 41584 sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: [sda] Unhandled error code sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sda, sector 40000 sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device - Gopala NOTICE: The information contained in this email and any document attached hereto is intended only for the named recipient(s). It is the property of Cernium Corporation and shall not be used, disclosed or reproduced without the express written consent of Cernium Corporation. If you are not the intended recipient (or the employee or agent responsible for delivering this message in confidence to the intended recipient(s)), you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this transmittal or its attachments is strictly prohibited. If you have received this transmittal and/or attachments in error, please notify me immediately by reply email or telephone and immediately delete this message and all its attachments. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From swami.iyer at ti.com Tue Jan 5 08:41:01 2010 From: swami.iyer at ti.com (Subbrathnam, Swaminathan) Date: Tue, 5 Jan 2010 20:11:01 +0530 Subject: USB storage error In-Reply-To: <03A2FA9E0D3DC841992E682BF528771801747D65@lipwig.Cernium.local> References: <03A2FA9E0D3DC841992E682BF528771801747AD2@lipwig.Cernium.local> <03A2FA9E0D3DC841992E682BF528771801747D65@lipwig.Cernium.local> Message-ID: Pl. refer to DaVinci Staging GIT kernel hosted at http://arago-project.org/git/people/?p=sneha/linux-davinci-staging.git;a=summary. ________________________________ From: Gopala Gottumukkala [mailto:ggottumu at Cernium.com] Sent: Tuesday, January 05, 2010 8:06 PM To: Subbrathnam, Swaminathan; davinci-linux-open-source at linux.davincidsp.com Subject: RE: USB storage error Which kernel version number is working for you can I know the kernel version number and if any patches please let me know the patches also. - Gopala From: Gopala Gottumukkala Sent: Monday, January 04, 2010 9:13 AM To: 'Subbrathnam, Swaminathan'; davinci-linux-open-source at linux.davincidsp.com Subject: RE: USB storage error Can I know the latest Davinci Git kernel version which is working for you. The kernel version number and where can I down load the latest one. - Gopala From: Subbrathnam, Swaminathan [mailto:swami.iyer at ti.com] Sent: Friday, January 01, 2010 8:10 AM To: Gopala Gottumukkala; davinci-linux-open-source at linux.davincidsp.com Subject: RE: USB storage error Gopala, Could you try the latest DaVinci Git. It works for me. regards swami ________________________________ From: davinci-linux-open-source-bounces at linux.davincidsp.com [davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Gopala Gottumukkala [ggottumu at Cernium.com] Sent: Friday, January 01, 2010 1:38 AM To: davinci-linux-open-source at linux.davincidsp.com Subject: USB storage error I have compiled davinci 2.6.30 I mounted the usb manually I ran some sample program which will open, write and delete the file into usb drive. While writing the file into usb drive. It gives the following error and the program dies. Any help would be appreciated on this usb 1-1: reset high speed USB device using musb_hdrc and address 2 usb 1-1: reset high speed USB device using musb_hdrc and address 2 usb 1-1: reset high speed USB device using musb_hdrc and address 2 sd 0:0:0:0: Device offlined - not ready after error recovery sd 0:0:0:0: [sda] Unhandled error code sd 0:0:0:0: [sda] Result: hostbyte=0x05 driverbyte=0x00 end_request: I/O error, dev sda, sector 41584 sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: [sda] Unhandled error code sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sda, sector 40000 sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device - Gopala NOTICE: The information contained in this email and any document attached hereto is intended only for the named recipient(s). It is the property of Cernium Corporation and shall not be used, disclosed or reproduced without the express written consent of Cernium Corporation. If you are not the intended recipient (or the employee or agent responsible for delivering this message in confidence to the intended recipient(s)), you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this transmittal or its attachments is strictly prohibited. If you have received this transmittal and/or attachments in error, please notify me immediately by reply email or telephone and immediately delete this message and all its attachments. Thank you. NOTICE: The information contained in this email and any document attached hereto is intended only for the named recipient(s). It is the property of Cernium Corporation and shall not be used, disclosed or reproduced without the express written consent of Cernium Corporation. If you are not the intended recipient (or the employee or agent responsible for delivering this message in confidence to the intended recipient(s)), you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this transmittal or its attachments is strictly prohibited. If you have received this transmittal and/or attachments in error, please notify me immediately by reply email or telephone and immediately delete this message and all its attachments. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Paul_Stuart at seektech.com Tue Jan 5 09:25:32 2010 From: Paul_Stuart at seektech.com (Paul Stuart) Date: Tue, 5 Jan 2010 07:25:32 -0800 Subject: Arago Kerenel w/ codec_engine_2_00_01 issues? In-Reply-To: <6B8224E84039B140AA662F0BB03616430122A5A9AC@dlee04.ent.ti.com> References: <7F1B6BBBDF05C649BBBA3C853F488A6119BDDFC806@Hawking.deepsea.com>, <6B8224E84039B140AA662F0BB03616430122A5A9AC@dlee04.ent.ti.com> Message-ID: <7F1B6BBBDF05C649BBBA3C853F488A6119BDDFC80C@Hawking.deepsea.com> Thanks for the response! I'll give the latest CMEM, LinuxUtils, et al a whirl and see what happens. The strange thing is that the mpeg4 decoder, jpeg encode/decode, and mp3 encode/decode all load without complaint. It's just the mpeg4enc that fails. I've rebuilt cmemk.ko and dm350mmap.ko against the arago kernel. Neither process was straight forward though because of changes between the montavista kernel we were using. Maybe something got botched in the process. Turning on the trace, with CE_DEBUG=2, I get the following during mpeg4enc initialization: @5,653,051us: [+0 T:0x43300490] ti.sdo.ce.video1.VIDENC1 - VIDENC1_create> Enter (engine=0x100670, name='mpeg4enc', params=0x432ffca8) @5,653,350us: [+0 T:0x43300490] CV - VISA_create(0x100670, 'mpeg4enc', 0x432ffca8, 0x2496, 'ti.sdo.ce.video1.IVIDENC1') @5,653,569us: [+0 T:0x43300490] CV - VISA_create2(0x100670, 'mpeg4enc', 0x432ffca8, 0x30, 0x2496, 'ti.sdo.ce.video1.IVIDENC1') @5,654,187us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - Algorithm_create> Enter(fxns=0xf89c0, idma3Fxns=0xf8988, iresFxns=0x0, params=0x432ffca8, attrs=0x432ffac8) @5,654,470us: [+0 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create> Enter (scratchId=1, fxns=0xf89c0, parentAlg=0x0, params=0x432ffca8) @5,678,280us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create> algNumAlloc 7 memory recs @5,678,574us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create> algAlloc returned numRecs=7 @5,678,777us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create> Memory requested memTab[0]: size=0x2c58, align=0x100, space=0x11, attrs=0x1 @5,678,985us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create> Memory requested memTab[1]: size=0x200, align=0x100, space=0x11, attrs=0x1 @5,679,182us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create> Memory requested memTab[2]: size=0x19a400, align=0x100, space=0x11, attrs=0x1 @5,679,568us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create> Memory requested memTab[3]: size=0x10e0, align=0x100, space=0x11, attrs=0x1 @5,679,816us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create> Memory requested memTab[4]: size=0x4, align=0x100, space=0x11, attrs=0x1 @5,680,026us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create> Memory requested memTab[5]: size=0x14000, align=0x100, space=0x11, attrs=0x1 @5,680,233us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create> Memory requested memTab[6]: size=0x3840, align=0x100, space=0x11, attrs=0x1 @5,680,648us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_alloc(11352) = 0x43301000. @5,680,909us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_getPhys(0x43301000) = 0x8702c000. @5,681,514us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_alloc(512) = 0x42a02000. @5,681,792us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_getPhys(0x42a02000) = 0x87018000. @5,682,401us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_alloc(1680384) = 0x43305000. @5,682,711us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_getPhys(0x43305000) = 0x87e00000. @5,698,324us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_alloc(4320) = 0x43505000. @5,698,622us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_getPhys(0x43505000) = 0x8702a000. @5,699,098us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_alloc(4) = 0x43507000. @5,699,535us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_getPhys(0x43507000) = 0x87019000. @5,700,033us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_alloc(81920) = 0x43508000. @5,700,348us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_getPhys(0x43508000) = 0x8704e000. @5,701,570us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_alloc(14400) = 0x4351c000. @5,701,844us: [+4 T:0x43300490] OM - Memory_contigAlloc> CMEM_getPhys(0x4351c000) = 0x87030000. @5,757,804us: [+7 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create> algInit call failed 49280 @5,765,522us: [+0 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create> Exit (algHandle=NULL) @5,765,791us: [+7 T:0x43300490] ti.sdo.ce.alg.Algorithm - Algorithm_create> Algorithm creation FAILED; make sure that 1) alg params are correct/appropriate, 2) there is enough internal and external algorithm memory available -- check DSKT2 settings for heap assignments and scratch allocation @5,766,031us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - Algorithm_delete> Enter(alg=0x1fb020) @5,766,236us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - Algorithm_create> return (0x0) @5,766,462us: [+2 T:0x43300490] CV - VISA_create> FAILED to create local codec. @5,766,648us: [+0 T:0x43300490] CV - VISA_delete(0x1439f8) @5,766,817us: [+5 T:0x43300490] CV - VISA_delete> deleting codec (localQueue=0xffff, remoteQueue=0xffff) @5,767,009us: [+0 T:0x43300490] ti.sdo.ce.video1.VIDENC1 - VIDENC1_create> return (0x0) Dvr_Titler Error: Failed to open video encode algorithm: mpeg4enc (0x0) >From the trace, it looks like cmem is allocating the the memory requested. I've tried passing in the default parameters to the algorithm, the parameters used in the dvsdk encode demo, as well as the parameters that worked for us previously. I don't know how to check the DSKT2 settings. Is there any way to add more tracing to the Algorithm create? It fails somewhat silently. Also strange that the last error from the Codec engine is 0x0 (mpeg4enc (0x0)), not sure why it would fail to initialize the algorithm and still return no error. I appreciate the help! Paul ________________________________________ From: Tivy, Robert [rtivy at ti.com] Sent: Monday, January 04, 2010 6:07 PM To: Paul Stuart; davinci-linux-open-source at linux.davincidsp.com Subject: RE: Arago Kerenel w/ codec_engine_2_00_01 issues? Generally, user-level code doesn't care much about the kernel version, and CE itself is all user-level code. Since CE encapsulates other packages that do contain kernel modules (which do care about kernel version), such as CMEM in LinuxUtils and DSPLink, the problem probably is with those. The kernel modules call APIs that can come or go with particular Linux kernels, hence the dependency of kernel modules on the kernel. Typically you will need to rebuild the kernel modules for the particular kernel that you're running. Rebuilding is also important with respect to simply inserting the kernel modules (usually done with a "loadmodules.sh" script) - you can't insert a kernel module that's been built against a kernel other than the one you're running (although there is some flexibility if the kernels in question are "close enough" to each other). It would help if you described your problem opening the mpeg4enc video encode algorithm. CE 2.00.01 is fairly old at this point, much older than 2.6.26 Linux. I would suggest updating to a newer CE, which also might just fix your problem. Regards, - Rob > -----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 Paul Stuart > Sent: Thursday, December 31, 2009 12:55 PM > To: davinci-linux-open-source at linux.davincidsp.com > Subject: Arago Kerenel w/ codec_engine_2_00_01 issues? > > Hi There, > Wondering if there is any magic that has to happen to make > the dvsdk's codec engine (2_00_01) play with the arago kernel > (2.6.26)? Everything compiles fine, but my app can't open the > mpeg4enc video encode algorithm. > Thanks, > Paul > _______________________________________________ > 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 ggottumu at Cernium.com Tue Jan 5 09:34:06 2010 From: ggottumu at Cernium.com (Gopala Gottumukkala) Date: Tue, 5 Jan 2010 10:34:06 -0500 Subject: how do i enable full speed instead of high speed in the USB In-Reply-To: References: <03A2FA9E0D3DC841992E682BF528771801747AD2@lipwig.Cernium.local> <03A2FA9E0D3DC841992E682BF528771801747D65@lipwig.Cernium.local> Message-ID: <03A2FA9E0D3DC841992E682BF528771801747DA9@lipwig.Cernium.local> I want to use Full speed instead of high speed. What needs to be done to work with full speed. Help appreciated, Thanks - Gopala From: Subbrathnam, Swaminathan [mailto:swami.iyer at ti.com] Sent: Tuesday, January 05, 2010 9:41 AM To: Gopala Gottumukkala; davinci-linux-open-source at linux.davincidsp.com Subject: RE: USB storage error Pl. refer to DaVinci Staging GIT kernel hosted at http://arago-project.org/git/people/?p=sneha/linux-davinci-staging.git;a =summary. ________________________________ From: Gopala Gottumukkala [mailto:ggottumu at Cernium.com] Sent: Tuesday, January 05, 2010 8:06 PM To: Subbrathnam, Swaminathan; davinci-linux-open-source at linux.davincidsp.com Subject: RE: USB storage error Which kernel version number is working for you can I know the kernel version number and if any patches please let me know the patches also. - Gopala From: Gopala Gottumukkala Sent: Monday, January 04, 2010 9:13 AM To: 'Subbrathnam, Swaminathan'; davinci-linux-open-source at linux.davincidsp.com Subject: RE: USB storage error Can I know the latest Davinci Git kernel version which is working for you. The kernel version number and where can I down load the latest one. - Gopala From: Subbrathnam, Swaminathan [mailto:swami.iyer at ti.com] Sent: Friday, January 01, 2010 8:10 AM To: Gopala Gottumukkala; davinci-linux-open-source at linux.davincidsp.com Subject: RE: USB storage error Gopala, Could you try the latest DaVinci Git. It works for me. regards swami ________________________________ From: davinci-linux-open-source-bounces at linux.davincidsp.com [davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Gopala Gottumukkala [ggottumu at Cernium.com] Sent: Friday, January 01, 2010 1:38 AM To: davinci-linux-open-source at linux.davincidsp.com Subject: USB storage error I have compiled davinci 2.6.30 I mounted the usb manually I ran some sample program which will open, write and delete the file into usb drive. While writing the file into usb drive. It gives the following error and the program dies. Any help would be appreciated on this usb 1-1: reset high speed USB device using musb_hdrc and address 2 usb 1-1: reset high speed USB device using musb_hdrc and address 2 usb 1-1: reset high speed USB device using musb_hdrc and address 2 sd 0:0:0:0: Device offlined - not ready after error recovery sd 0:0:0:0: [sda] Unhandled error code sd 0:0:0:0: [sda] Result: hostbyte=0x05 driverbyte=0x00 end_request: I/O error, dev sda, sector 41584 sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: [sda] Unhandled error code sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sda, sector 40000 sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device - Gopala NOTICE: The information contained in this email and any document attached hereto is intended only for the named recipient(s). It is the property of Cernium Corporation and shall not be used, disclosed or reproduced without the express written consent of Cernium Corporation. If you are not the intended recipient (or the employee or agent responsible for delivering this message in confidence to the intended recipient(s)), you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this transmittal or its attachments is strictly prohibited. If you have received this transmittal and/or attachments in error, please notify me immediately by reply email or telephone and immediately delete this message and all its attachments. Thank you. NOTICE: The information contained in this email and any document attached hereto is intended only for the named recipient(s). It is the property of Cernium Corporation and shall not be used, disclosed or reproduced without the express written consent of Cernium Corporation. If you are not the intended recipient (or the employee or agent responsible for delivering this message in confidence to the intended recipient(s)), you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this transmittal or its attachments is strictly prohibited. If you have received this transmittal and/or attachments in error, please notify me immediately by reply email or telephone and immediately delete this message and all its attachments. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cring at ti.com Tue Jan 5 09:57:45 2010 From: cring at ti.com (Ring, Chris) Date: Tue, 5 Jan 2010 09:57:45 -0600 Subject: Arago Kerenel w/ codec_engine_2_00_01 issues? In-Reply-To: <7F1B6BBBDF05C649BBBA3C853F488A6119BDDFC80C@Hawking.deepsea.com> References: <7F1B6BBBDF05C649BBBA3C853F488A6119BDDFC806@Hawking.deepsea.com>, <6B8224E84039B140AA662F0BB03616430122A5A9AC@dlee04.ent.ti.com> <7F1B6BBBDF05C649BBBA3C853F488A6119BDDFC80C@Hawking.deepsea.com> Message-ID: <92CDD168D1E81F4F9D3839DC45903FC66E72D25B@dlee03.ent.ti.com> First, it looks like your on a DM355 or DM365 as this codec is 'local' (i.e. running on the same processor as your app). That helps eliminate some complexity (e.g. no DSP Link, and no DSKT2... the warning msg is misleading - there's no DSKT2 in a DM355/365 system). Also from the trace, I can see that the memory requested by the alg succeeds (the codec needs 7 distinct memory blocks, and I can see 7 successful CMEM alloc() calls being made). However, during the algInit() call (where Codec Engine provides this newly allocated memory to the codec), the codec is returning 49280 (0xC080). So the codec didn't like something it was given - either the memory (unlikely) or the creation params(?) - and returned this error. Do the codec docs (or headers?) provide any details about this specific error code (0xC080)? Does it fail if you pass in NULL as the create() params? Finally, to your specific question, the error returned (mpeg4enc (0x0)) indicates a NULL handle, not a success code. Chris > -----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 Paul Stuart > Sent: Tuesday, January 05, 2010 7:26 AM > To: Tivy, Robert; davinci-linux-open-source at linux.davincidsp.com > Subject: RE: Arago Kerenel w/ codec_engine_2_00_01 issues? > > Thanks for the response! > > I'll give the latest CMEM, LinuxUtils, et al a whirl and see > what happens. The strange thing is that the mpeg4 decoder, > jpeg encode/decode, and mp3 encode/decode all load without > complaint. It's just the mpeg4enc that fails. > > > I've rebuilt cmemk.ko and dm350mmap.ko against the arago > kernel. Neither process was straight forward though because > of changes between the montavista kernel we were using. Maybe > something got botched in the process. > > > Turning on the trace, with CE_DEBUG=2, I get the following > during mpeg4enc initialization: > > > @5,653,051us: [+0 T:0x43300490] ti.sdo.ce.video1.VIDENC1 - > VIDENC1_create> Enter (engine=0x100670, name='mpeg4enc', > params=0x432ffca8) > @5,653,350us: [+0 T:0x43300490] CV - VISA_create(0x100670, > 'mpeg4enc', 0x432ffca8, 0x2496, 'ti.sdo.ce.video1.IVIDENC1') > @5,653,569us: [+0 T:0x43300490] CV - VISA_create2(0x100670, > 'mpeg4enc', 0x432ffca8, 0x30, 0x2496, 'ti.sdo.ce.video1.IVIDENC1') > @5,654,187us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - > Algorithm_create> Enter(fxns=0xf89c0, idma3Fxns=0xf8988, > iresFxns=0x0, params=0x432ffca8, attrs=0x432ffac8) > @5,654,470us: [+0 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Enter (scratchId=1, fxns=0xf89c0, parentAlg=0x0, > params=0x432ffca8) > @5,678,280us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> algNumAlloc 7 memory recs > @5,678,574us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> algAlloc returned numRecs=7 > @5,678,777us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[0]: size=0x2c58, > align=0x100, space=0x11, attrs=0x1 > @5,678,985us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[1]: size=0x200, > align=0x100, space=0x11, attrs=0x1 > @5,679,182us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[2]: size=0x19a400, > align=0x100, space=0x11, attrs=0x1 > @5,679,568us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[3]: size=0x10e0, > align=0x100, space=0x11, attrs=0x1 > @5,679,816us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[4]: size=0x4, > align=0x100, space=0x11, attrs=0x1 > @5,680,026us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[5]: size=0x14000, > align=0x100, space=0x11, attrs=0x1 > @5,680,233us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[6]: size=0x3840, > align=0x100, space=0x11, attrs=0x1 > @5,680,648us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(11352) = 0x43301000. > @5,680,909us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x43301000) = 0x8702c000. > @5,681,514us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(512) = 0x42a02000. > @5,681,792us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x42a02000) = 0x87018000. > @5,682,401us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(1680384) = 0x43305000. > @5,682,711us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x43305000) = 0x87e00000. > @5,698,324us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(4320) = 0x43505000. > @5,698,622us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x43505000) = 0x8702a000. > @5,699,098us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(4) = 0x43507000. > @5,699,535us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x43507000) = 0x87019000. > @5,700,033us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(81920) = 0x43508000. > @5,700,348us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x43508000) = 0x8704e000. > @5,701,570us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(14400) = 0x4351c000. > @5,701,844us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x4351c000) = 0x87030000. > @5,757,804us: [+7 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> algInit call failed 49280 > @5,765,522us: [+0 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Exit (algHandle=NULL) > @5,765,791us: [+7 T:0x43300490] ti.sdo.ce.alg.Algorithm - > Algorithm_create> Algorithm creation FAILED; make sure that > 1) alg params are correct/appropriate, 2) there is enough > internal and external algorithm memory available -- check > DSKT2 settings for heap assignments and scratch allocation > @5,766,031us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - > Algorithm_delete> Enter(alg=0x1fb020) > @5,766,236us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - > Algorithm_create> return (0x0) > @5,766,462us: [+2 T:0x43300490] CV - VISA_create> FAILED to > create local codec. > @5,766,648us: [+0 T:0x43300490] CV - VISA_delete(0x1439f8) > @5,766,817us: [+5 T:0x43300490] CV - VISA_delete> deleting > codec (localQueue=0xffff, remoteQueue=0xffff) > @5,767,009us: [+0 T:0x43300490] ti.sdo.ce.video1.VIDENC1 - > VIDENC1_create> return (0x0) > Dvr_Titler Error: Failed to open video encode algorithm: > mpeg4enc (0x0) > > > >From the trace, it looks like cmem is allocating the the > memory requested. I've tried passing in the default > parameters to the algorithm, the parameters used in the dvsdk > encode demo, as well as the parameters that worked for us > previously. I don't know how to check the DSKT2 settings. > > Is there any way to add more tracing to the Algorithm create? > It fails somewhat silently. Also strange that the last error > from the Codec engine is 0x0 (mpeg4enc (0x0)), not sure why > it would fail to initialize the algorithm and still return no error. > > > I appreciate the help! > > Paul > > ________________________________________ > From: Tivy, Robert [rtivy at ti.com] > Sent: Monday, January 04, 2010 6:07 PM > To: Paul Stuart; davinci-linux-open-source at linux.davincidsp.com > Subject: RE: Arago Kerenel w/ codec_engine_2_00_01 issues? > > Generally, user-level code doesn't care much about the kernel > version, and CE itself is all user-level code. Since CE > encapsulates other packages that do contain kernel modules > (which do care about kernel version), such as CMEM in > LinuxUtils and DSPLink, the problem probably is with those. > > The kernel modules call APIs that can come or go with > particular Linux kernels, hence the dependency of kernel > modules on the kernel. Typically you will need to rebuild > the kernel modules for the particular kernel that you're > running. Rebuilding is also important with respect to simply > inserting the kernel modules (usually done with a > "loadmodules.sh" script) - you can't insert a kernel module > that's been built against a kernel other than the one you're > running (although there is some flexibility if the kernels in > question are "close enough" to each other). > > It would help if you described your problem opening the > mpeg4enc video encode algorithm. CE 2.00.01 is fairly old at > this point, much older than 2.6.26 Linux. I would suggest > updating to a newer CE, which also might just fix your problem. > > Regards, > > - Rob > > > -----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 Paul Stuart > > Sent: Thursday, December 31, 2009 12:55 PM > > To: davinci-linux-open-source at linux.davincidsp.com > > Subject: Arago Kerenel w/ codec_engine_2_00_01 issues? > > > > Hi There, > > Wondering if there is any magic that has to happen to make > > the dvsdk's codec engine (2_00_01) play with the arago kernel > > (2.6.26)? Everything compiles fine, but my app can't open the > > mpeg4enc video encode algorithm. > > Thanks, > > Paul > > _______________________________________________ > > 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 ggottumu at Cernium.com Tue Jan 5 10:12:00 2010 From: ggottumu at Cernium.com (Gopala Gottumukkala) Date: Tue, 5 Jan 2010 11:12:00 -0500 Subject: Default config file when we do make menuconfig In-Reply-To: <7F1B6BBBDF05C649BBBA3C853F488A6119BDDFC80C@Hawking.deepsea.com> References: <7F1B6BBBDF05C649BBBA3C853F488A6119BDDFC806@Hawking.deepsea.com>, <6B8224E84039B140AA662F0BB03616430122A5A9AC@dlee04.ent.ti.com> <7F1B6BBBDF05C649BBBA3C853F488A6119BDDFC80C@Hawking.deepsea.com> Message-ID: <03A2FA9E0D3DC841992E682BF528771801747DC6@lipwig.Cernium.local> Hello Gurus, Looks to me like when I download a new kernel from the git or arago and do make menuconfig I don't see Davinci related arch. I need to do make arch-arm davinci_all_defconfig. Then do the make. Is there a way where you can include the davinci related arch in the system arch. - Gopala From raghav.moko at gmail.com Tue Jan 5 12:51:20 2010 From: raghav.moko at gmail.com (raghav n) Date: Wed, 6 Jan 2010 00:21:20 +0530 Subject: [PATCH] MMC: DaVinci: Fixed typos in comments of the response registers in davinci_mmc.c Message-ID: [PATCH 1/1] MMC: DaVinci: Fixed typos in comments of the response registers in davinci_mmc.c This patch fixes the typos in the comments for the MMC response registers. They were all /* Response Register 0 and 1 */ Signed-off-by: raghav.moko at gmail.com --- >From 08e00d18ca5d0c20a9035c631e7fcb5f39c88cb8 Mon Sep 17 00:00:00 2001 From: raghav Date: Tue, 5 Jan 2010 23:57:17 +0530 Subject: [PATCH] Fixed comments for the response registers. They were all saying Regiser 0 and 1. --- drivers/mmc/host/davinci_mmc.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c index dd45e7c..73a6a14 100644 --- a/drivers/mmc/host/davinci_mmc.c +++ b/drivers/mmc/host/davinci_mmc.c @@ -54,9 +54,9 @@ #define DAVINCI_MMCCMD 0x30 /* Command Register */ #define DAVINCI_MMCARGHL 0x34 /* Argument Register */ #define DAVINCI_MMCRSP01 0x38 /* Response Register 0 and 1 */ -#define DAVINCI_MMCRSP23 0x3C /* Response Register 0 and 1 */ -#define DAVINCI_MMCRSP45 0x40 /* Response Register 0 and 1 */ -#define DAVINCI_MMCRSP67 0x44 /* Response Register 0 and 1 */ +#define DAVINCI_MMCRSP23 0x3C /* Response Register 2 and 3 */ +#define DAVINCI_MMCRSP45 0x40 /* Response Register 4 and 5 */ +#define DAVINCI_MMCRSP67 0x44 /* Response Register 6 and 7 */ #define DAVINCI_MMCDRSP 0x48 /* Data Response Register */ #define DAVINCI_MMCETOK 0x4C #define DAVINCI_MMCCIDX 0x50 /* Command Index Register */ -- 1.6.0.4 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkansara at irvine-sensors.com Tue Jan 5 14:12:59 2010 From: nkansara at irvine-sensors.com (Naresh Kansara) Date: Tue, 5 Jan 2010 12:12:59 -0800 Subject: use NAND Flash MT29F2G08ABD (Micron) Message-ID: Hello All, Has anybody have used this NAND Flash with Davinci? The device (manufacture id is 0x2C & device id is 0xAA). I can load both the ubl_davinci_nand.bin and u-boot-594-nand.bin through CCS(Code Composer Studio). After I remove the JTAG connector and re-apply the power, the RBL still seem not to find this NAND device(get BOOTME message ) Any suggestion is appreciated. Regards, Naresh Kansara Irvine Sensors Corporation phone: (714)-435-8928 email: nkansara at irvine-sensors.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From schen at mvista.com Tue Jan 5 14:34:31 2010 From: schen at mvista.com (Steve Chen) Date: Tue, 05 Jan 2010 14:34:31 -0600 Subject: use NAND Flash MT29F2G08ABD (Micron) In-Reply-To: References: Message-ID: <1262723672.3083.19.camel@linux-1lbu> On Tue, 2010-01-05 at 12:12 -0800, Naresh Kansara wrote: > Hello All, > > Has anybody have used this NAND Flash with Davinci? The device > (manufacture id is 0x2C & device id is 0xAA). I can load both the > ubl_davinci_nand.bin and u-boot-594-nand.bin through CCS(Code Composer > Studio). After I remove the JTAG connector and re-apply the power, > the RBL still seem not to find this NAND device(get BOOTME message ) > > Any suggestion is appreciated. I have not used this part, but I heard that Micron NANDs comes up in power-save mode which can cause strange behaviors. Regards, Steve From khilman at deeprootsystems.com Tue Jan 5 16:15:31 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 14:15:31 -0800 Subject: [PATCH] MMC: DaVinci: Fixed typos in comments of the response registers in davinci_mmc.c In-Reply-To: (raghav n.'s message of "Wed\, 6 Jan 2010 00\:21\:20 +0530") References: Message-ID: <87hbr0tczg.fsf@deeprootsystems.com> raghav n writes: > [PATCH 1/1] MMC: DaVinci: Fixed typos in comments of the response registers in davinci_mmc.c You don't need to duplicate the subject in the changelog. > This patch fixes the typos in the comments for the MMC response registers. They were all /* Response Register 0 and 1 */ > > Signed-off-by: raghav.moko at gmail.com Thanks, will que > --- > From 08e00d18ca5d0c20a9035c631e7fcb5f39c88cb8 Mon Sep 17 00:00:00 2001 > From: raghav > > Date: Tue, 5 Jan 2010 23:57:17 +0530 > Subject: [PATCH] Fixed comments for the response registers. They were all saying Regiser 0 and 1. You've got duplicate headers/changelog etc. here. I highly recommend using git-format-patch + git-send-email to send patches? > --- > drivers/mmc/host/davinci_mmc.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) The patch itself looks fine. After cleaning up the changelog, I'll queue for 2.6.33-rc fixes series. Kevin > > > diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c > index dd45e7c..73a6a14 100644 > --- a/drivers/mmc/host/davinci_mmc.c > +++ b/drivers/mmc/host/davinci_mmc.c > @@ -54,9 +54,9 @@ > #define DAVINCI_MMCCMD 0x30 /* Command Register */ > > > #define DAVINCI_MMCARGHL 0x34 /* Argument Register */ > #define DAVINCI_MMCRSP01 0x38 /* Response Register 0 and 1 */ > -#define DAVINCI_MMCRSP23 0x3C /* Response Register 0 and 1 */ > > > -#define DAVINCI_MMCRSP45 0x40 /* Response Register 0 and 1 */ > -#define DAVINCI_MMCRSP67 0x44 /* Response Register 0 and 1 */ > +#define DAVINCI_MMCRSP23 0x3C /* Response Register 2 and 3 */ > > > +#define DAVINCI_MMCRSP45 0x40 /* Response Register 4 and 5 */ > +#define DAVINCI_MMCRSP67 0x44 /* Response Register 6 and 7 */ > #define DAVINCI_MMCDRSP 0x48 /* Data Response Register */ > > > #define DAVINCI_MMCETOK 0x4C > #define DAVINCI_MMCCIDX 0x50 /* Command Index Register */ > -- > 1.6.0.4 > > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source From khilman at deeprootsystems.com Tue Jan 5 16:29:28 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 14:29:28 -0800 Subject: [PATCH] MMC: DaVinci: Fixed typos in comments of the response registers in davinci_mmc.c In-Reply-To: <87hbr0tczg.fsf@deeprootsystems.com> References: <87hbr0tczg.fsf@deeprootsystems.com> Message-ID: <4B43BD48.9060208@deeprootsystems.com> Kevin Hilman wrote: > raghav n writes: > >> [PATCH 1/1] MMC: DaVinci: Fixed typos in comments of the response registers in davinci_mmc.c > > You don't need to duplicate the subject in the changelog. > >> This patch fixes the typos in the comments for the MMC response registers. They were all /* Response Register 0 and 1 */ >> >> Signed-off-by: raghav.moko at gmail.com > > Thanks, will que > >> --- >> From 08e00d18ca5d0c20a9035c631e7fcb5f39c88cb8 Mon Sep 17 00:00:00 2001 >> From: raghav >> >> Date: Tue, 5 Jan 2010 23:57:17 +0530 >> Subject: [PATCH] Fixed comments for the response registers. They were all saying Regiser 0 and 1. > > You've got duplicate headers/changelog etc. here. > > I highly recommend using git-format-patch + git-send-email to send patches? > >> --- >> drivers/mmc/host/davinci_mmc.c | 6 +++--- >> 1 files changed, 3 insertions(+), 3 deletions(-) > > The patch itself looks fine. After cleaning up the changelog, I'll > queue for 2.6.33-rc fixes series. After trying to apply this, the patch is corrupted in other ways and doesn't apply cleanly. Please fix up the patch to apply against current davinci git and resend, preferably using git-format-patch + git-send-email. Kevin From khilman at deeprootsystems.com Tue Jan 5 16:42:57 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 14:42:57 -0800 Subject: [PATCH 0/9] davinci: EDMA updates In-Reply-To: <1259731978-13147-1-git-send-email-sudhakar.raj@ti.com> (Sudhakar Rajashekhara's message of "Wed\, 2 Dec 2009 11\:02\:58 +0530") References: <1259731978-13147-1-git-send-email-sudhakar.raj@ti.com> Message-ID: <878wcctbpq.fsf@deeprootsystems.com> Sudhakar Rajashekhara writes: > This patch set corrects some issues with the existing EDMA > driver and also adds support for EDMA resource (channel/slots) > sharing between two processors (say ARM and DSP). > > The patch set has been tested on DM646x, OMAP-L137 and OMAP-L138 > EVM boards. Hi Sudhakar, This series looks good. One minor request. For the last three patches, I think it would be helpful to describe in the changelog or even better at the definition of the reserved arrays what the channels are being reserved for. Kevin > Sudhakar Rajashekhara (9): > 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: support for EDMA resource sharing > davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 > davinci: da830/omapl137: Specify reserved channels/slots > davinci: da850/omapl138: Specify reserved channels/slots > davinci: dm646x: Specify reserved EDMA channel/slots for DM646x > > arch/arm/mach-davinci/devices-da8xx.c | 181 ++++++++++++++++++++++++++-- > arch/arm/mach-davinci/dm355.c | 8 -- > arch/arm/mach-davinci/dm644x.c | 10 -- > arch/arm/mach-davinci/dm646x.c | 28 ++++- > arch/arm/mach-davinci/dma.c | 101 ++++++++++++++--- > arch/arm/mach-davinci/include/mach/edma.h | 4 +- > 6 files changed, 276 insertions(+), 56 deletions(-) > > _______________________________________________ > 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 rtivy at ti.com Tue Jan 5 16:45:48 2010 From: rtivy at ti.com (Tivy, Robert) Date: Tue, 5 Jan 2010 16:45:48 -0600 Subject: Arago Kerenel w/ codec_engine_2_00_01 issues? In-Reply-To: <7F1B6BBBDF05C649BBBA3C853F488A6119BDDFC80C@Hawking.deepsea.com> References: <7F1B6BBBDF05C649BBBA3C853F488A6119BDDFC806@Hawking.deepsea.com>, <6B8224E84039B140AA662F0BB03616430122A5A9AC@dlee04.ent.ti.com> <7F1B6BBBDF05C649BBBA3C853F488A6119BDDFC80C@Hawking.deepsea.com> Message-ID: <6B8224E84039B140AA662F0BB03616430122AF475A@dlee04.ent.ti.com> Chris has already responded to your other issues, so please see just one comment from me below. Regards, - Rob > -----Original Message----- > From: Paul Stuart [mailto:Paul_Stuart at seektech.com] > Sent: Tuesday, January 05, 2010 7:26 AM > To: Tivy, Robert; davinci-linux-open-source at linux.davincidsp.com > Subject: RE: Arago Kerenel w/ codec_engine_2_00_01 issues? > > Thanks for the response! > > I'll give the latest CMEM, LinuxUtils, et al a whirl and see > what happens. The strange thing is that the mpeg4 decoder, > jpeg encode/decode, and mp3 encode/decode all load without > complaint. It's just the mpeg4enc that fails. > > > I've rebuilt cmemk.ko and dm350mmap.ko against the arago > kernel. Neither process was straight forward though because > of changes between the montavista kernel we were using. Maybe > something got botched in the process. One of the reasons to upgrade to the latest LinuxUtils is that they've been ported to the recent DaVinci GIT kernel releases, although I don't know if the MontaVista changes have kept up-to-date with the GIT changes. > > > Turning on the trace, with CE_DEBUG=2, I get the following > during mpeg4enc initialization: > > > @5,653,051us: [+0 T:0x43300490] ti.sdo.ce.video1.VIDENC1 - > VIDENC1_create> Enter (engine=0x100670, name='mpeg4enc', > params=0x432ffca8) > @5,653,350us: [+0 T:0x43300490] CV - VISA_create(0x100670, > 'mpeg4enc', 0x432ffca8, 0x2496, 'ti.sdo.ce.video1.IVIDENC1') > @5,653,569us: [+0 T:0x43300490] CV - VISA_create2(0x100670, > 'mpeg4enc', 0x432ffca8, 0x30, 0x2496, 'ti.sdo.ce.video1.IVIDENC1') > @5,654,187us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - > Algorithm_create> Enter(fxns=0xf89c0, idma3Fxns=0xf8988, > iresFxns=0x0, params=0x432ffca8, attrs=0x432ffac8) > @5,654,470us: [+0 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Enter (scratchId=1, fxns=0xf89c0, parentAlg=0x0, > params=0x432ffca8) > @5,678,280us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> algNumAlloc 7 memory recs > @5,678,574us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> algAlloc returned numRecs=7 > @5,678,777us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[0]: size=0x2c58, > align=0x100, space=0x11, attrs=0x1 > @5,678,985us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[1]: size=0x200, > align=0x100, space=0x11, attrs=0x1 > @5,679,182us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[2]: size=0x19a400, > align=0x100, space=0x11, attrs=0x1 > @5,679,568us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[3]: size=0x10e0, > align=0x100, space=0x11, attrs=0x1 > @5,679,816us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[4]: size=0x4, > align=0x100, space=0x11, attrs=0x1 > @5,680,026us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[5]: size=0x14000, > align=0x100, space=0x11, attrs=0x1 > @5,680,233us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[6]: size=0x3840, > align=0x100, space=0x11, attrs=0x1 > @5,680,648us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(11352) = 0x43301000. > @5,680,909us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x43301000) = 0x8702c000. > @5,681,514us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(512) = 0x42a02000. > @5,681,792us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x42a02000) = 0x87018000. > @5,682,401us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(1680384) = 0x43305000. > @5,682,711us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x43305000) = 0x87e00000. > @5,698,324us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(4320) = 0x43505000. > @5,698,622us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x43505000) = 0x8702a000. > @5,699,098us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(4) = 0x43507000. > @5,699,535us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x43507000) = 0x87019000. > @5,700,033us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(81920) = 0x43508000. > @5,700,348us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x43508000) = 0x8704e000. > @5,701,570us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(14400) = 0x4351c000. > @5,701,844us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x4351c000) = 0x87030000. > @5,757,804us: [+7 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> algInit call failed 49280 > @5,765,522us: [+0 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Exit (algHandle=NULL) > @5,765,791us: [+7 T:0x43300490] ti.sdo.ce.alg.Algorithm - > Algorithm_create> Algorithm creation FAILED; make sure that > 1) alg params are correct/appropriate, 2) there is enough > internal and external algorithm memory available -- check > DSKT2 settings for heap assignments and scratch allocation > @5,766,031us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - > Algorithm_delete> Enter(alg=0x1fb020) > @5,766,236us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - > Algorithm_create> return (0x0) > @5,766,462us: [+2 T:0x43300490] CV - VISA_create> FAILED to > create local codec. > @5,766,648us: [+0 T:0x43300490] CV - VISA_delete(0x1439f8) > @5,766,817us: [+5 T:0x43300490] CV - VISA_delete> deleting > codec (localQueue=0xffff, remoteQueue=0xffff) > @5,767,009us: [+0 T:0x43300490] ti.sdo.ce.video1.VIDENC1 - > VIDENC1_create> return (0x0) Dvr_Titler Error: Failed to open > video encode algorithm: mpeg4enc (0x0) > > > From the trace, it looks like cmem is allocating the the > memory requested. I've tried passing in the default > parameters to the algorithm, the parameters used in the dvsdk > encode demo, as well as the parameters that worked for us > previously. I don't know how to check the DSKT2 settings. > > Is there any way to add more tracing to the Algorithm create? > It fails somewhat silently. Also strange that the last error > from the Codec engine is 0x0 (mpeg4enc (0x0)), not sure why > it would fail to initialize the algorithm and still return no error. > > > I appreciate the help! > > Paul > > ________________________________________ > From: Tivy, Robert [rtivy at ti.com] > Sent: Monday, January 04, 2010 6:07 PM > To: Paul Stuart; davinci-linux-open-source at linux.davincidsp.com > Subject: RE: Arago Kerenel w/ codec_engine_2_00_01 issues? > > Generally, user-level code doesn't care much about the kernel > version, and CE itself is all user-level code. Since CE > encapsulates other packages that do contain kernel modules > (which do care about kernel version), such as CMEM in > LinuxUtils and DSPLink, the problem probably is with those. > > The kernel modules call APIs that can come or go with > particular Linux kernels, hence the dependency of kernel > modules on the kernel. Typically you will need to rebuild > the kernel modules for the particular kernel that you're > running. Rebuilding is also important with respect to simply > inserting the kernel modules (usually done with a > "loadmodules.sh" script) - you can't insert a kernel module > that's been built against a kernel other than the one you're > running (although there is some flexibility if the kernels in > question are "close enough" to each other). > > It would help if you described your problem opening the > mpeg4enc video encode algorithm. CE 2.00.01 is fairly old at > this point, much older than 2.6.26 Linux. I would suggest > updating to a newer CE, which also might just fix your problem. > > Regards, > > - Rob > > > -----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 Paul Stuart > > Sent: Thursday, December 31, 2009 12:55 PM > > To: davinci-linux-open-source at linux.davincidsp.com > > Subject: Arago Kerenel w/ codec_engine_2_00_01 issues? > > > > Hi There, > > Wondering if there is any magic that has to happen to make the > > dvsdk's codec engine (2_00_01) play with the arago kernel (2.6.26)? > > Everything compiles fine, but my app can't open the mpeg4enc video > > encode algorithm. > > Thanks, > > Paul > > _______________________________________________ > > 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 rtivy at ti.com Tue Jan 5 16:52:15 2010 From: rtivy at ti.com (Tivy, Robert) Date: Tue, 5 Jan 2010 16:52:15 -0600 Subject: Cmem address translation when working with Codec Engine In-Reply-To: <10B9B66481AB544596EF70B519D5899601D52460@rvil-mail1.RADVISION.com> References: <6B8224E84039B140AA662F0BB03616430122930FB8@dlee04.ent.ti.com><10B9B66481AB544596EF70B519D5899601D52422@rvil-mail1.RADVISION.com><4B4220A7.6090506@nt.tu-darmstadt.de><10B9B66481AB544596EF70B519D5899601D52423@rvil-mail1.RADVISION.com><6B8224E84039B140AA662F0BB03616430122A5A903@dlee04.ent.ti.com><10B9B66481AB544596EF70B519D5899601D5245F@rvil-mail1.RADVISION.com> <4B430309.30009@nt.tu-darmstadt.de> <10B9B66481AB544596EF70B519D5899601D52460@rvil-mail1.RADVISION.com> Message-ID: <6B8224E84039B140AA662F0BB03616430122AF4775@dlee04.ent.ti.com> This sounds like an odd setup, how are you even calling the codec if not through CE? Since the first codec is assuming responsibility for doing "first" things, like calling CERuntime_init(), can't it also call Memory_registerContigBuf()? From your earlier descriptions it sounds like you might need a way to inform this first codec of the (big CMEM) buffer size to register, but communicating that info sounds easier than tracking small buffer subdivisions. Regards, - Rob > -----Original Message----- > From: > davinci-linux-open-source-bounces+rtivy=ti.com at linux.davincids > p.com > [mailto:davinci-linux-open-source-bounces+rtivy=ti.com at linux.d > avincidsp.com] On Behalf Of Erez Kinarti > Sent: Tuesday, January 05, 2010 1:26 AM > To: Vladimir Pantelic; Davinci-linux-open-source at linux.davincidsp.com > Cc: Davinci-linux-open-source at linux.davincidsp.com > Subject: RE: Cmem address translation when working with Codec Engine > > No, because in my system, the first codec that is generated > is calling CERuntimeInit (working with C++, keeping reference > counter for the call to CERuntimeInit and CERuntimeExit), > while the system buffers are allocated before that. > > > -----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 Vladimir Pantelic > Sent: Tuesday, January 05, 2010 11:15 AM > To: Davinci-linux-open-source at linux.davincidsp.com > Cc: Davinci-linux-open-source at linux.davincidsp.com > Subject: Re: Cmem address translation when working with Codec Engine > > Erez Kinarti wrote: > > Hey Rob, > > I see that calling the register functions require that CE is in the > air > > (CERuntimeInit) so it is problematic for us in the same way as doing > the > > CMEM allocations via CodecEngine. > > as you have to call CERuntimeInit() before using any of CE, > you can do the > Memory_registerContigBuf() after CERuntimeInit(), no? > > > _______________________________________________ > 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 rtivy at ti.com Tue Jan 5 16:56:41 2010 From: rtivy at ti.com (Tivy, Robert) Date: Tue, 5 Jan 2010 16:56:41 -0600 Subject: Cmem address translation when working with Codec Engine In-Reply-To: <10B9B66481AB544596EF70B519D5899601D52458@rvil-mail1.RADVISION.com> References: <6B8224E84039B140AA662F0BB03616430122930FB8@dlee04.ent.ti.com><10B9B66481AB544596EF70B519D5899601D52422@rvil-mail1.RADVISION.com><4B4220A7.6090506@nt.tu-darmstadt.de><10B9B66481AB544596EF70B519D5899601D52423@rvil-mail1.RADVISION.com> <6B8224E84039B140AA662F0BB03616430122A5A903@dlee04.ent.ti.com> <10B9B66481AB544596EF70B519D5899601D52458@rvil-mail1.RADVISION.com> Message-ID: <6B8224E84039B140AA662F0BB03616430122AF4788@dlee04.ent.ti.com> I would expect that the size that you use is good enough for the Memory_registerContigBuf() call. The only way you can query the size of the buffers allocated by CMEM is to do so in a non-direct manner, by performing "%cat /proc/cmem" and parsing the ASCII output (try out that command, you'll see what I mean). - Rob > -----Original Message----- > From: Erez Kinarti [mailto:erezk at radvision.com] > Sent: Tuesday, January 05, 2010 12:21 AM > To: Tivy, Robert; Vladimir Pantelic; > Davinci-linux-open-source at linux.davincidsp.com > Subject: RE: Cmem address translation when working with Codec Engine > > Thank you very much Rob, > I'm going to try it now. > Just one open issue is the size of the big buffer: > In the app I cannot be sure what is the buffer size that CMEM > allocated for me, I just know that the size is at least the > size that I requested. > Do I have to put the size parameter in these function the > exact size allocated by CMEM, or just the size that I use is enough? > In case I must use the size allocated by CMEM, is there a way > to know what this size is? > > Thanks, > Erez > > > -----Original Message----- > From: Tivy, Robert [mailto:rtivy at ti.com] > Sent: Tuesday, January 05, 2010 1:30 AM > To: Erez Kinarti; Vladimir Pantelic; > Davinci-linux-open-source at linux.davincidsp.com > Subject: RE: Cmem address translation when working with Codec Engine > > > There is no function available to invalidate all the Memory module > virt-phys translations. > > If your app structure allows it, you can call > Memory_registerContigBuf(bigCMEMBufferVirtAddr, 258048, > CMEM_getPhys(bigCMEMBufferVirtAddr)); > once, and all smaller subdivided buffers will be covered by this one > registration (or, even simpler, just call > Memory_getBufferPhysicalAddress(bigCMEMBufferVirtAddr, 258048, > NULL); > and ignore the result, which will do the CMEM_getPhys() for you and > register it). You can then call > Memory_unregisterContigBuf(bigCMEMBufferVirtAddr, 258048) once when > you're ready to free the CMEM buffer. FYI, if you want to > double-check > me, you can call Memory_dumpKnownContigBufsList() to display > (through GT > tracing) the contig buffer list (AKA, the Memory module virt-phys > translation table). > > Regards, > > - Rob > > > -----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 Erez Kinarti > > Sent: Monday, January 04, 2010 9:15 AM > > To: Vladimir Pantelic; > Davinci-linux-open-source at linux.davincidsp.com > > Subject: RE: Cmem address translation when working with Codec Engine > > > > Thank you Vladimir, > > But we are not able to allocate and free via CodecEngine due > > to the structure of our application and the need to call the > > alloc not before calling CERuntimeInit(). > > > > > > -----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 Vladimir Pantelic > > Sent: Monday, January 04, 2010 7:09 PM > > To: Davinci-linux-open-source at linux.davincidsp.com > > Subject: Re: Cmem address translation when working with Codec Engine > > > > Erez Kinarti wrote: > > > Thanks a lot Rob. > > > > > > calling this function for each of the pointers used with > > CodecEngine > > > solved the problem. > > > > > > However, we need something else, some function that > invalidates all > > this > > > virt->phy table and not each of the virtual pointers separately. > > > > > > Is there a way to do a full invalidate in a single call > > without keep > > > tracking on each of the virtual pointers? > > > > > > The reason that Memory_unregisterContigBuf it is not > enough for us: > > > > > > In our system, we allocate a very big buffer from CMEM > > (258048 bytes), > > > but we don't call CodecEngine with a pointer to the big buffer. > > > > You dont need to call Memory_unregisterContigBuf, just alloc > > and free the buffers via CE and CE will know that you are > > calling it with a smaller buffer inside a larger one that it > > knows the translation to... > > > > _______________________________________________ > > 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 Tue Jan 5 16:56:44 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 14:56:44 -0800 Subject: [PATCH v2 3/4] i2c: davinci: Add suspend/resume support In-Reply-To: <1260267218-19406-4-git-send-email-chaithrika@ti.com> (Chaithrika U. S.'s message of "Tue\, 8 Dec 2009 15\:43\:37 +0530") References: <1260267218-19406-1-git-send-email-chaithrika@ti.com> <1260267218-19406-2-git-send-email-chaithrika@ti.com> <1260267218-19406-3-git-send-email-chaithrika@ti.com> <1260267218-19406-4-git-send-email-chaithrika@ti.com> Message-ID: <87vdfgrwib.fsf@deeprootsystems.com> Chaithrika U S writes: > Add suspend and resume callbacks to DaVinci I2C driver. > This has been tested on DA850/OMAP-L138 EVM. The SoC specific > suspend-to-RAM support patch series [1] is needed to test this feature. > > [1] http://linux.davincidsp.com/pipermail/davinci-linux-open-source/ > 2009-November/016958.html > > Signed-off-by: Chaithrika U S > --- > drivers/i2c/busses/i2c-davinci.c | 32 ++++++++++++++++++++++++++++++++ > 1 files changed, 32 insertions(+), 0 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c > index 81c1049..c1c2909 100644 > --- a/drivers/i2c/busses/i2c-davinci.c > +++ b/drivers/i2c/busses/i2c-davinci.c > @@ -622,6 +622,36 @@ static int davinci_i2c_remove(struct platform_device *pdev) > return 0; > } > > +#ifdef CONFIG_PM > +static int davinci_i2c_suspend(struct platform_device *pdev, pm_message_t state) > +{ > + struct davinci_i2c_dev *dev = platform_get_drvdata(pdev); > + > + /* put I2C into reset */ > + davinci_i2c_reset_ctrl(dev, 0); > + > + clk_disable(dev->clk); > + > + return 0; > +} > + > +static int davinci_i2c_resume(struct platform_device *pdev) > +{ > + struct davinci_i2c_dev *dev = platform_get_drvdata(pdev); > + > + clk_enable(dev->clk); > + > + /* take I2C out of reset */ > + davinci_i2c_reset_ctrl(dev, 1); > + > + return 0; > +} > + > +#else > +#define davinci_i2c_suspend NULL > +#define davinci_i2c_resume NULL > +#endif > + > /* work with hotplug and coldplug */ > MODULE_ALIAS("platform:i2c_davinci"); > > @@ -632,6 +662,8 @@ static struct platform_driver davinci_i2c_driver = { > .name = "i2c_davinci", > .owner = THIS_MODULE, > }, > + .suspend = davinci_i2c_suspend, > + .resume = davinci_i2c_resume, Rather than adding these to the platform_driver, you should use dev_pm_ops. Something like the patch below on top of your PATCH 3/4 should work. Other than this, I'm OK with this series, feel free to add my signoff and resend to linux-i2c and LKML. linux-i2c has had very slow response to embedded patches lately. Kevin From khilman at deeprootsystems.com Tue Jan 5 17:04:03 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 15:04:03 -0800 Subject: [PATCH v2] davinci: add CDCE949 support on DM6467 EVM In-Reply-To: <1260431376-2789-1-git-send-email-nsekhar@ti.com> (Sekhar Nori's message of "Thu\, 10 Dec 2009 13\:19\:36 +0530") References: <1260431376-2789-1-git-send-email-nsekhar@ti.com> Message-ID: <87ocl8rw64.fsf@deeprootsystems.com> Sekhar Nori writes: > From: Nageswari Srinivasan > > This patch adds the CDCE949 reference oscillator to > the davinci clock list. > > On the DM6467T EVM, the CDCE949 is responsible for > generating the pixel clock for display. On the DM6467 > EVM, this pixel clock was being obtained from an > internal source. This is not possible on the DM6467T > EVM because of the presence of a 33MHz oscillator. > > The TSIF module also requires the CDCE949 to generate > the data clocks. > > The actual clock definitions will be added by patches > adding support for DM6467T VPIF and TSIF. This patch > mearly lays the foundation for that work. > > Signed-off-by: Nageswari Srinivasan > Signed-off-by: Sekhar Nori > --- > Since v1, ALWAYS_ENABLED flag has been removed from cdce_clk_in Looks good, applying to davinc git and queueing in davinci-next for 2.6.34. Kevin > arch/arm/mach-davinci/Makefile | 2 +- > arch/arm/mach-davinci/board-dm646x-evm.c | 31 ++++++++++++++++++++++++++++++ > 2 files changed, 32 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile > index eeb9230..7e806b0 100644 > --- a/arch/arm/mach-davinci/Makefile > +++ b/arch/arm/mach-davinci/Makefile > @@ -26,7 +26,7 @@ obj-$(CONFIG_MACH_SFFSDR) += board-sffsdr.o > obj-$(CONFIG_MACH_NEUROS_OSD2) += board-neuros-osd2.o > obj-$(CONFIG_MACH_DAVINCI_DM355_EVM) += board-dm355-evm.o > obj-$(CONFIG_MACH_DM355_LEOPARD) += board-dm355-leopard.o > -obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM) += board-dm646x-evm.o > +obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM) += board-dm646x-evm.o cdce949.o > obj-$(CONFIG_MACH_DAVINCI_DM365_EVM) += board-dm365-evm.o > obj-$(CONFIG_MACH_DAVINCI_DA830_EVM) += board-da830-evm.o > obj-$(CONFIG_MACH_DAVINCI_DA850_EVM) += board-da850-evm.o > diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c > index 6ff3411..6c7c604 100644 > --- a/arch/arm/mach-davinci/board-dm646x-evm.c > +++ b/arch/arm/mach-davinci/board-dm646x-evm.c > @@ -40,6 +40,8 @@ > #include > #include > #include > +#include > +#include > > #include "clock.h" > > @@ -389,6 +391,9 @@ static struct i2c_board_info __initdata i2c_info[] = { > { > I2C_BOARD_INFO("cpld_video", 0x3b), > }, > + { > + I2C_BOARD_INFO("cdce949", 0x6c), > + }, > }; > > static struct davinci_i2c_platform_data i2c_pdata = { > @@ -681,9 +686,35 @@ static void __init evm_init_i2c(void) > evm_init_video(); > } > > +#define CDCE949_XIN_RATE 27000000 > + > +/* CDCE949 support - "lpsc" field is overridden to work as clock number */ > +static struct clk cdce_clk_in = { > + .name = "cdce_xin", > + .rate = ATOMIC_INIT(CDCE949_XIN_RATE), > +}; > + > +static struct davinci_clk cdce_clks[] = { > + CLK(NULL, "xin", &cdce_clk_in), > + CLK(NULL, NULL, NULL), > +}; > + > +static void __init cdce_clk_init(void) > +{ > + struct davinci_clk *c; > + struct clk *clk; > + > + for (c = cdce_clks; c->lk.clk; c++) { > + clk = c->lk.clk; > + clkdev_add(&c->lk); > + clk_register(clk); > + } > +} > + > static void __init davinci_map_io(void) > { > dm646x_init(); > + cdce_clk_init(); > } > > static struct davinci_uart_config uart_config __initdata = { > -- > 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 rtivy at ti.com Tue Jan 5 17:04:31 2010 From: rtivy at ti.com (Tivy, Robert) Date: Tue, 5 Jan 2010 17:04:31 -0600 Subject: codec hangs In-Reply-To: References: <6B8224E84039B140AA662F0BB03616430122A5A994@dlee04.ent.ti.com> Message-ID: <6B8224E84039B140AA662F0BB03616430122AF47AE@dlee04.ent.ti.com> The message handling on the DSP is performed by the same thread (a DSP/BIOS TSK) as the codec's "control()" thread. So, once the DSP gets the CONTROL command for the codec, it calls the codec's control() function, and upon returning from that control() function sends the "reply" command that gets picked up by the ARM app. If the control() function never returns, the "reply" message will never be received by the ARM. It is my assumption that the codec's control() function is not returning for whatever reason. You could try general things, such as increasing the DSP/BIOS TSK's stack size for the codec, but even though you don't have the TI codec's source code you could still put a BP on the codec's control() function and step it at the assembly level, or just see if it ever returns. If it doesn't return, it could be either a codec problem or a general DSP/BIOS system problem (such as not enough stack for the codec TSK). Regards, - Rob ________________________________ From: Albert Burbea [mailto:albertbu at gmail.com] Sent: Monday, January 04, 2010 11:55 PM To: Tivy, Robert Cc: davinci-linux-open-source Subject: Re: codec hangs Hi thanks for your help - the problem is that the JPEG codec is TI's and I do not have access to its source code. What could hang the message queue ? Thanks again Albert On Tue, Jan 5, 2010 at 3:47 AM, Tivy, Robert > wrote: Nothing comes to mind from just your description. BTW, that "really strange" address (0xbeffc850) seems like a Linux user stack address. Since nothing jumps out from your top-down description, I would suggest a bottom-up investigation - debugging the DSP. Seems that the codec's "control()" code is sending the DSP into the weeds, at least with the parameters passed in. I would suggest putting a BP on the codec's "control()" function and stepping that function to see where the DSP goes bad. Regards, - Rob ________________________________ From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Albert Burbea Sent: Tuesday, December 29, 2009 11:22 AM To: davinci-linux-open-source Subject: codec hangs Hi everybody, I am using mv 4.01 with codec engine 2.01. I am integrating the TI JPEG encoder 1.1.13. At the beginning it did not work,it did not even open, until I modified the JPEGENC.xs to return the saram and daram scratch sizes. Before that, I modified also the ce/JPEGENC.xdc to use an IMGENC1 VISA interface instead of the IMGENC interface. I was able to open it and do an XDM_SETPARAMS control, but I did not try anything more. I restored the IMGENC interface in ce/JPEGENC.xdc, and compiled. Still worked. Then, I added a CMEM allocation for the output buffer, and... it hangs! Of course I removed the allocation and retried, but nope, I can only open it. Wen I execute the XDM_SETPARAMS, everything seems fine until the VISA_call for the XDM_SETPARAMS. The pointers it receives seem really strange to me, one of them if beffc850 or something like. It only enters the call, is able to queue the call, but then waits forever for the message queue to return, and everyting dies. What can be the problem? I verified several times the tcf file and the cmem settings and seem correct to me. Thanks in advance Albert -- Albert Burbea Harishonim 8 Ramat Gan 52502, Israel Tel/Fax + 972-3-7526016 Mobile: +972-52-3541842 -- 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 khilman at deeprootsystems.com Tue Jan 5 17:14:38 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 5 Jan 2010 15:14:38 -0800 Subject: [PATCH v2] davinci: add CDCE949 support on DM6467 EVM In-Reply-To: <87ocl8rw64.fsf@deeprootsystems.com> References: <1260431376-2789-1-git-send-email-nsekhar@ti.com> <87ocl8rw64.fsf@deeprootsystems.com> Message-ID: <636c5031001051514n46c855fbs8020bc270eff7a6e@mail.gmail.com> On Tue, Jan 5, 2010 at 3:04 PM, Kevin Hilman wrote: > Sekhar Nori writes: > >> From: Nageswari Srinivasan >> >> This patch adds the CDCE949 reference oscillator to >> the davinci clock list. >> >> On the DM6467T EVM, the CDCE949 is responsible for >> generating the pixel clock for display. On the DM6467 >> EVM, this pixel clock was being obtained from an >> internal source. This is not possible on the DM6467T >> EVM because of the presence of a 33MHz oscillator. >> >> The TSIF module also requires the CDCE949 to generate >> the data clocks. >> >> The actual clock definitions will be added by patches >> adding support for DM6467T VPIF and TSIF. This patch >> mearly lays the foundation for that work. >> >> Signed-off-by: Nageswari Srinivasan >> Signed-off-by: Sekhar Nori >> --- >> Since v1, ALWAYS_ENABLED flag has been removed from cdce_clk_in > > Looks good, applying to davinc git and queueing in davinci-next for > 2.6.34. > I responded too soon. This doesn't compile... > >> ?arch/arm/mach-davinci/Makefile ? ? ? ? ? | ? ?2 +- >> ?arch/arm/mach-davinci/board-dm646x-evm.c | ? 31 ++++++++++++++++++++++++++++++ >> ?2 files changed, 32 insertions(+), 1 deletions(-) >> >> diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile >> index eeb9230..7e806b0 100644 >> --- a/arch/arm/mach-davinci/Makefile >> +++ b/arch/arm/mach-davinci/Makefile >> @@ -26,7 +26,7 @@ obj-$(CONFIG_MACH_SFFSDR) ? ? ? ? ? += board-sffsdr.o >> ?obj-$(CONFIG_MACH_NEUROS_OSD2) ? ? ? ? ? ? ? += board-neuros-osd2.o >> ?obj-$(CONFIG_MACH_DAVINCI_DM355_EVM) += board-dm355-evm.o >> ?obj-$(CONFIG_MACH_DM355_LEOPARD) ? ? += board-dm355-leopard.o >> -obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM) ? ? ? ?+= board-dm646x-evm.o >> +obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM) ? ? ? ?+= board-dm646x-evm.o cdce949.o >> ?obj-$(CONFIG_MACH_DAVINCI_DM365_EVM) += board-dm365-evm.o >> ?obj-$(CONFIG_MACH_DAVINCI_DA830_EVM) += board-da830-evm.o >> ?obj-$(CONFIG_MACH_DAVINCI_DA850_EVM) += board-da850-evm.o >> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c >> index 6ff3411..6c7c604 100644 >> --- a/arch/arm/mach-davinci/board-dm646x-evm.c >> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c >> @@ -40,6 +40,8 @@ >> ?#include >> ?#include >> ?#include >> +#include >> +#include ...since this file doesn't exist yet. Kevin From Paul_Stuart at seektech.com Tue Jan 5 17:16:32 2010 From: Paul_Stuart at seektech.com (Paul Stuart) Date: Tue, 5 Jan 2010 15:16:32 -0800 Subject: Arago Kerenel w/ codec_engine_2_00_01 issues? In-Reply-To: <92CDD168D1E81F4F9D3839DC45903FC66E72D25B@dlee03.ent.ti.com> References: <7F1B6BBBDF05C649BBBA3C853F488A6119BDDFC806@Hawking.deepsea.com>, <6B8224E84039B140AA662F0BB03616430122A5A9AC@dlee04.ent.ti.com> <7F1B6BBBDF05C649BBBA3C853F488A6119BDDFC80C@Hawking.deepsea.com>, <92CDD168D1E81F4F9D3839DC45903FC66E72D25B@dlee03.ent.ti.com> Message-ID: <7F1B6BBBDF05C649BBBA3C853F488A6119BDDFC80D@Hawking.deepsea.com> Hi, Thanks for the info. I've updated to the latest cmemk.ko and dm350mmap.ko modules and still have the issue. Also fails if I pass NULL for the parameter structure instead of the defaults. If 0xC080 refers to the M355_MPEG4E_ERROR structure as defined in the MPEG4ENC user guide (which I'm not it does, could be a wild assumption), then the error reported would be DM355_MPEG4E_INVALID_FRAMERATE, DM355_MPEG4E_INVALID_INTRATHRES, and an undefined bit (15). Passing in NULL or using the default parameters, I wouldn't expect to run into these errors. Could this have anything to do with the changes to the edma api between the montavista kernel and the latest arago distribution? Grasping at straws here... thanks! Paul ________________________________________ From: Ring, Chris [cring at ti.com] Sent: Tuesday, January 05, 2010 7:57 AM To: Paul Stuart; Tivy, Robert; davinci-linux-open-source at linux.davincidsp.com Subject: RE: Arago Kerenel w/ codec_engine_2_00_01 issues? First, it looks like your on a DM355 or DM365 as this codec is 'local' (i.e. running on the same processor as your app). That helps eliminate some complexity (e.g. no DSP Link, and no DSKT2... the warning msg is misleading - there's no DSKT2 in a DM355/365 system). Also from the trace, I can see that the memory requested by the alg succeeds (the codec needs 7 distinct memory blocks, and I can see 7 successful CMEM alloc() calls being made). However, during the algInit() call (where Codec Engine provides this newly allocated memory to the codec), the codec is returning 49280 (0xC080). So the codec didn't like something it was given - either the memory (unlikely) or the creation params(?) - and returned this error. Do the codec docs (or headers?) provide any details about this specific error code (0xC080)? Does it fail if you pass in NULL as the create() params? Finally, to your specific question, the error returned (mpeg4enc (0x0)) indicates a NULL handle, not a success code. Chris > -----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 Paul Stuart > Sent: Tuesday, January 05, 2010 7:26 AM > To: Tivy, Robert; davinci-linux-open-source at linux.davincidsp.com > Subject: RE: Arago Kerenel w/ codec_engine_2_00_01 issues? > > Thanks for the response! > > I'll give the latest CMEM, LinuxUtils, et al a whirl and see > what happens. The strange thing is that the mpeg4 decoder, > jpeg encode/decode, and mp3 encode/decode all load without > complaint. It's just the mpeg4enc that fails. > > > I've rebuilt cmemk.ko and dm350mmap.ko against the arago > kernel. Neither process was straight forward though because > of changes between the montavista kernel we were using. Maybe > something got botched in the process. > > > Turning on the trace, with CE_DEBUG=2, I get the following > during mpeg4enc initialization: > > > @5,653,051us: [+0 T:0x43300490] ti.sdo.ce.video1.VIDENC1 - > VIDENC1_create> Enter (engine=0x100670, name='mpeg4enc', > params=0x432ffca8) > @5,653,350us: [+0 T:0x43300490] CV - VISA_create(0x100670, > 'mpeg4enc', 0x432ffca8, 0x2496, 'ti.sdo.ce.video1.IVIDENC1') > @5,653,569us: [+0 T:0x43300490] CV - VISA_create2(0x100670, > 'mpeg4enc', 0x432ffca8, 0x30, 0x2496, 'ti.sdo.ce.video1.IVIDENC1') > @5,654,187us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - > Algorithm_create> Enter(fxns=0xf89c0, idma3Fxns=0xf8988, > iresFxns=0x0, params=0x432ffca8, attrs=0x432ffac8) > @5,654,470us: [+0 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Enter (scratchId=1, fxns=0xf89c0, parentAlg=0x0, > params=0x432ffca8) > @5,678,280us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> algNumAlloc 7 memory recs > @5,678,574us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> algAlloc returned numRecs=7 > @5,678,777us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[0]: size=0x2c58, > align=0x100, space=0x11, attrs=0x1 > @5,678,985us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[1]: size=0x200, > align=0x100, space=0x11, attrs=0x1 > @5,679,182us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[2]: size=0x19a400, > align=0x100, space=0x11, attrs=0x1 > @5,679,568us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[3]: size=0x10e0, > align=0x100, space=0x11, attrs=0x1 > @5,679,816us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[4]: size=0x4, > align=0x100, space=0x11, attrs=0x1 > @5,680,026us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[5]: size=0x14000, > align=0x100, space=0x11, attrs=0x1 > @5,680,233us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Memory requested memTab[6]: size=0x3840, > align=0x100, space=0x11, attrs=0x1 > @5,680,648us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(11352) = 0x43301000. > @5,680,909us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x43301000) = 0x8702c000. > @5,681,514us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(512) = 0x42a02000. > @5,681,792us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x42a02000) = 0x87018000. > @5,682,401us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(1680384) = 0x43305000. > @5,682,711us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x43305000) = 0x87e00000. > @5,698,324us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(4320) = 0x43505000. > @5,698,622us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x43505000) = 0x8702a000. > @5,699,098us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(4) = 0x43507000. > @5,699,535us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x43507000) = 0x87019000. > @5,700,033us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(81920) = 0x43508000. > @5,700,348us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x43508000) = 0x8704e000. > @5,701,570us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_alloc(14400) = 0x4351c000. > @5,701,844us: [+4 T:0x43300490] OM - Memory_contigAlloc> > CMEM_getPhys(0x4351c000) = 0x87030000. > @5,757,804us: [+7 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> algInit call failed 49280 > @5,765,522us: [+0 T:0x43300490] ti.sdo.ce.osal.alg - > ALG_create> Exit (algHandle=NULL) > @5,765,791us: [+7 T:0x43300490] ti.sdo.ce.alg.Algorithm - > Algorithm_create> Algorithm creation FAILED; make sure that > 1) alg params are correct/appropriate, 2) there is enough > internal and external algorithm memory available -- check > DSKT2 settings for heap assignments and scratch allocation > @5,766,031us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - > Algorithm_delete> Enter(alg=0x1fb020) > @5,766,236us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - > Algorithm_create> return (0x0) > @5,766,462us: [+2 T:0x43300490] CV - VISA_create> FAILED to > create local codec. > @5,766,648us: [+0 T:0x43300490] CV - VISA_delete(0x1439f8) > @5,766,817us: [+5 T:0x43300490] CV - VISA_delete> deleting > codec (localQueue=0xffff, remoteQueue=0xffff) > @5,767,009us: [+0 T:0x43300490] ti.sdo.ce.video1.VIDENC1 - > VIDENC1_create> return (0x0) > Dvr_Titler Error: Failed to open video encode algorithm: > mpeg4enc (0x0) > > > >From the trace, it looks like cmem is allocating the the > memory requested. I've tried passing in the default > parameters to the algorithm, the parameters used in the dvsdk > encode demo, as well as the parameters that worked for us > previously. I don't know how to check the DSKT2 settings. > > Is there any way to add more tracing to the Algorithm create? > It fails somewhat silently. Also strange that the last error > from the Codec engine is 0x0 (mpeg4enc (0x0)), not sure why > it would fail to initialize the algorithm and still return no error. > > > I appreciate the help! > > Paul > > ________________________________________ > From: Tivy, Robert [rtivy at ti.com] > Sent: Monday, January 04, 2010 6:07 PM > To: Paul Stuart; davinci-linux-open-source at linux.davincidsp.com > Subject: RE: Arago Kerenel w/ codec_engine_2_00_01 issues? > > Generally, user-level code doesn't care much about the kernel > version, and CE itself is all user-level code. Since CE > encapsulates other packages that do contain kernel modules > (which do care about kernel version), such as CMEM in > LinuxUtils and DSPLink, the problem probably is with those. > > The kernel modules call APIs that can come or go with > particular Linux kernels, hence the dependency of kernel > modules on the kernel. Typically you will need to rebuild > the kernel modules for the particular kernel that you're > running. Rebuilding is also important with respect to simply > inserting the kernel modules (usually done with a > "loadmodules.sh" script) - you can't insert a kernel module > that's been built against a kernel other than the one you're > running (although there is some flexibility if the kernels in > question are "close enough" to each other). > > It would help if you described your problem opening the > mpeg4enc video encode algorithm. CE 2.00.01 is fairly old at > this point, much older than 2.6.26 Linux. I would suggest > updating to a newer CE, which also might just fix your problem. > > Regards, > > - Rob > > > -----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 Paul Stuart > > Sent: Thursday, December 31, 2009 12:55 PM > > To: davinci-linux-open-source at linux.davincidsp.com > > Subject: Arago Kerenel w/ codec_engine_2_00_01 issues? > > > > Hi There, > > Wondering if there is any magic that has to happen to make > > the dvsdk's codec engine (2_00_01) play with the arago kernel > > (2.6.26)? Everything compiles fine, but my app can't open the > > mpeg4enc video encode algorithm. > > Thanks, > > Paul > > _______________________________________________ > > 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 Tue Jan 5 17:19:43 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 15:19:43 -0800 Subject: [PATCH v3 1/3] davinci: add power management support In-Reply-To: <1261054773-23236-1-git-send-email-nsekhar@ti.com> (Sekhar Nori's message of "Thu\, 17 Dec 2009 18\:29\:31 +0530") References: <1261054773-23236-1-git-send-email-nsekhar@ti.com> Message-ID: <87fx6krvg0.fsf@deeprootsystems.com> Sekhar Nori writes: > This patch adds core power management (suspend-to-RAM) > support for DaVinci SoCs. > > The code depends on the the "deepsleep" feature to suspend > the SoC and saves power by gating the input clock. > > The wakeup can be based on an external event as supported > by the SoC. > > Assembly code (in sleep.S) is added to aid gating DDR2 > clocks. Code doing this work should not be accessing DDR2. > The assembly code is relocated to SRAM by the code in pm.c > > The support has been validated on DA850/OMAP-L138 only > though the code is (hopefully) generic enough that other > SoCs supporting deepsleep feature simply requires SoC > specific code to start using this driver. > > Note that all the device drivers don't support suspend/resume > still and are being worked on. > > Signed-off-by: Sekhar Nori This series looks good. Applying v3 to davinci-git and queuing for 2.6.34 in davinci-next. Kevin > --- > Since v1: > 1) suspend function has been renamed. > 2) register access helper functions have been removed. > 3) spinlock in davinci_pm_suspend() function has been removed. > > arch/arm/mach-davinci/Makefile | 1 + > arch/arm/mach-davinci/include/mach/memory.h | 1 + > arch/arm/mach-davinci/include/mach/pm.h | 54 +++++++ > arch/arm/mach-davinci/pm.c | 158 +++++++++++++++++++ > arch/arm/mach-davinci/sleep.S | 224 +++++++++++++++++++++++++++ > 5 files changed, 438 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/mach-davinci/include/mach/pm.h > create mode 100644 arch/arm/mach-davinci/pm.c > create mode 100644 arch/arm/mach-davinci/sleep.S > > diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile > index eeb9230..d0fed3a 100644 > --- a/arch/arm/mach-davinci/Makefile > +++ b/arch/arm/mach-davinci/Makefile > @@ -34,3 +34,4 @@ obj-$(CONFIG_MACH_DAVINCI_DA850_EVM) += board-da850-evm.o > # Power Management > obj-$(CONFIG_CPU_FREQ) += cpufreq.o > obj-$(CONFIG_CPU_IDLE) += cpuidle.o > +obj-$(CONFIG_SUSPEND) += pm.o sleep.o > diff --git a/arch/arm/mach-davinci/include/mach/memory.h b/arch/arm/mach-davinci/include/mach/memory.h > index 7aeaf46..a91edfb 100644 > --- a/arch/arm/mach-davinci/include/mach/memory.h > +++ b/arch/arm/mach-davinci/include/mach/memory.h > @@ -33,6 +33,7 @@ > > #define DDR2_SDRCR_OFFSET 0xc > #define DDR2_SRPD_BIT BIT(23) > +#define DDR2_MCLKSTOPEN_BIT BIT(30) > #define DDR2_LPMODEN_BIT BIT(31) > > /* > diff --git a/arch/arm/mach-davinci/include/mach/pm.h b/arch/arm/mach-davinci/include/mach/pm.h > new file mode 100644 > index 0000000..37b19bf > --- /dev/null > +++ b/arch/arm/mach-davinci/include/mach/pm.h > @@ -0,0 +1,54 @@ > +/* > + * TI DaVinci platform support for power management. > + * > + * Copyright (C) 2009 Texas Instruments, Inc. http://www.ti.com/ > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation version 2. > + * > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any > + * kind, whether express or implied; without even the implied warranty > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > +#ifndef _MACH_DAVINCI_PM_H > +#define _MACH_DAVINCI_PM_H > + > +/* > + * Caution: Assembly code in sleep.S makes assumtion on the order > + * of the members of this structure. > + */ > +struct davinci_pm_config { > + void __iomem *ddr2_ctlr_base; > + void __iomem *ddrpsc_reg_base; > + int ddrpsc_num; > + void __iomem *ddrpll_reg_base; > + void __iomem *deepsleep_reg; > + void __iomem *cpupll_reg_base; > + /* > + * Note on SLEEPCOUNT: > + * The SLEEPCOUNT feature is mainly intended for cases in which > + * the internal oscillator is used. The internal oscillator is > + * fully disabled in deep sleep mode. When you exist deep sleep > + * mode, the oscillator will be turned on and will generate very > + * small oscillations which will not be detected by the deep sleep > + * counter. Eventually those oscillations will grow to an amplitude > + * large enough to start incrementing the deep sleep counter. > + * In this case recommendation from hardware engineers is that the > + * SLEEPCOUNT be set to 4096. This means that 4096 valid clock cycles > + * must be detected before the clock is passed to the rest of the > + * system. > + * In the case that the internal oscillator is not used and the > + * clock is generated externally, the SLEEPCOUNT value can be very > + * small since the clock input is assumed to be stable before SoC > + * is taken out of deepsleep mode. A value of 128 would be more than > + * adequate. > + */ > + int sleepcount; > +}; > + > +extern unsigned int davinci_cpu_suspend_sz; > +extern void davinci_cpu_suspend(struct davinci_pm_config *); > + > +#endif > diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c > new file mode 100644 > index 0000000..fab953b > --- /dev/null > +++ b/arch/arm/mach-davinci/pm.c > @@ -0,0 +1,158 @@ > +/* > + * DaVinci Power Management Routines > + * > + * Copyright (C) 2009 Texas Instruments, Inc. http://www.ti.com/ > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > + > +#include > +#include > +#include > + > +#include "clock.h" > + > +#define DEEPSLEEP_SLEEPCOUNT_MASK 0xFFFF > + > +static void (*davinci_sram_suspend) (struct davinci_pm_config *); > +static struct davinci_pm_config *pdata; > + > +static void davinci_sram_push(void *dest, void *src, unsigned int size) > +{ > + memcpy(dest, src, size); > + flush_icache_range((unsigned long)dest, (unsigned long)(dest + size)); > +} > + > +static void davinci_pm_suspend(void) > +{ > + unsigned val; > + > + if (pdata->cpupll_reg_base != pdata->ddrpll_reg_base) { > + > + /* Switch CPU PLL to bypass mode */ > + val = __raw_readl(pdata->cpupll_reg_base + PLLCTL); > + val &= ~(PLLCTL_PLLENSRC | PLLCTL_PLLEN); > + __raw_writel(val, pdata->cpupll_reg_base + PLLCTL); > + > + udelay(PLL_BYPASS_TIME); > + > + /* Powerdown CPU PLL */ > + val = __raw_readl(pdata->cpupll_reg_base + PLLCTL); > + val |= PLLCTL_PLLPWRDN; > + __raw_writel(val, pdata->cpupll_reg_base + PLLCTL); > + } > + > + /* Configure sleep count in deep sleep register */ > + val = __raw_readl(pdata->deepsleep_reg); > + val &= ~DEEPSLEEP_SLEEPCOUNT_MASK, > + val |= pdata->sleepcount; > + __raw_writel(val, pdata->deepsleep_reg); > + > + /* System goes to sleep in this call */ > + davinci_sram_suspend(pdata); > + > + if (pdata->cpupll_reg_base != pdata->ddrpll_reg_base) { > + > + /* put CPU PLL in reset */ > + val = __raw_readl(pdata->cpupll_reg_base + PLLCTL); > + val &= ~PLLCTL_PLLRST; > + __raw_writel(val, pdata->cpupll_reg_base + PLLCTL); > + > + /* put CPU PLL in power down */ > + val = __raw_readl(pdata->cpupll_reg_base + PLLCTL); > + val &= ~PLLCTL_PLLPWRDN; > + __raw_writel(val, pdata->cpupll_reg_base + PLLCTL); > + > + /* wait for CPU PLL reset */ > + udelay(PLL_RESET_TIME); > + > + /* bring CPU PLL out of reset */ > + val = __raw_readl(pdata->cpupll_reg_base + PLLCTL); > + val |= PLLCTL_PLLRST; > + __raw_writel(val, pdata->cpupll_reg_base + PLLCTL); > + > + /* Wait for CPU PLL to lock */ > + udelay(PLL_LOCK_TIME); > + > + /* Remove CPU PLL from bypass mode */ > + val = __raw_readl(pdata->cpupll_reg_base + PLLCTL); > + val &= ~PLLCTL_PLLENSRC; > + val |= PLLCTL_PLLEN; > + __raw_writel(val, pdata->cpupll_reg_base + PLLCTL); > + } > +} > + > +static int davinci_pm_enter(suspend_state_t state) > +{ > + int ret = 0; > + > + switch (state) { > + case PM_SUSPEND_STANDBY: > + case PM_SUSPEND_MEM: > + davinci_pm_suspend(); > + break; > + default: > + ret = -EINVAL; > + } > + > + return ret; > +} > + > +static struct platform_suspend_ops davinci_pm_ops = { > + .enter = davinci_pm_enter, > + .valid = suspend_valid_only_mem, > +}; > + > +static int __init davinci_pm_probe(struct platform_device *pdev) > +{ > + pdata = pdev->dev.platform_data; > + if (!pdata) { > + dev_err(&pdev->dev, "cannot get platform data\n"); > + return -ENOENT; > + } > + > + davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL); > + if (!davinci_sram_suspend) { > + dev_err(&pdev->dev, "cannot allocate SRAM memory\n"); > + return -ENOMEM; > + } > + > + davinci_sram_push(davinci_sram_suspend, davinci_cpu_suspend, > + davinci_cpu_suspend_sz); > + > + suspend_set_ops(&davinci_pm_ops); > + > + return 0; > +} > + > +static int __exit davinci_pm_remove(struct platform_device *pdev) > +{ > + sram_free(davinci_sram_suspend, davinci_cpu_suspend_sz); > + return 0; > +} > + > +static struct platform_driver davinci_pm_driver = { > + .driver = { > + .name = "pm-davinci", > + .owner = THIS_MODULE, > + }, > + .remove = __exit_p(davinci_pm_remove), > +}; > + > +static int __init davinci_pm_init(void) > +{ > + return platform_driver_probe(&davinci_pm_driver, davinci_pm_probe); > +} > +late_initcall(davinci_pm_init); > diff --git a/arch/arm/mach-davinci/sleep.S b/arch/arm/mach-davinci/sleep.S > new file mode 100644 > index 0000000..fb5e72b > --- /dev/null > +++ b/arch/arm/mach-davinci/sleep.S > @@ -0,0 +1,224 @@ > +/* > + * (C) Copyright 2009, Texas Instruments, Inc. http://www.ti.com/ > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * version 2 as published by the Free Software Foundation. > + * > + * 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 > + */ > + > +/* replicated define because linux/bitops.h cannot be included in assembly */ > +#define BIT(nr) (1 << (nr)) > + > +#include > +#include > +#include > +#include > + > +#include "clock.h" > + > +/* Arbitrary, hardware currently does not update PHYRDY correctly */ > +#define PHYRDY_CYCLES 0x1000 > + > +/* Assume 25 MHz speed for the cycle conversions since PLLs are bypassed */ > +#define PLL_BYPASS_CYCLES (PLL_BYPASS_TIME * 25) > +#define PLL_RESET_CYCLES (PLL_RESET_TIME * 25) > +#define PLL_LOCK_CYCLES (PLL_LOCK_TIME * 25) > + > +#define DEEPSLEEP_SLEEPENABLE_BIT BIT(31) > + > + .text > +/* > + * Move DaVinci into deep sleep state > + * > + * Note: This code is copied to internal SRAM by PM code. When the DaVinci > + * wakes up it continues execution at the point it went to sleep. > + * Register Usage: > + * r0: contains virtual base for DDR2 controller > + * r1: contains virtual base for DDR2 Power and Sleep controller (PSC) > + * r2: contains PSC number for DDR2 > + * r3: contains virtual base DDR2 PLL controller > + * r4: contains virtual address of the DEEPSLEEP register > + */ > +ENTRY(davinci_cpu_suspend) > + stmfd sp!, {r0-r12, lr} @ save registers on stack > + > + ldr ip, CACHE_FLUSH > + blx ip > + > + ldmia r0, {r0-r4} > + > + /* > + * Switch DDR to self-refresh mode. > + */ > + > + /* calculate SDRCR address */ > + ldr ip, [r0, #DDR2_SDRCR_OFFSET] > + bic ip, ip, #DDR2_SRPD_BIT > + orr ip, ip, #DDR2_LPMODEN_BIT > + str ip, [r0, #DDR2_SDRCR_OFFSET] > + > + ldr ip, [r0, #DDR2_SDRCR_OFFSET] > + orr ip, ip, #DDR2_MCLKSTOPEN_BIT > + str ip, [r0, #DDR2_SDRCR_OFFSET] > + > + mov ip, #PHYRDY_CYCLES > +1: subs ip, ip, #0x1 > + bne 1b > + > + /* Disable DDR2 LPSC */ > + mov r7, r0 > + mov r0, #0x2 > + bl davinci_ddr_psc_config > + mov r0, r7 > + > + /* Disable clock to DDR PHY */ > + ldr ip, [r3, #PLLDIV1] > + bic ip, ip, #PLLDIV_EN > + str ip, [r3, #PLLDIV1] > + > + /* Put the DDR PLL in bypass and power down */ > + ldr ip, [r3, #PLLCTL] > + bic ip, ip, #PLLCTL_PLLENSRC > + bic ip, ip, #PLLCTL_PLLEN > + str ip, [r3, #PLLCTL] > + > + /* Wait for PLL to switch to bypass */ > + mov ip, #PLL_BYPASS_CYCLES > +2: subs ip, ip, #0x1 > + bne 2b > + > + /* Power down the PLL */ > + ldr ip, [r3, #PLLCTL] > + orr ip, ip, #PLLCTL_PLLPWRDN > + str ip, [r3, #PLLCTL] > + > + /* Go to deep sleep */ > + ldr ip, [r4] > + orr ip, ip, #DEEPSLEEP_SLEEPENABLE_BIT > + /* System goes to sleep beyond after this instruction */ > + str ip, [r4] > + > + /* Wake up from sleep */ > + > + /* Clear sleep enable */ > + ldr ip, [r4] > + bic ip, ip, #DEEPSLEEP_SLEEPENABLE_BIT > + str ip, [r4] > + > + /* initialize the DDR PLL controller */ > + > + /* Put PLL in reset */ > + ldr ip, [r3, #PLLCTL] > + bic ip, ip, #PLLCTL_PLLRST > + str ip, [r3, #PLLCTL] > + > + /* Clear PLL power down */ > + ldr ip, [r3, #PLLCTL] > + bic ip, ip, #PLLCTL_PLLPWRDN > + str ip, [r3, #PLLCTL] > + > + mov ip, #PLL_RESET_CYCLES > +3: subs ip, ip, #0x1 > + bne 3b > + > + /* Bring PLL out of reset */ > + ldr ip, [r3, #PLLCTL] > + orr ip, ip, #PLLCTL_PLLRST > + str ip, [r3, #PLLCTL] > + > + /* Wait for PLL to lock (assume prediv = 1, 25MHz OSCIN) */ > + mov ip, #PLL_LOCK_CYCLES > +4: subs ip, ip, #0x1 > + bne 4b > + > + /* Remove PLL from bypass mode */ > + ldr ip, [r3, #PLLCTL] > + bic ip, ip, #PLLCTL_PLLENSRC > + orr ip, ip, #PLLCTL_PLLEN > + str ip, [r3, #PLLCTL] > + > + /* Start 2x clock to DDR2 */ > + > + ldr ip, [r3, #PLLDIV1] > + orr ip, ip, #PLLDIV_EN > + str ip, [r3, #PLLDIV1] > + > + /* Enable VCLK */ > + > + /* Enable DDR2 LPSC */ > + mov r7, r0 > + mov r0, #0x3 > + bl davinci_ddr_psc_config > + mov r0, r7 > + > + /* clear MCLKSTOPEN */ > + > + ldr ip, [r0, #DDR2_SDRCR_OFFSET] > + bic ip, ip, #DDR2_MCLKSTOPEN_BIT > + str ip, [r0, #DDR2_SDRCR_OFFSET] > + > + ldr ip, [r0, #DDR2_SDRCR_OFFSET] > + bic ip, ip, #DDR2_LPMODEN_BIT > + str ip, [r0, #DDR2_SDRCR_OFFSET] > + > + /* Restore registers and return */ > + ldmfd sp!, {r0-r12, pc} > + > +ENDPROC(davinci_cpu_suspend) > + > +/* > + * Disables or Enables DDR2 LPSC > + * Register Usage: > + * r0: Enable or Disable LPSC r0 = 0x3 => Enable, r0 = 0x2 => Disable LPSC > + * r1: contains virtual base for DDR2 Power and Sleep controller (PSC) > + * r2: contains PSC number for DDR2 > + */ > +ENTRY(davinci_ddr_psc_config) > + /* Set next state in mdctl for DDR2 */ > + mov r6, #MDCTL > + add r6, r6, r2, lsl #2 > + ldr ip, [r1, r6] > + bic ip, ip, #MDSTAT_STATE_MASK > + orr ip, ip, r0 > + str ip, [r1, r6] > + > + /* Enable the Power Domain Transition Command */ > + ldr ip, [r1, #PTCMD] > + orr ip, ip, #0x1 > + str ip, [r1, #PTCMD] > + > + /* Check for Transition Complete (PTSTAT) */ > +ptstat_done: > + ldr ip, [r1, #PTSTAT] > + and ip, ip, #0x1 > + cmp ip, #0x0 > + bne ptstat_done > + > + /* Check for DDR2 clock disable completion; */ > + mov r6, #MDSTAT > + add r6, r6, r2, lsl #2 > +ddr2clk_stop_done: > + ldr ip, [r1, r6] > + and ip, ip, #MDSTAT_STATE_MASK > + cmp ip, r0 > + bne ddr2clk_stop_done > + > + mov pc, lr > +ENDPROC(davinci_ddr_psc_config) > + > +CACHE_FLUSH: > + .word arm926_flush_kern_cache_all > + > +ENTRY(davinci_cpu_suspend_sz) > + .word . - davinci_cpu_suspend > +ENDPROC(davinci_cpu_suspend_sz) > -- > 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 Tue Jan 5 17:24:08 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 15:24:08 -0800 Subject: [PATCH] davinci: clock: Check CLK_PSC flag before disabling PSC In-Reply-To: <1260880378-4708-1-git-send-email-chaithrika@ti.com> (Chaithrika U. S.'s message of "Tue\, 15 Dec 2009 18\:02\:58 +0530") References: <1260880378-4708-1-git-send-email-chaithrika@ti.com> Message-ID: <87aawsrv8n.fsf@deeprootsystems.com> Chaithrika U S writes: > Some modules do not have PSC to control their clocks. > The 'lpsc' field in the clk structure is 0 for such clocks. > > In the clock disable function check for CLK PSC flag before > disabling the PSC. If this is not taken care of then it may > so happen that module controlled by LPSC 0 is erroneously disabled. > > Signed-off-by: Chaithrika U S Looks good, Applying to master and queuing for 2.6.33-rc in davinci-fixes branch. Kevin > --- > arch/arm/mach-davinci/clock.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c > index e46a643..f097f8d 100644 > --- a/arch/arm/mach-davinci/clock.c > +++ b/arch/arm/mach-davinci/clock.c > @@ -49,7 +49,8 @@ static void __clk_disable(struct clk *clk) > { > if (WARN_ON(atomic_read(&clk->usecount) == 0)) > return; > - if (atomic_dec_and_test(&clk->usecount) && !(clk->flags & CLK_PLL)) > + if (atomic_dec_and_test(&clk->usecount) && !(clk->flags & CLK_PLL) > + && (clk->flags & CLK_PSC)) > davinci_psc_config(psc_domain(clk), clk->gpsc, clk->lpsc, 0); > if (clk->parent) > __clk_disable(clk->parent); > -- > 1.5.6 From khilman at deeprootsystems.com Tue Jan 5 17:28:02 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 15:28:02 -0800 Subject: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver In-Reply-To: <1260895054-13232-1-git-send-email-m-karicheri2@ti.com> (m-karicheri2@ti.com's message of "Tue\, 15 Dec 2009 11\:37\:31 -0500") References: <1260895054-13232-1-git-send-email-m-karicheri2@ti.com> Message-ID: <871vi4rv25.fsf@deeprootsystems.com> m-karicheri2 at ti.com writes: > From: Muralidharan Karicheri > > This combines the two patches sent earlier to change the clock configuration > and converting ccdc drivers to platform drivers. This has updated comments > against v2 of these patches. Two new clocks "master" and "slave" are defined for ccdc driver > as per comments from Kevin Hilman. > > This adds platform code for ccdc driver on DM355 and DM6446. > > Reviewed-by: Vaibhav Hiremath > Reviewed-by: Kevin Hilman > > Signed-off-by: Muralidharan Karicheri > --- > Applies to linux-davinci tree > arch/arm/mach-davinci/dm355.c | 41 ++++++++++++++++++++++++++++----------- > arch/arm/mach-davinci/dm644x.c | 20 ++++++++++++++++++- > 2 files changed, 48 insertions(+), 13 deletions(-) > > diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c > index 2244e8c..a9ea761 100644 > --- a/arch/arm/mach-davinci/dm355.c > +++ b/arch/arm/mach-davinci/dm355.c > @@ -378,6 +378,8 @@ static struct davinci_clk dm355_clks[] = { > CLK(NULL, "timer3", &timer3_clk), > CLK(NULL, "rto", &rto_clk), > CLK(NULL, "usb", &usb_clk), > + CLK("dm355_ccdc", "master", &vpss_master_clk), > + CLK("dm355_ccdc", "slave", &vpss_slave_clk), I still don't understand why you have to add new entries here and can't simply rename the existing CLK nodes using vpss_*_clk. Same comment for dm644x.c changes. Kevin > CLK(NULL, NULL, NULL), > }; > > @@ -665,6 +667,17 @@ static struct platform_device dm355_asp1_device = { > .resource = dm355_asp1_resources, > }; > > +static void dm355_ccdc_setup_pinmux(void) > +{ > + davinci_cfg_reg(DM355_VIN_PCLK); > + davinci_cfg_reg(DM355_VIN_CAM_WEN); > + davinci_cfg_reg(DM355_VIN_CAM_VD); > + davinci_cfg_reg(DM355_VIN_CAM_HD); > + davinci_cfg_reg(DM355_VIN_YIN_EN); > + davinci_cfg_reg(DM355_VIN_CINL_EN); > + davinci_cfg_reg(DM355_VIN_CINH_EN); > +} > + > static struct resource dm355_vpss_resources[] = { > { > /* VPSS BL Base address */ > @@ -701,6 +714,10 @@ static struct resource vpfe_resources[] = { > .end = IRQ_VDINT1, > .flags = IORESOURCE_IRQ, > }, > +}; > + > +static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32); > +static struct resource dm355_ccdc_resource[] = { > /* CCDC Base address */ > { > .flags = IORESOURCE_MEM, > @@ -708,8 +725,18 @@ static struct resource vpfe_resources[] = { > .end = 0x01c70600 + 0x1ff, > }, > }; > +static struct platform_device dm355_ccdc_dev = { > + .name = "dm355_ccdc", > + .id = -1, > + .num_resources = ARRAY_SIZE(dm355_ccdc_resource), > + .resource = dm355_ccdc_resource, > + .dev = { > + .dma_mask = &vpfe_capture_dma_mask, > + .coherent_dma_mask = DMA_BIT_MASK(32), > + .platform_data = dm355_ccdc_setup_pinmux, > + }, > +}; > > -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32); > static struct platform_device vpfe_capture_dev = { > .name = CAPTURE_DRV_NAME, > .id = -1, > @@ -860,17 +887,7 @@ static int __init dm355_init_devices(void) > davinci_cfg_reg(DM355_INT_EDMA_CC); > platform_device_register(&dm355_edma_device); > platform_device_register(&dm355_vpss_device); > - /* > - * setup Mux configuration for vpfe input and register > - * vpfe capture platform device > - */ > - davinci_cfg_reg(DM355_VIN_PCLK); > - davinci_cfg_reg(DM355_VIN_CAM_WEN); > - davinci_cfg_reg(DM355_VIN_CAM_VD); > - davinci_cfg_reg(DM355_VIN_CAM_HD); > - davinci_cfg_reg(DM355_VIN_YIN_EN); > - davinci_cfg_reg(DM355_VIN_CINL_EN); > - davinci_cfg_reg(DM355_VIN_CINH_EN); > + platform_device_register(&dm355_ccdc_dev); > platform_device_register(&vpfe_capture_dev); > > return 0; > diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c > index e65e29e..e5f1ee9 100644 > --- a/arch/arm/mach-davinci/dm644x.c > +++ b/arch/arm/mach-davinci/dm644x.c > @@ -315,6 +315,8 @@ struct davinci_clk dm644x_clks[] = { > CLK(NULL, "timer0", &timer0_clk), > CLK(NULL, "timer1", &timer1_clk), > CLK("watchdog", NULL, &timer2_clk), > + CLK("dm644x_ccdc", "master", &vpss_master_clk), > + CLK("dm644x_ccdc", "slave", &vpss_slave_clk), > CLK(NULL, NULL, NULL), > }; > > @@ -612,6 +614,11 @@ static struct resource vpfe_resources[] = { > .end = IRQ_VDINT1, > .flags = IORESOURCE_IRQ, > }, > +}; > + > +static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32); > +static struct resource dm644x_ccdc_resource[] = { > + /* CCDC Base address */ > { > .start = 0x01c70400, > .end = 0x01c70400 + 0xff, > @@ -619,7 +626,17 @@ static struct resource vpfe_resources[] = { > }, > }; > > -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32); > +static struct platform_device dm644x_ccdc_dev = { > + .name = "dm644x_ccdc", > + .id = -1, > + .num_resources = ARRAY_SIZE(dm644x_ccdc_resource), > + .resource = dm644x_ccdc_resource, > + .dev = { > + .dma_mask = &vpfe_capture_dma_mask, > + .coherent_dma_mask = DMA_BIT_MASK(32), > + }, > +}; > + > static struct platform_device vpfe_capture_dev = { > .name = CAPTURE_DRV_NAME, > .id = -1, > @@ -772,6 +789,7 @@ static int __init dm644x_init_devices(void) > platform_device_register(&dm644x_edma_device); > platform_device_register(&dm644x_emac_device); > platform_device_register(&dm644x_vpss_device); > + platform_device_register(&dm644x_ccdc_dev); > platform_device_register(&vpfe_capture_dev); > > return 0; > -- > 1.6.0.4 From khilman at deeprootsystems.com Tue Jan 5 17:33:08 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 15:33:08 -0800 Subject: [PATCH] DaVinci: DM365: Changing default queue for DM365. In-Reply-To: <1260903943-4924-1-git-send-email-s-paulraj@ti.com> (s-paulraj@ti.com's message of "Tue\, 15 Dec 2009 14\:05\:43 -0500") References: <1260903943-4924-1-git-send-email-s-paulraj@ti.com> Message-ID: <87wrzwqg97.fsf@deeprootsystems.com> s-paulraj at ti.com writes: > From: Sandeep Paulraj > > In DM365 Q0, Q1 and Q2 are used by codecs. > LSP drivers should use Q3. > This patch changes the default queue for DM365. > > Signed-off-by: Sandeep Paulraj Thanks. Applying to master, queueing for 2.6.34 in davinci-next. Kevin > --- > arch/arm/mach-davinci/dm365.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c > index cc3bae4..62cec33 100644 > --- a/arch/arm/mach-davinci/dm365.c > +++ b/arch/arm/mach-davinci/dm365.c > @@ -754,7 +754,7 @@ static struct edma_soc_info dm365_edma_info[] = { > .n_cc = 1, > .queue_tc_mapping = dm365_queue_tc_mapping, > .queue_priority_mapping = dm365_queue_priority_mapping, > - .default_queue = EVENTQ_2, > + .default_queue = EVENTQ_3, > }, > }; > > -- > 1.6.0.4 > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source From khilman at deeprootsystems.com Tue Jan 5 17:39:10 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 15:39:10 -0800 Subject: Audio quality with CPU frequency scaling In-Reply-To: <02a001ca7e38$6f1eac70$4d5c0550$@com> (Chaithrika U. S.'s message of "Wed\, 16 Dec 2009 15\:43\:36 +0530") References: <02a001ca7e38$6f1eac70$4d5c0550$@com> Message-ID: <87pr5oqfz5.fsf@deeprootsystems.com> "Chaithrika U S" writes: > Kevin, > > With the cpufreq support on DA850/OMAP-L138 SoC we are observing > that audio does not function as expected at all sampling rates > for various operating points. At a CPU frequency of 96MHz, audio > works fine with a sampling frequency of 8kHz. For other sampling > rates, there are lot of underrun/overrun errors. This is because > of EDMA also runs at a lower speed and is not able to transfer > data at the desired rate. > > To overcome the above, we can depend on the user to set the scaling > min frequency to be the same as scaling max frequency (in this case > 300 MHz) before starting aplay/arecord or temporarily move to > performance governor so that the audio quality is not affected. > > Do you think this is the right approach to this problem? Any other > solutions you suggest exploring? An alternative to relying on the user to change the CPUfreq policy is to have the audio driver itself do that. Based on the sample rate and clock frequency, the audio driver should be able to determine that the EDMA rate will not be fast enough and set a CPUfreq policy so that lower frequencies are not attempted. When the audio driver is done, it can set the policy back. Kevin From khilman at deeprootsystems.com Tue Jan 5 17:43:30 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 15:43:30 -0800 Subject: [PATCH v2] SPI DaVinci: SPI master driver for DaVinci/DA8xx In-Reply-To: <1261000938-1897-1-git-send-email-s-paulraj@ti.com> (s-paulraj@ti.com's message of "Wed\, 16 Dec 2009 17\:02\:18 -0500") References: <1261000938-1897-1-git-send-email-s-paulraj@ti.com> Message-ID: <87iqbgqfrx.fsf@deeprootsystems.com> s-paulraj at ti.com writes: > From: Sandeep Paulraj > > This patch adds support for a SPI master driver for the > DaVinci series of SOCs > > Signed-off-by: Sandeep Paulraj > Signed-off-by: Mark A. Greer > Signed-off-by: Philby John > Signed-off-by: Sudhakar Rajashekhara In case it helps move this along... Signed-off-by: Kevin Hilman > --- > drivers/spi/Kconfig | 7 + > drivers/spi/Makefile | 1 + > drivers/spi/davinci_spi.c | 1109 +++++++++++++++++++++++++++++++++++++++++++++ > drivers/spi/davinci_spi.h | 171 +++++++ > 4 files changed, 1288 insertions(+), 0 deletions(-) > create mode 100644 drivers/spi/davinci_spi.c > create mode 100644 drivers/spi/davinci_spi.h > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > index 4b6f7cb..28d2fae 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -77,6 +77,13 @@ config SPI_AU1550 > This driver can also be built as a module. If so, the module > will be called au1550_spi. > > +config SPI_DAVINCI > + tristate "SPI controller driver for DaVinci/DA8xx SoC's" > + depends on SPI_MASTER && ARCH_DAVINCI > + select SPI_BITBANG > + help > + SPI master controller for DaVinci and DA8xx SPI modules. > + > config SPI_BITBANG > tristate "Utilities for Bitbanging SPI masters" > help > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > index 21a1182..11f995d 100644 > --- a/drivers/spi/Makefile > +++ b/drivers/spi/Makefile > @@ -33,6 +33,7 @@ obj-$(CONFIG_SPI_TXX9) += spi_txx9.o > obj-$(CONFIG_SPI_XILINX) += xilinx_spi.o > obj-$(CONFIG_SPI_SH_SCI) += spi_sh_sci.o > obj-$(CONFIG_SPI_STMP3XXX) += spi_stmp.o > +obj-$(CONFIG_SPI_DAVINCI) += davinci_spi.o > # ... add above this line ... > > # SPI protocol drivers (device/link on bus) > diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c > new file mode 100644 > index 0000000..c62721a > --- /dev/null > +++ b/drivers/spi/davinci_spi.c > @@ -0,0 +1,1109 @@ > +/* > + * Copyright (C) 2009 Texas Instruments. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; 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 "davinci_spi.h" > + > +#define SPI_NO_RESOURCE ((resource_size_t)-1) > + > +static unsigned use_dma; > + > +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; > +} > + > +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; > +} > + > +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; > + 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; > + return data; > +} > + > +static inline void set_io_bits(void __iomem *addr, u32 bits) > +{ > + u32 v = ioread32(addr); > + > + v |= bits; > + iowrite32(v, addr); > +} > + > +static inline void clear_io_bits(void __iomem *addr, u32 bits) > +{ > + u32 v = ioread32(addr); > + > + v &= ~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 > + */ > +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; > + > + 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); > + > + while ((ioread32(davinci_spi->base + SPIBUF) > + & SPIBUF_RXEMPTY_MASK) == 0) > + cpu_relax(); > + } > +} > + > +/* > + * davinci_spi_setup_transfer - This functions will determine transfer method > + * @spi: spi device on which data transfer to be done > + * @t: spi transfer in which transfer info is filled > + * > + * This function determines data transfer method (8/16/32 bit transfer). > + * It will also set the SPI Clock Control register according to > + * SPI slave device freq. > + */ > +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; > + > + davinci_spi = spi_master_get_devdata(spi->master); > + pdata = davinci_spi->pdata; > + > + if (t) { > + bits_per_word = t->bits_per_word; > + hz = t->speed_hz; > + } > + > + /* if bits_per_word is not set then set it default */ > + if (!bits_per_word) > + bits_per_word = spi->bits_per_word; > + > + /* > + * Assign function pointer to appropriate transfer method > + * 8bit, 16bit or 32bit transfer > + */ > + 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; > + } 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; > + } 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 = ((clk_get_rate(davinci_spi->clk) / hz) - 1) & 0xff; > + > + clear_fmt_bits(davinci_spi->base, 0x0000ff00, spi->chip_select); > + set_fmt_bits(davinci_spi->base, prescale << 8, spi->chip_select); > + > + 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_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]); > + 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); > + > + complete(&davinci_spi_dma->dma_rx_completion); > + /* We must disable the DMA RX request */ > + davinci_spi_set_dma_req(spi, 0); > +} > + > +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_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]); > + 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); > +} > + > +static int davinci_spi_request_dma(struct spi_device *spi) > +{ > + struct davinci_spi *davinci_spi; > + struct davinci_spi_dma *davinci_spi_dma; > + struct davinci_spi_platform_data *pdata; > + struct device *sdev; > + int r; > + > + davinci_spi = spi_master_get_devdata(spi->master); > + davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select]; > + 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->eventq); > + if (r < 0) { > + dev_dbg(sdev, "Unable to request DMA channel for SPI RX\n"); > + return -EAGAIN; > + } > + 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->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 SPI TX\n"); > + return -EAGAIN; > + } > + davinci_spi_dma->dma_tx_channel = r; > + > + return 0; > +} > + > +/* > + * davinci_spi_setup - This functions will set default transfer method > + * @spi: spi device on which data transfer to be done > + * > + * This functions sets the default transfer method. > + */ > + > +static int davinci_spi_setup(struct spi_device *spi) > +{ > + int retval; > + struct davinci_spi *davinci_spi; > + struct davinci_spi_dma *davinci_spi_dma; > + struct device *sdev; > + > + davinci_spi = spi_master_get_devdata(spi->master); > + sdev = davinci_spi->bitbang.master->dev.parent; > + > + /* 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 ((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) { > + dev_dbg(sdev, "Operating frequency is not in acceptable " > + "range\n"); > + 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_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); > + > + /* > + * 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) > + */ > + > + 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); > + > + return retval; > +} > + > +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; > + > + 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; > + > + iowrite32(op_mode, davinci_spi->base + SPIPC0); > + > + 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 int davinci_spi_check_error(struct davinci_spi *davinci_spi, > + int int_status) > +{ > + struct device *sdev = davinci_spi->bitbang.master->dev.parent; > + > + if (int_status & SPIFLG_TIMEOUT_MASK) { > + dev_dbg(sdev, "SPI Time-out Error\n"); > + return -ETIMEDOUT; > + } > + if (int_status & SPIFLG_DESYNC_MASK) { > + dev_dbg(sdev, "SPI Desynchronization Error\n"); > + return -EIO; > + } > + if (int_status & SPIFLG_BITERR_MASK) { > + dev_dbg(sdev, "SPI Bit error\n"); > + return -EIO; > + } > + > + if (davinci_spi->version == SPI_VERSION_2) { > + if (int_status & SPIFLG_DLEN_ERR_MASK) { > + dev_dbg(sdev, "SPI Data Length Error\n"); > + return -EIO; > + } > + if (int_status & SPIFLG_PARERR_MASK) { > + dev_dbg(sdev, "SPI Parity Error\n"); > + return -EIO; > + } > + if (int_status & SPIFLG_OVRRUN_MASK) { > + dev_dbg(sdev, "SPI Data Overrun error\n"); > + return -EIO; > + } > + if (int_status & SPIFLG_TX_INTR_MASK) { > + dev_dbg(sdev, "SPI TX intr bit set\n"); > + return -EIO; > + } > + if (int_status & SPIFLG_BUF_INIT_ACTIVE_MASK) { > + dev_dbg(sdev, "SPI Buffer Init Active\n"); > + return -EBUSY; > + } > + } > + > + return 0; > +} > + > +/* > + * 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 > + * > + * 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_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 based 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) > +{ > + struct davinci_spi *davinci_spi; > + int int_status = 0; > + int count, temp_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 device *sdev; > + > + davinci_spi = spi_master_get_devdata(spi->master); > + pdata = davinci_spi->pdata; > + sdev = davinci_spi->bitbang.master->dev.parent; > + > + 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; > + > + davinci_spi->tx = t->tx_buf; > + davinci_spi->rx = t->rx_buf; > + > + /* 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; > + > + 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 -EINVAL; > + > + 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; > + > + /* CS 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) { > + 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, "Unable to DMA map a %d bytes" > + " TX buffer\n", count); > + return -ENOMEM; > + } > + temp_count = count; > + } 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, "Unable to DMA map a %d bytes" > + " TX tmp buffer\n", count); > + return -ENOMEM; > + } > + temp_count = count + 1; > + } > + > + edma_set_transfer_params(davinci_spi_dma->dma_tx_channel, > + data_type, temp_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); > + > + if (t->rx_buf) { > + /* 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 -ENOMEM; > + } > + 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) || (t->rx_buf)) > + edma_start(davinci_spi_dma->dma_tx_channel); > + > + if (t->rx_buf) > + edma_start(davinci_spi_dma->dma_rx_channel); > + > + if ((t->rx_buf) || (t->tx_buf)) > + davinci_spi_set_dma_req(spi, 1); > + > + if (t->tx_buf) > + wait_for_completion_interruptible( > + &davinci_spi_dma->dma_tx_completion); > + > + if (t->rx_buf) > + wait_for_completion_interruptible( > + &davinci_spi_dma->dma_rx_completion); > + > + dma_unmap_single(NULL, t->tx_dma, temp_count, DMA_TO_DEVICE); > + > + if (t->rx_buf) > + 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; > + > + return t->len; > +} > + > +/* > + * davinci_spi_irq - IRQ handler for DaVinci SPI > + * @irq: IRQ number for this SPI Master > + * @context_data: structure for SPI Master controller davinci_spi > + */ > +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 = ioread32(davinci_spi->base + SPIFLG); > + > + while ((int_status & SPIFLG_RX_INTR_MASK)) { > + if (likely(int_status & SPIFLG_RX_INTR_MASK)) { > + ret = IRQ_HANDLED; > + > + 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; > +} > + > +/* > + * davinci_spi_probe - probe function for SPI Master Controller > + * pdev: platform_device structure which contains plateform specific data > + */ > +static int davinci_spi_probe(struct platform_device *pdev) > +{ > + struct spi_master *master; > + struct davinci_spi *davinci_spi; > + struct davinci_spi_platform_data *pdata; > + struct resource *r, *mem; > + resource_size_t dma_rx_chan = SPI_NO_RESOURCE; > + resource_size_t dma_tx_chan = SPI_NO_RESOURCE; > + resource_size_t dma_eventq = SPI_NO_RESOURCE; > + int i = 0, ret = 0; > + > + pdata = pdev->dev.platform_data; > + if (pdata == NULL) { > + ret = -ENODEV; > + goto err; > + } > + > + master = spi_alloc_master(&pdev->dev, sizeof(struct davinci_spi)); > + if (master == NULL) { > + ret = -ENOMEM; > + goto err; > + } > + > + dev_set_drvdata(&pdev->dev, master); > + > + davinci_spi = spi_master_get_devdata(master); > + if (davinci_spi == NULL) { > + ret = -ENOENT; > + goto free_master; > + } > + > + r = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + if (r == NULL) { > + ret = -ENOENT; > + goto free_master; > + } > + > + davinci_spi->pbase = r->start; > + davinci_spi->region_size = resource_size(r); > + davinci_spi->pdata = pdata; > + > + mem = request_mem_region(r->start, davinci_spi->region_size, > + pdev->name); > + if (mem == NULL) { > + ret = -EBUSY; > + goto free_master; > + } > + > + davinci_spi->base = (struct davinci_spi_reg __iomem *) > + ioremap(r->start, davinci_spi->region_size); > + if (davinci_spi->base == NULL) { > + ret = -ENOMEM; > + goto release_region; > + } > + > + davinci_spi->irq = platform_get_irq(pdev, 0); > + if (davinci_spi->irq <= 0) { > + ret = -EINVAL; > + goto unmap_io; > + } > + > + ret = request_irq(davinci_spi->irq, davinci_spi_irq, IRQF_DISABLED, > + dev_name(&pdev->dev), davinci_spi); > + if (ret) > + goto unmap_io; > + > + /* Allocate tmp_buf for tx_buf */ > + davinci_spi->tmp_buf = kzalloc(SPI_BUFSIZ, GFP_KERNEL); > + if (davinci_spi->tmp_buf == NULL) { > + ret = -ENOMEM; > + goto irq_free; > + } > + > + davinci_spi->bitbang.master = spi_master_get(master); > + if (davinci_spi->bitbang.master == NULL) { > + ret = -ENODEV; > + goto free_tmp_buf; > + } > + > + davinci_spi->clk = clk_get(&pdev->dev, NULL); > + if (IS_ERR(davinci_spi->clk)) { > + ret = -ENODEV; > + goto put_master; > + } > + clk_enable(davinci_spi->clk); > + > + > + master->bus_num = pdev->id; > + master->num_chipselect = pdata->num_chipselect; > + master->setup = davinci_spi_setup; > + master->cleanup = davinci_spi_cleanup; > + > + davinci_spi->bitbang.chipselect = davinci_spi_chipselect; > + davinci_spi->bitbang.setup_transfer = davinci_spi_setup_transfer; > + > + 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) { > + r = platform_get_resource(pdev, IORESOURCE_DMA, 0); > + if (r) > + dma_rx_chan = r->start; > + r = platform_get_resource(pdev, IORESOURCE_DMA, 1); > + if (r) > + dma_tx_chan = r->start; > + r = platform_get_resource(pdev, IORESOURCE_DMA, 2); > + if (r) > + dma_eventq = r->start; > + } > + > + if (!use_dma || > + dma_rx_chan == SPI_NO_RESOURCE || > + dma_tx_chan == SPI_NO_RESOURCE || > + dma_eventq == 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); > + } > + > + davinci_spi->get_rx = davinci_spi_rx_buf_u8; > + davinci_spi->get_tx = davinci_spi_tx_buf_u8; > + > + init_completion(&davinci_spi->done); > + > + /* Reset In/OUT SPI module */ > + iowrite32(0, davinci_spi->base + SPIGCR0); > + 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); > + > + /* master mode default */ > + set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_MASTER_MASK); > + > + if (davinci_spi->pdata->intr_level) > + iowrite32(SPI_INTLVL_1, davinci_spi->base + SPILVL); > + else > + iowrite32(SPI_INTLVL_0, davinci_spi->base + SPILVL); > + > + ret = spi_bitbang_start(&davinci_spi->bitbang); > + if (ret) > + goto free_clk; > + > + 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: > + clk_disable(davinci_spi->clk); > + clk_put(davinci_spi->clk); > +put_master: > + spi_master_put(master); > +free_tmp_buf: > + kfree(davinci_spi->tmp_buf); > +irq_free: > + free_irq(davinci_spi->irq, davinci_spi); > +unmap_io: > + iounmap(davinci_spi->base); > +release_region: > + release_mem_region(davinci_spi->pbase, davinci_spi->region_size); > +free_master: > + kfree(master); > +err: > + return ret; > +} > + > +/* > + * davinci_spi_remove - remove function for SPI Master Controller > + * @pdev: platform_device structure which contains plateform specific data > + * > + * This function will do the reverse action of davinci_spi_probe function > + * It will free the IRQ and SPI controller's memory region. > + * It will also call spi_bitbang_stop to destroy the work queue which was > + * created by spi_bitbang_start. > + */ > +static int __exit davinci_spi_remove(struct platform_device *pdev) > +{ > + struct davinci_spi *davinci_spi; > + struct spi_master *master; > + > + master = dev_get_drvdata(&pdev->dev); > + davinci_spi = spi_master_get_devdata(master); > + > + spi_bitbang_stop(&davinci_spi->bitbang); > + > + clk_disable(davinci_spi->clk); > + clk_put(davinci_spi->clk); > + spi_master_put(master); > + kfree(davinci_spi->tmp_buf); > + free_irq(davinci_spi->irq, davinci_spi); > + iounmap(davinci_spi->base); > + release_mem_region(davinci_spi->pbase, davinci_spi->region_size); > + > + return 0; > +} > + > +static struct platform_driver davinci_spi_driver = { > + .driver.name = "spi_davinci", > + .remove = __exit_p(davinci_spi_remove), > +}; > + > +static int __init davinci_spi_init(void) > +{ > + return platform_driver_probe(&davinci_spi_driver, davinci_spi_probe); > +} > + > +static void __exit davinci_spi_exit(void) > +{ > + platform_driver_unregister(&davinci_spi_driver); > +} > + > +module_init(davinci_spi_init); > +module_exit(davinci_spi_exit); > + > +MODULE_DESCRIPTION("TI DaVinci SPI Master Controller Driver"); > +MODULE_LICENSE("GPL"); > diff --git a/drivers/spi/davinci_spi.h b/drivers/spi/davinci_spi.h > new file mode 100644 > index 0000000..98508c2 > --- /dev/null > +++ b/drivers/spi/davinci_spi.h > @@ -0,0 +1,171 @@ > +/* > + * Copyright (C) 2009 Texas Instruments. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; 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_SPI_H > +#define __DAVINCI_SPI_H > + > +#define SPI_MAX_CHIPSELECT 2 > + > +#define CS_DEFAULT 0xFF > + > +#define SPI_BUFSIZ (SMP_CACHE_BYTES + 1) > +#define DAVINCI_DMA_DATA_TYPE_S8 0x01 > +#define DAVINCI_DMA_DATA_TYPE_S16 0x02 > +#define DAVINCI_DMA_DATA_TYPE_S32 0x04 > + > +#define SPIFMT_PHASE_MASK BIT(16) > +#define SPIFMT_POLARITY_MASK BIT(17) > +#define SPIFMT_DISTIMER_MASK BIT(18) > +#define SPIFMT_SHIFTDIR_MASK BIT(20) > +#define SPIFMT_WAITENA_MASK BIT(21) > +#define SPIFMT_PARITYENA_MASK BIT(22) > +#define SPIFMT_ODD_PARITY_MASK BIT(23) > +#define SPIFMT_WDELAY_MASK 0x3f000000u > +#define SPIFMT_WDELAY_SHIFT 24 > +#define SPIFMT_CHARLEN_MASK 0x0000001Fu > + > +/* SPIGCR1 */ > +#define SPIGCR1_SPIENA_MASK 0x01000000u > + > +/* SPIPC0 */ > +#define SPIPC0_DIFUN_MASK BIT(11) /* MISO */ > +#define SPIPC0_DOFUN_MASK BIT(10) /* MOSI */ > +#define SPIPC0_CLKFUN_MASK BIT(9) /* CLK */ > +#define SPIPC0_SPIENA_MASK BIT(8) /* nREADY */ > +#define SPIPC0_EN1FUN_MASK BIT(1) > +#define SPIPC0_EN0FUN_MASK BIT(0) > + > +#define SPIINT_MASKALL 0x0101035F > +#define SPI_INTLVL_1 0x000001FFu > +#define SPI_INTLVL_0 0x00000000u > + > +/* SPIDAT1 */ > +#define SPIDAT1_CSHOLD_SHIFT 28 > +#define SPIDAT1_CSNR_SHIFT 16 > +#define SPIGCR1_CLKMOD_MASK BIT(1) > +#define SPIGCR1_MASTER_MASK BIT(0) > +#define SPIGCR1_LOOPBACK_MASK BIT(16) > + > +/* SPIBUF */ > +#define SPIBUF_TXFULL_MASK BIT(29) > +#define SPIBUF_RXEMPTY_MASK BIT(31) > + > +/* Error Masks */ > +#define SPIFLG_DLEN_ERR_MASK BIT(0) > +#define SPIFLG_TIMEOUT_MASK BIT(1) > +#define SPIFLG_PARERR_MASK BIT(2) > +#define SPIFLG_DESYNC_MASK BIT(3) > +#define SPIFLG_BITERR_MASK BIT(4) > +#define SPIFLG_OVRRUN_MASK BIT(6) > +#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 \ > + | SPIFLG_TIMEOUT_MASK | SPIFLG_PARERR_MASK \ > + | SPIFLG_DESYNC_MASK | SPIFLG_BITERR_MASK \ > + | SPIFLG_OVRRUN_MASK | SPIFLG_RX_INTR_MASK \ > + | SPIFLG_TX_INTR_MASK \ > + | SPIFLG_BUF_INIT_ACTIVE_MASK) > + > +#define SPIINT_DLEN_ERR_INTR BIT(0) > +#define SPIINT_TIMEOUT_INTR BIT(1) > +#define SPIINT_PARERR_INTR BIT(2) > +#define SPIINT_DESYNC_INTR BIT(3) > +#define SPIINT_BITERR_INTR BIT(4) > +#define SPIINT_OVRRUN_INTR BIT(6) > +#define SPIINT_RX_INTR BIT(8) > +#define SPIINT_TX_INTR BIT(9) > +#define SPIINT_DMA_REQ_EN BIT(16) > +#define SPIINT_ENABLE_HIGHZ BIT(24) > + > +#define SPI_T2CDELAY_SHIFT 16 > +#define SPI_C2TDELAY_SHIFT 24 > + > +/* SPI Controller registers */ > +#define SPIGCR0 0x00 > +#define SPIGCR1 0x04 > +#define SPIINT 0x08 > +#define SPILVL 0x0c > +#define SPIFLG 0x10 > +#define SPIPC0 0x14 > +#define SPIPC1 0x18 > +#define SPIPC2 0x1c > +#define SPIPC3 0x20 > +#define SPIPC4 0x24 > +#define SPIPC5 0x28 > +#define SPIPC6 0x2c > +#define SPIPC7 0x30 > +#define SPIPC8 0x34 > +#define SPIDAT0 0x38 > +#define SPIDAT1 0x3c > +#define SPIBUF 0x40 > +#define SPIEMU 0x44 > +#define SPIDELAY 0x48 > +#define SPIDEF 0x4c > +#define SPIFMT0 0x50 > +#define SPIFMT1 0x54 > +#define SPIFMT2 0x58 > +#define SPIFMT3 0x5c > +#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; > +}; > + > +/* We have 2 DMA channels per CS, one for RX and one for TX */ > +struct davinci_spi_dma { > + int dma_tx_channel; > + int dma_rx_channel; > + int dma_tx_sync_dev; > + int dma_rx_sync_dev; > + enum dma_event_q eventq; > + > + struct completion dma_tx_completion; > + struct completion dma_rx_completion; > +}; > + > +/* SPI Controller driver's private data. */ > +struct davinci_spi { > + struct spi_bitbang bitbang; > + struct clk *clk; > + > + u8 version; > + resource_size_t pbase; > + void __iomem *base; > + size_t region_size; > + u32 irq; > + struct completion done; > + > + const void *tx; > + void *rx; > + u8 *tmp_buf; > + int count; > + 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.0.4 > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source From khilman at deeprootsystems.com Tue Jan 5 17:46:38 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 15:46:38 -0800 Subject: [PATCH v2] SPI DaVinci: SPI master driver for DaVinci/DA8xx In-Reply-To: <1261000938-1897-1-git-send-email-s-paulraj@ti.com> (s-paulraj@ti.com's message of "Wed\, 16 Dec 2009 17\:02\:18 -0500") References: <1261000938-1897-1-git-send-email-s-paulraj@ti.com> Message-ID: <878wccqfmp.fsf@deeprootsystems.com> s-paulraj at ti.com writes: > From: Sandeep Paulraj > > This patch adds support for a SPI master driver for the > DaVinci series of SOCs > > Signed-off-by: Sandeep Paulraj > Signed-off-by: Mark A. Greer > Signed-off-by: Philby John > Signed-off-by: Sudhakar Rajashekhara Sandeep, This needs a minor refresh against current Linus tree for the Makefile change. While doing the Makefile addition, it looks like the list is maintained in alphabetical order. Please add davinci in the right order, and feel free to add my signoff. Thanks, Kevin > --- > drivers/spi/Kconfig | 7 + > drivers/spi/Makefile | 1 + > drivers/spi/davinci_spi.c | 1109 +++++++++++++++++++++++++++++++++++++++++++++ > drivers/spi/davinci_spi.h | 171 +++++++ > 4 files changed, 1288 insertions(+), 0 deletions(-) > create mode 100644 drivers/spi/davinci_spi.c > create mode 100644 drivers/spi/davinci_spi.h > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > index 4b6f7cb..28d2fae 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -77,6 +77,13 @@ config SPI_AU1550 > This driver can also be built as a module. If so, the module > will be called au1550_spi. > > +config SPI_DAVINCI > + tristate "SPI controller driver for DaVinci/DA8xx SoC's" > + depends on SPI_MASTER && ARCH_DAVINCI > + select SPI_BITBANG > + help > + SPI master controller for DaVinci and DA8xx SPI modules. > + > config SPI_BITBANG > tristate "Utilities for Bitbanging SPI masters" > help > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > index 21a1182..11f995d 100644 > --- a/drivers/spi/Makefile > +++ b/drivers/spi/Makefile > @@ -33,6 +33,7 @@ obj-$(CONFIG_SPI_TXX9) += spi_txx9.o > obj-$(CONFIG_SPI_XILINX) += xilinx_spi.o > obj-$(CONFIG_SPI_SH_SCI) += spi_sh_sci.o > obj-$(CONFIG_SPI_STMP3XXX) += spi_stmp.o > +obj-$(CONFIG_SPI_DAVINCI) += davinci_spi.o > # ... add above this line ... > > # SPI protocol drivers (device/link on bus) > diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c > new file mode 100644 > index 0000000..c62721a > --- /dev/null > +++ b/drivers/spi/davinci_spi.c > @@ -0,0 +1,1109 @@ > +/* > + * Copyright (C) 2009 Texas Instruments. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; 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 "davinci_spi.h" > + > +#define SPI_NO_RESOURCE ((resource_size_t)-1) > + > +static unsigned use_dma; > + > +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; > +} > + > +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; > +} > + > +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; > + 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; > + return data; > +} > + > +static inline void set_io_bits(void __iomem *addr, u32 bits) > +{ > + u32 v = ioread32(addr); > + > + v |= bits; > + iowrite32(v, addr); > +} > + > +static inline void clear_io_bits(void __iomem *addr, u32 bits) > +{ > + u32 v = ioread32(addr); > + > + v &= ~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 > + */ > +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; > + > + 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); > + > + while ((ioread32(davinci_spi->base + SPIBUF) > + & SPIBUF_RXEMPTY_MASK) == 0) > + cpu_relax(); > + } > +} > + > +/* > + * davinci_spi_setup_transfer - This functions will determine transfer method > + * @spi: spi device on which data transfer to be done > + * @t: spi transfer in which transfer info is filled > + * > + * This function determines data transfer method (8/16/32 bit transfer). > + * It will also set the SPI Clock Control register according to > + * SPI slave device freq. > + */ > +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; > + > + davinci_spi = spi_master_get_devdata(spi->master); > + pdata = davinci_spi->pdata; > + > + if (t) { > + bits_per_word = t->bits_per_word; > + hz = t->speed_hz; > + } > + > + /* if bits_per_word is not set then set it default */ > + if (!bits_per_word) > + bits_per_word = spi->bits_per_word; > + > + /* > + * Assign function pointer to appropriate transfer method > + * 8bit, 16bit or 32bit transfer > + */ > + 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; > + } 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; > + } 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 = ((clk_get_rate(davinci_spi->clk) / hz) - 1) & 0xff; > + > + clear_fmt_bits(davinci_spi->base, 0x0000ff00, spi->chip_select); > + set_fmt_bits(davinci_spi->base, prescale << 8, spi->chip_select); > + > + 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_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]); > + 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); > + > + complete(&davinci_spi_dma->dma_rx_completion); > + /* We must disable the DMA RX request */ > + davinci_spi_set_dma_req(spi, 0); > +} > + > +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_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]); > + 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); > +} > + > +static int davinci_spi_request_dma(struct spi_device *spi) > +{ > + struct davinci_spi *davinci_spi; > + struct davinci_spi_dma *davinci_spi_dma; > + struct davinci_spi_platform_data *pdata; > + struct device *sdev; > + int r; > + > + davinci_spi = spi_master_get_devdata(spi->master); > + davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select]; > + 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->eventq); > + if (r < 0) { > + dev_dbg(sdev, "Unable to request DMA channel for SPI RX\n"); > + return -EAGAIN; > + } > + 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->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 SPI TX\n"); > + return -EAGAIN; > + } > + davinci_spi_dma->dma_tx_channel = r; > + > + return 0; > +} > + > +/* > + * davinci_spi_setup - This functions will set default transfer method > + * @spi: spi device on which data transfer to be done > + * > + * This functions sets the default transfer method. > + */ > + > +static int davinci_spi_setup(struct spi_device *spi) > +{ > + int retval; > + struct davinci_spi *davinci_spi; > + struct davinci_spi_dma *davinci_spi_dma; > + struct device *sdev; > + > + davinci_spi = spi_master_get_devdata(spi->master); > + sdev = davinci_spi->bitbang.master->dev.parent; > + > + /* 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 ((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) { > + dev_dbg(sdev, "Operating frequency is not in acceptable " > + "range\n"); > + 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_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); > + > + /* > + * 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) > + */ > + > + 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); > + > + return retval; > +} > + > +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; > + > + 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; > + > + iowrite32(op_mode, davinci_spi->base + SPIPC0); > + > + 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 int davinci_spi_check_error(struct davinci_spi *davinci_spi, > + int int_status) > +{ > + struct device *sdev = davinci_spi->bitbang.master->dev.parent; > + > + if (int_status & SPIFLG_TIMEOUT_MASK) { > + dev_dbg(sdev, "SPI Time-out Error\n"); > + return -ETIMEDOUT; > + } > + if (int_status & SPIFLG_DESYNC_MASK) { > + dev_dbg(sdev, "SPI Desynchronization Error\n"); > + return -EIO; > + } > + if (int_status & SPIFLG_BITERR_MASK) { > + dev_dbg(sdev, "SPI Bit error\n"); > + return -EIO; > + } > + > + if (davinci_spi->version == SPI_VERSION_2) { > + if (int_status & SPIFLG_DLEN_ERR_MASK) { > + dev_dbg(sdev, "SPI Data Length Error\n"); > + return -EIO; > + } > + if (int_status & SPIFLG_PARERR_MASK) { > + dev_dbg(sdev, "SPI Parity Error\n"); > + return -EIO; > + } > + if (int_status & SPIFLG_OVRRUN_MASK) { > + dev_dbg(sdev, "SPI Data Overrun error\n"); > + return -EIO; > + } > + if (int_status & SPIFLG_TX_INTR_MASK) { > + dev_dbg(sdev, "SPI TX intr bit set\n"); > + return -EIO; > + } > + if (int_status & SPIFLG_BUF_INIT_ACTIVE_MASK) { > + dev_dbg(sdev, "SPI Buffer Init Active\n"); > + return -EBUSY; > + } > + } > + > + return 0; > +} > + > +/* > + * 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 > + * > + * 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_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 based 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) > +{ > + struct davinci_spi *davinci_spi; > + int int_status = 0; > + int count, temp_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 device *sdev; > + > + davinci_spi = spi_master_get_devdata(spi->master); > + pdata = davinci_spi->pdata; > + sdev = davinci_spi->bitbang.master->dev.parent; > + > + 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; > + > + davinci_spi->tx = t->tx_buf; > + davinci_spi->rx = t->rx_buf; > + > + /* 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; > + > + 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 -EINVAL; > + > + 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; > + > + /* CS 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) { > + 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, "Unable to DMA map a %d bytes" > + " TX buffer\n", count); > + return -ENOMEM; > + } > + temp_count = count; > + } 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, "Unable to DMA map a %d bytes" > + " TX tmp buffer\n", count); > + return -ENOMEM; > + } > + temp_count = count + 1; > + } > + > + edma_set_transfer_params(davinci_spi_dma->dma_tx_channel, > + data_type, temp_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); > + > + if (t->rx_buf) { > + /* 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 -ENOMEM; > + } > + 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) || (t->rx_buf)) > + edma_start(davinci_spi_dma->dma_tx_channel); > + > + if (t->rx_buf) > + edma_start(davinci_spi_dma->dma_rx_channel); > + > + if ((t->rx_buf) || (t->tx_buf)) > + davinci_spi_set_dma_req(spi, 1); > + > + if (t->tx_buf) > + wait_for_completion_interruptible( > + &davinci_spi_dma->dma_tx_completion); > + > + if (t->rx_buf) > + wait_for_completion_interruptible( > + &davinci_spi_dma->dma_rx_completion); > + > + dma_unmap_single(NULL, t->tx_dma, temp_count, DMA_TO_DEVICE); > + > + if (t->rx_buf) > + 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; > + > + return t->len; > +} > + > +/* > + * davinci_spi_irq - IRQ handler for DaVinci SPI > + * @irq: IRQ number for this SPI Master > + * @context_data: structure for SPI Master controller davinci_spi > + */ > +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 = ioread32(davinci_spi->base + SPIFLG); > + > + while ((int_status & SPIFLG_RX_INTR_MASK)) { > + if (likely(int_status & SPIFLG_RX_INTR_MASK)) { > + ret = IRQ_HANDLED; > + > + 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; > +} > + > +/* > + * davinci_spi_probe - probe function for SPI Master Controller > + * pdev: platform_device structure which contains plateform specific data > + */ > +static int davinci_spi_probe(struct platform_device *pdev) > +{ > + struct spi_master *master; > + struct davinci_spi *davinci_spi; > + struct davinci_spi_platform_data *pdata; > + struct resource *r, *mem; > + resource_size_t dma_rx_chan = SPI_NO_RESOURCE; > + resource_size_t dma_tx_chan = SPI_NO_RESOURCE; > + resource_size_t dma_eventq = SPI_NO_RESOURCE; > + int i = 0, ret = 0; > + > + pdata = pdev->dev.platform_data; > + if (pdata == NULL) { > + ret = -ENODEV; > + goto err; > + } > + > + master = spi_alloc_master(&pdev->dev, sizeof(struct davinci_spi)); > + if (master == NULL) { > + ret = -ENOMEM; > + goto err; > + } > + > + dev_set_drvdata(&pdev->dev, master); > + > + davinci_spi = spi_master_get_devdata(master); > + if (davinci_spi == NULL) { > + ret = -ENOENT; > + goto free_master; > + } > + > + r = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + if (r == NULL) { > + ret = -ENOENT; > + goto free_master; > + } > + > + davinci_spi->pbase = r->start; > + davinci_spi->region_size = resource_size(r); > + davinci_spi->pdata = pdata; > + > + mem = request_mem_region(r->start, davinci_spi->region_size, > + pdev->name); > + if (mem == NULL) { > + ret = -EBUSY; > + goto free_master; > + } > + > + davinci_spi->base = (struct davinci_spi_reg __iomem *) > + ioremap(r->start, davinci_spi->region_size); > + if (davinci_spi->base == NULL) { > + ret = -ENOMEM; > + goto release_region; > + } > + > + davinci_spi->irq = platform_get_irq(pdev, 0); > + if (davinci_spi->irq <= 0) { > + ret = -EINVAL; > + goto unmap_io; > + } > + > + ret = request_irq(davinci_spi->irq, davinci_spi_irq, IRQF_DISABLED, > + dev_name(&pdev->dev), davinci_spi); > + if (ret) > + goto unmap_io; > + > + /* Allocate tmp_buf for tx_buf */ > + davinci_spi->tmp_buf = kzalloc(SPI_BUFSIZ, GFP_KERNEL); > + if (davinci_spi->tmp_buf == NULL) { > + ret = -ENOMEM; > + goto irq_free; > + } > + > + davinci_spi->bitbang.master = spi_master_get(master); > + if (davinci_spi->bitbang.master == NULL) { > + ret = -ENODEV; > + goto free_tmp_buf; > + } > + > + davinci_spi->clk = clk_get(&pdev->dev, NULL); > + if (IS_ERR(davinci_spi->clk)) { > + ret = -ENODEV; > + goto put_master; > + } > + clk_enable(davinci_spi->clk); > + > + > + master->bus_num = pdev->id; > + master->num_chipselect = pdata->num_chipselect; > + master->setup = davinci_spi_setup; > + master->cleanup = davinci_spi_cleanup; > + > + davinci_spi->bitbang.chipselect = davinci_spi_chipselect; > + davinci_spi->bitbang.setup_transfer = davinci_spi_setup_transfer; > + > + 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) { > + r = platform_get_resource(pdev, IORESOURCE_DMA, 0); > + if (r) > + dma_rx_chan = r->start; > + r = platform_get_resource(pdev, IORESOURCE_DMA, 1); > + if (r) > + dma_tx_chan = r->start; > + r = platform_get_resource(pdev, IORESOURCE_DMA, 2); > + if (r) > + dma_eventq = r->start; > + } > + > + if (!use_dma || > + dma_rx_chan == SPI_NO_RESOURCE || > + dma_tx_chan == SPI_NO_RESOURCE || > + dma_eventq == 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); > + } > + > + davinci_spi->get_rx = davinci_spi_rx_buf_u8; > + davinci_spi->get_tx = davinci_spi_tx_buf_u8; > + > + init_completion(&davinci_spi->done); > + > + /* Reset In/OUT SPI module */ > + iowrite32(0, davinci_spi->base + SPIGCR0); > + 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); > + > + /* master mode default */ > + set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_MASTER_MASK); > + > + if (davinci_spi->pdata->intr_level) > + iowrite32(SPI_INTLVL_1, davinci_spi->base + SPILVL); > + else > + iowrite32(SPI_INTLVL_0, davinci_spi->base + SPILVL); > + > + ret = spi_bitbang_start(&davinci_spi->bitbang); > + if (ret) > + goto free_clk; > + > + 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: > + clk_disable(davinci_spi->clk); > + clk_put(davinci_spi->clk); > +put_master: > + spi_master_put(master); > +free_tmp_buf: > + kfree(davinci_spi->tmp_buf); > +irq_free: > + free_irq(davinci_spi->irq, davinci_spi); > +unmap_io: > + iounmap(davinci_spi->base); > +release_region: > + release_mem_region(davinci_spi->pbase, davinci_spi->region_size); > +free_master: > + kfree(master); > +err: > + return ret; > +} > + > +/* > + * davinci_spi_remove - remove function for SPI Master Controller > + * @pdev: platform_device structure which contains plateform specific data > + * > + * This function will do the reverse action of davinci_spi_probe function > + * It will free the IRQ and SPI controller's memory region. > + * It will also call spi_bitbang_stop to destroy the work queue which was > + * created by spi_bitbang_start. > + */ > +static int __exit davinci_spi_remove(struct platform_device *pdev) > +{ > + struct davinci_spi *davinci_spi; > + struct spi_master *master; > + > + master = dev_get_drvdata(&pdev->dev); > + davinci_spi = spi_master_get_devdata(master); > + > + spi_bitbang_stop(&davinci_spi->bitbang); > + > + clk_disable(davinci_spi->clk); > + clk_put(davinci_spi->clk); > + spi_master_put(master); > + kfree(davinci_spi->tmp_buf); > + free_irq(davinci_spi->irq, davinci_spi); > + iounmap(davinci_spi->base); > + release_mem_region(davinci_spi->pbase, davinci_spi->region_size); > + > + return 0; > +} > + > +static struct platform_driver davinci_spi_driver = { > + .driver.name = "spi_davinci", > + .remove = __exit_p(davinci_spi_remove), > +}; > + > +static int __init davinci_spi_init(void) > +{ > + return platform_driver_probe(&davinci_spi_driver, davinci_spi_probe); > +} > + > +static void __exit davinci_spi_exit(void) > +{ > + platform_driver_unregister(&davinci_spi_driver); > +} > + > +module_init(davinci_spi_init); > +module_exit(davinci_spi_exit); > + > +MODULE_DESCRIPTION("TI DaVinci SPI Master Controller Driver"); > +MODULE_LICENSE("GPL"); > diff --git a/drivers/spi/davinci_spi.h b/drivers/spi/davinci_spi.h > new file mode 100644 > index 0000000..98508c2 > --- /dev/null > +++ b/drivers/spi/davinci_spi.h > @@ -0,0 +1,171 @@ > +/* > + * Copyright (C) 2009 Texas Instruments. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; 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_SPI_H > +#define __DAVINCI_SPI_H > + > +#define SPI_MAX_CHIPSELECT 2 > + > +#define CS_DEFAULT 0xFF > + > +#define SPI_BUFSIZ (SMP_CACHE_BYTES + 1) > +#define DAVINCI_DMA_DATA_TYPE_S8 0x01 > +#define DAVINCI_DMA_DATA_TYPE_S16 0x02 > +#define DAVINCI_DMA_DATA_TYPE_S32 0x04 > + > +#define SPIFMT_PHASE_MASK BIT(16) > +#define SPIFMT_POLARITY_MASK BIT(17) > +#define SPIFMT_DISTIMER_MASK BIT(18) > +#define SPIFMT_SHIFTDIR_MASK BIT(20) > +#define SPIFMT_WAITENA_MASK BIT(21) > +#define SPIFMT_PARITYENA_MASK BIT(22) > +#define SPIFMT_ODD_PARITY_MASK BIT(23) > +#define SPIFMT_WDELAY_MASK 0x3f000000u > +#define SPIFMT_WDELAY_SHIFT 24 > +#define SPIFMT_CHARLEN_MASK 0x0000001Fu > + > +/* SPIGCR1 */ > +#define SPIGCR1_SPIENA_MASK 0x01000000u > + > +/* SPIPC0 */ > +#define SPIPC0_DIFUN_MASK BIT(11) /* MISO */ > +#define SPIPC0_DOFUN_MASK BIT(10) /* MOSI */ > +#define SPIPC0_CLKFUN_MASK BIT(9) /* CLK */ > +#define SPIPC0_SPIENA_MASK BIT(8) /* nREADY */ > +#define SPIPC0_EN1FUN_MASK BIT(1) > +#define SPIPC0_EN0FUN_MASK BIT(0) > + > +#define SPIINT_MASKALL 0x0101035F > +#define SPI_INTLVL_1 0x000001FFu > +#define SPI_INTLVL_0 0x00000000u > + > +/* SPIDAT1 */ > +#define SPIDAT1_CSHOLD_SHIFT 28 > +#define SPIDAT1_CSNR_SHIFT 16 > +#define SPIGCR1_CLKMOD_MASK BIT(1) > +#define SPIGCR1_MASTER_MASK BIT(0) > +#define SPIGCR1_LOOPBACK_MASK BIT(16) > + > +/* SPIBUF */ > +#define SPIBUF_TXFULL_MASK BIT(29) > +#define SPIBUF_RXEMPTY_MASK BIT(31) > + > +/* Error Masks */ > +#define SPIFLG_DLEN_ERR_MASK BIT(0) > +#define SPIFLG_TIMEOUT_MASK BIT(1) > +#define SPIFLG_PARERR_MASK BIT(2) > +#define SPIFLG_DESYNC_MASK BIT(3) > +#define SPIFLG_BITERR_MASK BIT(4) > +#define SPIFLG_OVRRUN_MASK BIT(6) > +#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 \ > + | SPIFLG_TIMEOUT_MASK | SPIFLG_PARERR_MASK \ > + | SPIFLG_DESYNC_MASK | SPIFLG_BITERR_MASK \ > + | SPIFLG_OVRRUN_MASK | SPIFLG_RX_INTR_MASK \ > + | SPIFLG_TX_INTR_MASK \ > + | SPIFLG_BUF_INIT_ACTIVE_MASK) > + > +#define SPIINT_DLEN_ERR_INTR BIT(0) > +#define SPIINT_TIMEOUT_INTR BIT(1) > +#define SPIINT_PARERR_INTR BIT(2) > +#define SPIINT_DESYNC_INTR BIT(3) > +#define SPIINT_BITERR_INTR BIT(4) > +#define SPIINT_OVRRUN_INTR BIT(6) > +#define SPIINT_RX_INTR BIT(8) > +#define SPIINT_TX_INTR BIT(9) > +#define SPIINT_DMA_REQ_EN BIT(16) > +#define SPIINT_ENABLE_HIGHZ BIT(24) > + > +#define SPI_T2CDELAY_SHIFT 16 > +#define SPI_C2TDELAY_SHIFT 24 > + > +/* SPI Controller registers */ > +#define SPIGCR0 0x00 > +#define SPIGCR1 0x04 > +#define SPIINT 0x08 > +#define SPILVL 0x0c > +#define SPIFLG 0x10 > +#define SPIPC0 0x14 > +#define SPIPC1 0x18 > +#define SPIPC2 0x1c > +#define SPIPC3 0x20 > +#define SPIPC4 0x24 > +#define SPIPC5 0x28 > +#define SPIPC6 0x2c > +#define SPIPC7 0x30 > +#define SPIPC8 0x34 > +#define SPIDAT0 0x38 > +#define SPIDAT1 0x3c > +#define SPIBUF 0x40 > +#define SPIEMU 0x44 > +#define SPIDELAY 0x48 > +#define SPIDEF 0x4c > +#define SPIFMT0 0x50 > +#define SPIFMT1 0x54 > +#define SPIFMT2 0x58 > +#define SPIFMT3 0x5c > +#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; > +}; > + > +/* We have 2 DMA channels per CS, one for RX and one for TX */ > +struct davinci_spi_dma { > + int dma_tx_channel; > + int dma_rx_channel; > + int dma_tx_sync_dev; > + int dma_rx_sync_dev; > + enum dma_event_q eventq; > + > + struct completion dma_tx_completion; > + struct completion dma_rx_completion; > +}; > + > +/* SPI Controller driver's private data. */ > +struct davinci_spi { > + struct spi_bitbang bitbang; > + struct clk *clk; > + > + u8 version; > + resource_size_t pbase; > + void __iomem *base; > + size_t region_size; > + u32 irq; > + struct completion done; > + > + const void *tx; > + void *rx; > + u8 *tmp_buf; > + int count; > + 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.0.4 > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source From khilman at deeprootsystems.com Tue Jan 5 17:53:53 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 15:53:53 -0800 Subject: [PATCH 2/2] davinci: MMC: updates to suspend/resume implementation In-Reply-To: <4fb5db50912180303w2052bce8q76c04782d9cd355e@mail.gmail.com> (Janakiram Sistla's message of "Fri\, 18 Dec 2009 16\:33\:35 +0530") References: <1261052101-14409-1-git-send-email-chaithrika@ti.com> <4fb5db50912180303w2052bce8q76c04782d9cd355e@mail.gmail.com> Message-ID: <87y6kcp0q6.fsf@deeprootsystems.com> Janakiram Sistla writes: > On 12/17/09, Chaithrika U S wrote: >> Improve the suspend and resume callbacks in DaVinci MMC >> host controller driver. > > [Ram] I came cross in the mailing some days back that "direct" > .suspend and .resume calls will stop being supported.Is This > true??This patch does require a migration then again. Yes, this patch (or an additional patch) will have to update the MMC driver to use dev_pm_ops. See this commit in Linus' tree where I converted the smc91x driver. Something like this will nee dto be done for this driver as well. Kevin commit 9f950f72e57fe4bf9b16ace67e4cc5ffcee79d00 Author: Kevin Hilman Date: Tue Nov 24 12:57:47 2009 +0000 NET: smc91x: convert to dev_pm_ops Convert smc91x driver from legacy PM hooks over to using dev_pm_ops. Tested on OMAP3 platform. Signed-off-by: Kevin Hilman Acked-by: Nicolas Pitre Signed-off-by: David S. Miller >> Tested on DA850/OMAP-L138 EVM. This testing requires patches >> which add suspend-to-RAM support to DA850/OMAP-L138 SoC[1]. >> >> [1]http://linux.davincidsp.com/pipermail/davinci-linux-open-source/ >> 2009-September/016118.html >> >> Signed-off-by: Chaithrika U S >> --- >> Applies to Linus' kernel tree. >> >> drivers/mmc/host/davinci_mmc.c | 31 +++++++++++++++++++++++++++++-- >> 1 files changed, 29 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c >> index 25645bf..7d05cc1 100644 >> --- a/drivers/mmc/host/davinci_mmc.c >> +++ b/drivers/mmc/host/davinci_mmc.c >> @@ -170,6 +170,7 @@ struct mmc_davinci_host { >> #define DAVINCI_MMC_DATADIR_READ 1 >> #define DAVINCI_MMC_DATADIR_WRITE 2 >> unsigned char data_dir; >> + unsigned char suspended; >> >> /* buffer is used during PIO of one scatterlist segment, and >> * is updated along with buffer_bytes_left. bytes_left applies >> @@ -1300,15 +1301,41 @@ static int __exit davinci_mmcsd_remove(struct platform_device *pdev) >> static int davinci_mmcsd_suspend(struct platform_device *pdev, pm_message_t msg) >> { >> struct mmc_davinci_host *host = platform_get_drvdata(pdev); >> + int ret; >> >> - return mmc_suspend_host(host->mmc, msg); >> + mmc_host_enable(host->mmc); >> + ret = mmc_suspend_host(host->mmc, msg); >> + if (!ret) { >> + writel(0, host->base + DAVINCI_MMCIM); >> + mmc_davinci_reset_ctrl(host, 1); >> + mmc_host_disable(host->mmc); >> + clk_disable(host->clk); >> + host->suspended = 1; >> + } else { >> + host->suspended = 0; >> + mmc_host_disable(host->mmc); >> + } >> + >> + return ret; >> } >> >> static int davinci_mmcsd_resume(struct platform_device *pdev) >> { >> struct mmc_davinci_host *host = platform_get_drvdata(pdev); >> + int ret; >> >> - return mmc_resume_host(host->mmc); >> + if (!host->suspended) >> + return 0; >> + >> + clk_enable(host->clk); >> + mmc_host_enable(host->mmc); >> + >> + mmc_davinci_reset_ctrl(host, 0); >> + ret = mmc_resume_host(host->mmc); >> + if (!ret) >> + host->suspended = 0; >> + >> + return ret; >> } >> #else >> #define davinci_mmcsd_suspend NULL >> -- >> 1.5.6 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majordomo at vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ >> From khilman at deeprootsystems.com Tue Jan 5 17:55:23 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 15:55:23 -0800 Subject: [PATCH 1/2] davinci: MMC: Add a function to control reset state of the controller In-Reply-To: <1261052091-14379-1-git-send-email-chaithrika@ti.com> (Chaithrika U. S.'s message of "Thu\, 17 Dec 2009 17\:44\:51 +0530") References: <1261052091-14379-1-git-send-email-chaithrika@ti.com> Message-ID: <87tyv0p0no.fsf@deeprootsystems.com> Chaithrika U S writes: > Add a helper function which will aid in changing the reset > status of the controller. > > Signed-off-by: Chaithrika U S Signed-off-by: Kevin Hilman > --- > Applies to Linus' kernel tree. > > drivers/mmc/host/davinci_mmc.c | 37 ++++++++++++++++--------------------- > 1 files changed, 16 insertions(+), 21 deletions(-) > > diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c > index dd45e7c..25645bf 100644 > --- a/drivers/mmc/host/davinci_mmc.c > +++ b/drivers/mmc/host/davinci_mmc.c > @@ -884,19 +884,26 @@ static void mmc_davinci_cmd_done(struct mmc_davinci_host *host, > } > } > > -static void > -davinci_abort_data(struct mmc_davinci_host *host, struct mmc_data *data) > +static inline void mmc_davinci_reset_ctrl(struct mmc_davinci_host *host, > + int val) > { > u32 temp; > > - /* reset command and data state machines */ > temp = readl(host->base + DAVINCI_MMCCTL); > - writel(temp | MMCCTL_CMDRST | MMCCTL_DATRST, > - host->base + DAVINCI_MMCCTL); > + if (val) /* reset */ > + temp |= MMCCTL_CMDRST | MMCCTL_DATRST; > + else /* enable */ > + temp &= ~(MMCCTL_CMDRST | MMCCTL_DATRST); > > - temp &= ~(MMCCTL_CMDRST | MMCCTL_DATRST); > - udelay(10); > writel(temp, host->base + DAVINCI_MMCCTL); > + udelay(10); > +} > + > +static void > +davinci_abort_data(struct mmc_davinci_host *host, struct mmc_data *data) > +{ > + mmc_davinci_reset_ctrl(host, 1); > + mmc_davinci_reset_ctrl(host, 0); > } > > static irqreturn_t mmc_davinci_irq(int irq, void *dev_id) > @@ -1100,15 +1107,8 @@ static inline void mmc_davinci_cpufreq_deregister(struct mmc_davinci_host *host) > #endif > static void __init init_mmcsd_host(struct mmc_davinci_host *host) > { > - /* DAT line portion is diabled and in reset state */ > - writel(readl(host->base + DAVINCI_MMCCTL) | MMCCTL_DATRST, > - host->base + DAVINCI_MMCCTL); > - > - /* CMD line portion is diabled and in reset state */ > - writel(readl(host->base + DAVINCI_MMCCTL) | MMCCTL_CMDRST, > - host->base + DAVINCI_MMCCTL); > > - udelay(10); > + mmc_davinci_reset_ctrl(host, 1); > > writel(0, host->base + DAVINCI_MMCCLK); > writel(MMCCLK_CLKEN, host->base + DAVINCI_MMCCLK); > @@ -1116,12 +1116,7 @@ static void __init init_mmcsd_host(struct mmc_davinci_host *host) > writel(0x1FFF, host->base + DAVINCI_MMCTOR); > writel(0xFFFF, host->base + DAVINCI_MMCTOD); > > - writel(readl(host->base + DAVINCI_MMCCTL) & ~MMCCTL_DATRST, > - host->base + DAVINCI_MMCCTL); > - writel(readl(host->base + DAVINCI_MMCCTL) & ~MMCCTL_CMDRST, > - host->base + DAVINCI_MMCCTL); > - > - udelay(10); > + mmc_davinci_reset_ctrl(host, 0); > } > > static int __init davinci_mmcsd_probe(struct platform_device *pdev) > -- > 1.5.6 From khilman at deeprootsystems.com Tue Jan 5 18:04:39 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 16:04:39 -0800 Subject: [PATCH] davinci: MMC: Adding support for 8bit MMC cards In-Reply-To: <4B3B32B1.4010900@ru.mvista.com> (Sergei Shtylyov's message of "Wed\, 30 Dec 2009 14\:00\:01 +0300") References: <1262001865-4373-1-git-send-email-vipin.bhandari@ti.com> <4B3B32B1.4010900@ru.mvista.com> Message-ID: <87my0sp088.fsf@deeprootsystems.com> Sergei Shtylyov writes: > Hello. > > Vipin Bhandari wrote: > > [Re-replying to all, as I only replied to Vipin the first time.] > >> This patch adds the support for 8bit MMC cards. The controller >> data width is configurable depending on the wires setting in the >> platform data structure. >> >> MMC 8bit is tested on OMAPL137 and MMC 4bit is tested on OMAPL138 EVM. >> >> Signed-off-by: Vipin Bhandari >> > > This has been done by MV in the internal tree but as you code is > significantly differenet from that one, I'm not asking you about the > missing MV signoffs... > >> diff --git a/drivers/mmc/host/davinci_mmc.c >> b/drivers/mmc/host/davinci_mmc.c >> index dd45e7c..3bd0ba2 100644 >> --- a/drivers/mmc/host/davinci_mmc.c >> +++ b/drivers/mmc/host/davinci_mmc.c >> @@ -73,6 +73,7 @@ >> /* DAVINCI_MMCCTL definitions */ >> #define MMCCTL_DATRST (1 << 0) >> #define MMCCTL_CMDRST (1 << 1) >> +#define MMCCTL_WIDTH_8_BIT (1 << 8) >> #define MMCCTL_WIDTH_4_BIT (1 << 2) >> #define MMCCTL_DATEG_DISABLED (0 << 6) >> #define MMCCTL_DATEG_RISING (1 << 6) >> @@ -791,22 +792,42 @@ static void calculate_clk_divider(struct >> mmc_host *mmc, struct mmc_ios *ios) >> static void mmc_davinci_set_ios(struct mmc_host *mmc, struct >> mmc_ios *ios) >> { >> - unsigned int mmc_pclk = 0; >> struct mmc_davinci_host *host = mmc_priv(mmc); >> - mmc_pclk = host->mmc_input_clk; >> dev_dbg(mmc_dev(host->mmc), >> "clock %dHz busmode %d powermode %d Vdd %04x\n", >> ios->clock, ios->bus_mode, ios->power_mode, >> ios->vdd); >> - if (ios->bus_width == MMC_BUS_WIDTH_4) { >> - dev_dbg(mmc_dev(host->mmc), "Enabling 4 bit mode\n"); >> - writel(readl(host->base + DAVINCI_MMCCTL) | MMCCTL_WIDTH_4_BIT, >> - host->base + DAVINCI_MMCCTL); >> - } else { >> - dev_dbg(mmc_dev(host->mmc), "Disabling 4 bit mode\n"); >> - writel(readl(host->base + DAVINCI_MMCCTL) & ~MMCCTL_WIDTH_4_BIT, >> + >> + switch (ios->bus_width) { >> + case MMC_BUS_WIDTH_8: >> + dev_dbg(mmc_dev(host->mmc), "Enabling 8 bit mode\n"); >> + writel((readl(host->base + DAVINCI_MMCCTL) & >> + ~MMCCTL_WIDTH_4_BIT) | MMCCTL_WIDTH_8_BIT, >> host->base + DAVINCI_MMCCTL); >> + break; >> + case MMC_BUS_WIDTH_4: >> + dev_dbg(mmc_dev(host->mmc), "Enabling 4 bit mode\n"); >> + if (host->version == MMC_CTLR_VERSION_2) >> + writel((readl(host->base + DAVINCI_MMCCTL) & >> + ~MMCCTL_WIDTH_8_BIT) | MMCCTL_WIDTH_4_BIT, >> + host->base + DAVINCI_MMCCTL); >> + else >> + writel(readl(host->base + DAVINCI_MMCCTL) | >> + MMCCTL_WIDTH_4_BIT, >> + host->base + DAVINCI_MMCCTL); >> > > I don't think it makes sense to check for host->version just to not > clear the bit which is reserved for original DaVinci. There's nothing > criminal in clearing a reserved bit, so I'm suggesting that you remove > the check. There's nothing criminal... yet... until some new version of the controller uses that bit for something else. I think it's always best to not touch reserved bits unless there is a good, well tested, reason not to, such as performance etc. Kevin >> + break; >> + case MMC_BUS_WIDTH_1: >> + dev_dbg(mmc_dev(host->mmc), "Enabling 1 bit mode\n"); >> + if (host->version == MMC_CTLR_VERSION_2) >> + writel(readl(host->base + DAVINCI_MMCCTL) & >> + ~(MMCCTL_WIDTH_8_BIT | MMCCTL_WIDTH_4_BIT), >> + host->base + DAVINCI_MMCCTL); >> + else >> + writel(readl(host->base + DAVINCI_MMCCTL) & >> + ~MMCCTL_WIDTH_4_BIT, >> + host->base + DAVINCI_MMCCTL); >> > > Same comment here... > >> + break; >> > > It'll result less code if you read/write the register only once -- > before/after the *switch* statement respectively. > >> } >> calculate_clk_divider(mmc, ios); >> @@ -1189,10 +1210,14 @@ static int __init davinci_mmcsd_probe(struct >> platform_device *pdev) >> /* REVISIT: someday, support IRQ-driven card detection. */ >> mmc->caps |= MMC_CAP_NEEDS_POLL; >> + mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY; >> > > Does this flag have to do with the bus width at all? :-/ > > WBR, Sergei > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From khilman at deeprootsystems.com Tue Jan 5 18:21:11 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 16:21:11 -0800 Subject: [PATCH v2 1/2] Input: Add device_enable handler to DaVinci Keyscan platform data In-Reply-To: <877hsy46o0.fsf@deeprootsystems.com> (Kevin Hilman's message of "Mon\, 07 Dec 2009 17\:05\:03 -0800") References: <1258141434-18351-1-git-send-email-miguel.aguilar@ridgerun.com> <87hbs25n38.fsf@deeprootsystems.com> <20091208004832.GA9495@core.coreip.homeip.net> <877hsy46o0.fsf@deeprootsystems.com> Message-ID: <87aawsozgo.fsf@deeprootsystems.com> Kevin Hilman writes: > Dmitry Torokhov writes: > >> On Mon, Dec 07, 2009 at 04:24:59PM -0800, Kevin Hilman wrote: >>> writes: >>> >>> > From: Miguel Aguilar >>> > >>> > Add a function pointer in the platform data of the DaVinci Keyscan driver >>> > called device_enabled, in order to perform board specific actions when >>> > the device is initialized, like setup the PINMUX configuration. >>> > >>> > Signed-off-by: Miguel Aguilar >>> >>> Signed-off-by: Kevin Hilman >>> >>> Dmitry, >>> >>> Will you be queueing this driver (and this patch) for 2.6.34? I >>> thought you had accepted the original driver, but I don't see it in >>> the master or next branch of your input tree at: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git >> >> The driver is there, commit bc09dcadc1a3da87d58aa70ebc8e9441205be75c on >> 'next' branch (I don't really use master branch). It was committed back >> in October, probably that's why you don't see it? >> >> As far as the patch goes - I got an impression from email sent by >> Steve that there are ways to do automatic PINMUX detection and thus >> this patch was not needed. Is this ture? > > The method Steve was referring to was done for MontaVista > internal/product kernels but was rejected for upstream (by me) because > of the way it was implemented (by tying mux settings to clock > settings.) > >> If not I am stull unsure what happens if you unload the driver. How >> do you restore the old configuration so that the device you took >> over from can start working again? Maybe pinmux should be controlled >> via sysfs attribute (in board code) so that user can switch on-fly >> between the devices? > > The way we currently handle MUXing in davinci, you don't need to do > anything after the driver unloads. Any other user of these pins will > mux them as needed. > > If really necessary, we could do an equivalent 'device_disable' hook > but there would be empty as it wouldn't be needed. > > So, speaking as maintainer of the DaVinci support, I'm in favor of this > approach from Miguel. Dmitry, Unless there are further objectsions, could you please queue this patch for 2.6.34 with my signoff? Thanks, Kevin From khilman at deeprootsystems.com Tue Jan 5 18:31:34 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 16:31:34 -0800 Subject: [PATCH v1] i2c: Davinci i2c bus recovery procedure to come out of time out conditions In-Reply-To: <1258989756.20007.227.camel@localhost.localdomain> (Philby John's message of "Mon\, 23 Nov 2009 20\:52\:36 +0530") References: <1258989756.20007.227.camel@localhost.localdomain> Message-ID: <87r5q4nkex.fsf@deeprootsystems.com> Philby John writes: >>From 062cfba8b86ccd932eaa498980e703295d86a6cb Mon Sep 17 00:00:00 2001 > From: Philby John > Date: Mon, 23 Nov 2009 18:08:33 +0530 > Subject: [PATCH] Davinci i2c bus recovery procedure to come out of time out conditions > > Get out of i2c time out condition by following the > bus recovery procedure outlined in the i2c protocol v3 spec. > The kernel must be robust enough to gracefully recover > from i2c bus failure without having to reset the machine. > This is done by first NACKing the slave, pulsing the SCL > line 9 times and then sending the stop command. > > This patch has been tested on a DM6446 and DM355 How are you testing this? this should also be tested on da8xx by someone. > Signed-off-by: Philby John > > --- > drivers/i2c/busses/i2c-davinci.c | 54 +++++++++++++++++++++++++++++++++---- > 1 files changed, 48 insertions(+), 6 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c > index 67d88cc..6b4a550 100644 > --- a/drivers/i2c/busses/i2c-davinci.c > +++ b/drivers/i2c/busses/i2c-davinci.c > @@ -35,6 +35,7 @@ > #include > #include > #include > +#include > > #include > > @@ -43,6 +44,7 @@ > /* ----- global defines ----------------------------------------------- */ > > #define DAVINCI_I2C_TIMEOUT (1*HZ) > +#define DAVINCI_I2C_MAX_TRIES 2 > #define I2C_DAVINCI_INTR_ALL (DAVINCI_I2C_IMR_AAS | \ > DAVINCI_I2C_IMR_SCD | \ > DAVINCI_I2C_IMR_ARDY | \ > @@ -134,6 +136,38 @@ static inline u16 davinci_i2c_read_reg(struct davinci_i2c_dev *i2c_dev, int reg) > return __raw_readw(i2c_dev->base + reg); > } > > +/* Generate a pulse on the i2c clock pin. */ > +static void pulse_i2c_clock(void) > +{ > + gpio_set_value(14, 0); > + udelay(20); > + gpio_set_value(14, 1); > + udelay(20); > +} > + > +/* This routine does i2c bus recovery as specified in the > + * i2c protocol Rev. 03 section 3.16 titled "Bus clear" > + */ > +static void i2c_recover_bus(struct davinci_i2c_dev *dev) > +{ > + u16 i; > + u32 flag = 0; > + > + dev_err(dev->dev, "initiating i2c bus recovery\n"); This looks like a debug leftover. I doubt you want this since you're calling this function on every xfer. > + /* Send NACK to the slave */ > + flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG); > + flag |= DAVINCI_I2C_MDR_NACK; > + /* write the data into mode register */ > + davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag); > + /* Send high and low on the SCL line */ > + for (i = 0; i < 9; i++) > + pulse_i2c_clock(); > + /* Send STOP */ > + flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG); > + MOD_REG_BIT(flag, DAVINCI_I2C_MDR_STP, 1); This patch will need some updates as this macro is now gone. Kevin > + davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag); > +} > + > /* > * This functions configures I2C and brings I2C out of reset. > * This function is called during I2C init function. This function > @@ -221,19 +255,26 @@ static int i2c_davinci_wait_bus_not_busy(struct davinci_i2c_dev *dev, > char allow_sleep) > { > unsigned long timeout; > + static u16 to_cnt = 0; > > timeout = jiffies + dev->adapter.timeout; > while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG) > - & DAVINCI_I2C_STR_BB) { > - if (time_after(jiffies, timeout)) { > - dev_warn(dev->dev, > - "timeout waiting for bus ready\n"); > - return -ETIMEDOUT; > + & DAVINCI_I2C_STR_BB) { > + if (to_cnt <= DAVINCI_I2C_MAX_TRIES) { > + if (time_after(jiffies, timeout)) { > + dev_warn(dev->dev, > + "timeout waiting for bus ready\n"); > + to_cnt++; > + return -ETIMEDOUT; > + } else { > + to_cnt = 0; > + i2c_recover_bus(dev); > + i2c_davinci_init(dev); > + } > } > if (allow_sleep) > schedule_timeout(1); > } > - > return 0; > } > > @@ -310,6 +351,7 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop) > dev->adapter.timeout); > if (r == 0) { > dev_err(dev->dev, "controller timed out\n"); > + i2c_recover_bus(dev); > i2c_davinci_init(dev); > dev->buf_len = 0; > return -ETIMEDOUT; > -- > 1.6.3.3.MVISTA > > > > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source From khilman at deeprootsystems.com Tue Jan 5 18:46:41 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Tue, 05 Jan 2010 16:46:41 -0800 Subject: [PATCH v2] SPI DaVinci: SPI master driver for DaVinci/DA8xx In-Reply-To: (Grant Likely's message of "Tue\, 5 Jan 2010 17\:41\:42 -0700") References: <1261000938-1897-1-git-send-email-s-paulraj@ti.com> <878wccqfmp.fsf@deeprootsystems.com> Message-ID: <87iqbgnjpq.fsf@deeprootsystems.com> Grant Likely writes: > On Tue, Jan 5, 2010 at 4:46 PM, Kevin Hilman > wrote: >> s-paulraj at ti.com writes: >> >>> From: Sandeep Paulraj >>> >>> This patch adds support for a SPI master driver for the >>> DaVinci series of SOCs >>> >>> Signed-off-by: Sandeep Paulraj >>> Signed-off-by: Mark A. Greer >>> Signed-off-by: Philby John >>> Signed-off-by: Sudhakar Rajashekhara >> >> Sandeep, >> >> This needs a minor refresh against current Linus tree for the Makefile >> change. >> >> While doing the Makefile addition, it looks like the list is maintained in >> alphabetical order. ?Please add davinci in the right order, and feel free to >> add my signoff. > > Signed-of-by lines are only for patches that actually pass through > your hands (ie. you add it yourself when you pick it up and pass it). > It is not appropriate to add a s-o-b line for someone else. > "Acked-by" or "Reviewed-by" should be used instead. Understood. This driver has passed through my hands (and in front of my eyes) in various forms many times in its development, so I figured an s-o-b was appropriate. That being said, for this particular version, and ack is probably more appropriate. Sandeep, after you refresh, please add Acked-by: Kevin Hilman From raghav.moko at gmail.com Tue Jan 5 20:34:29 2010 From: raghav.moko at gmail.com (raghav) Date: Wed, 6 Jan 2010 08:04:29 +0530 Subject: [PATCH] Fixed comments for the response registers. They were all saying Regiser 0 and 1. Message-ID: <1262745269-12102-1-git-send-email-raghav.moko@gmail.com> --- drivers/mmc/host/davinci_mmc.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c index dd45e7c..73a6a14 100644 --- a/drivers/mmc/host/davinci_mmc.c +++ b/drivers/mmc/host/davinci_mmc.c @@ -54,9 +54,9 @@ #define DAVINCI_MMCCMD 0x30 /* Command Register */ #define DAVINCI_MMCARGHL 0x34 /* Argument Register */ #define DAVINCI_MMCRSP01 0x38 /* Response Register 0 and 1 */ -#define DAVINCI_MMCRSP23 0x3C /* Response Register 0 and 1 */ -#define DAVINCI_MMCRSP45 0x40 /* Response Register 0 and 1 */ -#define DAVINCI_MMCRSP67 0x44 /* Response Register 0 and 1 */ +#define DAVINCI_MMCRSP23 0x3C /* Response Register 2 and 3 */ +#define DAVINCI_MMCRSP45 0x40 /* Response Register 4 and 5 */ +#define DAVINCI_MMCRSP67 0x44 /* Response Register 6 and 7 */ #define DAVINCI_MMCDRSP 0x48 /* Data Response Register */ #define DAVINCI_MMCETOK 0x4C #define DAVINCI_MMCCIDX 0x50 /* Command Index Register */ -- 1.6.0.4 From raghav.moko at gmail.com Tue Jan 5 20:36:09 2010 From: raghav.moko at gmail.com (raghav n) Date: Wed, 6 Jan 2010 08:06:09 +0530 Subject: [PATCH] MMC: DaVinci: Fixed typos in comments of the response registers in davinci_mmc.c In-Reply-To: <4B43BD48.9060208@deeprootsystems.com> References: <87hbr0tczg.fsf@deeprootsystems.com> <4B43BD48.9060208@deeprootsystems.com> Message-ID: Hi Kevin, I have tried sending the patch again using git send-email. Hope it should be in a good shape now. Thank you for the patience and the suggestions. -raghav On Wed, Jan 6, 2010 at 3:59 AM, Kevin Hilman wrote: > Kevin Hilman wrote: > >> raghav n writes: >> >> [PATCH 1/1] MMC: DaVinci: Fixed typos in comments of the response >>> registers in davinci_mmc.c >>> >> >> You don't need to duplicate the subject in the changelog. >> >> This patch fixes the typos in the comments for the MMC response >>> registers. They were all /* Response Register 0 and 1 */ >>> >>> Signed-off-by: raghav.moko at gmail.com >>> >> >> Thanks, will que >> >> --- >>> From 08e00d18ca5d0c20a9035c631e7fcb5f39c88cb8 Mon Sep 17 00:00:00 2001 >>> From: raghav >>> >>> Date: Tue, 5 Jan 2010 23:57:17 +0530 >>> Subject: [PATCH] Fixed comments for the response registers. They were all >>> saying Regiser 0 and 1. >>> >> >> You've got duplicate headers/changelog etc. here. >> >> I highly recommend using git-format-patch + git-send-email to send >> patches? >> >> --- >>> drivers/mmc/host/davinci_mmc.c | 6 +++--- >>> 1 files changed, 3 insertions(+), 3 deletions(-) >>> >> >> The patch itself looks fine. After cleaning up the changelog, I'll >> queue for 2.6.33-rc fixes series. >> > > After trying to apply this, the patch is corrupted in other ways and > doesn't apply cleanly. > > Please fix up the patch to apply against current davinci git and resend, > preferably using git-format-patch + git-send-email. > > Kevin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From swami.iyer at ti.com Tue Jan 5 21:13:15 2010 From: swami.iyer at ti.com (Subbrathnam, Swaminathan) Date: Wed, 6 Jan 2010 08:43:15 +0530 Subject: how do i enable full speed instead of high speed in the USB In-Reply-To: <03A2FA9E0D3DC841992E682BF528771801747DA9@lipwig.Cernium.local> References: <03A2FA9E0D3DC841992E682BF528771801747AD2@lipwig.Cernium.local> <03A2FA9E0D3DC841992E682BF528771801747D65@lipwig.Cernium.local> , <03A2FA9E0D3DC841992E682BF528771801747DA9@lipwig.Cernium.local> Message-ID: High Speed is backward compatible with Full Speed mode. So just connect any full speed device when acting as host or connect to a full speed port when acting as device and you should be able to work in full speed. regards swami ________________________________ From: davinci-linux-open-source-bounces at linux.davincidsp.com [davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Gopala Gottumukkala [ggottumu at Cernium.com] Sent: Tuesday, January 05, 2010 9:04 PM To: davinci-linux-open-source at linux.davincidsp.com Subject: how do i enable full speed instead of high speed in the USB I want to use Full speed instead of high speed. What needs to be done to work with full speed. Help appreciated, Thanks - Gopala From: Subbrathnam, Swaminathan [mailto:swami.iyer at ti.com] Sent: Tuesday, January 05, 2010 9:41 AM To: Gopala Gottumukkala; davinci-linux-open-source at linux.davincidsp.com Subject: RE: USB storage error Pl. refer to DaVinci Staging GIT kernel hosted at http://arago-project.org/git/people/?p=sneha/linux-davinci-staging.git;a=summary. ________________________________ From: Gopala Gottumukkala [mailto:ggottumu at Cernium.com] Sent: Tuesday, January 05, 2010 8:06 PM To: Subbrathnam, Swaminathan; davinci-linux-open-source at linux.davincidsp.com Subject: RE: USB storage error Which kernel version number is working for you can I know the kernel version number and if any patches please let me know the patches also. - Gopala From: Gopala Gottumukkala Sent: Monday, January 04, 2010 9:13 AM To: 'Subbrathnam, Swaminathan'; davinci-linux-open-source at linux.davincidsp.com Subject: RE: USB storage error Can I know the latest Davinci Git kernel version which is working for you. The kernel version number and where can I down load the latest one. - Gopala From: Subbrathnam, Swaminathan [mailto:swami.iyer at ti.com] Sent: Friday, January 01, 2010 8:10 AM To: Gopala Gottumukkala; davinci-linux-open-source at linux.davincidsp.com Subject: RE: USB storage error Gopala, Could you try the latest DaVinci Git. It works for me. regards swami ________________________________ From: davinci-linux-open-source-bounces at linux.davincidsp.com [davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Gopala Gottumukkala [ggottumu at Cernium.com] Sent: Friday, January 01, 2010 1:38 AM To: davinci-linux-open-source at linux.davincidsp.com Subject: USB storage error I have compiled davinci 2.6.30 I mounted the usb manually I ran some sample program which will open, write and delete the file into usb drive. While writing the file into usb drive. It gives the following error and the program dies. Any help would be appreciated on this usb 1-1: reset high speed USB device using musb_hdrc and address 2 usb 1-1: reset high speed USB device using musb_hdrc and address 2 usb 1-1: reset high speed USB device using musb_hdrc and address 2 sd 0:0:0:0: Device offlined - not ready after error recovery sd 0:0:0:0: [sda] Unhandled error code sd 0:0:0:0: [sda] Result: hostbyte=0x05 driverbyte=0x00 end_request: I/O error, dev sda, sector 41584 sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: [sda] Unhandled error code sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sda, sector 40000 sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device - Gopala NOTICE: The information contained in this email and any document attached hereto is intended only for the named recipient(s). It is the property of Cernium Corporation and shall not be used, disclosed or reproduced without the express written consent of Cernium Corporation. If you are not the intended recipient (or the employee or agent responsible for delivering this message in confidence to the intended recipient(s)), you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this transmittal or its attachments is strictly prohibited. If you have received this transmittal and/or attachments in error, please notify me immediately by reply email or telephone and immediately delete this message and all its attachments. Thank you. NOTICE: The information contained in this email and any document attached hereto is intended only for the named recipient(s). It is the property of Cernium Corporation and shall not be used, disclosed or reproduced without the express written consent of Cernium Corporation. If you are not the intended recipient (or the employee or agent responsible for delivering this message in confidence to the intended recipient(s)), you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this transmittal or its attachments is strictly prohibited. If you have received this transmittal and/or attachments in error, please notify me immediately by reply email or telephone and immediately delete this message and all its attachments. Thank you. NOTICE: The information contained in this email and any document attached hereto is intended only for the named recipient(s). It is the property of Cernium Corporation and shall not be used, disclosed or reproduced without the express written consent of Cernium Corporation. If you are not the intended recipient (or the employee or agent responsible for delivering this message in confidence to the intended recipient(s)), you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this transmittal or its attachments is strictly prohibited. If you have received this transmittal and/or attachments in error, please notify me immediately by reply email or telephone and immediately delete this message and all its attachments. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaithrika at ti.com Tue Jan 5 22:53:22 2010 From: chaithrika at ti.com (Chaithrika U S) Date: Wed, 6 Jan 2010 10:23:22 +0530 Subject: [PATCH 2/2] davinci: MMC: updates to suspend/resume implementation In-Reply-To: <87y6kcp0q6.fsf@deeprootsystems.com> References: <1261052101-14409-1-git-send-email-chaithrika@ti.com> <4fb5db50912180303w2052bce8q76c04782d9cd355e@mail.gmail.com> <87y6kcp0q6.fsf@deeprootsystems.com> Message-ID: <000001ca8e8c$2c82dda0$858898e0$@com> On Wed, Jan 06, 2010 at 05:23:53, Kevin Hilman wrote: > Janakiram Sistla writes: > > > On 12/17/09, Chaithrika U S wrote: > >> Improve the suspend and resume callbacks in DaVinci MMC > >> host controller driver. > > > > [Ram] I came cross in the mailing some days back that "direct" > > .suspend and .resume calls will stop being supported.Is This > > true??This patch does require a migration then again. > > Yes, this patch (or an additional patch) will have to update the > MMC driver to use dev_pm_ops. > > See this commit in Linus' tree where I converted the smc91x driver. > Something like this will nee dto be done for this driver as well. OK. I will submit an updated version of this patch soon. Regards, Chaithrika > > Kevin > > commit 9f950f72e57fe4bf9b16ace67e4cc5ffcee79d00 > Author: Kevin Hilman > Date: Tue Nov 24 12:57:47 2009 +0000 > > NET: smc91x: convert to dev_pm_ops > > Convert smc91x driver from legacy PM hooks over to using dev_pm_ops. > > Tested on OMAP3 platform. > > Signed-off-by: Kevin Hilman > Acked-by: Nicolas Pitre > Signed-off-by: David S. Miller > > >> Tested on DA850/OMAP-L138 EVM. This testing requires patches > >> which add suspend-to-RAM support to DA850/OMAP-L138 SoC[1]. > >> > >> [1]http://linux.davincidsp.com/pipermail/davinci-linux-open-source/ > >> 2009-September/016118.html > >> > >> Signed-off-by: Chaithrika U S > >> --- > >> Applies to Linus' kernel tree. > >> > >> drivers/mmc/host/davinci_mmc.c | 31 +++++++++++++++++++++++++++++-- > >> 1 files changed, 29 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c > >> index 25645bf..7d05cc1 100644 > >> --- a/drivers/mmc/host/davinci_mmc.c > >> +++ b/drivers/mmc/host/davinci_mmc.c > >> @@ -170,6 +170,7 @@ struct mmc_davinci_host { > >> #define DAVINCI_MMC_DATADIR_READ 1 > >> #define DAVINCI_MMC_DATADIR_WRITE 2 > >> unsigned char data_dir; > >> + unsigned char suspended; > >> > >> /* buffer is used during PIO of one scatterlist segment, and > >> * is updated along with buffer_bytes_left. bytes_left applies > >> @@ -1300,15 +1301,41 @@ static int __exit davinci_mmcsd_remove(struct platform_device *pdev) > >> static int davinci_mmcsd_suspend(struct platform_device *pdev, pm_message_t msg) > >> { > >> struct mmc_davinci_host *host = platform_get_drvdata(pdev); > >> + int ret; > >> > >> - return mmc_suspend_host(host->mmc, msg); > >> + mmc_host_enable(host->mmc); > >> + ret = mmc_suspend_host(host->mmc, msg); > >> + if (!ret) { > >> + writel(0, host->base + DAVINCI_MMCIM); > >> + mmc_davinci_reset_ctrl(host, 1); > >> + mmc_host_disable(host->mmc); > >> + clk_disable(host->clk); > >> + host->suspended = 1; > >> + } else { > >> + host->suspended = 0; > >> + mmc_host_disable(host->mmc); > >> + } > >> + > >> + return ret; > >> } > >> > >> static int davinci_mmcsd_resume(struct platform_device *pdev) > >> { > >> struct mmc_davinci_host *host = platform_get_drvdata(pdev); > >> + int ret; > >> > >> - return mmc_resume_host(host->mmc); > >> + if (!host->suspended) > >> + return 0; > >> + > >> + clk_enable(host->clk); > >> + mmc_host_enable(host->mmc); > >> + > >> + mmc_davinci_reset_ctrl(host, 0); > >> + ret = mmc_resume_host(host->mmc); > >> + if (!ret) > >> + host->suspended = 0; > >> + > >> + return ret; > >> } > >> #else > >> #define davinci_mmcsd_suspend NULL > >> -- > >> 1.5.6 > >> > >> -- > >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > >> the body of a message to majordomo at vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> Please read the FAQ at http://www.tux.org/lkml/ > >> > From chaithrika at ti.com Tue Jan 5 22:56:47 2010 From: chaithrika at ti.com (Chaithrika U S) Date: Wed, 6 Jan 2010 10:26:47 +0530 Subject: [PATCH v2 3/4] i2c: davinci: Add suspend/resume support In-Reply-To: <87vdfgrwib.fsf@deeprootsystems.com> References: <1260267218-19406-1-git-send-email-chaithrika@ti.com> <1260267218-19406-2-git-send-email-chaithrika@ti.com> <1260267218-19406-3-git-send-email-chaithrika@ti.com> <1260267218-19406-4-git-send-email-chaithrika@ti.com> <87vdfgrwib.fsf@deeprootsystems.com> Message-ID: <000101ca8e8c$a6612370$f3236a50$@com> On Wed, Jan 06, 2010 at 04:26:44, Kevin Hilman wrote: > Chaithrika U S writes: > > > Add suspend and resume callbacks to DaVinci I2C driver. > > This has been tested on DA850/OMAP-L138 EVM. The SoC specific > > suspend-to-RAM support patch series [1] is needed to test this feature. > > > > [1] http://linux.davincidsp.com/pipermail/davinci-linux-open-source/ > > 2009-November/016958.html > > > > Signed-off-by: Chaithrika U S > > --- > > drivers/i2c/busses/i2c-davinci.c | 32 ++++++++++++++++++++++++++++++++ > > 1 files changed, 32 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c > > index 81c1049..c1c2909 100644 > > --- a/drivers/i2c/busses/i2c-davinci.c > > +++ b/drivers/i2c/busses/i2c-davinci.c > > @@ -622,6 +622,36 @@ static int davinci_i2c_remove(struct platform_device *pdev) > > return 0; > > } > > > > +#ifdef CONFIG_PM > > +static int davinci_i2c_suspend(struct platform_device *pdev, pm_message_t state) > > +{ > > + struct davinci_i2c_dev *dev = platform_get_drvdata(pdev); > > + > > + /* put I2C into reset */ > > + davinci_i2c_reset_ctrl(dev, 0); > > + > > + clk_disable(dev->clk); > > + > > + return 0; > > +} > > + > > +static int davinci_i2c_resume(struct platform_device *pdev) > > +{ > > + struct davinci_i2c_dev *dev = platform_get_drvdata(pdev); > > + > > + clk_enable(dev->clk); > > + > > + /* take I2C out of reset */ > > + davinci_i2c_reset_ctrl(dev, 1); > > + > > + return 0; > > +} > > + > > +#else > > +#define davinci_i2c_suspend NULL > > +#define davinci_i2c_resume NULL > > +#endif > > + > > /* work with hotplug and coldplug */ > > MODULE_ALIAS("platform:i2c_davinci"); > > > > @@ -632,6 +662,8 @@ static struct platform_driver davinci_i2c_driver = { > > .name = "i2c_davinci", > > .owner = THIS_MODULE, > > }, > > + .suspend = davinci_i2c_suspend, > > + .resume = davinci_i2c_resume, > > Rather than adding these to the platform_driver, you should use dev_pm_ops. > > Something like the patch below on top of your PATCH 3/4 should work. > > Other than this, I'm OK with this series, feel free to add my signoff > and resend to linux-i2c and LKML. linux-i2c has had very slow > response to embedded patches lately. > > Kevin > OK. I will post updated patches soon. Thanks & Regards, Chaithrika From erezk at radvision.com Wed Jan 6 01:26:00 2010 From: erezk at radvision.com (Erez Kinarti) Date: Wed, 6 Jan 2010 09:26:00 +0200 Subject: Cmem address translation when working with Codec Engine In-Reply-To: <6B8224E84039B140AA662F0BB03616430122AF4775@dlee04.ent.ti.com> References: <6B8224E84039B140AA662F0BB03616430122930FB8@dlee04.ent.ti.com><10B9B66481AB544596EF70B519D5899601D52422@rvil-mail1.RADVISION.com><4B4220A7.6090506@nt.tu-darmstadt.de><10B9B66481AB544596EF70B519D5899601D52423@rvil-mail1.RADVISION.com><6B8224E84039B140AA662F0BB03616430122A5A903@dlee04.ent.ti.com><10B9B66481AB544596EF70B519D5899601D5245F@rvil-mail1.RADVISION.com><4B430309.30009@nt.tu-darmstadt.de><10B9B66481AB544596EF70B519D5899601D52460@rvil-mail1.RADVISION.com> <6B8224E84039B140AA662F0BB03616430122AF4775@dlee04.ent.ti.com> Message-ID: <10B9B66481AB544596EF70B519D5899601D524D7@rvil-mail1.RADVISION.com> This is not an odd setup. The buffers are allocated in other place by memory manager, and for decoupling the codec should not be aware of that, it just need to be called with pointers to in/out buffers. Believe me that we have good enough reason not to do the alloc and release from the codec. In addition, the codec is not aware at all to the big buffer, just to the pointers inside it. In bottom line, I understand that I have to take CERuntimeInit/Exit out of the codecs in some way and there is no other way supplied by TI to cope with this problem (like unregister all the virtual addresses in one call without a specific pointer). Am I correct? Thanks, Erez -----Original Message----- From: Tivy, Robert [mailto:rtivy at ti.com] Sent: Wednesday, January 06, 2010 12:52 AM To: Erez Kinarti; Vladimir Pantelic; Davinci-linux-open-source at linux.davincidsp.com Cc: Davinci-linux-open-source at linux.davincidsp.com Subject: RE: Cmem address translation when working with Codec Engine This sounds like an odd setup, how are you even calling the codec if not through CE? Since the first codec is assuming responsibility for doing "first" things, like calling CERuntime_init(), can't it also call Memory_registerContigBuf()? From your earlier descriptions it sounds like you might need a way to inform this first codec of the (big CMEM) buffer size to register, but communicating that info sounds easier than tracking small buffer subdivisions. Regards, - Rob > -----Original Message----- > From: > davinci-linux-open-source-bounces+rtivy=ti.com at linux.davincids > p.com > [mailto:davinci-linux-open-source-bounces+rtivy=ti.com at linux.d > avincidsp.com] On Behalf Of Erez Kinarti > Sent: Tuesday, January 05, 2010 1:26 AM > To: Vladimir Pantelic; Davinci-linux-open-source at linux.davincidsp.com > Cc: Davinci-linux-open-source at linux.davincidsp.com > Subject: RE: Cmem address translation when working with Codec Engine > > No, because in my system, the first codec that is generated > is calling CERuntimeInit (working with C++, keeping reference > counter for the call to CERuntimeInit and CERuntimeExit), > while the system buffers are allocated before that. > > > -----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 Vladimir Pantelic > Sent: Tuesday, January 05, 2010 11:15 AM > To: Davinci-linux-open-source at linux.davincidsp.com > Cc: Davinci-linux-open-source at linux.davincidsp.com > Subject: Re: Cmem address translation when working with Codec Engine > > Erez Kinarti wrote: > > Hey Rob, > > I see that calling the register functions require that CE is in the > air > > (CERuntimeInit) so it is problematic for us in the same way as doing > the > > CMEM allocations via CodecEngine. > > as you have to call CERuntimeInit() before using any of CE, > you can do the > Memory_registerContigBuf() after CERuntimeInit(), no? > > > _______________________________________________ > 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 chaithrika at ti.com Wed Jan 6 03:24:57 2010 From: chaithrika at ti.com (Chaithrika U S) Date: Wed, 6 Jan 2010 14:54:57 +0530 Subject: [PATCH v2 1/4] i2c: davinci: Remove MOD_REG_BIT and IO_ADDRESS usage In-Reply-To: <1262769900-2710-1-git-send-email-chaithrika@ti.com> References: <1262769900-2710-1-git-send-email-chaithrika@ti.com> Message-ID: <1262769900-2710-2-git-send-email-chaithrika@ti.com> Cleanup the DaVinci I2C driver. Remove MOD_REG_BIT macro. Also use ioremap instead of IO_ADDRESS macro. Signed-off-by: Chaithrika U S Signed-off-by: Kevin Hilman --- drivers/i2c/busses/i2c-davinci.c | 77 +++++++++++++++++++------------------- 1 files changed, 38 insertions(+), 39 deletions(-) diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c index c89687a..44a3cb3 100644 --- a/drivers/i2c/busses/i2c-davinci.c +++ b/drivers/i2c/busses/i2c-davinci.c @@ -37,7 +37,6 @@ #include #include - #include /* ----- global defines ----------------------------------------------- */ @@ -71,37 +70,29 @@ #define DAVINCI_I2C_IVR_NACK 0x02 #define DAVINCI_I2C_IVR_AL 0x01 -#define DAVINCI_I2C_STR_BB (1 << 12) -#define DAVINCI_I2C_STR_RSFULL (1 << 11) -#define DAVINCI_I2C_STR_SCD (1 << 5) -#define DAVINCI_I2C_STR_ARDY (1 << 2) -#define DAVINCI_I2C_STR_NACK (1 << 1) -#define DAVINCI_I2C_STR_AL (1 << 0) - -#define DAVINCI_I2C_MDR_NACK (1 << 15) -#define DAVINCI_I2C_MDR_STT (1 << 13) -#define DAVINCI_I2C_MDR_STP (1 << 11) -#define DAVINCI_I2C_MDR_MST (1 << 10) -#define DAVINCI_I2C_MDR_TRX (1 << 9) -#define DAVINCI_I2C_MDR_XA (1 << 8) -#define DAVINCI_I2C_MDR_RM (1 << 7) -#define DAVINCI_I2C_MDR_IRS (1 << 5) - -#define DAVINCI_I2C_IMR_AAS (1 << 6) -#define DAVINCI_I2C_IMR_SCD (1 << 5) -#define DAVINCI_I2C_IMR_XRDY (1 << 4) -#define DAVINCI_I2C_IMR_RRDY (1 << 3) -#define DAVINCI_I2C_IMR_ARDY (1 << 2) -#define DAVINCI_I2C_IMR_NACK (1 << 1) -#define DAVINCI_I2C_IMR_AL (1 << 0) - -#define MOD_REG_BIT(val, mask, set) do { \ - if (set) { \ - val |= mask; \ - } else { \ - val &= ~mask; \ - } \ -} while (0) +#define DAVINCI_I2C_STR_BB BIT(12) +#define DAVINCI_I2C_STR_RSFULL BIT(11) +#define DAVINCI_I2C_STR_SCD BIT(5) +#define DAVINCI_I2C_STR_ARDY BIT(2) +#define DAVINCI_I2C_STR_NACK BIT(1) +#define DAVINCI_I2C_STR_AL BIT(0) + +#define DAVINCI_I2C_MDR_NACK BIT(15) +#define DAVINCI_I2C_MDR_STT BIT(13) +#define DAVINCI_I2C_MDR_STP BIT(11) +#define DAVINCI_I2C_MDR_MST BIT(10) +#define DAVINCI_I2C_MDR_TRX BIT(9) +#define DAVINCI_I2C_MDR_XA BIT(8) +#define DAVINCI_I2C_MDR_RM BIT(7) +#define DAVINCI_I2C_MDR_IRS BIT(5) + +#define DAVINCI_I2C_IMR_AAS BIT(6) +#define DAVINCI_I2C_IMR_SCD BIT(5) +#define DAVINCI_I2C_IMR_XRDY BIT(4) +#define DAVINCI_I2C_IMR_RRDY BIT(3) +#define DAVINCI_I2C_IMR_ARDY BIT(2) +#define DAVINCI_I2C_IMR_NACK BIT(1) +#define DAVINCI_I2C_IMR_AL BIT(0) struct davinci_i2c_dev { struct device *dev; @@ -154,7 +145,7 @@ static int i2c_davinci_init(struct davinci_i2c_dev *dev) /* put I2C into reset */ w = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG); - MOD_REG_BIT(w, DAVINCI_I2C_MDR_IRS, 0); + w &= ~DAVINCI_I2C_MDR_IRS; davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, w); /* NOTE: I2C Clock divider programming info @@ -204,7 +195,7 @@ static int i2c_davinci_init(struct davinci_i2c_dev *dev) /* Take the I2C module out of reset: */ w = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG); - MOD_REG_BIT(w, DAVINCI_I2C_MDR_IRS, 1); + w |= DAVINCI_I2C_MDR_IRS; davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, w); /* Enable interrupts */ @@ -284,9 +275,9 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop) /* Enable receive or transmit interrupts */ w = davinci_i2c_read_reg(dev, DAVINCI_I2C_IMR_REG); if (msg->flags & I2C_M_RD) - MOD_REG_BIT(w, DAVINCI_I2C_IMR_RRDY, 1); + w |= DAVINCI_I2C_IMR_RRDY; else - MOD_REG_BIT(w, DAVINCI_I2C_IMR_XRDY, 1); + w |= DAVINCI_I2C_IMR_XRDY; davinci_i2c_write_reg(dev, DAVINCI_I2C_IMR_REG, w); dev->terminate = 0; @@ -333,7 +324,7 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop) return msg->len; if (stop) { w = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG); - MOD_REG_BIT(w, DAVINCI_I2C_MDR_STP, 1); + w |= DAVINCI_I2C_MDR_STP; davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, w); } return -EREMOTEIO; @@ -461,7 +452,7 @@ static irqreturn_t i2c_davinci_isr(int this_irq, void *dev_id) w = davinci_i2c_read_reg(dev, DAVINCI_I2C_IMR_REG); - MOD_REG_BIT(w, DAVINCI_I2C_IMR_XRDY, 0); + w &= ~DAVINCI_I2C_IMR_XRDY; davinci_i2c_write_reg(dev, DAVINCI_I2C_IMR_REG, w); @@ -540,7 +531,12 @@ static int davinci_i2c_probe(struct platform_device *pdev) } clk_enable(dev->clk); - dev->base = (void __iomem *)IO_ADDRESS(mem->start); + dev->base = ioremap(mem->start, resource_size(mem)); + if (!dev->base) { + r = -EBUSY; + goto err_mem_ioremap; + } + i2c_davinci_init(dev); r = request_irq(dev->irq, i2c_davinci_isr, 0, pdev->name, dev); @@ -570,6 +566,8 @@ static int davinci_i2c_probe(struct platform_device *pdev) err_free_irq: free_irq(dev->irq, dev); err_unuse_clocks: + iounmap(dev->base); +err_mem_ioremap: clk_disable(dev->clk); clk_put(dev->clk); dev->clk = NULL; @@ -598,6 +596,7 @@ static int davinci_i2c_remove(struct platform_device *pdev) davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, 0); free_irq(IRQ_I2C, dev); + iounmap(dev->base); kfree(dev); mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); -- 1.5.6 From chaithrika at ti.com Wed Jan 6 03:24:58 2010 From: chaithrika at ti.com (Chaithrika U S) Date: Wed, 6 Jan 2010 14:54:58 +0530 Subject: [PATCH v2 2/4] i2c: davinci: Add helper functions In-Reply-To: <1262769900-2710-2-git-send-email-chaithrika@ti.com> References: <1262769900-2710-1-git-send-email-chaithrika@ti.com> <1262769900-2710-2-git-send-email-chaithrika@ti.com> Message-ID: <1262769900-2710-3-git-send-email-chaithrika@ti.com> Add i2c reset control and clock divider calculation functions which will be useful for power management features. Signed-off-by: Chaithrika U S Signed-off-by: Kevin Hilman --- drivers/i2c/busses/i2c-davinci.c | 56 +++++++++++++++++++++++++------------- 1 files changed, 37 insertions(+), 19 deletions(-) diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c index 44a3cb3..81c1049 100644 --- a/drivers/i2c/busses/i2c-davinci.c +++ b/drivers/i2c/busses/i2c-davinci.c @@ -124,12 +124,21 @@ static inline u16 davinci_i2c_read_reg(struct davinci_i2c_dev *i2c_dev, int reg) return __raw_readw(i2c_dev->base + reg); } -/* - * This functions configures I2C and brings I2C out of reset. - * This function is called during I2C init function. This function - * also gets called if I2C encounters any errors. - */ -static int i2c_davinci_init(struct davinci_i2c_dev *dev) +static inline void davinci_i2c_reset_ctrl(struct davinci_i2c_dev *i2c_dev, + int val) +{ + u16 w; + + w = davinci_i2c_read_reg(i2c_dev, DAVINCI_I2C_MDR_REG); + if (!val) /* put I2C into reset */ + w &= ~DAVINCI_I2C_MDR_IRS; + else /* take I2C out of reset */ + w |= DAVINCI_I2C_MDR_IRS; + + davinci_i2c_write_reg(i2c_dev, DAVINCI_I2C_MDR_REG, w); +} + +static void i2c_davinci_calc_clk_dividers(struct davinci_i2c_dev *dev) { struct davinci_i2c_platform_data *pdata = dev->dev->platform_data; u16 psc; @@ -138,15 +147,6 @@ static int i2c_davinci_init(struct davinci_i2c_dev *dev) u32 clkh; u32 clkl; u32 input_clock = clk_get_rate(dev->clk); - u16 w; - - if (!pdata) - pdata = &davinci_i2c_platform_data_default; - - /* put I2C into reset */ - w = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG); - w &= ~DAVINCI_I2C_MDR_IRS; - davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, w); /* NOTE: I2C Clock divider programming info * As per I2C specs the following formulas provide prescaler @@ -178,12 +178,32 @@ static int i2c_davinci_init(struct davinci_i2c_dev *dev) davinci_i2c_write_reg(dev, DAVINCI_I2C_CLKH_REG, clkh); davinci_i2c_write_reg(dev, DAVINCI_I2C_CLKL_REG, clkl); + dev_dbg(dev->dev, "input_clock = %d, CLK = %d\n", input_clock, clk); +} + +/* + * This function configures I2C and brings I2C out of reset. + * This function is called during I2C init function. This function + * also gets called if I2C encounters any errors. + */ +static int i2c_davinci_init(struct davinci_i2c_dev *dev) +{ + struct davinci_i2c_platform_data *pdata = dev->dev->platform_data; + + if (!pdata) + pdata = &davinci_i2c_platform_data_default; + + /* put I2C into reset */ + davinci_i2c_reset_ctrl(dev, 0); + + /* compute clock dividers */ + i2c_davinci_calc_clk_dividers(dev); + /* Respond at reserved "SMBus Host" slave address" (and zero); * we seem to have no option to not respond... */ davinci_i2c_write_reg(dev, DAVINCI_I2C_OAR_REG, 0x08); - dev_dbg(dev->dev, "input_clock = %d, CLK = %d\n", input_clock, clk); dev_dbg(dev->dev, "PSC = %d\n", davinci_i2c_read_reg(dev, DAVINCI_I2C_PSC_REG)); dev_dbg(dev->dev, "CLKL = %d\n", @@ -194,9 +214,7 @@ static int i2c_davinci_init(struct davinci_i2c_dev *dev) pdata->bus_freq, pdata->bus_delay); /* Take the I2C module out of reset: */ - w = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG); - w |= DAVINCI_I2C_MDR_IRS; - davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, w); + davinci_i2c_reset_ctrl(dev, 1); /* Enable interrupts */ davinci_i2c_write_reg(dev, DAVINCI_I2C_IMR_REG, I2C_DAVINCI_INTR_ALL); -- 1.5.6 From chaithrika at ti.com Wed Jan 6 03:24:56 2010 From: chaithrika at ti.com (Chaithrika U S) Date: Wed, 6 Jan 2010 14:54:56 +0530 Subject: [PATCH v3 0/4] i2c: davinci: Add power management features Message-ID: <1262769900-2710-1-git-send-email-chaithrika@ti.com> Add suspend/resume and cpufreq features to DaVinci I2C driver All patches apply to Linus' kernel tree. Testing of these features was done on DA850/OMAP-L138 EVM. Chaithrika U S (4): i2c: davinci: Remove MOD_REG_BIT and IO_ADDRESS usage i2c: davinci: Add helper functions i2c: davinci: Add suspend/resume support i2c: davinci: Add cpufreq support drivers/i2c/busses/i2c-davinci.c | 228 ++++++++++++++++++++++++++++--------- 1 files changed, 172 insertions(+), 56 deletions(-) In this version, the suspend/resume support patch has been updated to use dev_pm_ops. From chaithrika at ti.com Wed Jan 6 03:24:59 2010 From: chaithrika at ti.com (Chaithrika U S) Date: Wed, 6 Jan 2010 14:54:59 +0530 Subject: [PATCH v3 3/4] i2c: davinci: Add suspend/resume support In-Reply-To: <1262769900-2710-3-git-send-email-chaithrika@ti.com> References: <1262769900-2710-1-git-send-email-chaithrika@ti.com> <1262769900-2710-2-git-send-email-chaithrika@ti.com> <1262769900-2710-3-git-send-email-chaithrika@ti.com> Message-ID: <1262769900-2710-4-git-send-email-chaithrika@ti.com> Add suspend and resume callbacks to DaVinci I2C driver. This has been tested on DA850/OMAP-L138 EVM. The SoC specific suspend-to-RAM support patch series [1] is needed to test this feature. [1] http://linux.davincidsp.com/pipermail/davinci-linux-open-source/ 2009-November/016958.html Signed-off-by: Chaithrika U S Signed-off-by: Kevin Hilman --- drivers/i2c/busses/i2c-davinci.c | 36 ++++++++++++++++++++++++++++++++++++ 1 files changed, 36 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c index 81c1049..d2a4844 100644 --- a/drivers/i2c/busses/i2c-davinci.c +++ b/drivers/i2c/busses/i2c-davinci.c @@ -622,6 +622,41 @@ static int davinci_i2c_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_PM +static int davinci_i2c_suspend(struct device *dev) +{ + struct platform_device *pdev = to_platform_device(dev); + struct davinci_i2c_dev *i2c_dev = platform_get_drvdata(pdev); + + /* put I2C into reset */ + davinci_i2c_reset_ctrl(i2c_dev, 0); + clk_disable(i2c_dev->clk); + + return 0; +} + +static int davinci_i2c_resume(struct device *dev) +{ + struct platform_device *pdev = to_platform_device(dev); + struct davinci_i2c_dev *i2c_dev = platform_get_drvdata(pdev); + + clk_enable(i2c_dev->clk); + /* take I2C out of reset */ + davinci_i2c_reset_ctrl(i2c_dev, 1); + + return 0; +} + +static struct dev_pm_ops davinci_i2c_pm = { + .suspend = davinci_i2c_suspend, + .resume = davinci_i2c_resume, +}; + +#define davinci_i2c_pm_ops (&davinci_i2c_pm) +#else +#define davinci_i2c_pm_ops NULL +#endif + /* work with hotplug and coldplug */ MODULE_ALIAS("platform:i2c_davinci"); @@ -631,6 +666,7 @@ static struct platform_driver davinci_i2c_driver = { .driver = { .name = "i2c_davinci", .owner = THIS_MODULE, + .pm = davinci_i2c_pm_ops, }, }; -- 1.5.6 From chaithrika at ti.com Wed Jan 6 03:25:00 2010 From: chaithrika at ti.com (Chaithrika U S) Date: Wed, 6 Jan 2010 14:55:00 +0530 Subject: [PATCH v2 4/4] i2c: davinci: Add cpufreq support In-Reply-To: <1262769900-2710-4-git-send-email-chaithrika@ti.com> References: <1262769900-2710-1-git-send-email-chaithrika@ti.com> <1262769900-2710-2-git-send-email-chaithrika@ti.com> <1262769900-2710-3-git-send-email-chaithrika@ti.com> <1262769900-2710-4-git-send-email-chaithrika@ti.com> Message-ID: <1262769900-2710-5-git-send-email-chaithrika@ti.com> Add cpufreq support for DaVinci I2C driver. Tested on DA850/OMAP-L138 EVM. For the purpose of testing, the patches which add cpufreq support [1] for this SoC are needed. [1]http://linux.davincidsp.com/pipermail/davinci-linux-open-source/ 2009-September/016118.html Signed-off-by: Chaithrika U S Signed-off-by: Kevin Hilman --- drivers/i2c/busses/i2c-davinci.c | 63 ++++++++++++++++++++++++++++++++++++++ 1 files changed, 63 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c index d2a4844..773cce5 100644 --- a/drivers/i2c/busses/i2c-davinci.c +++ b/drivers/i2c/busses/i2c-davinci.c @@ -35,6 +35,7 @@ #include #include #include +#include #include #include @@ -105,6 +106,10 @@ struct davinci_i2c_dev { int irq; u8 terminate; struct i2c_adapter adapter; +#ifdef CONFIG_CPU_FREQ + struct completion xfr_complete; + struct notifier_block freq_transition; +#endif }; /* default platform data to use if not supplied in the platform_device */ @@ -375,6 +380,11 @@ i2c_davinci_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) if (ret < 0) return ret; } + +#ifdef CONFIG_CPU_FREQ + complete(&dev->xfr_complete); +#endif + return num; } @@ -499,6 +509,48 @@ static irqreturn_t i2c_davinci_isr(int this_irq, void *dev_id) return count ? IRQ_HANDLED : IRQ_NONE; } +#ifdef CONFIG_CPU_FREQ +static int i2c_davinci_cpufreq_transition(struct notifier_block *nb, + unsigned long val, void *data) +{ + struct davinci_i2c_dev *dev; + + dev = container_of(nb, struct davinci_i2c_dev, freq_transition); + if (val == CPUFREQ_PRECHANGE) { + wait_for_completion(&dev->xfr_complete); + davinci_i2c_reset_ctrl(dev, 0); + } else if (val == CPUFREQ_POSTCHANGE) { + i2c_davinci_calc_clk_dividers(dev); + davinci_i2c_reset_ctrl(dev, 1); + } + + return 0; +} + +static inline int i2c_davinci_cpufreq_register(struct davinci_i2c_dev *dev) +{ + dev->freq_transition.notifier_call = i2c_davinci_cpufreq_transition; + + return cpufreq_register_notifier(&dev->freq_transition, + CPUFREQ_TRANSITION_NOTIFIER); +} + +static inline void i2c_davinci_cpufreq_deregister(struct davinci_i2c_dev *dev) +{ + cpufreq_unregister_notifier(&dev->freq_transition, + CPUFREQ_TRANSITION_NOTIFIER); +} +#else +static inline int i2c_davinci_cpufreq_register(struct davinci_i2c_dev *dev) +{ + return 0; +} + +static inline void i2c_davinci_cpufreq_deregister(struct davinci_i2c_dev *dev) +{ +} +#endif + static struct i2c_algorithm i2c_davinci_algo = { .master_xfer = i2c_davinci_xfer, .functionality = i2c_davinci_func, @@ -538,6 +590,9 @@ static int davinci_i2c_probe(struct platform_device *pdev) } init_completion(&dev->cmd_complete); +#ifdef CONFIG_CPU_FREQ + init_completion(&dev->xfr_complete); +#endif dev->dev = get_device(&pdev->dev); dev->irq = irq->start; platform_set_drvdata(pdev, dev); @@ -563,6 +618,12 @@ static int davinci_i2c_probe(struct platform_device *pdev) goto err_unuse_clocks; } + r = i2c_davinci_cpufreq_register(dev); + if (r) { + dev_err(&pdev->dev, "failed to register cpufreq\n"); + goto err_free_irq; + } + adap = &dev->adapter; i2c_set_adapdata(adap, dev); adap->owner = THIS_MODULE; @@ -604,6 +665,8 @@ static int davinci_i2c_remove(struct platform_device *pdev) struct davinci_i2c_dev *dev = platform_get_drvdata(pdev); struct resource *mem; + i2c_davinci_cpufreq_deregister(dev); + platform_set_drvdata(pdev, NULL); i2c_del_adapter(&dev->adapter); put_device(&pdev->dev); -- 1.5.6 From chaithrika at ti.com Wed Jan 6 03:34:48 2010 From: chaithrika at ti.com (Chaithrika U S) Date: Wed, 6 Jan 2010 15:04:48 +0530 Subject: [PATCH v2 1/2] davinci: MMC: Add a function to control reset state of the controller Message-ID: <1262770489-9486-1-git-send-email-chaithrika@ti.com> Add a helper function which will aid in changing the reset status of the controller. Signed-off-by: Chaithrika U S Signed-off-by: Kevin Hilman --- Applies to Linus' kernel tree drivers/mmc/host/davinci_mmc.c | 37 ++++++++++++++++--------------------- 1 files changed, 16 insertions(+), 21 deletions(-) diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c index dd45e7c..25645bf 100644 --- a/drivers/mmc/host/davinci_mmc.c +++ b/drivers/mmc/host/davinci_mmc.c @@ -884,19 +884,26 @@ static void mmc_davinci_cmd_done(struct mmc_davinci_host *host, } } -static void -davinci_abort_data(struct mmc_davinci_host *host, struct mmc_data *data) +static inline void mmc_davinci_reset_ctrl(struct mmc_davinci_host *host, + int val) { u32 temp; - /* reset command and data state machines */ temp = readl(host->base + DAVINCI_MMCCTL); - writel(temp | MMCCTL_CMDRST | MMCCTL_DATRST, - host->base + DAVINCI_MMCCTL); + if (val) /* reset */ + temp |= MMCCTL_CMDRST | MMCCTL_DATRST; + else /* enable */ + temp &= ~(MMCCTL_CMDRST | MMCCTL_DATRST); - temp &= ~(MMCCTL_CMDRST | MMCCTL_DATRST); - udelay(10); writel(temp, host->base + DAVINCI_MMCCTL); + udelay(10); +} + +static void +davinci_abort_data(struct mmc_davinci_host *host, struct mmc_data *data) +{ + mmc_davinci_reset_ctrl(host, 1); + mmc_davinci_reset_ctrl(host, 0); } static irqreturn_t mmc_davinci_irq(int irq, void *dev_id) @@ -1100,15 +1107,8 @@ static inline void mmc_davinci_cpufreq_deregister(struct mmc_davinci_host *host) #endif static void __init init_mmcsd_host(struct mmc_davinci_host *host) { - /* DAT line portion is diabled and in reset state */ - writel(readl(host->base + DAVINCI_MMCCTL) | MMCCTL_DATRST, - host->base + DAVINCI_MMCCTL); - - /* CMD line portion is diabled and in reset state */ - writel(readl(host->base + DAVINCI_MMCCTL) | MMCCTL_CMDRST, - host->base + DAVINCI_MMCCTL); - udelay(10); + mmc_davinci_reset_ctrl(host, 1); writel(0, host->base + DAVINCI_MMCCLK); writel(MMCCLK_CLKEN, host->base + DAVINCI_MMCCLK); @@ -1116,12 +1116,7 @@ static void __init init_mmcsd_host(struct mmc_davinci_host *host) writel(0x1FFF, host->base + DAVINCI_MMCTOR); writel(0xFFFF, host->base + DAVINCI_MMCTOD); - writel(readl(host->base + DAVINCI_MMCCTL) & ~MMCCTL_DATRST, - host->base + DAVINCI_MMCCTL); - writel(readl(host->base + DAVINCI_MMCCTL) & ~MMCCTL_CMDRST, - host->base + DAVINCI_MMCCTL); - - udelay(10); + mmc_davinci_reset_ctrl(host, 0); } static int __init davinci_mmcsd_probe(struct platform_device *pdev) -- 1.5.6 From chaithrika at ti.com Wed Jan 6 03:34:49 2010 From: chaithrika at ti.com (Chaithrika U S) Date: Wed, 6 Jan 2010 15:04:49 +0530 Subject: [PATCH v2 2/2] davinci: MMC: updates to suspend/resume implementation In-Reply-To: <1262770489-9486-1-git-send-email-chaithrika@ti.com> References: <1262770489-9486-1-git-send-email-chaithrika@ti.com> Message-ID: <1262770489-9486-2-git-send-email-chaithrika@ti.com> Improve the suspend and resume callbacks in DaVinci MMC host controller driver. Tested on DA850/OMAP-L138 EVM. This testing requires patches which add suspen-to-RAM support to DA850/OMAP-L138 SoC[1]. [1]http://linux.davincidsp.com/pipermail/davinci-linux-open-source/ 2009-September/016118.html Signed-off-by: Chaithrika U S --- Applies to Linus' kernel tree. drivers/mmc/host/davinci_mmc.c | 51 +++++++++++++++++++++++++++++++++------ 1 files changed, 43 insertions(+), 8 deletions(-) diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c index 25645bf..d60f648 100644 --- a/drivers/mmc/host/davinci_mmc.c +++ b/drivers/mmc/host/davinci_mmc.c @@ -170,6 +170,7 @@ struct mmc_davinci_host { #define DAVINCI_MMC_DATADIR_READ 1 #define DAVINCI_MMC_DATADIR_WRITE 2 unsigned char data_dir; + unsigned char suspended; /* buffer is used during PIO of one scatterlist segment, and * is updated along with buffer_bytes_left. bytes_left applies @@ -1297,32 +1298,66 @@ static int __exit davinci_mmcsd_remove(struct platform_device *pdev) } #ifdef CONFIG_PM -static int davinci_mmcsd_suspend(struct platform_device *pdev, pm_message_t msg) +static int davinci_mmcsd_suspend(struct device *dev) { + struct platform_device *pdev = to_platform_device(dev); struct mmc_davinci_host *host = platform_get_drvdata(pdev); + struct pm_message msg = { PM_EVENT_SUSPEND }; + int ret; - return mmc_suspend_host(host->mmc, msg); + mmc_host_enable(host->mmc); + ret = mmc_suspend_host(host->mmc, msg); + if (!ret) { + writel(0, host->base + DAVINCI_MMCIM); + mmc_davinci_reset_ctrl(host, 1); + mmc_host_disable(host->mmc); + clk_disable(host->clk); + host->suspended = 1; + } else { + host->suspended = 0; + mmc_host_disable(host->mmc); + } + + return ret; } -static int davinci_mmcsd_resume(struct platform_device *pdev) +static int davinci_mmcsd_resume(struct device *dev) { + struct platform_device *pdev = to_platform_device(dev); struct mmc_davinci_host *host = platform_get_drvdata(pdev); + int ret; - return mmc_resume_host(host->mmc); + if (!host->suspended) + return 0; + + clk_enable(host->clk); + mmc_host_enable(host->mmc); + + mmc_davinci_reset_ctrl(host, 0); + ret = mmc_resume_host(host->mmc); + if (!ret) + host->suspended = 0; + + return ret; } + +static struct dev_pm_ops davinci_mmcsd_pm = { + .suspend = davinci_mmcsd_suspend, + .resume = davinci_mmcsd_resume, +}; + +#define davinci_mmcsd_pm_ops (&davinci_mmcsd_pm) #else -#define davinci_mmcsd_suspend NULL -#define davinci_mmcsd_resume NULL +#define davinci_mmcsd_pm_ops NULL #endif static struct platform_driver davinci_mmcsd_driver = { .driver = { .name = "davinci_mmc", .owner = THIS_MODULE, + .pm = davinci_mmcsd_pm_ops, }, .remove = __exit_p(davinci_mmcsd_remove), - .suspend = davinci_mmcsd_suspend, - .resume = davinci_mmcsd_resume, }; static int __init davinci_mmcsd_init(void) -- 1.5.6 From pjohn at in.mvista.com Wed Jan 6 05:30:26 2010 From: pjohn at in.mvista.com (Philby John) Date: Wed, 06 Jan 2010 17:00:26 +0530 Subject: [PATCH v1] i2c: Davinci i2c bus recovery procedure to come out of time out conditions In-Reply-To: <87r5q4nkex.fsf@deeprootsystems.com> References: <1258989756.20007.227.camel@localhost.localdomain> <87r5q4nkex.fsf@deeprootsystems.com> Message-ID: <1262777426.3581.15.camel@localhost.localdomain> Kevin, On Tue, 2010-01-05 at 16:31 -0800, Kevin Hilman wrote: > Philby John writes: > > >>From 062cfba8b86ccd932eaa498980e703295d86a6cb Mon Sep 17 00:00:00 2001 > > From: Philby John > > Date: Mon, 23 Nov 2009 18:08:33 +0530 > > Subject: [PATCH] Davinci i2c bus recovery procedure to come out of time out conditions > > > > Get out of i2c time out condition by following the > > bus recovery procedure outlined in the i2c protocol v3 spec. > > The kernel must be robust enough to gracefully recover > > from i2c bus failure without having to reset the machine. > > This is done by first NACKing the slave, pulsing the SCL > > line 9 times and then sending the stop command. > > > > This patch has been tested on a DM6446 and DM355 > > How are you testing this? this should also be tested on da8xx by someone. This patch is redundant but patch v2 did not make it to the list because of reverse-dns issues. Resending it now. But then again I guess there will be a v3 because of removal of macro MOD_REG_BIT. Thank you for your comments. Regards, Philby > > > Signed-off-by: Philby John > > > > --- > > drivers/i2c/busses/i2c-davinci.c | 54 +++++++++++++++++++++++++++++++++---- > > 1 files changed, 48 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c > > index 67d88cc..6b4a550 100644 > > --- a/drivers/i2c/busses/i2c-davinci.c > > +++ b/drivers/i2c/busses/i2c-davinci.c > > @@ -35,6 +35,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > > > @@ -43,6 +44,7 @@ > > /* ----- global defines ----------------------------------------------- */ > > > > #define DAVINCI_I2C_TIMEOUT (1*HZ) > > +#define DAVINCI_I2C_MAX_TRIES 2 > > #define I2C_DAVINCI_INTR_ALL (DAVINCI_I2C_IMR_AAS | \ > > DAVINCI_I2C_IMR_SCD | \ > > DAVINCI_I2C_IMR_ARDY | \ > > @@ -134,6 +136,38 @@ static inline u16 davinci_i2c_read_reg(struct davinci_i2c_dev *i2c_dev, int reg) > > return __raw_readw(i2c_dev->base + reg); > > } > > > > +/* Generate a pulse on the i2c clock pin. */ > > +static void pulse_i2c_clock(void) > > +{ > > + gpio_set_value(14, 0); > > + udelay(20); > > + gpio_set_value(14, 1); > > + udelay(20); > > +} > > + > > +/* This routine does i2c bus recovery as specified in the > > + * i2c protocol Rev. 03 section 3.16 titled "Bus clear" > > + */ > > +static void i2c_recover_bus(struct davinci_i2c_dev *dev) > > +{ > > + u16 i; > > + u32 flag = 0; > > + > > + dev_err(dev->dev, "initiating i2c bus recovery\n"); > > This looks like a debug leftover. I doubt you want this since > you're calling this function on every xfer. > > > + /* Send NACK to the slave */ > > + flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG); > > + flag |= DAVINCI_I2C_MDR_NACK; > > + /* write the data into mode register */ > > + davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag); > > + /* Send high and low on the SCL line */ > > + for (i = 0; i < 9; i++) > > + pulse_i2c_clock(); > > + /* Send STOP */ > > + flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG); > > + MOD_REG_BIT(flag, DAVINCI_I2C_MDR_STP, 1); > > This patch will need some updates as this macro is now gone. > > Kevin > > > + davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag); > > +} > > + > > /* > > * This functions configures I2C and brings I2C out of reset. > > * This function is called during I2C init function. This function > > @@ -221,19 +255,26 @@ static int i2c_davinci_wait_bus_not_busy(struct davinci_i2c_dev *dev, > > char allow_sleep) > > { > > unsigned long timeout; > > + static u16 to_cnt = 0; > > > > timeout = jiffies + dev->adapter.timeout; > > while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG) > > - & DAVINCI_I2C_STR_BB) { > > - if (time_after(jiffies, timeout)) { > > - dev_warn(dev->dev, > > - "timeout waiting for bus ready\n"); > > - return -ETIMEDOUT; > > + & DAVINCI_I2C_STR_BB) { > > + if (to_cnt <= DAVINCI_I2C_MAX_TRIES) { > > + if (time_after(jiffies, timeout)) { > > + dev_warn(dev->dev, > > + "timeout waiting for bus ready\n"); > > + to_cnt++; > > + return -ETIMEDOUT; > > + } else { > > + to_cnt = 0; > > + i2c_recover_bus(dev); > > + i2c_davinci_init(dev); > > + } > > } > > if (allow_sleep) > > schedule_timeout(1); > > } > > - > > return 0; > > } > > > > @@ -310,6 +351,7 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop) > > dev->adapter.timeout); > > if (r == 0) { > > dev_err(dev->dev, "controller timed out\n"); > > + i2c_recover_bus(dev); > > i2c_davinci_init(dev); > > dev->buf_len = 0; > > return -ETIMEDOUT; > > -- > > 1.6.3.3.MVISTA > > > > > > > > > > _______________________________________________ > > 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 pjohn at in.mvista.com Wed Jan 6 05:33:35 2010 From: pjohn at in.mvista.com (Philby John) Date: Wed, 06 Jan 2010 17:03:35 +0530 Subject: [PATCH v2] i2c: Davinci i2c bus recovery procedure to clear the bus Message-ID: <1262777615.3581.16.camel@localhost.localdomain> >From 0372e68cfd14ab37595498234abe39f2f10787d5 Mon Sep 17 00:00:00 2001 From: Philby John Date: Mon, 23 Nov 2009 18:08:33 +0530 Subject: [PATCH] Davinci i2c bus recovery procedure to clear the bus Come out of i2c time out condition by following the bus recovery procedure outlined in the i2c protocol v3 spec. The kernel must be robust enough to gracefully recover from i2c bus failure without having to reset the machine. This is done by first NACKing the slave, pulsing the SCL line 9 times and then sending the stop command. This patch has been tested on a DM6446 and DM355 Signed-off-by: Philby John Signed-off-by: Srinivasan, Nageswari --- TODO: Need to add SDA and SCL pin numbers to the respective platforms such as dm355-leopard, dm365, dm646x, da8xx etc. What I have info on is limited to just dm355 and dm6446. arch/arm/mach-davinci/board-dm355-evm.c | 2 + arch/arm/mach-davinci/board-dm644x-evm.c | 2 + arch/arm/mach-davinci/include/mach/i2c.h | 2 + drivers/i2c/busses/i2c-davinci.c | 60 +++++++++++++++++++++++++++--- 4 files changed, 60 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c index a9b650d..a20b2de 100644 --- a/arch/arm/mach-davinci/board-dm355-evm.c +++ b/arch/arm/mach-davinci/board-dm355-evm.c @@ -111,6 +111,8 @@ static struct platform_device davinci_nand_device = { static struct davinci_i2c_platform_data i2c_pdata = { .bus_freq = 400 /* kHz */, .bus_delay = 0 /* usec */, + .sda_pin = 15, + .scl_pin = 14, }; static struct snd_platform_data dm355_evm_snd_data; diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index fd0398b..b5ce36b 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -628,6 +628,8 @@ static struct i2c_board_info __initdata i2c_info[] = { static struct davinci_i2c_platform_data i2c_pdata = { .bus_freq = 20 /* kHz */, .bus_delay = 100 /* usec */, + .sda_pin = 44, + .scl_pin = 43, }; static void __init evm_init_i2c(void) diff --git a/arch/arm/mach-davinci/include/mach/i2c.h b/arch/arm/mach-davinci/include/mach/i2c.h index c248e9b..21be118 100644 --- a/arch/arm/mach-davinci/include/mach/i2c.h +++ b/arch/arm/mach-davinci/include/mach/i2c.h @@ -16,6 +16,8 @@ struct davinci_i2c_platform_data { unsigned int bus_freq; /* standard bus frequency (kHz) */ unsigned int bus_delay; /* post-transaction delay (usec) */ + unsigned int sda_pin; /* GPIO pin ID to use for SDA */ + unsigned int scl_pin; /* GPIO pin ID to use for SCL */ }; /* for board setup code */ diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c index 67d88cc..be18cab 100644 --- a/drivers/i2c/busses/i2c-davinci.c +++ b/drivers/i2c/busses/i2c-davinci.c @@ -35,6 +35,7 @@ #include #include #include +#include #include @@ -43,6 +44,7 @@ /* ----- global defines ----------------------------------------------- */ #define DAVINCI_I2C_TIMEOUT (1*HZ) +#define DAVINCI_I2C_MAX_TRIES 2 #define I2C_DAVINCI_INTR_ALL (DAVINCI_I2C_IMR_AAS | \ DAVINCI_I2C_IMR_SCD | \ DAVINCI_I2C_IMR_ARDY | \ @@ -134,6 +136,44 @@ static inline u16 davinci_i2c_read_reg(struct davinci_i2c_dev *i2c_dev, int reg) return __raw_readw(i2c_dev->base + reg); } +/* 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); + } + } +} + +/* This routine does i2c bus recovery as specified in the + * i2c protocol Rev. 03 section 3.16 titled "Bus clear" + */ +static void i2c_recover_bus(struct davinci_i2c_dev *dev) +{ + u32 flag = 0; + struct davinci_i2c_platform_data *pdata = dev->dev->platform_data; + + dev_err(dev->dev, "initiating i2c bus recovery\n"); + /* Send NACK to the slave */ + flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG); + flag |= DAVINCI_I2C_MDR_NACK; + /* write the data into mode register */ + davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag); + if (pdata) + generic_i2c_clock_pulse(pdata->scl_pin); + /* Send STOP */ + flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG); + MOD_REG_BIT(flag, DAVINCI_I2C_MDR_STP, 1); + davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag); +} + /* * This functions configures I2C and brings I2C out of reset. * This function is called during I2C init function. This function @@ -221,19 +261,26 @@ static int i2c_davinci_wait_bus_not_busy(struct davinci_i2c_dev *dev, char allow_sleep) { unsigned long timeout; + static u16 to_cnt = 0; timeout = jiffies + dev->adapter.timeout; while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG) - & DAVINCI_I2C_STR_BB) { - if (time_after(jiffies, timeout)) { - dev_warn(dev->dev, - "timeout waiting for bus ready\n"); - return -ETIMEDOUT; + & DAVINCI_I2C_STR_BB) { + if (to_cnt <= DAVINCI_I2C_MAX_TRIES) { + if (time_after(jiffies, timeout)) { + dev_warn(dev->dev, + "timeout waiting for bus ready\n"); + to_cnt++; + return -ETIMEDOUT; + } else { + to_cnt = 0; + i2c_recover_bus(dev); + i2c_davinci_init(dev); + } } if (allow_sleep) schedule_timeout(1); } - return 0; } @@ -310,6 +357,7 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop) dev->adapter.timeout); if (r == 0) { dev_err(dev->dev, "controller timed out\n"); + i2c_recover_bus(dev); i2c_davinci_init(dev); dev->buf_len = 0; return -ETIMEDOUT; -- 1.6.3.3.MVISTA From nsekhar at ti.com Wed Jan 6 05:49:49 2010 From: nsekhar at ti.com (Sekhar Nori) Date: Wed, 6 Jan 2010 17:19:49 +0530 Subject: [PATCH v2 2/2] davinci: add CDCE949 support on DM6467 EVM In-Reply-To: <1262778589-31459-1-git-send-email-nsekhar@ti.com> References: <1262778589-31459-1-git-send-email-nsekhar@ti.com> Message-ID: <1262778589-31459-2-git-send-email-nsekhar@ti.com> From: Nageswari Srinivasan This patch adds the CDCE949 reference oscillator to the davinci clock list. On the DM6467T EVM, the CDCE949 is responsible for generating the pixel clock for display. On the DM6467 EVM, this pixel clock was being obtained from an internal source. This is not possible on the DM6467T EVM because of the presence of a 33MHz oscillator. The TSIF module also requires the CDCE949 to generate the data clocks. The actual clock definitions will be added by patches adding support for DM6467T VPIF and TSIF. This patch mearly lays the foundation for that work. Signed-off-by: Nageswari Srinivasan Signed-off-by: Sekhar Nori --- Since v1, ALWAYS_ENABLED flag has been removed from cdce_clk_in arch/arm/mach-davinci/Makefile | 2 +- arch/arm/mach-davinci/board-dm646x-evm.c | 31 ++++++++++++++++++++++++++++++ 2 files changed, 32 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile index eeb9230..7e806b0 100644 --- a/arch/arm/mach-davinci/Makefile +++ b/arch/arm/mach-davinci/Makefile @@ -26,7 +26,7 @@ obj-$(CONFIG_MACH_SFFSDR) += board-sffsdr.o obj-$(CONFIG_MACH_NEUROS_OSD2) += board-neuros-osd2.o obj-$(CONFIG_MACH_DAVINCI_DM355_EVM) += board-dm355-evm.o obj-$(CONFIG_MACH_DM355_LEOPARD) += board-dm355-leopard.o -obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM) += board-dm646x-evm.o +obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM) += board-dm646x-evm.o cdce949.o obj-$(CONFIG_MACH_DAVINCI_DM365_EVM) += board-dm365-evm.o obj-$(CONFIG_MACH_DAVINCI_DA830_EVM) += board-da830-evm.o obj-$(CONFIG_MACH_DAVINCI_DA850_EVM) += board-da850-evm.o diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c index 6ff3411..6c7c604 100644 --- a/arch/arm/mach-davinci/board-dm646x-evm.c +++ b/arch/arm/mach-davinci/board-dm646x-evm.c @@ -40,6 +40,8 @@ #include #include #include +#include +#include #include "clock.h" @@ -389,6 +391,9 @@ static struct i2c_board_info __initdata i2c_info[] = { { I2C_BOARD_INFO("cpld_video", 0x3b), }, + { + I2C_BOARD_INFO("cdce949", 0x6c), + }, }; static struct davinci_i2c_platform_data i2c_pdata = { @@ -681,9 +686,35 @@ static void __init evm_init_i2c(void) evm_init_video(); } +#define CDCE949_XIN_RATE 27000000 + +/* CDCE949 support - "lpsc" field is overridden to work as clock number */ +static struct clk cdce_clk_in = { + .name = "cdce_xin", + .rate = ATOMIC_INIT(CDCE949_XIN_RATE), +}; + +static struct davinci_clk cdce_clks[] = { + CLK(NULL, "xin", &cdce_clk_in), + CLK(NULL, NULL, NULL), +}; + +static void __init cdce_clk_init(void) +{ + struct davinci_clk *c; + struct clk *clk; + + for (c = cdce_clks; c->lk.clk; c++) { + clk = c->lk.clk; + clkdev_add(&c->lk); + clk_register(clk); + } +} + static void __init davinci_map_io(void) { dm646x_init(); + cdce_clk_init(); } static struct davinci_uart_config uart_config __initdata = { -- 1.6.2.4 From nsekhar at ti.com Wed Jan 6 05:49:48 2010 From: nsekhar at ti.com (Sekhar Nori) Date: Wed, 6 Jan 2010 17:19:48 +0530 Subject: [PATCH 1/2] davinci: add support for CDCE949 clock synthesizer Message-ID: <1262778589-31459-1-git-send-email-nsekhar@ti.com> From: Nageswari Srinivasan This patch adds support for TI's CDCE949 - a clock synthesizer with 4 PLLs and 9 outputs. It is used on DM6467 EVM. On the EVM, it generates clocks required for VPIF, TSIF and Audio modules. This patch adds it as part of the DaVinci clock framework. Testing: The various frequency outputs on Y1 have been tested using a out-of-tree VPIF video driver supporting HD video. The register values for Y5 frequency outputs have been derived from TSIF driver sources in MontaVista LSP kernel, but actual output has not been tested for lack of TSIF driver which actually works on the latest kernel. Signed-off-by: Nageswari Srinivasan Signed-off-by: Sekhar Nori --- arch/arm/mach-davinci/cdce949.c | 289 ++++++++++++++++++++++++++ arch/arm/mach-davinci/include/mach/cdce949.h | 19 ++ 2 files changed, 308 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-davinci/cdce949.c create mode 100644 arch/arm/mach-davinci/include/mach/cdce949.h diff --git a/arch/arm/mach-davinci/cdce949.c b/arch/arm/mach-davinci/cdce949.c new file mode 100644 index 0000000..5a08283 --- /dev/null +++ b/arch/arm/mach-davinci/cdce949.c @@ -0,0 +1,289 @@ +/* + * TI CDCE949 clock synthesizer driver + * + * Note: This implementation assumes an input of 27MHz to the CDCE. + * This is by no means constrained by CDCE hardware although the datasheet + * does use this as an example for all illustrations and more importantly: + * that is the crystal input on boards it is currently used on. + * + * Copyright (C) 2009 Texas Instruments Incorporated. http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + */ +#include +#include +#include +#include + +#include + +#include "clock.h" + +static struct i2c_client *cdce_i2c_client; + +/* CDCE register descriptor */ +struct cdce_reg { + u8 addr; + u8 val; +}; + +/* Per-Output (Y1, Y2 etc.) frequency descriptor */ +struct cdce_freq { + /* Frequency in KHz */ + unsigned long frequency; + /* + * List of registers to program to obtain a particular frequency. + * 0x0 in register address and value is the end of list marker. + */ + struct cdce_reg *reglist; +}; + +#define CDCE_FREQ_TABLE_ENTRY(line, out) \ +{ \ + .reglist = cdce_y ##line## _ ##out, \ + .frequency = out, \ +} + +/* List of CDCE outputs */ +struct cdce_output { + /* List of frequencies on this output */ + struct cdce_freq *freq_table; + /* Number of possible frequencies */ + int size; +}; + +/* + * Finding out the values to program into CDCE949 registers for a particular + * frequency output is not a simple calculation. Have a look at the datasheet + * for the details. There is desktop software available to help users with + * the calculations. Here, we just depend on the output of that software + * (or hand calculations) instead trying to runtime calculate the register + * values and inflicting misery on ourselves. + */ +static struct cdce_reg cdce_y1_148500[] = { + { 0x13, 0x00 }, + /* program PLL1_0 multiplier */ + { 0x18, 0xaf }, + { 0x19, 0x50 }, + { 0x1a, 0x02 }, + { 0x1b, 0xc9 }, + /* program PLL1_11 multiplier */ + { 0x1c, 0x00 }, + { 0x1d, 0x40 }, + { 0x1e, 0x02 }, + { 0x1f, 0xc9 }, + /* output state selection */ + { 0x15, 0x00 }, + { 0x14, 0xef }, + /* switch MUX to PLL1 output */ + { 0x14, 0x6f }, + { 0x16, 0x06 }, + /* set P2DIV divider, P3DIV and input crystal */ + { 0x17, 0x06 }, + { 0x01, 0x00 }, + { 0x05, 0x48 }, + { 0x02, 0x80 }, + /* enable and disable PLL */ + { 0x02, 0xbc }, + { 0x03, 0x01 }, + { }, +}; + +static struct cdce_reg cdce_y1_74250[] = { + { 0x13, 0x00 }, + { 0x18, 0xaf }, + { 0x19, 0x50 }, + { 0x1a, 0x02 }, + { 0x1b, 0xc9 }, + { 0x1c, 0x00 }, + { 0x1d, 0x40 }, + { 0x1e, 0x02 }, + { 0x1f, 0xc9 }, + /* output state selection */ + { 0x15, 0x00 }, + { 0x14, 0xef }, + /* switch MUX to PLL1 output */ + { 0x14, 0x6f }, + { 0x16, 0x06 }, + /* set P2DIV divider, P3DIV and input crystal */ + { 0x17, 0x06 }, + { 0x01, 0x00 }, + { 0x05, 0x48 }, + { 0x02, 0x80 }, + /* enable and disable PLL */ + { 0x02, 0xbc }, + { 0x03, 0x02 }, + { }, +}; + +static struct cdce_reg cdce_y1_27000[] = { + { 0x13, 0x00 }, + { 0x18, 0x00 }, + { 0x19, 0x40 }, + { 0x1a, 0x02 }, + { 0x1b, 0x08 }, + { 0x1c, 0x00 }, + { 0x1d, 0x40 }, + { 0x1e, 0x02 }, + { 0x1f, 0x08 }, + { 0x15, 0x02 }, + { 0x14, 0xed }, + { 0x16, 0x01 }, + { 0x17, 0x01 }, + { 0x01, 0x00 }, + { 0x05, 0x50 }, + { 0x02, 0xb4 }, + { 0x03, 0x01 }, + { }, +}; + +static struct cdce_freq cdce_y1_freqs[] = { + CDCE_FREQ_TABLE_ENTRY(1, 148500), + CDCE_FREQ_TABLE_ENTRY(1, 74250), + CDCE_FREQ_TABLE_ENTRY(1, 27000), +}; + +static struct cdce_reg cdce_y5_13500[] = { + { 0x27, 0x08 }, + { 0x28, 0x00 }, + { 0x29, 0x40 }, + { 0x2a, 0x02 }, + { 0x2b, 0x08 }, + { 0x24, 0x6f }, + { }, +}; + +static struct cdce_reg cdce_y5_16875[] = { + { 0x27, 0x08 }, + { 0x28, 0x9f }, + { 0x29, 0xb0 }, + { 0x2a, 0x02 }, + { 0x2b, 0x89 }, + { 0x24, 0x6f }, + { }, +}; + +static struct cdce_reg cdce_y5_27000[] = { + { 0x27, 0x04 }, + { 0x28, 0x00 }, + { 0x29, 0x40 }, + { 0x2a, 0x02 }, + { 0x2b, 0x08 }, + { 0x24, 0x6f }, + { }, +}; +static struct cdce_reg cdce_y5_54000[] = { + { 0x27, 0x04 }, + { 0x28, 0xff }, + { 0x29, 0x80 }, + { 0x2a, 0x02 }, + { 0x2b, 0x07 }, + { 0x24, 0x6f }, + { }, +}; + +static struct cdce_reg cdce_y5_81000[] = { + { 0x27, 0x02 }, + { 0x28, 0xbf }, + { 0x29, 0xa0 }, + { 0x2a, 0x03 }, + { 0x2b, 0x0a }, + { 0x24, 0x6f }, + { }, +}; + +static struct cdce_freq cdce_y5_freqs[] = { + CDCE_FREQ_TABLE_ENTRY(5, 13500), + CDCE_FREQ_TABLE_ENTRY(5, 16875), + CDCE_FREQ_TABLE_ENTRY(5, 27000), + CDCE_FREQ_TABLE_ENTRY(5, 54000), + CDCE_FREQ_TABLE_ENTRY(5, 81000), +}; + + +static struct cdce_output output_list[] = { + [1] = { cdce_y1_freqs, ARRAY_SIZE(cdce_y1_freqs) }, + [5] = { cdce_y5_freqs, ARRAY_SIZE(cdce_y5_freqs) }, +}; + +int cdce_set_rate(struct clk *clk, unsigned long rate) +{ + int i, ret = 0; + struct cdce_freq *freq_table = output_list[clk->lpsc].freq_table; + struct cdce_reg *regs = NULL; + + if (!cdce_i2c_client) + return -ENODEV; + + if (!freq_table) + return -EINVAL; + + for (i = 0; i < output_list[clk->lpsc].size; i++) { + if (freq_table[i].frequency == rate / 1000) { + regs = freq_table[i].reglist; + break; + } + } + + if (!regs) + return -EINVAL; + + for (i = 0; regs[i].addr; i++) { + ret = i2c_smbus_write_byte_data(cdce_i2c_client, + regs[i].addr | 0x80, regs[i].val); + if (ret) + return ret; + } + + atomic_set(&clk->rate, rate); + + return 0; +} + +static int cdce_probe(struct i2c_client *client, + const struct i2c_device_id *id) +{ + cdce_i2c_client = client; + return 0; +} + +static int __devexit cdce_remove(struct i2c_client *client) +{ + cdce_i2c_client = NULL; + return 0; +} + +static const struct i2c_device_id cdce_id[] = { + {"cdce949", 0}, + {}, +}; +MODULE_DEVICE_TABLE(i2c, cdce_id); + +static struct i2c_driver cdce_driver = { + .driver = { + .owner = THIS_MODULE, + .name = "cdce949", + }, + .probe = cdce_probe, + .remove = __devexit_p(cdce_remove), + .id_table = cdce_id, +}; + +static int __init cdce_init(void) +{ + return i2c_add_driver(&cdce_driver); +} +subsys_initcall(cdce_init); + +static void __exit cdce_exit(void) +{ + i2c_del_driver(&cdce_driver); +} +module_exit(cdce_exit); + +MODULE_AUTHOR("Texas Instruments"); +MODULE_DESCRIPTION("CDCE949 clock synthesizer driver"); +MODULE_LICENSE("GPL v2"); diff --git a/arch/arm/mach-davinci/include/mach/cdce949.h b/arch/arm/mach-davinci/include/mach/cdce949.h new file mode 100644 index 0000000..c73331f --- /dev/null +++ b/arch/arm/mach-davinci/include/mach/cdce949.h @@ -0,0 +1,19 @@ +/* + * TI CDCE949 off-chip clock synthesizer support + * + * 2009 (C) Texas Instruments, Inc. http://www.ti.com/ + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + */ +#ifndef _MACH_DAVINCI_CDCE949_H +#define _MACH_DAVINCI_CDCE949_H + +#include + +#include + +int cdce_set_rate(struct clk *clk, unsigned long rate); + +#endif -- 1.6.2.4 From sudhakar.raj at ti.com Wed Jan 6 05:47:42 2010 From: sudhakar.raj at ti.com (Sudhakar Rajashekhara) Date: Wed, 6 Jan 2010 17:17:42 +0530 Subject: [PATCH 0/9] davinci: EDMA updates In-Reply-To: <878wcctbpq.fsf@deeprootsystems.com> References: <1259731978-13147-1-git-send-email-sudhakar.raj@ti.com> <878wcctbpq.fsf@deeprootsystems.com> Message-ID: <00ac01ca8ec6$0deaf050$29c0d0f0$@raj@ti.com> Kevin, On Wed, Jan 06, 2010 at 04:12:57, Kevin Hilman wrote: > Sudhakar Rajashekhara writes: > > > This patch set corrects some issues with the existing EDMA > > driver and also adds support for EDMA resource (channel/slots) > > sharing between two processors (say ARM and DSP). > > > > The patch set has been tested on DM646x, OMAP-L137 and OMAP-L138 > > EVM boards. > > Hi Sudhakar, > > This series looks good. One minor request. > > For the last three patches, I think it would be helpful to describe in > the changelog or even better at the definition of the reserved arrays > what the channels are being reserved for. > I'll add the description for the arrays in the last 3 patches and will re-submit them. Thanks, Sudhakar From nsekhar at ti.com Wed Jan 6 05:54:56 2010 From: nsekhar at ti.com (Nori, Sekhar) Date: Wed, 6 Jan 2010 17:24:56 +0530 Subject: [PATCH v2] davinci: add CDCE949 support on DM6467 EVM In-Reply-To: <636c5031001051514n46c855fbs8020bc270eff7a6e@mail.gmail.com> References: <1260431376-2789-1-git-send-email-nsekhar@ti.com> <87ocl8rw64.fsf@deeprootsystems.com> <636c5031001051514n46c855fbs8020bc270eff7a6e@mail.gmail.com> Message-ID: On Wed, Jan 06, 2010 at 04:44:38, Kevin Hilman wrote: > On Tue, Jan 5, 2010 at 3:04 PM, Kevin Hilman > wrote: > > Sekhar Nori writes: > > > >> From: Nageswari Srinivasan > >> > >> This patch adds the CDCE949 reference oscillator to > >> the davinci clock list. > >> [...] > >> > >> Signed-off-by: Nageswari Srinivasan > >> Signed-off-by: Sekhar Nori > >> --- > >> Since v1, ALWAYS_ENABLED flag has been removed from cdce_clk_in > > > > Looks good, applying to davinc git and queueing in davinci-next for > > 2.6.34. > > > > I responded too soon. This doesn't compile... > > > [...] > >> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c > >> index 6ff3411..6c7c604 100644 > >> --- a/arch/arm/mach-davinci/board-dm646x-evm.c > >> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c > >> @@ -40,6 +40,8 @@ > >> #include > >> #include > >> #include > >> +#include > >> +#include > > ...since this file doesn't exist yet. > My bad. This file gets added by patch 4/5 of the original series; which I did not repost since there were no changes. I should have either posted all the remaining patches as a fresh series or indicated the dependency under the --- in this patch. I reposted the two patch series just now. Thanks, Sekhar From pjohn at in.mvista.com Wed Jan 6 06:23:04 2010 From: pjohn at in.mvista.com (Philby John) Date: Wed, 06 Jan 2010 17:53:04 +0530 Subject: how do i enable full speed instead of high speed in the USB In-Reply-To: <03A2FA9E0D3DC841992E682BF528771801747DA9@lipwig.Cernium.local> References: <03A2FA9E0D3DC841992E682BF528771801747AD2@lipwig.Cernium.local> <03A2FA9E0D3DC841992E682BF528771801747D65@lipwig.Cernium.local> <03A2FA9E0D3DC841992E682BF528771801747DA9@lipwig.Cernium.local> Message-ID: <1262780584.3581.64.camel@localhost.localdomain> Gopala, On Tue, 2010-01-05 at 10:34 -0500, Gopala Gottumukkala wrote: > I want to use Full speed instead of high speed. What needs to be done > to work with full speed. You will have better luck getting your question answered on the USB mailing list (linux-usb at vger.kernel.org). AFAIK, there are several dependencies that govern detection of speed on hotplug. One is the pull up resistor connected to D+ on the device, that allows the host to tell if its a full speed device. The other IIRC, is the USB clock speed at 480Mb/s for high speed data and full speed data clocked at 12Mb/s Regards, Philby > > > > Help appreciated, > > Thanks > > - Gopala > > > > From: Subbrathnam, Swaminathan [mailto:swami.iyer at ti.com] > Sent: Tuesday, January 05, 2010 9:41 AM > To: Gopala Gottumukkala; > davinci-linux-open-source at linux.davincidsp.com > Subject: RE: USB storage error > > > > > Pl. refer to DaVinci Staging GIT kernel hosted at > http://arago-project.org/git/people/?p=sneha/linux-davinci-staging.git;a=summary. > > > > > ______________________________________________________________________ > From: Gopala Gottumukkala [mailto:ggottumu at Cernium.com] > Sent: Tuesday, January 05, 2010 8:06 PM > To: Subbrathnam, Swaminathan; > davinci-linux-open-source at linux.davincidsp.com > Subject: RE: USB storage error > > > > > Which kernel version number is working for you can I know the kernel > version number and if any patches please let me know the patches also. > > > > - Gopala > > > > From: Gopala Gottumukkala > Sent: Monday, January 04, 2010 9:13 AM > To: 'Subbrathnam, Swaminathan'; > davinci-linux-open-source at linux.davincidsp.com > Subject: RE: USB storage error > > > > > Can I know the latest Davinci Git kernel version which is working for > you. The kernel version number and where can I down load the latest > one. > > > > - Gopala > > > > From: Subbrathnam, Swaminathan [mailto:swami.iyer at ti.com] > Sent: Friday, January 01, 2010 8:10 AM > To: Gopala Gottumukkala; > davinci-linux-open-source at linux.davincidsp.com > Subject: RE: USB storage error > > > > > Gopala, > > > > > > Could you try the latest DaVinci Git. It works for me. > > > > > > regards > > > swami > > > > ______________________________________________________________________ > From: davinci-linux-open-source-bounces at linux.davincidsp.com > [davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of > Gopala Gottumukkala [ggottumu at Cernium.com] > Sent: Friday, January 01, 2010 1:38 AM > To: davinci-linux-open-source at linux.davincidsp.com > Subject: USB storage error > > > I have compiled davinci 2.6.30 > > I mounted the usb manually > > I ran some sample program which will open, write and delete the file > into usb drive. > > While writing the file into usb drive. It gives the following error > and the program dies. > > > > Any help would be appreciated on this > > > > > > usb 1-1: reset high speed USB device using musb_hdrc and address 2 > > usb 1-1: reset high speed USB device using musb_hdrc and address 2 > > usb 1-1: reset high speed USB device using musb_hdrc and address 2 > > sd 0:0:0:0: Device offlined - not ready after error recovery > > sd 0:0:0:0: [sda] Unhandled error code > > sd 0:0:0:0: [sda] Result: hostbyte=0x05 driverbyte=0x00 > > end_request: I/O error, dev sda, sector 41584 > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: [sda] Unhandled error code > > sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00 > > end_request: I/O error, dev sda, sector 40000 > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device > > sd 0:0:0:0: rejecting I/O to offline device > > > > - Gopala > > > NOTICE: The information contained in this email and any document > attached hereto is intended only for the named recipient(s). It is the > property of Cernium Corporation and shall not be used, disclosed or > reproduced without the express written consent of Cernium Corporation. > If you are not the intended recipient (or the employee or agent > responsible for delivering this message in confidence to the intended > recipient(s)), you are hereby notified that you have received this > transmittal in error, and any review, dissemination, distribution or > copying of this transmittal or its attachments is strictly prohibited. > If you have received this transmittal and/or attachments in error, > please notify me immediately by reply email or telephone and > immediately delete this message and all its attachments. Thank you. > > > NOTICE: The information contained in this email and any document > attached hereto is intended only for the named recipient(s). It is the > property of Cernium Corporation and shall not be used, disclosed or > reproduced without the express written consent of Cernium Corporation. > If you are not the intended recipient (or the employee or agent > responsible for delivering this message in confidence to the intended > recipient(s)), you are hereby notified that you have received this > transmittal in error, and any review, dissemination, distribution or > copying of this transmittal or its attachments is strictly prohibited. > If you have received this transmittal and/or attachments in error, > please notify me immediately by reply email or telephone and > immediately delete this message and all its attachments. Thank you. > > > NOTICE: The information contained in this email and any document > attached hereto is intended only for the named recipient(s). It is the > property of Cernium Corporation and shall not be used, disclosed or > reproduced without the express written consent of Cernium Corporation. > If you are not the intended recipient (or the employee or agent > responsible for delivering this message in confidence to the intended > recipient(s)), you are hereby notified that you have received this > transmittal in error, and any review, dissemination, distribution or > copying of this transmittal or its attachments is strictly prohibited. > If you have received this transmittal and/or attachments in error, > please notify me immediately by reply email or telephone and > immediately delete this message and all its attachments. Thank you. > > _______________________________________________ > 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 sudhakar.raj at ti.com Wed Jan 6 05:58:21 2010 From: sudhakar.raj at ti.com (Sudhakar Rajashekhara) Date: Wed, 6 Jan 2010 17:28:21 +0530 Subject: [PATCH v2 0/9] davinci: EDMA updates Message-ID: <1262779101-25102-1-git-send-email-sudhakar.raj@ti.com> This patch set corrects some issues with the existing EDMA driver and also adds support for EDMA resource (channel/slots) sharing between two processors (say ARM and DSP). The patch set has been tested on DM646x, OMAP-L137 and OMAP-L138 EVM boards. First 6 patches of this set are same as the previous patches. The last 3 patches are different. Sudhakar Rajashekhara (9): 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: support for EDMA resource sharing davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 davinci: da830/omapl137: Specify reserved channels/slots davinci: da850/omapl138: Specify reserved channels/slots davinci: dm646x: Specify reserved EDMA channel/slots for DM646x arch/arm/mach-davinci/devices-da8xx.c | 191 +++++++++++++++++++++++++++-- arch/arm/mach-davinci/dm355.c | 8 -- arch/arm/mach-davinci/dm644x.c | 10 -- arch/arm/mach-davinci/dm646x.c | 33 ++++- arch/arm/mach-davinci/dma.c | 101 +++++++++++++--- arch/arm/mach-davinci/include/mach/edma.h | 4 +- 6 files changed, 291 insertions(+), 56 deletions(-) From sudhakar.raj at ti.com Wed Jan 6 05:58:36 2010 From: sudhakar.raj at ti.com (Sudhakar Rajashekhara) Date: Wed, 6 Jan 2010 17:28:36 +0530 Subject: [PATCH 1/9] davinci: Correct return value of edma_alloc_channel api Message-ID: <1262779116-25129-1-git-send-email-sudhakar.raj@ti.com> Currently, edma_alloc_channel api is returning the channel number without prepending the controller on which the channel was allocated. So, if a channel is allocated on 2nd controller, calls subsequent to edma_alloc_channel would never know that channel was allocated on the 2nd controller, and continue to operate on 1st controller, resulting in edma failure. This patch fixes this issue. Signed-off-by: Sudhakar Rajashekhara --- arch/arm/mach-davinci/dma.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index 648fbb7..5a71f4d 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -642,7 +642,7 @@ int edma_alloc_channel(int channel, map_dmach_queue(ctlr, channel, eventq_no); - return channel; + return EDMA_CTLR_CHAN(ctlr, channel); } EXPORT_SYMBOL(edma_alloc_channel); -- 1.5.6 From sudhakar.raj at ti.com Wed Jan 6 05:58:44 2010 From: sudhakar.raj at ti.com (Sudhakar Rajashekhara) Date: Wed, 6 Jan 2010 17:28:44 +0530 Subject: [PATCH 2/9] davinci: Keep count of channel controllers on a platform Message-ID: <1262779124-25156-1-git-send-email-sudhakar.raj@ti.com> Some architectures have only one channel controller, but the edma_alloc_channel api loops twice to findout the free channel available in EDMA_CHANNEL_ANY case. A new variable has been introduced to keep count of number of channel controllers being used on a particular architecture. Signed-off-by: Sudhakar Rajashekhara --- arch/arm/mach-davinci/dma.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index 5a71f4d..97a49f9 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -243,6 +243,7 @@ struct edma { }; static struct edma *edma_info[EDMA_MAX_CC]; +static int arch_num_cc; /* dummy param set used to (re)initialize parameter RAM slots */ static const struct edmacc_param dummy_paramset = { @@ -602,7 +603,7 @@ int edma_alloc_channel(int channel, } if (channel < 0) { - for (i = 0; i < EDMA_MAX_CC; i++) { + for (i = 0; i < arch_num_cc; i++) { channel = 0; for (;;) { channel = find_next_bit(edma_info[i]-> @@ -1467,6 +1468,7 @@ static int __init edma_probe(struct platform_device *pdev) edma_write_array2(j, EDMA_DRAE, i, 1, 0x0); edma_write_array(j, EDMA_QRAE, i, 0x0); } + arch_num_cc++; } if (tc_errs_handled) { -- 1.5.6 From sudhakar.raj at ti.com Wed Jan 6 05:59:11 2010 From: sudhakar.raj at ti.com (Sudhakar Rajashekhara) Date: Wed, 6 Jan 2010 17:29:11 +0530 Subject: [PATCH 3/9] davinci: Fix edma_alloc_channel api for EDMA_CHANNEL_ANY case Message-ID: <1262779151-25196-1-git-send-email-sudhakar.raj@ti.com> Though edma_alloc_channel api was looping through the available channel controllers in EDMA_CHANNEL_ANY case, it was never returning the channel for 2nd channel controller, if 1st channel controller had no free channels. This issue has been fixed with this patch. Signed-off-by: Sudhakar Rajashekhara --- arch/arm/mach-davinci/dma.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index 97a49f9..89a3dcc 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -595,7 +595,7 @@ int edma_alloc_channel(int channel, void *data, enum dma_event_q eventq_no) { - unsigned i, done, ctlr = 0; + unsigned i, done = 0, ctlr = 0; if (channel >= 0) { ctlr = EDMA_CTLR(channel); @@ -611,7 +611,7 @@ int edma_alloc_channel(int channel, edma_info[i]->num_channels, channel); if (channel == edma_info[i]->num_channels) - return -ENOMEM; + break; if (!test_and_set_bit(channel, edma_info[i]->edma_inuse)) { done = 1; @@ -623,6 +623,8 @@ int edma_alloc_channel(int channel, if (done) break; } + if (!done) + return -ENOMEM; } else if (channel >= edma_info[ctlr]->num_channels) { return -EINVAL; } else if (test_and_set_bit(channel, edma_info[ctlr]->edma_inuse)) { -- 1.5.6 From sudhakar.raj at ti.com Wed Jan 6 05:59:49 2010 From: sudhakar.raj at ti.com (Sudhakar Rajashekhara) Date: Wed, 6 Jan 2010 17:29:49 +0530 Subject: [PATCH 4/9] davinci: build list of unused EDMA events dynamically Message-ID: <1262779189-25230-1-git-send-email-sudhakar.raj@ti.com> Currently, the edma_noevent list is passed from platform data. But on some architectures, there will be many EDMA channels which will not be used at all. This patch scans all the platform devices and then builds a list of events which are not being used. The unused event list will be used to allocate EDMA channels in case of EDMA_CHANNEL_ANY usage instead of the edma_noevent being used earlier for this purpose. This patch is based on David Brownells's suggestion at http://article.gmane.org/gmane.linux.davinci/15176. Signed-off-by: Sudhakar Rajashekhara --- arch/arm/mach-davinci/devices-da8xx.c | 6 --- arch/arm/mach-davinci/dm355.c | 8 ---- arch/arm/mach-davinci/dm644x.c | 10 ----- arch/arm/mach-davinci/dm646x.c | 9 ----- arch/arm/mach-davinci/dma.c | 55 ++++++++++++++++++++++------ arch/arm/mach-davinci/include/mach/edma.h | 2 - 6 files changed, 43 insertions(+), 47 deletions(-) diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c index 0c759ad..ab12a8f 100644 --- a/arch/arm/mach-davinci/devices-da8xx.c +++ b/arch/arm/mach-davinci/devices-da8xx.c @@ -83,11 +83,6 @@ struct platform_device da8xx_serial_device = { }, }; -static const s8 da8xx_dma_chan_no_event[] = { - 20, 21, - -1 -}; - static const s8 da8xx_queue_tc_mapping[][2] = { /* {event queue no, TC no} */ {0, 0}, @@ -109,7 +104,6 @@ static struct edma_soc_info da8xx_edma_info[] = { .n_slot = 128, .n_tc = 2, .n_cc = 1, - .noevent = da8xx_dma_chan_no_event, .queue_tc_mapping = da8xx_queue_tc_mapping, .queue_priority_mapping = da8xx_queue_priority_mapping, }, diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c index 2244e8c..9b2c40e 100644 --- a/arch/arm/mach-davinci/dm355.c +++ b/arch/arm/mach-davinci/dm355.c @@ -564,13 +564,6 @@ static u8 dm355_default_priorities[DAVINCI_N_AINTC_IRQ] = { /*----------------------------------------------------------------------*/ -static const s8 dma_chan_dm355_no_event[] = { - 12, 13, 24, 56, 57, - 58, 59, 60, 61, 62, - 63, - -1 -}; - static const s8 queue_tc_mapping[][2] = { /* {event queue no, TC no} */ @@ -594,7 +587,6 @@ static struct edma_soc_info dm355_edma_info[] = { .n_slot = 128, .n_tc = 2, .n_cc = 1, - .noevent = dma_chan_dm355_no_event, .queue_tc_mapping = queue_tc_mapping, .queue_priority_mapping = queue_priority_mapping, }, diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index e65e29e..61856f8 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -479,15 +479,6 @@ static u8 dm644x_default_priorities[DAVINCI_N_AINTC_IRQ] = { /*----------------------------------------------------------------------*/ -static const s8 dma_chan_dm644x_no_event[] = { - 0, 1, 12, 13, 14, - 15, 25, 30, 31, 45, - 46, 47, 55, 56, 57, - 58, 59, 60, 61, 62, - 63, - -1 -}; - static const s8 queue_tc_mapping[][2] = { /* {event queue no, TC no} */ @@ -511,7 +502,6 @@ static struct edma_soc_info dm644x_edma_info[] = { .n_slot = 128, .n_tc = 2, .n_cc = 1, - .noevent = dma_chan_dm644x_no_event, .queue_tc_mapping = queue_tc_mapping, .queue_priority_mapping = queue_priority_mapping, }, diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index 6f80616..de306ca 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -511,14 +511,6 @@ static u8 dm646x_default_priorities[DAVINCI_N_AINTC_IRQ] = { /*----------------------------------------------------------------------*/ -static const s8 dma_chan_dm646x_no_event[] = { - 0, 1, 2, 3, 13, - 14, 15, 24, 25, 26, - 27, 30, 31, 54, 55, - 56, - -1 -}; - /* Four Transfer Controllers on DM646x */ static const s8 dm646x_queue_tc_mapping[][2] = { @@ -547,7 +539,6 @@ static struct edma_soc_info dm646x_edma_info[] = { .n_slot = 512, .n_tc = 4, .n_cc = 1, - .noevent = dma_chan_dm646x_no_event, .queue_tc_mapping = dm646x_queue_tc_mapping, .queue_priority_mapping = dm646x_queue_priority_mapping, }, diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index 89a3dcc..15dd886 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -226,11 +226,11 @@ struct edma { */ DECLARE_BITMAP(edma_inuse, EDMA_MAX_PARAMENTRY); - /* The edma_noevent bit for each channel is clear unless - * it doesn't trigger DMA events on this platform. It uses a - * bit of SOC-specific initialization code. + /* The edma_unused bit for each channel is clear unless + * it is not being used on this platform. It uses a bit + * of SOC-specific initialization code. */ - DECLARE_BITMAP(edma_noevent, EDMA_MAX_DMACH); + DECLARE_BITMAP(edma_unused, EDMA_MAX_DMACH); unsigned irq_res_start; unsigned irq_res_end; @@ -556,8 +556,27 @@ static int reserve_contiguous_slots(int ctlr, unsigned int id, return EDMA_CTLR_CHAN(ctlr, i - num_slots + 1); } +static int prepare_unused_channel_list(struct device *dev, void *data) +{ + struct platform_device *pdev = to_platform_device(dev); + int i, ctlr; + + for (i = 0; i < pdev->num_resources; i++) { + if ((pdev->resource[i].flags & IORESOURCE_DMA) && + (int)pdev->resource[i].start >= 0) { + ctlr = EDMA_CTLR(pdev->resource[i].start); + clear_bit(EDMA_CHAN_SLOT(pdev->resource[i].start), + edma_info[ctlr]->edma_unused); + } + } + + return 0; +} + /*-----------------------------------------------------------------------*/ +static bool unused_chan_list_done; + /* Resource alloc/free: dma channels, parameter RAM slots */ /** @@ -596,6 +615,21 @@ int edma_alloc_channel(int channel, enum dma_event_q eventq_no) { unsigned i, done = 0, ctlr = 0; + int ret = 0; + + if (!unused_chan_list_done) { + /* + * Scan all the platform devices to find out the EDMA channels + * used and clear them in the unused list, making the rest + * available for ARM usage. + */ + ret = bus_for_each_dev(&platform_bus_type, NULL, NULL, + prepare_unused_channel_list); + if (ret < 0) + return ret; + + unused_chan_list_done = true; + } if (channel >= 0) { ctlr = EDMA_CTLR(channel); @@ -607,7 +641,7 @@ int edma_alloc_channel(int channel, channel = 0; for (;;) { channel = find_next_bit(edma_info[i]-> - edma_noevent, + edma_unused, edma_info[i]->num_channels, channel); if (channel == edma_info[i]->num_channels) @@ -1222,7 +1256,7 @@ int edma_start(unsigned channel) unsigned int mask = (1 << (channel & 0x1f)); /* EDMA channels without event association */ - if (test_bit(channel, edma_info[ctlr]->edma_noevent)) { + if (test_bit(channel, edma_info[ctlr]->edma_unused)) { pr_debug("EDMA: ESR%d %08x\n", j, edma_shadow0_read_array(ctlr, SH_ESR, j)); edma_shadow0_write_array(ctlr, SH_ESR, j, mask); @@ -1347,7 +1381,6 @@ static int __init edma_probe(struct platform_device *pdev) const s8 (*queue_tc_mapping)[2]; int i, j, found = 0; int status = -1; - const s8 *noevent; int irq[EDMA_MAX_CC] = {0, 0}; int err_irq[EDMA_MAX_CC] = {0, 0}; struct resource *r[EDMA_MAX_CC] = {NULL}; @@ -1410,11 +1443,9 @@ static int __init edma_probe(struct platform_device *pdev) memcpy_toio(edmacc_regs_base[j] + PARM_OFFSET(i), &dummy_paramset, PARM_SIZE); - noevent = info[j].noevent; - if (noevent) { - while (*noevent != -1) - set_bit(*noevent++, edma_info[j]->edma_noevent); - } + /* Mark all channels as unused */ + memset(edma_info[j]->edma_unused, 0xff, + sizeof(edma_info[j]->edma_unused)); sprintf(irq_name, "edma%d", j); irq[j] = platform_get_irq_byname(pdev, irq_name); diff --git a/arch/arm/mach-davinci/include/mach/edma.h b/arch/arm/mach-davinci/include/mach/edma.h index eb8bfd7..ced3092 100644 --- a/arch/arm/mach-davinci/include/mach/edma.h +++ b/arch/arm/mach-davinci/include/mach/edma.h @@ -280,8 +280,6 @@ struct edma_soc_info { unsigned n_cc; enum dma_event_q default_queue; - /* list of channels with no even trigger; terminated by "-1" */ - const s8 *noevent; const s8 (*queue_tc_mapping)[2]; const s8 (*queue_priority_mapping)[2]; }; -- 1.5.6 From sudhakar.raj at ti.com Wed Jan 6 06:00:00 2010 From: sudhakar.raj at ti.com (Sudhakar Rajashekhara) Date: Wed, 6 Jan 2010 17:30:00 +0530 Subject: [PATCH 5/9] davinci: support for EDMA resource sharing Message-ID: <1262779200-25257-1-git-send-email-sudhakar.raj@ti.com> Current EDMA driver is not taking care of EDMA channels/slots which are allocated from other processor, say DSP. If a channel/slot is allocated from DSP, the existing EDMA driver can still allocate the same resource on ARM. This patch enables the user to pass the channel/slots reserved for DSP as platform data. EDMA driver scans this list during probe and prepares a bitmap of channel/slots which can be used on ARM side. Signed-off-by: Sudhakar Rajashekhara Cc: David Brownell --- arch/arm/mach-davinci/dma.c | 36 ++++++++++++++++++++++++++++- arch/arm/mach-davinci/include/mach/edma.h | 2 + 2 files changed, 37 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index 15dd886..d3e1702 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -206,6 +206,18 @@ static inline void edma_parm_or(unsigned ctlr, int offset, int param_no, edma_or(ctlr, EDMA_PARM + offset + (param_no << 5), or); } +static inline void set_bits(int offset, int len, unsigned long *p) +{ + for (; len > 0; len--) + set_bit(offset + (len - 1), p); +} + +static inline void clear_bits(int offset, int len, unsigned long *p) +{ + for (; len > 0; len--) + clear_bit(offset + (len - 1), p); +} + /*****************************************************************************/ /* actual number of DMA channels and slots on this silicon */ @@ -1379,8 +1391,10 @@ static int __init edma_probe(struct platform_device *pdev) struct edma_soc_info *info = pdev->dev.platform_data; const s8 (*queue_priority_mapping)[2]; const s8 (*queue_tc_mapping)[2]; - int i, j, found = 0; + int i, j, off, ln, found = 0; int status = -1; + const s16 (*rsv_chans)[2]; + const s16 (*rsv_slots)[2]; int irq[EDMA_MAX_CC] = {0, 0}; int err_irq[EDMA_MAX_CC] = {0, 0}; struct resource *r[EDMA_MAX_CC] = {NULL}; @@ -1447,6 +1461,26 @@ static int __init edma_probe(struct platform_device *pdev) memset(edma_info[j]->edma_unused, 0xff, sizeof(edma_info[j]->edma_unused)); + /* Clear the reserved channels in unused list */ + rsv_chans = info[j].rsv_chans; + if (rsv_chans) { + for (i = 0; rsv_chans[i][0] != -1; i++) { + off = rsv_chans[i][0]; + ln = rsv_chans[i][1]; + clear_bits(off, ln, edma_info[j]->edma_unused); + } + } + + /* Set the reserved channels/slots in inuse list */ + rsv_slots = info[j].rsv_slots; + if (rsv_slots) { + for (i = 0; rsv_slots[i][0] != -1; i++) { + off = rsv_slots[i][0]; + ln = rsv_slots[i][1]; + set_bits(off, ln, edma_info[j]->edma_inuse); + } + } + sprintf(irq_name, "edma%d", j); irq[j] = platform_get_irq_byname(pdev, irq_name); edma_info[j]->irq_res_start = irq[j]; diff --git a/arch/arm/mach-davinci/include/mach/edma.h b/arch/arm/mach-davinci/include/mach/edma.h index ced3092..55e217e 100644 --- a/arch/arm/mach-davinci/include/mach/edma.h +++ b/arch/arm/mach-davinci/include/mach/edma.h @@ -280,6 +280,8 @@ struct edma_soc_info { unsigned n_cc; enum dma_event_q default_queue; + const s16 (*rsv_chans)[2]; + const s16 (*rsv_slots)[2]; const s8 (*queue_tc_mapping)[2]; const s8 (*queue_priority_mapping)[2]; }; -- 1.5.6 From sudhakar.raj at ti.com Wed Jan 6 06:00:06 2010 From: sudhakar.raj at ti.com (Sudhakar Rajashekhara) Date: Wed, 6 Jan 2010 17:30:06 +0530 Subject: [PATCH 6/9] davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 Message-ID: <1262779206-25292-1-git-send-email-sudhakar.raj@ti.com> Currently da850/omap-l138 supports only one channel controller instance of EDMA though EDMA driver as such supports multiple channel controller instances. This patch adds platform data for the 2nd EDMA channel controller. As, the platform data differ between da830/omap-l137 and da850/omap-l138, existing code has been re-shuffled to accommodate this. Signed-off-by: Sudhakar Rajashekhara --- arch/arm/mach-davinci/devices-da8xx.c | 121 +++++++++++++++++++++++++++++++-- 1 files changed, 114 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c index ab12a8f..0a96791 100644 --- a/arch/arm/mach-davinci/devices-da8xx.c +++ b/arch/arm/mach-davinci/devices-da8xx.c @@ -24,8 +24,10 @@ #include "clock.h" #define DA8XX_TPCC_BASE 0x01c00000 +#define DA850_TPCC1_BASE 0x01e30000 #define DA8XX_TPTC0_BASE 0x01c08000 #define DA8XX_TPTC1_BASE 0x01c08400 +#define DA850_TPTC2_BASE 0x01e38000 #define DA8XX_WDOG_BASE 0x01c21000 /* DA8XX_TIMER64P1_BASE */ #define DA8XX_I2C0_BASE 0x01c22000 #define DA8XX_RTC_BASE 0x01C23000 @@ -97,7 +99,31 @@ static const s8 da8xx_queue_priority_mapping[][2] = { {-1, -1} }; -static struct edma_soc_info da8xx_edma_info[] = { +static const s8 da850_queue_tc_mapping[][2] = { + /* {event queue no, TC no} */ + {0, 0}, + {-1, -1} +}; + +static const s8 da850_queue_priority_mapping[][2] = { + /* {event queue no, Priority} */ + {0, 3}, + {-1, -1} +}; + +static struct edma_soc_info da830_edma_info[] = { + { + .n_channel = 32, + .n_region = 4, + .n_slot = 128, + .n_tc = 2, + .n_cc = 1, + .queue_tc_mapping = da8xx_queue_tc_mapping, + .queue_priority_mapping = da8xx_queue_priority_mapping, + }, +}; + +static struct edma_soc_info da850_edma_info[] = { { .n_channel = 32, .n_region = 4, @@ -107,9 +133,49 @@ static struct edma_soc_info da8xx_edma_info[] = { .queue_tc_mapping = da8xx_queue_tc_mapping, .queue_priority_mapping = da8xx_queue_priority_mapping, }, + { + .n_channel = 32, + .n_region = 4, + .n_slot = 128, + .n_tc = 1, + .n_cc = 1, + .queue_tc_mapping = da850_queue_tc_mapping, + .queue_priority_mapping = da850_queue_priority_mapping, + }, +}; + +static struct resource da830_edma_resources[] = { + { + .name = "edma_cc0", + .start = DA8XX_TPCC_BASE, + .end = DA8XX_TPCC_BASE + SZ_32K - 1, + .flags = IORESOURCE_MEM, + }, + { + .name = "edma_tc0", + .start = DA8XX_TPTC0_BASE, + .end = DA8XX_TPTC0_BASE + SZ_1K - 1, + .flags = IORESOURCE_MEM, + }, + { + .name = "edma_tc1", + .start = DA8XX_TPTC1_BASE, + .end = DA8XX_TPTC1_BASE + SZ_1K - 1, + .flags = IORESOURCE_MEM, + }, + { + .name = "edma0", + .start = IRQ_DA8XX_CCINT0, + .flags = IORESOURCE_IRQ, + }, + { + .name = "edma0_err", + .start = IRQ_DA8XX_CCERRINT, + .flags = IORESOURCE_IRQ, + }, }; -static struct resource da8xx_edma_resources[] = { +static struct resource da850_edma_resources[] = { { .name = "edma_cc0", .start = DA8XX_TPCC_BASE, @@ -129,6 +195,18 @@ static struct resource da8xx_edma_resources[] = { .flags = IORESOURCE_MEM, }, { + .name = "edma_cc1", + .start = DA850_TPCC1_BASE, + .end = DA850_TPCC1_BASE + SZ_32K - 1, + .flags = IORESOURCE_MEM, + }, + { + .name = "edma_tc2", + .start = DA850_TPTC2_BASE, + .end = DA850_TPTC2_BASE + SZ_1K - 1, + .flags = IORESOURCE_MEM, + }, + { .name = "edma0", .start = IRQ_DA8XX_CCINT0, .flags = IORESOURCE_IRQ, @@ -138,21 +216,50 @@ static struct resource da8xx_edma_resources[] = { .start = IRQ_DA8XX_CCERRINT, .flags = IORESOURCE_IRQ, }, + { + .name = "edma1", + .start = IRQ_DA850_CCINT1, + .flags = IORESOURCE_IRQ, + }, + { + .name = "edma1_err", + .start = IRQ_DA850_CCERRINT1, + .flags = IORESOURCE_IRQ, + }, +}; + +static struct platform_device da830_edma_device = { + .name = "edma", + .id = -1, + .dev = { + .platform_data = da830_edma_info, + }, + .num_resources = ARRAY_SIZE(da830_edma_resources), + .resource = da830_edma_resources, }; -static struct platform_device da8xx_edma_device = { +static struct platform_device da850_edma_device = { .name = "edma", .id = -1, .dev = { - .platform_data = da8xx_edma_info, + .platform_data = da850_edma_info, }, - .num_resources = ARRAY_SIZE(da8xx_edma_resources), - .resource = da8xx_edma_resources, + .num_resources = ARRAY_SIZE(da850_edma_resources), + .resource = da850_edma_resources, }; int __init da8xx_register_edma(void) { - return platform_device_register(&da8xx_edma_device); + struct platform_device *pdev; + + if (cpu_is_davinci_da830()) + pdev = &da830_edma_device; + else if (cpu_is_davinci_da850()) + pdev = &da850_edma_device; + else + return -ENODEV; + + return platform_device_register(pdev); } static struct resource da8xx_i2c_resources0[] = { -- 1.5.6 From sudhakar.raj at ti.com Wed Jan 6 06:00:14 2010 From: sudhakar.raj at ti.com (Sudhakar Rajashekhara) Date: Wed, 6 Jan 2010 17:30:14 +0530 Subject: [PATCH v2 7/9] davinci: da830/omapl137: Specify reserved channels/slots Message-ID: <1262779214-25318-1-git-send-email-sudhakar.raj@ti.com> Pass reserved EDMA channel/slots as platform data for da830/omap-l137. Signed-off-by: Sudhakar Rajashekhara --- arch/arm/mach-davinci/devices-da8xx.c | 25 +++++++++++++++++++++++++ 1 files changed, 25 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c index 0a96791..e32579f 100644 --- a/arch/arm/mach-davinci/devices-da8xx.c +++ b/arch/arm/mach-davinci/devices-da8xx.c @@ -111,6 +111,29 @@ static const s8 da850_queue_priority_mapping[][2] = { {-1, -1} }; +/* + * The following EDMA channels/slots are not being used by drivers (for + * example: Timer, GPIO, UART events etc) on da830/omap-l137, hence they + * are being reserved for codecs on the DSP side. + */ +static const s16 da830_dma_rsv_chans[][2] = { + /* (offset, number) */ + { 8, 2}, + {12, 2}, + {24, 4}, + {30, 2}, + {-1, -1} +}; + +static const s16 da830_dma_rsv_slots[][2] = { + /* (offset, number) */ + { 8, 2}, + {12, 2}, + {24, 4}, + {30, 26}, + {-1, -1} +}; + static struct edma_soc_info da830_edma_info[] = { { .n_channel = 32, @@ -118,6 +141,8 @@ static struct edma_soc_info da830_edma_info[] = { .n_slot = 128, .n_tc = 2, .n_cc = 1, + .rsv_chans = da830_dma_rsv_chans, + .rsv_slots = da830_dma_rsv_slots, .queue_tc_mapping = da8xx_queue_tc_mapping, .queue_priority_mapping = da8xx_queue_priority_mapping, }, -- 1.5.6 From sudhakar.raj at ti.com Wed Jan 6 06:00:19 2010 From: sudhakar.raj at ti.com (Sudhakar Rajashekhara) Date: Wed, 6 Jan 2010 17:30:19 +0530 Subject: [PATCH v2 8/9] davinci: da850/omapl138: Specify reserved channels/slots Message-ID: <1262779219-25341-1-git-send-email-sudhakar.raj@ti.com> Pass reserved EDMA channel/slots as platform data for da850/omap-l138. Signed-off-by: Sudhakar Rajashekhara --- arch/arm/mach-davinci/devices-da8xx.c | 39 +++++++++++++++++++++++++++++++++ 1 files changed, 39 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c index e32579f..7739391 100644 --- a/arch/arm/mach-davinci/devices-da8xx.c +++ b/arch/arm/mach-davinci/devices-da8xx.c @@ -134,6 +134,41 @@ static const s16 da830_dma_rsv_slots[][2] = { {-1, -1} }; +/* + * The following EDMA channels/slots are not being used by drivers (for + * example: Timer, GPIO, UART events etc) on da850/omap-l138, hence they + * are being reserved for codecs on the DSP side. + */ +static const s16 da850_dma0_rsv_chans[][2] = { + /* (offset, number) */ + { 8, 6}, + {24, 4}, + {30, 2}, + {-1, -1} +}; + +static const s16 da850_dma0_rsv_slots[][2] = { + /* (offset, number) */ + { 8, 6}, + {24, 4}, + {30, 50}, + {-1, -1} +}; + +static const s16 da850_dma1_rsv_chans[][2] = { + /* (offset, number) */ + { 0, 28}, + {30, 2}, + {-1, -1} +}; + +static const s16 da850_dma1_rsv_slots[][2] = { + /* (offset, number) */ + { 0, 28}, + {30, 90}, + {-1, -1} +}; + static struct edma_soc_info da830_edma_info[] = { { .n_channel = 32, @@ -155,6 +190,8 @@ static struct edma_soc_info da850_edma_info[] = { .n_slot = 128, .n_tc = 2, .n_cc = 1, + .rsv_chans = da850_dma0_rsv_chans, + .rsv_slots = da850_dma0_rsv_slots, .queue_tc_mapping = da8xx_queue_tc_mapping, .queue_priority_mapping = da8xx_queue_priority_mapping, }, @@ -164,6 +201,8 @@ static struct edma_soc_info da850_edma_info[] = { .n_slot = 128, .n_tc = 1, .n_cc = 1, + .rsv_chans = da850_dma1_rsv_chans, + .rsv_slots = da850_dma1_rsv_slots, .queue_tc_mapping = da850_queue_tc_mapping, .queue_priority_mapping = da850_queue_priority_mapping, }, -- 1.5.6 From sudhakar.raj at ti.com Wed Jan 6 06:00:25 2010 From: sudhakar.raj at ti.com (Sudhakar Rajashekhara) Date: Wed, 6 Jan 2010 17:30:25 +0530 Subject: [PATCH v2 9/9] davinci: dm646x: Specify reserved EDMA channel/slots for DM646x Message-ID: <1262779225-25368-1-git-send-email-sudhakar.raj@ti.com> Pass reserved EDMA channel/slots as platform data for dm646x. Signed-off-by: Sudhakar Rajashekhara --- arch/arm/mach-davinci/dm646x.c | 28 ++++++++++++++++++++++++++++ 1 files changed, 28 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index de306ca..99224ec 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -511,6 +511,32 @@ static u8 dm646x_default_priorities[DAVINCI_N_AINTC_IRQ] = { /*----------------------------------------------------------------------*/ +/* + * The following EDMA channels/slots are not being used by drivers (for + * example: Timer, GPIO, UART events etc) on dm646x, hence they are being + * reserved for codecs on the DSP side. + */ +static const s16 dm646x_dma_rsv_chans[][2] = { + /* (offset, number) */ + { 0, 4}, + {13, 3}, + {24, 4}, + {30, 2}, + {54, 3}, + {-1, -1} +}; + +static const s16 dm646x_dma_rsv_slots[][2] = { + /* (offset, number) */ + { 0, 4}, + {13, 3}, + {24, 4}, + {30, 2}, + {54, 3}, + {128, 384}, + {-1, -1} +}; + /* Four Transfer Controllers on DM646x */ static const s8 dm646x_queue_tc_mapping[][2] = { @@ -539,6 +565,8 @@ static struct edma_soc_info dm646x_edma_info[] = { .n_slot = 512, .n_tc = 4, .n_cc = 1, + .rsv_chans = dm646x_dma_rsv_chans, + .rsv_slots = dm646x_dma_rsv_slots, .queue_tc_mapping = dm646x_queue_tc_mapping, .queue_priority_mapping = dm646x_queue_priority_mapping, }, -- 1.5.6 From aelder at audioscience.com Wed Jan 6 07:58:10 2010 From: aelder at audioscience.com (Andrew Elder) Date: Wed, 06 Jan 2010 08:58:10 -0500 Subject: Audio quality with CPU frequency scaling In-Reply-To: <87pr5oqfz5.fsf@deeprootsystems.com> References: <02a001ca7e38$6f1eac70$4d5c0550$@com> <87pr5oqfz5.fsf@deeprootsystems.com> Message-ID: <4B4496F2.4000801@audioscience.com> Something doesn't make sense. Say we take a case stated not to work, ie 16 kHz with CPU at 96 MHz. If we assume stereo input and output running at simultaneously we have 16000 samples/sec x 4 audio channel x 1 EDMA transfer/audio channel = 64,000 EDMA transfer/second Give a clock rate of 96 MHz that is 96,000,000 / 64,000 = 1,500 CPU cycles per EDMA transfer. In my opinion there is something else going on. - Andrew Kevin Hilman wrote: > "Chaithrika U S" writes: > > >> Kevin, >> >> With the cpufreq support on DA850/OMAP-L138 SoC we are observing >> that audio does not function as expected at all sampling rates >> for various operating points. At a CPU frequency of 96MHz, audio >> works fine with a sampling frequency of 8kHz. For other sampling >> rates, there are lot of underrun/overrun errors. This is because >> of EDMA also runs at a lower speed and is not able to transfer >> data at the desired rate. >> >> To overcome the above, we can depend on the user to set the scaling >> min frequency to be the same as scaling max frequency (in this case >> 300 MHz) before starting aplay/arecord or temporarily move to >> performance governor so that the audio quality is not affected. >> >> Do you think this is the right approach to this problem? Any other >> solutions you suggest exploring? >> > > An alternative to relying on the user to change the CPUfreq policy is > to have the audio driver itself do that. Based on the sample rate and > clock frequency, the audio driver should be able to determine that the > EDMA rate will not be fast enough and set a CPUfreq policy so that > lower frequencies are not attempted. When the audio driver is done, > it can set the policy back. > > Kevin > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From premi at ti.com Wed Jan 6 08:41:27 2010 From: premi at ti.com (Premi, Sanjeev) Date: Wed, 6 Jan 2010 20:11:27 +0530 Subject: Audio quality with CPU frequency scaling In-Reply-To: <87pr5oqfz5.fsf@deeprootsystems.com> Message-ID: > -----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: Wednesday, January 06, 2010 5:09 AM > To: Subrahmanya, Chaithrika > Cc: davinci-linux-open-source at linux.davincidsp.com > Subject: Re: Audio quality with CPU frequency scaling > > "Chaithrika U S" writes: > > > Kevin, > > > > With the cpufreq support on DA850/OMAP-L138 SoC we are observing > > that audio does not function as expected at all sampling rates > > for various operating points. At a CPU frequency of 96MHz, audio > > works fine with a sampling frequency of 8kHz. For other sampling > > rates, there are lot of underrun/overrun errors. This is because > > of EDMA also runs at a lower speed and is not able to transfer > > data at the desired rate. > > > > To overcome the above, we can depend on the user to set the scaling > > min frequency to be the same as scaling max frequency (in this case > > 300 MHz) before starting aplay/arecord or temporarily move to > > performance governor so that the audio quality is not affected. > > > > Do you think this is the right approach to this problem? Any other > > solutions you suggest exploring? > > An alternative to relying on the user to change the CPUfreq policy is > to have the audio driver itself do that. Based on the sample rate and > clock frequency, the audio driver should be able to determine that the > EDMA rate will not be fast enough and set a CPUfreq policy so that > lower frequencies are not attempted. When the audio driver is done, > it can set the policy back. Kevin, Wouldn't this mean that driver is directly influencing the policy? Best regards, Sanjeev > > Kevin > > _______________________________________________ > 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 Wed Jan 6 08:44:53 2010 From: m-karicheri2 at ti.com (Karicheri, Muralidharan) Date: Wed, 6 Jan 2010 08:44:53 -0600 Subject: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver In-Reply-To: <871vi4rv25.fsf@deeprootsystems.com> References: <1260895054-13232-1-git-send-email-m-karicheri2@ti.com> <871vi4rv25.fsf@deeprootsystems.com> Message-ID: >> CLK(NULL, "rto", &rto_clk), >> CLK(NULL, "usb", &usb_clk), >> + CLK("dm355_ccdc", "master", &vpss_master_clk), >> + CLK("dm355_ccdc", "slave", &vpss_slave_clk), > >I still don't understand why you have to add new entries here and >can't simply rename the existing CLK nodes using vpss_*_clk. > [MK] This will allow multiple drivers define their own clocks derived from these. ccdc driver is not the only driver using these clocks. Your earlier suggestion was to use as follows :- - CLK(NULL, "vpss_master", &vpss_master_clk), - CLK(NULL, "vpss_slave", &vpss_slave_clk), + CLK("vpfe-capture", "master", &vpss_master_clk), + CLK("vpfe-capture", "slave", &vpss_slave_clk), I am not sure if the following will work so that it can be used across multiple drivers. + CLK(NULL, "master", &vpss_master_clk), + CLK(NULL, "slave", &vpss_slave_clk), If yes, I can re-do this patch. Please confirm. >Same comment for dm644x.c changes. > >Kevin > >> CLK(NULL, NULL, NULL), >> }; >> >> @@ -665,6 +667,17 @@ static struct platform_device dm355_asp1_device = { >> .resource = dm355_asp1_resources, >> }; >> >> +static void dm355_ccdc_setup_pinmux(void) >> +{ >> + davinci_cfg_reg(DM355_VIN_PCLK); >> + davinci_cfg_reg(DM355_VIN_CAM_WEN); >> + davinci_cfg_reg(DM355_VIN_CAM_VD); >> + davinci_cfg_reg(DM355_VIN_CAM_HD); >> + davinci_cfg_reg(DM355_VIN_YIN_EN); >> + davinci_cfg_reg(DM355_VIN_CINL_EN); >> + davinci_cfg_reg(DM355_VIN_CINH_EN); >> +} >> + >> static struct resource dm355_vpss_resources[] = { >> { >> /* VPSS BL Base address */ >> @@ -701,6 +714,10 @@ static struct resource vpfe_resources[] = { >> .end = IRQ_VDINT1, >> .flags = IORESOURCE_IRQ, >> }, >> +}; >> + >> +static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32); >> +static struct resource dm355_ccdc_resource[] = { >> /* CCDC Base address */ >> { >> .flags = IORESOURCE_MEM, >> @@ -708,8 +725,18 @@ static struct resource vpfe_resources[] = { >> .end = 0x01c70600 + 0x1ff, >> }, >> }; >> +static struct platform_device dm355_ccdc_dev = { >> + .name = "dm355_ccdc", >> + .id = -1, >> + .num_resources = ARRAY_SIZE(dm355_ccdc_resource), >> + .resource = dm355_ccdc_resource, >> + .dev = { >> + .dma_mask = &vpfe_capture_dma_mask, >> + .coherent_dma_mask = DMA_BIT_MASK(32), >> + .platform_data = dm355_ccdc_setup_pinmux, >> + }, >> +}; >> >> -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32); >> static struct platform_device vpfe_capture_dev = { >> .name = CAPTURE_DRV_NAME, >> .id = -1, >> @@ -860,17 +887,7 @@ static int __init dm355_init_devices(void) >> davinci_cfg_reg(DM355_INT_EDMA_CC); >> platform_device_register(&dm355_edma_device); >> platform_device_register(&dm355_vpss_device); >> - /* >> - * setup Mux configuration for vpfe input and register >> - * vpfe capture platform device >> - */ >> - davinci_cfg_reg(DM355_VIN_PCLK); >> - davinci_cfg_reg(DM355_VIN_CAM_WEN); >> - davinci_cfg_reg(DM355_VIN_CAM_VD); >> - davinci_cfg_reg(DM355_VIN_CAM_HD); >> - davinci_cfg_reg(DM355_VIN_YIN_EN); >> - davinci_cfg_reg(DM355_VIN_CINL_EN); >> - davinci_cfg_reg(DM355_VIN_CINH_EN); >> + platform_device_register(&dm355_ccdc_dev); >> platform_device_register(&vpfe_capture_dev); >> >> return 0; >> diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach- >davinci/dm644x.c >> index e65e29e..e5f1ee9 100644 >> --- a/arch/arm/mach-davinci/dm644x.c >> +++ b/arch/arm/mach-davinci/dm644x.c >> @@ -315,6 +315,8 @@ struct davinci_clk dm644x_clks[] = { >> CLK(NULL, "timer0", &timer0_clk), >> CLK(NULL, "timer1", &timer1_clk), >> CLK("watchdog", NULL, &timer2_clk), >> + CLK("dm644x_ccdc", "master", &vpss_master_clk), >> + CLK("dm644x_ccdc", "slave", &vpss_slave_clk), >> CLK(NULL, NULL, NULL), >> }; >> >> @@ -612,6 +614,11 @@ static struct resource vpfe_resources[] = { >> .end = IRQ_VDINT1, >> .flags = IORESOURCE_IRQ, >> }, >> +}; >> + >> +static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32); >> +static struct resource dm644x_ccdc_resource[] = { >> + /* CCDC Base address */ >> { >> .start = 0x01c70400, >> .end = 0x01c70400 + 0xff, >> @@ -619,7 +626,17 @@ static struct resource vpfe_resources[] = { >> }, >> }; >> >> -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32); >> +static struct platform_device dm644x_ccdc_dev = { >> + .name = "dm644x_ccdc", >> + .id = -1, >> + .num_resources = ARRAY_SIZE(dm644x_ccdc_resource), >> + .resource = dm644x_ccdc_resource, >> + .dev = { >> + .dma_mask = &vpfe_capture_dma_mask, >> + .coherent_dma_mask = DMA_BIT_MASK(32), >> + }, >> +}; >> + >> static struct platform_device vpfe_capture_dev = { >> .name = CAPTURE_DRV_NAME, >> .id = -1, >> @@ -772,6 +789,7 @@ static int __init dm644x_init_devices(void) >> platform_device_register(&dm644x_edma_device); >> platform_device_register(&dm644x_emac_device); >> platform_device_register(&dm644x_vpss_device); >> + platform_device_register(&dm644x_ccdc_dev); >> platform_device_register(&vpfe_capture_dev); >> >> return 0; >> -- >> 1.6.0.4 From khilman at deeprootsystems.com Wed Jan 6 09:10:18 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 06 Jan 2010 07:10:18 -0800 Subject: [PATCH] Fixed comments for the response registers. They were all saying Regiser 0 and 1. In-Reply-To: <1262745269-12102-1-git-send-email-raghav.moko@gmail.com> (raghav's message of "Wed\, 6 Jan 2010 08\:04\:29 +0530") References: <1262745269-12102-1-git-send-email-raghav.moko@gmail.com> Message-ID: <87d41nnuat.fsf@deeprootsystems.com> raghav writes: Missing changelog and signoff. Also, subject should be something like: [PATCH] MMC: davinci: fix some comment typos and the changelog should include a more detailed description. Kevin > --- > drivers/mmc/host/davinci_mmc.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c > index dd45e7c..73a6a14 100644 > --- a/drivers/mmc/host/davinci_mmc.c > +++ b/drivers/mmc/host/davinci_mmc.c > @@ -54,9 +54,9 @@ > #define DAVINCI_MMCCMD 0x30 /* Command Register */ > #define DAVINCI_MMCARGHL 0x34 /* Argument Register */ > #define DAVINCI_MMCRSP01 0x38 /* Response Register 0 and 1 */ > -#define DAVINCI_MMCRSP23 0x3C /* Response Register 0 and 1 */ > -#define DAVINCI_MMCRSP45 0x40 /* Response Register 0 and 1 */ > -#define DAVINCI_MMCRSP67 0x44 /* Response Register 0 and 1 */ > +#define DAVINCI_MMCRSP23 0x3C /* Response Register 2 and 3 */ > +#define DAVINCI_MMCRSP45 0x40 /* Response Register 4 and 5 */ > +#define DAVINCI_MMCRSP67 0x44 /* Response Register 6 and 7 */ > #define DAVINCI_MMCDRSP 0x48 /* Data Response Register */ > #define DAVINCI_MMCETOK 0x4C > #define DAVINCI_MMCCIDX 0x50 /* Command Index Register */ > -- > 1.6.0.4 From khilman at deeprootsystems.com Wed Jan 6 09:16:25 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 06 Jan 2010 07:16:25 -0800 Subject: [PATCH v2] i2c: Davinci i2c bus recovery procedure to clear the bus In-Reply-To: <1262777615.3581.16.camel@localhost.localdomain> (Philby John's message of "Wed\, 06 Jan 2010 17\:03\:35 +0530") References: <1262777615.3581.16.camel@localhost.localdomain> Message-ID: <878wcbnu0m.fsf@deeprootsystems.com> Philby John writes: >>From 0372e68cfd14ab37595498234abe39f2f10787d5 Mon Sep 17 00:00:00 2001 > From: Philby John > Date: Mon, 23 Nov 2009 18:08:33 +0530 > Subject: [PATCH] Davinci i2c bus recovery procedure to clear the bus > > Come out of i2c time out condition by following the > bus recovery procedure outlined in the i2c protocol v3 spec. > The kernel must be robust enough to gracefully recover > from i2c bus failure without having to reset the machine. > This is done by first NACKing the slave, pulsing the SCL > line 9 times and then sending the stop command. > > This patch has been tested on a DM6446 and DM355 > > Signed-off-by: Philby John > Signed-off-by: Srinivasan, Nageswari For v3, can you break this up into two patches. One for adding the new members to the pdata struct (this will go upstream via davinci git) and another with the i2c driver changes itself (this will go upstream via i2c subsystem.) Kevin > --- > TODO: Need to add SDA and SCL pin numbers to the respective > platforms such as dm355-leopard, dm365, dm646x, da8xx etc. > What I have info on is limited to just dm355 and dm6446. > arch/arm/mach-davinci/board-dm355-evm.c | 2 + > arch/arm/mach-davinci/board-dm644x-evm.c | 2 + > arch/arm/mach-davinci/include/mach/i2c.h | 2 + > drivers/i2c/busses/i2c-davinci.c | 60 +++++++++++++++++++++++++++--- > 4 files changed, 60 insertions(+), 6 deletions(-) > > diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c > index a9b650d..a20b2de 100644 > --- a/arch/arm/mach-davinci/board-dm355-evm.c > +++ b/arch/arm/mach-davinci/board-dm355-evm.c > @@ -111,6 +111,8 @@ static struct platform_device davinci_nand_device = { > static struct davinci_i2c_platform_data i2c_pdata = { > .bus_freq = 400 /* kHz */, > .bus_delay = 0 /* usec */, > + .sda_pin = 15, > + .scl_pin = 14, > }; > > static struct snd_platform_data dm355_evm_snd_data; > diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c > index fd0398b..b5ce36b 100644 > --- a/arch/arm/mach-davinci/board-dm644x-evm.c > +++ b/arch/arm/mach-davinci/board-dm644x-evm.c > @@ -628,6 +628,8 @@ static struct i2c_board_info __initdata i2c_info[] = { > static struct davinci_i2c_platform_data i2c_pdata = { > .bus_freq = 20 /* kHz */, > .bus_delay = 100 /* usec */, > + .sda_pin = 44, > + .scl_pin = 43, > }; > > static void __init evm_init_i2c(void) > diff --git a/arch/arm/mach-davinci/include/mach/i2c.h b/arch/arm/mach-davinci/include/mach/i2c.h > index c248e9b..21be118 100644 > --- a/arch/arm/mach-davinci/include/mach/i2c.h > +++ b/arch/arm/mach-davinci/include/mach/i2c.h > @@ -16,6 +16,8 @@ > struct davinci_i2c_platform_data { > unsigned int bus_freq; /* standard bus frequency (kHz) */ > unsigned int bus_delay; /* post-transaction delay (usec) */ > + unsigned int sda_pin; /* GPIO pin ID to use for SDA */ > + unsigned int scl_pin; /* GPIO pin ID to use for SCL */ > }; > > /* for board setup code */ > diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c > index 67d88cc..be18cab 100644 > --- a/drivers/i2c/busses/i2c-davinci.c > +++ b/drivers/i2c/busses/i2c-davinci.c > @@ -35,6 +35,7 @@ > #include > #include > #include > +#include > > #include > > @@ -43,6 +44,7 @@ > /* ----- global defines ----------------------------------------------- */ > > #define DAVINCI_I2C_TIMEOUT (1*HZ) > +#define DAVINCI_I2C_MAX_TRIES 2 > #define I2C_DAVINCI_INTR_ALL (DAVINCI_I2C_IMR_AAS | \ > DAVINCI_I2C_IMR_SCD | \ > DAVINCI_I2C_IMR_ARDY | \ > @@ -134,6 +136,44 @@ static inline u16 davinci_i2c_read_reg(struct davinci_i2c_dev *i2c_dev, int reg) > return __raw_readw(i2c_dev->base + reg); > } > > +/* 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); > + } > + } > +} > + > +/* This routine does i2c bus recovery as specified in the > + * i2c protocol Rev. 03 section 3.16 titled "Bus clear" > + */ > +static void i2c_recover_bus(struct davinci_i2c_dev *dev) > +{ > + u32 flag = 0; > + struct davinci_i2c_platform_data *pdata = dev->dev->platform_data; > + > + dev_err(dev->dev, "initiating i2c bus recovery\n"); > + /* Send NACK to the slave */ > + flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG); > + flag |= DAVINCI_I2C_MDR_NACK; > + /* write the data into mode register */ > + davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag); > + if (pdata) > + generic_i2c_clock_pulse(pdata->scl_pin); > + /* Send STOP */ > + flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG); > + MOD_REG_BIT(flag, DAVINCI_I2C_MDR_STP, 1); > + davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag); > +} > + > /* > * This functions configures I2C and brings I2C out of reset. > * This function is called during I2C init function. This function > @@ -221,19 +261,26 @@ static int i2c_davinci_wait_bus_not_busy(struct davinci_i2c_dev *dev, > char allow_sleep) > { > unsigned long timeout; > + static u16 to_cnt = 0; > > timeout = jiffies + dev->adapter.timeout; > while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG) > - & DAVINCI_I2C_STR_BB) { > - if (time_after(jiffies, timeout)) { > - dev_warn(dev->dev, > - "timeout waiting for bus ready\n"); > - return -ETIMEDOUT; > + & DAVINCI_I2C_STR_BB) { > + if (to_cnt <= DAVINCI_I2C_MAX_TRIES) { > + if (time_after(jiffies, timeout)) { > + dev_warn(dev->dev, > + "timeout waiting for bus ready\n"); > + to_cnt++; > + return -ETIMEDOUT; > + } else { > + to_cnt = 0; > + i2c_recover_bus(dev); > + i2c_davinci_init(dev); > + } > } > if (allow_sleep) > schedule_timeout(1); > } > - > return 0; > } > > @@ -310,6 +357,7 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop) > dev->adapter.timeout); > if (r == 0) { > dev_err(dev->dev, "controller timed out\n"); > + i2c_recover_bus(dev); > i2c_davinci_init(dev); > dev->buf_len = 0; > return -ETIMEDOUT; > -- > 1.6.3.3.MVISTA > > > > _______________________________________________ > 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 guillaume.gardet at cioinfoindus.fr Wed Jan 6 09:20:20 2010 From: guillaume.gardet at cioinfoindus.fr (Guillaume GARDET) Date: Wed, 06 Jan 2010 16:20:20 +0100 Subject: TVP5158 and DaVinci Message-ID: <4B44AA34.7070300@cioinfoindus.fr> Hi all, Is there someone who manage/try to use a TVP5158 with a DaVinci (DM6467 or another) ? TI provides a driver for the Montavista 2.6.10 and I try to use it with 2.6.18 with some modifications but no success. It compiles and run but I cannot use the test program since it need a display that I have not on my board. Moreover the DMA test crashes the system. Is there a driver for the arago kernel ? Regards, Guillaume From khilman at deeprootsystems.com Wed Jan 6 09:24:01 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 06 Jan 2010 07:24:01 -0800 Subject: [PATCH v3 0/4] i2c: davinci: Add power management features In-Reply-To: <1262769900-2710-1-git-send-email-chaithrika@ti.com> (Chaithrika U. S.'s message of "Wed\, 6 Jan 2010 14\:54\:56 +0530") References: <1262769900-2710-1-git-send-email-chaithrika@ti.com> Message-ID: <871vi3ntny.fsf@deeprootsystems.com> Chaithrika U S writes: > Add suspend/resume and cpufreq features to DaVinci I2C driver > All patches apply to Linus' kernel tree. > Testing of these features was done on DA850/OMAP-L138 EVM. > > Chaithrika U S (4): > i2c: davinci: Remove MOD_REG_BIT and IO_ADDRESS usage > i2c: davinci: Add helper functions > i2c: davinci: Add suspend/resume support > i2c: davinci: Add cpufreq support > > drivers/i2c/busses/i2c-davinci.c | 228 ++++++++++++++++++++++++++++--------- > 1 files changed, 172 insertions(+), 56 deletions(-) > > In this version, the suspend/resume support patch has been updated to > use dev_pm_ops. Acked-by: Kevin Hilman Ben, please queue this series for 2.6.34. Thanks, Kevin From pjohn at in.mvista.com Wed Jan 6 09:28:20 2010 From: pjohn at in.mvista.com (Philby John) Date: Wed, 06 Jan 2010 20:58:20 +0530 Subject: [PATCH v2] i2c: Davinci i2c bus recovery procedure to clear the bus In-Reply-To: <878wcbnu0m.fsf@deeprootsystems.com> References: <1262777615.3581.16.camel@localhost.localdomain> <878wcbnu0m.fsf@deeprootsystems.com> Message-ID: <1262791700.3581.69.camel@localhost.localdomain> On Wed, 2010-01-06 at 07:16 -0800, Kevin Hilman wrote: > Philby John writes: > > >>From 0372e68cfd14ab37595498234abe39f2f10787d5 Mon Sep 17 00:00:00 2001 > > From: Philby John > > Date: Mon, 23 Nov 2009 18:08:33 +0530 > > Subject: [PATCH] Davinci i2c bus recovery procedure to clear the bus > > > > Come out of i2c time out condition by following the > > bus recovery procedure outlined in the i2c protocol v3 spec. > > The kernel must be robust enough to gracefully recover > > from i2c bus failure without having to reset the machine. > > This is done by first NACKing the slave, pulsing the SCL > > line 9 times and then sending the stop command. > > > > This patch has been tested on a DM6446 and DM355 > > > > Signed-off-by: Philby John > > Signed-off-by: Srinivasan, Nageswari > > For v3, can you break this up into two patches. One for adding the > new members to the pdata struct (this will go upstream via davinci > git) and another with the i2c driver changes itself (this will go > upstream via i2c subsystem.) > Ok, will do that then. Regards, Philby From khilman at deeprootsystems.com Wed Jan 6 09:37:07 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 06 Jan 2010 07:37:07 -0800 Subject: [PATCH v2 1/2] davinci: MMC: Add a function to control reset state of the controller In-Reply-To: <1262770489-9486-1-git-send-email-chaithrika@ti.com> (Chaithrika U. S.'s message of "Wed\, 6 Jan 2010 15\:04\:48 +0530") References: <1262770489-9486-1-git-send-email-chaithrika@ti.com> Message-ID: <87r5q3meho.fsf@deeprootsystems.com> Chaithrika U S writes: > Add a helper function which will aid in changing the reset > status of the controller. > > Signed-off-by: Chaithrika U S > Signed-off-by: Kevin Hilman my s-o-b should actually be: Acked-by: Kevin Hilman > --- > Applies to Linus' kernel tree > > drivers/mmc/host/davinci_mmc.c | 37 ++++++++++++++++--------------------- > 1 files changed, 16 insertions(+), 21 deletions(-) > > diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c > index dd45e7c..25645bf 100644 > --- a/drivers/mmc/host/davinci_mmc.c > +++ b/drivers/mmc/host/davinci_mmc.c > @@ -884,19 +884,26 @@ static void mmc_davinci_cmd_done(struct mmc_davinci_host *host, > } > } > > -static void > -davinci_abort_data(struct mmc_davinci_host *host, struct mmc_data *data) > +static inline void mmc_davinci_reset_ctrl(struct mmc_davinci_host *host, > + int val) > { > u32 temp; > > - /* reset command and data state machines */ > temp = readl(host->base + DAVINCI_MMCCTL); > - writel(temp | MMCCTL_CMDRST | MMCCTL_DATRST, > - host->base + DAVINCI_MMCCTL); > + if (val) /* reset */ > + temp |= MMCCTL_CMDRST | MMCCTL_DATRST; > + else /* enable */ > + temp &= ~(MMCCTL_CMDRST | MMCCTL_DATRST); > > - temp &= ~(MMCCTL_CMDRST | MMCCTL_DATRST); > - udelay(10); > writel(temp, host->base + DAVINCI_MMCCTL); > + udelay(10); > +} > + > +static void > +davinci_abort_data(struct mmc_davinci_host *host, struct mmc_data *data) > +{ > + mmc_davinci_reset_ctrl(host, 1); > + mmc_davinci_reset_ctrl(host, 0); > } > > static irqreturn_t mmc_davinci_irq(int irq, void *dev_id) > @@ -1100,15 +1107,8 @@ static inline void mmc_davinci_cpufreq_deregister(struct mmc_davinci_host *host) > #endif > static void __init init_mmcsd_host(struct mmc_davinci_host *host) > { > - /* DAT line portion is diabled and in reset state */ > - writel(readl(host->base + DAVINCI_MMCCTL) | MMCCTL_DATRST, > - host->base + DAVINCI_MMCCTL); > - > - /* CMD line portion is diabled and in reset state */ > - writel(readl(host->base + DAVINCI_MMCCTL) | MMCCTL_CMDRST, > - host->base + DAVINCI_MMCCTL); > > - udelay(10); > + mmc_davinci_reset_ctrl(host, 1); > > writel(0, host->base + DAVINCI_MMCCLK); > writel(MMCCLK_CLKEN, host->base + DAVINCI_MMCCLK); > @@ -1116,12 +1116,7 @@ static void __init init_mmcsd_host(struct mmc_davinci_host *host) > writel(0x1FFF, host->base + DAVINCI_MMCTOR); > writel(0xFFFF, host->base + DAVINCI_MMCTOD); > > - writel(readl(host->base + DAVINCI_MMCCTL) & ~MMCCTL_DATRST, > - host->base + DAVINCI_MMCCTL); > - writel(readl(host->base + DAVINCI_MMCCTL) & ~MMCCTL_CMDRST, > - host->base + DAVINCI_MMCCTL); > - > - udelay(10); > + mmc_davinci_reset_ctrl(host, 0); > } > > static int __init davinci_mmcsd_probe(struct platform_device *pdev) > -- > 1.5.6 From khilman at deeprootsystems.com Wed Jan 6 09:37:52 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 06 Jan 2010 07:37:52 -0800 Subject: [PATCH v2 2/2] davinci: MMC: updates to suspend/resume implementation In-Reply-To: <1262770489-9486-2-git-send-email-chaithrika@ti.com> (Chaithrika U. S.'s message of "Wed\, 6 Jan 2010 15\:04\:49 +0530") References: <1262770489-9486-1-git-send-email-chaithrika@ti.com> <1262770489-9486-2-git-send-email-chaithrika@ti.com> Message-ID: <87k4vvmegf.fsf@deeprootsystems.com> Chaithrika U S writes: > Improve the suspend and resume callbacks in DaVinci MMC > host controller driver. I think this changelog needs a bit more detail on what "improve" means. Also, you should add a comment about the conversion to dev_pm_ops. Kevin > Tested on DA850/OMAP-L138 EVM. This testing requires patches > which add suspen-to-RAM support to DA850/OMAP-L138 SoC[1]. > > [1]http://linux.davincidsp.com/pipermail/davinci-linux-open-source/ > 2009-September/016118.html > > Signed-off-by: Chaithrika U S > --- > Applies to Linus' kernel tree. > > drivers/mmc/host/davinci_mmc.c | 51 +++++++++++++++++++++++++++++++++------ > 1 files changed, 43 insertions(+), 8 deletions(-) > > diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c > index 25645bf..d60f648 100644 > --- a/drivers/mmc/host/davinci_mmc.c > +++ b/drivers/mmc/host/davinci_mmc.c > @@ -170,6 +170,7 @@ struct mmc_davinci_host { > #define DAVINCI_MMC_DATADIR_READ 1 > #define DAVINCI_MMC_DATADIR_WRITE 2 > unsigned char data_dir; > + unsigned char suspended; > > /* buffer is used during PIO of one scatterlist segment, and > * is updated along with buffer_bytes_left. bytes_left applies > @@ -1297,32 +1298,66 @@ static int __exit davinci_mmcsd_remove(struct platform_device *pdev) > } > > #ifdef CONFIG_PM > -static int davinci_mmcsd_suspend(struct platform_device *pdev, pm_message_t msg) > +static int davinci_mmcsd_suspend(struct device *dev) > { > + struct platform_device *pdev = to_platform_device(dev); > struct mmc_davinci_host *host = platform_get_drvdata(pdev); > + struct pm_message msg = { PM_EVENT_SUSPEND }; > + int ret; > > - return mmc_suspend_host(host->mmc, msg); > + mmc_host_enable(host->mmc); > + ret = mmc_suspend_host(host->mmc, msg); > + if (!ret) { > + writel(0, host->base + DAVINCI_MMCIM); > + mmc_davinci_reset_ctrl(host, 1); > + mmc_host_disable(host->mmc); > + clk_disable(host->clk); > + host->suspended = 1; > + } else { > + host->suspended = 0; > + mmc_host_disable(host->mmc); > + } > + > + return ret; > } > > -static int davinci_mmcsd_resume(struct platform_device *pdev) > +static int davinci_mmcsd_resume(struct device *dev) > { > + struct platform_device *pdev = to_platform_device(dev); > struct mmc_davinci_host *host = platform_get_drvdata(pdev); > + int ret; > > - return mmc_resume_host(host->mmc); > + if (!host->suspended) > + return 0; > + > + clk_enable(host->clk); > + mmc_host_enable(host->mmc); > + > + mmc_davinci_reset_ctrl(host, 0); > + ret = mmc_resume_host(host->mmc); > + if (!ret) > + host->suspended = 0; > + > + return ret; > } > + > +static struct dev_pm_ops davinci_mmcsd_pm = { > + .suspend = davinci_mmcsd_suspend, > + .resume = davinci_mmcsd_resume, > +}; > + > +#define davinci_mmcsd_pm_ops (&davinci_mmcsd_pm) > #else > -#define davinci_mmcsd_suspend NULL > -#define davinci_mmcsd_resume NULL > +#define davinci_mmcsd_pm_ops NULL > #endif > > static struct platform_driver davinci_mmcsd_driver = { > .driver = { > .name = "davinci_mmc", > .owner = THIS_MODULE, > + .pm = davinci_mmcsd_pm_ops, > }, > .remove = __exit_p(davinci_mmcsd_remove), > - .suspend = davinci_mmcsd_suspend, > - .resume = davinci_mmcsd_resume, > }; > > static int __init davinci_mmcsd_init(void) > -- > 1.5.6 From khilman at deeprootsystems.com Wed Jan 6 09:57:25 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 06 Jan 2010 07:57:25 -0800 Subject: Audio quality with CPU frequency scaling In-Reply-To: (Sanjeev Premi's message of "Wed\, 6 Jan 2010 20\:11\:27 +0530") References: Message-ID: <87vdffkyze.fsf@deeprootsystems.com> "Premi, Sanjeev" writes: >> -----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: Wednesday, January 06, 2010 5:09 AM >> To: Subrahmanya, Chaithrika >> Cc: davinci-linux-open-source at linux.davincidsp.com >> Subject: Re: Audio quality with CPU frequency scaling >> >> "Chaithrika U S" writes: >> >> > Kevin, >> > >> > With the cpufreq support on DA850/OMAP-L138 SoC we are observing >> > that audio does not function as expected at all sampling rates >> > for various operating points. At a CPU frequency of 96MHz, audio >> > works fine with a sampling frequency of 8kHz. For other sampling >> > rates, there are lot of underrun/overrun errors. This is because >> > of EDMA also runs at a lower speed and is not able to transfer >> > data at the desired rate. >> > >> > To overcome the above, we can depend on the user to set the scaling >> > min frequency to be the same as scaling max frequency (in this case >> > 300 MHz) before starting aplay/arecord or temporarily move to >> > performance governor so that the audio quality is not affected. >> > >> > Do you think this is the right approach to this problem? Any other >> > solutions you suggest exploring? >> >> An alternative to relying on the user to change the CPUfreq policy is >> to have the audio driver itself do that. Based on the sample rate and >> clock frequency, the audio driver should be able to determine that the >> EDMA rate will not be fast enough and set a CPUfreq policy so that >> lower frequencies are not attempted. When the audio driver is done, >> it can set the policy back. > > Kevin, > > Wouldn't this mean that driver is directly influencing the policy? > Yes indeed, but if it is a question of correct functionality, I don't have a problem with that. If a driver is changing policy for power vs. performance tradeoff, I have a problem with that. Kevin From khilman at deeprootsystems.com Wed Jan 6 10:04:08 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 06 Jan 2010 08:04:08 -0800 Subject: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver In-Reply-To: (Muralidharan Karicheri's message of "Wed\, 6 Jan 2010 08\:44\:53 -0600") References: <1260895054-13232-1-git-send-email-m-karicheri2@ti.com> <871vi4rv25.fsf@deeprootsystems.com> Message-ID: <87k4vvkyo7.fsf@deeprootsystems.com> "Karicheri, Muralidharan" writes: >>> CLK(NULL, "rto", &rto_clk), >>> CLK(NULL, "usb", &usb_clk), >>> + CLK("dm355_ccdc", "master", &vpss_master_clk), >>> + CLK("dm355_ccdc", "slave", &vpss_slave_clk), >> >>I still don't understand why you have to add new entries here and >>can't simply rename the existing CLK nodes using vpss_*_clk. >> > > [MK] This will allow multiple drivers define their own clocks derived from > these. ccdc driver is not the only driver using these clocks. OK, but that still doesn't answer why you need multiple CLK() nodes. Who else is using the clocks? > Your earlier suggestion was to use as follows :- > > - CLK(NULL, "vpss_master", &vpss_master_clk), > - CLK(NULL, "vpss_slave", &vpss_slave_clk), > + CLK("vpfe-capture", "master", &vpss_master_clk), > + CLK("vpfe-capture", "slave", &vpss_slave_clk), > > I am not sure if the following will work so that it can be used across > multiple drivers. > > + CLK(NULL, "master", &vpss_master_clk), > + CLK(NULL, "slave", &vpss_slave_clk), > > If yes, I can re-do this patch. Please confirm. No, this will not work. You need a dev_id field so that matching is done using the struct device. My original suggestion was when you had the VPFE driver doing the clk_get(). Now that it's in CCDC, maybe it should look like this. - CLK(NULL, "vpss_master", &vpss_master_clk), - CLK(NULL, "vpss_slave", &vpss_slave_clk), + CLK("ccdc", "master", &vpss_master_clk), + CLK("ccdc", "slave", &vpss_slave_clk), Kevin From m-karicheri2 at ti.com Wed Jan 6 10:20:22 2010 From: m-karicheri2 at ti.com (Karicheri, Muralidharan) Date: Wed, 6 Jan 2010 10:20:22 -0600 Subject: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver In-Reply-To: <87k4vvkyo7.fsf@deeprootsystems.com> References: <1260895054-13232-1-git-send-email-m-karicheri2@ti.com> <871vi4rv25.fsf@deeprootsystems.com> <87k4vvkyo7.fsf@deeprootsystems.com> Message-ID: display, resizer drivers etc... 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: Wednesday, January 06, 2010 11:04 AM >To: Karicheri, Muralidharan >Cc: linux-media at vger.kernel.org; hverkuil at xs4all.nl; davinci-linux-open- >source at linux.davincidsp.com >Subject: Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc >drivers to platform driver > >"Karicheri, Muralidharan" writes: > >>>> CLK(NULL, "rto", &rto_clk), >>>> CLK(NULL, "usb", &usb_clk), >>>> + CLK("dm355_ccdc", "master", &vpss_master_clk), >>>> + CLK("dm355_ccdc", "slave", &vpss_slave_clk), >>> >>>I still don't understand why you have to add new entries here and >>>can't simply rename the existing CLK nodes using vpss_*_clk. >>> >> >> [MK] This will allow multiple drivers define their own clocks derived >from >> these. ccdc driver is not the only driver using these clocks. > >OK, but that still doesn't answer why you need multiple CLK() nodes. > >Who else is using the clocks? > >> Your earlier suggestion was to use as follows :- >> >> - CLK(NULL, "vpss_master", &vpss_master_clk), >> - CLK(NULL, "vpss_slave", &vpss_slave_clk), >> + CLK("vpfe-capture", "master", &vpss_master_clk), >> + CLK("vpfe-capture", "slave", &vpss_slave_clk), >> >> I am not sure if the following will work so that it can be used across >> multiple drivers. >> >> + CLK(NULL, "master", &vpss_master_clk), >> + CLK(NULL, "slave", &vpss_slave_clk), >> >> If yes, I can re-do this patch. Please confirm. > >No, this will not work. You need a dev_id field so that matching >is done using the struct device. > >My original suggestion was when you had the VPFE driver doing the >clk_get(). Now that it's in CCDC, maybe it should look like this. > >- CLK(NULL, "vpss_master", &vpss_master_clk), >- CLK(NULL, "vpss_slave", &vpss_slave_clk), >+ CLK("ccdc", "master", &vpss_master_clk), >+ CLK("ccdc", "slave", &vpss_slave_clk), > >Kevin From khilman at deeprootsystems.com Wed Jan 6 10:36:39 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 06 Jan 2010 08:36:39 -0800 Subject: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver In-Reply-To: (Muralidharan Karicheri's message of "Wed\, 6 Jan 2010 10\:20\:22 -0600") References: <1260895054-13232-1-git-send-email-m-karicheri2@ti.com> <871vi4rv25.fsf@deeprootsystems.com> <87k4vvkyo7.fsf@deeprootsystems.com> Message-ID: <878wcbkx60.fsf@deeprootsystems.com> In the future, please do not top-post. Inline replies are preferred so context can be followed. I've moved your reply into context below with some more comments... "Karicheri, Muralidharan" writes: >>-----Original Message----- >>From: Kevin Hilman [mailto:khilman at deeprootsystems.com] >>Sent: Wednesday, January 06, 2010 11:04 AM >>To: Karicheri, Muralidharan >>Cc: linux-media at vger.kernel.org; hverkuil at xs4all.nl; davinci-linux-open- >>source at linux.davincidsp.com >>Subject: Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc >>drivers to platform driver >> >>"Karicheri, Muralidharan" writes: >> >>>>> CLK(NULL, "rto", &rto_clk), >>>>> CLK(NULL, "usb", &usb_clk), >>>>> + CLK("dm355_ccdc", "master", &vpss_master_clk), >>>>> + CLK("dm355_ccdc", "slave", &vpss_slave_clk), >>>> >>>>I still don't understand why you have to add new entries here and >>>>can't simply rename the existing CLK nodes using vpss_*_clk. >>>> >>> >>> [MK] This will allow multiple drivers define their own clocks derived >>from >>> these. ccdc driver is not the only driver using these clocks. >> >>OK, but that still doesn't answer why you need multiple CLK() nodes. >> >>Who else is using the clocks? >> > > display, resizer drivers etc... OK, I'm not extremely familar with the whole video architecture here, but are all of these drivers expected to be doing clk_get() and clk_enable()? I thought the point of moving the clocks into the CCDC driver was so that the clock management was done in a single, shared space. Kevin >>> Your earlier suggestion was to use as follows :- >>> >>> - CLK(NULL, "vpss_master", &vpss_master_clk), >>> - CLK(NULL, "vpss_slave", &vpss_slave_clk), >>> + CLK("vpfe-capture", "master", &vpss_master_clk), >>> + CLK("vpfe-capture", "slave", &vpss_slave_clk), >>> >>> I am not sure if the following will work so that it can be used across >>> multiple drivers. >>> >>> + CLK(NULL, "master", &vpss_master_clk), >>> + CLK(NULL, "slave", &vpss_slave_clk), >>> >>> If yes, I can re-do this patch. Please confirm. >> >>No, this will not work. You need a dev_id field so that matching >>is done using the struct device. >> >>My original suggestion was when you had the VPFE driver doing the >>clk_get(). Now that it's in CCDC, maybe it should look like this. >> >>- CLK(NULL, "vpss_master", &vpss_master_clk), >>- CLK(NULL, "vpss_slave", &vpss_slave_clk), >>+ CLK("ccdc", "master", &vpss_master_clk), >>+ CLK("ccdc", "slave", &vpss_slave_clk), >> >>Kevin From khilman at deeprootsystems.com Wed Jan 6 10:40:24 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 06 Jan 2010 08:40:24 -0800 Subject: [PATCH 1/2] davinci: add support for CDCE949 clock synthesizer In-Reply-To: <1262778589-31459-1-git-send-email-nsekhar@ti.com> (Sekhar Nori's message of "Wed\, 6 Jan 2010 17\:19\:48 +0530") References: <1262778589-31459-1-git-send-email-nsekhar@ti.com> Message-ID: <873a2jkwzr.fsf@deeprootsystems.com> Sekhar Nori writes: > From: Nageswari Srinivasan > > This patch adds support for TI's CDCE949 - a clock > synthesizer with 4 PLLs and 9 outputs. > > It is used on DM6467 EVM. On the EVM, it generates > clocks required for VPIF, TSIF and Audio modules. > > This patch adds it as part of the DaVinci clock framework. > > Testing: > The various frequency outputs on Y1 have been tested using > a out-of-tree VPIF video driver supporting HD video. > The register values for Y5 frequency outputs have been > derived from TSIF driver sources in MontaVista LSP kernel, > but actual output has not been tested for lack of TSIF > driver which actually works on the latest kernel. > > Signed-off-by: Nageswari Srinivasan > Signed-off-by: Sekhar Nori Thanks, applying to master and queuing for 2.6.34 in davinci-next. Kevin > --- > arch/arm/mach-davinci/cdce949.c | 289 ++++++++++++++++++++++++++ > arch/arm/mach-davinci/include/mach/cdce949.h | 19 ++ > 2 files changed, 308 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/mach-davinci/cdce949.c > create mode 100644 arch/arm/mach-davinci/include/mach/cdce949.h > > diff --git a/arch/arm/mach-davinci/cdce949.c b/arch/arm/mach-davinci/cdce949.c > new file mode 100644 > index 0000000..5a08283 > --- /dev/null > +++ b/arch/arm/mach-davinci/cdce949.c > @@ -0,0 +1,289 @@ > +/* > + * TI CDCE949 clock synthesizer driver > + * > + * Note: This implementation assumes an input of 27MHz to the CDCE. > + * This is by no means constrained by CDCE hardware although the datasheet > + * does use this as an example for all illustrations and more importantly: > + * that is the crystal input on boards it is currently used on. > + * > + * Copyright (C) 2009 Texas Instruments Incorporated. http://www.ti.com/ > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + * > + */ > +#include > +#include > +#include > +#include > + > +#include > + > +#include "clock.h" > + > +static struct i2c_client *cdce_i2c_client; > + > +/* CDCE register descriptor */ > +struct cdce_reg { > + u8 addr; > + u8 val; > +}; > + > +/* Per-Output (Y1, Y2 etc.) frequency descriptor */ > +struct cdce_freq { > + /* Frequency in KHz */ > + unsigned long frequency; > + /* > + * List of registers to program to obtain a particular frequency. > + * 0x0 in register address and value is the end of list marker. > + */ > + struct cdce_reg *reglist; > +}; > + > +#define CDCE_FREQ_TABLE_ENTRY(line, out) \ > +{ \ > + .reglist = cdce_y ##line## _ ##out, \ > + .frequency = out, \ > +} > + > +/* List of CDCE outputs */ > +struct cdce_output { > + /* List of frequencies on this output */ > + struct cdce_freq *freq_table; > + /* Number of possible frequencies */ > + int size; > +}; > + > +/* > + * Finding out the values to program into CDCE949 registers for a particular > + * frequency output is not a simple calculation. Have a look at the datasheet > + * for the details. There is desktop software available to help users with > + * the calculations. Here, we just depend on the output of that software > + * (or hand calculations) instead trying to runtime calculate the register > + * values and inflicting misery on ourselves. > + */ > +static struct cdce_reg cdce_y1_148500[] = { > + { 0x13, 0x00 }, > + /* program PLL1_0 multiplier */ > + { 0x18, 0xaf }, > + { 0x19, 0x50 }, > + { 0x1a, 0x02 }, > + { 0x1b, 0xc9 }, > + /* program PLL1_11 multiplier */ > + { 0x1c, 0x00 }, > + { 0x1d, 0x40 }, > + { 0x1e, 0x02 }, > + { 0x1f, 0xc9 }, > + /* output state selection */ > + { 0x15, 0x00 }, > + { 0x14, 0xef }, > + /* switch MUX to PLL1 output */ > + { 0x14, 0x6f }, > + { 0x16, 0x06 }, > + /* set P2DIV divider, P3DIV and input crystal */ > + { 0x17, 0x06 }, > + { 0x01, 0x00 }, > + { 0x05, 0x48 }, > + { 0x02, 0x80 }, > + /* enable and disable PLL */ > + { 0x02, 0xbc }, > + { 0x03, 0x01 }, > + { }, > +}; > + > +static struct cdce_reg cdce_y1_74250[] = { > + { 0x13, 0x00 }, > + { 0x18, 0xaf }, > + { 0x19, 0x50 }, > + { 0x1a, 0x02 }, > + { 0x1b, 0xc9 }, > + { 0x1c, 0x00 }, > + { 0x1d, 0x40 }, > + { 0x1e, 0x02 }, > + { 0x1f, 0xc9 }, > + /* output state selection */ > + { 0x15, 0x00 }, > + { 0x14, 0xef }, > + /* switch MUX to PLL1 output */ > + { 0x14, 0x6f }, > + { 0x16, 0x06 }, > + /* set P2DIV divider, P3DIV and input crystal */ > + { 0x17, 0x06 }, > + { 0x01, 0x00 }, > + { 0x05, 0x48 }, > + { 0x02, 0x80 }, > + /* enable and disable PLL */ > + { 0x02, 0xbc }, > + { 0x03, 0x02 }, > + { }, > +}; > + > +static struct cdce_reg cdce_y1_27000[] = { > + { 0x13, 0x00 }, > + { 0x18, 0x00 }, > + { 0x19, 0x40 }, > + { 0x1a, 0x02 }, > + { 0x1b, 0x08 }, > + { 0x1c, 0x00 }, > + { 0x1d, 0x40 }, > + { 0x1e, 0x02 }, > + { 0x1f, 0x08 }, > + { 0x15, 0x02 }, > + { 0x14, 0xed }, > + { 0x16, 0x01 }, > + { 0x17, 0x01 }, > + { 0x01, 0x00 }, > + { 0x05, 0x50 }, > + { 0x02, 0xb4 }, > + { 0x03, 0x01 }, > + { }, > +}; > + > +static struct cdce_freq cdce_y1_freqs[] = { > + CDCE_FREQ_TABLE_ENTRY(1, 148500), > + CDCE_FREQ_TABLE_ENTRY(1, 74250), > + CDCE_FREQ_TABLE_ENTRY(1, 27000), > +}; > + > +static struct cdce_reg cdce_y5_13500[] = { > + { 0x27, 0x08 }, > + { 0x28, 0x00 }, > + { 0x29, 0x40 }, > + { 0x2a, 0x02 }, > + { 0x2b, 0x08 }, > + { 0x24, 0x6f }, > + { }, > +}; > + > +static struct cdce_reg cdce_y5_16875[] = { > + { 0x27, 0x08 }, > + { 0x28, 0x9f }, > + { 0x29, 0xb0 }, > + { 0x2a, 0x02 }, > + { 0x2b, 0x89 }, > + { 0x24, 0x6f }, > + { }, > +}; > + > +static struct cdce_reg cdce_y5_27000[] = { > + { 0x27, 0x04 }, > + { 0x28, 0x00 }, > + { 0x29, 0x40 }, > + { 0x2a, 0x02 }, > + { 0x2b, 0x08 }, > + { 0x24, 0x6f }, > + { }, > +}; > +static struct cdce_reg cdce_y5_54000[] = { > + { 0x27, 0x04 }, > + { 0x28, 0xff }, > + { 0x29, 0x80 }, > + { 0x2a, 0x02 }, > + { 0x2b, 0x07 }, > + { 0x24, 0x6f }, > + { }, > +}; > + > +static struct cdce_reg cdce_y5_81000[] = { > + { 0x27, 0x02 }, > + { 0x28, 0xbf }, > + { 0x29, 0xa0 }, > + { 0x2a, 0x03 }, > + { 0x2b, 0x0a }, > + { 0x24, 0x6f }, > + { }, > +}; > + > +static struct cdce_freq cdce_y5_freqs[] = { > + CDCE_FREQ_TABLE_ENTRY(5, 13500), > + CDCE_FREQ_TABLE_ENTRY(5, 16875), > + CDCE_FREQ_TABLE_ENTRY(5, 27000), > + CDCE_FREQ_TABLE_ENTRY(5, 54000), > + CDCE_FREQ_TABLE_ENTRY(5, 81000), > +}; > + > + > +static struct cdce_output output_list[] = { > + [1] = { cdce_y1_freqs, ARRAY_SIZE(cdce_y1_freqs) }, > + [5] = { cdce_y5_freqs, ARRAY_SIZE(cdce_y5_freqs) }, > +}; > + > +int cdce_set_rate(struct clk *clk, unsigned long rate) > +{ > + int i, ret = 0; > + struct cdce_freq *freq_table = output_list[clk->lpsc].freq_table; > + struct cdce_reg *regs = NULL; > + > + if (!cdce_i2c_client) > + return -ENODEV; > + > + if (!freq_table) > + return -EINVAL; > + > + for (i = 0; i < output_list[clk->lpsc].size; i++) { > + if (freq_table[i].frequency == rate / 1000) { > + regs = freq_table[i].reglist; > + break; > + } > + } > + > + if (!regs) > + return -EINVAL; > + > + for (i = 0; regs[i].addr; i++) { > + ret = i2c_smbus_write_byte_data(cdce_i2c_client, > + regs[i].addr | 0x80, regs[i].val); > + if (ret) > + return ret; > + } > + > + atomic_set(&clk->rate, rate); > + > + return 0; > +} > + > +static int cdce_probe(struct i2c_client *client, > + const struct i2c_device_id *id) > +{ > + cdce_i2c_client = client; > + return 0; > +} > + > +static int __devexit cdce_remove(struct i2c_client *client) > +{ > + cdce_i2c_client = NULL; > + return 0; > +} > + > +static const struct i2c_device_id cdce_id[] = { > + {"cdce949", 0}, > + {}, > +}; > +MODULE_DEVICE_TABLE(i2c, cdce_id); > + > +static struct i2c_driver cdce_driver = { > + .driver = { > + .owner = THIS_MODULE, > + .name = "cdce949", > + }, > + .probe = cdce_probe, > + .remove = __devexit_p(cdce_remove), > + .id_table = cdce_id, > +}; > + > +static int __init cdce_init(void) > +{ > + return i2c_add_driver(&cdce_driver); > +} > +subsys_initcall(cdce_init); > + > +static void __exit cdce_exit(void) > +{ > + i2c_del_driver(&cdce_driver); > +} > +module_exit(cdce_exit); > + > +MODULE_AUTHOR("Texas Instruments"); > +MODULE_DESCRIPTION("CDCE949 clock synthesizer driver"); > +MODULE_LICENSE("GPL v2"); > diff --git a/arch/arm/mach-davinci/include/mach/cdce949.h b/arch/arm/mach-davinci/include/mach/cdce949.h > new file mode 100644 > index 0000000..c73331f > --- /dev/null > +++ b/arch/arm/mach-davinci/include/mach/cdce949.h > @@ -0,0 +1,19 @@ > +/* > + * TI CDCE949 off-chip clock synthesizer support > + * > + * 2009 (C) Texas Instruments, Inc. http://www.ti.com/ > + * > + * This file is licensed under the terms of the GNU General Public License > + * version 2. This program is licensed "as is" without any warranty of any > + * kind, whether express or implied. > + */ > +#ifndef _MACH_DAVINCI_CDCE949_H > +#define _MACH_DAVINCI_CDCE949_H > + > +#include > + > +#include > + > +int cdce_set_rate(struct clk *clk, unsigned long rate); > + > +#endif > -- > 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 Wed Jan 6 10:41:54 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 06 Jan 2010 08:41:54 -0800 Subject: [PATCH v2 0/9] davinci: EDMA updates In-Reply-To: <1262779101-25102-1-git-send-email-sudhakar.raj@ti.com> (Sudhakar Rajashekhara's message of "Wed\, 6 Jan 2010 17\:28\:21 +0530") References: <1262779101-25102-1-git-send-email-sudhakar.raj@ti.com> Message-ID: <87tyuzjict.fsf@deeprootsystems.com> Sudhakar Rajashekhara writes: > This patch set corrects some issues with the existing EDMA > driver and also adds support for EDMA resource (channel/slots) > sharing between two processors (say ARM and DSP). > > The patch set has been tested on DM646x, OMAP-L137 and OMAP-L138 > EVM boards. First 6 patches of this set are same as the previous > patches. The last 3 patches are different. Thanks for the updated comments. Applying to master and queing for 2.6.34 in davinci-next. Kevin > Sudhakar Rajashekhara (9): > 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: support for EDMA resource sharing > davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 > davinci: da830/omapl137: Specify reserved channels/slots > davinci: da850/omapl138: Specify reserved channels/slots > davinci: dm646x: Specify reserved EDMA channel/slots for DM646x > > arch/arm/mach-davinci/devices-da8xx.c | 191 +++++++++++++++++++++++++++-- > arch/arm/mach-davinci/dm355.c | 8 -- > arch/arm/mach-davinci/dm644x.c | 10 -- > arch/arm/mach-davinci/dm646x.c | 33 ++++- > arch/arm/mach-davinci/dma.c | 101 +++++++++++++--- > arch/arm/mach-davinci/include/mach/edma.h | 4 +- > 6 files changed, 291 insertions(+), 56 deletions(-) > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source From khilman at deeprootsystems.com Wed Jan 6 11:04:23 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 06 Jan 2010 09:04:23 -0800 Subject: [PATCH v2 1/2] Input: Add device_enable handler to DaVinci Keyscan platform data In-Reply-To: <20100106082638.GA2176@core.coreip.homeip.net> (Dmitry Torokhov's message of "Wed\, 6 Jan 2010 00\:26\:38 -0800") References: <1258141434-18351-1-git-send-email-miguel.aguilar@ridgerun.com> <87hbs25n38.fsf@deeprootsystems.com> <20091208004832.GA9495@core.coreip.homeip.net> <877hsy46o0.fsf@deeprootsystems.com> <87aawsozgo.fsf@deeprootsystems.com> <20100106082638.GA2176@core.coreip.homeip.net> Message-ID: <87ocl7jhbc.fsf@deeprootsystems.com> Dmitry Torokhov writes: > On Tue, Jan 05, 2010 at 04:21:11PM -0800, Kevin Hilman wrote: >> Kevin Hilman writes: >> >> > Dmitry Torokhov writes: >> > >> >> On Mon, Dec 07, 2009 at 04:24:59PM -0800, Kevin Hilman wrote: >> >>> writes: >> >>> >> >>> > From: Miguel Aguilar >> >>> > >> >>> > Add a function pointer in the platform data of the DaVinci Keyscan driver >> >>> > called device_enabled, in order to perform board specific actions when >> >>> > the device is initialized, like setup the PINMUX configuration. >> >>> > >> >>> > Signed-off-by: Miguel Aguilar >> >>> >> >>> Signed-off-by: Kevin Hilman >> >>> >> >>> Dmitry, >> >>> >> >>> Will you be queueing this driver (and this patch) for 2.6.34? I >> >>> thought you had accepted the original driver, but I don't see it in >> >>> the master or next branch of your input tree at: >> >>> >> >>> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git >> >> >> >> The driver is there, commit bc09dcadc1a3da87d58aa70ebc8e9441205be75c on >> >> 'next' branch (I don't really use master branch). It was committed back >> >> in October, probably that's why you don't see it? >> >> >> >> As far as the patch goes - I got an impression from email sent by >> >> Steve that there are ways to do automatic PINMUX detection and thus >> >> this patch was not needed. Is this ture? >> > >> > The method Steve was referring to was done for MontaVista >> > internal/product kernels but was rejected for upstream (by me) because >> > of the way it was implemented (by tying mux settings to clock >> > settings.) >> > >> >> If not I am stull unsure what happens if you unload the driver. How >> >> do you restore the old configuration so that the device you took >> >> over from can start working again? Maybe pinmux should be controlled >> >> via sysfs attribute (in board code) so that user can switch on-fly >> >> between the devices? >> > >> > The way we currently handle MUXing in davinci, you don't need to do >> > anything after the driver unloads. Any other user of these pins will >> > mux them as needed. >> > >> > If really necessary, we could do an equivalent 'device_disable' hook >> > but there would be empty as it wouldn't be needed. >> > >> > So, speaking as maintainer of the DaVinci support, I'm in favor of this >> > approach from Miguel. >> >> Dmitry, >> >> Unless there are further objectsions, could you please queue this >> patch for 2.6.34 with my signoff? >> > > Applied to for-linus, I do not see any reason in holding this patch > till .34. Sorry for the delay. > Excellent. Thanks. I'll submit the platform specific code for -rc4 as well. Kevin From khilman at deeprootsystems.com Wed Jan 6 12:11:58 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 06 Jan 2010 10:11:58 -0800 Subject: [GIT PULL] davinci platform fixes for 2.6.33-rc4 Message-ID: <87k4vvf6hd.fsf@deeprootsystems.com> Linus, Please pull the fixes for the ARM/DaVinci platform for 2.6.33-rc4. Thanks, Kevin The following changes since commit 74d2e4f8d79ae0c4b6ec027958d5b18058662eea: Linus Torvalds (1): Linux 2.6.33-rc3 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git davinci-fixes or git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git davinci-fixes Miguel Aguilar (1): DaVinci: DM365: Add the device_enable for the DaVinci Keyscan Sekhar Nori (3): davinci: cp_intc: provide set_wake function davinci: da8xx/omap-l1: mark RTC as a wakeup source davinci: enable ARCH_HAS_HOLES_MEMORYMODEL for DaVinci Vaibhav Hiremath (1): Davinci VPFE Capture: Take i2c adapter id through platform data arch/arm/Kconfig | 1 + arch/arm/mach-davinci/board-dm355-evm.c | 1 + arch/arm/mach-davinci/board-dm365-evm.c | 11 ++++++----- arch/arm/mach-davinci/board-dm644x-evm.c | 1 + arch/arm/mach-davinci/cp_intc.c | 11 +++++++++++ arch/arm/mach-davinci/devices-da8xx.c | 9 ++++++++- arch/arm/mach-davinci/dm365.c | 1 - 7 files changed, 28 insertions(+), 7 deletions(-) From khilman at deeprootsystems.com Wed Jan 6 12:31:42 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 6 Jan 2010 10:31:42 -0800 Subject: [PATCH 00/35] davinci updates queued for 2.6.34 Message-ID: <1262802737-6601-1-git-send-email-khilman@deeprootsystems.com> Here's a set of DaVinci updates for review. Apologies for the large series, I've been meaning to send these in smaller batches, but hd lots to queue up from over the holidays. Pending any review comments, these will be submitted to Linus during the next merge window. Kevin Chaithrika U S (1): davinci: clock: Check CLK_PSC flag before disabling PSC Nageswari Srinivasan (2): davinci: add support for CDCE949 clock synthesizer davinci: add CDCE949 support on DM6467 EVM Sandeep Paulraj (1): DaVinci: DM365: Changing default queue for DM365. 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: clock framework: remove spinlock usage 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 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 (11): 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: support for EDMA resource sharing davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 davinci: da830/omapl137: Specify reserved channels/slots davinci: da850/omapl138: Specify reserved channels/slots davinci: dm646x: Specify reserved EDMA channel/slots for DM646x 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-dm646x-evm.c | 143 +++++++++---- arch/arm/mach-davinci/cdce949.c | 289 ++++++++++++++++++++++++++ arch/arm/mach-davinci/clock.c | 143 +++++-------- arch/arm/mach-davinci/clock.h | 29 ++- 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 | 86 +++++++-- arch/arm/mach-davinci/devices-da8xx.c | 210 +++++++++++++++++-- arch/arm/mach-davinci/dm355.c | 12 +- arch/arm/mach-davinci/dm365.c | 6 +- arch/arm/mach-davinci/dm644x.c | 18 +-- arch/arm/mach-davinci/dm646x.c | 44 +++-- arch/arm/mach-davinci/dma.c | 101 ++++++++-- arch/arm/mach-davinci/include/mach/cdce949.h | 19 ++ 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 | 2 +- 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 | 4 +- arch/arm/mach-davinci/include/mach/emac.h | 36 ---- arch/arm/mach-davinci/include/mach/memory.h | 5 + arch/arm/mach-davinci/include/mach/mux.h | 1 + arch/arm/mach-davinci/include/mach/pm.h | 54 +++++ arch/arm/mach-davinci/include/mach/psc.h | 15 ++ arch/arm/mach-davinci/include/mach/timex.h | 7 +- arch/arm/mach-davinci/pm.c | 158 ++++++++++++++ arch/arm/mach-davinci/psc.c | 17 +- arch/arm/mach-davinci/sleep.S | 224 ++++++++++++++++++++ drivers/net/Kconfig | 2 +- drivers/net/davinci_emac.c | 55 ++++-- include/linux/davinci_emac.h | 39 ++++ 37 files changed, 1494 insertions(+), 345 deletions(-) create mode 100644 arch/arm/mach-davinci/cdce949.c create mode 100644 arch/arm/mach-davinci/include/mach/cdce949.h delete mode 100644 arch/arm/mach-davinci/include/mach/emac.h create mode 100644 arch/arm/mach-davinci/include/mach/pm.h create mode 100644 arch/arm/mach-davinci/pm.c create mode 100644 arch/arm/mach-davinci/sleep.S create mode 100644 include/linux/davinci_emac.h From khilman at deeprootsystems.com Wed Jan 6 12:31:43 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 6 Jan 2010 10:31:43 -0800 Subject: [PATCH 01/35] davinci: da8xx/omapl1: add support for the second sysconfig module In-Reply-To: <1262802737-6601-1-git-send-email-khilman@deeprootsystems.com> References: <1262802737-6601-1-git-send-email-khilman@deeprootsystems.com> Message-ID: <1262802737-6601-2-git-send-email-khilman@deeprootsystems.com> From: Sekhar Nori OMAP-L138 adds a second SYSCFG region having useful functionality like deep sleep, pull up/down control and SATA clock stop. This patch makes provision for accessing registers from second SYSCFG region in da8xx code. Note that OMAP-L137 has a single SYSCFG region. Signed-off-by: Sekhar Nori Signed-off-by: Kevin Hilman --- arch/arm/mach-davinci/board-da830-evm.c | 4 ++-- arch/arm/mach-davinci/board-da850-evm.c | 2 +- arch/arm/mach-davinci/da830.c | 8 ++++---- arch/arm/mach-davinci/da850.c | 20 ++++++++++++-------- arch/arm/mach-davinci/devices-da8xx.c | 3 ++- arch/arm/mach-davinci/include/mach/da8xx.h | 10 +++++++--- 6 files changed, 28 insertions(+), 19 deletions(-) diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c index 31dc990..dc19870 100644 --- a/arch/arm/mach-davinci/board-da830-evm.c +++ b/arch/arm/mach-davinci/board-da830-evm.c @@ -112,7 +112,7 @@ static __init void da830_evm_usb_init(void) * Set up USB clock/mode in the CFGCHIP2 register. * FYI: CFGCHIP2 is 0x0000ef00 initially. */ - cfgchip2 = __raw_readl(DA8XX_SYSCFG_VIRT(DA8XX_CFGCHIP2_REG)); + cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG)); /* USB2.0 PHY reference clock is 24 MHz */ cfgchip2 &= ~CFGCHIP2_REFFREQ; @@ -139,7 +139,7 @@ static __init void da830_evm_usb_init(void) cfgchip2 |= CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN; #endif - __raw_writel(cfgchip2, DA8XX_SYSCFG_VIRT(DA8XX_CFGCHIP2_REG)); + __raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG)); /* USB_REFCLKIN is not used. */ ret = davinci_cfg_reg(DA830_USB0_DRVVBUS); diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index 07de8db..dba2241 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -537,7 +537,7 @@ static int __init da850_evm_config_emac(void) if (!machine_is_davinci_da850_evm()) return 0; - cfg_chip3_base = DA8XX_SYSCFG_VIRT(DA8XX_CFGCHIP3_REG); + cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG); val = __raw_readl(cfg_chip3_base); diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c index b22b5cf..5479605 100644 --- a/arch/arm/mach-davinci/da830.c +++ b/arch/arm/mach-davinci/da830.c @@ -1208,13 +1208,13 @@ static struct davinci_soc_info davinci_soc_info_da830 = { void __init da830_init(void) { - da8xx_syscfg_base = ioremap(DA8XX_SYSCFG_BASE, SZ_4K); - if (WARN(!da8xx_syscfg_base, "Unable to map syscfg module")) + da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K); + if (WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module")) return; davinci_soc_info_da830.jtag_id_base = - DA8XX_SYSCFG_VIRT(DA8XX_JTAG_ID_REG); - davinci_soc_info_da830.pinmux_base = DA8XX_SYSCFG_VIRT(0x120); + DA8XX_SYSCFG0_VIRT(DA8XX_JTAG_ID_REG); + davinci_soc_info_da830.pinmux_base = DA8XX_SYSCFG0_VIRT(0x120); davinci_common_init(&davinci_soc_info_da830); } diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c index 717806c..4f84ab4 100644 --- a/arch/arm/mach-davinci/da850.c +++ b/arch/arm/mach-davinci/da850.c @@ -838,12 +838,12 @@ static void da850_set_async3_src(int pllnum) } } - v = __raw_readl(DA8XX_SYSCFG_VIRT(DA8XX_CFGCHIP3_REG)); + v = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG)); if (pllnum) v |= CFGCHIP3_ASYNC3_CLKSRC; else v &= ~CFGCHIP3_ASYNC3_CLKSRC; - __raw_writel(v, DA8XX_SYSCFG_VIRT(DA8XX_CFGCHIP3_REG)); + __raw_writel(v, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG)); } #ifdef CONFIG_CPU_FREQ @@ -996,9 +996,9 @@ static int da850_set_pll0rate(struct clk *clk, unsigned long index) postdiv = opp->postdiv; /* Unlock writing to PLL registers */ - v = __raw_readl(DA8XX_SYSCFG_VIRT(DA8XX_CFGCHIP0_REG)); + v = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP0_REG)); v &= ~CFGCHIP0_PLL_MASTER_LOCK; - __raw_writel(v, DA8XX_SYSCFG_VIRT(DA8XX_CFGCHIP0_REG)); + __raw_writel(v, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP0_REG)); ret = davinci_set_pllrate(pll, prediv, mult, postdiv); if (WARN_ON(ret)) @@ -1053,13 +1053,17 @@ static struct davinci_soc_info davinci_soc_info_da850 = { void __init da850_init(void) { - da8xx_syscfg_base = ioremap(DA8XX_SYSCFG_BASE, SZ_4K); - if (WARN(!da8xx_syscfg_base, "Unable to map syscfg module")) + da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K); + if (WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module")) + return; + + da8xx_syscfg1_base = ioremap(DA8XX_SYSCFG1_BASE, SZ_4K); + if (WARN(!da8xx_syscfg1_base, "Unable to map syscfg1 module")) return; davinci_soc_info_da850.jtag_id_base = - DA8XX_SYSCFG_VIRT(DA8XX_JTAG_ID_REG); - davinci_soc_info_da850.pinmux_base = DA8XX_SYSCFG_VIRT(0x120); + DA8XX_SYSCFG0_VIRT(DA8XX_JTAG_ID_REG); + davinci_soc_info_da850.pinmux_base = DA8XX_SYSCFG0_VIRT(0x120); davinci_common_init(&davinci_soc_info_da850); diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c index dd2d32c..8de5f9f 100644 --- a/arch/arm/mach-davinci/devices-da8xx.c +++ b/arch/arm/mach-davinci/devices-da8xx.c @@ -42,7 +42,8 @@ #define DA8XX_MDIO_REG_OFFSET 0x4000 #define DA8XX_EMAC_CTRL_RAM_SIZE SZ_8K -void __iomem *da8xx_syscfg_base; +void __iomem *da8xx_syscfg0_base; +void __iomem *da8xx_syscfg1_base; static struct plat_serial8250_port da8xx_serial_pdata[] = { { diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h index 9070491..bddc4d4 100644 --- a/arch/arm/mach-davinci/include/mach/da8xx.h +++ b/arch/arm/mach-davinci/include/mach/da8xx.h @@ -21,7 +21,8 @@ #include #include -extern void __iomem *da8xx_syscfg_base; +extern void __iomem *da8xx_syscfg0_base; +extern void __iomem *da8xx_syscfg1_base; /* * The cp_intc interrupt controller for the da8xx isn't in the same @@ -34,13 +35,16 @@ extern void __iomem *da8xx_syscfg_base; #define DA8XX_CP_INTC_SIZE SZ_8K #define DA8XX_CP_INTC_VIRT (IO_VIRT - DA8XX_CP_INTC_SIZE - SZ_4K) -#define DA8XX_SYSCFG_BASE (IO_PHYS + 0x14000) -#define DA8XX_SYSCFG_VIRT(x) (da8xx_syscfg_base + (x)) +#define DA8XX_SYSCFG0_BASE (IO_PHYS + 0x14000) +#define DA8XX_SYSCFG0_VIRT(x) (da8xx_syscfg0_base + (x)) #define DA8XX_JTAG_ID_REG 0x18 #define DA8XX_CFGCHIP0_REG 0x17c #define DA8XX_CFGCHIP2_REG 0x184 #define DA8XX_CFGCHIP3_REG 0x188 +#define DA8XX_SYSCFG1_BASE (IO_PHYS + 0x22C000) +#define DA8XX_SYSCFG1_VIRT(x) (da8xx_syscfg1_base + (x)) + #define DA8XX_PSC0_BASE 0x01c10000 #define DA8XX_PLL0_BASE 0x01c11000 #define DA8XX_TIMER64P0_BASE 0x01c20000 -- 1.6.6.rc2.1.g42108 From khilman at deeprootsystems.com Wed Jan 6 12:31:44 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 6 Jan 2010 10:31:44 -0800 Subject: [PATCH 02/35] davinci: move PLL wait time values to clock.h In-Reply-To: <1262802737-6601-2-git-send-email-khilman@deeprootsystems.com> References: <1262802737-6601-1-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-2-git-send-email-khilman@deeprootsystems.com> Message-ID: <1262802737-6601-3-git-send-email-khilman@deeprootsystems.com> From: Sekhar Nori As suspend support is added, the code supporting the suspend operation needs to bypass PLLs and needs to access the same wait time values as the PLL code in clock.c. To facilitate this, move the PLL wait times to clock.h where they can be accessed by suspend code. Signed-off-by: Sekhar Nori Signed-off-by: Kevin Hilman --- arch/arm/mach-davinci/clock.c | 15 +++------------ arch/arm/mach-davinci/clock.h | 15 +++++++++++++++ 2 files changed, 18 insertions(+), 12 deletions(-) diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c index baece65..0fa68c5 100644 --- a/arch/arm/mach-davinci/clock.c +++ b/arch/arm/mach-davinci/clock.c @@ -376,7 +376,7 @@ int davinci_set_pllrate(struct pll_data *pll, unsigned int prediv, locktime = ((2000 * prediv) / 100); prediv = (prediv - 1) | PLLDIV_EN; } else { - locktime = 20; + locktime = PLL_LOCK_TIME; } if (postdiv) postdiv = (postdiv - 1) | PLLDIV_EN; @@ -389,12 +389,7 @@ int davinci_set_pllrate(struct pll_data *pll, unsigned int prediv, ctrl &= ~(PLLCTL_PLLENSRC | PLLCTL_PLLEN); __raw_writel(ctrl, pll->base + PLLCTL); - /* - * Wait for 4 OSCIN/CLKIN cycles to ensure that the PLLC has switched - * to bypass mode. Delay of 1us ensures we are good for all > 4MHz - * OSCIN/CLKIN inputs. Typically the input is ~25MHz. - */ - udelay(1); + udelay(PLL_BYPASS_TIME); /* Reset and enable PLL */ ctrl &= ~(PLLCTL_PLLRST | PLLCTL_PLLDIS); @@ -408,11 +403,7 @@ int davinci_set_pllrate(struct pll_data *pll, unsigned int prediv, if (pll->flags & PLL_HAS_POSTDIV) __raw_writel(postdiv, pll->base + POSTDIV); - /* - * Wait for PLL to reset properly, OMAP-L138 datasheet says - * 'min' time = 125ns - */ - udelay(1); + udelay(PLL_RESET_TIME); /* Bring PLL out of reset */ ctrl |= PLLCTL_PLLRST; diff --git a/arch/arm/mach-davinci/clock.h b/arch/arm/mach-davinci/clock.h index c92d77a..eca4d99 100644 --- a/arch/arm/mach-davinci/clock.h +++ b/arch/arm/mach-davinci/clock.h @@ -53,6 +53,21 @@ #define PLLDIV_EN BIT(15) #define PLLDIV_RATIO_MASK 0x1f +/* + * OMAP-L138 system reference guide recommends a wait for 4 OSCIN/CLKIN + * cycles to ensure that the PLLC has switched to bypass mode. Delay of 1us + * ensures we are good for all > 4MHz OSCIN/CLKIN inputs. Typically the input + * is ~25MHz. Units are micro seconds. + */ +#define PLL_BYPASS_TIME 1 +/* From OMAP-L138 datasheet table 6-4. Units are micro seconds */ +#define PLL_RESET_TIME 1 +/* + * From OMAP-L138 datasheet table 6-4; assuming prediv = 1, sqrt(pllm) = 4 + * Units are micro seconds. + */ +#define PLL_LOCK_TIME 20 + struct pll_data { u32 phys_base; void __iomem *base; -- 1.6.6.rc2.1.g42108 From khilman at deeprootsystems.com Wed Jan 6 12:31:45 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 6 Jan 2010 10:31:45 -0800 Subject: [PATCH 03/35] davinci: move DDR2 controller defines to memory.h In-Reply-To: <1262802737-6601-3-git-send-email-khilman@deeprootsystems.com> References: <1262802737-6601-1-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-2-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-3-git-send-email-khilman@deeprootsystems.com> Message-ID: <1262802737-6601-4-git-send-email-khilman@deeprootsystems.com> From: Sekhar Nori Move defintions of DDR2 controller registers to memory.h from cpuidle.c. The motivation behind the change is to be able to use these defintions in assembly code that puts DDR2 in self-refresh and enables the SoC to enter suspend state. Signed-off-by: Sekhar Nori Signed-off-by: Kevin Hilman --- arch/arm/mach-davinci/cpuidle.c | 5 +---- arch/arm/mach-davinci/include/mach/memory.h | 4 ++++ 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c index 97a90f3..beda3b5 100644 --- a/arch/arm/mach-davinci/cpuidle.c +++ b/arch/arm/mach-davinci/cpuidle.c @@ -19,6 +19,7 @@ #include #include +#include #define DAVINCI_CPUIDLE_MAX_STATES 2 @@ -39,10 +40,6 @@ static struct cpuidle_driver davinci_idle_driver = { static DEFINE_PER_CPU(struct cpuidle_device, davinci_cpuidle_device); static void __iomem *ddr2_reg_base; -#define DDR2_SDRCR_OFFSET 0xc -#define DDR2_SRPD_BIT BIT(23) -#define DDR2_LPMODEN_BIT BIT(31) - static void davinci_save_ddr_power(int enter, bool pdown) { u32 val; diff --git a/arch/arm/mach-davinci/include/mach/memory.h b/arch/arm/mach-davinci/include/mach/memory.h index 80309ae..7aeaf46 100644 --- a/arch/arm/mach-davinci/include/mach/memory.h +++ b/arch/arm/mach-davinci/include/mach/memory.h @@ -31,6 +31,10 @@ #define PHYS_OFFSET DAVINCI_DDR_BASE #endif +#define DDR2_SDRCR_OFFSET 0xc +#define DDR2_SRPD_BIT BIT(23) +#define DDR2_LPMODEN_BIT BIT(31) + /* * Increase size of DMA-consistent memory region */ -- 1.6.6.rc2.1.g42108 From khilman at deeprootsystems.com Wed Jan 6 12:31:46 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 6 Jan 2010 10:31:46 -0800 Subject: [PATCH 04/35] davinci: move PSC register definitions from psc.c to psc.h In-Reply-To: <1262802737-6601-4-git-send-email-khilman@deeprootsystems.com> References: <1262802737-6601-1-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-2-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-3-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-4-git-send-email-khilman@deeprootsystems.com> Message-ID: <1262802737-6601-5-git-send-email-khilman@deeprootsystems.com> From: Sekhar Nori The motivation behind the change is to use the same definitions in the assembly code responsible for suspending the SoC, a part of which is to clock gate the DDR2 clock. Note that the assembly code cannot invoke the C function meant for this. The main reason being that stack in DDR2 cannot be accessed while DDR2 clock is being clock gated. Signed-off-by: Sekhar Nori Signed-off-by: Kevin Hilman --- arch/arm/mach-davinci/include/mach/psc.h | 11 +++++++++++ arch/arm/mach-davinci/psc.c | 11 ----------- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/arch/arm/mach-davinci/include/mach/psc.h b/arch/arm/mach-davinci/include/mach/psc.h index 171173c..2776b23 100644 --- a/arch/arm/mach-davinci/include/mach/psc.h +++ b/arch/arm/mach-davinci/include/mach/psc.h @@ -180,6 +180,17 @@ #define DA8XX_LPSC1_CR_P3_SS 26 #define DA8XX_LPSC1_L3_CBA_RAM 31 +/* PSC register offsets */ +#define EPCPR 0x070 +#define PTCMD 0x120 +#define PTSTAT 0x128 +#define PDSTAT 0x200 +#define PDCTL1 0x304 +#define MDSTAT 0x800 +#define MDCTL 0xA00 + +#define MDSTAT_STATE_MASK 0x1f + extern int davinci_psc_is_clk_active(unsigned int ctlr, unsigned int id); extern void davinci_psc_config(unsigned int domain, unsigned int ctlr, unsigned int id, char enable); diff --git a/arch/arm/mach-davinci/psc.c b/arch/arm/mach-davinci/psc.c index 04a3cb7..adf6b5c 100644 --- a/arch/arm/mach-davinci/psc.c +++ b/arch/arm/mach-davinci/psc.c @@ -25,17 +25,6 @@ #include #include -/* PSC register offsets */ -#define EPCPR 0x070 -#define PTCMD 0x120 -#define PTSTAT 0x128 -#define PDSTAT 0x200 -#define PDCTL1 0x304 -#define MDSTAT 0x800 -#define MDCTL 0xA00 - -#define MDSTAT_STATE_MASK 0x1f - /* Return nonzero iff the domain's clock is active */ int __init davinci_psc_is_clk_active(unsigned int ctlr, unsigned int id) { -- 1.6.6.rc2.1.g42108 From khilman at deeprootsystems.com Wed Jan 6 12:31:47 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 6 Jan 2010 10:31:47 -0800 Subject: [PATCH 05/35] davinci: make it possible to include clock.h and psc.h in assembly code In-Reply-To: <1262802737-6601-5-git-send-email-khilman@deeprootsystems.com> References: <1262802737-6601-1-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-2-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-3-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-4-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-5-git-send-email-khilman@deeprootsystems.com> Message-ID: <1262802737-6601-6-git-send-email-khilman@deeprootsystems.com> From: Sekhar Nori psc.h contains register defines for PSC module which need to be accessed in assembly code which helps the DA850/OMAP-L138 SoC go to sleep. Shutting down DDR clock using PSC is a part of the sleep procedure. Also, the PLL related hardware definitions in clock.h are needed in assembly code to bypass the DDR2 PLL. Signed-off-by: Sekhar Nori Signed-off-by: Kevin Hilman --- arch/arm/mach-davinci/clock.h | 10 +++++++--- arch/arm/mach-davinci/include/mach/psc.h | 4 ++++ 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-davinci/clock.h b/arch/arm/mach-davinci/clock.h index eca4d99..31fb6ea 100644 --- a/arch/arm/mach-davinci/clock.h +++ b/arch/arm/mach-davinci/clock.h @@ -12,9 +12,6 @@ #ifndef __ARCH_ARM_DAVINCI_CLOCK_H #define __ARCH_ARM_DAVINCI_CLOCK_H -#include -#include - #define DAVINCI_PLL1_BASE 0x01c40800 #define DAVINCI_PLL2_BASE 0x01c40c00 #define MAX_PLL 2 @@ -68,6 +65,11 @@ */ #define PLL_LOCK_TIME 20 +#ifndef __ASSEMBLER__ + +#include +#include + struct pll_data { u32 phys_base; void __iomem *base; @@ -124,3 +126,5 @@ int davinci_set_pllrate(struct pll_data *pll, unsigned int prediv, extern struct platform_device davinci_wdt_device; #endif + +#endif diff --git a/arch/arm/mach-davinci/include/mach/psc.h b/arch/arm/mach-davinci/include/mach/psc.h index 2776b23..651f6d8 100644 --- a/arch/arm/mach-davinci/include/mach/psc.h +++ b/arch/arm/mach-davinci/include/mach/psc.h @@ -191,8 +191,12 @@ #define MDSTAT_STATE_MASK 0x1f +#ifndef __ASSEMBLER__ + extern int davinci_psc_is_clk_active(unsigned int ctlr, unsigned int id); extern void davinci_psc_config(unsigned int domain, unsigned int ctlr, unsigned int id, char enable); +#endif + #endif /* __ASM_ARCH_PSC_H */ -- 1.6.6.rc2.1.g42108 From khilman at deeprootsystems.com Wed Jan 6 12:31:48 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 6 Jan 2010 10:31:48 -0800 Subject: [PATCH 06/35] davinci: cpuidle: move mapping of DDR2 controller registers out of driver In-Reply-To: <1262802737-6601-6-git-send-email-khilman@deeprootsystems.com> References: <1262802737-6601-1-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-2-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-3-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-4-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-5-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-6-git-send-email-khilman@deeprootsystems.com> Message-ID: <1262802737-6601-7-git-send-email-khilman@deeprootsystems.com> From: Sekhar Nori When suspend is supported, both cpuidle and suspend code need to work on DDR2 registers. Instead of mapping the DDR2 registers twice, do it once outside of cpuidle driver and let cpuidle driver get the virtual base address of DDR2 registers. Signed-off-by: Sekhar Nori Signed-off-by: Kevin Hilman --- arch/arm/mach-davinci/cpuidle.c | 33 +++---------------------- arch/arm/mach-davinci/devices-da8xx.c | 16 +++++++++++- arch/arm/mach-davinci/include/mach/cpuidle.h | 1 + arch/arm/mach-davinci/include/mach/da8xx.h | 1 + 4 files changed, 21 insertions(+), 30 deletions(-) diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c index beda3b5..bd59f31 100644 --- a/arch/arm/mach-davinci/cpuidle.c +++ b/arch/arm/mach-davinci/cpuidle.c @@ -106,8 +106,6 @@ static int __init davinci_cpuidle_probe(struct platform_device *pdev) int ret; struct cpuidle_device *device; struct davinci_cpuidle_config *pdata = pdev->dev.platform_data; - struct resource *ddr2_regs; - resource_size_t len; device = &per_cpu(davinci_cpuidle_device, smp_processor_id()); @@ -116,28 +114,12 @@ static int __init davinci_cpuidle_probe(struct platform_device *pdev) return -ENOENT; } - ddr2_regs = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!ddr2_regs) { - dev_err(&pdev->dev, "cannot get DDR2 controller register base"); - return -ENODEV; - } - - len = resource_size(ddr2_regs); - - ddr2_regs = request_mem_region(ddr2_regs->start, len, ddr2_regs->name); - if (!ddr2_regs) - return -EBUSY; - - ddr2_reg_base = ioremap(ddr2_regs->start, len); - if (!ddr2_reg_base) { - ret = -ENOMEM; - goto ioremap_fail; - } + ddr2_reg_base = pdata->ddr2_ctlr_base; ret = cpuidle_register_driver(&davinci_idle_driver); if (ret) { dev_err(&pdev->dev, "failed to register driver\n"); - goto driver_register_fail; + return ret; } /* Wait for interrupt state */ @@ -164,18 +146,11 @@ static int __init davinci_cpuidle_probe(struct platform_device *pdev) ret = cpuidle_register_device(device); if (ret) { dev_err(&pdev->dev, "failed to register device\n"); - goto device_register_fail; + cpuidle_unregister_driver(&davinci_idle_driver); + return ret; } return 0; - -device_register_fail: - cpuidle_unregister_driver(&davinci_idle_driver); -driver_register_fail: - iounmap(ddr2_reg_base); -ioremap_fail: - release_mem_region(ddr2_regs->start, len); - return ret; } static struct platform_driver davinci_cpuidle_driver = { diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c index 8de5f9f..5df27f7 100644 --- a/arch/arm/mach-davinci/devices-da8xx.c +++ b/arch/arm/mach-davinci/devices-da8xx.c @@ -489,6 +489,19 @@ int da8xx_register_rtc(void) return platform_device_register(&da8xx_rtc_device); } +static void __iomem *da8xx_ddr2_ctlr_base; +void __iomem * __init da8xx_get_mem_ctlr(void) +{ + if (da8xx_ddr2_ctlr_base) + return da8xx_ddr2_ctlr_base; + + da8xx_ddr2_ctlr_base = ioremap(DA8XX_DDR2_CTL_BASE, SZ_32K); + if (!da8xx_ddr2_ctlr_base) + pr_warning("%s: Unable to map DDR2 controller", __func__); + + return da8xx_ddr2_ctlr_base; +} + static struct resource da8xx_cpuidle_resources[] = { { .start = DA8XX_DDR2_CTL_BASE, @@ -514,6 +527,7 @@ static struct platform_device da8xx_cpuidle_device = { int __init da8xx_register_cpuidle(void) { + da8xx_cpuidle_pdata.ddr2_ctlr_base = da8xx_get_mem_ctlr(); + return platform_device_register(&da8xx_cpuidle_device); } - diff --git a/arch/arm/mach-davinci/include/mach/cpuidle.h b/arch/arm/mach-davinci/include/mach/cpuidle.h index cbfc6a9..74f088b 100644 --- a/arch/arm/mach-davinci/include/mach/cpuidle.h +++ b/arch/arm/mach-davinci/include/mach/cpuidle.h @@ -12,6 +12,7 @@ struct davinci_cpuidle_config { u32 ddr2_pdown; + void __iomem *ddr2_ctlr_base; }; #endif diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h index bddc4d4..cab4a25 100644 --- a/arch/arm/mach-davinci/include/mach/da8xx.h +++ b/arch/arm/mach-davinci/include/mach/da8xx.h @@ -94,6 +94,7 @@ void __init da8xx_register_mcasp(int id, struct snd_platform_data *pdata); int da8xx_register_rtc(void); int da850_register_cpufreq(void); int da8xx_register_cpuidle(void); +void __iomem * __init da8xx_get_mem_ctlr(void); extern struct platform_device da8xx_serial_device; extern struct emac_platform_data da8xx_emac_pdata; -- 1.6.6.rc2.1.g42108 From khilman at deeprootsystems.com Wed Jan 6 12:31:49 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 6 Jan 2010 10:31:49 -0800 Subject: [PATCH 07/35] davinci: da850/omap-l138: unlock PLL registers during init In-Reply-To: <1262802737-6601-7-git-send-email-khilman@deeprootsystems.com> References: <1262802737-6601-1-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-2-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-3-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-4-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-5-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-6-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-7-git-send-email-khilman@deeprootsystems.com> Message-ID: <1262802737-6601-8-git-send-email-khilman@deeprootsystems.com> From: Sekhar Nori On omap-l1 devices the PLL registers can be locked from writes. Currently the cpufreq rate setting code unlocks PLL0 before the write actually happens. With suspend support getting added PLL1 registers need be be unlocked as well. To facilitate this, unlock both PLLs during the init time itself. This also obviates the need to unlock PLL registers for each CPUFreq transtition. Signed-off-by: Sekhar Nori Signed-off-by: Kevin Hilman --- arch/arm/mach-davinci/da850.c | 19 +++++++++++++------ 1 files changed, 13 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c index 4f84ab4..fcfde2a 100644 --- a/arch/arm/mach-davinci/da850.c +++ b/arch/arm/mach-davinci/da850.c @@ -40,6 +40,7 @@ #define DA850_REF_FREQ 24000000 #define CFGCHIP3_ASYNC3_CLKSRC BIT(4) +#define CFGCHIP3_PLL1_MASTER_LOCK BIT(5) #define CFGCHIP0_PLL_MASTER_LOCK BIT(4) static int da850_set_armrate(struct clk *clk, unsigned long rate); @@ -987,7 +988,6 @@ static int da850_set_pll0rate(struct clk *clk, unsigned long index) unsigned int prediv, mult, postdiv; struct da850_opp *opp; struct pll_data *pll = clk->pll_data; - unsigned int v; int ret; opp = (struct da850_opp *) da850_freq_table[index].index; @@ -995,11 +995,6 @@ static int da850_set_pll0rate(struct clk *clk, unsigned long index) mult = opp->mult; postdiv = opp->postdiv; - /* Unlock writing to PLL registers */ - v = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP0_REG)); - v &= ~CFGCHIP0_PLL_MASTER_LOCK; - __raw_writel(v, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP0_REG)); - ret = davinci_set_pllrate(pll, prediv, mult, postdiv); if (WARN_ON(ret)) return ret; @@ -1053,6 +1048,8 @@ static struct davinci_soc_info davinci_soc_info_da850 = { void __init da850_init(void) { + unsigned int v; + da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K); if (WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module")) return; @@ -1075,4 +1072,14 @@ void __init da850_init(void) * be any noticible change even in non-DVFS use cases. */ da850_set_async3_src(1); + + /* Unlock writing to PLL0 registers */ + v = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP0_REG)); + v &= ~CFGCHIP0_PLL_MASTER_LOCK; + __raw_writel(v, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP0_REG)); + + /* Unlock writing to PLL1 registers */ + v = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG)); + v &= ~CFGCHIP3_PLL1_MASTER_LOCK; + __raw_writel(v, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG)); } -- 1.6.6.rc2.1.g42108 From khilman at deeprootsystems.com Wed Jan 6 12:31:50 2010 From: khilman at deeprootsystems.com (Kevin Hilman) Date: Wed, 6 Jan 2010 10:31:50 -0800 Subject: [PATCH 08/35] davinci: da850/omap-l138: create static map for SRAM In-Reply-To: <1262802737-6601-8-git-send-email-khilman@deeprootsystems.com> References: <1262802737-6601-1-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-2-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-3-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-4-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-5-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-6-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-7-git-send-email-khilman@deeprootsystems.com> <1262802737-6601-8-git-send-email-khilman@deeprootsystems.com> Message-ID: <1262802737-6601-9-git-send-email-khilman@deeprootsystems.com> From: Sekhar Nori Create static map for internal SRAM and populate SRAM base and size in soc_info structure to allow SRAM allocation functions from arch/arm/mach-davinci/sram.c to work. On DA850 SRAM is used for suspend-to-RAM implementation in places where DDR2 cannot be accessed as its clocks are stopped. Signed-off-by: Sekhar Nori Signed-off-by: Kevin Hilman --- arch/arm/mach-davinci/da850.c | 8 ++++++++ arch/arm/mach-davinci/include/mach/da8xx.h | 1 + 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c index fcfde2a..1ac8f63 100644 --- a/arch/arm/mach-davinci/da850.c +++ b/arch/arm/mach-davinci/da850.c @@ -771,6 +771,12 @@ static struct map_desc da850_io_desc[] = { .length = DA8XX_CP_INTC_SIZE, .type = MT_DEVICE }, + { + .virtual = SRAM_VIRT, + .pfn = __phys_to_pfn(DA8XX_ARM_RAM_BASE), + .length = SZ_8K, + .type = MT_DEVICE + }, }; static void __iomem *da850_psc_bases[] = { @@ -1044,6 +1050,8 @@ static struct davinci_soc_info davinci_soc_info_da850 = { .gpio_irq = IRQ_DA8XX_GPIO0, .serial_dev = &da8xx_serial_device, .emac_pdata = &da8xx_emac_pdata, + .sram_dma = DA8XX_ARM_RAM_BASE, + .sram_len = SZ_8K, }; void __init da850_init(void) diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h index cab4a25..d43a4b6 100644 --- a/arch/arm/mach-davinci/include/mach/da8xx.h +++ b/arch/arm/mach-davinci/include/mach/da8xx.h @@ -57,6 +57,7 @@ extern void __iomem *da8xx_syscfg1_base; #define DA8XX_AEMIF_CS3_BASE 0x62000000 #define DA8XX_AEMIF_CTL_BASE 0x68000000 #define DA8XX_DDR2_CTL_BASE 0xb0000000 +#define DA8XX_ARM_RAM_BASE 0xffff0000 #define PINMUX0 0x00 #define PINMUX1 0x04 -- 1.6.6