HACK: firmware: ti_sci: Move mailbox ticker after the tick

For some reason, unless we move the ticker logic *after* transmit, we
are unable to send data, however, when we do that, we have to deal
with Mailbox core's queue logic which is limited in size, so we can
only send "so much" requests simultaneously(ridiculous limitation, but
that is how it is).

While at this, increase predicted timeout to an unexpected value.

NOTE: this is tagged as a hack as the rootcause is still unknown. Side
effect of this patch will be to force the system to have just one
xfer only in progress to TI SCI. This needs further investigation to
rootcause, but this should unblock further work using the ti_sci for
communication

Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Dave Gerlach <d-gerlach@ti.com>

1 files changed, 10 insertions, 11 deletions

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index f874d9c8c611..b266d7c2c09f 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -429,15 +429,6 @@ static inline int ti_sci_do_xfer(struct ti_sci_info *info,
         if (ret < 0)
                 return ret;
 
-        /*
-         * NOTE: we don't need the mailbox ticker to manage the transfer
-         * queueing since the protocol layer queues things by itself. So,
-         * kick it once we are done with current transmit. This forces
-         * the mailbox framework to submit next message allowing for
-         * transmission of next message to occur in parallel to processing
-         * in TISCI entity and subsequent response of the current message.
-         */
-        mbox_client_txdone(info->chan_tx, 0);
         ret = 0;
 
         /* And we wait for the response. */
@@ -447,6 +438,13 @@ static inline int ti_sci_do_xfer(struct ti_sci_info *info,
                         (void *)_RET_IP_);
                 ret = -ETIMEDOUT;
         }
+        /*
+         * NOTE: we might prefer not to need the mailbox ticker to manage the
+         * transfer queueing since the protocol layer queues things by itself.
+         * Unfortunately, we have to kick the mailbox framework after we have
+         * received our message.
+         */
+        mbox_client_txdone(info->chan_tx, ret);
 
         return ret;
 }
@@ -629,8 +627,9 @@ EXPORT_SYMBOL_GPL(devm_ti_sci_get_handle);
 /* Description for K2G */
 static const struct ti_sci_desc ti_sci_pmmc_k2g_desc = {
         .host_id = 2,
-        .max_rx_timeout_ms = 200,
-        .max_msgs = 128,
+        .max_rx_timeout_ms = 1000,
+        /* Limited by MBOX_TX_QUEUE_LEN!!!! K2G can handle upto 128! */
+        .max_msgs = 20,
         .max_msg_size = 64,
 };