cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

machine.rst (3085B)

      1==================================
      2Regulator Machine Driver Interface
      3==================================
      4
      5The regulator machine driver interface is intended for board/machine specific
      6initialisation code to configure the regulator subsystem.
      7
      8Consider the following machine::
      9
     10  Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
     11               |
     12               +-> [Consumer B @ 3.3V]
     13
     14The drivers for consumers A & B must be mapped to the correct regulator in
     15order to control their power supplies. This mapping can be achieved in machine
     16initialisation code by creating a struct regulator_consumer_supply for
     17each regulator::
     18
     19  struct regulator_consumer_supply {
     20	const char *dev_name;	/* consumer dev_name() */
     21	const char *supply;	/* consumer supply - e.g. "vcc" */
     22  };
     23
     24e.g. for the machine above::
     25
     26  static struct regulator_consumer_supply regulator1_consumers[] = {
     27	REGULATOR_SUPPLY("Vcc", "consumer B"),
     28  };
     29
     30  static struct regulator_consumer_supply regulator2_consumers[] = {
     31	REGULATOR_SUPPLY("Vcc", "consumer A"),
     32  };
     33
     34This maps Regulator-1 to the 'Vcc' supply for Consumer B and maps Regulator-2
     35to the 'Vcc' supply for Consumer A.
     36
     37Constraints can now be registered by defining a struct regulator_init_data
     38for each regulator power domain. This structure also maps the consumers
     39to their supply regulators::
     40
     41  static struct regulator_init_data regulator1_data = {
     42	.constraints = {
     43		.name = "Regulator-1",
     44		.min_uV = 3300000,
     45		.max_uV = 3300000,
     46		.valid_modes_mask = REGULATOR_MODE_NORMAL,
     47	},
     48	.num_consumer_supplies = ARRAY_SIZE(regulator1_consumers),
     49	.consumer_supplies = regulator1_consumers,
     50  };
     51
     52The name field should be set to something that is usefully descriptive
     53for the board for configuration of supplies for other regulators and
     54for use in logging and other diagnostic output.  Normally the name
     55used for the supply rail in the schematic is a good choice.  If no
     56name is provided then the subsystem will choose one.
     57
     58Regulator-1 supplies power to Regulator-2. This relationship must be registered
     59with the core so that Regulator-1 is also enabled when Consumer A enables its
     60supply (Regulator-2). The supply regulator is set by the supply_regulator
     61field below and co::
     62
     63  static struct regulator_init_data regulator2_data = {
     64	.supply_regulator = "Regulator-1",
     65	.constraints = {
     66		.min_uV = 1800000,
     67		.max_uV = 2000000,
     68		.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
     69		.valid_modes_mask = REGULATOR_MODE_NORMAL,
     70	},
     71	.num_consumer_supplies = ARRAY_SIZE(regulator2_consumers),
     72	.consumer_supplies = regulator2_consumers,
     73  };
     74
     75Finally the regulator devices must be registered in the usual manner::
     76
     77  static struct platform_device regulator_devices[] = {
     78	{
     79		.name = "regulator",
     80		.id = DCDC_1,
     81		.dev = {
     82			.platform_data = &regulator1_data,
     83		},
     84	},
     85	{
     86		.name = "regulator",
     87		.id = DCDC_2,
     88		.dev = {
     89			.platform_data = &regulator2_data,
     90		},
     91	},
     92  };
     93  /* register regulator 1 device */
     94  platform_device_register(&regulator_devices[0]);
     95
     96  /* register regulator 2 device */
     97  platform_device_register(&regulator_devices[1]);