Re: vme_scc.c breakage (was: Re: linux-next: Tree for November 21)

[Brad Boyer <flar@allandria.com>]

On Sun, Nov 23, 2008 at 05:40:21AM +0100, Michael Schmitz wrote:
> > I can't recommend trying to merge with pmac_zilog. It's got some very
> > mac specific bits including workarounds for the hardware bugs in some
> > revisions of the ASIC that included Apple's implementation of the Zilog
> > ESCC. It also has to handle the odd way Apple hooked up some of the
> > non-data lines such as hardware flow control. The last issue would be
> > the fact that it's a macio bus driver rather than a platform bus driver
> > or something else available more generically.
> 
> From a cursory glance, ip22zilog is not a platform bus driver either. I was 
> thinking along the same lines, though.
> 
> Atari SCC variants have their own quirks, so something more configurable will 
> be needed.

We probably should have an SCC/ESCC core driver the way we have for
a lot of the other common chips like 8390 ethernet or ESP SCSI. I
know there's lots of systems with these chips that each have drivers.

> > I'm not even 100% sure I can make pmac_zilog get shared with m68k
> > macs, although I'm still looking into it.
> > 
> > I would definitely look at one of the other *zilog drivers first.
> 
> What are the quirks the m68k mac SCC driver woukd add? From memory, I have this 
> for Atari:
> 
> - hardware recovery delay for register access
> - channel A/B reversed on ST ESCC
> - TT channel A has 3.672 MHz RTxC, different from channel B; this is
>   generated by timer C and needs to be set up.
> - TT ring indicator is wired to separate interrupt
> - serial console may have initialized channel B already (ip22zilog 
>   handles this).
> 
> VME needs interrupt enable in the main interrupt controller. 

Most of the m68k mac serial quirks are the same as the ones in the
pmac serial driver. There is only one interrupt for both ports, but
the drivers do funny things to make it look mostly like each port
has its own interrupt. There are some odd things about how Apple
hooked up the hardware flow control. I suspect that any models with
built-in modems need enable/disable code for that on m68k macs
just like the hooks in the pmac_zilog driver. For the most part,
any odd thing in pmac_zilog would also be needed for m68k macs
with the exception of the hardware bug workarounds for the bugs in
the ASIC chips Apple used in some models after they stopped using
discrete IO chips. The first generation PCI macs still used the
AMD Curio (combo of MACE, ESP [53c94], ESCC) connected to a custom
ASIC that bridged them onto the PCI bus, while later systems
integrated similar features into the ASIC.

There isn't much m68k mac specific, and I don't think the issues
you mention for Atari are issues on macs. The AV systems have
DMA but don't have a tx-dma channel for the second port. The one
interrupt is hooked up to IRQ 4, which means it doesn't go through
the normal interrupt handling on the VIA chips. We can ignore most
of the other odd Apple specific issues because they only show up
with things the Linux tty layer isn't going to do anyway. There
may be something else that I just don't know about since we don't
have a working driver at the moment.

> Can the platform bus device code define architecture specific init callbacks
> to hide this?

We could probably do something along those lines, but I can't see
tying it directly to the platform bus. I think it would be better
to make a zilog SCC/ESCC core driver and write a driver for each
bus interface type the way the ESP driver now works. It just seems
simpler from a code maintenance perspective.

	Brad Boyer
	flar@allandria.com