Subject: test6-rmk5-np1 PCMCIA / UCB1200 audio?

From: I-Gene Leong <[email-masked]>
Date: Wed, 23 Aug 2000 14:13:10 -0700 (PDT)

Is PCMCIA just fundamentally broken? It works, I just still get that
start-stop-daemon oops, and if I get rid of PCMCIA I have no problems at
all.

And is anyone working on a proper UCB1200 audio driver? I'm looking at the
new UCB1200 touchscreen driver and trying to decide whether a second UCB
driver will interfere with it (I'm wondering this because of the unified
UCB interface in arch/arm/special)... and if nobody is writing a driver,
I'll do it, although the question of a unified interface should probably
be resolved before I start.

-- 
I-Gene Leong
[email-masked] / 604-646-6962
"We see Linux as being much of a fad as the Internet was in 1995."
  - Irving Wladawsky-Berger, IBM VP of technology and strategy

unsubscribe: body of `unsubscribe linux-arm-kernel' to [email-masked]

---

From: Nicolas Pitre <[email-masked]>
Date: Wed, 23 Aug 2000 17:33:57 -0400 (EDT)

> start-stop-daemon oops, and if I get rid of PCMCIA I have no problems at

It worked before.  I apparently let a change slip into the code that broke
it somehow.  Now we just need to revert that change or fix it
appropriately.  I'm sure the first person with some free time among us
will fix it.

> be resolved before I start.

We definitely need a master UCB1200 driver that will arbiter the access
from all the slave drivers providing services, like touchscreen, audio,
etc.  I kept the old special/ files for reference only.  They should be
reintegrated/rewritten to support the master/slave structure as it was
done before.

Nicolas

---

From: I-Gene Leong <[email-masked]>
Date: Wed, 23 Aug 2000 14:39:45 -0700 (PDT)

> appropriately.  I'm sure the first person with some free time among us

test4-rmk1-np1 was fine, test5-rmk1-np1 wasn't... I have a diff between
the two and am going to start looking.

> reintegrated/rewritten to support the master/slave structure as it was

Sure, can do... yeah, I looked through and realized that we'll have
conflicts for anything that wants the UCB interrupt, so I volunteer to do
this driver.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Wed, 23 Aug 2000 23:15:43 +0100 (BST)

> start-stop-daemon oops, and if I get rid of PCMCIA I have no problems at

This is a well-known trademark of wrong flags passed into kernel_thread()
(most notably '0' passed in for the flags).  This ends up with an invalid
pointer to a couple of structures in the task struct, which procfs then
dereferences when start-stop-daemon searches through all PIDs.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |            http://www.arm.linux.org.uk/            /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: I-Gene Leong <[email-masked]>
Date: Wed, 23 Aug 2000 15:19:58 -0700 (PDT)

Looks to me as though some major changes happened inside the PCMCIA driver
itself between test4 and test5. All this is beyond my comprehension, so I
can't really do anything about fixing it...

---

From: I-Gene Leong <[email-masked]>
Date: Wed, 23 Aug 2000 15:35:28 -0700 (PDT)

> dereferences when start-stop-daemon searches through all PIDs.

Quick grep reveals sa1100_generic.c with this; test4 doesn't have a single
mention of it.

I have no idea what I'm doing here, but yenta.c also has a kernel_thread
call with CLONE_FS | CLONE_FILES | CLONE_SIGHAND, so I'm going to wander
out on a limb and give that a shot. People who know more about this than I
do (i.e. probably just about everyone) feel free to flame me in the right
direction. :)

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Wed, 23 Aug 2000 23:47:40 +0100 (BST)

I-Gene Leong writes:
> call with CLONE_FS | CLONE_FILES | CLONE_SIGHAND

That's correct.  It is also arguable that it should have SIGCHLD ored in
there as well, but this will not affect your problem.  (see the usage in
fs/buffer.c)
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |            http://www.arm.linux.org.uk/            /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Tak-Shing Chan <[email-masked]>
Date: Thu, 24 Aug 2000 12:36:21 +0800 (CST)

>>> And is anyone working on a proper UCB1200 audio driver? I'm looking at the

     Erik Mouw's LART drivers (branched out from Compaq's Itsy
drivers) already have all the master/slave functionality you're
looking for.  I was working on integrating the touchscreen driver
with the LART drivers as well as upgrading the calibration stuffs
as per http://www.handhelds.org/projects/ts_spec.html.  It will
be ready when the final COMPAQ touchscreen specs are released.

Tak-Shing Chan

---

From: <[email-masked]>
Date: Thu, 24 Aug 2000 14:09:51 +0800 (CST)

> be ready when the final COMPAQ touchscreen specs are released.

Thanks for your intergration,but it seems that your struct TS_EVENT
is unbound data,
typedef struct {
	short pressure;
	int x;
	int y;
	int millisecs
}TS_EVENT

I also make a TS driver that based Tifon's driver,
ftp://ftp.netwinder.org/users/c/chester/TS/
and i hope can intergrate with others.

BTW,please don't use Major=11 ,it will conflict when uses keyboard.
Maybe dynamic assign or use a reserved number,(0 or 60-63).

				Chester

---

From: Tak-Shing Chan <[email-masked]>
Date: Thu, 24 Aug 2000 16:17:01 +0800 (CST)

> Thanks for your intergration,but it seems that your struct TS_EVENT

     I can't get your point--please enlighten me.  By the way,
TS_EVENT is taken verbatim from Compaq's touchscreen specs
version 0.2.

> and i hope can intergrate with others.

     Just have a glance at your code.  Looks like there have been
a lot of work (like powermgr stuffs), perhaps we should just mix
and match the two drivers to avoid duplicated efforts.

> Maybe dynamic assign or use a reserved number,(0 or 60-63).

     The specs suggest a major of 10, but I change it to 11
because I don't yet want to switch to misc_register() until the
specs are finalized, and 11 because I bet no one is using SCSI
CDROMs on the SA11x0.  It's just temporary.  I'll change it to
the correct values as soon as the specs are ready.

     By the way, how come your keyboard uses SCSI_CDROM_MAJOR?

Regards,
Tak-Shing Chan

---

From: <[email-masked]>
Date: Thu, 24 Aug 2000 18:01:08 +0800 (CST)

> TS_EVENT is taken verbatim from Compaq's touchscreen specs
Ooop,their should be old on web site.
look at their some code about h3650_ts.h

>From devices.txt
11 char	Raw keyboard device

You can choose 60-63 for temporary(flash driver use 60/block),
But maybe we should register a number to linux

					Chester

---

From: Tak-Shing Chan <[email-masked]>
Date: Thu, 24 Aug 2000 18:32:09 +0800 (CST)

Chester,

     Oh I've made a BIG mistake.  Thanks for correcting me!!!  :)
I was too obsessed with the absolute numbers and forget about
the fundamental differences of block and char devices...

Tak-Shing Chan

---

From: S A McConnell <[email-masked]>
Date: Thu, 24 Aug 2000 08:18:24 -0500

I am interested in a "generic" interface to the UCB1200 that can be used
to support touch screen, audio and telephony drivers.

I have been working on a touch screen based upon sa1100_ts.c and
ucb1100_ts.c. Have I made a mistake looking at those drivers?

I found that the above drivers had a fair amount of duplicated code.
(measure_x, measure_y, measure_pressure...) Which I have reduced.

I also created several macro's that significantly reduce the complexity
of the UCB register reads and writes.

I also disliked the TS knowing about the register formats. I tried to
move all that knowledge into the *.h files as well as the code used to
read and write the UCB registers.

I have not been able to find out who wrote the sa1100_ts.c and
ucb1100_ts.c code.

I have questions about how the touch screen should detect events.
(interrupts vs timer based polling) I am currently using an Interrupt
to detect touch events.

Should the driver buffer touch events? How many?
If data is buffered what should be done on overruns?
	(Toss oldest? Toss youngest?)

I have mine mapped to Major 10, minor 24 and I am using the misc_device
approach to register the driver with the kernel.
Did I make a misake?

You discussion on char vs block is very confusing. This is a character
device right?

Scott

---

From: Nicolas Pitre <[email-masked]>
Date: Thu, 24 Aug 2000 10:56:49 -0400 (EDT)

> But maybe we should register a number to linux

No because the flash driver is destined to die i.e. merged with the MTD
stuff.

Nicolas

---

From: Nicolas Pitre <[email-masked]>
Date: Thu, 24 Aug 2000 11:49:58 -0400 (EDT)

> (interrupts vs timer based polling) I am currently using an Interrupt

Interrupts is always the best.  Like the iPAQ touchscreen interface, your
events only need a timestamp to measure velocity.

> Should the driver buffer touch events? How many?

Probably, but not much.

> 	(Toss oldest? Toss youngest?)

Probably the oldest since the newer pen position is more relevant than the
oldest which is not current anymore.

> approach to register the driver with the kernel.

Probably not.

> You discussion on char vs block is very confusing. This is a character

Yes.

Nicolas

---

From: <[email-masked]>
Date: Fri, 25 Aug 2000 00:20:45 +0800 (CST)

> > to support touch screen, audio and telephony drivers.

Go,do it.

> events only need a timestamp to measure velocity.

Agreed,that's why i don't like original sa1100_ts.c,it use polling mode.
For handwriting recognization,it's a bad soluation for asia glyhps.

						Chester

---

From: Tak-Shing Chan <[email-masked]>
Date: Fri, 25 Aug 2000 11:15:15 +0800 (CST)

> to support touch screen, audio and telephony drivers.
     We can perhaps reuse arch/arm/special/mcp_common.c.

> ucb1100_ts.c. Have I made a mistake looking at those drivers?
     Which version?  There are no less than 3 different UCB1200
touchscreen drivers in ARM Linux's history (the Itsy port, Tifon,
ADS/Microwindows and various others).

> of the UCB register reads and writes.
     The sa1100_ts.h in test6 is derived from Itsy and it does
inlined codec_read() and codec_write(), similar to macros.  A
better solution is perhaps to use the original Itsy codec header
file that is already integrated with mcp_common.c.  (Itsy
drivers are written for an obsolete version of ARM Linux; some
heavy portings are needed.  Erik Mouw has already done a lot of
such portings.)

> I have not been able to find out who wrote the sa1100_ts.c and
     The ones before test6 are originally by Century Software
(ADS/Microwindows); the ones since test6 use interrupts and are
originally by Peter Danielsson (Tifon).  Both have been patched
heavily.

> (interrupts vs timer based polling) I am currently using an Interrupt
     Interrupts can detect pen downs only; you need a timer for
continuous sampling during the pen down period or else you
can't drag the ``mouse''.

> You discussion on char vs block is very confusing. This is a character
     Sorry about the confusion.  This is certainly a character
device, of course.  :)  In early August, I was modifying the
ucb1200_ts.c driver such that it uses interrupts and that it can
emulate an iPAQ.  The result is that I've pasted in the Tifon
driver's code and deleted most of the original code, and added
various stuffs from various sources.  The touchscreen specs said
the major should be 10 but as I'm too lazy to switch to
misc_register() just yet, I use 11,0 instead thinking that it
is the unused /dev/scd0 (unfortunately it isn't).  In the
meantime I've already switched to misc_register() with a minor
of 240 and have preliminary integration with mcp_common.c (derived
from Chester's code) but the touchscreen specs and the code layout
in the linux directories are still not sorted out yet...  (I'll
post my patch here somewhere in September when the issues are
resolved.)

Tak-Shing Chan

---

From: Nicolas Pitre <[email-masked]>
Date: Fri, 25 Aug 2000 11:53:11 -0400 (EDT)

>      We can perhaps reuse arch/arm/special/mcp_common.c.

Yes, and rename it to ucb1200-generic.c, or better yet sa1100-ucb1200.c
for more clarity.  This could become ucb1200-xyz.c if ever some
other architecture xyz uses the UCB1200 chip.

The slave drivers could be ucb1200-ts for touchscreen, ucb1200-audio for
audio, etc.

>      And before anyone writes or modifies anything, should we
> have a who's-doing-what list in order to minimize duplicated
> efforts?

I guess volunteers might identify themselves on this list.
You are one?  :-)

Nicolas

---

From: S A McConnell <[email-masked]>
Date: Fri, 25 Aug 2000 14:32:37 -0500

> other architecture xyz uses the UCB1200 chip.

Lets use the generic name. The LinkUp L7200 & L7205 uses the UCB1200
(ARM720)

> I guess volunteers might identify themselves on this list.

I am interested in the TS at this point.

Scott

---

From: S A McConnell <[email-masked]>
Date: Fri, 25 Aug 2000 15:59:03 -0500

> can't drag the ``mouse''.

(I am a novice at this...)

Using thresholds, pen ups can be detected by interrupts. With the hacked
up code I have been playing with the last interrupt is always x=-1, y=-1
(Pen Up)

I do not believe it is the job of the driver to detect "drags". Rather
it is the job of the driver to provide enough information to allow
userland app's to detect drags.

If there is data available the pen is down.
If there is no data available the pen is up.

If the current position is more than z units different from the last
measurement it moved. X, Y with timestamp will allow momentum and angle
to be calculated. (I do not believe that is the job of the driver)

The question I have is: will an "interrupt" based approach generate
events at a rate greater than they can be sampled by user land app's? Is
this a problem?

How has this problem been solved in the past? (keyboards?)

This is where the timer based approach could help resolve this problem.

Any other thoughts.

Scott

---

From: Tak-Shing Chan <[email-masked]>
Date: Mon, 28 Aug 2000 09:39:42 +0800 (CST)

> I guess volunteers might identify themselves on this list.

     Sure.  I plan to port the latest Itsy drivers (Y2K version)
from 2.0.30 to 2.4.0-test6-rmk5-np1 (quite a tedious task but
hopefully I can start from Erik Mouw's port of an older version),
and rename them to the ones you proposed...  I'll also make their
TS driver iPAQ-compatible.  This seems to solve all the problems
at once.  Is there anyone else already doing this?

Tak-Shing Chan

---

From: Tak-Shing Chan <[email-masked]>
Date: Mon, 28 Aug 2000 10:43:48 +0800 (CST)

> up code I have been playing with the last interrupt is always x=-1, y=-1
     You must be talking about the polling driver from Century
Software.  The interrupt-based driver in test6-rmk5-np1 has no
thresholds nor the x=-1, y=-1 thing.

> userland app's to detect drags.
     I didn't say drivers detect drags.  What I meant is that
with a pure interrupt-based driver there will not be ``enough
information to allow userland app's to detect drags''.  Let me
clarify how the touchscreen interrupt actually works.

     As per the UCB1300 specification [1], ``a touch screen
interrupt is generated either when the touch screen is pressed
(falling edge enabled) or when the touch screen is released
(rising edge enabled).  It can be used to activate the system
around the UCB1300 to start a touch screen read-out sequence.''

    The above paragraph is the most important part of the
touchscreen specification.  It says that pen movements during pen
down will NOT be detected by the interrupts.  Therefore you do
need a timer for the continuous sampling during pen down, and
ideally the rate should be software-selectable.

Tak-Shing Chan

[1] Philips Semiconductor.  UCB1300 Product Specfication
    (2000 Jun 26), p. 19, available on the web at:
    http://www.semiconductors.com/acrobat/datasheets/UCB1300_2.pdf

---

From: Tak-Shing Chan <[email-masked]>
Date: Wed, 30 Aug 2000 19:49:43 +0800 (CST)

Dear ARM Linux people,

     I apologize for replying to my own post--my plan of porting
has to be canceled as I have to finish up some urgent tasks
before I leave my present job.  I guess I need to pull my name
off the volunteers list for now...

     In the past six months I have learned a great deal about ARM
Linux just by reading your discussions.  Thanks for the advices
and knowledge given to me during my stay!

Cheers and farewell,
Tak-Shing Chan