linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: waltergoossens@home.nl
To: nios2-dev@sopc.et.ntust.edu.tw
Cc: Andrew Morton <akpm@linux-foundation.org>,
	gregkh@suse.de, linux-kernel@vger.kernel.org,
	linux-serial@vger.kernel.org
Subject: Re: [Nios2-dev] [PATCHv3 1/2] serial: Add driver for the Altera	JTAG UART
Date: Mon, 15 Mar 2010 10:24:49 +0000 (GMT)	[thread overview]
Message-ID: <fba089db11ddf.4b9e0af1@home.nl> (raw)
In-Reply-To: <20100315102045.GM21818@distanz.ch>

----- Origineel bericht -----
Van: Tobias Klauser <tklauser@distanz.ch>
Datum: maandag, maart 15, 2010 10:21
Onderwerp: Re: [Nios2-dev] [PATCHv3 1/2] serial: Add driver for the Altera	JTAG UART
Aan: Andrew Morton <akpm@linux-foundation.org>
Cc: nios2-dev@sopc.et.ntust.edu.tw, gregkh@suse.de, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org


> On 2010-03-12 at 21:48:35 +0100, Andrew Morton 
> <akpm@linux-foundation.org> wrote:
> > On Fri,  5 Mar 2010 17:52:22 +0100
> > Tobias Klauser <tklauser@distanz.ch> wrote:
> > 
> > > Add an UART driver for the JTAG UART component available as a SOPC
> > > (System on Programmable Chip) component for Altera FPGAs.
> > > 
> > > ...
> > >
> > > --- a/drivers/serial/Kconfig
> > > +++ b/drivers/serial/Kconfig
> > > @@ -1490,4 +1490,25 @@ config SERIAL_GRLIB_GAISLER_APBUART_CONSOLE
> > >  	help
> > >  	Support for running a console on the GRLIB APBUART
> > >  
> > > +config SERIAL_ALTERA_JTAGUART
> > > +	bool "Altera JTAG UART support"
> > > +	select SERIAL_CORE
> > > +	help
> > > +          This driver supports the Altera JTAG UART port.
> > > +
> > > +config SERIAL_ALTERA_JTAGUART_CONSOLE
> > > +	bool "Altera JTAG UART console support"
> > > +	depends on SERIAL_ALTERA_JTAGUART
> > > +	select SERIAL_CORE_CONSOLE
> > > +	help
> > > +          Enable a Altera JTAG UART port to be the system console.
> > > +
> > > +config SERIAL_ALTERA_JTAGUART_CONSOLE_BYPASS
> > > +	bool "Bypass output when no connection"
> > > +	depends on SERIAL_ALTERA_JTAGUART_CONSOLE
> > > +	select SERIAL_CORE_CONSOLE
> > > +	help
> > > +          Bypass console output and keep going even if there is no
> > > +          JTAG terminal connection with the host.
> > 
> > So this driver will be available on all CPU architectures.
> > 
> > I'm guessing that the hardware _isn't_ available on all CPU
> > architectures?  Maybe that's wrong.
> 
> In principle it is available on all CPU. I can think of a hardware
> component with an Altera FPGA containing this UART. But at the moment 
> no
> such implementation is known to me and the UART is only usable on the
> nios2 CPU architecture  (which is not in mainline yet - we're planning
> to change that, submitting the arch-sepcific drivers is the first step
> towards this).
> 
We are actually working on a project without a Nios2 where a PCIe core connected to a powerPC is the avalon-master. So I'm in favor of not getting everything too nios2 specific.

