TSC2101/2102

DISCUSSION Imre Deak 10 participants 35 messages Mar 9, 2007 – Apr 3, 2007

Subsystems (8)

Arm (32-bit) Sound Arm sub-architectures Framebuffer layer +4 more subsystems

lore

Share & tools

lore

Imre Deak

author

2007-03-09 14:06 UTC #0 lore raw

Hi,

I'm wondering about the proper way to convert the existing omap-tsc2101 driver to the SPI framework. Would it make sense to handle it with the tsc2102 driver? omap-tsc2101 has only the register read / write interface which is the same as in tsc2102.

Are you planning to do this? I'd need to access the tsc2101 from another driver.

--Imre

andrzej zaborowski

2007-03-09 14:23 UTC #1 lore raw

Hiya,

Quoted 4 lines · Imre Deak

I'm wondering about the proper way to convert the existing omap-tsc2101 driver to the SPI framework. Would it make sense to handle it with the tsc2102 driver? omap-tsc2101 has only the register read / write interface which is the same as in tsc2102.

How about maybe a header file <linux/spi/tsc2xxx.h> shared between tsc2101/2102 with the register access functions as "static inline" functions?

Regards,
Andrew

Nishanth Menon

2007-03-14 13:21 UTC #2 lore raw

andrzej zaborowski stated on 3/9/2007 8:23 AM:

Quoted 10 lines · Imre Deak

Quoted 5 lines
I'm wondering about the proper way to convert the existing omap-tsc2101 driver to the SPI framework. Would it make sense to handle it with the tsc2102 driver? omap-tsc2101 has only the register read / write interface
which is the same as in tsc2102.
How about maybe a header file <linux/spi/tsc2xxx.h> shared between tsc2101/2102 with the register access functions as "static inline" functions?

Some TODOs:
1. should interrupt muxing be done here?
2. There are some TSC2005 devices(TS only).. so it will be interesting to see xxxx.h scales to all..
3. rename this to tsc2xxx_core.[ch]
4. use SPI framework (would not break uwire support I believe). Regards,
Nishanth Menon

Imre Deak

author

2007-03-14 17:09 UTC #3 lore raw

Quoted 11 lines · Nishanth Menon

andrzej zaborowski stated on 3/9/2007 8:23 AM:
Quoted 10 lines · Imre Deak
Quoted 5 lines
I'm wondering about the proper way to convert the existing omap-tsc2101 driver to the SPI framework. Would it make sense to handle it with the tsc2102 driver? omap-tsc2101 has only the register read / write interface
which is the same as in tsc2102.
How about maybe a header file <linux/spi/tsc2xxx.h> shared between tsc2101/2102 with the register access functions as "static inline" functions?

Quoted 6 lines

Some TODOs:
1. should interrupt muxing be done here?
2. There are some TSC2005 devices(TS only).. so it will be interesting to see xxxx.h scales to all..
3. rename this to tsc2xxx_core.[ch]
4. use SPI framework (would not break uwire support I believe).

The attached patches try to do #4. Please review it / sign it off as necessary.

There is an upcoming TSC2301 patch, that should also be taken into account when creating a tsc2xxx-core.[ch] based on the existing TSC driver implementations.

--Imre

Quoted 1 line

From 3ac516c27d9d8facf1ac925e1444984849208678 Mon Sep 17 00:00:00 2001

From: Imre Deak <[email protected]>
Date: Wed, 14 Mar 2007 18:57:44 +0200
Subject: [PATCH] TSC2101: convert existing driver to use the SPI framework

The new driver is functionally the same as the old drivers/ssi/omap-tsc2101 driver.

Signed-off-by Imre Deak <[email protected]>

---
 drivers/spi/Kconfig         |    8 +
 drivers/spi/Makefile        |    1 +
 drivers/spi/tsc2101.c       |  316 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/spi/tsc2101.h |   43 ++++++
 4 files changed, 368 insertions(+), 0 deletions(-)
 create mode 100644 drivers/spi/tsc2101.c
 create mode 100644 include/linux/spi/tsc2101.h

drivers/spi/Kconfig +8 -0

index bde6231..e9b871f 100644
@@ -149,6 +149,14 @@ config SPI_OMAP24XX
 comment "SPI Protocol Masters"
 	depends on SPI_MASTER
 
+config TSC2101
+	depends on SPI_MASTER
+	tristate "TSC2101 chip support"
+	---help---
+	  Say Y here if you want support for the TSC2101 chip.
+	  At the moment it provides basic register read / write interface
+	  as well as a way to enable the MCLK clock.
+
 config TSC2102
 	depends on SPI_MASTER
 	tristate "TSC2102 codec support"

drivers/spi/Makefile +1 -0

index 6d84bac..822121a 100644
@@ -24,6 +24,7 @@ obj-$(CONFIG_SPI_OMAP_UWIRE)		+= omap_uwire.o
 # 	... add above this line ...
 
 # SPI protocol drivers (device/link on bus)
+obj-$(CONFIG_TSC2101)			+= tsc2101.o
 obj-$(CONFIG_TSC2102)			+= tsc2102.o
 obj-$(CONFIG_SPI_AT25)		+= at25.o
 # 	... add above this line ...

drivers/spi/tsc2101.c new file +316 -0

316 lines not on this page · raw message

include/linux/spi/tsc2101.h new file +43 -0

43 lines not on this page · raw message

Signature · 1 line

1.5.0.rc3

Quoted 1 line

From 9c10561f8acef67715e635842bd06e189607c5d2 Mon Sep 17 00:00:00 2001

From: Imre Deak <[email protected]>
Date: Wed, 14 Mar 2007 17:52:42 +0200
Subject: [PATCH] ARM: OMAP: TSC2101: add platform init / registration to board files

H2 / H3 boards use this chip, update their board files.

Signed-off-by Imre Deak <[email protected]>

---
 arch/arm/mach-omap1/board-h2.c |   77 +++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap1/board-h3.c |   88 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 165 insertions(+), 0 deletions(-)

arch/arm/mach-omap1/board-h2.c +77 -0

95 lines not on this page · raw message

arch/arm/mach-omap1/board-h3.c +88 -0

106 lines not on this page · raw message

Signature · 1 line

1.5.0.rc3

Quoted 1 line

From 6c5d62dc669071afb2f4a7e8d1514c13ddc8a7b9 Mon Sep 17 00:00:00 2001

From: Imre Deak <[email protected]>
Date: Wed, 14 Mar 2007 18:06:26 +0200
Subject: [PATCH] ARM: OMAP: update H2 / H3 defconfig

Enable the new TSC2101 driver.

Signed-off-by Imre Deak <[email protected]>

---
 arch/arm/configs/omap_h2_1610_defconfig |   86 +++++--
 arch/arm/configs/omap_h3_1710_defconfig |  410 +++++++++++++++++++++++--------
 2 files changed, 372 insertions(+), 124 deletions(-)

arch/arm/configs/omap_h2_1610_defconfig +64 ~~-22~~

309 lines not on this page · raw message

arch/arm/configs/omap_h3_1710_defconfig +308 ~~-102~~

916 lines not on this page · raw message

Signature · 1 line

1.5.0.rc3

Dirk Behme

2007-03-14 20:35 UTC #4 lore raw

Quoted 24 lines · Imre Deak

Quoted 14 lines · Nishanth Menon
andrzej zaborowski stated on 3/9/2007 8:23 AM:
Quoted 11 lines · Imre Deak
Quoted 6 lines
I'm wondering about the proper way to convert the existing omap-tsc2101 driver to the SPI framework. Would it make sense to handle it with the tsc2102 driver? omap-tsc2101 has only the register read / write interface
which is the same as in tsc2102.
How about maybe a header file <linux/spi/tsc2xxx.h> shared between tsc2101/2102 with the register access functions as "static inline" functions?
Quoted 6 lines
Some TODOs:
1. should interrupt muxing be done here?
2. There are some TSC2005 devices(TS only).. so it will be interesting to see xxxx.h scales to all..
3. rename this to tsc2xxx_core.[ch]
4. use SPI framework (would not break uwire support I believe).

Quoted 2 lines

The attached patches try to do #4. Please review it / sign it off as necessary.

Great! Many thanks.

Is this already sufficient to remove drivers/ssi/omap-tsc2101.[ch]? If yes, I would propose to apply this to get rid of tsc in ssi directory as fast as possible. And, in parallel, we can use this as starting point for further improvements as mentioned above.

Dirk

Kyungmin Park

2007-03-15 01:18 UTC #5 lore raw

In reply to Imre Deak

Hi,

Quoted 21 lines · Nishanth Menon

Quoted 8 lines
andrzej zaborowski stated on 3/9/2007 8:23 AM:
Quoted 7 lines · Imre Deak
Quoted 5 lines
I'm wondering about the proper way to convert the existing omap-tsc2101 driver to the SPI framework. Would it make sense to handle it with the
tsc2102 driver? omap-tsc2101 has only the register read / write interface which is the same as in tsc2102.
Quoted 6 lines
Quoted 3 lines
How about maybe a header file <linux/spi/tsc2xxx.h> shared between tsc2101/2102 with the register access functions as "static inline" functions?
Some TODOs:
1. should interrupt muxing be done here?
2. There are some TSC2005 devices(TS only).. so it will be
interesting
Quoted 3 lines
to see xxxx.h scales to all..
3. rename this to tsc2xxx_core.[ch]
4. use SPI framework (would not break uwire support I believe).

Quoted 7 lines

The attached patches try to do #4. Please review it / sign it off as necessary.
There is an upcoming TSC2301 patch, that should also be taken into account when creating a tsc2xxx-core.[ch] based on the existing TSC driver implementations.

Cool!!!

In the previous time, I implemented the tsc2101 on OMAP2 based on tsc2301.
[1]
The current code only supports 16-bit tsc2101 for OMAP1.
We have to consider OMAP2 tsc2101 for H4 and apollon.

Here's simple changes.

+struct tsc2101_platform_data {

+       int     (*init)(struct spi_device *spi);
+       void    (*cleanup)(struct spi_device *spi);
+       void    (*enable_mclk)(struct spi_device *spi);
+       void    (*disable_mclk)(struct spi_device *spi);

+ int bits_per_word;

+};

How about to add 'bits_per_word' to platform. So if the bits_per_word is empty. it assumes it will use 16-bit, otherwise we use it provided from platform.

+struct tsc2101_device {

+       struct mutex            mutex;
+       int                     mclk_enabled;
+       struct clock            *mclk_ck;
+       struct spi_message      message;
+       struct spi_transfer     transfer[2];
+       u16                     command;
+       void                    (*enable_mclk)(struct spi_device *spi);
+       void                    (*disable_mclk)(struct spi_device *spi);

+ int 32bit_shift; /* 16 if 32-bit bus, otherwise 0 */

+};

Please change the command from u16 to u32. Umm, I'm not sure we have to change the parameter from u16 *data to u32 *data.

I will check it.

Thank you,
Kyungmin Park

1. http://linux.omap.com/pipermail/linux-omap-open-source/2007-
January/008933.html

Imre Deak

author

2007-03-15 10:23 UTC #6 lore raw

Hi,

Quoted 4 lines · Kyungmin Park

[...]
In the previous time, I implemented the tsc2101 on OMAP2 based on tsc2301.
[1]

I needed only the basic register read / write interface to access the TSC2101 GPIO lines. The TS part you wrote is still needed, it's init function being called from the tsc2101.c probe, as it's done in tsc2301-core.c.

Quoted 2 lines

The current code only supports 16-bit tsc2101 for OMAP1. We have to consider OMAP2 tsc2101 for H4 and apollon.

Is the 32-bit interface some alternate interface configuration for the chip? In the TSC2101 spec I found at least only a description of the 16-bit protocoll. Could you point to a documentation for this?

--Imre

Quoted 42 lines

Here's simple changes.

include/linux/spi/tsc2101.h new file +7 -0

+struct tsc2101_platform_data {
+       int     (*init)(struct spi_device *spi);
+       void    (*cleanup)(struct spi_device *spi);
+       void    (*enable_mclk)(struct spi_device *spi);
+       void    (*disable_mclk)(struct spi_device *spi);
 
+       int       bits_per_word;
 
+};

How about to add 'bits_per_word' to platform. So if the bits_per_word is empty. it assumes it will use 16-bit, otherwise we use it provided from platform.

drivers/spi/tsc2101.c new file +11 -0

+struct tsc2101_device {
+       struct mutex            mutex;
+       int                     mclk_enabled;
+       struct clock            *mclk_ck;
+       struct spi_message      message;
+       struct spi_transfer     transfer[2];
+       u16                     command;
+       void                    (*enable_mclk)(struct spi_device *spi);
+       void                    (*disable_mclk)(struct spi_device *spi);
 
+       int		32bit_shift;	/* 16 if 32-bit bus, otherwise 0 */
 
+};

Please change the command from u16 to u32. Umm, I'm not sure we have to change the parameter from u16 *data to u32 *data.

I will check it.

Thank you,
Kyungmin Park

1. http://linux.omap.com/pipermail/linux-omap-open-source/2007-
January/008933.html

Raja Mallik

2007-03-15 14:23 UTC #7 lore raw

Regarding use of DirectFB

Hi All,

I am working on to run some DirectFB application on my board that has omap5912 core. I am using linux-2.6.20 git kernel port and arm toolchain built with gcc-4.1.2, bin utils-2.17, glibc-2.5.

We found that Ti' omap frame buffer is working fine.
Has there been any port of directfb applications running on omap5912?

Pl, share your reference..

-Raja Mallik

Cliff Brake

2007-03-15 17:09 UTC #8 lore raw

Re: Regarding use of DirectFB

Quoted 6 lines · Raja Mallik

I am working on to run some DirectFB application on my board that has omap5912 core. I am using linux-2.6.20 git kernel port and arm toolchain built with gcc-4.1.2, bin utils-2.17, glibc-2.5.
We found that Ti' omap frame buffer is working fine.
Has there been any port of directfb applications running on omap5912?

http://openembedded.org supports directfb, and I have heard reports that people are successfully using it on PXA270 based systems. I suspect directfb apps would also run fine on omap.

Cliff

Signature · 3 lines

=======================
Cliff Brake
http://bec-systems.com

Kyungmin Park

2007-03-16 00:28 UTC #9 lore raw

In reply to Imre Deak

Hi,

Quoted 11 lines

I needed only the basic register read / write interface to access the TSC2101 GPIO lines. The TS part you wrote is still needed, it's init function being called from the tsc2101.c probe, as it's done in tsc2301-core.c.
Quoted 2 lines
The current code only supports 16-bit tsc2101 for OMAP1. We have to consider OMAP2 tsc2101 for H4 and apollon.
Is the 32-bit interface some alternate interface
configuration for the chip?

No. it's only needed in SPI protocol.

I don't know it's possible to use 16-bit mode in OMAP2. but most driver which uses tsc2101 on OMAP2 uses 32-bit access.

Thank you,
Kyungmin Park

Imre Deak

author

2007-03-16 07:41 UTC #10 lore raw

Quoted 11 lines · Kyungmin Park

Hi,
Quoted 9 lines
I needed only the basic register read / write interface to access the TSC2101 GPIO lines. The TS part you wrote is still needed, it's init function being called from the tsc2101.c probe, as it's done in tsc2301-core.c.
Quoted 2 lines
The current code only supports 16-bit tsc2101 for OMAP1. We have to consider OMAP2 tsc2101 for H4 and apollon.

Quoted 7 lines

Quoted 2 lines
Is the 32-bit interface some alternate interface
configuration for the chip?
No. it's only needed in SPI protocol.
I don't know it's possible to use 16-bit mode in OMAP2. but most driver which uses tsc2101 on OMAP2 uses 32-bit access.

The following is an example how you setup the transfer for 32-bit transfer:

+static void tsc2101_ts_setup_spi_xfer(struct tsc2101 *tsc) +{
+ struct tsc2101_ts *ts = tsc->ts;
+ struct spi_message *m = &ts->read_msg;
+ struct spi_transfer *x = &ts->read_xfer[0];
+

+	ts->address[0] = (0x8000 | TSC2101_REG_X) << 16;
+	ts->address[1] = (0x8000 | TSC2101_REG_Y) << 16;
+	ts->address[2] = (0x8000 | TSC2101_REG_Z1) << 16;
+	ts->address[3] = (0x8000 | TSC2101_REG_Z2) << 16;

+
+ spi_message_init(m);
+
+ x->tx_buf = &ts->address;
+ x->rx_buf = &ts->data;
+ x->len = 16;
+ spi_message_add_tail(x, m);
+
+ m->complete = tsc2101_ts_rx;
+ m->context = tsc;
+}

While this may work, I'm not sure the driver should have support for such an alternate protocol. What's the benifit of it? The TSC2xxx chips have a register address auto increment feature, so you need to send only the starting address and then do a read for each consecutive registers. Did you try the 16-bit mode in SPI_MODE_0 as it's done in the TSC2301 driver?

--Imre

Kyungmin Park

2007-03-16 08:05 UTC #11 lore raw

Quoted 45 lines

Quoted 5 lines
Quoted 5 lines
I needed only the basic register read / write interface to access the
TSC2101 GPIO lines. The TS part you wrote is still
needed, it's init
Quoted 7 lines
Quoted 7 lines
function being called from the tsc2101.c probe, as it's done in tsc2301-core.c.
Quoted 2 lines
The current code only supports 16-bit tsc2101 for OMAP1. We have to consider OMAP2 tsc2101 for H4 and apollon.
Is the 32-bit interface some alternate interface
configuration for
Quoted 6 lines
Quoted 1 line
the chip?
No. it's only needed in SPI protocol.
I don't know it's possible to use 16-bit mode in OMAP2. but most driver which uses tsc2101 on OMAP2 uses 32-bit access.
The following is an example how you setup the transfer for 32-bit transfer:
(quoted diff) +20 -0
+static void tsc2101_ts_setup_spi_xfer(struct tsc2101 *tsc) {
+	struct tsc2101_ts *ts = tsc->ts;
+	struct spi_message *m = &ts->read_msg;
+	struct spi_transfer *x = &ts->read_xfer[0];
+
+	ts->address[0] = (0x8000 | TSC2101_REG_X) << 16;
+	ts->address[1] = (0x8000 | TSC2101_REG_Y) << 16;
+	ts->address[2] = (0x8000 | TSC2101_REG_Z1) << 16;
+	ts->address[3] = (0x8000 | TSC2101_REG_Z2) << 16;
+
+	spi_message_init(m);
+
+	x->tx_buf = &ts->address;
+	x->rx_buf = &ts->data;
+	x->len = 16;
+	spi_message_add_tail(x, m);
+
+	m->complete = tsc2101_ts_rx;
+	m->context = tsc;
+}

Quoted 6 lines

While this may work, I'm not sure the driver should have support for such an alternate protocol. What's the benifit of it? The TSC2xxx chips have a register address auto increment feature, so you need to send only the starting address and then do a read for each consecutive registers. Did you try the 16-bit mode in SPI_MODE_0 as it's done in the TSC2301 driver?

No, it's not work if we provide the one address

/* XXX: tsc2101 specific */

static const u32 tsc2101_ts_read_data[4] = {
        (0x8000 | TSC2101_REG_X) << 16,
        (0x8000 | TSC2101_REG_Y) << 16,
        (0x8000 | TSC2101_REG_Z1) << 16,
        (0x8000 | TSC2101_REG_Z2) << 16,
};

static void tsc2101_ts_setup_spi_xfer(struct tsc2101 *tsc)

{
        struct tsc2101_ts *ts = tsc->ts;
        struct spi_message *m = &ts->read_msg;
        struct spi_transfer *x = &ts->read_xfer[0];

        spi_message_init(m);

        x->tx_buf = &tsc2101_ts_read_data;
        x->rx_buf = &ts->data;
        x->len = 16;
        spi_message_add_tail(x, m);

        m->complete = tsc2101_ts_rx;
        m->context = tsc;
}

No, I don't try to use 16-bit mode. since it's working well 32-bit mode, I just use it for a long time.

Thank you,
Kyungmin Park

Imre Deak

author

2007-03-16 09:49 UTC #12 lore raw

Quoted 79 lines · Kyungmin Park

Quoted 45 lines
Quoted 5 lines
Quoted 5 lines
I needed only the basic register read / write interface to access the
TSC2101 GPIO lines. The TS part you wrote is still
needed, it's init
Quoted 7 lines
Quoted 7 lines
function being called from the tsc2101.c probe, as it's done in tsc2301-core.c.
Quoted 2 lines
The current code only supports 16-bit tsc2101 for OMAP1. We have to consider OMAP2 tsc2101 for H4 and apollon.
Is the 32-bit interface some alternate interface
configuration for
Quoted 6 lines
Quoted 1 line
the chip?
No. it's only needed in SPI protocol.
I don't know it's possible to use 16-bit mode in OMAP2. but most driver which uses tsc2101 on OMAP2 uses 32-bit access.
The following is an example how you setup the transfer for 32-bit transfer:
(quoted diff) +20 -0
+static void tsc2101_ts_setup_spi_xfer(struct tsc2101 *tsc) {
+	struct tsc2101_ts *ts = tsc->ts;
+	struct spi_message *m = &ts->read_msg;
+	struct spi_transfer *x = &ts->read_xfer[0];
+
+	ts->address[0] = (0x8000 | TSC2101_REG_X) << 16;
+	ts->address[1] = (0x8000 | TSC2101_REG_Y) << 16;
+	ts->address[2] = (0x8000 | TSC2101_REG_Z1) << 16;
+	ts->address[3] = (0x8000 | TSC2101_REG_Z2) << 16;
+
+	spi_message_init(m);
+
+	x->tx_buf = &ts->address;
+	x->rx_buf = &ts->data;
+	x->len = 16;
+	spi_message_add_tail(x, m);
+
+	m->complete = tsc2101_ts_rx;
+	m->context = tsc;
+}
Quoted 6 lines
While this may work, I'm not sure the driver should have support for such an alternate protocol. What's the benifit of it? The TSC2xxx chips have a register address auto increment feature, so you need to send only the starting address and then do a read for each consecutive registers. Did you try the 16-bit mode in SPI_MODE_0 as it's done in the TSC2301 driver?
No, it's not work if we provide the one address
/* XXX: tsc2101 specific */
static const u32 tsc2101_ts_read_data[4] = {
        (0x8000 | TSC2101_REG_X) << 16,
        (0x8000 | TSC2101_REG_Y) << 16,
        (0x8000 | TSC2101_REG_Z1) << 16,
        (0x8000 | TSC2101_REG_Z2) << 16,
};
static void tsc2101_ts_setup_spi_xfer(struct tsc2101 *tsc)
{
        struct tsc2101_ts *ts = tsc->ts;
        struct spi_message *m = &ts->read_msg;
        struct spi_transfer *x = &ts->read_xfer[0];

        spi_message_init(m);

        x->tx_buf = &tsc2101_ts_read_data;
        x->rx_buf = &ts->data;
        x->len = 16;
        spi_message_add_tail(x, m);

        m->complete = tsc2101_ts_rx;
        m->context = tsc;
}

