/juno), thanks!
[1/2] arm64: dts: juno: Describe PCI dma-ranges
https://git.kernel.org/sudeep.holla/c/4ac4d146cb
[2/2] arm64: dts: juno: Enable more SMMUs
https://git.kernel.org/sudeep.holla/c/d9df28ba58
--
Regards,
Sudeep
When building tinyconfig on parisc the following warnign shows up:
/tmp/arch/parisc/kernel/pci-dma.c:338:12: warning: 'proc_pcxl_dma_show' defined
but not used [-Wunused-function]
static int proc_pcxl_dma_show(struct seq_file *m, void *v)
^~
Mark the function as __ma
On Tue, 2020-10-20 at 21:21 -0500, Bjorn Helgaas wrote:
> On Wed, Oct 21, 2020 at 01:20:24AM +, Derrick, Jonathan wrote:
> > On Tue, 2020-10-20 at 15:26 -0500, Bjorn Helgaas wrote:
> > > On Tue, Jul 28, 2020 at 01:49:44PM -0600, Jon Derrick wrote:
> > > > VMD retransmits child device MSI/X with
On Wed, Oct 21, 2020 at 01:20:24AM +, Derrick, Jonathan wrote:
> On Tue, 2020-10-20 at 15:26 -0500, Bjorn Helgaas wrote:
> > On Tue, Jul 28, 2020 at 01:49:44PM -0600, Jon Derrick wrote:
> > > VMD retransmits child device MSI/X with the VMD endpoint's requester-id.
> > > In order to support dire
On Tue, 2020-10-20 at 15:26 -0500, Bjorn Helgaas wrote:
> On Tue, Jul 28, 2020 at 01:49:44PM -0600, Jon Derrick wrote:
> > VMD retransmits child device MSI/X with the VMD endpoint's requester-id.
> > In order to support direct interrupt remapping of VMD child devices,
> > ensure that the IRTE is pr
On Tue, Jul 28, 2020 at 01:49:44PM -0600, Jon Derrick wrote:
> VMD retransmits child device MSI/X with the VMD endpoint's requester-id.
> In order to support direct interrupt remapping of VMD child devices,
> ensure that the IRTE is programmed with the VMD endpoint's requester-id
> using pci_real_d
On Mon, Sep 07 2020 at 15:32, Lorenzo Pieralisi wrote:
> On Tue, Jul 28, 2020 at 01:49:44PM -0600, Jon Derrick wrote:
>> VMD retransmits child device MSI/X with the VMD endpoint's requester-id.
>> In order to support direct interrupt remapping of VMD child devices,
>> ensure that the IRTE is progr
On Tue, Jul 28, 2020 at 01:49:44PM -0600, Jon Derrick wrote:
> VMD retransmits child device MSI/X with the VMD endpoint's requester-id.
> In order to support direct interrupt remapping of VMD child devices,
> ensure that the IRTE is programmed with the VMD endpoint's requester-id
> using pci_real_d
On Wed, 29 Jul 2020 23:35:29 +0530, Suraj Upadhyay wrote:
> Hii Maintainers,
> This patchset replaces the pci-dma-compat wrappers with their
> dma-mapping counterparts. Thus, removing possible midlayering and
> unnecessary legacy code and API.
>
> Most of the task i
On Sun, Aug 09, 2020 at 12:54:28PM +0530, Suraj Upadhyay wrote:
> Hii Developers,
>
> This patch series will replace all the legacy pci-dma-compat wrappers
> with the dma-mapping APIs directly in the INFINIBAND Subsystem.
>
> This task is done through a coccinelle script
On Sun, Aug 09, 2020 at 11:35:51AM +0300, Gal Pressman wrote:
> On 09/08/2020 10:24, Suraj Upadhyay wrote:
> > Hii Developers,
> >
> > This patch series will replace all the legacy pci-dma-compat wrappers
> > with the dma-mapping APIs directly in the INFINIBAND Su
On 09/08/2020 10:24, Suraj Upadhyay wrote:
> Hii Developers,
>
> This patch series will replace all the legacy pci-dma-compat wrappers
> with the dma-mapping APIs directly in the INFINIBAND Subsystem.
>
> This task is done through a coccinelle script which is described
On Sun, 2020-08-09 at 13:15 +0530, Suraj Upadhyay wrote:
> The legacy API wrappers in include/linux/pci-dma-compat.h
> should go away as it creates unnecessary midlayering
> for include/linux/dma-mapping.h APIs.
>
> Instead use dma-mapping.h APIs directly.
>
> The patch ha
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested
Hii Developers,
This patch series will replace all the legacy pci-dma-compat wrappers
with the dma-mapping APIs directly in the INFINIBAND Subsystem.
This task is done through a coccinelle script which is described in each commit
message.
The changes are compile tested.
Thanks,
Suraj
On Tue, Jul 28, 2020 at 11:40:12PM -0400, Martin K. Petersen wrote:
>
> Hello Suraj!
>
> > The legacy API wrappers in include/linux/pci-dma-compat.h
> > should go away as it creates unnecessary midlayering
> > for include/linux/dma-mapping.h APIs, instead use dma-
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.
The patch has been generated with the coccinelle script below.
And has been hand modified to replace each
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.
The patch has been generated with the coccinelle script below.
Compile tested
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.
The patch has been generated with the coccinelle script below.
Compile tested
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.
The patch has been generated with the coccinelle script below.
Compile tested
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering for
include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.
The patch has been generated with the coccinelle script below.
Compile tested
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.
The patch has been generated with the coccinelle script below.
And has been hand modified to replace each
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering for
include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.
The patch has been generated with the coccinelle script below.
Compile-tested
Hii Maintainers,
This patchset replaces the pci-dma-compat wrappers with their
dma-mapping counterparts. Thus, removing possible midlayering and
unnecessary legacy code and API.
Most of the task is fairly trivially scriptable and done with
coccinelle. But the handling of pci_z
Hello Suraj!
> The legacy API wrappers in include/linux/pci-dma-compat.h
> should go away as it creates unnecessary midlayering
> for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
> APIs directly.
Instead of all these individual patches, please submit a combined patc
VMD retransmits child device MSI/X with the VMD endpoint's requester-id.
In order to support direct interrupt remapping of VMD child devices,
ensure that the IRTE is programmed with the VMD endpoint's requester-id
using pci_real_dma_dev().
Reviewed-by: Andy Shevchenko
Signed-off-by: Jon Derrick
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below and has
been hand modified to replace GFP_
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below
and has been hand modified to replace GFP_
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below
and has been hand modified to replace GFP_
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below
and has been hand modified to replace GFP_
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below and has
been hand modified to replace GFP_
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below
and has been hand modified to replace GFP_
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested
On 13/07/2020 15:32, Suraj Upadhyay wrote:
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested
On 11/07/2020 14:38, Christophe JAILLET wrote:
Le 11/07/2020 à 14:35, Suraj Upadhyay a écrit :
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch
On 2020-07-13 11:14 +0530, Suraj Upadhyay wrote:
> On Mon, Jul 13, 2020 at 01:59:59PM +0900, Benjamin Poirier wrote:
> > On 2020-07-11 18:16 +0530, Suraj Upadhyay wrote:
> > > The legacy API wrappers in include/linux/pci-dma-compat.h
> > > should go away as it crea
On Mon, Jul 13, 2020 at 01:59:59PM +0900, Benjamin Poirier wrote:
> On 2020-07-11 18:16 +0530, Suraj Upadhyay wrote:
> > The legacy API wrappers in include/linux/pci-dma-compat.h
> > should go away as it creates unnecessary midlayering
> > for include/linux/dma-mapping.h
On 2020-07-11 18:16 +0530, Suraj Upadhyay wrote:
> The legacy API wrappers in include/linux/pci-dma-compat.h
> should go away as it creates unnecessary midlayering
> for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
> APIs directly.
>
> The patch has been
Le 11/07/2020 à 14:35, Suraj Upadhyay a écrit :
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested
Hello,
Maciej W. Rozycki wrote:
> Hi,
>
> This mini patch series enables correct support for DMA in the presence of
> memory outside the 32-bit address range with the Broadcom SiByte SOCs and
> the relevant development boards.
>
> There is a quirk in the BCM1250, BCM1125 and BCM1125H SOCs in tha
Hi,
This mini patch series enables correct support for DMA in the presence of
memory outside the 32-bit address range with the Broadcom SiByte SOCs and
the relevant development boards.
There is a quirk in the BCM1250, BCM1125 and BCM1125H SOCs in that their
onchip 32-bit PCI host bridge does
Hi,
This mini patch series enables correct support for DMA in the presence of
memory outside the 32-bit address range with the Broadcom SiByte SOCs and
the relevant development boards.
There is a quirk in the BCM1250, BCM1125 and BCM1125H SOCs in that their
onchip 32-bit PCI host bridge does
Hi,
This mini patch series enables correct support for DMA in the presence of
memory outside the 32-bit address range with the Broadcom SiByte SOCs and
the relevant development boards.
There is a quirk in the BCM1250, BCM1125 and BCM1125H SOCs in that their
onchip 32-bit PCI host bridge does
Thanks,
applied to the dma-mapping tree.
From: Huaisheng Ye
arch_dma_alloc_attrs has parameter gfp which is not used at all.
Remove it.
Signed-off-by: Huaisheng Ye
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: Konrad Rzeszutek Wilk
Cc: Andrew Morton
Cc:
Christoph,
that patch fixed the panic. Thank you for the fix. Please submit
them to the netdev mailing list.
- Matthew
Does it work with this patch applied?
---
>From 564da7415bbd43457561b1e4c4cf07d1c7e20d44 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Mon, 7 May 2018 12:11:49 +0200
Subject: 3c59x: convert to generic DMA API
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/3com/3c59x.c | 104
Christoph,
I bisected the following kernel panic to the patch "PCI: Remove NULL
device handling from PCI DMA API". It seems we
still need NULL checking for some older drivers, in my case the 3c59x
driver for PCI/EISA cards.
I am pretty sure the panic arises in the driver here
(d
Historically some ISA drivers used the old PCI DMA API with a NULL pdev
argument, but these days this isn't used and not too useful due to the
per-device DMA ops, so remove it.
Signed-off-by: Christoph Hellwig
---
include/linux/pci-dma-compat.h | 27 +--
1 file ch
On Tue, Jan 09, 2018 at 06:25:44PM -0600, Bjorn Helgaas wrote:
> It looks like "pci_free_consistent(NULL" is still used in
> drivers/net/ethernet/tundra/tsi108_eth.c.
Yikes. That one needs to pass the device is the platform dev to
the dma_map_* routines to start with, and mixing that with PCI
is
s/pci-dma-compat: remove handling of NULL pdev
/PCI: Remove NULL device handling from DMA API/
On Tue, Jan 09, 2018 at 09:39:39PM +0100, Christoph Hellwig wrote:
> Historically some ISA drivers used the old pci DMA API with a NULL pdev
> argument, but these days this isn't used
Historically some ISA drivers used the old pci DMA API with a NULL pdev
argument, but these days this isn't used and not too useful due to the
per-device DMA ops, so remove it.
Signed-off-by: Christoph Hellwig
---
include/linux/pci-dma-compat.h | 27 +--
1 file ch
On Thu, May 18, 2017 at 12:43 AM, Arnd Bergmann wrote:
> On Tue, May 16, 2017 at 7:22 AM, Oza Pawandeep wrote:
>> current device framework and OF framework integration assumes
>> dma-ranges in a way where memory-mapped devices define their
>> dma-ranges. (child-bus-address, parent-bus-address, le
On Thu, May 18, 2017 at 12:43 AM, Arnd Bergmann wrote:
> On Tue, May 16, 2017 at 7:22 AM, Oza Pawandeep wrote:
>> current device framework and OF framework integration assumes
>> dma-ranges in a way where memory-mapped devices define their
>> dma-ranges. (child-bus-address, parent-bus-address, le
On Wed, May 17, 2017 at 10:40 PM, Bjorn Helgaas wrote:
> On Tue, May 16, 2017 at 10:52:05AM +0530, Oza Pawandeep wrote:
>> current device framework and OF framework integration assumes
>
> s/current/The current/
>
>> dma-ranges in a way where memory-mapped devices define their
>> dma-ranges. (chil
On Tue, May 16, 2017 at 7:22 AM, Oza Pawandeep wrote:
> current device framework and OF framework integration assumes
> dma-ranges in a way where memory-mapped devices define their
> dma-ranges. (child-bus-address, parent-bus-address, length).
>
> of_dma_configure is specifically written to take c
On Tue, May 16, 2017 at 10:52:05AM +0530, Oza Pawandeep wrote:
> current device framework and OF framework integration assumes
s/current/The current/
> dma-ranges in a way where memory-mapped devices define their
> dma-ranges. (child-bus-address, parent-bus-address, length).
>
> of_dma_configure
On Sat, May 6, 2017 at 11:00 AM, Oza Oza wrote:
> On Fri, May 5, 2017 at 8:55 PM, Robin Murphy wrote:
>> On 04/05/17 19:41, Oza Oza wrote:
>> [...]
> 5) leaves scope of adding PCI flag handling for inbound memory
> by the new function.
Which flags would ever actually matter? DMA
current device framework and OF framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).
of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for p
On Fri, May 5, 2017 at 8:55 PM, Robin Murphy wrote:
> On 04/05/17 19:41, Oza Oza wrote:
> [...]
5) leaves scope of adding PCI flag handling for inbound memory
by the new function.
>>>
>>> Which flags would ever actually matter? DMA windows aren't going to be
>>> to config or I/O space, s
On 04/05/17 19:41, Oza Oza wrote:
[...]
>>> 5) leaves scope of adding PCI flag handling for inbound memory
>>> by the new function.
>>
>> Which flags would ever actually matter? DMA windows aren't going to be
>> to config or I/O space, so the memory type can be assumed, and the
>> 32/64-bit distinc
current device framework and OF framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).
of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for p
current device framework and OF framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).
of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for p
current device framework and OF framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).
of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for p
current device framework and OF framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).
of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for p
current device framework and OF framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).
of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for p
On Thu, May 4, 2017 at 11:32 PM, Robin Murphy wrote:
> [apologies for the silence - I've been on holiday]
>
> On 03/05/17 05:46, Oza Pawandeep wrote:
>> current device framework and of framework integration assumes
>> dma-ranges in a way where memory-mapped devices define their
>> dma-ranges. (chi
On Thu, May 4, 2017 at 11:32 PM, Robin Murphy wrote:
> [apologies for the silence - I've been on holiday]
>
> On 03/05/17 05:46, Oza Pawandeep wrote:
>> current device framework and of framework integration assumes
>> dma-ranges in a way where memory-mapped devices define their
>> dma-ranges. (chi
[apologies for the silence - I've been on holiday]
On 03/05/17 05:46, Oza Pawandeep wrote:
> current device framework and of framework integration assumes
> dma-ranges in a way where memory-mapped devices define their
> dma-ranges. (child-bus-address, parent-bus-address, length).
Well, yes, that
On Tue, May 2, 2017 at 11:46 PM, Oza Pawandeep wrote:
> current device framework and of framework integration assumes
> dma-ranges in a way where memory-mapped devices define their
> dma-ranges. (child-bus-address, parent-bus-address, length).
>
> of_dma_configure is specifically written to take c
I will send v2 after removing GERRIT details from
commit message. My apologies for the noise.
Regards,
Oza
(!node)
>> return -EINVAL;
>>
>> + if (strcmp(np->name, "pci")) {
>
> Using the name is not reliable though I did recently add a dtc check
> for this. Of course, 'pcie' is valid too (and probably should be used
> for what you
current device framework and of framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).
of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for p
On Sat, Apr 22, 2017 at 3:08 AM, Oza Pawandeep wrote:
> current device frmework and of framework integration assumes dma-ranges
> in a way where memory-mapped devices define their dma-ranges.
> dma-ranges: (child-bus-address, parent-bus-address, length).
>
> but iproc based SOCs and other SOCs(suc
current device frmework and of framework integration assumes dma-ranges
in a way where memory-mapped devices define their dma-ranges.
dma-ranges: (child-bus-address, parent-bus-address, length).
but iproc based SOCs and other SOCs(suc as rcar) have PCI world dma-ranges.
dma-ranges = <0x4300 0x
On Tue, Mar 28, 2017 at 7:43 PM, Rob Herring wrote:
> On Tue, Mar 28, 2017 at 12:27 AM, Oza Oza wrote:
>> On Mon, Mar 27, 2017 at 8:16 PM, Rob Herring wrote:
>>> On Sat, Mar 25, 2017 at 12:31 AM, Oza Pawandeep
>>> wrote:
it is possible that PCI device supports 64-bit DMA addressing,
/linux/pci.h
>> @@ -2086,6 +2086,7 @@ void pci_release_of_node(struct pci_dev *dev);
>> void pci_set_bus_of_node(struct pci_bus *bus);
>> void pci_release_bus_of_node(struct pci_bus *bus);
>> struct irq_domain *pci_host_bridge_of_msi_domain(struct pci_bus *bus);
>> +stru
line struct device_node *
> pci_device_to_OF_node(const struct pci_dev *pdev) { return NULL; }
> static inline struct irq_domain *
> pci_host_bridge_of_msi_domain(struct pci_bus *bus) { return NULL; }
> +static inline struct device_node *
> +pci_dev_get_dma_of_node(struct pci_dev *dev) { return NULL; }
> #endif /* CONFIG_OF */
>
> #ifdef CONFIG_ACPI
>
pci and memory mapped device world is different. of course if you talk
from iommu perspective, all the master are same for IOMMU
but the original intention of the patch is to try to solve 2 problems.
1) expose generic API for pci world clients to configure their
dma-ranges. right now there is none.
2) same API can be used by IOMMU to derive dma_mask.
the implementation tries to handle dma-ranges for both memory mapped
and pci devices, which I think is overkill.
besides we have different configuration of dma-ranges based on iommu
is enabled or not enabled.
#define PCIE_DMA_RANGES dma-ranges = <0x4300 0x00 0x8000 0x00
0x8000 0x00 0x8000 \
0x4300 0x08 0x 0x08
0x 0x08 0x \
0x4300 0x80 0x 0x80
0x 0x40 0x>;
the of_dma_get_range is written with respect to traditional memory
ranges, they were not meant for pci dma-ranges.
Regards,
Oza.
On 28/03/17 06:27, Oza Oza wrote:
> On Mon, Mar 27, 2017 at 8:16 PM, Rob Herring wrote:
>> On Sat, Mar 25, 2017 at 12:31 AM, Oza Pawandeep wrote:
>>> it is possible that PCI device supports 64-bit DMA addressing,
>>> and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64),
>>> however PCI
On Tue, Mar 28, 2017 at 12:27 AM, Oza Oza wrote:
> On Mon, Mar 27, 2017 at 8:16 PM, Rob Herring wrote:
>> On Sat, Mar 25, 2017 at 12:31 AM, Oza Pawandeep wrote:
>>> it is possible that PCI device supports 64-bit DMA addressing,
>>> and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64),
On Mon, Mar 27, 2017 at 8:16 PM, Rob Herring wrote:
> On Sat, Mar 25, 2017 at 12:31 AM, Oza Pawandeep wrote:
>> it is possible that PCI device supports 64-bit DMA addressing,
>> and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64),
>> however PCI host bridge may have limitations on the
On Sat, Mar 25, 2017 at 12:31 AM, Oza Pawandeep wrote:
> it is possible that PCI device supports 64-bit DMA addressing,
> and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64),
> however PCI host bridge may have limitations on the inbound
> transaction addressing. As an example, consider
it is possible that PCI device supports 64-bit DMA addressing,
and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64),
however PCI host bridge may have limitations on the inbound
transaction addressing. As an example, consider NVME SSD device
connected to iproc-PCIe controller.
Currently,
This is v2 of this patch series.
The first series had missing commit logs and named the dma_dev differently
in include/linux/mcb.h and drivers/mcb/mcb-core.c.
This small series of two patches enable (PCI) DMA support in MCB.
The first patch enables PCI bus mastering by default for all PCI
I'm sorry for the errors in the patches.
I'll correct them and resend everything.
On Mon, Aug 29, 2016 at 02:08:21PM +0200, Michael Moese wrote:
> This small series of two patches enable (PCI) DMA support in MCB.
>
> The first patch enables PCI bus mastering by default for
This small series of two patches enable (PCI) DMA support in MCB.
The first patch enables PCI bus mastering by default for all
PCI-based MCB devices.
The second patch adds a dma_device to the mcb_device for all devices
as a shortcut to mcb_device->bus->carrier.
Michael Moese (2):
Enab
1 - 100 of 192 matches
Mail list logo
