From: Imre Deak <imre.deak@solidboot.com>
To: Kyungmin Park <kmpark@infradead.org>
Cc: 'Linux OMAP ML' <linux-omap-open-source@linux.omap.com>
Subject: Re: TSC2101/2102
Date: Fri, 16 Mar 2007 11:49:27 +0200 [thread overview]
Message-ID: <20070316094926.GA4519@bitbox.mine.nu> (raw)
In-Reply-To: <004401c767a1$f1489590$c7a3580a@swcenter.sec.samsung.co.kr>
On Fri, Mar 16, 2007 at 05:05:58PM +0900, Kyungmin Park wrote:
>
> > > >
> > > > 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.
> > > >
> > > > > 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.
> >
> > 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?
>
> 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.
Could you try it with debugging enabled in omap2_mcspi? Would be interesting
to see where the problem is.
--Imre
>
next prev parent reply other threads:[~2007-03-16 9:49 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-09 14:06 TSC2101/2102 Imre Deak
2007-03-09 14:23 ` TSC2101/2102 andrzej zaborowski
2007-03-14 13:21 ` TSC2101/2102 Nishanth Menon
2007-03-14 17:09 ` TSC2101/2102 Imre Deak
2007-03-14 20:35 ` TSC2101/2102 Dirk Behme
2007-03-15 1:18 ` TSC2101/2102 Kyungmin Park
2007-03-15 10:23 ` TSC2101/2102 Imre Deak
2007-03-15 14:23 ` Regarding use of DirectFB Raja Mallik
2007-03-15 17:09 ` Cliff Brake
2007-03-16 0:28 ` TSC2101/2102 Kyungmin Park
2007-03-16 7:41 ` TSC2101/2102 Imre Deak
2007-03-16 8:05 ` TSC2101/2102 Kyungmin Park
2007-03-16 9:49 ` Imre Deak [this message]
2007-03-19 2:02 ` TSC2101/2102 Kyungmin Park
2007-03-19 7:37 ` TSC2101/2102 Jarkko Nikula
2007-03-19 8:04 ` TSC2101/2102 Kyungmin Park
2007-03-19 8:37 ` TSC2101/2102 Jarkko Nikula
2007-03-19 19:22 ` TSC2101/2102 tony
2007-03-20 1:46 ` TSC2101/2102 Kyungmin Park
2007-03-20 13:27 ` TSC2101/2102 tony
2007-03-20 13:54 ` TSC2101/2102 Jarkko Nikula
2007-03-20 15:38 ` TSC2101/2102 Tony Lindgren
2007-03-21 19:24 ` TSC2101/2102 Eduardo Valentin
2007-03-22 6:48 ` TSC2101/2102 Jarkko Nikula
2007-03-30 18:49 ` TSC2101/2102 Tony Lindgren
2007-03-31 12:52 ` TSC2101/2102 Eduardo Valentin
2007-03-31 17:01 ` TSC2101/2102 Imre Deak
2007-04-02 13:43 ` TSC2101/2102 Eduardo Valentin
2007-04-02 20:23 ` TSC2101/2102 Imre Deak
2007-04-02 20:41 ` TSC2101/2102 Eduardo Valentin
2007-04-03 11:22 ` TSC2101/2102 Eduardo Valentin
2007-04-03 14:36 ` TSC2101/2102 Imre Deak
2007-04-03 15:10 ` TSC2101/2102 Eduardo Valentin
2007-04-03 19:23 ` TSC2101/2102 Tony Lindgren
2007-03-29 20:26 ` TSC2101/2102 Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070316094926.GA4519@bitbox.mine.nu \
--to=imre.deak@solidboot.com \
--cc=kmpark@infradead.org \
--cc=linux-omap-open-source@linux.omap.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox