Regulator consumer and i2c device interaction.

Regulator consumer and i2c device interaction.

[Jonathan Cameron]

Dear All,

Currently regulator consumers are registered and identified via a pointer to the relevant
device:

e.g. via a regulator consumer supply structure:
static struct regulator_consumer_supply imote2_sensor_3_con[] = {
	{
		.dev = &sht15.dev,
		.supply = "vcc",
	},
};

static struct regulator_init_data imote2_ldo_init_data[] = {{
	{
	 	.constraints = {
		.name = "vcc_sensor_3",
		.min_uV = 2800000,
		.max_uV = 3000000,
		.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
	},
	.num_consumer_supplies = ARRAY_SIZE(imote2_sensor_3_con),
	.consumer_supplies = imote2_sensor_3_con,
},
};

and relevant association with a regulator driver.

Now in the case of i2c devices, the struct device  pointer is created
somewhat later and isn't readily available.

I think the struct device pointer is only used as device instance specific
token in the regulator framework.  If so is there any reason it can't be
relaxed to a void * thus allowing something else to be used in i2c drivers?

If so what could actually be used?  Unfortunately all the data elements
of i2c_board_info are coppied out (rather than a pointer to the original
structure being used) so that's not currently available.  I guess it could
be made so at the cost of a single pointer in each i2c_client structure.

So the question is how would people prefer to do this?

Thanks,

--
Jonathan Cameron

Re: Regulator consumer and i2c device interaction.

[Mark Brown]

On Sat, Jan 10, 2009 at 04:01:22PM +0000, Jonathan Cameron wrote:

[Regulators use a struct device and a supply name for lookup...]

> Now in the case of i2c devices, the struct device  pointer is created
> somewhat later and isn't readily available.

> I think the struct device pointer is only used as device instance specific
> token in the regulator framework.  If so is there any reason it can't be

That's the primary reason - this idiom is also used by at least the
clock API and possibly other things.  It also allows us to do things
like show which devices are supplied by which regulators in sysfs.

> relaxed to a void * thus allowing something else to be used in i2c drivers?

That's doable at the cost of the diagnostic info but...

> If so what could actually be used?  Unfortunately all the data elements
> of i2c_board_info are coppied out (rather than a pointer to the original
> structure being used) so that's not currently available.  I guess it could
> be made so at the cost of a single pointer in each i2c_client structure.

...as you say it's a bit tricky to use right now.  I haven't checked but
I expect that the platform data that you can supply in the i2c board info
would work as a token, though it's far from ideal and there may be no
other need for platform data.

As a temporary workaround note that the regulator API allows the device
to be NULL at the minute, though there is a desire to remove that
option.  Providing your regulators have unique names you will be able to
pass the supply name in as platform data and use that only.  This usage
is not encouraged and will hopefully become invalid over time, it's
there at the minute mainly because we don't have a good idea what to use
for the struct device for cpufreq drivers.

> So the question is how would people prefer to do this?

It'd be nice to be able to access the struct device for i2c devices more
readily at registration time.  Like I say, it's not a regulator specific
issue so it'd be good to come up with a general solution.

Re: Regulator consumer and i2c device interaction.

[Jonathan Cameron]

Jonathan Cameron wrote:
> Dear All,
>
> Currently regulator consumers are registered and identified via a pointer to the relevant
> device:
>
> e.g. via a regulator consumer supply structure:
> static struct regulator_consumer_supply imote2_sensor_3_con[] = {
> 	{
> 		.dev = &sht15.dev,
> 		.supply = "vcc",
> 	},
> };
>
> static struct regulator_init_data imote2_ldo_init_data[] = {{
> 	{
> 	 	.constraints = {
> 		.name = "vcc_sensor_3",
> 		.min_uV = 2800000,
> 		.max_uV = 3000000,
> 		.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
> 	},
> 	.num_consumer_supplies = ARRAY_SIZE(imote2_sensor_3_con),
> 	.consumer_supplies = imote2_sensor_3_con,
> },
> };
>
> and relevant association with a regulator driver.
>
> Now in the case of i2c devices, the struct device  pointer is created
> somewhat later and isn't readily available.
>
> I think the struct device pointer is only used as device instance specific
> token in the regulator framework.  If so is there any reason it can't be
> relaxed to a void * thus allowing something else to be used in i2c drivers?
>
> If so what could actually be used?  Unfortunately all the data elements
> of i2c_board_info are coppied out (rather than a pointer to the original
> structure being used) so that's not currently available.  I guess it could
> be made so at the cost of a single pointer in each i2c_client structure.
>   
Oops, that won't work as typically these are specified __initdata .
Any suggestions for alternatives?
> So the question is how would people prefer to do this?
>
> Thanks,
>
> --
> Jonathan Cameron
>
>