mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: <Valentina.FernandezAlanis@microchip.com>
To: <conor@kernel.org>, <linux-riscv@lists.infradead.org>
Cc: <Conor.Dooley@microchip.com>, <Daire.McNamara@microchip.com>,
	<jassisinghbrar@gmail.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 0/8] Hey Jassi, all,
Date: Mon, 3 Apr 2023 18:11:32 +0000	[thread overview]
Message-ID: <d3fe02e9-0e34-17d0-251e-5cc4394c8889@microchip.com> (raw)
In-Reply-To: <20230307202257.1762151-1-conor@kernel.org>

On 07/03/2023 20:22, Conor Dooley wrote:
> 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.
Hi Conor,

I tested this on the Icicle Kit board, looks good to me. So:
Tested-by: Valentina Fernandez <valentina.fernandezalanis@microchip.com>
> 
> 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(-)
> 


  parent reply	other threads:[~2023-04-03 18:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-07 20:22 Conor Dooley
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 ` Valentina.FernandezAlanis [this message]
2023-04-03 18:28 ` [PATCH v3 0/8] Hey Jassi, all, 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=d3fe02e9-0e34-17d0-251e-5cc4394c8889@microchip.com \
    --to=valentina.fernandezalanis@microchip.com \
    --cc=Conor.Dooley@microchip.com \
    --cc=Daire.McNamara@microchip.com \
    --cc=conor@kernel.org \
    --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

all inboxes | Powered by JetHome®