RE: [PATCH v4] i2c: davinci: Fix race when setting up for TX
Kevin Hilman wrote: I just noticed that it has already been pulled and is part of -rc7. Jon, care to submit a new patch with v4 diff and including the acks and tested-bys? Done and sent: Message-Id: 1286858825-21540-1-git-send-email-jon.po...@racelogic.co.uk -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v4] i2c: davinci: Fix race when setting up for TX
Hi Ben, I am not on the i2c list but noticed this pull request: http://www.spinics.net/linux/lists/linux-i2c/msg04022.html I think you have the wrong (old) version of this patch in that branch, http://git.fluff.org/gitweb?p=bjdooks/linux.git;a=commitdiff;h=4bba0fd8d1c6d405df666e2573e1a1f917098be0 The correct v4 one from the start of this thread has more lines of patch and this commit message: When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com It also has some more acks and a tested, via Kevin: Acked-by: Troy Kisky troy.ki...@boundarydevices.com Tested-by: Sudhakar Rajashekhara sudhakar@ti.com Acked-by: Kevin Hilman khil...@deeprootsystems.com -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX
Jon Povey jon.po...@racelogic.co.uk writes: Hi Ben, I am not on the i2c list but noticed this pull request: http://www.spinics.net/linux/lists/linux-i2c/msg04022.html I think you have the wrong (old) version of this patch in that branch, http://git.fluff.org/gitweb?p=bjdooks/linux.git;a=commitdiff;h=4bba0fd8d1c6d405df666e2573e1a1f917098be0 The correct v4 one from the start of this thread has more lines of patch and this commit message: It is also available in my davinci-i2c branch: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git davinci-i2c Thanks Jon for catching this, Kevin When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com It also has some more acks and a tested, via Kevin: Acked-by: Troy Kisky troy.ki...@boundarydevices.com Tested-by: Sudhakar Rajashekhara sudhakar@ti.com Acked-by: Kevin Hilman khil...@deeprootsystems.com -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX
Kevin Hilman khil...@deeprootsystems.com writes: Jon Povey jon.po...@racelogic.co.uk writes: Hi Ben, I am not on the i2c list but noticed this pull request: http://www.spinics.net/linux/lists/linux-i2c/msg04022.html I think you have the wrong (old) version of this patch in that branch, http://git.fluff.org/gitweb?p=bjdooks/linux.git;a=commitdiff;h=4bba0fd8d1c6d405df666e2573e1a1f917098be0 The correct v4 one from the start of this thread has more lines of patch and this commit message: It is also available in my davinci-i2c branch: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git davinci-i2c Thanks Jon for catching this, I just noticed that it has already been pulled and is part of -rc7. Jon, care to submit a new patch with v4 diff and including the acks and tested-bys? Thanks, Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX
Ben Dooks ben-...@fluff.org writes: On Tue, Sep 21, 2010 at 12:17:58PM -0700, Troy Kisky wrote: On 9/21/2010 4:24 AM, Sudhakar Rajashekhara wrote: Hi, On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote: When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com --- Reworked after comments by Troy and Sudhakar. Looking at the datasheet it seemed like setting STP without STT early might cause a stray STOP to be generated, so I moved it into the second MDR load. This passes a quick smoke test but I can't do much more testing right at the moment. Sudhakar, your comments would be welcomed. Looks good to me. I can test on couple of platforms I have and update the result by tomorrow. Thanks, Sudhakar I like it too. I hope it works for omap. Thanks as well Troy Ok, any objections to this being applied, or should I wait? Please apply with: Acked-by: Troy Kisky troy.ki...@boundarydevices.com Tested-by: Sudhakar Rajashekhara sudhakar@ti.com Acked-by: Kevin Hilman khil...@deeprootsystems.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX
On Tue, Sep 21, 2010 at 12:17:58PM -0700, Troy Kisky wrote: On 9/21/2010 4:24 AM, Sudhakar Rajashekhara wrote: Hi, On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote: When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com --- Reworked after comments by Troy and Sudhakar. Looking at the datasheet it seemed like setting STP without STT early might cause a stray STOP to be generated, so I moved it into the second MDR load. This passes a quick smoke test but I can't do much more testing right at the moment. Sudhakar, your comments would be welcomed. Looks good to me. I can test on couple of platforms I have and update the result by tomorrow. Thanks, Sudhakar I like it too. I hope it works for omap. Thanks as well Troy Ok, any objections to this being applied, or should I wait? -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX
On Fri, Sep 24, 2010 at 07:37:03AM -0700, Kevin Hilman wrote: Sudhakar Rajashekhara sudhakar@ti.com writes: On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote: When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com --- Tested-by: Sudhakar Rajashekhara sudhakar@ti.com Tested with audio loopback on OMAP-L138, OMAP-L137 and DM365. Also tested with i2cdetect function which probes all the devices on the i2c bus. Ben, can you queue this one for 2.6.37 with the addition of: If it is a worthwhile bugfix i'll send it for the next -rc. Acked-by: Troy Kisky troy.ki...@boundarydevices.com Tested-by: Sudhakar Rajashekhara sudhakar@ti.com Acked-by: Kevin Hilman khil...@deeprootsystems.com Thanks, Kevin -- -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX
Ben Dooks b...@trinity.fluff.org writes: On Fri, Sep 24, 2010 at 07:37:03AM -0700, Kevin Hilman wrote: Sudhakar Rajashekhara sudhakar@ti.com writes: On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote: When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com --- Tested-by: Sudhakar Rajashekhara sudhakar@ti.com Tested with audio loopback on OMAP-L138, OMAP-L137 and DM365. Also tested with i2cdetect function which probes all the devices on the i2c bus. Ben, can you queue this one for 2.6.37 with the addition of: If it is a worthwhile bugfix i'll send it for the next -rc. OK, yeah. It's probably better to queue for the next -rc. Thanks, Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX
Sudhakar Rajashekhara sudhakar@ti.com writes: On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote: When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com --- Tested-by: Sudhakar Rajashekhara sudhakar@ti.com Tested with audio loopback on OMAP-L138, OMAP-L137 and DM365. Also tested with i2cdetect function which probes all the devices on the i2c bus. Ben, can you queue this one for 2.6.37 with the addition of: Acked-by: Troy Kisky troy.ki...@boundarydevices.com Tested-by: Sudhakar Rajashekhara sudhakar@ti.com Acked-by: Kevin Hilman khil...@deeprootsystems.com Thanks, Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX
Troy Kisky troy.ki...@boundarydevices.com writes: On 9/21/2010 4:24 AM, Sudhakar Rajashekhara wrote: Hi, On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote: When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com --- Reworked after comments by Troy and Sudhakar. Looking at the datasheet it seemed like setting STP without STT early might cause a stray STOP to be generated, so I moved it into the second MDR load. This passes a quick smoke test but I can't do much more testing right at the moment. Sudhakar, your comments would be welcomed. Looks good to me. I can test on couple of platforms I have and update the result by tomorrow. Thanks, Sudhakar I like it too. I hope it works for omap. Troy, can I take this as an Acked-by from you? or a Tested-by? Thanks, Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX
On 9/23/2010 7:27 AM, Kevin Hilman wrote: Troy Kisky troy.ki...@boundarydevices.com writes: On 9/21/2010 4:24 AM, Sudhakar Rajashekhara wrote: Hi, On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote: When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com --- Reworked after comments by Troy and Sudhakar. Looking at the datasheet it seemed like setting STP without STT early might cause a stray STOP to be generated, so I moved it into the second MDR load. This passes a quick smoke test but I can't do much more testing right at the moment. Sudhakar, your comments would be welcomed. Looks good to me. I can test on couple of platforms I have and update the result by tomorrow. Thanks, Sudhakar I like it too. I hope it works for omap. Troy, can I take this as an Acked-by from you? or a Tested-by? Thanks, Kevin Acked-by is fine, but I didn't test it. Troy ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v4] i2c: davinci: Fix race when setting up for TX
On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote: When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com --- Tested-by: Sudhakar Rajashekhara sudhakar@ti.com Tested with audio loopback on OMAP-L138, OMAP-L137 and DM365. Also tested with i2cdetect function which probes all the devices on the i2c bus. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v4] i2c: davinci: Fix race when setting up for TX
Hi, On Wed, Sep 22, 2010 at 05:39:16, Ben Dooks wrote: On Tue, Sep 21, 2010 at 12:17:58PM -0700, Troy Kisky wrote: On 9/21/2010 4:24 AM, Sudhakar Rajashekhara wrote: Hi, On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote: When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com --- Reworked after comments by Troy and Sudhakar. Looking at the datasheet it seemed like setting STP without STT early might cause a stray STOP to be generated, so I moved it into the second MDR load. This passes a quick smoke test but I can't do much more testing right at the moment. Sudhakar, your comments would be welcomed. Looks good to me. I can test on couple of platforms I have and update the result by tomorrow. Thanks, Sudhakar I like it too. I hope it works for omap. Thanks as well Troy Ok, any objections to this being applied, or should I wait? I am stuck in some other work. If you can wait till I test it, that'll be good. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v4] i2c: davinci: Fix race when setting up for TX
Hi, On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote: When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com --- Reworked after comments by Troy and Sudhakar. Looking at the datasheet it seemed like setting STP without STT early might cause a stray STOP to be generated, so I moved it into the second MDR load. This passes a quick smoke test but I can't do much more testing right at the moment. Sudhakar, your comments would be welcomed. Looks good to me. I can test on couple of platforms I have and update the result by tomorrow. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX
On 9/21/2010 4:24 AM, Sudhakar Rajashekhara wrote: Hi, On Tue, Sep 21, 2010 at 09:43:28, Jon Povey wrote: When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com --- Reworked after comments by Troy and Sudhakar. Looking at the datasheet it seemed like setting STP without STT early might cause a stray STOP to be generated, so I moved it into the second MDR load. This passes a quick smoke test but I can't do much more testing right at the moment. Sudhakar, your comments would be welcomed. Looks good to me. I can test on couple of platforms I have and update the result by tomorrow. Thanks, Sudhakar I like it too. I hope it works for omap. Thanks as well Troy ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
