From: Ned Forrester <nforrester-/d+BM93fTQY@public.gmane.org>
To: Ned Forrester <nforrester-/d+BM93fTQY@public.gmane.org>
Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
"J. Scott Merritt" <merrij3-IL7dBOYR4Vg@public.gmane.org>,
stephen-nl6u4wocdmy51APUEpUfAkEOCMrvLtNR@public.gmane.org
Subject: Re: PXA270 SSPSFRM gates chip select ?
Date: Mon, 11 Feb 2008 23:08:54 -0500 [thread overview]
Message-ID: <47B11BD6.8060502@whoi.edu> (raw)
In-Reply-To: <47B0D9A4.6080104-/d+BM93fTQY@public.gmane.org>
Ned Forrester wrote:
> J. Scott Merritt wrote:
>> Reposted from linux-arm-kernel mailing list ... at the suggestion
>> of David Brownell.
>>
>> Using pxa2xx_spi from Kernel 2.6.21. PXA270 is SSP Master in
>> SPI_MODE_3 (SPO=1, SPH=1) with internal clock and GPIO's used as
>> external chip selects.
>>
>> On the very first message after boot, I am receiving an extra clock
>> pulse at the slave device (causing the whole message to be "shifted").
>>
>> It appears that on the first message, the Chip Select is activated
>> before the SPO=1/SPH=1 is fully established in the PXA's SSP hardware,
>> resulting in an extra, positive-going transition of SSPSCLK as it
>> attempts to establish the proper (high) clock level for the SPH=1
>> setting.
>>
>> Testing was performed on Kernal 2.6.21, but it appears that 2.6.24
>> also performs the chip select call before updating SSCR0 & SSCR1.
>> Slave device is NXP LPC2366.
>>
>> I have tried setting the "default" in pxa2xx_spi.c to SPO=1, SPH=1;
>> but still have the clock riding low before the first chip select.
>
> I have worked with this driver extensively, so I took a look. It seems
> that you are right. The these bits are set at the end of
> pump_transfers(), based on internal values that are configured in
> setup(). The SSCR1 register is initialized with default data in
> probe(), but this default value is not influenced from any other
> configuration data.
>
> SSCR1 contains the interrupt enables and dma service request enables.
> As such, it is set as the very last task in pump_transfers(), after all
> other setup, including the call to cs_control(). If I recall correctly,
> in some modes of operation, it is important that this register not be
> written when activity is already in progress, and so it is only set if
> changed at the end of pump_transfers(). It appears that there needs to
> be a check for changed clock mode in pump_transfers(), prior to setting
> chip select. It is important to do this carefully, so as not to
> interfere with on-going operations.
>
> I will take a closer look at this. I know that normally each of these
> SPI transfers is independent, but I worked with Stephen Street (the
> maintainer) over a year ago to prep this driver for some external master
> data steaming that I needed, and I know we worked in this area of the
> driver. It is possible that we messed this up, as I don't use chip select.
I have looked some more, and I see what happened. In the fall of 2006 I
worked with Stephen to fix some bugs, and to implement a few changes
that would facilitate chaining of transfers and messages when no
configuration changes are required between transfers. In the process,
we removed the function restore_state(), which was called only from
pump_messages() and which stopped the SSP and set up the SSCRx
registers. All of the SSCRx changes were reduced to a single, final
code segment at the end of pump_transfers, so as to create a
maintainable place to manage the "set only if changed" function required
by chaining of transfers. However, removing the call in pump_messages()
has the side effect of not setting up SSCCRx until *after* any CS
change, and thus a configuration change will not occur until CS has been
set on the first transfer that uses that config change. These code
changes were implemented by a patch released by Stephen on 12/7/06 (I'm
not sure which kernel release it first appeared in).
I will try to think about a patch tomorrow. I volunteer to be involved
in this so that it gets fixed without breaking the other things I need
to do. Hopefully Stephen will be available to review any patches.
>> ... David Brownell responds:
>>
>> Actually, the SPI_CPOL mode bit controls the clock polarity
>> before the chip select coes active: CPOL=0 should mean it's
>> forced low (if it isn't already low).
>>
>> So if that driver is doing chipselect *then* clock setup,
>> it's doing the wrong thing. A patch would be appreciated...
>>
>> ...
>> Thanks, Scott.
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> spi-devel-general mailing list
>> spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> https://lists.sourceforge.net/lists/listinfo/spi-devel-general
>>
>>
>
>
--
Ned Forrester nforrester-/d+BM93fTQY@public.gmane.org
Oceanographic Systems Lab 508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA
http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212
http://www.whoi.edu/hpb/Site.do?id=1532
http://www.whoi.edu/page.do?pid=10079
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
next prev parent reply other threads:[~2008-02-12 4:08 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-11 22:43 PXA270 SSPSFRM gates chip select ? J. Scott Merritt
[not found] ` <20080211174339.73ca7ed5.merrij3-IL7dBOYR4Vg@public.gmane.org>
2008-02-11 22:54 ` Zik Saleeba
[not found] ` <33e9dd1c0802111454k5deeaa38o9d21cee610b79da7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-02-12 2:51 ` David Brownell
[not found] ` <200802111851.10155.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>
2008-02-12 3:15 ` Zik Saleeba
[not found] ` <33e9dd1c0802111915q48cb80ecxb33461a9263f9295-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-02-12 4:02 ` David Brownell
2008-02-12 3:24 ` Ned Forrester
[not found] ` <47B11178.6090904-/d+BM93fTQY@public.gmane.org>
2008-02-12 3:48 ` Zik Saleeba
[not found] ` <33e9dd1c0802111948u2256d0adj8caa478073795d78-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-02-12 4:16 ` David Brownell
2008-02-12 4:19 ` Zik Saleeba
2008-02-12 4:43 ` Ned Forrester
[not found] ` <47B12406.9040208-/d+BM93fTQY@public.gmane.org>
2008-02-12 5:24 ` Zik Saleeba
[not found] ` <33e9dd1c0802112124y5ae8dd39ua9078f2b3878a018-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-02-12 20:48 ` Zik Saleeba
2008-02-12 4:20 ` David Brownell
2008-02-11 23:26 ` Ned Forrester
[not found] ` <47B0D9A4.6080104-/d+BM93fTQY@public.gmane.org>
2008-02-12 4:08 ` Ned Forrester [this message]
2008-11-07 16:43 ` PXA270 SSP DMA Corruption J. Scott Merritt
[not found] ` <20081107114312.2f34b389.merrij3-IL7dBOYR4Vg@public.gmane.org>
2008-11-07 18:59 ` Ned Forrester
2008-11-07 19:00 ` PXA270 SSP DMA Corruption - correction J. Scott Merritt
[not found] ` <20081107184819.54baa679.merrij3@rpi.edu>
[not found] ` <491B6249.7070407@whoi.edu>
[not found] ` <491B6249.7070407-/d+BM93fTQY@public.gmane.org>
2008-11-13 1:24 ` PXA270 SSP DMA Corruption J. Scott Merritt
[not found] ` <20081112202438.61c28cf4.merrij3-IL7dBOYR4Vg@public.gmane.org>
2008-11-13 1:48 ` Ned Forrester
[not found] ` <491B8783.9050800-/d+BM93fTQY@public.gmane.org>
2008-11-13 1:59 ` Ned Forrester
[not found] ` <20081112213403.402948b9.merrij3@rpi.edu>
[not found] ` <20081112213403.402948b9.merrij3-IL7dBOYR4Vg@public.gmane.org>
2008-11-13 3:19 ` Ned Forrester
[not found] ` <20081113120134.70d533c8.merrij3@rpi.edu>
[not found] ` <20081113120134.70d533c8.merrij3-IL7dBOYR4Vg@public.gmane.org>
2008-11-13 18:54 ` Ned Forrester
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47B11BD6.8060502@whoi.edu \
--to=nforrester-/d+bm93ftqy@public.gmane.org \
--cc=merrij3-IL7dBOYR4Vg@public.gmane.org \
--cc=spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=stephen-nl6u4wocdmy51APUEpUfAkEOCMrvLtNR@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).