26 Oct, 2015

1 commit


06 Jan, 2014

1 commit

  • As of commit 03e361b25ee8dfb1fd9b890072c23c4aae01c6c7 ("mfd: Stop setting
    refcounting pointers in original mfd_cell arrays"), the "cell" parameter of
    mfd_add_devices() is "const" again. Hence make all cell data passed to
    mfd_add_devices() const where possible.

    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Lee Jones

    Geert Uytterhoeven
     

31 Jul, 2013

1 commit


14 Sep, 2012

1 commit

  • Currently the MFD core supports remapping MFD cell interrupts using an
    irqdomain but only if the MFD is being instantiated using device tree
    and only if the device tree bindings use the pattern of registering IPs
    in the device tree with compatible properties. This will be actively
    harmful for drivers which support non-DT platforms and use this pattern
    for their DT bindings as it will mean that the core will silently change
    remapping behaviour and it is also limiting for drivers which don't do
    DT with this particular pattern. There is also a potential fragility if
    there are interrupts not associated with MFD cells and all the cells are
    omitted from the device tree for some reason.

    Instead change the code to take an IRQ domain as an optional argument,
    allowing drivers to take the decision about the parent domain for their
    interrupts. The one current user of this feature is ab8500-core, it has
    the domain lookup pushed out into the driver.

    Signed-off-by: Mark Brown
    Signed-off-by: Samuel Ortiz

    Mark Brown
     

11 Sep, 2012

1 commit

  • This was originally written by Russell King who unfortunately found
    himself unable to take the patch futher.

    Signed-off-by: Mark Brown
    Acked-by: Arnd Bergmann
    Acked-by: Haojian Zhuang
    Tested-by: Haojian Zhuang
    Signed-off-by: Samuel Ortiz

    Mark Brown
     

20 May, 2012

1 commit

  • The modern idiom is to use irq_domain to allocate interrupts. This is
    useful partly to allow further infrastructure to be based on the domains
    and partly because it makes it much easier to allocate virtual interrupts
    to devices as we don't need to allocate a contiguous range of interrupt
    numbers.

    Convert the wm831x driver over to this infrastructure, using a legacy
    IRQ mapping if an irq_base is specified in platform data and otherwise
    using a linear mapping, always registering the interrupts even if they
    won't ever be used. Only boards which need to use the GPIOs as
    interrupts should need to use an irq_base.

    This means that we can't use the MFD irq_base management since the
    unless we're using an explicit irq_base from platform data we can't rely
    on a linear mapping of interrupts. Instead we need to map things via
    the irq_domain - provide a conveniencem function wm831x_irq() to save a
    small amount of typing when doing so. Looking at this I couldn't clearly
    see anything the MFD core could do to make this nicer.

    Since we're not supporting device tree yet there's no meaningful
    advantage if we don't do this conversion in one, the fact that the
    interrupt resources are used for repeated IP blocks makes accessor
    functions for the irq_domain more trouble to do than they're worth.

    Signed-off-by: Mark Brown
    Signed-off-by: Samuel Ortiz

    Mark Brown
     

07 May, 2012

1 commit

  • The removal of mach/io.h from most ARM platforms also set the range of
    valid IO ports to be empty for most platforms when previously any 32
    bit integer had been valid. This makes it impossible to add IO resources
    as the added range is smaller than that of the root resource for IO ports.

    Since we're not really using IO memory at all fix this by defining our
    own root resource outside the normal tree and make that the parent of
    all IO resources. This also ensures we won't conflict with read IO ports
    if we ever run on a platform which happens to use them.

    Signed-off-by: Mark Brown
    Signed-off-by: Samuel Ortiz

    Mark Brown
     

22 Feb, 2012

1 commit


09 Jan, 2012

2 commits


18 Oct, 2011

1 commit

  • Most useful with the regulators where we're doing a lot of read/modify/write
    updates in potentially performance critical paths. Providing some defaults
    would make this slightly better but this is a win right now.

    Signed-off-by: Mark Brown
    Acked-by: Samuel Ortiz

    Mark Brown
     

20 Sep, 2011

1 commit

  • In systems where there is no hardware signal from the processor to the
    PMIC to initiate the final power off sequence we must initiate the
    shutdown with a register write to the PMIC. Support such systems in the
    driver. Since this may prevent a full shutdown of the system platform
    data is used to enable the feature.

    Signed-off-by: Mark Brown
    Signed-off-by: Samuel Ortiz

    Mark Brown
     

22 Aug, 2011

2 commits


01 Aug, 2011

7 commits


27 May, 2011

1 commit

  • Allow the GPIO mode of WM831x devices to be configured using platform data.
    Users may provide a table of GPIO register values in gpio_defaults[]. In
    order to allow 0 to be set explicitly out of range values are accepted and
    masked off, with a WM831X_GPIO_CONFIGURE define provided to set an out of
    range value.

    This can be used to configure higher numbered GPIOs or override values set
    in OTP for GPIOs configured using OTP.

    Signed-off-by: Mark Brown
    Signed-off-by: Samuel Ortiz

    Mark Brown
     

14 Jan, 2011

2 commits


22 Dec, 2010

2 commits


29 Oct, 2010

2 commits

  • In preparation for the addition of SPI support for the WM831x move the I2C
    specific code into a separate file with a separate Kconfig option so the
    I2C support can be excluded from the build.

    Also update the 1133-EV1 PMIC module support for SMDK6410 to use the new
    symbol.

    Signed-off-by: Mark Brown
    Signed-off-by: Samuel Ortiz

    Mark Brown
     
  • The WM8325 is a PMIC for low power, high performance applications. From
    a software point of view the device is identical to the WM8320, all the
    differences are at the hardware level.

    Signed-off-by: Mark Brown
    Signed-off-by: Samuel Ortiz

    Mark Brown
     

12 Aug, 2010

2 commits


28 May, 2010

2 commits

  • The charger interrupts on the WM831x are unconditionally a wake source
    for the system. If the power driver is not able to monitor them (for
    example, due to the IRQ line not having been wired up on the system)
    then any charger interrupt will prevent the system suspending for any
    meaningful amount of time since nothing will ack them.

    Avoid this issue by manually acknowledging these interrupts when we
    suspend the WM831x core device if they are masked. If software is
    actually using the interrupts then they will be unmasked and this
    change will have no effect.

    Signed-off-by: Mark Brown
    Signed-off-by: Samuel Ortiz

    Mark Brown
     
  • Currently completion of WM831x AUXADC conversions is monitored by
    checking for convertor enable. Due to the mechanism used to ensure
    data corruption is avoided when reading AUXADC data there may under
    heavy I/O be a window where this bit has cleared but the conversion
    results have not been updated. Data availability is only guaranteed
    after the AUXADC data interrupt has been asserted.

    Avoid this by always using the interrupt to detect completion. If the
    chip IRQ is not set up then we poll the IRQ status register for up to
    5ms. If it is set up then we rely on the data done interrupt with a
    vastly increased timeout, failing the conversion if the interrupt is
    not generated.

    This also saves a register read when using interrupts.

    Signed-off-by: Mark Brown
    Signed-off-by: Samuel Ortiz

    Mark Brown
     

13 May, 2010

1 commit

  • In certain circumstances, especially under heavy load, the AUXADC
    completion interrupt may be detected after we've timed out waiting for
    it. That conversion would still succeed but the next conversion will
    see the completion that was signalled by the interrupt for the previous
    conversion and therefore not wait for the AUXADC conversion to run,
    causing it to report failure.

    Provide a simple, non-invasive cleanup by using try_wait_for_completion()
    to ensure that the completion is not signalled before we wait. Since
    the AUXADC is run within a mutex we know there can only have been at
    most one AUXADC interrupt outstanding. A more involved change should
    follow for the next merge window.

    Signed-off-by: Mark Brown
    Signed-off-by: Samuel Ortiz

    Mark Brown
     

30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

08 Mar, 2010

2 commits

  • Use the completion interrupt generated by the device rather than
    polling for conversions to complete. As a backup we still check
    the status of the AUXADC if we don't get a completion, mostly for
    systems that don't have the WM831x interrupt infrastructure hooked
    up.

    Also reduce the timeout for completion of conversions to 5ms from
    the previous 10ms, the lower timeout should be sufficient.

    Signed-off-by: Mark Brown
    Signed-off-by: Samuel Ortiz

    Mark Brown
     
  • Revision B of the WM831x devices changes the sense of the tristate
    bit for GPIO configuration, inverting it to become an enable instead.
    Take account of this in the gpiolib driver.

    A current sink regulation status bit has also been added in revision B,
    add a flag indicating if it's present but don't use it yet.

    This revision also adds an interrupt on key up for the ON pin event
    which the existing code is able to take advantage of.

    Signed-off-by: Mark Brown
    Signed-off-by: Samuel Ortiz

    Mark Brown
     

16 Dec, 2009

1 commit

  • * git://git.infradead.org/battery-2.6:
    power_supply_sysfs: Handle -ENODATA in a special way
    wm831x_backup: Remove unused variables
    gta02: Set pcf50633 charger_reference_current_ma
    pcf50633: Query charger status directly
    pcf50633: Properly reenable charging when the supply conditions change
    pcf50633: Get rid of charging restart software auto-triggering
    pcf50633: introduces battery charging current control
    pcf50633: Add ac power supply class to the charger
    wm831x: Factor out WM831x backup battery charger

    Linus Torvalds
     

14 Dec, 2009

3 commits

  • Replace the wm831x-local IRQ infrastructure with genirq, allowing access
    to the diagnostic infrastructure of genirq and allowing us to implement
    interrupt support for the GPIOs. The switchover is done within the
    wm831x specific IRQ API, further patches will convert the individual
    drivers to use genirq directly.

    Signed-off-by: Mark Brown
    Signed-off-by: Samuel Ortiz

    Mark Brown
     
  • The WM8320 is an integrated power management subsystem providing
    voltage regulators, RTC, watchdog and other functionality. The
    WM8320 is derived from the WM831x and therefore shares most of
    the driver code with the WM831x.

    Signed-off-by: Mark Brown
    Signed-off-by: Samuel Ortiz

    Mark Brown
     
  • This supports future devices with fewer GPIOs.

    Signed-off-by: Mark Brown
    Signed-off-by: Samuel Ortiz

    Mark Brown