From: viresh kumar <viresh.kumar-qxv4g6HH51o@public.gmane.org>
To: <spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
"linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org"
<linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
Cc: Dinesh Kumar SHARMA <dinesh.sharma-qxv4g6HH51o@public.gmane.org>,
Armando VISCONTI <armando.visconti-qxv4g6HH51o@public.gmane.org>,
Shiraz HASHIM <shiraz.hashim-qxv4g6HH51o@public.gmane.org>,
Jamie Iles <jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org>,
Vikas MANOCHA <vikas.manocha-qxv4g6HH51o@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [QUERY] Behavior of spi slave memories w.r.t chip select signal.
Date: Fri, 13 May 2011 09:22:57 +0530 [thread overview]
Message-ID: <4DCCAB19.2020302@st.com> (raw)
In-Reply-To: <4DCA0B77.8060700-qxv4g6HH51o@public.gmane.org>
On 05/11/2011 09:37 AM, viresh kumar wrote:
>
> Hello,
>
> Following is what i understood after reading m25p80 driver and spi master
> drivers in drivers/spi folder.
>
> "chip_select signal controls start and end of transfer. For ex: if we have to read
> status reg of spi memory, then we use write_and_then_read() routine. which writes
> 0x9F in one spi transfer and writes dummy bytes and reads rx reg in other transfer.
> And these two transfers are part of single spi_message.
>
> Now, it is controllable to handle cs, and if we send cs_change == 0, then chip select
> is activated at start of message and deactivated at end of message, instead at end
> of every transfer.
>
> Which means, even if there is a delay between command and dummy bytes received at
> spi memory, current transfer will not be terminated by memory as cs is low."
>
> Is this correct??
>
> Actually i am seeing a different behavior by some of the spi memories, like m25p10.
> If there is a delay between read_sts_reg command and dummy bytes, then 0xFFFFFF is
> returned in response. If there is no delay then transfer always passes.
>
Linus, Jamie,
Have you ever seen this kind of issue? Which spi slave memories did you used for testing?
I am using standard pl0022 and m25p80 driver. Tried in all modes: polling, interrupt, dma.
--
viresh
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
WARNING: multiple messages have this Message-ID (diff)
From: viresh.kumar@st.com (viresh kumar)
To: linux-arm-kernel@lists.infradead.org
Subject: [QUERY] Behavior of spi slave memories w.r.t chip select signal.
Date: Fri, 13 May 2011 09:22:57 +0530 [thread overview]
Message-ID: <4DCCAB19.2020302@st.com> (raw)
In-Reply-To: <4DCA0B77.8060700@st.com>
On 05/11/2011 09:37 AM, viresh kumar wrote:
>
> Hello,
>
> Following is what i understood after reading m25p80 driver and spi master
> drivers in drivers/spi folder.
>
> "chip_select signal controls start and end of transfer. For ex: if we have to read
> status reg of spi memory, then we use write_and_then_read() routine. which writes
> 0x9F in one spi transfer and writes dummy bytes and reads rx reg in other transfer.
> And these two transfers are part of single spi_message.
>
> Now, it is controllable to handle cs, and if we send cs_change == 0, then chip select
> is activated at start of message and deactivated at end of message, instead at end
> of every transfer.
>
> Which means, even if there is a delay between command and dummy bytes received at
> spi memory, current transfer will not be terminated by memory as cs is low."
>
> Is this correct??
>
> Actually i am seeing a different behavior by some of the spi memories, like m25p10.
> If there is a delay between read_sts_reg command and dummy bytes, then 0xFFFFFF is
> returned in response. If there is no delay then transfer always passes.
>
Linus, Jamie,
Have you ever seen this kind of issue? Which spi slave memories did you used for testing?
I am using standard pl0022 and m25p80 driver. Tried in all modes: polling, interrupt, dma.
--
viresh
next prev parent reply other threads:[~2011-05-13 3:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-11 4:07 [QUERY] Behavior of spi slave memories w.r.t chip select signal viresh kumar
2011-05-11 4:07 ` viresh kumar
2011-05-11 7:17 ` Jamie Iles
2011-05-11 7:17 ` Jamie Iles
2011-05-11 7:19 ` viresh kumar
2011-05-11 7:19 ` viresh kumar
[not found] ` <4DCA0B77.8060700-qxv4g6HH51o@public.gmane.org>
2011-05-13 3:52 ` viresh kumar [this message]
2011-05-13 3:52 ` viresh kumar
[not found] ` <4DCCAB19.2020302-qxv4g6HH51o@public.gmane.org>
2011-05-13 6:54 ` Linus Walleij
2011-05-13 6:54 ` Linus Walleij
[not found] ` <BANLkTik2OxGdQ7z1JBAsE+=gc5UCgx3wEA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-05-13 9:20 ` viresh kumar
2011-05-13 9:20 ` viresh kumar
2011-05-13 9:04 ` Jamie Iles
2011-05-13 9:04 ` Jamie Iles
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=4DCCAB19.2020302@st.com \
--to=viresh.kumar-qxv4g6hh51o@public.gmane.org \
--cc=armando.visconti-qxv4g6HH51o@public.gmane.org \
--cc=dinesh.sharma-qxv4g6HH51o@public.gmane.org \
--cc=jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org \
--cc=linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=shiraz.hashim-qxv4g6HH51o@public.gmane.org \
--cc=spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=vikas.manocha-qxv4g6HH51o@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.