> > If this hardware is only available on certain CPUs then we face
> > tradeoffs.  By making it universally available, the code gets better
> > compile tesst coverage and that can detect problems (usually minor
> > ones).  otoh, it can increase your maintenance load a bit, and adds 
> a
> > risk that people will ship unusable kernel modules and will see
> > increased build times.  I have no particular opinion either way.
> 
> I'd like to have this universally available if no one objects. It'd be
> nice to get better test coverage and I don't really mind the additional
> maintanance load. AFAICS other UART driver are only available on one
> single architecture too, so I hoped it would be fine to go the same way
> with the altera_{jtag,}uart drivers.
> 
> > >  endmenu
> > > diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
> > > index 5548fe7..6228b6e 100644
> > > --- a/drivers/serial/Makefile
> > > +++ b/drivers/serial/Makefile
> > > @@ -82,3 +82,4 @@ obj-$(CONFIG_KGDB_SERIAL_CONSOLE) += kgdboc.o
> > >  obj-$(CONFIG_SERIAL_QE) += ucc_uart.o
> > >  obj-$(CONFIG_SERIAL_TIMBERDALE)	+= timbuart.o
> > >  obj-$(CONFIG_SERIAL_GRLIB_GAISLER_APBUART) += apbuart.o
> > > +obj-$(CONFIG_SERIAL_ALTERA_JTAGUART) += altera_jtaguart.o
> > > diff --git a/drivers/serial/altera_jtaguart.c b/drivers/serial/altera_jtaguart.c
> > > new file mode 100644
> > > index 0000000..f9b49b5
> > > --- /dev/null
> > > +++ b/drivers/serial/altera_jtaguart.c
> > > @@ -0,0 +1,504 @@
> > > +/*
> > > + * altera_jtaguart.c -- Altera JTAG UART driver
> > > + *
> > > + * Based on mcf.c -- Freescale ColdFire UART driver
> > > + *
> > > + * (C) Copyright 2003-2007, Greg Ungerer <gerg@snapgear.com>
> > > + * (C) Copyright 2008, Thomas Chou <thomas@wytron.com.tw>
> > > + * (C) Copyright 2010, Tobias Klauser <tklauser@distanz.ch>
> > > + *
> > > + * This program is free software; you can redistribute it and/or 
> modify
> > > + * it under the terms of the GNU General Public License as 
> published by
> > > + * the Free Software Foundation; either version 2 of the License, 
> or
> > > + * (at your option) any later version.
> > > + */
> > > +
> > > +#include <linux/kernel.h>
> > > +#include <linux/init.h>
> > > +#include <linux/interrupt.h>
> > > +#include <linux/module.h>
> > > +#include <linux/console.h>
> > > +#include <linux/tty.h>
> > > +#include <linux/tty_flip.h>
> > > +#include <linux/serial.h>
> > > +#include <linux/serial_core.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/io.h>
> > > +#include <linux/altera_jtaguart.h>
> > 
> > Does it make sense to put altera_jtaguart.h into include/linux?  Could
> > we put it in drivers/serial/?
> 
> It is stored in include/linux and not in drivers/serial because we need
> to include it from arch/nios2 for the platform device setup. Including
> <linux/altera_jtaguart.h> looks nicer than including
> "../drivers/serial/altera_jtaguart.h". The same holds true for the
> altera_uart driver.
> 
> Thanks a lot,
> Tobias
> _______________________________________________
> Nios2-dev mailing list
> Nios2-dev@sopc.et.ntust.edu.tw
> http://sopc.et.ntust.edu.tw/cgi-bin/mailman/listinfo/nios2-dev

  reply	other threads:[~2010-03-15 10:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-05 16:52 [PATCHv3 0/2] serial: Drivers for Altera UARTs Tobias Klauser
2010-03-05 16:52 ` [PATCHv3 1/2] serial: Add driver for the Altera JTAG UART Tobias Klauser
2010-03-05 16:52   ` [PATCHv3 2/2] serial: Add driver for the Altera UART Tobias Klauser
2010-03-23 21:54     ` Andrew Morton
2010-03-24  6:47       ` Tobias Klauser
2010-03-24 11:05         ` Andrew Morton
2010-03-24 16:24           ` Tobias Klauser
2010-03-25  0:54             ` Thomas Chou
2010-03-29 13:29               ` Tobias Klauser
2010-03-30  0:18                 ` Thomas Chou
2010-03-12 20:48   ` [PATCHv3 1/2] serial: Add driver for the Altera JTAG UART Andrew Morton
2010-03-15 10:20     ` Tobias Klauser
2010-03-15 10:24       ` waltergoossens [this message]
2010-03-16  0:47     ` [Nios2-dev] " Thomas Chou

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=fba089db11ddf.4b9e0af1@home.nl \
    --to=waltergoossens@home.nl \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=nios2-dev@sopc.et.ntust.edu.tw \
    /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;
as well as URLs for NNTP newsgroup(s).