2019-02-09 08:37:19 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
|
/*
|
|
|
|
|
* RTC interface for Wilco Embedded Controller with R/W abilities
|
|
|
|
|
*
|
|
|
|
|
* Copyright 2018 Google LLC
|
|
|
|
|
*
|
|
|
|
|
* The corresponding platform device is typically registered in
|
|
|
|
|
* drivers/platform/chrome/wilco_ec/core.c
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/bcd.h>
|
|
|
|
|
#include <linux/err.h>
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
|
#include <linux/platform_device.h>
|
|
|
|
|
#include <linux/platform_data/wilco-ec.h>
|
|
|
|
|
#include <linux/rtc.h>
|
|
|
|
|
#include <linux/timekeeping.h>
|
|
|
|
|
|
|
|
|
|
#define EC_COMMAND_CMOS 0x7c
|
|
|
|
|
#define EC_CMOS_TOD_WRITE 0x02
|
|
|
|
|
#define EC_CMOS_TOD_READ 0x08
|
|
|
|
|
|
platform/chrome: wilco_ec: Standardize mailbox interface
The current API for the wilco EC mailbox interface is bad.
It assumes that most messages sent to the EC follow a similar structure,
with a command byte in MBOX[0], followed by a junk byte, followed by
actual data. This doesn't happen in several cases, such as setting the
RTC time, using the raw debugfs interface, and reading or writing
properties such as the Peak Shift policy (this last to be submitted soon).
Similarly for the response message from the EC, the current interface
assumes that the first byte of data is always 0, and the second byte
is unused. However, in both setting and getting the RTC time, in the
debugfs interface, and for reading and writing properties, this isn't
true.
The current way to resolve this is to use WILCO_EC_FLAG_RAW* flags to
specify when and when not to skip these initial bytes in the sent and
received message. They are confusing and used so much that they are
normal, and not exceptions. In addition, the first byte of
response in the debugfs interface is still always skipped, which is
weird, since this raw interface should be giving the entire result.
Additionally, sent messages assume the first byte is a command, and so
struct wilco_ec_message contains the "command" field. In setting or
getting properties however, the first byte is not a command, and so this
field has to be filled with a byte that isn't actually a command. This
is again inconsistent.
wilco_ec_message contains a result field as well, copied from
wilco_ec_response->result. The message result field should be removed:
if the message fails, the cause is already logged, and the callers are
alerted. They will never care about the actual state of the result flag.
These flags and different cases make the wilco_ec_transfer() function,
used in wilco_ec_mailbox(), really gross, dealing with a bunch of
different cases. It's difficult to figure out what it is doing.
Finally, making these assumptions about the structure of a message make
it so that the messages do not correspond well with the specification
for the EC's mailbox interface. For instance, this interface
specification may say that MBOX[9] in the received message contains
some information, but the calling code needs to remember that the first
byte of response is always skipped, and because it didn't set the
RESPONSE_RAW flag, the next byte is also skipped, so this information
is actually contained within wilco_ec_message->response_data[7]. This
makes it difficult to maintain this code in the future.
To fix these problems this patch standardizes the mailbox interface by:
- Removing the WILCO_EC_FLAG_RAW* flags
- Removing the command and reserved_raw bytes from wilco_ec_request
- Removing the mbox0 byte from wilco_ec_response
- Simplifying wilco_ec_transfer() because of these changes
- Gives the callers of wilco_ec_mailbox() the responsibility of exactly
and consistently defining the structure of the mailbox request and
response
- Removing command and result from wilco_ec_message.
This results in the reduction of total code, and makes it much more
maintainable and understandable.
Signed-off-by: Nick Crews <ncrews@chromium.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-04-05 06:54:15 +08:00
|
|
|
/* Message sent to the EC to request the current time. */
|
|
|
|
|
struct ec_rtc_read_request {
|
|
|
|
|
u8 command;
|
|
|
|
|
u8 reserved;
|
|
|
|
|
u8 param;
|
|
|
|
|
} __packed;
|
|
|
|
|
static struct ec_rtc_read_request read_rq = {
|
|
|
|
|
.command = EC_COMMAND_CMOS,
|
|
|
|
|
.param = EC_CMOS_TOD_READ,
|
|
|
|
|
};
|
|
|
|
|
|
2019-02-09 08:37:19 +08:00
|
|
|
/**
|
platform/chrome: wilco_ec: Standardize mailbox interface
The current API for the wilco EC mailbox interface is bad.
It assumes that most messages sent to the EC follow a similar structure,
with a command byte in MBOX[0], followed by a junk byte, followed by
actual data. This doesn't happen in several cases, such as setting the
RTC time, using the raw debugfs interface, and reading or writing
properties such as the Peak Shift policy (this last to be submitted soon).
Similarly for the response message from the EC, the current interface
assumes that the first byte of data is always 0, and the second byte
is unused. However, in both setting and getting the RTC time, in the
debugfs interface, and for reading and writing properties, this isn't
true.
The current way to resolve this is to use WILCO_EC_FLAG_RAW* flags to
specify when and when not to skip these initial bytes in the sent and
received message. They are confusing and used so much that they are
normal, and not exceptions. In addition, the first byte of
response in the debugfs interface is still always skipped, which is
weird, since this raw interface should be giving the entire result.
Additionally, sent messages assume the first byte is a command, and so
struct wilco_ec_message contains the "command" field. In setting or
getting properties however, the first byte is not a command, and so this
field has to be filled with a byte that isn't actually a command. This
is again inconsistent.
wilco_ec_message contains a result field as well, copied from
wilco_ec_response->result. The message result field should be removed:
if the message fails, the cause is already logged, and the callers are
alerted. They will never care about the actual state of the result flag.
These flags and different cases make the wilco_ec_transfer() function,
used in wilco_ec_mailbox(), really gross, dealing with a bunch of
different cases. It's difficult to figure out what it is doing.
Finally, making these assumptions about the structure of a message make
it so that the messages do not correspond well with the specification
for the EC's mailbox interface. For instance, this interface
specification may say that MBOX[9] in the received message contains
some information, but the calling code needs to remember that the first
byte of response is always skipped, and because it didn't set the
RESPONSE_RAW flag, the next byte is also skipped, so this information
is actually contained within wilco_ec_message->response_data[7]. This
makes it difficult to maintain this code in the future.
To fix these problems this patch standardizes the mailbox interface by:
- Removing the WILCO_EC_FLAG_RAW* flags
- Removing the command and reserved_raw bytes from wilco_ec_request
- Removing the mbox0 byte from wilco_ec_response
- Simplifying wilco_ec_transfer() because of these changes
- Gives the callers of wilco_ec_mailbox() the responsibility of exactly
and consistently defining the structure of the mailbox request and
response
- Removing command and result from wilco_ec_message.
This results in the reduction of total code, and makes it much more
maintainable and understandable.
Signed-off-by: Nick Crews <ncrews@chromium.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-04-05 06:54:15 +08:00
|
|
|
* struct ec_rtc_read_response - Format of RTC returned by EC.
|
|
|
|
|
* @reserved: Unused byte
|
2019-02-09 08:37:19 +08:00
|
|
|
* @second: Second value (0..59)
|
|
|
|
|
* @minute: Minute value (0..59)
|
|
|
|
|
* @hour: Hour value (0..23)
|
|
|
|
|
* @day: Day value (1..31)
|
|
|
|
|
* @month: Month value (1..12)
|
|
|
|
|
* @year: Year value (full year % 100)
|
|
|
|
|
* @century: Century value (full year / 100)
|
|
|
|
|
*
|
|
|
|
|
* All values are presented in binary (not BCD).
|
|
|
|
|
*/
|
platform/chrome: wilco_ec: Standardize mailbox interface
The current API for the wilco EC mailbox interface is bad.
It assumes that most messages sent to the EC follow a similar structure,
with a command byte in MBOX[0], followed by a junk byte, followed by
actual data. This doesn't happen in several cases, such as setting the
RTC time, using the raw debugfs interface, and reading or writing
properties such as the Peak Shift policy (this last to be submitted soon).
Similarly for the response message from the EC, the current interface
assumes that the first byte of data is always 0, and the second byte
is unused. However, in both setting and getting the RTC time, in the
debugfs interface, and for reading and writing properties, this isn't
true.
The current way to resolve this is to use WILCO_EC_FLAG_RAW* flags to
specify when and when not to skip these initial bytes in the sent and
received message. They are confusing and used so much that they are
normal, and not exceptions. In addition, the first byte of
response in the debugfs interface is still always skipped, which is
weird, since this raw interface should be giving the entire result.
Additionally, sent messages assume the first byte is a command, and so
struct wilco_ec_message contains the "command" field. In setting or
getting properties however, the first byte is not a command, and so this
field has to be filled with a byte that isn't actually a command. This
is again inconsistent.
wilco_ec_message contains a result field as well, copied from
wilco_ec_response->result. The message result field should be removed:
if the message fails, the cause is already logged, and the callers are
alerted. They will never care about the actual state of the result flag.
These flags and different cases make the wilco_ec_transfer() function,
used in wilco_ec_mailbox(), really gross, dealing with a bunch of
different cases. It's difficult to figure out what it is doing.
Finally, making these assumptions about the structure of a message make
it so that the messages do not correspond well with the specification
for the EC's mailbox interface. For instance, this interface
specification may say that MBOX[9] in the received message contains
some information, but the calling code needs to remember that the first
byte of response is always skipped, and because it didn't set the
RESPONSE_RAW flag, the next byte is also skipped, so this information
is actually contained within wilco_ec_message->response_data[7]. This
makes it difficult to maintain this code in the future.
To fix these problems this patch standardizes the mailbox interface by:
- Removing the WILCO_EC_FLAG_RAW* flags
- Removing the command and reserved_raw bytes from wilco_ec_request
- Removing the mbox0 byte from wilco_ec_response
- Simplifying wilco_ec_transfer() because of these changes
- Gives the callers of wilco_ec_mailbox() the responsibility of exactly
and consistently defining the structure of the mailbox request and
response
- Removing command and result from wilco_ec_message.
This results in the reduction of total code, and makes it much more
maintainable and understandable.
Signed-off-by: Nick Crews <ncrews@chromium.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-04-05 06:54:15 +08:00
|
|
|
struct ec_rtc_read_response {
|
|
|
|
|
u8 reserved;
|
2019-02-09 08:37:19 +08:00
|
|
|
u8 second;
|
|
|
|
|
u8 minute;
|
|
|
|
|
u8 hour;
|
|
|
|
|
u8 day;
|
|
|
|
|
u8 month;
|
|
|
|
|
u8 year;
|
|
|
|
|
u8 century;
|
|
|
|
|
} __packed;
|
|
|
|
|
|
|
|
|
|
/**
|
platform/chrome: wilco_ec: Standardize mailbox interface
The current API for the wilco EC mailbox interface is bad.
It assumes that most messages sent to the EC follow a similar structure,
with a command byte in MBOX[0], followed by a junk byte, followed by
actual data. This doesn't happen in several cases, such as setting the
RTC time, using the raw debugfs interface, and reading or writing
properties such as the Peak Shift policy (this last to be submitted soon).
Similarly for the response message from the EC, the current interface
assumes that the first byte of data is always 0, and the second byte
is unused. However, in both setting and getting the RTC time, in the
debugfs interface, and for reading and writing properties, this isn't
true.
The current way to resolve this is to use WILCO_EC_FLAG_RAW* flags to
specify when and when not to skip these initial bytes in the sent and
received message. They are confusing and used so much that they are
normal, and not exceptions. In addition, the first byte of
response in the debugfs interface is still always skipped, which is
weird, since this raw interface should be giving the entire result.
Additionally, sent messages assume the first byte is a command, and so
struct wilco_ec_message contains the "command" field. In setting or
getting properties however, the first byte is not a command, and so this
field has to be filled with a byte that isn't actually a command. This
is again inconsistent.
wilco_ec_message contains a result field as well, copied from
wilco_ec_response->result. The message result field should be removed:
if the message fails, the cause is already logged, and the callers are
alerted. They will never care about the actual state of the result flag.
These flags and different cases make the wilco_ec_transfer() function,
used in wilco_ec_mailbox(), really gross, dealing with a bunch of
different cases. It's difficult to figure out what it is doing.
Finally, making these assumptions about the structure of a message make
it so that the messages do not correspond well with the specification
for the EC's mailbox interface. For instance, this interface
specification may say that MBOX[9] in the received message contains
some information, but the calling code needs to remember that the first
byte of response is always skipped, and because it didn't set the
RESPONSE_RAW flag, the next byte is also skipped, so this information
is actually contained within wilco_ec_message->response_data[7]. This
makes it difficult to maintain this code in the future.
To fix these problems this patch standardizes the mailbox interface by:
- Removing the WILCO_EC_FLAG_RAW* flags
- Removing the command and reserved_raw bytes from wilco_ec_request
- Removing the mbox0 byte from wilco_ec_response
- Simplifying wilco_ec_transfer() because of these changes
- Gives the callers of wilco_ec_mailbox() the responsibility of exactly
and consistently defining the structure of the mailbox request and
response
- Removing command and result from wilco_ec_message.
This results in the reduction of total code, and makes it much more
maintainable and understandable.
Signed-off-by: Nick Crews <ncrews@chromium.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-04-05 06:54:15 +08:00
|
|
|
* struct ec_rtc_write_request - Format of RTC sent to the EC.
|
|
|
|
|
* @command: Always EC_COMMAND_CMOS
|
|
|
|
|
* @reserved: Unused byte
|
|
|
|
|
* @param: Always EC_CMOS_TOD_WRITE
|
2019-02-09 08:37:19 +08:00
|
|
|
* @century: Century value (full year / 100)
|
|
|
|
|
* @year: Year value (full year % 100)
|
|
|
|
|
* @month: Month value (1..12)
|
|
|
|
|
* @day: Day value (1..31)
|
|
|
|
|
* @hour: Hour value (0..23)
|
|
|
|
|
* @minute: Minute value (0..59)
|
|
|
|
|
* @second: Second value (0..59)
|
|
|
|
|
* @weekday: Day of the week (0=Saturday)
|
|
|
|
|
*
|
|
|
|
|
* All values are presented in BCD.
|
|
|
|
|
*/
|
platform/chrome: wilco_ec: Standardize mailbox interface
The current API for the wilco EC mailbox interface is bad.
It assumes that most messages sent to the EC follow a similar structure,
with a command byte in MBOX[0], followed by a junk byte, followed by
actual data. This doesn't happen in several cases, such as setting the
RTC time, using the raw debugfs interface, and reading or writing
properties such as the Peak Shift policy (this last to be submitted soon).
Similarly for the response message from the EC, the current interface
assumes that the first byte of data is always 0, and the second byte
is unused. However, in both setting and getting the RTC time, in the
debugfs interface, and for reading and writing properties, this isn't
true.
The current way to resolve this is to use WILCO_EC_FLAG_RAW* flags to
specify when and when not to skip these initial bytes in the sent and
received message. They are confusing and used so much that they are
normal, and not exceptions. In addition, the first byte of
response in the debugfs interface is still always skipped, which is
weird, since this raw interface should be giving the entire result.
Additionally, sent messages assume the first byte is a command, and so
struct wilco_ec_message contains the "command" field. In setting or
getting properties however, the first byte is not a command, and so this
field has to be filled with a byte that isn't actually a command. This
is again inconsistent.
wilco_ec_message contains a result field as well, copied from
wilco_ec_response->result. The message result field should be removed:
if the message fails, the cause is already logged, and the callers are
alerted. They will never care about the actual state of the result flag.
These flags and different cases make the wilco_ec_transfer() function,
used in wilco_ec_mailbox(), really gross, dealing with a bunch of
different cases. It's difficult to figure out what it is doing.
Finally, making these assumptions about the structure of a message make
it so that the messages do not correspond well with the specification
for the EC's mailbox interface. For instance, this interface
specification may say that MBOX[9] in the received message contains
some information, but the calling code needs to remember that the first
byte of response is always skipped, and because it didn't set the
RESPONSE_RAW flag, the next byte is also skipped, so this information
is actually contained within wilco_ec_message->response_data[7]. This
makes it difficult to maintain this code in the future.
To fix these problems this patch standardizes the mailbox interface by:
- Removing the WILCO_EC_FLAG_RAW* flags
- Removing the command and reserved_raw bytes from wilco_ec_request
- Removing the mbox0 byte from wilco_ec_response
- Simplifying wilco_ec_transfer() because of these changes
- Gives the callers of wilco_ec_mailbox() the responsibility of exactly
and consistently defining the structure of the mailbox request and
response
- Removing command and result from wilco_ec_message.
This results in the reduction of total code, and makes it much more
maintainable and understandable.
Signed-off-by: Nick Crews <ncrews@chromium.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-04-05 06:54:15 +08:00
|
|
|
struct ec_rtc_write_request {
|
|
|
|
|
u8 command;
|
|
|
|
|
u8 reserved;
|
2019-02-09 08:37:19 +08:00
|
|
|
u8 param;
|
|
|
|
|
u8 century;
|
|
|
|
|
u8 year;
|
|
|
|
|
u8 month;
|
|
|
|
|
u8 day;
|
|
|
|
|
u8 hour;
|
|
|
|
|
u8 minute;
|
|
|
|
|
u8 second;
|
|
|
|
|
u8 weekday;
|
|
|
|
|
} __packed;
|
|
|
|
|
|
|
|
|
|
static int wilco_ec_rtc_read(struct device *dev, struct rtc_time *tm)
|
|
|
|
|
{
|
|
|
|
|
struct wilco_ec_device *ec = dev_get_drvdata(dev->parent);
|
platform/chrome: wilco_ec: Standardize mailbox interface
The current API for the wilco EC mailbox interface is bad.
It assumes that most messages sent to the EC follow a similar structure,
with a command byte in MBOX[0], followed by a junk byte, followed by
actual data. This doesn't happen in several cases, such as setting the
RTC time, using the raw debugfs interface, and reading or writing
properties such as the Peak Shift policy (this last to be submitted soon).
Similarly for the response message from the EC, the current interface
assumes that the first byte of data is always 0, and the second byte
is unused. However, in both setting and getting the RTC time, in the
debugfs interface, and for reading and writing properties, this isn't
true.
The current way to resolve this is to use WILCO_EC_FLAG_RAW* flags to
specify when and when not to skip these initial bytes in the sent and
received message. They are confusing and used so much that they are
normal, and not exceptions. In addition, the first byte of
response in the debugfs interface is still always skipped, which is
weird, since this raw interface should be giving the entire result.
Additionally, sent messages assume the first byte is a command, and so
struct wilco_ec_message contains the "command" field. In setting or
getting properties however, the first byte is not a command, and so this
field has to be filled with a byte that isn't actually a command. This
is again inconsistent.
wilco_ec_message contains a result field as well, copied from
wilco_ec_response->result. The message result field should be removed:
if the message fails, the cause is already logged, and the callers are
alerted. They will never care about the actual state of the result flag.
These flags and different cases make the wilco_ec_transfer() function,
used in wilco_ec_mailbox(), really gross, dealing with a bunch of
different cases. It's difficult to figure out what it is doing.
Finally, making these assumptions about the structure of a message make
it so that the messages do not correspond well with the specification
for the EC's mailbox interface. For instance, this interface
specification may say that MBOX[9] in the received message contains
some information, but the calling code needs to remember that the first
byte of response is always skipped, and because it didn't set the
RESPONSE_RAW flag, the next byte is also skipped, so this information
is actually contained within wilco_ec_message->response_data[7]. This
makes it difficult to maintain this code in the future.
To fix these problems this patch standardizes the mailbox interface by:
- Removing the WILCO_EC_FLAG_RAW* flags
- Removing the command and reserved_raw bytes from wilco_ec_request
- Removing the mbox0 byte from wilco_ec_response
- Simplifying wilco_ec_transfer() because of these changes
- Gives the callers of wilco_ec_mailbox() the responsibility of exactly
and consistently defining the structure of the mailbox request and
response
- Removing command and result from wilco_ec_message.
This results in the reduction of total code, and makes it much more
maintainable and understandable.
Signed-off-by: Nick Crews <ncrews@chromium.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-04-05 06:54:15 +08:00
|
|
|
struct ec_rtc_read_response rtc;
|
|
|
|
|
struct wilco_ec_message msg;
|
2019-02-09 08:37:19 +08:00
|
|
|
int ret;
|
|
|
|
|
|
platform/chrome: wilco_ec: Standardize mailbox interface
The current API for the wilco EC mailbox interface is bad.
It assumes that most messages sent to the EC follow a similar structure,
with a command byte in MBOX[0], followed by a junk byte, followed by
actual data. This doesn't happen in several cases, such as setting the
RTC time, using the raw debugfs interface, and reading or writing
properties such as the Peak Shift policy (this last to be submitted soon).
Similarly for the response message from the EC, the current interface
assumes that the first byte of data is always 0, and the second byte
is unused. However, in both setting and getting the RTC time, in the
debugfs interface, and for reading and writing properties, this isn't
true.
The current way to resolve this is to use WILCO_EC_FLAG_RAW* flags to
specify when and when not to skip these initial bytes in the sent and
received message. They are confusing and used so much that they are
normal, and not exceptions. In addition, the first byte of
response in the debugfs interface is still always skipped, which is
weird, since this raw interface should be giving the entire result.
Additionally, sent messages assume the first byte is a command, and so
struct wilco_ec_message contains the "command" field. In setting or
getting properties however, the first byte is not a command, and so this
field has to be filled with a byte that isn't actually a command. This
is again inconsistent.
wilco_ec_message contains a result field as well, copied from
wilco_ec_response->result. The message result field should be removed:
if the message fails, the cause is already logged, and the callers are
alerted. They will never care about the actual state of the result flag.
These flags and different cases make the wilco_ec_transfer() function,
used in wilco_ec_mailbox(), really gross, dealing with a bunch of
different cases. It's difficult to figure out what it is doing.
Finally, making these assumptions about the structure of a message make
it so that the messages do not correspond well with the specification
for the EC's mailbox interface. For instance, this interface
specification may say that MBOX[9] in the received message contains
some information, but the calling code needs to remember that the first
byte of response is always skipped, and because it didn't set the
RESPONSE_RAW flag, the next byte is also skipped, so this information
is actually contained within wilco_ec_message->response_data[7]. This
makes it difficult to maintain this code in the future.
To fix these problems this patch standardizes the mailbox interface by:
- Removing the WILCO_EC_FLAG_RAW* flags
- Removing the command and reserved_raw bytes from wilco_ec_request
- Removing the mbox0 byte from wilco_ec_response
- Simplifying wilco_ec_transfer() because of these changes
- Gives the callers of wilco_ec_mailbox() the responsibility of exactly
and consistently defining the structure of the mailbox request and
response
- Removing command and result from wilco_ec_message.
This results in the reduction of total code, and makes it much more
maintainable and understandable.
Signed-off-by: Nick Crews <ncrews@chromium.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-04-05 06:54:15 +08:00
|
|
|
memset(&msg, 0, sizeof(msg));
|
|
|
|
|
msg.type = WILCO_EC_MSG_LEGACY;
|
|
|
|
|
msg.request_data = &read_rq;
|
|
|
|
|
msg.request_size = sizeof(read_rq);
|
|
|
|
|
msg.response_data = &rtc;
|
|
|
|
|
msg.response_size = sizeof(rtc);
|
|
|
|
|
|
2019-02-09 08:37:19 +08:00
|
|
|
ret = wilco_ec_mailbox(ec, &msg);
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
|
|
tm->tm_sec = rtc.second;
|
|
|
|
|
tm->tm_min = rtc.minute;
|
|
|
|
|
tm->tm_hour = rtc.hour;
|
|
|
|
|
tm->tm_mday = rtc.day;
|
|
|
|
|
tm->tm_mon = rtc.month - 1;
|
|
|
|
|
tm->tm_year = rtc.year + (rtc.century * 100) - 1900;
|
2019-10-04 22:26:08 +08:00
|
|
|
/* Ignore other tm fields, man rtc says userspace shouldn't use them. */
|
2019-02-09 08:37:19 +08:00
|
|
|
|
2019-10-04 22:26:08 +08:00
|
|
|
if (rtc_valid_tm(tm)) {
|
|
|
|
|
dev_err(dev, "Time from RTC is invalid: %ptRr\n", tm);
|
|
|
|
|
return -EIO;
|
|
|
|
|
}
|
2019-02-09 08:37:19 +08:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int wilco_ec_rtc_write(struct device *dev, struct rtc_time *tm)
|
|
|
|
|
{
|
|
|
|
|
struct wilco_ec_device *ec = dev_get_drvdata(dev->parent);
|
platform/chrome: wilco_ec: Standardize mailbox interface
The current API for the wilco EC mailbox interface is bad.
It assumes that most messages sent to the EC follow a similar structure,
with a command byte in MBOX[0], followed by a junk byte, followed by
actual data. This doesn't happen in several cases, such as setting the
RTC time, using the raw debugfs interface, and reading or writing
properties such as the Peak Shift policy (this last to be submitted soon).
Similarly for the response message from the EC, the current interface
assumes that the first byte of data is always 0, and the second byte
is unused. However, in both setting and getting the RTC time, in the
debugfs interface, and for reading and writing properties, this isn't
true.
The current way to resolve this is to use WILCO_EC_FLAG_RAW* flags to
specify when and when not to skip these initial bytes in the sent and
received message. They are confusing and used so much that they are
normal, and not exceptions. In addition, the first byte of
response in the debugfs interface is still always skipped, which is
weird, since this raw interface should be giving the entire result.
Additionally, sent messages assume the first byte is a command, and so
struct wilco_ec_message contains the "command" field. In setting or
getting properties however, the first byte is not a command, and so this
field has to be filled with a byte that isn't actually a command. This
is again inconsistent.
wilco_ec_message contains a result field as well, copied from
wilco_ec_response->result. The message result field should be removed:
if the message fails, the cause is already logged, and the callers are
alerted. They will never care about the actual state of the result flag.
These flags and different cases make the wilco_ec_transfer() function,
used in wilco_ec_mailbox(), really gross, dealing with a bunch of
different cases. It's difficult to figure out what it is doing.
Finally, making these assumptions about the structure of a message make
it so that the messages do not correspond well with the specification
for the EC's mailbox interface. For instance, this interface
specification may say that MBOX[9] in the received message contains
some information, but the calling code needs to remember that the first
byte of response is always skipped, and because it didn't set the
RESPONSE_RAW flag, the next byte is also skipped, so this information
is actually contained within wilco_ec_message->response_data[7]. This
makes it difficult to maintain this code in the future.
To fix these problems this patch standardizes the mailbox interface by:
- Removing the WILCO_EC_FLAG_RAW* flags
- Removing the command and reserved_raw bytes from wilco_ec_request
- Removing the mbox0 byte from wilco_ec_response
- Simplifying wilco_ec_transfer() because of these changes
- Gives the callers of wilco_ec_mailbox() the responsibility of exactly
and consistently defining the structure of the mailbox request and
response
- Removing command and result from wilco_ec_message.
This results in the reduction of total code, and makes it much more
maintainable and understandable.
Signed-off-by: Nick Crews <ncrews@chromium.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-04-05 06:54:15 +08:00
|
|
|
struct ec_rtc_write_request rtc;
|
|
|
|
|
struct wilco_ec_message msg;
|
2019-02-09 08:37:19 +08:00
|
|
|
int year = tm->tm_year + 1900;
|
|
|
|
|
/*
|
|
|
|
|
* Convert from 0=Sunday to 0=Saturday for the EC
|
|
|
|
|
* We DO need to set weekday because the EC controls battery charging
|
|
|
|
|
* schedules that depend on the day of the week.
|
|
|
|
|
*/
|
|
|
|
|
int wday = tm->tm_wday == 6 ? 0 : tm->tm_wday + 1;
|
|
|
|
|
int ret;
|
|
|
|
|
|
platform/chrome: wilco_ec: Standardize mailbox interface
The current API for the wilco EC mailbox interface is bad.
It assumes that most messages sent to the EC follow a similar structure,
with a command byte in MBOX[0], followed by a junk byte, followed by
actual data. This doesn't happen in several cases, such as setting the
RTC time, using the raw debugfs interface, and reading or writing
properties such as the Peak Shift policy (this last to be submitted soon).
Similarly for the response message from the EC, the current interface
assumes that the first byte of data is always 0, and the second byte
is unused. However, in both setting and getting the RTC time, in the
debugfs interface, and for reading and writing properties, this isn't
true.
The current way to resolve this is to use WILCO_EC_FLAG_RAW* flags to
specify when and when not to skip these initial bytes in the sent and
received message. They are confusing and used so much that they are
normal, and not exceptions. In addition, the first byte of
response in the debugfs interface is still always skipped, which is
weird, since this raw interface should be giving the entire result.
Additionally, sent messages assume the first byte is a command, and so
struct wilco_ec_message contains the "command" field. In setting or
getting properties however, the first byte is not a command, and so this
field has to be filled with a byte that isn't actually a command. This
is again inconsistent.
wilco_ec_message contains a result field as well, copied from
wilco_ec_response->result. The message result field should be removed:
if the message fails, the cause is already logged, and the callers are
alerted. They will never care about the actual state of the result flag.
These flags and different cases make the wilco_ec_transfer() function,
used in wilco_ec_mailbox(), really gross, dealing with a bunch of
different cases. It's difficult to figure out what it is doing.
Finally, making these assumptions about the structure of a message make
it so that the messages do not correspond well with the specification
for the EC's mailbox interface. For instance, this interface
specification may say that MBOX[9] in the received message contains
some information, but the calling code needs to remember that the first
byte of response is always skipped, and because it didn't set the
RESPONSE_RAW flag, the next byte is also skipped, so this information
is actually contained within wilco_ec_message->response_data[7]. This
makes it difficult to maintain this code in the future.
To fix these problems this patch standardizes the mailbox interface by:
- Removing the WILCO_EC_FLAG_RAW* flags
- Removing the command and reserved_raw bytes from wilco_ec_request
- Removing the mbox0 byte from wilco_ec_response
- Simplifying wilco_ec_transfer() because of these changes
- Gives the callers of wilco_ec_mailbox() the responsibility of exactly
and consistently defining the structure of the mailbox request and
response
- Removing command and result from wilco_ec_message.
This results in the reduction of total code, and makes it much more
maintainable and understandable.
Signed-off-by: Nick Crews <ncrews@chromium.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-04-05 06:54:15 +08:00
|
|
|
rtc.command = EC_COMMAND_CMOS;
|
2019-02-09 08:37:19 +08:00
|
|
|
rtc.param = EC_CMOS_TOD_WRITE;
|
|
|
|
|
rtc.century = bin2bcd(year / 100);
|
|
|
|
|
rtc.year = bin2bcd(year % 100);
|
|
|
|
|
rtc.month = bin2bcd(tm->tm_mon + 1);
|
|
|
|
|
rtc.day = bin2bcd(tm->tm_mday);
|
|
|
|
|
rtc.hour = bin2bcd(tm->tm_hour);
|
|
|
|
|
rtc.minute = bin2bcd(tm->tm_min);
|
|
|
|
|
rtc.second = bin2bcd(tm->tm_sec);
|
|
|
|
|
rtc.weekday = bin2bcd(wday);
|
|
|
|
|
|
platform/chrome: wilco_ec: Standardize mailbox interface
The current API for the wilco EC mailbox interface is bad.
It assumes that most messages sent to the EC follow a similar structure,
with a command byte in MBOX[0], followed by a junk byte, followed by
actual data. This doesn't happen in several cases, such as setting the
RTC time, using the raw debugfs interface, and reading or writing
properties such as the Peak Shift policy (this last to be submitted soon).
Similarly for the response message from the EC, the current interface
assumes that the first byte of data is always 0, and the second byte
is unused. However, in both setting and getting the RTC time, in the
debugfs interface, and for reading and writing properties, this isn't
true.
The current way to resolve this is to use WILCO_EC_FLAG_RAW* flags to
specify when and when not to skip these initial bytes in the sent and
received message. They are confusing and used so much that they are
normal, and not exceptions. In addition, the first byte of
response in the debugfs interface is still always skipped, which is
weird, since this raw interface should be giving the entire result.
Additionally, sent messages assume the first byte is a command, and so
struct wilco_ec_message contains the "command" field. In setting or
getting properties however, the first byte is not a command, and so this
field has to be filled with a byte that isn't actually a command. This
is again inconsistent.
wilco_ec_message contains a result field as well, copied from
wilco_ec_response->result. The message result field should be removed:
if the message fails, the cause is already logged, and the callers are
alerted. They will never care about the actual state of the result flag.
These flags and different cases make the wilco_ec_transfer() function,
used in wilco_ec_mailbox(), really gross, dealing with a bunch of
different cases. It's difficult to figure out what it is doing.
Finally, making these assumptions about the structure of a message make
it so that the messages do not correspond well with the specification
for the EC's mailbox interface. For instance, this interface
specification may say that MBOX[9] in the received message contains
some information, but the calling code needs to remember that the first
byte of response is always skipped, and because it didn't set the
RESPONSE_RAW flag, the next byte is also skipped, so this information
is actually contained within wilco_ec_message->response_data[7]. This
makes it difficult to maintain this code in the future.
To fix these problems this patch standardizes the mailbox interface by:
- Removing the WILCO_EC_FLAG_RAW* flags
- Removing the command and reserved_raw bytes from wilco_ec_request
- Removing the mbox0 byte from wilco_ec_response
- Simplifying wilco_ec_transfer() because of these changes
- Gives the callers of wilco_ec_mailbox() the responsibility of exactly
and consistently defining the structure of the mailbox request and
response
- Removing command and result from wilco_ec_message.
This results in the reduction of total code, and makes it much more
maintainable and understandable.
Signed-off-by: Nick Crews <ncrews@chromium.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-04-05 06:54:15 +08:00
|
|
|
memset(&msg, 0, sizeof(msg));
|
|
|
|
|
msg.type = WILCO_EC_MSG_LEGACY;
|
|
|
|
|
msg.request_data = &rtc;
|
|
|
|
|
msg.request_size = sizeof(rtc);
|
|
|
|
|
|
2019-02-09 08:37:19 +08:00
|
|
|
ret = wilco_ec_mailbox(ec, &msg);
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const struct rtc_class_ops wilco_ec_rtc_ops = {
|
|
|
|
|
.read_time = wilco_ec_rtc_read,
|
|
|
|
|
.set_time = wilco_ec_rtc_write,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int wilco_ec_rtc_probe(struct platform_device *pdev)
|
|
|
|
|
{
|
|
|
|
|
struct rtc_device *rtc;
|
|
|
|
|
|
|
|
|
|
rtc = devm_rtc_allocate_device(&pdev->dev);
|
|
|
|
|
if (IS_ERR(rtc))
|
|
|
|
|
return PTR_ERR(rtc);
|
|
|
|
|
|
|
|
|
|
rtc->ops = &wilco_ec_rtc_ops;
|
|
|
|
|
/* EC only supports this century */
|
|
|
|
|
rtc->range_min = RTC_TIMESTAMP_BEGIN_2000;
|
|
|
|
|
rtc->range_max = RTC_TIMESTAMP_END_2099;
|
|
|
|
|
rtc->owner = THIS_MODULE;
|
|
|
|
|
|
2020-11-10 00:34:08 +08:00
|
|
|
return devm_rtc_register_device(rtc);
|
2019-02-09 08:37:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct platform_driver wilco_ec_rtc_driver = {
|
|
|
|
|
.driver = {
|
|
|
|
|
.name = "rtc-wilco-ec",
|
|
|
|
|
},
|
|
|
|
|
.probe = wilco_ec_rtc_probe,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
module_platform_driver(wilco_ec_rtc_driver);
|
|
|
|
|
|
|
|
|
|
MODULE_ALIAS("platform:rtc-wilco-ec");
|
|
|
|
|
MODULE_AUTHOR("Nick Crews <ncrews@chromium.org>");
|
|
|
|
|
MODULE_LICENSE("GPL v2");
|
|
|
|
|
MODULE_DESCRIPTION("Wilco EC RTC driver");
|