- 17 Sep, 2012 8 commits
-
-
Lars-Peter Clausen authored
Some converters require an external signal to start the conversion. This patch adds support to the bfintmr trigger driver to generate such a signal. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Jonathan Cameron <jic23@kernel.org>
-
Lars-Peter Clausen authored
This patch hooks up the set_trigger_state callback for the blackfin timer trigger driver and only enables the timer when a trigger consumer requests it to be enabled. There really is no reason to keep the timer running and generate interrupts if nobody is listening to them. Signed-off-by:
-
Lars-Peter Clausen authored
If the timer frequency has not been configured yet get_gptimer_period() will return 0. Handle this case instead of blindly dividing by the returned value. Signed-off-by:
-
Lars-Peter Clausen authored
Use the iio_read_channel_processed function to read the sample value in the proper unit instead of using iio_read_channel_raw and iio_read_channel_scale and doing the unit conversion manually. Signed-off-by:
-
Lars-Peter Clausen authored
Add a function to read a processed value from a channel. The function will first attempt to read the IIO_CHAN_INFO_PROCESSED attribute. If that fails it will read the IIO_CHAN_INFO_RAW attribute and convert the result from a raw value to a processed value. The patch also introduces a function to convert raw value to a processed value and exports it, in case a user needs or wants to do the conversion by itself. Signed-off-by:
-
Lars-Peter Clausen authored
For the iio_read_channel_raw and iio_read_channel_scale the kerneldoc comment refers to an argument called "channel", while the argument is called "chan" in the function signature. This leads to the following warnings from kerneldoc: Warning(include/linux/iio/consumer.h:71): No description found for parameter 'chan' Warning(include/linux/iio/consumer.h:71): Excess function parameter 'channel' description in 'iio_read_channel_raw' Warning(include/linux/iio/consumer.h:109): No description found for parameter 'chan' Warning(include/linux/iio/consumer.h:109): Excess function parameter 'channel' description in 'iio_read_channel_scale' This patch fixes the warnings by naming them consistently. Signed-off-by:
-
Lars-Peter Clausen authored
This patch adds support for the AD5755, AD5755-1, AD5757, AD5735, AD5737 16 and 14 bit quad-channel DACs. The AD5757/AD5737 only have current outputs, but for the AD5755/AD5757 each of the outputs can be configured to either be a voltage or a current output. We only allow to configure this at device probe time since usually this needs to match the external circuitry and should not be changed on the fly. A few trivial formatting changes on merge. Signed-off-by:
-
Kim, Milo authored
The datasheet name is defined in the IIO driver. On the other hand, the adc_channel_label is configured in the platform side. If the datasheet name is not matched with any adc_channel_label, the iio_channel_get() should be returned as error for preventing invalid channel data access. This can be handled either way. (a) checking null data when using it : in the xxx_read_raw() or (b) error returns when the channel is requested : this patch The IIO consumer can't use the channel with invalid channel spec. Therefore case (b) is more reasonable. Signed-off-by:
Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by:
-
- 15 Sep, 2012 10 commits
-
-
Kim, Milo authored
Use kzalloc() rather than kmalloc() for initializing the iio_channel structure. This patch enables the iio_dev and iio_chan_spec are set to NULL. This may prevent the page fault problem because the pointer of iio_chan_spec is initialized as NULL. The iio_chan_spec is updated only in case that the IIO map has specific channel label. When the map has no ADC channel label, then the value of iio_chan_spec remains as invalid pointer. To prevent this problem, the pointer should be initialized as NULL. Signed-off-by:
-
Lars-Peter Clausen authored
Currently IIO uses a decimal fixed point representations for real type numbers. This patch introduces a new representation for rational type numbers. The number will be expressed by specifying a numerator and denominator. For converting a raw value to a processed value multiply it by the numerator and divide it by the denominator. The reasoning for introducing this new type is that for a lot of devices the scale can be represented easily by a fractional number, but it is not possible to represent it as fixed point number without rounding. E.g. for a simple DAC the scale is often the reference voltage divided by the number of possible values (Usually 2**n_bits - 1). Each driver currently implements the conversion of this fraction to a fixed point number on its own. Also when it comes to the in-kernel interface this allows to directly use the fractional factors to convert a raw value to a processed value. This should on one hand require less instructions and on the other hand increase the precision. Signed-off-by:
-
anish kumar authored
This commit- 314be14b renamed the _st_ functions to loose the bit that was meant for staging version but forgot to change the documentation which still have _st_ sprinkled in some of the places. Signed-off-by:
anish kumar <anish198519851985@gmail.com> Signed-off-by:
-
Lars-Peter Clausen authored
The ad7276/ad7277/ad7278 are similar to the ad7476/ad7477/ad7478 but have the same number of leading zeros as the ad7940. The ad7273/ad7274 have a extra pin for VREF where as for the ad7276/ad7277/ad7278 VREF is taken from VDD, but otherwise they are compatible to the ad7276/ad7277. Signed-off-by:
-
Lars-Peter Clausen authored
The AD7940 is a single channel 14 bit ADC similar to the ADCs already supported by the ad7476 driver, but it does have a different shift factor. Signed-off-by:
-
Lars-Peter Clausen authored
The ad7910/ad7920 are software compatible to the ad7467/ad7466. Signed-off-by:
-
Lars-Peter Clausen authored
The ad7476 driver is a driver for simple single channel ADCs. The driver does not export any experimental or custom ABI files nor do the static code check tools report any issues, so move the driver out of staging. Signed-off-by:
-
Lars-Peter Clausen authored
Signed-off-by:
-
Lars-Peter Clausen authored
After the recent cleanups the buffer support is just a single 23 line function. This does not really justify a file on its own, so move it to the main driver file. And with only one source file left the header file containing the device state struct becomes superflousious so move the content of the header file to the main driver source file as well. Signed-off-by:
-
Lars-Peter Clausen authored
Slightly rework the reference voltage handling for the ad7476 driver. Now the only way to specify a external reference voltage is to use the regulator API, previously it was possible to use either platform_data or the regulator API. The new way is more consistent with what other drivers do. Also do not ignore errors when requesting the regulator, since this will cope very poorly with e.g. deferred probing. Signed-off-by:
-
- 13 Sep, 2012 2 commits
-
-
Lars-Peter Clausen authored
The ad7476 driver has only support for 1 channel ADCs. So the upper limit for the buffer size is the size of one sample plus the size of the timestamp. Preallocate a buffer large enough to hold this to avoid having to allocate and free a new buffer for each sample being captured. Signed-off-by:
-
Lars-Peter Clausen authored
Some of the parts supported by this driver are software compatible. The difference between them is only in the operating voltage range. So we do not need extra chip info entries for them. Signed-off-by:
-
- 12 Sep, 2012 20 commits
-
-
Lars-Peter Clausen authored
The datasheet is a bit confusing about this. It says that a dataword has 4 leading zeros, but the first zero is already put on the bus when CS is pulled low and the second zero is put on the bus on the first leading edge of SCLK, so when the first bit is sampled on the first trailing edge it will sample what the datasheet refers to as the second leading zero. Subsequently we only see 3 leading zeros in the 16 bit dataword and the result we get is shifted to the left by one bit. Fix this by adjusting the channel shift by 1. Signed-off-by:
-
Jens Taprogge authored
Signed-off-by:
Jens Taprogge <jens.taprogge@taprogge.org> Signed-off-by:
Samuel Iglesias Gonsalvez <siglesias@igalia.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jens Taprogge authored
Signed-off-by:
-
Samuel Iglesias Gonsalvez authored
With the latest patches, the TODO file was outdated. Signed-off-by:
-
Samuel Iglesias Gonsalvez authored
The RX FIFO has a size of 3 characters. Check if when we are picking the oldest one, we have more to read. Signed-off-by:
-
Jens Taprogge authored
Use tty_dev->dev's drdata to associate struct ipocal_channel to the respective tty_struct. Signed-off-by:
-
Jens Taprogge authored
Signed-off-by:
-
Jens Taprogge authored
Signed-off-by:
-
Jens Taprogge authored
Make use of dev_set_drvdata() and dev_get_drvdata() to store and obtain a pointer to the ipoctal struct corresponding to a struct dev. Previously we relied on a private list of devices. Signed-off-by:
-
Jens Taprogge authored
Signed-off-by:
-
Jens Taprogge authored
Now, all the interrupt related functions are next to each other. Signed-off-by:
-
Jens Taprogge authored
Rename __tpci_request_irq() to tpci_enable_irq() and __tpci_free_irq() to tpci_disable_irq(). Change their second argument, move them above tpci200_interrupt(), and use tpci_disable_irq() in the latter Signed-off-by:
-
Jens Taprogge authored
Minor cleanup. No functional changes. Signed-off-by:
-
Jens Taprogge authored
Previously the return value from tpci200_interrupt was not quite correct if a slot had caused an interrupt but no handler was instellalled: IRQ_NONE was returned. However in this case we react to the interrupt by disabling the IPack device interrupt. Basically there are two cases the code now distinguishes: - The tpci200 has raised an interrupt. We handle it and return IRQ_HANDLED. - Our device did not raise an interrupt. We return IRQ_NONE. Signed-off-by:
-
Jens Taprogge authored
Some of the device registers are accessed from both interrupt and non-interrupt context. To ensure proper read-modify-write modification of these registers we can not use the "global" tpci200 mutex. Instead a spin-lock is used. Signed-off-by:
-
Jens Taprogge authored
In tpci200_request_irq as well as tpci200_free_irq we set and unset the pointer to struct slot_irq. This pointer is accessed in tpci200_interrupt. To ensure that the pointer is not freed after it has been fetched in tpci200_interrupt() it is now protected through RCU. Signed-off-by:
-
Jens Taprogge authored
ipoctal_write_tty and ipoctal_write are merged. Signed-off-by:
-
Jens Taprogge authored
Split the IRQ service routing in TX part and RX part. Signed-off-by:
-
Jens Taprogge authored
This way interrupt handling becomes independent of the channel number. Signed-off-by:
-
Jens Taprogge authored
Each tty's driver_data is now pointing to the channel it is talking to. struct ipoctal_channel contains all the information the callbacks require to do their work. Signed-off-by:
-
