summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@g5.osdl.org>2006-06-23 02:08:34 +0400
committerLinus Torvalds <torvalds@g5.osdl.org>2006-06-23 02:08:34 +0400
commiteaa8568901b3164197ce727c4c9b4067383e526c (patch)
tree6dc48f016cfff6e1e5ce9278be819e1b651027b0 /Documentation
parent6c763eb9ead86c612492b59287b36c0dcf7d09b1 (diff)
parentc6976a4eb3c9ead165de950899b45db0840b8e30 (diff)
downloadlinux-eaa8568901b3164197ce727c4c9b4067383e526c.tar.xz
Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/w1-2.6
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/w1-2.6: [PATCH] w1: warning fix [PATCH] w1: clean up W1_CON dependency. [PATCH] drivers/w1/w1.c: fix a compile error [PATCH] W1: fix dependencies of W1_SLAVE_DS2433_CRC [PATCH] W1: possible cleanups [PATCH] W1: cleanups [PATCH] w1 exports [PATCH] w1: Use mutexes instead of semaphores. [PATCH] w1: Make w1 connector notifications depend on connector. [PATCH] w1: netlink: Mark netlink group 1 as unused. [PATCH] w1: Move w1-connector definitions into linux/include/connector.h [PATCH] w1: Userspace communication protocol over connector. [PATCH] w1: Replace dscore and ds_w1_bridge with ds2490 driver. [PATCH] w1: Added default generic read/write operations.
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/w1/masters/ds249018
-rw-r--r--Documentation/w1/w1.generic18
-rw-r--r--Documentation/w1/w1.netlink98
3 files changed, 131 insertions, 3 deletions
diff --git a/Documentation/w1/masters/ds2490 b/Documentation/w1/masters/ds2490
new file mode 100644
index 000000000000..44a4918bd7f2
--- /dev/null
+++ b/Documentation/w1/masters/ds2490
@@ -0,0 +1,18 @@
+Kernel driver ds2490
+====================
+
+Supported chips:
+ * Maxim DS2490 based
+
+Author: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
+
+
+Description
+-----------
+
+The Maixm/Dallas Semiconductor DS2490 is a chip
+which allows to build USB <-> W1 bridges.
+
+DS9490(R) is a USB <-> W1 bus master device
+which has 0x81 family ID integrated chip and DS2490
+low-level operational chip.
diff --git a/Documentation/w1/w1.generic b/Documentation/w1/w1.generic
index f937fbe1cacb..4c6509dd4789 100644
--- a/Documentation/w1/w1.generic
+++ b/Documentation/w1/w1.generic
@@ -27,8 +27,19 @@ When a w1 master driver registers with the w1 subsystem, the following occurs:
When a device is found on the bus, w1 core checks if driver for it's family is
loaded. If so, the family driver is attached to the slave.
-If there is no driver for the family, a simple sysfs entry is created
-for the slave device.
+If there is no driver for the family, default one is assigned, which allows to perform
+almost any kind of operations. Each logical operation is a transaction
+in nature, which can contain several (two or one) low-level operations.
+Let's see how one can read EEPROM context:
+1. one must write control buffer, i.e. buffer containing command byte
+and two byte address. At this step bus is reset and appropriate device
+is selected using either W1_SKIP_ROM or W1_MATCH_ROM command.
+Then provided control buffer is being written to the wire.
+2. reading. This will issue reading eeprom response.
+
+It is possible that between 1. and 2. w1 master thread will reset bus for searching
+and slave device will be even removed, but in this case 0xff will
+be read, since no device was selected.
W1 device families
@@ -89,4 +100,5 @@ driver - (standard) symlink to the w1 driver
name - the device name, usually the same as the directory name
w1_slave - (optional) a binary file whose meaning depends on the
family driver
-
+rw - (optional) created for slave devices which do not have
+ appropriate family driver. Allows to read/write binary data.
diff --git a/Documentation/w1/w1.netlink b/Documentation/w1/w1.netlink
new file mode 100644
index 000000000000..3640c7c87d45
--- /dev/null
+++ b/Documentation/w1/w1.netlink
@@ -0,0 +1,98 @@
+Userspace communication protocol over connector [1].
+
+
+Message types.
+=============
+
+There are three types of messages between w1 core and userspace:
+1. Events. They are generated each time new master or slave device found
+ either due to automatic or requested search.
+2. Userspace commands. Includes read/write and search/alarm search comamnds.
+3. Replies to userspace commands.
+
+
+Protocol.
+========
+
+[struct cn_msg] - connector header. It's length field is equal to size of the attached data.
+[struct w1_netlink_msg] - w1 netlink header.
+ __u8 type - message type.
+ W1_SLAVE_ADD/W1_SLAVE_REMOVE - slave add/remove events.
+ W1_MASTER_ADD/W1_MASTER_REMOVE - master add/remove events.
+ W1_MASTER_CMD - userspace command for bus master device (search/alarm search).
+ W1_SLAVE_CMD - userspace command for slave device (read/write/ search/alarm search
+ for bus master device where given slave device found).
+ __u8 res - reserved
+ __u16 len - size of attached to this header data.
+ union {
+ __u8 id; - slave unique device id
+ struct w1_mst {
+ __u32 id; - master's id.
+ __u32 res; - reserved
+ } mst;
+ } id;
+
+[strucrt w1_netlink_cmd] - command for gived master or slave device.
+ __u8 cmd - command opcode.
+ W1_CMD_READ - read command.
+ W1_CMD_WRITE - write command.
+ W1_CMD_SEARCH - search command.
+ W1_CMD_ALARM_SEARCH - alarm search command.
+ __u8 res - reserved
+ __u16 len - length of data for this command.
+ For read command data must be allocated like for write command.
+ __u8 data[0] - data for this command.
+
+
+Each connector message can include one or more w1_netlink_msg with zero of more attached w1_netlink_cmd messages.
+
+For event messages there are no w1_netlink_cmd embedded structures, only connector header
+and w1_netlink_msg strucutre with "len" field being zero and filled type (one of event types)
+and id - either 8 bytes of slave unique id in host order, or master's id, which is assigned
+to bus master device when it is added to w1 core.
+
+Currently replies to userspace commands are only generated for read command request.
+One reply is generated exactly for one w1_netlink_cmd read request.
+Replies are not combined when sent - i.e. typical reply messages looks like the following:
+[cn_msg][w1_netlink_msg][w1_netlink_cmd]
+cn_msg.len = sizeof(struct w1_netlink_msg) + sizeof(struct w1_netlink_cmd) + cmd->len;
+w1_netlink_msg.len = sizeof(struct w1_netlink_cmd) + cmd->len;
+w1_netlink_cmd.len = cmd->len;
+
+
+Operation steps in w1 core when new command is received.
+=======================================================
+
+When new message (w1_netlink_msg) is received w1 core detects if it is master of slave request,
+according to w1_netlink_msg.type field.
+Then master or slave device is searched for.
+When found, master device (requested or those one on where slave device is found) is locked.
+If slave command is requested, then reset/select procedure is started to select given device.
+
+Then all requested in w1_netlink_msg operations are performed one by one.
+If command requires reply (like read command) it is sent on command completion.
+
+When all commands (w1_netlink_cmd) are processed muster device is unlocked
+and next w1_netlink_msg header processing started.
+
+
+Connector [1] specific documentation.
+====================================
+
+Each connector message includes two u32 fields as "address".
+w1 uses CN_W1_IDX and CN_W1_VAL defined in include/linux/connector.h header.
+Each message also includes sequence and acknowledge numbers.
+Sequence number for event messages is appropriate bus master sequence number increased with
+each event message sent "through" this master.
+Sequence number for userspace requests is set by userspace application.
+Sequence number for reply is the same as was in request, and
+acknowledge number is set to seq+1.
+
+
+Additional documantion, source code examples.
+============================================
+
+1. Documentation/connector
+2. http://tservice.net.ru/~s0mbre/archive/w1
+This archive includes userspace application w1d.c which
+uses read/write/search commands for all master/slave devices found on the bus.