All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Eggers <ceggers@arri.de>
To: David Laight <David.Laight@aculab.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] eeprom: at25: set minimum read/write access stride to 1
Date: Tue, 28 Jul 2020 12:30:13 +0200	[thread overview]
Message-ID: <2225645.EMaFvj1lSc@n95hx1g2> (raw)
In-Reply-To: <a65b01608fb34c5c8782b301c2e0cabc@AcuMS.aculab.com>

On Tuesday, 28 July 2020, 11:52:05 CEST, David Laight wrote:
> From: Christian Eggers
> 
> > Sent: 28 July 2020 10:30
> > 
> > SPI eeproms are addressed by byte.
> 
> They also support multi-byte writes - possibly with alignment
> restrictions.
> So forcing 4-byte writes (at aligned addresses) would typically
> speed up writes by a factor of 4 over byte writes.
> 
> So does this fix a problem?
> If so what.
I use the nvmem-cells property for getting the MAC-Address out of the eeprom 
(actually an FRAM in my case).

&spi {
    ....
    fram: fram@0 {
    ...
        mac_address_fec2: mac-address@126 {
            reg = <0x126 6>;
        };
    ...
    };
};

&fec2 {
    ...
    nvmem-cells = <&mac_address_fec2>;
    nvmem-cell-names = "mac-address";
    ...
};

As the address of the MAC is not aligned to 4 bytes,
reading the MAC from FRAM fails.

> So setting the 'stride' to 4 may be a compromise.
> Looking at some code that writes the EPCQ for Altera FPGA
> (which I think is just SPI) it does aligned 256 byte writes.
> The long writes (and the 4-bit physical interface) are needed
> to get the write times down to a sensible value.
I do not understand why a minimum read/write stride of 1 would affect 
performance. It is fully up to the user of the eeprom, how much data is read/
written at once. Of course it would not be economical only to read/write one 
byte at a time.

For reading data, there should be no difference whether the access is aligned 
to a particular address. For writing, data is usually organized in "write 
pages". For (I2C) eeproms I've used, the write page size is typically 32 
bytes. But his is handled separately by the "pagesize" property.

Is there any benefit at all if the stride size is set > 1?


> 
> 	David
> 
regards
Christian




  reply	other threads:[~2020-07-28 10:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-28  9:29 [PATCH] eeprom: at25: set minimum read/write access stride to 1 Christian Eggers
2020-07-28  9:52 ` David Laight
2020-07-28 10:30   ` Christian Eggers [this message]
2020-07-28 11:20     ` David Laight
2020-07-28 12:03       ` Christian Eggers

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=2225645.EMaFvj1lSc@n95hx1g2 \
    --to=ceggers@arri.de \
    --cc=David.Laight@aculab.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.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.