Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1255393 > unrolled thread
| Started by | Jonathan Cameron <jic23@kernel.org> |
|---|---|
| First post | 2015-10-25 14:40 +0100 |
| Last post | 2015-10-31 12:10 +0100 |
| Articles | 4 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCHv2 1/2] Documentation: ad5592r: Added devicetree bindings documentation Jonathan Cameron <jic23@kernel.org> - 2015-10-25 14:40 +0100
Re: [PATCHv2 1/2] Documentation: ad5592r: Added devicetree bindings documentation Linus Walleij <linus.walleij@linaro.org> - 2015-10-27 17:20 +0100
Re: [PATCHv2 1/2] Documentation: ad5592r: Added devicetree bindings documentation Linus Walleij <linus.walleij@linaro.org> - 2015-10-27 17:20 +0100
Re: [PATCHv2 1/2] Documentation: ad5592r: Added devicetree bindings documentation Jonathan Cameron <jic23@kernel.org> - 2015-10-31 12:10 +0100
| From | Jonathan Cameron <jic23@kernel.org> |
|---|---|
| Date | 2015-10-25 14:40 +0100 |
| Subject | Re: [PATCHv2 1/2] Documentation: ad5592r: Added devicetree bindings documentation |
| Message-ID | <qntGG-3z4-1@gated-at.bofh.it> |
On 13/10/15 10:37, Paul Cercueil wrote:
> Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
Looks good to me, but as it is a little bit 'different' and we are
defining entirely new generic bindings (the channel modes stuff)
I would like some more input. It might be overkill but we do
of course have the pinctl framework which covers this sort of
thing... Might be worth considering if using that to get the unified
bindings might make sense here...
cc'd Linus in case he wants to comment on this.
It would obviously be a very heavy weight solution to the problem
so I'm far from convinced it makes sense - or even fits the usecase
terrible well. Just thought I'd mention the possibility.
> ---
> .../devicetree/bindings/iio/dac/ad5592r.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/dac/ad5592r.txt
>
> v2: Fix indentation issue
>
> diff --git a/Documentation/devicetree/bindings/iio/dac/ad5592r.txt b/Documentation/devicetree/bindings/iio/dac/ad5592r.txt
> new file mode 100644
> index 0000000..12b8d0e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/dac/ad5592r.txt
> @@ -0,0 +1,43 @@
> +Analog Devices AD5592R/AD5593R DAC/ADC device driver
> +
> +Required properties for the AD5592R:
> + - compatible: Must be "adi,ad5592r"
> + - reg: SPI chip select number for the device
> + - spi-max-frequency: Max SPI frequency to use (< 30000000)
> + - spi-cpol: The AD5592R requires inverse clock polarity (CPOL) mode
> +
> +Required properties for the AD5593R:
> + - compatible: Must be "adi,ad5593r"
> + - reg: I2C address of the device
> +
> +Required properties for all supported chips:
> + - channel-modes: An array of eight 8-bit values (one per channel)
> + describing the mode of each channel. Macros specifying the valid values
> + can be found in <dt-bindings/iio/adi,ad5592r.h>.
> + The following values are currently supported:
> + * CH_MODE_UNUSED (the pin is pulled down)
> + * CH_MODE_DAC
> + * CH_MODE_ADC
> + * CH_MODE_GPIO_TRISTATE
> +
> +Example:
> +
> + #include <dt-bindings/iio/adi,ad5592r.h>
> +
> + ad5592r@0 {
> + compatible = "adi,ad5592r";
> + reg = <0>;
> + spi-max-frequency = <1000000>;
> + spi-cpol;
> +
> + channel-modes = /bits/ 8 <
> + CH_MODE_DAC
> + CH_MODE_ADC
> + CH_MODE_ADC
> + CH_MODE_UNUSED
> + CH_MODE_UNUSED
> + CH_MODE_UNUSED
> + CH_MODE_UNUSED
> + CH_MODE_UNUSED
> + >;
> + };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Linus Walleij <linus.walleij@linaro.org> |
|---|---|
| Date | 2015-10-27 17:20 +0100 |
| Subject | Re: [PATCHv2 1/2] Documentation: ad5592r: Added devicetree bindings documentation |
| Message-ID | <qof8B-7mI-11@gated-at.bofh.it> |
| In reply to | #1255393 |
On Tue, Oct 27, 2015 at 5:13 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > There are other problems though, but I comment on these > separately. Was wrong about that. I think this can go in like this. Later, this device may fork off a GPIO chip as well, but we will deal with that whenever we run into it. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Linus Walleij <linus.walleij@linaro.org> |
|---|---|
| Date | 2015-10-27 17:20 +0100 |
| Subject | Re: [PATCHv2 1/2] Documentation: ad5592r: Added devicetree bindings documentation |
| Message-ID | <qof8B-7mI-13@gated-at.bofh.it> |
| In reply to | #1255393 |
On Sun, Oct 25, 2015 at 2:31 PM, Jonathan Cameron <jic23@kernel.org> wrote: > On 13/10/15 10:37, Paul Cercueil wrote: >> Signed-off-by: Paul Cercueil <paul.cercueil@analog.com> > Looks good to me, but as it is a little bit 'different' and we are > defining entirely new generic bindings (the channel modes stuff) > I would like some more input. It might be overkill but we do > of course have the pinctl framework which covers this sort of > thing... Might be worth considering if using that to get the unified > bindings might make sense here... > > cc'd Linus in case he wants to comment on this. > > It would obviously be a very heavy weight solution to the problem > so I'm far from convinced it makes sense - or even fits the usecase > terrible well. Just thought I'd mention the possibility. There is something of a grey area between "definately pin control" and "some extra pin hardware duct-taped to something else". I guess that is natural, life is full of grey areas... Basically if there are plenty of pins and functions, local solutions to the problem will not scale. Then it is necessary to go ahead and implement full pin control. Especially for say a big BGA package or so with lots and lots of pins. It is is a few pins or they just alter between similar functionality (like different graphic modes) I think local solutions are OK. There are other problems though, but I comment on these separately. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Jonathan Cameron <jic23@kernel.org> |
|---|---|
| Date | 2015-10-31 12:10 +0100 |
| Message-ID | <qpCcN-25F-5@gated-at.bofh.it> |
| In reply to | #1256902 |
On 27/10/15 16:13, Linus Walleij wrote: > On Sun, Oct 25, 2015 at 2:31 PM, Jonathan Cameron <jic23@kernel.org> wrote: >> On 13/10/15 10:37, Paul Cercueil wrote: >>> Signed-off-by: Paul Cercueil <paul.cercueil@analog.com> >> Looks good to me, but as it is a little bit 'different' and we are >> defining entirely new generic bindings (the channel modes stuff) >> I would like some more input. It might be overkill but we do >> of course have the pinctl framework which covers this sort of >> thing... Might be worth considering if using that to get the unified >> bindings might make sense here... >> >> cc'd Linus in case he wants to comment on this. >> >> It would obviously be a very heavy weight solution to the problem >> so I'm far from convinced it makes sense - or even fits the usecase >> terrible well. Just thought I'd mention the possibility. > > There is something of a grey area between "definately pin control" > and "some extra pin hardware duct-taped to something else". > > I guess that is natural, life is full of grey areas... > > Basically if there are plenty of pins and functions, local solutions > to the problem will not scale. Then it is necessary to go ahead > and implement full pin control. Especially for say a big BGA > package or so with lots and lots of pins. > > It is is a few pins or they just alter between similar functionality > (like different graphic modes) I think local solutions are OK. Thanks Linus. Makes sense -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web