All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: linux-can@vger.kernel.org, Thomas Kopp <thomas.kopp@microchip.com>
Subject: Re: [PATCH] can: mcp251xfd: mcp251xfd_open(): request IRQ as shared
Date: Tue, 27 Jul 2021 09:46:17 +0200	[thread overview]
Message-ID: <20210727074617.6tsjtlxmmvsmtfvc@pengutronix.de> (raw)
In-Reply-To: <20210727071717.GA33931@thinkpad>

[-- Attachment #1: Type: text/plain, Size: 1892 bytes --]

On 27.07.2021 12:47:17, Manivannan Sadhasivam wrote:
> On Sat, Jul 24, 2021 at 10:52:13PM +0200, Marc Kleine-Budde wrote:
> > The driver's IRQ handler supports shared IRQs, so request a shared IRQ
> > handler.
> 
> I don't see any issue with the idea but I'd like to understand the
> requirement for it.

Hardware designers might come up with strange ideas, so better be
prepared for this. :)

But seriously, there's a group of people trying to bring the mcp251xfd
driver to work on ACPI based systems. Having a shared mcp251xfd IRQ
handler will (hopefully) help them during debugging.

I've written the IRQ handler to properly only return IRQ_HANDLED if
there really was an interrupt, this means it should be capable running
as a shared IRQ handler. I've tested it and it works. So let the driver
request a shared IRQ handler.

> Usually the IRQ lines are shared when multiple devices use them
> physically. For instance, a MFD device using a single GPIO for all of its
> functions. But I don't see any sort of requirement like that here.

Indeed there is really no good reason to do so, but it works. For
testing I've connected 2 mcp2518fd to the same IRQ line and the kernel
runs both IRQ handlers an interrupt is triggered. If course this brings
the overhead of an additional SPI transfer per IRQ, but it works.

> Making the IRQ lines shared will only induce latency IMO.

ACK - you will not get better performance compared to separate IRQ lines
:) But if you don't use shared interrupts this change doesn't make the
driver or system any slower or induce latency.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2021-07-27  7:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-24 20:52 [PATCH] can: mcp251xfd: mcp251xfd_open(): request IRQ as shared Marc Kleine-Budde
2021-07-27  7:17 ` Manivannan Sadhasivam
2021-07-27  7:46   ` Marc Kleine-Budde [this message]
2021-07-27  9:10     ` Manivannan Sadhasivam

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=20210727074617.6tsjtlxmmvsmtfvc@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=linux-can@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=thomas.kopp@microchip.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.