From: Jonathan Cameron <jic23@kernel.org>
To: Martin Kelly <mkelly@xevo.com>
Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v5 1/2] iio:imu: inv_mpu6050: support more interrupt types
Date: Sun, 15 Apr 2018 18:50:27 +0100 [thread overview]
Message-ID: <20180415185027.62a74e05@archlinux> (raw)
In-Reply-To: <faa41264-5063-541a-32cd-976930769ee9@xevo.com>
On Fri, 13 Apr 2018 09:19:41 -0700
Martin Kelly <mkelly@xevo.com> wrote:
> On 04/13/2018 02:25 AM, Jean-Baptiste Maneyrol wrote:
> > Hello,
> >
> > I am now able to reproduce the issue by generating kernel irq (just
> > plug/unplug mouse or keyboard is sufficient).
> >
> > My last modification doesn't solve anything, since event the hard irq
> > handler is disabled when processing another interrupt. Having a latched
> > interrupt and triggering by level is a workaround, but clearly not perfect.
> >
>
>
> I'm glad you can reproduce the issue now! What board are you using? My
> issues have been with the nanopi neo air (based on the Allwinner H3 SoC).
>
> > I think we need to work out a new solution for timestamping correctly
> > the data.
> >
> > JB
> >
> >
> I think we should try to solve the missing interrupts issue. Without
> solving it, the best we can do is interpolate, as I do in the other patch.
>
> That said, I think supporting more interrupt types and interpolating are
> good ideas regardless. Supporting more interrupt types is useful for
> integrating with more types of hardware, and interpolating is useful for
> being more robust against systems having issues, which can unexpectedly
> happen even if we fix the immediate issue we see here.
Agreed on the interrupt types. Interpolating is till rather 'nasty'
so the case is a little less clear, but I'm being convinced I think...
Anyhow, looking forward to v6 Will want JB reviewed-by or acked-by
on this one!
Jonathan
next prev parent reply other threads:[~2018-04-15 17:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-09 20:21 [PATCH v5 1/2] iio:imu: inv_mpu6050: support more interrupt types Martin Kelly
2018-04-09 20:21 ` [PATCH v5 2/2] dt-bindings: iio:imu:mpu6050: " Martin Kelly
2018-04-13 13:43 ` Rob Herring
2018-04-10 9:06 ` [PATCH v5 1/2] iio:imu: inv_mpu6050: " Jean-Baptiste Maneyrol
2018-04-10 18:08 ` Martin Kelly
2018-04-11 7:01 ` Jean-Baptiste Maneyrol
2018-04-11 16:42 ` Martin Kelly
2018-04-12 15:01 ` Jean-Baptiste Maneyrol
2018-04-12 18:16 ` Martin Kelly
2018-04-13 9:25 ` Jean-Baptiste Maneyrol
2018-04-13 16:19 ` Martin Kelly
2018-04-15 17:50 ` Jonathan Cameron [this message]
2018-04-15 17:43 ` Jonathan Cameron
2018-04-15 19:05 ` Martin Kelly
2018-04-17 14:10 ` Jean-Baptiste Maneyrol
2018-04-17 18:14 ` Martin Kelly
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=20180415185027.62a74e05@archlinux \
--to=jic23@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jmaneyrol@invensense.com \
--cc=linux-iio@vger.kernel.org \
--cc=mkelly@xevo.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.