On 05/05/2021 04:15, Jason Gunthorpe wrote:
On Tue, May 04, 2021 at 01:54:55PM +1000, David Gibson wrote:
On Mon, May 03, 2021 at 01:05:30PM -0300, Jason Gunthorpe wrote:
On Thu, Apr 29, 2021 at 01:20:22PM +1000, David Gibson wrote:
There is a certain appeal to having some
'PPC_TCE_CREATE_S
On Tue, May 04, 2021 at 03:11:54PM -0700, Jacob Pan wrote:
> > It is a weird way to use xarray to have a structure which
> > itself is just a wrapper around another RCU protected structure.
> >
> > Make the caller supply the ioasid_data memory, embedded in its own
> > element, get rid of the void
On Tue, May 04 2021 at 12:10, Ricardo Neri wrote:
> In x86 there is not an IRQF_NMI flag that can be used to indicate the
There exists no IRQF_NMI flag at all. No architecture provides that.
> delivery mode when requesting an interrupt (via request_irq()). Thus,
> there is no way for the interrup
Hi Jason,
On Tue, 4 May 2021 15:00:50 -0300, Jason Gunthorpe wrote:
> On Tue, May 04, 2021 at 08:41:48AM -0700, Jacob Pan wrote:
> > > >
> > > > (also looking at ioasid.c, why do we need such a thin and odd
> > > > wrapper around xarray?)
> > > >
> > >
> > > I'll leave it to Jean and Jaco
A previous changeset introduced a new member to struct irq_cfg to specify
the delivery mode of an interrupt. Supporting the configuration of the
delivery mode would require adding a third argument to prepare_irte().
Instead, simply take a pointer to an irq_cfg data structure as the only
argument.
The HPET hardlockup detector requires that the HPET timer delivers the
interrupt as NMI. When interrupt remapping is disabled, this can be
done by programming the HPET MSI registers directly. With interrupt
remapping, it is necessary to populate an entry in the interrupt
remapping table.
In x86 th
Until now, the delivery mode of APIC interrupts is set to the default
mode set in the APIC driver. However, there are no restrictions in hardware
to configure each interrupt with a different delivery mode. Specifying the
delivery mode per interrupt is useful when one is interested in changing
the d
The HPET hardlockup detector requires that the HPET timer delivers the
interrupt as NMI. When interrupt remapping is disabled, this can be
done by programming the HPET MSI registers directly. With interrupt
remapping, it is necessary to populate an entry in the interrupt
remapping table.
In x86 th
The HPET hardlockup detector needs to deliver its interrupt as NMI.
In x86 there is not an IRQF_NMI flag that can be used in the irq plumbing
code to tell interrupt remapping drivers to set the interrupt delivery
mode accordingly. Hence, they must fixup the delivery mode internally.
Implement a me
When interrupt remapping is enabled in the system, the MSI interrupt
address and data fields must follow a special format that the IOMMU
defines.
However, the HPET hardlockup detector must rely on the interrupt
subsystem to have the interrupt remapping drivers allocate, activate,
and set the affin
There is not hardware requirement to have a different delivery mode for
each interrupt. Instead of using the delivery mode of the APIC driver, use
the delivery mode of each specific interrupt configuration.
This allows to accommodate interrupts which require a specific delivery
mode, such as the H
Hi IOMMU experts,
I proposed a hardlockup detector driven by the HPET timer [1]. Such
detector is driven by a single timer. The hardlockup detector brings the
extra complexity of having to update the affinity of the interrupt
periodically and initiated from NMI context. The proposed design only
re
The pull request you sent on Tue, 4 May 2021 09:58:23 +0200:
> git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.13
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/954b7207059cc4004f2e18f49c335304b1c6d64a
Thank you!
--
Deet-doot-dot, I am a bot.
ht
On Tue, May 04, 2021 at 01:54:55PM +1000, David Gibson wrote:
> On Mon, May 03, 2021 at 01:05:30PM -0300, Jason Gunthorpe wrote:
> > On Thu, Apr 29, 2021 at 01:20:22PM +1000, David Gibson wrote:
> > > > There is a certain appeal to having some
> > > > 'PPC_TCE_CREATE_SPECIAL_IOASID' entry point tha
On Tue, May 04, 2021 at 08:41:48AM -0700, Jacob Pan wrote:
> > >
> > > (also looking at ioasid.c, why do we need such a thin and odd wrapper
> > > around xarray?)
> > >
> >
> > I'll leave it to Jean and Jacob.
> Could you elaborate?
I mean stuff like this:
int ioasid_set_data(ioasid_t ioasi
On Wed, Apr 28, 2021 at 06:58:19AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, April 28, 2021 1:12 AM
> >
> [...]
> > > As Alex says, if this line fails because of the group restrictions,
> > > that's not great because it's not very obvious what's gone wrong.
> >
>
Hi again!
On 04/05/2021 07:52, Suravee Suthikulpanit wrote:
On certain AMD platforms, when the IOMMU performance counter source
(csource) field is zero, power-gating for the counter is enabled, which
prevents write access and returns zero for read access.
This can cause invalid perf result espe
On Tue, May 04, 2021 at 09:22:55AM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Wed, 28 Apr 2021 17:46:06 -0300, Jason Gunthorpe wrote:
>
> > > > I think the name IOASID is fine for the uAPI, the kernel version can
> > > > be called ioasid_id or something.
> > >
> > > ioasid is already an id an
Hi Jason,
On Wed, 28 Apr 2021 17:46:06 -0300, Jason Gunthorpe wrote:
> > > I think the name IOASID is fine for the uAPI, the kernel version can
> > > be called ioasid_id or something.
> >
> > ioasid is already an id and then ioasid_id just adds confusion. Another
> > point is that ioasid is c
Hi Kevin,
On Wed, 28 Apr 2021 06:34:11 +, "Tian, Kevin"
wrote:
> >
> > (also looking at ioasid.c, why do we need such a thin and odd wrapper
> > around xarray?)
> >
>
> I'll leave it to Jean and Jacob.
I am not sure whether you are referring to the current ioasid.c or the
changes propos
Hi Rob,
On Friday, April 30, 2021 22:34 -03, Rob Herring wrote:
> On Thu, Apr 22, 2021 at 04:16:00PM +0200, Benjamin Gaignard wrote:
> > Add compatible for the second version of IOMMU hardware block.
> > RK356x IOMMU can also be link to a power domain.
> >
> > Signed-off-by: Benjamin Gaignar
On Tue, May 04, 2021 at 06:58:29PM +0700, Suthikulpanit, Suravee wrote:
> Peter,
>
> On 5/4/2021 4:39 PM, Peter Zijlstra wrote:
> > On Tue, May 04, 2021 at 01:52:36AM -0500, Suravee Suthikulpanit wrote:
> >
> > > 2. Since AMD IOMMU PMU does not support interrupt mode, the logic
> > > can be s
Peter,
On 5/4/2021 4:39 PM, Peter Zijlstra wrote:
On Tue, May 04, 2021 at 01:52:36AM -0500, Suravee Suthikulpanit wrote:
2. Since AMD IOMMU PMU does not support interrupt mode, the logic
can be simplified to always start counting with value zero,
and accumulate the counter value when s
On Tue, May 04, 2021 at 01:52:36AM -0500, Suravee Suthikulpanit wrote:
> 2. Since AMD IOMMU PMU does not support interrupt mode, the logic
>can be simplified to always start counting with value zero,
>and accumulate the counter value when stopping without the need
>to keep track and re
print_iommu_info prints the EFR register and then the decoded list of
features on a separate line:
pci :00:00.2: AMD-Vi: Extended features (0x206d73ef22254ade):
PPR X2APIC NX GT IA GA PC GA_vAPIC
The second line is emitted via 'pr_cont', which causes it to have a
different ('warn') loglevel
From: Simon Xue
RK356x SoC got new IOMMU hardware block (version 2).
Add a compatible to distinguish it from the first version.
Signed-off-by: Simon Xue
[Benjamin]
- port driver from kernel 4.19 to 5.12
- change functions prototype.
- squash all fixes in this commit.
Signed-off-by: Benjamin Gai
Add compatible for the second version of IOMMU hardware block.
RK356x IOMMU can also be link to a power domain.
Signed-off-by: Benjamin Gaignard
---
version 3:
- Rename compatible with SoC name
version 2:
- Add power-domains property
.../devicetree/bindings/iommu/rockchip,iommu.yaml
Convert Rockchip IOMMU to DT schema
Signed-off-by: Benjamin Gaignard
---
version 2:
- Change maintainer
- Change reg maxItems
- Change interrupt maxItems
.../bindings/iommu/rockchip,iommu.txt | 38 -
.../bindings/iommu/rockchip,iommu.yaml| 79 +++
2 fi
Add '#" to iommu-cells properties
Signed-off-by: Benjamin Gaignard
---
arch/arm/boot/dts/rk322x.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index a4dd50aaf3fc..8af2e9288029 100644
--- a/arch/arm/boot
This series adds the IOMMU driver for rk356x SoC.
Since a new compatible is needed to distinguish this second version of
IOMMU hardware block from the first one, it is an opportunity to convert
the binding to DT schema.
version 3:
- Rename compatible with soc prefix
- Rebase on v5.12 tag
versi
The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0:
Linux 5.12-rc3 (2021-03-14 14:41:02 -0700)
are available in the Git repository at:
git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.13
for you to fetch changes up to a7f3d3d3600c8ed119eb0d2483de
Le 01/05/2021 à 00:14, Rob Herring a écrit :
On Thu, Apr 22, 2021 at 02:16:53PM -0300, Ezequiel Garcia wrote:
(Adding Kever)
Hi Benjamin,
Thanks a lot for working on this, it looks amazing. Together with the great work
that Rockchip is doing, it seems RK3566/RK3568 will have decent support ve
32 matches
Mail list logo
