All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mason <slash.tmp@free.fr>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Robin Murphy <robin.murphy@arm.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Liviu Dudau <liviu.dudau@arm.com>,
	David Laight <david.laight@aculab.com>,
	linux-pci <linux-pci@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Thibaud Cornic <thibaud_cornic@sigmadesigns.com>,
	Phuong Nguyen <phuong_nguyen@sigmadesigns.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge
Date: Tue, 28 Mar 2017 00:04:38 +0200	[thread overview]
Message-ID: <b180c091-e4a4-7f58-7378-e0f3a24e44d6@free.fr> (raw)
In-Reply-To: <8637dyo2d9.fsf@arm.com>

On 27/03/2017 23:07, Marc Zyngier wrote:

> On Mon, Mar 27 2017 at 08:44:08 PM, Mason wrote:
>
>> On 27/03/2017 19:09, Marc Zyngier wrote:
>>
>>> On 27/03/17 16:53, Mason wrote:
>>>
>>>> I have one remaining issue with bitmaps.
>>>>
>>>> My HW regs are 32b. How do I grab e.g. bits 96-127?
>>>> All I can think of is
>>>>   u32 val = ((u32 *)bitmap)[3];
>>>>
>>>> Is this acceptable?
>>>
>>> No.
>>>
>>>> mrutland mentioned bitmap_to_u32array() but IIUC it is used to
>>>> copy an entire bitmap.
>>>
>>> The real question is "Why do you need such a thing?".
>>
>> You told me to use an in-memory version of the "unmasked"
>> bitmap, yes? In that case, I need to be able to grab
>> a piece of said bitmap, to update the corresponding piece
>> of the HW bitmap.
>>
>> For example, assume the first 3 MSIs are unmasked,
>> in other words, unmasked = 0x7
>>
>> A new user comes along and wants to assign an MSI.
>> Scan "unmasked", found bit at pos 3.
>> Update "unmasked" to 0xf.
>> At some point, I need to write 0xf to some HW reg.
>> So I need to grab a piece of "unmasked" (bits 0-31 in my example)
>>
>>   pos = find_first_zero_bit(unmasked, COUNT);
>>   __set_bit(pos, unmasked);
>>   int reg_index = pos / 32;
>>   u32 val = ((u32 *)unmasked)[reg_index];
>>   writel_relaxed(val, pcie->enabled + reg_index * 4);
>>
>> Or did I miss something in your suggestion?
> 
> I don't know, I'm sightly taken aback by your question. Completely
> puzzled, actually. "Read Modify Write" is a fairly obvious construct.
> 
>      val = readl_relaxed(pcie->enabled + reg_index);
>      writel_relaxed(val | BIT(pos % 32), pcie->enabled + reg_index);
> 
> I never realized this could be such a novel concept. Replace pos with
> hwirq, add a spinlock, and that's your irq_unmask.

I'm not sure why you would think I'm not familiar with RMW.

My original code was:

	mask = readl_relaxed(pcie->msi_mask);
	pos = find_first_zero_bit(&mask, 32);
	writel(mask | BIT(pos), pcie->msi_mask);

To which you replied:
"Do you really need to read this from the HW each time you allocate an
interrupt? That feels pretty crazy. You're much better off having an
in-memory bitmap that will make things more efficient"

This is why I was trying to avoid a MMIO read from the HW
each time I allocate an interrupt.

> My suggestion was to use a bitmap in order not to perform extra MMIO
> accesses on the fast path. It doesn't mean that you cannot read from the
> register under any circumstances. It just means that you don't do it
> when there are more efficient ways to do it.

