CVS log for src/sys/dev/i2c/spdmem_i2c.c

Up to [cvs.NetBSD.org] / src / sys / dev / i2c

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

These modules need to depend on iic, not just on i2cexec.  (They will
still recursively get i2cexec since the iic depends on it.)

Partial fix for kern/56772

Pull up the following revisions, requested by msaitoh in ticket #1717

	sys/dev/i2c/spdmem_i2c.c		1.23-1.25 via patch

- Carefully access to the I2C bus in the match function.
- Improve bank reset code for DDR4.

Pull up the following revisions, requested by msaitoh in ticket #1388:

	sys/dev/i2c/spdmem_i2c.c		1.23-1.25 via patch

- Carefully access to the I2C bus in the match function.
- Improve bank reset code for DDR4.

Check the return value correctly. Pointed out by pgoyette@.

Carefully access to the I2C bus in the match function.

Access byte2...

Port over the changes from thorpej-i2c-spi-conf to thorpej-i2c-spi-conf2,
which is based on a newer HEAD revision.

Sync w/ HEAD.

iic_acquire_bus can fail

Tweak previous to deal better with "device tree node describes empty
DIMM slot" problem.

Go back to probing in the direct config case, and return a high confidence
match value if the SPD probe succeeds.  This ensures that we beat a generic
i2c serial eeprom driver if the contents looks like they contain SPD data.

Check for errors from iic_acquire_bus().

The last change had an unfortunate side-effect on empty DIMM slots, so
roll that back.  Instead, if we used direct config, then probe for the
module in the attach routine and report if the module is not present,
rather than assuming that it is.

Encapsulate the direct config logic for SPD into one place for clarity.

SPD stands for "Serial Presence Detect".  This implies that
if we're using direct configuration that we should treat
that as a *hint*... it's entirely possible that a device
tree lists locations where SPD memory can be found, not
necessarily where memory is known to be present.

Accordingly, if we get a direct configuration match based
on compatible data or device name, we still check to see
if the device is there.

Sync with HEAD.

Use DEVICE_COMPAT_EOL.

Since we're using designated initialisers for compat data, we should
use a completely empty initializer for the sentinel.

Use designated initializers and a consistent termination style in
compat_data[].

Merge changes from current as of 20200406

No need to use I2C_F_POLL here.

Pull up following revision(s) (requested by msaitoh in ticket #1442):

	sys/dev/i2c/spdmem_i2c.c: revision 1.14

Use 1-byte data-buffers when writing to the "control" device for the
SPD ROMs (we do this for page-selection).  The imcsmb doesn't support
zero-byte transfers.

With this, I'm able to get the data for all 8 of my DIMMs (on two
different imcsmb busses) using the spdmem(4) driver.  And the data
decodes correctly using the decode-dimms utility (from the linux
i2ctools).

Sync with HEAD

Sync with head

match "i2c-at34c02", found in various sparc64 boxes

Ssync with HEAD

match spdmem_i2c on "atmel,spd" compatible string

Sync with HEAD

More cleanup to i2c autoconfiguration:

- Get all of the drivers onto the new match quality constants.
- Introduce a new helper function, iic_use_direct_match(), that has
  all of the logic for direct-config matching.  If it returns true,
  the driver returns the match result (which may be 0).  If it returns
  false, the driver does indirect-config matching.
- iic_compat_match() now returns a weighted match quality; matches to
  lower-indexed "compatible" device property are more-specific matches,
  and return a better match quality accordingly.

Use 1-byte data-buffers when writing to the "control" device for the
SPD ROMs (we do this for page-selection).  The imcsmb doesn't support
zero-byte transfers.

With this, I'm able to get the data for all 8 of my DIMMs (on two
different imcsmb busses) using the spdmem(4) driver.  And the data
decodes correctly using the decode-dimms utility (from the linux
i2ctools).

update from HEAD

Sync with HEAD

 Add code to select page "0" for DDR4 and newer SPD ROM. If the value read
is not suitable as SPD ROM, try to select page 0 and try again. The passed
arguments of iic_exec(SPDCTL_SPA) might not be correct and/or our API of
iic_exec() should be improved. See the comment for the detail.

Use this change until we find a better (or correct?) way.

Sync with HEAD

