@@ -54,30 +54,6 @@ static int pli1209bc_read_word_data(struct i2c_client *client, int page,
}
}
-static int pli1209bc_write_byte(struct i2c_client *client, int page, u8 reg)
-{
- int ret;
-
- switch (reg) {
- case PMBUS_CLEAR_FAULTS:
- ret = pmbus_write_byte(client, page, reg);
- /*
- * PLI1209 takes 230 usec to execute the CLEAR_FAULTS command.
- * During that time it's busy and NACKs all requests on the
- * SMBUS interface. It also NACKs reads on PMBUS_STATUS_BYTE
- * making it impossible to poll the BUSY flag.
- *
- * Just wait for not BUSY unconditionally.
- */
- usleep_range(250, 300);
- break;
- default:
- ret = -ENODATA;
- break;
- }
- return ret;
-}
-
#if IS_ENABLED(CONFIG_SENSORS_PLI1209BC_REGULATOR)
static const struct regulator_desc pli1209bc_reg_desc = {
.name = "vout2",
@@ -127,7 +103,7 @@ static struct pmbus_driver_info pli1209bc_info = {
| PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP
| PMBUS_HAVE_STATUS_IOUT | PMBUS_HAVE_STATUS_INPUT,
.read_word_data = pli1209bc_read_word_data,
- .write_byte = pli1209bc_write_byte,
+ .write_delay = 250,
#if IS_ENABLED(CONFIG_SENSORS_PLI1209BC_REGULATOR)
.num_regulators = 1,
.reg_desc = &pli1209bc_reg_desc,
Tests on PLI12096bc showed that sometimes a small delay is necessary after a write operation before a new operation can be processed. If not respected the device will probably NACK the data phase of the SMBus transaction. Tests showed that the probability to observe transaction errors can be raised by either reading sensor data or toggling the regulator enable. Further tests showed that 250 microseconds, as used previously for the CLEAR_FAULTS workaround, is sufficient. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> --- drivers/hwmon/pmbus/pli1209bc.c | 26 +------------------------- 1 file changed, 1 insertion(+), 25 deletions(-)