* Mark Brown wrote:
> On Wed, Apr 25, 2012 at 12:41:47PM +0200, Thierry Reding wrote:
>
> > After taking a closer look I don't think Rhyland's patch is very useful for
> > this driver. I need to lookup the platform ID by regulator name anyway so
> > using the new code is actually more work and requires a second table that
> > lists the regulator names only.
>
> Why do you need the plaform ID, and if it is needed could we work out a
> way to make the generic code do that lookup for you (since presumably
> other drivers will have the same requirement)? If you can't use the
> generic code it seems like the fix is to enhance the generic code and
> I'd expect that something not requiring the platform ID would just be
> able to igore that information if the generic code could look it up.
Basically the platform ID is used by the regulator driver to differentiate
between the different types of regulators. I could imagine a more advanced
setup to do the matching, along the lines of OF device matching and platform
device matching, where an entry in the table has both a name and an
associated "driver data" field.
For instance we could have a new structure:
struct regulator_lookup_data {
const char *name;
unsigned long driver_data;
struct regulator_init_data *init_data;
struct device_node *of_node;
};
static struct regulator_lookup_data tps6586x_lookup[] = {
{ .name = "sm0", .driver_data = TPS6586X_ID_SM_0 },
{ .name = "sm1", .driver_data = TPS6586X_ID_SM_1 },
...
};
And pass that into of_find_regulator_init_data_from_device():
of_find_regulator_init_data_from_device(&client->dev, regulators,
tps6586x_lookup,
ARRAY_SIZE(tps6586x_lookup));
Upon return, the tps6586x_lookup table will have the init_data and of_node
fields filled with the data parsed from the DT. Then we can simply iterate
over all entries and add the corresponding regulators.
This is somewhat ugly because of_find_regulator_init_data_from_device() would
modify the same data structure for potentially different devices. This should
be okay because the driver core takes care of serializing device probing
(unless I am mistaken). Alternatively we could make the function return a
copy of the regulator_lookup_data structure with the additional fields filled
in.
Thierry
Attachment:
pgpequr4FaLL7.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
