From: Tim Nordell <tim.nordell@logicpd.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: <linux-media@vger.kernel.org>, <sakari.ailus@iki.fi>
Subject: Re: [PATCH 2/3] omap3isp: Disable CCDC's VD0 and VD1 interrupts when stream is not enabled
Date: Tue, 21 Apr 2015 13:05:02 -0500 [thread overview]
Message-ID: <5536914E.7090407@logicpd.com> (raw)
In-Reply-To: <7150396.TWY5qHavDR@avalon>
Laurent -
On 04/21/15 12:58, Laurent Pinchart wrote:
> Hi Tim,
>
> On Wednesday 18 March 2015 10:25:34 Tim Nordell wrote:
>> I'll give that a shot and try add code into the adv7180 driver to turn on
>> and off its output signals. However, it seems like if the driver can avoid
>> a problem presented by external hardware (or other drivers), that it should.
>> Something like either turning off the VD0 and VD1 interrupts when not in
>> use, or by simply moving the trigger points for those interrupts (as I did
>> here) to avoid problems by presented by signals to the system is probably a
>> good thing for robustness.
> I don't disagree with that. I'll have to review the patch in details, as the
> CCDC code is quite sensitive. In order to do so, I'd like to know whether the
> problem in your case was caused by the adv7180 always being enabled. Any luck
> with adding a s_stream implementation in the adv7180 driver ? :-)
>
I did add the stream on/off code, but it still seemed to have some
difficulties. The codebase has effectively been handed off to our
client, however, at this point. I still happen to have hardware (we're
wrapping things up with the client), but likely I won't have the
hardware in a week or so.
I still think that the driver should avoid having the interrupts enabled
if it knows it shouldn't be receiving any at a given point. I personally
like the approach of modifying the VD0/VD1 trigger points as it
effectively silences those interrupts without touching the central
interrupt register (less potential locking issues between the various
components in the OMAP3 ISP), but it could be reworked of course to
touch the central interrupt register too.
- Tim
next prev parent reply other threads:[~2015-04-21 18:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-10 19:24 [PATCH 0/3] *** Updates against OMAP3ISP and BT.656 Tim Nordell
2015-03-10 19:24 ` [PATCH 1/3] omap3isp: Defer probing when subdev isn't available Tim Nordell
2015-03-18 15:15 ` Laurent Pinchart
2015-03-18 15:18 ` Tim Nordell
2015-03-10 19:24 ` [PATCH 2/3] omap3isp: Disable CCDC's VD0 and VD1 interrupts when stream is not enabled Tim Nordell
2015-03-18 15:19 ` Laurent Pinchart
2015-03-18 15:25 ` Tim Nordell
2015-04-21 17:58 ` Laurent Pinchart
2015-04-21 18:05 ` Tim Nordell [this message]
2015-03-10 19:24 ` [PATCH 3/3] omap3isp: Add a delayed buffers for frame mode Tim Nordell
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=5536914E.7090407@logicpd.com \
--to=tim.nordell@logicpd.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=sakari.ailus@iki.fi \
/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.