<feed xmlns='http://www.w3.org/2005/Atom'>
<title>talos-op-linux/include/linux/irqchip, branch master</title>
<subtitle>Talos™ II Linux sources for OpenPOWER</subtitle>
<id>https://git.raptorcs.com/git/talos-op-linux/atom?h=master</id>
<link rel='self' href='https://git.raptorcs.com/git/talos-op-linux/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/'/>
<updated>2020-02-08T10:01:33+00:00</updated>
<entry>
<title>irqchip/gic-v4.1: Set vpe_l1_base for all redistributors</title>
<updated>2020-02-08T10:01:33+00:00</updated>
<author>
<name>Zenghui Yu</name>
<email>yuzenghui@huawei.com</email>
</author>
<published>2020-02-06T07:57:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=8b718d403c5cdc7f0ea492c33ec88169f3e76462'/>
<id>urn:sha1:8b718d403c5cdc7f0ea492c33ec88169f3e76462</id>
<content type='text'>
Currently, we will not set vpe_l1_page for the current RD if we can
inherit the vPE configuration table from another RD (or ITS), which
results in an inconsistency between RDs within the same CommonLPIAff
group.

Let's rename it to vpe_l1_base to indicate the base address of the
vPE configuration table of this RD, and set it properly for *all*
v4.1 redistributors.

Signed-off-by: Zenghui Yu &lt;yuzenghui@huawei.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/20200206075711.1275-3-yuzenghui@huawei.com
</content>
</entry>
<entry>
<title>irqchip/gic-v4.1: Allow direct invalidation of VLPIs</title>
<updated>2020-01-22T14:22:21+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2019-12-24T11:10:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=f4a81f5a853e0b7c38bfad3afd6d0365d654e777'/>
<id>urn:sha1:f4a81f5a853e0b7c38bfad3afd6d0365d654e777</id>
<content type='text'>
Just like for INVALL, GICv4.1 has grown a VPE-aware INVLPI register.
Let's plumb it in and make use of the DirectLPI code in that case.

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Reviewed-by: Zenghui Yu &lt;yuzenghui@huawei.com&gt;
Link: https://lore.kernel.org/r/20191224111055.11836-16-maz@kernel.org
</content>
</entry>
<entry>
<title>irqchip/gic-v4.1: Add VPE INVALL callback</title>
<updated>2020-01-22T14:22:21+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2019-12-24T11:10:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=b4a4bd0f2629ec2ece7690de1b4721529da29871'/>
<id>urn:sha1:b4a4bd0f2629ec2ece7690de1b4721529da29871</id>
<content type='text'>
GICv4.1 redistributors have a VPE-aware INVALL register. Progress!
We can now emulate a guest-requested INVALL without emiting a
VINVALL command.

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Reviewed-by: Zenghui Yu &lt;yuzenghui@huawei.com&gt;
Link: https://lore.kernel.org/r/20191224111055.11836-14-maz@kernel.org
</content>
</entry>
<entry>
<title>irqchip/gic-v4.1: Add VPE residency callback</title>
<updated>2020-01-22T14:22:20+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2019-12-24T11:10:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=91bf6395f7b8614a5a9934a0ae9c8b5312d77b29'/>
<id>urn:sha1:91bf6395f7b8614a5a9934a0ae9c8b5312d77b29</id>
<content type='text'>
Making a VPE resident on GICv4.1 is pretty simple, as it is just a
single write to the local redistributor. We just need extra information
about which groups to enable, which the KVM code will have to provide.

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Reviewed-by: Zenghui Yu &lt;yuzenghui@huawei.com&gt;
Link: https://lore.kernel.org/r/20191224111055.11836-12-maz@kernel.org
</content>
</entry>
<entry>
<title>irqchip/gic-v4.1: Add mask/unmask doorbell callbacks</title>
<updated>2020-01-22T14:22:20+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2019-12-24T11:10:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=d97c97baa214486cc3d64c996a2214475f6cc83c'/>
<id>urn:sha1:d97c97baa214486cc3d64c996a2214475f6cc83c</id>
<content type='text'>
masking/unmasking doorbells on GICv4.1 relies on a new INVDB command,
which broadcasts the invalidation to all RDs.

Implement the new command as well as the masking callbacks, and plug
the whole thing into the v4.1 VPE irqchip.

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Reviewed-by: Zenghui Yu &lt;yuzenghui@huawei.com&gt;
Link: https://lore.kernel.org/r/20191224111055.11836-11-maz@kernel.org
</content>
</entry>
<entry>
<title>irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP</title>
<updated>2020-01-22T14:22:19+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2019-12-24T11:10:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=64edfaa9a2342a3ce34f8cb982c2c2df84db4de3'/>
<id>urn:sha1:64edfaa9a2342a3ce34f8cb982c2c2df84db4de3</id>
<content type='text'>
The ITS VMAPP command gains some new fields with GICv4.1:
- a default doorbell, which allows a single doorbell to be used for
  all the VLPIs routed to a given VPE
- a pointer to the configuration table (instead of having it in a register
  that gets context switched)
- a flag indicating whether this is the first map or the last unmap for
  this particular VPE
- a flag indicating whether the pending table is known to be zeroed, or not

