linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dipen Patel <dipenp@nvidia.com>
To: Kent Gibson <warthog618@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
	Jon Hunter <jonathanh@nvidia.com>,
	"Bartosz Golaszewski" <bgolaszewski@baylibre.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	linux-tegra <linux-tegra@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Arnd Bergmann <arnd@arndb.de>,
	"Richard Cochran" <richardcochran@gmail.com>
Subject: Re: GTE - The hardware timestamping engine
Date: Mon, 22 Mar 2021 21:09:50 -0700	[thread overview]
Message-ID: <16ff9b8a-15d9-f2fd-24f4-817a7078c40e@nvidia.com> (raw)
In-Reply-To: <20210323025933.GA10669@sol>



On 3/22/21 7:59 PM, Kent Gibson wrote:
> On Mon, Mar 22, 2021 at 06:53:10PM -0700, Dipen Patel wrote:
>>
>>
>> On 3/22/21 5:32 PM, Kent Gibson wrote:
>>> On Mon, Mar 22, 2021 at 01:21:46PM -0700, Dipen Patel wrote:
>>>> Hi Linus and Kent,
>>>>
> 
> [snip]
> 
>>> In response to all your comments above...
>>>
>>> Firstly, I'm not suggesting that other kernel modules would use the
>>> cdev lineevents, only that they would use the same mechanism that
>>> gpiolib-cdev would use to timestamp the lineevents for userspace.
>>>
>> Sure, I just wanted to mention the different scenarios and wanted to know
>> how can we fit all those together. Having said that, shouldn't this serve
>> an opportunity to extend the linevent framework to accommodate kernel
>> drivers as a clients?
>>
>> If we can't, then there is a risk of duplicating lineevent mechanism in all
>> of those kernel drivers or at least in GTE framework/infrastructure as far
>> as GPIO related GTE part is concerned.
>>  
> 
> In-kernel the lineevents are just IRQs so anything needing a "lineevent"
> can request the IRQ directly.  Or am I missing something?
> 

In the GPIO context, I meant we can extend line_event_timestamp to kernel
drivers as well in that way, both userspace and kernel drivers requesting
particular GPIO for the hardware timestamp would be managed by same
lineevent_* infrastructure from the gpiolib. Something like lineevent_create
version of the kernel drivers, so if they need hardware timestamp on the
GPIO line, they can request with some flags. In that way, GTE can leverage
linevent* codes from gpiolib to cover its both the GPIO related use cases i.e.
userspace app and kernel drivers.

>>> As to that mechanism, my current thinking is that the approach of
>>> associating GTE event FIFO entries with particular physical IRQ events is
>>> problematic, as keeping the two in sync would be difficult, if not
>>> impossible.
>>>
>>> A more robust approach is to ignore the physical IRQs and instead service
>>> the GTE event FIFO, generating IRQs from those events in software -
>>> essentially a pre-timestamped IRQ.  The IRQ framework could provide the
>>> timestamping functionality, equivalent to line_event_timestamp(), for
>>> the IRQ handler/thread and in this case provide the timestamp from the GTE
>>> event.
>>>
>>
>> I have not fully understood above two paragraphs (except about
>> lineevent_event_timestamp related part).
>>
>> I have no idea what it means to "ignore the physical IRQs and service the
>> GTE event FIFO". Just like GPIO clients, there could be IRQ clients which
>> want to monitor certain IRQ line, like ethernet driver wanted to retrieve
>> timestamp for its IRQ line and so on.
>>
> 
> I mean that in the IRQ framework, rather than enabling the physical IRQ
> line it would leave that masked and would instead enable the FIFO line to
> service the FIFO, configure the GTE to generate the events for that
> line, and then generate IRQs in response to the FIFO events.
> That way the client requesting the IRQ is guaranteed to only receive an
> IRQ that corresponds to a GTE FIFO event and the timestamp stored in the
> IRQ framework would match.
> 

I do not think we need to do such things, for example, below is
the rough sequence how GTE can notify its clients be it GPIO or IRQ
lines. I believe this will also help understand better ongoing GPIO
discussions.

1. Configure GTE FIFO watermark or threshold, lets assume 1, i.e
   generate GTE interrupt when FIFO depth is 1.
2. In the GTE ISR or ISR thread, drain internal FIFO entries
3. Through GTE driver's internal mapping, identify which IRQ or
   GPIO number this entry belongs to. (This is possible as GTE
   has predefined bits for each supported signals, for example GTE
   supports 40 GPIOs and 352 IRQ lines, and it has multliple GTE instances
   which can take care all of them)
4. GTE driver pushes the event data (in this case it will be timestamp and
   direction of the event ie.rising or falling) to the GTE generic framework
5. GTE framework will store per event data to its per client/event sw FIFO
6. wake up any sleeping client thread
7. Points 3 to 6 are happening in GTE ISR context. 
8. gte_retrieve_event (which can block if no event) at later convenient
   time do whatever it wants with it. We can extend it to non blocking
   version where some sort of client callbacks can be implemented.

> And that is what I mean by this being an IRQ feature.
> We need feedback from the IRQ guys as to whether that makes sense to
> them.
> 
> Cheers,
> Kent.
> 
Best Regards,
Dipen Patel

  reply	other threads:[~2021-03-23  4:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-17 22:33 GTE - The hardware timestamping engine Dipen Patel
2021-03-20 11:56 ` Linus Walleij
2021-03-20 12:44   ` Arnd Bergmann
2021-03-20 15:38     ` Richard Cochran
2021-03-22 20:33       ` Dipen Patel
2021-03-23  9:03         ` Thierry Reding
2021-03-23 12:51           ` Richard Cochran
2021-03-22  6:00   ` Kent Gibson
2021-03-22 20:21     ` Dipen Patel
2021-03-23  0:32       ` Kent Gibson
2021-03-23  1:53         ` Dipen Patel
2021-03-23  2:59           ` Kent Gibson
2021-03-23  4:09             ` Dipen Patel [this message]
2021-03-23  5:22               ` Kent Gibson
2021-03-23  9:08       ` Linus Walleij
2021-03-23 10:06         ` Thierry Reding
2021-03-23 18:21           ` Marc Zyngier
2021-03-23 18:25           ` Dipen Patel
2021-03-23 21:19           ` Dipen Patel
2021-03-23 18:01         ` Dipen Patel

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=16ff9b8a-15d9-f2fd-24f4-817a7078c40e@nvidia.com \
    --to=dipenp@nvidia.com \
    --cc=arnd@arndb.de \
    --cc=bgolaszewski@baylibre.com \
    --cc=jonathanh@nvidia.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=thierry.reding@gmail.com \
    --cc=warthog618@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).