* Linux driver for IRPS5401 - status reg not found
@ 2020-03-30 11:33 Michal Simek
2020-03-30 15:24 ` Guenter Roeck
0 siblings, 1 reply; 14+ messages in thread
From: Michal Simek @ 2020-03-30 11:33 UTC (permalink / raw)
To: Robert Hancock, Guenter Roeck; +Cc: linux-hwmon
Hi Robert and Guenter,
Xilinx boards are using IRPS5401 chips and I have tried to use your driver.
I have checked that u-boot can detect that devices and read it.
ZynqMP> i2c probe
Valid chip addresses: 0C 13 14 20 43 44 74
ZynqMP> i2c md 13 0 10
0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................
ZynqMP> i2c md 14 0 10
0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................
ZynqMP> i2c md 43 0 10
0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
ZynqMP> i2c md 44 0 10
0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
ZynqMP>
Here is DT fragment which I use (it is under i2c mux)
185 irps5401_43: irps5401@43 {
186 compatible = "infineon,irps5401";
187 reg = <0x43>; /* pmbus / i2c 0x13 */
188 };
189 irps5401_4d: irps5401@44 {
190 compatible = "infineon,irps5401";
191 reg = <0x44>; /* pmbus / i2c 0x14 */
192 };
I see that driver is used but with error.
[ 37.553740] irps5401 3-0043: PMBus status register not found
[ 37.559815] irps5401 3-0044: PMBus status register not found
That's why I want to check with you what could be the problem.
Also I would like to know if there is a way to disable it via any API.
One of this regulator is connected to another device which doesn't have
access to it. It means before powering up this device there is a need to
enable this power regulator. The best via any dedicated API.
Thanks,
Michal
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: Linux driver for IRPS5401 - status reg not found 2020-03-30 11:33 Linux driver for IRPS5401 - status reg not found Michal Simek @ 2020-03-30 15:24 ` Guenter Roeck 2020-03-30 15:42 ` Robert Hancock 2020-03-30 15:46 ` Michal Simek 0 siblings, 2 replies; 14+ messages in thread From: Guenter Roeck @ 2020-03-30 15:24 UTC (permalink / raw) To: Michal Simek, Robert Hancock; +Cc: linux-hwmon On 3/30/20 4:33 AM, Michal Simek wrote: > Hi Robert and Guenter, > > Xilinx boards are using IRPS5401 chips and I have tried to use your driver. > I have checked that u-boot can detect that devices and read it. > > ZynqMP> i2c probe > Valid chip addresses: 0C 13 14 20 43 44 74 > ZynqMP> i2c md 13 0 10 > 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ > ZynqMP> i2c md 14 0 10 > 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ > ZynqMP> i2c md 43 0 10 > 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ > ZynqMP> i2c md 44 0 10 > 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ > ZynqMP> > > Here is DT fragment which I use (it is under i2c mux) > > 185 irps5401_43: irps5401@43 { > 186 compatible = "infineon,irps5401"; > 187 reg = <0x43>; /* pmbus / i2c 0x13 */ Does that mean the mux is at 0x13 ? > 188 }; > 189 irps5401_4d: irps5401@44 { > 190 compatible = "infineon,irps5401"; > 191 reg = <0x44>; /* pmbus / i2c 0x14 */ Why _4d ? > 192 }; > > I see that driver is used but with error. > > [ 37.553740] irps5401 3-0043: PMBus status register not found > [ 37.559815] irps5401 3-0044: PMBus status register not found > > > That's why I want to check with you what could be the problem. > PMBus status registers are at 0x78 (byte) and 0x79 (word). The above error is reported if reading both returns an error or 0xff / 0xffff, which indicates that the chip is not accessible. I can say for sure that whatever is at 0x43/0x44, it is very likely not an irps5401. If it was, at least registers 0x2 and 0x6 should report different values, and 0x01 doesn't look much better (the lower 2 bits should never be set). > Also I would like to know if there is a way to disable it via any API. Not sure what you want to disable. The message ? The PMBus core needs to have access to the chip to initialize. If there is no status register, there is nothing it can do but to refuse to instantiate. It might make sense to use i2cdetect / i2cget in Linux to determine if the chips are accessible. I'd try reading the status registers (0x78 to 0x7e), value registers (0x88 to 0x8d, 0x96, 0x97), manufacturer id (0x99) and model (0x9a), and i2c device ID (0xad) and revision (0xae). > One of this regulator is connected to another device which doesn't have > access to it. It means before powering up this device there is a need to > enable this power regulator. The best via any dedicated API. > We can add regulator support to the PMBus core or to the irps5401 driver if necessary (patches welcome), assuming the regulator in question is handled by Linux. Hope this helps, Guenter ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux driver for IRPS5401 - status reg not found 2020-03-30 15:24 ` Guenter Roeck @ 2020-03-30 15:42 ` Robert Hancock 2020-03-30 18:48 ` Guenter Roeck 2020-03-30 15:46 ` Michal Simek 1 sibling, 1 reply; 14+ messages in thread From: Robert Hancock @ 2020-03-30 15:42 UTC (permalink / raw) To: Guenter Roeck, Michal Simek; +Cc: linux-hwmon On 2020-03-30 9:24 a.m., Guenter Roeck wrote: > On 3/30/20 4:33 AM, Michal Simek wrote: >> Hi Robert and Guenter, >> >> Xilinx boards are using IRPS5401 chips and I have tried to use your driver. >> I have checked that u-boot can detect that devices and read it. >> >> ZynqMP> i2c probe >> Valid chip addresses: 0C 13 14 20 43 44 74 >> ZynqMP> i2c md 13 0 10 >> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ >> ZynqMP> i2c md 14 0 10 >> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ >> ZynqMP> i2c md 43 0 10 >> 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ >> ZynqMP> i2c md 44 0 10 >> 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ >> ZynqMP> >> >> Here is DT fragment which I use (it is under i2c mux) >> >> 185 irps5401_43: irps5401@43 { >> 186 compatible = "infineon,irps5401"; >> 187 reg = <0x43>; /* pmbus / i2c 0x13 */ > > Does that mean the mux is at 0x13 ? These chips have two I2C addresses with two separate interfaces: the standard PMBus-compatible interface at an address between 0x40-0x4f, which the irps5401 driver supports, and another proprietary interface at an address between 0x10-0x1f. The specific addresses in those ranges is configured by the value of a resistor on one of the pins. > >> 188 }; >> 189 irps5401_4d: irps5401@44 { >> 190 compatible = "infineon,irps5401"; >> 191 reg = <0x44>; /* pmbus / i2c 0x14 */ > > Why _4d ? > >> 192 }; >> >> I see that driver is used but with error. >> >> [ 37.553740] irps5401 3-0043: PMBus status register not found >> [ 37.559815] irps5401 3-0044: PMBus status register not found >> >> >> That's why I want to check with you what could be the problem. >> > > PMBus status registers are at 0x78 (byte) and 0x79 (word). The above > error is reported if reading both returns an error or 0xff / 0xffff, > which indicates that the chip is not accessible. > > I can say for sure that whatever is at 0x43/0x44, it is very likely > not an irps5401. If it was, at least registers 0x2 and 0x6 should report > different values, and 0x01 doesn't look much better (the lower 2 bits > should never be set). > >> Also I would like to know if there is a way to disable it via any API. > > Not sure what you want to disable. The message ? The PMBus core needs > to have access to the chip to initialize. If there is no status register, > there is nothing it can do but to refuse to instantiate. > > It might make sense to use i2cdetect / i2cget in Linux to determine > if the chips are accessible. I'd try reading the status registers (0x78 > to 0x7e), value registers (0x88 to 0x8d, 0x96, 0x97), manufacturer > id (0x99) and model (0x9a), and i2c device ID (0xad) and revision (0xae). This would be my first suggestion as well. > >> One of this regulator is connected to another device which doesn't have >> access to it. It means before powering up this device there is a need to >> enable this power regulator. The best via any dedicated API. I don't think the PMBus interface on these chips exposes any interface to command the regulator. However, one could do this over the Infineon programming/control interface on the 0x10-0x1f addresses. This protocol is documented publicly now (see the programming guide and register map document on the Infineon web site). >> > > We can add regulator support to the PMBus core or to the irps5401 driver > if necessary (patches welcome), assuming the regulator in question is > handled by Linux. > > Hope this helps, > Guenter > -- Robert Hancock Senior Hardware Designer SED Systems, a division of Calian Ltd. Email: hancock@sedsystems.ca ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux driver for IRPS5401 - status reg not found 2020-03-30 15:42 ` Robert Hancock @ 2020-03-30 18:48 ` Guenter Roeck 2020-03-30 19:09 ` Robert Hancock 0 siblings, 1 reply; 14+ messages in thread From: Guenter Roeck @ 2020-03-30 18:48 UTC (permalink / raw) To: Robert Hancock, Michal Simek; +Cc: linux-hwmon On 3/30/20 8:42 AM, Robert Hancock wrote: > On 2020-03-30 9:24 a.m., Guenter Roeck wrote: >> On 3/30/20 4:33 AM, Michal Simek wrote: >>> Hi Robert and Guenter, >>> >>> Xilinx boards are using IRPS5401 chips and I have tried to use your driver. >>> I have checked that u-boot can detect that devices and read it. >>> >>> ZynqMP> i2c probe >>> Valid chip addresses: 0C 13 14 20 43 44 74 >>> ZynqMP> i2c md 13 0 10 >>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ >>> ZynqMP> i2c md 14 0 10 >>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ >>> ZynqMP> i2c md 43 0 10 >>> 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ >>> ZynqMP> i2c md 44 0 10 >>> 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ >>> ZynqMP> >>> >>> Here is DT fragment which I use (it is under i2c mux) >>> >>> 185 irps5401_43: irps5401@43 { >>> 186 compatible = "infineon,irps5401"; >>> 187 reg = <0x43>; /* pmbus / i2c 0x13 */ >> >> Does that mean the mux is at 0x13 ? > > These chips have two I2C addresses with two separate interfaces: the standard PMBus-compatible interface at an address between 0x40-0x4f, which the irps5401 driver supports, and another proprietary interface at an address between 0x10-0x1f. The specific addresses in those ranges is configured by the value of a resistor on one of the pins. > Ah, sorry, I didn't get that part earlier. Unfortunately, the datasheet doesn't seem to include a description of the proprietary interface registers/commands, or maybe I am missing it. The chip datasheet does talk a lot about various MTP registers. Part of that register set is Write_protect_section and Read_protect_section. Maybe the PMBus registers are all read protected ? Guenter ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux driver for IRPS5401 - status reg not found 2020-03-30 18:48 ` Guenter Roeck @ 2020-03-30 19:09 ` Robert Hancock 2020-03-30 19:48 ` Guenter Roeck 0 siblings, 1 reply; 14+ messages in thread From: Robert Hancock @ 2020-03-30 19:09 UTC (permalink / raw) To: Guenter Roeck, Michal Simek; +Cc: linux-hwmon On 2020-03-30 12:48 p.m., Guenter Roeck wrote: > On 3/30/20 8:42 AM, Robert Hancock wrote: >> On 2020-03-30 9:24 a.m., Guenter Roeck wrote: >>> On 3/30/20 4:33 AM, Michal Simek wrote: >>>> Hi Robert and Guenter, >>>> >>>> Xilinx boards are using IRPS5401 chips and I have tried to use your driver. >>>> I have checked that u-boot can detect that devices and read it. >>>> >>>> ZynqMP> i2c probe >>>> Valid chip addresses: 0C 13 14 20 43 44 74 >>>> ZynqMP> i2c md 13 0 10 >>>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ >>>> ZynqMP> i2c md 14 0 10 >>>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ >>>> ZynqMP> i2c md 43 0 10 >>>> 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ >>>> ZynqMP> i2c md 44 0 10 >>>> 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ >>>> ZynqMP> >>>> >>>> Here is DT fragment which I use (it is under i2c mux) >>>> >>>> 185 irps5401_43: irps5401@43 { >>>> 186 compatible = "infineon,irps5401"; >>>> 187 reg = <0x43>; /* pmbus / i2c 0x13 */ >>> >>> Does that mean the mux is at 0x13 ? >> >> These chips have two I2C addresses with two separate interfaces: the standard PMBus-compatible interface at an address between 0x40-0x4f, which the irps5401 driver supports, and another proprietary interface at an address between 0x10-0x1f. The specific addresses in those ranges is configured by the value of a resistor on one of the pins. >> > > Ah, sorry, I didn't get that part earlier. Unfortunately, the datasheet > doesn't seem to include a description of the proprietary interface > registers/commands, or maybe I am missing it. > > The chip datasheet does talk a lot about various MTP registers. > Part of that register set is Write_protect_section and > Read_protect_section. Maybe the PMBus registers are all read > protected ? There is a programming guide and register map on the Infineon site under "Additional Technical Information" here: https://www.infineon.com/cms/en/product/power/dc-dc-converters/integrated-pol-voltage-regulators/irps5401m/ -- Robert Hancock Senior Hardware Designer SED Systems, a division of Calian Ltd. Email: hancock@sedsystems.ca ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux driver for IRPS5401 - status reg not found 2020-03-30 19:09 ` Robert Hancock @ 2020-03-30 19:48 ` Guenter Roeck 2020-03-31 12:38 ` Michal Simek 0 siblings, 1 reply; 14+ messages in thread From: Guenter Roeck @ 2020-03-30 19:48 UTC (permalink / raw) To: Robert Hancock; +Cc: Michal Simek, linux-hwmon On Mon, Mar 30, 2020 at 01:09:56PM -0600, Robert Hancock wrote: > On 2020-03-30 12:48 p.m., Guenter Roeck wrote: > > On 3/30/20 8:42 AM, Robert Hancock wrote: > > > On 2020-03-30 9:24 a.m., Guenter Roeck wrote: > > > > On 3/30/20 4:33 AM, Michal Simek wrote: > > > > > Hi Robert and Guenter, > > > > > > > > > > Xilinx boards are using IRPS5401 chips and I have tried to use your driver. > > > > > I have checked that u-boot can detect that devices and read it. > > > > > > > > > > ZynqMP> i2c probe > > > > > Valid chip addresses: 0C 13 14 20 43 44 74 > > > > > ZynqMP> i2c md 13 0 10 > > > > > 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ > > > > > ZynqMP> i2c md 14 0 10 > > > > > 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ > > > > > ZynqMP> i2c md 43 0 10 > > > > > 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ > > > > > ZynqMP> i2c md 44 0 10 > > > > > 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ > > > > > ZynqMP> > > > > > > > > > > Here is DT fragment which I use (it is under i2c mux) > > > > > > > > > > 185 irps5401_43: irps5401@43 { > > > > > 186 compatible = "infineon,irps5401"; > > > > > 187 reg = <0x43>; /* pmbus / i2c 0x13 */ > > > > > > > > Does that mean the mux is at 0x13 ? > > > > > > These chips have two I2C addresses with two separate interfaces: the standard PMBus-compatible interface at an address between 0x40-0x4f, which the irps5401 driver supports, and another proprietary interface at an address between 0x10-0x1f. The specific addresses in those ranges is configured by the value of a resistor on one of the pins. > > > > > > > Ah, sorry, I didn't get that part earlier. Unfortunately, the datasheet > > doesn't seem to include a description of the proprietary interface > > registers/commands, or maybe I am missing it. > > > > The chip datasheet does talk a lot about various MTP registers. > > Part of that register set is Write_protect_section and > > Read_protect_section. Maybe the PMBus registers are all read > > protected ? > > There is a programming guide and register map on the Infineon site under > "Additional Technical Information" here: > > https://www.infineon.com/cms/en/product/power/dc-dc-converters/integrated-pol-voltage-regulators/irps5401m/ > Based on that my best guess would be that either the chips are not at the expected addresses, or that the registers are indeed read protected. Guenter ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux driver for IRPS5401 - status reg not found 2020-03-30 19:48 ` Guenter Roeck @ 2020-03-31 12:38 ` Michal Simek 2020-04-09 14:29 ` Michal Simek 0 siblings, 1 reply; 14+ messages in thread From: Michal Simek @ 2020-03-31 12:38 UTC (permalink / raw) To: Guenter Roeck, Robert Hancock; +Cc: Michal Simek, linux-hwmon On 30. 03. 20 21:48, Guenter Roeck wrote: > On Mon, Mar 30, 2020 at 01:09:56PM -0600, Robert Hancock wrote: >> On 2020-03-30 12:48 p.m., Guenter Roeck wrote: >>> On 3/30/20 8:42 AM, Robert Hancock wrote: >>>> On 2020-03-30 9:24 a.m., Guenter Roeck wrote: >>>>> On 3/30/20 4:33 AM, Michal Simek wrote: >>>>>> Hi Robert and Guenter, >>>>>> >>>>>> Xilinx boards are using IRPS5401 chips and I have tried to use your driver. >>>>>> I have checked that u-boot can detect that devices and read it. >>>>>> >>>>>> ZynqMP> i2c probe >>>>>> Valid chip addresses: 0C 13 14 20 43 44 74 >>>>>> ZynqMP> i2c md 13 0 10 >>>>>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ >>>>>> ZynqMP> i2c md 14 0 10 >>>>>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ >>>>>> ZynqMP> i2c md 43 0 10 >>>>>> 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ >>>>>> ZynqMP> i2c md 44 0 10 >>>>>> 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ >>>>>> ZynqMP> >>>>>> >>>>>> Here is DT fragment which I use (it is under i2c mux) >>>>>> >>>>>> 185 irps5401_43: irps5401@43 { >>>>>> 186 compatible = "infineon,irps5401"; >>>>>> 187 reg = <0x43>; /* pmbus / i2c 0x13 */ >>>>> >>>>> Does that mean the mux is at 0x13 ? >>>> >>>> These chips have two I2C addresses with two separate interfaces: the standard PMBus-compatible interface at an address between 0x40-0x4f, which the irps5401 driver supports, and another proprietary interface at an address between 0x10-0x1f. The specific addresses in those ranges is configured by the value of a resistor on one of the pins. >>>> >>> >>> Ah, sorry, I didn't get that part earlier. Unfortunately, the datasheet >>> doesn't seem to include a description of the proprietary interface >>> registers/commands, or maybe I am missing it. >>> >>> The chip datasheet does talk a lot about various MTP registers. >>> Part of that register set is Write_protect_section and >>> Read_protect_section. Maybe the PMBus registers are all read >>> protected ? >> >> There is a programming guide and register map on the Infineon site under >> "Additional Technical Information" here: >> >> https://www.infineon.com/cms/en/product/power/dc-dc-converters/integrated-pol-voltage-regulators/irps5401m/ >> > Based on that my best guess would be that either the chips are not at the > expected addresses, or that the registers are indeed read protected. I am able to detect that devices. root@zcu104-debian:/etc/apt# i2cdetect -y -r 3 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- 13 14 -- -- -- -- -- -- -- -- -- -- -- 20: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- 43 44 -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- UU -- -- -- Also disable/enable rail on 0x44 and see power good led on/off root@zcu104-debian:~# i2cset -y 3 0x44 0 3 root@zcu104-debian:~# i2cset -y 3 0x44 1 0x80 b root@zcu104-debian:~# i2cget -y 3 0x44 0x78 b I can't read the rest of regs but checking with hw guys what they have done with these devices. Anyway thanks for your help and advices. Thanks, Michal ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux driver for IRPS5401 - status reg not found 2020-03-31 12:38 ` Michal Simek @ 2020-04-09 14:29 ` Michal Simek 2020-04-09 15:16 ` Guenter Roeck 0 siblings, 1 reply; 14+ messages in thread From: Michal Simek @ 2020-04-09 14:29 UTC (permalink / raw) To: Michal Simek, Guenter Roeck, Robert Hancock; +Cc: linux-hwmon On 31. 03. 20 14:38, Michal Simek wrote: > On 30. 03. 20 21:48, Guenter Roeck wrote: >> On Mon, Mar 30, 2020 at 01:09:56PM -0600, Robert Hancock wrote: >>> On 2020-03-30 12:48 p.m., Guenter Roeck wrote: >>>> On 3/30/20 8:42 AM, Robert Hancock wrote: >>>>> On 2020-03-30 9:24 a.m., Guenter Roeck wrote: >>>>>> On 3/30/20 4:33 AM, Michal Simek wrote: >>>>>>> Hi Robert and Guenter, >>>>>>> >>>>>>> Xilinx boards are using IRPS5401 chips and I have tried to use your driver. >>>>>>> I have checked that u-boot can detect that devices and read it. >>>>>>> >>>>>>> ZynqMP> i2c probe >>>>>>> Valid chip addresses: 0C 13 14 20 43 44 74 >>>>>>> ZynqMP> i2c md 13 0 10 >>>>>>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ >>>>>>> ZynqMP> i2c md 14 0 10 >>>>>>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ >>>>>>> ZynqMP> i2c md 43 0 10 >>>>>>> 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ >>>>>>> ZynqMP> i2c md 44 0 10 >>>>>>> 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ >>>>>>> ZynqMP> >>>>>>> >>>>>>> Here is DT fragment which I use (it is under i2c mux) >>>>>>> >>>>>>> 185 irps5401_43: irps5401@43 { >>>>>>> 186 compatible = "infineon,irps5401"; >>>>>>> 187 reg = <0x43>; /* pmbus / i2c 0x13 */ >>>>>> >>>>>> Does that mean the mux is at 0x13 ? >>>>> >>>>> These chips have two I2C addresses with two separate interfaces: the standard PMBus-compatible interface at an address between 0x40-0x4f, which the irps5401 driver supports, and another proprietary interface at an address between 0x10-0x1f. The specific addresses in those ranges is configured by the value of a resistor on one of the pins. >>>>> >>>> >>>> Ah, sorry, I didn't get that part earlier. Unfortunately, the datasheet >>>> doesn't seem to include a description of the proprietary interface >>>> registers/commands, or maybe I am missing it. >>>> >>>> The chip datasheet does talk a lot about various MTP registers. >>>> Part of that register set is Write_protect_section and >>>> Read_protect_section. Maybe the PMBus registers are all read >>>> protected ? >>> >>> There is a programming guide and register map on the Infineon site under >>> "Additional Technical Information" here: >>> >>> https://www.infineon.com/cms/en/product/power/dc-dc-converters/integrated-pol-voltage-regulators/irps5401m/ >>> >> Based on that my best guess would be that either the chips are not at the >> expected addresses, or that the registers are indeed read protected. > > I am able to detect that devices. > > root@zcu104-debian:/etc/apt# i2cdetect -y -r 3 > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: -- -- -- -- -- -- -- -- -- -- -- -- -- > 10: -- -- -- 13 14 -- -- -- -- -- -- -- -- -- -- -- > 20: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 40: -- -- -- 43 44 -- -- -- -- -- -- -- -- -- -- -- > 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 70: -- -- -- -- UU -- -- -- > > Also disable/enable rail on 0x44 and see power good led on/off > > root@zcu104-debian:~# i2cset -y 3 0x44 0 3 > root@zcu104-debian:~# i2cset -y 3 0x44 1 0x80 b > root@zcu104-debian:~# i2cget -y 3 0x44 0x78 b > > I can't read the rest of regs but checking with hw guys what they have > done with these devices. Just to let you know issue is with i2c driver. Here is my output for the record. irps5401-i2c-3-43 Adapter: i2c-0-mux (chan_id 2) vin1: 11.56 V (min = +9.00 V, crit max = +14.00 V) vin2: 11.56 V (min = +9.00 V, crit max = +14.00 V) vin3: 11.56 V (min = +9.00 V, crit max = +14.00 V) vin4: N/A vin5: 2.52 V (min = +0.40 V, crit max = +4.00 V) ALARM (CRIT) vout1: 851.00 mV (crit min = +0.65 V, min = +0.68 V) (max = +1.02 V, crit max = +1.25 V) vout2: 1.80 V (crit min = +1.55 V, min = +1.56 V) (max = +2.16 V, crit max = +2.20 V) vout3: 1.20 V (crit min = +0.90 V, min = +0.96 V) (max = +1.43 V, crit max = +1.59 V) vout4: N/A vout5: 906.00 mV (crit min = +0.68 V, min = +0.79 V) (max = +1.02 V, crit max = +1.13 V) temp1: +43.0°C (high = +100.0°C, crit = +120.0°C) temp2: +43.0°C (high = +100.0°C, crit = +120.0°C) temp3: +43.0°C (high = +100.0°C, crit = +120.0°C) temp4: N/A temp5: +44.0°C (high = +100.0°C, crit = +120.0°C) pin1: 1.75 W pin2: 406.25 mW pin3: 468.75 mW pin4: N/A pin5: 15.62 mW pout1: 1.50 W pout2: 406.25 mW pout3: 468.75 mW pout4: N/A pout5: 15.62 mW iin1: 125.00 mA iin2: 31.00 mA iin3: 39.00 mA iin4: N/A iout1: 2.00 A (max = +21.00 A, crit max = +25.00 A) iout2: 234.00 mA (max = +2.50 A, crit max = +3.12 A) iout3: 390.00 mA (max = +8.50 A, crit max = +10.25 A) iout4: N/A iout5: 8.00 mA (max = +0.65 A, crit max = +0.72 A) irps5401-i2c-3-44 Adapter: i2c-0-mux (chan_id 2) vin1: 11.53 V (min = +9.00 V, crit max = +14.00 V) vin2: 11.56 V (min = +9.00 V, crit max = +14.00 V) vin3: 11.41 V (min = +9.00 V, crit max = +14.00 V) vin4: 11.56 V (min = +9.00 V, crit max = +14.00 V) vin5: 2.51 V (min = +0.40 V, crit max = +4.00 V) ALARM (CRIT) vout1: 3.30 V (crit min = +2.90 V, min = +2.91 V) (max = +3.69 V, crit max = +3.70 V) vout2: 1.13 V (crit min = +0.73 V, min = +0.90 V) (max = +1.35 V, crit max = +1.52 V) vout3: 5.00 V (crit min = +4.60 V, min = +4.70 V) (max = +5.20 V, crit max = +5.40 V) vout4: 152.00 mV (crit min = +1.40 V, min = +1.44 V) (max = +2.16 V, crit max = +2.20 V) vout5: 851.00 mV (crit min = +0.64 V, min = +0.75 V) (max = +0.97 V, crit max = +1.07 V) temp1: +40.0°C (high = +100.0°C, crit = +120.0°C) temp2: +40.0°C (high = +100.0°C, crit = +120.0°C) temp3: +40.0°C (high = +100.0°C, crit = +120.0°C) temp4: +40.0°C (high = +100.0°C, crit = +120.0°C) temp5: +40.0°C (high = +100.0°C, crit = +120.0°C) pin1: 2.50 W pin2: 31.25 mW pin3: 0.00 W pin4: 0.00 W pin5: 187.50 mW pout1: 2.25 W pout2: 31.25 mW pout3: 0.00 W pout4: 31.25 mW pout5: 62.50 mW iin1: 187.00 mA iin2: 0.00 A iin3: 0.00 A iin4: 0.00 A iout1: 750.00 mA (max = +12.00 A, crit max = +14.00 A) iout2: 46.00 mA (max = +1.81 A, crit max = +2.19 A) iout3: 0.00 A (max = +3.50 A, crit max = +4.00 A) iout4: 9.28 A (max = +3.81 A, crit max = +4.81 A) iout5: 73.00 mA (max = +0.65 A, crit max = +0.72 A) Thanks, Michal ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux driver for IRPS5401 - status reg not found 2020-04-09 14:29 ` Michal Simek @ 2020-04-09 15:16 ` Guenter Roeck 2020-04-09 15:30 ` Robert Hancock 0 siblings, 1 reply; 14+ messages in thread From: Guenter Roeck @ 2020-04-09 15:16 UTC (permalink / raw) To: monstr, Michal Simek, Robert Hancock; +Cc: linux-hwmon Hi Michal, On 4/9/20 7:29 AM, Michal Simek wrote: [ ... ] > > Just to let you know issue is with i2c driver. Here is my output for the > record. > Thanks a lot for the update. > irps5401-i2c-3-43 > Adapter: i2c-0-mux (chan_id 2) > vin1: 11.56 V (min = +9.00 V, crit max = +14.00 V) > vin2: 11.56 V (min = +9.00 V, crit max = +14.00 V) > vin3: 11.56 V (min = +9.00 V, crit max = +14.00 V) > vin4: N/A This is interesting; it means that the rail is not active (?) or not supported, or maybe even that the driver has a bug. The second chip reports a value here, so I guess the rail is inactive. If possible, it would be desirable to detect this during probe and not try to report values for this rail. It would be great if you can find the time to figure out what is going on. Thanks, Guenter ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux driver for IRPS5401 - status reg not found 2020-04-09 15:16 ` Guenter Roeck @ 2020-04-09 15:30 ` Robert Hancock 2020-04-09 21:23 ` Guenter Roeck 0 siblings, 1 reply; 14+ messages in thread From: Robert Hancock @ 2020-04-09 15:30 UTC (permalink / raw) To: Guenter Roeck, monstr, Michal Simek; +Cc: linux-hwmon On 2020-04-09 9:16 a.m., Guenter Roeck wrote: > Hi Michal, > > On 4/9/20 7:29 AM, Michal Simek wrote: > [ ... ] >> >> Just to let you know issue is with i2c driver. Here is my output for the >> record. >> > Thanks a lot for the update. > >> irps5401-i2c-3-43 >> Adapter: i2c-0-mux (chan_id 2) >> vin1: 11.56 V (min = +9.00 V, crit max = +14.00 V) >> vin2: 11.56 V (min = +9.00 V, crit max = +14.00 V) >> vin3: 11.56 V (min = +9.00 V, crit max = +14.00 V) >> vin4: N/A > > This is interesting; it means that the rail is not active (?) or > not supported, or maybe even that the driver has a bug. The second > chip reports a value here, so I guess the rail is inactive. > If possible, it would be desirable to detect this during probe > and not try to report values for this rail. It would be great if > you can find the time to figure out what is going on. I would assume that either that rail is not used in that board design and was disabled in the non-volatile config on the chip, or alternately the chip allows combining outputs C and D (i.e. 3 and 4) into a single output in which case only one will report valid data. Not sure offhand if there is a way to detect those cases from the PMBus interface at probe time. -- Robert Hancock Senior Hardware Designer SED Systems, a division of Calian Ltd. Email: hancock@sedsystems.ca ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux driver for IRPS5401 - status reg not found 2020-04-09 15:30 ` Robert Hancock @ 2020-04-09 21:23 ` Guenter Roeck 2020-04-10 7:19 ` Michal Simek 0 siblings, 1 reply; 14+ messages in thread From: Guenter Roeck @ 2020-04-09 21:23 UTC (permalink / raw) To: Robert Hancock, monstr, Michal Simek; +Cc: linux-hwmon On 4/9/20 8:30 AM, Robert Hancock wrote: > On 2020-04-09 9:16 a.m., Guenter Roeck wrote: >> Hi Michal, >> >> On 4/9/20 7:29 AM, Michal Simek wrote: >> [ ... ] >>> >>> Just to let you know issue is with i2c driver. Here is my output for the >>> record. >>> >> Thanks a lot for the update. >> >>> irps5401-i2c-3-43 >>> Adapter: i2c-0-mux (chan_id 2) >>> vin1: 11.56 V (min = +9.00 V, crit max = +14.00 V) >>> vin2: 11.56 V (min = +9.00 V, crit max = +14.00 V) >>> vin3: 11.56 V (min = +9.00 V, crit max = +14.00 V) >>> vin4: N/A >> >> This is interesting; it means that the rail is not active (?) or >> not supported, or maybe even that the driver has a bug. The second >> chip reports a value here, so I guess the rail is inactive. >> If possible, it would be desirable to detect this during probe >> and not try to report values for this rail. It would be great if >> you can find the time to figure out what is going on. > > I would assume that either that rail is not used in that board design and was disabled in the non-volatile config on the chip, or alternately the chip allows combining outputs C and D (i.e. 3 and 4) into a single output in which case only one will report valid data. Not sure offhand if there is a way to detect those cases from the PMBus interface at probe time. > I think it may be the output disable register (0x38). One would have to know the i2c address, read the register, and set page bits accordingly. Overall, I am not sure if it is worth the trouble. Maybe we should just just add a note to the driver documentation. Thanks, Guenter ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux driver for IRPS5401 - status reg not found 2020-04-09 21:23 ` Guenter Roeck @ 2020-04-10 7:19 ` Michal Simek 0 siblings, 0 replies; 14+ messages in thread From: Michal Simek @ 2020-04-10 7:19 UTC (permalink / raw) To: Guenter Roeck, Robert Hancock, monstr, Michal Simek; +Cc: linux-hwmon On 09. 04. 20 23:23, Guenter Roeck wrote: > On 4/9/20 8:30 AM, Robert Hancock wrote: >> On 2020-04-09 9:16 a.m., Guenter Roeck wrote: >>> Hi Michal, >>> >>> On 4/9/20 7:29 AM, Michal Simek wrote: >>> [ ... ] >>>> >>>> Just to let you know issue is with i2c driver. Here is my output for the >>>> record. >>>> >>> Thanks a lot for the update. >>> >>>> irps5401-i2c-3-43 >>>> Adapter: i2c-0-mux (chan_id 2) >>>> vin1: 11.56 V (min = +9.00 V, crit max = +14.00 V) >>>> vin2: 11.56 V (min = +9.00 V, crit max = +14.00 V) >>>> vin3: 11.56 V (min = +9.00 V, crit max = +14.00 V) >>>> vin4: N/A >>> >>> This is interesting; it means that the rail is not active (?) or >>> not supported, or maybe even that the driver has a bug. The second >>> chip reports a value here, so I guess the rail is inactive. >>> If possible, it would be desirable to detect this during probe >>> and not try to report values for this rail. It would be great if >>> you can find the time to figure out what is going on. >> >> I would assume that either that rail is not used in that board design and was disabled in the non-volatile config on the chip, or alternately the chip allows combining outputs C and D (i.e. 3 and 4) into a single output in which case only one will report valid data. Not sure offhand if there is a way to detect those cases from the PMBus interface at probe time. >> > I think it may be the output disable register (0x38). One would have > to know the i2c address, read the register, and set page bits > accordingly. Overall, I am not sure if it is worth the trouble. > Maybe we should just just add a note to the driver documentation. https://www.xilinx.com/support/documentation/boards_and_kits/zcu104/ug1267-zcu104-eval-bd.pdf page 83 0x43 is PHASE_C/D combined together a provide 1.2v. Thanks, Michal ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux driver for IRPS5401 - status reg not found 2020-03-30 15:24 ` Guenter Roeck 2020-03-30 15:42 ` Robert Hancock @ 2020-03-30 15:46 ` Michal Simek 2020-03-30 16:52 ` Guenter Roeck 1 sibling, 1 reply; 14+ messages in thread From: Michal Simek @ 2020-03-30 15:46 UTC (permalink / raw) To: Guenter Roeck, Michal Simek, Robert Hancock; +Cc: linux-hwmon On 30. 03. 20 17:24, Guenter Roeck wrote: > On 3/30/20 4:33 AM, Michal Simek wrote: >> Hi Robert and Guenter, >> >> Xilinx boards are using IRPS5401 chips and I have tried to use your driver. >> I have checked that u-boot can detect that devices and read it. >> >> ZynqMP> i2c probe >> Valid chip addresses: 0C 13 14 20 43 44 74 >> ZynqMP> i2c md 13 0 10 >> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ >> ZynqMP> i2c md 14 0 10 >> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ >> ZynqMP> i2c md 43 0 10 >> 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ >> ZynqMP> i2c md 44 0 10 >> 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ >> ZynqMP> >> >> Here is DT fragment which I use (it is under i2c mux) >> >> 185 irps5401_43: irps5401@43 { >> 186 compatible = "infineon,irps5401"; >> 187 reg = <0x43>; /* pmbus / i2c 0x13 */ > > Does that mean the mux is at 0x13 ? HW guys wrote that 0x13 is i2c address and 0x43 is pmbus address. > >> 188 }; >> 189 irps5401_4d: irps5401@44 { >> 190 compatible = "infineon,irps5401"; >> 191 reg = <0x44>; /* pmbus / i2c 0x14 */ > > Why _4d ? Sorry - I was checking board and 4d was address on early revision and didn't update it. > >> 192 }; >> >> I see that driver is used but with error. >> >> [ 37.553740] irps5401 3-0043: PMBus status register not found >> [ 37.559815] irps5401 3-0044: PMBus status register not found >> >> >> That's why I want to check with you what could be the problem. >> > > PMBus status registers are at 0x78 (byte) and 0x79 (word). The above > error is reported if reading both returns an error or 0xff / 0xffff, > which indicates that the chip is not accessible. > > I can say for sure that whatever is at 0x43/0x44, it is very likely > not an irps5401. If it was, at least registers 0x2 and 0x6 should report > different values, and 0x01 doesn't look much better (the lower 2 bits > should never be set). There is nothing else on schematics. When I try 0x13/0x14 I am getting. irps5401 3-0013: Failed to identify chip capabilities irps5401 3-0014: Failed to identify chip capabilities >> Also I would like to know if there is a way to disable it via any API. > > Not sure what you want to disable. The message ? The PMBus core needs > to have access to the chip to initialize. If there is no status register, > there is nothing it can do but to refuse to instantiate. When driver is probed I would like to be able from user space enable/disable the specific output from PMIC. This one has 4 VOUTs. > It might make sense to use i2cdetect / i2cget in Linux to determine > if the chips are accessible. I'd try reading the status registers (0x78 > to 0x7e), value registers (0x88 to 0x8d, 0x96, 0x97), manufacturer > id (0x99) and model (0x9a), and i2c device ID (0xad) and revision (0xae). ok. Will try. > >> One of this regulator is connected to another device which doesn't have >> access to it. It means before powering up this device there is a need to >> enable this power regulator. The best via any dedicated API. >> > > We can add regulator support to the PMBus core or to the irps5401 driver > if necessary (patches welcome), assuming the regulator in question is > handled by Linux. ok. Thanks, Michal ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux driver for IRPS5401 - status reg not found 2020-03-30 15:46 ` Michal Simek @ 2020-03-30 16:52 ` Guenter Roeck 0 siblings, 0 replies; 14+ messages in thread From: Guenter Roeck @ 2020-03-30 16:52 UTC (permalink / raw) To: Michal Simek, Robert Hancock; +Cc: linux-hwmon On 3/30/20 8:46 AM, Michal Simek wrote: > On 30. 03. 20 17:24, Guenter Roeck wrote: >> On 3/30/20 4:33 AM, Michal Simek wrote: >>> Hi Robert and Guenter, >>> >>> Xilinx boards are using IRPS5401 chips and I have tried to use your driver. >>> I have checked that u-boot can detect that devices and read it. >>> >>> ZynqMP> i2c probe >>> Valid chip addresses: 0C 13 14 20 43 44 74 >>> ZynqMP> i2c md 13 0 10 >>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ >>> ZynqMP> i2c md 14 0 10 >>> 0000: 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 ................ >>> ZynqMP> i2c md 43 0 10 >>> 0000: 00 98 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ >>> ZynqMP> i2c md 44 0 10 >>> 0000: 00 8a ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ >>> ZynqMP> >>> >>> Here is DT fragment which I use (it is under i2c mux) >>> >>> 185 irps5401_43: irps5401@43 { >>> 186 compatible = "infineon,irps5401"; >>> 187 reg = <0x43>; /* pmbus / i2c 0x13 */ >> >> Does that mean the mux is at 0x13 ? > > HW guys wrote that 0x13 is i2c address and 0x43 is pmbus address. > Sorry, I have no idea what that is supposed to mean. PMBus is SMBus which, for all practical purpose, is i2c. There is no difference between PMBus and I2C addresses. [ ... ] > > There is nothing else on schematics. When I try 0x13/0x14 I am getting. > irps5401 3-0013: Failed to identify chip capabilities > irps5401 3-0014: Failed to identify chip capabilities > Yes, the chips at those addresses don't look like PMBus chips. Maybe the chips are on other i2c busses. There must be at least four of them in the system. >>> Also I would like to know if there is a way to disable it via any API. >> >> Not sure what you want to disable. The message ? The PMBus core needs >> to have access to the chip to initialize. If there is no status register, >> there is nothing it can do but to refuse to instantiate. > > When driver is probed I would like to be able from user space > enable/disable the specific output from PMIC. This one has 4 VOUTs. > You mean to instantiate a regulator ? That is possible; see drivers/hwmon/pmbus/ltc2978.c for an example. I don't know if one can enable/disable regulators from userspace, though. Guenter ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-04-10 7:19 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-30 11:33 Linux driver for IRPS5401 - status reg not found Michal Simek 2020-03-30 15:24 ` Guenter Roeck 2020-03-30 15:42 ` Robert Hancock 2020-03-30 18:48 ` Guenter Roeck 2020-03-30 19:09 ` Robert Hancock 2020-03-30 19:48 ` Guenter Roeck 2020-03-31 12:38 ` Michal Simek 2020-04-09 14:29 ` Michal Simek 2020-04-09 15:16 ` Guenter Roeck 2020-04-09 15:30 ` Robert Hancock 2020-04-09 21:23 ` Guenter Roeck 2020-04-10 7:19 ` Michal Simek 2020-03-30 15:46 ` Michal Simek 2020-03-30 16:52 ` Guenter Roeck
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).