Re: [PATCHv2 1/2] Documentation: ad5592r: Added devicetree bindings documentation
On Sun, Oct 25, 2015 at 2:31 PM, Jonathan Cameron wrote: > On 13/10/15 10:37, Paul Cercueil wrote: >> Signed-off-by: Paul Cercueil > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 1/2] Documentation: ad5592r: Added devicetree bindings documentation
On Tue, Oct 27, 2015 at 5:13 PM, Linus Walleij 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 1/2] Documentation: ad5592r: Added devicetree bindings documentation
On 13/10/15 10:37, Paul Cercueil wrote:
> Signed-off-by: Paul Cercueil
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 000..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 (< 3000)
> + - 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 .
> + 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
> +
> + ad5592r@0 {
> + compatible = "adi,ad5592r";
> + reg = <0>;
> + spi-max-frequency = <100>;
> + 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 1/2] Documentation: ad5592r: Added devicetree bindings documentation
On 27/10/15 16:13, Linus Walleij wrote: > On Sun, Oct 25, 2015 at 2:31 PM, Jonathan Cameron wrote: >> On 13/10/15 10:37, Paul Cercueil wrote: >>> Signed-off-by: Paul Cercueil >> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
