On Mon, Nov 24, 2014 at 09:57:46AM +0100, Sebastian Andrzej Siewior wrote:
> On 11/21/2014 02:10 PM, Richard Cochran wrote:
>
> > On the BB white using the LCD4 cape and the shipped debian kernel, the
> > cursor *does* jump away, but not as often or as far as on the custom
> > design I was
On 11/21/2014 02:10 PM, Richard Cochran wrote:
> On the BB white using the LCD4 cape and the shipped debian kernel, the
> cursor *does* jump away, but not as often or as far as on the custom
> design I was working with.
This sounds like the ADC is still sampling while the input data becomes
2014-11-21 23:25 GMT+01:00 Griffis, Brad :
>
>> -Original Message-
>> From: Richard Cochran [mailto:richardcoch...@gmail.com]
>>
>> On Fri, Nov 21, 2014 at 07:17:18PM +0100, Johannes Pointner wrote:
>> > Before the patches were also jumps but I thought it is something
>> > Vignesh should
2014-11-21 23:25 GMT+01:00 Griffis, Brad bgrif...@ti.com:
-Original Message-
From: Richard Cochran [mailto:richardcoch...@gmail.com]
On Fri, Nov 21, 2014 at 07:17:18PM +0100, Johannes Pointner wrote:
Before the patches were also jumps but I thought it is something
Vignesh should
On 11/21/2014 02:10 PM, Richard Cochran wrote:
On the BB white using the LCD4 cape and the shipped debian kernel, the
cursor *does* jump away, but not as often or as far as on the custom
design I was working with.
This sounds like the ADC is still sampling while the input data becomes
On Mon, Nov 24, 2014 at 09:57:46AM +0100, Sebastian Andrzej Siewior wrote:
On 11/21/2014 02:10 PM, Richard Cochran wrote:
On the BB white using the LCD4 cape and the shipped debian kernel, the
cursor *does* jump away, but not as often or as far as on the custom
design I was working with.
> -Original Message-
> From: Richard Cochran [mailto:richardcoch...@gmail.com]
>
> On Fri, Nov 21, 2014 at 07:17:18PM +0100, Johannes Pointner wrote:
> > Before the patches were also jumps but I thought it is something
> > Vignesh should know. Maybe there is some fix for that too?
I
On Fri, Nov 21, 2014 at 07:17:18PM +0100, Johannes Pointner wrote:
> Before the patches were also jumps but I thought it is something
> Vignesh should know. Maybe there is some fix for that too?
> As Richard also noted, it would be nice if ti could let us know how to
> get the delay values right.
Before the patches were also jumps but I thought it is something
Vignesh should know. Maybe there is some fix for that too?
As Richard also noted, it would be nice if ti could let us know how to
get the delay values right. By trial and error is IMHO not the best
way.
For the testing I used 3.16.7.
On Friday 21 November 2014 08:41 PM, Johannes Pointner wrote:
> I tested version 4 of the patch series on a custom design and I saw
> also the jumps as described by Richard. I played a little with the
> sample delay and it got better but I couldn't completely remove the
> jumps.
And before the
I tested version 4 of the patch series on a custom design and I saw
also the jumps as described by Richard. I played a little with the
sample delay and it got better but I couldn't completely remove the
jumps.
The other issue I had with version 3, the pen_ups during the busy
loop, is solved. I
On Fri, Nov 21, 2014 at 05:40:12PM +0530, Sekhar Nori wrote:
> Not sure how to reproduce the jumping on pen-up.
Does the cursor stay in exactly the same spot when you lift up the
stylus? Then you don't have the issue.
On the BB white using the LCD4 cape and the shipped debian kernel, the
cursor
On Thursday 20 November 2014 08:10 PM, Richard Cochran wrote:
> On Thu, Nov 20, 2014 at 07:26:00PM +0530, Sekhar Nori wrote:
>> I tested this using lcd7 cape connected to beaglebone black. The latest
>> kernel I could find on this board was a TI BSP based v3.14 kernel. So I
>> had to port these
On Thursday 20 November 2014 08:10 PM, Richard Cochran wrote:
On Thu, Nov 20, 2014 at 07:26:00PM +0530, Sekhar Nori wrote:
I tested this using lcd7 cape connected to beaglebone black. The latest
kernel I could find on this board was a TI BSP based v3.14 kernel. So I
had to port these patches
On Fri, Nov 21, 2014 at 05:40:12PM +0530, Sekhar Nori wrote:
Not sure how to reproduce the jumping on pen-up.
Does the cursor stay in exactly the same spot when you lift up the
stylus? Then you don't have the issue.
On the BB white using the LCD4 cape and the shipped debian kernel, the
cursor
I tested version 4 of the patch series on a custom design and I saw
also the jumps as described by Richard. I played a little with the
sample delay and it got better but I couldn't completely remove the
jumps.
The other issue I had with version 3, the pen_ups during the busy
loop, is solved. I
On Friday 21 November 2014 08:41 PM, Johannes Pointner wrote:
I tested version 4 of the patch series on a custom design and I saw
also the jumps as described by Richard. I played a little with the
sample delay and it got better but I couldn't completely remove the
jumps.
And before the
Before the patches were also jumps but I thought it is something
Vignesh should know. Maybe there is some fix for that too?
As Richard also noted, it would be nice if ti could let us know how to
get the delay values right. By trial and error is IMHO not the best
way.
For the testing I used 3.16.7.
On Fri, Nov 21, 2014 at 07:17:18PM +0100, Johannes Pointner wrote:
Before the patches were also jumps but I thought it is something
Vignesh should know. Maybe there is some fix for that too?
As Richard also noted, it would be nice if ti could let us know how to
get the delay values right. By
-Original Message-
From: Richard Cochran [mailto:richardcoch...@gmail.com]
On Fri, Nov 21, 2014 at 07:17:18PM +0100, Johannes Pointner wrote:
Before the patches were also jumps but I thought it is something
Vignesh should know. Maybe there is some fix for that too?
I believe
On Thu, Nov 20, 2014 at 07:26:00PM +0530, Sekhar Nori wrote:
> I tested this using lcd7 cape connected to beaglebone black. The latest
> kernel I could find on this board was a TI BSP based v3.14 kernel. So I
> had to port these patches to that kernel. Cc Robert Nelson to see if he
> knows about a
Brad,
What you wrote is just the kind of thing one would like to see in the
cover letter or change log...
On Thu, Nov 20, 2014 at 02:23:30PM +, Griffis, Brad wrote:
> In that thread the user was registering multiple press events for a single
> press. By increasing the udelay to 1.5ms they
> -Original Message-
> From: Nori, Sekhar
> Sent: Thursday, November 20, 2014 7:56 AM
>
> I also tested this series on AM335x EVM using the v3.18-rc5 kernel.
> Again, no breakage but no improvement as well.
The primary goal was not necessarily to improve performance of the touchscreen
On Tuesday 18 November 2014 10:42 PM, Dmitry Torokhov wrote:
> On Tue, Nov 18, 2014 at 02:30:05PM +, Lee Jones wrote:
>> On Fri, 14 Nov 2014, Vignesh R wrote:
>>
>>> In one shot mode, sequencer automatically disables all enabled steps at
>>> the end of each cycle. (both ADC steps and TSC
On Tuesday 18 November 2014 10:42 PM, Dmitry Torokhov wrote:
On Tue, Nov 18, 2014 at 02:30:05PM +, Lee Jones wrote:
On Fri, 14 Nov 2014, Vignesh R wrote:
In one shot mode, sequencer automatically disables all enabled steps at
the end of each cycle. (both ADC steps and TSC steps) Hence
-Original Message-
From: Nori, Sekhar
Sent: Thursday, November 20, 2014 7:56 AM
I also tested this series on AM335x EVM using the v3.18-rc5 kernel.
Again, no breakage but no improvement as well.
The primary goal was not necessarily to improve performance of the touchscreen
itself.
Brad,
What you wrote is just the kind of thing one would like to see in the
cover letter or change log...
On Thu, Nov 20, 2014 at 02:23:30PM +, Griffis, Brad wrote:
In that thread the user was registering multiple press events for a single
press. By increasing the udelay to 1.5ms they
On Thu, Nov 20, 2014 at 07:26:00PM +0530, Sekhar Nori wrote:
I tested this using lcd7 cape connected to beaglebone black. The latest
kernel I could find on this board was a TI BSP based v3.14 kernel. So I
had to port these patches to that kernel. Cc Robert Nelson to see if he
knows about a
On Tue, Nov 18, 2014 at 02:30:05PM +, Lee Jones wrote:
> On Fri, 14 Nov 2014, Vignesh R wrote:
>
> > In one shot mode, sequencer automatically disables all enabled steps at
> > the end of each cycle. (both ADC steps and TSC steps) Hence these steps
> > need not be saved in reg_se_cache for
On Fri, 14 Nov 2014, Vignesh R wrote:
> In one shot mode, sequencer automatically disables all enabled steps at
> the end of each cycle. (both ADC steps and TSC steps) Hence these steps
> need not be saved in reg_se_cache for clearing these steps at a later
> stage.
> Also, when ADC wakes up
On Tue, Nov 18, 2014 at 02:30:05PM +, Lee Jones wrote:
On Fri, 14 Nov 2014, Vignesh R wrote:
In one shot mode, sequencer automatically disables all enabled steps at
the end of each cycle. (both ADC steps and TSC steps) Hence these steps
need not be saved in reg_se_cache for clearing
On Fri, 14 Nov 2014, Vignesh R wrote:
In one shot mode, sequencer automatically disables all enabled steps at
the end of each cycle. (both ADC steps and TSC steps) Hence these steps
need not be saved in reg_se_cache for clearing these steps at a later
stage.
Also, when ADC wakes up Sequencer
In one shot mode, sequencer automatically disables all enabled steps at
the end of each cycle. (both ADC steps and TSC steps) Hence these steps
need not be saved in reg_se_cache for clearing these steps at a later
stage.
Also, when ADC wakes up Sequencer should not be busy executing any of the
In one shot mode, sequencer automatically disables all enabled steps at
the end of each cycle. (both ADC steps and TSC steps) Hence these steps
need not be saved in reg_se_cache for clearing these steps at a later
stage.
Also, when ADC wakes up Sequencer should not be busy executing any of the
34 matches
Mail list logo
