Re: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Linus Walleij]

On Fri, Dec 18, 2015 at 12:19 AM, Peter Rosin  wrote:

> This all makes sense. The reason is that I'm not familiar with
> the kernel APIs. I have to wrap my head around how to set up
> work to be performed later, etc etc.

FWIW a random work to be performed later is a delayed work.
It can be queued on a global workqueue or you can create your
own workqueue. This is the latter way, it's even simpler if you
just use NULL as workqueue, it will then end up on the big
system workqueue. The workqueue in turn uses deferrable timers,
and these can also be used directly.

#include 

struct foo {
   struct workqueue_struct *foo_wq;
   struct delayed_work delayed_foo_work;
   
};

static void foo_work_cb(struct work_struct *work)
{
struct foo *foo = container_of(work, struct foo, delayed_foo_work.work);

... do the work ...
};

main {
   INIT_DEFERRABLE_WORK(>delayed_foo_work, foo_work_cb);
   queue_delayed_work(foo->foo_wq, >delayed_foo_work, 6*HZ);
}

6*HZ means wait for 6 seconds as the delay is given in ticks (jiffies)
and the system does HZ ticks per second.

>> > I have realized that I could work with one-shot-interrupts. Then the
>> > urgency to disable interrupts go away, as only one interrupt would
>> > be served. That was not my immediate solution though, as I have been
>> > using isr type registers in this way several times before.
>>
>> That sounds like the right solution. With ONESHOT a threaded IRQ
>> will have its line masked until you return from the ISR thread. Would this
>> work for your usecase?
>
> The ISR thread would need to be able to disable further interrupts
> before it returned, is that possible without deadlock? If so, it's
> a good fit.

Yes that is what the ONESHOT flag means. So like this:

ret = request_threaded_irq(irqnum, NULL, foo_irq_handler,
   IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
   "foo", foo);

To register a threaded oneshot IRQ that will run on a falling edge,
as a thread, until completed, masking its own interrupt line, but
no others.

The threaded handler can msleep(), mdelay()/udelay() etc since it
is a thread. usleep_range(a, b) is the best as the system can idle
while that happens, and can plan for a good wakeup point.

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

Re: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Linus Walleij]

On Fri, Dec 18, 2015 at 12:19 AM, Peter Rosin  wrote:

> This all makes sense. The reason is that I'm not familiar with
> the kernel APIs. I have to wrap my head around how to set up
> work to be performed later, etc etc.

FWIW a random work to be performed later is a delayed work.
It can be queued on a global workqueue or you can create your
own workqueue. This is the latter way, it's even simpler if you
just use NULL as workqueue, it will then end up on the big
system workqueue. The workqueue in turn uses deferrable timers,
and these can also be used directly.

#include 

struct foo {
   struct workqueue_struct *foo_wq;
   struct delayed_work delayed_foo_work;
   
};

static void foo_work_cb(struct work_struct *work)
{
struct foo *foo = container_of(work, struct foo, delayed_foo_work.work);

... do the work ...
};

main {
   INIT_DEFERRABLE_WORK(>delayed_foo_work, foo_work_cb);
   queue_delayed_work(foo->foo_wq, >delayed_foo_work, 6*HZ);
}

6*HZ means wait for 6 seconds as the delay is given in ticks (jiffies)
and the system does HZ ticks per second.

>> > I have realized that I could work with one-shot-interrupts. Then the
>> > urgency to disable interrupts go away, as only one interrupt would
>> > be served. That was not my immediate solution though, as I have been
>> > using isr type registers in this way several times before.
>>
>> That sounds like the right solution. With ONESHOT a threaded IRQ
>> will have its line masked until you return from the ISR thread. Would this
>> work for your usecase?
>
> The ISR thread would need to be able to disable further interrupts
> before it returned, is that possible without deadlock? If so, it's
> a good fit.

Yes that is what the ONESHOT flag means. So like this:

ret = request_threaded_irq(irqnum, NULL, foo_irq_handler,
   IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
   "foo", foo);

To register a threaded oneshot IRQ that will run on a falling edge,
as a thread, until completed, masking its own interrupt line, but
no others.

The threaded handler can msleep(), mdelay()/udelay() etc since it
is a thread. usleep_range(a, b) is the best as the system can idle
while that happens, and can plan for a good wakeup point.

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

Re: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Jonathan Cameron]

On 17/12/15 23:19, Peter Rosin wrote:
> Hi Linus,
> 
>> On Mon, Dec 14, 2015 at 11:38 AM, Peter Rosin  wrote:
>>
>> I think I atleast half-understand what you're trying to do.
> 
> Good. It's really not that complicated, but I'm perhaps not describing
> it very clearly...
> 
>>> Userspace does the following when doing this w/o the isr patches:
>>>
>>> 1. select signal using the MUX
>>> 2. set the DAC so high that INPUT is never reaching that level.
>>>C (and thus gpio) is now stable
>>> 3. start waiting for interrupts on gpio
>>> 4. adjust the DAC level to the level of interest
>>> 5. abort on interrupt or timeout
>> (...)
>>> With the isr patches, the above transforms into:
>>>
>>> 1. select signal using the MUX
>>> 2. set the DAC so high that INPUT is never reaching that level.
>>>C (and thus gpio) is now stable
>>> 3. read the isr bit to clear it
>>> 4. adjust the DAC level to the level of interest
>>> 5. read the isr bit again after 50ms
>>>
>>> The result is available directly in the isr bit, no interrupts needed.
>>
>> The problem I see here as kernel developer is that there is a fuzzy
>> and implicit separation of concerns between userspace and
>> kernelspace.
>>
>> IMO reading hardware registers is the domain of the kernel, and
>> then the result thereof is presented to userspace. The kernel
>> handles hardware, simply.
>>
>> I think we need to reverse out of this solution and instead ask
>> the question what the kernel should provide your userspace.
>> Maybe parts of what you have in userspace needs to actually
>> go into the kernel?
>>
>> The goal of IIO seems to be to present raw and calibrated
>> (SI unit) data to userspace. So what data is it you want, and
>> why can't you just get that directly from the kernel without
>> tricksing around with reading registers bits in userspace?
> 
> This all makes sense. The reason is that I'm not familiar with
> the kernel APIs. I have to wrap my head around how to set up
> work to be performed later, etc etc. All of that is in all
> likelihood pretty straightforward, but I feel that I am
> flundering around every step of the way. End result; I find
> myself trying to do as little as possible inside the kernel.
> 
> I.e. I have a pretty clear picture of what needs to be done, but
> the devil is in the details...
> 
>> If a kernel module needs to read an interrupt bit directly from the
>> GPIO controller is another thing. That is akin to how polling
>> network drivers start polling registers for incoming packages
>> instead of waiting for them to fire interrupts. Just that these are
>> dedicated IRQ lines, not GPIOs.
> 
> Yes, there was also the NACK to adding new gpio sysfs files which
> emphasizes this.
> 
>> As struct irq_chip has irq_get_irqchip_state() I think this
>> is actually possible to achieve this by implementing that
>> and calling irq_get_irqchip_state().
> 
> I'll have a peek into that, but see below.
> 
>>> I have realized that I could work with one-shot-interrupts. Then the
>>> urgency to disable interrupts go away, as only one interrupt would
>>> be served. That was not my immediate solution though, as I have been
>>> using isr type registers in this way several times before.
>>
>> That sounds like the right solution. With ONESHOT a threaded IRQ
>> will have its line masked until you return from the ISR thread. Would this
>> work for your usecase?
> 
> The ISR thread would need to be able to disable further interrupts
> before it returned, is that possible without deadlock? If so, it's
> a good fit.
> 
>> I suspect this require you to move the logic into the kernel? Into IIO?
> bc 
> Yes, and yes IIO seems about right to me too.
Whilst the full approach could well be done in IIO I can also see
some possible demand for a simple latching gpio which is I think all you
were doing with the ISR stuff.

Seems a sensible interface to support in some fashion even aside from this
discussion.  Devices like PLCs do this stuff all the time though usually
in conjunction with a capture unit that will stash a copy of some
associated counter...


> 
>>> If this is to be done in IIO, I imagine that the sanest thing would
>>> be to integrate the whole DAC-loop and present a finished envelope
>>> value to user space? This envelope detector would have to be pretty
>>> configurable, or it will be next to useless to anybody but me.
>>
>> Makes sense to me, but must be ACKed by Jonathan. But it
>> sounds pretty cool does it not?
> 
> Right, but I don't see why it should be a problem? An envelope detector
> surely fits IIO.
Sure - it's within scope I think, but there is probably a fair bit of
new interface needed to control it..
> 
>>> I could imaging that this new IIO driver should be able to work
>>> with any DAC type device, which in my case would be the mcp4531
>>> dpot. Which is not a DAC, maybe that could be solved with a new
>>> dac-dpot driver, applicable to cases where a dpot is wired as a
>>> simple voltage divider? The new IIO driver also needs 

Re: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Jonathan Cameron]

