[RFC] TSC2101 support

[Kyungmin Park <kyungmin.park@samsung.com>]

[-- Attachment #1: Type: text/plain, Size: 4105 bytes --]

(Sorry for renaming the subject. Our mail system can't reply the mail to maling list)

Thank you for your opinions.

I agree with your ideas except  that we don't want to break the existing drivers. especially OMAP1 TSC2101 drivers.
In the previous time I tried to use omapts.c on OMAP2. but it's not working well. I think interrupt handling and timer is problem.
omapts.c is simple but new implementation is more complicated.

If we break the previous drivers. it's big works and I want to avoid it. So how about do it as below?

First, Add OMAP2 TSC2101
Second, Separate the SPI protocol, tsc2101 drivers, and platform dependent part. e.g., N800 use 16 bit but h4 and apollon use 32 bit
Finally, Merge OMAP1 with OMAP2, if possible

By the way TSC2101, 2102, and 2301 has similar functions. Of course, each chips have its own features. but we can make it common driver if possible
(yes, I know it's another topic)

Thank you,
Kyungmin Park

------- Original Message -------
Sender : Syed Mohammed, Khasim<x0khasim@ti.com>
Date   : Jan 25, 2007 15:08
Title  : RE: [RFC] TSC2101 support

Kyungmin, thanks for the code.        
         
I was thinking on similar lines as Mika. We should have tsc2101 driver independent of Touchscreen / Audio / battery etc. Basically it should provide (export) read and write APIs using SPI. The TS part (GPIO registration / passing data to input subsystem etc) should be part of touch screen driver. The TS / Audio / Battery drivers should use these exported APIs to talk to TSC2101. There by all TSC2101 dependent drivers can be isolated from using direct SPI calls.        
         
If you agree with this design I can work on this part. But as Mika pointed it will change omapts.c, this is the only concern.         
         
Regards,Khasim
From: linux-omap-open-source-bounces@linux.omap.com on behalf of lamikr
Sent: Wed 1/24/2007 9:13 PM
To: kyungmin.park@samsung.com
Cc: Linux-omap-open-source@linux.omap.com
Subject: Re: [RFC] TSC2101 support


It would replace the h2, h3, h6300 touchscreen driver in
drivers/input/touchscreen/omap/ directory. (omapts.c and ts_hx.c).
But if that can be made to work with h2 and h3, I think it would be fine.

Byteway, what about the support for the temperature, battery and aux
registers that are supported at least by some of the devices?
My understanding is that the reading of temperature, battery and aux
data values that the tsc2101 page0 must be handled in the same driver
than the reading of the touchscreen related info. (one must ask the
tsc2101 to give those values and once ready, tsc2101 sends interrupt and
we must check from the status register (01) from page1 informs whether
those values are readable or whether the interrupt was touchscreen press
related.)
I did that once by hacking the omapts.c ts_hx.c framework but the
resulting code was not pretty due to big changes in omapts.c which broke
all others ts drivers relying to omapts.c Do you have any code for doing
the read of those values with the new driver?

And if the ts is transfered to use SPI framework, maybe the same should
be done also for the omap-alsa-tsc2101. (It is currently relying on to
drivers/ssi/omap-tsc2101.c) I could volunteer in that if I manage to get
my h6300 kernel updated from 2.6.16 to latest...

Mika

Kyungmin Park wrote:
> Hi,
>
> A few days ago, Nokia released the their N800 source code. and I found the TSC2301 source code. it's similar with TSC2101 except keypad, and some registers.
>
> Now the TSC2101 chip is used in H4 and apollon. So I modified the TSC2301 source code to run TSC2101 chip for quick enabling test.
> However the TSC2101 use 32-bit spi protocol instead of 16-bit in TSC2301. So we have to modify spi part for 32-bit. but it's main strutures are same.
>
> In my opinion, the TSC2301 is not merged in omap tree. So if you don't mind we commit TSC2101 first, and after TSC2301 is merged. we  make one driver to support both.
>
> I want to listen your opinions what is better approache
>
> Thank you,
> Kyungmin Park
>


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]