26 Oct, 2016

2 commits


11 Aug, 2016

1 commit


28 Jun, 2016

2 commits

  • The reset value for this register seems broken on certain versions of
    tps65218 chip, so make sure the dcdc3 settings is proper. Needed for
    proper functionality of rtc+ddr / rtc-only modes.

    Signed-off-by: Tero Kristo
    Signed-off-by: Dave Gerlach
    Signed-off-by: Keerthy
    Signed-off-by: Mark Brown

    Tero Kristo
     
  • TPS65218 has a pre-defined power-up / power-down sequence which in
    a typical application does not need to be changed. However, it is possible
    to define custom sequences under I2C control. The power-up sequence is
    defined by strobes and delay times. Each output rail is assigned to a
    strobe to determine the order in which the rails are enabled.

    Every regulator has sequence registers and every regulator has a default
    strobe value and gets disabled when a particular power down sequence
    occurs.

    To keep a regulator on during suspend we write value 0 to strobe so
    that the regulator is out of all sequencers and is not impacted by any
    power down sequence. Hence saving the default strobe value during probe
    so that when we want to regulator to be enabled during suspend we write 0
    to strobe and when we want it to get disabled during suspend we write
    the default saved strobe value.
    This allows platform data to specify which power rails should be on or off
    during RTC only suspend. This is necessary to keep DDR state while in RTC
    only suspend.

    Signed-off-by: Tero Kristo
    Signed-off-by: Keerthy
    Signed-off-by: Mark Brown

    Tero Kristo
     

25 Nov, 2015

1 commit


17 Sep, 2015

1 commit


15 Dec, 2014

1 commit

  • Pull driver core update from Greg KH:
    "Here's the set of driver core patches for 3.19-rc1.

    They are dominated by the removal of the .owner field in platform
    drivers. They touch a lot of files, but they are "simple" changes,
    just removing a line in a structure.

    Other than that, a few minor driver core and debugfs changes. There
    are some ath9k patches coming in through this tree that have been
    acked by the wireless maintainers as they relied on the debugfs
    changes.

    Everything has been in linux-next for a while"

    * tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (324 commits)
    Revert "ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries"
    fs: debugfs: add forward declaration for struct device type
    firmware class: Deletion of an unnecessary check before the function call "vunmap"
    firmware loader: fix hung task warning dump
    devcoredump: provide a one-way disable function
    device: Add dev__once variants
    ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries
    ath: use seq_file api for ath9k debugfs files
    debugfs: add helper function to create device related seq_file
    drivers/base: cacheinfo: remove noisy error boot message
    Revert "core: platform: add warning if driver has no owner"
    drivers: base: support cpu cache information interface to userspace via sysfs
    drivers: base: add cpu_device_create to support per-cpu devices
    topology: replace custom attribute macros with standard DEVICE_ATTR*
    cpumask: factor out show_cpumap into separate helper function
    driver core: Fix unbalanced device reference in drivers_probe
    driver core: fix race with userland in device_add()
    sysfs/kernfs: make read requests on pre-alloc files use the buffer.
    sysfs/kernfs: allow attributes to request write buffer be pre-allocated.
    fs: sysfs: return EGBIG on write if offset is larger than file size
    ...

    Linus Torvalds
     

27 Nov, 2014

1 commit

  • The of_get_regulator_init_data() function is used to extract the regulator
    init_data but information on how to extract certain data is defined in the
    static regulator descriptor (e.g: how to map the hardware operating modes).

    Add a const struct regulator_desc * parameter to the function signature so
    the parsing logic could use the information in the struct regulator_desc.

    of_get_regulator_init_data() relies on of_get_regulation_constraints() to
    actually extract the init_data so it has to pass the struct regulator_desc
    but that is modified on a later patch.

    Signed-off-by: Javier Martinez Canillas
    Signed-off-by: Mark Brown

    Javier Martinez Canillas
     

20 Oct, 2014

1 commit


10 Jul, 2014

1 commit


09 Jul, 2014

4 commits


24 Jun, 2014

3 commits


27 May, 2014

1 commit


19 Feb, 2014

3 commits


15 Feb, 2014

1 commit