linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Mark Rutland <mark.rutland@arm.com>, Andrew Lunn <andrew@lunn.ch>,
	raymond pang <raymondpangxd@gmail.com>,
	Jason Cooper <jason@lakedaemon.net>,
	Nadav Haklai <nadavh@marvell.com>,
	devicetree@vger.kernel.org,
	Antoine Tenart <antoine.tenart@bootlin.com>,
	Gregory Clement <gregory.clement@bootlin.com>,
	Baruch Siach <baruch@tkos.co.il>,
	Maxime Chevallier <maxime.chevallier@bootlin.com>,
	linux-ide@vger.kernel.org, Hans de Goede <hdegoede@redhat.com>,
	Rob Herring <robh+dt@kernel.org>, Jens Axboe <axboe@kernel.dk>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Subject: Re: [PATCH v4 01/10] ata: libahci: Ensure the host interrupt status bits are cleared
Date: Wed, 29 May 2019 14:33:39 +0100	[thread overview]
Message-ID: <f619298a-cb51-b86e-9542-55b9e45bf803@arm.com> (raw)
In-Reply-To: <20190529141356.1d9f03f3@xps13>

On 29/05/2019 13:13, Miquel Raynal wrote:
> Hi Marc,
> 
> Marc Zyngier <marc.zyngier@arm.com> wrote on Wed, 29 May 2019 11:37:58
> +0100:
> 
>> On 29/05/2019 11:08, Miquel Raynal wrote:
>>> Hi Marc & Raymond,
>>>
>>> Marc Zyngier <marc.zyngier@arm.com> wrote on Thu, 23 May 2019 10:26:01
>>> +0100:
>>>   
>>>> On 23/05/2019 04:11, raymond pang wrote:  
>>>>> Hi Miquel,
>>>>>
>>>>> This patch adds clearing GHC.IS into hot path, could you explain how
>>>>> irq storm is generated? thanks
>>>>> According to AHCI Spec, HBA should not refer to GHC.IS to generate
>>>>> MSI when applying multiple MSIs.    
>>>>
>>>> Well spotted.
>>>>
>>>> I have the ugly feeling that this is because the Marvell AHCI
>>>> implementation is not using MSIs at all, but instead a pair of wired
>>>> interrupts (which are level triggered instead of edge, hence the
>>>> screaming interrupts).
>>>>
>>>> The changes in the following patches abuse the rest of the driver by
>>>> pretending this is a a multi-MSI setup, while it clearly doesn't match
>>>> the expectation of the AHCI spec for MSIs.
>>>>
>>>> It looks like this shouldn't be imposed on other unsuspecting
>>>> implementations which correctly use edge-triggered MSIs and do not
>>>> require such an MMIO access.  
>>>
>>> I understand your concern, let me add a AHCI_HFLAG_LEVEL_MSI in
>>> hpriv->flags which will be used by the mvebu_ahci.c driver to request
>>> for this MMIO access. This way, the hot path remains the same.  
>>
>> I'm not convinced that's a good idea, if only because from the PoV of
>> the AHCI device itself, these are not MSIs at all, but wired interrupts.
>> The fact that there is some glue logic in the middle that turns it into
>> a message (and then back into a wire) is a regrettable implementation
>> detail.
>>
>> I'd rather you stick to the normal interrupt handler, or provide your
>> own, which would solve most problems.
> 
> Unless I don't understand your proposal, "stick to the normal interrupt
> handler" is not possible as I need this register write to happen at
> this time, not at any other moment.
> 
> However, on the possibility of having a separate interrupt handler, I
> may use the new AHCI_HFALG_LEVEL_MSI flag to change the
> devm_request_irq call here [1] and use my own at this moment. The
> handler will be in libahci.c though.
> 
> Would this be a better approach?

Again, level-triggered MSIs are not a property of the AHCI block. If
anything, that's a property of the ICU block. Please do not conflate the
two.

What you have here is a set of wired interrupts, one per port. I'd
suggest you implement it a separate interrupt handler keyed on a
particular flag if you cannot detect this case by other means.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-05-29 13:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-21 14:30 [PATCH v4 00/10] Enable per-port SATA interrupts and drop a hack in the IRQ subsystem Miquel Raynal
2019-05-21 14:30 ` [PATCH v4 01/10] ata: libahci: Ensure the host interrupt status bits are cleared Miquel Raynal
2019-05-23  3:11   ` raymond pang
2019-05-23  9:26     ` Marc Zyngier
2019-05-29 10:08       ` Miquel Raynal
2019-05-29 10:37         ` Marc Zyngier
2019-05-29 12:13           ` Miquel Raynal
2019-05-29 13:33             ` Marc Zyngier [this message]
2019-05-21 14:30 ` [PATCH v4 02/10] ata: ahci: Support per-port interrupts Miquel Raynal
2019-05-23  9:36   ` Christoph Hellwig
2019-05-21 14:30 ` [PATCH v4 03/10] dt-bindings: ata: Update ahci bindings with possible " Miquel Raynal
2019-05-21 14:30 ` [PATCH v4 04/10] ata: ahci: mvebu: Rename a platform data flag Miquel Raynal
2019-05-22  8:58   ` Marc Zyngier
2019-05-21 14:30 ` [PATCH v4 05/10] ata: ahci: mvebu: Add a parameter to a platform data callback Miquel Raynal
2019-05-21 14:30 ` [PATCH v4 06/10] dt-bindings: ata: Update ahci_mvebu bindings Miquel Raynal
2019-05-21 14:30 ` [PATCH v4 07/10] ata: ahci: mvebu: Support A8k compatible Miquel Raynal
2019-05-21 14:30 ` [PATCH v4 08/10] ata: ahci: mvebu: Add support for A8k legacy DT bindings Miquel Raynal
2019-05-21 15:46   ` Marc Zyngier
2019-05-29 10:10     ` Miquel Raynal
2019-05-21 14:30 ` [PATCH v4 09/10] irqchip/irq-mvebu-icu: Remove the double SATA ports interrupt hack Miquel Raynal
2019-05-21 15:51   ` Marc Zyngier
2019-05-21 14:30 ` [PATCH v4 10/10] arm64: dts: marvell: armada-cp110: Switch to per-port SATA interrupts Miquel Raynal

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=f619298a-cb51-b86e-9542-55b9e45bf803@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=andrew@lunn.ch \
    --cc=antoine.tenart@bootlin.com \
    --cc=axboe@kernel.dk \
    --cc=baruch@tkos.co.il \
    --cc=devicetree@vger.kernel.org \
    --cc=gregory.clement@bootlin.com \
    --cc=hdegoede@redhat.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maxime.chevallier@bootlin.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=nadavh@marvell.com \
    --cc=raymondpangxd@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.petazzoni@bootlin.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).