From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency
Date: Thu, 14 Feb 2013 14:47:10 -0800 [thread overview]
Message-ID: <20130214224710.GF11362@atomide.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1302142124370.11016@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [130214 13:44]:
> Hi,
>
> On Thu, 14 Feb 2013, Paul Walmsley wrote:
>
> > So instead of something bus-specific like that, a better way would be to
> > use something like:
> >
> > va = dev->bus->ioremap( ... );
> > va = dev->bus->iounmap( ... );
>
> Something like this is what I was thinking. Obviously there would be more
> patches needed, for the various arches, etc.; and I'm not convinced that
> the function pointer init is done at the right time yet. Comments welcome.
>
>
> - Paul
>
>
> From: Paul Walmsley <paul@pwsan.com>
> Date: Thu, 14 Feb 2013 13:49:58 -0700
> Subject: [PATCH] EXPERIMENTAL: device/ARM: allow buses to override ioremap*()
> and iounmap()
>
> On some hardware, such as OMAP, the bus abstraction code needs to call
> ioremap(), since some SoC-integration registers are located in the
> device address space. But generic device drivers should be able to
> call ioremap() from driver code, for the majority of situations where
> this isn't necessary. This experimental patch allows Linux bus abstraction
> code to override all of the ioremap*() and iounmap() functions. In the OMAP
> case, this would be used to return the previously-mapped address range from
> the bus code, when called for the device's register area. This would avoid
> a duplicate TLB mapping for that space.
>
> This might also be useful as a generic replacement for pci_ioremap_bar().
>
> Compile-tested only.
The other option could be to allow custom ioremap function pointers
based on address range in __arm_ioremap_pfn_caller() the same way as
the SoC specific static mappings are allowed. That would require adding
a function pointer to struct map_desc.
Maybe that would do the trick?
Regards,
Tony
> ---
> arch/arm/include/asm/io.h | 10 +++++-----
> arch/arm/mm/ioremap.c | 30 ++++++++++++++++++++++++++++++
> arch/arm/mm/mmu.c | 8 ++++++++
> include/linux/device.h | 26 ++++++++++++++++++++++++++
> 4 files changed, 69 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
> index 652b560..22cc085 100644
> --- a/arch/arm/include/asm/io.h
> +++ b/arch/arm/include/asm/io.h
> @@ -325,11 +325,11 @@ extern void _memset_io(volatile void __iomem *, int, size_t);
> * Documentation/io-mapping.txt.
> *
> */
> -#define ioremap(cookie,size) __arm_ioremap((cookie), (size), MT_DEVICE)
j> -#define ioremap_nocache(cookie,size) __arm_ioremap((cookie), (size), MT_DEVICE)
> -#define ioremap_cached(cookie,size) __arm_ioremap((cookie), (size), MT_DEVICE_CACHED)
> -#define ioremap_wc(cookie,size) __arm_ioremap((cookie), (size), MT_DEVICE_WC)
> -#define iounmap __arm_iounmap
> +extern void __iomem *ioremap(unsigned long cookie, size_t size);
> +extern void __iomem *ioremap_nocache(unsigned long cookie, size_t size);
> +extern void __iomem *ioremap_cached(unsigned long cookie, size_t size);
> +extern void __iomem *ioremap_wc(unsigned long cookie, size_t size);
> +extern void iounmap(volatile void __iomem *va);
>
> /*
> * io{read,write}{8,16,32} macros
> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
> index 88fd86c..6507e69 100644
> --- a/arch/arm/mm/ioremap.c
> +++ b/arch/arm/mm/ioremap.c
> @@ -398,3 +398,33 @@ int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr)
> }
> EXPORT_SYMBOL_GPL(pci_ioremap_io);
> #endif
> +
> +void __iomem *ioremap(unsigned long cookie, size_t size)
> +{
> + return __arm_ioremap(cookie, size, MT_DEVICE);
> +}
> +EXPORT_SYMBOL(ioremap);
> +
> +void __iomem *ioremap_nocache(unsigned long cookie, size_t size)
> +{
> + return __arm_ioremap(cookie, size, MT_DEVICE);
> +}
> +EXPORT_SYMBOL(ioremap_nocache);
> +
> +void __iomem *ioremap_cached(unsigned long cookie, size_t size)
> +{
> + return __arm_ioremap(cookie, size, MT_DEVICE_CACHED);
> +}
> +EXPORT_SYMBOL(ioremap_cached);
> +
> +void __iomem *ioremap_wc(unsigned long cookie, size_t size)
> +{
> + return __arm_ioremap(cookie, size, MT_DEVICE_WC);
> +}
> +EXPORT_SYMBOL(ioremap_wc);
> +
> +void iounmap(volatile void __iomem *va)
> +{
> + return __arm_iounmap(va);
> +}
> +EXPORT_SYMBOL(iounmap);
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index ce328c7..303dba0 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -17,6 +17,7 @@
> #include <linux/fs.h>
> #include <linux/vmalloc.h>
> #include <linux/sizes.h>
> +#include <linux/platform_device.h>
>
> #include <asm/cp15.h>
> #include <asm/cputype.h>
> @@ -28,6 +29,7 @@
> #include <asm/highmem.h>
> #include <asm/system_info.h>
> #include <asm/traps.h>
> +#include <asm/io.h>
>
> #include <asm/mach/arch.h>
> #include <asm/mach/map.h>
> @@ -1246,4 +1248,10 @@ void __init paging_init(struct machine_desc *mdesc)
>
> empty_zero_page = virt_to_page(zero_page);
> __flush_dcache_page(NULL, empty_zero_page);
> +
> + platform_bus_type.ioremap = ioremap;
> + platform_bus_type.ioremap_nocache = ioremap_nocache;
> + platform_bus_type.ioremap_cached = ioremap_cached;
> + platform_bus_type.ioremap_wc = ioremap_wc;
> + platform_bus_type.iounmap = iounmap;
> }
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 43dcda9..48c35e2 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -71,6 +71,26 @@ extern void bus_remove_file(struct bus_type *, struct bus_attribute *);
> * @shutdown: Called at shut-down time to quiesce the device.
> * @suspend: Called when a device on this bus wants to go to sleep mode.
> * @resume: Called to bring a device on this bus out of sleep mode.
> + * @ioremap: Function pointer returning a virtual address used to
> + * interact with a device on this bus. Generally
> + * implemented via @ioremap_nocache.
> + * @ioremap_nocache: Function pointer returning a virtual address used to
> + * interact with a device on this bus. Reads and writes
> + * to the returned address space are not cached by the
> + * CPU, so are suitable for memory-mapped I/O regions.
> + * @ioremap_cached: Function pointer returning a virtual address used to
> + * interact with private memory located on this bus. Reads and
> + * writes to the returned address space may be cached by the
> + * CPU, so this is suitable for I/O-mapped memory where all
> + * accesses are via the same cache.
> + * @ioremap_wc: Function pointer returning a virtual address used to
> + * interact with memory located on this bus. Writes to
> + * the returned address space may be combined by the CPU,
> + * so this is suitable for I/O-mapped memory such as
> + * framebuffers.
> + * @iounmap: Function pointer called to indicate that a caller is done
> + * with the virtual address mapping returned by @ioremap,
> + * @ioremap_nocache, @ioremap_cached, or @ioremap_wc.
> * @pm: Power management operations of this bus, callback the specific
> * device driver's pm-ops.
> * @iommu_ops: IOMMU specific operations for this bus, used to attach IOMMU
> @@ -105,6 +125,12 @@ struct bus_type {
> int (*suspend)(struct device *dev, pm_message_t state);
> int (*resume)(struct device *dev);
>
> + void __iomem *(*ioremap)(unsigned long phys_addr, size_t size);
> + void __iomem *(*ioremap_nocache)(unsigned long phys_addr, size_t size);
> + void __iomem *(*ioremap_cached)(unsigned long phys_addr, size_t size);
> + void __iomem *(*ioremap_wc)(unsigned long phys_addr, size_t size);
> + void (*iounmap)(volatile void __iomem *va);
> +
> const struct dev_pm_ops *pm;
>
> struct iommu_ops *iommu_ops;
> --
> 1.7.10.4
>
next prev parent reply other threads:[~2013-02-14 22:47 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-14 11:15 [RFC/NOT FOR MERGING 1/3] arm: omap: use generic implementation if !od Felipe Balbi
2013-02-14 11:20 ` Russell King - ARM Linux
2013-02-14 17:57 ` Felipe Balbi
2013-02-15 15:28 ` Kevin Hilman
2013-02-15 16:04 ` Felipe Balbi
[not found] ` <1360840554-26901-2-git-send-email-balbi@ti.com>
2013-02-14 17:12 ` [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency Tony Lindgren
2013-02-14 17:56 ` Felipe Balbi
2013-02-14 18:12 ` Tony Lindgren
2013-02-14 19:27 ` Felipe Balbi
2013-02-14 19:39 ` Tony Lindgren
2013-02-14 20:47 ` Paul Walmsley
2013-02-14 21:40 ` Paul Walmsley
2013-02-14 22:47 ` Tony Lindgren [this message]
2013-02-15 6:46 ` Felipe Balbi
2013-02-15 7:29 ` Santosh Shilimkar
2013-02-19 15:30 ` Paul Walmsley
2013-02-19 15:45 ` Russell King - ARM Linux
2013-02-19 16:30 ` Tony Lindgren
2013-02-19 18:22 ` Russell King - ARM Linux
2013-02-19 19:31 ` Tony Lindgren
2013-02-19 19:43 ` hwmod data duplication (was: Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency) Felipe Balbi
2013-02-19 22:09 ` Tony Lindgren
2013-02-19 22:22 ` Felipe Balbi
2013-02-19 22:31 ` Tony Lindgren
2013-02-19 22:51 ` Felipe Balbi
2013-02-15 10:26 ` [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency Russell King - ARM Linux
2013-02-14 21:56 ` Paul Walmsley
2013-02-14 22:22 ` Tony Lindgren
2013-02-15 6:53 ` Felipe Balbi
2013-02-15 7:27 ` Bedia, Vaibhav
2013-02-19 15:27 ` Paul Walmsley
2013-02-19 16:38 ` Tony Lindgren
2013-02-19 16:57 ` Felipe Balbi
2013-02-19 17:43 ` Tony Lindgren
2013-02-19 18:34 ` Felipe Balbi
2013-02-19 19:16 ` Kevin Hilman
2013-02-19 19:32 ` Felipe Balbi
2013-02-19 19:50 ` Kevin Hilman
2013-02-19 20:10 ` OMAP reset requirements (was: Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency)^[:x Felipe Balbi
2013-02-19 20:25 ` OMAP reset requirements Kevin Hilman
2013-02-20 6:26 ` [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency Santosh Shilimkar
2013-02-15 6:44 ` Felipe Balbi
2013-02-15 7:27 ` Bedia, Vaibhav
2013-02-20 17:38 ` Paul Walmsley
2013-02-20 19:16 ` Felipe Balbi
2013-02-20 20:03 ` Paul Walmsley
2013-02-20 20:37 ` Russell King - ARM Linux
2013-02-21 10:16 ` Peter De Schrijver
2013-02-21 12:09 ` Peter Korsgaard
2013-02-15 10:16 ` Russell King - ARM Linux
2013-02-15 13:26 ` Santosh Shilimkar
2013-02-15 13:27 ` Russell King - ARM Linux
2013-02-15 13:31 ` Santosh Shilimkar
2013-02-15 16:30 ` Tony Lindgren
2013-02-15 16:42 ` Felipe Balbi
2013-02-16 6:01 ` Santosh Shilimkar
2013-02-16 8:55 ` Felipe Balbi
2013-02-16 9:17 ` Santosh Shilimkar
2013-02-16 9:22 ` Felipe Balbi
2013-02-16 9:31 ` Santosh Shilimkar
2013-02-18 15:27 ` Kevin Hilman
2013-02-16 5:31 ` Santosh Shilimkar
2013-02-16 5:36 ` Nicolas Pitre
2013-02-16 5:48 ` Santosh Shilimkar
2013-02-18 8:08 ` Bedia, Vaibhav
2013-02-18 8:28 ` Santosh Shilimkar
2013-02-15 15:40 ` Kevin Hilman
2013-02-15 16:03 ` Felipe Balbi
2013-02-16 4:59 ` Santosh Shilimkar
2013-02-18 14:52 ` Kevin Hilman
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=20130214224710.GF11362@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.infradead.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).