From: mchehab@s-opensource.com (Mauro Carvalho Chehab)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 15/17] media: st_rc: Don't stay on an IRQ handler forever
Date: Fri, 13 Apr 2018 11:08:03 -0300 [thread overview]
Message-ID: <20180413110803.0599eb2a@vento.lan> (raw)
In-Reply-To: <20180413132052.37fudkaxltvwc46v@gofer.mess.org>
Em Fri, 13 Apr 2018 14:20:52 +0100
Sean Young <sean@mess.org> escreveu:
> On Fri, Apr 13, 2018 at 07:00:50AM -0300, Mauro Carvalho Chehab wrote:
> > Yeah, we could limit it to run only 512 times (or some other reasonable
> > quantity), but in order to do that, we need to be sure that, on each read(),
> > the FIFO will shift - e. g. no risk of needing to do more than one read
> > to get the next element. That would work if the FIFO is implemented via
> > flip-flops. But if it is implemented via some slow memory, or if the
> > shift logic is implemented via some software on a micro-controller, it
> > may need a few interactions to get the next value.
> >
> > Without knowing about the hardware implementation, I'd say that setting
> > a max time for the whole FIFO interaction is safer.
>
> Ok. If the 10ms timeout is reached, there really is a problem; should we
> report an error in this case?
Maybe, but then it should likely warn only once.
Thanks,
Mauro
WARNING: multiple messages have this Message-ID (diff)
From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Sean Young <sean@mess.org>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@infradead.org>,
Patrice Chotard <patrice.chotard@st.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 15/17] media: st_rc: Don't stay on an IRQ handler forever
Date: Fri, 13 Apr 2018 11:08:03 -0300 [thread overview]
Message-ID: <20180413110803.0599eb2a@vento.lan> (raw)
In-Reply-To: <20180413132052.37fudkaxltvwc46v@gofer.mess.org>
Em Fri, 13 Apr 2018 14:20:52 +0100
Sean Young <sean@mess.org> escreveu:
> On Fri, Apr 13, 2018 at 07:00:50AM -0300, Mauro Carvalho Chehab wrote:
> > Yeah, we could limit it to run only 512 times (or some other reasonable
> > quantity), but in order to do that, we need to be sure that, on each read(),
> > the FIFO will shift - e. g. no risk of needing to do more than one read
> > to get the next element. That would work if the FIFO is implemented via
> > flip-flops. But if it is implemented via some slow memory, or if the
> > shift logic is implemented via some software on a micro-controller, it
> > may need a few interactions to get the next value.
> >
> > Without knowing about the hardware implementation, I'd say that setting
> > a max time for the whole FIFO interaction is safer.
>
> Ok. If the 10ms timeout is reached, there really is a problem; should we
> report an error in this case?
Maybe, but then it should likely warn only once.
Thanks,
Mauro
next prev parent reply other threads:[~2018-04-13 14:08 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-12 15:23 [PATCH 01/17] media: staging: atomisp: fix number conversion Mauro Carvalho Chehab
2018-04-12 15:23 ` [PATCH 02/17] media: staging: atomisp: don't declare the same vars as both private and public Mauro Carvalho Chehab
2018-04-13 21:27 ` kbuild test robot
2018-04-12 15:23 ` [PATCH 03/17] media: atomisp: fix __user annotations Mauro Carvalho Chehab
2018-04-13 22:35 ` kbuild test robot
2018-04-16 10:22 ` [PATCHv2 02/17] media: staging: atomisp: don't declare the same vars as both private and public Mauro Carvalho Chehab
2018-04-12 15:23 ` [PATCH 04/17] media: staging: atomisp: fix string comparation logic Mauro Carvalho Chehab
2018-04-12 15:23 ` [PATCH 05/17] dvb_frontend: fix locking issues at dvb_frontend_get_event() Mauro Carvalho Chehab
2018-04-12 15:23 ` Mauro Carvalho Chehab
2018-04-12 15:23 ` [PATCH 06/17] media: v4l2-fwnode: simplify v4l2_fwnode_reference_parse_int_props() Mauro Carvalho Chehab
2018-04-12 15:23 ` [PATCH 07/17] media: cec: fix smatch error Mauro Carvalho Chehab
2018-04-12 15:24 ` [PATCH 08/17] atomisp: remove an impossible condition Mauro Carvalho Chehab
2018-04-12 15:24 ` [PATCH 09/17] media: platform: fix some 64-bits warnings Mauro Carvalho Chehab
2018-04-12 15:24 ` [PATCH 10/17] media: v4l2-compat-ioctl32: prevent go past max size Mauro Carvalho Chehab
2018-04-12 15:24 ` Mauro Carvalho Chehab
2018-04-12 15:24 ` [PATCH 11/17] media: atomisp: compat32: use get_user() before referencing user data Mauro Carvalho Chehab
2018-04-12 15:24 ` [PATCH 12/17] media: staging: atomisp: add missing include Mauro Carvalho Chehab
2018-04-12 15:24 ` [PATCH 13/17] media: atomisp: compat32: fix __user annotations Mauro Carvalho Chehab
2018-04-12 15:24 ` [PATCH 14/17] media: atomisp: get rid of a warning Mauro Carvalho Chehab
2018-04-12 15:24 ` [PATCH 15/17] media: st_rc: Don't stay on an IRQ handler forever Mauro Carvalho Chehab
2018-04-12 15:24 ` Mauro Carvalho Chehab
2018-04-12 22:21 ` Sean Young
2018-04-12 22:21 ` Sean Young
2018-04-13 7:32 ` Patrice CHOTARD
2018-04-13 7:32 ` Patrice CHOTARD
2018-04-13 9:06 ` Mauro Carvalho Chehab
2018-04-13 9:06 ` Mauro Carvalho Chehab
2018-04-13 9:40 ` Sean Young
2018-04-13 9:40 ` Sean Young
2018-04-13 10:00 ` Mauro Carvalho Chehab
2018-04-13 10:00 ` Mauro Carvalho Chehab
2018-04-13 13:20 ` Sean Young
2018-04-13 13:20 ` Sean Young
2018-04-13 14:08 ` Mauro Carvalho Chehab [this message]
2018-04-13 14:08 ` Mauro Carvalho Chehab
2018-04-13 8:03 ` Patrice CHOTARD
2018-04-13 8:03 ` Patrice CHOTARD
2018-04-13 9:15 ` Mason
2018-04-13 9:15 ` Mason
2018-04-13 9:25 ` Mauro Carvalho Chehab
2018-04-13 9:25 ` Mauro Carvalho Chehab
2018-04-13 9:36 ` Mason
2018-04-13 9:36 ` Mason
2018-04-13 9:52 ` Mauro Carvalho Chehab
2018-04-13 9:52 ` Mauro Carvalho Chehab
2018-04-12 15:24 ` [PATCH 16/17] media: mantis: prevent staying forever in a loop at IRQ Mauro Carvalho Chehab
2018-04-12 15:24 ` [PATCH 17/17] media: v4l2-compat-ioctl32: fix several __user annotations Mauro Carvalho Chehab
2018-04-13 18:07 ` [PATCHv2 " Mauro Carvalho Chehab
2018-04-16 12:03 ` Hans Verkuil
2018-04-16 14:50 ` Mauro Carvalho Chehab
2018-04-16 15:32 ` Hans Verkuil
2018-04-16 17:26 ` Mauro Carvalho Chehab
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=20180413110803.0599eb2a@vento.lan \
--to=mchehab@s-opensource.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.