Quoted 2 lines

No, I don't try to use 16-bit mode. since it's working well 32-bit mode, I just use it for a long time.

Could you try it with debugging enabled in omap2_mcspi? Would be interesting to see where the problem is.

--Imre

Quoted 1 line

Kyungmin Park

2007-03-19 02:02 UTC #13 lore raw

Hi Imre Deak,

Quoted 4 lines

Could you try it with debugging enabled in omap2_mcspi? Would be interesting
to see where the problem is.

Before read/write I set the these values for TSC2101 intialization

write-32 08600016
write-32 08a00008
write-32 08400000
write-32 09a00900
write-32 08204000
write-32 08008bf4

If we set four read data

write-32 80000000
read-32 ffff0a9b
write-32 80200000
read-32 ffff064f
write-32 80400000
read-32 ffff055f
write-32 80600000
read-32 ffff0deb

and if not

write-32 80000000
read-32 ffff0c4b
write-32 70616d6f
read-32 ffffffff
write-32 6364755f
read-32 ffffffff
write-32 00000000
read-32 ffffffff
--repeat forever--

I think tsc2101 increase the its address automatically. but it's not work at 32- bit mode.
I also tried to change the format and values "tsc2101_ts_read_data" but it's same situation.

Ah, a few days ago, tsc2301 driver is merged in omap tree. Why don't you consider the tsc2301 driver too?
Because I tried to use tsc2102 driver before, but it's not work well. but tsc2301 is working well.

tsc2xxx driver? I heard tsc2301 is super set of tsc210x, (the bigger chip number, the more functions)

There's some issue related with omap2_mcspi inferface.
If I use the 32-bit mode, it required the 32-bit data buffer address. so we mask the read results like this

static void tsc2101_ts_rx(void *arg)

{
        x  = ts->data[0] & 0xffff;
        y  = ts->data[1] & 0xffff;
        z1 = ts->data[2] & 0xffff;
        z2 = ts->data[3] & 0xffff;
}

What's the better approcahes to address this problem?
1. modify the omap2_mcspi source
2. mask the results
3. others.

Thank you,
Kyungmin Park

Jarkko Nikula

2007-03-19 07:37 UTC #14 lore raw

Quoted 2 lines · On Mon, 19 Mar 2007 11:02:30 +0900 "ext Kyungmin Park" <[email protected]>…

Ah, a few days ago, tsc2301 driver is merged in omap tree. Why don't you consider the tsc2301 driver too?

Hmm... from where I could find the tsc2301 driver from omap tree? Just started to wonder has someone already pushed it there :-)

My copy of the tree is from ftp://www.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git. Is it rebased correctly? E.g. last commit in master branch is from "Fri Feb 16" but "Wed Mar 7" in omap-drivers.

We have some kind of working version of 2301 driver with subdrivers separated to proper kernel directories (drivers/input/touchscreen, sound/soc/codecs) but e.g. audio part is not yet actual ASoC driver.

Quoted 3 lines

tsc2xxx driver? I heard tsc2301 is super set of tsc210x, (the bigger chip number, the more functions)

I had a short look to TSC2101 spec and at least audio parts of TSC230x and TSC2101 are not compatible. Different block diagrams and most/all of the audio registers.

http://www.ti.com/lit/gpn/tsc2101
http://www.ti.com/lit/gpn/tsc2301

Jarkko

Kyungmin Park

2007-03-19 08:04 UTC #15 lore raw

Quoted 8 lines

Quoted 1 line · On Mon, 19 Mar 2007 11:02:30 +0900 "ext Kyungmin Park" <[email protected]>…
Ah, a few days ago, tsc2301 driver is merged in omap tree.
Why don't you
Quoted 1 line
consider the tsc2301 driver too?

Quoted 7 lines

Hmm... from where I could find the tsc2301 driver from omap tree? Just started to wonder has someone already pushed it there :-)
My copy of the tree is from ftp://www.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-oma p-2.6.git. Is it rebased correctly? E.g. last commit in master branch is from "Fri Feb 16" but "Wed Mar 7" in omap-drivers.

I usually use the omap git tree in mvista.
http://source.mvista.com/git/gitweb.cgi?p=linux-omap-
2.6.git;a=commit;h=a7b9b17c9025066cd05f555bbba5542bcf16df3a it was commited at Tue, 13 Mar.

Quoted 8 lines

We have some kind of working version of 2301 driver with subdrivers separated to proper kernel directories (drivers/input/touchscreen, sound/soc/codecs) but e.g. audio part is not yet actual ASoC driver.
Quoted 1 line
tsc2xxx driver? I heard tsc2301 is super set of tsc210x,
(the bigger chip

Quoted 8 lines

Quoted 2 lines
number, the more functions)
I had a short look to TSC2101 spec and at least audio parts of TSC230x and TSC2101 are not compatible. Different block diagrams and most/all of the audio registers.
http://www.ti.com/lit/gpn/tsc2101
http://www.ti.com/lit/gpn/tsc2301

Yes, I knew it. I also suffered because of its different registers.

In my opinion, As OMAP CPU registers. it has common registers and chip specific ones.
So we can define it at least headers files.

# common parts

TSC2XXX_TS_X,
TSC2XXX_TS_Y,

# chip specific parts
 TSC21XX_AUDIO_CTRL1.
 TSC23XX_AUDIO_CTRL1,

I will send the tsc2101 patch based on tsc2301 files. I think it's complicted with Imre's tsc2101 patch.

Thank you,
Kyungmin Park

Jarkko Nikula

2007-03-19 08:37 UTC #16 lore raw

Quoted 10 lines · On Mon, 19 Mar 2007 17:04:55 +0900 "ext Kyungmin Park" <[email protected]>…

Quoted 4 lines
My copy of the tree is from ftp://www.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-oma p-2.6.git. Is it rebased correctly? E.g. last commit in master branch is from "Fri Feb 16" but "Wed Mar 7" in omap-drivers.
I usually use the omap git tree in mvista.
http://source.mvista.com/git/gitweb.cgi?p=linux-omap-
2.6.git;a=commit;h=a7b9b17c9025066cd05f555bbba5542bcf16df3a it was commited at Tue, 13 Mar.

I'll see. That pushed version wasn't very good one. It didn't compile without warnings, etc. I'll send soon few patches in top of it.

Tony, any plans to keep sync kernel.org and mvista.com trees?

Quoted 3 lines

I will send the tsc2101 patch based on tsc2301 files. I think it's complicted with Imre's tsc2101 patch.

How about just keeping both of them separated including config names, header files, etc. for awhile until both are pushed & working. Bit easier first step for us I think :-)

Jarkko

[email protected]

maintainer

2007-03-19 19:22 UTC #17 lore raw

Quoted 2 lines · Jarkko Nikula

Tony, any plans to keep sync kernel.org and mvista.com trees?

Yeah, sorry I was at a conference last week and my net access was spotty. Working on updating to trees to 2.6.21-rc4 now, and will also update kernel.org tree then.

Tony

Kyungmin Park

2007-03-20 01:46 UTC #18 lore raw

In reply to Jarkko Nikula

Quoted 8 lines

Quoted 2 lines
I will send the tsc2101 patch based on tsc2301 files. I
think it's complicted
Quoted 2 lines
with Imre's tsc2101 patch.
How about just keeping both of them separated including config names, header files, etc. for awhile until both are pushed & working. Bit easier first step for us I think :-)

I agree.

Here's tsc2101 patch. It includes the tsc2101 spi functions and touchscreen part.
It's similary with your updated pache style.

I think it's not compatible with OMAP1 touchscreen in touchscreen/omap. But I added the 16-bit bus handling part. It needs to be check.

Umm the new updated git tree don't have tsc2301 commit. maybe it's missing :)

Here's sample configuration at apollon.

arch/arm/mach-omap2/board- renamed from arch/arm/mach-omap2/board-apollon.c +0 -0

apollon.c
index 5488961..4f2ea29 100644

arch/arm/mach-omap2/board-apollon.c +33 -1

@@ -24,9 +24,10 @@
 #include <linux/mtd/onenand.h>
 #include <linux/irq.h>
 #include <linux/interrupt.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/tsc2101.h>
 #include <linux/delay.h>
 #include <linux/leds.h>
-#include <linux/irq.h>
 #include <linux/err.h>
 #include <linux/clk.h>

@@ -42,6 +43,7 @@
 #include <asm/arch/board.h>
 #include <asm/arch/common.h>
 #include <asm/arch/gpmc.h>
+#include <asm/arch/mcspi.h>
 #include "prcm-regs.h"
 
 /* LED & Switch macros */

@@ -51,6 +53,7 @@
 #define SW_ENTER_GPIO16                16
 #define SW_UP_GPIO17           17
 #define SW_DOWN_GPIO58         58
+#define PINTDAV_GPIO85         85
 
 #define APOLLON_FLASH_CS       0
 #define APOLLON_ETH_CS         1

@@ -358,6 +361,33 @@ static void __init apollon_usb_init(void)
        omap_set_gpio_dataout(12, 0);
 }
 
+static struct omap2_mcspi_device_config tsc2101_mcspi_config = {
+       .turbo_mode             = 0,
+       .single_channel         = 0,
+};
+
+static struct tsc2101_platform_data tsc2101_platform_config = {
+       /* Bus */
+       .bits_per_word          = 32,
+
+       /* Touchscreen */
+       .dav_gpio               = PINTDAV_GPIO85,
+       .ts_x_plate_ohm         = 200,
+       .ts_stab_time           = 500,          /* 500 usec */
+       .ts_hw_avg              = 16,
+};
+
+static struct spi_board_info apollon_spi_board_info[] __initdata = {
+       [0] = {
+               .modalias               = "tsc2101",
+               .bus_num                = 1,
+               .chip_select            = 0,
+               .max_speed_hz           = 6000000,
+               .controller_data        = &tsc2101_mcspi_config,
+               .platform_data          = &tsc2101_platform_config,
+       },
+};
+
 static void __init omap_apollon_init(void)
 {
        apollon_led_init();

@@ -373,6 +403,8 @@ static void __init omap_apollon_init(void)
         * You have to mux them off in device drivers later on
         * if not needed.
         */
+       spi_register_board_info(apollon_spi_board_info,
+                               ARRAY_SIZE(apollon_spi_board_info));
        platform_add_devices(apollon_devices, ARRAY_SIZE(apollon_devices));
        omap_board_config = apollon_config;
        omap_board_config_size = ARRAY_SIZE(apollon_config);

Thank you,
Kyungmin Park

drivers/input/touchscreen/Kconfig +13 -0

index 6b46c9b..da5caea 100644
@@ -159,4 +159,17 @@ config TOUCHSCREEN_UCB1400
 	  To compile this driver as a module, choose M here: the
 	  module will be called ucb1400_ts.
 
+config TOUCHSCREEN_TSC2101
+	tristate "TSC2101 touchscreen support"
+	depends on SPI_TSC2101
+	help
+	  Say Y here if you have a touchscreen interface using the
+	  TSC2101 controller, and your board-specific initialization
+	  code includes that in its table of SPI devices.
+
+	  If unsure, say N (but it's safe to say "Y").
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called tsc2101_ts.
+
 endif

drivers/input/touchscreen/Makefile +1 -0

index 061bc14..973154b 100644
@@ -16,5 +16,6 @@ obj-$(CONFIG_TOUCHSCREEN_PENMOUNT)	+= penmount.o
 obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT)	+= touchright.o
 obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN)	+= touchwin.o
 obj-$(CONFIG_TOUCHSCREEN_UCB1400)	+= ucb1400_ts.o
