1. 15 5月, 2012 1 次提交
  2. 13 5月, 2012 1 次提交
  3. 12 5月, 2012 2 次提交
  4. 04 5月, 2012 1 次提交
  5. 17 4月, 2012 3 次提交
  6. 09 4月, 2012 1 次提交
    • M
      regulator: core: Use a struct to pass in regulator runtime configuration · c172708d
      Mark Brown 提交于
      Rather than adding new arguments to regulator_register() every time we
      want to add a new bit of dynamic information at runtime change the function
      to take these via a struct. By doing this we avoid needing to do further
      changes like the recent addition of device tree support which required each
      regulator driver to be updated to take an additional parameter.
      
      The regulator_desc which should (mostly) be static data is still passed
      separately as most drivers are able to configure this statically at build
      time.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      c172708d
  7. 04 4月, 2012 1 次提交
  8. 03 4月, 2012 1 次提交
  9. 01 4月, 2012 1 次提交
  10. 29 3月, 2012 1 次提交
  11. 16 3月, 2012 1 次提交
    • P
      device.h: audit and cleanup users in main include dir · 313162d0
      Paul Gortmaker 提交于
      The <linux/device.h> header includes a lot of stuff, and
      it in turn gets a lot of use just for the basic "struct device"
      which appears so often.
      
      Clean up the users as follows:
      
      1) For those headers only needing "struct device" as a pointer
      in fcn args, replace the include with exactly that.
      
      2) For headers not really using anything from device.h, simply
      delete the include altogether.
      
      3) For headers relying on getting device.h implicitly before
      being included themselves, now explicitly include device.h
      
      4) For files in which doing #1 or #2 uncovers an implicit
      dependency on some other header, fix by explicitly adding
      the required header(s).
      
      Any C files that were implicitly relying on device.h to be
      present have already been dealt with in advance.
      
      Total removals from #1 and #2: 51.  Total additions coming
      from #3: 9.  Total other implicit dependencies from #4: 7.
      
      As of 3.3-rc1, there were 110, so a net removal of 42 gives
      about a 38% reduction in device.h presence in include/*
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      313162d0
  12. 07 3月, 2012 2 次提交
  13. 04 3月, 2012 1 次提交
  14. 21 2月, 2012 1 次提交
  15. 17 2月, 2012 1 次提交
  16. 02 2月, 2012 1 次提交
  17. 30 1月, 2012 1 次提交
  18. 27 1月, 2012 1 次提交
  19. 23 1月, 2012 2 次提交
  20. 20 1月, 2012 2 次提交
  21. 04 1月, 2012 1 次提交
  22. 02 1月, 2012 1 次提交
  23. 06 12月, 2011 1 次提交
    • S
      regulator: pass device_node to of_get_regulator_init_data() · d9a861cc
      Shawn Guo 提交于
      It's not always true that the device_node of regulator can be found
      at dev->of_node at the time when of_get_regulator_init_data() is being
      called, because in some cases the regulator nodes in device tree do
      not have 'struct device' behind them until regulator_dev gets created
      for it by core function regulator_register().
      
      The patch adds device_node as a new parameter to
      of_get_regulator_init_data(), so that caller can pass in the node of
      regulator directly.
      Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: Liam Girdwood <lrg@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      d9a861cc
  24. 24 11月, 2011 3 次提交
    • R
      regulator: map consumer regulator based on device tree · 69511a45
      Rajendra Nayak 提交于
      Device nodes in DT can associate themselves with one or more
      regulators/supply by providing a list of phandles (to regulator nodes)
      and corresponding supply names.
      
      For Example:
      	devicenode: node@0x0 {
      		...
      		...
      		vmmc-supply = <&regulator1>;
      		vpll-supply = <&regulator2>;
      	};
      
      The driver would then do a regulator_get(dev, "vmmc"); to get
      regulator1 and do a regulator_get(dev, "vpll"); to get
      regulator2.
      
      of_get_regulator() extracts the regulator node for a given
      device, based on the supply name.
      
      Use it to look up the regulator for a given consumer from device tree, during
      a regulator_get(). If not found fallback and lookup through
      the regulator_map_list instead.
      
      Also, since the regulator dt nodes can use the same binding to
      associate with a parent regulator/supply, allow the drivers to
      specify a supply_name, which can then be used to lookup dt
      to find the parent phandle.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Acked-by: NGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      69511a45
    • R
      regulator: pass additional of_node to regulator_register() · 2c043bcb
      Rajendra Nayak 提交于
      With device tree support for regulators, its needed that the
      regulator_dev->dev device has the right of_node attached.
      To be able to do this add an additional parameter to the
      regulator_register() api, wherein the dt-adapted driver can
      then pass this additional info onto the regulator core.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      2c043bcb
    • R
      regulator: helper routine to extract regulator_init_data · 8f446e6f
      Rajendra Nayak 提交于
      The helper routine is meant to be used by the regulator drivers
      to extract the regulator_init_data structure from the data
      that is passed from device tree.
      'consumer_supplies' which is part of regulator_init_data is not extracted
      as the regulator consumer mappings are passed through DT differently,
      implemented in subsequent patches.
      Similarly the regulator<-->parent/supply mapping is handled in
      subsequent patches.
      
      Also add documentation for regulator bindings to be used to pass
      regulator_init_data struct information from device tree.
      
      Some of the regulator properties which are linux and board specific,
      are left out since its not clear if they can
      be in someway embedded into the kernel or passed in from DT.
      They will be revisited later.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      8f446e6f
  25. 01 11月, 2011 1 次提交
  26. 15 10月, 2011 1 次提交
  27. 09 10月, 2011 1 次提交
    • H
      regulator: Add driver for gpio-controlled regulators · 3f0292ae
      Heiko Stübner 提交于
      This patch adds support for regulators that can be controlled via gpios.
      
      Examples for such regulators are the TI-tps65024x voltage regulators
      with 4 fixed and 1 runtime-switchable voltage regulators
      or the TI-bq240XX charger regulators.
      
      The number of controlling gpios is not limited, the mapping between
      voltage/current and target gpio state is done via the states map
      and the driver can be used for either voltage or current regulators.
      
      A mapping for a regulator with two GPIOs could look like:
      
      gpios = {
      	{ .gpio = GPIO1, .flags = GPIOF_OUT_INIT_HIGH, .label = "gpio name 1" },
      	{ .gpio = GPIO2, .flags = GPIOF_OUT_INIT_LOW,  .label = "gpio name 2" },
      }
      
      The flags element of the gpios array determines the initial state of
      the gpio, set during probe. The initial state of the regulator is also
      calculated from these values
      
      states = {
      	{ .value = volt_or_cur1, .gpios = (0 << 1) | (0 << 0) },
      	{ .value = volt_or_cur2, .gpios = (0 << 1) | (1 << 0) },
      	{ .value = volt_or_cur3, .gpios = (1 << 1) | (0 << 0) },
      	{ .value = volt_or_cur4, .gpios = (1 << 1) | (1 << 0) },
      }
      
      The target-state for the n-th gpio is determined by the n-th bit
      in the bitfield of the target-value.
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      3f0292ae
  28. 14 9月, 2011 1 次提交
    • M
      regulator: Implement deferred disable support · da07ecd9
      Mark Brown 提交于
      It is a reasonably common pattern for hardware to require some delay after
      being quiesced before the disable has finalised, especially in mixed signal
      devices. For example, an active discharge may be required to ensure that
      the circuit starts up again in a known state. Avoid having to implement
      such delays in the regulator API by providing regulator_deferred_disable()
      which will do a regulator_disable() a specified number of milliseconds
      after it is called.
      
      Due to the reference counting done on regulators a deferred disable can
      be cancelled by doing another regulator_enable().
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@ti.com>
      da07ecd9
  29. 09 9月, 2011 1 次提交
  30. 09 8月, 2011 1 次提交
  31. 10 6月, 2011 1 次提交
  32. 30 5月, 2011 1 次提交
    • M
      regulator: Do bulk enables of regulators in parallel · f21e0e81
      Mark Brown 提交于
      In order to reduce the impact of ramp times rather than enabling the
      regulators for a device in series use async tasks to run the actual
      enables. This means that the delays which the enables implement can all
      run in parallel, though it does mean that the order in which the
      supplies come on may be unstable.
      
      For super bonus fun points if any of the regulators are shared between
      multiple supplies on the same device (as is rather likely) then this
      will test our locking.  Note that in this case we only delay once for
      each physical regulator so the threads shouldn't block each other while
      delaying.
      
      It'd be even nicer if we could coalesce writes to a shared enable registers
      in PMICs but that's definitely future work, and it may also be useful
      and is certainly more achievable to optimise out the parallelism if none
      of the regulators implement ramp delays.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>
      f21e0e81