From: James Hogan <james.hogan@imgtec.com>
To: Jiri Slaby <jslaby@suse.cz>
Cc: <linux-kernel@vger.kernel.org>, <linux-arch@vger.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mauro Carvalho Chehab <mchehab@redhat.com>,
Cesar Eduardo Barros <cesarb@cesarb.net>,
Joe Perches <joe@perches.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v3 43/44] tty/metag_da: Add metag DA TTY driver
Date: Fri, 11 Jan 2013 10:50:25 +0000 [thread overview]
Message-ID: <50EFEE71.4000706@imgtec.com> (raw)
In-Reply-To: <50EEE642.20608@suse.cz>
[-- Attachment #1: Type: text/plain, Size: 10026 bytes --]
Hi Jiri,
On 10/01/13 16:03, Jiri Slaby wrote:
> Hi, few comments/questions below.
>
> On 01/10/2013 04:31 PM, James Hogan wrote:
>> --- /dev/null
>> +++ b/drivers/tty/metag_da.c
>> @@ -0,0 +1,696 @@
> ...
>> +struct dashtty_port {
>> + struct tty_port port;
>> + spinlock_t rx_lock;
>> + void *rx_buf;
>> + struct mutex xmit_lock;
>> + unsigned int xmit_cnt;
>> + unsigned int xmit_head;
>> + unsigned int xmit_tail;
>> + struct completion xmit_empty;
>> +};
>> +
>> +static struct dashtty_port dashtty_ports[NUM_TTY_CHANNELS];
>
>> +static int chancall(int bios_function, int channel, int arg2, void *arg3,
>> + void *arg4)
>> +{
>> + register int bios_function__ __asm__("D1Ar1") = bios_function;
>> + register int channel__ __asm__("D0Ar2") = channel;
>> + register int arg2__ __asm__("D1Ar3") = arg2;
>> + register void *arg3__ __asm__("D0Ar4") = arg3;
>> + register void *arg4__ __asm__("D1Ar5") = arg4;
>> + register int bios_call __asm__("D0Ar6") = 3;
>> + register int result __asm__("D0Re0");
>
> This is really ugly. Couldn't it be specified in the asm's constraints
> below?
Unfortunately not. There aren't any constraints for these individual
registers. It could be made to use u64's with shifting and add/or'ing
but then the generated code is pretty bad. Using struct {int lo,hi;}'s
produces better code (none of the registers actually need moving from
their argument positions) but honestly isn't any less ugly.
>
>> + __asm__ volatile (
>> + "SETL [A0StP++], %6,%5\n\t"
>> + "SETL [A0StP++], %4,%3\n\t"
>> + "SETL [A0StP++], %2,%1\n\t"
Using specific registers also allows these three to be combined into a
single MSETL instruction... I'll do that.
>> + "ADD A0StP, A0StP, #8\n\t"
>> + "SWITCH #0x0C30208\n\t"
>> + "GETD %0, [A0StP+#-8]\n\t"
>> + "SUB A0StP, A0StP, #(4*6)+8\n\t"
>> + : "=r" (result)/* outs */
>> + : "r" (bios_function__), "r" (channel__), "r" (arg2__),
>> + "r" (arg3__), "r" (arg4__), "r" (bios_call) /* ins */
>> + : "memory");
>> +
>> + return result;
>> +}
> ...
>> +static int dashtty_port_activate(struct tty_port *port, struct tty_struct *tty)
>> +{
>> + struct dashtty_port *dport = container_of(port, struct dashtty_port,
>> + port);
>> + void *rx_buf;
>> +
>> + /* Allocate the buffer we use for writing data */
>> + if (tty_port_alloc_xmit_buf(port) < 0)
>> + goto err;
>> +
>> + /* Allocate the buffer we use for reading data */
>> + rx_buf = kzalloc(RX_BUF_SIZE, GFP_KERNEL);
>> + if (!rx_buf)
>> + goto err_free_xmit;
>> +
>> + spin_lock_bh(&dport->rx_lock);
>> + dport->rx_buf = rx_buf;
>> + spin_unlock_bh(&dport->rx_lock);
>> +
>> + return 0;
>> +err_free_xmit:
>> + tty_port_free_xmit_buf(port);
>> +err:
>> + return -ENOMEM;
>> +}
>> +
>> +static void dashtty_port_shutdown(struct tty_port *port)
>> +{
>> + struct dashtty_port *dport = container_of(port, struct dashtty_port,
>> + port);
>> + void *rx_buf;
>> + unsigned int count;
>> +
>> + mutex_lock(&dport->xmit_lock);
>> + count = dport->xmit_cnt;
>> + mutex_unlock(&dport->xmit_lock);
>> + if (count) {
>> + /*
>> + * There's still data to write out, so wake and wait for the
>> + * writer thread to drain the buffer.
>> + */
>> + del_timer(&put_timer);
>> + wake_up_interruptible(&dashtty_waitqueue);
>> + wait_for_completion(&dport->xmit_empty);
>> + }
>> +
>> + /* Null the read buffer (timer could still be running!) */
>> + spin_lock_bh(&dport->rx_lock);
>> + rx_buf = dport->rx_buf;
>> + dport->rx_buf = NULL;
>> + spin_unlock_bh(&dport->rx_lock);
>> + /* Free the read buffer */
>> + kfree(rx_buf);
>> +
>> + /* Free the write buffer */
>> + tty_port_free_xmit_buf(port);
>> +}
>> +
>> +static const struct tty_port_operations dashtty_port_ops = {
>> + .activate = dashtty_port_activate,
>> + .shutdown = dashtty_port_shutdown,
>> +};
>> +
>> +static int dashtty_install(struct tty_driver *driver, struct tty_struct *tty)
>> +{
>> + struct dashtty_port *port;
>> + int ret, line;
>> +
>> + if (!tty)
>> + return -ENODEV;
>
> This will never happen.
Agreed, I thought I'd removed these but must've missed them.
>
>> + line = tty->index;
>> +
>> + if (line < 0 || line >= NUM_TTY_CHANNELS)
>> + return -ENODEV;
>
> Neither this.
Agreed.
>
>> + port = &dashtty_ports[line];
>> +
>> + port->port.ops = &dashtty_port_ops;
>
> You can do that along with tty_port_init in the module_init function.
Yes, good idea.
>
>> + ret = tty_port_install(&port->port, driver, tty);
>> + if (ret)
>> + return ret;
>> +
>> + /*
>> + * Don't add the poll timer if we're opening a console. This
>> + * avoids the overhead of polling the Dash but means it is not
>> + * possible to have a login on /dev/console.
>> + *
>> + */
>> + if (line != CONSOLE_CHANNEL)
>> + if (atomic_inc_return(&num_channels_need_poll) == 1)
>> + add_poll_timer(&poll_timer);
>
> This should be in activate I suppose. You don't need install/cleanup at
> all I beleive.
Yes, I've moved it in there (but with s/line != CONSOLE_CHANNEL/dport !=
&dashtty_ports[CONSOLE_CHANNEL]/). That just leaves a one line install
callback which just passes the relevant tty_port to tty_port_install.
>
>> + return 0;
>> +}
>> +
>> +static void dashtty_cleanup(struct tty_struct *tty)
>> +{
>> + int line;
>> +
>> + if (!tty)
>> + return;
>
> The same as above.
>
>> + line = tty->index;
>> +
>> + if (line < 0 || line >= NUM_TTY_CHANNELS)
>> + return;
>
> Detto.
>
>> + if (line != CONSOLE_CHANNEL)
>> + if (atomic_dec_and_test(&num_channels_need_poll))
>> + del_timer_sync(&poll_timer);
>
> To shutdown. No need for cleanup.
agreed, done.
>> +static int dashtty_write_room(struct tty_struct *tty)
>> +{
>> + struct dashtty_port *dport;
>> + int channel;
>> + int room;
>> +
>> + channel = FIRST_TTY_CHANNEL + tty->index;
>
> FIRST_TTY_CHANNEL doesn't make much sense. Better to be removed completely.
Agreed, I'm not sure what this was originally for but I've removed it now.
>
>> + dport = &dashtty_ports[channel];
>> +
>> + /* report the space in the xmit buffer */
>> + mutex_lock(&dport->xmit_lock);
>> + room = SERIAL_XMIT_SIZE - dport->xmit_cnt;
>> + mutex_unlock(&dport->xmit_lock);
>> +
>> + return room;
>> +}
> ...
>> +static int __init dashtty_init(void)
>> +{
>> + int ret;
>> + int nport;
>> + struct dashtty_port *dport;
>> +
>> + if (!metag_da_enabled())
>> + return -ENODEV;
>> +
>> + channel_driver = tty_alloc_driver(NUM_TTY_CHANNELS, 0);
>
> This should be s/0/TTY_DRIVER_REAL_RAW/.
Neat, thanks
>
>> + if (IS_ERR(channel_driver))
>> + return PTR_ERR(channel_driver);
>> +
>> + channel_driver->owner = THIS_MODULE;
>
> No need to set this.
Yes, I see it's passed into __tty_alloc_driver automatically.
>
>> + channel_driver->driver_name = "ttyDA";
>
> This should be rather "metag".
Yes, I'll set to "metag_da" if that's okay since the transport is the
DA. I presume this is pretty much just to appear in /proc/tty/drivers?
>
>> + channel_driver->name = "ttyDA";
>> + channel_driver->major = DA_TTY_MAJOR;
>> + channel_driver->minor_start = 0;
>> + channel_driver->type = TTY_DRIVER_TYPE_SERIAL;
>> + channel_driver->subtype = SERIAL_TYPE_NORMAL;
>> + channel_driver->init_termios = tty_std_termios;
>> + channel_driver->init_termios.c_cflag |= CLOCAL;
>> + channel_driver->flags = TTY_DRIVER_REAL_RAW;
>
> And this is unnecessary now.
>
>> +
>> + tty_set_operations(channel_driver, &dashtty_ops);
>> + for (nport = 0; nport < NUM_TTY_CHANNELS; nport++) {
>> + dport = &dashtty_ports[nport];
>> + tty_port_init(&dport->port);
>> + spin_lock_init(&dport->rx_lock);
>> + mutex_init(&dport->xmit_lock);
>> + /* the xmit buffer starts empty, i.e. completely written */
>> + init_completion(&dport->xmit_empty);
>> + complete(&dport->xmit_empty);
>> + }
>> +
>> + init_timer(&put_timer);
>> + put_timer.function = dashtty_put_timer;
>
> setup_timer()
Thanks, I've also changed the other timer to use this too
>
>> + init_waitqueue_head(&dashtty_waitqueue);
>> + dashtty_thread = kthread_create(put_data, NULL, "ttyDA");
>> + if (IS_ERR(dashtty_thread)) {
>> + pr_err("Couldn't create dashtty thread\n");
>> + ret = PTR_ERR(dashtty_thread);
>> + goto err_free_driver;
>> + }
>> + kthread_bind(dashtty_thread, 0);
>
> This deserves a comment why you bind it to CPU0...
Okay, comment added:
+ /*
+ * Bind the writer thread to the boot CPU so it can't migrate.
+ * DA channels are per-CPU and we want all channel I/O to be on a single
+ * predictable CPU.
+ */
>
>> + wake_up_process(dashtty_thread);
>> +
>> + ret = tty_register_driver(channel_driver);
>> +
>> + if (ret < 0) {
>> + pr_err("Couldn't install dashtty driver: err %d\n",
>> + ret);
>> + goto err_stop_kthread;
>> + }
>> +
>> + return 0;
>> +
>> +err_stop_kthread:
>> + kthread_stop(dashtty_thread);
>> +err_free_driver:
>> + put_tty_driver(channel_driver);
>> + return ret;
>> +}
>> +
>> +static void dashtty_exit(void)
>> +{
>> + del_timer_sync(&put_timer);
>> + kthread_stop(dashtty_thread);
>> + del_timer_sync(&poll_timer);
>> + tty_unregister_driver(channel_driver);
>> + put_tty_driver(channel_driver);
>
> No tty_port_destroy anywhere?
Ah yes, I've added a loop to do this before put_tty_driver() both here
and in the error handling of dashtty_init().
This driver isn't actually buildable as a module at the moment, but if
it was, would the module owner being set ensure that the ttys/ports are
closed down prior to dashtty_exit being called? (i.e. is it racy?)
>
>> +}
>> +
>> +module_init(dashtty_init);
>> +module_exit(dashtty_exit);
>
> thanks,
>
Thanks for reviewing,
Cheers
James
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-01-11 10:50 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-10 15:30 [PATCH v3 00/44] Meta Linux Kernel Port James Hogan
2013-01-10 15:30 ` [PATCH v3 01/44] asm-generic/io.h: check CONFIG_VIRT_TO_BUS James Hogan
2013-01-10 15:30 ` [PATCH v3 02/44] asm-generic/unistd.h: handle symbol prefixes in cond_syscall James Hogan
2013-01-10 15:30 ` [PATCH v3 03/44] Revert some of "binfmt_elf: cleanups" James Hogan
2013-01-10 15:30 ` [PATCH v3 04/44] Add HAVE_64BIT_ALIGNED_ACCESS James Hogan
2013-01-10 15:30 ` [PATCH v3 05/44] trace/ring_buffer: handle 64bit aligned structs James Hogan
2013-01-10 15:30 ` [PATCH v3 06/44] metag: Add MAINTAINERS entry James Hogan
2013-01-10 15:30 ` [PATCH v3 07/44] metag: Headers for core arch constants James Hogan
2013-01-10 15:30 ` [PATCH v3 08/44] metag: Header for core memory mapped registers James Hogan
2013-01-10 15:30 ` [PATCH v3 09/44] metag: Boot James Hogan
2013-01-10 15:30 ` [PATCH v3 10/44] metag: TBX header James Hogan
2013-01-10 15:30 ` [PATCH v3 11/44] metag: TBX source James Hogan
2013-01-10 15:30 ` [PATCH v3 12/44] metag: Cache/TLB handling James Hogan
2013-01-10 15:30 ` [PATCH v3 13/44] metag: Memory management James Hogan
2013-01-10 15:30 ` [PATCH v3 14/44] metag: Memory handling James Hogan
2013-01-10 15:30 ` [PATCH v3 15/44] metag: Huge TLB James Hogan
2013-01-10 16:57 ` Dave Hansen
2013-01-11 9:58 ` James Hogan
2013-01-10 15:30 ` [PATCH v3 16/44] metag: Highmem support James Hogan
2013-01-10 15:30 ` [PATCH v3 17/44] metag: TCM support James Hogan
2013-01-10 15:30 ` [PATCH v3 18/44] metag: Signal handling James Hogan
2013-01-10 15:30 ` [PATCH v3 19/44] metag: Device tree James Hogan
2013-02-06 13:06 ` Vineet Gupta
2013-02-06 13:47 ` James Hogan
2013-01-10 15:30 ` [PATCH v3 20/44] metag: ptrace James Hogan
2013-01-10 15:30 ` [PATCH v3 21/44] metag: Time keeping James Hogan
2013-01-26 0:03 ` Arnd Bergmann
2013-01-28 12:59 ` James Hogan
2013-01-10 15:30 ` [PATCH v3 22/44] metag: Traps James Hogan
2013-01-10 15:30 ` [PATCH v3 23/44] metag: IRQ handling James Hogan
2013-01-10 15:30 ` [PATCH v3 24/44] metag: Internal and external irqchips James Hogan
2013-01-10 15:30 ` [PATCH v3 25/44] metag: System Calls James Hogan
2013-01-10 15:30 ` [PATCH v3 26/44] metag: Scheduling/Process management James Hogan
2013-01-10 15:30 ` [PATCH v3 27/44] metag: Module support James Hogan
2013-01-10 15:30 ` [PATCH v3 28/44] metag: Atomics, locks and bitops James Hogan
2013-01-10 15:30 ` [PATCH v3 29/44] metag: Basic documentation James Hogan
2013-01-10 15:30 ` [PATCH v3 30/44] metag: SMP support James Hogan
2013-01-10 15:30 ` [PATCH v3 31/44] metag: DMA James Hogan
2013-01-10 15:31 ` [PATCH v3 32/44] metag: Optimised library functions James Hogan
2013-01-10 15:31 ` [PATCH v3 33/44] metag: Stack unwinding James Hogan
2013-01-10 15:31 ` [PATCH v3 34/44] metag: Various other headers James Hogan
2013-01-10 15:31 ` [PATCH v3 35/44] mm: define VM_GROWSUP for CONFIG_METAG James Hogan
2013-01-10 15:31 ` [PATCH v3 36/44] Kconfig.debug: add METAG to dependency lists James Hogan
2013-01-10 15:31 ` [PATCH v3 37/44] metag: Build infrastructure James Hogan
2013-01-10 15:31 ` [PATCH v3 38/44] metag: Perf James Hogan
2013-01-10 15:31 ` [PATCH v3 39/44] metag: ftrace support James Hogan
2013-01-10 15:59 ` Steven Rostedt
2013-01-10 16:00 ` Steven Rostedt
2013-01-10 16:13 ` James Hogan
2013-01-10 15:31 ` [PATCH v3 40/44] scripts/checkstack.pl: Add metag support James Hogan
2013-01-10 15:31 ` [PATCH v3 41/44] metag: OProfile James Hogan
2013-01-10 17:12 ` Maynard Johnson
2013-01-11 9:43 ` James Hogan
2013-01-10 15:31 ` [PATCH v3 42/44] metag: Add JTAG Debug Adapter (DA) support James Hogan
2013-01-10 15:31 ` [PATCH v3 43/44] tty/metag_da: Add metag DA TTY driver James Hogan
2013-01-10 16:03 ` Jiri Slaby
2013-01-11 10:50 ` James Hogan [this message]
2013-01-14 10:15 ` Jiri Slaby
2013-01-14 10:54 ` James Hogan
2013-01-25 11:36 ` James Hogan
2013-01-30 5:14 ` Greg Kroah-Hartman
2013-01-30 10:43 ` James Hogan
2013-01-10 15:31 ` [PATCH v3 44/44] fs: imgdafs: Add IMG DAFS filesystem for metag James Hogan
2013-01-28 13:28 ` James Hogan
2013-01-10 23:34 ` [PATCH v3 00/44] Meta Linux Kernel Port Stephen Rothwell
2013-01-11 9:15 ` James Hogan
2013-01-11 13:03 ` Stephen Rothwell
2013-01-11 13:16 ` James Hogan
2013-01-11 15:02 ` James Hogan
2013-01-12 1:09 ` Stephen Rothwell
2013-01-12 9:55 ` James Hogan
2013-01-12 14:56 ` Stephen Rothwell
2013-01-19 5:55 ` Al Viro
2013-01-22 11:35 ` James Hogan
2013-01-25 17:04 ` James Hogan
2013-01-26 0:25 ` Arnd Bergmann
2013-01-26 21:53 ` James Hogan
2013-01-28 7:10 ` Vineet Gupta
2013-01-28 11:08 ` James Hogan
2013-01-29 12:45 ` ARC Port for linux-next (was Re: [PATCH v3 00/44] Meta Linux Kernel Port) Vineet Gupta
2013-01-29 20:44 ` [PATCH v3 00/44] Meta Linux Kernel Port Stephen Rothwell
2013-01-29 20:50 ` Stephen Rothwell
2013-02-01 8:18 ` linux-net for ARC port Vineet Gupta
2013-02-01 12:05 ` Stephen Rothwell
2013-02-01 12:33 ` Geert Uytterhoeven
2013-02-01 12:59 ` Stephen Rothwell
2013-02-05 13:54 ` [PATCH v3 00/44] Meta Linux Kernel Port Vineet Gupta
2013-02-05 23:40 ` rkuo
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=50EFEE71.4000706@imgtec.com \
--to=james.hogan@imgtec.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=cesarb@cesarb.net \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=joe@perches.com \
--cc=jslaby@suse.cz \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@redhat.com \
/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
Powered by JetHome