| Message ID | 1461177750-20187-3-git-send-email-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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@chris-wilson.co.uk> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > Cc: Daniel Vetter <daniel.vetter@intel.com> > Cc: Jani Nikula <jani.nikula@linux.intel.com> > Cc: David Airlie <airlied@linux.ie> > Cc: Yishai Hadas <yishaih@mellanox.com> > Cc: Dan Williams <dan.j.williams@intel.com> > Cc: Ingo Molnar <mingo@kernel.org> > Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> > Cc: David Hildenbrand <dahi@linux.vnet.ibm.com> > Cc: Luis R. Rodriguez <mcgrof@kernel.org> > Cc: intel-gfx@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Cc: netdev@vger.kernel.org > Cc: linux-rdma@vger.kernel.org > Cc: linux-kernel@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. Other than that possible API optimization: Reviewed-by: Luis R. Rodriguez <mcgrof@kernel.org> Luis
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@chris-wilson.co.uk> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > > Cc: Daniel Vetter <daniel.vetter@intel.com> > > Cc: Jani Nikula <jani.nikula@linux.intel.com> > > Cc: David Airlie <airlied@linux.ie> > > Cc: Yishai Hadas <yishaih@mellanox.com> > > Cc: Dan Williams <dan.j.williams@intel.com> > > Cc: Ingo Molnar <mingo@kernel.org> > > Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> > > Cc: David Hildenbrand <dahi@linux.vnet.ibm.com> > > Cc: Luis R. Rodriguez <mcgrof@kernel.org> > > Cc: intel-gfx@lists.freedesktop.org > > Cc: dri-devel@lists.freedesktop.org > > Cc: netdev@vger.kernel.org > > Cc: linux-rdma@vger.kernel.org > > Cc: linux-kernel@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. -Chris
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@chris-wilson.co.uk> > > > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > > > Cc: Daniel Vetter <daniel.vetter@intel.com> > > > Cc: Jani Nikula <jani.nikula@linux.intel.com> > > > Cc: David Airlie <airlied@linux.ie> > > > Cc: Yishai Hadas <yishaih@mellanox.com> > > > Cc: Dan Williams <dan.j.williams@intel.com> > > > Cc: Ingo Molnar <mingo@kernel.org> > > > Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> > > > Cc: David Hildenbrand <dahi@linux.vnet.ibm.com> > > > Cc: Luis R. Rodriguez <mcgrof@kernel.org> > > > Cc: intel-gfx@lists.freedesktop.org > > > Cc: dri-devel@lists.freedesktop.org > > > Cc: netdev@vger.kernel.org > > > Cc: linux-rdma@vger.kernel.org > > > Cc: linux-kernel@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
diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c index 9746b9841c13..0d5a376878d3 100644 --- a/drivers/gpu/drm/i915/intel_overlay.c +++ b/drivers/gpu/drm/i915/intel_overlay.c @@ -198,7 +198,8 @@ intel_overlay_map_regs(struct intel_overlay *overlay) regs = (struct overlay_registers __iomem *)overlay->reg_bo->phys_handle->vaddr; else regs = io_mapping_map_wc(ggtt->mappable, - overlay->flip_addr); + overlay->flip_addr, + PAGE_SIZE); return regs; } diff --git a/drivers/net/ethernet/mellanox/mlx4/pd.c b/drivers/net/ethernet/mellanox/mlx4/pd.c index b3cc3ab63799..6fc156a3918d 100644 --- a/drivers/net/ethernet/mellanox/mlx4/pd.c +++ b/drivers/net/ethernet/mellanox/mlx4/pd.c @@ -205,7 +205,9 @@ int mlx4_bf_alloc(struct mlx4_dev *dev, struct mlx4_bf *bf, int node) goto free_uar; } - uar->bf_map = io_mapping_map_wc(priv->bf_mapping, uar->index << PAGE_SHIFT); + uar->bf_map = io_mapping_map_wc(priv->bf_mapping, + uar->index << PAGE_SHIFT, + PAGE_SIZE); if (!uar->bf_map) { err = -ENOMEM; goto unamp_uar; diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h index e399029b68c5..645ad06b5d52 100644 --- a/include/linux/io-mapping.h +++ b/include/linux/io-mapping.h @@ -100,14 +100,16 @@ io_mapping_unmap_atomic(void __iomem *vaddr) } static inline void __iomem * -io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset) +io_mapping_map_wc(struct io_mapping *mapping, + unsigned long offset, + unsigned long size) { resource_size_t phys_addr; BUG_ON(offset >= mapping->size); phys_addr = mapping->base + offset; - return ioremap_wc(phys_addr, PAGE_SIZE); + return ioremap_wc(phys_addr, size); } static inline void @@ -155,7 +157,9 @@ io_mapping_unmap_atomic(void __iomem *vaddr) /* Non-atomic map/unmap */ static inline void __iomem * -io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset) +io_mapping_map_wc(struct io_mapping *mapping, + unsigned long offset, + unsigned long size) { return ((char __force __iomem *) mapping) + offset; }
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@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Yishai Hadas <yishaih@mellanox.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> Cc: David Hildenbrand <dahi@linux.vnet.ibm.com> Cc: Luis R. Rodriguez <mcgrof@kernel.org> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: netdev@vger.kernel.org Cc: linux-rdma@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/gpu/drm/i915/intel_overlay.c | 3 ++- drivers/net/ethernet/mellanox/mlx4/pd.c | 4 +++- include/linux/io-mapping.h | 10 +++++++--- 3 files changed, 12 insertions(+), 5 deletions(-)