Move the code registering the Alchemy UART platform devices from
drivers/serial/ to its proper place, into the Alchemy platform code. Fix
the related Kconfig entry, while at it...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
polled console handling support, to access a console in an irq-less
way while in debug or irq context.
absolutely zero impact as long as CONFIG_CONSOLE_POLL is disabled.
(which is the default)
[ jan.kiszka@siemens.com: lots of cleanups ]
[ mingo@elte.hu: redesign, splitups, cleanups. ]
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
This patch is based on the DMA-patch by Chip Coldwell for the AT91/AT32 serial
USARTS, with some tweaks to make it apply neatly on top of the other patches
in this series.
The RX and TX code has been moved to a tasklet and reworked a bit. Instead of
depending on the ENDRX and TIMEOUT bits in CSR, we simply grab as much data as
we can from the DMA buffers. I think this closes a race where the ENDRX bit
is set after we read CSR but before we read RPR, although I haven't confirmed
this.
Similarly, the two TX handlers (ENDTX and TXBUFE) have been combined into one.
Since the current code only uses a single TX buffer, there's no point in
handling those interrupts separately.
This also fixes a DMA sync bug in the original patch.
[linux@bohmer.net: rebased onto irq-splitup patch]
[hskinnemoen@atmel.com: moved to tasklet, fixed dma bug, misc cleanups]
[hskinnemoen@atmel.com: atmel_serial dma: Misc fixes and cleanups]
Signed-off-by: Remy Bohmer <linux@bohmer.net>
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Andrew Victor <linux@maxim.org.za>
Tested-by: Marc Pignat <marc.pignat@hevs.ch>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Reformat the Kconfig entries and update descriptions for accuracy. Select the
driver by default for configurations of interest. For the curious: 32BIT
means only 32-bit DECstations support the device, not that the driver is not
64-bit clean; I have not checked that either though.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add 512x support using the psc_ops framework established
with the previous patch.
All 512x PSCs share the same interrupt so add
IRQF_SHARED to irq flags.
Signed-off-by: John Rigby <jrigby@freescale.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Add file ucc_uart.c, a serial device driver for the Freescale QUICCEngine.
Update the Kconfig and Makefile accordingly.
Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Most of these fixes were already submitted for old kernel versions, and were
approved, but for some reason they never made it into the releases.
Because this is a consolidation of a couple old missed patches, it touches both
Kconfigs and documentation texts.
Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
This adds the option for the pmac_zilog driver to use the major/minor
numbers recently allocated specifically for it (/dev/ttyPZn) instead
of the /dev/ttySn numbers. The advantage of doing this is that it
allows the pmac_zilog and 8250 drivers to coexist. The disadvantage
of doing this is that it is a user-visible ABI change and it will
break existing working setups on powermacs, and could be confusing to
users.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Revert 7e92b4fc34. It broke Sébastien Dugué's
machine and Jeff said (persuasively)
This seems like it will break decades-long-working stuff, in favor of
breaking new ground in our favorite area, "trusting the BIOS."
It's just not worth it for serial ports, IMO. Serial ports are something
that just shouldn't break at this late stage in the game. My new Intel
platform boxes don't even have serial ports, so I question the value of
messing with serial port probing even more... because... just wait a year,
and your box won't have a serial port either! :)
I certainly don't object to the use of platform devices (or isa_driver),
but the probe change seems questionable. That's sorta analagous to
rewriting the floppy driver probe routine. Sure you could do it... but why
risk all that damage and go through debugging all over again?
It seems clear from this report that we cannot, should not, trust BIOS for
something (a) so simple and (b) that has been working for over a decade.
Much discussion ensued and we've decided to have another go at all of this.
Cc: Sébastien Dugué <sebastien.dugue@bull.net>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Adam Belay <ambx1@neo.rr.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Jeff Garzik <jeff@garzik.org>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Cc: Sascha Sommer <saschasommer@freenet.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is a reimplementation of the zs driver for the serial subsystem. Any
resemblance to the old driver is purely coincidential. ;-) I do hope I got
the handling of modem lines right -- better do not tackle me about the
issue unless you feel too good...
Any users of the old driver: please note the numbers of the serial lines
have now been swapped, i.e. ttyS0 <-> ttyS1 and ttyS2 <-> ttyS3. It has
to do with the modem lines mentioned above; basically the port A in a given
chip has to be initialised before the port B if you want to use the latter
as the serial console (which is usually the case), as operations on modem
lines of the serial line associated with the port B access both ports (see
the comment at the top of the driver for the details of wiring used).
Please update your scripts.
This is also the reason each SCC now requests an IRQ once only (as seen in
"/proc/interrupts") -- the handler takes care of both ports at once as the
line associated with the port B has to take status update interrupts from
both ports (and yet the line of the port A takes its own for itself too).
The old driver never got it right...
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>