On 17/12/15 23:19, Peter Rosin wrote:
> Hi Linus,
> 
>> On Mon, Dec 14, 2015 at 11:38 AM, Peter Rosin  wrote:
>>
>> I think I atleast half-understand what you're trying to do.
> 
> Good. It's really not that complicated, but I'm perhaps not describing
> it very clearly...
> 
>>> Userspace does the following when doing this w/o the isr patches:
>>>
>>> 1. select signal using the MUX
>>> 2. set the DAC so high that INPUT is never reaching that level.
>>>C (and thus gpio) is now stable
>>> 3. start waiting for interrupts on gpio
>>> 4. adjust the DAC level to the level of interest
>>> 5. abort on interrupt or timeout
>> (...)
>>> With the isr patches, the above transforms into:
>>>
>>> 1. select signal using the MUX
>>> 2. set the DAC so high that INPUT is never reaching that level.
>>>C (and thus gpio) is now stable
>>> 3. read the isr bit to clear it
>>> 4. adjust the DAC level to the level of interest
>>> 5. read the isr bit again after 50ms
>>>
>>> The result is available directly in the isr bit, no interrupts needed.
>>
>> The problem I see here as kernel developer is that there is a fuzzy
>> and implicit separation of concerns between userspace and
>> kernelspace.
>>
>> IMO reading hardware registers is the domain of the kernel, and
>> then the result thereof is presented to userspace. The kernel
>> handles hardware, simply.
>>
>> I think we need to reverse out of this solution and instead ask
>> the question what the kernel should provide your userspace.
>> Maybe parts of what you have in userspace needs to actually
>> go into the kernel?
>>
>> The goal of IIO seems to be to present raw and calibrated
>> (SI unit) data to userspace. So what data is it you want, and
>> why can't you just get that directly from the kernel without
>> tricksing around with reading registers bits in userspace?
> 
> This all makes sense. The reason is that I'm not familiar with
> the kernel APIs. I have to wrap my head around how to set up
> work to be performed later, etc etc. All of that is in all
> likelihood pretty straightforward, but I feel that I am
> flundering around every step of the way. End result; I find
> myself trying to do as little as possible inside the kernel.
> 
> I.e. I have a pretty clear picture of what needs to be done, but
> the devil is in the details...
> 
>> If a kernel module needs to read an interrupt bit directly from the
>> GPIO controller is another thing. That is akin to how polling
>> network drivers start polling registers for incoming packages
>> instead of waiting for them to fire interrupts. Just that these are
>> dedicated IRQ lines, not GPIOs.
> 
> Yes, there was also the NACK to adding new gpio sysfs files which
> emphasizes this.
> 
>> As struct irq_chip has irq_get_irqchip_state() I think this
>> is actually possible to achieve this by implementing that
>> and calling irq_get_irqchip_state().
> 
> I'll have a peek into that, but see below.
> 
>>> I have realized that I could work with one-shot-interrupts. Then the
>>> urgency to disable interrupts go away, as only one interrupt would
>>> be served. That was not my immediate solution though, as I have been
>>> using isr type registers in this way several times before.
>>
>> That sounds like the right solution. With ONESHOT a threaded IRQ
>> will have its line masked until you return from the ISR thread. Would this
>> work for your usecase?
> 
> The ISR thread would need to be able to disable further interrupts
> before it returned, is that possible without deadlock? If so, it's
> a good fit.
> 
>> I suspect this require you to move the logic into the kernel? Into IIO?
> bc 
> Yes, and yes IIO seems about right to me too.
Whilst the full approach could well be done in IIO I can also see
some possible demand for a simple latching gpio which is I think all you
were doing with the ISR stuff.

Seems a sensible interface to support in some fashion even aside from this
discussion.  Devices like PLCs do this stuff all the time though usually
in conjunction with a capture unit that will stash a copy of some
associated counter...


> 
>>> If this is to be done in IIO, I imagine that the sanest thing would
>>> be to integrate the whole DAC-loop and present a finished envelope
>>> value to user space? This envelope detector would have to be pretty
>>> configurable, or it will be next to useless to anybody but me.
>>
>> Makes sense to me, but must be ACKed by Jonathan. But it
>> sounds pretty cool does it not?
> 
> Right, but I don't see why it should be a problem? An envelope detector
> surely fits IIO.
Sure - it's within scope I think, but there is probably a fair bit of
new interface needed to control it..
> 
>>> I could imaging that this new IIO driver should be able to work
>>> with any DAC type device, which in my case would be the mcp4531
>>> dpot. Which is not a DAC, maybe that could be solved with a new
>>> dac-dpot driver, applicable to cases where a dpot is wired as a
>>> simple voltage divider? The new IIO 

RE: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Peter Rosin]

Hi Linus,

> On Mon, Dec 14, 2015 at 11:38 AM, Peter Rosin  wrote:
> 
> I think I atleast half-understand what you're trying to do.

Good. It's really not that complicated, but I'm perhaps not describing
it very clearly...

> > Userspace does the following when doing this w/o the isr patches:
> >
> > 1. select signal using the MUX
> > 2. set the DAC so high that INPUT is never reaching that level.
> >C (and thus gpio) is now stable
> > 3. start waiting for interrupts on gpio
> > 4. adjust the DAC level to the level of interest
> > 5. abort on interrupt or timeout
> (...)
> > With the isr patches, the above transforms into:
> >
> > 1. select signal using the MUX
> > 2. set the DAC so high that INPUT is never reaching that level.
> >C (and thus gpio) is now stable
> > 3. read the isr bit to clear it
> > 4. adjust the DAC level to the level of interest
> > 5. read the isr bit again after 50ms
> >
> > The result is available directly in the isr bit, no interrupts needed.
> 
> The problem I see here as kernel developer is that there is a fuzzy
> and implicit separation of concerns between userspace and
> kernelspace.
> 
> IMO reading hardware registers is the domain of the kernel, and
> then the result thereof is presented to userspace. The kernel
> handles hardware, simply.
> 
> I think we need to reverse out of this solution and instead ask
> the question what the kernel should provide your userspace.
> Maybe parts of what you have in userspace needs to actually
> go into the kernel?
> 
> The goal of IIO seems to be to present raw and calibrated
> (SI unit) data to userspace. So what data is it you want, and
> why can't you just get that directly from the kernel without
> tricksing around with reading registers bits in userspace?

This all makes sense. The reason is that I'm not familiar with
the kernel APIs. I have to wrap my head around how to set up
work to be performed later, etc etc. All of that is in all
likelihood pretty straightforward, but I feel that I am
flundering around every step of the way. End result; I find
myself trying to do as little as possible inside the kernel.

I.e. I have a pretty clear picture of what needs to be done, but
the devil is in the details...

> If a kernel module needs to read an interrupt bit directly from the
> GPIO controller is another thing. That is akin to how polling
> network drivers start polling registers for incoming packages
> instead of waiting for them to fire interrupts. Just that these are
> dedicated IRQ lines, not GPIOs.

Yes, there was also the NACK to adding new gpio sysfs files which
emphasizes this.

> As struct irq_chip has irq_get_irqchip_state() I think this
> is actually possible to achieve this by implementing that
> and calling irq_get_irqchip_state().

I'll have a peek into that, but see below.

> > I have realized that I could work with one-shot-interrupts. Then the
> > urgency to disable interrupts go away, as only one interrupt would
> > be served. That was not my immediate solution though, as I have been
> > using isr type registers in this way several times before.
> 
> That sounds like the right solution. With ONESHOT a threaded IRQ
> will have its line masked until you return from the ISR thread. Would this
> work for your usecase?

The ISR thread would need to be able to disable further interrupts
before it returned, is that possible without deadlock? If so, it's
a good fit.

> I suspect this require you to move the logic into the kernel? Into IIO?

Yes, and yes IIO seems about right to me too.

> > If this is to be done in IIO, I imagine that the sanest thing would
> > be to integrate the whole DAC-loop and present a finished envelope
> > value to user space? This envelope detector would have to be pretty
> > configurable, or it will be next to useless to anybody but me.
> 
> Makes sense to me, but must be ACKed by Jonathan. But it
> sounds pretty cool does it not?

Right, but I don't see why it should be a problem? An envelope detector
surely fits IIO.

> > I could imaging that this new IIO driver should be able to work
> > with any DAC type device, which in my case would be the mcp4531
> > dpot. Which is not a DAC, maybe that could be solved with a new
> > dac-dpot driver, applicable to cases where a dpot is wired as a
> > simple voltage divider? The new IIO driver also needs to know how
> > to get a reading from the comparator. I think the driver should
> > support having a latch between the comparator and the gpio, so it
> > need to know how to optionally "reset the comparator". That
> > would have solved the whole problem, you would never have seen
> > any of this if I had such a latch on my board. But the isr
> > register is a latch, so...
> >
> > Regardless, I think such a driver still needs support from gpio
> > and/or pinctrl. Either exposing the isr register or supporting
> > one-shot-interrupts that disarm themselves before restoring the
> > processor interrupt flag (maybe that exists?).
> 
> All irqchips support 

RE: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Peter Rosin]

Hi Linus,

> On Mon, Dec 14, 2015 at 11:38 AM, Peter Rosin  wrote:
> 
> I think I atleast half-understand what you're trying to do.

Good. It's really not that complicated, but I'm perhaps not describing
it very clearly...