+obj-$(CONFIG_TOUCHSCREEN_TSC2101)	+= tsc2101_ts.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2102)	+= tsc2102_ts.o
 obj-$(CONFIG_TOUCHSCREEN_OMAP)	+= omap/

drivers/input/touchscreen/tsc2101_ts.c new file +715 -0

715 lines not on this page · raw message

drivers/spi/Kconfig +15 -0

index c98392c..64f59e0 100644
@@ -149,6 +149,21 @@ config SPI_OMAP24XX
 comment "SPI Protocol Masters"
 	depends on SPI_MASTER
 
+config SPI_TSC2101
+	tristate "TSC2101 driver"
+	depends on SPI_MASTER
+	help
+	  Say Y here if you have a TSC2101 chip connected to a SPI
+	  bus on your board.
+
+	  The TSC2101 is a highly integrated PDA analog interface circuit.
+	  It contains a complete 12-bit A/D resistive touch screen
+	  converter (ADC) including drivers, touch pressure measurement
+	  capability.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called tsc2101.
+
 config TSC2102
 	depends on SPI_MASTER
 	tristate "TSC2102 codec support"

drivers/spi/Makefile +1 -0

index bfa8ea3..810ff0f 100644
@@ -24,6 +24,7 @@ obj-$(CONFIG_SPI_OMAP_UWIRE)		+= omap_uwire.o
 # 	... add above this line ...
 
 # SPI protocol drivers (device/link on bus)
+obj-$(CONFIG_SPI_TSC2101)		+= tsc2101.o
 obj-$(CONFIG_TSC2102)			+= tsc2102.o
 obj-$(CONFIG_SPI_AT25)		+= at25.o
 obj-$(CONFIG_SPI_TSC2301)		+= tsc2301.o

drivers/spi/tsc2101.c new file +280 -0

280 lines not on this page · raw message

include/linux/spi/tsc2101.h new file +203 -0

203 lines not on this page · raw message

[email protected]

maintainer

2007-03-20 13:27 UTC #19 lore raw

Hi,

Quoted 2 lines · Kyungmin Park

Umm the new updated git tree don't have tsc2301 commit. maybe it's missing :)

Just want to verify we haven't lost anything.. Are you talking about commit a7b9b17c9025066cd05f555bbba5542bcf16df3a or something else?

At least a7b9b17c9025066cd05f555bbba5542bcf16df3a is there, if it's some other commit you're talking about please let me know.

The commits in the master tree currently get buried easily as we have a long series of patches in omap-upstream and omap-drivers and I keep rebasing them continuously. This problem should disappear for most part once omap-upstream is merged into Linus' tree.

Regards,

Tony

Jarkko Nikula

2007-03-20 13:54 UTC #20 lore raw

Quoted 6 lines

Quoted 2 lines
Umm the new updated git tree don't have tsc2301 commit. maybe it's missing :)
Just want to verify we haven't lost anything.. Are you talking about commit a7b9b17c9025066cd05f555bbba5542bcf16df3a or something else?

Yep, that and some other recent commits were missing from linux-omap tree in kernel.org. Now both kernel.org and source.mvista.com linux-omap trees seems to be in sync.

Jarkko

Tony Lindgren

maintainer

2007-03-20 15:38 UTC #21 lore raw

Quoted 9 lines · Jarkko Nikula

Quoted 6 lines
Quoted 2 lines
Umm the new updated git tree don't have tsc2301 commit. maybe it's missing :)
Just want to verify we haven't lost anything.. Are you talking about commit a7b9b17c9025066cd05f555bbba5542bcf16df3a or something else?
Yep, that and some other recent commits were missing from linux-omap tree in kernel.org. Now both kernel.org and source.mvista.com linux-omap trees seems to be in sync.

OK, thanks for verifying. The kernel.org tree was out of sync for last week. In general they should be in sync though.

Tony

Eduardo Valentin

2007-03-21 19:24 UTC #22 lore raw

Hello all,

SPI API has changed. Following this discussion, this patch fixes OMAP H2 LCD initialization.

This patch (patch-lcd-h2-spi-fix.diff) applies on top of Imre Deak's patch (spi-tsc2101-patch.diff).

Signed-off-by Imre Deak <[email protected]>

Signed-off-by Eduardo Valentin <[email protected]>

--
Eduardo Valentin

Quoted 20 lines · Tony Lindgren

Quoted 9 lines · Jarkko Nikula
Quoted 6 lines
Quoted 2 lines
Umm the new updated git tree don't have tsc2301 commit. maybe it's missing :)
Just want to verify we haven't lost anything.. Are you talking about commit a7b9b17c9025066cd05f555bbba5542bcf16df3a or something else?
Yep, that and some other recent commits were missing from linux-omap tree in kernel.org. Now both kernel.org and source.mvista.com linux-omap trees seems to be in sync.
OK, thanks for verifying. The kernel.org tree was out of sync for last week. In general they should be in sync though.
Tony
_______________________________________________
Linux-omap-open-source mailing list
[email protected]
http://linux.omap.com/mailman/listinfo/linux-omap-open-source

Signature · 1 line

Eduardo Bezerra Valentin

arch/arm/configs/omap_h2_1610_defconfig +64 ~~-22~~

Index: linux-omap-2.6/arch/arm/configs/omap_h2_1610_defconfig
===================================================================
@@ -1,11 +1,14 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.20-rc3-omap1
-# Thu Jan  4 16:07:28 2007
+# Linux kernel version: 2.6.21-rc3-omap1
+# Tue Mar 13 14:36:54 2007
 #
 CONFIG_ARM=y
+CONFIG_SYS_SUPPORTS_APM_EMULATION=y
+CONFIG_GENERIC_GPIO=y
 # CONFIG_GENERIC_TIME is not set
 CONFIG_MMU=y
+# CONFIG_NO_IOPORT is not set
 CONFIG_GENERIC_HARDIRQS=y
 CONFIG_TRACE_IRQFLAGS_SUPPORT=y
 CONFIG_HARDIRQS_SW_RESEND=y

@@ -15,6 +18,7 @@ CONFIG_RWSEM_GENERIC_SPINLOCK=y
 # CONFIG_ARCH_HAS_ILOG2_U64 is not set
 CONFIG_GENERIC_HWEIGHT=y
 CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_ZONE_DMA=y
 CONFIG_VECTORS_BASE=0xffff0000
 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

@@ -33,6 +37,7 @@ CONFIG_LOCALVERSION_AUTO=y
 CONFIG_SWAP=y
 CONFIG_SYSVIPC=y
 # CONFIG_IPC_NS is not set
+CONFIG_SYSVIPC_SYSCTL=y
 # CONFIG_POSIX_MQUEUE is not set
 # CONFIG_BSD_PROCESS_ACCT is not set
 # CONFIG_TASKSTATS is not set

@@ -41,6 +46,7 @@ CONFIG_SYSVIPC=y
 # CONFIG_IKCONFIG is not set
 CONFIG_SYSFS_DEPRECATED=y
 # CONFIG_RELAY is not set
+CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE=""
 CONFIG_CC_OPTIMIZE_FOR_SIZE=y
 CONFIG_SYSCTL=y

@@ -120,6 +126,7 @@ CONFIG_DEFAULT_IOSCHED="anticipatory"
 # CONFIG_ARCH_IXP2000 is not set
 # CONFIG_ARCH_IXP23XX is not set
 # CONFIG_ARCH_L7200 is not set
+# CONFIG_ARCH_NS9XXX is not set
 # CONFIG_ARCH_PNX4008 is not set
 # CONFIG_ARCH_PXA is not set
 # CONFIG_ARCH_RPC is not set

@@ -149,6 +156,8 @@ CONFIG_OMAP_MUX_DEBUG=y
 CONFIG_OMAP_MUX_WARNINGS=y
 # CONFIG_OMAP_STI is not set
 CONFIG_OMAP_MCBSP=y
+# CONFIG_OMAP_MMU_FWK is not set
+# CONFIG_OMAP_MBOX_FWK is not set
 CONFIG_OMAP_MPU_TIMER=y
 # CONFIG_OMAP_32K_TIMER is not set
 # CONFIG_OMAP_DM_TIMER is not set

@@ -207,6 +216,7 @@ CONFIG_ARM_THUMB=y
 # CONFIG_CPU_DCACHE_DISABLE is not set
 # CONFIG_CPU_DCACHE_WRITETHROUGH is not set
 # CONFIG_CPU_CACHE_ROUND_ROBIN is not set
+# CONFIG_OUTER_CACHE is not set
 
 #
 # Bus support

@@ -234,6 +244,7 @@ CONFIG_FLAT_NODE_MEM_MAP=y
 # CONFIG_SPARSEMEM_STATIC is not set
 CONFIG_SPLIT_PTLOCK_CPUS=4096
 # CONFIG_RESOURCES_64BIT is not set
+CONFIG_ZONE_DMA_FLAG=1
 CONFIG_LEDS=y
 # CONFIG_LEDS_TIMER is not set
 # CONFIG_LEDS_CPU is not set

@@ -246,6 +257,7 @@ CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_CMDLINE="mem=32M console=ttyS0,115200n8 root=/dev/ram0 rw initrd=0x10600000,8M ramdisk_size=8192"
 # CONFIG_XIP_KERNEL is not set
+# CONFIG_KEXEC is not set
 
 #
 # CPU Frequency scaling

@@ -279,7 +291,7 @@ CONFIG_PM=y
 # CONFIG_PM_LEGACY is not set
 # CONFIG_PM_DEBUG is not set
 # CONFIG_PM_SYSFS_DEPRECATED is not set
-# CONFIG_APM is not set
+# CONFIG_APM_EMULATION is not set
 
 #
 # Networking

@@ -296,6 +308,7 @@ CONFIG_UNIX=y
 CONFIG_XFRM=y
 # CONFIG_XFRM_USER is not set
 # CONFIG_XFRM_SUB_POLICY is not set
+# CONFIG_XFRM_MIGRATE is not set
 # CONFIG_NET_KEY is not set
 CONFIG_INET=y
 # CONFIG_IP_MULTICAST is not set

@@ -380,6 +393,7 @@ CONFIG_STANDALONE=y
 CONFIG_PREVENT_FIRMWARE_BUILD=y
 # CONFIG_FW_LOADER is not set
 CONFIG_DEBUG_DRIVER=y
+# CONFIG_DEBUG_DEVRES is not set
 # CONFIG_SYS_HYPERVISOR is not set
 
 #

@@ -403,6 +417,7 @@ CONFIG_MTD_CMDLINE_PARTS=y
 # User Modules And Translation Layers
 #
 CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLKDEVS=y
 CONFIG_MTD_BLOCK=y
 # CONFIG_FTL is not set
 # CONFIG_NFTL is not set

@@ -448,6 +463,8 @@ CONFIG_MTD_CFI_UTIL=y
 #
 # Self-contained MTD device drivers
 #
+# CONFIG_MTD_DATAFLASH is not set
+# CONFIG_MTD_M25P80 is not set
 # CONFIG_MTD_SLRAM is not set
 # CONFIG_MTD_PHRAM is not set
 # CONFIG_MTD_MTDRAM is not set

@@ -478,6 +495,7 @@ CONFIG_MTD_CFI_UTIL=y
 #
 # Plug and Play support
 #
+# CONFIG_PNPACPI is not set
 
 #
 # Block devices

@@ -491,7 +509,6 @@ CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_RAM_COUNT=16
 CONFIG_BLK_DEV_RAM_SIZE=8192
 CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
-CONFIG_BLK_DEV_INITRD=y
 # CONFIG_CDROM_PKTCDVD is not set
 # CONFIG_ATA_OVER_ETH is not set

