From: Michael Hennerich <michael.hennerich@analog.com>
To: Jonathan Cameron <jic23@kernel.org>,
lars@metafoo.de, knaack.h@gmx.de, paul.cercueil@analog.com,
robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
Linus Walleij <linus.walleij@linaro.org>,
Alexandre Courbot <gnurou@gmail.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH v2] iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs
Date: Mon, 7 Mar 2016 13:25:38 +0100 [thread overview]
Message-ID: <56DD7342.5040101@analog.com> (raw)
In-Reply-To: <56DB1E49.3070908@kernel.org>
On 03/05/2016 06:58 PM, Jonathan Cameron wrote:
> On 02/03/16 16:21, Michael Hennerich wrote:
>> On 02/27/2016 06:50 PM, Jonathan Cameron wrote:
>>> On 25/02/16 13:36, michael.hennerich@analog.com wrote:
>>>> From: Paul Cercueil <paul.cercueil@analog.com>
>>>>
>>>> This patch adds support for the AD5592R (spi) and AD5593R (i2c)
>>>> ADC/DAC devices.
>>>>
>>>> Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
>>>> Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
>>>>
>>> A few bits inline.
>>>
>>> I'll need a gpio review on this (looks fine to me but it does contain
>>> a gpiochip driver.) Not to mention the question of whether they will
>>> be happy with a gpio chip hiding in iio (rather than via an mfd with a
>>> separate driver - which feels like overkill here).
>>>
>>> The big question to my mind is whether we can take the view this won't
>>> be the last multipurpose chip we will see so do we need to sort the
>>> binding out to make it generic? It'll be a bit of a pain for you
>>> but I think we can do it fairly easily.
>>> (either way I'll also need a device tree ack on this one!)
>>>
>>> So then we get into the question of the best way of doing the bindings.
>>> The gpio approach seems a little limiting for things as flexible as
>>> this but we should certainly be using their macros where relevant.
>>
>> Hi Jonathan,
>>
>> Thanks for the review.
>>
>> The problem is see is that using GPIOF_OPEN_DRAIN, will simulate OPEN DRAIN behaviour only, by configuring the device for input when outputing logic high.
>>
> Is it actually documented as such anywhere? (that's hideous!)
In fact it is -
www.kernel.org/doc/Documentation/gpio/gpio-legacy.txt
"When setting the flag as GPIOF_OPEN_DRAIN then it will assume that pins is
open drain type. Such pins will not be driven to 1 in output mode. It is
require to connect pull-up on such pins. By enabling this flag, gpio lib
will
make the direction to input when it is asked to set value of 1 in output
mode
to make the pin HIGH. The pin is make to LOW by driving value 0 in
output mode."
And that's exactly what the gpiolib code does.
--
Greetings,
Michael
--
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif
WARNING: multiple messages have this Message-ID (diff)
From: Michael Hennerich <michael.hennerich@analog.com>
To: Jonathan Cameron <jic23@kernel.org>, <lars@metafoo.de>,
<knaack.h@gmx.de>, <paul.cercueil@analog.com>,
<robh+dt@kernel.org>, <pawel.moll@arm.com>,
<mark.rutland@arm.com>, <ijc+devicetree@hellion.org.uk>
Cc: <linux-iio@vger.kernel.org>, <devicetree@vger.kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Alexandre Courbot <gnurou@gmail.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH v2] iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs
Date: Mon, 7 Mar 2016 13:25:38 +0100 [thread overview]
Message-ID: <56DD7342.5040101@analog.com> (raw)
In-Reply-To: <56DB1E49.3070908@kernel.org>
On 03/05/2016 06:58 PM, Jonathan Cameron wrote:
> On 02/03/16 16:21, Michael Hennerich wrote:
>> On 02/27/2016 06:50 PM, Jonathan Cameron wrote:
>>> On 25/02/16 13:36, michael.hennerich@analog.com wrote:
>>>> From: Paul Cercueil <paul.cercueil@analog.com>
>>>>
>>>> This patch adds support for the AD5592R (spi) and AD5593R (i2c)
>>>> ADC/DAC devices.
>>>>
>>>> Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
>>>> Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
>>>>
>>> A few bits inline.
>>>
>>> I'll need a gpio review on this (looks fine to me but it does contain
>>> a gpiochip driver.) Not to mention the question of whether they will
>>> be happy with a gpio chip hiding in iio (rather than via an mfd with a
>>> separate driver - which feels like overkill here).
>>>
>>> The big question to my mind is whether we can take the view this won't
>>> be the last multipurpose chip we will see so do we need to sort the
>>> binding out to make it generic? It'll be a bit of a pain for you
>>> but I think we can do it fairly easily.
>>> (either way I'll also need a device tree ack on this one!)
>>>
>>> So then we get into the question of the best way of doing the bindings.
>>> The gpio approach seems a little limiting for things as flexible as
>>> this but we should certainly be using their macros where relevant.
>>
>> Hi Jonathan,
>>
>> Thanks for the review.
>>
>> The problem is see is that using GPIOF_OPEN_DRAIN, will simulate OPEN DRAIN behaviour only, by configuring the device for input when outputing logic high.
>>
> Is it actually documented as such anywhere? (that's hideous!)
In fact it is -
www.kernel.org/doc/Documentation/gpio/gpio-legacy.txt
"When setting the flag as GPIOF_OPEN_DRAIN then it will assume that pins is
open drain type. Such pins will not be driven to 1 in output mode. It is
require to connect pull-up on such pins. By enabling this flag, gpio lib
will
make the direction to input when it is asked to set value of 1 in output
mode
to make the pin HIGH. The pin is make to LOW by driving value 0 in
output mode."
And that's exactly what the gpiolib code does.
--
Greetings,
Michael
--
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif
next prev parent reply other threads:[~2016-03-07 12:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-25 13:36 [PATCH v2] iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs michael.hennerich
2016-02-25 13:36 ` michael.hennerich-OyLXuOCK7orQT0dZR+AlfA
[not found] ` <1456407412-16218-1-git-send-email-michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
2016-02-27 17:50 ` Jonathan Cameron
2016-02-27 17:50 ` Jonathan Cameron
2016-03-02 16:21 ` Michael Hennerich
2016-03-02 16:21 ` Michael Hennerich
[not found] ` <56D71309.30204-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
2016-03-05 17:58 ` Jonathan Cameron
2016-03-05 17:58 ` Jonathan Cameron
2016-03-07 12:25 ` Michael Hennerich [this message]
2016-03-07 12:25 ` Michael Hennerich
2016-03-11 16:28 ` Linus Walleij
[not found] ` <CACRpkdap_8YGCAvNeK7_0H2MDDnwQ9QDJH4O2SzEkDmczPGtLg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-03-21 14:07 ` Michael Hennerich
2016-03-21 14:07 ` Michael Hennerich
[not found] ` <56F0001B.9010608-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
2016-03-22 10:50 ` Linus Walleij
2016-03-22 10:50 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56DD7342.5040101@analog.com \
--to=michael.hennerich@analog.com \
--cc=devicetree@vger.kernel.org \
--cc=gnurou@gmail.com \
--cc=ijc+devicetree@hellion.org.uk \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=paul.cercueil@analog.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.