> > Userspace does the following when doing this w/o the isr patches:
> >
> > 1. select signal using the MUX
> > 2. set the DAC so high that INPUT is never reaching that level.
> >C (and thus gpio) is now stable
> > 3. start waiting for interrupts on gpio
> > 4. adjust the DAC level to the level of interest
> > 5. abort on interrupt or timeout
> (...)
> > With the isr patches, the above transforms into:
> >
> > 1. select signal using the MUX
> > 2. set the DAC so high that INPUT is never reaching that level.
> >C (and thus gpio) is now stable
> > 3. read the isr bit to clear it
> > 4. adjust the DAC level to the level of interest
> > 5. read the isr bit again after 50ms
> >
> > The result is available directly in the isr bit, no interrupts needed.
> 
> The problem I see here as kernel developer is that there is a fuzzy
> and implicit separation of concerns between userspace and
> kernelspace.
> 
> IMO reading hardware registers is the domain of the kernel, and
> then the result thereof is presented to userspace. The kernel
> handles hardware, simply.
> 
> I think we need to reverse out of this solution and instead ask
> the question what the kernel should provide your userspace.
> Maybe parts of what you have in userspace needs to actually
> go into the kernel?
> 
> The goal of IIO seems to be to present raw and calibrated
> (SI unit) data to userspace. So what data is it you want, and
> why can't you just get that directly from the kernel without
> tricksing around with reading registers bits in userspace?

This all makes sense. The reason is that I'm not familiar with
the kernel APIs. I have to wrap my head around how to set up
work to be performed later, etc etc. All of that is in all
likelihood pretty straightforward, but I feel that I am
flundering around every step of the way. End result; I find
myself trying to do as little as possible inside the kernel.

I.e. I have a pretty clear picture of what needs to be done, but
the devil is in the details...

> If a kernel module needs to read an interrupt bit directly from the
> GPIO controller is another thing. That is akin to how polling
> network drivers start polling registers for incoming packages
> instead of waiting for them to fire interrupts. Just that these are
> dedicated IRQ lines, not GPIOs.

Yes, there was also the NACK to adding new gpio sysfs files which
emphasizes this.

> As struct irq_chip has irq_get_irqchip_state() I think this
> is actually possible to achieve this by implementing that
> and calling irq_get_irqchip_state().

I'll have a peek into that, but see below.

> > I have realized that I could work with one-shot-interrupts. Then the
> > urgency to disable interrupts go away, as only one interrupt would
> > be served. That was not my immediate solution though, as I have been
> > using isr type registers in this way several times before.
> 
> That sounds like the right solution. With ONESHOT a threaded IRQ
> will have its line masked until you return from the ISR thread. Would this
> work for your usecase?

The ISR thread would need to be able to disable further interrupts
before it returned, is that possible without deadlock? If so, it's
a good fit.

> I suspect this require you to move the logic into the kernel? Into IIO?

Yes, and yes IIO seems about right to me too.

> > If this is to be done in IIO, I imagine that the sanest thing would
> > be to integrate the whole DAC-loop and present a finished envelope
> > value to user space? This envelope detector would have to be pretty
> > configurable, or it will be next to useless to anybody but me.
> 
> Makes sense to me, but must be ACKed by Jonathan. But it
> sounds pretty cool does it not?

Right, but I don't see why it should be a problem? An envelope detector
surely fits IIO.

> > I could imaging that this new IIO driver should be able to work
> > with any DAC type device, which in my case would be the mcp4531
> > dpot. Which is not a DAC, maybe that could be solved with a new
> > dac-dpot driver, applicable to cases where a dpot is wired as a
> > simple voltage divider? The new IIO driver also needs to know how
> > to get a reading from the comparator. I think the driver should
> > support having a latch between the comparator and the gpio, so it
> > need to know how to optionally "reset the comparator". That
> > would have solved the whole problem, you would never have seen
> > any of this if I had such a latch on my board. But the isr
> > register is a latch, so...
> >
> > Regardless, I think such a driver still needs support from gpio
> > and/or pinctrl. Either exposing the isr register or supporting
> > one-shot-interrupts that disarm themselves before restoring the
> > processor interrupt flag (maybe that exists?).
> 
> All 

Re: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Linus Walleij]

Hi Peter,

On Mon, Dec 14, 2015 at 11:38 AM, Peter Rosin  wrote:

I think I atleast half-understand what you're trying to do.

> Userspace does the following when doing this w/o the isr patches:
>
> 1. select signal using the MUX
> 2. set the DAC so high that INPUT is never reaching that level.
>C (and thus gpio) is now stable
> 3. start waiting for interrupts on gpio
> 4. adjust the DAC level to the level of interest
> 5. abort on interrupt or timeout
(...)
> With the isr patches, the above transforms into:
>
> 1. select signal using the MUX
> 2. set the DAC so high that INPUT is never reaching that level.
>C (and thus gpio) is now stable
> 3. read the isr bit to clear it
> 4. adjust the DAC level to the level of interest
> 5. read the isr bit again after 50ms
>
> The result is available directly in the isr bit, no interrupts needed.

The problem I see here as kernel developer is that there is a fuzzy
and implicit separation of concerns between userspace and
kernelspace.

IMO reading hardware registers is the domain of the kernel, and
then the result thereof is presented to userspace. The kernel
handles hardware, simply.

I think we need to reverse out of this solution and instead ask
the question what the kernel should provide your userspace.
Maybe parts of what you have in userspace needs to actually
go into the kernel?

The goal of IIO seems to be to present raw and calibrated
(SI unit) data to userspace. So what data is it you want, and
why can't you just get that directly from the kernel without
tricksing around with reading registers bits in userspace?

If a kernel module needs to read an interrupt bit directly from the
GPIO controller is another thing. That is akin to how polling
network drivers start polling registers for incoming packages
instead of waiting for them to fire interrupts. Just that these are
dedicated IRQ lines, not GPIOs.

As struct irq_chip has irq_get_irqchip_state() I think this
is actually possible to achieve this by implementing that
and calling irq_get_irqchip_state().

> I have realized that I could work with one-shot-interrupts. Then the
> urgency to disable interrupts go away, as only one interrupt would
> be served. That was not my immediate solution though, as I have been
> using isr type registers in this way several times before.

That sounds like the right solution. With ONESHOT a threaded IRQ
will have its line masked until you return from the ISR thread. Would this
work for your usecase?

I suspect this require you to move the logic into the kernel? Into IIO?

> If this is to be done in IIO, I imagine that the sanest thing would
> be to integrate the whole DAC-loop and present a finished envelope
> value to user space? This envelope detector would have to be pretty
> configurable, or it will be next to useless to anybody but me.

Makes sense to me, but must be ACKed by Jonathan. But it
sounds pretty cool does it not?

> I could imaging that this new IIO driver should be able to work
> with any DAC type device, which in my case would be the mcp4531
> dpot. Which is not a DAC, maybe that could be solved with a new
> dac-dpot driver, applicable to cases where a dpot is wired as a
> simple voltage divider? The new IIO driver also needs to know how
> to get a reading from the comparator. I think the driver should
> support having a latch between the comparator and the gpio, so it
> need to know how to optionally "reset the comparator". That
> would have solved the whole problem, you would never have seen
> any of this if I had such a latch on my board. But the isr
> register is a latch, so...
>
> Regardless, I think such a driver still needs support from gpio
> and/or pinctrl. Either exposing the isr register or supporting
> one-shot-interrupts that disarm themselves before restoring the
> processor interrupt flag (maybe that exists?).

All irqchips support one-shot interrupts as long as you request a
threaded IRQ I think.

Your GPIO driver must support IRQs though but AT91 surely does.
Maybe you will need to implement irq_get_irqchip_state() on it
if you insist on polling the interrupt.

> Otherwise the
> core problem remains unsolved. Also, this imaginary IIO driver
> probably have to be totally oblivious of the MUX, or the number
> of possibilities explode.

Usually we try to follow the UNIX philisophy to do one thing
and do it good.

You haven't said much about how that MUX works, if it's another
userspace ThingOfABob or what it is. There is no generic
kernel framework for muxes so I see why people would want to
drive that using userspace GPIO lines for example.

If it is pinmuxing in a standard chip of some kind, pinctrl
handles it.

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

Re: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Linus Walleij]

Hi Peter,

On Mon, Dec 14, 2015 at 11:38 AM, Peter Rosin  wrote:

I think I atleast half-understand what you're trying to do.

> Userspace does the following when doing this w/o the isr patches:
>
> 1. select signal using the MUX
> 2. set the DAC so high that INPUT is never reaching that level.
>C (and thus gpio) is now stable
> 3. start waiting for interrupts on gpio
> 4. adjust the DAC level to the level of interest
> 5. abort on interrupt or timeout
(...)
> With the isr patches, the above transforms into:
>
> 1. select signal using the MUX
> 2. set the DAC so high that INPUT is never reaching that level.
>C (and thus gpio) is now stable
> 3. read the isr bit to clear it
> 4. adjust the DAC level to the level of interest
> 5. read the isr bit again after 50ms
>
> The result is available directly in the isr bit, no interrupts needed.

The problem I see here as kernel developer is that there is a fuzzy
and implicit separation of concerns between userspace and
kernelspace.

IMO reading hardware registers is the domain of the kernel, and
then the result thereof is presented to userspace. The kernel
handles hardware, simply.

I think we need to reverse out of this solution and instead ask
the question what the kernel should provide your userspace.
Maybe parts of what you have in userspace needs to actually
go into the kernel?

The goal of IIO seems to be to present raw and calibrated
(SI unit) data to userspace. So what data is it you want, and
why can't you just get that directly from the kernel without
tricksing around with reading registers bits in userspace?

If a kernel module needs to read an interrupt bit directly from the
GPIO controller is another thing. That is akin to how polling
network drivers start polling registers for incoming packages
instead of waiting for them to fire interrupts. Just that these are
dedicated IRQ lines, not GPIOs.

As struct irq_chip has irq_get_irqchip_state() I think this
is actually possible to achieve this by implementing that
and calling irq_get_irqchip_state().

