mfd/power/phy: Add support for otg vbus detection via axp pmic
Subsystems (6)
cover mfd/power/phy: Add support for otg vbus detection via axp pmic
Hi All,
Here is a series which adds the beginning of power-supply support to the axp20x pmic code. My primary reason for working on this is to enable the use of the usb power-supply bits in the pmic to for vbus detection on boards which do not have a vbus-det gpio, and instead rely on the pmic for vbus detection.
After I had written most of the vbus power-supply driver code I became aware of Bruno Pr?mont's (in the CC) previous work on this our drivers are mostly the same, and I've borrowed some code from his driver to add support for min-volt / max-curr properties.
The big difference between our 2 drivers is that mine driver uses a devicetree child node / mfd cell per power-supply, so one for each of the usb-power, ac-power / battery-charger and rtc-backup-bat-charger bits.
Depending on the board each of those must be enabled / disabled separately in devicetree as most boards do not use all 4. So in dt each one needs its own child-node of the axp20x node. Another reason for using separate child nodes for each is so that other devicetree nodes can have a power-supply property with a phandle referencing a node representing a single power-supply.
Regards,
Hans
PATCH 1/8 mfd: axp20x: Add missing registers, and mark more registers volatile
From: Bruno Pr?mont <[email protected]>
Add an extra set of registers which is necessary tu support the PMICs battery charger function, and mark registers which contain status bits, gpio status, and adc readings as volatile.
--- drivers/mfd/axp20x.c | 6 ++++++ include/linux/mfd/axp20x.h | 5 +++++ 2 files changed, 11 insertions(+)
drivers/mfd/axp20x.c +6 -0
@@ -39,10 +39,16 @@ static const char * const axp20x_model_names[] = {static const struct regmap_range axp20x_writeable_ranges[] = {regmap_reg_range (AXP20X_DATACACHE (0 ),AXP20X_IRQ5_STATE ),regmap_reg_range (AXP20X_DCDC_MODE ,AXP20X_FG_RES ), +regmap_reg_range (AXP20X_RDC_H ,AXP20X_OCV (15 )), };static const struct regmap_range axp20x_volatile_ranges[] = { +regmap_reg_range (AXP20X_PWR_INPUT_STATUS ,AXP20X_USB_OTG_STATUS ), +regmap_reg_range (AXP20X_CHRG_CTRL1 ,AXP20X_CHRG_CTRL2 ),regmap_reg_range (AXP20X_IRQ1_EN ,AXP20X_IRQ5_STATE ), +regmap_reg_range (AXP20X_ACIN_V_ADC_H ,AXP20X_IPSOUT_V_HIGH_L ), +regmap_reg_range (AXP20X_GPIO20_SS ,AXP20X_GPIO3_CTRL ), +regmap_reg_range (AXP20X_FG_RES ,AXP20X_RDC_L ), };static const struct regmap_access_table axp20x_writeable_table = {
include/linux/mfd/axp20x.h +5 -0
@@ -151,6 +151,11 @@ enum {#define AXP20X_CC_CTRL 0xb8#define AXP20X_FG_RES 0xb9 +/* OCV */ +#define AXP20X_RDC_H 0xba +#define AXP20X_RDC_L 0xbb +#define AXP20X_OCV (m) (0xc0 + (m)) +/* AXP22X specific registers */ #define AXP22X_BATLOW_THRES1 0xe6
Signature · 1 line
2.3.6
PATCH 1/8 mfd: axp20x: Add missing registers, and mark more registers volatile
Quoted 18 lines · Hans de Goede
From: Bruno Pr?mont <[email protected]>
Add an extra set of registers which is necessary tu support the PMICs battery charger function, and mark registers which contain status bits, gpio status, and adc readings as volatile.
Cc Bruno Pr?mont <[email protected]>Signed-off-by Hans de Goede <[email protected]>--- drivers/mfd/axp20x.c | 6 ++++++ include/linux/mfd/axp20x.h | 5 +++++ 2 files changed, 11 insertions(+)drivers/mfd/axp20x.c +0
-0
drivers/mfd/axp20x.c static const char * const axp20x_model_names[] = { · line 42
Quoted 4 lines
drivers/mfd/axp20x.c +1
-0@@ -39,10 +39,16 @@ static const char * const axp20x_model_names[] = {static const struct regmap_range axp20x_writeable_ranges[] = {regmap_reg_range (AXP20X_DATACACHE (0 ),AXP20X_IRQ5_STATE ),regmap_reg_range (AXP20X_DCDC_MODE ,AXP20X_FG_RES ), +regmap_reg_range (AXP20X_RDC_H ,AXP20X_OCV (15 )),
Define 15 please.
Quoted 28 lines
drivers/mfd/axp20x.c +5
-0};static const struct regmap_range axp20x_volatile_ranges[] = { +regmap_reg_range (AXP20X_PWR_INPUT_STATUS ,AXP20X_USB_OTG_STATUS ), +regmap_reg_range (AXP20X_CHRG_CTRL1 ,AXP20X_CHRG_CTRL2 ),regmap_reg_range (AXP20X_IRQ1_EN ,AXP20X_IRQ5_STATE ), +regmap_reg_range (AXP20X_ACIN_V_ADC_H ,AXP20X_IPSOUT_V_HIGH_L ), +regmap_reg_range (AXP20X_GPIO20_SS ,AXP20X_GPIO3_CTRL ), +regmap_reg_range (AXP20X_FG_RES ,AXP20X_RDC_L ), };static const struct regmap_access_table axp20x_writeable_table = {include/linux/mfd/axp20x.h +5
-0@@ -151,6 +151,11 @@ enum {#define AXP20X_CC_CTRL 0xb8#define AXP20X_FG_RES 0xb9 +/* OCV */ +#define AXP20X_RDC_H 0xba +#define AXP20X_RDC_L 0xbb +#define AXP20X_OCV (m) (0xc0 + (m)) +/* AXP22X specific registers */ #define AXP22X_BATLOW_THRES1 0xe6
Signature · 4 lines
Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH 2/8 mfd: axp20x: Add a cell for the usb power_supply part of the axp20x PMICs
In reply to Hans de GoedeAdd a cell for the usb power_supply part of the axp20x PMICs.
Note that this cell is only for the usb power_supply part and not the ac-power / battery-charger / rtc-backup-bat-charger bits.
Depending on the board each of those must be enabled / disabled separately in devicetree as most boards do not use all 4. So in dt each one needs its own child-node of the axp20x node. Another reason for using separate child nodes for each is so that other devicetree nodes can have a power-supply property with a phandle referencing a node representing a single power-supply.
The decision to use a separate devicetree node for each is reflected on the kernel side by each getting its own mfd-cell / platform_device and platform-driver.
--- drivers/mfd/axp20x.c | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-)
drivers/mfd/axp20x.c +31 -1
@@ -113,6 +113,30 @@ static struct resource axp20x_pek_resources[] = { }, }; +static struct resource axp20x_usb_power_supply_resources[] = { + { + .name ="VBUS_PLUGIN" , + .start =AXP20X_IRQ_VBUS_PLUGIN , + .end =AXP20X_IRQ_VBUS_PLUGIN , + .flags =IORESOURCE_IRQ , + }, { + .name ="VBUS_REMOVAL" , + .start =AXP20X_IRQ_VBUS_REMOVAL , + .end =AXP20X_IRQ_VBUS_REMOVAL , + .flags =IORESOURCE_IRQ , + }, { + .name ="VBUS_VALID" , + .start =AXP20X_IRQ_VBUS_VALID , + .end =AXP20X_IRQ_VBUS_VALID , + .flags =IORESOURCE_IRQ , + }, { + .name ="VBUS_NOT_VALID" , + .start =AXP20X_IRQ_VBUS_NOT_VALID , + .end =AXP20X_IRQ_VBUS_NOT_VALID , + .flags =IORESOURCE_IRQ , + }, +}; +static struct resource axp22x_pek_resources[] = { { .name ="PEK_DBR" ,
@@ -165,7 +189,7 @@ static const struct regmap_config axp20x_regmap_config = { .val_bits = 8, .wr_table = &axp20x_writeable_table, .volatile_table = &axp20x_volatile_table, - .max_register = AXP20X_FG_RES, + .max_register = AXP20X_OCV(15), .cache_type = REGCACHE_RBTREE, };
@@ -368,6 +392,12 @@ static struct mfd_cell axp20x_cells[] = { .resources = axp20x_pek_resources, }, { .name = "axp20x-regulator", + }, { + .name = "axp20x-usb-power-supply", + .of_compatible = "x-powers,axp202-usb-power-supply", + .num_resources = + ARRAY_SIZE(axp20x_usb_power_supply_resources), + .resources = axp20x_usb_power_supply_resources, }, };
Signature · 1 line
2.3.6
PATCH 2/8 mfd: axp20x: Add a cell for the usb power_supply part of the axp20x PMICs
Quoted 67 lines · Hans de Goede
Add a cell for the usb
power_supplypart of the axp20x PMICs.Note that this cell is only for the usb
power_supplypart and not the ac-power / battery-charger / rtc-backup-bat-charger bits.Depending on the board each of those must be enabled / disabled separately in devicetree as most boards do not use all 4. So in dt each one needs its own child-node of the axp20x node. Another reason for using separate child nodes for each is so that other devicetree nodes can have a power-supply property with a phandle referencing a node representing a single power-supply.
The decision to use a separate devicetree node for each is reflected on the kernel side by each getting its own mfd-cell /
platform_deviceand platform-driver.Cc Bruno Pr?mont <[email protected]>Signed-off-by Hans de Goede <[email protected]>--- drivers/mfd/axp20x.c | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-)drivers/mfd/axp20x.c +25
-1@@ -113,6 +113,30 @@ static struct resource axp20x_pek_resources[] = { }, }; +static struct resource axp20x_usb_power_supply_resources[] = { + { + .name ="VBUS_PLUGIN" , + .start =AXP20X_IRQ_VBUS_PLUGIN , + .end =AXP20X_IRQ_VBUS_PLUGIN , + .flags =IORESOURCE_IRQ , + }, { + .name ="VBUS_REMOVAL" , + .start =AXP20X_IRQ_VBUS_REMOVAL , + .end =AXP20X_IRQ_VBUS_REMOVAL , + .flags =IORESOURCE_IRQ , + }, { + .name ="VBUS_VALID" , + .start =AXP20X_IRQ_VBUS_VALID , + .end =AXP20X_IRQ_VBUS_VALID , + .flags =IORESOURCE_IRQ , + }, { + .name ="VBUS_NOT_VALID" , + .start =AXP20X_IRQ_VBUS_NOT_VALID , + .end =AXP20X_IRQ_VBUS_NOT_VALID , + .flags =IORESOURCE_IRQ , + }, +}; +static struct resource axp22x_pek_resources[] = { { .name ="PEK_DBR" ,@@ -165,7 +189,7 @@ static const struct regmap_config axp20x_regmap_config = { .val_bits = 8, .wr_table = &axp20x_writeable_table, .volatile_table = &axp20x_volatile_table, - .max_register = AXP20X_FG_RES, + .max_register = AXP20X_OCV(15), .cache_type = REGCACHE_RBTREE, };
drivers/mfd/axp20x.c static struct mfd_cell axp20x_cells[] = { · line 396
Quoted 5 lines
drivers/mfd/axp20x.c +2
-0@@ -368,6 +392,12 @@ static struct mfd_cell axp20x_cells[] = { .resources = axp20x_pek_resources, }, { .name = "axp20x-regulator", + }, { + .name = "axp20x-usb-power-supply",
Could we use either "vbus-power-supply" to match the AXP datasheets, or "otg-power-supply" which is slightly more obvious to board owners?
Thanks
ChenYu
Quoted 14 lines
drivers/mfd/axp20x.c +4
-1+ .of_compatible = "x-powers,axp202-usb-power-supply", + .num_resources = + ARRAY_SIZE(axp20x_usb_power_supply_resources), + .resources = axp20x_usb_power_supply_resources, }, }; --2.3.6
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/d/optout.
PATCH 2/8 mfd: axp20x: Add a cell for the usb power_supply part of the axp20x PMICs
Hi,
Quoted 67 lines · Chen-Yu Tsai
Quoted 66 lines · Hans de Goede
Add a cell for the usb
power_supplypart of the axp20x PMICs.Note that this cell is only for the usb
power_supplypart and not the ac-power / battery-charger / rtc-backup-bat-charger bits.Depending on the board each of those must be enabled / disabled separately in devicetree as most boards do not use all 4. So in dt each one needs its own child-node of the axp20x node. Another reason for using separate child nodes for each is so that other devicetree nodes can have a power-supply property with a phandle referencing a node representing a single power-supply.
The decision to use a separate devicetree node for each is reflected on the kernel side by each getting its own mfd-cell /
platform_deviceand platform-driver.Cc Bruno Pr?mont <[email protected]>Signed-off-by Hans de Goede <[email protected]>--- drivers/mfd/axp20x.c | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-)drivers/mfd/axp20x.c +25
-1@@ -113,6 +113,30 @@ static struct resource axp20x_pek_resources[] = { }, }; +static struct resource axp20x_usb_power_supply_resources[] = { + { + .name ="VBUS_PLUGIN" , + .start =AXP20X_IRQ_VBUS_PLUGIN , + .end =AXP20X_IRQ_VBUS_PLUGIN , + .flags =IORESOURCE_IRQ , + }, { + .name ="VBUS_REMOVAL" , + .start =AXP20X_IRQ_VBUS_REMOVAL , + .end =AXP20X_IRQ_VBUS_REMOVAL , + .flags =IORESOURCE_IRQ , + }, { + .name ="VBUS_VALID" , + .start =AXP20X_IRQ_VBUS_VALID , + .end =AXP20X_IRQ_VBUS_VALID , + .flags =IORESOURCE_IRQ , + }, { + .name ="VBUS_NOT_VALID" , + .start =AXP20X_IRQ_VBUS_NOT_VALID , + .end =AXP20X_IRQ_VBUS_NOT_VALID , + .flags =IORESOURCE_IRQ , + }, +}; +static struct resource axp22x_pek_resources[] = { { .name ="PEK_DBR" ,@@ -165,7 +189,7 @@ static const struct regmap_config axp20x_regmap_config = { .val_bits = 8, .wr_table = &axp20x_writeable_table, .volatile_table = &axp20x_volatile_table, - .max_register = AXP20X_FG_RES, + .max_register = AXP20X_OCV(15), .cache_type = REGCACHE_RBTREE, };
Quoted 9 lines
drivers/mfd/axp20x.c static struct mfd_cell axp20x_cells[] = { · line 396
Quoted 6 lines
drivers/mfd/axp20x.c +2
-0@@ -368,6 +392,12 @@ static struct mfd_cell axp20x_cells[] = { .resources = axp20x_pek_resources, }, { .name = "axp20x-regulator", + }, { + .name = "axp20x-usb-power-supply",Could we use either "vbus-power-supply" to match the AXP datasheets, or "otg-power-supply" which is slightly more obvious to board owners?
I do not like the vbus name, since it does not indicate which bus it is, OTOH you are right that is what it is called in the datasheet.
As for using otg, I think that usb is better then.
All in all I believe that the current usb name is best, but if others disagree I'm open to renaming this.
So anyone else have an opinion on what would be a good name for the cell and the compatible ?
Regards,
Hans
PATCH 2/8 mfd: axp20x: Add a cell for the usb power_supply part of the axp20x PMICs
Quoted 13 lines · Hans de Goede
Quoted 9 lines
drivers/mfd/axp20x.c static struct mfd_cell axp20x_cells[] = { · line 396
Quoted 6 lines
drivers/mfd/axp20x.c +2
-0@@ -368,6 +392,12 @@ static struct mfd_cell axp20x_cells[] = { .resources = axp20x_pek_resources, }, { .name = "axp20x-regulator", + }, { + .name = "axp20x-usb-power-supply",Could we use either "vbus-power-supply" to match the AXP datasheets, or "otg-power-supply" which is slightly more obvious to board owners?
I do not like the vbus name, since it does not indicate which bus it is, OTOH you are right that is what it is called in the datasheet.
Quoted 7 lines
As for using otg, I think that usb is better then.
All in all I believe that the current usb name is best, but if others disagree I'm open to renaming this.
So anyone else have an opinion on what would be a good name for the cell and the compatible ?
I usually prefer to use the name mentionned in the datasheet, but if that doesn't make sense, feel free to use an alternative like this one.
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150613/3324ad71/attachment.sig>
PATCH 2/8 mfd: axp20x: Add a cell for the usb power_supply part of the axp20x PMICs
Hello,
Quoted 19 lines · Maxime Ripard
Quoted 18 lines · Hans de Goede
Quoted 9 lines
drivers/mfd/axp20x.c static struct mfd_cell axp20x_cells[] = { · line 396
Quoted 6 lines
drivers/mfd/axp20x.c +2
-0@@ -368,6 +392,12 @@ static struct mfd_cell axp20x_cells[] = { .resources = axp20x_pek_resources, }, { .name = "axp20x-regulator", + }, { + .name = "axp20x-usb-power-supply",Could we use either "vbus-power-supply" to match the AXP datasheets, or "otg-power-supply" which is slightly more obvious to board owners?
I do not like the vbus name, since it does not indicate which bus it is, OTOH you are right that is what it is called in the datasheet.
As for using otg, I think that usb is better then.
All in all I believe that the current usb name is best, but if others disagree I'm open to renaming this.
Quoted 6 lines
Quoted 2 lines
So anyone else have an opinion on what would be a good name for the cell and the compatible ?
I usually prefer to use the name mentionned in the datasheet, but if that doesn't make sense, feel free to use an alternative like this one.
The power source is known as USB power since the reference Allwinner design connects this pin to the USB OTG connector and all known boards that use the AXP copy the design.
If somebody gets creative with the vbus input or there is another manufacturer using AXP with different design it might get problematic naming it usb.
However, either name is pretty much arbitrary and there is no need for the vbus to be connected to a bus connector. You could design a board with two plain power jacks and the AXP would switch between those according to its priority. If this priority is not configurable then I think it would be most descriptive to name the inputs as primary and secondary AC.
The most important part is adding proper documentation so whatever the name the user can understand that this is the part that is called vbus in datasheed and is typically wired to the usb otg port.
I only found very terse doc patch.
It adds a new file without a reference in the main axp20x file. IMHO there should be a reference for the sub-nodes or they should be all in one file. Spreading the text into multitude of files that contain 2 lines of explanation and an example seems counter-productive. The examples can be combined in one.
Another nit is that the doc shows axp202-usb-power-supply compatible while the usb power is available on all AXP regulators for which there are drivers since axp152. IMHO this can be just x-powers,usb-power-supply since it can only appear as subnode of the axp, anyway.
Thanks
Michal
PATCH 2/8 mfd: axp20x: Add a cell for the usb power_supply part of the axp20x PMICs
In reply to Hans de GoedeQuoted 43 lines · Hans de Goede
Add a cell for the usb
power_supplypart of the axp20x PMICs.Note that this cell is only for the usb
power_supplypart and not the ac-power / battery-charger / rtc-backup-bat-charger bits.Depending on the board each of those must be enabled / disabled separately in devicetree as most boards do not use all 4. So in dt each one needs its own child-node of the axp20x node. Another reason for using separate child nodes for each is so that other devicetree nodes can have a power-supply property with a phandle referencing a node representing a single power-supply.
The decision to use a separate devicetree node for each is reflected on the kernel side by each getting its own mfd-cell /
platform_deviceand platform-driver.Cc Bruno Pr?mont <[email protected]>Signed-off-by Hans de Goede <[email protected]>--- drivers/mfd/axp20x.c | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-)drivers/mfd/axp20x.c +13
-0@@ -113,6 +113,30 @@ static struct resource axp20x_pek_resources[] = { }, }; +static struct resource axp20x_usb_power_supply_resources[] = { + { + .name ="VBUS_PLUGIN" , + .start =AXP20X_IRQ_VBUS_PLUGIN , + .end =AXP20X_IRQ_VBUS_PLUGIN , + .flags =IORESOURCE_IRQ , + }, { + .name ="VBUS_REMOVAL" , + .start =AXP20X_IRQ_VBUS_REMOVAL , + .end =AXP20X_IRQ_VBUS_REMOVAL , + .flags =IORESOURCE_IRQ , + }, { + .name ="VBUS_VALID" ,
drivers/mfd/axp20x.c static struct resource axp20x_pek_resources[] = { · line 138
Quoted 10 lines
drivers/mfd/axp20x.c +10
-0+ .start = AXP20X_IRQ_VBUS_VALID, + .end = AXP20X_IRQ_VBUS_VALID, + .flags = IORESOURCE_IRQ, + }, { + .name = "VBUS_NOT_VALID", + .start = AXP20X_IRQ_VBUS_NOT_VALID, + .end = AXP20X_IRQ_VBUS_NOT_VALID, + .flags = IORESOURCE_IRQ, + }, +};
Can you take a look at the DEFINE_RES_* macros ininclude/linux/ioport.h please?
Quoted 13 lines
drivers/mfd/axp20x.c +1
-1static struct resource axp22x_pek_resources[] = { { .name ="PEK_DBR" ,@@ -165,7 +189,7 @@ static const struct regmap_config axp20x_regmap_config = { .val_bits = 8, .wr_table = &axp20x_writeable_table, .volatile_table = &axp20x_volatile_table, - .max_register = AXP20X_FG_RES, + .max_register = AXP20X_OCV(15), .cache_type = REGCACHE_RBTREE, };
drivers/mfd/axp20x.c static struct mfd_cell axp20x_cells[] = { · line 399
Quoted 8 lines
drivers/mfd/axp20x.c +5
-0@@ -368,6 +392,12 @@ static struct mfd_cell axp20x_cells[] = { .resources = axp20x_pek_resources, }, { .name = "axp20x-regulator", + }, { + .name = "axp20x-usb-power-supply", + .of_compatible = "x-powers,axp202-usb-power-supply", + .num_resources = + ARRAY_SIZE(axp20x_usb_power_supply_resources),
This wrap is only necessary due to the extreme tabbing used to line up the '='. Please do something about that instead.
Quoted 4 lines
drivers/mfd/axp20x.c +1
-0+ .resources = axp20x_usb_power_supply_resources, }, };
Signature · 4 lines
Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH 2/8 mfd: axp20x: Add a cell for the usb power_supply part of the axp20x PMICs
In reply to Hans de GoedeQuoted 58 lines · Hans de Goede
Add a cell for the usb
power_supplypart of the axp20x PMICs.Note that this cell is only for the usb
power_supplypart and not the ac-power / battery-charger / rtc-backup-bat-charger bits.Depending on the board each of those must be enabled / disabled separately in devicetree as most boards do not use all 4. So in dt each one needs its own child-node of the axp20x node. Another reason for using separate child nodes for each is so that other devicetree nodes can have a power-supply property with a phandle referencing a node representing a single power-supply.
The decision to use a separate devicetree node for each is reflected on the kernel side by each getting its own mfd-cell /
platform_deviceand platform-driver.Cc Bruno Pr?mont <[email protected]>Signed-off-by Hans de Goede <[email protected]>--- drivers/mfd/axp20x.c | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-)drivers/mfd/axp20x.c +24
-0@@ -113,6 +113,30 @@ static struct resource axp20x_pek_resources[] = { }, }; +static struct resource axp20x_usb_power_supply_resources[] = { + { + .name ="VBUS_PLUGIN" , + .start =AXP20X_IRQ_VBUS_PLUGIN , + .end =AXP20X_IRQ_VBUS_PLUGIN , + .flags =IORESOURCE_IRQ , + }, { + .name ="VBUS_REMOVAL" , + .start =AXP20X_IRQ_VBUS_REMOVAL , + .end =AXP20X_IRQ_VBUS_REMOVAL , + .flags =IORESOURCE_IRQ , + }, { + .name ="VBUS_VALID" , + .start =AXP20X_IRQ_VBUS_VALID , + .end =AXP20X_IRQ_VBUS_VALID , + .flags =IORESOURCE_IRQ , + }, { + .name ="VBUS_NOT_VALID" , + .start =AXP20X_IRQ_VBUS_NOT_VALID , + .end =AXP20X_IRQ_VBUS_NOT_VALID , + .flags =IORESOURCE_IRQ , + }, +}; +static struct resource axp22x_pek_resources[] = { { .name ="PEK_DBR" ,
drivers/mfd/axp20x.c static const struct regmap_config axp20x_regmap_config = { · line 192
Quoted 5 lines
drivers/mfd/axp20x.c +1
-1@@ -165,7 +189,7 @@ static const struct regmap_config axp20x_regmap_config = { .val_bits = 8, .wr_table = &axp20x_writeable_table, .volatile_table = &axp20x_volatile_table, - .max_register = AXP20X_FG_RES, + .max_register = AXP20X_OCV(15),
Please define 15, as MAX_WHATEVER_REG or something.
Quoted 16 lines
drivers/mfd/axp20x.c +6
-0.cache_type = REGCACHE_RBTREE, };@@ -368,6 +392,12 @@ static struct mfd_cell axp20x_cells[] = { .resources = axp20x_pek_resources, }, { .name = "axp20x-regulator", + }, { + .name = "axp20x-usb-power-supply", + .of_compatible = "x-powers,axp202-usb-power-supply", + .num_resources = + ARRAY_SIZE(axp20x_usb_power_supply_resources), + .resources = axp20x_usb_power_supply_resources, }, };
Signature · 4 lines
Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH 3/8 power: Add devm_power_supply_get_by_phandle() helper function
In reply to Hans de GoedeThis commit adds a resource-managed version of the power_supply_get_by_phandle() function.
--- drivers/power/power_supply_core.c | 39 +++++++++++++++++++++++++++++++++++++++ include/linux/power_supply.h | 5 +++++ 2 files changed, 44 insertions(+)
drivers/power/power_supply_core.c +39 -0
@@ -420,6 +420,45 @@ struct power_supply *power_supply_get_by_phandle(struct device_node *np,return psy; }EXPORT_SYMBOL_GPL (power_supply_get_by_phandle); + +static void devm_power_supply_put (struct device *dev,void *res) +{ +struct power_supply **psy = res; + +power_supply_put (*psy); +} + +/** +* devm_power_supply_get_by_phandle() - Resource managed version of +* power_supply_get_by_phandle() +* @dev: Pointer to device holding phandle property +* @phandle_name: Name of property holding a power supply phandle +* +* Return: On success returns a reference to a power supply with +* matching name equals to value under @property, NULL or ERR_PTR otherwise. +*/ +struct power_supply *devm_power_supply_get_by_phandle (struct device *dev, +const char *property) +{ +struct power_supply **ptr, *psy; + +if (!dev->of_node) +return ERR_PTR (-ENODEV ); + + ptr =devres_alloc (devm_power_supply_put,sizeof (*ptr),GFP_KERNEL ); +if (!ptr) +return ERR_PTR (-ENOMEM ); + + psy =power_supply_get_by_phandle (dev->of_node, property); +if (IS_ERR_OR_NULL (psy)) { +devres_free (ptr); + }else { + *ptr = psy; +devres_add (dev, ptr); + } +return psy; +} +EXPORT_SYMBOL_GPL (devm_power_supply_get_by_phandle);#endif /* CONFIG_OF */ int power_supply_get_property(struct power_supply *psy,
include/linux/power_supply.h +5 -0
@@ -286,10 +286,15 @@ extern void power_supply_put(struct power_supply *psy);#ifdef CONFIG_OF extern struct power_supply *power_supply_get_by_phandle (struct device_node *np,const char *property); +extern struct power_supply *devm_power_supply_get_by_phandle ( +struct device *dev,const char *property);#else /* !CONFIG_OF */ static inline struct power_supply *power_supply_get_by_phandle (struct device_node *np,const char *property) {return NULL ; } +static inline struct power_supply * +devm_power_supply_get_by_phandle (struct device *dev,const char *property) +{return NULL ; }#endif /* CONFIG_OF */ extern void power_supply_changed (struct power_supply *psy);extern int power_supply_am_i_supplied (struct power_supply *psy);
Signature · 1 line
2.3.6
Sebastian Reichel
maintainerPATCH 3/8 power: Add devm_power_supply_get_by_phandle() helper function
Hi,
Quoted 2 lines · Hans de Goede
This commit adds a resource-managed version of the
power_supply_get_by_phandle()function.
Thanks, queued.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150610/66ec6051/attachment.sig>
PATCH 4/8 power: Add an axp20x-usb-power driver
In reply to Hans de GoedeThis adds a driver for the usb power_supply bits of the axp20x PMICs.
I initially started writing my own driver, before coming aware of Bruno Pr?mont's excellent earlier RFC with a driver for this.
My driver was lacking CURRENT_MAX and VOLTAGE_MIN support Bruno's drvier has, so I've copied the code for those from his driver.
Note that the AC-power-supply and battery charger bits will need separate drivers. Each one needs its own devictree child-node so that other devicetree nodes can reference the right power-supply, and thus each one will get its own mfd-cell / platform_device and platform-driver.
--- .../bindings/power_supply/axp20x_usb_power.txt | 34 +++ drivers/power/Kconfig | 7 + drivers/power/Makefile | 1 + drivers/power/axp20x_usb_power.c | 241 +++++++++++++++++++++ include/linux/mfd/axp20x.h | 24 ++ 5 files changed, 307 insertions(+) create mode 100644 Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt create mode 100644 drivers/power/axp20x_usb_power.c
Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt new file +34 -0
@@ -0,0 +1,34 @@ +AXP20x USB power supply + +Required Properties: +-compatible: "x-powers,axp202-usb-power-supply" + +This node is a subnode of the axp20x PMIC. + +Example: + +axp209: pmic at 34 { + compatible = "x-powers,axp209"; + reg = <0x34>; + interrupt-parent = <&nmi_intc>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #interrupt-cells = <1>; + + regulators { + x-powers,dcdc-freq = <1500>; + + vdd_cpu: dcdc2 { + regulator-always-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1450000>; + regulator-name = "vdd-cpu"; + }; + + ... + }; + + usb_power_supply: usb_power_supply { + compatible = "x-powers,axp202-usb-power-supply"; + }; +};
drivers/power/Kconfig +7 -0
@@ -439,6 +439,13 @@ config BATTERY_RT5033 The fuelgauge calculates and determines the battery state of charge according to battery open circuit voltage. +config AXP20X_POWER + tristate "AXP20x power supply driver" + depends on MFD_AXP20X + help + This driver provides support for the power supply features of + AXP20x PMIC. + source "drivers/power/reset/Kconfig" endif # POWER_SUPPLY
drivers/power/Makefile +1 -0
@@ -9,6 +9,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o obj-$(CONFIG_PDA_POWER) += pda_power.o obj-$(CONFIG_APM_POWER) += apm_power.o +obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o obj-$(CONFIG_MAX8925_POWER) += max8925_power.o obj-$(CONFIG_WM831X_BACKUP) += wm831x_backup.o obj-$(CONFIG_WM831X_POWER) += wm831x_power.o
drivers/power/axp20x_usb_power.c new file +241 -0
241 lines not on this page · raw message
include/linux/mfd/axp20x.h +24 -0
@@ -11,6 +11,8 @@#ifndef __LINUX_MFD_AXP20X_H#define __LINUX_MFD_AXP20X_H +#include <linux/regmap.h> +enum {AXP202_ID =0 , AXP209_ID,
@@ -366,4 +368,26 @@ struct axp20x_fg_pdata { int thermistor_curve[MAX_THERM_CURVE_SIZE][2]; }; +/* generic helper function for reading 9-16 bit wide regs */ +static inline int axp20x_read_16bit (struct regmap *regmap, +unsigned int reg,unsigned int width) +{ +unsigned int v, raw; +int r; + + r =regmap_read (regmap, reg, &v); +if (r) +return r; + + raw = v << (width -8 ); + + r =regmap_read (regmap, reg +1 , &v); +if (r) +return r; + + raw |= v; + +return raw; +} +#endif /* __LINUX_MFD_AXP20X_H */
Signature · 1 line
2.3.6
PATCH 4/8 power: Add an axp20x-usb-power driver
Quoted 13 lines · Hans de Goede
This adds a driver for the usb
power_supplybits of the axp20x PMICs.I initially started writing my own driver, before coming aware of Bruno Pr?mont's excellent earlier RFC with a driver for this.
My driver was lacking
CURRENT_MAXandVOLTAGE_MINsupport Bruno's drvier has, so I've copied the code for those from his driver.Note that the AC-power-supply and battery charger bits will need separate drivers. Each one needs its own devictree child-node so that other devicetree nodes can reference the right power-supply, and thus each one will get its own mfd-cell /
platform_deviceand platform-driver.
Quoted 4 lines
Cc Bruno Pr?mont <[email protected]>Signed-off-by Hans de Goede <[email protected]>--- .../bindings/power_supply/axp20x_usb_power.txt | 34 +++
This needs to be submitted in a seperate patch.
Quoted 7 lines
drivers/power/Kconfig | 7 + drivers/power/Makefile | 1 + drivers/power/axp20x_usb_power.c | 241 +++++++++++++++++++++ include/linux/mfd/axp20x.h | 24 ++ 5 files changed, 307 insertions(+) create mode 100644 Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt create mode 100644 drivers/power/axp20x_usb_power.c
[...]
Quoted 14 lines
include/linux/mfd/axp20x.h +2
-0@@ -11,6 +11,8 @@#ifndef __LINUX_MFD_AXP20X_H#define __LINUX_MFD_AXP20X_H +#include <linux/regmap.h> +enum {AXP202_ID =0 , AXP209_ID,
include/linux/mfd/axp20x.h struct axp20x_fg_pdata { · line 372
Quoted 5 lines
include/linux/mfd/axp20x.h +2
-0@@ -366,4 +368,26 @@ struct axp20x_fg_pdata {int thermistor_curve[MAX_THERM_CURVE_SIZE ][2 ]; }; +/* generic helper function for reading 9-16 bit wide regs */ +static inline int axp20x_read_16bit(struct regmap *regmap,
This is only used twice and only in one file.
Do you know of any other uses of this call that will be upstreamed shortly?
include/linux/mfd/axp20x.h struct axp20x_fg_pdata { · line 373
Quoted 1 line
include/linux/mfd/axp20x.h +1
-0+ unsigned int reg, unsigned int width)
The function name is a bit misleading.
include/linux/mfd/axp20x.h struct axp20x_fg_pdata { · line 376
Quoted 3 lines
include/linux/mfd/axp20x.h +3
-0+{ +unsigned int v, raw; +int r;
'v' and 'r' are not good variable names.
include/linux/mfd/axp20x.h struct axp20x_fg_pdata { · line 382
Quoted 5 lines
include/linux/mfd/axp20x.h +5
-0+ r =regmap_read (regmap, reg, &v); +if (r) +return r; + + raw = v << (width -8 );
So 'reg' is expected to be top end loaded?
E.g A value of say 0x0101 (257) in 9 bits will look like this:
reg reg + 1
1000 0000b 0000 0001b
Quoted 10 lines
include/linux/mfd/axp20x.h +9
-0+ r =regmap_read (regmap, reg +1 , &v); +if (r) +return r; + + raw |= v; + + return raw; +} +#endif /* __LINUX_MFD_AXP20X_H */
Signature · 4 lines
Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH 4/8 power: Add an axp20x-usb-power driver
Hi,
Thanks for the quick review I'll do a v2 addressing your concerns soonish.
Quoted 15 lines · Lee Jones
Quoted 13 lines · Hans de Goede
This adds a driver for the usb
power_supplybits of the axp20x PMICs.I initially started writing my own driver, before coming aware of Bruno Pr?mont's excellent earlier RFC with a driver for this.
My driver was lacking
CURRENT_MAXandVOLTAGE_MINsupport Bruno's drvier has, so I've copied the code for those from his driver.Note that the AC-power-supply and battery charger bits will need separate drivers. Each one needs its own devictree child-node so that other devicetree nodes can reference the right power-supply, and thus each one will get its own mfd-cell /
platform_deviceand platform-driver.
Quoted 6 lines
Quoted 4 lines
Cc Bruno Pr?mont <[email protected]>Signed-off-by Hans de Goede <[email protected]>--- .../bindings/power_supply/axp20x_usb_power.txt | 34 +++This needs to be submitted in a seperate patch.
Ok.
Quoted 28 lines
Quoted 8 lines
drivers/power/Kconfig | 7 + drivers/power/Makefile | 1 + drivers/power/axp20x_usb_power.c | 241 +++++++++++++++++++++ include/linux/mfd/axp20x.h | 24 ++ 5 files changed, 307 insertions(+)create mode 100644
Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txtcreate mode 100644drivers/power/axp20x_usb_power.c[...]
Quoted 17 lines
include/linux/mfd/axp20x.h +2
-0@@ -11,6 +11,8 @@#ifndef __LINUX_MFD_AXP20X_H#define __LINUX_MFD_AXP20X_H +#include <linux/regmap.h> +enum {AXP202_ID =0 , AXP209_ID,@@ -366,4 +368,26 @@ struct axp20x_fg_pdata {int thermistor_curve[MAX_THERM_CURVE_SIZE ][2 ]; };
Quoted 7 lines
include/linux/mfd/axp20x.h struct axp20x_fg_pdata { · line 372
Quoted 2 lines
include/linux/mfd/axp20x.h +2
-0+/* generic helper function for reading 9-16 bit wide regs */ +static inline int axp20x_read_16bit(struct regmap *regmap,This is only used twice and only in one file.
Do you know of any other uses of this call that will be upstreamed shortly?
Yes I plan to write drivers for the other 3 power_supply class cells (ac-power, battery-charger, rtc-bat-charger) in the axp209, and most of those need the same helper which I why I put it here.
Quoted 4 lines
include/linux/mfd/axp20x.h struct axp20x_fg_pdata { · line 373
Quoted 2 lines
include/linux/mfd/axp20x.h +1
-0+ unsigned int reg, unsigned int width)The function name is a bit misleading.
How about: axp20x_read_multibyte_reg ?
Quoted 15 lines
include/linux/mfd/axp20x.h struct axp20x_fg_pdata { · line 376
Quoted 4 lines
include/linux/mfd/axp20x.h +3
-0+{ +unsigned int v, raw; +int r;'v' and 'r' are not good variable names.
include/linux/mfd/axp20x.h struct axp20x_fg_pdata { · line 382
Quoted 5 lines
include/linux/mfd/axp20x.h +5
-0+ r =regmap_read (regmap, reg, &v); +if (r) +return r; + + raw = v << (width -8 );So 'reg' is expected to be top end loaded?
Quoted 4 lines
E.g A value of say
0x0101(257) in 9 bits will look like this:reg reg + 1
1000 0000b 0000 0001b
Yes, I guess this was done so that you can get all the 8 msb-s in a single read if you do not care about the lsb-s.
Quoted 12 lines
include/linux/mfd/axp20x.h struct axp20x_fg_pdata { · line 393
Quoted 11 lines
include/linux/mfd/axp20x.h +9
-0+ r =regmap_read (regmap, reg +1 , &v); +if (r) +return r; + + raw |= v; + + return raw; +} +#endif /* __LINUX_MFD_AXP20X_H */
Regards,
Hans
PATCH 4/8 power: Add an axp20x-usb-power driver
Quoted 62 lines · Hans de Goede
Hi,
Thanks for the quick review I'll do a v2 addressing your concerns soonish.
Quoted 15 lines · Lee Jones
Quoted 13 lines · Hans de Goede
This adds a driver for the usb
power_supplybits of the axp20x PMICs.I initially started writing my own driver, before coming aware of Bruno Pr?mont's excellent earlier RFC with a driver for this.
My driver was lacking
CURRENT_MAXandVOLTAGE_MINsupport Bruno's drvier has, so I've copied the code for those from his driver.Note that the AC-power-supply and battery charger bits will need separate drivers. Each one needs its own devictree child-node so that other devicetree nodes can reference the right power-supply, and thus each one will get its own mfd-cell /
platform_deviceand platform-driver.Quoted 6 lines
Quoted 4 lines
Cc Bruno Pr?mont <[email protected]>Signed-off-by Hans de Goede <[email protected]>--- .../bindings/power_supply/axp20x_usb_power.txt | 34 +++This needs to be submitted in a seperate patch.
Ok.
Quoted 33 lines
Quoted 8 lines
drivers/power/Kconfig | 7 + drivers/power/Makefile | 1 + drivers/power/axp20x_usb_power.c | 241 +++++++++++++++++++++ include/linux/mfd/axp20x.h | 24 ++ 5 files changed, 307 insertions(+) create mode 100644 Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt create mode 100644 drivers/power/axp20x_usb_power.c[...]
Quoted 14 lines
include/linux/mfd/axp20x.h +2
-0@@ -11,6 +11,8 @@#ifndef __LINUX_MFD_AXP20X_H#define __LINUX_MFD_AXP20X_H +#include <linux/regmap.h> +enum {AXP202_ID =0 , AXP209_ID,include/linux/mfd/axp20x.h struct axp20x_fg_pdata { · line 372
Quoted 5 lines
include/linux/mfd/axp20x.h +2
-0@@ -366,4 +368,26 @@ struct axp20x_fg_pdata {int thermistor_curve[MAX_THERM_CURVE_SIZE ][2 ]; }; +/* generic helper function for reading 9-16 bit wide regs */ +static inline int axp20x_read_16bit(struct regmap *regmap,This is only used twice and only in one file.
Quoted 6 lines
Quoted 2 lines
Do you know of any other uses of this call that will be upstreamed shortly?
Yes I plan to write drivers for the other 3
power_supplyclass cells (ac-power, battery-charger, rtc-bat-charger) in the axp209, and most of those need the same helper which I why I put it here.
Okay.
Quoted 5 lines
Quoted 3 lines
include/linux/mfd/axp20x.h struct axp20x_fg_pdata { · line 373
Quoted 1 line
include/linux/mfd/axp20x.h +1
-0+ unsigned int reg, unsigned int width)The function name is a bit misleading.
How about:
axp20x_read_multibyte_reg?
axp20x_read_variable_width() ?
Quoted 14 lines
Quoted 14 lines
include/linux/mfd/axp20x.h struct axp20x_fg_pdata { · line 376
Quoted 3 lines
include/linux/mfd/axp20x.h +3
-0+{ +unsigned int v, raw; +int r;'v' and 'r' are not good variable names.
include/linux/mfd/axp20x.h struct axp20x_fg_pdata { · line 382
Quoted 5 lines
include/linux/mfd/axp20x.h +5
-0+ r =regmap_read (regmap, reg, &v); +if (r) +return r; + + raw = v << (width -8 );So 'reg' is expected to be top end loaded?
Quoted 7 lines
Quoted 4 lines
E.g A value of say
0x0101(257) in 9 bits will look like this:reg reg + 1
1000 0000b 0000 0001bYes, I guess this was done so that you can get all the 8 msb-s in a single read if you do not care about the lsb-s.
Odd, but okay.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
include/linux/mfd/axp20x.h +9
-0+ r =regmap_read (regmap, reg +1 , &v); +if (r) +return r; + + raw |= v; + + return raw; +} +#endif /* __LINUX_MFD_AXP20X_H */
Signature · 4 lines
Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH 5/8 phy-sun4i-usb: Add support for monitoring vbus via a power-supply
In reply to Hans de GoedeOn some boards there is no vbus_det gpio pin, instead vbus-detection for otg can be done via the pmic.
This commit adds support for monitoring vbus_det via the power_supply exported by the pmic, enabling support for otg on these boards.
--- .../devicetree/bindings/phy/sun4i-usb-phy.txt | 1 + drivers/phy/phy-sun4i-usb.c | 68 +++++++++++++++++++--- 2 files changed, 62 insertions(+), 7 deletions(-)
Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt +1 -0
@@ -29,6 +29,7 @@ Required properties: Optional properties: - usb0_id_det-gpios : gpio phandle for reading the otg id pin value - usb0_vbus_det-gpios : gpio phandle for detecting the presence of usb0 vbus +- usb0_vbus_power-supply: power-supply phandle for usb0 vbus presence detect - usb0_vbus-supply : regulator phandle for controller usb0 vbus - usb1_vbus-supply : regulator phandle for controller usb1 vbus - usb2_vbus-supply : regulator phandle for controller usb2 vbus
drivers/phy/phy-sun4i-usb.c +61 -7
117 lines not on this page · raw message
Signature · 1 line
2.3.6
PATCH 6/8 ARM: dts: axp209: Add usb_power_supply child node to the ax209 node
In reply to Hans de GoedeAdd a node representing the usb power supply part of the axp209 pmic, note that the usb power supply and the (to be added later) ac power supply will each have their own child-node, so that they can be separately specified as power-supply for other nodes using a power-supply property with a phandle pointing to the right axp209 child-node.
--- arch/arm/boot/dts/axp209.dtsi | 5 +++++ 1 file changed, 5 insertions(+)
arch/arm/boot/dts/axp209.dtsi +5 -0
@@ -89,4 +89,9 @@ regulator-name = "ldo5"; }; }; + + usb_power_supply: usb_power_supply { + compatible = "x-powers,axp202-usb-power-supply"; + status = "disabled"; + }; };
Signature · 1 line
2.3.6
PATCH 6/8 ARM: dts: axp209: Add usb_power_supply child node to the ax209 node
Hi Hans,
Quoted 16 lines · Hans de Goede
Add a node representing the usb power supply part of the axp209 pmic, note that the usb power supply and the (to be added later) ac power supply will each have their own child-node, so that they can be separately specified as power-supply for other nodes using a power-supply property with a phandle pointing to the right axp209 child-node.
Signed-off-by Hans de Goede <[email protected]>--- arch/arm/boot/dts/axp209.dtsi | 5 +++++ 1 file changed, 5 insertions(+)arch/arm/boot/dts/axp209.dtsi +0
-0
arch/arm/boot/dts/axp209.dtsi line 95
Quoted 7 lines
arch/arm/boot/dts/axp209.dtsi +4
-0@@ -89,4 +89,9 @@ regulator-name = "ldo5"; }; }; + + usb_power_supply: usb_power_supply { + compatible = "x-powers,axp202-usb-power-supply"; + status = "disabled";
Is there any reason to have this disabled by default? AFAIK this is not something configurable in hardware, and the driver just gives readouts and status updates.
ChenYu
Quoted 9 lines
arch/arm/boot/dts/axp209.dtsi +1
-1+ }; }; --2.3.6
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/d/optout.
PATCH 6/8 ARM: dts: axp209: Add usb_power_supply child node to the ax209 node
Hi ChenYu,
Quoted 14 lines · On Fri, 31 Jul 2015 13:31:53 +0800 Chen-Yu Tsai wrote:
Hi Hans,
Quoted 11 lines · Hans de Goede
Add a node representing the usb power supply part of the axp209 pmic, note that the usb power supply and the (to be added later) ac power supply will each have their own child-node, so that they can be separately specified as power-supply for other nodes using a power-supply property with a phandle pointing to the right axp209 child-node.
Signed-off-by Hans de Goede <[email protected]>--- arch/arm/boot/dts/axp209.dtsi | 5 +++++ 1 file changed, 5 insertions(+)
Quoted 16 lines
arch/arm/boot/dts/axp209.dtsi line 95
Quoted 12 lines
arch/arm/boot/dts/axp209.dtsi +4
-0@@ -89,4 +89,9 @@ regulator-name = "ldo5"; }; }; + + usb_power_supply: usb_power_supply { + compatible = "x-powers,axp202-usb-power-supply"; + status = "disabled";Is there any reason to have this disabled by default? AFAIK this is not something configurable in hardware, and the driver just gives readouts and status updates.
There are some devices that only have 'AC-IN' instead of usb/otg power (set-top boxes) so having the devices tell what power sources they have makes sense (otherwise those that have ac-in instead of otg would have to disable usb_power_supply) and avoids confusion by explicitly stating presence in device dts.
NB: I should hopefully get my battery supply driver ported this WE, ac-in/rtc are done, this WE. I'm going to default-off for them as well (note that for some extra details should be provided in dts).
Bruno
Quoted 6 lines
ChenYu
Quoted 4 lines
arch/arm/boot/dts/axp209.dtsi +1
-1+ }; }; --2.3.6
PATCH 6/8 ARM: dts: axp209: Add usb_power_supply child node to the ax209 node
Quoted 34 lines · Bruno Pr?mont
Hi ChenYu,
Quoted 14 lines · On Fri, 31 Jul 2015 13:31:53 +0800 Chen-Yu Tsai wrote:
Hi Hans,
Quoted 11 lines · Hans de Goede
Add a node representing the usb power supply part of the axp209 pmic, note that the usb power supply and the (to be added later) ac power supply will each have their own child-node, so that they can be separately specified as power-supply for other nodes using a power-supply property with a phandle pointing to the right axp209 child-node.
Signed-off-by Hans de Goede <[email protected]>--- arch/arm/boot/dts/axp209.dtsi | 5 +++++ 1 file changed, 5 insertions(+)Quoted 16 lines
arch/arm/boot/dts/axp209.dtsi line 95
Quoted 12 lines
arch/arm/boot/dts/axp209.dtsi +4
-0@@ -89,4 +89,9 @@ regulator-name = "ldo5"; }; }; + + usb_power_supply: usb_power_supply { + compatible = "x-powers,axp202-usb-power-supply"; + status = "disabled";Is there any reason to have this disabled by default? AFAIK this is not something configurable in hardware, and the driver just gives readouts and status updates.
Quoted 5 lines
There are some devices that only have 'AC-IN' instead of usb/otg power (set-top boxes) so having the devices tell what power sources they have makes sense (otherwise those that have ac-in instead of otg would have to disable
usb_power_supply) and avoids confusion by explicitly stating presence in device dts.
That's true. But this is a bit of hardware inside the AXP. If it's power isn't routed, it should report it, shouldn't it?
And normal users would probably expect to read the input voltage/current/status through sysfs (or maybe hwmon?), instead of not finding the device and having to look through the DTS.
If you're using a distro, you might not have the kernel sources around, and digging through the in-system device tree isn't that straightforward if you don't know where to look.
Quoted 3 lines
NB: I should hopefully get my battery supply driver ported this WE, ac-in/rtc are done, this WE. I'm going to default-off for them as well (note that for some extra details should be provided in dts).
I'm guessing we won't be using the axp288 one?
Thanks
ChenYu
Quoted 8 lines
Bruno
Quoted 6 lines
ChenYu
Quoted 4 lines
arch/arm/boot/dts/axp209.dtsi +1
-1+ }; }; --2.3.6
PATCH 6/8 ARM: dts: axp209: Add usb_power_supply child node to the ax209 node
Quoted 35 lines · On Fri, 31 Jul 2015 14:14:28 +0800 Chen-Yu Tsai wrote:
Quoted 34 lines · Bruno Pr?mont
Hi ChenYu,
Quoted 30 lines · On Fri, 31 Jul 2015 13:31:53 +0800 Chen-Yu Tsai wrote:
Hi Hans,
Quoted 16 lines · Hans de Goede
Add a node representing the usb power supply part of the axp209 pmic, note that the usb power supply and the (to be added later) ac power supply will each have their own child-node, so that they can be separately specified as power-supply for other nodes using a power-supply property with a phandle pointing to the right axp209 child-node.
Signed-off-by Hans de Goede <[email protected]>--- arch/arm/boot/dts/axp209.dtsi | 5 +++++ 1 file changed, 5 insertions(+)arch/arm/boot/dts/axp209.dtsi +0
-0arch/arm/boot/dts/axp209.dtsi line 95
Quoted 7 lines
arch/arm/boot/dts/axp209.dtsi +4
-0@@ -89,4 +89,9 @@ regulator-name = "ldo5"; }; }; + + usb_power_supply: usb_power_supply { + compatible = "x-powers,axp202-usb-power-supply"; + status = "disabled";Is there any reason to have this disabled by default? AFAIK this is not something configurable in hardware, and the driver just gives readouts and status updates.
Quoted 8 lines
Quoted 5 lines
There are some devices that only have 'AC-IN' instead of usb/otg power (set-top boxes) so having the devices tell what power sources they have makes sense (otherwise those that have ac-in instead of otg would have to disable
usb_power_supply) and avoids confusion by explicitly stating presence in device dts.That's true. But this is a bit of hardware inside the AXP. If it's power isn't routed, it should report it, shouldn't it?
If the device does not use the input there are two cases:
- ac-in and usb/otg in short-circuited (there is a bit in AXP registers to provide this indication)
- the unused one is just not connected/connectable
In either case the voltage of the unused/unusable branch is not really useful, nor is it useful to have it show up in sysfs.
Quoted 4 lines
And normal users would probably expect to read the input voltage/current/status through sysfs (or maybe hwmon?), instead of not finding the device and having to look through the DTS.
Only those supplies effectively present (in-use or with connectors to eventually use them) should be visible in sysfs.
Having more of them will just confuse the users, they would be searching how they can connect the supply while there is no means to do so except soldering to the tiny AXP pins.
hwmon makes more sense for output voltages of the AXP or temperature of AXP chip itself, not so much for the input side if that side is covered by power_supply devices (otherwise the information is being duplicated and if so should only be via power_supply class, not individual drivers).
Quoted 3 lines
If you're using a distro, you might not have the kernel sources around, and digging through the in-system device tree isn't that straightforward if you don't know where to look.
If the dts is incomplete that's another issue.
Quoted 5 lines
Quoted 3 lines
NB: I should hopefully get my battery supply driver ported this WE, ac-in/rtc are done, this WE. I'm going to default-off for them as well (note that for some extra details should be provided in dts).
I'm guessing we won't be using the axp288 one?
In a first step I won't be using it.
There are a few reasons for that:
- axp288 is based on ACPI/platform to provide configuration information instead of dts
- it makes extensive use of OCV and registers that are possibly present on axp20x but undocumented there.
Bruno
PATCH 6/8 ARM: dts: axp209: Add usb_power_supply child node to the ax209 node
Quoted 11 lines · Bruno Pr?mont
Quoted 5 lines
Quoted 3 lines
NB: I should hopefully get my battery supply driver ported this WE, ac-in/rtc are done, this WE. I'm going to default-off for them as well (note that for some extra details should be provided in dts).
I'm guessing we won't be using the axp288 one?
In a first step I won't be using it.
There are a few reasons for that:
- axp288 is based on ACPI/platform to provide configuration information instead of dts
That's not an issue. You have an API to handle lookup in both DT and ACPI (the fwnode_* stuff).
Quoted 2 lines
- it makes extensive use of OCV and registers that are possibly present on axp20x but undocumented there.
That will be more problematic. Still I don't see why we wouldn't use a similar setup to what they did.
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150731/796bb5e1/attachment.sig>
PATCH 6/8 ARM: dts: axp209: Add usb_power_supply child node to the ax209 node
In reply to Bruno PrémontHi,
Quoted 45 lines · Bruno Pr?mont
Quoted 35 lines · On Fri, 31 Jul 2015 14:14:28 +0800 Chen-Yu Tsai wrote:
Quoted 34 lines · Bruno Pr?mont
Hi ChenYu,
Quoted 30 lines · On Fri, 31 Jul 2015 13:31:53 +0800 Chen-Yu Tsai wrote:
Hi Hans,
Quoted 16 lines · Hans de Goede
Add a node representing the usb power supply part of the axp209 pmic, note that the usb power supply and the (to be added later) ac power supply will each have their own child-node, so that they can be separately specified as power-supply for other nodes using a power-supply property with a phandle pointing to the right axp209 child-node.
Signed-off-by Hans de Goede <[email protected]>--- arch/arm/boot/dts/axp209.dtsi | 5 +++++ 1 file changed, 5 insertions(+)arch/arm/boot/dts/axp209.dtsi +0
-0arch/arm/boot/dts/axp209.dtsi line 95
Quoted 7 lines
arch/arm/boot/dts/axp209.dtsi +4
-0@@ -89,4 +89,9 @@ regulator-name = "ldo5"; }; }; + + usb_power_supply: usb_power_supply { + compatible = "x-powers,axp202-usb-power-supply"; + status = "disabled";Is there any reason to have this disabled by default? AFAIK this is not something configurable in hardware, and the driver just gives readouts and status updates.
Quoted 8 lines
Quoted 5 lines
There are some devices that only have 'AC-IN' instead of usb/otg power (set-top boxes) so having the devices tell what power sources they have makes sense (otherwise those that have ac-in instead of otg would have to disable
usb_power_supply) and avoids confusion by explicitly stating presence in device dts.That's true. But this is a bit of hardware inside the AXP. If it's power isn't routed, it should report it, shouldn't it?
Quoted 7 lines
If the device does not use the input there are two cases:
- ac-in and usb/otg in short-circuited (there is a bit in AXP registers to provide this indication)
- the unused one is just not connected/connectableIn either case the voltage of the unused/unusable branch is not really useful, nor is it useful to have it show up in sysfs.
Exactly my thinking on this, +1 .
Quoted 10 lines
Quoted 4 lines
And normal users would probably expect to read the input voltage/current/status through sysfs (or maybe hwmon?), instead of not finding the device and having to look through the DTS.
Only those supplies effectively present (in-use or with connectors to eventually use them) should be visible in sysfs.
Having more of them will just confuse the users, they would be searching how they can connect the supply while there is no means to do so except soldering to the tiny AXP pins.
+1
Regards,
Hans
PATCH 6/8 ARM: dts: axp209: Add usb_power_supply child node to the ax209 node
Quoted 79 lines · Hans de Goede
Hi,
Quoted 58 lines · Bruno Pr?mont
Quoted 52 lines · On Fri, 31 Jul 2015 14:14:28 +0800 Chen-Yu Tsai wrote:
Quoted 43 lines · Bruno Pr?mont
Hi ChenYu,
Quoted 29 lines · On Fri, 31 Jul 2015 13:31:53 +0800 Chen-Yu Tsai wrote:
Hi Hans,
Quoted 25 lines · Hans de Goede
Add a node representing the usb power supply part of the axp209 pmic, note
that the usb power supply and the (to be added later) ac power supply will
each have their own child-node, so that they can be separately specified
as power-supply for other nodes using a power-supply property with a phandle pointing to the right axp209 child-node.Signed-off-by Hans de Goede <[email protected]>--- arch/arm/boot/dts/axp209.dtsi | 5 +++++ 1 file changed, 5 insertions(+)arch/arm/boot/dts/axp209.dtsi +1
-0@@ -89,4 +89,9 @@ regulator-name = "ldo5"; }; }; +Quoted 8 lines
arch/arm/boot/dts/axp209.dtsi line 95
Quoted 3 lines
arch/arm/boot/dts/axp209.dtsi +3
-0+ usb_power_supply: usb_power_supply { + compatible = "x-powers,axp202-usb-power-supply"; + status = "disabled";Is there any reason to have this disabled by default? AFAIK this is not something configurable in hardware, and the driver just gives readouts and status updates.
Quoted 5 lines
There are some devices that only have 'AC-IN' instead of usb/otg power (set-top boxes) so having the devices tell what power sources they have makes sense (otherwise those that have ac-in instead of otg would have to disable
usb_power_supply) and avoids confusion by explicitly stating presence in device dts.Quoted 2 lines
That's true. But this is a bit of hardware inside the AXP. If it's power isn't routed, it should report it, shouldn't it?
Quoted 7 lines
If the device does not use the input there are two cases:
- ac-in and usb/otg in short-circuited (there is a bit in AXP registers to provide this indication)
- the unused one is just not connected/connectableIn either case the voltage of the unused/unusable branch is not really useful, nor is it useful to have it show up in sysfs.
Exactly my thinking on this, +1 .
Quoted 6 lines
Quoted 4 lines
And normal users would probably expect to read the input voltage/current/status through sysfs (or maybe hwmon?), instead of not finding the device and having to look through the DTS.
Quoted 8 lines
Quoted 5 lines
Only those supplies effectively present (in-use or with connectors to eventually use them) should be visible in sysfs.
Having more of them will just confuse the users, they would be searching how they can connect the supply while there is no means to do so except soldering to the tiny AXP pins.+1
OK. So mostly tablets and dev boards would benefit from having both power supplies. Is there a preference for usb-power-supply over vbus-det-gpio if both are available? Or just list them both and let the driver sort it out?
Thanks.
ChenYu
PATCH 6/8 ARM: dts: axp209: Add usb_power_supply child node to the ax209 node
Hi,
Quoted 87 lines · Chen-Yu Tsai
Quoted 86 lines · Hans de Goede
Hi,
Quoted 58 lines · Bruno Pr?mont
Quoted 52 lines · On Fri, 31 Jul 2015 14:14:28 +0800 Chen-Yu Tsai wrote:
Quoted 43 lines · Bruno Pr?mont
Hi ChenYu,
Quoted 29 lines · On Fri, 31 Jul 2015 13:31:53 +0800 Chen-Yu Tsai wrote:
Hi Hans,
Quoted 25 lines · Hans de Goede
Add a node representing the usb power supply part of the axp209 pmic, note
that the usb power supply and the (to be added later) ac power supply will
each have their own child-node, so that they can be separately specified
as power-supply for other nodes using a power-supply property with a phandle pointing to the right axp209 child-node.Signed-off-by Hans de Goede <[email protected]>--- arch/arm/boot/dts/axp209.dtsi | 5 +++++ 1 file changed, 5 insertions(+)arch/arm/boot/dts/axp209.dtsi +1
-0@@ -89,4 +89,9 @@ regulator-name = "ldo5"; }; }; +Quoted 8 lines
arch/arm/boot/dts/axp209.dtsi line 95
Quoted 3 lines
arch/arm/boot/dts/axp209.dtsi +3
-0+ usb_power_supply: usb_power_supply { + compatible = "x-powers,axp202-usb-power-supply"; + status = "disabled";Is there any reason to have this disabled by default? AFAIK this is not something configurable in hardware, and the driver just gives readouts and status updates.
Quoted 5 lines
There are some devices that only have 'AC-IN' instead of usb/otg power (set-top boxes) so having the devices tell what power sources they have makes sense (otherwise those that have ac-in instead of otg would have to disable
usb_power_supply) and avoids confusion by explicitly stating presence in device dts.Quoted 2 lines
That's true. But this is a bit of hardware inside the AXP. If it's power isn't routed, it should report it, shouldn't it?
Quoted 7 lines
If the device does not use the input there are two cases:
- ac-in and usb/otg in short-circuited (there is a bit in AXP registers to provide this indication)
- the unused one is just not connected/connectableIn either case the voltage of the unused/unusable branch is not really useful, nor is it useful to have it show up in sysfs.
Exactly my thinking on this, +1 .
Quoted 11 lines
Quoted 4 lines
And normal users would probably expect to read the input voltage/current/status through sysfs (or maybe hwmon?), instead of not finding the device and having to look through the DTS.
Only those supplies effectively present (in-use or with connectors to eventually use them) should be visible in sysfs.
Having more of them will just confuse the users, they would be searching how they can connect the supply while there is no means to do so except soldering to the tiny AXP pins.
Quoted 6 lines
Quoted 1 line
+1
OK. So mostly tablets and dev boards would benefit from having both power supplies. Is there a preference for usb-power-supply over vbus-det-gpio if both are available? Or just list them both and let the driver sort it out?
So far I've simply stuck with whatever the fex file uses, if both are specified the driver will prefer the gpio, but that is not documented behavior. IMHO it would be better to pick and specify only one.
Regards,
Hans
PATCH 6/8 ARM: dts: axp209: Add usb_power_supply child node to the ax209 node
Quoted 117 lines · Hans de Goede
Hi,
Quoted 104 lines · Chen-Yu Tsai
Quoted 101 lines · Hans de Goede
Hi,
Quoted 69 lines · Bruno Pr?mont
Quoted 61 lines · On Fri, 31 Jul 2015 14:14:28 +0800 Chen-Yu Tsai wrote:
Quoted 50 lines · Bruno Pr?mont
Hi ChenYu,
Quoted 34 lines · On Fri, 31 Jul 2015 13:31:53 +0800 Chen-Yu Tsai wrote:
Hi Hans,
Quoted 29 lines · Hans de Goede
Add a node representing the usb power supply part of the axp209 pmic,
note
that the usb power supply and the (to be added later) ac power supply
will
each have their own child-node, so that they can be separately specified
as power-supply for other nodes using a power-supply property with a phandle pointing to the right axp209 child-node.Signed-off-by Hans de Goede <[email protected]>--- arch/arm/boot/dts/axp209.dtsi | 5 +++++ 1 file changed, 5 insertions(+)arch/arm/boot/dts/axp209.dtsi +2
-0@@ -89,4 +89,9 @@ regulator-name = "ldo5"; }; }; + + usb_power_supply: usb_power_supply {Quoted 8 lines
arch/arm/boot/dts/axp209.dtsi line 95
Quoted 2 lines
arch/arm/boot/dts/axp209.dtsi +2
-0+ compatible = "x-powers,axp202-usb-power-supply"; + status = "disabled";Is there any reason to have this disabled by default? AFAIK this is not something configurable in hardware, and the driver just gives readouts and status updates.
Quoted 5 lines
There are some devices that only have 'AC-IN' instead of usb/otg power (set-top boxes) so having the devices tell what power sources they have makes sense (otherwise those that have ac-in instead of otg would have to disable
usb_power_supply) and avoids confusion by explicitly stating presence in device dts.Quoted 2 lines
That's true. But this is a bit of hardware inside the AXP. If it's power isn't routed, it should report it, shouldn't it?
Quoted 7 lines
If the device does not use the input there are two cases:
- ac-in and usb/otg in short-circuited (there is a bit in AXP registers to provide this indication)
- the unused one is just not connected/connectableIn either case the voltage of the unused/unusable branch is not really useful, nor is it useful to have it show up in sysfs.
Exactly my thinking on this, +1 .
Quoted 12 lines
Quoted 4 lines
And normal users would probably expect to read the input voltage/current/status through sysfs (or maybe hwmon?), instead of not finding the device and having to look through the DTS.
Only those supplies effectively present (in-use or with connectors to eventually use them) should be visible in sysfs.
Having more of them will just confuse the users, they would be searching how they can connect the supply while there is no means to do so except soldering to the tiny AXP pins.Quoted 7 lines
Quoted 1 line
+1
OK. So mostly tablets and dev boards would benefit from having both power supplies. Is there a preference for usb-power-supply over vbus-det-gpio if both are available? Or just list them both and let the driver sort it out?
Quoted 6 lines
So far I've simply stuck with whatever the fex file uses, if both are specified the driver will prefer the gpio, but that is not documented behavior. IMHO it would be better to pick and specify only one.
From a functional standpoint, if usb-power-supply is available,
using it would be better because:
a) VBUS detection should be much better (IIRC cutoff at 4.4V)
b) Controllable max current draw
c) Can see the current draw
Of course not all boards would work. I think I even have a board that is only half powered on when only USB VBUS is used.
ChenYu
PATCH 6/8 ARM: dts: axp209: Add usb_power_supply child node to the ax209 node
In reply to Chen-Yu TsaiHi,
Quoted 87 lines · Chen-Yu Tsai
Quoted 86 lines · Hans de Goede
Hi,
Quoted 58 lines · Bruno Pr?mont
Quoted 52 lines · On Fri, 31 Jul 2015 14:14:28 +0800 Chen-Yu Tsai wrote:
Quoted 43 lines · Bruno Pr?mont
Hi ChenYu,
Quoted 29 lines · On Fri, 31 Jul 2015 13:31:53 +0800 Chen-Yu Tsai wrote:
Hi Hans,
Quoted 25 lines · Hans de Goede
Add a node representing the usb power supply part of the axp209 pmic, note
that the usb power supply and the (to be added later) ac power supply will
each have their own child-node, so that they can be separately specified
as power-supply for other nodes using a power-supply property with a phandle pointing to the right axp209 child-node.Signed-off-by Hans de Goede <[email protected]>--- arch/arm/boot/dts/axp209.dtsi | 5 +++++ 1 file changed, 5 insertions(+)arch/arm/boot/dts/axp209.dtsi +1
-0@@ -89,4 +89,9 @@ regulator-name = "ldo5"; }; }; +Quoted 8 lines
arch/arm/boot/dts/axp209.dtsi line 95
Quoted 3 lines
arch/arm/boot/dts/axp209.dtsi +3
-0+ usb_power_supply: usb_power_supply { + compatible = "x-powers,axp202-usb-power-supply"; + status = "disabled";Is there any reason to have this disabled by default? AFAIK this is not something configurable in hardware, and the driver just gives readouts and status updates.
Quoted 5 lines
There are some devices that only have 'AC-IN' instead of usb/otg power (set-top boxes) so having the devices tell what power sources they have makes sense (otherwise those that have ac-in instead of otg would have to disable
usb_power_supply) and avoids confusion by explicitly stating presence in device dts.Quoted 2 lines
That's true. But this is a bit of hardware inside the AXP. If it's power isn't routed, it should report it, shouldn't it?
Quoted 7 lines
If the device does not use the input there are two cases:
- ac-in and usb/otg in short-circuited (there is a bit in AXP registers to provide this indication)
- the unused one is just not connected/connectableIn either case the voltage of the unused/unusable branch is not really useful, nor is it useful to have it show up in sysfs.
Exactly my thinking on this, +1 .
Quoted 11 lines
Quoted 4 lines
And normal users would probably expect to read the input voltage/current/status through sysfs (or maybe hwmon?), instead of not finding the device and having to look through the DTS.
Only those supplies effectively present (in-use or with connectors to eventually use them) should be visible in sysfs.
Having more of them will just confuse the users, they would be searching how they can connect the supply while there is no means to do so except soldering to the tiny AXP pins.
Quoted 6 lines
Quoted 1 line
+1
OK. So mostly tablets and dev boards would benefit from having both power supplies. Is there a preference for usb-power-supply over vbus-det-gpio if both are available? Or just list them both and let the driver sort it out?
p.s.
Note that the driver can even deal with not having a vbus-det at all. It will then simulate a vbus drop for long enough to terminate the current session when ever the id pin changes. This is necessary for the original cubieboard which has its vbus wired hard to 5V.
This MUST only be used on boards woth broken vbus-det though, having vbus-det is important to avoid feeding power to the outside when a charger is plugged in (a charge cable should never pull the id pin low, but you never know).
Regards,
Hans
PATCH 7/8 ARM: dts: sun7i: Add regulator configuration to the bananapi dts file
In reply to Hans de GoedeAdd regulator configuration to the bananapi dts file, this enables cpu voltage scaling.
--- arch/arm/boot/dts/sun7i-a20-bananapi.dts | 39 ++++++++++++++++++++++++++++---- 1 file changed, 35 insertions(+), 4 deletions(-)
arch/arm/boot/dts/sun7i-a20-bananapi.dts +35 -4
@@ -92,6 +92,10 @@ status = "okay"; }; +&cpu0 { + cpu-supply = <®_dcdc2>; +}; + &ehci0 { status = "okay"; };
@@ -119,16 +123,14 @@ status = "okay"; axp209: pmic at 34 { - compatible = "x-powers,axp209"; reg = <0x34>; interrupt-parent = <&nmi_intc>; interrupts = <0 IRQ_TYPE_LEVEL_LOW>; - - interrupt-controller; - #interrupt-cells = <1>; }; }; +#include "axp209.dtsi" + &i2c2 { pinctrl-names = "default"; pinctrl-0 = <&i2c2_pins_a>;
@@ -182,6 +184,31 @@ }; }; +®_dcdc2 { + regulator-always-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1500000>; + regulator-name = "vdd-cpu"; +}; + +®_dcdc3 { + regulator-always-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1400000>; + regulator-name = "vdd-int-pll"; +}; + +®_ldo1 { + regulator-name = "vdd-rtc"; +}; + +®_ldo2 { + regulator-always-on; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + regulator-name = "avcc"; +}; + ®_usb1_vbus { status = "okay"; };
@@ -216,6 +243,10 @@ status = "okay"; }; +&usb_power_supply { + status = "okay"; +}; + &usbphy { usb1_vbus-supply = <®_usb1_vbus>; usb2_vbus-supply = <®_usb2_vbus>;
Signature · 1 line
2.3.6
PATCH 8/8 ARM: dts: sun7i: Enable USB DRC on Bananapi
In reply to Hans de GoedeEnable the otg/drc usb controller on the Bananapi.
--- arch/arm/boot/dts/sun7i-a20-bananapi.dts | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
arch/arm/boot/dts/sun7i-a20-bananapi.dts +25 -0
@@ -161,7 +161,18 @@ status = "okay"; }; +&otg_sram { + status = "okay"; +}; + &pio { + usb0_id_detect_pin: usb0_id_detect_pin at 0 { + allwinner,pins = "PH4"; + allwinner,function = "gpio_in"; + allwinner,drive = <SUN4I_PINCTRL_10_MA>; + allwinner,pull = <SUN4I_PINCTRL_PULL_UP>; + }; + mmc0_cd_pin_bananapi: mmc0_cd_pin at 0 { allwinner,pins = "PH10"; allwinner,function = "gpio_in";
@@ -209,6 +220,10 @@ regulator-name = "avcc"; }; +®_usb0_vbus { + status = "okay"; +}; + ®_usb1_vbus { status = "okay"; };
@@ -243,11 +258,21 @@ status = "okay"; }; +&usb_otg { + dr_mode = "otg"; + status = "okay"; +}; + &usb_power_supply { status = "okay"; }; &usbphy { + pinctrl-names = "default"; + pinctrl-0 = <&usb0_id_detect_pin>; + usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */ + usb0_vbus_power-supply = <&usb_power_supply>; + usb0_vbus-supply = <®_usb0_vbus>; usb1_vbus-supply = <®_usb1_vbus>; usb2_vbus-supply = <®_usb2_vbus>; status = "okay";
Signature · 1 line
2.3.6
cover mfd/power/phy: Add support for otg vbus detection via axp pmic
In reply to Hans de GoedeQuoted 8 lines · Hans de Goede
Hi All,
Here is a series which adds the beginning of power-supply support to the axp20x pmic code. My primary reason for working on this is to enable the use of the usb power-supply bits in the pmic to for vbus detection on boards which do not have a vbus-det gpio, and instead rely on the pmic for vbus detection.
Quoted 4 lines
After I had written most of the vbus power-supply driver code I became aware of Bruno Pr?mont's (in the CC) previous work on this our drivers are mostly the same, and I've borrowed some code from his driver to add support for min-volt / max-curr properties.
This is one of the reasons why we try to keep our Mainlining Effort page up-to-date:
http://linux-sunxi.org/Linux_mainlining_effort
Quoted 22 lines
The big difference between our 2 drivers is that mine driver uses a devicetree child node / mfd cell per power-supply, so one for each of the usb-power, ac-power / battery-charger and rtc-backup-bat -charger
bits.Depending on the board each of those must be enabled / disabled separately
in devicetree as most boards do not use all 4. So in dt each one needs its
own child-node of the axp20x node. Another reason for using separate child
nodes for each is so that other devicetree nodes can have a power -supply
property with a phandle referencing a node representing a single power-supply.Regards,
Hans