[PATCH 02/19] io-mapping: Specify mapping size for io_mapping_map_wc()

[Luis R. Rodriguez]

On Wed, Apr 20, 2016 at 08:14:32PM +0100, Chris Wilson wrote:
> On Wed, Apr 20, 2016 at 08:58:44PM +0200, Luis R. Rodriguez wrote:
> > On Wed, Apr 20, 2016 at 07:42:13PM +0100, Chris Wilson wrote:
> > > The ioremap() hidden behind the io_mapping_map_wc() convenience helper
> > > can be used for remapping multiple pages. Extend the helper so that
> > > future callers can use it for larger ranges.
> > > 
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> > > Cc: Daniel Vetter <daniel.vetter at intel.com>
> > > Cc: Jani Nikula <jani.nikula at linux.intel.com>
> > > Cc: David Airlie <airlied at linux.ie>
> > > Cc: Yishai Hadas <yishaih at mellanox.com>
> > > Cc: Dan Williams <dan.j.williams at intel.com>
> > > Cc: Ingo Molnar <mingo at kernel.org>
> > > Cc: "Peter Zijlstra (Intel)" <peterz at infradead.org>
> > > Cc: David Hildenbrand <dahi at linux.vnet.ibm.com>
> > > Cc: Luis R. Rodriguez <mcgrof at kernel.org>
> > > Cc: intel-gfx at lists.freedesktop.org
> > > Cc: dri-devel at lists.freedesktop.org
> > > Cc: netdev at vger.kernel.org
> > > Cc: linux-rdma at vger.kernel.org
> > > Cc: linux-kernel at vger.kernel.org
> > 
> > We have 2 callers today, in the future, can you envision
> > this API getting more options? If so, in order to avoid the
> > pain of collateral evolutions I can suggest a descriptor
> > being passed with the required settings / options. This lets
> > you evolve the API without needing to go in and modify
> > old users. If you choose not to that's fine too, just
> > figured I'd chime in with that as I've seen the pain
> > with other APIs, and I'm putting an end to the needless
> > set of collateral evolutions this way.
> 
> Do you have a good example in mind? I've one more patch to try and take
> advantage of the io-mapping (that may or not be such a good idea in
> practice) but I may as well see if I can make io_mapping more useful
> when I do.

Sure, here's my current version of the revamp of the firmware API
to a more flexible API, which lets us compartamentalize the
usermode helper, and through the new API avoids the issues with further
future collateral evolutions. It is still being baked, I'm fine tuning
the SmPL to folks automatically do conversion if they want:

https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux.git/log/?h=20160417-sysdata-api-v1

It also has a test driver (which I'd also recommend if you can pull off).
It would be kind of hard to do something like a lib/io-mapping_test.c
given there is no real device to ioremap -- _but_ perhaps regular
RAM can be used for fake a device MMIO. I am not sure if its even
possible... but if so it would not only be useful for something
like your API but also for testing ioremap() and friends, and
any possible aliasing bombs we may want to vet for. It also hints
how we may in the future be able to automatically write test drivers
for APIs for us through inference, but that needs a lot of more love
to make it tangible.

  Luis