LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Todd Poynor <toddpoynor@google.com>
To: "Ahmed S. Darwish" <darwish.07@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Rob Springer <rspringer@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	devel@linuxdriverproject.org
Subject: RFC: staging: gasket: re-implement using UIO
Date: Tue, 6 Nov 2018 16:20:49 -0800
Message-ID: <CAAW3YpZj=U=RtKLtB3Wq-agi9Vxxd_Mn8x1qo5hXXcV7hSLV9Q@mail.gmail.com> (raw)
In-Reply-To: <20180910152837.GA31819@darwi-kernel>

On Mon, Sep 10, 2018 at 8:28 AM Ahmed S. Darwish <darwish.07@gmail.com> wrote:
>
> The gasket in-kernel framework, recently introduced under staging,
> re-implements what is already long-time provided by the UIO
> subsystem, with extra PCI BAR remapping and MSI conveniences.
>
> Before moving it out of staging, make sure we add the new bits to
> the UIO framework instead, then transform its signle client, the
> Apex driver, to a proper UIO driver (uio_driver.h).
>
> Link: https://lkml.kernel.org/r/20180828103817.GB1397@do-kernel

So I'm looking at this for reals now.  The BAR mapping stuff is
straightforward with the existing framework.  Everything else could be
done outside of UIO via the existing device interface, but figured I'd
collect any opinions about adding the new bits to UIO.

The Apex device has 13 MSIX interrupts.  UIO does one IRQ per device.
The PRUSS driver registers 8 instances of the UIO device with
identical memory mappings but individual IRQs for its 8 interrupts.
Currently gasket has userspace pass down an eventfd (via ioctl) for
each interrupt it wants to watch.  Is there interest in modifying UIO
to handle multiple IRQs in some perhaps similar fashion?

Speaking of ioctls, are those allowed here, or is sysfs or something
else always required?  The aforementioned multiple IRQ stuff probably
maps nicely to sysfs (there's a small number of them easily
represented as attributes), while DMA buffer mappings seem more
problematic, but maybe somebody's thought of a good way to represent
these already.

And then we need to map buffers to our device.  We could probably
implement this via an IOMMU driver API for our custom MMU and hook
that up to generic IOMMU support for UIO, which sounds like something
a lot of drivers could use.

There's a few other tidbits the driver does, including allocating
coherent memory for userspace to share with the device, but that's
probably enough for now.

If anybody wants to squash any of the above as a non-starter for UIO
or point things in a different direction, it's appreciated.

Thanks,


Todd

  reply index

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-18 15:57 [GIT PULL] Staging/IIO driver patches for 4.19-rc1 Greg KH
2018-08-18 18:00 ` Linus Torvalds
2018-08-19  6:07   ` Greg Kroah-Hartman
2018-08-28 10:38 ` Ahmed S. Darwish
2018-08-28 11:20   ` Todd Poynor
2018-08-28 12:36   ` Greg KH
2018-08-28 14:30     ` Ahmed S. Darwish
2018-09-10  8:16       ` Greg KH
2018-09-10 15:28         ` [PATCH] staging: gasket: TODO: re-implement using UIO Ahmed S. Darwish
2018-11-07  0:20           ` Todd Poynor [this message]
2018-11-07  9:20             ` RFC: staging: gasket: " Greg KH

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='CAAW3YpZj=U=RtKLtB3Wq-agi9Vxxd_Mn8x1qo5hXXcV7hSLV9Q@mail.gmail.com' \
    --to=toddpoynor@google.com \
    --cc=darwish.07@gmail.com \
    --cc=devel@linuxdriverproject.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rspringer@google.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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lkml.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lkml.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lkml.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lkml.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lkml.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lkml.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lkml.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lkml.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lkml.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lkml.kernel.org/lkml/9 lkml/git/9.git
	git clone --mirror https://lkml.kernel.org/lkml/10 lkml/git/10.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lkml.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git