I'll get on it.
Jim
On Tue, Nov 3, 2020 at 12:42 PM Florian Fainelli wrote:
>
>
>
> On 11/3/2020 2:15 AM, Christoph Hellwig wrote:
> > Hi Florian and others,
> >
> > now that the generic DMA ranges code landed, can we switch bmips over
> > to it instead of duplicating the logic?
>
> This should
/git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-ranges.2
>
Tested-by: Jim Quinlan
> Note that we'll still need to sort out the arm/keystone warnings from
> the original patch. Do we have anyone on the CC list who knows that
> platform a little better to figure o
On Mon, Sep 7, 2020 at 5:16 AM Lorenzo Pieralisi
wrote:
>
> On Thu, Aug 27, 2020 at 09:29:59AM -0400, Jim Quinlan wrote:
> > On Thu, Aug 27, 2020 at 2:35 AM Christoph Hellwig wrote:
> > >
> > > On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote:
>
On Mon, Sep 7, 2020 at 11:01 AM Nicolas Saenz Julienne
wrote:
>
> Hi Jim, sorry I'm a little late to the party, but was on vacation.
>
> On Thu, 2020-09-03 at 13:32 -0400, Jim Quinlan wrote:
> > On Wed, Sep 2, 2020 at 8:52 PM Nathan Chancellor
> > wrote:
> > &
EBUG by any
> > chance?
>
> Of course. A new log is attached with the debug output from that config.
Hi Nicolas,
Can you please help us out here? It appears that your commit
3d2cbb644836 "ARM: dts: bcm2711: Move emmc2 into its own bus"
added the following line to the bcm27
On Wed, Sep 2, 2020 at 5:53 PM Nathan Chancellor
wrote:
>
> On Mon, Aug 24, 2020 at 03:30:20PM -0400, Jim Quinlan wrote:
> > The new field 'dma_range_map' in struct device is used to facilitate the
> > use of single or multiple offsets between mapping regions of cpu
A real change is that I changed the
> prototype for dma_copy_dma_range_map to require less boilerplate code.
>
> The result is here:
>
>
> http://git.infradead.org/users/hch/dma-mapping.git/commitdiff/eef520b232c60e74eb8b33a5a7863ad8f2b4a5c7
>
> please double check t
On Thu, Aug 27, 2020 at 2:35 AM Christoph Hellwig wrote:
>
> On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote:
> > Hi,
> >
> > On 8/24/2020 12:30 PM, Jim Quinlan wrote:
> >>
> >> Patchset Summary:
> >>Enhance a PCIe hos
Hi Andy,
On Tue, Aug 25, 2020 at 5:54 AM Andy Shevchenko
wrote:
>
> On Mon, Aug 24, 2020 at 03:30:20PM -0400, Jim Quinlan wrote:
> > The new field 'dma_range_map' in struct device is used to facilitate the
> > use of single or multiple offsets between mapping regi
_range(dev, cpu_addr, dma_addr, size).
Signed-off-by: Jim Quinlan
---
arch/arm/include/asm/dma-mapping.h| 10 +--
arch/arm/mach-keystone/keystone.c | 17 +++--
arch/sh/drivers/pci/pcie-sh7786.c | 9 +--
arch/x86/pci/sta2x11-fixup.c
or sticking point was the code required
for the DMA remapping needed for the PCIe driver to work [1].
There have been many changes to the DMA and OF subsystems since that
time, making a cleaner and less intrusive patchset possible. This
patchset implements a generalization of "dev->dm
Hi Anday,
On Tue, Aug 18, 2020 at 4:14 AM Andy Shevchenko
wrote:
>
> On Mon, Aug 17, 2020 at 05:53:09PM -0400, Jim Quinlan wrote:
> > The new field 'dma_range_map' in struct device is used to facilitate the
> > use of single or multiple offsets between mapping regi
_range(dev, cpu_addr, dma_addr, size).
Signed-off-by: Jim Quinlan
---
arch/arm/include/asm/dma-mapping.h| 10 +--
arch/arm/mach-keystone/keystone.c | 17 +++--
arch/sh/drivers/pci/pcie-sh7786.c | 9 +--
arch/sh/kernel/dma-coherent.c | 1
that
time, making a cleaner and less intrusive patchset possible. This
patchset implements a generalization of "dev->dma_pfn_offset", except
that instead of a single scalar offset it provides for multiple
offsets via a function which depends upon the "dma-ranges" propert
_range(dev, cpu_addr, dma_addr, size).
Signed-off-by: Jim Quinlan
---
arch/arm/include/asm/dma-mapping.h| 10 +--
arch/arm/mach-keystone/keystone.c | 17 +++--
arch/sh/drivers/pci/pcie-sh7786.c | 9 +--
arch/sh/kernel/dma-coherent.c | 1
that
time, making a cleaner and less intrusive patchset possible. This
patchset implements a generalization of "dev->dma_pfn_offset", except
that instead of a single scalar offset it provides for multiple
offsets via a function which depends upon the "dma-ranges" propert
On Sat, Aug 1, 2020 at 1:17 PM Nicolas Saenz Julienne
wrote:
>
> Hi Jim, here's some comments after testing your series against RPi4.
>
> On Fri, 2020-07-24 at 16:33 -0400, Jim Quinlan wrote:
> > The new field 'dma_range_map' in struct device is used to fa
On Thu, Jul 30, 2020 at 1:05 PM Nicolas Saenz Julienne
wrote:
>
> Hi Jim,
>
> On Fri, 2020-07-24 at 16:33 -0400, Jim Quinlan wrote:
> > static void __init of_unittest_pci_dma_ranges(void)
> > diff --git a/drivers/pci/controller/pcie-brcmstb.c
> > b/drivers
On Wed, Jul 29, 2020 at 10:28 AM Rob Herring wrote:
>
> On Wed, Jul 29, 2020 at 12:19 AM Christoph Hellwig wrote:
> >
> > On Tue, Jul 28, 2020 at 02:24:51PM -0400, Jim Quinlan wrote:
> > > I started using devm_kcalloc() but at least two reviewers convinced me
>
On Wed, Jul 29, 2020 at 2:19 AM Christoph Hellwig wrote:
>
> On Tue, Jul 28, 2020 at 02:24:51PM -0400, Jim Quinlan wrote:
> > I started using devm_kcalloc() but at least two reviewers convinced me
> > to just use kcalloc(). In addition, when I was using devm_kcalloc()
> >
r 5.9 and then
> finish up for 5.10? If the former I can apply it to the dma-mapping
> tree and just fix up the nitpicks.
Whatever you think is best -- I would be quite happy if you could
accept at least the "dma_range_map" commit. Of course I'd be most
happy if the entir
On Tue, Jul 28, 2020 at 11:05 AM Rob Herring wrote:
>
> On Fri, Jul 24, 2020 at 2:45 PM Jim Quinlan
> wrote:
> >
> > The new field 'dma_range_map' in struct device is used to facilitate the
> > use of single or multiple offsets between mapping region
apping needed for the PCIe driver to work [1].
There have been many changes to the DMA and OF subsystems since that
time, making a cleaner and less intrusive patchset possible. This
patchset implements a generalization of "dev->dma_pfn_offset", except
that instead of a single scalar offset
_range(dev, cpu_addr, dma_addr, size).
Signed-off-by: Jim Quinlan
---
arch/arm/include/asm/dma-mapping.h| 10 +--
arch/arm/mach-keystone/keystone.c | 17 +++--
arch/sh/drivers/pci/pcie-sh7786.c | 9 +--
arch/sh/kernel/dma-coherent.c | 1
On Tue, Jul 21, 2020 at 8:51 AM Christoph Hellwig wrote:
>
> On Wed, Jul 15, 2020 at 10:35:11AM -0400, Jim Quinlan wrote:
> > The new field 'dma_range_map' in struct device is used to facilitate the
> > use of single or multiple offsets between mapping regions of cpu
making a cleaner and less intrusive patchset possible. This
patchset implements a generalization of "dev->dma_pfn_offset", except
that instead of a single scalar offset it provides for multiple
offsets via a function which depends upon the "dma-ranges" property of
the PCIe host con
_range(dev, cpu_addr, dma_addr, size).
Signed-off-by: Jim Quinlan
---
arch/arm/include/asm/dma-mapping.h| 9 +-
arch/arm/mach-keystone/keystone.c | 17 ++--
arch/sh/drivers/pci/pcie-sh7786.c | 9 +-
arch/sh/kernel/dma-coherent.c | 1
Hi Christoph,
I'm sending all commits to since most of
them are PCI related. I don't send all patches to
linux-ker...@vger.kernel.org since I've read it is overused. The --cc
list is generated by get_maintainer.pl.
IIRC, in a previous discussion you said you preferred NOT to get the
entire pat
tchset implements a generalization of "dev->dma_pfn_offset", except
that instead of a single scalar offset it provides for multiple
offsets via a function which depends upon the "dma-ranges" property of
the PCIe host controller. This is required for proper functionality
of th
_range(dev, cpu_addr, dma_addr, size).
Signed-off-by: Jim Quinlan
---
arch/arm/include/asm/dma-mapping.h| 9 +-
arch/arm/mach-keystone/keystone.c | 17 ++--
arch/sh/drivers/pci/pcie-sh7786.c | 9 +-
arch/sh/kernel/dma-coherent.c | 1
Hi Andy,
Sorry for the delay in response. I will do what you suggest in your
email. I do have one response to one of your comments below.
On Thu, Jul 2, 2020 at 4:43 AM Andy Shevchenko
wrote:
>
> On Wed, Jul 01, 2020 at 05:21:38PM -0400, Jim Quinlan wrote:
> > The new field '
_range(dev, cpu_addr, dma_addr, size).
Signed-off-by: Jim Quinlan
---
arch/arm/include/asm/dma-mapping.h| 9 +-
arch/arm/mach-keystone/keystone.c | 17 ++--
arch/sh/drivers/pci/pcie-sh7786.c | 9 +-
arch/sh/kernel/dma-coherent.c |
ems since that
time, making a cleaner and less intrusive patchset possible. This
patchset implements a generalization of "dev->dma_pfn_offset", except
that instead of a single scalar offset it provides for multiple
offsets via a function which depends upon the "dma-ranges" property
On Wed, Jun 17, 2020 at 9:00 AM Robin Murphy wrote:
>
> Hi Jim,
>
> Thanks for taking this on!
Hi Robin,
>
> On 2020-06-16 21:55, Jim Quinlan wrote:
> > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > the use of single or mu
ffset in the kernel driver
code. These cases now invoke the function
dma_attach_uniform_pfn_offset(dev, pfn_offset).
Signed-off-by: Jim Quinlan
---
arch/arm/include/asm/dma-mapping.h| 9 +--
arch/arm/mach-keystone/keystone.c | 8 ++-
arch/sh/drivers/pci/pcie-sh7786.c
t
time, making a cleaner and less intrusive patchset possible. This
patchset implements a generalization of "dev->dma_pfn_offset", except
that instead of a single scalar offset it provides for multiple
offsets via a function which depends upon the "dma-ranges" property o
Hi Andy,
On Tue, Jun 9, 2020 at 7:18 AM Andy Shevchenko
wrote:
>
> On Mon, Jun 08, 2020 at 11:48:51AM -0400, Jim Quinlan wrote:
> > On Sun, Jun 7, 2020 at 12:500f9bfe0fb8840b268af1bbcc51f1cd440514e PM
> > Andy Shevchenko wrote:
> > > On Fri, Jun 05, 2020 at 05:26:48
Hi Andy,
On Sun, Jun 7, 2020 at 12:500f9bfe0fb8840b268af1bbcc51f1cd440514e PM
Andy Shevchenko wrote:
>
> On Fri, Jun 05, 2020 at 05:26:48PM -0400, Jim Quinlan wrote:
> > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > the use of si
e
offsets via a function which depends upon the "dma-ranges" property of
the PCIe host controller. This is required for proper functionality
of the BrcmSTB PCIe controller and possibly some other devices.
[1]
https://lore.kernel.org/linux-arm-kernel/1516058925-46522-5-git-send-email-ji
ffset in the kernel driver
code. These cases now invoke the function
dma_attach_uniform_pfn_offset(dev, pfn_offset).
Signed-off-by: Jim Quinlan
---
arch/arm/include/asm/dma-mapping.h| 9 +--
arch/arm/mach-keystone/keystone.c | 9 ++-
arch/sh/drivers/pci/pcie-sh7786.c
elming usage of say,
> dev->dma_pfn_offset, involves shifting it.
>
> Hi Jim,
> On Thu, 2020-06-04 at 14:01 -0400, Jim Quinlan wrote:
> > Hi Nicolas,
>
> [...]
>
> > > I understand the need for dev to be around, devm_*() is key. But also it's
> > >
Hi Nicolas,
On Thu, Jun 4, 2020 at 12:52 PM Nicolas Saenz Julienne
wrote:
>
> Hi Jim,
>
> On Thu, 2020-06-04 at 10:35 -0400, Jim Quinlan wrote:
>
> [...]
>
> > > > --- a/arch/sh/kernel/dma-coherent.c
> > > > +++ b/arch/sh/kernel/dma-coherent.c
&
Hi Andy,
On Thu, Jun 4, 2020 at 11:05 AM Andy Shevchenko
wrote:
>
> On Thu, Jun 04, 2020 at 10:35:12AM -0400, Jim Quinlan wrote:
> > On Thu, Jun 4, 2020 at 9:53 AM Nicolas Saenz Julienne
> > wrote:
> > > On Wed, 2020-06-03 at 15:20 -0400, Jim Quinlan wrote:
&
On Thu, Jun 4, 2020 at 10:20 AM Dan Carpenter wrote:
>
> On Thu, Jun 04, 2020 at 09:48:49AM -0400, Jim Quinlan wrote:
> > > > + r = devm_kcalloc(dev, 1, sizeof(struct dma_pfn_offset_region),
> > > > + GFP_KERNEL);
> > >
> &
On Thu, Jun 4, 2020 at 9:53 AM Nicolas Saenz Julienne
wrote:
>
> Hi Jim,
>
> On Wed, 2020-06-03 at 15:20 -0400, Jim Quinlan wrote:
> > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > the use of multiple pfn offsets between cpu add
Hi Dan,
On Thu, Jun 4, 2020 at 7:06 AM Dan Carpenter wrote:
>
> On Wed, Jun 03, 2020 at 03:20:41PM -0400, Jim Quinlan wrote:
> > @@ -786,7 +787,7 @@ static int sun4i_backend_bind(struct device *dev,
> > struct device *master,
> > const struct sun4i_backend_quirks *
ypical manner to set pfn offsets but there
are a number of ad hoc assignments to dev->dma_pfn_offset in the
kernel code. These cases now invoke the function
attach_uniform_dma_pfn_offset(dev, pfn_offset).
Signed-off-by: Jim Quinlan
---
arch/arm/include/asm/dma-mapping.h| 9 +
ead of a single scalar offset it provides for multiple
offsets via a function which depends upon the "dma-ranges" property of
the PCIe host controller. This is required for proper functionality
of the BrcmSTB PCIe controller and possibly some other devices.
[1]
https://lore.ker
On Fri, May 29, 2020 at 1:49 PM Rob Herring wrote:
>
> On Tue, May 26, 2020 at 03:12:39PM -0400, Jim Quinlan wrote:
> > v2:
> > Commit: "device core: Add ability to handle multiple dma offsets"
> > o Added helper func attach_dma_pfn_offset_map() in address.
On Fri, May 29, 2020 at 1:35 PM Rob Herring wrote:
>
> On Wed, May 27, 2020 at 9:43 AM Jim Quinlan
> wrote:
> >
> > Hi Nicolas,
> >
> > On Wed, May 27, 2020 at 11:00 AM Nicolas Saenz Julienne
> > wrote:
> > >
> > > Hi Jim,
>
check out.
>
> On Tue, 2020-05-26 at 15:12 -0400, Jim Quinlan wrote:
> > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > the use of multiple pfn offsets between cpu addrs and dma addrs. It is
> > similar to 'dma_pfn_offset
Hello Andy,
On Tue, May 26, 2020 at 4:54 PM Andy Shevchenko
wrote:
>
> On Tue, May 26, 2020 at 03:12:48PM -0400, Jim Quinlan wrote:
> > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > the use of multiple pfn offsets between cpu
The new field in struct device 'dma_pfn_offset_map' is used to facilitate
the use of multiple pfn offsets between cpu addrs and dma addrs. It is
similar to 'dma_pfn_offset' except that the offset chosen depends on the
cpu or dma address involved.
Signed-off-by: Jim Quin
controller and possibly some other devices.
[1]
https://lore.kernel.org/linux-arm-kernel/1516058925-46522-5-git-send-email-jim2101...@gmail.com/
Jim Quinlan (14):
PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB
ata: ahci_brcm: Fix use of BCM7216 reset controller
dt-bindings: PCI: Add bindin
Hi Nicolas,
On Wed, May 20, 2020 at 7:28 AM Nicolas Saenz Julienne
wrote:
>
> Hi Jim,
> thanks for having a go at this! My two cents.
>
> On Tue, 2020-05-19 at 16:34 -0400, Jim Quinlan wrote:
> > The device variable 'dma_pfn_offset' is used to do a single
> >
Sorry, I meant to put you on the to-list for all patches. The last
time I sent out this many patches using a collective cc-list for all
patches I was told to reduce my cc-list.
Jim
On Wed, May 20, 2020 at 1:42 PM Christoph Hellwig wrote:
>
> If you don't Cc me on the whole series I have absolut
On Wed, May 20, 2020 at 10:03 AM Greg Kroah-Hartman <
gre...@linuxfoundation.org> wrote:
> On Wed, May 20, 2020 at 09:50:36AM -0400, Jim Quinlan wrote:
> > On Wed, May 20, 2020 at 1:43 AM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Tue, May 19, 2020
On Wed, May 20, 2020 at 1:43 AM Greg Kroah-Hartman
wrote:
>
> On Tue, May 19, 2020 at 04:34:07PM -0400, Jim Quinlan wrote:
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index ac8e37cd716a..6cd916860b5f 100644
> > --- a/include/linux/device.h
> >
The device variable 'dma_pfn_offset' is used to do a single
linear map between cpu addrs and dma addrs. The variable
'dma_map' is added to struct device to point to an array
of multiple offsets which is required for some devices.
Signed-off-by: Jim Quinlan
---
drivers/of/a
-46522-5-git-send-email-jim2101...@gmail.com/
Jim Quinlan (15):
PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB
ahci_brcm: fix use of BCM7216 reset controller
dt-bindings: PCI: Add bindings for more Brcmstb chips
PCI: brcmstb: Add compatibily of other chips
PCI: brcmstb: Add suspend and resum
Just like dma_pfn_offset, another offset is added to
the dma/phys translation if there happen to be multiple
regions that have different mapping offsets.
Signed-off-by: Jim Quinlan
---
include/linux/dma-direct.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux
On Mon, Oct 23, 2017 at 5:06 AM, David Laight wrote:
> From: Jim Quinlan
>> Sent: 20 October 2017 16:28
>> On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig wrote:
>> > On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
>> >> I am not sure I unders
On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig wrote:
> On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
>> I am not sure I understand your comment -- the size of the request
>> shouldn't be a factor. Let's look at your example of the DMA request
&
On Fri, Oct 20, 2017 at 3:37 AM, Christoph Hellwig wrote:
> On Thu, Oct 19, 2017 at 06:47:45PM -0400, Jim Quinlan wrote:
>> The only way to prevent this is to reserve a single page at the end of
>> the first memory region of any pair that are adjacent in physical
>> memory
On Thu, Oct 19, 2017 at 5:16 AM, Christoph Hellwig wrote:
> On Wed, Oct 18, 2017 at 10:41:17AM -0400, Jim Quinlan wrote:
>> That's what brcm_to_{pci,cpu} are for -- they keep a list of the
>> dma-ranges given in the PCIe DT node, and translate from system memory
>&
On Wed, Oct 18, 2017 at 2:53 AM, Christoph Hellwig wrote:
> On Tue, Oct 17, 2017 at 12:11:55PM -0400, Jim Quinlan wrote:
>> My understanding is that dma_pfn_offset is that it is a single
>> constant offset from RAM, in our case, to map to PCIe space.
>
> Yes.
>
>>
On Tue, Oct 17, 2017 at 4:14 AM, Christoph Hellwig wrote:
> Just took a quick look over this and I basically agree with the comments
> from Robin.
>
> What I don't understand is why you're even trying to do all these
> hacky things.
>
> It seems like the controller should simply set dma_pfn_offset
On Thu, Oct 12, 2017 at 2:04 PM, Robin Murphy wrote:
> [+DMA API maintainers]
>
> On 11/10/17 23:34, Jim Quinlan wrote:
>> The Broadcom STB PCIe host controller is intimately related to the
>> memory subsystem. This close relationship adds complexity to how cpu
>> syst
68 matches
Mail list logo
