Dear All,
Within board configuration files, i2c devices are currently allocated using
i2c_board_info structures. The only element of these that retains it's
memory address once the struct device elements are allocated (upon adapter
initialization) is the platform data pointer.
Several subsystems (regulator and clock for example) use an association
method based upon a device specific string associated with a pointer to
a device structure. Unfortunately as things currently stand there is no
means of obtaining a suitable device for i2c devices at the point when
it is required (in the board config).
So the question is, how to overcome this problem?
Options that I can come up with are:
1) Relax the constraints that the token used for device identification
in subsystems using the regulators approach to a void * and use
the platform data pointer of an i2c device. Note this requires
every device which may need a regulator to have platform data.
Whilst this would work, it is far from ideal.
2) Allow more static allocation of struct i2c_client. The way of doing
this with minimal disruption would be to add a pointer to i2c_board_info
to a preallocated i2c_client structure and if this is supplied do not
allocate another. A flag can then be used to indicated whether the
structure has been statically allocated or not (thus preventing it
being inadvertently freed.
3) Allow static allocation of i2c_client structures as a direct alternative
to having any i2c_board_info structures at all. As the majority if not
all of i2c_board_info's elements are simply copied into the i2c_client
structure anyway, there is considerable overhead in option 2. Clearly
it would not be simple or necessarily advisable to remove i2c_board_info
structures so I would propose providing an alternative set of registration
functions which would only be used when people cared about the problem
we are addressing here.
What do people think? In particular can anyone come up with any other /
better way round this issue. (or am I missing something?)
In particular, are there any similar cases already in kernel that would
suggest a particular approach to solving this issue?
I have an implementation of option 2 that works fine and is relatively simple.
Thanks,
---
Jonathan Cameron
On Mon, Jan 19, 2009 at 07:18:39PM +0000, Jonathan Cameron wrote:
> 1) Relax the constraints that the token used for device identification
> in subsystems using the regulators approach to a void * and use
> the platform data pointer of an i2c device. Note this requires
> every device which may need a regulator to have platform data.
> Whilst this would work, it is far from ideal.
This would also remove the ability of the APIs using this to use the
struct device for other things like showing what they're doing in sysfs
or use dev_printk.
Added spi mailing list (+ likely interested people) as the same approach
is used for device registration as with i2c.
> Dear All,
>
> Within board configuration files, i2c devices are currently allocated using
> i2c_board_info structures. The only element of these that retains it's
> memory address once the struct device elements are allocated (upon adapter
> initialization) is the platform data pointer.
>
> Several subsystems (regulator and clock for example) use an association
> method based upon a device specific string associated with a pointer to
> a device structure. Unfortunately as things currently stand there is no
> means of obtaining a suitable device for i2c devices at the point when
> it is required (in the board config).
>
> So the question is, how to overcome this problem?
>
> Options that I can come up with are:
>
> 1) Relax the constraints that the token used for device identification
> in subsystems using the regulators approach to a void * and use
> the platform data pointer of an i2c device. Note this requires
> every device which may need a regulator to have platform data.
> Whilst this would work, it is far from ideal.
As Mark Brown pointed out:
This would also remove the ability of the APIs using this to use the
struct device for other things like showing what they're doing in sysfs
or use dev_printk.
>
> 2) Allow more static allocation of struct i2c_client. The way of doing
> this with minimal disruption would be to add a pointer to i2c_board_info
> to a preallocated i2c_client structure and if this is supplied do not
> allocate another. A flag can then be used to indicated whether the
> structure has been statically allocated or not (thus preventing it
> being inadvertently freed.
>
> 3) Allow static allocation of i2c_client structures as a direct alternative
> to having any i2c_board_info structures at all. As the majority if not
> all of i2c_board_info's elements are simply copied into the i2c_client
> structure anyway, there is considerable overhead in option 2. Clearly
> it would not be simple or necessarily advisable to remove i2c_board_info
> structures so I would propose providing an alternative set of registration
> functions which would only be used when people cared about the problem
> we are addressing here.
>
> What do people think? In particular can anyone come up with any other /
> better way round this issue. (or am I missing something?)
> In particular, are there any similar cases already in kernel that would
> suggest a particular approach to solving this issue?
>
> I have an implementation of option 2 that works fine and is relatively simple.
>
> Thanks,
>
> ---
> Jonathan Cameron
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Thursday 22 January 2009, Jonathan Cameron wrote:
> > Within board configuration files, i2c devices are currently allocated
> > using i2c_board_info structures. ?The only element of these that retains
> > it's memory address once the struct device elements are allocated (upon
> > adapter initialization) is the platform data pointer.
> >
> > Several subsystems (regulator and clock for example) use an association
> > method based upon a device specific string associated with a pointer to
> > a device structure. ?Unfortunately as things currently stand there is no
> > means of obtaining a suitable device for i2c devices at the point when
> > it is required (in the board config).
Yeah, kind of awkward. Multi-Function Device (MFD) drivers have
this kind of problem a lot. A given I2C device might have a few
dozen child devices -- including regulators and clock generators,
RTCs, GPIOs, input devices, etc -- that can't be set up until the
parent I2C device is probed.
It's solved easily enough by making sure the associations and their
devices get set up after the core of the MFD comes up ... in the
probe() routine. And by making sure the MFD and its subsystem
initializes early enough that those other devices don't fail too
many hidden assumptions.
> > What do people think? In particular can anyone come up with any other /
> > better way round this issue. (or am I missing something?)
> > In particular, are there any similar cases already in kernel that would
> > suggest a particular approach to solving this issue?
This is a special case of a general problem: init sequencing.
The initcall levels don't provide sufficient control, so you
need to work around them.
Static device allocation is a bit problematic, and some folk
really dislike it ... I'm not that averse to it, but since
the cost of a device keeps growing I'd rather avoid that in
most cases. A couple dozen bytes of board_info, especially
if it's __initdata, versus several hundred bytes of "struct
foo_device", multiplied by even just a dozen devices that
won't always be present, adds up.
That leaves a dynamic solution for setting up linkage between
various devices. In the past I've done that using callbacks
to board-specific code that knows what linkages to establish.
You can see that with the GPIO controllers that use I2C or SPI
communications: they have setup callbacks that receive the
device and GPIO information, which can continue to set the
stage for the main event ... and teardown callbacks to break
it all down after the show is done.
So for example those callbacks can be used to configure and
then register the devices which rely on those GPIOs ... like
LED banks, MMC/SD card sense switches, voltage regulator
enables, and so on.
- Dave