On 07/29/2014 01:26 PM, Stephen Warren wrote:
On 07/29/2014 11:06 AM, Nick Dyer wrote:
On 29/07/14 17:16, Stephen Warren wrote:
...
I also found that removing the module (even without attempting a FW
update) yields:
After attempted FW update via sysfs:
root@localhost:~# rmmod ./atmel_mxt_ts
On 07/29/2014 11:06 AM, Nick Dyer wrote:
On 29/07/14 17:16, Stephen Warren wrote:
I then tried updating the firmware. This didn't work at all.
First I tried via mxt-app:
root@localhost:~# ./obp-utils/mxt-app -d i2c-dev:1-004b --flash
130.1_1.0.170.bin
Version:1.16-65-g0a4c
Opening firmware fi
On 29/07/14 17:16, Stephen Warren wrote:
> I then tried updating the firmware. This didn't work at all.
>
> First I tried via mxt-app:
>
>> root@localhost:~# ./obp-utils/mxt-app -d i2c-dev:1-004b --flash
>> 130.1_1.0.170.bin
>> Version:1.16-65-g0a4c
>> Opening firmware file 130.1_1.0.170.bin
>> R
On 29/07/14 01:10, Yufeng Shen wrote:
> T37 (0x25) is DEBUG_DIAGNOSTIC object which the host can read debugging info
> from. It is not useful to have a initial config for it so usually CrOS
> system would just
> don't include configuration for this object.
>
> Nick, I want to confirm with you that
On 29/07/14 00:42, Stephen Warren wrote:
> Anyway, here's the diff between the two config files:
>
>> # diff -u mxt-save-after-t9-83-write.xml 224sl.raw
>> --- mxt-save-after-t9-83-write.xml2014-07-25 19:41:45.0 +
>> +++ 224sl.raw2014-07-28 23:25:49.0 +
>> @@ -1,8 +
On 07/28/2014 06:10 PM, Yufeng Shen wrote:
On Mon, Jul 28, 2014 at 7:42 PM, Stephen Warren wrote:
On 07/28/2014 03:23 PM, Stephen Warren wrote:
On 07/28/2014 02:20 PM, Yufeng Shen wrote:
...
Where did you get the configuration file ? It is possible that we rely
too much on mxt_start to tur
On Mon, Jul 28, 2014 at 7:42 PM, Stephen Warren wrote:
> On 07/28/2014 03:23 PM, Stephen Warren wrote:
>>
>> On 07/28/2014 02:20 PM, Yufeng Shen wrote:
>
> ...
>
>>> Where did you get the configuration file ? It is possible that we rely
>>> too much on mxt_start to turn on the T9.CTRL bit and have
On 07/28/2014 03:23 PM, Stephen Warren wrote:
On 07/28/2014 02:20 PM, Yufeng Shen wrote:
...
Where did you get the configuration file ? It is possible that we rely
too much on mxt_start to turn on the T9.CTRL bit and have neglected
its setting in the config file.
If you can tell me where you ge
On 07/28/2014 02:20 PM, Yufeng Shen wrote:
On Fri, Jul 25, 2014 at 4:06 PM, Stephen Warren wrote:
On 07/25/2014 08:10 AM, Nick Dyer wrote:
On 24/07/14 22:19, Stephen Warren wrote:
...
I've uploaded 2 logs to:
http://avon.wwwdotorg.org/downloads/mxt-logs/
(note there's no directory index
On Fri, Jul 25, 2014 at 4:06 PM, Stephen Warren wrote:
>
> On 07/25/2014 08:10 AM, Nick Dyer wrote:
>>
>> On 24/07/14 22:19, Stephen Warren wrote:
>
> ...
>
>>> I've uploaded 2 logs to:
>>>
>>> http://avon.wwwdotorg.org/downloads/mxt-logs/
>>> (note there's no directory indexing, so manually add t
On Fri, Jul 25, 2014 at 02:06:40PM -0600, Stephen Warren wrote:
> On 07/25/2014 08:10 AM, Nick Dyer wrote:
> >On 24/07/14 22:19, Stephen Warren wrote:
> ...
> >>I've uploaded 2 logs to:
> >>
> >>http://avon.wwwdotorg.org/downloads/mxt-logs/
> >>(note there's no directory indexing, so manually add t
On 07/25/2014 08:10 AM, Nick Dyer wrote:
On 24/07/14 22:19, Stephen Warren wrote:
...
I've uploaded 2 logs to:
http://avon.wwwdotorg.org/downloads/mxt-logs/
(note there's no directory indexing, so manually add the filenames below to
the URL)
mxt-save-no-movement.xml
This is with the whole se
On 24/07/14 22:19, Stephen Warren wrote:
>> mxt-app [device] --save fail.xcfg
>
> That command always experiences a timeout error, but still seems to dump
> something out. Is this timeout error an issue? I'm a little hesitant to
> modify the COMMSCONFIG settings until I know load/save are really w
On 07/24/2014 07:47 AM, Nick Dyer wrote:
On 23/07/14 18:22, Stephen Warren wrote:
That didn't make any difference.
I also tried the tool interactively. the "Display raw (M)essages" option
never displayed anything, and the couple of self-tests I tried just
timed out. "Read (I)nfo block" did disp
On 23/07/14 18:22, Stephen Warren wrote:
> That didn't make any difference.
>
> I also tried the tool interactively. the "Display raw (M)essages" option
> never displayed anything, and the couple of self-tests I tried just
> timed out. "Read (I)nfo block" did display some values that seemed like
>
On 07/23/2014 02:29 PM, Dmitry Torokhov wrote:
> On Wed, Jul 23, 2014 at 11:22:54AM -0600, Stephen Warren wrote:
>> On 07/23/2014 09:30 AM, Nick Dyer wrote:
>>> On 22/07/14 21:34, Stephen Warren wrote:
Unfortunately, I still can't get these to work on my system.
Per your "Re: atmel_m
On Wed, Jul 23, 2014 at 11:22:54AM -0600, Stephen Warren wrote:
> On 07/23/2014 09:30 AM, Nick Dyer wrote:
> > On 22/07/14 21:34, Stephen Warren wrote:
> >> Unfortunately, I still can't get these to work on my system.
> >>
> >> Per your "Re: atmel_mxt_ts: defaulting irqflags to
> >> IRQF_TRIGGER_FA
On 07/23/2014 09:30 AM, Nick Dyer wrote:
> On 22/07/14 21:34, Stephen Warren wrote:
>> Unfortunately, I still can't get these to work on my system.
>>
>> Per your "Re: atmel_mxt_ts: defaulting irqflags to
>> IRQF_TRIGGER_FALLING", I set up the IRQ type in the Tegra DT file, and
>> then applied this
On 22/07/14 21:34, Stephen Warren wrote:
> Unfortunately, I still can't get these to work on my system.
>
> Per your "Re: atmel_mxt_ts: defaulting irqflags to
> IRQF_TRIGGER_FALLING", I set up the IRQ type in the Tegra DT file, and
> then applied this series on top of next-20140721. The driver app
On 07/03/2014 09:01 AM, nick.d...@itdev.co.uk wrote:
> Hi Dimitry-
>
> Here is another set of atmel_mxt_ts patches for upstream. There are some
> really useful new features, but I hope nothing too controversial.
Unfortunately, I still can't get these to work on my system.
Per your "Re: atmel_mxt
On Monday 07 July 2014 05:08 PM, Nick Dyer wrote:
> On 07/07/14 12:21, Sekhar Nori wrote:
>> I was unable to get the touchscreen working on my board after applying
>> just these patches. It does work correctly with your for-next branch so
>> I guess I need to wait for you to post the rest of your
On 07/07/14 12:21, Sekhar Nori wrote:
> I was unable to get the touchscreen working on my board after applying
> just these patches. It does work correctly with your for-next branch so
> I guess I need to wait for you to post the rest of your patches too.
>
> Here are the relevant messages at bo
Hi Nick,
On Thursday 03 July 2014 08:31 PM, nick.d...@itdev.co.uk wrote:
> Hi Dimitry-
>
> Here is another set of atmel_mxt_ts patches for upstream. There are some
> really useful new features, but I hope nothing too controversial.
I was unable to get the touchscreen working on my board after ap
Hi Dimitry-
Here is another set of atmel_mxt_ts patches for upstream. There are some
really useful new features, but I hope nothing too controversial.
thanks
Nick Dyer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.or
24 matches
Mail list logo
