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

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

[Geert Uytterhoeven]

	Hi Alan,

drivers/char/vme_scc.c no longer compiles in linux-next:
http://kisskb.ellerman.id.au/kisskb/buildresult/56964/

I get a slightly different error message, though:

| drivers/char/vme_scc.c: In function 'scc_carrier_raised':
| drivers/char/vme_scc.c:634: error: expected identifier or '(' before 'volatile'
| drivers/char/vme_scc.c:634: error: expected ')' before '(' token
| drivers/char/vme_scc.c:634: error: expected statement before ')' token
| drivers/char/vme_scc.c:635: error: 'struct tty_port' has no member named 'channel'

The problem seems to be introduced by commit
e21405cbbaa859c68119b260c0fe43afdb86a385 ("tty-port-extract-cd"). The relevant
part is below:

| diff --git a/drivers/char/vme_scc.c b/drivers/char/vme_scc.c
| index 1718b3c..d4e1534 100644
| --- a/drivers/char/vme_scc.c
| +++ b/drivers/char/vme_scc.c
| @@ -624,9 +629,9 @@ static void scc_enable_rx_interrupts(void *ptr)
|  }
|  
|  
| -static int scc_get_CD(void *ptr)
| +static int scc_carrier_raised(struct tty_port *port)
|  {
| -	struct scc_port *port = ptr;
| +	struct scc_port *scc = container_of(port, struct scc_port, gs.port);
|  	unsigned channel = port->channel;
|  
|  	return !!(scc_last_status_reg[channel] & SR_DCD);

Issues:
  1. When Atari support is enabled, `scc' is defined in
     include/asm-m68k/atari.h as:

	# define scc ((*(volatile struct SCC*)SCC_BAS))

     However, renaming the variable `scc' doesn't help, as

  2. the variable `scc' is not used in scc_carrier_raised(),

  3. `port->channel' on line 635 still fails as `port' is not longer `struct
     scc_port', but a 'struct tty_port', which has no member named 'channel'.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

[Alan Cox]

> | -	struct scc_port *port = ptr;
> | +	struct scc_port *scc = container_of(port, struct scc_port, gs.port);
> |  	unsigned channel = port->channel;
> |  
> |  	return !!(scc_last_status_reg[channel] & SR_DCD);
> 
> Issues:
>   1. When Atari support is enabled, `scc' is defined in
>      include/asm-m68k/atari.h as:
> 
> 	# define scc ((*(volatile struct SCC*)SCC_BAS))
> 
>      However, renaming the variable `scc' doesn't help, as
> 
>   2. the variable `scc' is not used in scc_carrier_raised(),
> 
>   3. `port->channel' on line 635 still fails as `port' is not longer `struct
>      scc_port', but a 'struct tty_port', which has no member named 'channel'.

Will take a look at this, but gs is going to away so at some point
someone with hardware is going to have to admit to owning this driver or
just mark it BROKEN..

Alan

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

[Michael Schmitz]

Hi,

> > Issues:
> >   1. When Atari support is enabled, `scc' is defined in
> >      include/asm-m68k/atari.h as:
> > 
> > 	# define scc ((*(volatile struct SCC*)SCC_BAS))

This can be renamed - it is only used for control and data port address init 
(aside from serial console, which should probably be separated out if it cannot 
be reconciled). 

> > 
> >      However, renaming the variable `scc' doesn't help, as
> > 
> >   2. the variable `scc' is not used in scc_carrier_raised(),
> > 
> >   3. `port->channel' on line 635 still fails as `port' is not longer `struct
> >      scc_port', but a 'struct tty_port', which has no member named 'channel'.
> 
> Will take a look at this, but gs is going to away so at some point
> someone with hardware is going to have to admit to owning this driver or
> just mark it BROKEN..

Time to merge with pmac_zilog or ip22zilog (the latter even needing similar 
register access delays as Ataris). 

What is the time frame to gs being removed? I admit to 'owning' atari_scc which 
was based on vme_scc so I'll have to deal with that sooner or later.

	Michael

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

[Brad Boyer]

On Sun, Nov 23, 2008 at 03:29:19AM +0100, Michael Schmitz wrote:
> Time to merge with pmac_zilog or ip22zilog (the latter even needing similar 
> register access delays as Ataris). 

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.

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.

	Brad Boyer
	flar@allandria.com

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

[Michael Schmitz]

Hi, 

> > Time to merge with pmac_zilog or ip22zilog (the latter even needing similar 
> > register access delays as Ataris). 
> 
> 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.

> 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. 

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

	Michael

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

[Brad Boyer]

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

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

[Michael Schmitz]

Hi,

> > 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.

Didn't seem too many of those in drivers/serial ...

> > What are the quirks the m68k mac SCC driver woukd add? From memory, I have this 
> 
> 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? 
What seems to be true is all interrupt types for a given channel go to the same 
handler...

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).

> 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

Right you are ...

> built-in modems need enable/disable code for that on m68k macs

Are there any Macs with builtin modems in the standard configuration?

> 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)?

> > 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.

I don't think using callbacks would be a clean way of handling this, so your 
idea may be better. 

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

	Michael

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

[Brad Boyer]

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