linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: peda@lysator.liu.se (Peter Rosin)
To: linux-arm-kernel@lists.infradead.org
Subject: Regression: at24 eeprom writing
Date: Sat, 3 Oct 2015 01:05:21 +0200	[thread overview]
Message-ID: <560F0DB1.2020101@lysator.liu.se> (raw)

Hi!

I recently upgraded from the atmel linux-3.18-at91 kernel to vanilla 4.2
and everything seemed fine. Until I tried to write to the little eeprom
chip. I then tried the linux-4.1-at91 kernel and that suffers too.

The symptoms are that it seems like writes get interrupted, and restarted
again without properly initializing everything again. Inspecting the i2c
bus during these fails gets me something like this (int hex) when I

echo abcdefghijklmnopqr > /sys/bus/i2c/devices/0-0050/eeprom

S a0 00 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 P
S a0 10 (clk and data low for a "long" time) 10 71 72 0a P

Notice how the address byte in the second chunk (10) is repeated after
the strange event on the i2c bus.

I looked around and found that if I revert a839ce663b3183209fdf7b1fc4796bfe2a4679c3
"eeprom: at24: extend driver to allow writing via i2c_smbus_write_byte_data"
eeprom writing starts working again.

AFAICT, the i2c-at91 bus driver makes the eeprom driver use the
i2c_transfer code path both with that patch and with it reverted,
so I sadly don't see why the patch makes a difference.

I'm on a board that is based on the sama5d31 evaluation kit, with a
NXP SE97BTP,547 chip and this in the devicetree:

			i2c0: i2c at f0014000 {
				status = "okay";

				jc42 at 18 {
					compatible = "jc42";
					reg = <0x18>;
				};

				eeprom at 50 {
					compatible = "24c02";
					reg = <0x50>;
					pagesize = <16>;
				};
			};

Any ideas?

Cheers,
Peter

             reply	other threads:[~2015-10-02 23:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-02 23:05 Peter Rosin [this message]
2015-10-04 19:50 ` Regression: at24 eeprom writing Peter Rosin
2015-10-05  6:16   ` Christian Gmeiner
2015-10-06 16:41     ` Peter Rosin
2015-10-05  8:45 ` Peter Rosin
2015-10-05  8:59   ` kbuild test robot
2015-10-05 15:00   ` Ludovic Desroches
2015-10-05 15:09     ` Peter Rosin
2015-10-12 15:13       ` Peter Rosin
2015-10-12 16:13         ` Cyrille Pitchen
2015-10-13 10:38           ` Peter Rosin
2015-10-13 12:57             ` Nicolas Ferre
2015-10-13 14:35               ` Peter Rosin
2015-10-13 13:26             ` ludovic.desroches at atmel.com
2015-10-05 15:28   ` Cyrille Pitchen
2015-10-05 15:54     ` Peter Rosin

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=560F0DB1.2020101@lysator.liu.se \
    --to=peda@lysator.liu.se \
    --cc=linux-arm-kernel@lists.infradead.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).