> It's interesting to see this from a fresh angle which isn't clouded by
> other SoC GPU details - thanks for the proposal! A couple more thoughts
> jump out immediately...
>
Thanks a lot! for jumping in and providing your valuable insights :)
Sorry! for taking time to reply on this. Did some
This patch adds the bindings for the Page-based Address Translator (PAT)
present on various TI SoCs. A Page-based Address Translator (PAT) device
performs address translation using tables stored in an internal SRAM.
Each PAT supports a set number of pages, each occupying a programmable
4KB, 16KB, 6
Hello all,
So I've got a new IP on our new SoC I'm looking to make use of and would
like some help figuring out what framework best matches its function. The
IP is called a "Page-based Address Translator" or PAT. A PAT instance
(there are 5 of these things on our J721e device[0]) is basically a
re
This patch adds a driver for the Page-based Address Translator (PAT)
present on various TI SoCs. A PAT device performs address translation
using tables stored in an internal SRAM. Each PAT supports a set number
of pages, each occupying a programmable 4KB, 16KB, 64KB, or 1MB of
addresses in a window
The linux-next series "iommu/vt-d: Delegate DMA domain to generic iommu" [1]
causes a system with the rootfs on megaraid_sas card unable to boot.
Reverted the whole series on the top of linux-next (next-20190607) fixed the
issue.
The information regards this storage card is,
[
On Fri, 7 Jun 2019 11:28:13 +0100
Jean-Philippe Brucker wrote:
> On 06/06/2019 21:29, Jacob Pan wrote:
> >> iommu_unregister_device_fault_handler(&vdev->pdev->dev);
> >
> >
> > But this can fail if there are pending faults which leaves a
> > device reference and then the
On Fri, 7 Jun 2019 16:47:13 +0900
Yoshihiro Shimoda wrote:
> The exported function name is dma_max_mapping_size(), not
> dma_direct_max_mapping_size() so that this patch fixes
> the function name in the documentation.
>
> Fixes: 133d624b1cee ("dma: Introduce dma_max_mapping_size()")
> Signed-of
On Fri, 7 Jun 2019 10:28:06 +0200
Auger Eric wrote:
> Hi Alex,
>
> On 6/4/19 12:31 AM, Alex Williamson wrote:
> > On Sun, 26 May 2019 18:10:00 +0200
> > Eric Auger wrote:
> >
> >> This patch adds two new regions aiming to handle nested mode
> >> translation faults.
> >>
> >> The first region
Hi Jean,
On 6/7/19 2:48 PM, Jean-Philippe Brucker wrote:
> On 26/05/2019 17:10, Eric Auger wrote:
>> +int vfio_pci_iommu_dev_fault_handler(struct iommu_fault_event *evt, void
>> *data)
>> +{
>> +struct vfio_pci_device *vdev = (struct vfio_pci_device *) data;
>> +struct vfio_region_fault_p
On Thu, Jun 06, 2019 at 05:35:51PM -0700, Stephane Eranian wrote:
> Hi Ricardo,
Hi Stephane,
> Thanks for your contribution here. It is very important to move the
> watchdog out of the PMU wherever possible.
Indeed, using the PMU for the hardlockup detector is still the default
option. This patc
On 07/06/2019 03:24, Prakhya, Sai Praneeth wrote:
Hi All,
I am working on an IOMMU driver feature that allows a user to specify if the DMA from a device
should be translated by IOMMU or not. Presently, we support only all devices or none mode i.e. if
user specifies "iommu=pt" [X86] or "iommu.p
On 26/05/2019 17:10, Eric Auger wrote:
> +int vfio_pci_iommu_dev_fault_handler(struct iommu_fault_event *evt, void
> *data)
> +{
> + struct vfio_pci_device *vdev = (struct vfio_pci_device *) data;
> + struct vfio_region_fault_prod *prod_region =
> + (struct vfio_region_fault_pr
On 07/06/2019 09:28, Auger Eric wrote:
>>> +static const struct vfio_pci_fault_abi fault_abi_versions[] = {
>>> + [0] = {
>>> + .entry_size = sizeof(struct iommu_fault),
>>> + },
>>> +};
>>> +
>>> +#define NR_FAULT_ABIS ARRAY_SIZE(fault_abi_versions)
>>
>> This looks like it's leading
Hi Christoph,
> From: Christoph Hellwig, Sent: Friday, June 7, 2019 5:35 PM
>
> On Fri, Jun 07, 2019 at 08:19:08AM +, Yoshihiro Shimoda wrote:
> > Hi Christoph,
> >
> > > From: Christoph Hellwig, Sent: Friday, June 7, 2019 5:08 PM
> > >
> > > Looks good. And it seems like you've also found t
Hi Christoph,
I think we should continue to discuss on this email thread instead of the fixed
DMA-API.txt patch [1]
[1]
https://marc.info/?t=15598941221&r=1&w=2
> From: Yoshihiro Shimoda, Sent: Monday, June 3, 2019 3:42 PM
>
> Hi linux-block and iommu mailing lists,
>
> I have an issue th
On 05/06/2019 14:19, Will Deacon wrote:
> On Mon, Jun 03, 2019 at 02:15:37PM +0200, Marc Gonzalez wrote:
>
>> From: Robin Murphy
>>
>> Apparently, some Qualcomm arm64 platforms which appear to expose their
>> SMMU global register space are still, in fact, using a hypervisor to
>> mediate it by tr
On 06/06/2019 21:29, Jacob Pan wrote:
>> iommu_unregister_device_fault_handler(&vdev->pdev->dev);
>
>
> But this can fail if there are pending faults which leaves a
> device reference and then the system is broken :(
This series only features unrecoverable errors an
+ Rob
On Wed, 5 Jun 2019 at 16:23, Thierry Reding wrote:
>
> From: Thierry Reding
>
> Some subsystems, such as pinctrl, allow continuing to defer probe
> indefinitely. This is useful for devices that depend on resources
> provided by devices that are only probed after the init stage.
>
> One exa
On Fri, Jun 07, 2019 at 08:19:08AM +, Yoshihiro Shimoda wrote:
> Hi Christoph,
>
> > From: Christoph Hellwig, Sent: Friday, June 7, 2019 5:08 PM
> >
> > Looks good. And it seems like you've also found the solution to
> > your usb storage problem, but I'm going to post the variant I just
> >
Hi Alex,
On 6/4/19 12:32 AM, Alex Williamson wrote:
> On Sun, 26 May 2019 18:09:59 +0200
> Eric Auger wrote:
>
>> This patch adds the VFIO_IOMMU_BIND/UNBIND_MSI ioctl which aim
>> to pass/withdraw the guest MSI binding to/from the host.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>> v6 -> v7:
>>
Hi Alex,
On 6/4/19 12:31 AM, Alex Williamson wrote:
> On Sun, 26 May 2019 18:10:00 +0200
> Eric Auger wrote:
>
>> This patch adds two new regions aiming to handle nested mode
>> translation faults.
>>
>> The first region (two host kernel pages) is read-only from the
>> user-space perspective. Th
Hi Christoph,
> From: Christoph Hellwig, Sent: Friday, June 7, 2019 5:08 PM
>
> Looks good. And it seems like you've also found the solution to
> your usb storage problem, but I'm going to post the variant I just
> hacked up nevertheless.
Thank you for your reply! I think this API is related to
Looks good. And it seems like you've also found the solution to
your usb storage problem, but I'm going to post the variant I just
hacked up nevertheless.
The exported function name is dma_max_mapping_size(), not
dma_direct_max_mapping_size() so that this patch fixes
the function name in the documentation.
Fixes: 133d624b1cee ("dma: Introduce dma_max_mapping_size()")
Signed-off-by: Yoshihiro Shimoda
---
Documentation/DMA-API.txt | 2 +-
1 file cha
Hi Jean, Jacob,
On 6/6/19 10:29 PM, Jacob Pan wrote:
> On Thu, 6 Jun 2019 19:54:05 +0100
> Jean-Philippe Brucker wrote:
>
>> On 05/06/2019 23:45, Jacob Pan wrote:
>>> On Tue, 4 Jun 2019 18:11:08 +0200
>>> Auger Eric wrote:
>>>
Hi Alex,
On 6/4/19 12:31 AM, Alex Williamson wrote
25 matches
Mail list logo
