Re: [PATCH 0/1] hwmon: (pmbus_core) Relative encoding of vout related commands

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/15/24 08:18, Lars Petter Mostad wrote:
PMBus 1.3 allows for relative encoding of voltages in certain output
voltage related commands. I'm starting this thread to ask if adding support
for this, either by me or someone else, is of interest. I have made an
initial attempt to add support that is adequate for my needs. I have
included the patch for discussion. I don't expect it to be accepted as is.

I'm working on the software for an ARM64 based board that uses the
TDK FS1412, which uses relative encoding. This is the only chip that uses
this feature that I have access to. I only have access to this chip on this
board, so I'm only able to test it on this architecture. I have to use the
kernel sources from NXPs LLDP project, which ATTOW is based on kernel
6.1.55. I'm not able to test on a newer kernel at the moment. The board is
fairly expensive, so I don't dare test setting voltages. I have only tested
monitoring voltages.

In relative mode, certain output voltage related commands (e.g.
VOUT_MARGIN_HIGH) are encoded relative to the nominal value (VOUT_COMMAND).
If e.g. the high margin is to be 10% above the nominal value,
VOUT_MARGIN_HIGH is set to 1.1. This factor is encoded the same way as
VOUT_COMMAND (i.e. as indicated by VOUT_MODE).

I have been a little unsure about how to best organize the changes.
Decoding the relative values requires access to the current value of
VOUT_COMMAND. I decided to handle it the same way exponent is handled.
I placed the relevant information next to exponent in pmbus_data.
vout_mode_relative is true if relative encoding is used, vout_command
stores what is believed to be the current VOUT_COMMAND. As exponent,
vout_mode_relative is set during decoding of VOUT_MODE in
pmbus_identify_common.

I decided to assume that VOUT_COMMAND is not changed outside the driver,
as this is also done for VOUT_MODE. VOUT_COMMAND is read and saved during
pmbus_init_common. It is also saved to vout_command during
pmbus_regulator_set_voltage.

pmbus_regulator_set_voltage usually clamps the requested voltage to be
between VOUT_MARGIN_LOW and VOUT_MARGIN_HIGH. This does not make sense in
relative mode, as the margins move with the requested voltage. This part is
skipped in relative mode.

pmbus_reg2data does the actual relative decoding. The pmbus_reg2data_*
functions return the register value multiplied by 1000, which in relative
mode means the permilleage of the nominal value. If we are in relative mode,
and the current register is one of the registers that can use relative
decoding, the permilleage value is multiplied with the stored vout_command.
Currently, the vout_command in pmbus_data is stored decoded, i.e. 1000x and
rounded to an integer. Better precision could be achieved if the
multiplication was done inside each pmbus_reg2data_*, before the rounding
to integer, but this would be a bit messier.

I welcome comments on wether this is of interest, and what is needed to
get it into an acceptable state!


My major concern is unintended side effects. In drivers/hwmon/pmbus/tps546d24.c
we "solve" the problem by explicitly setting absolute mode. Would that help
for the time being ?

I'd prefer to get some experience with actual chips (meaning evaluation boards)
before trying to provide a supposedly generic solution which retains relative mode.
I ordered a couple of evaluation boards for TPS546D24 variants. The evaluation
board for FS1412 is a bit too expensive for my liking, so I don't really want
to order that one. Do you know of any other chips supporting this functionality ?

Thanks,
Guenter





[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux