From: Douglas Anderson <dianders@chromium.org>
To: Mark Brown <broonie@kernel.org>,
Benson Leung <bleung@chromium.org>,
Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: linux-rockchip@lists.infradead.org, drinkcat@chromium.org,
Guenter Roeck <groeck@chromium.org>,
briannorris@chromium.org, mka@chromium.org,
Douglas Anderson <dianders@chromium.org>,
linux-kernel@vger.kernel.org
Subject: [PATCH v2 3/3] Revert "platform/chrome: cros_ec_spi: Transfer messages at high priority"
Date: Mon, 13 May 2019 13:18:25 -0700 [thread overview]
Message-ID: <20190513201825.166969-4-dianders@chromium.org> (raw)
In-Reply-To: <20190513201825.166969-1-dianders@chromium.org>
This reverts commit 37a186225a0c020516bafad2727fdcdfc039a1e4.
We have a better solution in the patch ("platform/chrome: cros_ec_spi:
Force transfers to realtime priority"). Let's revert the uglier and
less reliable solution.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
---
Changes in v2: None
drivers/platform/chrome/cros_ec_spi.c | 80 ++-------------------------
1 file changed, 6 insertions(+), 74 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_spi.c b/drivers/platform/chrome/cros_ec_spi.c
index a2959365a870..7adaf534eb8b 100644
--- a/drivers/platform/chrome/cros_ec_spi.c
+++ b/drivers/platform/chrome/cros_ec_spi.c
@@ -75,27 +75,6 @@ struct cros_ec_spi {
unsigned int end_of_msg_delay;
};
-typedef int (*cros_ec_xfer_fn_t) (struct cros_ec_device *ec_dev,
- struct cros_ec_command *ec_msg);
-
-/**
- * struct cros_ec_xfer_work_params - params for our high priority workers
- *
- * @work: The work_struct needed to queue work
- * @fn: The function to use to transfer
- * @ec_dev: ChromeOS EC device
- * @ec_msg: Message to transfer
- * @ret: The return value of the function
- */
-
-struct cros_ec_xfer_work_params {
- struct work_struct work;
- cros_ec_xfer_fn_t fn;
- struct cros_ec_device *ec_dev;
- struct cros_ec_command *ec_msg;
- int ret;
-};
-
static void debug_packet(struct device *dev, const char *name, u8 *ptr,
int len)
{
@@ -371,13 +350,13 @@ static int cros_ec_spi_receive_response(struct cros_ec_device *ec_dev,
}
/**
- * do_cros_ec_pkt_xfer_spi - Transfer a packet over SPI and receive the reply
+ * cros_ec_pkt_xfer_spi - Transfer a packet over SPI and receive the reply
*
* @ec_dev: ChromeOS EC device
* @ec_msg: Message to transfer
*/
-static int do_cros_ec_pkt_xfer_spi(struct cros_ec_device *ec_dev,
- struct cros_ec_command *ec_msg)
+static int cros_ec_pkt_xfer_spi(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *ec_msg)
{
struct ec_host_response *response;
struct cros_ec_spi *ec_spi = ec_dev->priv;
@@ -514,13 +493,13 @@ static int do_cros_ec_pkt_xfer_spi(struct cros_ec_device *ec_dev,
}
/**
- * do_cros_ec_cmd_xfer_spi - Transfer a message over SPI and receive the reply
+ * cros_ec_cmd_xfer_spi - Transfer a message over SPI and receive the reply
*
* @ec_dev: ChromeOS EC device
* @ec_msg: Message to transfer
*/
-static int do_cros_ec_cmd_xfer_spi(struct cros_ec_device *ec_dev,
- struct cros_ec_command *ec_msg)
+static int cros_ec_cmd_xfer_spi(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *ec_msg)
{
struct cros_ec_spi *ec_spi = ec_dev->priv;
struct spi_transfer trans;
@@ -632,53 +611,6 @@ static int do_cros_ec_cmd_xfer_spi(struct cros_ec_device *ec_dev,
return ret;
}
-static void cros_ec_xfer_high_pri_work(struct work_struct *work)
-{
- struct cros_ec_xfer_work_params *params;
-
- params = container_of(work, struct cros_ec_xfer_work_params, work);
- params->ret = params->fn(params->ec_dev, params->ec_msg);
-}
-
-static int cros_ec_xfer_high_pri(struct cros_ec_device *ec_dev,
- struct cros_ec_command *ec_msg,
- cros_ec_xfer_fn_t fn)
-{
- struct cros_ec_xfer_work_params params;
-
- INIT_WORK_ONSTACK(¶ms.work, cros_ec_xfer_high_pri_work);
- params.ec_dev = ec_dev;
- params.ec_msg = ec_msg;
- params.fn = fn;
-
- /*
- * This looks a bit ridiculous. Why do the work on a
- * different thread if we're just going to block waiting for
- * the thread to finish? The key here is that the thread is
- * running at high priority but the calling context might not
- * be. We need to be at high priority to avoid getting
- * context switched out for too long and the EC giving up on
- * the transfer.
- */
- queue_work(system_highpri_wq, ¶ms.work);
- flush_work(¶ms.work);
- destroy_work_on_stack(¶ms.work);
-
- return params.ret;
-}
-
-static int cros_ec_pkt_xfer_spi(struct cros_ec_device *ec_dev,
- struct cros_ec_command *ec_msg)
-{
- return cros_ec_xfer_high_pri(ec_dev, ec_msg, do_cros_ec_pkt_xfer_spi);
-}
-
-static int cros_ec_cmd_xfer_spi(struct cros_ec_device *ec_dev,
- struct cros_ec_command *ec_msg)
-{
- return cros_ec_xfer_high_pri(ec_dev, ec_msg, do_cros_ec_cmd_xfer_spi);
-}
-
static void cros_ec_spi_dt_probe(struct cros_ec_spi *ec_spi, struct device *dev)
{
struct device_node *np = dev->of_node;
--
2.21.0.1020.gf2820cf01a-goog
prev parent reply other threads:[~2019-05-13 20:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-13 20:18 [PATCH v2 0/3] spi: A better solution for cros_ec_spi reliability Douglas Anderson
2019-05-13 20:18 ` [PATCH v2 1/3] spi: Allow SPI devices to force transfers on a realtime thread Douglas Anderson
2019-05-13 20:18 ` [PATCH v2 2/3] platform/chrome: cros_ec_spi: Force transfers to realtime priority Douglas Anderson
2019-05-13 20:18 ` Douglas Anderson [this message]
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=20190513201825.166969-4-dianders@chromium.org \
--to=dianders@chromium.org \
--cc=bleung@chromium.org \
--cc=briannorris@chromium.org \
--cc=broonie@kernel.org \
--cc=drinkcat@chromium.org \
--cc=enric.balletbo@collabora.com \
--cc=groeck@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mka@chromium.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
all inboxes | Powered by JetHome®