Add device tree support for mc13892 regulator driver
Subsystems (4)
v3 cover Add device tree support for mc13892 regulator driver
Changes since v2:
* Drop '[PATCH v2 2/4] regulator: pass device_node to of_get_regulator_init_data()' which has been picked up by Mark
* Add a note on how driver matches regulator device and the node in binding document
Changes since v1:
* Drop '[PATCH 2/5] regulator: fix label names used in device tree bindings' which has been picked up
* Add binding document for mfd/mc13xxx-core device tree support
* Fix regulator/fixed.c breakage caused by interface change on of_get_regulator_init_data()
* Reword the commit message of patch #2 a little bit to make the reason for changing clear
* Retrieve the irq from gpio irq domain
Shawn Guo (3):
mfd: mc13xxx: add device tree probe support
regulator: mc13892: add device tree probe support arm/imx: add mc13892 support into imx51-babbage.dts
Documentation/devicetree/bindings/mfd/mc13xxx.txt | 53 ++++++++++ arch/arm/boot/dts/imx51-babbage.dts | 103 ++++++++++++++++++++- drivers/mfd/mc13xxx-core.c | 106 +++++++++++++++------ drivers/regulator/mc13892-regulator.c | 43 ++++++-- drivers/regulator/mc13xxx-regulator-core.c | 57 +++++++++++ drivers/regulator/mc13xxx.h | 20 ++++ include/linux/mfd/mc13xxx.h | 1 + 7 files changed, 339 insertions(+), 44 deletions(-)
PATCH v3 1/3 mfd: mc13xxx: add device tree probe support
It adds device tree probe support for mc13xxx mfd driver.
--- Documentation/devicetree/bindings/mfd/mc13xxx.txt | 53 ++++++++++ drivers/mfd/mc13xxx-core.c | 106 +++++++++++++++------ 2 files changed, 128 insertions(+), 31 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/mc13xxx.txt
Documentation/devicetree/bindings/mfd/mc13xxx.txt new file +53 -0
@@ -0,0 +1,53 @@ +* Freescale MC13783/MC13892 Power Management Integrated Circuit (PMIC) + +Required properties: +- compatible : Should be "fsl,mc13783" or "fsl,mc13892" + +Optional properties: +- fsl,mc13xxx-uses-adc : Indicate the ADC is being used +- fsl,mc13xxx-uses-codec : Indicate the Audio Codec is being used +- fsl,mc13xxx-uses-rtc : Indicate the RTC is being used +- fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used + +Sub-nodes: +- regulators : Contain the regulator nodes. The name of regulator node + is being used by mc13xxx regulator driver to find the correct relator + device. + + The bindings details of individual regulator device can be found in: + Documentation/devicetree/bindings/regulator/regulator.txt + +Examples: + +ecspi at 70010000 { /* ECSPI1 */ + fsl,spi-num-chipselects = <2>; + cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */ + <&gpio3 25 0>; /* GPIO4_25 */ + status = "okay"; + + pmic: mc13892 at 0 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,mc13892"; + spi-max-frequency = <6000000>; + reg = <0>; + interrupt-parent = <&gpio0>; + interrupts = <8>; + + regulators { + sw1_reg: mc13892__sw1 { + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <1375000>; + regulator-boot-on; + regulator-always-on; + }; + + sw2_reg: mc13892__sw2 { + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <1850000>; + regulator-boot-on; + regulator-always-on; + }; + }; + }; +};
drivers/mfd/mc13xxx-core.c +75 -31
166 lines not on this page · raw message
Signature · 1 line
1.7.4.1
PATCH v3 1/3 mfd: mc13xxx: add device tree probe support
Documentation/devicetree/bindings/mfd/mc13xxx.txt line 15
Quoted 4 lines · Shawn Guo
Documentation/devicetree/bindings/mfd/mc13xxx.txt new file +4
-0+Sub-nodes: +- regulators : Contain the regulator nodes. The name of regulator node + is being used by mc13xxx regulator driver to find the correct relator + device.
Reading this I'm not clear what the name of the node is, or what the valid node names are.
Documentation/devicetree/bindings/mfd/mc13xxx.txt line 38
Quoted 1 line
Documentation/devicetree/bindings/mfd/mc13xxx.txt new file +1
-0+ sw1_reg: mc13892__sw1 {
The examples don't really elucidate this either (and the __ is rather odd).
PATCH v3 1/3 mfd: mc13xxx: add device tree probe support
Quoted 10 lines · Mark Brown
Documentation/devicetree/bindings/mfd/mc13xxx.txt line 15
Quoted 4 lines · Shawn Guo
Documentation/devicetree/bindings/mfd/mc13xxx.txt new file +4
-0+Sub-nodes: +- regulators : Contain the regulator nodes. The name of regulator node + is being used by mc13xxx regulator driver to find the correct relator + device.Reading this I'm not clear what the name of the node is, or what the valid node names are.
In the example below, the name would be 'mc13892__sw1'.
Quoted 4 lines
Documentation/devicetree/bindings/mfd/mc13xxx.txt line 38
Quoted 1 line
Documentation/devicetree/bindings/mfd/mc13xxx.txt new file +1
-0+ sw1_reg: mc13892__sw1 {The examples don't really elucidate this either (and the __ is rather odd).
Yes, that's because the name defined by mc13892 regulator driver is odd.
There is a '_' in 'MC13892_' when using MC13xxx_DEFINE below.
#define MC13892_SW_DEFINE(name, reg, vsel_reg, voltages) \
MC13xxx_DEFINE(MC13892_, name, reg, vsel_reg, voltages, \
mc13892_sw_regulator_ops)And the second one comes from the definition of .name below.
#define MC13xxx_DEFINE(prefix, _name, _reg, _vsel_reg, _voltages, _ops) \
[prefix ## _name] = { \
.desc = { \
.name = #prefix "_" #_name, \Using the regulator name to find the correct device is the approach I can see that brings the least churn to the existing driver. You may think the regulator name is Linux mc13892 regulator driver specific. But I think it should be something from hardware manual and should be used in driver and device tree consistently. Unfortunately, the driver created an odd name first, and we have to use that name in device tree to minimize the diff stat.
Signature · 2 lines
Regards, Shawn
PATCH v3 1/3 mfd: mc13xxx: add device tree probe support
Quoted 8 lines · Shawn Guo
Quoted 6 lines · Mark Brown
Quoted 4 lines · Shawn Guo
Documentation/devicetree/bindings/mfd/mc13xxx.txt new file +4
-0+Sub-nodes: +- regulators : Contain the regulator nodes. The name of regulator node + is being used by mc13xxx regulator driver to find the correct relator + device.
Quoted 4 lines
Quoted 2 lines
Reading this I'm not clear what the name of the node is, or what the valid node names are.
In the example below, the name would be '
mc13892__sw1'.
You're missing the point - someone reading the documentation needs to be able to figure out what strings they need to use for all the different regulators on the chip are without groveling through the driver code.
Quoted 6 lines
Quoted 4 lines
Documentation/devicetree/bindings/mfd/mc13xxx.txt line 38
Quoted 1 line
Documentation/devicetree/bindings/mfd/mc13xxx.txt new file +1
-0+ sw1_reg: mc13892__sw1 {The examples don't really elucidate this either (and the __ is rather odd).
Yes, that's because the name defined by mc13892 regulator driver is odd.
That's *not* something that we should be exposing in the device tree bindings. This is an implementation detail of the Linux driver which might well change in future.
PATCH v3 1/3 mfd: mc13xxx: add device tree probe support
Quoted 23 lines · Mark Brown
Quoted 8 lines · Shawn Guo
Quoted 6 lines · Mark Brown
Quoted 4 lines · Shawn Guo
Documentation/devicetree/bindings/mfd/mc13xxx.txt new file +4
-0+Sub-nodes: +- regulators : Contain the regulator nodes. The name of regulator node + is being used by mc13xxx regulator driver to find the correct relator + device.Quoted 4 lines
Quoted 2 lines
Reading this I'm not clear what the name of the node is, or what the valid node names are.
In the example below, the name would be '
mc13892__sw1'.You're missing the point - someone reading the documentation needs to be able to figure out what strings they need to use for all the different regulators on the chip are without groveling through the driver code.
Quoted 4 lines
Quoted 4 lines
Documentation/devicetree/bindings/mfd/mc13xxx.txt line 38
Quoted 1 line
Documentation/devicetree/bindings/mfd/mc13xxx.txt new file +1
-0+ sw1_reg: mc13892__sw1 {The examples don't really elucidate this either (and the __ is rather odd).
Quoted 6 lines
Quoted 1 line
Yes, that's because the name defined by mc13892 regulator driver is odd.
That's *not* something that we should be exposing in the device tree bindings. This is an implementation detail of the Linux driver which might well change in future.
Any suggestion on a better binding for mc13892 regulator device?
Signature · 2 lines
Regards, Shawn
PATCH v3 1/3 mfd: mc13xxx: add device tree probe support
Quoted 5 lines · Shawn Guo
Quoted 3 lines · Mark Brown
You're missing the point - someone reading the documentation needs to be able to figure out what strings they need to use for all the different regulators on the chip are without groveling through the driver code.
...
Quoted 5 lines
Quoted 3 lines
That's *not* something that we should be exposing in the device tree bindings. This is an implementation detail of the Linux driver which might well change in future.
Any suggestion on a better binding for mc13892 regulator device?
Well, removing the random extra _s would be a big start (though I'd just drop the chip name entirely from the name of the regulators since by the time we're looking at the regulator we've already identified the chip) and as I keep saying you need to document what the names mean - what are the possible names and how do they map onto the hardware?
PATCH v3 1/3 mfd: mc13xxx: add device tree probe support
Quoted 13 lines · Mark Brown
Quoted 5 lines · Shawn Guo
Quoted 3 lines · Mark Brown
You're missing the point - someone reading the documentation needs to be able to figure out what strings they need to use for all the different regulators on the chip are without groveling through the driver code.
...
Quoted 3 lines
Quoted 3 lines
That's *not* something that we should be exposing in the device tree bindings. This is an implementation detail of the Linux driver which might well change in future.
Quoted 8 lines
Quoted 1 line
Any suggestion on a better binding for mc13892 regulator device?
Well, removing the random extra _s would be a big start (though I'd just drop the chip name entirely from the name of the regulators since by the time we're looking at the regulator we've already identified the chip) and as I keep saying you need to document what the names mean - what are the possible names and how do they map onto the hardware?
I just came up with an idea which can totally avoid matching name. It seems that we can identify a regulator using register plus enable bit, which is basically 'reg' and 'enable_bit' in 'mc13xxx_regulator'. As these data must be coming from hardware manual, they should be stable enough for binding a regulator. What do you think?
Signature · 2 lines
Regards, Shawn
PATCH v3 1/3 mfd: mc13xxx: add device tree probe support
Quoted 8 lines · Shawn Guo
Quoted 5 lines · Mark Brown
Well, removing the random extra _s would be a big start (though I'd just drop the chip name entirely from the name of the regulators since by the time we're looking at the regulator we've already identified the chip) and as I keep saying you need to document what the names mean - what are the possible names and how do they map onto the hardware?
Quoted 5 lines
I just came up with an idea which can totally avoid matching name. It seems that we can identify a regulator using register plus enable bit, which is basically 'reg' and '
enable_bit' in 'mc13xxx_regulator'. As these data must be coming from hardware manual, they should be stable enough for binding a regulator. What do you think?
I don't know that that helps, register numbers and shifts aren't going to do anything for legibility. The problem with the names was that the names chosen were poorly defined (why call DCDCn chipname__dcdcn?) and not documented in the binding, not that they were names.
PATCH v3 1/3 mfd: mc13xxx: add device tree probe support
Quoted 9 lines · Mark Brown
Quoted 7 lines · Shawn Guo
Quoted 5 lines · Mark Brown
Well, removing the random extra _s would be a big start (though I'd just drop the chip name entirely from the name of the regulators since by the time we're looking at the regulator we've already identified the chip) and as I keep saying you need to document what the names mean - what are the possible names and how do they map onto the hardware?
Quoted 8 lines
Quoted 5 lines
I just came up with an idea which can totally avoid matching name. It seems that we can identify a regulator using register plus enable bit, which is basically 'reg' and '
enable_bit' in 'mc13xxx_regulator'. As these data must be coming from hardware manual, they should be stable enough for binding a regulator. What do you think?I don't know that that helps, register numbers and shifts aren't going to do anything for legibility.
I think it helps. It's not about legibility but identification. For mc13892 driver to work, it has to match the register number and enable bit shift given by mc13892 reference manual. So register number + enable bit shift is stable and unique to identify a mc13892 regulator.
Quoted 4 lines
The problem with the names was that the
names chosen were poorly defined (why call DCDCnchipname__dcdcn?) and not documented in the binding, not that they were names.
The problem with name is it's name. The mc13892 driver can still work with naming regulator differently from mc13892 reference manual. So using name to bind a regulator means we are binding with Linux mc13892 driver. In that case, DT probe works if and only if the name in dts matches the name used in mc13892 driver, and it does not work as long as the name dts does not match the name used in mc13892 driver.
Yes, I flipped and now think using name to bind is a bad idea, no matter how we document it.
Signature · 2 lines
Regards, Shawn
PATCH v3 1/3 mfd: mc13xxx: add device tree probe support
Quoted 9 lines · Shawn Guo
Quoted 2 lines · Mark Brown
I don't know that that helps, register numbers and shifts aren't going to do anything for legibility.
I think it helps. It's not about legibility but identification. For mc13892 driver to work, it has to match the register number and enable bit shift given by mc13892 reference manual. So register number + enable bit shift is stable and unique to identify a mc13892 regulator.
It's unique but I feel the disadvantages in terms of legibility of the resulting device trees are substantial - we want humans to be able to read and write device trees, preferrably without having to dig out the datasheet for the part. So long as the names are reasonably sensible and can be understood in the case of any lack of clarity we should be OK.
Quoted 10 lines
Quoted 3 lines
The problem with the names was that the
names chosen were poorly defined (why call DCDCnchipname__dcdcn?) and not documented in the binding, not that they were names.The problem with name is it's name. The mc13892 driver can still work with naming regulator differently from mc13892 reference manual. So using name to bind a regulator means we are binding with Linux mc13892 driver. In that case, DT probe works if and only if the name in dts matches the name used in mc13892 driver, and it does not work as long as the name dts does not match the name used in mc13892 driver.
This is the whole reason why I'm saying that you need to define the names used in the binding - if the names are a defined part of the binding then there's nothing driver specific about them.
PATCH v3 1/3 mfd: mc13xxx: add device tree probe support
Quoted 11 lines · Mark Brown
Quoted 9 lines · Shawn Guo
Quoted 2 lines · Mark Brown
I don't know that that helps, register numbers and shifts aren't going to do anything for legibility.
I think it helps. It's not about legibility but identification. For mc13892 driver to work, it has to match the register number and enable bit shift given by mc13892 reference manual. So register number + enable bit shift is stable and unique to identify a mc13892 regulator.
Quoted 4 lines
It's unique but I feel the disadvantages in terms of legibility of the resulting device trees are substantial - we want humans to be able to read and write device trees, preferrably without having to dig out the datasheet for the part.
Eh, device tree is all about describing hardware. I do not understand what is wrong with looking at hardware manual when writing dts.
Quoted 4 lines
So long as the names are reasonably sensible
and can be understood in the case of any lack of clarity we should be OK.
The problem is even if we have the name defined that way, it has to be matched to the name used in mc13892 driver somehow, if we want to use name as the key to find the regulator defined in mc13892 driver as array mc13892_regulators[].
Quoted 11 lines
Quoted 10 lines
Quoted 3 lines
The problem with the names was that the
names chosen were poorly defined (why call DCDCnchipname__dcdcn?) and not documented in the binding, not that they were names.The problem with name is it's name. The mc13892 driver can still work with naming regulator differently from mc13892 reference manual. So using name to bind a regulator means we are binding with Linux mc13892 driver. In that case, DT probe works if and only if the name in dts matches the name used in mc13892 driver, and it does not work as long as the name dts does not match the name used in mc13892 driver.
Quoted 4 lines
This is the whole reason why I'm saying that you need to define the names used in the binding - if the names are a defined part of the binding then there's nothing driver specific about them.
Can you please help me understand how this can be achieved with an example? Taking 'mc13892__sw1' as the example, if I read your comment before correctly, 'sw1' is the name that you are suggesting. How this name can be nothing driver specific? After all, we need to find regulator MC13892_SW1 defined in mc13892_regulators[] by matching name 'sw1' defined by binding and name 'MC13892_SW1' defined by driver somehow, if we want to use name to bind the regulator.
I feel I might miss your point again. So please help clarify.
Signature · 2 lines
Regards, Shawn
PATCH v3 1/3 mfd: mc13xxx: add device tree probe support
Quoted 9 lines · Shawn Guo
Quoted 4 lines · Mark Brown
It's unique but I feel the disadvantages in terms of legibility of the resulting device trees are substantial - we want humans to be able to read and write device trees, preferrably without having to dig out the datasheet for the part.
Eh, device tree is all about describing hardware. I do not understand what is wrong with looking at hardware manual when writing dts.
For the same reason we define constants for register names and values when writing drivers - so humans can make sense of what's in front of them and to reduce the chance of errors when things are being written.
Quoted 8 lines
Quoted 3 lines
So long as the names are reasonably sensible
and can be understood in the case of any lack of clarity we should be OK.The problem is even if we have the name defined that way, it has to be matched to the name used in mc13892 driver somehow, if we want to use name as the key to find the regulator defined in mc13892 driver as array mc13892_regulators[].
This doesn't seem like a problem - the most obvious thing would just be to adjust the strings in the code to correspond to what the device tree binding says.
Quoted 11 lines
Quoted 3 lines
This is the whole reason why I'm saying that you need to define the names used in the binding - if the names are a defined part of the binding then there's nothing driver specific about them.
Can you please help me understand how this can be achieved with an example? Taking '
mc13892__sw1' as the example, if I read your comment before correctly, 'sw1' is the name that you are suggesting. How this name can be nothing driver specific? After all, we need to find regulatorMC13892_SW1defined in mc13892_regulators[] by matching name 'sw1' defined by binding and name 'MC13892_SW1' defined by driver somehow, if we want to use name to bind the regulator.
Your binding document would say something like "the regulators are bound using their names as listed below with their enable bits:
sw1 - SW1 regulator (register X bit Y)
" so in the binding document it would say what strings map onto which regulators. Then any driver implementing that binding would pick the same strings.
PATCH v3 1/3 mfd: mc13xxx: add device tree probe support
Quoted 10 lines · Mark Brown
Quoted 4 lines · Shawn Guo
The problem is even if we have the name defined that way, it has to be matched to the name used in mc13892 driver somehow, if we want to use name as the key to find the regulator defined in mc13892 driver as array mc13892_regulators[].
This doesn't seem like a problem - the most obvious thing would just be to adjust the strings in the code to correspond to what the device tree binding says.
Okay, that's it. Something obvious to you is not obvious to me :) As I'm migrating an existing driver to be DT aware, I'm trying to avoid changing any non-dt code. Your suggestion would be obvious to me if I'm writing a new driver that only supports DT.
Anyway, I got your point, and will follow that since you seems fine with changing non-dt code to adopt dt support.
Signature · 2 lines
Regards, Shawn
PATCH v3 2/3 regulator: mc13892: add device tree probe support
In reply to Shawn GuoIt adds device tree probe support for mc13892-regulator driver.
--- drivers/regulator/mc13892-regulator.c | 43 +++++++++++++++----- drivers/regulator/mc13xxx-regulator-core.c | 57 ++++++++++++++++++++++++++++ drivers/regulator/mc13xxx.h | 20 ++++++++++ include/linux/mfd/mc13xxx.h | 1 + 4 files changed, 110 insertions(+), 11 deletions(-)
drivers/regulator/mc13892-regulator.c +32 -11
@@ -527,18 +527,27 @@ static int __devinit mc13892_regulator_probe(struct platform_device *pdev)struct mc13xxx *mc13892 =dev_get_drvdata (pdev->dev.parent);struct mc13xxx_regulator_platform_data *pdata =dev_get_platdata (&pdev->dev); -struct mc13xxx_regulator_init_data *init_data; +struct mc13xxx_regulator_init_data *mc13xxx_data;int i, ret; +int num_regulators =0 ;u32 val; + num_regulators =mc13xxx_get_num_regulators_dt (pdev); +if (num_regulators <=0 && pdata) + num_regulators = pdata->num_regulators; +if (num_regulators <=0 ) +return -EINVAL ; + priv =kzalloc (sizeof (*priv) + - pdata->num_regulators *sizeof (priv->regulators[0 ]), + num_regulators *sizeof (priv->regulators[0 ]),GFP_KERNEL );if (!priv)return -ENOMEM ; + priv->num_regulators = num_regulators; priv->mc13xxx_regulators = mc13892_regulators; priv->mc13xxx = mc13892; +platform_set_drvdata (pdev, priv);mc13xxx_lock (mc13892); ret =mc13xxx_reg_read (mc13892,MC13892_REVISION , &val);
@@ -569,11 +578,27 @@ static int __devinit mc13892_regulator_probe(struct platform_device *pdev) = mc13892_vcam_set_mode; mc13892_regulators[MC13892_VCAM ].desc.ops->get_mode = mc13892_vcam_get_mode; -for (i =0 ; i < pdata->num_regulators; i++) { - init_data = &pdata->regulators[i]; + + mc13xxx_data =mc13xxx_parse_regulators_dt (pdev, mc13892_regulators, +ARRAY_SIZE (mc13892_regulators)); +for (i =0 ; i < num_regulators; i++) { +struct regulator_init_data *init_data; +struct regulator_desc *desc; +struct device_node *node =NULL ; +int id; + +if (mc13xxx_data) { + id = mc13xxx_data[i].id; + init_data = mc13xxx_data[i].init_data; + node = mc13xxx_data[i].node; + }else { + id = pdata->regulators[i].id; + init_data = pdata->regulators[i].init_data; + } + desc = &mc13892_regulators[id].desc; + priv->regulators[i] =regulator_register ( - &mc13892_regulators[init_data->id].desc, - &pdev->dev, init_data->init_data, priv,NULL ); + desc, &pdev->dev, init_data, priv, node);if (IS_ERR (priv->regulators[i])) { dev_err(&pdev->dev, "failed to register regulator %s\n",
@@ -583,8 +608,6 @@ static int __devinit mc13892_regulator_probe(struct platform_device *pdev) } } -platform_set_drvdata (pdev, priv); -return 0 ; err:while (--i >=0 )
@@ -600,13 +623,11 @@ err_free: static int __devexit mc13892_regulator_remove(struct platform_device *pdev) {struct mc13xxx_regulator_priv *priv =platform_get_drvdata (pdev); -struct mc13xxx_regulator_platform_data *pdata = -dev_get_platdata (&pdev->dev);int i;platform_set_drvdata (pdev,NULL ); -for (i =0 ; i < pdata->num_regulators; i++) +for (i =0 ; i < priv->num_regulators; i++)regulator_unregister (priv->regulators[i]);kfree (priv);
drivers/regulator/mc13xxx-regulator-core.c +57 -0
75 lines not on this page · raw message
drivers/regulator/mc13xxx.h +20 -0
@@ -29,6 +29,7 @@ struct mc13xxx_regulator_priv {struct mc13xxx *mc13xxx;u32 powermisc_pwgt_state;struct mc13xxx_regulator *mc13xxx_regulators; +int num_regulators;struct regulator_dev *regulators[]; };
@@ -42,6 +43,25 @@ extern int mc13xxx_fixed_regulator_set_voltage(struct regulator_dev *rdev, int min_uV, int max_uV, unsigned *selector);extern int mc13xxx_fixed_regulator_get_voltage (struct regulator_dev *rdev); +#ifdef CONFIG_OF +extern int mc13xxx_get_num_regulators_dt (struct platform_device *pdev); +extern struct mc13xxx_regulator_init_data *mc13xxx_parse_regulators_dt ( +struct platform_device *pdev,struct mc13xxx_regulator *regulators, +int num_regulators); +#else +static inline int mc13xxx_get_num_regulators_dt (struct platform_device *pdev) +{ +return -ENODEV ; +} + +static inline struct mc13xxx_regulator_init_data *mc13xxx_parse_regulators_dt ( +struct platform_device *pdev,struct mc13xxx_regulator *regulators, +int num_regulators) +{ +return NULL ; +} +#endif +extern struct regulator_ops mc13xxx_regulator_ops;extern struct regulator_ops mc13xxx_fixed_regulator_ops;
include/linux/mfd/mc13xxx.h +1 -0
@@ -69,6 +69,7 @@ struct regulator_init_data;struct mc13xxx_regulator_init_data {int id;struct regulator_init_data *init_data; +struct device_node *node; };struct mc13xxx_regulator_platform_data {
Signature · 1 line
1.7.4.1
PATCH v3 2/3 regulator: mc13892: add device tree probe support
Quoted 5 lines · Shawn Guo
It adds device tree probe support for mc13892-regulator driver.
Signed-off-by Shawn Guo <[email protected]>Cc Mark Brown <[email protected]>Cc Liam Girdwood <[email protected]>
Ping?
Signature · 2 lines
Regards, Shawn
PATCH v3 2/3 regulator: mc13892: add device tree probe support
Quoted 8 lines · Shawn Guo
Quoted 5 lines · Shawn Guo
It adds device tree probe support for mc13892-regulator driver.
Signed-off-by Shawn Guo <[email protected]>Cc Mark Brown <[email protected]>Cc Liam Girdwood <[email protected]>Ping?
I can't really do anything with this without the MFD portion being OK.
PATCH v3 2/3 regulator: mc13892: add device tree probe support
Quoted 4 lines · Mark Brown
Quoted 3 lines · Shawn Guo
Quoted 2 lines · Shawn Guo
It adds device tree probe support for mc13892-regulator driver.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Signed-off-by Shawn Guo <[email protected]>Cc Mark Brown <[email protected]>Cc Liam Girdwood <[email protected]>Ping?
I can't really do anything with this without the MFD portion being OK.
It seems that Samuel has applied it.
http://article.gmane.org/gmane.linux.drivers.devicetree/10441
Signature · 2 lines
Regards, Shawn
PATCH v3 2/3 regulator: mc13892: add device tree probe support
Quoted 3 lines · Shawn Guo
It seems that Samuel has applied it.
http://article.gmane.org/gmane.linux.drivers.devicetree/10441
Oh, that's a bit unfortunate as looking at the first patch I'm still not happy I understand what the regulator part of the binding is supposed to be...
PATCH v3 2/3 regulator: mc13892: add device tree probe support
Quoted 10 lines · Mark Brown
Quoted 3 lines · Shawn Guo
It seems that Samuel has applied it.
http://article.gmane.org/gmane.linux.drivers.devicetree/10441
Oh, that's a bit unfortunate as looking at the first patch I'm still not happy I understand what the regulator part of the binding is supposed to be...
I will be very happy to send any incremental patch for anything that we agree to improve.
Signature · 2 lines
Regards, Shawn
PATCH v3 3/3 arm/imx: add mc13892 support into imx51-babbage.dts
In reply to Shawn GuoIt adds mc13892 support into imx51-babbage device tree source.
--- arch/arm/boot/dts/imx51-babbage.dts | 103 ++++++++++++++++++++++++++++++++++- 1 files changed, 101 insertions(+), 2 deletions(-)
arch/arm/boot/dts/imx51-babbage.dts +101 -2
@@ -31,12 +31,14 @@ esdhc at 70004000 { /* ESDHC1 */ fsl,cd-internal; fsl,wp-internal; + vmmc-supply = <&vsd_reg>; status = "okay"; }; esdhc at 70008000 { /* ESDHC2 */ cd-gpios = <&gpio0 6 0>; /* GPIO1_6 */ wp-gpios = <&gpio0 5 0>; /* GPIO1_5 */ + vmmc-supply = <&vsd_reg>; status = "okay"; };
@@ -57,8 +59,105 @@ compatible = "fsl,mc13892"; spi-max-frequency = <6000000>; reg = <0>; - mc13xxx-irq-gpios = <&gpio0 8 0>; /* GPIO1_8 */ - fsl,mc13xxx-uses-regulator; + interrupt-parent = <&gpio0>; + interrupts = <8>; + + regulators { + sw1_reg: mc13892__sw1 { + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <1375000>; + regulator-boot-on; + regulator-always-on; + }; + + sw2_reg: mc13892__sw2 { + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <1850000>; + regulator-boot-on; + regulator-always-on; + }; + + sw3_reg: mc13892__sw3 { + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1850000>; + regulator-boot-on; + regulator-always-on; + }; + + sw4_reg: mc13892__sw4 { + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1850000>; + regulator-boot-on; + regulator-always-on; + }; + + viohi_reg: mc13892__viohi { + regulator-boot-on; + regulator-always-on; + }; + + vpll_reg: mc13892__vpll { + regulator-min-microvolt = <1050000>; + regulator-max-microvolt = <1800000>; + regulator-boot-on; + regulator-always-on; + }; + + vdig_reg: mc13892__vdig { + regulator-min-microvolt = <1650000>; + regulator-max-microvolt = <1650000>; + regulator-boot-on; + }; + + vsd_reg: mc13892__vsd { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3150000>; + }; + + vusb2_reg: mc13892__vusb2 { + regulator-min-microvolt = <2400000>; + regulator-max-microvolt = <2775000>; + regulator-boot-on; + regulator-always-on; + }; + + vvideo_reg: mc13892__vvideo { + regulator-min-microvolt = <2775000>; + regulator-max-microvolt = <2775000>; + }; + + vaudio_reg: mc13892__vaudio { + regulator-min-microvolt = <2300000>; + regulator-max-microvolt = <3000000>; + }; + + vcam_reg: mc13892__vcam { + regulator-min-microvolt = <2500000>; + regulator-max-microvolt = <3000000>; + }; + + vgen1_reg: mc13892__vgen1 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + }; + + vgen2_reg: mc13892__vgen2 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3150000>; + regulator-always-on; + }; + + vgen3_reg: mc13892__vgen3 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <2900000>; + regulator-always-on; + }; + + vusb_reg: mc13892__vusb { + regulator-boot-on; + regulator-always-on; + }; + }; }; flash: at45db321d at 1 {
Signature · 1 line
1.7.4.1