<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/iio/dac, branch linux-5.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2019-06-09T07:16:10Z</updated>
<entry>
<title>iio: dac: ds4422/ds4424 fix chip verification</title>
<updated>2019-06-09T07:16:10Z</updated>
<author>
<name>Ruslan Babayev</name>
<email>ruslan@babayev.com</email>
</author>
<published>2019-05-05T19:24:37Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=642ec93fe232028f859a090e8a1d8dc4e4367d39'/>
<id>urn:sha1:642ec93fe232028f859a090e8a1d8dc4e4367d39</id>
<content type='text'>
commit 60f2208699ec08ff9fdf1f97639a661a92a18f1c upstream.

The ds4424_get_value function takes channel number as it's 3rd
argument and translates it internally into I2C address using
DS4424_DAC_ADDR macro. The caller ds4424_verify_chip was passing an
already translated I2C address as its last argument.

Signed-off-by: Ruslan Babayev &lt;ruslan@babayev.com&gt;
Cc: xe-linux-external@cisco.com
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iio: dac: mcp4725: add missing powerdown bits in store eeprom</title>
<updated>2019-03-16T15:15:31Z</updated>
<author>
<name>Jean-Francois Dagenais</name>
<email>jeff.dagenais@gmail.com</email>
</author>
<published>2019-03-06T20:56:06Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=06003531502d06bc89d32528f6ec96bf978790f9'/>
<id>urn:sha1:06003531502d06bc89d32528f6ec96bf978790f9</id>
<content type='text'>
When issuing the write DAC register and write eeprom command, the two
powerdown bits (PD0 and PD1) are assumed by the chip to be present in
the bytes sent. Leaving them at 0 implies "powerdown disabled" which is
a different state that the current one. By adding the current state of
the powerdown in the i2c write, the chip will correctly power-on exactly
like as it is at the moment of store_eeprom call.

This is documented in MCP4725's datasheet, FIGURE 6-2: "Write Commands
for DAC Input Register and EEPROM" and MCP4726's datasheet, FIGURE 6-3:
"Write All Memory Command".

Signed-off-by: Jean-Francois Dagenais &lt;jeff.dagenais@gmail.com&gt;
Acked-by: Peter Meerwald-Stadler &lt;pmeerw@pmeerw.net&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
</entry>
<entry>
<title>iio:dac:ti-dac7612: Add driver for Texas Instruments DAC7612</title>
<updated>2019-02-09T18:46:02Z</updated>
<author>
<name>Ricardo Ribalda Delgado</name>
<email>ricardo@ribalda.com</email>
</author>
<published>2019-02-04T12:48:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=977724d20584bd268b0a84bc2fbfffbc8681b595'/>
<id>urn:sha1:977724d20584bd268b0a84bc2fbfffbc8681b595</id>
<content type='text'>
It is a driver for Texas Instruments Dual, 12-Bit Serial Input
Digital-to-Analog Converter.

Datasheet of this chip:
http://www.ti.com/lit/ds/sbas106/sbas106.pdf

Signed-off-by: Ricardo Ribalda Delgado &lt;ricardo@ribalda.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
</entry>
<entry>
<title>drivers: iio: dac: Fix wrong license for ADI drivers</title>
<updated>2019-02-09T18:46:01Z</updated>
<author>
<name>Stefan Popa</name>
<email>stefan.popa@analog.com</email>
</author>
<published>2019-02-04T09:19:35Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=cbd5dd387afab8511e055d0487e1ef747e7f72b5'/>
<id>urn:sha1:cbd5dd387afab8511e055d0487e1ef747e7f72b5</id>
<content type='text'>
Analog Devices drivers are typically GPL v2 only. This patch fixes the
inconsistencies between the module license and SPDX.

Signed-off-by: Stefan Popa &lt;stefan.popa@analog.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
</entry>
<entry>
<title>iio: dac: ad5686: Add support for AD5674R/AD5679R</title>
<updated>2019-01-12T18:58:21Z</updated>
<author>
<name>Mircea Caprioru</name>
<email>mircea.caprioru@analog.com</email>
</author>
<published>2019-01-09T09:14:16Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=192778fb969c2b9bc33d559b9c7aecdd1498c1ba'/>
<id>urn:sha1:192778fb969c2b9bc33d559b9c7aecdd1498c1ba</id>
<content type='text'>
The AD5674R/AD5679R are low power, 16-channel, 12-/16-bit buffered voltage
output digital-to-analog converters (DACs). They include a 2.5 V internal
reference (enabled by default).

These devices are very similar to AD5684R/AD5686R, except that they have 16
channels.

