path: root/Documentation/w1/masters
diff options
Diffstat (limited to 'Documentation/w1/masters')
6 files changed, 0 insertions, 202 deletions
diff --git a/Documentation/w1/masters/00-INDEX b/Documentation/w1/masters/00-INDEX
deleted file mode 100644
index d63fa024ac0..00000000000
--- a/Documentation/w1/masters/00-INDEX
+++ /dev/null
@@ -1,10 +0,0 @@
- - This file
- - The Maxim/Dallas Semiconductor DS2482 provides 1-wire busses.
- - The Maxim/Dallas Semiconductor DS2490 builds USB <-> W1 bridges.
- - W1 master controller driver found on Freescale MX2/MX3 SoCs
- - GPIO 1-wire bus master driver.
diff --git a/Documentation/w1/masters/ds2482 b/Documentation/w1/masters/ds2482
deleted file mode 100644
index 56f8edace6a..00000000000
--- a/Documentation/w1/masters/ds2482
+++ /dev/null
@@ -1,31 +0,0 @@
-Kernel driver ds2482
-Supported chips:
- * Maxim DS2482-100, Maxim DS2482-800
- Prefix: 'ds2482'
- Addresses scanned: None
- Datasheets:
-Author: Ben Gardner <>
-The Maxim/Dallas Semiconductor DS2482 is a I2C device that provides
-one (DS2482-100) or eight (DS2482-800) 1-wire busses.
-General Remarks
-Valid addresses are 0x18, 0x19, 0x1a, and 0x1b.
-However, the device cannot be detected without writing to the i2c bus, so no
-detection is done. You should instantiate the device explicitly.
-$ modprobe ds2482
-$ echo ds2482 0x18 > /sys/bus/i2c/devices/i2c-0/new_device
diff --git a/Documentation/w1/masters/ds2490 b/Documentation/w1/masters/ds2490
deleted file mode 100644
index 28176def3d6..00000000000
--- a/Documentation/w1/masters/ds2490
+++ /dev/null
@@ -1,70 +0,0 @@
-Kernel driver ds2490
-Supported chips:
- * Maxim DS2490 based
-Author: Evgeniy Polyakov <>
-The Maxim/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.
-Notes and limitations.
-- The weak pullup current is a minimum of 0.9mA and maximum of 6.0mA.
-- The 5V strong pullup is supported with a minimum of 5.9mA and a
- maximum of 30.4 mA. (From DS2490.pdf)
-- While the ds2490 supports a hardware search the code doesn't take
- advantage of it (in tested case it only returned first device).
-- The hardware will detect when devices are attached to the bus on the
- next bus (reset?) operation, however only a message is printed as
- the core w1 code doesn't make use of the information. Connecting
- one device tends to give multiple new device notifications.
-- The number of USB bus transactions could be reduced if w1_reset_send
- was added to the API. The name is just a suggestion. It would take
- a write buffer and a read buffer (along with sizes) as arguments.
- The ds2490 block I/O command supports reset, write buffer, read
- buffer, and strong pullup all in one command, instead of the current
- 1 reset bus, 2 write the match rom command and slave rom id, 3 block
- write and read data. The write buffer needs to have the match rom
- command and slave rom id prepended to the front of the requested
- write buffer, both of which are known to the driver.
-- The hardware supports normal, flexible, and overdrive bus
- communication speeds, but only the normal is supported.
-- The registered w1_bus_master functions don't define error
- conditions. If a bus search is in progress and the ds2490 is
- removed it can produce a good amount of error output before the bus
- search finishes.
-- The hardware supports detecting some error conditions, such as
- short, alarming presence on reset, and no presence on reset, but the
- driver doesn't query those values.
-- The ds2490 specification doesn't cover short bulk in reads in
- detail, but my observation is if fewer bytes are requested than are
- available, the bulk read will return an error and the hardware will
- clear the entire bulk in buffer. It would be possible to read the
- maximum buffer size to not run into this error condition, only extra
- bytes in the buffer is a logic error in the driver. The code should
- should match reads and writes as well as data sizes. Reads and
- writes are serialized and the status verifies that the chip is idle
- (and data is available) before the read is executed, so it should
- not happen.
-- Running x86_64 2.6.24 UHCI under qemu 0.9.0 under x86_64 2.6.22-rc6
- with a OHCI controller, ds2490 running in the guest would operate
- normally the first time the module was loaded after qemu attached
- the ds2490 hardware, but if the module was unloaded, then reloaded
- most of the time one of the bulk out or in, and usually the bulk in
- would fail. qemu sets a 50ms timeout and the bulk in would timeout
- even when the status shows data available. A bulk out write would
- show a successful completion, but the ds2490 status register would
- show 0 bytes written. Detaching qemu from the ds2490 hardware and
- reattaching would clear the problem. usbmon output in the guest and
- host did not explain the problem. My guess is a bug in either qemu
- or the host OS and more likely the host OS.
--- 03-06-2008 David Fries <>
diff --git a/Documentation/w1/masters/mxc-w1 b/Documentation/w1/masters/mxc-w1
deleted file mode 100644
index 38be1ad6553..00000000000
--- a/Documentation/w1/masters/mxc-w1
+++ /dev/null
@@ -1,12 +0,0 @@
-Kernel driver mxc_w1
-Supported chips:
- * Freescale MX27, MX31 and probably other i.MX SoCs
- Datasheets:
-Author: Originally based on Freescale code, prepared for mainline by
- Sascha Hauer <>
diff --git a/Documentation/w1/masters/omap-hdq b/Documentation/w1/masters/omap-hdq
deleted file mode 100644
index 884dc284b21..00000000000
--- a/Documentation/w1/masters/omap-hdq
+++ /dev/null
@@ -1,46 +0,0 @@
-Kernel driver for omap HDQ/1-wire module.
-Supported chips:
- HDQ/1-wire controller on the TI OMAP 2430/3430 platforms.
-A useful link about HDQ basics:
-The HDQ/1-Wire module of TI OMAP2430/3430 platforms implement the hardware
-protocol of the master functions of the Benchmark HDQ and the Dallas
-Semiconductor 1-Wire protocols. These protocols use a single wire for
-communication between the master (HDQ/1-Wire controller) and the slave
-(HDQ/1-Wire external compliant device).
-A typical application of the HDQ/1-Wire module is the communication with battery
-monitor (gas gauge) integrated circuits.
-The controller supports operation in both HDQ and 1-wire mode. The essential
-difference between the HDQ and 1-wire mode is how the slave device responds to
-initialization pulse.In HDQ mode, the firmware does not require the host to
-create an initialization pulse to the slave.However, the slave can be reset by
-using an initialization pulse (also referred to as a break pulse).The slave
-does not respond with a presence pulse as it does in the 1-Wire protocol.
-The driver (drivers/w1/masters/omap_hdq.c) supports the HDQ mode of the
-controller. In this mode, as we can not read the ID which obeys the W1
-spec(family:id:crc), a module parameter can be passed to the driver which will
-be used to calculate the CRC and pass back an appropriate slave ID to the W1
-By default the master driver and the BQ slave i/f
-driver(drivers/w1/slaves/w1_bq27000.c) sets the ID to 1.
-Please note to load both the modules with a different ID if required, but note
-that the ID used should be same for both master and slave driver loading.
-insmod omap_hdq.ko W1_ID=2
-inamod w1_bq27000.ko F_ID=2
diff --git a/Documentation/w1/masters/w1-gpio b/Documentation/w1/masters/w1-gpio
deleted file mode 100644
index af5d3b4aa85..00000000000
--- a/Documentation/w1/masters/w1-gpio
+++ /dev/null
@@ -1,33 +0,0 @@
-Kernel driver w1-gpio
-Author: Ville Syrjala <>
-GPIO 1-wire bus master driver. The driver uses the GPIO API to control the
-wire and the GPIO pin can be specified using platform data.
-Example (mach-at91)
-#include <linux/w1-gpio.h>
-static struct w1_gpio_platform_data foo_w1_gpio_pdata = {
- .pin = AT91_PIN_PB20,
- .is_open_drain = 1,
-static struct platform_device foo_w1_device = {
- .name = "w1-gpio",
- .id = -1,
- .dev.platform_data = &foo_w1_gpio_pdata,
- at91_set_GPIO_periph(, 1);
- at91_set_multi_drive(, 1);
- platform_device_register(&foo_w1_device);