Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp1655918ybm; Sat, 30 May 2020 16:23:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw0lT86OCSNaIZFINal8Nbkpi12Z1iTqqZY0vyAvxg8aBQeHRV8Taoi1Ve4fB04iBw5GLkW X-Received: by 2002:a17:906:1751:: with SMTP id d17mr14354551eje.314.1590880992066; Sat, 30 May 2020 16:23:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590880992; cv=none; d=google.com; s=arc-20160816; b=iCvVupooRD+4LOrTks9bFzZgp32bEPT58gQNDeJKfUkQsbhJn48YNmvZh2y5oeo2F2 iAkAl4sap+nb7kQngkXZogb9LARaRsFT4M1kOzr7OEd/Q6gcGgUzXNWP6wtYF0a0IB8a PZIMcKOQUP9rnqmpUsNHAOEZvD1PhDhrzCTjxbXc3tN8KPFu1YRGglcsWd7l58phEFyz assL49uz+Q2TNuWb2w+TlZTMfvUoKJmWpyqHk9GTEAd6dSVW8w0/K5UGUKTcmPzFBLs4 rA58kbPz6SHugSxK8wYt3BBJ8hNzUR5B4AlAN8Ui7lzQYUHLE9X4027mj6zfp6gl6AWo LPGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:subject:from:references:in-reply-to :message-id:cc:to; bh=ry3r+iK7Ph2J4I7fUidQutzAzBfe/JrqoEeEPTBnZz4=; b=MLBEAbwvryLuCiPLtp/Lb8p1zHl6fDstPWC60YpKvbOie+euVNQ8/zF60GG/QqPcZ4 bVogpIZcowAY5X8EBW8QHYkZnALyx38fnC2VYBPuqw9SEuhA5Jtnw+0zKSBh6bZBlvkQ bEyTKWwBnjawEmIylqhEMxpYyKdlbT+kpoGkQmlmCb+HrSge0SuzhUkJAdflLPu+pixT beQaA7txSkV8cSXqtKpW/5kqdw0h6AZoNVvKd02MgjTt9aF385PseagbE9SRAm8JMpGF AFPLpEHgAUMN9f/Xs3nXP+De8CJxKgx/kIeNardeNy4U99v+AEfVxitvsTYhyAaYIHlH 18Ug== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ng5si7761219ejb.661.2020.05.30.16.22.49; Sat, 30 May 2020 16:23:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729634AbgE3XU5 (ORCPT + 99 others); Sat, 30 May 2020 19:20:57 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:51242 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729553AbgE3XUf (ORCPT ); Sat, 30 May 2020 19:20:35 -0400 Received: by kvm5.telegraphics.com.au (Postfix, from userid 502) id 4FC8B27FE0; Sat, 30 May 2020 19:20:34 -0400 (EDT) To: Benjamin Herrenschmidt Cc: Joshua Thompson , linux-m68k@lists.linux-m68k.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Message-Id: In-Reply-To: References: From: Finn Thain Subject: [PATCH 6/8] macintosh/adb-iop: Implement idle -> sending state transition Date: Sun, 31 May 2020 09:17:03 +1000 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In the present algorithm, the 'idle' state transition does not take place until there's a bus timeout. Once idle, the driver does not automatically proceed with the next request. Change the algorithm so that queued ADB requests will be sent as soon as the driver becomes idle. This is to take place after the current IOP message is completed. Cc: Joshua Thompson Tested-by: Stan Johnson Signed-off-by: Finn Thain --- drivers/macintosh/adb-iop.c | 43 +++++++++++++++++++++---------------- 1 file changed, 24 insertions(+), 19 deletions(-) diff --git a/drivers/macintosh/adb-iop.c b/drivers/macintosh/adb-iop.c index a2b28e09f2ce..f22792c95d4f 100644 --- a/drivers/macintosh/adb-iop.c +++ b/drivers/macintosh/adb-iop.c @@ -54,13 +54,19 @@ struct adb_driver adb_iop_driver = { .reset_bus = adb_iop_reset_bus }; -static void adb_iop_end_req(struct adb_request *req, int state) +static void adb_iop_done(void) { + struct adb_request *req = current_req; + + adb_iop_state = idle; + req->complete = 1; current_req = req->next; if (req->done) (*req->done)(req); - adb_iop_state = state; + + if (adb_iop_state == idle) + adb_iop_start(); } /* @@ -94,37 +100,36 @@ static void adb_iop_complete(struct iop_msg *msg) static void adb_iop_listen(struct iop_msg *msg) { struct adb_iopmsg *amsg = (struct adb_iopmsg *)msg->message; - struct adb_request *req; unsigned long flags; + bool req_done = false; local_irq_save(flags); - req = current_req; - /* Handle a timeout. Timeout packets seem to occur even after * we've gotten a valid reply to a TALK, presumably because of * autopolling. */ - if (amsg->flags & ADB_IOP_TIMEOUT) { - msg->reply[0] = ADB_IOP_TIMEOUT | ADB_IOP_AUTOPOLL; - msg->reply[1] = 0; - msg->reply[2] = 0; - if (req && (adb_iop_state != idle)) { - adb_iop_end_req(req, idle); - } - } else { - if ((adb_iop_state == awaiting_reply) && - (amsg->flags & ADB_IOP_EXPLICIT)) { + if (amsg->flags & ADB_IOP_EXPLICIT) { + if (adb_iop_state == awaiting_reply) { + struct adb_request *req = current_req; + req->reply_len = amsg->count + 1; memcpy(req->reply, &amsg->cmd, req->reply_len); - } else { - adb_input(&amsg->cmd, amsg->count + 1, - amsg->flags & ADB_IOP_AUTOPOLL); + + req_done = true; } - memcpy(msg->reply, msg->message, IOP_MSG_LEN); + } else if (!(amsg->flags & ADB_IOP_TIMEOUT)) { + adb_input(&amsg->cmd, amsg->count + 1, + amsg->flags & ADB_IOP_AUTOPOLL); } + + msg->reply[0] = ADB_IOP_AUTOPOLL; iop_complete_message(msg); + + if (req_done) + adb_iop_done(); + local_irq_restore(flags); } -- 2.26.2