> I have realized that I could work with one-shot-interrupts. Then the
> urgency to disable interrupts go away, as only one interrupt would
> be served. That was not my immediate solution though, as I have been
> using isr type registers in this way several times before.

That sounds like the right solution. With ONESHOT a threaded IRQ
will have its line masked until you return from the ISR thread. Would this
work for your usecase?

I suspect this require you to move the logic into the kernel? Into IIO?

> If this is to be done in IIO, I imagine that the sanest thing would
> be to integrate the whole DAC-loop and present a finished envelope
> value to user space? This envelope detector would have to be pretty
> configurable, or it will be next to useless to anybody but me.

Makes sense to me, but must be ACKed by Jonathan. But it
sounds pretty cool does it not?

> I could imaging that this new IIO driver should be able to work
> with any DAC type device, which in my case would be the mcp4531
> dpot. Which is not a DAC, maybe that could be solved with a new
> dac-dpot driver, applicable to cases where a dpot is wired as a
> simple voltage divider? The new IIO driver also needs to know how
> to get a reading from the comparator. I think the driver should
> support having a latch between the comparator and the gpio, so it
> need to know how to optionally "reset the comparator". That
> would have solved the whole problem, you would never have seen
> any of this if I had such a latch on my board. But the isr
> register is a latch, so...
>
> Regardless, I think such a driver still needs support from gpio
> and/or pinctrl. Either exposing the isr register or supporting
> one-shot-interrupts that disarm themselves before restoring the
> processor interrupt flag (maybe that exists?).

All irqchips support one-shot interrupts as long as you request a
threaded IRQ I think.

Your GPIO driver must support IRQs though but AT91 surely does.
Maybe you will need to implement irq_get_irqchip_state() on it
if you insist on polling the interrupt.

> Otherwise the
> core problem remains unsolved. Also, this imaginary IIO driver
> probably have to be totally oblivious of the MUX, or the number
> of possibilities explode.

Usually we try to follow the UNIX philisophy to do one thing
and do it good.

You haven't said much about how that MUX works, if it's another
userspace ThingOfABob or what it is. There is no generic
kernel framework for muxes so I see why people would want to
drive that using userspace GPIO lines for example.

If it is pinmuxing in a standard chip of some kind, pinctrl
handles it.

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

RE: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Peter Rosin]

Jonathan Cameron [mailto:ji...@kernel.org] wrote:
> On 11/12/15 12:53, Linus Walleij wrote:
> > Quoting extensively since I'm involving the linux-iio mailinglist.
> > 
> > The use case you describe is hand-in-glove with Industrial I/O.
> > I think you want a trigger interface from IIO and read events from
> > userspace using the IIO character device.
> > 
> > Look at the userspace examples in tools/iio for how it's used
> > in userspace, the subsystem is in drivers/iio. I suspect
> > drivers/iio/adc/polled-gpio.c or something is where you actually
> > want to go with this. The module should do all the fastpath
> > work and then expose what you actually want to know to
> > userspace using the IIO triggers or events.
> > 
> > I have used IIO myself, it is really neat for this kind of usecase,
> > and designed right from the ground up.
> > 
> > I think you whould think about how to write the right kind of
> > driver for IIO to do what you want.
> Peter has a spot of IIO experience as well :)

Right, the "DAC" I'm using to control the input level on the comparator
is actually my IIO mcp4531 potentiometer driver. But I have only
rudimentary IIO knowledge; that driver is trivial.

> I'm not sure I entirely understand what the data flows are here so I may
> get this completely wrong!
> 
> Sounds like a quick, dirty and simple 'capture unit' like you'd find on a PLC 
> to
> me (be bit one that doesn't grab much data - I use these all the time at
> work to catch the output from beam break sensor on automated systems and
> stuff like that).  Timers often support a copy to register on a gpio
> signal but I'm not sure I've ever seen that supported in kernel either
> (some discussion about doing this in IIO occurred a while ago but I don't
> think anything ever came of it unfortunately). It was for the TI ECAP devices
> by Matt Porter (cc'd)  Not that closely related but perhaps Matt will
> have some insight here.
> 
> So:
> 
> Are we looking to synchronised control of the DAC
> feeding the comparator or is that entirely autonomous?
> (for now I'll assume autonomous - it gets interesting if
>  not - we'd need the buffered output stuff Lars has for that)
> 
> How fast are we talking?
> 
> So I think we are basically looking for fast sampling of the gpio with 
> latching.
> 
> I suspect the rates are high enough that an IIO trigger is going to be too 
> expensive
> (as it effectively runs as an irq).  That's fine though as they are optional 
> if
> you have a good reason not to use them and a direct polling of the isr and 
> filling a
> buffer might work.
> 
> We don't currently have 1 bit channel support in IIO and in this particular 
> case
> our normal buffers are going to be very inefficient as they are kfifo based
> and hence will burn 1 byte per sample if we do this the simple way.
> The closest we have gotten to a 1 bit support was a comparator driver and
> in the end the author decided to support that via events which have way higher
> overhead than I think you want.
> 
> So if IIO is the sensible way to support this I think we need something like
> the following:
> 
> 1) 1 bit data type support in IIO - not too bad to add, though will need
>to have some restrictions in the demux as arbitary bit channel recombining
>would be horrible and costly.  So in the first instance we'd probably burn 
> 1 byte
>per 1 bit channel each sample - address this later perhaps.  If burning
>a byte, just specify that you have a channel with realbits = 1, 
> storagebits = 8
>and it should all work.  I'd like to add 1 bit support fully if you are
>interested though!
> 
> 2) A driver that can effectively check and clear the interrupt register and
>push that to the kfifo.  Probably running a kthread to keep the overhead
>low - something like the recent INA2XX driver is doing (though for a rather
>different reason).  That would then shove data into the buffer at regular
>intervals.
> 
> 3) Normal userspace code would then read this - ideally with updates to
>correctly interpret it as boolean data.
> 
> Doesn't sound too bad - just a question of whether it will be lightweight
> enough for your use case.
> 
> Assuming I have understood even vaguely what you are doing ;)
>  
> Sounds fun.

Hmm, I've been reading the responses from you and Linus a couple of
times, and I think you have misunderstood? You talk about triggers,
fastpath, high rates and whatnot. That is not what I need and not my
itch at all! I'm not looking at getting a continuous stream of envelope
values, I only need to check the envelope value every 5 seconds or
so. Also, the whole thing is complicated by the envelope detector
being multiplexed, so that the one envelope detector can be used
for a handful of signals.

The simplified schematics are:

 ---
 -> | I1|  ---  ---
 -> | I2  O | -> INPUT -> | A ||   |
 -> | I3| | C | -> | gpio  |
 -> | I4|  DAC -> | 

RE: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Peter Rosin]

Jonathan Cameron [mailto:ji...@kernel.org] wrote:
> On 11/12/15 12:53, Linus Walleij wrote:
> > Quoting extensively since I'm involving the linux-iio mailinglist.
> > 
> > The use case you describe is hand-in-glove with Industrial I/O.
> > I think you want a trigger interface from IIO and read events from
> > userspace using the IIO character device.
> > 
> > Look at the userspace examples in tools/iio for how it's used
> > in userspace, the subsystem is in drivers/iio. I suspect
> > drivers/iio/adc/polled-gpio.c or something is where you actually
> > want to go with this. The module should do all the fastpath
> > work and then expose what you actually want to know to
> > userspace using the IIO triggers or events.
> > 
> > I have used IIO myself, it is really neat for this kind of usecase,
> > and designed right from the ground up.
> > 
> > I think you whould think about how to write the right kind of
> > driver for IIO to do what you want.
> Peter has a spot of IIO experience as well :)

Right, the "DAC" I'm using to control the input level on the comparator
is actually my IIO mcp4531 potentiometer driver. But I have only
rudimentary IIO knowledge; that driver is trivial.

> I'm not sure I entirely understand what the data flows are here so I may
> get this completely wrong!
> 
> Sounds like a quick, dirty and simple 'capture unit' like you'd find on a PLC 
> to
> me (be bit one that doesn't grab much data - I use these all the time at
> work to catch the output from beam break sensor on automated systems and
> stuff like that).  Timers often support a copy to register on a gpio
> signal but I'm not sure I've ever seen that supported in kernel either
> (some discussion about doing this in IIO occurred a while ago but I don't
> think anything ever came of it unfortunately). It was for the TI ECAP devices
> by Matt Porter (cc'd)  Not that closely related but perhaps Matt will
> have some insight here.
> 
> So:
> 
> Are we looking to synchronised control of the DAC
> feeding the comparator or is that entirely autonomous?
> (for now I'll assume autonomous - it gets interesting if
>  not - we'd need the buffered output stuff Lars has for that)
> 
> How fast are we talking?
> 
> So I think we are basically looking for fast sampling of the gpio with 
> latching.
> 
> I suspect the rates are high enough that an IIO trigger is going to be too 
> expensive
> (as it effectively runs as an irq).  That's fine though as they are optional 
> if
> you have a good reason not to use them and a direct polling of the isr and 
> filling a
> buffer might work.
> 
> We don't currently have 1 bit channel support in IIO and in this particular 
> case
> our normal buffers are going to be very inefficient as they are kfifo based
> and hence will burn 1 byte per sample if we do this the simple way.
> The closest we have gotten to a 1 bit support was a comparator driver and
> in the end the author decided to support that via events which have way higher
> overhead than I think you want.
> 
> So if IIO is the sensible way to support this I think we need something like
> the following:
> 
> 1) 1 bit data type support in IIO - not too bad to add, though will need
>to have some restrictions in the demux as arbitary bit channel recombining
>would be horrible and costly.  So in the first instance we'd probably burn 
> 1 byte
>per 1 bit channel each sample - address this later perhaps.  If burning
>a byte, just specify that you have a channel with realbits = 1, 
> storagebits = 8
>and it should all work.  I'd like to add 1 bit support fully if you are
>interested though!
> 
> 2) A driver that can effectively check and clear the interrupt register and
>push that to the kfifo.  Probably running a kthread to keep the overhead
>low - something like the recent INA2XX driver is doing (though for a rather
>different reason).  That would then shove data into the buffer at regular
>intervals.
> 
> 3) Normal userspace code would then read this - ideally with updates to
>correctly interpret it as boolean data.
> 
> Doesn't sound too bad - just a question of whether it will be lightweight
> enough for your use case.
> 
> Assuming I have understood even vaguely what you are doing ;)
>  
> Sounds fun.