The fast path is the interrupt handler, right?
(I didn't read the interrupt mask in the ISR.)

I understand your underlying point. It is fine to read
from MMIO in the slow path, but try as hard as possible
NOT to do so in the fast path.

Regards.

WARNING: multiple messages have this Message-ID (diff)
From: slash.tmp@free.fr (Mason)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge
Date: Tue, 28 Mar 2017 00:04:38 +0200	[thread overview]
Message-ID: <b180c091-e4a4-7f58-7378-e0f3a24e44d6@free.fr> (raw)
In-Reply-To: <8637dyo2d9.fsf@arm.com>

On 27/03/2017 23:07, Marc Zyngier wrote:

> On Mon, Mar 27 2017 at 08:44:08 PM, Mason wrote:
>
>> On 27/03/2017 19:09, Marc Zyngier wrote:
>>
>>> On 27/03/17 16:53, Mason wrote:
>>>
>>>> I have one remaining issue with bitmaps.
>>>>
>>>> My HW regs are 32b. How do I grab e.g. bits 96-127?
>>>> All I can think of is
>>>>   u32 val = ((u32 *)bitmap)[3];
>>>>
>>>> Is this acceptable?
>>>
>>> No.
>>>
>>>> mrutland mentioned bitmap_to_u32array() but IIUC it is used to
>>>> copy an entire bitmap.
>>>
>>> The real question is "Why do you need such a thing?".
>>
>> You told me to use an in-memory version of the "unmasked"
>> bitmap, yes? In that case, I need to be able to grab
>> a piece of said bitmap, to update the corresponding piece
>> of the HW bitmap.
>>
>> For example, assume the first 3 MSIs are unmasked,
>> in other words, unmasked = 0x7
>>
>> A new user comes along and wants to assign an MSI.
>> Scan "unmasked", found bit at pos 3.
>> Update "unmasked" to 0xf.
>> At some point, I need to write 0xf to some HW reg.
>> So I need to grab a piece of "unmasked" (bits 0-31 in my example)
>>
>>   pos = find_first_zero_bit(unmasked, COUNT);
>>   __set_bit(pos, unmasked);
>>   int reg_index = pos / 32;
>>   u32 val = ((u32 *)unmasked)[reg_index];
>>   writel_relaxed(val, pcie->enabled + reg_index * 4);
>>
>> Or did I miss something in your suggestion?
> 
> I don't know, I'm sightly taken aback by your question. Completely
> puzzled, actually. "Read Modify Write" is a fairly obvious construct.
> 
>      val = readl_relaxed(pcie->enabled + reg_index);
>      writel_relaxed(val | BIT(pos % 32), pcie->enabled + reg_index);
> 
> I never realized this could be such a novel concept. Replace pos with
> hwirq, add a spinlock, and that's your irq_unmask.

I'm not sure why you would think I'm not familiar with RMW.

My original code was:

	mask = readl_relaxed(pcie->msi_mask);
	pos = find_first_zero_bit(&mask, 32);
	writel(mask | BIT(pos), pcie->msi_mask);

To which you replied:
"Do you really need to read this from the HW each time you allocate an
interrupt? That feels pretty crazy. You're much better off having an
in-memory bitmap that will make things more efficient"

This is why I was trying to avoid a MMIO read from the HW
each time I allocate an interrupt.

> My suggestion was to use a bitmap in order not to perform extra MMIO
> accesses on the fast path. It doesn't mean that you cannot read from the
> register under any circumstances. It just means that you don't do it
> when there are more efficient ways to do it.

The fast path is the interrupt handler, right?
(I didn't read the interrupt mask in the ISR.)

I understand your underlying point. It is fine to read
from MMIO in the slow path, but try as hard as possible
NOT to do so in the fast path.

Regards.

  reply	other threads:[~2017-03-27 22:07 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-23 13:05 [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge Mason
2017-03-23 13:05 ` Mason
2017-03-23 14:22 ` Marc Zyngier
2017-03-23 14:22   ` Marc Zyngier
2017-03-23 17:03   ` Mason
2017-03-23 17:03     ` Mason
2017-03-23 23:40     ` Mason
2017-03-23 23:40       ` Mason
2017-03-24 18:22       ` Marc Zyngier
2017-03-24 18:22         ` Marc Zyngier
2017-03-27 14:35         ` Mason
2017-03-27 14:35           ` Mason
2017-03-27 14:35           ` Mason
2017-03-27 14:46           ` Thomas Gleixner
2017-03-27 14:46             ` Thomas Gleixner
2017-03-27 15:18             ` Mason
2017-03-27 15:18               ` Mason
2017-03-27 15:18               ` Mason
2017-03-24 18:47     ` Marc Zyngier
2017-03-24 18:47       ` Marc Zyngier
2017-03-27 15:53       ` Mason
2017-03-27 15:53         ` Mason
2017-03-27 17:09         ` Marc Zyngier
2017-03-27 17:09           ` Marc Zyngier
2017-03-27 19:44           ` Mason
2017-03-27 19:44             ` Mason
2017-03-27 21:07             ` Marc Zyngier
2017-03-27 21:07               ` Marc Zyngier
2017-03-27 21:07               ` Marc Zyngier
2017-03-27 22:04               ` Mason [this message]
2017-03-27 22:04                 ` Mason
2017-03-28  8:21                 ` Marc Zyngier
2017-03-28  8:21                   ` Marc Zyngier
2017-04-11 15:13           ` Mason
2017-04-11 15:13             ` Mason
2017-04-11 15:49             ` Marc Zyngier
2017-04-11 15:49               ` Marc Zyngier
2017-04-11 16:26               ` Mason
2017-04-11 16:26                 ` Mason
2017-04-11 16:43                 ` Marc Zyngier
2017-04-11 16:43                   ` Marc Zyngier
2017-04-11 17:52                   ` Mason
2017-04-11 17:52                     ` Mason
2017-04-12  8:08                     ` Marc Zyngier
2017-04-12  8:08                       ` Marc Zyngier
2017-04-12  9:50                       ` Mason
2017-04-12  9:50                         ` Mason
2017-04-12  9:59                         ` Marc Zyngier
2017-04-12  9:59                           ` Marc Zyngier
2017-04-19 11:19                           ` Mason
2017-04-19 11:19                             ` Mason
2017-04-20  8:20                             ` Mason
2017-04-20  8:20                               ` Mason
2017-04-20  9:43                               ` Marc Zyngier
2017-04-20  9:43                                 ` Marc Zyngier
2017-03-29 11:39 ` Mason
2017-03-29 11:39   ` Mason
2017-03-30 11:09 ` Mason
2017-03-30 11:09   ` Mason

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=b180c091-e4a4-7f58-7378-e0f3a24e44d6@free.fr \
    --to=slash.tmp@free.fr \
    --cc=david.laight@aculab.com \
    --cc=helgaas@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=liviu.dudau@arm.com \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=marc.zyngier@arm.com \
    --cc=phuong_nguyen@sigmadesigns.com \
    --cc=robin.murphy@arm.com \
    --cc=tglx@linutronix.de \
    --cc=thibaud_cornic@sigmadesigns.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.