public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: linux-riscv@lists.infradead.org
Cc: conor@kernel.org, Conor Dooley <conor.dooley@microchip.com>,
	Daire McNamara <daire.mcnamara@microchip.com>,
	Jassi Brar <jassisinghbrar@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/8] Hey Jassi, all,
Date: Tue,  7 Mar 2023 20:22:50 +0000	[thread overview]
Message-ID: <20230307202257.1762151-1-conor@kernel.org> (raw)

From: Conor Dooley <conor.dooley@microchip.com>

Here are some fixes for the system controller on PolarFire SoC that I
ran into while implementing support for using the system controller to
re-program the FPGA. A few are just minor bits that I fixed in passing,
but the bulk of the patchset is changes to how the mailbox figures out
if a "service" has completed.

Prior to implementing this particular functionality, the services
requested from the system controller, via its mailbox interface, always
triggered an interrupt when the system controller was finished with
the service.

Unfortunately some of the services used to validate the FPGA images
before programming them do not trigger an interrupt if they fail.
For example, the service that checks whether an FPGA image is actually
a newer version than what is already programmed, does not trigger an
interrupt, unless the image is actually newer than the one currently
programmed. If it has an earlier version, no interrupt is triggered
and a status is set in the system controller's status register to
signify the reason for the failure.

In order to differentiate between the service succeeding & the system
controller being inoperative or otherwise unable to function, I had to
switch the controller to poll a busy bit in the system controller's
registers to see if it has completed a service.
This makes sense anyway, as the interrupt corresponds to "data ready"
rather than "tx done", so I have changed the mailbox controller driver
to do that & left the interrupt solely for signalling data ready.
It just so happened that all of the services that I had worked with and
tested up to this point were "infallible" & did not set a status, so the
particular code paths were never tested.

Jassi, the mailbox and soc patches depend on each other, as the change
in what the interrupt is used for requires changing the client driver's
behaviour too, as mbox_send_message() will now return when the system
controller is no longer busy rather than when the data is ready.
I'm happy to send the lot via the soc tree with your Ack and/or reivew,
if that also works you?
I've got some other bits that I'd like to change in the client driver,
so via the soc tree would suit me better.

Thanks,
Conor.

Changes in v3:
- check the service status in the .tx_done() callback rather than
  mpfs_mbox_rx_data()
- re-order the if/else bits in mpfs_blocking_transaction() to please my
  eyes a bit more
- expand on the comment in same

Changes in v2:
- up the timeout to 30 seconds, as required for services like image
  validation, which may vary significantly in execution time
- fixed a typo!

CC: Conor Dooley <conor.dooley@microchip.com>
CC: Daire McNamara <daire.mcnamara@microchip.com>
CC: Jassi Brar <jassisinghbrar@gmail.com>
CC: linux-riscv@lists.infradead.org
CC: linux-kernel@vger.kernel.org

Conor Dooley (8):
  mailbox: mpfs: fix an incorrect mask width
  mailbox: mpfs: switch to txdone_poll
  mailbox: mpfs: ditch a useless busy check
  mailbox: mpfs: check the service status in .tx_done()
  soc: microchip: mpfs: fix some horrible alignment
  soc: microchip: mpfs: use a consistent completion timeout
  soc: microchip: mpfs: simplify error handling in
    mpfs_blocking_transaction()
  soc: microchip: mpfs: handle timeouts and failed services differently

 drivers/mailbox/mailbox-mpfs.c              | 55 ++++++++++++---------
 drivers/soc/microchip/mpfs-sys-controller.c | 52 +++++++++++++------
 2 files changed, 67 insertions(+), 40 deletions(-)

-- 
2.39.2


             reply	other threads:[~2023-03-07 20:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-07 20:22 Conor Dooley [this message]
2023-03-07 20:22 ` [PATCH v3 1/8] mailbox: mpfs: fix an incorrect mask width Conor Dooley
2023-03-07 20:22 ` [PATCH v3 2/8] mailbox: mpfs: switch to txdone_poll Conor Dooley
2023-03-07 20:22 ` [PATCH v3 3/8] mailbox: mpfs: ditch a useless busy check Conor Dooley
2023-03-07 20:22 ` [PATCH v3 4/8] mailbox: mpfs: check the service status in .tx_done() Conor Dooley
2023-03-07 20:22 ` [PATCH v3 5/8] soc: microchip: mpfs: fix some horrible alignment Conor Dooley
2023-03-07 20:22 ` [PATCH v3 6/8] soc: microchip: mpfs: use a consistent completion timeout Conor Dooley
2023-03-07 20:22 ` [PATCH v3 7/8] soc: microchip: mpfs: simplify error handling in mpfs_blocking_transaction() Conor Dooley
2023-03-07 20:22 ` [PATCH v3 8/8] soc: microchip: mpfs: handle timeouts and failed services differently Conor Dooley
2023-03-07 20:30 ` mailbox,soc: mpfs: add support for fallible services (was [PATCH v3 0/8] Hey Jassi, all,) Conor Dooley
2023-03-29 16:15   ` Conor Dooley
2023-03-31 15:03     ` Jassi Brar
2023-03-31 18:14       ` Conor Dooley
2023-04-03 18:11 ` [PATCH v3 0/8] Hey Jassi, all, Valentina.FernandezAlanis
2023-04-03 18:28 ` Conor Dooley

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=20230307202257.1762151-1-conor@kernel.org \
    --to=conor@kernel.org \
    --cc=conor.dooley@microchip.com \
    --cc=daire.mcnamara@microchip.com \
    --cc=jassisinghbrar@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.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