[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANCKTBs--M6FHHp4YMcTGox+OeKanz2-QJ8-1_R99XHq2iR37g@mail.gmail.com>
Date: Fri, 28 Sep 2018 17:48:00 -0400
From: Jim Quinlan <jim2101024@...il.com>
To: Paul Burton <paul.burton@...s.com>
Cc: linux-kernel@...r.kernel.org, Kevin Cernekee <cernekee@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Ralf Baechle <ralf@...ux-mips.org>,
James Hogan <jhogan@...nel.org>,
Linux-MIPS <linux-mips@...ux-mips.org>,
bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
linux-pci <linux-pci@...r.kernel.org>,
Christoph Hellwig <hch@....de>
Subject: Re: [PATCH v5 06/12] MIPS: BMIPS: add dma remap for BrcmSTB PCIe
On Wed, Sep 26, 2018 at 6:07 PM Paul Burton <paul.burton@...s.com> wrote:
>
> Hi Jim,
>
> On Wed, Sep 19, 2018 at 10:32:01AM -0400, Jim Quinlan wrote:
> > The design of the Broadcom PCIe RC controller requires us to remap its
> > DMA addresses for inbound traffic. We do this by modifying the
> > definitions of __phys_to_dma() and __dma_to_phys().
> >
> > In arch/mips/bmips/dma.c, these functions are already in use to remap
> > DMA addresses for the 338x SOC chips. We leave this code alone -- and
> > give its mapping priority -- but if it is not in use, the PCIe DMA
> > mapping is in effect.
> >
> > One might think that the two DMA remapping systems of dma.c could be
> > combined, but they cannot: one governs only DMA addresses for the PCIe
> > controller of BrcmSTB ARM/ARM64/MIPs chips, while the other governs
> > the PCIe controller *and* other peripherals for only MIPs 338x
> > chips.
> >
> > Signed-off-by: Jim Quinlan <jim2101024@...il.com>
> > ---
> > arch/mips/bmips/dma.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
>
> Please copy me/linux-mips on the whole series next time - I seem to have
> only received patches 6, 8 & 9 which means I have no idea whether they
> have dependencies & if so whether those dependencies have been accepted
> or rejected. I also have no clue whether these patches make sense to
> take through the MIPS tree or if it would make more sense for someone
> else to take them with acks.
Hi Paul,
I had problem with the first time I sent this out and someone said I
should reduce me email list so I used the "git email --cc_cmd
get_mainters.pl". I'll switch back to an aggregate email list.
>
> > diff --git a/arch/mips/bmips/dma.c b/arch/mips/bmips/dma.c
> > index 3d13c77..292994f 100644
> > --- a/arch/mips/bmips/dma.c
> > +++ b/arch/mips/bmips/dma.c
> > @@ -18,6 +18,7 @@
> > #include <linux/slab.h>
> > #include <linux/types.h>
> > #include <asm/bmips.h>
> > +#include <soc/brcmstb/common.h>
> >
> > /*
> > * BCM338x has configurable address translation windows which allow the
> > @@ -44,6 +45,10 @@ dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t pa)
> > {
> > struct bmips_dma_range *r;
> >
> > +#ifdef CONFIG_PCIE_BRCMSTB
> > + if (!bmips_dma_ranges)
> > + return brcm_phys_to_dma(dev, pa);
> > +#endif
> > for (r = bmips_dma_ranges; r && r->size; r++) {
> > if (pa >= r->child_addr &&
> > pa < (r->child_addr + r->size))
>
> I can't tell because I presume brcm_phys_to_dma() is added in one of
> those patches I wasn't copied on, but perhaps you could avoid the #ifdef
> by just returning brcm_phys_to_dma(dev, pa) after the loop?
Yes, will rectify in next version.
>
> > @@ -56,6 +61,10 @@ phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dma_addr)
> > {
> > struct bmips_dma_range *r;
> >
> > +#ifdef CONFIG_PCIE_BRCMSTB
> > + if (!bmips_dma_ranges)
> > + return (unsigned long)brcm_dma_to_phys(dev, dma_addr);
> > +#endif
> > for (r = bmips_dma_ranges; r && r->size; r++) {
> > if (dma_addr >= r->parent_addr &&
> > dma_addr < (r->parent_addr + r->size))
>
> And similar here.
>
Okay, thanks,
Jim
> Thanks,
> Paul
Powered by blists - more mailing lists