Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On Fri, Jan 26, 2018 at 12:46 PM, Jim Quinlan wrote: > On Fri, Jan 26, 2018 at 2:53 AM, Christoph Hellwig wrote: >> On Wed, Jan 24, 2018 at 12:04:58PM -0800, Florian Fainelli wrote: >>> This looks nicer than the current shape, but this still requires to >>>

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On Fri, Jan 26, 2018 at 12:46 PM, Jim Quinlan wrote: > On Fri, Jan 26, 2018 at 2:53 AM, Christoph Hellwig wrote: >> On Wed, Jan 24, 2018 at 12:04:58PM -0800, Florian Fainelli wrote: >>> This looks nicer than the current shape, but this still requires to >>> register a PCI fixup to override

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On Fri, Jan 26, 2018 at 2:53 AM, Christoph Hellwig wrote: > On Wed, Jan 24, 2018 at 12:04:58PM -0800, Florian Fainelli wrote: >> This looks nicer than the current shape, but this still requires to >> register a PCI fixup to override phys_to_dma() and dma_to_phys(), and it >> would

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On Fri, Jan 26, 2018 at 2:53 AM, Christoph Hellwig wrote: > On Wed, Jan 24, 2018 at 12:04:58PM -0800, Florian Fainelli wrote: >> This looks nicer than the current shape, but this still requires to >> register a PCI fixup to override phys_to_dma() and dma_to_phys(), and it >> would appear that you

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On Wed, Jan 24, 2018 at 12:04:58PM -0800, Florian Fainelli wrote: > This looks nicer than the current shape, but this still requires to > register a PCI fixup to override phys_to_dma() and dma_to_phys(), and it > would appear that you have dodged my question about how this is supposed > to fit

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On Wed, Jan 24, 2018 at 12:04:58PM -0800, Florian Fainelli wrote: > This looks nicer than the current shape, but this still requires to > register a PCI fixup to override phys_to_dma() and dma_to_phys(), and it > would appear that you have dodged my question about how this is supposed > to fit

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On 01/23/2018 05:20 AM, Christoph Hellwig wrote: > On Fri, Jan 19, 2018 at 11:47:54AM -0800, Florian Fainelli wrote: >> How can this work well in the context of a loadable module for instance? >> For MIPS, this would mean that we have to override phys_to_dma() and >> dma_to_phys() in the platform

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On 01/23/2018 05:20 AM, Christoph Hellwig wrote: > On Fri, Jan 19, 2018 at 11:47:54AM -0800, Florian Fainelli wrote: >> How can this work well in the context of a loadable module for instance? >> For MIPS, this would mean that we have to override phys_to_dma() and >> dma_to_phys() in the platform

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On Fri, Jan 19, 2018 at 11:47:54AM -0800, Florian Fainelli wrote: > How can this work well in the context of a loadable module for instance? > For MIPS, this would mean that we have to override phys_to_dma() and > dma_to_phys() in the platform that is *susceptible* to use this PCIe > controller

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On Fri, Jan 19, 2018 at 11:47:54AM -0800, Florian Fainelli wrote: > How can this work well in the context of a loadable module for instance? > For MIPS, this would mean that we have to override phys_to_dma() and > dma_to_phys() in the platform that is *susceptible* to use this PCIe > controller

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On 01/18/2018 07:23 AM, Christoph Hellwig wrote: > On Thu, Jan 18, 2018 at 07:09:23AM -0800, Florian Fainelli wrote: >>> But in this case it actually is the example to follow as told >>> previously. >>> >>> NAK again for these chained dma ops that only create problems. >> >> Care to explain what

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On 01/18/2018 07:23 AM, Christoph Hellwig wrote: > On Thu, Jan 18, 2018 at 07:09:23AM -0800, Florian Fainelli wrote: >>> But in this case it actually is the example to follow as told >>> previously. >>> >>> NAK again for these chained dma ops that only create problems. >> >> Care to explain what

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On Thu, Jan 18, 2018 at 07:09:23AM -0800, Florian Fainelli wrote: > >But in this case it actually is the example to follow as told > >previously. > > > >NAK again for these chained dma ops that only create problems. > > Care to explain what should be done instead? Override phys_to_dma and

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On Thu, Jan 18, 2018 at 07:09:23AM -0800, Florian Fainelli wrote: > >But in this case it actually is the example to follow as told > >previously. > > > >NAK again for these chained dma ops that only create problems. > > Care to explain what should be done instead? Override phys_to_dma and

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On January 17, 2018 11:31:23 PM PST, Christoph Hellwig wrote: >On Wed, Jan 17, 2018 at 08:15:33PM -0600, Rob Herring wrote: >> > (a) overriding/redefining the dma_to_phys() and phys_to_dma() calls >> > that are used by the dma_ops routines. This is the approach of >> > >> >

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On January 17, 2018 11:31:23 PM PST, Christoph Hellwig wrote: >On Wed, Jan 17, 2018 at 08:15:33PM -0600, Rob Herring wrote: >> > (a) overriding/redefining the dma_to_phys() and phys_to_dma() calls >> > that are used by the dma_ops routines. This is the approach of >> > >> >

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On Wed, Jan 17, 2018 at 08:15:33PM -0600, Rob Herring wrote: > > (a) overriding/redefining the dma_to_phys() and phys_to_dma() calls > > that are used by the dma_ops routines. This is the approach of > > > > arch/mips/cavium-octeon/dma-octeon.c > > MIPS is rarely an example to follow. :)

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On Wed, Jan 17, 2018 at 08:15:33PM -0600, Rob Herring wrote: > > (a) overriding/redefining the dma_to_phys() and phys_to_dma() calls > > that are used by the dma_ops routines. This is the approach of > > > > arch/mips/cavium-octeon/dma-octeon.c > > MIPS is rarely an example to follow. :)

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On Mon, Jan 15, 2018 at 5:28 PM, Jim Quinlan wrote: > The Broadcom STB PCIe host controller is intimately related to the > memory subsystem. This close relationship adds complexity to how cpu > system memory is mapped to PCIe memory. Ideally, this mapping is an > identity

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On Mon, Jan 15, 2018 at 5:28 PM, Jim Quinlan wrote: > The Broadcom STB PCIe host controller is intimately related to the > memory subsystem. This close relationship adds complexity to how cpu > system memory is mapped to PCIe memory. Ideally, this mapping is an > identity mapping, or an

[PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

The Broadcom STB PCIe host controller is intimately related to the memory subsystem. This close relationship adds complexity to how cpu system memory is mapped to PCIe memory. Ideally, this mapping is an identity mapping, or an identity mapping off by a constant. Not so in this case. Consider

[PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

The Broadcom STB PCIe host controller is intimately related to the memory subsystem. This close relationship adds complexity to how cpu system memory is mapped to PCIe memory. Ideally, this mapping is an identity mapping, or an identity mapping off by a constant. Not so in this case. Consider