Plumb in the new fields in the VMAPP builder, and add the map/unmap
refcounting so that the ITS can do the right thing.

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Reviewed-by: Zenghui Yu &lt;yuzenghui@huawei.com&gt;
Link: https://lore.kernel.org/r/20191224111055.11836-7-maz@kernel.org
</content>
</entry>
<entry>
<title>irqchip/gic-v4.1: VPE table (aka GICR_VPROPBASER) allocation</title>
<updated>2020-01-22T14:22:19+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2019-12-24T11:10:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=5e5168461c22c8738d31d4ee12a5cbc2ab0aa440'/>
<id>urn:sha1:5e5168461c22c8738d31d4ee12a5cbc2ab0aa440</id>
<content type='text'>
GICv4.1 defines a new VPE table that is potentially shared between
both the ITSs and the redistributors, following complicated affinity
rules.

To make things more confusing, the programming of this table at
the redistributor level is reusing the GICv4.0 GICR_VPROPBASER register
for something completely different.

The code flow is somewhat complexified by the need to respect the
affinities required by the HW, meaning that tables can either be
inherited from a previously discovered ITS or redistributor.

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Reviewed-by: Zenghui Yu &lt;yuzenghui@huawei.com&gt;
Link: https://lore.kernel.org/r/20191224111055.11836-6-maz@kernel.org
</content>
</entry>
<entry>
<title>irqchip/gic-v3: Add GICv4.1 VPEID size discovery</title>
<updated>2020-01-22T14:22:19+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2019-12-24T11:10:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=f2d834092ee276610ccb6637e5109b61fc79ab89'/>
<id>urn:sha1:f2d834092ee276610ccb6637e5109b61fc79ab89</id>
<content type='text'>
While GICv4.0 mandates 16 bit worth of VPEIDs, GICv4.1 allows smaller
implementations to be built. Add the required glue to dynamically
compute the limit.

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Reviewed-by: Zenghui Yu &lt;yuzenghui@huawei.com&gt;
Link: https://lore.kernel.org/r/20191224111055.11836-3-maz@kernel.org
</content>
</entry>
<entry>
<title>irqchip/gic-v3: Detect GICv4.1 supporting RVPEID</title>
<updated>2020-01-22T14:22:19+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2019-12-24T11:10:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=b25319d279b63781b972c4966b4082193e69afac'/>
<id>urn:sha1:b25319d279b63781b972c4966b4082193e69afac</id>
<content type='text'>
GICv4.1 supports the RVPEID ("Residency per vPE ID"), which allows for
a much efficient way of making virtual CPUs resident (to allow direct
injection of interrupts).

The functionnality needs to be discovered on each and every redistributor
in the system, and disabled if the settings are inconsistent.

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Reviewed-by: Zenghui Yu &lt;yuzenghui@huawei.com&gt;
Link: https://lore.kernel.org/r/20191224111055.11836-2-maz@kernel.org
</content>
</entry>
<entry>
<title>Merge branch 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2019-12-03T17:29:50+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2019-12-03T17:29:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=b22bfea7f16cda6e08918a3e9c7b4b99eb95ea70'/>
<id>urn:sha1:b22bfea7f16cda6e08918a3e9c7b4b99eb95ea70</id>
<content type='text'>
Pull irq updates from Ingo Molnar:
 "Most of the IRQ subsystem changes in this cycle were irq-chip driver
  updates:

   - Qualcomm PDC wakeup interrupt support

   - Layerscape external IRQ support

   - Broadcom bcm7038 PM and wakeup support

   - Ingenic driver cleanup and modernization

   - GICv3 ITS preparation for GICv4.1 updates

   - GICv4 fixes

  There's also the series from Frederic Weisbecker that fixes memory
  ordering bugs for the irq-work logic, whose primary fix is to turn
  work-&gt;irq_work.flags into an atomic variable and then convert the
  complex (and buggy) atomic_cmpxchg() loop in irq_work_claim() into a
  much simpler atomic_fetch_or() call.

  There are also various smaller cleanups"

* 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (44 commits)
  pinctrl/sdm845: Add PDC wakeup interrupt map for GPIOs
  pinctrl/msm: Setup GPIO chip in hierarchy
  irqchip/qcom-pdc: Add irqchip set/get state calls
  irqchip/qcom-pdc: Add irqdomain for wakeup capable GPIOs
  irqchip/qcom-pdc: Do not toggle IRQ_ENABLE during mask/unmask
  irqchip/qcom-pdc: Update max PDC interrupts
  of/irq: Document properties for wakeup interrupt parent
  genirq: Introduce irq_chip_get/set_parent_state calls
  irqdomain: Add bus token DOMAIN_BUS_WAKEUP
  genirq: Fix function documentation of __irq_alloc_descs()
  irq_work: Fix IRQ_WORK_BUSY bit clearing
  irqchip/ti-sci-inta: Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...))
  irq_work: Slightly simplify IRQ_WORK_PENDING clearing
  irq_work: Fix irq_work_claim() memory ordering
  irq_work: Convert flags to atomic_t
  irqchip: Ingenic: Add process for more than one irq at the same time.
  irqchip: ingenic: Alloc generic chips from IRQ domain
  irqchip: ingenic: Get virq number from IRQ domain
  irqchip: ingenic: Error out if IRQ domain creation failed
  irqchip: ingenic: Drop redundant irq_suspend / irq_resume functions
  ...
</content>
</entry>
</feed>
