Skip to content

L
linux
Switch branch/tag
  1. 06 Aug, 2018 1 commit
  3. 27 Jul, 2018 1 commit
  5. 16 Jul, 2018 6 commits
    • Marc Zyngier's avatar
      irqchip/gic-v3-its: Honor hypervisor enforced LPI range · 12b2905a
      Marc Zyngier authored 
      A recent extension to the GIC architecture allows a hypervisor to
arbitrarily reduce the number of LPIs available to a guest, no
matter what the GIC says about the valid range of IntIDs.

Let's factor in this information when computing the number of
available LPIs
Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      12b2905a
    • Marc Zyngier's avatar
      irqchip/gic-v3: Expose GICD_TYPER in the rdist structure · a4f9edb2
      Marc Zyngier authored 
      Instead of exposing the GIC distributor IntID field in the rdist
structure that is passed to the ITS, let's replace it with a
copy of the whole GICD_TYPER register. We are going to need
some of this information at a later time.

No functionnal change.
Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      a4f9edb2
    • Marc Zyngier's avatar
      irqchip/gic-v3-its: Drop chunk allocation compatibility · 38dd7c49
      Marc Zyngier authored 
      The chunk allocation system is now officially dead, so let's
remove it.
Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      38dd7c49
    • Marc Zyngier's avatar
      irqchip/gic-v3-its: Move minimum LPI requirements to individual busses · 147c8f37
      Marc Zyngier authored 
      At the moment, the core ITS driver imposes the allocation to be
in chunks of 32. As we want to relax this on a per bus basis, let's
move the the the allocation constraints to each bus.

No functionnal change.
Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      147c8f37
    • Marc Zyngier's avatar
      irqchip/gic-v3-its: Use full range of LPIs · fe8e9350
      Marc Zyngier authored 
      As we used to represent the LPI range using a bitmap, we were reducing
the number of LPIs to at most 64k in order to preserve memory.

With our new allocator, there is no such need, as dealing with 2^16
or 2^32 LPIs takes the same amount of memory.

So let's use the number of IntID bits reported by the GIC instead of
an arbitrary limit.
Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      fe8e9350
    • Marc Zyngier's avatar
      irqchip/gic-v3-its: Refactor LPI allocator · 880cb3cd
      Marc Zyngier authored 
      Our current LPI allocator relies on a bitmap, each bit representing
a chunk of 32 LPIs, meaning that each device gets allocated LPIs
in multiple of 32. It served us well so far, but new use cases now
require much more finer grain allocations, down the the individual
LPI.

Given the size of the IntID space (up to 32bit), it isn't practical
to continue using a bitmap, so let's use a different data structure
altogether.

We switch to a list, where each element represent a contiguous range
of LPIs. On allocation, we simply grab the first group big enough to
satisfy the allocation, and substract what we need from it. If the
group becomes empty, we just remove it. On freeing interrupts, we
insert a new group of interrupt in the list, sort it and fuse the
adjacent groups.

This makes freeing interrupt much more expensive than allocating
them (an unusual behaviour), but that's fine as long as we consider
that freeing interrupts is an extremely rare event.

We still allocate interrupts in blocks of 32 for the time being,
but subsequent patches will relax this.
Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      880cb3cd
  7. 15 Jul, 2018 2 commits
  9. 14 Jul, 2018 19 commits
  11. 13 Jul, 2018 11 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7