[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTinnuxvx9+eNvCqjK2GW2XQPn4LjK4WfMj=f20Xw@mail.gmail.com>
Date: Mon, 10 Jan 2011 22:08:48 -0500
From: Mike Frysinger <vapier@...too.org>
To: linux-serial@...r.kernel.org, Greg Kroah-Hartman <gregkh@...e.de>,
Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: uclinux-dist-devel@...ckfin.uclinux.org,
linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH] drivers: char: hvc: add Blackfin JTAG console support
On Mon, Jan 10, 2011 at 21:43, Mike Frysinger wrote:
> This converts the existing bfin_jtag_comm TTY driver to the HVC layer so
> that the common HVC code can worry about all of the TTY/polling crap and
> leave the Blackfin code to worry about the Blackfin bits.
ive noticed a few downsides of converting to this ...
hvc cant be built as a module. but not that big of a deal i guess.
throughput seems to be a bit lower. the Blackfin JTAG hardware has
basically a 4 byte fifo that is filled/consumed in a single shot. and
the Blackfin can produce much faster than the host can consume. so
atm, i have it send out 4 bytes, and the hvc layers take care of
calling back into me at some point. if i add a busy loop to run a few
hundred milliseconds (like HZ/4), it runs much nicer. but obviously
doesnt give anyone else time to run. i cant schedule or anything as
the write layers are called with a spin_lock_irqsave. any tips for
how to speed this up a bit ? or is it a wash with hvc ?
the code size also increased a bit ... old driver added up to ~1.7KiB
while hvc stuff is like ~4KiB. but hvc does a nice job of keeping the
Blackfin-specific piece small. so i guess it's a wash.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists