Message-ID: <4DBA3F13.9010706@gmail.com>
Date:	Fri, 29 Apr 2011 08:31:15 +0400
From:	Igor Plyatov <plyatov@...il.com>
To:	Alexander Gordeev <lasaine@....cs.msu.su>
CC:	Rodolfo Giometti <rodolfo.giometti@...eenne.com>,
	linuxpps@...enneenne.com, linux-kernel@...r.kernel.org
Subject: Re: [LinuxPPS] [PATCH 2/2] pps: new client driver using IRQs

Hi!

> В Fri, 29 Apr 2011 00:55:24 +0400
> Alexander Gordeev<lasaine@....cs.msu.su>  пишет:
>
>> В Thu, 28 Apr 2011 16:03:59 -0400
>> James Nuss<jamesnuss@...ometrics.ca>  пишет:
>>
>>> Hi Alexander,
>>>
>>> Thanks for reviewing the code.
>>>
>>> On Thu, Apr 28, 2011 at 7:22 AM, Alexander Gordeev
>>> <lasaine@....cs.msu.su>  wrote:
>>>> Hi James,
>>>>
>>>> В Wed, 27 Apr 2011 14:14:14 -0400
>>>> James Nuss<jamesnuss@...ometrics.ca>  пишет:
>>>>
>>>>> +             return -EINVAL;
>>>>> +     }
>>>>> +
>>>>> +     res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>>>>> +     if (res == NULL) {
>>>>> +             pr_err(PPS_IRQ_NAME ": no IRQ resource was given");
>>>>> +             return -EINVAL;
>>>>> +     }
>>>>> +
>>>>> +     if (!(res->flags&  (IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING))) {
>>>>> +             pr_err(PPS_IRQ_NAME ": given IRQ resource must be edge triggered");
>>>>> +             return -EINVAL;
>>>>> +     }
>>>> I think it doesn't actually expect that both flags are set because it
>>>> always treats it as assert in the irq handler. What does your signal
>>>> look like?
>>> The conditional logic is that one of either IRQF_TRIGGER_RISING or
>>> IRQF_TRIGGER_FALLING must be set. It doesn't make much sense to have
>>> neither set for PPS signals.
>>> My intention is that the driver is generic enough so you can register
>>> an IRQ resource with either IRQF_TRIGGER_RISING or
>>> IRQF_TRIGGER_FALLING and you will get and assert event for that edge.
>>> Clear events are not generated as you suggest but I believe this is
>>> OK.
>>> My signal is a simple low-to-high transition indicating the PPS. But I
>>> believe you could register a device using this driver referencing the
>>> other edge if required.
>> Ok, but is there a way one can register an IRQ resource with both flags
>> set? If yes, then it would be nice to have a stricter check here to
>> prevent two situations:
>> 1. none flag is set (it is already in place)
>> 2. both flags are set
>>
>> The latter will definitely mess things up, right?
> I mean, one surely can register an IRQ resource with both flags set. And
> if the underlying hardware works as it is described (i.e. raises an irq
> on both edges) then it will be a problem.

Please don't try to abandon one of ASSERT or CLEAR events!
It is very useful to register both of them, because in this case its 
possible to measure pulse width and decode PPS signals like DCF77.

I write similar driver (pps-client-gpio.c) for Linux-2.6.36 with helper 
drivers (virtual-gps.c and pps-decoders.c) which allows to receive 
GeoSIG Ltd. T1PPS (DCF77 alike) time signal, register both events, then 
decode them and provide a virtual GPS (NMEA time source) device.

These drivers operates very well together with standard NTP server.

>
> _______________________________________________
> LinuxPPS mailing list
> LinuxPPS@...enneenne.com
> http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
> Wiki:http://wiki.enneenne.com/index.php/LinuxPPS_support

Best regards!

-- 
Igor Plyatov

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists