aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* Run pci_apply_final_quirks() sooner.David Woodhouse2009-10-12
| | | | | | | | | | | | | | | | | Having this as a device_initcall() means that some real device drivers can actually initialise _before_ the quirks are run, which is wrong. We want it to run _before_ device_initcall(), but _after_ fs_initcall(), since some arch-specific PCI initialisation like pcibios_assign_resources() is done at fs_initcall(). We could use rootfs_initcall() but I actually want to use that for the IOMMU initialisation, which has to come after the quirks, but still before the real devices. So use fs_initcall_sync() instead -- since this is entirely synchronous, it doesn't hurt that it'll escape the synchronisation. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
* Mark pci_apply_final_quirks() __init rather than __devinitDavid Woodhouse2009-10-12
| | | | | | It doesn't get invoked on hotplug; it can be thrown away after init. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
* Rename pci_init() to pci_apply_final_quirks(), move it to quirks.cDavid Woodhouse2009-10-12
| | | | | | | | This function may have done more in the past, but all it does now is apply the PCI_FIXUP_FINAL quirks. So name it sensibly and put it where it belongs. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
* intel-iommu: Yet another BIOS workaround: Isoch DMAR unit with no TLB spaceDavid Woodhouse2009-09-30
| | | | | | | | | Asus decided to ship a BIOS which configures sound DMA to go via the dedicated IOMMU unit, but assigns precisely zero TLB entries to that unit. Which causes the whole thing to deadlock, including the DMA traffic on the _other_ IOMMU units. Nice one. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
* intel-iommu: Decode (and ignore) RHSA entriesRoland Dreier2009-09-24
| | | | | | | | | | I recently got a system where the DMAR table included a couple of RHSA (remapping hardware static affinity) entries. Rather than printing a message about an "Unknown DMAR structure," it would probably be more useful to dump the RHSA structure (as other DMAR structures are dumped). Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
* intel-iommu: Make "Unknown DMAR structure" message more informativeRoland Dreier2009-09-23
| | | | | | | | | | We might as well print the type of the DMAR structure we don't know how to handle when skipping it. Then someone getting this message has a chance of telling whether the structure is just bogus, or if there really is something valid that the kernel doesn't know how to handle. Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
* Merge git://git.infradead.org/iommu-2.6Linus Torvalds2009-09-23
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * git://git.infradead.org/iommu-2.6: (23 commits) intel-iommu: Disable PMRs after we enable translation, not before intel-iommu: Kill DMAR_BROKEN_GFX_WA option. intel-iommu: Fix integer wrap on 32 bit kernels intel-iommu: Fix integer overflow in dma_pte_{clear_range,free_pagetable}() intel-iommu: Limit DOMAIN_MAX_PFN to fit in an 'unsigned long' intel-iommu: Fix kernel hang if interrupt remapping disabled in BIOS intel-iommu: Disallow interrupt remapping if not all ioapics covered intel-iommu: include linux/dmi.h to use dmi_ routines pci/dmar: correct off-by-one error in dmar_fault() intel-iommu: Cope with yet another BIOS screwup causing crashes intel-iommu: iommu init error path bug fixes intel-iommu: Mark functions with __init USB: Work around BIOS bugs by quiescing USB controllers earlier ia64: IOMMU passthrough mode shouldn't trigger swiotlb init intel-iommu: make domain_add_dev_info() call domain_context_mapping() intel-iommu: Unify hardware and software passthrough support intel-iommu: Cope with broken HP DC7900 BIOS iommu=pt is a valid early param intel-iommu: double kfree() intel-iommu: Kill pointless intel_unmap_single() function ... Fixed up trivial include lines conflict in drivers/pci/intel-iommu.c
| * intel-iommu: Disable PMRs after we enable translation, not beforeDavid Woodhouse2009-09-19
| | | | | | | | Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * intel-iommu: Kill DMAR_BROKEN_GFX_WA option.David Woodhouse2009-09-19
| | | | | | | | | | | | | | | | | | Just make it depend on BROKEN for now, in case people scream really loud about it (and because we might want to keep some of this logic for an upcoming BIOS workaround, so I don't just want to rip it out entirely just yet). But for graphics devices, it really ought to be unnecessary. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * intel-iommu: Fix integer wrap on 32 bit kernelsBenjamin LaHaise2009-09-19
| | | | | | | | | | | | | | | | | | | | The following 64 bit promotions are necessary to handle memory above the 4GiB boundary correctly. [dwmw2: Fix the second part not to need 64-bit arithmetic at all] Signed-off-by: Benjamin LaHaise <ben.lahaise@neterion.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * intel-iommu: Fix integer overflow in dma_pte_{clear_range,free_pagetable}()David Woodhouse2009-09-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If end_pfn is equal to (unsigned long)-1, then the loop will never end. Seen on 32-bit kernel, but could have happened on 64-bit too once we get hardware that supports 64-bit guest addresses. Change both functions to a 'do {} while' loop with the test at the end, and check for the PFN having wrapper round to zero. Reported-by: Benjamin LaHaise <ben.lahaise@neterion.com> Tested-by: Benjamin LaHaise <ben.lahaise@neterion.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * intel-iommu: Limit DOMAIN_MAX_PFN to fit in an 'unsigned long'David Woodhouse2009-09-19
| | | | | | | | | | | | | | | | | | | | | | This means we're limited to 44-bit addresses on 32-bit kernels, and makes it sane for us to use 'unsigned long' for PFNs throughout. Which is just as well, really, since we already do that. Reported-by: Benjamin LaHaise <ben.lahaise@neterion.com> Tested-by: Benjamin LaHaise <ben.lahaise@neterion.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * intel-iommu: Fix kernel hang if interrupt remapping disabled in BIOSYouquan Song2009-09-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BIOS clear DMAR table INTR_REMAP flag to disable interrupt remapping. Current kernel only check interrupt remapping(IR) flag in DRHD's extended capability register to decide interrupt remapping support or not. But IR flag will not change when BIOS disable/enable interrupt remapping. When user disable interrupt remapping in BIOS or BIOS often defaultly disable interrupt remapping feature when BIOS is not mature.Though BIOS disable interrupt remapping but intr_remapping_supported function will always report to OS support interrupt remapping if VT-d2 chipset populated. On this cases, kernel will continue enable interrupt remapping and result kernel panic. This bug exist on almost all platforms with interrupt remapping support. This patch add DMAR table INTR_REMAP flag check before enable interrupt remapping. Signed-off-by: Youquan Song <youquan.song@intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * intel-iommu: Disallow interrupt remapping if not all ioapics coveredYouquan Song2009-09-11
| | | | | | | | | | | | | | | | | | | | | | Current kernel enable interrupt remapping only when all the vt-d unit support interrupt remapping. So it is reasonable we should also disallow enabling intr-remapping if there any io-apics that are not listed under vt-d units. Otherwise we can run into issues. Acked-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Youquan Song <youquan.song@intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * intel-iommu: include linux/dmi.h to use dmi_ routinesStephen Rothwell2009-08-31
| | | | | | | | | | | | | | | | This file needs to include linux/dmi.h directly rather than relying on it being pulled in from elsewhere. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * pci/dmar: correct off-by-one error in dmar_fault()Troy Heber2009-08-30
| | | | | | | | | | | | | | | | | | | | | | DMAR faults are recorded into a ring of "fault recording registers". fault_index is a 0-based index into the ring. The code allows the 0-based fault_index to be equal to the total number of fault registers available from the cap_num_fault_regs() macro, which causes access beyond the last available register. Signed-off-by Troy Heber <troy.heber@hp.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * intel-iommu: Cope with yet another BIOS screwup causing crashesDavid Woodhouse2009-08-26
| | | | | | | | Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * intel-iommu: iommu init error path bug fixesDonald Dutile2009-08-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kcalloc() failure path in iommu_init_domains() calls free_dmar_iommu(), which assumes that ->domains, ->domain_ids, and ->lock have been properly initialized. Add checks in free_[dmar]_iommu to not use ->domains,->domain_ids if not alloced. Move the lock init to prior to the kcalloc()'s, so it is valid in free_context_table() when free_dmar_iommu() invokes it at the end. Patch based on iommu-2.6, commit 132032274a594ee9ffb6b9c9e2e9698149a09ea9 Signed-off-by: Donald Dutile <ddutile@redhat.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * intel-iommu: Mark functions with __initMatt Kraai2009-08-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mark si_domain_init and iommu_prepare_static_identity_mapping with __init, to eliminate the following warnings: WARNING: drivers/pci/built-in.o(.text+0xf1f4): Section mismatch in reference from the function si_domain_init() to the function .init.text:si_domain_work_fn() The function si_domain_init() references the function __init si_domain_work_fn(). This is often because si_domain_init lacks a __init annotation or the annotation of si_domain_work_fn is wrong. WARNING: drivers/pci/built-in.o(.text+0xe340): Section mismatch in reference from the function iommu_prepare_static_identity_mapping() to the function .init.text:si_domain_init() The function iommu_prepare_static_identity_mapping() references the function __init si_domain_init(). This is often because iommu_prepare_static_identity_mapping lacks a __init annotation or the annotation of si_domain_init is wrong. Signed-off-by: Matt Kraai <kraai@ftbfs.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * USB: Work around BIOS bugs by quiescing USB controllers earlierDavid Woodhouse2009-08-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are seeing a number of crashes in SMM, when VT-d is enabled while 'Legacy USB support' is enabled in various BIOSes. The BIOS is supposed to indicate which addresses it uses for DMA in a special ACPI table ("RMRR"), so that we can punch a hole for it when we set up the IOMMU. The problem is, as usual, that BIOS engineers are totally incompetent. They write code which will crash if the DMA goes AWOL, and then they either neglect to provide an RMRR table at all, or they put the wrong addresses in it. And of course they don't do _any_ QA, since that would take too much time away from their crack-smoking habit. The real fix, of course, is for consumers to refuse to buy motherboards which only have closed-source firmware available. If we had _open_ firmware, bugs like this would be easy to fix. Since that's something I can only dream about, this patch implements an alternative -- ensuring that the USB controllers are handed off from the BIOS and quiesced _before_ the IOMMU is initialised. That would have been a much better design than this RMRR nonsense in the first place, of course. The bootloader has no business doing DMA after the OS has booted anyway. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * ia64: IOMMU passthrough mode shouldn't trigger swiotlb initDavid Woodhouse2009-08-13
| | | | | | | | | | | | | | | | | | | | Since commit 19943b0e30b05d42e494ae6fef78156ebc8c637e ('intel-iommu: Unify hardware and software passthrough support'), hardware passthrough mode will do the same as software passthrough mode was doing -- it'll still use the IOMMU normally for devices which can't address all of memory. This means that we don't need to bother with swiotlb. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * intel-iommu: make domain_add_dev_info() call domain_context_mapping()David Woodhouse2009-08-09
| | | | | | | | | | | | | | | | All callers of the former were also calling the latter, in one order or the other, and failing to correctly clean up if the second returned failure. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * Merge branch 'master' of /pub/scm/linux/kernel/git/torvalds/linux-2.6David Woodhouse2009-08-08
| |\ | | | | | | | | | | | | Pull fixes in from 2.6.31 so that people testing the iommu-2.6.git tree no longer trip over bugs which were already fixed (sorry, Horms).
| * | intel-iommu: Unify hardware and software passthrough supportDavid Woodhouse2009-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes the hardware passthrough mode work a lot more like the software version, so that the behaviour of a kernel with 'iommu=pt' is the same whether the hardware supports passthrough or not. In particular: - We use a single si_domain for the pass-through devices. - 32-bit devices can be taken out of the pass-through domain so that they don't have to use swiotlb. - Devices will work again after being removed from a KVM guest. - A potential oops on OOM (in init_context_pass_through()) is fixed. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | intel-iommu: Cope with broken HP DC7900 BIOSDavid Woodhouse2009-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Yet another reason why trusting this stuff to the BIOS was a bad idea. The HP DC7900 BIOS reports an iommu at an address which just returns all ones, when VT-d is disabled in the BIOS. Fix up the missing iounmap in the error paths while we're at it. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | iommu=pt is a valid early paramAlex Williamson2009-08-03
| | | | | | | | | | | | | | | | | | | | | | | | This avoids a "Malformed early option 'iommu'" warning on boot when trying to use pass-through mode. Signed-off-by: Alex Williamson <alex.williamson@hp.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | intel-iommu: double kfree()Dan Carpenter2009-07-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | g_iommus is freed after we "goto error;". Found by smatch (http://repo.or.cz/w/smatch.git). Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | intel-iommu: Kill pointless intel_unmap_single() functionDavid Woodhouse2009-07-15
| | | | | | | | | | | | Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | intel-iommu: Defer the iotlb flush and iova free for intel_unmap_sg() too.David Woodhouse2009-07-15
| | | | | | | | | | | | | | | | | | I see no reason why we did this _only_ in intel_unmap_page(). Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | intel-iommu: Remove superfluous iova_alloc_lock from IOVA codeDavid Woodhouse2009-07-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | We only ever obtain this lock immediately before the iova_rbtree_lock, and release it immediately after the iova_rbtree_lock. So ditch it and just use iova_rbtree_lock. [v2: Remove the lockdep bits this time too] Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | intel-iommu: Speed up map routines by using cached domain ASAPDavid Woodhouse2009-07-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We did before, in the end -- but it was at the bottom of a long stack of functions. Add an inline wrapper get_valid_domain_for_dev() which will use the cached one _first_ and only make the out-of-line call if it's not already set. This takes the average time taken for a 1-page intel_map_sg() from 5961 cycles to 4812 cycles on my Lenovo x200s test box -- a modest 20%. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
* | | misc: remove redundant start_kernel prototypesRusty Russell2009-09-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Impact: cleanup No need for redeclaration. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | Merge branch 'for-linus' of ↵Linus Torvalds2009-09-23
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6: (41 commits) regulator: Add some brief design documentation regulator: fix voltage range in da9034 ldo12 regulator/driver: be more specific in nanodoc for is_enabled regulator/lp3971: drop unnecessary initialization regulator: drop 'default n' regulator: fix typos regulator: fix calculation of voltage range in da9034_set_ldo12_voltage() regulator: update a filename in documentation drivers/regulator/Kconfig: fix typo (s/Usersapce/Userspace/) in REGULATOR_USERSPACE_CONSUMER description REGULATOR Handle positive returncode from enable regulator: tps650xx - build fixes for x86_64 Fix some regulator documentation Regulator: Adding TPS65023 and TPS6507x in Kconfig and Makefile Regulator: Add TPS6507x regulator driver Regulator: Add TPS65023 regulator driver regulator: userspace: use sysfs_create_group regulator: Add GPIO enable control to fixed voltage regulator driver Regulator: Implement list_voltage for pcf50633 regulator driver. regulator: regulator_enable() permission checking regulator: Push locking for regulator_is_enabled() out ...
| * | | regulator: Add some brief design documentationMark Brown2009-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provide some brief documentation of some of the design decisions that are made by the regulator API. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | regulator: fix voltage range in da9034 ldo12Haojian Zhuang2009-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | regulator/driver: be more specific in nanodoc for is_enabledWolfram Sang2009-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Document the possibility that is_enabled may also return with negative errorcodes. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | regulator/lp3971: drop unnecessary initializationWolfram Sang2009-09-22
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | regulator: drop 'default n'Wolfram Sang2009-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Specifying 'default n' is superfluous. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | regulator: fix typosWolfram Sang2009-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a couple of typos I found while working with this subsystem. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | regulator: fix calculation of voltage range in da9034_set_ldo12_voltage()Roel Kluin2009-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For val to be greater than 7 or less than 20 is logically always true. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | regulator: update a filename in documentationWolfram Sang2009-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | drivers/regulator/Kconfig: fix typo (s/Usersapce/Userspace/) in ↵Michael Prokop2009-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | REGULATOR_USERSPACE_CONSUMER description Signed-off-by: Michael Prokop <mika@grml.org> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | REGULATOR Handle positive returncode from enableLinus Walleij2009-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes _regulator_enable() properly handle the case where a regulator is already on when you try to enable it. Currently it will erroneously handle positive return values as an error. Signed-off-by: Linus Walleij <linus.walleij@stericsson.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | regulator: tps650xx - build fixes for x86_64Liam Girdwood2009-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes the following errors on both tps650xx regulator drivers :- drivers/regulator/tps65023-regulator: struct i2c_device_id is 32 bytes. The last of 1 is: 0x74 0x70 0x73 0x36 0x35 0x30 0x32 0x33 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 FATAL: drivers/regulator/tps65023-regulator: struct i2c_device_id is not terminated with a NULL entry! This patch also fixes the GPL v2 licence string for both drivers. Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | Fix some regulator documentationLinus Walleij2009-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a spelling error and an API function signature mismatch in the regulator documentation. Signed-off-by: Linus Walleij <linus.walleij@stericsson.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | Regulator: Adding TPS65023 and TPS6507x in Kconfig and MakefileAnuj Aggarwal2009-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adding TPS65023 and TPS6507x regulator driver support in drivers/regulator/Makefile and drivers/regulator/Kconfig Signed-off-by: Anuj Aggarwal <anuj.aggarwal@ti.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | Regulator: Add TPS6507x regulator driverAnuj Aggarwal2009-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adding support for TI TPS6507x regulator driver Signed-off-by: Anuj Aggarwal <anuj.aggarwal@ti.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | Regulator: Add TPS65023 regulator driverAnuj Aggarwal2009-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adding support for TI TPS65023 regulator driver Signed-off-by: Anuj Aggarwal <anuj.aggarwal@ti.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | regulator: userspace: use sysfs_create_groupFelipe Balbi2009-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and avoid introducing our own loops for creating several sysfs entries. Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Mike Rapoport <mike@compulab.co.il> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | regulator: Add GPIO enable control to fixed voltage regulator driverRoger Quadros2009-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now fixed regulators that have their enable pin connected to a GPIO line can use the fixed regulator driver for regulator enable/disable control. The GPIO number and polarity information is passed through platform data. GPIO enable control is achieved using gpiolib. Signed-off-by: Roger Quadros <ext-roger.quadros@nokia.com> Reviewed-by: Philipp Zabel <philipp.zabel@gmail.com> Reviewed-by: Felipe Balbi <felipe.balbi@nokia.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
generated by cgit v1.2.2 (git 2.25.0) at 2025-01-24 21:39:00 -0500