public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Duke Du <dukedu83@gmail.com>
Cc: jdelvare@suse.com, corbet@lwn.net, linux-hwmon@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	fran.hsu@quantatw.com, charles.hsu@quantatw.com,
	george.hung@quantatw.com, duke.du@quantatw.com
Subject: Re: [PATCH v3] hwmon: Add driver for the TEXAS TPS546D24 Buck Converter.
Date: Thu, 25 Aug 2022 05:59:32 -0700	[thread overview]
Message-ID: <20220825125932.GA598991@roeck-us.net> (raw)
In-Reply-To: <CAJqQiD2+6jo3h5Ymd2e7Th634gBZgijBxp5xRHB=h7-__8N0uQ@mail.gmail.com>

On Thu, Aug 25, 2022 at 07:22:34PM +0800, Duke Du wrote:
> > >
> > > When the vout mode bit 7 is set, we update vout mode and clear bit 7
> > > in the driver probe function, this operation is the same as changing
> > > the reported value of PMBUS_VOUT_MODE ?
> >
> > Absolutely not. When changing the bit in the register, the chip operation
> > mode changes, and the associated values (VOUT*) change from relative
> > to absolute mode. When changing the value reported by the chip, nothing
> > changes from the chip side, it still operates in relative mode, and all
> > VOUT* registers are set to relative mode.
> >
> > Guenter
> >
> Got it, thanks for your reply !!
> 
> Another question, If we don't need to change the mode from relative to absolute
> mode, could we just change the PMBus core to determine vout mode with only
> bit 5 and 6 ?
> And clearing the bit 7 in the driver (tps546d24.c) probe function
> would not be needed, right ?
> 
Sorry, you lost me. The problem is that the chip supports relative mode,
and that the PMBus core doesn't. We can not just ignore bit 7 of vout mode;
that would result in bad data for all vout limit attributes since the PMBus
core (currently) only supports absolute mode. We could add support for
relative mode to the PMBus core, but that would be a major effort.
This is why I suggested to change the chip mode to absolute mode in the
tps546d24 driver. If you don't want to do that, you'll have to implement
relative mode support in the PMBus core. I'll be happy to review patches,
but you'll have to implement and test it since I have neither the time
nor the necessary hardware to do it myself.

Thanks,
Guenter

  reply	other threads:[~2022-08-25 12:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-19  3:04 [PATCH v3] hwmon: Add driver for the TEXAS TPS546D24 Buck Converter Duke Du
2022-08-19 13:34 ` Guenter Roeck
2022-08-24  5:58   ` Duke Du
2022-08-24 10:50     ` Guenter Roeck
2022-08-25 11:22       ` Duke Du
2022-08-25 12:59         ` Guenter Roeck [this message]
2022-08-25 14:43 ` Krzysztof Kozlowski

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=20220825125932.GA598991@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=charles.hsu@quantatw.com \
    --cc=corbet@lwn.net \
    --cc=duke.du@quantatw.com \
    --cc=dukedu83@gmail.com \
    --cc=fran.hsu@quantatw.com \
    --cc=george.hung@quantatw.com \
    --cc=jdelvare@suse.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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