On Thu, Aug 20, 2020 at 06:43:47AM +0200, Christoph Hellwig wrote:
> On Wed, Aug 19, 2020 at 03:57:53PM +0200, Tomasz Figa wrote:
> > > > Could you explain what makes you think it's unused? It's a feature of
> > > > the UAPI generally supported by the videobuf2 framework and relied on
> > > > by Ch
On Wed, Aug 19, 2020 at 05:03:52PM +0200, Tomasz Figa wrote:
> >
> > -Warning: These pieces of the DMA API should not be used in the
> > -majority of cases, since they cater for unlikely corner cases that
> > -don't belong in usual drivers.
> > +These APIs allow to allocate pages that can be used l
On Wed, Aug 19, 2020 at 03:07:04PM +0100, Robin Murphy wrote:
>> FWIW, I asked back in time what the plan is for non-coherent
>> allocations and it seemed like DMA_ATTR_NON_CONSISTENT and
>> dma_sync_*() was supposed to be the right thing to go with. [2] The
>> same thread also explains why dma_all
On Wed, Aug 19, 2020 at 04:22:29PM +0200, Tomasz Figa wrote:
> > > FWIW, I asked back in time what the plan is for non-coherent
> > > allocations and it seemed like DMA_ATTR_NON_CONSISTENT and
> > > dma_sync_*() was supposed to be the right thing to go with. [2] The
> > > same thread also explains
On Wed, Aug 19, 2020 at 04:11:52PM +0200, Tomasz Figa wrote:
> > > By the way, as a videobuf2 reviewer, I'd appreciate being CC'd on any
> > > series related to the subsystem-facing DMA API changes, since
> > > videobuf2 is one of the biggest users of it.
> >
> > The cc list is too long - I cc list
On Wed, Aug 19, 2020 at 03:57:53PM +0200, Tomasz Figa wrote:
> > > Could you explain what makes you think it's unused? It's a feature of
> > > the UAPI generally supported by the videobuf2 framework and relied on
> > > by Chromium OS to get any kind of reasonable performance when
> > > accessing V4
Christoph Hellwig writes:
> On Tue, Aug 18, 2020 at 07:11:26PM -0300, Thiago Jung Bauermann wrote:
>> POWER secure guests (i.e., guests which use the Protection Execution
>> Facility) need to use SWIOTLB to be able to do I/O with the hypervisor, but
>> they don't need the SWIOTLB memory to be in l
From: Boris Ostrovsky
[ Upstream commit 8b1e868f66076490189a36d984fcce286cdd6295 ]
xen_alloc_coherent_pages might return pages for which virt_to_phys and
virt_to_page don't work, e.g. ioremap'ed pages.
So in xen_swiotlb_free_coherent we can't assume that virt_to_page works.
Instead add a is_vma
From: Boris Ostrovsky
[ Upstream commit 8b1e868f66076490189a36d984fcce286cdd6295 ]
xen_alloc_coherent_pages might return pages for which virt_to_phys and
virt_to_page don't work, e.g. ioremap'ed pages.
So in xen_swiotlb_free_coherent we can't assume that virt_to_page works.
Instead add a is_vma
From: Boris Ostrovsky
[ Upstream commit 8b1e868f66076490189a36d984fcce286cdd6295 ]
xen_alloc_coherent_pages might return pages for which virt_to_phys and
virt_to_page don't work, e.g. ioremap'ed pages.
So in xen_swiotlb_free_coherent we can't assume that virt_to_page works.
Instead add a is_vma
On Wed, Aug 19, 2020 at 12:24:05PM -0700, Andrew Morton wrote:
> On Tue, 18 Aug 2020 18:16:26 +0300 Mike Rapoport wrote:
>
> > From: Mike Rapoport
> >
> > The only user of memblock_dbg() outside memblock was s390 setup code and it
> > is converted to use pr_debug() instead.
> > This allows to s
Konrad Rzeszutek Wilk writes:
> On Tue, Aug 18, 2020 at 07:11:26PM -0300, Thiago Jung Bauermann wrote:
>> POWER secure guests (i.e., guests which use the Protection Execution
>> Facility) need to use SWIOTLB to be able to do I/O with the hypervisor, but
>> they don't need the SWIOTLB memory to
On Tue, 18 Aug 2020 18:16:26 +0300 Mike Rapoport wrote:
> From: Mike Rapoport
>
> The only user of memblock_dbg() outside memblock was s390 setup code and it
> is converted to use pr_debug() instead.
> This allows to stop exposing memblock_debug and memblock_dbg() to the rest
> of the kernel.
>
Hi,
On Wed, Aug 19, 2020 at 10:36 AM Rob Clark wrote:
>
> On Wed, Aug 19, 2020 at 10:03 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Mon, Aug 17, 2020 at 3:03 PM Rob Clark wrote:
> > >
> > > From: Jordan Crouse
> > >
> > > Every Qcom Adreno GPU has an embedded SMMU for its own use. These
> >
The of_device_id is included unconditionally by of.h header and used
in the driver as well. Remove of_match_ptr to fix W=1 compile test
warning with !CONFIG_OF:
drivers/iommu/qcom_iommu.c:910:34: warning: 'qcom_iommu_of_match' defined
but not used [-Wunused-const-variable=]
910 | stati
Fix W=1 compile warnings (invalid kerneldoc):
drivers/iommu/intel/dmar.c:389: warning: Function parameter or member
'header' not described in 'dmar_parse_one_drhd'
Signed-off-by: Krzysztof Kozlowski
---
drivers/iommu/intel/dmar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
The of_device_id is included unconditionally by of.h header and used
in the driver as well. Remove of_match_ptr to fix W=1 compile test
warning with !CONFIG_OF:
drivers/iommu/mtk_iommu.c:833:34: warning: 'mtk_iommu_of_ids' defined but
not used [-Wunused-const-variable=]
833 | static co
Few exported functions from AMD IOMMU driver are missing prototypes.
They have declaration in arch/x86/events/amd/iommu.h but this file
cannot be included in the driver. Add prototypes to fix W=1 warnings
like:
drivers/iommu/amd/init.c:3066:19: warning:
no previous prototype for 'get_
Fix W=1 compile warnings (invalid kerneldoc):
drivers/iommu/amd/init.c:1586: warning: Function parameter or member 'ivrs'
not described in 'get_highest_supported_ivhd_type'
drivers/iommu/amd/init.c:1938: warning: Function parameter or member
'iommu' not described in 'iommu_update_intcapx
Hi Andy,
On Wed, Aug 19, 2020 at 2:16 PM Andy Shevchenko
wrote:
> - unsigned long bytes = io_tlb_nslabs << IO_TLB_SHIFT;
> + unsigned long mb = (io_tlb_nslabs << IO_TLB_SHIFT) >> 20;
Looks like an unrelated change.
___
iommu mailing list
i
On Wed, Aug 19, 2020 at 02:24:10PM -0300, Fabio Estevam wrote:
> On Wed, Aug 19, 2020 at 2:16 PM Andy Shevchenko
> wrote:
>
> > - unsigned long bytes = io_tlb_nslabs << IO_TLB_SHIFT;
> > + unsigned long mb = (io_tlb_nslabs << IO_TLB_SHIFT) >> 20;
>
> Looks like an unrelated change.
On Wed, Aug 19, 2020 at 10:03 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Aug 17, 2020 at 3:03 PM Rob Clark wrote:
> >
> > From: Jordan Crouse
> >
> > Every Qcom Adreno GPU has an embedded SMMU for its own use. These
> > devices depend on unique features such as split pagetables,
> > different s
Hi,
On Mon, Aug 17, 2020 at 3:03 PM Rob Clark wrote:
>
> From: Jordan Crouse
>
> Every Qcom Adreno GPU has an embedded SMMU for its own use. These
> devices depend on unique features such as split pagetables,
> different stall/halt requirements and other settings. Identify them
> with a compatib
Sparse is not happy about max_segment declaration:
CHECK kernel/dma/swiotlb.c
kernel/dma/swiotlb.c:96:14: warning: symbol 'max_segment' was not declared.
Should it be static?
Mark it static as suggested.
Signed-off-by: Andy Shevchenko
---
kernel/dma/swiotlb.c | 2 +-
1 file changed, 1 i
Compiler is not happy about one function prototype:
CC kernel/dma/swiotlb.o
kernel/dma/swiotlb.c:275:1: warning: no previous prototype for
‘swiotlb_late_init_with_default_size’ [-Wmissing-prototypes]
275 | swiotlb_late_init_with_default_size(size_t default_size)
| ^~~
There is an extension to a %p to print phys_addr_t type of variables.
Use it here.
Signed-off-by: Andy Shevchenko
---
kernel/dma/swiotlb.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index c19379fabd20..676ccf0e49d3 10064
On Tue, Aug 18, 2020 at 07:11:26PM -0300, Thiago Jung Bauermann wrote:
> POWER secure guests (i.e., guests which use the Protection Execution
> Facility) need to use SWIOTLB to be able to do I/O with the hypervisor, but
> they don't need the SWIOTLB memory to be in low addresses since the
> hypervi
Christoph Hellwig writes:
> On Tue, Aug 18, 2020 at 07:11:26PM -0300, Thiago Jung Bauermann wrote:
>> POWER secure guests (i.e., guests which use the Protection Execution
>> Facility) need to use SWIOTLB to be able to do I/O with the hypervisor, but
>> they don't need the SWIOTLB memory to be i
Hi Christoph,
On Wed, Aug 19, 2020 at 8:57 AM Christoph Hellwig wrote:
>
> Add a new API to allocate and free pages that are guaranteed to be
> addressable by a device, but otherwise behave like pages allocated by
> alloc_pages. The intended APIs to sync them for use with the device
> and cpu ar
On Wed, Aug 19, 2020 at 4:07 PM Robin Murphy wrote:
>
> On 2020-08-19 13:49, Tomasz Figa wrote:
> > On Wed, Aug 19, 2020 at 1:51 PM Robin Murphy wrote:
> >>
> >> Hi Tomasz,
> >>
> >> On 2020-08-19 12:16, Tomasz Figa wrote:
> >>> Hi Christoph,
> >>>
> >>> On Wed, Aug 19, 2020 at 8:56 AM Christoph
On Wed, Aug 19, 2020 at 3:57 PM Christoph Hellwig wrote:
>
> On Wed, Aug 19, 2020 at 02:49:01PM +0200, Tomasz Figa wrote:
> > With the default config it doesn't, but with
> > CONFIG_DMA_NONCOHERENT_CACHE_SYNC enabled it makes dma_pgprot() keep
> > the pgprot value as is, without enforcing coherenc
On 2020-08-19 13:49, Tomasz Figa wrote:
On Wed, Aug 19, 2020 at 1:51 PM Robin Murphy wrote:
Hi Tomasz,
On 2020-08-19 12:16, Tomasz Figa wrote:
Hi Christoph,
On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote:
The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused,
Could you e
On Wed, Aug 19, 2020 at 3:55 PM Christoph Hellwig wrote:
>
> On Wed, Aug 19, 2020 at 01:16:51PM +0200, Tomasz Figa wrote:
> > Hi Christoph,
> >
> > On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote:
> > >
> > > The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused,
> >
> > Could you e
On Wed, Aug 19, 2020 at 02:49:01PM +0200, Tomasz Figa wrote:
> With the default config it doesn't, but with
> CONFIG_DMA_NONCOHERENT_CACHE_SYNC enabled it makes dma_pgprot() keep
> the pgprot value as is, without enforcing coherence attributes.
Which isn't selected on arm64, and that is for a good
On Wed, Aug 19, 2020 at 01:16:51PM +0200, Tomasz Figa wrote:
> Hi Christoph,
>
> On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote:
> >
> > The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused,
>
> Could you explain what makes you think it's unused? It's a feature of
> the UAPI gene
On Wed, Aug 19, 2020 at 1:51 PM Robin Murphy wrote:
>
> Hi Tomasz,
>
> On 2020-08-19 12:16, Tomasz Figa wrote:
> > Hi Christoph,
> >
> > On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote:
> >>
> >> The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused,
> >
> > Could you explain what m
Hi Tomasz,
On 2020-08-19 12:16, Tomasz Figa wrote:
Hi Christoph,
On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote:
The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused,
Could you explain what makes you think it's unused? It's a feature of
the UAPI generally supported by the v
On 2020-08-19 11:28, Mauro Carvalho Chehab wrote:
Em Tue, 18 Aug 2020 15:02:54 -0700
John Stultz escreveu:
On Tue, Aug 18, 2020 at 9:26 AM Robin Murphy wrote:
On 2020-08-18 16:29, Mauro Carvalho Chehab wrote:
Em Tue, 18 Aug 2020 15:47:55 +0100
Basically, the DT binding has this, for IOMMU:
Hi Christoph,
On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote:
>
> The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused,
Could you explain what makes you think it's unused? It's a feature of
the UAPI generally supported by the videobuf2 framework and relied on
by Chromium OS to ge
Em Tue, 18 Aug 2020 15:02:54 -0700
John Stultz escreveu:
> On Tue, Aug 18, 2020 at 9:26 AM Robin Murphy wrote:
> > On 2020-08-18 16:29, Mauro Carvalho Chehab wrote:
> > > Em Tue, 18 Aug 2020 15:47:55 +0100
> > > Basically, the DT binding has this, for IOMMU:
> > >
> > >
> > > smmu_lpae {
On 2020-08-18 23:02, John Stultz wrote:
On Tue, Aug 18, 2020 at 9:26 AM Robin Murphy wrote:
On 2020-08-18 16:29, Mauro Carvalho Chehab wrote:
Em Tue, 18 Aug 2020 15:47:55 +0100
Basically, the DT binding has this, for IOMMU:
smmu_lpae {
compatible = "hisilicon,smmu-lpae"
41 matches
Mail list logo
