[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-omap
Subject:    Common code for TSC 2101 and 2102
From:       balrogg () gmail ! com (andrzej zaborowski)
Date:       2007-09-23 17:37:31
Message-ID: fb249edb0709231537p4de2f11aic934938f92e2936e () mail ! gmail ! com
[Download RAW message or body]

Hi, sorry for late reply, I'm just catching up with email now.

On 14/08/2007, David Brownell <david-b@pacbell.net> wrote:
> Following this will be several patches, two related to
> this driver:
>
>  - H4 board support, using TSC2101 (not TSC2102)
>  - A biggish tsc210x cleanup patch, with some bugfixes

Thanks for this work.

>
> For boards using external VREF, that value should be in
> the tsc210x chip platform data.  (And Andrzej, I'm
> curious why you settled on VREF=1.25V vs 2.50V ... not
> that it's necessarily an issue, just "why".  A comment
> in the code might be good.)

Oh, I'm afraid I left it to be made configurable by the first person
who needs VREF of 2.5V, out of laziness. I settled on 1.25V
specifically because that's what PalmOS (the OS that ships with Palm
Tungsten E) uses. The device is a consumer PDA and I have no
schematics or even multimeter access to the chips, and likely I
wouldn't know how to use it if I had.

>
> Somewhat related, I think the TSC setup code should
> likely hold off until it can fetch calibration data
> from EEPROM or somesuch ... temperature readings are
> not all that useful until that data is available.
> Alternatively, do like I did in ads7846:  punt it all
> to userspace, just provide the raw milliVolt readings
> and expect someone else to compute temperature.

The board setup code can defer the TSC setup by registering the
tsc210x device only after all information is available to fill in the
pdata struct.

Regards

[prev in list] [next in list] [prev in thread] [next in thread]