Check whether iic_exec is failed or not.
- This change fixes a bug that a device that the checksum is really 0 fails
  attaching.
- Reduce the number of access to one if a device doesn't exist. Without this
  change and iic(4) does polling, it'll wait long time.

Sync with HEAD (as of 26th Dec)

Handle reading of 4kbit EEPROMs in SPD devices. This is needed for DDR4 DIMMs.

Sync with HEAD

Pull up following revision(s) (requested by jmcneill in ticket #634):
	distrib/sets/lists/modules/md.amd64: revision 1.51
	distrib/sets/lists/modules/md.evbppc.powerpc: revision 1.5
	distrib/sets/lists/modules/md.i386: revision 1.55
	distrib/sets/lists/modules/mi: revision 1.71
	sys/dev/i2c/au8522.c: revision 1.7
	sys/dev/i2c/cx24227.c: revision 1.7
	sys/dev/i2c/dbcool.c: revision 1.42
	sys/dev/i2c/hytp14.c: revision 1.3
	sys/dev/i2c/i2c_exec.c: revision 1.10
	sys/dev/i2c/lg3303.c: revision 1.9
	sys/dev/i2c/mt2131.c: revision 1.5
	sys/dev/i2c/nxt2k.c: revision 1.4
	sys/dev/i2c/sdtemp.c: revision 1.24
	sys/dev/i2c/spdmem_i2c.c: revision 1.10
	sys/dev/i2c/tvpll.c: revision 1.6
	sys/dev/i2c/xc3028.c: revision 1.7
	sys/dev/i2c/xc5k.c: revision 1.6
	sys/dev/i2c/zl10353.c: revision 1.4
	sys/modules/Makefile: revision 1.143
	sys/modules/i2cexec/Makefile: revision 1.1
i2c devices don't actually have a dependency on "iic" (the bus driver)
but on "i2cexec". Create an i2cexec module (i2c_exec.c) to mirror the
dependencies in files.i2c and switch device drivers to depend on "i2cexec"
module instead.
A kernel with a USB stack and no I2C controller / bus attachment would spit
out a bunch of "WARNING: module error: can't find builtin dependency `iic'"
messages at boot. This change solves that problem.

i2c devices don't actually have a dependency on "iic" (the bus driver)
but on "i2cexec". Create an i2cexec module (i2c_exec.c) to mirror the
dependencies in files.i2c and switch device drivers to depend on "i2cexec"
module instead.

A kernel with a USB stack and no I2C controller / bus attachment would spit
out a bunch of "WARNING: module error: can't find builtin dependency `iic'"
messages at boot. This change solves that problem.

Rebase to HEAD as of a few days ago.

Rebase.

sync with head.

for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.

this commit was splitted into small chunks to avoid
a limitation of cvs.  ("Protocol error: too many arguments")

sync with head

Remove extraneous sysctl setup calls now done as part of regular attach.

sync with head

Allow i2c addr wildcard matching. Use with care!

Call iic_exec() with I2C_F_POLL.  Don't sleep in probe/attach time.

sync with head

Initialize the sysctl(9) stuff before configuring the spd(4) devices.

Otherwise, the devices do not create their own sysctl nodes!

sync to latest -current.

Update handling of sysctl stuff when built as modules

sync with head

merge to -current.

Add "dimm" found on Sun US-IIe based machines (eg. Netra X1, Blade 100).

now that iic is a module, add "iic" dependency to iic drivers

Modularize the spdmem(4) driver

sync with head.

sync with head

Sync with HEAD.

file spdmem_i2c.c was added on branch yamt-nfs-mp on 2010-08-11 22:53:22 +0000

file spdmem_i2c.c was added on branch rmind-uvmplock on 2010-05-30 05:17:20 +0000

file spdmem_i2c.c was added on branch uebayasi-xip on 2010-04-30 14:43:12 +0000

Split spdmem driver into a bus attachment and a common back-end
probe and ROM decode, to follow similar changes made in OpenBSD:

        http://article.gmane.org/gmane.os.openbsd.cvs/94948
        http://article.gmane.org/gmane.os.openbsd.cvs/94956

There exists at least one alternative attachment (for SGI IP35
systems; see http://article.gmane.org/gmane.os.openbsd.cvs/94947),
and there could be more in the future.

Thanks to Christoph Egger for pointing out the OpenBSD activity.