1. 17 4月, 2012 1 次提交
  2. 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
  3. 04 4月, 2012 1 次提交
  4. 21 2月, 2012 1 次提交
  5. 17 2月, 2012 1 次提交
  6. 24 11月, 2011 2 次提交
    • 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
  7. 01 11月, 2011 1 次提交
  8. 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
  9. 10 6月, 2011 1 次提交
  10. 26 3月, 2011 1 次提交
  11. 12 1月, 2011 5 次提交
  12. 03 3月, 2010 1 次提交
    • M
      regulator: Allow regulators to specify the time taken to ramp on enable · 31aae2be
      Mark Brown 提交于
      Regulators may sometimes take longer to enable than the control operation
      used to do so, either because the regulator has ramp rate control used to
      limit inrush current or because the control operation is very fast (GPIO
      being the most common example of this).  In order to ensure that consumers
      do not rely on the regulator before it is enabled provide an enable_time()
      operation and have the core delay for that time before returning to the
      caller.
      
      This is implemented as a function since the ramp rate may be specified in
      voltage per unit time and therefore the time depend on the configuration.
      In future it would be desirable to allow the bulk operations to run the
      delays for multiple enables in parallel but this is not currently supported.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      31aae2be
  13. 22 9月, 2009 2 次提交
  14. 17 9月, 2009 1 次提交
  15. 29 4月, 2009 1 次提交
  16. 31 3月, 2009 7 次提交
  17. 09 1月, 2009 2 次提交
  18. 14 10月, 2008 2 次提交
    • M
      regulator: Fix typo · 3de89609
      Mark Brown 提交于
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>
      3de89609
    • L
      regulator: core - Rework machine API to remove string based functions. · a5766f11
      Liam Girdwood 提交于
      This improves the machine level API in order to configure
      regulator constraints and consumers as platform data and removes the
      old string based API that required several calls to set up each regulator.
      
      The intention is to create a struct regulator_init_data, populate
      it's fields with constraints, consumers devices, etc and then register
      the regulator device from board.c in the standard Linux way.
      
      e.g. regulator LDO2 (supplying codec and sim) platform data.
      
      /* regulator LDO2 consumer devices */
      static struct regulator_consumer_supply ldo2_consumers[] = {
      {
      	.dev	= &platform_audio_device.dev,
      	.supply	= "codec_avdd",
      },
      {
      	.dev	= &platform_sim_device.dev,
      	.supply	= "sim_vcc",
      }
      };
      
      /* regulator LDO2 constraints  */
      static struct regulator_init_data ldo2_data = {
      	.constraints = {
      		.min_uV = 3300000,
      		.max_uV = 3300000,
      		.valid_modes_mask = REGULATOR_MODE_NORMAL,
      		.apply_uV = 1,
      	},
      	.num_consumer_supplies = ARRAY_SIZE(ldo2_consumers),
      	.consumer_supplies = ldo2_consumers,
      };
      
      /* machine regulator devices with thier consumers and constraints */
      static struct platform_device wm8350_regulator_devices[] = {
      {
      	.name = "wm8350-regulator",
      	.id = WM8350_LDO_2,
      	.dev = {
      		.platform_data = &ldo2_data,
      	},
      },
      };
      
      Changes in detail:-
      
        o Removed all const char* regulator config functions in machine API.
        o Created new struct regulator_init_data to contain regulator
          machine configuration constraints and consmuers.
        o Changed set_supply(), set_machine_constraints(),
          set_consumer_device_supply() to remove their string identifier
          parameters. Also made them static and moved functions nearer top of
          core.c.
        o Removed no longer used inline func to_rdev()
        o Added regulator_get_init_drvdata() to retrieve init data.
        o Added struct device* as parameter to regulator_register().
        o Changed my email address.
      Signed-off-by: NEric Miao <eric.miao@marvell.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>
      a5766f11
  19. 30 7月, 2008 1 次提交