Hmm, I've been reading the responses from you and Linus a couple of
times, and I think you have misunderstood? You talk about triggers,
fastpath, high rates and whatnot. That is not what I need and not my
itch at all! I'm not looking at getting a continuous stream of envelope
values, I only need to check the envelope value every 5 seconds or
so. Also, the whole thing is complicated by the envelope detector
being multiplexed, so that the one envelope detector can be used
for a handful of signals.

The simplified schematics are:

 ---
 -> | I1|  ---  ---
 -> | I2  O | -> INPUT -> | A ||   |
 -> | I3| | C | -> | gpio  |
 -> | I4|  DAC -> | 

Re: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Jonathan Cameron]

My address for Matt was out of date..
Here's hoping there is only one Matt Porter writing IIO drivers and
trying a more recent email address.

On 12/12/15 18:02, Jonathan Cameron wrote:
> On 11/12/15 12:53, Linus Walleij wrote:
>> Quoting extensively since I'm involving the linux-iio mailinglist.
>>
>> The use case you describe is hand-in-glove with Industrial I/O.
>> I think you want a trigger interface from IIO and read events from
>> userspace using the IIO character device.
>>
>> Look at the userspace examples in tools/iio for how it's used
>> in userspace, the subsystem is in drivers/iio. I suspect
>> drivers/iio/adc/polled-gpio.c or something is where you actually
>> want to go with this. The module should do all the fastpath
>> work and then expose what you actually want to know to
>> userspace using the IIO triggers or events.
>>
>> I have used IIO myself, it is really neat for this kind of usecase,
>> and designed right from the ground up.
>>
>> I think you whould think about how to write the right kind of
>> driver for IIO to do what you want.
> Peter has a spot of IIO experience as well :)
> 
> I'm not sure I entirely understand what the data flows are here so I may
> get this completely wrong!
> 
> Sounds like a quick, dirty and simple 'capture unit' like you'd find on a PLC 
> to
> me (be bit one that doesn't grab much data - I use these all the time at
> work to catch the output from beam break sensor on automated systems and
> stuff like that).  Timers often support a copy to register on a gpio
> signal but I'm not sure I've ever seen that supported in kernel either
> (some discussion about doing this in IIO occurred a while ago but I don't
> think anything ever came of it unfortunately). It was for the TI ECAP devices
> by Matt Porter (cc'd)  Not that closely related but perhaps Matt will
> have some insight here.
> 
> So:
> 
> Are we looking to synchronised control of the DAC
> feeding the comparator or is that entirely autonomous?
> (for now I'll assume autonomous - it gets interesting if
>  not - we'd need the buffered output stuff Lars has for that)
> 
> How fast are we talking?
> 
> So I think we are basically looking for fast sampling of the gpio with 
> latching.
> 
> I suspect the rates are high enough that an IIO trigger is going to be too 
> expensive
> (as it effectively runs as an irq).  That's fine though as they are optional 
> if
> you have a good reason not to use them and a direct polling of the isr and 
> filling a
> buffer might work.
> 
> We don't currently have 1 bit channel support in IIO and in this particular 
> case
> our normal buffers are going to be very inefficient as they are kfifo based
> and hence will burn 1 byte per sample if we do this the simple way.
> The closest we have gotten to a 1 bit support was a comparator driver and
> in the end the author decided to support that via events which have way higher
> overhead than I think you want.
> 
> So if IIO is the sensible way to support this I think we need something like
> the following:
> 
> 1) 1 bit data type support in IIO - not too bad to add, though will need
>to have some restrictions in the demux as arbitary bit channel recombining
>would be horrible and costly.  So in the first instance we'd probably burn 
> 1 byte
>per 1 bit channel each sample - address this later perhaps.  If burning
>a byte, just specify that you have a channel with realbits = 1, 
> storagebits = 8
>and it should all work.  I'd like to add 1 bit support fully if you are
>interested though!
> 
> 2) A driver that can effectively check and clear the interrupt register and
>push that to the kfifo.  Probably running a kthread to keep the overhead
>low - something like the recent INA2XX driver is doing (though for a rather
>different reason).  That would then shove data into the buffer at regular
>intervals.
> 
> 3) Normal userspace code would then read this - ideally with updates to
>correctly interpret it as boolean data.
> 
> Doesn't sound too bad - just a question of whether it will be lightweight
> enough for your use case.
> 
> Assuming I have understood even vaguely what you are doing ;)
>  
> Sounds fun.
> 
> Jonathan
>>
>> Yours,
>> Linus Walleij
>>
>> On Tue, Dec 8, 2015 at 4:20 AM, Peter Rosin  wrote:
>>> From: Peter Rosin 
>>>
>>> Hi!
>>>
>>> I have a signal connected to a gpio pin which is the output of
>>> a comparator. By changing the level of one of the inputs to the
>>> comparator, I can detect the envelope of the other input to
>>> the comparator by using a series of measurements much in the
>>> same maner a manual ADC works, but watching for changes on the
>>> comparator over a period of time instead of only the immediate
>>> output.
>>>
>>> Now, the input signal to the comparator might have a high frequency,
>>> which will cause the output from the comparator (and thus the GPIO
>>> input) to change rapidly.
>>>
>>> A common(?) idiom for this is to use the interrupt status 

Re: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Jonathan Cameron]

On 11/12/15 12:53, Linus Walleij wrote:
> Quoting extensively since I'm involving the linux-iio mailinglist.
> 
> The use case you describe is hand-in-glove with Industrial I/O.
> I think you want a trigger interface from IIO and read events from
> userspace using the IIO character device.
> 
> Look at the userspace examples in tools/iio for how it's used
> in userspace, the subsystem is in drivers/iio. I suspect
> drivers/iio/adc/polled-gpio.c or something is where you actually
> want to go with this. The module should do all the fastpath
> work and then expose what you actually want to know to
> userspace using the IIO triggers or events.
> 
> I have used IIO myself, it is really neat for this kind of usecase,
> and designed right from the ground up.
> 
> I think you whould think about how to write the right kind of
> driver for IIO to do what you want.
Peter has a spot of IIO experience as well :)

I'm not sure I entirely understand what the data flows are here so I may
get this completely wrong!

Sounds like a quick, dirty and simple 'capture unit' like you'd find on a PLC to
me (be bit one that doesn't grab much data - I use these all the time at
work to catch the output from beam break sensor on automated systems and
stuff like that).  Timers often support a copy to register on a gpio
signal but I'm not sure I've ever seen that supported in kernel either
(some discussion about doing this in IIO occurred a while ago but I don't
think anything ever came of it unfortunately). It was for the TI ECAP devices
by Matt Porter (cc'd)  Not that closely related but perhaps Matt will
have some insight here.

So:

Are we looking to synchronised control of the DAC
feeding the comparator or is that entirely autonomous?
(for now I'll assume autonomous - it gets interesting if
 not - we'd need the buffered output stuff Lars has for that)

How fast are we talking?

So I think we are basically looking for fast sampling of the gpio with latching.

I suspect the rates are high enough that an IIO trigger is going to be too 
expensive
(as it effectively runs as an irq).  That's fine though as they are optional if
you have a good reason not to use them and a direct polling of the isr and 
filling a
buffer might work.

We don't currently have 1 bit channel support in IIO and in this particular case
our normal buffers are going to be very inefficient as they are kfifo based
and hence will burn 1 byte per sample if we do this the simple way.
The closest we have gotten to a 1 bit support was a comparator driver and
in the end the author decided to support that via events which have way higher
overhead than I think you want.

So if IIO is the sensible way to support this I think we need something like
the following:

1) 1 bit data type support in IIO - not too bad to add, though will need
   to have some restrictions in the demux as arbitary bit channel recombining
   would be horrible and costly.  So in the first instance we'd probably burn 1 
byte
   per 1 bit channel each sample - address this later perhaps.  If burning
   a byte, just specify that you have a channel with realbits = 1, storagebits 
= 8
   and it should all work.  I'd like to add 1 bit support fully if you are
   interested though!

2) A driver that can effectively check and clear the interrupt register and
   push that to the kfifo.  Probably running a kthread to keep the overhead
   low - something like the recent INA2XX driver is doing (though for a rather
   different reason).  That would then shove data into the buffer at regular
   intervals.

3) Normal userspace code would then read this - ideally with updates to
   correctly interpret it as boolean data.

Doesn't sound too bad - just a question of whether it will be lightweight
enough for your use case.

Assuming I have understood even vaguely what you are doing ;)
 
