Thanks a lot.

ps Where is the FAQ for this group?

I doubt there's a comprehensive writeup on these topics for the PPC
architecture. The best (and most up to date) reference you can hope to
find is the source.

Linux device driver architecture in general should be covered in the
book by A. Rubini (Writing Linuc Device Drivers I believe it's called)
if the intel bias doesn't bother you.

        Michael

I digress.

At the moment I have looked at the macserial.[ch], asm/io.h - now I can see
where
registers (z8530) are written but seems like the struct macserial is
populated quite close
to the tty stuff. I think the probe_sccs() function does it. But I still
don't know how and when
the control lands up here - during the startup I guess when things are
happening from
/etc/rc.d/*

Also there are cascaded 8259 in there as well as the PIC-PMA - what's the
deal with that?
Is I/O mapped to the memory or the kernel does that (some fn in asm/io.h),
how is openfirmware
and pram involved - any interface that can be used to access them?

In the end I think the bummer is that I can't reuse the functions in
macserial.[ch] to toy
around with the serial ports e.g. assert RTS or DCD - or is there a neat way
to do it?

Oh well back to work. Thanks a lot for your help. I will dedicate a Heineken
to you this
weekend ;-)

It is the serial struct plus some driver specific things in a private
extension. These driver private bits hold a shadow copy of all 8530
registers. Maybe there's some stuff to deal with the BRG programming
too, I've not looked at the serial code in a while.

The tty struct is used in the higer level tty driver and may reference
the serial struct
it uses, but we're talking low level driver here, tty is a line
discipline and the serial driver may be used by other code as well
(SLIP, PPP) so it's kept separate.

probe_sccs() is called during serial init on kernel startup and queries
the OF device tree for information about the serial hardware, then goes
and populates the serial struct.

During kernel init, which is before init(1) ever runs. /etc/rc.d/ stuff
must open a serial device to talk to the hardware, so look for the
serial_open() stuff and follow the flow from there.

No idea, I've not even looked at PPC interrupt code. I've looked at the
macserial driver while writing the m68k Mac SCC driver mainly.

I/O space in the Intel sense doesn't exist for PPC; it's all memory
mapped.

There's the OF device tree with associated access functions in the
kernel, there's /proc/
device-tree to look at from user space, and PRAM would be nvram which is
in the device
tree as well.

ioctls is what you need to look at I guess. I'm not sure you can
independently toggle control lines that way though. DCD is an input
line, you seem a bit confused here. RTS and CTS are handled by the
serial driver if your tty settings (via ioctl, or via stty from the
shell) request that. /RTS can be asserted by setting bit 1 in write
register 5, add a new ioctl if you feel like modifying the registers
directly. Changing registers on the serial chip while the line is in use
may have undesired side effects.

        Michael

You da man!!! If you do ever come to Dallas,TX USA give me a holler
I will buy you beer.

To write any code to access the SCC I have to be
in kernel space i.e. I can't write a quick dirty program to mess around with
the
Z8530. So I write a module and do an lsmod on it and take it from there?

I'm including asm/prom.h and the linker can't resolve 'find_devices()'. It's
a
EXPORT_SYMBOL in ppc_ksyms.o, but I guess there is a different discipline
to link it in (inheriting kernel Makefiles? Rules.Make?)

So I guess I can boot into MacOS and hack a C program to mess around to
learn the Z8530 and make a linux module out of it.

Thanks a lot for your help - I really appreciate it.

-Sumeet

ps Excuse me for that DCD error, I mean to assert RTS to power my circuit
which
toggles DCD - I lifted the idea from LIRC project.

news:3975F60B.2AEBCD72@biophys.uni-duesseldorf.de...

Nope, add a function to the existing SCC driver to do what you want.
Loading a module that messes with hardware already under control of
other kernel code seems a bit silly to me. But maybe you have some good
ideas to keep the two drivers from interfering with each other.

It might be one of the functions that are in __init() sections and thus
freed after kernel init. You may not even be able to call these
functions anymore beyond a certain stage in kernel init.

        Michael