devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ray Jui <ray.jui@broadcom.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>,
	Andrew Murray <andrew.murray@arm.com>
Cc: Srinath Mannam <srinath.mannam@broadcom.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Ray Jui <rjui@broadcom.com>, Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Arnd Bergmann <arnd@arndb.de>,
	bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>,
	linux-pci@vger.kernel.org,
	devicetree <devicetree@vger.kernel.org>,
	linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 2/6] PCI: iproc: Add INTx support with better modeling
Date: Tue, 3 Dec 2019 14:09:22 -0800	[thread overview]
Message-ID: <40fffa66-4b06-a851-84c2-4de36d5c6777@broadcom.com> (raw)
In-Reply-To: <CAHp75Vf7d=Gw24MTq2q3BKspkLEDDM24GVK4Zh_4zfZEzVuZjw@mail.gmail.com>



On 12/3/19 11:27 AM, Andy Shevchenko wrote:
> On Tue, Dec 3, 2019 at 5:55 PM Andrew Murray <andrew.murray@arm.com> wrote:
>> On Tue, Dec 03, 2019 at 10:27:02AM +0530, Srinath Mannam wrote:
> 
>>> +     /* go through INTx A, B, C, D until all interrupts are handled */
>>> +     do {
>>> +             status = iproc_pcie_read_reg(pcie, IPROC_PCIE_INTX_CSR);
>>
>> By performing this read once and outside of the do/while loop you may improve
>> performance. I wonder how probable it is to get another INTx whilst handling
>> one?
> 
> May I ask how it can be improved?
> One read will be needed any way, and so does this code.
> 

I guess the current code will cause the IPROC_PCIE_INTX_CSR register to 
be read TWICE, if it's ever set to start with.

But then if we do it outside of the while loop, if we ever receive an 
interrupt while servicing one, the interrupt will still need to be 
serviced, and in this case, it will cause additional context switch 
overhead by going out and back in the interrupt context.

My take is that it's probably more ideal to leave this portion of code 
as it is.

>>> +             for_each_set_bit(bit, &status, PCI_NUM_INTX) {
>>> +                     virq = irq_find_mapping(pcie->irq_domain, bit);
>>> +                     if (virq)
>>> +                             generic_handle_irq(virq);
>>> +                     else
>>> +                             dev_err(dev, "unexpected INTx%u\n", bit);
>>> +             }
>>> +     } while ((status & SYS_RC_INTX_MASK) != 0);
> 

  reply	other threads:[~2019-12-03 22:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-03  4:57 [PATCH v3 0/6] PAXB INTx support with proper model Srinath Mannam
2019-12-03  4:57 ` [PATCH v3 1/6] dt-bindings: pci: Update iProc PCI binding for INTx support Srinath Mannam
2019-12-03 19:19   ` Rob Herring
2019-12-03  4:57 ` [PATCH v3 2/6] PCI: iproc: Add INTx support with better modeling Srinath Mannam
2019-12-03 15:55   ` Andrew Murray
2019-12-03 19:27     ` Andy Shevchenko
2019-12-03 22:09       ` Ray Jui [this message]
2019-12-04  8:29         ` Andy Shevchenko
2019-12-04 16:07           ` Andrew Murray
2019-12-04 18:36             ` Ray Jui
2019-12-06  9:44     ` Srinath Mannam
2019-12-03  4:57 ` [PATCH v3 3/6] arm: dts: Change PCIe INTx mapping for Cygnus Srinath Mannam
2019-12-03  4:57 ` [PATCH v3 4/6] arm: dts: Change PCIe INTx mapping for NSP Srinath Mannam
2019-12-03  4:57 ` [PATCH v3 5/6] arm: dts: Change PCIe INTx mapping for HR2 Srinath Mannam
2019-12-03  4:57 ` [PATCH v3 6/6] arm64: dts: Change PCIe INTx mapping for NS2 Srinath Mannam

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=40fffa66-4b06-a851-84c2-4de36d5c6777@broadcom.com \
    --to=ray.jui@broadcom.com \
    --cc=andrew.murray@arm.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=rjui@broadcom.com \
    --cc=robh+dt@kernel.org \
    --cc=srinath.mannam@broadcom.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).