On Mon, Mar 22, 2021 at 06:53:10PM -0700, Dipen Patel wrote:

On 3/22/21 5:32 PM, Kent Gibson wrote:

quoted

On Mon, Mar 22, 2021 at 01:21:46PM -0700, Dipen Patel wrote:

quoted

Hi Linus and Kent,

[snip]

quoted

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?

quoted

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.

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.