From: Greg KH <gregkh@linuxfoundation.org>
To: Kumaravel.Thiagarajan@microchip.com
Cc: Richard.Petrie@microchip.com, linux-serial@vger.kernel.org,
Sundararaman.H@microchip.com, Ronnie.Kunin@microchip.com,
Tharunkumar.Pasumarthi@microchip.com, Annirudh.D@microchip.com,
Pragash.Mangalapandian@microchip.com
Subject: Re: Reg: Serial port driver for microchip's new PCIe UART device
Date: Fri, 11 Feb 2022 13:02:23 +0100 [thread overview]
Message-ID: <YgZQT9SFWQcXm9C7@kroah.com> (raw)
In-Reply-To: <CH0PR11MB5380EE38DD9B8BF9EE5F1796E92F9@CH0PR11MB5380.namprd11.prod.outlook.com>
On Thu, Feb 10, 2022 at 10:38:39AM +0000, Kumaravel.Thiagarajan@microchip.com wrote:
> > > We are working on a PCIe based multi-instance UART device.
> > > Based on the Linux community feedback few months back, we had written
> > it as a custom driver inside drivers/tty/serial/8250.
> > > Now this custom driver is requiring a DWORD FIFO access for both Tx and
> > Rx, and I am in the process of changing my driver code.
> >
> > Why does the hardware not follow the normal standard here?
> We are building a PCIe 8250 based UART. We can absolutely support the normal 8250 framework and standard drivers.
> However, the challenges we see are the round-trip delays introduced by PCIe reads and writes having an impact on throughput, particularly if you are downstream of a PCIe tree with multiple hops.
> The sizes of the payloads are limited to 32-bit by the processor PIO, however, even going from 8-bit payloads to 32-bit payloads improves throughput dramatically.
What specific reads are you having problems with?
Why not just use DMA like other PCIe serial port cards do, which we have
supported for decades now.
> > And are you sure it will still not fit into the 8250 format?
> As mentioned our hardware can support this, however, we see that it is less efficient due to the requirement for single byte reads and writes.
Again, which reads/writes are taking a long time? And again, why not
use DMA for the data instead?
> > > Can I model my custom driver on serial drivers present in drivers/tty/serial/
> > directory?
> >
> > You could, but it would be much smaller and easier to use the 8250
> > framework given that you probably do have an 8250-like device, right?
> Adding DWORD reads/writes to the hardware is a necessary enhancement for improved performance over PCIe.
> But 8250 framework looks very closely tied with reading character by character from the FIFO and I was not able to find a place in that framework where I could hook my own DWORD based Rx and Tx logic.
> Is there any DWORD based UART FIFO driver example with 8250 framework available?
All of the code is there for you to read :)
thanks,
greg k-h
next prev parent reply other threads:[~2022-02-11 12:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-09 10:38 Reg: Serial port driver for microchip's new PCIe UART device Kumaravel.Thiagarajan
2022-02-09 11:30 ` Greg KH
2022-02-10 10:38 ` Kumaravel.Thiagarajan
2022-02-11 12:02 ` Greg KH [this message]
2022-02-14 12:51 ` Kumaravel.Thiagarajan
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=YgZQT9SFWQcXm9C7@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Annirudh.D@microchip.com \
--cc=Kumaravel.Thiagarajan@microchip.com \
--cc=Pragash.Mangalapandian@microchip.com \
--cc=Richard.Petrie@microchip.com \
--cc=Ronnie.Kunin@microchip.com \
--cc=Sundararaman.H@microchip.com \
--cc=Tharunkumar.Pasumarthi@microchip.com \
--cc=linux-serial@vger.kernel.org \
/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).