linux-hwmon.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: 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 08:24:30 -0700	[thread overview]
Message-ID: <44d8631a-618c-a061-d9ca-d8030dd8a420@roeck-us.net> (raw)
In-Reply-To: <e303166b-4d7a-d2b9-a5c0-fd4de8d22a49@xilinx.com>

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

  reply	other threads:[~2020-03-30 15:24 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 [this message]
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

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=44d8631a-618c-a061-d9ca-d8030dd8a420@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=hancock@sedsystems.ca \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=michal.simek@xilinx.com \
    /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;
as well as URLs for NNTP newsgroup(s).