lkml.org 
[lkml]   [2018]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v7 1/4] dt-bindings: pps: descriptor-based gpio, capture-clear addition
Quoting Rob Herring <robh@kernel.org>:

> On Mon, Nov 26, 2018 at 9:57 PM tom burkart <tom@aussec.com> wrote:
>>
>> Quoting Rob Herring <robh@kernel.org>:
>>
>> > On Sat, Nov 17, 2018 at 6:35 PM tom burkart <tom@aussec.com> wrote:
>> >>
>> >> Quoting Rob Herring <robh@kernel.org>:
>> >>
>> >> > On Sat, Nov 17, 2018 at 4:35 AM tom burkart <tom@aussec.com> wrote:
>> >> >>
>> >> >> Quoting Rob Herring <robh@kernel.org>:
>> >> >>
>> >> >> > On Wed, Nov 14, 2018 at 11:54:29PM +1100, Tom Burkart wrote:
>> >> >> >> This patch changes the devicetree bindings for the pps-gpio driver
>> >> >> >> from the integer based ABI to the descriptor based ABI.
>> >> >> > ? That has nothing to do with DT.
>> >> >>
>> >> >> I believe it does, as the change in ABI forces a rename in the DT
>> >> >> naming convention.
>> >> >> This is due to the descriptor based ABI appending "-gpio" or
>> >> "-gpios" (see
>> >> >> Documentation/gpio/base.txt.)
>> >> >> Admittedly, I may have called it by the wrong name due to ignorance,
>> >> >> my apologies.
>> >> >
>> >> > If what you say is correct, then you can't change this driver. You'll
>> >> > break compatibility with any existing DT.
>> >> >
>> >> > Changing the binding reasoning should purely be that this is the
>> >> > preferred form. Bindings must be independent from changing kernel
>> >> > APIs.
>> >>
>> >> See comments from Philip Zabel. I misread the documentation and this
>> >> has now been corrected in v8 of the patch. I hope that eliminates all
>> >> comments made above.
>> >>
>> >> >> >> It also adds
>> >> >> >> documentation for the device tree capture-clear option. The legacy
>> >> >> >> device tree entry for the GPIO pin is supported.
>> >> >> >>
>> >> >> >> Signed-off-by: Tom Burkart <tom@aussec.com>
>> >> >> >> ---
>> >> >> >> Documentation/devicetree/bindings/pps/pps-gpio.txt | 8 ++++++--
>> >> >> >> 1 file changed, 6 insertions(+), 2 deletions(-)
>> >> >> >>
>> >> >> >> diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.txt
>> >> >> >> b/Documentation/devicetree/bindings/pps/pps-gpio.txt
>> >> >> >> index 3683874832ae..6c9fc0998d94 100644
>> >> >> >> --- a/Documentation/devicetree/bindings/pps/pps-gpio.txt
>> >> >> >> +++ b/Documentation/devicetree/bindings/pps/pps-gpio.txt
>> >> >> >> @@ -5,19 +5,23 @@ a GPIO pin.
>> >> >> >>
>> >> >> >> Required properties:
>> >> >> >> - compatible: should be "pps-gpio"
>> >> >> >> -- gpios: one PPS GPIO in the format described by ../gpio/gpio.txt
>> >> >> >> +- pps-gpios: one PPS GPIO in the format described by
>> ../gpio/gpio.txt
>> >> >> >> +Alternatively (DEPRECATED), instead of pps-gpios above,
>> it may have:
>> >> >> >> +- gpios: one PPS GPIO as above
>> >> >> >>
>> >> >> >> Optional properties:
>> >> >> >> - assert-falling-edge: when present, assert is indicated by a
>> >> >> falling edge
>> >> >> >> (instead of by a rising edge)
>> >> >> >> +- capture-clear: when present, also capture the PPS clear event
>> >> >> >
>> >> >> > Is this a h/w thing? or driver configuration?
>> >> >>
>> >> >> Driver configuration. Most of the code was present in the driver, yet
>> >> >> it was not documented, or usable due to a two line (code) omission
>> >> >> (the value was not being fetched from DT).
>> >> >
>> >> > So what determines how you want to configure this? If the user will
>> >> > want to change it, then it should be a sysfs attr and exposed to
>> >> > userspace. If it depends on h/w config for a board then it can be in
>> >> > DT.
>> >>
>> >> Sorry, I misled you somewhat. If the PPS pulse active transition from
>> >> the hardware is on the falling edge, this flag is required to get the
>> >> OS to use that as the active transition. This would not change at the
>> >> user's whim but rather it is dependent on connected hardware.
>> >
>> > This description sounds more like 'assert-falling-edge' than
>> 'capture-clear'.
>> >
>> > I'm still not clear on what 'capture-clear' is.
>>
>> Ignoring my patch for a minute, the pps_gpio_irq_handler will only
>> report a pps PPS_CAPTURECLEAR event if 'capture-clear' is set. As the
>> current pps-gpio driver is not able to set this flag, it cannot ever
>> report a PPS_CAPTURECLEAR event.
>>
>> My patch adds the ability to set this flag and adds the documentation
>> to go with it.
>> Admittedly, I do not require this functionality for what I want, but
>> working with the code, I noticed the omission and decided to add it
>> for someone else to use it, if they need it.
>>
>> I am happy to remove this out of my patch, if you feel this to be the
>> best way forward.
>
> I found this prior discussion on adding this[1]. Seems to me this
> should be userspace configurable if the GPIO line can interrupt on
> both edges. We shouldn't need a DT property to determine that.
>
> Rob
>
> [1] https://lore.kernel.org/patchwork/patch/557781/

Patch v11 has just been sent that has no changes to the capture-clear
DT option.

Tom

\
 
 \ /
  Last update: 2018-11-29 01:30    [W:0.143 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site