1. 20 Aug, 2018 2 commits
  2. 13 Aug, 2018 3 commits
  3. 06 Aug, 2018 1 commit
  4. 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
  6. 15 Jul, 2018 2 commits
  7. 14 Jul, 2018 19 commits
  8. 13 Jul, 2018 6 commits