- 19 May, 2011 40 commits
-
-
Jonathan Cameron authored
Signed-off-by:
Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jonathan Cameron authored
Saves on a fair bit of code replication. Signed-off-by:
-
Jonathan Cameron authored
Signed-off-by:
-
Jonathan Cameron authored
Untested. Signed-off-by:
-
Jonathan Cameron authored
Untested. Also cleared out last_timestamp as it isn't used anywhere. Signed-off-by:
-
Jonathan Cameron authored
Untested. Signed-off-by:
-
Jonathan Cameron authored
I'm far from sure what the best way to handle this particular part is, so have (I think) done the absolute minimum to change it to the new interface. V2: Trivial constification of device name. Signed-off-by:
Michael Hennerich <michael.hennerich@analog.com> Signed-off-by:
-
Jonathan Cameron authored
Untested. This one is of a different form, so worth a closer look than the previous incredibly similar patches (which were based on the adis16400 that I have tested). Signed-off-by:
-
Jonathan Cameron authored
Untested. Signed-off-by:
-
Jonathan Cameron authored
Untested. Signed-off-by:
-
Jonathan Cameron authored
Untested. Signed-off-by:
-
Jonathan Cameron authored
Untested. Signed-off-by:
-
Jonathan Cameron authored
Untested. Signed-off-by:
-
Jonathan Cameron authored
Support is now provided by the unified adis16400 driver. Signed-off-by:
-
Jonathan Cameron authored
Next patch will remove original driver. Note this leaves holes in the scan indexing. Untested - except via adis16350... V3: rebase fixup. V2: move to single IIO_CHAN macro. Signed-off-by:
-
Jonathan Cameron authored
Signed-off-by:
-
Jonathan Cameron authored
Next patch will remove the current adis16350 driver. These should have been merged a long time ago, but there we are. V3: rebase fixup + add missing extend_name for supply on adis16350 V2: Move to single IIO_CHAN macro + use the new extend_name to make the naming of the temperature sensors contain x, y, z rather than messing with modifiers. This a very weird case and I don't want temperature to use axial modifiers. Signed-off-by:
-
Jonathan Cameron authored
V2: rebase fixup. Signed-off-by:
-
Jonathan Cameron authored
Untested Signed-off-by:
-
Jonathan Cameron authored
Untested V2: Fixed missing free of pollfunc->name pointed out by Michael Hennerich. Signed-off-by:
-
Jonathan Cameron authored
V3: Trivial rebase fixup. V2: Move to new single IIO_CHAN macro. Done without hardware. Fix from Michael Hennerich incorporated to use iio_ring_buffer_register_ex instead of iio_ring_buffer_register and thus actually make it work. Signed-off-by:
-
Jonathan Cameron authored
V2: Fixed missing free of pollfunc->name as pointed out by Michael Hennerich. Signed-off-by:
-
Jonathan Cameron authored
V2: Cleaned up handling of name string. Signed-off-by:
-
Jonathan Cameron authored
This case is extremely common, so let us only have the one copy. Signed-off-by:
-
Jonathan Cameron authored
Signed-off-by:
-
Jonathan Cameron authored
Trivial space before newline fix incorporated. Additional fixes related to handling of sign extension and shifted data. Signed-off-by:
-
Jonathan Cameron authored
V3: Get rid of separate interrupt pool. This is well handled by irq_get_descs and irq_free_descs. Two functions I simply wasn't aware of previously. Thus the allocation for a given trigger is now handled by core code rather than us reinventing the wheel. V2: Stop silly name duplication. Move pool handling to industrialio-trigger as that is the only user. Changed over to using irq_modify_status rather than the arm specific set_irq_flags as per Thomas Gleixner's suggestion. Signed-off-by: -
Jonathan Cameron authored
We have moved the timestamp acquisition into the bottom half. It may technically be less accurate but for this device I very much doubt anyone cares! Signed-off-by:
-
Jonathan Cameron authored
This requires all drivers using the channel registration code and events to change in one go. V3: remove unwanted irq enable from event handler. V2: rebase related fixes to move to new IIO_CHAN macro. All trivial. Signed-off-by:
-
Jonathan Cameron authored
Untested. Signed-off-by:
-
Jonathan Cameron authored
Signed-off-by:
-
Jonathan Cameron authored
Another driver that has two event lines, but pushes all events out the same chrdev. Probably needs a rethink. Signed-off-by:
-
Jonathan Cameron authored
This device actually has a pair of interrupts. The code basically ignores that and feeds them both to the same handlers. I'm not sure if that is the right thing to do, but the updated code should do exactly the same. Signed-off-by:
-
Jonathan Cameron authored
This driver needed some tender loving care. It still does. Signed-off-by:
-
Jonathan Cameron authored
Another one where the events are 'unusual'. Still left sorting that out for another day. Untested changes Signed-off-by:
-
Jonathan Cameron authored
a) This interface is going away b) There is no matching register call so looks like a cut and paste error Trivial sparse warning fix. Signed-off-by:
-
Jonathan Cameron authored
Another driver with some very 'non standard' magic event codes. Again I've left it be for now and merely moved it to the new api. There is no reason why the irq in this driver ever had to be a gpio. Scrap that test and clean out unecessary headers. Signed-off-by:
-
Jonathan Cameron authored
I'm not sure what the event is and am very much against the dodgy hack to give it a code. However for now, lets just stop it using the deprecated core handling so we can move on. Signed-off-by:
-
Jonathan Cameron authored
Nice simple one. Not sure we actually want devices outputting datardy signals like that, but I'll leave it for now. Cleaned up some unneeded functions whilst here. Signed-off-by:
-
Jonathan Cameron authored
Note this driver is still a long way from being abi compliant. What I have done here cleans up a few corners, but primarily gets it away from using the infrastructure that is going away. Untested Signed-off-by:
-
