Linux Hardware Monitor development
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@xilinx.com>
To: Guenter Roeck <linux@roeck-us.net>,
	Michal Simek <michal.simek@xilinx.com>,
	Robert Hancock <hancock@sedsystems.ca>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: Linux driver for IRPS5401 - status reg not found
Date: Mon, 30 Mar 2020 17:46:27 +0200	[thread overview]
Message-ID: <f6f3735d-1af2-4d57-d8d5-3b87e9be8b32@xilinx.com> (raw)
In-Reply-To: <44d8631a-618c-a061-d9ca-d8030dd8a420@roeck-us.net>

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


  parent reply	other threads:[~2020-03-30 15:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2020-03-30 16:52     ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f6f3735d-1af2-4d57-d8d5-3b87e9be8b32@xilinx.com \
    --to=michal.simek@xilinx.com \
    --cc=hancock@sedsystems.ca \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox