On 12/15/2016 02:14 AM, Nicholas Mc Guire wrote:
> if its actually unused then it might be best to completely drop the code
> raher than fixing up dead-code. Is the EXYNOS the only system that had
> this device in use ? If it shold stay in then setting it to the above
> proposed 3000, 4000 would se
On Tue, Dec 13, 2016 at 03:53:47PM +0100, Sylwester Nawrocki wrote:
> Hi Laurent,
>
> On 12/13/2016 03:10 PM, Laurent Pinchart wrote:
> > As pointed out by Ian Arkver, the datasheet states the delay should be
> > >50µs.
> > Would it make sense to reduce the sleep duration to (3000, 4000) for
>
Hi Laurent,
On 12/13/2016 03:10 PM, Laurent Pinchart wrote:
> As pointed out by Ian Arkver, the datasheet states the delay should be >50µs.
> Would it make sense to reduce the sleep duration to (3000, 4000) for instance
> (or possibly even lower), instead of increasing it ?
Theoretically it wou
Hi Sylwester,
On Tuesday 13 Dec 2016 13:38:52 Sylwester Nawrocki wrote:
> On 12/13/2016 02:58 AM, Nicholas Mc Guire wrote:
> > As this is not in atomic context and it does not seem like a critical
> > timing setting a range of 1ms allows the timer subsystem to optimize
> > the hrtimer here.
> >
>
On 12/13/2016 02:58 AM, Nicholas Mc Guire wrote:
> As this is not in atomic context and it does not seem like a critical
> timing setting a range of 1ms allows the timer subsystem to optimize
> the hrtimer here.
>
> Fixes: commit bfa8dd3a0524 ("[media] v4l: Add v4l2 subdev driver for S5K6AAFX
>
On Tue, Dec 13, 2016 at 10:10:51AM +, Ian Arkver wrote:
> On 13/12/16 09:43, Sakari Ailus wrote:
> >Hi Nicholas,
> >
> >On Tue, Dec 13, 2016 at 02:58:02AM +0100, Nicholas Mc Guire wrote:
> >>As this is not in atomic context and it does not seem like a critical
> >>timing setting a range of 1ms
On 13/12/16 09:43, Sakari Ailus wrote:
Hi Nicholas,
On Tue, Dec 13, 2016 at 02:58:02AM +0100, Nicholas Mc Guire wrote:
As this is not in atomic context and it does not seem like a critical
timing setting a range of 1ms allows the timer subsystem to optimize
the hrtimer here.
I'd suggest not to
Hi Nicholas,
On Tue, Dec 13, 2016 at 02:58:02AM +0100, Nicholas Mc Guire wrote:
> As this is not in atomic context and it does not seem like a critical
> timing setting a range of 1ms allows the timer subsystem to optimize
> the hrtimer here.
I'd suggest not to. These delays are often directly
As this is not in atomic context and it does not seem like a critical
timing setting a range of 1ms allows the timer subsystem to optimize
the hrtimer here.
Fixes: commit bfa8dd3a0524 ("[media] v4l: Add v4l2 subdev driver for S5K6AAFX
sensor")
Signed-off-by: Nicholas Mc Guire
---
problem was
9 matches
Mail list logo