@@ -677,7 +694,6 @@ CONFIG_WATCHDOG_NOWAYOUT=y
 # CONFIG_USBPCWATCHDOG is not set
 CONFIG_HW_RANDOM=m
 CONFIG_HW_RANDOM_OMAP=m
-# CONFIG_OMAP_RNG is not set
 # CONFIG_NVRAM is not set
 CONFIG_OMAP_RTC=y
 # CONFIG_DTLK is not set

@@ -733,8 +749,22 @@ CONFIG_TPS65010=y
 #
 # SPI support
 #
-# CONFIG_SPI is not set
-# CONFIG_SPI_MASTER is not set
+CONFIG_SPI=y
+# CONFIG_SPI_DEBUG is not set
+CONFIG_SPI_MASTER=y
+
+#
+# SPI Master Controller Drivers
+#
+# CONFIG_SPI_BITBANG is not set
+# CONFIG_SPI_OMAP_UWIRE is not set
+
+#
+# SPI Protocol Masters
+#
+CONFIG_TSC2101=y
+# CONFIG_TSC2102 is not set
+# CONFIG_SPI_AT25 is not set
 
 #
 # Dallas's 1-wire bus

@@ -750,6 +780,7 @@ CONFIG_HWMON=y
 # CONFIG_SENSORS_ADM1021 is not set
 # CONFIG_SENSORS_ADM1025 is not set
 # CONFIG_SENSORS_ADM1026 is not set
+# CONFIG_SENSORS_ADM1029 is not set
 # CONFIG_SENSORS_ADM1031 is not set
 # CONFIG_SENSORS_ADM9240 is not set
 # CONFIG_SENSORS_ASB100 is not set

@@ -762,6 +793,7 @@ CONFIG_HWMON=y
 # CONFIG_SENSORS_GL520SM is not set
 # CONFIG_SENSORS_IT87 is not set
 # CONFIG_SENSORS_LM63 is not set
+# CONFIG_SENSORS_LM70 is not set
 # CONFIG_SENSORS_LM75 is not set
 # CONFIG_SENSORS_LM77 is not set
 # CONFIG_SENSORS_LM78 is not set

@@ -790,7 +822,11 @@ CONFIG_HWMON=y
 #
 # Misc devices
 #
-# CONFIG_TIFM_CORE is not set
+
+#
+# Multifunction device drivers
+#
+# CONFIG_MFD_SM501 is not set
 
 #
 # LED devices

@@ -819,23 +855,30 @@ CONFIG_HWMON=y
 #
 # Graphics support
 #
-CONFIG_FIRMWARE_EDID=y
+# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
 CONFIG_FB=y
+CONFIG_FIRMWARE_EDID=y
+# CONFIG_FB_DDC is not set
 # CONFIG_FB_CFB_FILLRECT is not set
 # CONFIG_FB_CFB_COPYAREA is not set
 # CONFIG_FB_CFB_IMAGEBLIT is not set
+# CONFIG_FB_SVGALIB is not set
 # CONFIG_FB_MACMODES is not set
 # CONFIG_FB_BACKLIGHT is not set
 CONFIG_FB_MODE_HELPERS=y
 # CONFIG_FB_TILEBLITTING is not set
+
+#
+# Frambuffer hardware drivers
+#
 # CONFIG_FB_S1D13XXX is not set
-# CONFIG_FB_VIRTUAL is not set
 CONFIG_FB_OMAP=y
 # CONFIG_FB_OMAP_LCDC_EXTERNAL is not set
 # CONFIG_FB_OMAP_LCD_MIPID is not set
 # CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
 CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2
 # CONFIG_FB_OMAP_DMA_TUNE is not set
+# CONFIG_FB_VIRTUAL is not set
 
 #
 # Console display driver support

@@ -855,7 +898,6 @@ CONFIG_LOGO=y
 # CONFIG_LOGO_LINUX_MONO is not set
 # CONFIG_LOGO_LINUX_VGA16 is not set
 CONFIG_LOGO_LINUX_CLUT224=y
-# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
 
 #
 # Sound

@@ -866,6 +908,7 @@ CONFIG_LOGO_LINUX_CLUT224=y
 # HID Devices
 #
 CONFIG_HID=y
+# CONFIG_HID_DEBUG is not set
 
 #
 # USB support

@@ -880,10 +923,8 @@ CONFIG_USB=y
 # Miscellaneous USB options
 #
 CONFIG_USB_DEVICEFS=y
-# CONFIG_USB_BANDWIDTH is not set
 # CONFIG_USB_DYNAMIC_MINORS is not set
 CONFIG_USB_SUSPEND=y
-# CONFIG_USB_MULTITHREAD_PROBE is not set
 CONFIG_USB_OTG=y
 CONFIG_USB_OTG_WHITELIST=y
 # CONFIG_USB_OTG_BLACKLIST_HUB is not set

@@ -893,7 +934,8 @@ CONFIG_USB_OTG_WHITELIST=y
 #
 # CONFIG_USB_ISP116X_HCD is not set
 CONFIG_USB_OHCI_HCD=y
-# CONFIG_USB_OHCI_BIG_ENDIAN is not set
+# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
+# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
 CONFIG_USB_OHCI_LITTLE_ENDIAN=y
 # CONFIG_USB_SL811_HCD is not set
 # CONFIG_USB_MUSB_HDRC is not set

@@ -936,6 +978,7 @@ CONFIG_USB_OHCI_LITTLE_ENDIAN=y
 # CONFIG_USB_ATI_REMOTE2 is not set
 # CONFIG_USB_KEYSPAN_REMOTE is not set
 # CONFIG_USB_APPLETOUCH is not set
+# CONFIG_USB_GTCO is not set
 
 #
 # USB Imaging devices

@@ -972,6 +1015,7 @@ CONFIG_USB_MON=y
 # CONFIG_USB_RIO500 is not set
 # CONFIG_USB_LEGOTOWER is not set
 # CONFIG_USB_LCD is not set
+# CONFIG_USB_BERRY_CHARGE is not set
 # CONFIG_USB_LED is not set
 # CONFIG_USB_CYPRESS_CY7C63 is not set
 # CONFIG_USB_CYTHERM is not set

@@ -981,6 +1025,7 @@ CONFIG_USB_MON=y
 # CONFIG_USB_APPLEDISPLAY is not set
 # CONFIG_USB_LD is not set
 # CONFIG_USB_TRANCEVIBRATOR is not set
+# CONFIG_USB_IOWARRIOR is not set
 CONFIG_USB_TEST=y
 
 #

@@ -1022,12 +1067,6 @@ CONFIG_RTC_LIB=y
 # CONFIG_RTC_CLASS is not set
 
 #
-# Synchronous Serial Interfaces (SSI)
-#
-CONFIG_OMAP_UWIRE=y
-# CONFIG_OMAP_TSC2101 is not set
-
-#
 # CBUS support
 #
 # CONFIG_CBUS is not set

@@ -1199,15 +1238,16 @@ CONFIG_ENABLE_MUST_CHECK=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
+# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_LOG_BUF_SHIFT=14
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
+# CONFIG_TIMER_STATS is not set
 # CONFIG_DEBUG_SLAB is not set
 # CONFIG_DEBUG_RT_MUTEXES is not set
 # CONFIG_RT_MUTEX_TESTER is not set
 # CONFIG_DEBUG_SPINLOCK is not set
 # CONFIG_DEBUG_MUTEXES is not set
-# CONFIG_DEBUG_RWSEMS is not set
 # CONFIG_DEBUG_SPINLOCK_SLEEP is not set
 # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
 # CONFIG_DEBUG_KOBJECT is not set

@@ -1218,6 +1258,7 @@ CONFIG_DEBUG_INFO=y
 CONFIG_FRAME_POINTER=y
 CONFIG_FORCED_INLINING=y
 # CONFIG_RCU_TORTURE_TEST is not set
+# CONFIG_FAULT_INJECTION is not set
 CONFIG_DEBUG_USER=y
 CONFIG_DEBUG_ERRORS=y
 # CONFIG_DEBUG_LL is not set

@@ -1244,4 +1285,5 @@ CONFIG_CRC32=y
 CONFIG_ZLIB_INFLATE=y
 CONFIG_ZLIB_DEFLATE=y
 CONFIG_PLIST=y
-CONFIG_IOMAP_COPY=y
+CONFIG_HAS_IOMEM=y
+CONFIG_HAS_IOPORT=y

arch/arm/mach-omap1/board-h2.c +85 -1

110 lines not on this page · raw message

drivers/spi/Kconfig +8 -0

Index: linux-omap-2.6/drivers/spi/Kconfig
===================================================================
@@ -149,6 +149,14 @@ config SPI_OMAP24XX
 comment "SPI Protocol Masters"
 	depends on SPI_MASTER
 
+config TSC2101
+	depends on SPI_MASTER
+	tristate "TSC2101 chip support"
+	---help---
+	  Say Y here if you want support for the TSC2101 chip.
+	  At the moment it provides basic register read / write interface
+	  as well as a way to enable the MCLK clock.
+
 config TSC2102
 	depends on SPI_MASTER
 	tristate "TSC2102 codec support"

drivers/spi/Makefile +1 -0

Index: linux-omap-2.6/drivers/spi/Makefile
===================================================================
@@ -24,6 +24,7 @@ obj-$(CONFIG_SPI_OMAP_UWIRE)		+= omap_uw
 # 	... add above this line ...
 
 # SPI protocol drivers (device/link on bus)
+obj-$(CONFIG_TSC2101)			+= tsc2101.o
 obj-$(CONFIG_TSC2102)			+= tsc2102.o
 obj-$(CONFIG_SPI_AT25)		+= at25.o
 obj-$(CONFIG_SPI_TSC2301)		+= tsc2301.o

drivers/spi/tsc2101.c new file +327 -0

327 lines not on this page · raw message

drivers/video/omap/lcd_h2.c +25 ~~-32~~

88 lines not on this page · raw message

include/linux/spi/tsc2101.h new file +43 -0

43 lines not on this page · raw message

[PATCH] OMAP H2 LCD Fixes

SPI API has changed from kernel version 2.6.X to 2.6.20-rc1. This patch fixes OMAP H2 LCD initialization.

This patch applies on top of Imre Deak's patch:
http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009334.html

Signed-off-by Eduardo Valentin <[email protected]>

---

arch/arm/configs/omap_h2_1610_defconfig +1 -1

Index: linux-omap-2.6/arch/arm/configs/omap_h2_1610_defconfig
===================================================================
@@ -757,7 +757,7 @@ CONFIG_SPI_MASTER=y
 # SPI Master Controller Drivers
 #
 # CONFIG_SPI_BITBANG is not set
-# CONFIG_SPI_OMAP_UWIRE is not set
+CONFIG_SPI_OMAP_UWIRE=y
 
 #
 # SPI Protocol Masters

arch/arm/mach-omap1/board-h2.c +3 -1

Index: linux-omap-2.6/arch/arm/mach-omap1/board-h2.c
===================================================================
@@ -303,7 +303,9 @@ static void h2_lcd_dev_init(struct spi_d
 	 * we have to tie them here. We can also register the LCD driver
 	 * first only here, where we know that the TSC driver is ready.
 	 */
-	h2_lcd_device.dev.platform_data = tsc2101;
+	device_initialize(&h2_lcd_device.dev);
+
+	dev_set_drvdata(&h2_lcd_device.dev, tsc2101);
 
 	platform_device_add(&h2_lcd_device);
 }

sound/arm/Kconfig +2 -2

