| Message ID | alpine.DEB.2.00.1302142124370.11016@utopia.booyaka.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Feb 14, 2013 at 02:47:10PM -0800, Tony Lindgren wrote: > * 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? I'm not sure we should even try that. I mean, eventually (maybe in 100 years) we wouldn't mach-* at all and even struct map_desc would be dynamically initialized by data passed in via DTB, right ? Just consider Arnd's patch for the "machine_desc-less" DT boot. If we add a function pointer to struct map_desc, it will just become yet another function pointer to be removed later.
+ Tero, Rajendra, Kevin On Friday 15 February 2013 12:16 PM, Felipe Balbi wrote: > On Thu, Feb 14, 2013 at 02:47:10PM -0800, Tony Lindgren wrote: >> * 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? > > I'm not sure we should even try that. I mean, eventually (maybe in 100 > years) we wouldn't mach-* at all and even struct map_desc would be > dynamically initialized by data passed in via DTB, right ? Just consider > Arnd's patch for the "machine_desc-less" DT boot. If we add a function > pointer to struct map_desc, it will just become yet another function > pointer to be removed later. > On the same thread, it was also mentioned that, "machine_desc-less" DT boot is for simple machines. I have looked that aspect bit more. Considering the amount of callbacks OMAP uses, it is not practical. Ofcourse am also not in favor of adding another function pointer stuff here. We should get rid of dual ioremap() and the method suggested by Paul seems to be reasonable. Sysconfig handling is very tightly coupled with PRCM. I agree with Paul that hardware should have mapped it in separate address space. So whichever framework manages the PRCM, should also manage sysconfig. Refer all the issues around sysconfig for IP's like USB, UART and they are directly PRCM issues. We should be able to work around the IP integration issues around problematic IPs like UART, USB with some profile knowledge which can be handled by runtime PM transparently. It should have been done that way in first place instead of functions pointers which today break the Device Tree builds directly. As I mentioned in OMAP5 data series, we are now able to remove the IO_resource information ( Address space, IRQ data, DMA lines) from from hwmod data and extract it from device Tree. Thats a good point. Next one is getting rid off sysconfig function pointers which drivers are using and handle those issues using runtime_pm APIs. Idea is, IP gives profile like... e.g McSPI1 -> Smart Idle always UART -> no_idle(runtime_get) and smart_idle(runtime_put) mUSB --> no_idle(runtime_get) and force_idle(runtime_put) Then the last one is custom reset function for broken IPs. For this one as well if we can add a hook in runtime framework, then it can be handled without direct function calls. Regards, Santosh Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Feb 14, 2013 at 09:40:29PM +0000, Paul Walmsley wrote: > 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. Not only does this break the "ioremap caller" stuff, allowing the caller of ioremap() to be recorded, I believe this to be a total abonimation. > This might also be useful as a generic replacement for pci_ioremap_bar(). No it isn't. Read the comments about why pci_ioremap_bar() was introduced in its original commit. It's there to reduce the number of common errors with mapping a PCI bar, so it takes the PCI device and the BAR index. It has a totally different interface to standard ioremap(). It can't be twisted into the standard ioremap() interface in any shape or form. > 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> How many more bloody times do I have to tell people about using asm/io.h directly? You've been around for _long_ enough that you well know this by now. There is no excuse for this kind of thing other than shere laziness or down-right sloppyness on your part. If I make a big enough thing about it, hopefully people will become scared to post their un-self-reviewed patches and instead start taking a little more care in future. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Thu, 14 Feb 2013, Tony Lindgren wrote: > 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? That sounds fine to me too. To me it makes sense to eventually handle the I/O mappings automatically from data in the DT -- hence the association with a bus device, which should be present in DT data. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 19, 2013 at 03:30:01PM +0000, Paul Walmsley wrote: > Hi, > > On Thu, 14 Feb 2013, Tony Lindgren wrote: > > > 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? > > That sounds fine to me too. > > To me it makes sense to eventually handle the I/O mappings automatically > from data in the DT -- hence the association with a bus device, which > should be present in DT data. No. I really don't get why OMAP thinks it's soo special that it needs to go around adding lots and lots of new abstractions all over the place. Indirect ioremap() through a function pointer so you can overload it with OMAP specific crap? No way. Function pointers in map_desc - what the hell for? You must be totally mad if you think that's a way forward, I really don't see how you think this kind of crap would be remotely acceptable. Ok, so you have this problem that you need hwmod to touch a register which is also contained within the device resources as well. That's fine. You can do it one of two ways: 1. Call out from the driver at the appropriate points (which seems to be _after_ you've ioremapped it) to access the register. 2. Find the resource, temporarily map the register, access it, and then unmap it. No requirement what so ever to override ioremap(). AT ALL. So stop this madness now. As for a function pointer in struct map_desc. You're bonkers, the lot of you. map_desc is a structure describing the boot time static mappings which gets discarded. Nothing keeps any references around to it, and it is used at a time when *NOTHING ELSE* should be going on in the kernel other than building those static mappings. Not even any arch code poking about at devices. Or anything like that. Because if you think that's acceptable, then we'll need to flush the cache and TLB after each and every map_desc entry is touched - which brings a whole load of new pain and slowness to the kernel boot. So please, stop this idiotic madness now. If you want such things as pci_enable_device(), then what you're actually asking for is omap_enable_device() for OMAP devices. OMAP devices are already specific enough to OMAP SoCs (god knows, they have really complex and obscure behaviours that no one else in their right mind would want to copy) that calling out to omap specific functions would never really be a problem. No need for any of this crazy dev->bus shit either. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Russell King - ARM Linux <linux@arm.linux.org.uk> [130219 07:49]: > On Tue, Feb 19, 2013 at 03:30:01PM +0000, Paul Walmsley wrote: > > Hi, > > > > On Thu, 14 Feb 2013, Tony Lindgren wrote: > > > > > 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? > > > > That sounds fine to me too. > > > > To me it makes sense to eventually handle the I/O mappings automatically > > from data in the DT -- hence the association with a bus device, which > > should be present in DT data. > > No. I really don't get why OMAP thinks it's soo special that it needs > to go around adding lots and lots of new abstractions all over the > place. Hey it's actually quite the opposite. We're trying to find a generic way of doing things in order to avoid omap specific driver hacks. > Indirect ioremap() through a function pointer so you can overload it with > OMAP specific crap? No way. Function pointers in map_desc - what the hell > for? > > You must be totally mad if you think that's a way forward, I really don't > see how you think this kind of crap would be remotely acceptable. > > Ok, so you have this problem that you need hwmod to touch a register which > is also contained within the device resources as well. That's fine. You > can do it one of two ways: > > 1. Call out from the driver at the appropriate points (which seems to be > _after_ you've ioremapped it) to access the register. > > 2. Find the resource, temporarily map the register, access it, and then > unmap it. > > No requirement what so ever to override ioremap(). AT ALL. So stop this > madness now. > > As for a function pointer in struct map_desc. You're bonkers, the lot of > you. map_desc is a structure describing the boot time static mappings > which gets discarded. Nothing keeps any references around to it, and it > is used at a time when *NOTHING ELSE* should be going on in the kernel > other than building those static mappings. Not even any arch code poking > about at devices. Or anything like that. Because if you think that's > acceptable, then we'll need to flush the cache and TLB after each and > every map_desc entry is touched - which brings a whole load of new pain > and slowness to the kernel boot. > > So please, stop this idiotic madness now. OK good point. Also it would be risky for things going wrong trying to try set up more complex stuff that early as then debugging it again depends on DEBUG_LL. > If you want such things as pci_enable_device(), then what you're actually > asking for is omap_enable_device() for OMAP devices. OMAP devices are > already specific enough to OMAP SoCs (god knows, they have really complex > and obscure behaviours that no one else in their right mind would want > to copy) that calling out to omap specific functions would never really > be a problem. I'd rather avoid adding omap_enable_device() calls to drivers as we really want to keep the drivers generic. But maybe there could be some generic bus_enable_device() function pointer that could be populated by the bus code during init. > No need for any of this crazy dev->bus shit either. Paul's suggestion on configuring things with pm_runtime_get() seems doable and is generic. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 19, 2013 at 08:30:53AM -0800, Tony Lindgren wrote: > * Russell King - ARM Linux <linux@arm.linux.org.uk> [130219 07:49]: > > If you want such things as pci_enable_device(), then what you're actually > > asking for is omap_enable_device() for OMAP devices. OMAP devices are > > already specific enough to OMAP SoCs (god knows, they have really complex > > and obscure behaviours that no one else in their right mind would want > > to copy) that calling out to omap specific functions would never really > > be a problem. > > I'd rather avoid adding omap_enable_device() calls to drivers as we really > want to keep the drivers generic. But maybe there could be some generic > bus_enable_device() function pointer that could be populated by the bus > code during init. What you're not getting is that pci_enable_device() is a PCI thing which is mostly a no-op - and where it isn't a no-op, it's something that must be done _before_ PCI resources are used or even reserved (because conceptually, this is to do with getting the resources correct.) The PCI case is: pci_device_probe(pci_dev) { pci_enable_device(pci_dev); pci_request_regions(pci_dev); regs = pci_iomap(pci_dev, BAR, size); ... } That's different from what you're wanting on OMAP - what you're wanting there is some way to record the platform device has been ioremapped, so that you can then fiddle with its idle/reset register from "bus" code. If you think about it in light of the above sequence, the "enable device" stage *doesn't* suit your needs because that happens before the driver has done anything. However... if you think you're going to get away with another total rewrite of OMAP device support away from hwmod to a new scheme with a new load of huge churn, think again. Remember, churn is evil. I've complained to you about the amount of churn that OMAP manufactures in the past. Linus has complained about it too. You can't continue like this. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Russell King - ARM Linux <linux@arm.linux.org.uk> [130219 10:26]: > On Tue, Feb 19, 2013 at 08:30:53AM -0800, Tony Lindgren wrote: > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [130219 07:49]: > > > If you want such things as pci_enable_device(), then what you're actually > > > asking for is omap_enable_device() for OMAP devices. OMAP devices are > > > already specific enough to OMAP SoCs (god knows, they have really complex > > > and obscure behaviours that no one else in their right mind would want > > > to copy) that calling out to omap specific functions would never really > > > be a problem. > > > > I'd rather avoid adding omap_enable_device() calls to drivers as we really > > want to keep the drivers generic. But maybe there could be some generic > > bus_enable_device() function pointer that could be populated by the bus > > code during init. > > What you're not getting is that pci_enable_device() is a PCI thing which > is mostly a no-op - and where it isn't a no-op, it's something that must > be done _before_ PCI resources are used or even reserved (because > conceptually, this is to do with getting the resources correct.) > > The PCI case is: > > pci_device_probe(pci_dev) > { > pci_enable_device(pci_dev); > > pci_request_regions(pci_dev); > > regs = pci_iomap(pci_dev, BAR, size); > ... > } > > That's different from what you're wanting on OMAP - what you're wanting > there is some way to record the platform device has been ioremapped, so > that you can then fiddle with its idle/reset register from "bus" code. > > If you think about it in light of the above sequence, the "enable device" > stage *doesn't* suit your needs because that happens before the driver > has done anything. Right.. that won't help then. It sounds like the proper place would be something like pm_runtime_init() as these register manage things like autoidle etc. > However... if you think you're going to get away with another total > rewrite of OMAP device support away from hwmod to a new scheme with a > new load of huge churn, think again. Remember, churn is evil. I've > complained to you about the amount of churn that OMAP manufactures > in the past. Linus has complained about it too. You can't continue > like this. I don't think there's any churn needed here if done properly. It's mostly a question of dropping duplicate data from hwmod that we already have available in device tree. That means we can shrink the hwmod data needed. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Tue, Feb 19, 2013 at 11:31:22AM -0800, Tony Lindgren wrote: > > However... if you think you're going to get away with another total > > rewrite of OMAP device support away from hwmod to a new scheme with a > > new load of huge churn, think again. Remember, churn is evil. I've > > complained to you about the amount of churn that OMAP manufactures > > in the past. Linus has complained about it too. You can't continue > > like this. > > I don't think there's any churn needed here if done properly. It's > mostly a question of dropping duplicate data from hwmod that we > already have available in device tree. That means we can shrink the > hwmod data needed. how about starting by removing register addresses and interrupt numbers which are passed by devicetree today ? If you want to move to DT-only now even without all drivers DT-adapted, you can have something like what Marvel folks did for kirkwood: static void __init kirkwood_dt_init(void) { [ ... ] if (of_machine_is_compatible("globalscale,dreamplug")) dreamplug_init(); if (of_machine_is_compatible("dlink,dns-kirkwood")) dnskw_init(); if (of_machine_is_compatible("iom,iconnect")) iconnect_init(); [ ... ] of_platform_populate(NULL, kirkwood_dt_match_table, NULL, NULL); } those machine-based inits are there just to initialize drivers which aren't converted to DT. this would let you remove all board-files except board-generic.c and remove data which is already passed in via DT. It has the benefit of showing Linus (or whoever cares) that we are working to remove the "churn" while also removing some of the pressure of DT conversion, since there are still details which need to be sorted out (UART function pointers, clock nodes via DT - see Roger's discussion with Rajendra, DMA nodes, etc etc). Only on board-files we're talking about over 13K lines: arch/arm/mach-omap2/board-2430sdp.c | 289 ------ arch/arm/mach-omap2/board-3430sdp.c | 602 ------------ arch/arm/mach-omap2/board-3630sdp.c | 216 ----- arch/arm/mach-omap2/board-4430sdp.c | 730 --------------- arch/arm/mach-omap2/board-am3517crane.c | 97 -- arch/arm/mach-omap2/board-am3517evm.c | 398 -------- arch/arm/mach-omap2/board-apollon.c | 342 ------- arch/arm/mach-omap2/board-cm-t35.c | 769 ---------------- arch/arm/mach-omap2/board-cm-t3517.c | 302 ------ arch/arm/mach-omap2/board-devkit8000.c | 648 ------------- arch/arm/mach-omap2/board-flash.c | 242 ----- arch/arm/mach-omap2/board-flash.h | 62 -- arch/arm/mach-omap2/board-h4.c | 347 ------- arch/arm/mach-omap2/board-igep0020.c | 673 -------------- arch/arm/mach-omap2/board-ldp.c | 440 --------- arch/arm/mach-omap2/board-n8x0.c | 762 --------------- arch/arm/mach-omap2/board-omap3beagle.c | 549 ----------- arch/arm/mach-omap2/board-omap3evm.c | 762 --------------- arch/arm/mach-omap2/board-omap3logic.c | 249 ----- arch/arm/mach-omap2/board-omap3pandora.c | 623 ------------- arch/arm/mach-omap2/board-omap3stalker.c | 432 --------- arch/arm/mach-omap2/board-omap3touchbook.c | 391 -------- arch/arm/mach-omap2/board-omap4panda.c | 467 ---------- arch/arm/mach-omap2/board-overo.c | 556 ----------- arch/arm/mach-omap2/board-rm680.c | 165 ---- arch/arm/mach-omap2/board-rx51-peripherals.c | 1276 -------------------------- arch/arm/mach-omap2/board-rx51-video.c | 89 -- arch/arm/mach-omap2/board-rx51.c | 128 --- arch/arm/mach-omap2/board-rx51.h | 11 - arch/arm/mach-omap2/board-ti8168evm.c | 62 -- arch/arm/mach-omap2/board-zoom-debugboard.c | 139 --- arch/arm/mach-omap2/board-zoom-display.c | 147 --- arch/arm/mach-omap2/board-zoom-peripherals.c | 304 ------ arch/arm/mach-omap2/board-zoom.c | 155 ---- arch/arm/mach-omap2/board-zoom.h | 10 - 35 files changed, 13434 deletions(-) If we remove all addresses and interrupts, numbers look even better.
* Felipe Balbi <balbi@ti.com> [130219 11:47]: > Hi, > > On Tue, Feb 19, 2013 at 11:31:22AM -0800, Tony Lindgren wrote: > > > However... if you think you're going to get away with another total > > > rewrite of OMAP device support away from hwmod to a new scheme with a > > > new load of huge churn, think again. Remember, churn is evil. I've > > > complained to you about the amount of churn that OMAP manufactures > > > in the past. Linus has complained about it too. You can't continue > > > like this. > > > > I don't think there's any churn needed here if done properly. It's > > mostly a question of dropping duplicate data from hwmod that we > > already have available in device tree. That means we can shrink the > > hwmod data needed. > > how about starting by removing register addresses and interrupt numbers > which are passed by devicetree today ? If you want to move to DT-only > now even without all drivers DT-adapted, you can have something like > what Marvel folks did for kirkwood: > > static void __init kirkwood_dt_init(void) > { > > [ ... ] > > if (of_machine_is_compatible("globalscale,dreamplug")) > dreamplug_init(); > > if (of_machine_is_compatible("dlink,dns-kirkwood")) > dnskw_init(); > > if (of_machine_is_compatible("iom,iconnect")) > iconnect_init(); > > [ ... ] > > of_platform_populate(NULL, kirkwood_dt_match_table, NULL, NULL); > } > > those machine-based inits are there just to initialize drivers which > aren't converted to DT. Yes we could do that at least partially, but.. > this would let you remove all board-files except board-generic.c and > remove data which is already passed in via DT. It has the benefit of > showing Linus (or whoever cares) that we are working to remove the > "churn" while also removing some of the pressure of DT conversion, since > there are still details which need to be sorted out (UART function > pointers, clock nodes via DT - see Roger's discussion with Rajendra, DMA > nodes, etc etc). ..that means massive amount of churn in the board-*.c files to convert them to various init functions to be called from board-generic.c and removing the ones that are working with DT. I think we're better off making first sure things are usable with DT, then just dropping the board-*.c files as we go. And omap4 is the place to start as we only have blaze and panda board files. Once DSS, USB and WLAN work with the .dts files, we can just drop those board files and make omap4 DT only. We may be able to drop omap4 board-*.c files faster than going full DT with few selected legacy init functions in board-generic.c for things like LCD panel configuration etc. > Only on board-files we're talking about over 13K lines: > > arch/arm/mach-omap2/board-2430sdp.c | 289 ------ > arch/arm/mach-omap2/board-3430sdp.c | 602 ------------ > arch/arm/mach-omap2/board-3630sdp.c | 216 ----- > arch/arm/mach-omap2/board-4430sdp.c | 730 --------------- > arch/arm/mach-omap2/board-am3517crane.c | 97 -- > arch/arm/mach-omap2/board-am3517evm.c | 398 -------- > arch/arm/mach-omap2/board-apollon.c | 342 ------- > arch/arm/mach-omap2/board-cm-t35.c | 769 ---------------- > arch/arm/mach-omap2/board-cm-t3517.c | 302 ------ > arch/arm/mach-omap2/board-devkit8000.c | 648 ------------- > arch/arm/mach-omap2/board-flash.c | 242 ----- > arch/arm/mach-omap2/board-flash.h | 62 -- > arch/arm/mach-omap2/board-h4.c | 347 ------- > arch/arm/mach-omap2/board-igep0020.c | 673 -------------- > arch/arm/mach-omap2/board-ldp.c | 440 --------- > arch/arm/mach-omap2/board-n8x0.c | 762 --------------- > arch/arm/mach-omap2/board-omap3beagle.c | 549 ----------- > arch/arm/mach-omap2/board-omap3evm.c | 762 --------------- > arch/arm/mach-omap2/board-omap3logic.c | 249 ----- > arch/arm/mach-omap2/board-omap3pandora.c | 623 ------------- > arch/arm/mach-omap2/board-omap3stalker.c | 432 --------- > arch/arm/mach-omap2/board-omap3touchbook.c | 391 -------- > arch/arm/mach-omap2/board-omap4panda.c | 467 ---------- > arch/arm/mach-omap2/board-overo.c | 556 ----------- > arch/arm/mach-omap2/board-rm680.c | 165 ---- > arch/arm/mach-omap2/board-rx51-peripherals.c | 1276 -------------------------- > arch/arm/mach-omap2/board-rx51-video.c | 89 -- > arch/arm/mach-omap2/board-rx51.c | 128 --- > arch/arm/mach-omap2/board-rx51.h | 11 - > arch/arm/mach-omap2/board-ti8168evm.c | 62 -- > arch/arm/mach-omap2/board-zoom-debugboard.c | 139 --- > arch/arm/mach-omap2/board-zoom-display.c | 147 --- > arch/arm/mach-omap2/board-zoom-peripherals.c | 304 ------ > arch/arm/mach-omap2/board-zoom.c | 155 ---- > arch/arm/mach-omap2/board-zoom.h | 10 - > 35 files changed, 13434 deletions(-) > > If we remove all addresses and interrupts, numbers look even better. Yeah. Let's start with omap4 first when DSS + USB + WLAN work. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Tue, Feb 19, 2013 at 02:09:33PM -0800, Tony Lindgren wrote: > > On Tue, Feb 19, 2013 at 11:31:22AM -0800, Tony Lindgren wrote: > > > > However... if you think you're going to get away with another total > > > > rewrite of OMAP device support away from hwmod to a new scheme with a > > > > new load of huge churn, think again. Remember, churn is evil. I've > > > > complained to you about the amount of churn that OMAP manufactures > > > > in the past. Linus has complained about it too. You can't continue > > > > like this. > > > > > > I don't think there's any churn needed here if done properly. It's > > > mostly a question of dropping duplicate data from hwmod that we > > > already have available in device tree. That means we can shrink the > > > hwmod data needed. > > > > how about starting by removing register addresses and interrupt numbers > > which are passed by devicetree today ? If you want to move to DT-only > > now even without all drivers DT-adapted, you can have something like > > what Marvel folks did for kirkwood: > > > > static void __init kirkwood_dt_init(void) > > { > > > > [ ... ] > > > > if (of_machine_is_compatible("globalscale,dreamplug")) > > dreamplug_init(); > > > > if (of_machine_is_compatible("dlink,dns-kirkwood")) > > dnskw_init(); > > > > if (of_machine_is_compatible("iom,iconnect")) > > iconnect_init(); > > > > [ ... ] > > > > of_platform_populate(NULL, kirkwood_dt_match_table, NULL, NULL); > > } > > > > those machine-based inits are there just to initialize drivers which > > aren't converted to DT. > > Yes we could do that at least partially, but.. > > > this would let you remove all board-files except board-generic.c and > > remove data which is already passed in via DT. It has the benefit of > > showing Linus (or whoever cares) that we are working to remove the > > "churn" while also removing some of the pressure of DT conversion, since > > there are still details which need to be sorted out (UART function > > pointers, clock nodes via DT - see Roger's discussion with Rajendra, DMA > > nodes, etc etc). > > ..that means massive amount of churn in the board-*.c files to convert > them to various init functions to be called from board-generic.c and > removing the ones that are working with DT. why ? I meant that only what's not converted to DT today should be handled this way. Also, most of the "churn" is already there (usb_musb_init(), usb_ehci_init(), etc etc), it just needs to be called from a different place. We don't need to have one function for each board, however, maybe we could target by-soc: if (of_is_compatible("omap3")) omap3_init_devices(); /* or whatever you wanna call it */ omap_init_devices() has initialization for everything which isn't DT adapted today and as we move things to DT, there's a single place to remove code from. > I think we're better off making first sure things are usable with > DT, then just dropping the board-*.c files as we go. > > And omap4 is the place to start as we only have blaze and panda > board files. Once DSS, USB and WLAN work with the .dts files, we > can just drop those board files and make omap4 DT only. fair enough. > We may be able to drop omap4 board-*.c files faster than going full > DT with few selected legacy init functions in board-generic.c for > things like LCD panel configuration etc. > > > Only on board-files we're talking about over 13K lines: > > > > arch/arm/mach-omap2/board-2430sdp.c | 289 ------ > > arch/arm/mach-omap2/board-3430sdp.c | 602 ------------ > > arch/arm/mach-omap2/board-3630sdp.c | 216 ----- > > arch/arm/mach-omap2/board-4430sdp.c | 730 --------------- > > arch/arm/mach-omap2/board-am3517crane.c | 97 -- > > arch/arm/mach-omap2/board-am3517evm.c | 398 -------- > > arch/arm/mach-omap2/board-apollon.c | 342 ------- > > arch/arm/mach-omap2/board-cm-t35.c | 769 ---------------- > > arch/arm/mach-omap2/board-cm-t3517.c | 302 ------ > > arch/arm/mach-omap2/board-devkit8000.c | 648 ------------- > > arch/arm/mach-omap2/board-flash.c | 242 ----- > > arch/arm/mach-omap2/board-flash.h | 62 -- > > arch/arm/mach-omap2/board-h4.c | 347 ------- > > arch/arm/mach-omap2/board-igep0020.c | 673 -------------- > > arch/arm/mach-omap2/board-ldp.c | 440 --------- > > arch/arm/mach-omap2/board-n8x0.c | 762 --------------- > > arch/arm/mach-omap2/board-omap3beagle.c | 549 ----------- > > arch/arm/mach-omap2/board-omap3evm.c | 762 --------------- > > arch/arm/mach-omap2/board-omap3logic.c | 249 ----- > > arch/arm/mach-omap2/board-omap3pandora.c | 623 ------------- > > arch/arm/mach-omap2/board-omap3stalker.c | 432 --------- > > arch/arm/mach-omap2/board-omap3touchbook.c | 391 -------- > > arch/arm/mach-omap2/board-omap4panda.c | 467 ---------- > > arch/arm/mach-omap2/board-overo.c | 556 ----------- > > arch/arm/mach-omap2/board-rm680.c | 165 ---- > > arch/arm/mach-omap2/board-rx51-peripherals.c | 1276 -------------------------- > > arch/arm/mach-omap2/board-rx51-video.c | 89 -- > > arch/arm/mach-omap2/board-rx51.c | 128 --- > > arch/arm/mach-omap2/board-rx51.h | 11 - > > arch/arm/mach-omap2/board-ti8168evm.c | 62 -- > > arch/arm/mach-omap2/board-zoom-debugboard.c | 139 --- > > arch/arm/mach-omap2/board-zoom-display.c | 147 --- > > arch/arm/mach-omap2/board-zoom-peripherals.c | 304 ------ > > arch/arm/mach-omap2/board-zoom.c | 155 ---- > > arch/arm/mach-omap2/board-zoom.h | 10 - > > 35 files changed, 13434 deletions(-) > > > > If we remove all addresses and interrupts, numbers look even better. > > Yeah. Let's start with omap4 first when DSS + USB + WLAN work. USB is going to be ready for v3.10, likely Wlan too.
* Felipe Balbi <balbi@ti.com> [130219 14:26]: > On Tue, Feb 19, 2013 at 02:09:33PM -0800, Tony Lindgren wrote: > > > > ..that means massive amount of churn in the board-*.c files to convert > > them to various init functions to be called from board-generic.c and > > removing the ones that are working with DT. > > why ? I meant that only what's not converted to DT today should be > handled this way. Also, most of the "churn" is already there > (usb_musb_init(), usb_ehci_init(), etc etc), it just needs to be called > from a different place. We don't need to have one function for each > board, however, maybe we could target by-soc: > > if (of_is_compatible("omap3")) > omap3_init_devices(); /* or whatever you wanna call it */ > > omap_init_devices() has initialization for everything which isn't DT > adapted today and as we move things to DT, there's a single place to > remove code from. And the pdata for that comes from where? :) I think that means converting each board-*.c to device init functions, which leads to the churn I was mentioning.. > > I think we're better off making first sure things are usable with > > DT, then just dropping the board-*.c files as we go. > > > > And omap4 is the place to start as we only have blaze and panda > > board files. Once DSS, USB and WLAN work with the .dts files, we > > can just drop those board files and make omap4 DT only. > > fair enough. > > > We may be able to drop omap4 board-*.c files faster than going full > > DT with few selected legacy init functions in board-generic.c for > > things like LCD panel configuration etc. > > > > > Only on board-files we're talking about over 13K lines: > > > 35 files changed, 13434 deletions(-) ... > > > If we remove all addresses and interrupts, numbers look even better. > > > > Yeah. Let's start with omap4 first when DSS + USB + WLAN work. > > USB is going to be ready for v3.10, likely Wlan too. That's good news. Maybe we can then have a legacy device pdata init for DSS, and make omap4 DT only for v3.10. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Tue, Feb 19, 2013 at 02:31:28PM -0800, Tony Lindgren wrote: > * Felipe Balbi <balbi@ti.com> [130219 14:26]: > > On Tue, Feb 19, 2013 at 02:09:33PM -0800, Tony Lindgren wrote: > > > > > > ..that means massive amount of churn in the board-*.c files to convert > > > them to various init functions to be called from board-generic.c and > > > removing the ones that are working with DT. > > > > why ? I meant that only what's not converted to DT today should be > > handled this way. Also, most of the "churn" is already there > > (usb_musb_init(), usb_ehci_init(), etc etc), it just needs to be called > > from a different place. We don't need to have one function for each > > board, however, maybe we could target by-soc: > > > > if (of_is_compatible("omap3")) > > omap3_init_devices(); /* or whatever you wanna call it */ > > > > omap_init_devices() has initialization for everything which isn't DT > > adapted today and as we move things to DT, there's a single place to > > remove code from. > > And the pdata for that comes from where? :) I think that means > converting each board-*.c to device init functions, which leads to > the churn I was mentioning.. fair enough, still a lot less churn ;-)
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) -#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;