All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Janusz Użycki" <j.uzycki-9tnw74Q4ehaHKKo6LODCOg@public.gmane.org>
To: marex-ynQEQJNshbs@public.gmane.org
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org
Subject: Re: [PATCH] i2c-mxs: detect No Slave Ack on SELECT in PIO mode
Date: Wed, 10 Sep 2014 17:57:31 +0200	[thread overview]
Message-ID: <541074EB.3060702@elproma.com.pl> (raw)
In-Reply-To: <1410362286-1785-1-git-send-email-j.uzycki-9tnw74Q4ehaHKKo6LODCOg@public.gmane.org>


W dniu 2014-09-10 17:18, Janusz Uzycki pisze:
> Reported problem:
> i2cdetect scanned i2c bus very slow if address was not occupied by any device.
>
> Solution:
> The patch adds to mxs_i2c_pio_wait_xfer_end() function
> NO_SLAVE_ACK_IRQ bit polling during wait loop (until timeout).
> If the bit is set the function immediately returns ENXIO error
> in order to break the loop and not reset I2C block (it is in idle state then).
> The function is called by mxs_i2c_pio_setup_xfer() to wait for complete xfer
> after sent SELECT, READ or WRITE command.
> If SELECT command is sent and selected slave address is unused by any device
> on the bus I2C block sets NO_SLAVE_ACK_IRQ flag and doesn't deassert CTRL0_RUN.
> Therefore we need to break the timeout loop when the flag is set,
> otherwise the loop continues until long timeout (1000ms).
> The change does not affect READ command because slave does not ack
> any byte then (only the master does ack / or not for the last read byte).
> According to i.MX28 reference manual (quoted below) it is not clear
> if the patch affects WRITE command. However when no acked bytes
> on WRITE command followed after address byte (SELECT command)
> STAT_GOT_A_NAK flag is set rather than NO_SLAVE_ACK_IRQ (no tested).
> Therefore clock stretching shouldn't be affected too.
> It has confirmation in FSL BSP 2.6.35 i2c implementation which
> completes xfer after NO_SLAVE_ACK_IRQ interrupt and scheduled work.
> Registers on NO_SLAVE_ACK_IRQ in PIO mode:
>
Some words of comment about clock stretching. In the patch
I meant clock stretching by master (RETAIN_CLOCK) during WRITE command.
This prevents to use the bus by other master (multimaster bus).
However there is also possible "clock low period stretching" by slave device
(I wrote about in threads before) to inform the master that clock is too 
fast
or slave is not ready. Then slave sets SCL line to low state.
The case is rather not supported by any i2c driver in Linux? The i2c 
clock freq. is fixed.
Therefore when SCL is hold by long time master treats it as NACK, show 
streching by slave
is probably handled directly by master's hardware if implemented.
Clock strechting by slave seems impossible when RETAIN_CLOCK set by master.
Clock stretching by master is not affected by the patch because the 
master decides
when ACK/NACK is received from slave during WRITE command.

best regards
Janusz

  parent reply	other threads:[~2014-09-10 15:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-10 15:18 [PATCH] i2c-mxs: detect No Slave Ack on SELECT in PIO mode Janusz Uzycki
     [not found] ` <1410362286-1785-1-git-send-email-j.uzycki-9tnw74Q4ehaHKKo6LODCOg@public.gmane.org>
2014-09-10 15:57   ` Janusz Użycki [this message]
2014-09-19  2:45   ` Marek Vasut
     [not found]     ` <201409190445.21419.marex-ynQEQJNshbs@public.gmane.org>
2014-09-22 14:33       ` Janusz Użycki
     [not found]         ` <5420334D.8090809-9tnw74Q4ehaHKKo6LODCOg@public.gmane.org>
2014-09-22 15:04           ` Marek Vasut
  -- strict thread matches above, loose matches on Subject: below --
2014-09-23 10:48 Janusz Uzycki
     [not found] ` <1411469306-15390-1-git-send-email-j.uzycki-9tnw74Q4ehaHKKo6LODCOg@public.gmane.org>
2014-09-23 10:48   ` Janusz Użycki
2014-10-03  0:51   ` Wolfram Sang

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=541074EB.3060702@elproma.com.pl \
    --to=j.uzycki-9tnw74q4ehahkko6lodcog@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=marex-ynQEQJNshbs@public.gmane.org \
    --cc=wsa-z923LK4zBo2bacvFa/9K2g@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.