Index: linux-omap-2.6/sound/arm/Kconfig
===================================================================
@@ -52,8 +52,8 @@ config SND_OMAP_TSC2101
  	tristate "OMAP TSC2101 alsa driver"
  	depends on ARCH_OMAP && SND
  	select SND_PCM
-         select OMAP_TSC2101
-         select OMAP_UWIRE if ARCH_OMAP
+	 select TSC2101
+	 select SPI_OMAP_UWIRE if ARCH_OMAP
 	 select OMAP_MCBSP
  	help
  	  Say Y here if you have a OMAP platform board

Jarkko Nikula

2007-03-22 06:48 UTC #23 lore raw

Quoted 3 lines · On Wed, 21 Mar 2007 15:24:21 -0400 "ext Eduardo Valentin"…

This patch (patch-lcd-h2-spi-fix.diff) applies on top of Imre Deak's patch (spi-tsc2101-patch.diff).

Hi, my two cents. It seems that almost everyone forgot to update/remove path names in comment section when moving files to another directory :-)

spi-tsc2101-patch.diff:

--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-omap-2.6/drivers/spi/tsc2101.c 2007-03-21
15:12:49.000000000 -0400 @@ -0,0 +1,327 @@
+/*
+ * linux/drivers/ssi/omap-tsc2101.c
+ *

===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-omap-2.6/include/linux/spi/tsc2101.h 2007-03-21
15:12:49.000000000 -0400 @@ -0,0 +1,43 @@
+/*
+ * linux/drivers/ssi/omap-tsc2101.h
+ *

Signature · 1 line

Jarkko

Tony Lindgren

maintainer

2007-03-30 18:49 UTC #24 lore raw

Quoted 21 lines · Jarkko Nikula

Quoted 3 lines · On Wed, 21 Mar 2007 15:24:21 -0400 "ext Eduardo Valentin"…
This patch (patch-lcd-h2-spi-fix.diff) applies on top of Imre Deak's patch (spi-tsc2101-patch.diff).
Hi, my two cents. It seems that almost everyone forgot to update/remove path names in comment section when moving files to another directory :-)
spi-tsc2101-patch.diff:
drivers/spi/tsc2101.c new file +0 -0
15:12:49.000000000 -0400 @@ -0,0 +1,327 @@
+/*
+ * linux/drivers/ssi/omap-tsc2101.c
+ *
===================================================================
include/linux/spi/tsc2101.h new file +0 -0

Quoted 5 lines

15:12:49.000000000 -0400 @@ -0,0 +1,43 @@
+/*
+ * linux/drivers/ssi/omap-tsc2101.h
+ *

Kyungmin, Eduardo & Jarkko, please sign your patches above so I can apply them!

Tony

Eduardo Valentin

2007-03-31 12:52 UTC #25 lore raw

Hello Tony,

This is an updated patch to fix lcd for H2 board. This one is
applied against
current linux omap (commit ).

The patch is a merge of what was discussed here and what is already pushed.

Signed-off-by Eduardo Valentin <[email protected]>

BR,

Eduardo Valentin

Quoted 33 lines · Tony Lindgren

Quoted 21 lines · Jarkko Nikula
Quoted 3 lines · On Wed, 21 Mar 2007 15:24:21 -0400 "ext Eduardo Valentin"…
This patch (patch-lcd-h2-spi-fix.diff) applies on top of Imre Deak's patch (spi-tsc2101-patch.diff).
Hi, my two cents. It seems that almost everyone forgot to update/remove path names in comment section when moving files to another directory :-)
spi-tsc2101-patch.diff:
drivers/spi/tsc2101.c 2007-03-21 renamed from dev/null 1970-01-01 00:00:00.000000000 +0000 +0 -0
15:12:49.000000000 -0400 @@ -0,0 +1,327 @@
+/*
+ * linux/drivers/ssi/omap-tsc2101.c
+ *
===================================================================
include/linux/spi/tsc2101.h 2007-03-21 renamed from dev/null 1970-01-01 00:00:00.000000000 +0000 +0 -0
Quoted 5 lines
15:12:49.000000000 -0400 @@ -0,0 +1,43 @@
+/*
+ * linux/drivers/ssi/omap-tsc2101.h
+ *
Kyungmin, Eduardo & Jarkko, please sign your patches above so I can apply them!
Tony

Signature · 1 line

Eduardo Bezerra Valentin

drivers/video/omap/lcd_h2.c +25 ~~-32~~

Index: linux-omap-2.6/drivers/video/omap/lcd_h2.c
===================================================================
@@ -23,42 +23,18 @@
 
 #include <linux/module.h>
 #include <linux/platform_device.h>
+#include <linux/spi/tsc2101.h>
 
 #include <asm/arch/mux.h>
 #include <asm/arch/omapfb.h>
 
-#include "../drivers/ssi/omap-uwire.h"
-
-#define MODULE_NAME		"omapfb-lcd_h2"
-#define TSC2101_UWIRE_CS	1
-
-#define pr_err(fmt, args...) printk(KERN_ERR MODULE_NAME ": " fmt, ## args)
-
-static int tsc2101_write_reg(int page, int reg, u16 data)
-{
-	u16	cmd;
-	int	r;
-
-	cmd = ((page & 3) << 11) | ((reg & 0x3f) << 5);
-	if (omap_uwire_data_transfer(TSC2101_UWIRE_CS, cmd, 16, 0, NULL, 1))
-		r = -1;
-	else
-		r = omap_uwire_data_transfer(TSC2101_UWIRE_CS, data, 16, 0,
-					     NULL, 0);
-
-	return r;
-}
+static struct {
+	struct platform_device	*lcd_dev;
+	struct spi_device	*tsc2101_dev;
+} h2_panel_dev;
 
 static int h2_panel_init(struct lcd_panel *panel, struct omapfb_device *fbdev)
 {
-	unsigned long uwire_flags;
-
-	 /* Configure N15 pin to be uWire CS1 */
-	omap_cfg_reg(N15_1610_UWIRE_CS1);
-	uwire_flags = UWIRE_READ_RISING_EDGE | UWIRE_WRITE_RISING_EDGE;
-	uwire_flags |= UWIRE_FREQ_DIV_8;
-	omap_uwire_configure_mode(TSC2101_UWIRE_CS, uwire_flags);
-
 	return 0;
 }

@@ -73,7 +49,10 @@ static int h2_panel_enable(struct lcd_pa
 	/* Assert LCD_EN, BKLIGHT_EN pins on LCD panel
 	 * page2, GPIO config reg, GPIO(0,1) to out and asserted
 	 */
-	r = tsc2101_write_reg(2, 0x23, 0xCC00) ? -1 : 0;
+	r = tsc2101_write_sync(h2_panel_dev.tsc2101_dev, 2, 0x23, 0xcc00);
+	if (r < 0)
+		dev_err(&h2_panel_dev.lcd_dev->dev,
+			"failed to enable LCD panel\n");
 
 	return r;
 }

@@ -83,8 +62,9 @@ static void h2_panel_disable(struct lcd_
 	/* Deassert LCD_EN and BKLIGHT_EN pins on LCD panel
 	 * page2, GPIO config reg, GPIO(0,1) to out and deasserted
 	 */
-	if (tsc2101_write_reg(2, 0x23, 0x8800))
-		pr_err("failed to disable LCD panel\n");
+	if (tsc2101_write_sync(h2_panel_dev.tsc2101_dev, 2, 0x23, 0x8800))
+		dev_err(&h2_panel_dev.lcd_dev->dev,
+			"failed to disable LCD panel\n");
 }
 
 static unsigned long h2_panel_get_caps(struct lcd_panel *panel)

