public inbox for linux-m68k@lists.linux-m68k.org
 help / color / mirror / Atom feed
From: Brad Boyer <flar@allandria.com>
To: Michael Schmitz <schmitz@biophys.uni-duesseldorf.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org,
	Linux/m68k <linux-m68k@vger.kernel.org>
Subject: Re: vme_scc.c breakage (was: Re: linux-next: Tree for November 21)
Date: Sun, 23 Nov 2008 22:08:38 -0800	[thread overview]
Message-ID: <20081124060838.GA15288@cynthia.pants.nu> (raw)
In-Reply-To: <alpine.DEB.1.00.0811240217030.18487@zirkon.biophys.uni-duesseldorf.de>

On Mon, Nov 24, 2008 at 02:55:42AM +0100, Michael Schmitz wrote:
> > 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.
> 
> Didn't seem too many of those in drivers/serial ...

I must admit I didn't go count them.

> > 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
> 
> According to my 2.2.25 source, SCC A is at interrupt number 33, SCC B is
> at 34. Did that change with tha A/UX interrupt style? 

No, those are synthetic interrupt sources. If you look at the interrupt
code, there is a fake interrupt controller registered on IRQ 4 that
looks at the SCC status bits and triggers the correct interrupt. Take
a look at mac_scc_dispatch in arch/m68k/mac/macints.c for details. The
pmac_zilog code does it a little different by tying the two devices
together and only registering for one interrupt and passing them off.

> What seems to be true is all interrupt types for a given channel go to
> the same handler...

That is definitely true on any Mac. Apple was generally stingy with
interrupt sources. For example, some mac systems don't even have a
real IRQ per NuBus slot even though they do all at least have a way
to detect which slot asserted the interrupt.

> The platform device would need to have one interrupt number each for TX, RX, 
> status and special condition for each channel, plus data/control ports forr 
> each, plus flags. The Mac platform device would have only one interrupt per 
> channel (and perhaps a flag indicating that).

I'm sure we could do something like that with flags.

> > built-in modems need enable/disable code for that on m68k macs
> 
> Are there any Macs with builtin modems in the standard configuration?

It depends on what you mean by standard configuration. Some PowerBooks
shipped with internal modems, but I don't think there is any model
that always had one. It was an option on most later m68k PowerBooks
while most early ppc PowerBooks always had an internal modem.

> > 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
> 
> This is on AV Macs only (because the PSC interrupts are at 32-35 there)?

The AV Macs are quite a bit different from an IRQ perspective. They
don't hook much of anything up directly, so the layout is slightly more
logical. In particular, the registration of mac_scc_dispatch to IRQ 4
is conditionalized on !psc_present to exclude the AV models. It's all
the models using VIA1 as the main interrupt controller that need it.
The SCC interrupt line is never hooked up to a VIA chip, but it is
connected to the PSC on AV macs and the SCC IOP on the IIfx.  Sorry
if the way I wrote this was confusing.

> > 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.
> 
> I don't think using callbacks would be a clean way of handling this, so your 
> idea may be better. 

It's hard to say for sure without trying it to see how it turns out.

> VME and Atari used to use the same driver in 2.2 so that should still be 
> possible now. 

Seems reasonable.

	Brad Boyer
	flar@allandria.com

      reply	other threads:[~2008-11-24  6:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20081121181948.ee771502.sfr@canb.auug.org.au>
2008-11-22 15:07 ` vme_scc.c breakage (was: Re: linux-next: Tree for November 21) Geert Uytterhoeven
2008-11-22 16:47   ` Alan Cox
2008-11-23  2:29     ` Michael Schmitz
2008-11-23  2:59       ` Brad Boyer
2008-11-23  4:40         ` Michael Schmitz
2008-11-23  9:22           ` Brad Boyer
2008-11-24  1:55             ` Michael Schmitz
2008-11-24  6:08               ` Brad Boyer [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=20081124060838.GA15288@cynthia.pants.nu \
    --to=flar@allandria.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=schmitz@biophys.uni-duesseldorf.de \
    --cc=sfr@canb.auug.org.au \
    /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