Sounds fun.

Jonathan
> 
> Yours,
> Linus Walleij
> 
> On Tue, Dec 8, 2015 at 4:20 AM, Peter Rosin  wrote:
>> From: Peter Rosin 
>>
>> Hi!
>>
>> I have a signal connected to a gpio pin which is the output of
>> a comparator. By changing the level of one of the inputs to the
>> comparator, I can detect the envelope of the other input to
>> the comparator by using a series of measurements much in the
>> same maner a manual ADC works, but watching for changes on the
>> comparator over a period of time instead of only the immediate
>> output.
>>
>> Now, the input signal to the comparator might have a high frequency,
>> which will cause the output from the comparator (and thus the GPIO
>> input) to change rapidly.
>>
>> A common(?) idiom for this is to use the interrupt status register
>> to catch the glitches, but then not have any interrupt tied to
>> the pin as that could possibly generate pointless bursts of
>> (expensive) interrupts.
>>
>> So, these two patches expose an interface to the PIO_ISR register
>> of the pio controllers on the platform I'm targetting. The first
>> patch adds some infrastructure to the gpio core and the second
>> 

Re: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Jonathan Cameron]

My address for Matt was out of date..
Here's hoping there is only one Matt Porter writing IIO drivers and
trying a more recent email address.

On 12/12/15 18:02, Jonathan Cameron wrote:
> On 11/12/15 12:53, Linus Walleij wrote:
>> Quoting extensively since I'm involving the linux-iio mailinglist.
>>
>> The use case you describe is hand-in-glove with Industrial I/O.
>> I think you want a trigger interface from IIO and read events from
>> userspace using the IIO character device.
>>
>> Look at the userspace examples in tools/iio for how it's used
>> in userspace, the subsystem is in drivers/iio. I suspect
>> drivers/iio/adc/polled-gpio.c or something is where you actually
>> want to go with this. The module should do all the fastpath
>> work and then expose what you actually want to know to
>> userspace using the IIO triggers or events.
>>
>> I have used IIO myself, it is really neat for this kind of usecase,
>> and designed right from the ground up.
>>
>> I think you whould think about how to write the right kind of
>> driver for IIO to do what you want.
> Peter has a spot of IIO experience as well :)
> 
> I'm not sure I entirely understand what the data flows are here so I may
> get this completely wrong!
> 
> Sounds like a quick, dirty and simple 'capture unit' like you'd find on a PLC 
> to
> me (be bit one that doesn't grab much data - I use these all the time at
> work to catch the output from beam break sensor on automated systems and
> stuff like that).  Timers often support a copy to register on a gpio
> signal but I'm not sure I've ever seen that supported in kernel either
> (some discussion about doing this in IIO occurred a while ago but I don't
> think anything ever came of it unfortunately). It was for the TI ECAP devices
> by Matt Porter (cc'd)  Not that closely related but perhaps Matt will
> have some insight here.
> 
> So:
> 
> Are we looking to synchronised control of the DAC
> feeding the comparator or is that entirely autonomous?
> (for now I'll assume autonomous - it gets interesting if
>  not - we'd need the buffered output stuff Lars has for that)
> 
> How fast are we talking?
> 
> So I think we are basically looking for fast sampling of the gpio with 
> latching.
> 
> I suspect the rates are high enough that an IIO trigger is going to be too 
> expensive
> (as it effectively runs as an irq).  That's fine though as they are optional 
> if
> you have a good reason not to use them and a direct polling of the isr and 
> filling a
> buffer might work.
> 
> We don't currently have 1 bit channel support in IIO and in this particular 
> case
> our normal buffers are going to be very inefficient as they are kfifo based
> and hence will burn 1 byte per sample if we do this the simple way.
> The closest we have gotten to a 1 bit support was a comparator driver and
> in the end the author decided to support that via events which have way higher
> overhead than I think you want.
> 
> So if IIO is the sensible way to support this I think we need something like
> the following:
> 
> 1) 1 bit data type support in IIO - not too bad to add, though will need
>to have some restrictions in the demux as arbitary bit channel recombining
>would be horrible and costly.  So in the first instance we'd probably burn 
> 1 byte
>per 1 bit channel each sample - address this later perhaps.  If burning
>a byte, just specify that you have a channel with realbits = 1, 
> storagebits = 8
>and it should all work.  I'd like to add 1 bit support fully if you are
>interested though!
> 
> 2) A driver that can effectively check and clear the interrupt register and
>push that to the kfifo.  Probably running a kthread to keep the overhead
>low - something like the recent INA2XX driver is doing (though for a rather
>different reason).  That would then shove data into the buffer at regular
>intervals.
> 
> 3) Normal userspace code would then read this - ideally with updates to
>correctly interpret it as boolean data.
> 
> Doesn't sound too bad - just a question of whether it will be lightweight
> enough for your use case.
> 
> Assuming I have understood even vaguely what you are doing ;)
>  
> Sounds fun.
> 
> Jonathan
>>
>> Yours,
>> Linus Walleij
>>
>> On Tue, Dec 8, 2015 at 4:20 AM, Peter Rosin  wrote:
>>> From: Peter Rosin 
>>>
>>> Hi!
>>>
>>> I have a signal connected to a gpio pin which is the output of
>>> a comparator. By changing the level of one of the inputs to the
>>> comparator, I can detect the envelope of the other input to
>>> the comparator by using a series of measurements much in the
>>> same maner a manual ADC works, but watching for changes on the
>>> comparator over a period of time instead of only the immediate
>>> output.
>>>
>>> Now, the input signal to the comparator might have a high frequency,
>>> which will cause the output from the comparator (and thus the GPIO
>>> input) to change rapidly.
>>>
>>> A common(?) idiom 

Re: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Jonathan Cameron]

On 11/12/15 12:53, Linus Walleij wrote:
> Quoting extensively since I'm involving the linux-iio mailinglist.
> 
> The use case you describe is hand-in-glove with Industrial I/O.
> I think you want a trigger interface from IIO and read events from
> userspace using the IIO character device.
> 
> Look at the userspace examples in tools/iio for how it's used
> in userspace, the subsystem is in drivers/iio. I suspect
> drivers/iio/adc/polled-gpio.c or something is where you actually
> want to go with this. The module should do all the fastpath
> work and then expose what you actually want to know to
> userspace using the IIO triggers or events.
> 
> I have used IIO myself, it is really neat for this kind of usecase,
> and designed right from the ground up.
> 
> I think you whould think about how to write the right kind of
> driver for IIO to do what you want.
Peter has a spot of IIO experience as well :)

I'm not sure I entirely understand what the data flows are here so I may
get this completely wrong!

Sounds like a quick, dirty and simple 'capture unit' like you'd find on a PLC to
me (be bit one that doesn't grab much data - I use these all the time at
work to catch the output from beam break sensor on automated systems and
stuff like that).  Timers often support a copy to register on a gpio
signal but I'm not sure I've ever seen that supported in kernel either
(some discussion about doing this in IIO occurred a while ago but I don't
think anything ever came of it unfortunately). It was for the TI ECAP devices
by Matt Porter (cc'd)  Not that closely related but perhaps Matt will
have some insight here.

So:

Are we looking to synchronised control of the DAC
feeding the comparator or is that entirely autonomous?
(for now I'll assume autonomous - it gets interesting if
 not - we'd need the buffered output stuff Lars has for that)

How fast are we talking?

So I think we are basically looking for fast sampling of the gpio with latching.

I suspect the rates are high enough that an IIO trigger is going to be too 
expensive
(as it effectively runs as an irq).  That's fine though as they are optional if
you have a good reason not to use them and a direct polling of the isr and 
filling a
buffer might work.

We don't currently have 1 bit channel support in IIO and in this particular case
our normal buffers are going to be very inefficient as they are kfifo based
and hence will burn 1 byte per sample if we do this the simple way.
The closest we have gotten to a 1 bit support was a comparator driver and
in the end the author decided to support that via events which have way higher
overhead than I think you want.

So if IIO is the sensible way to support this I think we need something like
the following:

1) 1 bit data type support in IIO - not too bad to add, though will need
   to have some restrictions in the demux as arbitary bit channel recombining
   would be horrible and costly.  So in the first instance we'd probably burn 1 
byte
   per 1 bit channel each sample - address this later perhaps.  If burning
   a byte, just specify that you have a channel with realbits = 1, storagebits 
= 8
   and it should all work.  I'd like to add 1 bit support fully if you are
   interested though!

2) A driver that can effectively check and clear the interrupt register and
   push that to the kfifo.  Probably running a kthread to keep the overhead
   low - something like the recent INA2XX driver is doing (though for a rather
   different reason).  That would then shove data into the buffer at regular
   intervals.

3) Normal userspace code would then read this - ideally with updates to
   correctly interpret it as boolean data.

Doesn't sound too bad - just a question of whether it will be lightweight
enough for your use case.

Assuming I have understood even vaguely what you are doing ;)
 
Sounds fun.

Jonathan
> 
> Yours,
> Linus Walleij
> 
> On Tue, Dec 8, 2015 at 4:20 AM, Peter Rosin  wrote:
>> From: Peter Rosin 
>>
>> Hi!
>>
>> I have a signal connected to a gpio pin which is the output of
>> a comparator. By changing the level of one of the inputs to the
>> comparator, I can detect the envelope of the other input to
>> the comparator by using a series of measurements much in the
>> same maner a manual ADC works, but watching for changes on the
>> comparator over a period of time instead of only the immediate
>> output.
>>
>> Now, the input signal to the comparator might have a high frequency,
>> which will cause the output from the comparator (and thus the GPIO
>> input) to change rapidly.
>>
>> A common(?) idiom for this is to use the interrupt status register
>> to catch the glitches, but then not have any interrupt tied to
>> the pin as that could possibly generate pointless bursts of
>> (expensive) interrupts.
>>
>> So, these two patches expose an interface to the PIO_ISR register
>> of the pio controllers on the platform I'm targetting. The first
>> patch adds some 

