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