Signed-off-by: Mircea Caprioru &lt;mircea.caprioru@analog.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
</entry>
<entry>
<title>iio: dac: ad5686: fix bit shift read register</title>
<updated>2018-12-08T15:45:09Z</updated>
<author>
<name>Mircea Caprioru</name>
<email>mircea.caprioru@analog.com</email>
</author>
<published>2018-12-06T13:53:15Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0e76df5c978338f3051e5126fc0c4245c57a307a'/>
<id>urn:sha1:0e76df5c978338f3051e5126fc0c4245c57a307a</id>
<content type='text'>
This patch solves the register readback issue with the bit shift. When the
dac resolution was lower than the register size (ex. 12 bits out of 16
bits) the readback value was not shifted with the difference in bits and
the value was higher. Also a mask is applied on the read value in order to
get the value relative to the actual bit size.

Fixes: 0357e488b8 ("iio:dac:ad5686: Refactor the driver")
Signed-off-by: Mircea Caprioru &lt;mircea.caprioru@analog.com&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
</entry>
<entry>
<title>iio:dac:ad5686: Add AD5310R support</title>
<updated>2018-12-08T15:35:55Z</updated>
<author>
<name>Stefan Popa</name>
<email>stefan.popa@analog.com</email>
</author>
<published>2018-12-06T13:38:30Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=12d323cf6dd558b442fa3f03af3c7703617eed81'/>
<id>urn:sha1:12d323cf6dd558b442fa3f03af3c7703617eed81</id>
<content type='text'>
The AD5310R is a single channel DAC with 10-bit precision, which is
part of the same family as AD5311R, except that it uses the spi interface
instead of i2c. The device has a built-in 2.5V reference which is enabled
by default.

Another important difference is that the SPI write command operation is
16 bits long. The first four bits represent the command, while the
remaining 12 bits are for data. In the control reg, DB9 and DB10 are used
for power-down modes, while DB8 is the REF bit. In order to accommodate
this change, a new regmap type was defined and checked accordingly.

Because AD5310R does not have a readback register, the read_raw operation
will return "Operation is not supported".

Datasheet:
Link: http://www.analog.com/media/en/technical-documentation/data-sheets/AD5310R_5311R.pdf

Signed-off-by: Stefan Popa &lt;stefan.popa@analog.com&gt;
Signed-off-by: Mircea Caprioru &lt;mircea.caprioru@analog.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
</entry>
<entry>
<title>iio:dac:ti-dac7311 Add driver for Texas Instrument DAC7311</title>
<updated>2018-11-11T15:29:44Z</updated>
<author>
<name>Charles-Antoine Couret</name>
<email>charles-antoine.couret@essensium.com</email>
</author>
<published>2018-10-28T16:24:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7a02ef7907d8a2b4b699d815b9221c6febee0fac'/>
<id>urn:sha1:7a02ef7907d8a2b4b699d815b9221c6febee0fac</id>
<content type='text'>
It is a driver for Texas Instruments 8/10/12-bit 1-channel
compatible with DAC6311 and DAC5311 chips.

Datasheet of this chip:
http://www.ti.com/lit/ds/symlink/dac7311.pdf

Signed-off-by: Charles-Antoine Couret &lt;charles-antoine.couret@essensium.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
</entry>
<entry>
<title>iio: dpot-dac: mark expected switch fall-through with text GCC expects.</title>
<updated>2018-10-14T17:01:00Z</updated>
<author>
<name>Gustavo A. R. Silva</name>
<email>gustavo@embeddedor.com</email>
</author>
<published>2018-10-08T17:35:28Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c65a0d84ee9cae48ce4b40346e238415e47904fa'/>
<id>urn:sha1:c65a0d84ee9cae48ce4b40346e238415e47904fa</id>
<content type='text'>
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Notice that in this particular case, I replaced "...and fall through."
with the specific string "fall through", which is what GCC is
expecting to find thus supressing this false positive.

As Peter has observed this breaks the nice English flow, which is
less than ideal, but short of teaching GCC to read English, there
isn't a lot that we can do about it.

Addresses-Coverity-ID: 1462408 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
</entry>
<entry>
<title>iio: ad5064: Fix regulator handling</title>
<updated>2018-09-29T12:28:47Z</updated>
<author>
<name>Lars-Peter Clausen</name>
<email>lars@metafoo.de</email>
</author>
<published>2018-09-28T09:23:40Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8911a43bc198877fad9f4b0246a866b26bb547ab'/>
<id>urn:sha1:8911a43bc198877fad9f4b0246a866b26bb547ab</id>
<content type='text'>
The correct way to handle errors returned by regualtor_get() and friends is
to propagate the error since that means that an regulator was specified,
but something went wrong when requesting it.

For handling optional regulators, e.g. when the device has an internal
vref, regulator_get_optional() should be used to avoid getting the dummy
regulator that the regulator core otherwise provides.

Signed-off-by: Lars-Peter Clausen &lt;lars@metafoo.de&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
</entry>
</feed>
