Hi,
Since we have drivers/serial/dz.[ch] now merged, is there a reason to
keep drivers/char/dz.[ch] around any more? I notice people keep doing
cleanups, but this is wasted effort if the driver is superseded by the
new drivers/serial/dz.[ch] driver.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Sun, 2004-04-04 10:12:41 +0100, Russell King <[email protected]>
wrote in message <[email protected]>:
> Since we have drivers/serial/dz.[ch] now merged, is there a reason to
> keep drivers/char/dz.[ch] around any more? I notice people keep doing
> cleanups, but this is wasted effort if the driver is superseded by the
> new drivers/serial/dz.[ch] driver.
The VAX port also (still) uses a modified version of the d/c/dz.[ch]
driver. Also, the MIPS guys may have some outstanding patches...
So, please let's do two things before throwing away the old driver:
- The MIPS guys need to be happy; they might have some
outstanding changes...
- The VAX guys need to start using the new driver, I'll just
start and try to port over our changes.
While at it, I've already implemented some SERIO changes. That'll allow
the dz.c driver to announce that it waits for LK-style keyboard on one
port and VSXXX-style mouse/digitizer on the 2nd port...
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Sun, Apr 04, 2004 at 01:17:12PM +0200, Jan-Benedict Glaw wrote:
> The VAX port also (still) uses a modified version of the d/c/dz.[ch]
> driver. Also, the MIPS guys may have some outstanding patches...
It is my understanding that the MIPS people are happy with the new
dz.c, since I passed it to them to test and submit. Since they
submitted it, I think we can assume that they're happy.
So we just need the VAX people to confirm that the new driver works
for them, and then for _someone_ to remove the old driver (either
the MIPS or the VAX people.)
> While at it, I've already implemented some SERIO changes. That'll allow
> the dz.c driver to announce that it waits for LK-style keyboard on one
> port and VSXXX-style mouse/digitizer on the 2nd port...
Which dz.c ? 8)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Sun, 2004-04-04 12:29:58 +0100, Russell King <[email protected]>
wrote in message <[email protected]>:
> On Sun, Apr 04, 2004 at 01:17:12PM +0200, Jan-Benedict Glaw wrote:
> So we just need the VAX people to confirm that the new driver works
> for them, and then for _someone_ to remove the old driver (either
> the MIPS or the VAX people.)
Let me do some surgery :)
Interrupt setup is a bit tricky on the VAXen. First, they actually have
separated RX and TX IRQ and these aren't static. IRQ probing needs to be
redone (at least can't be easily copied) since the new dz_init() is
basically a complete new rewrite...
> > While at it, I've already implemented some SERIO changes. That'll allow
> > the dz.c driver to announce that it waits for LK-style keyboard on one
> > port and VSXXX-style mouse/digitizer on the 2nd port...
>
> Which dz.c ? 8)
Old ./drivers/char/dz.c + VAX changes + SERIO changes, that is :) I
guess best practice is that VAX people first merge up with MIPS folks,
then we snatch the old driver together and have a beer...
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Mon, Apr 05, 2004 at 03:15:33PM +0200, Maciej W. Rozycki wrote:
> On Sun, 4 Apr 2004, Russell King wrote:
>
> > Since we have drivers/serial/dz.[ch] now merged, is there a reason to
> > keep drivers/char/dz.[ch] around any more? I notice people keep doing
> > cleanups, but this is wasted effort if the driver is superseded by the
> > new drivers/serial/dz.[ch] driver.
>
> drivers/char/dz.[ch] has been verified to work on real hardware, at least
> with 2.4. Can the same be said of drivers/serial/dz.[ch]? If so, then
> the former can be removed from the mainline.
Ralf has verified that it works before he submitted it to Linus, so
I guess that means that it does "work on real hardware".
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Mon, Apr 05, 2004 at 02:19:57PM +0100, Russell King wrote:
> > > Since we have drivers/serial/dz.[ch] now merged, is there a reason to
> > > keep drivers/char/dz.[ch] around any more? I notice people keep doing
> > > cleanups, but this is wasted effort if the driver is superseded by the
> > > new drivers/serial/dz.[ch] driver.
> >
> > drivers/char/dz.[ch] has been verified to work on real hardware, at least
> > with 2.4. Can the same be said of drivers/serial/dz.[ch]? If so, then
> > the former can be removed from the mainline.
>
> Ralf has verified that it works before he submitted it to Linus, so
> I guess that means that it does "work on real hardware".
That must be been some missunderstanding. DECstations are still not
supported in 2.6 and therfore there was simply no way of testing.
I'm surprised drivers/char/dz.c still exists - I was pretty sure having
submitted a patch to delete it when drivers/serial/dz.c was submitted -
two is one too much.
Ralf
On Sun, 4 Apr 2004, Russell King wrote:
> Since we have drivers/serial/dz.[ch] now merged, is there a reason to
> keep drivers/char/dz.[ch] around any more? I notice people keep doing
> cleanups, but this is wasted effort if the driver is superseded by the
> new drivers/serial/dz.[ch] driver.
drivers/char/dz.[ch] has been verified to work on real hardware, at least
with 2.4. Can the same be said of drivers/serial/dz.[ch]? If so, then
the former can be removed from the mainline.
Anyway, I plan a functional update to drivers/char/dz.[ch], to add
missing features that should have made their way there for 2.4. Then I'll
see what needs to be ported to drivers/serial/dz.[ch] and update it
accordingly. Only then I'll consider the former to be in a strict bugfix
mode. Updates to the old driver can be done solely in the MIPS 2.4 tree,
though.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Mon, 5 Apr 2004, Russell King wrote:
> > drivers/char/dz.[ch] has been verified to work on real hardware, at least
> > with 2.4. Can the same be said of drivers/serial/dz.[ch]? If so, then
> > the former can be removed from the mainline.
>
> Ralf has verified that it works before he submitted it to Linus, so
> I guess that means that it does "work on real hardware".
I see no problem then, though it's unfortunate I haven't got a note on
that.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Sun, 4 Apr 2004, Jan-Benedict Glaw wrote:
> Interrupt setup is a bit tricky on the VAXen. First, they actually have
> separated RX and TX IRQ and these aren't static. IRQ probing needs to be
> redone (at least can't be easily copied) since the new dz_init() is
> basically a complete new rewrite...
I think we need to separate the chipset driver from the
implementation-specific details. There are at least three configurations
in existence:
1. DECstation on-board serial ports for the 3100 (2100) and the 5000/200
(there are minor differences which can be handled together, I think).
2. The PMAC-A TURBOchannel board. This implies up to 24 ports in a single
system if we ever support the DEC 3000/900 (3000/800) Alpha systems; 16
ports otherwise. ;-)
3. VAX-based systems -- you know the details better.
Note the existence of #2 above implies there may be two different kinds of
such ports in a single system, be it a DECstation or a VAXstation (the
4000 series use these ports as well, don't they?).
> Old ./drivers/char/dz.c + VAX changes + SERIO changes, that is :) I
> guess best practice is that VAX people first merge up with MIPS folks,
> then we snatch the old driver together and have a beer...
It sounds like a plan. :-)
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Wed, 2004-04-07 13:16:48 +0200, Maciej W. Rozycki <[email protected]>
wrote in message <[email protected]>:
> On Sun, 4 Apr 2004, Jan-Benedict Glaw wrote:
> > Interrupt setup is a bit tricky on the VAXen. First, they actually have
> > separated RX and TX IRQ and these aren't static. IRQ probing needs to be
> > redone (at least can't be easily copied) since the new dz_init() is
> > basically a complete new rewrite...
>
> I think we need to separate the chipset driver from the
> implementation-specific details. There are at least three configurations
That might be a good idea...
> in existence:
>
> 1. DECstation on-board serial ports for the 3100 (2100) and the 5000/200
> (there are minor differences which can be handled together, I think).
>
> 2. The PMAC-A TURBOchannel board. This implies up to 24 ports in a single
> system if we ever support the DEC 3000/900 (3000/800) Alpha systems; 16
> ports otherwise. ;-)
>
> 3. VAX-based systems -- you know the details better.
>From my point of view, (1) and (3) are quite similar; the differences
are mostly:
- Different base addresses
- Separate RX and TX interrupt. This part is tricky because on
VAX, the triggered IRQ needs to be ACKed twice. On the CPU and
on the vsbus controller, as it seems. That is, both VAX IRQ
handlers explicitely ACK their respective vsbus IRQ.
- Register offsets are offset_mips = offset_vax * 2.
> Note the existence of #2 above implies there may be two different kinds of
> such ports in a single system, be it a DECstation or a VAXstation (the
> 4000 series use these ports as well, don't they?).
They do. ...and I also think that there *may* exist Linux support for
the 3000 type Alphas at some time. So for TC systems, we need to walk
through the busses and search for cards, right?
Also, we should be able to mark specific ports special. First and second
onboard ports are expected to deal with keyboard and mouse/tablet, so
they need to advertise this fact towards SERIO subsystem.
I wasn't yet successful in getting the new driver to work on VAX, but
that's a problem of time (-> I'm currently doing additional payed work)
and lack of output (-> I'd really try to figure out how to access the
diagnostic LEDs in the 4000/60 chassis). I hope to finish the additional
work during upcoming Easter, so I'd continue work after that.
However, we can right now start to discuss how to split the current
driver into chip-specific and machine/bus-specific parts. First goal, of
course, should be to make it work with DECstations and VAXstations (it's
current users). IIRC, 2.6.x isn't yet expected to work on DECstations,
so I'll probably start to make it work for VAXen first.
I'm not that familiar with the TC busses. Do you have the same register
offsets on the TC chips compared to the onboard DZ11? (So are
register offsets machine specific or bus specific?)
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Wed, 7 Apr 2004, Jan-Benedict Glaw wrote:
> - Separate RX and TX interrupt. This part is tricky because on
> VAX, the triggered IRQ needs to be ACKed twice. On the CPU and
> on the vsbus controller, as it seems. That is, both VAX IRQ
> handlers explicitely ACK their respective vsbus IRQ.
But this is done by the platform-specific IRQ controller handler -- the
driver is not aware of the setup used. For example on the DECstation
interrupts arriving from the TURBOchannel, depending on the system, may
come through three kinds of IRQ controllers, for which the following
handlers are used: kn02_irq_type, ioasic_irq_type and
mips_cpu_irq_controller (hmm, the latter should probably be renamed for
consistency). None of the TC drivers cares.
> - Register offsets are offset_mips = offset_vax * 2.
Yes, and this essentially means we want configuration-specific read and
write backends. For the Alpha the rule could be yet different. Note the
driver now incorrectly operates directly on virtual addresses, while it
should use physical ones and obtain a virtual mapping as appropriate.
> I'm not that familiar with the TC busses. Do you have the same register
> offsets on the TC chips compared to the onboard DZ11? (So are
> register offsets machine specific or bus specific?)
I can't recall TC wiring off the head. Certainly the offsets may be
different as they depend on how the address decoders are set up. I
suspect registers are word-aligned as the TC has a 32-bit data path.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Wed, Apr 07, 2004 at 01:16:48PM +0200, Maciej W. Rozycki wrote:
> On Sun, 4 Apr 2004, Jan-Benedict Glaw wrote:
> > Old ./drivers/char/dz.c + VAX changes + SERIO changes, that is :) I
> > guess best practice is that VAX people first merge up with MIPS folks,
> > then we snatch the old driver together and have a beer...
>
> It sounds like a plan. :-)
Sorry for coming in late on this.
There is no problem with dropping drivers/char/dz.[ch] from the official
tree. Us Linux/VAX guys work off our own CVS tree on SourceForge, so we
can continue to carry the drivers/char/dz.[ch] until we've got the
new driver working.
So, Jan-Benedict, there is no major panic to get the new driver working
for us before Rusty/Linus remove the old one.
Later,
Kenn (another Linux/VAX guy)