Add ADC driver for Atmel G20, G45 and X5 boards

The AT91 SoCs often embeds an ADC. This patch adds the needed platform data to specify the informations required by the driver to work properly.

For now, we only need the reference voltage and which channels are available on the board.

Signed-off-by Maxime Ripard<[email protected]>

---
  include/linux/platform_data/at91_adc.h |   61 ++++++++++++++++++++++++++++++++
  1 file changed, 61 insertions(+)

create mode 100644 include/linux/platform_data/at91_adc.h

include/linux/platform_data/at91_adc.h new file +20 -0

new file mode 100644
index 0000000..f9e2f00
@@ -0,0 +1,61 @@
+/*
+ * Copyright (C) 2011 Free Electrons
+ *
+ * Licensed under the GPLv2 or later.
+ */
+
+#ifndef _AT91_ADC_H_
+#define _AT91_ADC_H_
+
+/**
+ * struct at91_adc_reg_desc - Various informations relative to registers
+ * @channel_base:	Base address for the channel data registers
+ * @drdy_mask:		Mask of the DRDY field in the relevant registers
+			(Interruptions registers mostly)
+ * @status_register:	Address of the Interrupt Status Register
+ * @trigger_register:	Address of the Trigger setup register
+ */
+struct at91_adc_reg_desc {
+	u8	channel_base;
+	u32	drdy_mask;

include/linux/platform_data/at91_adc.h new file +31 -0

+ */
+struct at91_adc_trigger {
+	const char	*name;
+	u8		value;
+	bool		is_external;
+};
+
+/**
+ * struct at91_adc_data - platform data for ADC driver
+ * @channels_used:		channels in use on the board as a bitmask
+ * @num_channels:		global number of channels available on the board
+ * @registers:			Registers definition on the board
+ * @startup_time:		startup time of the ADC in microseconds
+ * @trigger_list:		Triggers available in the ADC
+ * @trigger_number:		Number of triggers available in the ADC
+ * @use_external_triggers:	does the board has external triggers availables
+ * @vref:			Reference voltage for the ADC in millivolts
+ */
+struct at91_adc_data {
+	unsigned long			channels_used;
+	u8				num_channels;
+	struct at91_adc_reg_desc	*registers;
+	u8				startup_time;
+	struct at91_adc_trigger		*trigger_list;
+	u8				trigger_number;
+	bool				use_external_triggers;
+	u16				vref;
+};
+
+extern void __init at91_add_device_adc(struct at91_adc_data *data);
+#endif

Hi all,

Here is another version of the patches to bring ADC driver to Atmel boards. Since last version, here is what changed:
* Rebased on top of staging-next to move out of staging. Had to change to IIO kfifo buffer along the way.
* Reworked the DT bindings according to Jean-Christophe reviews
* Made various fixes according to reviews
* Support for X5 boards

Thanks,
Maxime

Jonathan, Arnd, Olof,

As explained by Maxime, this patch series is adding the Atmel ADC driver to the out-of-staging iio subsystem. It relies on patches that are in staging-next.
On the other hand, I really wouldn't like to split the series between iio and arm-soc...
My question is: would it be possible to take this series in Jonathan iio/staging-next git tree for inclusion in 3.5? Arnd & Olof, is it ok for you? Do you want to add your Acked-by on some patches?

Here is another version of the patches to bring ADC driver to Atmel boards. Since last version, here is what changed:
* Rebased on top of staging-next to move out of staging. Had to change to IIO kfifo buffer along the way.
* Reworked the DT bindings according to Jean-Christophe reviews
* Made various fixes according to reviews
* Support for X5 boards

Quoted 7 lines

Here is another version of the patches to bring ADC driver to Atmel boards. Since last version, here is what changed:
* Rebased on top of staging-next to move out of staging. Had to change to IIO kfifo buffer along the way.
* Reworked the DT bindings according to Jean-Christophe reviews
* Made various fixes according to reviews
* Support for X5 boards

What's the reason for providing both DT and non-DT probing in that driver? Doesn't it make more sense to just require that everyone who uses this device boots using the device tree?

Le 09/05/2012 16:40, Arnd Bergmann a ?crit :

Quoted 9 lines · Maxime Ripard

Quoted 7 lines

Here is another version of the patches to bring ADC driver to Atmel boards. Since last version, here is what changed:
* Rebased on top of staging-next to move out of staging. Had to change to IIO kfifo buffer along the way.
* Reworked the DT bindings according to Jean-Christophe reviews
* Made various fixes according to reviews
* Support for X5 boards

Quoted 3 lines

What's the reason for providing both DT and non-DT probing in that driver? Doesn't it make more sense to just require that everyone who uses this device boots using the device tree?

Mostly historical actually.
The first versions were made using only non-DT probing, and then DT was added, so I didn't remove it.
I've no strong feeling about this however, I believe we can definitely drop it, moreover if it makes life easier for you to merge it.

I'll send an updated version.

So I would really like to keep the non-DT probing. This will give the ability for users to experiment IIO/ADC with whichever kernel revision, whichever AT91 SoC they like.

Arnd, we will have to agree on a way to push this work into mainline, but please consider keeping the non-DT part for this driver.

Quoted 6 lines

So I would really like to keep the non-DT probing. This will give the ability for users to experiment IIO/ADC with whichever kernel revision, whichever AT91 SoC they like.

Arnd, we will have to agree on a way to push this work into mainline, but please consider keeping the non-DT part for this driver.

Ok. If the non-DT part is important to you, I suggest you merge it all through the IIO tree, to avoid dependency problems with the platform data header file.

Please add my Acked-by for the arch/arm patches.

Arnd

Hi Jonathan,

Since everyone seems to have put his Acked-By (Nicolas, Arnd and you), are you ok to merge it in your tree ?

You still had some minor comments, do you you want me to post a new patchset to the mailing list, or a public git branch would be enough ?

Thanks,
Maxime

Le 10/05/2012 15:28, Arnd Bergmann a ?crit :

Quoted 15 lines · Nicolas Ferre

Quoted 6 lines

So I would really like to keep the non-DT probing. This will give the ability for users to experiment IIO/ADC with whichever kernel revision, whichever AT91 SoC they like.

Arnd, we will have to agree on a way to push this work into mainline, but please consider keeping the non-DT part for this driver.

Ok. If the non-DT part is important to you, I suggest you merge it all through the IIO tree, to avoid dependency problems with the platform data header file.

Please add my Acked-by for the arch/arm patches.

Arnd