@@ -117,6 +97,19 @@ struct lcd_panel h2_panel = {
 
 static int h2_panel_probe(struct platform_device *pdev)
 {
+	struct spi_device *tsc2101;
+
+	tsc2101 = dev_get_drvdata(&pdev->dev);
+	if (tsc2101 == NULL) {
+		dev_err(&pdev->dev, "no platform data\n");
+		return -ENODEV;
+	}
+	if (strncmp(tsc2101->modalias, "tsc2101", 8) != 0) {
+		dev_err(&pdev->dev, "tsc2101 not found\n");
+		return -EINVAL;
+	}
+	h2_panel_dev.lcd_dev = pdev;
+	h2_panel_dev.tsc2101_dev = tsc2101;
 	omapfb_register_panel(&h2_panel);
 	return 0;
 }

arch/arm/mach-omap1/board-h2.c +15 -1

Index: linux-omap-2.6/arch/arm/mach-omap1/board-h2.c
===================================================================
@@ -305,6 +305,19 @@ struct {
 #define TSC2101_MUX_MCLK_ON	R10_1610_MCLK_ON
 #define TSC2101_MUX_MCLK_OFF	R10_1610_MCLK_OFF
 
+static void h2_lcd_dev_init(struct spi_device *tsc2101)
+{
+	/* The LCD is connected to the GPIO pins of the TSC2101, so
+	 * we have to tie them here. We can also register the LCD driver
+	 * first only here, where we know that the TSC driver is ready.
+	 */
+
+	device_initialize(&h2_lcd_device.dev);
+
+	dev_set_drvdata(&h2_lcd_device.dev, tsc2101);
+	platform_device_add(&h2_lcd_device);
+}
+
 static int h2_tsc2101_init(struct spi_device *spi)
 {
 	int r;

@@ -328,6 +341,8 @@ static int h2_tsc2101_init(struct spi_de
 	omap_cfg_reg(TSC2101_MUX_MCLK_OFF);
 	omap_cfg_reg(N15_1610_UWIRE_CS1);
 
+	h2_lcd_dev_init(spi);
+
 	return 0;
 err:
 	clk_put(h2_tsc2101.mclk);

@@ -410,7 +425,6 @@ static struct platform_device *h2_device
 	&h2_smc91x_device,
 	&h2_irda_device,
 	&h2_kp_device,
-	&h2_lcd_device,
 	&h2_mcbsp1_device,
 };

Imre Deak

author

2007-03-31 17:01 UTC #26 lore raw

Quoted 26 lines · Eduardo Valentin

Hello Tony,
This is an updated patch to fix lcd for H2 board. This one is
applied against
current linux omap (commit ).
The patch is a merge of what was discussed here and what is already pushed.
Signed-off-by Eduardo Valentin <[email protected]>
BR,
Eduardo Valentin
[...]
Index: linux-omap-2.6/arch/arm/mach-omap1/board-h2.c
===================================================================
arch/arm/mach-omap1/board-h2.c +0 -0
@@ -305,6 +305,19 @@ struct {
 #define TSC2101_MUX_MCLK_ON	R10_1610_MCLK_ON
 #define TSC2101_MUX_MCLK_OFF	R10_1610_MCLK_OFF
 

arch/arm/mach-omap1/board-h2.c struct { · line 317

Quoted 10 lines

arch/arm/mach-omap1/board-h2.c +10 -0

+static void h2_lcd_dev_init(struct spi_device *tsc2101)
+{
+	/* The LCD is connected to the GPIO pins of the TSC2101, so
+	 * we have to tie them here. We can also register the LCD driver
+	 * first only here, where we know that the TSC driver is ready.
+	 */
+
+	device_initialize(&h2_lcd_device.dev);
+
+	dev_set_drvdata(&h2_lcd_device.dev, tsc2101);

Is this really necessary? Why isn't it ok to pass it through the platform_data?

--Imre

Eduardo Valentin

2007-04-02 13:43 UTC #27 lore raw

Hi Imre Deak,

Quoted 27 lines · Imre Deak

Quoted 26 lines · Eduardo Valentin
Hello Tony,
This is an updated patch to fix lcd for H2 board. This one is
applied against
current linux omap (commit ).
The patch is a merge of what was discussed here and what is already pushed.
Signed-off-by Eduardo Valentin <[email protected]>
BR,
Eduardo Valentin
[...]
Index: linux-omap-2.6/arch/arm/mach-omap1/board-h2.c
===================================================================
arch/arm/mach-omap1/board-h2.c 2007-03-30 14:36:53.000000000 -0400 renamed from arch/arm/mach-omap1/board-h2.c 2007-03-30 14:26:13.000000000 -0400 +0 -0
@@ -305,6 +305,19 @@ struct {
 #define TSC2101_MUX_MCLK_ON  R10_1610_MCLK_ON
 #define TSC2101_MUX_MCLK_OFF R10_1610_MCLK_OFF
 

Quoted 13 lines

arch/arm/mach-omap1/board-h2.c 2007-03-30 14:36:53.000000000 -0400 struct { · line 317
Quoted 10 lines
arch/arm/mach-omap1/board-h2.c 2007-03-30 14:36:53.000000000 -0400 renamed from arch/arm/mach-omap1/board-h2.c 2007-03-30 14:26:13.000000000 -0400 +10 -0
+static void h2_lcd_dev_init(struct spi_device *tsc2101)
+{
+     /* The LCD is connected to the GPIO pins of the TSC2101, so
+      * we have to tie them here. We can also register the LCD driver
+      * first only here, where we know that the TSC driver is ready.
+      */
+
+     device_initialize(&h2_lcd_device.dev);
+
+     dev_set_drvdata(&h2_lcd_device.dev, tsc2101);
Is this really necessary? Why isn't it ok to pass it through the platform_data?

I tested also with
h2_lcd_device.dev.platform_data = tsc2101;

But the lcd is not initialized using this line. During the board
boot, it prints:
lcd_h2 lcd_h2: no platform data

I know that it is weird, but that's why I used dev_set_drvdata().

BR,

Eduardo Valentin

Quoted 4 lines

--Imre

Signature · 1 line

Eduardo Bezerra Valentin

Imre Deak

author

2007-04-02 20:23 UTC #28 lore raw

Quoted 49 lines · Eduardo Valentin

Hi Imre Deak,
Quoted 29 lines · Imre Deak
Quoted 14 lines · Eduardo Valentin
Hello Tony,
This is an updated patch to fix lcd for H2 board. This one is
applied against
current linux omap (commit ).
The patch is a merge of what was discussed here and what is already pushed.
Signed-off-by Eduardo Valentin <[email protected]>
BR,
Quoted 7 lines
Eduardo Valentin
[...]
Index: linux-omap-2.6/arch/arm/mach-omap1/board-h2.c
===================================================================
--- linux-omap-2.6.orig/arch/arm/mach-omap1/board-h2.c 2007-03-30
14:26:13.000000000 -0400
Quoted 1 line
+++ linux-omap-2.6/arch/arm/mach-omap1/board-h2.c 2007-03-30
14:36:53.000000000 -0400
Quoted 4 lines
arch/arm/mach-omap1/board-h2.c +0 -0
@@ -305,6 +305,19 @@ struct {
 #define TSC2101_MUX_MCLK_ON  R10_1610_MCLK_ON
 #define TSC2101_MUX_MCLK_OFF R10_1610_MCLK_OFF
 
Quoted 13 lines
arch/arm/mach-omap1/board-h2.c struct { · line 317
Quoted 10 lines
arch/arm/mach-omap1/board-h2.c +10 -0
+static void h2_lcd_dev_init(struct spi_device *tsc2101)
+{
+     /* The LCD is connected to the GPIO pins of the TSC2101, so
+      * we have to tie them here. We can also register the LCD driver
+      * first only here, where we know that the TSC driver is ready.
+      */
+
+     device_initialize(&h2_lcd_device.dev);
+
+     dev_set_drvdata(&h2_lcd_device.dev, tsc2101);
Is this really necessary? Why isn't it ok to pass it through the platform_data?

Quoted 6 lines

I tested also with
h2_lcd_device.dev.platform_data = tsc2101;
But the lcd is not initialized using this line. During the board
boot, it prints:
lcd_h2 lcd_h2: no platform data

Odd. Calling platform_device_add is one bug at least so that should be fixed as follows:

+static void h2_lcd_dev_init(struct spi_device *tsc2101) +{
+ /* The LCD is connected to the GPIO pins of the TSC2101, so
+ * we have to tie them here. We can also register the LCD driver
+ * first only here, where we know that the TSC driver is ready.
+ */
+ h2_lcd_device.dev.platform_data = tsc2101;
+
+ platform_device_register(&h2_lcd_device);
+}

Quoted 2 lines

I know that it is weird, but that's why I used dev_set_drvdata().

I think it's not a good thing to do, since the related field is for driver private data.

--Imre

Eduardo Valentin

2007-04-02 20:41 UTC #29 lore raw

Hello Imre

Quoted 72 lines · Imre Deak

Quoted 49 lines · Eduardo Valentin
Hi Imre Deak,
Quoted 29 lines · Imre Deak
Quoted 14 lines · Eduardo Valentin
Hello Tony,
This is an updated patch to fix lcd for H2 board. This one is
applied against
current linux omap (commit ).
The patch is a merge of what was discussed here and what is already pushed.
Signed-off-by Eduardo Valentin <[email protected]>
BR,
Quoted 7 lines
Eduardo Valentin
[...]
Index: linux-omap-2.6/arch/arm/mach-omap1/board-h2.c
===================================================================
--- linux-omap-2.6.orig/arch/arm/mach-omap1/board-h2.c 2007-03-30
14:26:13.000000000 -0400
Quoted 1 line
+++ linux-omap-2.6/arch/arm/mach-omap1/board-h2.c 2007-03-30
14:36:53.000000000 -0400
Quoted 4 lines
arch/arm/mach-omap1/board-h2.c +0 -0
@@ -305,6 +305,19 @@ struct {
 #define TSC2101_MUX_MCLK_ON  R10_1610_MCLK_ON
 #define TSC2101_MUX_MCLK_OFF R10_1610_MCLK_OFF
 
Quoted 13 lines
arch/arm/mach-omap1/board-h2.c struct { · line 317
Quoted 10 lines
arch/arm/mach-omap1/board-h2.c +10 -0
+static void h2_lcd_dev_init(struct spi_device *tsc2101)
+{
+     /* The LCD is connected to the GPIO pins of the TSC2101, so
+      * we have to tie them here. We can also register the LCD driver
+      * first only here, where we know that the TSC driver is ready.
+      */
+
+     device_initialize(&h2_lcd_device.dev);
+
+     dev_set_drvdata(&h2_lcd_device.dev, tsc2101);
Is this really necessary? Why isn't it ok to pass it through the platform_data?
Quoted 6 lines
I tested also with
h2_lcd_device.dev.platform_data = tsc2101;
But the lcd is not initialized using this line. During the board
boot, it prints:
lcd_h2 lcd_h2: no platform data
Odd. Calling platform_device_add is one bug at least so that should be fixed as follows:
arch/arm/mach-omap1/board-h2.c +10 -0
+static void h2_lcd_dev_init(struct spi_device *tsc2101)
+{
+       /* The LCD is connected to the GPIO pins of the TSC2101, so
+        * we have to tie them here. We can also register the LCD driver
+        * first only here, where we know that the TSC driver is ready.
+        */
+       h2_lcd_device.dev.platform_data = tsc2101;
+
+       platform_device_register(&h2_lcd_device);
+}
Quoted 2 lines

Quoted 4 lines

Quoted 1 line
I know that it is weird, but that's why I used dev_set_drvdata().
I think it's not a good thing to do, since the related field is for driver private data.

Yes, I agree with you. It is odd ! :) But with this sequence:

	h2_lcd_device.dev.platform_data = tsc2101;
	platform_device_register(&h2_lcd_device);

The lcd does not initialize properly. During the boot process, it prints:

lcd_h2 lcd_h2: no platform data
tsc2101 spi2.1: initialized

and the lcd device is not powered on.

This is what I'm currently getting here on my H2. Maybe someone would test this patch also :)

Cheers,

Eduardo Valentin

Quoted 4 lines

--Imre

Signature · 1 line

Eduardo Bezerra Valentin

Eduardo Valentin

2007-04-03 11:22 UTC #30 lore raw

Hello again Imre,

I didn't understand properly your question. My bad. Sorry. I used set_drvdata because it is used into lcd_h2.c (accordingly to
my previous patch):
@@ -117,6 +97,19 @@ struct lcd_panel h2_panel = {

static int h2_panel_probe(struct platform_device *pdev) {
+ struct spi_device *tsc2101;
+
+ tsc2101 = dev_get_drvdata(&pdev->dev);
+ if (tsc2101 == NULL) {
+ dev_err(&pdev->dev, "no platform data\n");
+ return -ENODEV;
+ }

Of course, it is clear enough that this dev_err message is wrong.
It must be "no driver data". My bad again. However, why do you suggest use platform_data instead of driver_data?

Cheers,

Eduardo Valentin

Quoted 109 lines · Eduardo Valentin

Hello Imre
Quoted 72 lines · Imre Deak
Quoted 49 lines · Eduardo Valentin
Hi Imre Deak,
Quoted 29 lines · Imre Deak
Quoted 14 lines · Eduardo Valentin
Hello Tony,
This is an updated patch to fix lcd for H2 board. This one is
applied against
current linux omap (commit ).
The patch is a merge of what was discussed here and what is already pushed.
Signed-off-by Eduardo Valentin <[email protected]>
BR,
Quoted 7 lines
Eduardo Valentin
[...]
Index: linux-omap-2.6/arch/arm/mach-omap1/board-h2.c
===================================================================
--- linux-omap-2.6.orig/arch/arm/mach-omap1/board-h2.c 2007-03-30
14:26:13.000000000 -0400
Quoted 1 line
+++ linux-omap-2.6/arch/arm/mach-omap1/board-h2.c 2007-03-30
14:36:53.000000000 -0400
Quoted 4 lines
arch/arm/mach-omap1/board-h2.c +0 -0
@@ -305,6 +305,19 @@ struct {
 #define TSC2101_MUX_MCLK_ON  R10_1610_MCLK_ON
 #define TSC2101_MUX_MCLK_OFF R10_1610_MCLK_OFF
 
Quoted 13 lines
arch/arm/mach-omap1/board-h2.c struct { · line 317
Quoted 10 lines
arch/arm/mach-omap1/board-h2.c +10 -0
+static void h2_lcd_dev_init(struct spi_device *tsc2101)
+{
+     /* The LCD is connected to the GPIO pins of the TSC2101, so
+      * we have to tie them here. We can also register the LCD driver
+      * first only here, where we know that the TSC driver is ready.
+      */
+
+     device_initialize(&h2_lcd_device.dev);
+
+     dev_set_drvdata(&h2_lcd_device.dev, tsc2101);
Is this really necessary? Why isn't it ok to pass it through the platform_data?
Quoted 6 lines
I tested also with
h2_lcd_device.dev.platform_data = tsc2101;
But the lcd is not initialized using this line. During the board
boot, it prints:
lcd_h2 lcd_h2: no platform data
Odd. Calling platform_device_add is one bug at least so that should be fixed as follows:
arch/arm/mach-omap1/board-h2.c +10 -0
+static void h2_lcd_dev_init(struct spi_device *tsc2101)
+{
+       /* The LCD is connected to the GPIO pins of the TSC2101, so
+        * we have to tie them here. We can also register the LCD driver
+        * first only here, where we know that the TSC driver is ready.
+        */
+       h2_lcd_device.dev.platform_data = tsc2101;
+
+       platform_device_register(&h2_lcd_device);
+}
Quoted 2 lines
Quoted 4 lines
Quoted 1 line
I know that it is weird, but that's why I used dev_set_drvdata().
I think it's not a good thing to do, since the related field is for driver private data.
Yes, I agree with you. It is odd ! :) But with this sequence:
        h2_lcd_device.dev.platform_data = tsc2101;
        platform_device_register(&h2_lcd_device);
The lcd does not initialize properly. During the boot process, it prints:
lcd_h2 lcd_h2: no platform data
tsc2101 spi2.1: initialized
and the lcd device is not powered on.
This is what I'm currently getting here on my H2. Maybe someone would test this patch also :)
Cheers,
Eduardo Valentin
Quoted 4 lines
--Imre
--
Eduardo Bezerra Valentin

Signature · 1 line

Eduardo Bezerra Valentin

Imre Deak

author

2007-04-03 14:36 UTC #31 lore raw

Hi,

Quoted 19 lines · Eduardo Valentin

Hello again Imre,
I didn't understand properly your question. My bad. Sorry. I used set_drvdata because it is used into lcd_h2.c (accordingly to
my previous patch):
drivers/video/omap/lcd_h2.c +7 -0
@@ -117,6 +97,19 @@ struct lcd_panel h2_panel = {
 
 static int h2_panel_probe(struct platform_device *pdev)
 {
+	struct spi_device *tsc2101;
+
+	tsc2101 = dev_get_drvdata(&pdev->dev);
+	if (tsc2101 == NULL) {
+		dev_err(&pdev->dev, "no platform data\n");
+		return -ENODEV;
+	}
 
  Of course, it is clear enough that this dev_err message is wrong.

Quoted 2 lines

It must be "no driver data". My bad again. However, why do you suggest use platform_data instead of driver_data?

That's the standard way platforms pass init data to the driver. The driver can then use the driver_data field for it's own purpose.

But more important would be to know why platform_data gets zero'd, since the device core is not touching it. A workaround you're proposing might just delay some other problem..

--Imre

Eduardo Valentin

2007-04-03 15:10 UTC #32 lore raw

Hi Imre,

All right, I agreed with you :). I'm re-sending now an updated
patch. Now it uses platform_data field to pass the spi_device to lcd. The lcd now is working here. It also fix the omap_h2_1610_defconfig file to include CONFIG_SPI_TSC2101 option.

I applied/tested it against commit 6cb703eea609cb60448ce71740495c24ac0e9646.

Cheers,

Quoted 34 lines · Imre Deak

Hi,
Quoted 19 lines · Eduardo Valentin
Hello again Imre,
I didn't understand properly your question. My bad. Sorry. I used set_drvdata because it is used into lcd_h2.c (accordingly to
my previous patch):
(quoted diff) +7 -0
@@ -117,6 +97,19 @@ struct lcd_panel h2_panel = {
 
 static int h2_panel_probe(struct platform_device *pdev)
 {
+     struct spi_device *tsc2101;
+
+     tsc2101 = dev_get_drvdata(&pdev->dev);
+     if (tsc2101 == NULL) {
+             dev_err(&pdev->dev, "no platform data\n");
+             return -ENODEV;
+     }
 
  Of course, it is clear enough that this dev_err message is wrong.
Quoted 2 lines
It must be "no driver data". My bad again. However, why do you suggest use platform_data instead of driver_data?
That's the standard way platforms pass init data to the driver. The driver can then use the driver_data field for it's own purpose.
But more important would be to know why platform_data gets zero'd, since the device core is not touching it. A workaround you're proposing might just delay some other problem..
--Imre

Signature · 1 line

Eduardo Bezerra Valentin

This is an updated patch to fix lcd for H2 board. It uses platform_data field to pass spi_device to lcd driver.

Signed-off-by Eduardo Valentin <[email protected]>

drivers/video/omap/lcd_h2.c +25 ~~-32~~

Index: linux-omap-2.6/drivers/video/omap/lcd_h2.c
===================================================================
@@ -23,42 +23,18 @@
 
 #include <linux/module.h>
 #include <linux/platform_device.h>
+#include <linux/spi/tsc2101.h>
 
 #include <asm/arch/mux.h>
 #include <asm/arch/omapfb.h>
 
-#include "../drivers/ssi/omap-uwire.h"
-
-#define MODULE_NAME		"omapfb-lcd_h2"
-#define TSC2101_UWIRE_CS	1
-
-#define pr_err(fmt, args...) printk(KERN_ERR MODULE_NAME ": " fmt, ## args)
-
-static int tsc2101_write_reg(int page, int reg, u16 data)
-{
-	u16	cmd;
-	int	r;
-
-	cmd = ((page & 3) << 11) | ((reg & 0x3f) << 5);
-	if (omap_uwire_data_transfer(TSC2101_UWIRE_CS, cmd, 16, 0, NULL, 1))
-		r = -1;
-	else
-		r = omap_uwire_data_transfer(TSC2101_UWIRE_CS, data, 16, 0,
-					     NULL, 0);
-
-	return r;
-}
+static struct {
+	struct platform_device	*lcd_dev;
+	struct spi_device	*tsc2101_dev;
+} h2_panel_dev;
 
 static int h2_panel_init(struct lcd_panel *panel, struct omapfb_device *fbdev)
 {
-	unsigned long uwire_flags;
-
-	 /* Configure N15 pin to be uWire CS1 */
-	omap_cfg_reg(N15_1610_UWIRE_CS1);
-	uwire_flags = UWIRE_READ_RISING_EDGE | UWIRE_WRITE_RISING_EDGE;
-	uwire_flags |= UWIRE_FREQ_DIV_8;
-	omap_uwire_configure_mode(TSC2101_UWIRE_CS, uwire_flags);
-
 	return 0;
 }

@@ -73,7 +49,10 @@ static int h2_panel_enable(struct lcd_pa
 	/* Assert LCD_EN, BKLIGHT_EN pins on LCD panel
 	 * page2, GPIO config reg, GPIO(0,1) to out and asserted
 	 */
-	r = tsc2101_write_reg(2, 0x23, 0xCC00) ? -1 : 0;
+	r = tsc2101_write_sync(h2_panel_dev.tsc2101_dev, 2, 0x23, 0xcc00);
+	if (r < 0)
+		dev_err(&h2_panel_dev.lcd_dev->dev,
+			"failed to enable LCD panel\n");
 
 	return r;
 }

@@ -83,8 +62,9 @@ static void h2_panel_disable(struct lcd_
 	/* Deassert LCD_EN and BKLIGHT_EN pins on LCD panel
 	 * page2, GPIO config reg, GPIO(0,1) to out and deasserted
 	 */
-	if (tsc2101_write_reg(2, 0x23, 0x8800))
-		pr_err("failed to disable LCD panel\n");
+	if (tsc2101_write_sync(h2_panel_dev.tsc2101_dev, 2, 0x23, 0x8800))
+		dev_err(&h2_panel_dev.lcd_dev->dev,
+			"failed to disable LCD panel\n");
 }
 
 static unsigned long h2_panel_get_caps(struct lcd_panel *panel)

@@ -117,6 +97,19 @@ struct lcd_panel h2_panel = {
 
 static int h2_panel_probe(struct platform_device *pdev)
 {
+	struct spi_device *tsc2101;
+
+	tsc2101 = pdev->dev.platform_data;
+	if (tsc2101 == NULL) {
+		dev_err(&pdev->dev, "no platform data\n");
+		return -ENODEV;
+	}
+	if (strncmp(tsc2101->modalias, "tsc2101", 8) != 0) {
+		dev_err(&pdev->dev, "tsc2101 not found\n");
+		return -EINVAL;
+	}
+	h2_panel_dev.lcd_dev = pdev;
+	h2_panel_dev.tsc2101_dev = tsc2101;
 	omapfb_register_panel(&h2_panel);
 	return 0;
 }

arch/arm/mach-omap1/board-h2.c +13 -1

Index: linux-omap-2.6/arch/arm/mach-omap1/board-h2.c
===================================================================
@@ -305,6 +305,17 @@ struct {
 #define TSC2101_MUX_MCLK_ON	R10_1610_MCLK_ON
 #define TSC2101_MUX_MCLK_OFF	R10_1610_MCLK_OFF
 
+static void h2_lcd_dev_init(struct spi_device *tsc2101)
+{
+	/* The LCD is connected to the GPIO pins of the TSC2101, so
+	 * we have to tie them here. We can also register the LCD driver
+	 * first only here, where we know that the TSC driver is ready.
+	 */
+
+	h2_lcd_device.dev.platform_data = tsc2101;
+	platform_device_register(&h2_lcd_device);
+}
+
 static int h2_tsc2101_init(struct spi_device *spi)
 {
 	int r;

@@ -328,6 +339,8 @@ static int h2_tsc2101_init(struct spi_de
 	omap_cfg_reg(TSC2101_MUX_MCLK_OFF);
 	omap_cfg_reg(N15_1610_UWIRE_CS1);
 
+	h2_lcd_dev_init(spi);
+
 	return 0;
 err:
 	clk_put(h2_tsc2101.mclk);

@@ -410,7 +423,6 @@ static struct platform_device *h2_device
 	&h2_smc91x_device,
 	&h2_irda_device,
 	&h2_kp_device,
-	&h2_lcd_device,
 	&h2_mcbsp1_device,
 };

arch/arm/configs/omap_h2_1610_defconfig +1 -1

Index: linux-omap-2.6/arch/arm/configs/omap_h2_1610_defconfig
===================================================================
@@ -762,7 +762,7 @@ CONFIG_SPI_OMAP_UWIRE=y
 #
 # SPI Protocol Masters
 #
-CONFIG_TSC2101=y
+CONFIG_SPI_TSC2101=y
 # CONFIG_TSC2102 is not set
 # CONFIG_SPI_AT25 is not set

Tony Lindgren

maintainer

2007-04-03 19:23 UTC #33 lore raw

Quoted 7 lines · Eduardo Valentin

Hi Imre,
All right, I agreed with you :). I'm re-sending now an updated
patch. Now it uses platform_data field to pass the spi_device to lcd. The lcd now is working here. It also fix the omap_h2_1610_defconfig file to include CONFIG_SPI_TSC2101 option.

I'll merge the drivers/video/omap/ changes to Imre's add framebuffer patch. And I'll push the board init changes to omap-upstream. The h2 defconfig should end up in the master branch.

Subject to comments from Imre, of course.

Regards,

Tony

Tony Lindgren

maintainer

2007-03-29 20:26 UTC #34 lore raw

In reply to Imre Deak

Quoted 19 lines · Imre Deak

Quoted 11 lines · Nishanth Menon
andrzej zaborowski stated on 3/9/2007 8:23 AM:
Quoted 10 lines · Imre Deak
Quoted 5 lines
I'm wondering about the proper way to convert the existing omap-tsc2101 driver to the SPI framework. Would it make sense to handle it with the tsc2102 driver? omap-tsc2101 has only the register read / write interface
which is the same as in tsc2102.
How about maybe a header file <linux/spi/tsc2xxx.h> shared between tsc2101/2102 with the register access functions as "static inline" functions?
Quoted 6 lines
Some TODOs:
1. should interrupt muxing be done here?
2. There are some TSC2005 devices(TS only).. so it will be interesting to see xxxx.h scales to all..
3. rename this to tsc2xxx_core.[ch]
4. use SPI framework (would not break uwire support I believe).

Quoted 6 lines

The attached patches try to do #4. Please review it / sign it off as necessary.
There is an upcoming TSC2301 patch, that should also be taken into account when creating a tsc2xxx-core.[ch] based on the existing TSC driver implementations.

I'll push these 3 patches today.

Tony