From: David Brownell <david-b@pacbell.net>
To: Ragner Magalhaes <ragner.magalhaes@indt.org.br>
Cc: linux-omap-open-source@linux.omap.com
Subject: Re: [PATCH 1/4] SPI: tsc2xxx core
Date: Tue, 14 Aug 2007 15:50:28 -0700 [thread overview]
Message-ID: <200708141550.28530.david-b@pacbell.net> (raw)
In-Reply-To: <46C21853.9050101@indt.org.br>
On Tuesday 14 August 2007, Ragner Magalhaes wrote:
> ext David Brownell wrote:
> > On Tuesday 14 August 2007, Ragner Magalhaes wrote:
> >> This is the start to build tsc2xxx core with all sharable routines
> >> between tsc2101, tsc2102, tsc2301 ... and more later tsc2100, tsc2111, etc.
> >
> > I'm getting confused here. What's the plan? Is this an entirely
> > different approach from the tsc210x stuff ... and if so, why?
>
> I think we could to have a tsc2xxx core with all main sharable routines
> by tsc2xxx family ... and Chip-specific calling this core routines ...
>
> And "[PATCH 1/4] SPI: tsc2xxx core" could to be the start ...
Yes, but we also want other sharable code too. In most cases it
seems that the touchscreen and sensor code is sharable -- modulo
the "what sensors are valid on this system" issue -- and the audio
code isn't. Plus tsc2301 has keypad support, etc.
> > I took a look at the tsc2101 bits, and I'm puzzled by why the
> > original "int tsc2101_read_sync()" became "u16 tsc2101_read_sync()".
> >
> > First, why return "int" instead of "negative erno or value"? Not
> > that errors will be common, but returning "u16" means they can't
> > ever be reported or handled...
> Ok, I do not saw at the kernel's code some thing as
>
> w = tsc2101_read_sync(spi, 1, 0);
> if (w < 0) {
> dev_err(&spi->dev, "Error or invalid anything \n");
> goto err;
> }
>
> I saw ...
> w = tsc2101_read_sync(spi, 1, 0);
> if (!(w & (1 << 14))) {
> dev_err(&spi->dev, "Error or invalid anything \n");
> goto err;
> }
>
> I think my solution is not a mistake about this ...
But, did yoou see the patch I posted yesterday? It fixes that.
I had a similar patch for the old tsc2101 code too.
> > I just don't see how these parts are expected to fit together yet.
> > The patch from Andrzej seemed a bit more clear, although it did
> > not cover as much ground at the beginning. I suspect you have
> > a plan, but it's just not yet apparent to me...
> >
> > - Dave
>
> Ok, David
> Thanks for yours comments ...
> I go to continue working about this ... to find a better solution ..
prev parent reply other threads:[~2007-08-14 22:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-14 19:12 [PATCH 1/4] SPI: tsc2xxx core Ragner Magalhaes
2007-08-14 19:12 ` [PATCH 2/4] SPI: tsc2301 support for " Ragner Magalhaes
2007-08-14 19:12 ` [PATCH 3/4] SPI: tsc2101 " Ragner Magalhaes
2007-08-14 19:13 ` [PATCH 4/4] SPI: tsc2102 " Ragner Magalhaes
2007-08-14 20:12 ` [PATCH 1/4] SPI: " David Brownell
2007-08-14 21:02 ` Ragner Magalhaes
2007-08-14 22:50 ` David Brownell [this message]
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=200708141550.28530.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=linux-omap-open-source@linux.omap.com \
--cc=ragner.magalhaes@indt.org.br \
/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