Re: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Linus Walleij]

Quoting extensively since I'm involving the linux-iio mailinglist.

The use case you describe is hand-in-glove with Industrial I/O.
I think you want a trigger interface from IIO and read events from
userspace using the IIO character device.

Look at the userspace examples in tools/iio for how it's used
in userspace, the subsystem is in drivers/iio. I suspect
drivers/iio/adc/polled-gpio.c or something is where you actually
want to go with this. The module should do all the fastpath
work and then expose what you actually want to know to
userspace using the IIO triggers or events.

I have used IIO myself, it is really neat for this kind of usecase,
and designed right from the ground up.

I think you whould think about how to write the right kind of
driver for IIO to do what you want.

Yours,
Linus Walleij

On Tue, Dec 8, 2015 at 4:20 AM, Peter Rosin  wrote:
> From: Peter Rosin 
>
> Hi!
>
> I have a signal connected to a gpio pin which is the output of
> a comparator. By changing the level of one of the inputs to the
> comparator, I can detect the envelope of the other input to
> the comparator by using a series of measurements much in the
> same maner a manual ADC works, but watching for changes on the
> comparator over a period of time instead of only the immediate
> output.
>
> Now, the input signal to the comparator might have a high frequency,
> which will cause the output from the comparator (and thus the GPIO
> input) to change rapidly.
>
> A common(?) idiom for this is to use the interrupt status register
> to catch the glitches, but then not have any interrupt tied to
> the pin as that could possibly generate pointless bursts of
> (expensive) interrupts.
>
> So, these two patches expose an interface to the PIO_ISR register
> of the pio controllers on the platform I'm targetting. The first
> patch adds some infrastructure to the gpio core and the second
> patch hooks up "my" pin controller.
>
> But hey, this seems like an old problem and I was surprised that
> I had to touch the source to do it. Which makes me wonder what I'm
> missing and what others needing to see short pulses on a pin but not
> needing/wanting interrupts are doing?
>
> Yes, there needs to be a way to select the interrupt edge w/o
> actually arming the interrupt, that is missing. And probably
> other things too, but I didn't want to do more work in case this
> is a dead end for some reason...
>
> Cheers,
> Peter
>
> Peter Rosin (2):
>   gpio: Add isr property of gpio pins
>   pinctrl: at91: expose the isr bit
>
>  Documentation/gpio/sysfs.txt   |   12 ++
>  drivers/gpio/gpiolib-sysfs.c   |   30 
>  drivers/gpio/gpiolib.c |   15 
>  drivers/pinctrl/pinctrl-at91.c |   50 
> 
>  include/linux/gpio/consumer.h  |1 +
>  include/linux/gpio/driver.h|2 ++
>  6 files changed, 106 insertions(+), 4 deletions(-)
>
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Linus Walleij]

Quoting extensively since I'm involving the linux-iio mailinglist.

The use case you describe is hand-in-glove with Industrial I/O.
I think you want a trigger interface from IIO and read events from
userspace using the IIO character device.

Look at the userspace examples in tools/iio for how it's used
in userspace, the subsystem is in drivers/iio. I suspect
drivers/iio/adc/polled-gpio.c or something is where you actually
want to go with this. The module should do all the fastpath
work and then expose what you actually want to know to
userspace using the IIO triggers or events.

I have used IIO myself, it is really neat for this kind of usecase,
and designed right from the ground up.

I think you whould think about how to write the right kind of
driver for IIO to do what you want.

Yours,
Linus Walleij

On Tue, Dec 8, 2015 at 4:20 AM, Peter Rosin  wrote:
> From: Peter Rosin 
>
> Hi!
>
> I have a signal connected to a gpio pin which is the output of
> a comparator. By changing the level of one of the inputs to the
> comparator, I can detect the envelope of the other input to
> the comparator by using a series of measurements much in the
> same maner a manual ADC works, but watching for changes on the
> comparator over a period of time instead of only the immediate
> output.
>
> Now, the input signal to the comparator might have a high frequency,
> which will cause the output from the comparator (and thus the GPIO
> input) to change rapidly.
>
> A common(?) idiom for this is to use the interrupt status register
> to catch the glitches, but then not have any interrupt tied to
> the pin as that could possibly generate pointless bursts of
> (expensive) interrupts.
>
> So, these two patches expose an interface to the PIO_ISR register
> of the pio controllers on the platform I'm targetting. The first
> patch adds some infrastructure to the gpio core and the second
> patch hooks up "my" pin controller.
>
> But hey, this seems like an old problem and I was surprised that
> I had to touch the source to do it. Which makes me wonder what I'm
> missing and what others needing to see short pulses on a pin but not
> needing/wanting interrupts are doing?
>
> Yes, there needs to be a way to select the interrupt edge w/o
> actually arming the interrupt, that is missing. And probably
> other things too, but I didn't want to do more work in case this
> is a dead end for some reason...
>
> Cheers,
> Peter
>
> Peter Rosin (2):
>   gpio: Add isr property of gpio pins
>   pinctrl: at91: expose the isr bit
>
>  Documentation/gpio/sysfs.txt   |   12 ++
>  drivers/gpio/gpiolib-sysfs.c   |   30 
>  drivers/gpio/gpiolib.c |   15 
>  drivers/pinctrl/pinctrl-at91.c |   50 
> 
>  include/linux/gpio/consumer.h  |1 +
>  include/linux/gpio/driver.h|2 ++
>  6 files changed, 106 insertions(+), 4 deletions(-)
>
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Peter Rosin]

Hi!

On 2015-12-09 09:01, Ludovic Desroches wrote:
> Hi Peter,
> 
> On Tue, Dec 08, 2015 at 04:20:06AM +0100, Peter Rosin wrote:
>> From: Peter Rosin 
>>
>> Hi!
>>
>> I have a signal connected to a gpio pin which is the output of
>> a comparator. By changing the level of one of the inputs to the
>> comparator, I can detect the envelope of the other input to
>> the comparator by using a series of measurements much in the
>> same maner a manual ADC works, but watching for changes on the
>> comparator over a period of time instead of only the immediate
>> output.
>>
>> Now, the input signal to the comparator might have a high frequency,
>> which will cause the output from the comparator (and thus the GPIO
>> input) to change rapidly.
>>
>> A common(?) idiom for this is to use the interrupt status register
>> to catch the glitches, but then not have any interrupt tied to
>> the pin as that could possibly generate pointless bursts of
>> (expensive) interrupts.
>>
> 
> Well I don't know if this use case as already been considered. I
> understand you don't want to be overwhelmed by interrupts but why not
> using the interrupt to start polling the PDSR (Pin Data Status
> Register)?

That scheme will not work for me. There might be only one short
glitch, and there might be a flood. I need to catch both. What could
be made to work is some kind of one-off interrupt thingy. I.e. an
interrupt that disabled itself when hit (if that is possibly without
lockup?). That could be a small generic driver not specific to gpio,
I suppose, but where should such a beast live and what user space
interface should it have?

And while that is generic and will probably work in more cases, it
seems complicated and quite a bit of a detour compared to simply
reading the same info from a register.

Are there really noone else using ISR type registers like this with
Linux? In my mind that was pretty standard practice...

> I am really not comfortable about exposing the ISR since there is a
> clean on read. You have taken precautions by checking the IMR before but
> if there is a single driver using a gpio as an irq, you will never get
> the ISR.

Yes, I'm aware of the limitation, but in my case that's not a problem,
obviously. I have no (other) interrupt sources on the gpios covered by
the ISR register in question.

I take it that your major concern is the non-generality, i.e. that it
is not possible to safely get at the ISR when there are interrupts
enabled, and not the complication/overhead of the new lock?

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

Re: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Ludovic Desroches]

Hi Peter,

On Tue, Dec 08, 2015 at 04:20:06AM +0100, Peter Rosin wrote:
> From: Peter Rosin 
> 
> Hi!
> 
> I have a signal connected to a gpio pin which is the output of
> a comparator. By changing the level of one of the inputs to the
> comparator, I can detect the envelope of the other input to
> the comparator by using a series of measurements much in the
> same maner a manual ADC works, but watching for changes on the
> comparator over a period of time instead of only the immediate
> output.
> 
> Now, the input signal to the comparator might have a high frequency,
> which will cause the output from the comparator (and thus the GPIO
> input) to change rapidly.
> 
> A common(?) idiom for this is to use the interrupt status register
> to catch the glitches, but then not have any interrupt tied to
> the pin as that could possibly generate pointless bursts of
> (expensive) interrupts.
> 

Well I don't know if this use case as already been considered. I
understand you don't want to be overwhelmed by interrupts but why not
using the interrupt to start polling the PDSR (Pin Data Status
Register)?

I am really not confortable about exposing the ISR since there is a
clean on read. You have taken precautions by checking the IMR before but
if there is a single driver using a gpio as an irq, you will never get
the ISR.

Regards

Ludovic

> So, these two patches expose an interface to the PIO_ISR register
> of the pio controllers on the platform I'm targetting. The first
> patch adds some infrastructure to the gpio core and the second
> patch hooks up "my" pin controller.
> 
> But hey, this seems like an old problem and I was surprised that
> I had to touch the source to do it. Which makes me wonder what I'm
> missing and what others needing to see short pulses on a pin but not
> needing/wanting interrupts are doing?
> 
> Yes, there needs to be a way to select the interrupt edge w/o
> actually arming the interrupt, that is missing. And probably
> other things too, but I didn't want to do more work in case this
> is a dead end for some reason...
> 
> Cheers,
> Peter
> 
> Peter Rosin (2):
>   gpio: Add isr property of gpio pins
>   pinctrl: at91: expose the isr bit
> 
>  Documentation/gpio/sysfs.txt   |   12 ++
>  drivers/gpio/gpiolib-sysfs.c   |   30 
>  drivers/gpio/gpiolib.c |   15 
>  drivers/pinctrl/pinctrl-at91.c |   50 
> 
>  include/linux/gpio/consumer.h  |1 +
>  include/linux/gpio/driver.h|2 ++
>  6 files changed, 106 insertions(+), 4 deletions(-)
> 
> -- 
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Peter Rosin]

Hi!

On 2015-12-09 09:01, Ludovic Desroches wrote:
> Hi Peter,
> 
> On Tue, Dec 08, 2015 at 04:20:06AM +0100, Peter Rosin wrote:
>> From: Peter Rosin 
>>
>> Hi!
>>
>> I have a signal connected to a gpio pin which is the output of
>> a comparator. By changing the level of one of the inputs to the
>> comparator, I can detect the envelope of the other input to
>> the comparator by using a series of measurements much in the
>> same maner a manual ADC works, but watching for changes on the
>> comparator over a period of time instead of only the immediate
>> output.
>>
>> Now, the input signal to the comparator might have a high frequency,
>> which will cause the output from the comparator (and thus the GPIO
>> input) to change rapidly.
>>
>> A common(?) idiom for this is to use the interrupt status register
>> to catch the glitches, but then not have any interrupt tied to
>> the pin as that could possibly generate pointless bursts of
>> (expensive) interrupts.
>>
> 
> Well I don't know if this use case as already been considered. I
> understand you don't want to be overwhelmed by interrupts but why not
> using the interrupt to start polling the PDSR (Pin Data Status
> Register)?

That scheme will not work for me. There might be only one short
glitch, and there might be a flood. I need to catch both. What could
be made to work is some kind of one-off interrupt thingy. I.e. an
interrupt that disabled itself when hit (if that is possibly without
lockup?). That could be a small generic driver not specific to gpio,
I suppose, but where should such a beast live and what user space
interface should it have?

And while that is generic and will probably work in more cases, it
seems complicated and quite a bit of a detour compared to simply
reading the same info from a register.

Are there really noone else using ISR type registers like this with
Linux? In my mind that was pretty standard practice...

> I am really not comfortable about exposing the ISR since there is a
> clean on read. You have taken precautions by checking the IMR before but
> if there is a single driver using a gpio as an irq, you will never get
> the ISR.

Yes, I'm aware of the limitation, but in my case that's not a problem,
obviously. I have no (other) interrupt sources on the gpios covered by
the ISR register in question.

I take it that your major concern is the non-generality, i.e. that it
is not possible to safely get at the ISR when there are interrupts
enabled, and not the complication/overhead of the new lock?

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

Re: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Ludovic Desroches]

Hi Peter,

On Tue, Dec 08, 2015 at 04:20:06AM +0100, Peter Rosin wrote:
> From: Peter Rosin 
> 
> Hi!
> 
> I have a signal connected to a gpio pin which is the output of
> a comparator. By changing the level of one of the inputs to the
> comparator, I can detect the envelope of the other input to
> the comparator by using a series of measurements much in the
> same maner a manual ADC works, but watching for changes on the
> comparator over a period of time instead of only the immediate
> output.
> 
> Now, the input signal to the comparator might have a high frequency,
> which will cause the output from the comparator (and thus the GPIO
> input) to change rapidly.
> 
> A common(?) idiom for this is to use the interrupt status register
> to catch the glitches, but then not have any interrupt tied to
> the pin as that could possibly generate pointless bursts of
> (expensive) interrupts.
> 

Well I don't know if this use case as already been considered. I
understand you don't want to be overwhelmed by interrupts but why not
using the interrupt to start polling the PDSR (Pin Data Status
Register)?

I am really not confortable about exposing the ISR since there is a
clean on read. You have taken precautions by checking the IMR before but
if there is a single driver using a gpio as an irq, you will never get
the ISR.

Regards

Ludovic

> So, these two patches expose an interface to the PIO_ISR register
> of the pio controllers on the platform I'm targetting. The first
> patch adds some infrastructure to the gpio core and the second
> patch hooks up "my" pin controller.
> 
> But hey, this seems like an old problem and I was surprised that
> I had to touch the source to do it. Which makes me wonder what I'm
> missing and what others needing to see short pulses on a pin but not
> needing/wanting interrupts are doing?
> 
> Yes, there needs to be a way to select the interrupt edge w/o
> actually arming the interrupt, that is missing. And probably
> other things too, but I didn't want to do more work in case this
> is a dead end for some reason...
> 
> Cheers,
> Peter
> 
> Peter Rosin (2):
>   gpio: Add isr property of gpio pins
>   pinctrl: at91: expose the isr bit
> 
>  Documentation/gpio/sysfs.txt   |   12 ++
>  drivers/gpio/gpiolib-sysfs.c   |   30 
>  drivers/gpio/gpiolib.c |   15 
>  drivers/pinctrl/pinctrl-at91.c |   50 
> 
>  include/linux/gpio/consumer.h  |1 +
>  include/linux/gpio/driver.h|2 ++
>  6 files changed, 106 insertions(+), 4 deletions(-)
> 
> -- 
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Peter Rosin]

From: Peter Rosin 

Hi!

I have a signal connected to a gpio pin which is the output of
a comparator. By changing the level of one of the inputs to the
comparator, I can detect the envelope of the other input to
the comparator by using a series of measurements much in the
same maner a manual ADC works, but watching for changes on the
comparator over a period of time instead of only the immediate
output.

Now, the input signal to the comparator might have a high frequency,
which will cause the output from the comparator (and thus the GPIO
input) to change rapidly.

A common(?) idiom for this is to use the interrupt status register
to catch the glitches, but then not have any interrupt tied to
the pin as that could possibly generate pointless bursts of
(expensive) interrupts.

So, these two patches expose an interface to the PIO_ISR register
of the pio controllers on the platform I'm targetting. The first
patch adds some infrastructure to the gpio core and the second
patch hooks up "my" pin controller.

But hey, this seems like an old problem and I was surprised that
I had to touch the source to do it. Which makes me wonder what I'm
missing and what others needing to see short pulses on a pin but not
needing/wanting interrupts are doing?

Yes, there needs to be a way to select the interrupt edge w/o
actually arming the interrupt, that is missing. And probably
other things too, but I didn't want to do more work in case this
is a dead end for some reason...

Cheers,
Peter

Peter Rosin (2):
  gpio: Add isr property of gpio pins
  pinctrl: at91: expose the isr bit

 Documentation/gpio/sysfs.txt   |   12 ++
 drivers/gpio/gpiolib-sysfs.c   |   30 
 drivers/gpio/gpiolib.c |   15 
 drivers/pinctrl/pinctrl-at91.c |   50 
 include/linux/gpio/consumer.h  |1 +
 include/linux/gpio/driver.h|2 ++
 6 files changed, 106 insertions(+), 4 deletions(-)

-- 
1.7.10.4

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

[RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

[Peter Rosin]

From: Peter Rosin 

Hi!

I have a signal connected to a gpio pin which is the output of
a comparator. By changing the level of one of the inputs to the
comparator, I can detect the envelope of the other input to
the comparator by using a series of measurements much in the
same maner a manual ADC works, but watching for changes on the
comparator over a period of time instead of only the immediate
output.

Now, the input signal to the comparator might have a high frequency,
which will cause the output from the comparator (and thus the GPIO
input) to change rapidly.

A common(?) idiom for this is to use the interrupt status register
to catch the glitches, but then not have any interrupt tied to
the pin as that could possibly generate pointless bursts of
(expensive) interrupts.

So, these two patches expose an interface to the PIO_ISR register
of the pio controllers on the platform I'm targetting. The first
patch adds some infrastructure to the gpio core and the second
patch hooks up "my" pin controller.

But hey, this seems like an old problem and I was surprised that
I had to touch the source to do it. Which makes me wonder what I'm
missing and what others needing to see short pulses on a pin but not
needing/wanting interrupts are doing?

Yes, there needs to be a way to select the interrupt edge w/o
actually arming the interrupt, that is missing. And probably
other things too, but I didn't want to do more work in case this
is a dead end for some reason...

Cheers,
Peter

Peter Rosin (2):
  gpio: Add isr property of gpio pins
  pinctrl: at91: expose the isr bit

 Documentation/gpio/sysfs.txt   |   12 ++
 drivers/gpio/gpiolib-sysfs.c   |   30 
 drivers/gpio/gpiolib.c |   15 
 drivers/pinctrl/pinctrl-at91.c |   50 
 include/linux/gpio/consumer.h  |1 +
 include/linux/gpio/driver.h|2 ++
 6 files changed, 106 insertions(+), 4 deletions(-)

-- 
1.7.10.4

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